from:"Tomasz Stanislawski"

Hi everyone,
This patchset adds 4 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.

All comments are welcome.

Regards,
Tomasz Stanislawski

Changelog:

v2:
* fix check with gpio_is_valid()
* use U32_MAX instead of ULONG_MAX to be 64-bit-friendly
* use hdmi_driver_data as hdmi's compatile data

v1:
* initial version

Tomasz Stanislawski (4):
  drm: exynos: hdmi: simplify extracting hpd-gpio from DT
  drm: exynos: mixer: fix using usleep() in atomic context
  drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210
SoC
  drm: exynos: hdmi: add support for pixel clock limitation

 .../devicetree/bindings/video/exynos_hdmi.txt  |4 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   30 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |5 +++-
 include/media/s5p_hdmi.h   |1 +
 4 files changed, 31 insertions(+), 9 deletions(-)

-- 
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

[PATCHv2 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..47c6e85 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;
 
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;
 
-   if (!of_find_property(np, hpd-gpio, value)) {
+   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
+   if (!gpio_is_valid(pd-hpd_gpio)) {
DRM_ERROR(no hpd gpio property found\n);
-   goto err_data;
+   return NULL;
}
 
-   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
-   return NULL;
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
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

[PATCHv2 2/4] drm: exynos: mixer: fix using usleep() in atomic context

This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ce28881..e3306c8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx)
/* waiting until VP_SRESET_PROCESSING is 0 */
if (~vp_reg_read(res, VP_SRESET)  VP_SRESET_PROCESSING)
break;
-   usleep_range(1, 12000);
+   mdelay(10);
}
WARN(tries == 0, failed to reset Video Processor\n);
 }
-- 
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

[PATCHv2 3/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |7 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 47c6e85..2a18f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -204,6 +204,10 @@ struct hdmiphy_config {
u8 conf[32];
 };
 
+struct hdmi_driver_data exynos4210_hdmi_driver_data = {
+   .type   = HDMI_TYPE13,
+};
+
 struct hdmi_driver_data exynos4212_hdmi_driver_data = {
.type   = HDMI_TYPE14,
 };
@@ -2032,6 +2036,9 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 
 static struct of_device_id hdmi_match_types[] = {
{
+   .compatible = samsung,exynos4210-hdmi,
+   .data = exynos4210_hdmi_driver_data,
+   }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
 
 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = samsung,exynos4210-mixer,
+   .data   = exynos4210_mxr_drv_data,
+   }, {
.compatible = samsung,exynos5-mixer,
.data   = exynos5250_mxr_drv_data,
}, {
-- 
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

[PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |4 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
 include/media/s5p_hdmi.h   |1 +
 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
 
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+   connectors or bridges not capable of carring higher frequencies
+
 Example:
 
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2a18f4e..404f1b7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources   res;
 
int hpd_gpio;
+   u32 max_pixel_clock;
 
enum hdmi_type  type;
 };
@@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
 
+   if (mode-clock * 1000  hdata-max_pixel_clock)
+   return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret  0)
return MODE_BAD;
@@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
return NULL;
}
 
+   of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
 }
 
@@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
 
+   if (!pdata-max_pixel_clock) {
+   DRM_INFO(max-pixel-clock is zero, using INF\n);
+   pdata-max_pixel_clock = U32_MAX;
+   }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
 
hdata-hpd_gpio = pdata-hpd_gpio;
+   hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
 
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+   u32 max_pixel_clock;
 };
 
 #endif /* S5P_HDMI_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: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

On 04/15/2014 11:42 AM, Rahul Sharma wrote:
 Hi Tomasz,
 
 On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
 Adds support for limitation of maximal pixel clock of HDMI
 signal. This feature is needed on boards that contains
 lines or bridges with frequency limitations.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 ---
  .../devicetree/bindings/video/exynos_hdmi.txt  |4 
  drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
  include/media/s5p_hdmi.h   |1 +
  3 files changed, 17 insertions(+)

 diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
 b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 index f9187a2..8718f8d 100644
 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
 @@ -28,6 +28,10 @@ Required properties:
  - ddc: phandle to the hdmi ddc node
  - phy: phandle to the hdmi phy node

 +Optional properties:
 +- max-pixel-clock: used to limit the maximal pixel clock if a board has 
 lines,
 +   connectors or bridges not capable of carring higher frequencies
 +
  Example:

 hdmi {
 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 2a18f4e..404f1b7 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -195,6 +195,7 @@ struct hdmi_context {
 struct hdmi_resources   res;

 int hpd_gpio;
 +   u32 max_pixel_clock;

 enum hdmi_type  type;
  };
 @@ -887,6 +888,9 @@ static int hdmi_mode_valid(struct drm_connector 
 *connector,
 if (ret)
 return MODE_BAD;

 +   if (mode-clock * 1000  hdata-max_pixel_clock)
 +   return MODE_BAD;
 +
 ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
 if (ret  0)
 return MODE_BAD;
 @@ -2031,6 +2035,8 @@ static struct s5p_hdmi_platform_data 
 *drm_hdmi_dt_parse_pdata
 return NULL;
 }

 +   of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
 +
 return pd;
  }

 @@ -2067,6 +2073,11 @@ static int hdmi_probe(struct platform_device *pdev)
 if (!pdata)
 return -EINVAL;

 +   if (!pdata-max_pixel_clock) {
 +   DRM_INFO(max-pixel-clock is zero, using INF\n);
 +   pdata-max_pixel_clock = U32_MAX;
 +   }
 +
 hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
 if (!hdata)
 return -ENOMEM;
 @@ -2083,6 +2094,7 @@ static int hdmi_probe(struct platform_device *pdev)
 hdata-type = drv_data-type;

 hdata-hpd_gpio = pdata-hpd_gpio;
 +   hdata-max_pixel_clock = pdata-max_pixel_clock;
 hdata-dev = dev;

 ret = hdmi_resources_init(hdata);
 diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
 index 181642b..7272d65 100644
 --- a/include/media/s5p_hdmi.h
 +++ b/include/media/s5p_hdmi.h
 @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
 int mhl_bus;
 struct i2c_board_info *mhl_info;
 int hpd_gpio;
 +   u32 max_pixel_clock;
  };
 
 We have already removed Non DT support from the drm hdmi
 driver. IMO we should not be extending the pdata struct.
 
 Regards,
 Rahul Sharma

Hi Rahul,

This is not a non-DT patch. The s5p_hdmi_platform_data is
generated from DT itself. This structure is just
a parsed version of DT attributes.

It may be a good idea to rename s5p_hdmi_platform_data
to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
or parse DT directly in probe function.

I can prepare a patch for that.

Regards,
Tomasz Stanislawski


 

  #endif /* S5P_HDMI_H */
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

--
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: [PATCHv2 4/4] drm: exynos: hdmi: add support for pixel clock limitation

On 04/15/2014 03:42 PM, Rahul Sharma wrote:
 On 15 April 2014 18:41, Tomasz Stanislawski t.stanisl...@samsung.com wrote:
 On 04/15/2014 11:42 AM, Rahul Sharma wrote:
 Hi Tomasz,

 On 15 April 2014 14:57, Tomasz Stanislawski t.stanisl...@samsung.com 
 wrote:
 Adds support for limitation of maximal pixel clock of HDMI
 signal. This feature is needed on boards that contains
 lines or bridges with frequency limitations.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[snip]

 diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
 index 181642b..7272d65 100644
 --- a/include/media/s5p_hdmi.h
 +++ b/include/media/s5p_hdmi.h
 @@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
 int mhl_bus;
 struct i2c_board_info *mhl_info;
 int hpd_gpio;
 +   u32 max_pixel_clock;
  };

 We have already removed Non DT support from the drm hdmi
 driver. IMO we should not be extending the pdata struct.

 Regards,
 Rahul Sharma

 Hi Rahul,

 This is not a non-DT patch. The s5p_hdmi_platform_data is
 generated from DT itself. This structure is just
 a parsed version of DT attributes.

 It may be a good idea to rename s5p_hdmi_platform_data
 to exynos_hdmi_pdata and move it to exynos_hdmi_drm.c file
 or parse DT directly in probe function.

 I can prepare a patch for that.
 
 Else we can completely remove the dependency from
 s5p_hdmi_platform_data. We can directly assign to hdmi context
 variables. Later we can remove that struct itself from include/.
 What you say?

This structure cannot be removed from include yet because it is used by s5p-tv 
driver.
However its usage can be removed from both drivers.
I can prepare both.

 
 Regards,
 Rahul Sharma
 

Regards,
Tomasz Stanislawski


 Regards,
 Tomasz Stanislawski




  #endif /* S5P_HDMI_H */
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

 

--
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/4] drm: exynos: hdmi: add support for pixel clock limitation

Adds support for limitation of maximal pixel clock of HDMI
signal. This feature is needed on boards that contains
lines or bridges with frequency limitations.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 .../devicetree/bindings/video/exynos_hdmi.txt  |4 
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   12 
 include/media/s5p_hdmi.h   |1 +
 3 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a2..8718f8d 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -28,6 +28,10 @@ Required properties:
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
 
+Optional properties:
+- max-pixel-clock: used to limit the maximal pixel clock if a board has lines,
+   connectors or bridges not capable of carring higher frequencies
+
 Example:
 
hdmi {
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 6fa63ea..ca313b3 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -195,6 +195,7 @@ struct hdmi_context {
struct hdmi_resources   res;
 
int hpd_gpio;
+   u32 max_pixel_clock;
 
enum hdmi_type  type;
 };
@@ -883,6 +884,9 @@ static int hdmi_mode_valid(struct drm_connector *connector,
if (ret)
return MODE_BAD;
 
+   if (mode-clock * 1000  hdata-max_pixel_clock)
+   return MODE_BAD;
+
ret = hdmi_find_phy_conf(hdata, mode-clock * 1000);
if (ret  0)
return MODE_BAD;
@@ -2027,6 +2031,8 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
return NULL;
}
 
+   of_property_read_u32(np, max-pixel-clock, pd-max_pixel_clock);
+
return pd;
 }
 
@@ -2063,6 +2069,11 @@ static int hdmi_probe(struct platform_device *pdev)
if (!pdata)
return -EINVAL;
 
+   if (!pdata-max_pixel_clock) {
+   DRM_INFO(max-pixel-clock is zero, using INF\n);
+   pdata-max_pixel_clock = ULONG_MAX;
+   }
+
hdata = devm_kzalloc(dev, sizeof(struct hdmi_context), GFP_KERNEL);
if (!hdata)
return -ENOMEM;
@@ -2079,6 +2090,7 @@ static int hdmi_probe(struct platform_device *pdev)
hdata-type = drv_data-type;
 
hdata-hpd_gpio = pdata-hpd_gpio;
+   hdata-max_pixel_clock = pdata-max_pixel_clock;
hdata-dev = dev;
 
ret = hdmi_resources_init(hdata);
diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
index 181642b..7272d65 100644
--- a/include/media/s5p_hdmi.h
+++ b/include/media/s5p_hdmi.h
@@ -31,6 +31,7 @@ struct s5p_hdmi_platform_data {
int mhl_bus;
struct i2c_board_info *mhl_info;
int hpd_gpio;
+   u32 max_pixel_clock;
 };
 
 #endif /* S5P_HDMI_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/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

This patch eliminates redundant checks while retrieving HPD gpio from DT during
HDMI's probe().

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..d2d6e2e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 {
struct device_node *np = dev-of_node;
struct s5p_hdmi_platform_data *pd;
-   u32 value;
 
pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
if (!pd)
-   goto err_data;
+   return NULL;
 
-   if (!of_find_property(np, hpd-gpio, value)) {
+   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
+   if (gpio_is_valid(pd-hpd_gpio)) {
DRM_ERROR(no hpd gpio property found\n);
-   goto err_data;
+   return NULL;
}
 
-   pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
-
return pd;
-
-err_data:
-   return NULL;
 }
 
 static struct of_device_id hdmi_match_types[] = {
-- 
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 0/4] drm: exynos: update/fixes to HDMI driver

Hi everyone,
This patchset adds 4 fixes/updates to EXYNOS DRM driver for
HDMI subsystem.

All comments are welcome.

Regards,
Tomasz Stanislawski

Tomasz Stanislawski (4):
  drm: exynos: hdmi: simplify extracting hpd-gpio from DT
  drm: exynos: mixer: fix using usleep() in atomic context
  drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210
SoC
  drm: exynos: hdmi: add support for pixel clock limitation

 .../devicetree/bindings/video/exynos_hdmi.txt  |4 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   26 ++--
 drivers/gpu/drm/exynos/exynos_mixer.c  |5 +++-
 include/media/s5p_hdmi.h   |1 +
 4 files changed, 27 insertions(+), 9 deletions(-)

-- 
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/4] drm: exynos: add compatibles for HDMI and Mixer chips and exynos4210 SoC

This patch add proper compatibles for Mixer and HDMI chip
available on exynos4210 SoCs.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c  |3 +++
 drivers/gpu/drm/exynos/exynos_mixer.c |3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index d2d6e2e..6fa63ea 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2032,6 +2032,9 @@ static struct s5p_hdmi_platform_data 
*drm_hdmi_dt_parse_pdata
 
 static struct of_device_id hdmi_match_types[] = {
{
+   .compatible = samsung,exynos4210-hdmi,
+   .data   = (void *)HDMI_TYPE13,
+   }, {
.compatible = samsung,exynos5-hdmi,
.data = exynos5_hdmi_driver_data,
}, {
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index e3306c8..fd8a9a0 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1187,6 +1187,9 @@ static struct platform_device_id mixer_driver_types[] = {
 
 static struct of_device_id mixer_match_types[] = {
{
+   .compatible = samsung,exynos4210-mixer,
+   .data   = exynos4210_mxr_drv_data,
+   }, {
.compatible = samsung,exynos5-mixer,
.data   = exynos5250_mxr_drv_data,
}, {
-- 
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 2/4] drm: exynos: mixer: fix using usleep() in atomic context

This patch fixes calling usleep_range() after taking reg_slock
using spin_lock_irqsave(). The mdelay() is used instead.
Waiting in atomic context is not the best idea in general.
Hopefully, waiting occurs only when Video Processor fails
to reset correctly.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_mixer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ce28881..e3306c8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -615,7 +615,7 @@ static void vp_win_reset(struct mixer_context *ctx)
/* waiting until VP_SRESET_PROCESSING is 0 */
if (~vp_reg_read(res, VP_SRESET)  VP_SRESET_PROCESSING)
break;
-   usleep_range(1, 12000);
+   mdelay(10);
}
WARN(tries == 0, failed to reset Video Processor\n);
 }
-- 
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 1/4] drm: exynos: hdmi: simplify extracting hpd-gpio from DT

On 04/14/2014 05:00 PM, Tomasz Stanislawski wrote:
 This patch eliminates redundant checks while retrieving HPD gpio from DT 
 during
 HDMI's probe().
 
 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c |   13 -
  1 file changed, 4 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index 9a6d652..d2d6e2e 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -2016,23 +2016,18 @@ static struct s5p_hdmi_platform_data 
 *drm_hdmi_dt_parse_pdata
  {
   struct device_node *np = dev-of_node;
   struct s5p_hdmi_platform_data *pd;
 - u32 value;
  
   pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
   if (!pd)
 - goto err_data;
 + return NULL;
  
 - if (!of_find_property(np, hpd-gpio, value)) {
 + pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
 + if (gpio_is_valid(pd-hpd_gpio)) {

Sorry. Should be !gpio_is_valid().

   DRM_ERROR(no hpd gpio property found\n);
 - goto err_data;
 + return NULL;
   }
  
 - pd-hpd_gpio = of_get_named_gpio(np, hpd-gpio, 0);
 -
   return pd;
 -
 -err_data:
 - return NULL;
  }
  
  static struct of_device_id hdmi_match_types[] = {
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] misc: add sii9234 driver

Add driver for HDMI bridge using MHL connection.
Contains refactored code for MHL driver developed by:

Adam Hampson ahamp...@sta.samsung.com
Erik Gilling konk...@android.com
Shankar Bandal shanka...@samsung.com
Dharam Kumar dharam...@samsung.com

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 Documentation/devicetree/bindings/sii9234.txt |   22 +
 drivers/misc/Kconfig  |8 +
 drivers/misc/Makefile |1 +
 drivers/misc/sii9234.c| 1081 +
 4 files changed, 1112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sii9234.txt
 create mode 100644 drivers/misc/sii9234.c

diff --git a/Documentation/devicetree/bindings/sii9234.txt 
b/Documentation/devicetree/bindings/sii9234.txt
new file mode 100644
index 000..4431139
--- /dev/null
+++ b/Documentation/devicetree/bindings/sii9234.txt
@@ -0,0 +1,22 @@
+SiI9234 Mobile HD Link Transmitter
+
+Required properties:
+- compatible : sil,sii9234.
+- reg : I2C address for TPI interface, use 0x39
+- vcc-supply : regulator that supplies the chip
+- gpio-reset : GPIO connected to RESET_N pin
+- gpio-int : GPIO connected to INT pin
+
+Optional properties:
+- extcon : phandle to extcon that wakes up the chip
+
+Additional compatible properties are also allowed.
+
+Example:
+   sii9234@39 {
+   compatible = sil,sii9234;
+   reg = 0x39;
+   vcc-supply = vsil;
+   gpio-reset = gpf3 4 0;
+   gpio-int = gpf3 5 0;
+   };
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1cb7408..3b7f266 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -515,6 +515,14 @@ config SRAM
  the genalloc API. It is supposed to be used for small on-chip SRAM
  areas found on many SoCs.
 
+config SII9234
+   tristate Silicon Image SII9234 Driver
+   depends on I2C
+   help
+ Say Y here if you want support for the MHL interface.
+ It is an I2C driver, that detects connection of MHL bridge
+ and starts encapsulation of HDMI signal.
+
 source drivers/misc/c2port/Kconfig
 source drivers/misc/eeprom/Kconfig
 source drivers/misc/cb710/Kconfig
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 7eb4b69..145a47a 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -55,3 +55,4 @@ obj-$(CONFIG_SRAM)+= sram.o
 obj-y  += mic/
 obj-$(CONFIG_GENWQE)   += genwqe/
 obj-$(CONFIG_ECHO) += echo/
+obj-$(CONFIG_SII9234)  += sii9234.o
diff --git a/drivers/misc/sii9234.c b/drivers/misc/sii9234.c
new file mode 100644
index 000..60b7c66
--- /dev/null
+++ b/drivers/misc/sii9234.c
@@ -0,0 +1,1081 @@
+/*
+ * Copyright (C) 2014 Samsung Electronics
+ *
+ * Author: Tomasz Stanislawski t.stanisl...@samsung.com
+ *
+ * Based on sii9234 driver created by:
+ *Adam Hampson ahamp...@sta.samsung.com
+ *Erik Gilling konk...@android.com
+ *Shankar Bandal shanka...@samsung.com
+ *Dharam Kumar dharam...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program
+ *
+ */
+
+#include linux/delay.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/wait.h
+#include linux/file.h
+#include linux/uaccess.h
+#include linux/proc_fs.h
+#include linux/extcon.h
+#include linux/of.h
+#include linux/of_gpio.h
+#include linux/extcon.h
+#include linux/regulator/machine.h
+
+/* MHL Tx registers and bits */
+#define MHL_TX_SRST 0x05
+#define MHL_TX_SYSSTAT_REG  0x09
+#define RSEN_STATUS (12)
+#define MHL_TX_INTR1_REG0x71
+#define HPD_CHANGE_INT  (16)
+#define RSEN_CHANGE_INT (15)
+#define MHL_TX_INTR4_REG0x74
+#define RGND_READY_INT  (16)
+#define VBUS_LOW_INT(15)
+#define CBUS_LKOUT_INT  (14)
+#define MHL_DISC_FAIL_INT   (13)
+#define MHL_EST_INT (12)
+#define MHL_TX_INTR1_ENABLE_REG 0x75
+#define HPD_CHANGE_INT_MASK (16)
+#define

[PATCH 2/2] arm: dts: trats2: add SiI9234 node

This patch adds configuration of SiI9234 bridge to Trats2 board.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 arch/arm/boot/dts/exynos4412-trats2.dts |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 9583563d..65fd1d4 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -680,4 +680,47 @@
pulldown-ohm = 10; /* 100K */
io-channels = adc 2;  /* Battery temperature */
};
+
+   vsil: voltage-regulator-vsil {
+   compatible = regulator-fixed;
+   regulator-name = HDMI_5V;
+   regulator-min-microvolt = 500;
+   regulator-max-microvolt = 500;
+   gpio = gpl0 4 0;
+   enable-active-high;
+   vin-supply = buck7_reg;
+   };
+
+   i2c-mhl {
+   compatible = i2c-gpio;
+   gpios = gpf0 4 0 gpf0 6 0;
+   i2c-gpio,delay-us = 100;
+   #address-cells = 1;
+   #size-cells = 0;
+
+   pinctrl-0 = i2c_mhl_bus;
+   pinctrl-names = default;
+   status = okay;
+
+   sii9234: sii9234@39 {
+   compatible = sil,sii9234;
+   vcc-supply = vsil;
+   gpio-reset = gpf3 4 0;
+   gpio-int = gpf3 5 0;
+   reg = 0x39;
+   };
+   };
+};
+
+pinctrl_0 {
+   mhl_int: mhl-int {
+   samsung,pins = gpf3-5;
+   samsung,pin-pud = 0;
+   };
+   i2c_mhl_bus: i2c-mhl-bus {
+   samsung,pins = gpf0-4, gpf0-6;
+   samsung,pin-function = 2;
+   samsung,pin-pud = 1;
+   samsung,pin-drv = 0;
+   };
 };
-- 
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 0/2] Add support for sii9234 chip

Hi everyone,
This patchset adds support for sii9234 HD Mobile Link Bridge. The chip is used
to convert HDMI signal into MHL. The driver enables HDMI output on Trats and
Trats2 boards.

The code is based on the driver [1] developed by:
Adam Hampson ahamp...@sta.samsung.com
Erik Gilling konk...@android.com
with additional contributions from:
Shankar Bandal shanka...@samsung.com
Dharam Kumar dharam...@samsung.com

The drivers architecture was greatly simplified and transformed into a form
accepted (hopefully) by opensource community. The main differences from
original code are:
* using single I2C client instead of 4 subclients
* remove all logic non-related to establishing HDMI link
* simplify error handling
* rewrite state machine in interrupt handler
* wakeup and discovery triggered by an extcon event
* integrate with Device Tree

For now, the driver is added to drivers/misc/ directory because it has neigher
userspace nor kernel interface. The chip is capable of receiving and
processing CEC events, so the driver may export an input device in /dev/ in the
future. However CEC could be also handled by HDMI driver.

I kindly ask for suggestions about the best location for this driver.

Both the chip and the driver are quite autonomic. The chip works as 'invisible
proxy' for HDMI signal, so there is no need to integrate it with HDMI drivers
by helper-subsystems like v4l2_subdev or drm_bridge. If the driver is merged
then the driver from drivers/media/platform/s5p-tv/sii9234_drv.c could be safely
removed.

All comments are welcome.

Regards,
Tomasz Stanislawski

References:
[1]
https://github.com/junpei0824/SC02C-linux/tree/master-jelly-cm-aokp/drivers/media/video/mhl

Tomasz Stanislawski (2):
misc: add sii9234 driver
arm: dts: trats2: add SiI9234 node

Documentation/devicetree/bindings/sii9234.txt | 22 +
arch/arm/boot/dts/exynos4412-trats2.dts | 43 +
drivers/misc/Kconfig |8 +
drivers/misc/Makefile |1 +
drivers/misc/sii9234.c| 1081 +
5 files changed, 1155 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sii9234.txt
create mode 100644 drivers/misc/sii9234.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

Re: [REVIEWv2 PATCH 02/13] vb2: fix handling of data_offset and v4l2_plane.reserved[]

On 04/07/2014 03:11 PM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
 and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
 array in struct v4l2_plane would be non-zero, causing v4l2-compliance
 errors.
 
 More serious is the fact that data_offset was not handled correctly:
 
 - for capture devices it was never zeroed, which meant that it was
   uninitialized. Unless the driver sets it it was a completely random
   number. With the memset above this is now fixed.
 
 - __qbuf_dmabuf had a completely incorrect length check that included
   data_offset.

Hi Hans,

I may understand it wrongly but IMO allowing non-zero data offset
simplifies buffer sharing using dmabuf.
I remember a problem that occurred when someone wanted to use
a single dmabuf with multiplanar API.

For example, MFC shares a buffer with DRM. Assume that DRM device
forces the whole image to be located in one dmabuf.

The MFC uses multiplanar API therefore application must use
the same dmabuf to describe luma and chroma planes.

It is intuitive to use the same dmabuf for both planes and
data_offset=0 for luma plane and data_offset = luma_size
for chroma offset.

The check:

 - if (planes[plane].length  planes[plane].data_offset +
 - q-plane_sizes[plane]) {

assured that the logical plane does not overflow the dmabuf.

Am I wrong?

Regards,
Tomasz Stanislawski

 
 - in __fill_vb2_buffer in the DMABUF case the data_offset field was
   unconditionally copied from v4l2_buffer to v4l2_plane when this
   should only happen in the output case.
 
 - in the single-planar case data_offset was never correctly set to 0.
   The single-planar API doesn't support data_offset, so setting it
   to 0 is the right thing to do. This too is now solved by the memset.
 
 All these issues were found with v4l2-compliance.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REVIEWv3 PATCH 09/13] vb2: add vb2_fileio_is_active and check it more often

Hi Hans,

On 04/11/2014 10:11 AM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 Added a vb2_fileio_is_active inline function that returns true if fileio
 is in progress. Check for this too in mmap() (you don't want apps mmap()ing
 buffers used by fileio) and expbuf() (same reason).

Why? I expect that there is no sane use case for using
mmap() and expbuf in read/write mode but why forbidding this.

Could you provide a reason?

Regard,
Tomasz Stanislawski

 
 In addition drivers should be able to check for this in queue_setup() to
 return an error if an attempt is made to read() or write() with
 V4L2_FIELD_ALTERNATE being configured. This is illegal (there is no way
 to pass the TOP/BOTTOM information around using file I/O).
 
 However, in order to be able to check for this the init_fileio function
 needs to set q-fileio early on, before the buffers are allocated. So switch
 to using internal functions (__reqbufs, vb2_internal_qbuf and
 vb2_internal_streamon) to skip the fileio check. Well, that's why the internal
 functions were created...
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Acked-by: Pawel Osciak pa...@osciak.com
 Acked-by: Sakari Ailus sakari.ai...@linux.intel.com

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REVIEWv2 PATCH 02/13] vb2: fix handling of data_offset and v4l2_plane.reserved[]

On 04/11/2014 03:03 PM, Hans Verkuil wrote:
 On 04/11/2014 02:48 PM, Tomasz Stanislawski wrote:
 On 04/07/2014 03:11 PM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 The videobuf2-core did not zero the 'planes' array in __qbuf_userptr()
 and __qbuf_dmabuf(). That's now memset to 0. Without this the reserved
 array in struct v4l2_plane would be non-zero, causing v4l2-compliance
 errors.

 More serious is the fact that data_offset was not handled correctly:

 - for capture devices it was never zeroed, which meant that it was
   uninitialized. Unless the driver sets it it was a completely random
   number. With the memset above this is now fixed.

 - __qbuf_dmabuf had a completely incorrect length check that included
   data_offset.

 Hi Hans,

 I may understand it wrongly but IMO allowing non-zero data offset
 simplifies buffer sharing using dmabuf.
 I remember a problem that occurred when someone wanted to use
 a single dmabuf with multiplanar API.

 For example, MFC shares a buffer with DRM. Assume that DRM device
 forces the whole image to be located in one dmabuf.

 The MFC uses multiplanar API therefore application must use
 the same dmabuf to describe luma and chroma planes.

 It is intuitive to use the same dmabuf for both planes and
 data_offset=0 for luma plane and data_offset = luma_size
 for chroma offset.

 The check:

 -   if (planes[plane].length  planes[plane].data_offset +
 -   q-plane_sizes[plane]) {

 assured that the logical plane does not overflow the dmabuf.

 Am I wrong?
 
 Yes :-)
 
 For video capture the data_offset field is set by the *driver*, not the
 application. In practice data_offset is the size of a header that is in
 front of the actual image.
 
 You cannot use data_offset for the purpose you describe. To do that a new
 offset field would have to be added (user_offset?). I'm not opposed to
 that, I think it is a valid use-case for both dmabuf and userptr and
 even mmap in combination with CREATE_BUFS.

Ok. What do you think about allowing the user to set this field?
The driver would be allowed to adjust it.
This is a slight change of semantics. As long as application
was forced to treat data_offset as a reserved field (I mean zeroing)
then this change would be backward compatible.

Otherwise, a new field could be introduces as you mentioned.
The name buffer_offset or simply offset might be more
appropriate than user_offset.

I can prepare some RFC about this extension.

Regards,
Tomasz Stanislawski

 
 Regards,
 
   Hans
 

--
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: [PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

2014-04-09 Thread Tomasz Stanislawski

Hi Andrzej,
This issue could be solved by exporting a regmap from PMU driver
or Exynos clock provider for the usage by exynos-simple-phy.
The operations on PHYs from exynos-simple-phy provider would
be chained to PMU driver and protected by a spinlock in the regmap.

Luckily, the divider is not used as far as I know.

Regards,
Tomasz Stanislawski

On 04/09/2014 12:30 PM, Andrzej Hajda wrote:
 Hi Tomasz,
 
 On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
 The HDMIPHY (physical interface) is controlled by a single
 bit in a power controller's regiter. It was implemented
 as clock. It was a simple but effective hack.
 
 This power controller register has also bits to control HDMI clock
 divider ratio. I guess current drivers do not change it, but how do you
 want to implement access to it if some HDMI driver in the future will
 need to change ratio. I guess in case of clk it would be easier.
 
 Regards
 Andrzej
 
 

--
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: [PATCHv2 1/3] phy: Add exynos-simple-phy driver

2014-04-09 Thread Tomasz Stanislawski

Hi Rahul,

On 04/09/2014 11:12 AM, Rahul Sharma wrote:
 Hi Tomasz,
 
 On 9 April 2014 14:07, Andrzej Hajda a.ha...@samsung.com wrote:
 Hi Tomasz,

 On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
 Add exynos-simple-phy driver to support a single register
 PHY interfaces present on Exynos4 SoC.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com

[snip]

 +
 + regs = devm_ioremap(dev, res-start, res-end - res-start);
 + if (!regs) {
 + dev_err(dev, failed to ioremap registers\n);
 + return -EFAULT;
 + }

 Why not devm_ioremap_resource? If not, resource_size function calculates
 length of resource correctly.

 Anyway I like the idea of implementing multiple phys in one driver.
 The only drawback I see is that some phys will be created even there are
 no consumers for them. To avoid such situation you can try to use
 lazy approach - create phy only if there is request for it,
 exynos_phy_xlate callback should allow this.

 Regards
 Andrzej

 
 Idea looks good. How about keeping compatible which is independent
 of SoC, something like samsung,exynos-simple-phy and provide Reg
 and Bit through phy provider node. This way we can avoid SoC specific
 hardcoding in phy driver and don't need to look into dt bindings for
 each new SoC.

A very nice idea BUT there is a very strong pressure from DT guys
to avoid adding any bit fields/offsets/masks in DT nodes.

Hopefully, as long as driver name starts with exynos- prefix
one can hide SoCs specific tricks deep inside driver code.

The idea behind this driver was not to create a generic phy for 1-bit
devices but rather to hide SoC-specific issues from client drivers
like DRM-HDMI.

 
 We can use syscon interface to access PMU bits like USB phy.
 PMU is already registered as system controller
 

Ok. I will try to use it in PATCHv3.

 Regards,
 Rahul Sharma.
 

Regards,
Tomasz Stanislawski


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv2 3/3] s5p-tv: hdmi: use hdmiphy as PHY

The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.

This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/media/platform/s5p-tv/hdmi_drv.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/s5p-tv/hdmi_drv.c 
b/drivers/media/platform/s5p-tv/hdmi_drv.c
index 534722c..8013e52 100644
--- a/drivers/media/platform/s5p-tv/hdmi_drv.c
+++ b/drivers/media/platform/s5p-tv/hdmi_drv.c
@@ -32,6 +32,7 @@
 #include linux/clk.h
 #include linux/regulator/consumer.h
 #include linux/v4l2-dv-timings.h
+#include linux/phy/phy.h
 
 #include media/s5p_hdmi.h
 #include media/v4l2-common.h
@@ -66,7 +67,7 @@ struct hdmi_resources {
struct clk *sclk_hdmi;
struct clk *sclk_pixel;
struct clk *sclk_hdmiphy;
-   struct clk *hdmiphy;
+   struct phy *hdmiphy;
struct regulator_bulk_data *regul_bulk;
int regul_count;
 };
@@ -586,7 +587,7 @@ static int hdmi_resource_poweron(struct hdmi_resources *res)
if (ret  0)
return ret;
/* power-on hdmi physical interface */
-   clk_enable(res-hdmiphy);
+   phy_power_on(res-hdmiphy);
/* use VPP as parent clock; HDMIPHY is not working yet */
clk_set_parent(res-sclk_hdmi, res-sclk_pixel);
/* turn clocks on */
@@ -600,7 +601,7 @@ static void hdmi_resource_poweroff(struct hdmi_resources 
*res)
/* turn clocks off */
clk_disable(res-sclk_hdmi);
/* power-off hdmiphy */
-   clk_disable(res-hdmiphy);
+   phy_power_off(res-hdmiphy);
/* turn HDMI power off */
regulator_bulk_disable(res-regul_count, res-regul_bulk);
 }
@@ -784,7 +785,7 @@ static void hdmi_resources_cleanup(struct hdmi_device *hdev)
/* kfree is NULL-safe */
kfree(res-regul_bulk);
if (!IS_ERR(res-hdmiphy))
-   clk_put(res-hdmiphy);
+   phy_put(res-hdmiphy);
if (!IS_ERR(res-sclk_hdmiphy))
clk_put(res-sclk_hdmiphy);
if (!IS_ERR(res-sclk_pixel))
@@ -835,7 +836,7 @@ static int hdmi_resources_init(struct hdmi_device *hdev)
dev_err(dev, failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
-   res-hdmiphy = clk_get(dev, hdmiphy);
+   res-hdmiphy = phy_get(dev, hdmiphy);
if (IS_ERR(res-hdmiphy)) {
dev_err(dev, failed to get clock 'hdmiphy'\n);
goto fail;
-- 
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

[PATCHv2 2/3] drm: exynos: hdmi: use hdmiphy as PHY

The HDMIPHY (physical interface) is controlled by a single
bit in a power controller's regiter. It was implemented
as clock. It was a simple but effective hack.

This patch makes HDMI driver to control HDMIPHY via PHY interface.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..ef1cdd0 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -36,6 +36,7 @@
 #include linux/i2c.h
 #include linux/of_gpio.h
 #include linux/hdmi.h
+#include linux/phy/phy.h
 
 #include drm/exynos_drm.h
 
@@ -74,8 +75,8 @@ struct hdmi_resources {
struct clk  *sclk_hdmi;
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
-   struct clk  *hdmiphy;
struct clk  *mout_hdmi;
+   struct phy  *hdmiphy;
struct regulator_bulk_data  *regul_bulk;
int regul_count;
 };
@@ -1854,7 +1855,7 @@ static void hdmi_poweron(struct exynos_drm_display 
*display)
if (regulator_bulk_enable(res-regul_count, res-regul_bulk))
DRM_DEBUG_KMS(failed to enable regulator bulk\n);
 
-   clk_prepare_enable(res-hdmiphy);
+   phy_power_on(res-hdmiphy);
clk_prepare_enable(res-hdmi);
clk_prepare_enable(res-sclk_hdmi);
 
@@ -1881,7 +1882,7 @@ static void hdmi_poweroff(struct exynos_drm_display 
*display)
 
clk_disable_unprepare(res-sclk_hdmi);
clk_disable_unprepare(res-hdmi);
-   clk_disable_unprepare(res-hdmiphy);
+   phy_power_off(res-hdmiphy);
regulator_bulk_disable(res-regul_count, res-regul_bulk);
 
pm_runtime_put_sync(hdata-dev);
@@ -1977,9 +1978,9 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
DRM_ERROR(failed to get clock 'sclk_hdmiphy'\n);
goto fail;
}
-   res-hdmiphy = devm_clk_get(dev, hdmiphy);
+   res-hdmiphy = devm_phy_get(dev, hdmiphy);
if (IS_ERR(res-hdmiphy)) {
-   DRM_ERROR(failed to get clock 'hdmiphy'\n);
+   DRM_ERROR(failed to get phy 'hdmiphy'\n);
goto fail;
}
res-mout_hdmi = devm_clk_get(dev, mout_hdmi);
-- 
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

[PATCHv2 1/3] phy: Add exynos-simple-phy driver

Add exynos-simple-phy driver to support a single register
PHY interfaces present on Exynos4 SoC.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 .../devicetree/bindings/phy/samsung-phy.txt|   24 +++
 drivers/phy/Kconfig|5 +
 drivers/phy/Makefile   |1 +
 drivers/phy/exynos-simple-phy.c|  154 
 4 files changed, 184 insertions(+)
 create mode 100644 drivers/phy/exynos-simple-phy.c

diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt 
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38..f97c4c3 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,27 @@ Example:
compatible = samsung,exynos-sataphy-i2c;
reg = 0x38;
};
+
+Samsung S5P/EXYNOS SoC series SIMPLE PHY
+-
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+   - samsung,exynos4210-simple-phy
+   - samsung,exynos4412-simple-phy
+- reg : offset and length of the register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For samsung,exynos4210-simple-phy compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+  0 - HDMI PHY,
+  1 - DAC PHY,
+  2 - ADC PHY,
+  3 - PCIE PHY.
+  4 - SATA PHY.
+
+For samsung,exynos4412-simple-phy compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+  0 - HDMI PHY,
+  1 - ADC PHY,
+
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 3bb05f1..65ab783 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -166,4 +166,9 @@ config PHY_XGENE
help
  This option enables support for APM X-Gene SoC multi-purpose PHY.
 
+config EXYNOS_SIMPLE_PHY
+   tristate Exynos Simple PHY driver
+   help
+ Support for 1-bit PHY controllers on SoCs from Exynos family.
+
 endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 2faf78e..88c5b60 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PHY_EXYNOS4210_USB2) += phy-exynos4210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS4X12_USB2)  += phy-exynos4x12-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5250_USB2)  += phy-exynos5250-usb2.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
+obj-$(CONFIG_EXYNOS_SIMPLE_PHY)+= exynos-simple-phy.o
diff --git a/drivers/phy/exynos-simple-phy.c b/drivers/phy/exynos-simple-phy.c
new file mode 100644
index 000..57ad338
--- /dev/null
+++ b/drivers/phy/exynos-simple-phy.c
@@ -0,0 +1,154 @@
+/*
+ * Exynos Simple PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tomasz Stanislawski t.stanisl...@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/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/phy/phy.h
+
+#define EXYNOS_PHY_ENABLE  (1  0)
+
+static int exynos_phy_power_on(struct phy *phy)
+{
+   void __iomem *reg = phy_get_drvdata(phy);
+   u32 val;
+
+   val = readl(reg);
+   val |= EXYNOS_PHY_ENABLE;
+   writel(val, reg);
+
+   return 0;
+}
+
+static int exynos_phy_power_off(struct phy *phy)
+{
+   void __iomem *reg = phy_get_drvdata(phy);
+   u32 val;
+
+   val = readl(reg);
+   val = ~EXYNOS_PHY_ENABLE;
+   writel(val, reg);
+
+   return 0;
+}
+
+static struct phy_ops exynos_phy_ops = {
+   .power_on   = exynos_phy_power_on,
+   .power_off  = exynos_phy_power_off,
+   .owner  = THIS_MODULE,
+};
+
+static const u32 exynos4210_offsets[] = {
+   0x0700, /* HDMI_PHY */
+   0x070C, /* DAC_PHY */
+   0x0718, /* ADC_PHY */
+   0x071C, /* PCIE_PHY */
+   0x0720, /* SATA_PHY */
+   ~0, /* end mark */
+};
+
+static const u32 exynos4412_offsets[] = {
+   0x0700, /* HDMI_PHY */
+   0x0718, /* ADC_PHY */
+   ~0, /* end mark */
+};
+
+static const struct of_device_id exynos_phy_of_match[] = {
+   { .compatible = samsung,exynos4210-simple-phy,
+ .data = exynos4210_offsets},
+   { .compatible = samsung,exynos4412-simple-phy,
+ .data = exynos4412_offsets},
+   { },
+};
+MODULE_DEVICE_TABLE(of, exynos_phy_of_match);
+
+static struct phy *exynos_phy_xlate(struct device *dev,
+   struct of_phandle_args *args)
+{
+   struct phy **phys = dev_get_drvdata(dev);
+   int index = args-args[0];
+   int i;
+
+   /* verify if index is valid */
+   for (i = 0; i = index; ++i

[PATCHv2 0/3] phy: Add exynos-simple-phy driver

Hello everyone,

The Samsung SoCs from Exynos family are enhanced with a bunch of devices that
provide functionality of a physical layer for interfaces like USB, HDMI, SATA,
etc. They are controlled by a simple interface, often a single bit that enables
and/or resets the physical layer.

An IP driver should to control such a controller in an abstract manner.
Therefore, such 'enablers' were implemented as clocks in older versions of
Linux kernel.  With the dawn of PHY subsystems, PHYs become a natural way of
exporting the 'enabler' functionality to drivers.  However, there is an
unexpected consequence. Some of those 1-bit PHYs were implemented as separate
drivers.  This means that one has to create a struct device, struct phy, its
phy provider and 100-150 lines of driver code to basically set one bit.

The DP phy driver is a good example:
https://lkml.org/lkml/2013/7/18/53

And simple-phy RFC (shares only driver code but not other resources):
https://lkml.org/lkml/2013/10/21/313

To avoid waste of resources I propose to create all such 1-bit phys from Exynos
SoC using a single device, driver and phy provider.

This patchset contains a proposed solution.

All comment are welcome.

Hopefully in future the functionality introduced by this patch may be merged
into a larger Power Management Unit (PMU) gluer driver.  On Samsusng SoC , the
PMU part contains a number of register barely linked to power management (like
clock gating, clock dividers, CPU resetting, etc.).  It may be tempting to
create a hybrid driver that export clocks/phys/etc that are controlled by PMU
unit.

Alternative solutions might be:
* exporting a regmap to the IP driver and allow the driver to control the PHY 
layer
  like in the patch:
  http://thread.gmane.org/gmane.linux.kernel.samsung-soc/28617/focus=28648

* create a dedicated power domain for hdmiphy

Regards,
Tomasz Stanislawski

Changelog:
v2:
* rename to exynos-simple-phy
* fix usage of devm_ioremap()
* add documentation for DT bindings
* add patches to client drivers

v1: initial version

Tomasz Stanislawski (3):
  phy: Add exynos-simple-phy driver
  drm: exynos: hdmi: use hdmiphy as PHY
  s5p-tv: hdmi: use hdmiphy as PHY

 .../devicetree/bindings/phy/samsung-phy.txt|   24 +++
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   11 +-
 drivers/media/platform/s5p-tv/hdmi_drv.c   |   11 +-
 drivers/phy/Kconfig|5 +
 drivers/phy/Makefile   |1 +
 drivers/phy/exynos-simple-phy.c|  154 
 6 files changed, 196 insertions(+), 10 deletions(-)
 create mode 100644 drivers/phy/exynos-simple-phy.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

Re: DMABUF doesn't work when frame size not equal to the size of GPU bo

2013-12-30 Thread Tomasz Stanislawski

Hi Chuanbo Weng,

I suspect that the problem might be caused by difference
between size of DMABUF object and buffer size in V4L2.
What is the content of v4l2_format returned by VIDIOC_G_FMT?
What is the content of V4l2_buffer structure passed by VIDIOC_QBUF?

Regards,
Tomasz Stanislawski

On 12/31/2013 03:42 AM, Chuanbo Weng wrote:
 Hi Laurent,
 
 
 2013/12/29 Laurent Pinchart laurent.pinch...@ideasonboard.com:
 Hi Chuanbo,

 On Friday 27 December 2013 09:55:40 Chuanbo Weng wrote:
 Hi all,

 (My environment is intel platform, HD4000 GPU, kernel 3.10.19, logitech
 270 webcam)

 As title said, I discover this issue when I run the program shown by
 Laurent Pinchart:
 http://www.mail-archive.com/linux-media@vger.kernel.org/msg54806.html

 If the frame is (width, height) = (640, 480), DMABUF works well.
 If the frame is (width, height) = (160, 120), v4lfd receives no event.

 And I dig into drm kernel code, find that: i915_gem_create will create a
 GPU buffer object on intel platform. The size of GPU bo will be bigger
 than frame size, for the reason that i915_gem_create will roundup the bo
 size to multiple of PAGE_SIZE when the frame is (width, height) = (160,
 120). For (width, height) = (640, 480), the frame size is already multiple
 of PAGE_SIZE, so GPU bo is exactly equal to frame size.

 That should in theory not be an issue). This might be a stupid question, but
 have you tried to capture 160x120 images directly (with yavta for instance)
 without using DMABUF ?
 
 Thanks for your reply! Please forgive me if it's a stupid question
 because I'm new in camera
 and v4l2 region. Yes, of course, I have tried to capture 160x120
 images using yavta and v4l-utils
 without using DMABUF (using MMAP), it works well. So it proves the
 camera support this width
 and height.I strongly recommend you to tried 160x120 images using
 DMABUF on your machine,
 because I have tried 3 cameras (two logiteh, one microsoft) and all of
 them don't work.

 I also dump the uvc driver infomation, there is some infomation i
 think maybe important:
 uvcvideo: Stream 1 error event 07 01 len 4

 Looking forward to the discussion!

 --
 Regards,

 Laurent Pinchart

 
 Thanks,
 Chuanbo Weng
 

--
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: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-12-19 Thread Tomasz Stanislawski

Hi Ricardo,
Please refer to the comments below.

On 12/10/2013 09:37 AM, Ricardo Ribalda Delgado wrote:
 Hello Tomasz
 
 Now is my time to say sorry for the delay, but i have been in holidays
 and then I had a pile of work waiting on my desk :).
 

No problem.

 
 
 On Tue, Nov 12, 2013 at 3:54 PM, Tomasz Stanislawski
 t.stanisl...@samsung.com wrote:
 Hi Ricardo,
 Sorry for a late reply. I've been 'offline' for the last two weeks.
 Please refer to the comments below.

[snip]

 As I said. Changes of rectangle n may trigger changes in rectangle n+1 and 
 so on.
 So activation of rectangle B (setting height to non-zero value) will enable
 rectangle C with some default size. Moreover disabling rectangle B (setting 
 height to 0)
 may disable rectangle C automatically. I do not follow what is the problem 
 here?

 
 Lets say you want a configuration composed by 3 rectangles ABC and
 there are no pair of rectangles with a legal configuration. You cannot
 do step by step configuration.
 
 Also lets say that your sensor requires that the total size of the
 image is 700 lines on 3 rectanges and 500 on 4. You cannot do this
 configuration step by step.
 
 

Please, give more details. I do not think that situation is that problematic.
Is it even a practical limitation of hardware?

 Hmm. I think that the real problem is much different.
 Not how to set up rectangles atomically but rather
 how do anything non-trivial atomically in V4L2.

 It would be very nice to have crop/compose and format configured at the same 
 time.
 However, current version of V4L2 API does not support that.

 Setting multiple crop rectangles may help a bit for only this little case.
 But how would like to set multicrop rectangles and multicompose rectangle 
 atomically.
 How to define which crop rectangle refers to which to which compose 
 rectangle.
 
 The number of retangles in crop are the same number of rectables in the 
 compose.
 
 Crop[0] corresponds to compose[0], crop[1]to compose[1] and so on
 

I mean something different.
While using multirectangle selection, one still must use two
VIDIOC_S_SELECTION calls. One to set crop rectangles,
second one to set compose rectangles.
So you cannot set crop and compose atomically, anyway.

Hans proposed some extension to support atomic setup
of both properties. However I think that it is a little overengineered.

I still does not solve problems with flipping and rotations, which may
have a huge impact on mulitrect cropping/composing limitations.


 What to do if one would like to change only 3rd crop rectangle?
 
 You send the whole configuration. The same as today when the user only
 wants to change the pixel format. He still have to send the size.
 

 Introduce rectangle id into v4l2_ext_rect?
 Call VIDIOC_G_SELECTION to get all rectangles, change one and apply 
 VIDIOC_S_SELECTION?
 Is it really scalable?
 
  Why it is not scalable?It is much more scalable than 8 ioctls to set
 8 rectangles.
 
 

One has to copy_from_user/copy_to_user an arbitrary amount of data.
One cannot say I would like to change rectangle number 5.
Using single S_SELECTION for 1 rectangle is only one ioctl need to be called.

When using multirect selections a kernel must copy
all data to user (completely needlessly) during G_SELECTION.
next, the kernel must load all rectangles back to kernel space
(only one rectangle is actually needed to be copied).

It is quite probable that copying 8 rectangle will NOT cause any
performance issues. But copying 256 rectangles in both directions
might cause an observable slowdown.


 Multirectangle targets may seam to be a solution but I think it is not.

 I think that atomic transactions are what is really needed in V4L2.
 Other ideas like try-context from subdev API may also help.

 It will be nice to have something like

 VIDIOC_BEGIN
   VIDIOC_S_SELECTION (target = CROP)
   VIDIOC_S_SELECTION (target = COMPOSE)
   VIDIOC_S_FMT
   VIDIOC_S_CTRL
 VIDIOC_COMMIT

 and call a bunch of VIDIOC_G_* to see what really was applied.

 
 This will trigger other isues. What we do if 2 programs starts two
 transactions at the same time. We will keep a transaction array with
 ALL the configurations? And what happens if there are 100?
 
 

There are multiple ways to solve the problem.
One options would be making VIDIOC_BEGIN a blocking operation
so only one thread can access the critical section.

Other way would be creation of temporary configuration for
each file handle and applying it after VIDIOC_COMMIT.
The VIDIOC_COMMIT would he handled in a driver under a mutex.

There is a huge space for inventions here.

 I have an auxiliary question. Do you have to set all rectangles
 at once? can you set up them one by one?

 Also if you tell the driver what exact configuration you will need, it
 will provide you with the closest possible confuration, that cannot be

 s/cannot be done/may not be 'doable'
 
 cannot be done. The driver cannot guess which rectangles will the user
 set in the future

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-12-19 Thread Tomasz Stanislawski

Hi Ricardo,

On 12/10/2013 10:46 AM, Ricardo Ribalda Delgado wrote:
 Hello Tomasz and Hans
 
 On Thu, Nov 14, 2013 at 4:40 PM, Tomasz Stanislawski
 t.stanisl...@samsung.com wrote:
 Hi Hans,

 On 11/14/2013 11:18 AM, Hans Verkuil wrote:
 Hi Tomasz,

 On 11/12/13 15:54, Tomasz Stanislawski wrote:
 Hi Ricardo,
 Sorry for a late reply. I've been 'offline' for the last two weeks.
 Please refer to the comments below.


 [snip]


 As I said. Changes of rectangle n may trigger changes in rectangle n+1 and 
 so on.
 So activation of rectangle B (setting height to non-zero value) will enable
 rectangle C with some default size. Moreover disabling rectangle B 
 (setting height to 0)
 may disable rectangle C automatically. I do not follow what is the problem 
 here?

 The problem would be in a situation like this:

 ..
 .AA.B.
 ..   --   AAB
 .C.DD. CDD
 ..

 A-D are the rectangles you want to select. They are cropped as shown on the
 left and composed as shown on the right.

 From what Ricardo told me the resulting composed image typically must be
 a proper rectangle without padding anywhere.

 Trying to add rectangles one at a time breaks down when adding C because
 the composition result is no longer a 'proper' rectangle. I don't see how
 you can set something like that up one rectangle at a time.

 I see the issue but I think that it is not a big problem.
 Activating C forms a non-proper rectangle with A and B.
 Therefore, driver must force enabling D to form a proper rectangle again.

 I mean that instead of enlarging C to sum of width of A and B,
 the driver can implicitly activate D to ensure that A,B,C,D form a proper 
 rectangle.
 
 I think this will lead to X different drivers with X different behaviours.
 

I sadly have to agree. All drivers behave differently.
But, is it really an issue?

As I understand a developer is responsible to assure that
future versions of driver works the same (in practical context)
when used by old applications.

The driver is allowed to interpret/adjust user calls.
This includes even ignoring them.


 The special target called V4L2_SEL_TGT_COMPOSE_PADDED was introduced
 to inform application which part of a buffers if going to be modified
 with some undefined value.

 I see nothing against setting a padded rectangle for C to a rectangle that
 covers C and D or even the whole ABCD rectangle.
 I think it could be a great application for PADDED target.
 The application could easily detect which part of a buffer are affected.

 Even applications prepared to work with single crop devices
 would still work after enabling multi crop mode.

 The setup of rectangles my look like this.

 

 S_SELECTION(CROP0 = A)

 crop   compose
 --
 ..
 .AA...
 ..   --   AA..
 .. 
 .. 

 G_SELECTION(COMPOSE0)
   AA..
   
   


 G_SELECTION(COMPOSE0_PADDED)
   AA..
   
   

 

 S_SELECTION(CROP1 = B)
 ..
 .AA.B.
 ..   --   AAB.
 .. 
 .. 

 G_SELECTION(COMPOSE0)
   AA..
   
   

 G_SELECTION(COMPOSE0_PADDED)
   AAA.
   
   

 G_SELECTION(COMPOSE1)
   ..B.
   
   

 G_SELECTION(COMPOSE1_PADDED)
   BBB.
   
   


 

 S_SELECTION(CROP2 = C) - D is activated implicitly
 ..
 .AA.B.
 .C.DD.   --   AAB.
 .. CDD.
 .. 

 G_SELECTION(COMPOSE0_PADDED)

   AAA.
   AAA.
   

 G_SELECTION(COMPOSE2)
   
   C...
   


 G_SELECTION(COMPOSE2_PADDED)
   CCC.
   CCC.
   

 G_SELECTION(COMPOSE3)
   
   .DD.
   


 G_SELECTION(COMPOSE3_PADDED)
   DDD.
   DDD.
   

 One may argue that all this logic is unnecessary after adding support
 for multirect selections.
 So, I kindly ask what should happen if someone call S_SELECTION
 (in multirect mode) passing THREE rectangles A, B, and C (not D) ?

 The driver must adjust rectangles to some valid value. So it can
 increase width of C or implicitly activate D or disable C.
 I think that the best solution is activating D because
 it allows to set size of C to the value closest to requested one.
 Therefore logic for implicit activation of D should be implemented anyway.
 
 You are assuming that the user will send you the rectangles in an
 order that makes sense, but it is not always the case. On the other
 hand if you have all the rectangles, you can ALWAYS make the better
 decisition.
 

Yes. I assume that a user will send rectangles in the right order.
It stated that changing order of V4L2 operations may result
is different configuration. So I do not see a problem that
a specific configuration can be achieved on specific hardware
only if operations are performed in specific order.

 On the other
 hand if you have all the rectangles, you can ALWAYS make the better
 decisition.

I agree completely.
To make a best

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-12-19 Thread Tomasz Stanislawski

Hi Hans,
We've misunderstood. When I was saying 'overengineered'
I did not mean your RFC.
I was taking about this:

#define V4L2_SEL_TGT_CROP_COMPOSE0x0200

struct v4l2_selection {
__u32   type;
__u32   target;
__u32   flags;
union {
struct v4l2_rectr;
struct v4l2_ext_rect*pr;
};
__u32   flags2;
union {
struct v4l2_rectr2;
struct v4l2_ext_rect*pr2;
};
__u32   rectangles;
__u32   reserved[3];
};

This structure looks scary to me :).

 
 I disagree. I implemented it in vivi and it turned out to be quite easy.
 
 For the record: I'm talking about this RFC:
 
 http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/71822
 
 I still does not solve problems with flipping and rotations, which may
 have a huge impact on mulitrect cropping/composing limitations.
 
 My proposal will make that much easier as well since flipping, rotating,
 cropping and composing are all controls/properties that can be set
 atomically (a control cluster). So drivers can create a single function
 that can handle all the relationships in one place, and applications can
 set all of these with one VIDIOC_S_EXT_CTRLS call.
 

I think that your idea is quite good. Solve atomic configuration
in a different part of API (control cluster), not by making
properties larger.

As I said, there are multiple way to handle atomic configuration.
Using control API is one of them. Quite nice BTW :)

Regards,
Tomasz Stanislawski


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-11-14 Thread Tomasz Stanislawski

Hi Hans,

On 11/14/2013 11:18 AM, Hans Verkuil wrote:
 Hi Tomasz,
 
 On 11/12/13 15:54, Tomasz Stanislawski wrote:
 Hi Ricardo,
 Sorry for a late reply. I've been 'offline' for the last two weeks.
 Please refer to the comments below.


[snip]


 As I said. Changes of rectangle n may trigger changes in rectangle n+1 and 
 so on.
 So activation of rectangle B (setting height to non-zero value) will enable
 rectangle C with some default size. Moreover disabling rectangle B (setting 
 height to 0)
 may disable rectangle C automatically. I do not follow what is the problem 
 here?
 
 The problem would be in a situation like this:
 
 ..
 .AA.B.
 ..   --   AAB
 .C.DD. CDD
 ..
 
 A-D are the rectangles you want to select. They are cropped as shown on the
 left and composed as shown on the right.
 
From what Ricardo told me the resulting composed image typically must be
 a proper rectangle without padding anywhere.
 
 Trying to add rectangles one at a time breaks down when adding C because
 the composition result is no longer a 'proper' rectangle. I don't see how
 you can set something like that up one rectangle at a time.

I see the issue but I think that it is not a big problem.
Activating C forms a non-proper rectangle with A and B.
Therefore, driver must force enabling D to form a proper rectangle again.

I mean that instead of enlarging C to sum of width of A and B,
the driver can implicitly activate D to ensure that A,B,C,D form a proper 
rectangle.

The special target called V4L2_SEL_TGT_COMPOSE_PADDED was introduced
to inform application which part of a buffers if going to be modified
with some undefined value.

I see nothing against setting a padded rectangle for C to a rectangle that
covers C and D or even the whole ABCD rectangle.
I think it could be a great application for PADDED target.
The application could easily detect which part of a buffer are affected.

Even applications prepared to work with single crop devices
would still work after enabling multi crop mode.

The setup of rectangles my look like this.



S_SELECTION(CROP0 = A)

crop   compose
--
..
.AA...
..   --   AA..
.. 
.. 

G_SELECTION(COMPOSE0)
  AA..
  
  


G_SELECTION(COMPOSE0_PADDED)
  AA..
  
  



S_SELECTION(CROP1 = B)
..
.AA.B.
..   --   AAB.
.. 
.. 

G_SELECTION(COMPOSE0)
  AA..
  
  

G_SELECTION(COMPOSE0_PADDED)
  AAA.
  
  

G_SELECTION(COMPOSE1)
  ..B.
  
  

G_SELECTION(COMPOSE1_PADDED)
  BBB.
  
  




S_SELECTION(CROP2 = C) - D is activated implicitly
..
.AA.B.
.C.DD.   --   AAB.
.. CDD.
.. 

G_SELECTION(COMPOSE0_PADDED)

  AAA.
  AAA.
  

G_SELECTION(COMPOSE2)
  
  C...
  


G_SELECTION(COMPOSE2_PADDED)
  CCC.
  CCC.
  

G_SELECTION(COMPOSE3)
  
  .DD.
  


G_SELECTION(COMPOSE3_PADDED)
  DDD.
  DDD.
  

One may argue that all this logic is unnecessary after adding support
for multirect selections.
So, I kindly ask what should happen if someone call S_SELECTION
(in multirect mode) passing THREE rectangles A, B, and C (not D) ?

The driver must adjust rectangles to some valid value. So it can
increase width of C or implicitly activate D or disable C.
I think that the best solution is activating D because
it allows to set size of C to the value closest to requested one.
Therefore logic for implicit activation of D should be implemented anyway.

 
 It makes much more sense to set everything up at once.

I agree that it is better to set everything at once.
But I strongly believe that transactions are the proper way to achieve that.

Not multirectangle selections.

It obfuscates API. It only pretends to fix a problem with applying
a part of configuration atomically.

 
 BTW, what probably wasn't clear from Ricardo's explanation is that for every
 crop rectangle you must have a corresponding compose rectangle so that you
 know where to DMA it to.
 
 Your next question will be that it is a real problem that you can't set
 crop and compose simultaneously, and you are right about that. Read on for
 that... :-)
 
 Hmm. I think that the real problem is much different.
 Not how to set up rectangles atomically but rather
 how do anything non-trivial atomically in V4L2.

 It would be very nice to have crop/compose and format configured at the same 
 time.
 However, current version of V4L2 API does not support that.

 Setting multiple crop rectangles may help a bit for only this little case.
 But how would like to set multicrop rectangles and multicompose rectangle 
 atomically.
 
 Why can't we extend the selection API a bit? How about this:
 
 #define V4L2_SEL_TGT_CROP_COMPOSE0x0200
 
 struct v4l2_selection {
 __u32   type

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-11-12 Thread Tomasz Stanislawski

Hi Ricardo,
Sorry for a late reply. I've been 'offline' for the last two weeks.
Please refer to the comments below.

On 10/28/2013 11:46 PM, Ricardo Ribalda Delgado wrote:
 Hello Tomasz
 
 Sorry for the late reply, but I have been offline the last week due to
 the conference.
 
 
 On Thu, Oct 24, 2013 at 12:31 PM, Tomasz Stanislawski
 t.stanisl...@samsung.com wrote:
 Hi Ricardo,
 I am the designer of selection API. I hope I can help you a little.
 I think that there are two issues mixed in 'Mulitple selections' topic.

 Firstly, you described that you program a piece of hardware that is
 capable of selecting 8 areas for scanning. Now you
 are looking for userspace API to support such a feature.
 The feature of posting multiple rectangle was proposed in this RFC.

 Secondly, You introduced struct v4l2_ext_rect which is a future-proof
 version of v4l2_rect.


 I think that both issues should be solved in two separate patchsets.

 Ad 1.
 The selection of multiple scanning areas is a very driver-specific
 feature, isn't it? I think that you do not need to introduce any abstract
 interface. What would be other applications of the proposed interface?
 
 It is not driver specific. There are many sensors out there that
 supports multiple window of interest, but today we are ignoring them
 just because we dont have an api.
 
 The main application would be industrial imaging, where less data to
 read means more fps and therefore the system can run faster.
 
 From my field I can tell you that it is a hard requirement for
 computer vision. And it is a feature that we cannot model through v4l2
 controls.
 
 

OK. So there is no need to implement this feature as a driver-specific API.
It can go automatically to generic API.

 Do you know other drivers that may need it? Sakari mentioned introduction
 of private targets for selections. I like this idea. Just define:

 #define V4L2_SEL_TGT_PRIVATE 0x8000

 All targets that are = V4L2_SEL_TGT_PRIVATE are driver-specific.
 Generic applications must not use them. Non-generic application
 must check out the driver of video node before using selections
 from private set. If some target becomes more useful and accepted
 by more then one driver then it can be moved to generic API.
 The good thing about private target is that enums from different
 drivers can collide so the target space is not going to be trashed.

 
 If you read the previous RFCs you will see that the approach you are
 mentioning has been rejected.
 
 The main issue is that you cannot set atomically all the rectangles.
 Lets say that the configuration formed by rectangle A, B and C is
 legal, but the configuration A and B is not allowed by the sensor. How
 could you set the rectangles one by one?
 

As I said. Changes of rectangle n may trigger changes in rectangle n+1 and so 
on.
So activation of rectangle B (setting height to non-zero value) will enable
rectangle C with some default size. Moreover disabling rectangle B (setting 
height to 0)
may disable rectangle C automatically. I do not follow what is the problem here?

Hmm. I think that the real problem is much different.
Not how to set up rectangles atomically but rather
how do anything non-trivial atomically in V4L2.

It would be very nice to have crop/compose and format configured at the same 
time.
However, current version of V4L2 API does not support that.

Setting multiple crop rectangles may help a bit for only this little case.
But how would like to set multicrop rectangles and multicompose rectangle 
atomically.
How to define which crop rectangle refers to which to which compose rectangle.

What to do if one would like to change only 3rd crop rectangle?

Introduce rectangle id into v4l2_ext_rect?
Call VIDIOC_G_SELECTION to get all rectangles, change one and apply 
VIDIOC_S_SELECTION?
Is it really scalable?

Multirectangle targets may seam to be a solution but I think it is not.

I think that atomic transactions are what is really needed in V4L2.
Other ideas like try-context from subdev API may also help.

It will be nice to have something like

VIDIOC_BEGIN
  VIDIOC_S_SELECTION (target = CROP)
  VIDIOC_S_SELECTION (target = COMPOSE)
  VIDIOC_S_FMT
  VIDIOC_S_CTRL
VIDIOC_COMMIT

and call a bunch of VIDIOC_G_* to see what really was applied.

 I have an auxiliary question. Do you have to set all rectangles
 at once? can you set up them one by one?
 
 Also if you tell the driver what exact configuration you will need, it
 will provide you with the closest possible confuration, that cannot be

s/cannot be done/may not be 'doable'

 done if you provide rectangle by rectangle.
 
 But how to deal with multiple rectangles?
 
 Multiple rectangles is a desired feature, please take a look to the
 presentation on the workshop.
 

I agree that it may be useful. I just think that multirectangle selections
are needed to add support for such a feature.


 Anyway, first try to define something like this:

 #define V4L2_SEL_TGT_XXX_SCANOUT0

Re: [RFC v3] [RFC] v4l2: Support for multiple selections

2013-10-24 Thread Tomasz Stanislawski

Hi Ricardo,
I am the designer of selection API. I hope I can help you a little.
I think that there are two issues mixed in 'Mulitple selections' topic.

Firstly, you described that you program a piece of hardware that is
capable of selecting 8 areas for scanning. Now you
are looking for userspace API to support such a feature.
The feature of posting multiple rectangle was proposed in this RFC.

Secondly, You introduced struct v4l2_ext_rect which is a future-proof
version of v4l2_rect.


I think that both issues should be solved in two separate patchsets.

Ad 1.
The selection of multiple scanning areas is a very driver-specific
feature, isn't it? I think that you do not need to introduce any abstract
interface. What would be other applications of the proposed interface?
Do you know other drivers that may need it? Sakari mentioned introduction
of private targets for selections. I like this idea. Just define:

#define V4L2_SEL_TGT_PRIVATE 0x8000

All targets that are = V4L2_SEL_TGT_PRIVATE are driver-specific.
Generic applications must not use them. Non-generic application
must check out the driver of video node before using selections
from private set. If some target becomes more useful and accepted
by more then one driver then it can be moved to generic API.
The good thing about private target is that enums from different
drivers can collide so the target space is not going to be trashed.

But how to deal with multiple rectangles?
I have an auxiliary question. Do you have to set all rectangles
at once? can you set up them one by one?

Anyway, first try to define something like this:

#define V4L2_SEL_TGT_XXX_SCANOUT0  V4L2_SEL_TGT_PRIVATE
#define V4L2_SEL_TGT_XXX_SCANOUT0_DEFAULT  (V4L2_SEL_TGT_XXX_SCANOUT0 + 1)
#define V4L2_SEL_TGT_XXX_SCANOUT0_BOUNDS  (V4L2_SEL_TGT_XXX_SCANOUT0 + 2)

#define V4L2_SEL_TGT_XXX_SCANOUT0  (V4L2_SEL_TGT_PRIVATE + 16)
...

-- OR-- parametrized macros similar to one below:

#define V4L2_SEL_TGT_XXX_SCANOUT(n) (V4L2_SEL_TGT_PRIVATE + 16 * (n))

The application could setup all scanout areas one-by-one.
By default V4L2_SEL_TGT_XXX_SCANOUT0 would be equal to the whole array.
The height of all consecutive area would be 0. This means disabling
them effectively.

The change of V4L2_SEL_TGT_XXX_SCANOUT0 would influence all consequtive
rectangle by shifting them down or resetting them to height 0.
Notice that as long as targets are driver specific you are free do define
interaction between the targets.

I hope that proposed solution is satisfactory.

BTW. I think that the HW trick you described is not cropping.
By cropping you select which part of sensor area is going
to be processed into compose rectangle in a buffer.

So technicaly you still insert the whole sensor area into the buffer.
Only part of the buffer is actually updated. So there is no cropping
(cropping area is equal to the whole array).

Notice, that every 'cropping' area goes to different part of a buffer.
So you would need also muliple targets for composing (!!!) and very long
chapter in V4L2 doc describing interactions between muliple-rectangle
crops and compositions. Good luck !!! :).
Currently it is a hell to understand and define interaction between
single crop, and compose and unfamous VIDIOC_S_FMT and m2m madness.

I strongly recommend to use private selections.
It will be much simpler to define, implement, and modify if needed.

BTW2. I think that the mulitple scanout areas can be modelled using
media device API. Sakari may know how to do this.


Ad 2. Extended rectangles.
It is a good idea because v4l2_rect lacks any place for extensions.
But before adding it to V4L2 API, I would like to know the examples
of actual applications. Please, point drivers that actually need it.

Other thing worth mentioning is reservation of few bits from
v4l2_selection::flags to describe the type of data used for
rectangle, v4l2_rect or v4l2_ext_rect. This way one can avoid
introducting v4l2_selection::rectangles field.

I hope you find this comments useful.

Regards,
Tomasz Stanislawski



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/7] phy: Add driver for Exynos DP PHY

2013-10-24 Thread Tomasz Stanislawski

Hi Kishon,
Recently, I posted 'simple-phy' driver.
It is a part of patchset for HDMI enabling on Exynos4 using Device Tree.

http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg23655.html

The simple-phy was dedicated for single register PHYs like HDMI or DP.
Using such a generic phy may help to avoid code duplication.

Regards,
Tomasz Stanislawski


On 10/16/2013 06:28 PM, Kishon Vijay Abraham I wrote:
 From: Jingoo Han jg1@samsung.com
 
 Add a PHY provider driver for the Samsung Exynos SoC Display Port PHY.
 
 Signed-off-by: Jingoo Han jg1@samsung.com
 Reviewed-by: Tomasz Figa t.f...@samsung.com
 Cc: Sylwester Nawrocki s.nawro...@samsung.com
 Acked-by: Felipe Balbi ba...@ti.com
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 ---
  .../devicetree/bindings/phy/samsung-phy.txt|8 ++
  drivers/phy/Kconfig|7 ++
  drivers/phy/Makefile   |1 +
  drivers/phy/phy-exynos-dp-video.c  |  111 
 
  4 files changed, 127 insertions(+)
  create mode 100644 drivers/phy/phy-exynos-dp-video.c
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fwd: [PATCH 3/6] [media] s5p-mfc: add support for VIDIOC_{G,S}_CROP to encoder

2013-10-17 Thread Tomasz Stanislawski

 should not use them.


I hope you find this information useful.


Regards,
Tomasz Stanislawski


On 10/12/2013 11:08 AM, John Sheu wrote:

 On Sat, Oct 12, 2013 at 1:00 AM, Hans Verkuil hverk...@xs4all.nl wrote:
 On 10/12/2013 01:48 AM, John Sheu wrote:
 On Wed, Oct 9, 2013 at 11:49 PM, Hans Verkuil hverk...@xs4all.nl wrote:
 In all cases, the crop boundary refers to the area in the source
 image; for a CAPTURE device, this is the (presumably analog) sensor,

 Correct.

 and for an OUTPUT device, this is the memory buffer.

 Correct.
 
 Here you are referring to the crop boundary, which is _not_ always
 what {G,S}_CROP refers to.  (Confusing part).  {G,S}_CROP refers to
 the crop boundary only for a CAPTURE queue.
 
 My particular
 case is a memory-to-memory device, with both CAPTURE and OUTPUT
 queues.  In this case, {G,S}_CROP on either the CAPTURE or OUTPUT
 queues should effect exactly the same operation: cropping on the
 source image, i.e. whatever image buffer I'm providing to the OUTPUT
 queue.

 Incorrect.

 S_CROP on an OUTPUT queue does the inverse: it refers to the area in
 the sink image.
 
 This confused me for a bit (seeming contradiction with the above),
 until I realized that you're referring to the S_CROP ioctl here, which
 is _not_ the crop boundary; on an OUTPUT queue it refers to the
 compose boundary.
 
 No, it adds the compose operation for capture and the crop operation for
 output, and it uses the terms 'cropping' and 'composing' correctly
 without the inversion that S_CROP introduced on the output side.

 Bottom line: S_CROP for capture is equivalent to 
 S_SELECTION(V4L2_SEL_TGT_CROP).
 S_CROP for output is equivalent to S_SELECTION(V4L2_SEL_TGT_COMPOSE).
 
 So yes.  By adding the {G,S}_SELECTION ioctls we can now refer to the
 compose boundary for CAPTURE, and crop boundary for OUTPUT.
 
 
 Now, here's a question.  It seems that for a mem2mem device, since
 {G,S}_CROP on the CAPTURE queue covers the crop boundary, and
 {G,S}_CROP on the OUTPUT queue capture the compose boundary, is there
 any missing functionality that {G,S}_SELECTION is covering here.  In
 other words: for a mem2mem device, the crop and compose boundaries
 should be identical for the CAPTURE and OUTPUT queues?
 
 -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 v5 2/4] media: s5p-tv: Restore vpll clock rate

Hi,

As you can see sdo, hdmi and mixer are saparate drivers that are
parts of s5p-tv drivers set. Could you rename commit name to
'media: s5p-tv: sdo: Restore vpll clock rate after streamoff'


On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
 Restore vpll clock rate if start stream fail or stream is off.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/sdo_drv.c | 23 +--
  1 file changed, 21 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c 
 b/drivers/media/platform/s5p-tv/sdo_drv.c
 index 0afa90f..e49ac6c 100644
 --- a/drivers/media/platform/s5p-tv/sdo_drv.c
 +++ b/drivers/media/platform/s5p-tv/sdo_drv.c
 @@ -55,6 +55,8 @@ struct sdo_device {
   struct clk *dacphy;
   /** clock for control of VPLL */
   struct clk *fout_vpll;
 + /** vpll rate before sdo stream was on */
 + unsigned long vpll_rate;
   /** regulator for SDO IP power */
   struct regulator *vdac;
   /** regulator for SDO plug detection */
 @@ -193,17 +195,33 @@ static int sdo_s_power(struct v4l2_subdev *sd, int on)
  
  static int sdo_streamon(struct sdo_device *sdev)
  {
 + int ret;
 +
   /* set proper clock for Timing Generator */
 - clk_set_rate(sdev-fout_vpll, 5400);
 + sdev-vpll_rate = clk_get_rate(sdev-fout_vpll);
 + ret = clk_set_rate(sdev-fout_vpll, 5400);
 + if (ret  0) {
 + dev_err(sdev-dev, Failed to set vpll rate\n);
 + return ret;
 + }
   dev_info(sdev-dev, fout_vpll.rate = %lu\n,

Could you also remove the line below in a new 'sdo: cleanup' patch?
Change dev_info to dev_dbg in the line above.

   clk_get_rate(sdev-fout_vpll));
   /* enable clock in SDO */
   sdo_write_mask(sdev, SDO_CLKCON, ~0, SDO_TVOUT_CLOCK_ON);
 - clk_enable(sdev-dacphy);
 + ret = clk_enable(sdev-dacphy);
 + if (ret  0) {
 + dev_err(sdev-dev, clk_enable(dacphy) failed\n);
 + goto fail;
 + }
   /* enable DAC */
   sdo_write_mask(sdev, SDO_DAC, ~0, SDO_POWER_ON_DAC);
   sdo_reg_debug(sdev);
   return 0;
 + 
 +fail:
 + sdo_write_mask(sdev, SDO_CLKCON, 0, SDO_TVOUT_CLOCK_ON);
 + clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
 + return ret;
  }
  
  static int sdo_streamoff(struct sdo_device *sdev)
 @@ -220,6 +238,7 @@ static int sdo_streamoff(struct sdo_device *sdev)
   }
   if (tries == 0)
   dev_err(sdev-dev, failed to stop streaming\n);

Produce some warning if the line below fails.

 + clk_set_rate(sdev-fout_vpll, sdev-vpll_rate);
   return tries ? 0 : -EIO;
  }
  
 

--
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 v5 3/4] media: s5p-tv: Fix sdo driver to work with CCF

Rename to 'media: s5p-tv: sdo: integrate with CCF'

On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
 Replace clk_enable by clock_enable_prepare and clk_disable with 
 clk_disable_unprepare.
 Clock prepare is required by Clock Common Framework, and old clock driver 
 didn`t support it.
 Without it Common Clock Framework prints a warning.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/sdo_drv.c | 20 
  1 file changed, 12 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/sdo_drv.c 
 b/drivers/media/platform/s5p-tv/sdo_drv.c
 index e49ac6c..17272e1 100644
 --- a/drivers/media/platform/s5p-tv/sdo_drv.c
 +++ b/drivers/media/platform/s5p-tv/sdo_drv.c
 @@ -208,9 +208,9 @@ static int sdo_streamon(struct sdo_device *sdev)
   clk_get_rate(sdev-fout_vpll));
   /* enable clock in SDO */
   sdo_write_mask(sdev, SDO_CLKCON, ~0, SDO_TVOUT_CLOCK_ON);
 - ret = clk_enable(sdev-dacphy);
 + ret = clk_prepare_enable(sdev-dacphy);
   if (ret  0) {
 - dev_err(sdev-dev, clk_enable(dacphy) failed\n);
 + dev_err(sdev-dev, clk_prepare_enable(dacphy) failed\n);
   goto fail;
   }
   /* enable DAC */
 @@ -229,7 +229,7 @@ static int sdo_streamoff(struct sdo_device *sdev)
   int tries;
  
   sdo_write_mask(sdev, SDO_DAC, 0, SDO_POWER_ON_DAC);
 - clk_disable(sdev-dacphy);
 + clk_disable_unprepare(sdev-dacphy);
   sdo_write_mask(sdev, SDO_CLKCON, 0, SDO_TVOUT_CLOCK_ON);
   for (tries = 100; tries; --tries) {
   if (sdo_read(sdev, SDO_CLKCON)  SDO_TVOUT_CLOCK_READY)
 @@ -273,7 +273,7 @@ static int sdo_runtime_suspend(struct device *dev)
   dev_info(dev, suspend\n);
   regulator_disable(sdev-vdet);
   regulator_disable(sdev-vdac);
 - clk_disable(sdev-sclk_dac);
 + clk_disable_unprepare(sdev-sclk_dac);
   return 0;
  }
  
 @@ -285,7 +285,7 @@ static int sdo_runtime_resume(struct device *dev)
  
   dev_info(dev, resume\n);
  
 - ret = clk_enable(sdev-sclk_dac);
 + ret = clk_prepare_enable(sdev-sclk_dac);
   if (ret  0)
   return ret;
  
 @@ -318,7 +318,7 @@ static int sdo_runtime_resume(struct device *dev)
  vdac_r_dis:
   regulator_disable(sdev-vdac);
  dac_clk_dis:
 - clk_disable(sdev-sclk_dac);
 + clk_disable_unprepare(sdev-sclk_dac);
   return ret;
  }
  
 @@ -424,7 +424,11 @@ static int sdo_probe(struct platform_device *pdev)
   }
  
   /* enable gate for dac clock, because mixer uses it */
 - clk_enable(sdev-dac);
 + ret = clk_prepare_enable(sdev-dac);
 + if (ret  0) {
 + dev_err(dev, clk_prepare_enable(dac) failed\n);
 + goto fail_fout_vpll;
 + }
  
   /* configure power management */
   pm_runtime_enable(dev);
 @@ -463,7 +467,7 @@ static int sdo_remove(struct platform_device *pdev)
   struct sdo_device *sdev = sd_to_sdev(sd);
  
   pm_runtime_disable(pdev-dev);
 - clk_disable(sdev-dac);
 + clk_disable_unprepare(sdev-dac);
   clk_put(sdev-fout_vpll);
   clk_put(sdev-dacphy);
   clk_put(sdev-dac);
 

--
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 v5 4/4] media: s5p-tv: Fix mixer driver to work with CCF

rename to 'media: s5p-tv: mixer: integrate with CCF'

On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
 Replace clk_enable by clock_enable_prepare and clk_disable with 
 clk_disable_unprepare.
 Clock prepare is required by Clock Common Framework, and old clock driver 
 didn`t support it.
 Without it Common Clock Framework prints a warning.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com

 ---
  drivers/media/platform/s5p-tv/mixer_drv.c | 34 
 +--
  1 file changed, 28 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c 
 b/drivers/media/platform/s5p-tv/mixer_drv.c
 index 8ce7c3e..7eea286 100644
 --- a/drivers/media/platform/s5p-tv/mixer_drv.c
 +++ b/drivers/media/platform/s5p-tv/mixer_drv.c
 @@ -347,19 +347,41 @@ static int mxr_runtime_resume(struct device *dev)
  {
   struct mxr_device *mdev = to_mdev(dev);
   struct mxr_resources *res = mdev-res;
 + int ret;
  
   dev_dbg(mdev-dev, resume - start\n);
   mutex_lock(mdev-mutex);
   /* turn clocks on */
 - clk_enable(res-mixer);
 - clk_enable(res-vp);
 - clk_enable(res-sclk_mixer);
 + ret = clk_prepare_enable(res-mixer);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(mixer) failed\n);
 + goto fail;
 + }
 + ret = clk_prepare_enable(res-vp);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(vp) failed\n);
 + goto fail_mixer;
 + }
 + ret = clk_prepare_enable(res-sclk_mixer);
 + if (ret  0) {
 + dev_err(mdev-dev, clk_prepare_enable(sclk_mixer) failed\n);
 + goto fail_vp;
 + }
   /* apply default configuration */
   mxr_reg_reset(mdev);
   dev_dbg(mdev-dev, resume - finished\n);
  
   mutex_unlock(mdev-mutex);
   return 0;
 +
 +fail_vp:
 + clk_disable_unprepare(res-vp);
 +fail_mixer:
 + clk_disable_unprepare(res-mixer);
 +fail:
 + mutex_unlock(mdev-mutex);
 + dev_err(mdev-dev, resume failed\n);
 + return ret;
  }
  
  static int mxr_runtime_suspend(struct device *dev)
 @@ -369,9 +391,9 @@ static int mxr_runtime_suspend(struct device *dev)
   dev_dbg(mdev-dev, suspend - start\n);
   mutex_lock(mdev-mutex);
   /* turn clocks off */
 - clk_disable(res-sclk_mixer);
 - clk_disable(res-vp);
 - clk_disable(res-mixer);
 + clk_disable_unprepare(res-sclk_mixer);
 + clk_disable_unprepare(res-vp);
 + clk_disable_unprepare(res-mixer);
   mutex_unlock(mdev-mutex);
   dev_dbg(mdev-dev, suspend - finished\n);
   return 0;
 

--
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 v5 4/4] media: s5p-tv: Fix mixer driver to work with CCF

On 09/23/2013 02:44 PM, Sylwester Nawrocki wrote:
 On 21/09/13 17:00, Mateusz Krawczuk wrote:
 Replace clk_enable by clock_enable_prepare and clk_disable with 
 clk_disable_unprepare.
 Clock prepare is required by Clock Common Framework, and old clock driver 
 didn`t support it.
 Without it Common Clock Framework prints a warning.
 
 nit: Please wrap this text to not exceed 80 columns.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/mixer_drv.c | 34 
 +--
  1 file changed, 28 insertions(+), 6 deletions(-)

 diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c 
 b/drivers/media/platform/s5p-tv/mixer_drv.c
 index 8ce7c3e..7eea286 100644
 --- a/drivers/media/platform/s5p-tv/mixer_drv.c
 +++ b/drivers/media/platform/s5p-tv/mixer_drv.c
 @@ -347,19 +347,41 @@ static int mxr_runtime_resume(struct device *dev)
  {
  struct mxr_device *mdev = to_mdev(dev);
  struct mxr_resources *res = mdev-res;
 +int ret;
  
  dev_dbg(mdev-dev, resume - start\n);
  mutex_lock(mdev-mutex);
  /* turn clocks on */
 -clk_enable(res-mixer);
 -clk_enable(res-vp);
 -clk_enable(res-sclk_mixer);
 +ret = clk_prepare_enable(res-mixer);
 +if (ret  0) {
 +dev_err(mdev-dev, clk_prepare_enable(mixer) failed\n);
 +goto fail;
 +}
 +ret = clk_prepare_enable(res-vp);
 +if (ret  0) {
 +dev_err(mdev-dev, clk_prepare_enable(vp) failed\n);
 +goto fail_mixer;
 +}
 +ret = clk_prepare_enable(res-sclk_mixer);
 +if (ret  0) {
 +dev_err(mdev-dev, clk_prepare_enable(sclk_mixer) failed\n);
 +goto fail_vp;
 +}
  /* apply default configuration */
  mxr_reg_reset(mdev);
  dev_dbg(mdev-dev, resume - finished\n);
  
  mutex_unlock(mdev-mutex);
  return 0;
 +
 +fail_vp:
 +clk_disable_unprepare(res-vp);
 +fail_mixer:
 +clk_disable_unprepare(res-mixer);
 +fail:
 
 How about only one error log here if any of the clk_prepare_enable() calls
 fails ? I'm not sure if we need a separate log for each single clock.
 

I think it would nice to know which clock caused a failure.

 +mutex_unlock(mdev-mutex);
 +dev_err(mdev-dev, resume failed\n);
 +return ret;
  }
 
 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 v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-24 Thread Tomasz Stanislawski

Hi,

On 09/23/2013 05:48 PM, Bartlomiej Zolnierkiewicz wrote:
 
 Hi Tomasz,
 
 On Monday, September 23, 2013 04:50:01 PM Tomasz Stanislawski wrote:
 Hello,
 May I ask what is the rationale for this patch?
 To reduce a few lines of code?
 
 This patch makes source code more generic-like and easier to follow (mxd_r*

more generic(-like?) - NOT. Using mxr_ macros is a more generic way to produce 
logs
because one can change only one line to change error format for the whole 
module.
For example, in case of mxr_ family, a patch adding function name to debug 
message
would require just a few lines patch. Using in case of dev_ family, one has to
produce 200-lines of highly conflicting patch.

'easier to follow' - MAYBE. I agree that some people may prefer to
see more directly what is happening, but tell me if you really consider line:

mxr_dbg(mdev, this is debug\n);

as a very confusing and obfuscated piece of code.

COME ON!

Regards,
TS

 macros currently only obfuscate the code and make them harder to read for
 everybody, maybe besides the original driver author ;). Removal of few
 superfluous lines of code is just a bonus.
 
 Or to give up possibility of changing message format in just one place?
 
 For over two and half year (since s5p-tv driver introduction in Feb 2011)
 such change was not needed and it doesn't seem that keeping the code to
 allow such possibility is worth an added code obfuscation.
 
 Besides you can easily script a change to message format so in practice
 I don't see a real advantage of keeping non-standard messaging macros
 just for easing a potential message format conversion.
 
 I could see migrating from mxr_* to pr_* could seen as the fix, but not this.
 
 Such migration seems to be pointless as you would have to add an extra
 argument to pr_* to not lose the device information.

There is something called pr_fmt. It may help with mentioned issue.

 



 Best regards,
 --
 Bartlomiej Zolnierkiewicz
 Samsung RD Institute Poland
 Samsung Electronics
 
 Waiting for reply,
 Tomasz Stanislawski


 On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
 Replace mxr_dbg, mxr_info and mxr_warn by generic solution.

 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/mixer.h   |  12 ---
  drivers/media/platform/s5p-tv/mixer_drv.c   |  47 ++-
  drivers/media/platform/s5p-tv/mixer_grp_layer.c |   2 +-
  drivers/media/platform/s5p-tv/mixer_reg.c   |   6 +-
  drivers/media/platform/s5p-tv/mixer_video.c | 100 
 
  drivers/media/platform/s5p-tv/mixer_vp_layer.c  |   2 +-
  6 files changed, 78 insertions(+), 91 deletions(-)


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-24 Thread Tomasz Stanislawski

On 09/23/2013 07:44 PM, Joe Perches wrote:
 On Mon, 2013-09-23 at 17:48 +0200, Bartlomiej Zolnierkiewicz wrote:
 On Monday, September 23, 2013 04:50:01 PM Tomasz Stanislawski wrote:
 May I ask what is the rationale for this patch?
 To reduce a few lines of code?
 This patch makes source code more generic-like and easier to follow (mxd_r*
 macros currently only obfuscate the code and make them harder to read for
 everybody, maybe besides the original driver author ;). Removal of few
 superfluous lines of code is just a bonus.
 I don't see any significant issue with this change.
 Using generic mechanisms is good.


Hi Joe,
Sorry for flaming but please let me explain reasons of my opposition to this 
patch.

1. It is true that there was no change in mixer messages for 2.5 year in 
MAINLINE.
But sometimes I used modification of mxr_ macros while testing the driver.
Therefore those macros are useful for me.

2. The other problem with this patch is its high 'conflictness' during merging.
Unfortunately, sometimes I have to use s5p-tv on platform and configuration
that is only supported in older versions of the kernel + some integration 
patches.
The s5p-tv differs from mainline version in those kernels. Therefore
I would need to keep two versions of patches, one for old and another one for 
new kernel.
Or backport the 'cleanup patch' and all experimental patches above it.

3. As I understand the coding guidelines asked to use dev_* to ensure that all
error messages have information about the device. There is no change in format 
of
errors after this patch. So they do not change anything from userland point of 
view.

4. I looked for other files where macro for dev_err is used.
I tried following shell command on v3.12-rc2.

git grep -A1 _err( | grep -A1 '#define' | grep -B1 dev_err

then processing results using
grep -v ^-- | cut -d: -f 1 | sort -u | wc

produced 55 files. Among them, the files below makes use of a macro that is
directly expanded to dev_err(dev_ptr, fmt, ...) without any changes in format.

drivers/firewire/ohci.c
drivers/gpu/drm/i2c/ch7006_priv.h
drivers/gpu/drm/i2c/sil164_drv.c
drivers/infiniband/hw/mthca/mthca_dev.h
drivers/infiniband/hw/qib/qib.h
drivers/media/platform/marvell-ccic/cafe-driver.c
drivers/media/platform/marvell-ccic/mcam-core.c
drivers/media/platform/s5p-tv/mixer.h
drivers/media/platform/via-camera.c
drivers/mtd/devices/docg3.h
drivers/net/ethernet/broadcom/bgmac.h
drivers/net/ethernet/chelsio/cxgb3/common.h
drivers/net/ethernet/intel/e1000/e1000.h
drivers/net/ethernet/intel/ixgbe/ixgbe_common.h
drivers/net/ethernet/mellanox/mlx4/mlx4.h
drivers/net/wireless/iwlegacy/common.h
drivers/pci/hotplug/pciehp.h
drivers/pci/hotplug/shpchp.h
drivers/remoteproc/ste_modem_rproc.c
drivers/scsi/csiostor/csio_hw.h
drivers/staging/fwserial/fwserial.c
drivers/usb/atm/usbatm.h
drivers/usb/host/ehci.h
drivers/usb/host/fhci.h
drivers/usb/host/fotg210-hcd.c
drivers/usb/host/fusbh200-hcd.c
drivers/usb/host/ohci.h
drivers/usb/host/oxu210hp-hcd.c
drivers/usb/host/xhci.h
include/linux/hid.h
include/net/cfg80211.h

Other files makes only cosmetic changes to format, so they might still be worth 
to
be 'demacronized'. So I think we can consider that macros wrapping dev_* is 
still
a widely used technique so I ask for a good reason before changing the driver.

If one still would like to continue a 'dev_* cleanup crusade' then I kindly
ask to create a big patchset that fixes all over mentioned files.
If most of their maintainers accepts the patches I promise to accept it in
s5p-tv.

Currently, due to mentioned reason the patch is not a cleanup-up for me.
And since I am still a maintainer of this god-forgotten driver I am
going NACK this patch because it makes my work more difficult and because
this patch provides only (if any) relative aesthetic gain.

However this patch can be saved a little. (see below)

 Few trivial nits:

 I'd remove the trailing periods from some of the messages
 at the same time.

 Function tracing is better done by the function tracing
 mechanism built in to the kernel.  Removing the
   dev_dbg(dev, %s: enter\n, __func__)
 lines would be good too.

 Maybe look at the message levels of more of these
 logging messages and determine which are actually
 useful and what is mostly noise and should be dev_dbg
 or deleted altogether.


I agree that most of debugs in form

mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);

are obfuscation. So removal of such lines is a cleanup
and provides some gain and I can ACK this kind of change.

Moreover, I agree that some mxr_info() should be changed mxr_dbg().
I ask Mateusz to modify the 'cleanup' patch to remove only useless
mxr_dbg() and mxr_info() but to keep mxr_* macros intact.

Regards,
Tomasz Stanislawski

 diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c 
 b/drivers/media/platform/s5p-tv/mixer_drv.c
 
 @@ -59,7 +59,7 @@ void mxr_streamer_get(struct mxr_device *mdev)
  {
mutex_lock(mdev-mutex);
++mdev-n_streamer;
 -  mxr_dbg

Re: [PATCH v5 1/4] media: s5p-tv: Replace mxr_ macro by default dev_

2013-09-23 Thread Tomasz Stanislawski

Hello,
May I ask what is the rationale for this patch?
To reduce a few lines of code?
Or to give up possibility of changing message format in just one place?

I could see migrating from mxr_* to pr_* could seen as the fix, but not this.

Waiting for reply,
Tomasz Stanislawski


On 09/21/2013 05:00 PM, Mateusz Krawczuk wrote:
 Replace mxr_dbg, mxr_info and mxr_warn by generic solution.
 
 Signed-off-by: Mateusz Krawczuk m.krawc...@partner.samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/mixer.h   |  12 ---
  drivers/media/platform/s5p-tv/mixer_drv.c   |  47 ++-
  drivers/media/platform/s5p-tv/mixer_grp_layer.c |   2 +-
  drivers/media/platform/s5p-tv/mixer_reg.c   |   6 +-
  drivers/media/platform/s5p-tv/mixer_video.c | 100 
 
  drivers/media/platform/s5p-tv/mixer_vp_layer.c  |   2 +-
  6 files changed, 78 insertions(+), 91 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/mixer.h 
 b/drivers/media/platform/s5p-tv/mixer.h
 index 04e6490..c054106 100644
 --- a/drivers/media/platform/s5p-tv/mixer.h
 +++ b/drivers/media/platform/s5p-tv/mixer.h
 @@ -327,18 +327,6 @@ void mxr_streamer_put(struct mxr_device *mdev);
  void mxr_get_mbus_fmt(struct mxr_device *mdev,
   struct v4l2_mbus_framefmt *mbus_fmt);
  
 -/* Debug */
 -
 -#define mxr_err(mdev, fmt, ...)  dev_err(mdev-dev, fmt, ##__VA_ARGS__)
 -#define mxr_warn(mdev, fmt, ...) dev_warn(mdev-dev, fmt, ##__VA_ARGS__)
 -#define mxr_info(mdev, fmt, ...) dev_info(mdev-dev, fmt, ##__VA_ARGS__)
 -
 -#ifdef CONFIG_VIDEO_SAMSUNG_S5P_MIXER_DEBUG
 - #define mxr_dbg(mdev, fmt, ...)  dev_dbg(mdev-dev, fmt, ##__VA_ARGS__)
 -#else
 - #define mxr_dbg(mdev, fmt, ...)  do { (void) mdev; } while (0)
 -#endif
 -
  /* accessing Mixer's and Video Processor's registers */
  
  void mxr_vsync_set_update(struct mxr_device *mdev, int en);
 diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c 
 b/drivers/media/platform/s5p-tv/mixer_drv.c
 index 51805a5..8ce7c3e 100644
 --- a/drivers/media/platform/s5p-tv/mixer_drv.c
 +++ b/drivers/media/platform/s5p-tv/mixer_drv.c
 @@ -59,7 +59,7 @@ void mxr_streamer_get(struct mxr_device *mdev)
  {
   mutex_lock(mdev-mutex);
   ++mdev-n_streamer;
 - mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
 + dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
   if (mdev-n_streamer == 1) {
   struct v4l2_subdev *sd = to_outsd(mdev);
   struct v4l2_mbus_framefmt mbus_fmt;
 @@ -91,7 +91,7 @@ void mxr_streamer_put(struct mxr_device *mdev)
  {
   mutex_lock(mdev-mutex);
   --mdev-n_streamer;
 - mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_streamer);
 + dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_streamer);
   if (mdev-n_streamer == 0) {
   int ret;
   struct v4l2_subdev *sd = to_outsd(mdev);
 @@ -113,7 +113,7 @@ void mxr_output_get(struct mxr_device *mdev)
  {
   mutex_lock(mdev-mutex);
   ++mdev-n_output;
 - mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
 + dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
   /* turn on auxiliary driver */
   if (mdev-n_output == 1)
   v4l2_subdev_call(to_outsd(mdev), core, s_power, 1);
 @@ -124,7 +124,7 @@ void mxr_output_put(struct mxr_device *mdev)
  {
   mutex_lock(mdev-mutex);
   --mdev-n_output;
 - mxr_dbg(mdev, %s(%d)\n, __func__, mdev-n_output);
 + dev_dbg(mdev-dev, %s(%d)\n, __func__, mdev-n_output);
   /* turn on auxiliary driver */
   if (mdev-n_output == 0)
   v4l2_subdev_call(to_outsd(mdev), core, s_power, 0);
 @@ -159,42 +159,42 @@ static int mxr_acquire_plat_resources(struct mxr_device 
 *mdev,
  
   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, mxr);
   if (res == NULL) {
 - mxr_err(mdev, get memory resource failed.\n);
 + dev_err(mdev-dev, get memory resource failed.\n);
   ret = -ENXIO;
   goto fail;
   }
  
   mdev-res.mxr_regs = ioremap(res-start, resource_size(res));
   if (mdev-res.mxr_regs == NULL) {
 - mxr_err(mdev, register mapping failed.\n);
 + dev_err(mdev-dev, register mapping failed.\n);
   ret = -ENXIO;
   goto fail;
   }
  
   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, vp);
   if (res == NULL) {
 - mxr_err(mdev, get memory resource failed.\n);
 + dev_err(mdev-dev, get memory resource failed.\n);
   ret = -ENXIO;
   goto fail_mxr_regs;
   }
  
   mdev-res.vp_regs = ioremap(res-start, resource_size(res));
   if (mdev-res.vp_regs == NULL) {
 - mxr_err(mdev, register mapping failed.\n);
 + dev_err(mdev-dev, register mapping failed.\n);
   ret = -ENXIO;
   goto fail_mxr_regs;
   }
  
   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ

Re: Question: interaction between selection API, ENUM_FRAMESIZES and S_FMT?

2013-07-02 Thread Tomasz Stanislawski

Hi Hans,
Maybe it is a good time to separate configuration of a data source from
configuration of a data sink. Currently, everything is pretty mixed
for videodev API. The magic ioctl called S_FMT does to much.
As I understand it includes:
  a) setting pixelformat
  b) setting size of a buffer
  c) setting/adjusting crop rectangle previously defined using S_CROP
  d) if S_CROP is not used then S_FMT sets the framesize
 changing framesize ahs huge impact on a pipeline for capture device
  e) setting composing rectangle to the whole buffer

IMO, it would a good idea to split S_FMT into separate calls for a sink and
a source.

In case of a capture device, the source is TV grabber or sensor array.
They are controlled using S_STD for anlog TV, S_DV_TIMING for digital TV
or hypothetical S_FRAMESIZE for sensor arrays.
All mentioned medias are pretty different so they deserve dedicated ioctl.
I think it might be much better to introduce an ioctl dedicated
only for sensor arrays like {S/G}_SENSOR(_ARRAY). This ioctl would take width,
height as parameters (updating to defaults if only one resolution is supported).
All binning, skipping, etc. magic might have dedicated fields in S_SENSOR.
Introducing new selection target like SEL_TGT_FRAMESIZE or even
SEL_TGT_SOURCE is a nice abstraction but it is not need to provide HW
functionality to userspace.

In case of a capture device, the sink is a buffer. IMO, it would be nice
to have an ioctl dedicated only for configuration of buffers in memory.
Let's call it S_BUFFER. It will take width, height and pixelformat
as parameters. This ioctl would be very similar to S_FMT expect
much smaller influence on other parts of the pipeline. This call would
not change neither framesize nor cropping rectangle. There would be no
requirement that the buffer is fully filled without margins. This would
greatly simplify interactions with composing rectangle and scaling setup.

The interactions between composing rectangle and S_BUFFER are
an interesting topic. During the discussion about pipeline
configuration [1] it was mentioned that all dependencies
should be executed in to-memory order. It means that S_BUFFER
would adjust width and height to be assure that composing
rectangle fits. The same way adjusting composing rectangle will
change buffer size if necessary.

Finally S_FMT could be emulated in libv4l2 or v4l2-core as series of
of S_SELECTION and S_BUFFER calls, optionally S_STD, S_DV_TIMING or S_SENSOR
if possible. The same emulation would have to be performed for S_CROP.
The emulation would be used only to handle support for legacy applications.
All new and experimental applications must not use S_FMT or S_CROP.

I know that the changes are dramatic but fixing issues with pipeline
configuration is worth it.

What do you think about the proposed idea?

Regards,
Tomasz Stanislawski

[1] http://www.spinics.net/lists/linux-media/msg34541.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [REVIEW PATCH 0/6] s5p-tv: replace dv_preset by dv_timings

2013-03-20 Thread Tomasz Stanislawski

Hi everyone,
After successful testing (after applying use cap instead of 0 fix),
please add:

Tested-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com

to the commit log.

Regards,
Tomasz Stanislawski

On 03/18/2013 03:24 PM, Hans Verkuil wrote:
 On Mon March 4 2013 14:02:00 Hans Verkuil wrote:
 Hi Tomasz,

 Here is what I hope is the final patch series for this. I've incorporated
 your suggestions and it's split off from the davinci/blackfin changes into
 its own patch series to keep things better organized.

 The changes since the previous version are:

 - changed the order of the first three patches as per your suggestion.
 - the patch named [RFC PATCH 08/18] s5p-tv: add dv_timings support for
   mixer_video. had two changes that rightfully belonged to the 'add
   dv_timings support for mixer_video.' patch. Moved them accordingly.
 - hdmiphy now also supports dv_timings_cap and sets the pixelclock range
   accordingly. The hdmi driver chains hdmiphy to get those values.
 - updating the minimum width to 720.

 I didn't add a comment to clarify the pixclk handling hdmiphy_s_dv_preset
 because 1) I forgot, 2) it's not a bug, and 3) that whole function is
 removed anyway a few patches later :-)

 The only functional change is the handling of dv_timings_cap. Can you
 verify that that works as it should?
 
 Tomasz,
 
 Should I wait for feedback from you, or can I go ahead and make a pull
 request for this?
 
 Regards,
 
   Hans
 

--
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: [RFC PATCH 00/18] Remove DV_PRESET API

Hi Hans,
Thank you for the patches.
I applied the patchset on the top of SPRC's 3.8-rc4 kernel.
I tested the s5p-tv dv-timings using 0.9.3 using v4l-utils.
The test platform was Universal C210 (based on Exynos 4210 SoC).

Every timing mode worked correctly so do not hesitate to add:

Tested-by: Tomasz Stanislawski t.stanisl...@samsung.com

to all s5p-tv related patches.

I tested following features:
a) v4l2-ctl --list-dv-timings
   Result: got 10 timings entries as expected
b) v4l2-ctl --get-dv-timings-cap
   Result: got timings caps. The was minor issue. Minimal with is 720 not 640.
c) for each available timing
   v4l2-ctl --set-dv-bt-timings=index={index}
   v4l2-ctl --get-dv-bt-timings
   Show test image on the screen
   Result: TV detected correct timings for all cases

I found some minor issues in the patches.
Please refer to the inlined comments.

BTW.
The v4l2-ctl reports that fps for 1080i50 and 1080i60 as 25 and 30 respectively.
I agree that those values correctly reflects relation between
image resolution and the pixel rate.
However, I admit it looks a little bit confusing when suddenly 50 changes into 
25.
It should clarified if F in FPS stands for frame or field.

Regards,
Tomasz Stanislawski

On 02/16/2013 10:28 AM, Hans Verkuil wrote:
 Hi all!
 
 This patch series removes the last remnants of the deprecated DV_PRESET API
 from the kernel:
 
 - remove the dv_preset ops from the tvp7002 driver: all bridge drivers that
   use this i2c driver have already been converted to the DV_TIMINGS API, so
   these ops are no longer used. Prabhakar, can you test this for me?
 
 - fix some remaining references to the preset API from the davinci drivers.
   It's trivial stuff, but I would appreciate it if you can look at it, 
   Prabhakar.
 
 - rename some CUSTOM_TIMINGS defines to DV_TIMINGS since CUSTOM_TIMINGS
   is deprecated. It certainly shouldn't be used anymore in the kernel.
   Trivial patches, but please look at it as well, Prabhakar and Scott.
 
 - convert the s5p-tv drivers from the DV_PRESET to the DV_TIMINGS API and
   remove the DV_PRESET API. Tomasz or Kyungmin Park, can you test this?
   I do not know whether removal of the DV_PRESET API is possible at this
   stage for the s5p-tv since I do not know if any code inside Samsung
   uses the DV_PRESET API. If the DV_PRESET API cannot be removed at this
   time, then let me know. I would have to make some changes to allow the
   preset and timings APIs to co-exist. I would really like to remove the
   preset API some time this year, though, if only to prevent new drivers 
   from attempting to use the preset API.
 
 - finally remove the remaining core DV_PRESET support.
 
 - remove the DV_PRESET API from the videodev2.h header. Note that I am not
   at all certain if we should do this. I know that the DV_PRESET API has
   only been used in embedded systems, so the impact should be very limited.
   But it is probably better to wait for a year or so before actually 
   removing it from the header. The main reason for adding this removal is
   to verify that I haven't forgotten any driver conversions.
 
 Comments are welcome!
 
 Regards,
 
   Hans
 

--
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: [RFC PATCH 09/18] s5p-tv: add dv_timings support for hdmi.

Hi Hans,
Please refer to the comments below.

On 02/16/2013 10:28 AM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 This just adds dv_timings support without modifying existing dv_preset
 support.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Cc: Tomasz Stanislawski t.stanisl...@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/hdmi_drv.c |   92 
 +-
  1 file changed, 79 insertions(+), 13 deletions(-)
 

[snip]

 +static int hdmi_enum_dv_timings(struct v4l2_subdev *sd,
 + struct v4l2_enum_dv_timings *timings)
 +{
 + if (timings-index = ARRAY_SIZE(hdmi_timings))
 + return -EINVAL;
 + timings-timings = hdmi_timings[timings-index].dv_timings;
 + if (!hdmi_timings[timings-index].reduced_fps)
 + timings-timings.bt.flags = ~V4L2_DV_FL_CAN_REDUCE_FPS;
 + return 0;
 +}
 +
 +static int hdmi_dv_timings_cap(struct v4l2_subdev *sd,
 + struct v4l2_dv_timings_cap *cap)
 +{
 + cap-type = V4L2_DV_BT_656_1120;

The minimal width among all the supported timings is 720 not 640.

 + cap-bt.min_width = 640;
 + cap-bt.max_width = 1920;
 + cap-bt.min_height = 480;
 + cap-bt.max_height = 1080;

The range of pixelclock is a property of hdmiphy.
Not all ranges might be supported on all platforms.
Therefore it may be a good idea to obtains those values
from hdmiphy by chaining hdmi_dv_timings_cap to hdmiphy.

 + cap-bt.min_pixelclock = 2700;
 + cap-bt.max_pixelclock = 14850;
 + cap-bt.standards = V4L2_DV_BT_STD_CEA861;
 + cap-bt.capabilities = V4L2_DV_BT_CAP_INTERLACED |
 +V4L2_DV_BT_CAP_PROGRESSIVE;
 + return 0;
 +}
 +
  static const struct v4l2_subdev_core_ops hdmi_sd_core_ops = {
   .s_power = hdmi_s_power,
  };
 @@ -687,6 +749,10 @@ static const struct v4l2_subdev_video_ops 
 hdmi_sd_video_ops = {
   .s_dv_preset = hdmi_s_dv_preset,
   .g_dv_preset = hdmi_g_dv_preset,
   .enum_dv_presets = hdmi_enum_dv_presets,
 + .s_dv_timings = hdmi_s_dv_timings,
 + .g_dv_timings = hdmi_g_dv_timings,
 + .enum_dv_timings = hdmi_enum_dv_timings,
 + .dv_timings_cap = hdmi_dv_timings_cap,
   .g_mbus_fmt = hdmi_g_mbus_fmt,
   .s_stream = hdmi_s_stream,
  };
 

--
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: [RFC PATCH 10/18] s5p-tv: add dv_timings support for hdmiphy.

Hi Hans,
Please refer to the comments below.

On 02/16/2013 10:28 AM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 This just adds dv_timings support without modifying existing dv_preset
 support, although I had to refactor a little bit in order to share
 hdmiphy_find_conf() between the preset and timings code.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Cc: Tomasz Stanislawski t.stanisl...@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/hdmiphy_drv.c |   48 
 ++-
  1 file changed, 39 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/hdmiphy_drv.c 
 b/drivers/media/platform/s5p-tv/hdmiphy_drv.c
 index 80717ce..85b4211 100644
 --- a/drivers/media/platform/s5p-tv/hdmiphy_drv.c
 +++ b/drivers/media/platform/s5p-tv/hdmiphy_drv.c
 @@ -197,14 +197,9 @@ static unsigned long hdmiphy_preset_to_pixclk(u32 preset)
   return 0;
  }
  
 -static const u8 *hdmiphy_find_conf(u32 preset, const struct hdmiphy_conf 
 *conf)
 +static const u8 *hdmiphy_find_conf(unsigned long pixclk,
 + const struct hdmiphy_conf *conf)
  {
 - unsigned long pixclk;
 -
 - pixclk = hdmiphy_preset_to_pixclk(preset);
 - if (!pixclk)
 - return NULL;
 -
   for (; conf-pixclk; ++conf)
   if (conf-pixclk == pixclk)
   return conf-data;
 @@ -220,15 +215,49 @@ static int hdmiphy_s_power(struct v4l2_subdev *sd, int 
 on)
  static int hdmiphy_s_dv_preset(struct v4l2_subdev *sd,
   struct v4l2_dv_preset *preset)
  {
 - const u8 *data;
 + const u8 *data = NULL;
   u8 buffer[32];
   int ret;
   struct hdmiphy_ctx *ctx = sd_to_ctx(sd);
   struct i2c_client *client = v4l2_get_subdevdata(sd);
 + unsigned long pixclk;
   struct device *dev = client-dev;
  
   dev_info(dev, s_dv_preset(preset = %d)\n, preset-preset);
 - data = hdmiphy_find_conf(preset-preset, ctx-conf_tab);
 +
 + pixclk = hdmiphy_preset_to_pixclk(preset-preset);

Just nitpicking.
The pixclk might be 0 is the preset is not supported hdmiphy.
For some platforms not all frequencies are supported.
Anyway, if pixclk is 0 then hdmiphy_find_conf will detect it.

 + data = hdmiphy_find_conf(pixclk, ctx-conf_tab);
 + if (!data) {
 + dev_err(dev, format not supported\n);
 + return -EINVAL;
 + }
 +
 + /* storing configuration to the device */
 + memcpy(buffer, data, 32);
 + ret = i2c_master_send(client, buffer, 32);
 + if (ret != 32) {
 + dev_err(dev, failed to configure HDMIPHY via I2C\n);
 + return -EIO;
 + }
 +
 + return 0;
 +}
 +
 +static int hdmiphy_s_dv_timings(struct v4l2_subdev *sd,
 + struct v4l2_dv_timings *timings)
 +{
 + const u8 *data;
 + u8 buffer[32];
 + int ret;
 + struct hdmiphy_ctx *ctx = sd_to_ctx(sd);
 + struct i2c_client *client = v4l2_get_subdevdata(sd);
 + struct device *dev = client-dev;
 + unsigned long pixclk = timings-bt.pixelclock;
 +
 + dev_info(dev, s_dv_timings\n);

Using test against V4L2_DV_FL_REDUCED_FPS and 7425 looks little hacky to me.
Why there is no such a check for 14850 and 2700 (REDUCED - INCREASED?).
Maybe it will be better to past both timings-bt.pixelclock and 
timings-bt.flags
as parameters for hdmiphy_find_conf function. The hdmiphy_find_conf could
perform pixclk adjustment or some fallback policy based on the flags.

 + if ((timings-bt.flags  V4L2_DV_FL_REDUCED_FPS)  pixclk == 7425)
 + pixclk = 74176000;
 + data = hdmiphy_find_conf(pixclk, ctx-conf_tab);
   if (!data) {
   dev_err(dev, format not supported\n);
   return -EINVAL;
 @@ -271,6 +300,7 @@ static const struct v4l2_subdev_core_ops hdmiphy_core_ops 
 = {
  
  static const struct v4l2_subdev_video_ops hdmiphy_video_ops = {
   .s_dv_preset = hdmiphy_s_dv_preset,
 + .s_dv_timings = hdmiphy_s_dv_timings,
   .s_stream =  hdmiphy_s_stream,
  };
  
 

--
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: [RFC PATCH 11/18] s5p-tv: remove dv_preset support from mixer_video.

Hi Hans,
Please refer to the comments below.

On 02/16/2013 10:28 AM, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 The dv_preset API is deprecated and is replaced by the much improved 
 dv_timings
 API. Remove the dv_preset support from this driver as this will allow us to
 remove the dv_preset API altogether (s5p-tv being the last user of this code).
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 Cc: Tomasz Stanislawski t.stanisl...@samsung.com
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/media/platform/s5p-tv/mixer_video.c |   68 
 ++-
  1 file changed, 3 insertions(+), 65 deletions(-)
 

[snip]

  static int mxr_enum_dv_timings(struct file *file, void *fh,
   struct v4l2_enum_dv_timings *timings)
  {
 @@ -584,7 +526,7 @@ static int mxr_s_dv_timings(struct file *file, void *fh,
   /* lock protects from changing sd_out */
   mutex_lock(mdev-mutex);
  
 - /* preset change cannot be done while there is an entity
 + /* timings change cannot be done while there is an entity
* dependant on output configuration
*/
   if (mdev-n_output  0) {
 @@ -689,8 +631,8 @@ static int mxr_enum_output(struct file *file, void *fh, 
 struct v4l2_output *a)
   /* try to obtain supported tv norms */
   v4l2_subdev_call(sd, video, g_tvnorms_output, a-std);
   a-capabilities = 0;
 - if (sd-ops-video  sd-ops-video-s_dv_preset)
 - a-capabilities |= V4L2_OUT_CAP_PRESETS;

Could you move the lines below to the patch named
[RFC PATCH 08/18] s5p-tv: add dv_timings support for mixer_video..

 + if (sd-ops-video  sd-ops-video-s_dv_timings)
 + a-capabilities |= V4L2_OUT_CAP_DV_TIMINGS;

Don't you think that all add patches should go in reverse order?
I mean that dv_timings hdmiphy should be applied before hdmi. The hdmi before 
mixer.
This way all non-functional features would stay invisible from user-space until
they become functional.

   if (sd-ops-video  sd-ops-video-s_std_output)
   a-capabilities |= V4L2_OUT_CAP_STD;
   a-type = V4L2_OUTPUT_TYPE_ANALOG;
 @@ -811,10 +753,6 @@ static const struct v4l2_ioctl_ops mxr_ioctl_ops = {
   /* Streaming control */
   .vidioc_streamon = mxr_streamon,
   .vidioc_streamoff = mxr_streamoff,
 - /* Preset functions */
 - .vidioc_enum_dv_presets = mxr_enum_dv_presets,
 - .vidioc_s_dv_preset = mxr_s_dv_preset,
 - .vidioc_g_dv_preset = mxr_g_dv_preset,
   /* DV Timings functions */
   .vidioc_enum_dv_timings = mxr_enum_dv_timings,
   .vidioc_s_dv_timings = mxr_s_dv_timings,
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] [media] s5p-tv: Checkpatch Fixes and cleanup

2012-12-03 Thread Tomasz Stanislawski

On 12/03/2012 05:28 AM, Sachin Kamat wrote:
 On 28 November 2012 11:33, Sachin Kamat sachin.ka...@linaro.org wrote:
 
 How about testing it on Origen board ?

 I wanted to but could not due to hardware setup problem.
 I will see if I can get it up today (I am off for the rest of the week).

 Tested this series with test application on Origen. Works fine.



 Tomasz, are you OK with this patch series ?

Hi Sachin Kamat,
I am OK with patches from s5p-tv: Add missing braces around sizeof in ... 
family.
You can add my Acked-by to them.

The devm_clk patches should be postponed until s5p-tv gets integrated with
clk_prepare/unprepare stuff.

Regards,
Tomasz Stanislawski


 
 Hi Tomasz,
 
 Any comments on this series?
 
 Regards,
 Sachin
 
 


 Sachin Kamat (9):
[media] s5p-tv: Add missing braces around sizeof in sdo_drv.c
[media] s5p-tv: Add missing braces around sizeof in mixer_video.c
[media] s5p-tv: Add missing braces around sizeof in mixer_reg.c
[media] s5p-tv: Add missing braces around sizeof in mixer_drv.c
[media] s5p-tv: Add missing braces around sizeof in hdmiphy_drv.c
[media] s5p-tv: Add missing braces around sizeof in hdmi_drv.c
[media] s5p-tv: Use devm_clk_get APIs in sdo_drv.c
[media] s5p-tv: Use devm_* APIs in mixer_drv.c
[media] s5p-tv: Use devm_clk_get APIs in hdmi_drv

 
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/1] [media] s5p-tv: Use devm_gpio_request in sii9234_drv.c

2012-11-15 Thread Tomasz Stanislawski

On 11/16/2012 05:55 AM, Sachin Kamat wrote:
 devm_gpio_request is a device managed function and will make
 error handling and cleanup a bit simpler.
 
 Signed-off-by: Sachin Kamat sachin.ka...@linaro.org

Acked-by: Tomasz Stanislawski t.stanisl...@samsung.com

 ---
  drivers/media/platform/s5p-tv/sii9234_drv.c |6 +-
  1 files changed, 1 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/media/platform/s5p-tv/sii9234_drv.c 
 b/drivers/media/platform/s5p-tv/sii9234_drv.c
 index 716d484..4597342 100644
 --- a/drivers/media/platform/s5p-tv/sii9234_drv.c
 +++ b/drivers/media/platform/s5p-tv/sii9234_drv.c
 @@ -338,7 +338,7 @@ static int __devinit sii9234_probe(struct i2c_client 
 *client,
   }
  
   ctx-gpio_n_reset = pdata-gpio_n_reset;
 - ret = gpio_request(ctx-gpio_n_reset, MHL_RST);
 + ret = devm_gpio_request(dev, ctx-gpio_n_reset, MHL_RST);
   if (ret) {
   dev_err(dev, failed to acquire MHL_RST gpio\n);
   return ret;
 @@ -370,7 +370,6 @@ fail_pm_get:
  
  fail_pm:
   pm_runtime_disable(dev);
 - gpio_free(ctx-gpio_n_reset);
  
  fail:
   dev_err(dev, probe failed\n);
 @@ -381,11 +380,8 @@ fail:
  static int __devexit sii9234_remove(struct i2c_client *client)
  {
   struct device *dev = client-dev;
 - struct v4l2_subdev *sd = i2c_get_clientdata(client);
 - struct sii9234_context *ctx = sd_to_context(sd);
  
   pm_runtime_disable(dev);
 - gpio_free(ctx-gpio_n_reset);
  
   dev_info(dev, remove successful\n);
  
 

--
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 27/26] v4l: vb2: Set data_offset to 0 for single-plane buffers

2012-11-08 Thread Tomasz Stanislawski

Hi Laurent,
The fix was partially applied in [PATCHv10 03/26] v4l: vb2: add support for 
shared buffer (dma_buf).
The data_offset is set to 0 for DMABUF capture/output for single-planar API.

We should define the meaning of data_offset in case of USERPTR and MMAP buffers.
For output device it is pretty intuitive.

For DMABUF capture devices data_offset maybe used to inform a driver to
capture the image at some offset inside the DMABUF buffer.

BTW. Should {} be added after if (V4L2_TYPE_IS_OUTPUT(b-type))
to avoid 'interesting' behavior? :)

Regards,
Tomasz Stanislawski


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv10 21/26] v4l: vb2-dma-contig: add reference counting for a device from allocator context

2012-10-12 Thread Tomasz Stanislawski

Hi Laurent,
Thank your your review.

On 10/11/2012 11:49 PM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thanks for the patch.
 
 On Wednesday 10 October 2012 16:46:40 Tomasz Stanislawski wrote:
 This patch adds taking reference to the device for MMAP buffers.

 Such buffers, may be exported using DMABUF mechanism. If the driver that
 created a queue is unloaded then the queue is released, the device might be
 released too.  However, buffers cannot be released if they are referenced by
 DMABUF descriptor(s). The device pointer kept in a buffer must be valid for
 the whole buffer's lifetime. Therefore MMAP buffers should take a reference
 to the device to avoid risk of dangling pointers.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Acked-by: Hans Verkuil hans.verk...@cisco.com
 
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 
 But two small comments below.
 
 ---
  drivers/media/v4l2-core/videobuf2-dma-contig.c |4 
  1 file changed, 4 insertions(+)

 diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 b/drivers/media/v4l2-core/videobuf2-dma-contig.c index b138b5c..2d661fd
 100644
 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
 @@ -148,6 +148,7 @@ static void vb2_dc_put(void *buf_priv)
  kfree(buf-sgt_base);
  }
  dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
 +put_device(buf-dev);
  kfree(buf);
  }

 @@ -168,6 +169,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
 size) return ERR_PTR(-ENOMEM);
  }

 +/* prevent the device from release while the buffer is exported */
 
 s/prevent/Prevent/ ?
 

s/release/being released/ ?

 +get_device(dev);
 +
  buf-dev = dev;
 
 What about just
 
   buf-dev = get_device(dev);
 

Right, sorry I missed that from your previous review :).

Regards,
Tomasz Stanislawski

  buf-size = size;

--
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: [PATCHv10 22/26] v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned

2012-10-12 Thread Tomasz Stanislawski

Hi Laurent,
Thank you for the review.
Please refer to the comments below.

On 10/11/2012 11:36 PM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 Thanks for the patch.
 
 On Wednesday 10 October 2012 16:46:41 Tomasz Stanislawski wrote:
 From: Marek Szyprowski m.szyprow...@samsung.com

 The DMA transfer must be aligned to a specific value. If userptr is not
 aligned to DMA requirements then unexpected corruptions of the memory may
 occur before or after a buffer.  To prevent such situations, all unligned
 userptr buffers are rejected at VIDIOC_QBUF.

 Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
 Acked-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/v4l2-core/videobuf2-dma-contig.c |   12 
  1 file changed, 12 insertions(+)

 diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 2d661fd..571a919
 100644
 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
 @@ -493,6 +493,18 @@ static void *vb2_dc_get_userptr(void *alloc_ctx,
 unsigned long vaddr, struct vm_area_struct *vma;
  struct sg_table *sgt;
  unsigned long contig_size;
 +unsigned long dma_align = dma_get_cache_alignment();
 +
 +/* Only cache aligned DMA transfers are reliable */
 +if (!IS_ALIGNED(vaddr | size, dma_align)) {
 +pr_debug(user data must be aligned to %lu bytes\n, dma_align);
 +return ERR_PTR(-EINVAL);
 +}
 
 Looks good to me.
 
 +if (!size) {
 +pr_debug(size is zero\n);
 +return ERR_PTR(-EINVAL);
 +}
 
 Can this happen ? The vb2 core already has
 
 /* Check if the provided plane buffer is large enough */
 if (planes[plane].length  q-plane_sizes[plane]) {
 ret = -EINVAL;
 goto err;
 }
 
 Unless queue_setup sets plane_sizes to 0 we can't reach vb2_dc_get_userptr.
 

Yes.. unfortunately, some drivers set plane_size to 0 at queue_setup.
Especially, if REQBUFS is called before any S_FMT.
Maybe it is just a driver bug.

However, VB2 makes no sanity check if plane_sizes[] is zero.
I was not able to find in Documentation nor code comments
any explicit statement that plane_size cannot be zero.

Therefore I have to reject reject a 0-bytes-long user pointer
at vb2_dc_get_userptr before creating an empty scatterlist
and passing it to the DMA layer.

Regards,
Tomasz Stanislawski

  buf = kzalloc(sizeof *buf, GFP_KERNEL);
  if (!buf)
 

--
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: [PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE

2012-10-12 Thread Tomasz Stanislawski

Hi Laurent,

On 10/11/2012 11:31 PM, Laurent Pinchart wrote:
 Hi Tomasz,
 
 On Wednesday 10 October 2012 16:46:42 Tomasz Stanislawski wrote:
 Most operations on DMA and DMABUF framework need page
 aligned buffers.
 
 The comment is a bit misleading, the buffer is already page-aligned (unless 
 I'm mistaken dma_alloc_coherent() returns a page-aligned buffer) but its size 
 isn't a multiple of the page size.

Ok. I will update the commit message that only buffer size is going to be page 
aligned.

 
 Do we really need a page size multiple ? Isn't it enough to make the size a 
 multiple of the cache line size ?
 

Frankly, I strongly oppose forcing a size of a DMA buffer to be rounded up.

However, I discovered a problem while testing mmap() interface in dma-buf.
The test in dma_buf_mmap() will fail if the size is not a multiple of 4k.

Maybe the value from dma-buf.c:456 should be changed from:

dmabuf-size  PAGE_SHIFT

to

PAGE_ALIGN(dmabuf-size)  PAGE_SHIFT

However, I preferred to avoid any changes outside of the media tree
hoping that the patchset gets merged. Rounding the buffer size to
a page size was quick workaround for the issue with DMABUF mmap().

Regards,
Tomasz Stanislawski

 This fix guarantees this requirement
 for vb2-dma-contig buffers.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 ---
  drivers/media/v4l2-core/videobuf2-dma-contig.c |3 +++
  1 file changed, 3 insertions(+)

 diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 571a919..002ee50
 100644
 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
 +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
 @@ -162,6 +162,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long
 size) if (!buf)
  return ERR_PTR(-ENOMEM);

 +/* align image size to PAGE_SIZE */
 +size = PAGE_ALIGN(size);
 +
  buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
  if (!buf-vaddr) {
  dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);

--
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: [PATCHv9 19/25] v4l: vb2: add buffer exporting via dmabuf

On 10/06/2012 02:22 PM, Hans Verkuil wrote:
 On Tue October 2 2012 16:27:30 Tomasz Stanislawski wrote:
 This patch adds extension to videobuf2-core. It allow to export a mmap buffer
 as a file descriptor.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
 ---
  drivers/media/video/videobuf2-core.c |   82 
 ++
  include/media/videobuf2-core.h   |4 ++
  2 files changed, 86 insertions(+)

 diff --git a/drivers/media/video/videobuf2-core.c 
 b/drivers/media/video/videobuf2-core.c
 index 05da3b4..a97815b 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 
 snip
 
 @@ -2455,6 +2528,15 @@ int vb2_ioctl_streamoff(struct file *file, void 
 *priv, enum v4l2_buf_type i)
  }
  EXPORT_SYMBOL_GPL(vb2_ioctl_streamoff);
  
 +int vb2_ioctl_expbuf(struct file *file, void *priv, struct 
 v4l2_exportbuffer *p)
 +{
 +struct video_device *vdev = video_devdata(file);
 +
 +/* No need to call vb2_queue_is_busy(), anyone can export buffers. */

Hi Hans,

 
 After thinking about this some more I'm not so sure we should allow this.
 Exporting a buffer also means that the memory can't be freed as long as the
 exported filehandle remains open.
 

You are completely right.
But the problem is much more complex ... see below.

 That means that it is possible to make a malicious application that exports
 the buffers and never frees them, which can cause havoc.

What kind of havoc do you mean? Resource leakage?

 I think that only
 the filehandle that called REQBUFS/CREATE_BUFS should be allowed to export
 buffers.

Notice that you should allow to call mmap() only for the file handles that 
called
REQBUFS/CREATE_BUFS. The mmap() creates a vma that holds a reference to a 
buffer.
As long as the mapping exists, the buffers cannot be freed and REQBUFS(count=0) 
returns -EBUSY.
According to V4L2 spec all the nodes share the same context, therefore
one process can call REQBUFS, and the other can call QUERYBUF and mmap().

Therefore if EXPBUF has to check vb2_queue_is_busy() then vb2_fop_mmap()
should do the same check too.

IMO, it is very difficult to develop a useful multi-client API that
would protect V4L2 from creating non-freeable buffers by a rogue applications.

I think that the requirements below:

- the buffers should be sharable between processes by mmap(), or DMABUF 
exporting
- the REQBUFS(count=0) should release the buffers

are contradictory and cannot be *reliably* satisfied at the same time.
Notice that REQBUFS(count=0) that unexpectedly return -EBUSY is not
a reliable solution. The application cannot do anything fix the problem
after receiving -EBUSY.

Anyway, I will apply the check for vb2_queue_is_busy() in v2b_ioctl_expbuf().

Regards,
Tomasz Stanislawski

 
 What do you think?
 
 Regards,
 
   Hans
 
 +return vb2_expbuf(vdev-queue, p);
 +}
 +EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
 +
  /* v4l2_file_operations helpers */
  
  int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)

--
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

[PATCHv10 00/26] Integration of videobuf2 with DMABUF

] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819
[4] 
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/49700

Laurent Pinchart (2):
  v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc
  v4l: vb2-dma-contig: reorder functions

Marek Szyprowski (4):
  v4l: vb2: add prepare/finish callbacks to allocators
  v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator
  v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call
  v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned

Sumit Semwal (4):
  v4l: Add DMABUF as a memory type
  v4l: vb2: add support for shared buffer (dma_buf)
  v4l: vb: remove warnings about MEMORY_DMABUF
  v4l: vb2-dma-contig: add support for dma_buf importing

Tomasz Stanislawski (16):
  Documentation: media: description of DMABUF importing in V4L2
  v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
  v4l: vb2-dma-contig: add support for scatterlist in userptr mode
  v4l: vb2-vmalloc: add support for dmabuf importing
  v4l: vivi: support for dmabuf importing
  v4l: s5p-tv: mixer: support for dmabuf importing
  v4l: s5p-fimc: support for dmabuf importing
  Documentation: media: description of DMABUF exporting in V4L2
  v4l: add buffer exporting via dmabuf
  v4l: vb2: add buffer exporting via dmabuf
  v4l: vb2-dma-contig: add support for DMABUF exporting
  v4l: vb2-dma-contig: add reference counting for a device from
allocator context
  v4l: vb2-dma-contig: align buffer size to PAGE_SIZE
  v4l: s5p-fimc: support for dmabuf exporting
  v4l: s5p-tv: mixer: support for dmabuf exporting
  v4l: s5p-mfc: support for dmabuf exporting

 Documentation/DocBook/media/v4l/compat.xml |7 +
 Documentation/DocBook/media/v4l/io.xml |  184 -
 Documentation/DocBook/media/v4l/v4l2.xml   |1 +
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
 Documentation/DocBook/media/v4l/vidioc-expbuf.xml  |  212 ++
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 +
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 +-
 drivers/media/platform/s5p-fimc/fimc-capture.c |   11 +-
 drivers/media/platform/s5p-fimc/fimc-m2m.c |   14 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   14 +
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |   14 +
 drivers/media/platform/s5p-tv/mixer_video.c|   12 +-
 drivers/media/platform/vivi.c  |2 +-
 drivers/media/v4l2-core/Kconfig|3 +
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c  |   19 +
 drivers/media/v4l2-core/v4l2-dev.c |1 +
 drivers/media/v4l2-core/v4l2-ioctl.c   |   11 +
 drivers/media/v4l2-core/v4l2-mem2mem.c |   13 +
 drivers/media/v4l2-core/videobuf-core.c|4 +
 drivers/media/v4l2-core/videobuf2-core.c   |  300 -
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  702 ++--
 drivers/media/v4l2-core/videobuf2-memops.c |   40 --
 drivers/media/v4l2-core/videobuf2-vmalloc.c|   56 ++
 include/linux/videodev2.h  |   35 +
 include/media/v4l2-ioctl.h |2 +
 include/media/v4l2-mem2mem.h   |3 +
 include/media/videobuf2-core.h |   38 ++
 include/media/videobuf2-memops.h   |5 -
 28 files changed, 1645 insertions(+), 138 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml

-- 
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

[PATCHv10 01/26] v4l: Add DMABUF as a memory type

From: Sumit Semwal sumit.sem...@ti.com

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |   18 ++
 drivers/media/v4l2-core/v4l2-ioctl.c  |1 +
 include/linux/videodev2.h |7 +++
 3 files changed, 26 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index 83ffb64..cc5998b 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -297,6 +297,7 @@ struct v4l2_plane32 {
union {
__u32   mem_offset;
compat_long_t   userptr;
+   __s32   fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -318,6 +319,7 @@ struct v4l2_buffer32 {
__u32   offset;
compat_long_t   userptr;
compat_caddr_t  planes;
+   __s32   fd;
} m;
__u32   length;
__u32   reserved2;
@@ -341,6 +343,9 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct 
v4l2_plane32 *up32,
up_pln = compat_ptr(p);
if (put_user((unsigned long)up_pln, up-m.userptr))
return -EFAULT;
+   } else if (memory == V4L2_MEMORY_DMABUF) {
+   if (copy_in_user(up-m.fd, up32-m.fd, sizeof(int)))
+   return -EFAULT;
} else {
if (copy_in_user(up-m.mem_offset, up32-m.mem_offset,
sizeof(__u32)))
@@ -364,6 +369,11 @@ static int put_v4l2_plane32(struct v4l2_plane *up, struct 
v4l2_plane32 *up32,
if (copy_in_user(up32-m.mem_offset, up-m.mem_offset,
sizeof(__u32)))
return -EFAULT;
+   /* For DMABUF, driver might've set up the fd, so copy it back. */
+   if (memory == V4L2_MEMORY_DMABUF)
+   if (copy_in_user(up32-m.fd, up-m.fd,
+   sizeof(int)))
+   return -EFAULT;
 
return 0;
 }
@@ -446,6 +456,10 @@ static int get_v4l2_buffer32(struct v4l2_buffer *kp, 
struct v4l2_buffer32 __user
if (get_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+   case V4L2_MEMORY_DMABUF:
+   if (get_user(kp-m.fd, up-m.fd))
+   return -EFAULT;
+   break;
}
}
 
@@ -510,6 +524,10 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
struct v4l2_buffer32 __user
if (put_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+   case V4L2_MEMORY_DMABUF:
+   if (put_user(kp-m.fd, up-m.fd))
+   return -EFAULT;
+   break;
}
}
 
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 8f388ff..530a67e 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -155,6 +155,7 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= mmap,
[V4L2_MEMORY_USERPTR] = userptr,
[V4L2_MEMORY_OVERLAY] = overlay,
+   [V4L2_MEMORY_DMABUF] = dmabuf,
 };
 
 #define prt_names(a, arr) (((unsigned)(a))  ARRAY_SIZE(arr) ? arr[a] : 
unknown)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 873adbe..07bc5d6 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -188,6 +188,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };
 
 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -604,6 +605,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header

[PATCHv10 02/26] Documentation: media: description of DMABUF importing in V4L2

This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
 Documentation/DocBook/media/v4l/compat.xml |4 +
 Documentation/DocBook/media/v4l/io.xml |  181 +++-
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 ++
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 ++---
 5 files changed, 235 insertions(+), 30 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 4fdf6b5..50eb630 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2586,6 +2586,10 @@ ioctls./para
  paraVendor and device specific media bus pixel formats.
xref linkend=v4l2-mbus-vendor-spec-fmts /./para
 /listitem
+listitem
+ paraImporting DMABUF file descriptors as a new IO method described
+ in xref linkend=dmabuf /./para
+/listitem
   /itemizedlist
 /section
 
diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index b5d1cbd..0abb5cb 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By 
default
 outgoing queue. When the constantO_NONBLOCK/constant flag was
 given to the func-open; function, constantVIDIOC_DQBUF/constant
 returns immediately with an EAGAIN; when no buffer is available. The
-func-select; or func-poll; function are always available./para
+func-select; or func-poll; functions are always available./para
 
 paraTo start and stop capturing or output applications call the
 VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,162 @@ rest should be evident./para
   /footnote/para
   /section
 
+  section id=dmabuf
+titleStreaming I/O (DMA buffer importing)/title
+
+note
+  titleExperimental/title
+  paraThis is an link linkend=experimental experimental /link
+  interface and may change in the future./para
+/note
+
+paraThe DMABUF framework provides a generic method for sharing buffers
+between multiple devices. Device drivers that support DMABUF can export a DMA
+buffer to userspace as a file descriptor (known as the exporter role), import a
+DMA buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2./para
+
+paraInput and output devices support the streaming I/O method when the
+constantV4L2_CAP_STREAMING/constant flag in the
+structfieldcapabilities/structfield field of v4l2-capability; returned by
+the VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+VIDIOC-REQBUFS; ioctl with the memory type set to
+constantV4L2_MEMORY_DMABUF/constant./para
+
+paraThis I/O method is dedicated to sharing DMA buffers between different
+devices, which may be V4L devices or other video-related devices (e.g. DRM).
+Buffers (planes) are allocated by a driver on behalf of an application. Next,
+these buffers are exported to the application as file descriptors using an API
+which is specific for an allocator driver.  Only such file descriptor are
+exchanged. The descriptors and meta-information are passed in v4l2-buffer; (or
+in v4l2-plane; in the multi-planar API case).  The driver must be switched
+into DMABUF I/O mode by calling the VIDIOC-REQBUFS; with the desired buffer
+type./para
+
+example
+  titleInitiating streaming I/O with DMABUF file descriptors/title
+
+  programlisting
+v4l2-requestbuffers; reqbuf;
+
+memset(amp;reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+reqbuf.count = 1;
+
+if (ioctl(fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {
+   if (errno == EINVAL)
+   printf(Video capturing or DMABUF streaming is not 
supported\n);
+   else
+   perror(VIDIOC_REQBUFS);
+
+   exit(EXIT_FAILURE);
+}
+  /programlisting
+/example
+
+paraThe buffer (plane) file descriptor is passed on the fly with the
+VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
+associated with a different DMABUF descriptor. Although buffers are commonly
+cycled, applications can pass a different DMABUF descriptor at each
+constantVIDIOC_QBUF/constant call./para
+
+example
+  titleQueueing DMABUF using single plane API/title
+
+  programlisting
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+   v4l2-buffer; buf;
+
+   memset(amp;buf, 0, sizeof buf);
+   buf.type

[PATCHv10 03/26] v4l: vb2: add support for shared buffer (dma_buf)

From: Sumit Semwal sumit.sem...@ti.com

This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.

For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]

[1]: Rob Clark's DRM:
   https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/Kconfig  |1 +
 drivers/media/v4l2-core/videobuf2-core.c |  206 +-
 include/media/videobuf2-core.h   |   27 
 3 files changed, 231 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 0c54e19..2e787cc 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -59,6 +59,7 @@ config VIDEOBUF_DVB
 
 # Used by drivers that need Videobuf2 modules
 config VIDEOBUF2_CORE
+   select DMA_SHARED_BUFFER
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 432df11..a51dad6 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -109,6 +109,36 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
 }
 
 /**
+ * __vb2_plane_dmabuf_put() - release memory associated with
+ * a DMABUF shared plane
+ */
+static void __vb2_plane_dmabuf_put(struct vb2_queue *q, struct vb2_plane *p)
+{
+   if (!p-mem_priv)
+   return;
+
+   if (p-dbuf_mapped)
+   call_memop(q, unmap_dmabuf, p-mem_priv);
+
+   call_memop(q, detach_dmabuf, p-mem_priv);
+   dma_buf_put(p-dbuf);
+   memset(p, 0, sizeof(*p));
+}
+
+/**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+   struct vb2_queue *q = vb-vb2_queue;
+   unsigned int plane;
+
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   __vb2_plane_dmabuf_put(q, vb-planes[plane]);
+}
+
+/**
  * __setup_offsets() - setup unique offsets (cookies) for every plane in
  * every buffer on the queue
  */
@@ -230,6 +260,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned 
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q-memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+   else if (q-memory == V4L2_MEMORY_DMABUF)
+   __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -362,6 +394,8 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb, 
struct v4l2_buffer *b)
b-m.offset = vb-v4l2_planes[0].m.mem_offset;
else if (q-memory == V4L2_MEMORY_USERPTR)
b-m.userptr = vb-v4l2_planes[0].m.userptr;
+   else if (q-memory == V4L2_MEMORY_DMABUF)
+   b-m.fd = vb-v4l2_planes[0].m.fd;
}
 
/*
@@ -454,13 +488,28 @@ static int __verify_mmap_ops(struct vb2_queue *q)
 }
 
 /**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+   if (!(q-io_modes  VB2_DMABUF) || !q-mem_ops-attach_dmabuf ||
+   !q-mem_ops-detach_dmabuf  || !q-mem_ops-map_dmabuf ||
+   !q-mem_ops-unmap_dmabuf)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
  * __verify_memory_type() - Check whether the memory type and buffer type
  * passed to a buffer operation are compatible with the queue.
  */
 static int __verify_memory_type(struct vb2_queue *q,
enum v4l2_memory memory, enum v4l2_buf_type type)
 {
-   if (memory != V4L2_MEMORY_MMAP  memory != V4L2_MEMORY_USERPTR) {
+   if (memory != V4L2_MEMORY_MMAP  memory != V4L2_MEMORY_USERPTR 
+   memory != V4L2_MEMORY_DMABUF) {
dprintk(1, reqbufs: unsupported memory type\n);
return -EINVAL;
}
@@ -484,6 +533,11 @@ static int __verify_memory_type(struct vb2_queue *q,
return -EINVAL;
}
 
+   if (memory == V4L2_MEMORY_DMABUF  __verify_dmabuf_ops(q)) {
+   dprintk(1, reqbufs: DMABUF for current setup unsupported\n);
+   return -EINVAL;
+   }
+
/*
 * Place the busy tests at the end: -EBUSY can be ignored when
 * create_bufs is called with count == 0, but count == 0 should still

[PATCHv10 04/26] v4l: vb: remove warnings about MEMORY_DMABUF

From: Sumit Semwal sumit.sem...@ti.com

Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf-core.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf-core.c 
b/drivers/media/v4l2-core/videobuf-core.c
index bf7a326..5449e8a 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
case V4L2_MEMORY_OVERLAY:
b-m.offset  = vb-boff;
break;
+   case V4L2_MEMORY_DMABUF:
+   /* DMABUF is not handled in videobuf framework */
+   break;
}
 
b-flags= 0;
@@ -405,6 +408,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
+   case V4L2_MEMORY_DMABUF:
/* nothing */
break;
}
-- 
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

[PATCHv10 05/26] v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   36 
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 4b71326..a05784f 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -32,9 +32,9 @@ struct vb2_dc_buf {
struct vb2_vmarea_handler   handler;
 };
 
-static void vb2_dma_contig_put(void *buf_priv);
+static void vb2_dc_put(void *buf_priv);
 
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
@@ -56,7 +56,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
buf-size = size;
 
buf-handler.refcount = buf-refcount;
-   buf-handler.put = vb2_dma_contig_put;
+   buf-handler.put = vb2_dc_put;
buf-handler.arg = buf;
 
atomic_inc(buf-refcount);
@@ -64,7 +64,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
return buf;
 }
 
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
@@ -75,14 +75,14 @@ static void vb2_dma_contig_put(void *buf_priv)
}
 }
 
-static void *vb2_dma_contig_cookie(void *buf_priv)
+static void *vb2_dc_cookie(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
return buf-dma_addr;
 }
 
-static void *vb2_dma_contig_vaddr(void *buf_priv)
+static void *vb2_dc_vaddr(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
if (!buf)
@@ -91,14 +91,14 @@ static void *vb2_dma_contig_vaddr(void *buf_priv)
return buf-vaddr;
 }
 
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
+static unsigned int vb2_dc_num_users(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
return atomic_read(buf-refcount);
 }
 
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
+static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
 
@@ -111,7 +111,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct 
vm_area_struct *vma)
  vb2_common_vm_ops, buf-handler);
 }
 
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
+static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
 {
struct vb2_dc_buf *buf;
@@ -138,7 +138,7 @@ static void *vb2_dma_contig_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
return buf;
 }
 
-static void vb2_dma_contig_put_userptr(void *mem_priv)
+static void vb2_dc_put_userptr(void *mem_priv)
 {
struct vb2_dc_buf *buf = mem_priv;
 
@@ -150,14 +150,14 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
 }
 
 const struct vb2_mem_ops vb2_dma_contig_memops = {
-   .alloc  = vb2_dma_contig_alloc,
-   .put= vb2_dma_contig_put,
-   .cookie = vb2_dma_contig_cookie,
-   .vaddr  = vb2_dma_contig_vaddr,
-   .mmap   = vb2_dma_contig_mmap,
-   .get_userptr= vb2_dma_contig_get_userptr,
-   .put_userptr= vb2_dma_contig_put_userptr,
-   .num_users  = vb2_dma_contig_num_users,
+   .alloc  = vb2_dc_alloc,
+   .put= vb2_dc_put,
+   .cookie = vb2_dc_cookie,
+   .vaddr  = vb2_dc_vaddr,
+   .mmap   = vb2_dc_mmap,
+   .get_userptr= vb2_dc_get_userptr,
+   .put_userptr= vb2_dc_put_userptr,
+   .num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
 
-- 
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

[PATCHv10 06/26] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer

This patch removes a reference to alloc_ctx from an instance of a DMA
contiguous buffer. It helps to avoid a risk of a dangling pointer if the
context is released while the buffer is still valid. Moreover it removes one
dereference step while accessing a device structure.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a05784f..20c95da 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -23,7 +23,7 @@ struct vb2_dc_conf {
 };
 
 struct vb2_dc_buf {
-   struct vb2_dc_conf  *conf;
+   struct device   *dev;
void*vaddr;
dma_addr_t  dma_addr;
unsigned long   size;
@@ -37,22 +37,21 @@ static void vb2_dc_put(void *buf_priv);
 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
+   struct device *dev = conf-dev;
struct vb2_dc_buf *buf;
 
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
 
-   buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
-   GFP_KERNEL);
+   buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
-   dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
-   size);
+   dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
 
-   buf-conf = conf;
+   buf-dev = dev;
buf-size = size;
 
buf-handler.refcount = buf-refcount;
@@ -69,7 +68,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
 
if (atomic_dec_and_test(buf-refcount)) {
-   dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
+   dma_free_coherent(buf-dev, buf-size, buf-vaddr,
  buf-dma_addr);
kfree(buf);
}
-- 
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

[PATCHv10 07/26] v4l: vb2-dma-contig: reorder functions

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

Group functions by buffer type.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   92 ++--
 1 file changed, 54 insertions(+), 38 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 20c95da..daac2b2 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -25,14 +25,56 @@ struct vb2_dc_conf {
 struct vb2_dc_buf {
struct device   *dev;
void*vaddr;
-   dma_addr_t  dma_addr;
unsigned long   size;
-   struct vm_area_struct   *vma;
-   atomic_trefcount;
+   dma_addr_t  dma_addr;
+
+   /* MMAP related */
struct vb2_vmarea_handler   handler;
+   atomic_trefcount;
+
+   /* USERPTR related */
+   struct vm_area_struct   *vma;
 };
 
-static void vb2_dc_put(void *buf_priv);
+/*/
+/* callbacks for all buffers */
+/*/
+
+static void *vb2_dc_cookie(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return buf-dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return buf-vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return atomic_read(buf-refcount);
+}
+
+/*/
+/*callbacks for MMAP buffers */
+/*/
+
+static void vb2_dc_put(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   if (!atomic_dec_and_test(buf-refcount))
+   return;
+
+   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
+   kfree(buf);
+}
 
 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
@@ -63,40 +105,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
return buf;
 }
 
-static void vb2_dc_put(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   if (atomic_dec_and_test(buf-refcount)) {
-   dma_free_coherent(buf-dev, buf-size, buf-vaddr,
- buf-dma_addr);
-   kfree(buf);
-   }
-}
-
-static void *vb2_dc_cookie(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   return buf-dma_addr;
-}
-
-static void *vb2_dc_vaddr(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-   if (!buf)
-   return NULL;
-
-   return buf-vaddr;
-}
-
-static unsigned int vb2_dc_num_users(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   return atomic_read(buf-refcount);
-}
-
 static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
@@ -110,6 +118,10 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
  vb2_common_vm_ops, buf-handler);
 }
 
+/*/
+/*   callbacks for USERPTR buffers   */
+/*/
+
 static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
 {
@@ -148,6 +160,10 @@ static void vb2_dc_put_userptr(void *mem_priv)
kfree(buf);
 }
 
+/*/
+/*   DMA CONTIG exported functions   */
+/*/
+
 const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc  = vb2_dc_alloc,
.put= vb2_dc_put,
-- 
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

[PATCHv10 08/26] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.

This patch contains some of the code kindly provided by Marek Szyprowski
m.szyprow...@samsung.com and Kamil Debski k.deb...@samsung.com and Andrzej
Pietrasiewicz andrze...@samsung.com. Kind thanks for bug reports from Laurent
Pinchart laurent.pinch...@ideasonboard.com and Seung-Woo Kim
sw0312@samsung.com.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  226 ++--
 1 file changed, 210 insertions(+), 16 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index daac2b2..8486e06 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -11,6 +11,8 @@
  */
 
 #include linux/module.h
+#include linux/scatterlist.h
+#include linux/sched.h
 #include linux/slab.h
 #include linux/dma-mapping.h
 
@@ -27,6 +29,8 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long   size;
dma_addr_t  dma_addr;
+   enum dma_data_direction dma_dir;
+   struct sg_table *dma_sgt;
 
/* MMAP related */
struct vb2_vmarea_handler   handler;
@@ -37,6 +41,44 @@ struct vb2_dc_buf {
 };
 
 /*/
+/*scatterlist table functions*/
+/*/
+
+
+static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
+   void (*cb)(struct page *pg))
+{
+   struct scatterlist *s;
+   unsigned int i;
+
+   for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+   struct page *page = sg_page(s);
+   unsigned int n_pages = PAGE_ALIGN(s-offset + s-length)
+PAGE_SHIFT;
+   unsigned int j;
+
+   for (j = 0; j  n_pages; ++j, ++page)
+   cb(page);
+   }
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+   struct scatterlist *s;
+   dma_addr_t expected = sg_dma_address(sgt-sgl);
+   unsigned int i;
+   unsigned long size = 0;
+
+   for_each_sg(sgt-sgl, s, sgt-nents, i) {
+   if (sg_dma_address(s) != expected)
+   break;
+   expected = sg_dma_address(s) + sg_dma_len(s);
+   size += sg_dma_len(s);
+   }
+   return size;
+}
+
+/*/
 /* callbacks for all buffers */
 /*/
 
@@ -122,42 +164,194 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
 /*   callbacks for USERPTR buffers   */
 /*/
 
+static inline int vma_is_io(struct vm_area_struct *vma)
+{
+   return !!(vma-vm_flags  (VM_IO | VM_PFNMAP));
+}
+
+static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
+   int n_pages, struct vm_area_struct *vma, int write)
+{
+   if (vma_is_io(vma)) {
+   unsigned int i;
+
+   for (i = 0; i  n_pages; ++i, start += PAGE_SIZE) {
+   unsigned long pfn;
+   int ret = follow_pfn(vma, start, pfn);
+
+   if (ret) {
+   pr_err(no page for address %lu\n, start);
+   return ret;
+   }
+   pages[i] = pfn_to_page(pfn);
+   }
+   } else {
+   int n;
+
+   n = get_user_pages(current, current-mm, start  PAGE_MASK,
+   n_pages, write, 1, pages, NULL);
+   /* negative error means that no page was pinned */
+   n = max(n, 0);
+   if (n != n_pages) {
+   pr_err(got only %d of %d user pages\n, n, n_pages);
+   while (n)
+   put_page(pages[--n]);
+   return -EFAULT;
+   }
+   }
+
+   return 0;
+}
+
+static void vb2_dc_put_dirty_page(struct page *page)
+{
+   set_page_dirty_lock(page);
+   put_page(page);
+}
+
+static void vb2_dc_put_userptr(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   dma_unmap_sg(buf-dev, sgt-sgl, sgt-orig_nents, buf-dma_dir);
+   if (!vma_is_io(buf-vma))
+   vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page);
+
+   sg_free_table(sgt);
+   kfree(sgt);
+   vb2_put_vma(buf-vma);
+   kfree(buf);
+}
+
 static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr

[PATCHv10 09/26] v4l: vb2: add prepare/finish callbacks to allocators

From: Marek Szyprowski m.szyprow...@samsung.com

This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-core.c |   11 +++
 include/media/videobuf2-core.h   |7 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index a51dad6..613dea1 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 {
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+   unsigned int plane;
 
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
 
+   /* sync buffers */
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -1136,9 +1141,15 @@ err:
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb-vb2_queue;
+   unsigned int plane;
 
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+   /* sync buffers */
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
 }
 
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 689ae4a..24b9c90 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -56,6 +56,10 @@ struct vb2_fileio_data;
  * dmabuf
  * @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
  *   that this driver is done using the dmabuf for now
+ * @prepare:   called every time the buffer is passed from userspace to the
+ * driver, useful for cache synchronisation, optional
+ * @finish:called every time the buffer is passed back from the driver
+ * to the userspace, also optional
  * @vaddr: return a kernel virtual address to a given memory buffer
  * associated with the passed private structure or NULL if no
  * such mapping exists
@@ -82,6 +86,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
 
+   void(*prepare)(void *buf_priv);
+   void(*finish)(void *buf_priv);
+
void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
-- 
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

[PATCHv10 10/26] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

From: Marek Szyprowski m.szyprow...@samsung.com

Add prepare/finish callbacks to vb2-dma-contig allocator.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 8486e06..494a824 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -103,6 +103,28 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
return atomic_read(buf-refcount);
 }
 
+static void vb2_dc_prepare(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
+static void vb2_dc_finish(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
 /*/
 /*callbacks for MMAP buffers */
 /*/
@@ -366,6 +388,8 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.mmap   = vb2_dc_mmap,
.get_userptr= vb2_dc_get_userptr,
.put_userptr= vb2_dc_put_userptr,
+   .prepare= vb2_dc_prepare,
+   .finish = vb2_dc_finish,
.num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
-- 
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

[PATCHv10 11/26] v4l: vb2-dma-contig: add support for dma_buf importing

From: Sumit Semwal sumit.sem...@ti.com

This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[author of the original patch]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[integration with refactored dma-contig allocator]
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/v4l2-core/Kconfig|1 +
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  120 +++-
 2 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index 2e787cc..e30583b 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -69,6 +69,7 @@ config VIDEOBUF2_DMA_CONTIG
tristate
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+   select DMA_SHARED_BUFFER
 
 config VIDEOBUF2_VMALLOC
tristate
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 494a824..a5804cf 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -10,6 +10,7 @@
  * the Free Software Foundation.
  */
 
+#include linux/dma-buf.h
 #include linux/module.h
 #include linux/scatterlist.h
 #include linux/sched.h
@@ -38,6 +39,9 @@ struct vb2_dc_buf {
 
/* USERPTR related */
struct vm_area_struct   *vma;
+
+   /* DMABUF related */
+   struct dma_buf_attachment   *db_attach;
 };
 
 /*/
@@ -108,7 +112,8 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
 
-   if (!sgt)
+   /* DMABUF exporter will flush the cache for us */
+   if (!sgt || buf-db_attach)
return;
 
dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -119,7 +124,8 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
 
-   if (!sgt)
+   /* DMABUF exporter will flush the cache for us */
+   if (!sgt || buf-db_attach)
return;
 
dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -377,6 +383,112 @@ fail_buf:
 }
 
 /*/
+/*   callbacks for DMABUF buffers*/
+/*/
+
+static int vb2_dc_map_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct sg_table *sgt;
+   unsigned long contig_size;
+
+   if (WARN_ON(!buf-db_attach)) {
+   pr_err(trying to pin a non attached buffer\n);
+   return -EINVAL;
+   }
+
+   if (WARN_ON(buf-dma_sgt)) {
+   pr_err(dmabuf buffer is already pinned\n);
+   return 0;
+   }
+
+   /* get the associated scatterlist for this buffer */
+   sgt = dma_buf_map_attachment(buf-db_attach, buf-dma_dir);
+   if (IS_ERR_OR_NULL(sgt)) {
+   pr_err(Error getting dmabuf scatterlist\n);
+   return -EINVAL;
+   }
+
+   /* checking if dmabuf is big enough to store contiguous chunk */
+   contig_size = vb2_dc_get_contiguous_size(sgt);
+   if (contig_size  buf-size) {
+   pr_err(contiguous chunk is too small %lu/%lu b\n,
+   contig_size, buf-size);
+   dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+   return -EFAULT;
+   }
+
+   buf-dma_addr = sg_dma_address(sgt-sgl);
+   buf-dma_sgt = sgt;
+
+   return 0;
+}
+
+static void vb2_dc_unmap_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (WARN_ON(!buf-db_attach)) {
+   pr_err(trying to unpin a not attached buffer\n);
+   return;
+   }
+
+   if (WARN_ON(!sgt)) {
+   pr_err(dmabuf buffer is already unpinned\n);
+   return;
+   }
+
+   dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+
+   buf-dma_addr = 0;
+   buf-dma_sgt = NULL;
+}
+
+static void vb2_dc_detach_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+
+   /* if vb2 works correctly you should never detach mapped buffer */
+   if (WARN_ON(buf-dma_addr))
+   vb2_dc_unmap_dmabuf(buf);
+
+   /* detach this attachment */
+   dma_buf_detach(buf-db_attach-dmabuf, buf-db_attach);
+   kfree(buf);
+}
+
+static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
+   unsigned long size, int write)
+{
+   struct vb2_dc_conf *conf = alloc_ctx;
+   struct vb2_dc_buf *buf

[PATCHv10 12/26] v4l: vb2-vmalloc: add support for dmabuf importing

This patch adds support for importing DMABUF files for
vmalloc allocator in Videobuf2.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/Kconfig |1 +
 drivers/media/v4l2-core/videobuf2-vmalloc.c |   56 +++
 2 files changed, 57 insertions(+)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index e30583b..65875c3 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -75,6 +75,7 @@ config VIDEOBUF2_VMALLOC
tristate
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+   select DMA_SHARED_BUFFER
 
 config VIDEOBUF2_DMA_SG
tristate
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c 
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 94efa04..a47fd4f 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -30,6 +30,7 @@ struct vb2_vmalloc_buf {
unsigned intn_pages;
atomic_trefcount;
struct vb2_vmarea_handler   handler;
+   struct dma_buf  *dbuf;
 };
 
 static void vb2_vmalloc_put(void *buf_priv);
@@ -207,11 +208,66 @@ static int vb2_vmalloc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
return 0;
 }
 
+/*/
+/*   callbacks for DMABUF buffers*/
+/*/
+
+static int vb2_vmalloc_map_dmabuf(void *mem_priv)
+{
+   struct vb2_vmalloc_buf *buf = mem_priv;
+
+   buf-vaddr = dma_buf_vmap(buf-dbuf);
+
+   return buf-vaddr ? 0 : -EFAULT;
+}
+
+static void vb2_vmalloc_unmap_dmabuf(void *mem_priv)
+{
+   struct vb2_vmalloc_buf *buf = mem_priv;
+
+   dma_buf_vunmap(buf-dbuf, buf-vaddr);
+   buf-vaddr = NULL;
+}
+
+static void vb2_vmalloc_detach_dmabuf(void *mem_priv)
+{
+   struct vb2_vmalloc_buf *buf = mem_priv;
+
+   if (buf-vaddr)
+   dma_buf_vunmap(buf-dbuf, buf-vaddr);
+
+   kfree(buf);
+}
+
+static void *vb2_vmalloc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
+   unsigned long size, int write)
+{
+   struct vb2_vmalloc_buf *buf;
+
+   if (dbuf-size  size)
+   return ERR_PTR(-EFAULT);
+
+   buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+   if (!buf)
+   return ERR_PTR(-ENOMEM);
+
+   buf-dbuf = dbuf;
+   buf-write = write;
+   buf-size = size;
+
+   return buf;
+}
+
+
 const struct vb2_mem_ops vb2_vmalloc_memops = {
.alloc  = vb2_vmalloc_alloc,
.put= vb2_vmalloc_put,
.get_userptr= vb2_vmalloc_get_userptr,
.put_userptr= vb2_vmalloc_put_userptr,
+   .map_dmabuf = vb2_vmalloc_map_dmabuf,
+   .unmap_dmabuf   = vb2_vmalloc_unmap_dmabuf,
+   .attach_dmabuf  = vb2_vmalloc_attach_dmabuf,
+   .detach_dmabuf  = vb2_vmalloc_detach_dmabuf,
.vaddr  = vb2_vmalloc_vaddr,
.mmap   = vb2_vmalloc_mmap,
.num_users  = vb2_vmalloc_num_users,
-- 
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

[PATCHv10 13/26] v4l: vivi: support for dmabuf importing

This patch enhances VIVI driver with a support for importing a buffer
from DMABUF file descriptors.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/vivi.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/vivi.c b/drivers/media/platform/vivi.c
index b366b05..9e077bb 100644
--- a/drivers/media/platform/vivi.c
+++ b/drivers/media/platform/vivi.c
@@ -1308,7 +1308,7 @@ static int __init vivi_create_instance(int inst)
/* initialize queue */
q = dev-vb_vidq;
q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
-   q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_READ;
+   q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ;
q-drv_priv = dev;
q-buf_struct_size = sizeof(struct vivi_buffer);
q-ops = vivi_video_qops;
-- 
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

[PATCHv10 15/26] v4l: s5p-fimc: support for dmabuf importing

This patch enhances s5p-fimc with support for DMABUF importing via
V4L2_MEMORY_DMABUF memory type.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
 drivers/media/platform/s5p-fimc/fimc-m2m.c |4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 367efd1..246bb32 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1730,7 +1730,7 @@ static int fimc_register_capture_device(struct fimc_dev 
*fimc,
q = fimc-vid_cap.vbq;
memset(q, 0, sizeof(*q));
q-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-   q-io_modes = VB2_MMAP | VB2_USERPTR;
+   q-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
q-drv_priv = fimc-vid_cap.ctx;
q-ops = fimc_capture_qops;
q-mem_ops = vb2_dma_contig_memops;
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c 
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index 4500e44..17067a7 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -622,7 +622,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
int ret;
 
src_vq-type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
-   src_vq-io_modes = VB2_MMAP | VB2_USERPTR;
+   src_vq-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
src_vq-drv_priv = ctx;
src_vq-ops = fimc_qops;
src_vq-mem_ops = vb2_dma_contig_memops;
@@ -633,7 +633,7 @@ static int queue_init(void *priv, struct vb2_queue *src_vq,
return ret;
 
dst_vq-type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-   dst_vq-io_modes = VB2_MMAP | VB2_USERPTR;
+   dst_vq-io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF;
dst_vq-drv_priv = ctx;
dst_vq-ops = fimc_qops;
dst_vq-mem_ops = vb2_dma_contig_memops;
-- 
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

[PATCHv10 16/26] v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call

From: Marek Szyprowski m.szyprow...@samsung.com

Let mmap method to use dma_mmap_coherent call.  Moreover, this patch removes
vb2_mmap_pfn_range from videobuf2 helpers as it was suggested by Laurent
Pinchart.  The function is no longer used in vb2 code.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   28 +++--
 drivers/media/v4l2-core/videobuf2-memops.c |   40 
 include/media/videobuf2-memops.h   |5 ---
 3 files changed, 26 insertions(+), 47 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a5804cf..0e065ce 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -178,14 +178,38 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
 static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
+   int ret;
 
if (!buf) {
printk(KERN_ERR No buffer to map\n);
return -EINVAL;
}
 
-   return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size,
- vb2_common_vm_ops, buf-handler);
+   /*
+* dma_mmap_* uses vm_pgoff as in-buffer offset, but we want to
+* map whole buffer
+*/
+   vma-vm_pgoff = 0;
+
+   ret = dma_mmap_coherent(buf-dev, vma, buf-vaddr,
+   buf-dma_addr, buf-size);
+
+   if (ret) {
+   pr_err(Remapping memory failed, error: %d\n, ret);
+   return ret;
+   }
+
+   vma-vm_flags   |= VM_DONTEXPAND | VM_RESERVED;
+   vma-vm_private_data= buf-handler;
+   vma-vm_ops = vb2_common_vm_ops;
+
+   vma-vm_ops-open(vma);
+
+   pr_debug(%s: mapped dma addr 0x%08lx at 0x%08lx, size %ld\n,
+   __func__, (unsigned long)buf-dma_addr, vma-vm_start,
+   buf-size);
+
+   return 0;
 }
 
 /*/
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c 
b/drivers/media/v4l2-core/videobuf2-memops.c
index 504cd4c..81c1ad8 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -137,46 +137,6 @@ int vb2_get_contig_userptr(unsigned long vaddr, unsigned 
long size,
 EXPORT_SYMBOL_GPL(vb2_get_contig_userptr);
 
 /**
- * vb2_mmap_pfn_range() - map physical pages to userspace
- * @vma:   virtual memory region for the mapping
- * @paddr: starting physical address of the memory to be mapped
- * @size:  size of the memory to be mapped
- * @vm_ops:vm operations to be assigned to the created area
- * @priv:  private data to be associated with the area
- *
- * Returns 0 on success.
- */
-int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long paddr,
-   unsigned long size,
-   const struct vm_operations_struct *vm_ops,
-   void *priv)
-{
-   int ret;
-
-   size = min_t(unsigned long, vma-vm_end - vma-vm_start, size);
-
-   vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
-   ret = remap_pfn_range(vma, vma-vm_start, paddr  PAGE_SHIFT,
-   size, vma-vm_page_prot);
-   if (ret) {
-   printk(KERN_ERR Remapping memory failed, error: %d\n, ret);
-   return ret;
-   }
-
-   vma-vm_flags   |= VM_DONTEXPAND | VM_RESERVED;
-   vma-vm_private_data= priv;
-   vma-vm_ops = vm_ops;
-
-   vma-vm_ops-open(vma);
-
-   pr_debug(%s: mapped paddr 0x%08lx at 0x%08lx, size %ld\n,
-   __func__, paddr, vma-vm_start, size);
-
-   return 0;
-}
-EXPORT_SYMBOL_GPL(vb2_mmap_pfn_range);
-
-/**
  * vb2_common_vm_open() - increase refcount of the vma
  * @vma:   virtual memory region for the mapping
  *
diff --git a/include/media/videobuf2-memops.h b/include/media/videobuf2-memops.h
index 84e1f6c..f05444c 100644
--- a/include/media/videobuf2-memops.h
+++ b/include/media/videobuf2-memops.h
@@ -33,11 +33,6 @@ extern const struct vm_operations_struct vb2_common_vm_ops;
 int vb2_get_contig_userptr(unsigned long vaddr, unsigned long size,
   struct vm_area_struct **res_vma, dma_addr_t *res_pa);
 
-int vb2_mmap_pfn_range(struct vm_area_struct *vma, unsigned long paddr,
-   unsigned long size,
-   const struct vm_operations_struct *vm_ops,
-   void *priv);
-
 struct vm_area_struct *vb2_get_vma(struct vm_area_struct *vma);
 void vb2_put_vma(struct vm_area_struct *vma);
 
-- 
1.7.9.5

--
To unsubscribe from

[PATCHv10 17/26] Documentation: media: description of DMABUF exporting in V4L2

This patch adds description and usage examples for exporting
DMABUF file descriptor in V4L2.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
 Documentation/DocBook/media/v4l/compat.xml|3 +
 Documentation/DocBook/media/v4l/io.xml|3 +
 Documentation/DocBook/media/v4l/v4l2.xml  |1 +
 Documentation/DocBook/media/v4l/vidioc-expbuf.xml |  212 +
 4 files changed, 219 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 50eb630..3dd9e78 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2590,6 +2590,9 @@ ioctls./para
  paraImporting DMABUF file descriptors as a new IO method described
  in xref linkend=dmabuf /./para
 /listitem
+listitem
+ paraExporting DMABUF files using VIDIOC-EXPBUF; ioctl./para
+/listitem
   /itemizedlist
 /section
 
diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 0abb5cb..81d0ed4 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -488,6 +488,9 @@ DMA buffer from userspace using a file descriptor 
previously exported for a
 different or the same device (known as the importer role), or both. This
 section describes the DMABUF importer role API in V4L2./para
 
+paraRefer to link linked=vidioc-expbuf DMABUF exporting /link for
+details about exporting V4L2 buffers as DMABUF file descriptors./para
+
 paraInput and output devices support the streaming I/O method when the
 constantV4L2_CAP_STREAMING/constant flag in the
 structfieldcapabilities/structfield field of v4l2-capability; returned by
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml 
b/Documentation/DocBook/media/v4l/v4l2.xml
index 10ccde9..4d110b1 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -543,6 +543,7 @@ and discussions on the V4L mailing list./revremark
 sub-enuminput;
 sub-enumoutput;
 sub-enumstd;
+sub-expbuf;
 sub-g-audio;
 sub-g-audioout;
 sub-g-crop;
diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml 
b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
new file mode 100644
index 000..72dfbd2
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
@@ -0,0 +1,212 @@
+refentry id=vidioc-expbuf
+
+  refmeta
+refentrytitleioctl VIDIOC_EXPBUF/refentrytitle
+manvol;
+  /refmeta
+
+  refnamediv
+refnameVIDIOC_EXPBUF/refname
+refpurposeExport a buffer as a DMABUF file descriptor./refpurpose
+  /refnamediv
+
+  refsynopsisdiv
+funcsynopsis
+  funcprototype
+   funcdefint functionioctl/function/funcdef
+   paramdefint parameterfd/parameter/paramdef
+   paramdefint parameterrequest/parameter/paramdef
+   paramdefstruct v4l2_exportbuffer 
*parameterargp/parameter/paramdef
+  /funcprototype
+/funcsynopsis
+  /refsynopsisdiv
+
+  refsect1
+titleArguments/title
+
+variablelist
+  varlistentry
+   termparameterfd/parameter/term
+   listitem
+ parafd;/para
+   /listitem
+  /varlistentry
+  varlistentry
+   termparameterrequest/parameter/term
+   listitem
+ paraVIDIOC_EXPBUF/para
+   /listitem
+  /varlistentry
+  varlistentry
+   termparameterargp/parameter/term
+   listitem
+ para/para
+   /listitem
+  /varlistentry
+/variablelist
+  /refsect1
+
+  refsect1
+titleDescription/title
+
+note
+  titleExperimental/title
+  paraThis is an link linkend=experimental experimental /link
+  interface and may change in the future./para
+/note
+
+paraThis ioctl is an extension to the link linkend=mmapmemory
+mapping/link I/O method, therefore it is available only for
+constantV4L2_MEMORY_MMAP/constant buffers.  It can be used to export a
+buffer as a DMABUF file at any time after buffers have been allocated with the
+VIDIOC-REQBUFS; ioctl./para
+
+para To export a buffer, applications fill v4l2-exportbuffer;.  The
+structfield type /structfield field is set to the same buffer type as was
+previously used with  v4l2-requestbuffers;structfield type /structfield.
+Applications must also set the structfield index /structfield field. Valid
+index numbers range from zero to the number of buffers allocated with
+VIDIOC-REQBUFS; (v4l2-requestbuffers;structfield count /structfield)
+minus one.  For the multi-planar API, applications set the structfield plane
+/structfield field to the index of the plane to be exported. Valid planes
+range from zero to the maximal number of valid planes for the currently active
+format. For the single-planar API, applications must set

[PATCHv10 18/26] v4l: add buffer exporting via dmabuf

This patch adds extension to V4L2 api. It allow to export a mmap buffer as file
descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset used by
mmap and return a file descriptor on success.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
 drivers/media/v4l2-core/v4l2-compat-ioctl32.c |1 +
 drivers/media/v4l2-core/v4l2-dev.c|1 +
 drivers/media/v4l2-core/v4l2-ioctl.c  |   10 +
 include/linux/videodev2.h |   28 +
 include/media/v4l2-ioctl.h|2 ++
 5 files changed, 42 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c 
b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
index cc5998b..7157af3 100644
--- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
+++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
@@ -1018,6 +1018,7 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int 
cmd, unsigned long arg)
case VIDIOC_S_FBUF32:
case VIDIOC_OVERLAY32:
case VIDIOC_QBUF32:
+   case VIDIOC_EXPBUF:
case VIDIOC_DQBUF32:
case VIDIOC_STREAMON32:
case VIDIOC_STREAMOFF32:
diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index a2df842..98dcad9 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -571,6 +571,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
+   SET_VALID_IOCTL(ops, VIDIOC_EXPBUF, vidioc_expbuf);
SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
SET_VALID_IOCTL(ops, VIDIOC_STREAMON, vidioc_streamon);
SET_VALID_IOCTL(ops, VIDIOC_STREAMOFF, vidioc_streamoff);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 530a67e..aa6e7c7 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -454,6 +454,15 @@ static void v4l_print_buffer(const void *arg, bool 
write_only)
tc-type, tc-flags, tc-frames, *(__u32 
*)tc-userbits);
 }
 
+static void v4l_print_exportbuffer(const void *arg, bool write_only)
+{
+   const struct v4l2_exportbuffer *p = arg;
+
+   pr_cont(fd=%d, type=%s, index=%u, plane=%u, flags=0x%08x\n,
+   p-fd, prt_names(p-type, v4l2_type_names),
+   p-index, p-plane, p-flags);
+}
+
 static void v4l_print_create_buffers(const void *arg, bool write_only)
 {
const struct v4l2_create_buffers *p = arg;
@@ -1961,6 +1970,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = {
IOCTL_INFO_STD(VIDIOC_S_FBUF, vidioc_s_fbuf, v4l_print_framebuffer, 
INFO_FL_PRIO),
IOCTL_INFO_FNC(VIDIOC_OVERLAY, v4l_overlay, v4l_print_u32, 
INFO_FL_PRIO),
IOCTL_INFO_FNC(VIDIOC_QBUF, v4l_qbuf, v4l_print_buffer, INFO_FL_QUEUE),
+   IOCTL_INFO_STD(VIDIOC_EXPBUF, vidioc_expbuf, v4l_print_exportbuffer, 
INFO_FL_QUEUE | INFO_FL_CLEAR(v4l2_exportbuffer, flags)),
IOCTL_INFO_FNC(VIDIOC_DQBUF, v4l_dqbuf, v4l_print_buffer, 
INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMON, v4l_streamon, v4l_print_buftype, 
INFO_FL_PRIO | INFO_FL_QUEUE),
IOCTL_INFO_FNC(VIDIOC_STREAMOFF, v4l_streamoff, v4l_print_buftype, 
INFO_FL_PRIO | INFO_FL_QUEUE),
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 07bc5d6..19765df 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -696,6 +696,33 @@ struct v4l2_buffer {
 #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE  0x0800
 #define V4L2_BUF_FLAG_NO_CACHE_CLEAN   0x1000
 
+/**
+ * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
+ *
+ * @index: id number of the buffer
+ * @type:  enum v4l2_buf_type; buffer type (type == *_MPLANE for
+ * multiplanar buffers);
+ * @plane: index of the plane to be exported, 0 for single plane queues
+ * @flags: flags for newly created file, currently only O_CLOEXEC is
+ * supported, refer to manual of open syscall for more details
+ * @fd:file descriptor associated with DMABUF (set by driver)
+ *
+ * Contains data used for exporting a video buffer as DMABUF file descriptor.
+ * The buffer is identified by a 'cookie' returned by VIDIOC_QUERYBUF
+ * (identical to the cookie used to mmap() the buffer to userspace). All
+ * reserved fields must be set to zero. The field reserved0 is expected to
+ * become a structure 'type' allowing an alternative layout of the structure
+ * content. Therefore this field should not be used for any other extensions.
+ */
+struct v4l2_exportbuffer {
+   __u32   type; /* enum v4l2_buf_type */
+   __u32   index;
+   __u32   plane;
+   __u32   flags

[PATCHv10 19/26] v4l: vb2: add buffer exporting via dmabuf

This patch adds extension to videobuf2-core. It allow to export a mmap buffer
as a file descriptor.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/v4l2-mem2mem.c   |   13 +
 drivers/media/v4l2-core/videobuf2-core.c |   83 ++
 include/media/v4l2-mem2mem.h |3 ++
 include/media/videobuf2-core.h   |4 ++
 4 files changed, 103 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c 
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 3ac8358..9aa7cc7 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -369,6 +369,19 @@ int v4l2_m2m_dqbuf(struct file *file, struct v4l2_m2m_ctx 
*m2m_ctx,
 EXPORT_SYMBOL_GPL(v4l2_m2m_dqbuf);
 
 /**
+ * v4l2_m2m_expbuf() - export a source or destination buffer, depending on
+ * the type
+ */
+int v4l2_m2m_expbuf(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
+ struct v4l2_exportbuffer *eb)
+{
+   struct vb2_queue *vq;
+
+   vq = v4l2_m2m_get_vq(m2m_ctx, eb-type);
+   return vb2_expbuf(vq, eb);
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_expbuf);
+/**
  * v4l2_m2m_streamon() - turn on streaming for a video queue
  */
 int v4l2_m2m_streamon(struct file *file, struct v4l2_m2m_ctx *m2m_ctx,
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 613dea1..9f81be2 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1751,6 +1751,79 @@ static int __find_plane_by_offset(struct vb2_queue *q, 
unsigned long off,
 }
 
 /**
+ * vb2_expbuf() - Export a buffer as a file descriptor
+ * @q: videobuf2 queue
+ * @eb:export buffer structure passed from userspace to 
vidioc_expbuf
+ * handler in driver
+ *
+ * The return values from this function are intended to be directly returned
+ * from vidioc_expbuf handler in driver.
+ */
+int vb2_expbuf(struct vb2_queue *q, struct v4l2_exportbuffer *eb)
+{
+   struct vb2_buffer *vb = NULL;
+   struct vb2_plane *vb_plane;
+   int ret;
+   struct dma_buf *dbuf;
+
+   if (q-memory != V4L2_MEMORY_MMAP) {
+   dprintk(1, Queue is not currently set up for mmap\n);
+   return -EINVAL;
+   }
+
+   if (!q-mem_ops-get_dmabuf) {
+   dprintk(1, Queue does not support DMA buffer exporting\n);
+   return -EINVAL;
+   }
+
+   if (eb-flags  ~O_CLOEXEC) {
+   dprintk(1, Queue does support only O_CLOEXEC flag\n);
+   return -EINVAL;
+   }
+
+   if (eb-type != q-type) {
+   dprintk(1, qbuf: invalid buffer type\n);
+   return -EINVAL;
+   }
+
+   if (eb-index = q-num_buffers) {
+   dprintk(1, buffer index out of range\n);
+   return -EINVAL;
+   }
+
+   vb = q-bufs[eb-index];
+
+   if (eb-plane = vb-num_planes) {
+   dprintk(1, buffer plane out of range\n);
+   return -EINVAL;
+   }
+
+   vb_plane = vb-planes[eb-plane];
+
+   dbuf = call_memop(q, get_dmabuf, vb_plane-mem_priv);
+   if (IS_ERR_OR_NULL(dbuf)) {
+   dprintk(1, Failed to export buffer %d, plane %d\n,
+   eb-index, eb-plane);
+   return -EINVAL;
+   }
+
+   ret = dma_buf_fd(dbuf, eb-flags);
+   if (ret  0) {
+   dprintk(3, buffer %d, plane %d failed to export (%d)\n,
+   eb-index, eb-plane, ret);
+   dma_buf_put(dbuf);
+   return ret;
+   }
+
+   dprintk(3, buffer %d, plane %d exported as %d descriptor\n,
+   eb-index, eb-plane, ret);
+   eb-fd = ret;
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(vb2_expbuf);
+
+/**
  * vb2_mmap() - map video buffers into application address space
  * @q: videobuf2 queue
  * @vma:   vma passed to the mmap file operation handler in the driver
@@ -2456,6 +2529,16 @@ int vb2_ioctl_streamoff(struct file *file, void *priv, 
enum v4l2_buf_type i)
 }
 EXPORT_SYMBOL_GPL(vb2_ioctl_streamoff);
 
+int vb2_ioctl_expbuf(struct file *file, void *priv, struct v4l2_exportbuffer 
*p)
+{
+   struct video_device *vdev = video_devdata(file);
+
+   if (vb2_queue_is_busy(vdev, file))
+   return -EBUSY;
+   return vb2_expbuf(vdev-queue, p);
+}
+EXPORT_SYMBOL_GPL(vb2_ioctl_expbuf);
+
 /* v4l2_file_operations helpers */
 
 int vb2_fop_mmap(struct file *file, struct vm_area_struct *vma)
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index 131cc4a..7e82d2b 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -111,6 +111,9 @@ int v4l2_m2m_qbuf(struct file *file, struct v4l2_m2m_ctx 
*m2m_ctx,
 int v4l2_m2m_dqbuf

[PATCHv10 20/26] v4l: vb2-dma-contig: add support for DMABUF exporting

This patch adds support for exporting a dma-contig buffer using
DMABUF interface.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |  200 
 1 file changed, 200 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 0e065ce..b138b5c 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -36,6 +36,7 @@ struct vb2_dc_buf {
/* MMAP related */
struct vb2_vmarea_handler   handler;
atomic_trefcount;
+   struct sg_table *sgt_base;
 
/* USERPTR related */
struct vm_area_struct   *vma;
@@ -142,6 +143,10 @@ static void vb2_dc_put(void *buf_priv)
if (!atomic_dec_and_test(buf-refcount))
return;
 
+   if (buf-sgt_base) {
+   sg_free_table(buf-sgt_base);
+   kfree(buf-sgt_base);
+   }
dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
kfree(buf);
 }
@@ -213,6 +218,200 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
 }
 
 /*/
+/* DMABUF ops for exporters  */
+/*/
+
+struct vb2_dc_attachment {
+   struct sg_table sgt;
+   enum dma_data_direction dir;
+};
+
+static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf, struct device *dev,
+   struct dma_buf_attachment *dbuf_attach)
+{
+   struct vb2_dc_attachment *attach;
+   unsigned int i;
+   struct scatterlist *rd, *wr;
+   struct sg_table *sgt;
+   struct vb2_dc_buf *buf = dbuf-priv;
+   int ret;
+
+   attach = kzalloc(sizeof(*attach), GFP_KERNEL);
+   if (!attach)
+   return -ENOMEM;
+
+   sgt = attach-sgt;
+   /* Copy the buf-base_sgt scatter list to the attachment, as we can't
+* map the same scatter list to multiple attachments at the same time.
+*/
+   ret = sg_alloc_table(sgt, buf-sgt_base-orig_nents, GFP_KERNEL);
+   if (ret) {
+   kfree(attach);
+   return -ENOMEM;
+   }
+
+   rd = buf-sgt_base-sgl;
+   wr = sgt-sgl;
+   for (i = 0; i  sgt-orig_nents; ++i) {
+   sg_set_page(wr, sg_page(rd), rd-length, rd-offset);
+   rd = sg_next(rd);
+   wr = sg_next(wr);
+   }
+
+   attach-dir = DMA_NONE;
+   dbuf_attach-priv = attach;
+
+   return 0;
+}
+
+static void vb2_dc_dmabuf_ops_detach(struct dma_buf *dbuf,
+   struct dma_buf_attachment *db_attach)
+{
+   struct vb2_dc_attachment *attach = db_attach-priv;
+   struct sg_table *sgt;
+
+   if (!attach)
+   return;
+
+   sgt = attach-sgt;
+
+   /* release the scatterlist cache */
+   if (attach-dir != DMA_NONE)
+   dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
+   attach-dir);
+   sg_free_table(sgt);
+   kfree(attach);
+   db_attach-priv = NULL;
+}
+
+static struct sg_table *vb2_dc_dmabuf_ops_map(
+   struct dma_buf_attachment *db_attach, enum dma_data_direction dir)
+{
+   struct vb2_dc_attachment *attach = db_attach-priv;
+   /* stealing dmabuf mutex to serialize map/unmap operations */
+   struct mutex *lock = db_attach-dmabuf-lock;
+   struct sg_table *sgt;
+   int ret;
+
+   mutex_lock(lock);
+
+   sgt = attach-sgt;
+   /* return previously mapped sg table */
+   if (attach-dir == dir) {
+   mutex_unlock(lock);
+   return sgt;
+   }
+
+   /* release any previous cache */
+   if (attach-dir != DMA_NONE) {
+   dma_unmap_sg(db_attach-dev, sgt-sgl, sgt-orig_nents,
+   attach-dir);
+   attach-dir = DMA_NONE;
+   }
+
+   /* mapping to the client with new direction */
+   ret = dma_map_sg(db_attach-dev, sgt-sgl, sgt-orig_nents, dir);
+   if (ret = 0) {
+   pr_err(failed to map scatterlist\n);
+   mutex_unlock(lock);
+   return ERR_PTR(-EIO);
+   }
+
+   attach-dir = dir;
+
+   mutex_unlock(lock);
+
+   return sgt;
+}
+
+static void vb2_dc_dmabuf_ops_unmap(struct dma_buf_attachment *db_attach,
+   struct sg_table *sgt, enum dma_data_direction dir)
+{
+   /* nothing to be done here */
+}
+
+static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
+{
+   /* drop reference obtained in vb2_dc_get_dmabuf */
+   vb2_dc_put(dbuf-priv);
+}
+
+static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
+{
+   struct vb2_dc_buf *buf = dbuf-priv;
+
+   return buf-vaddr + pgnum * PAGE_SIZE;
+}
+
+static void

[PATCHv10 21/26] v4l: vb2-dma-contig: add reference counting for a device from allocator context

This patch adds taking reference to the device for MMAP buffers.

Such buffers, may be exported using DMABUF mechanism. If the driver that
created a queue is unloaded then the queue is released, the device might be
released too.  However, buffers cannot be released if they are referenced by
DMABUF descriptor(s). The device pointer kept in a buffer must be valid for the
whole buffer's lifetime. Therefore MMAP buffers should take a reference to the
device to avoid risk of dangling pointers.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index b138b5c..2d661fd 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -148,6 +148,7 @@ static void vb2_dc_put(void *buf_priv)
kfree(buf-sgt_base);
}
dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
+   put_device(buf-dev);
kfree(buf);
 }
 
@@ -168,6 +169,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
return ERR_PTR(-ENOMEM);
}
 
+   /* prevent the device from release while the buffer is exported */
+   get_device(dev);
+
buf-dev = dev;
buf-size = size;
 
-- 
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

[PATCHv10 22/26] v4l: vb2-dma-contig: fail if user ptr buffer is not correctly aligned

From: Marek Szyprowski m.szyprow...@samsung.com

The DMA transfer must be aligned to a specific value. If userptr is not aligned
to DMA requirements then unexpected corruptions of the memory may occur before
or after a buffer.  To prevent such situations, all unligned userptr buffers
are rejected at VIDIOC_QBUF.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 2d661fd..571a919 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -493,6 +493,18 @@ static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned 
long vaddr,
struct vm_area_struct *vma;
struct sg_table *sgt;
unsigned long contig_size;
+   unsigned long dma_align = dma_get_cache_alignment();
+
+   /* Only cache aligned DMA transfers are reliable */
+   if (!IS_ALIGNED(vaddr | size, dma_align)) {
+   pr_debug(user data must be aligned to %lu bytes\n, dma_align);
+   return ERR_PTR(-EINVAL);
+   }
+
+   if (!size) {
+   pr_debug(size is zero\n);
+   return ERR_PTR(-EINVAL);
+   }
 
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
-- 
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

[PATCHv10 23/26] v4l: vb2-dma-contig: align buffer size to PAGE_SIZE

Most operations on DMA and DMABUF framework need page
aligned buffers. This fix guarantees this requirement
for vb2-dma-contig buffers.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 571a919..002ee50 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -162,6 +162,9 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
if (!buf)
return ERR_PTR(-ENOMEM);
 
+   /* align image size to PAGE_SIZE */
+   size = PAGE_ALIGN(size);
+
buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
-- 
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

[PATCHv10 24/26] v4l: s5p-fimc: support for dmabuf exporting

This patch enhances s5p-fimc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Sylwester Nawrocki s.nawro...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/s5p-fimc/fimc-capture.c |9 +
 drivers/media/platform/s5p-fimc/fimc-m2m.c |   10 ++
 2 files changed, 19 insertions(+)

diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c 
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 246bb32..e5fd159 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1231,6 +1231,14 @@ static int fimc_cap_qbuf(struct file *file, void *priv,
return vb2_qbuf(fimc-vid_cap.vbq, buf);
 }
 
+static int fimc_cap_expbuf(struct file *file, void *priv,
+ struct v4l2_exportbuffer *eb)
+{
+   struct fimc_dev *fimc = video_drvdata(file);
+
+   return vb2_expbuf(fimc-vid_cap.vbq, eb);
+}
+
 static int fimc_cap_dqbuf(struct file *file, void *priv,
   struct v4l2_buffer *buf)
 {
@@ -1355,6 +1363,7 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops 
= {
 
.vidioc_qbuf= fimc_cap_qbuf,
.vidioc_dqbuf   = fimc_cap_dqbuf,
+   .vidioc_expbuf  = fimc_cap_expbuf,
 
.vidioc_prepare_buf = fimc_cap_prepare_buf,
.vidioc_create_bufs = fimc_cap_create_bufs,
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c 
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index 17067a7..1cd4fcf 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -439,6 +439,15 @@ static int fimc_m2m_dqbuf(struct file *file, void *fh,
return v4l2_m2m_dqbuf(file, ctx-m2m_ctx, buf);
 }
 
+static int fimc_m2m_expbuf(struct file *file, void *fh,
+   struct v4l2_exportbuffer *eb)
+{
+   struct fimc_ctx *ctx = fh_to_ctx(fh);
+
+   return v4l2_m2m_expbuf(file, ctx-m2m_ctx, eb);
+}
+
+
 static int fimc_m2m_streamon(struct file *file, void *fh,
 enum v4l2_buf_type type)
 {
@@ -607,6 +616,7 @@ static const struct v4l2_ioctl_ops fimc_m2m_ioctl_ops = {
.vidioc_querybuf= fimc_m2m_querybuf,
.vidioc_qbuf= fimc_m2m_qbuf,
.vidioc_dqbuf   = fimc_m2m_dqbuf,
+   .vidioc_expbuf  = fimc_m2m_expbuf,
.vidioc_streamon= fimc_m2m_streamon,
.vidioc_streamoff   = fimc_m2m_streamoff,
.vidioc_g_crop  = fimc_m2m_g_crop,
-- 
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

[PATCHv10 25/26] v4l: s5p-tv: mixer: support for dmabuf exporting

This patch enhances s5p-tv with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/s5p-tv/mixer_video.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/media/platform/s5p-tv/mixer_video.c 
b/drivers/media/platform/s5p-tv/mixer_video.c
index 2421e527..5e3cdb2 100644
--- a/drivers/media/platform/s5p-tv/mixer_video.c
+++ b/drivers/media/platform/s5p-tv/mixer_video.c
@@ -698,6 +698,15 @@ static int mxr_dqbuf(struct file *file, void *priv, struct 
v4l2_buffer *p)
return vb2_dqbuf(layer-vb_queue, p, file-f_flags  O_NONBLOCK);
 }
 
+static int mxr_expbuf(struct file *file, void *priv,
+   struct v4l2_exportbuffer *eb)
+{
+   struct mxr_layer *layer = video_drvdata(file);
+
+   mxr_dbg(layer-mdev, %s:%d\n, __func__, __LINE__);
+   return vb2_expbuf(layer-vb_queue, eb);
+}
+
 static int mxr_streamon(struct file *file, void *priv, enum v4l2_buf_type i)
 {
struct mxr_layer *layer = video_drvdata(file);
@@ -725,6 +734,7 @@ static const struct v4l2_ioctl_ops mxr_ioctl_ops = {
.vidioc_querybuf = mxr_querybuf,
.vidioc_qbuf = mxr_qbuf,
.vidioc_dqbuf = mxr_dqbuf,
+   .vidioc_expbuf = mxr_expbuf,
/* Streaming control */
.vidioc_streamon = mxr_streamon,
.vidioc_streamoff = mxr_streamoff,
-- 
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

[PATCHv10 26/26] v4l: s5p-mfc: support for dmabuf exporting

This patch enhances s5p-mfc with support for DMABUF exporting via
VIDIOC_EXPBUF ioctl.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Kamil Debski k.deb...@samsung.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c |   14 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c |   14 ++
 2 files changed, 28 insertions(+)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
index eb6a70b..6dad9a7 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
@@ -636,6 +636,19 @@ static int vidioc_dqbuf(struct file *file, void *priv, 
struct v4l2_buffer *buf)
return -EINVAL;
 }
 
+/* Export DMA buffer */
+static int vidioc_expbuf(struct file *file, void *priv,
+   struct v4l2_exportbuffer *eb)
+{
+   struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
+
+   if (eb-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+   return vb2_expbuf(ctx-vq_src, eb);
+   if (eb-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   return vb2_expbuf(ctx-vq_dst, eb);
+   return -EINVAL;
+}
+
 /* Stream on */
 static int vidioc_streamon(struct file *file, void *priv,
   enum v4l2_buf_type type)
@@ -813,6 +826,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_dec_ioctl_ops = {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+   .vidioc_expbuf = vidioc_expbuf,
.vidioc_streamon = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
.vidioc_g_crop = vidioc_g_crop,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 2af6d52..22bf684 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -1165,6 +1165,19 @@ static int vidioc_dqbuf(struct file *file, void *priv, 
struct v4l2_buffer *buf)
return ret;
 }
 
+/* Export DMA buffer */
+static int vidioc_expbuf(struct file *file, void *priv,
+   struct v4l2_exportbuffer *eb)
+{
+   struct s5p_mfc_ctx *ctx = fh_to_ctx(priv);
+
+   if (eb-type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
+   return vb2_expbuf(ctx-vq_src, eb);
+   if (eb-type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+   return vb2_expbuf(ctx-vq_dst, eb);
+   return -EINVAL;
+}
+
 /* Stream on */
 static int vidioc_streamon(struct file *file, void *priv,
   enum v4l2_buf_type type)
@@ -1568,6 +1581,7 @@ static const struct v4l2_ioctl_ops s5p_mfc_enc_ioctl_ops 
= {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+   .vidioc_expbuf = vidioc_expbuf,
.vidioc_streamon = vidioc_streamon,
.vidioc_streamoff = vidioc_streamoff,
.vidioc_s_parm = vidioc_s_parm,
-- 
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

Test application for DMABUF support in V4L2

Hello everyone,
This mail contains an application to test DMABUF support
in V4L2 for VIVI and S5P-FIMC drivers. The application was
tested on linux-media for 3.7 with applied patchset
[PATCHv10 */26] Integration of videobuf2 with DMABUF
on Universal C210 board.

Compilation:
1. Fetch media-next, apply patchset [PATCHv10 */26] Integration of videobuf2 
with DMABUF
2. Execute 'make headers_install' in kernel source
3. arm-linux-gnueabi-gcc v4l-dbuf.c -o v4l-dbuf -O2 -std=gnu99 -I 
kernel/usr/include/

This app creates a simple pipeline between VIVI and two FIMC instances.
The scenario goes as follows:

1. FIMC0 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc)
2. The buffer from 1. is exported using VIDIOC_EXPBUF. (testing exporting in 
vb2-dma-config)
3. The DMABUF from 2. is imported to VIVI at CAPTURE queue. (testing importing 
in vb2-vmalloc)
4. Single frame is grabbed from VIVI into the DMABUF. (testing 
vb2_dc_dmabuf_ops_vmap)
5. FIMC1 creates an MMAP buffer at its OUTPUT queue. (testing vb2_dc_alloc)
6. he buffer from 5. is exported using VIDIOC_EXPBUF. (testing exporting in 
vb2-dma-config)
7. The DMABUF from 6. is imported by FIMC0 at CAPTURE queue. (testing importing 
in vb2-dma-contig)
8. FIMC0 is used to process a frame (format conversion/scaling/rotation).
9. USERPTR is created from an anonymous or file mapping.
10. The USERPTR from 9. is passed to FIMC1 at CAPTURE queue. (testing 
vb2_dc_get_userptr)
11. FIMC1 is used to process a frame (format conversion/scaling/rotation).

In the result, the USERPTR contains a frame from VIVI processed by
two FIMCs. The app should produce 'Test passed' text on finish.

The command line options allow to control the stages of the process

-v pathpath to vivi [default /dev/video0]
-f pathpath to fimc0 [default /dev/video1]
-F pathpath to fimc1 [default /dev/video3]
-0 4cc@WxH format between VIVI and FIMC0
-1 4cc@WxH format between FIMC0 and FIMC1
-2 4cc@WxH format between FIMC1 and destination
-V vertical flip on FIMC0
-H horizontal flip on FIMC0
-R angle   rotation by angle [default 0] on FIMC0
-m size[@file[+offset]]  destination mapping,
 size 0 is adjusted automatically,
 no file indicate anonymous mapping
-h print this help

For example:
v4l-dbuf -0 RGBP@320x200 -H -R 90 -1 RGB4@96x96 -2 YUYV@32x32 -m 0@/dev/fb0

does:

- grab frame from VIVI 320x200 in RGBP (RGB565) format
- convert this frame to 96x96 RGB4 (RGB32) format using FIMC0,
  apply horizontal flip and 90 degree rotation
- convert result frame to 32x32 YUYV format using FIMC1
- store result in a framebuffer at /dev/fb0

Please, notice if destination file is missing, then anonymous mapping
is used. On platforms that support no SYSMMU for FIMC it is very likely
that VIDIOC_QBUF will fail if the size of the result image is larger
than a single page.

Please use -v, -f, -F options to setup proper paths to VIVI, FIMC0-M2M,
and FIMC1-M2M nodes.

At each stage the result frames are dumped in PPM format (Netpbm format).
Currently, dumping is supported only for RGB565, RGB32 and YUYV formats.
The app is not aborted if a format is not supported.

Please let us know if you have any further questions.

Regards,
Tomasz Stanislawski
/*
 * V4L2 VIVI + FIMC + DMABUF sharing Test Application
 *
 * This application is used to test DMABUF sharing between VIVI and FIMC
 * device.
 *
 * Authors:
 *	Tomasz Stanislawski t.stanisl...@samsung.com
 *
 * Date:
 *  08.10.2012
 *
 */

#include errno.h
#include fcntl.h
#include limits.h
#include signal.h
#include stdarg.h
#include stdbool.h
#include stdint.h
#include stdio.h
#include stdlib.h
#include string.h
#include sys/ioctl.h
#include sys/mman.h
#include sys/stat.h
#include sys/time.h
#include sys/types.h
#include sys/wait.h
#include time.h
#include unistd.h

#include linux/videodev2.h

#define ARRAY_SIZE(tab) \
	(sizeof(tab) / sizeof(*tab))

#define CLEAR(s) memset(s, 0, sizeof(s))

#define MIN(x,y) ((x)  (y) ? (x) : (y))
#define MAX(x,y) ((x)  (y) ? (x) : (y))
#define CLAMP(x,l,h) ((x)  (l) ? (l) : ((x)  (h) ? (h) : (x)))

static inline int __info(const char *prefix, const char *file, int line,
	const char *fmt, ...)
{
	int errsv = errno;
	va_list va;

	va_start(va, fmt);
	fprintf(stderr, %s(%s:%d): , prefix, file, line);
	vfprintf(stderr, fmt, va);
	va_end(va);
	errno = errsv;

	return 1;
}

#define ERRSTR strerror(errno)

#define LOG(...) fprintf(stderr, __VA_ARGS__)

#define ERR(...) __info(Error, __FILE__, __LINE__, __VA_ARGS__)
#define ERR_ON(cond, ...) ((cond) ? ERR(__VA_ARGS__) : 0)

#define CRIT(...) \
	do { \
		__info(Critical, __FILE__, __LINE__, __VA_ARGS__); \
		exit(EXIT_FAILURE); \
	} while(0)
#define CRIT_ON(cond, ...) do { if (cond) CRIT(__VA_ARGS__); } while(0)

struct format {
	unsigned long fourcc;
	unsigned long width;
	unsigned long height

Re: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf

2012-10-08 Thread Tomasz Stanislawski

Hi Hans,

On 10/07/2012 04:17 PM, Hans Verkuil wrote:
 On Sun October 7 2012 15:38:30 Laurent Pinchart wrote:
 Hi Hans,

 On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
 On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer as
 file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
 offset used by mmap and return a file descriptor on success.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com

 [snip]

 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index e04a73e..f429b6a 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -688,6 +688,33 @@ struct v4l2_buffer {

  #define V4L2_BUF_FLAG_NO_CACHE_INVALIDATE 0x0800
  #define V4L2_BUF_FLAG_NO_CACHE_CLEAN  0x1000

 +/**
 + * struct v4l2_exportbuffer - export of video buffer as DMABUF file
 descriptor + *
 + * @fd:   file descriptor associated with DMABUF (set by driver)
 + * @flags:flags for newly created file, currently only O_CLOEXEC 
 is
 + *supported, refer to manual of open syscall for more 
 details
 + * @index:id number of the buffer
 + * @type: enum v4l2_buf_type; buffer type (type == *_MPLANE for
 + *multiplanar buffers);
 + * @plane:index of the plane to be exported, 0 for single plane 
 queues
 + *
 + * Contains data used for exporting a video buffer as DMABUF file
 descriptor. + * The buffer is identified by a 'cookie' returned by
 VIDIOC_QUERYBUF + * (identical to the cookie used to mmap() the buffer to
 userspace). All + * reserved fields must be set to zero. The field
 reserved0 is expected to + * become a structure 'type' allowing an
 alternative layout of the structure + * content. Therefore this field
 should not be used for any other extensions. + */
 +struct v4l2_exportbuffer {
 +  __s32   fd;
 +  __u32   flags;
 +  __u32   type; /* enum v4l2_buf_type */
 +  __u32   index;
 +  __u32   plane;

 As suggested in my comments in the previous patch, I think it is a more
 natural order to have the type/index/plane fields first in this struct.

 Actually, I think that flags should also come before fd:

 struct v4l2_exportbuffer {
 __u32   type; /* enum v4l2_buf_type */
 __u32   index;
 __u32   plane;
 __u32   flags;
 __s32   fd;
 __u32   reserved[11];
 };

 It would indeed feel more natural, but putting them right before the 
 reserved 
 fields allows creating an anonymous union around type, index and plane and 
 extending it with reserved fields if needed. That's (at least to my 
 understanding) the rationale behind the current structure layout.
 
 The anonymous union argument makes no sense to me, to be honest.

I agree that the anonymous unions are not good solutions because they are not
supported in many C dialects. However I have nothing against using named unions.

 It's standard practice within V4L2 to have the IN fields first, then the OUT 
 fields, followed
 by reserved fields for future expansion.

IMO, the input/output/reserved rule is only a recommendation.
The are places in V4L2 where this rule is violated with structure
v4l2_buffer being the most notable example.

Notice that if at least one of the reserved fields becomes an input
file then the rule will be violated anyway.

 Should we ever need a, say, sub-plane
 index (whatever that might be), then we can use one of the reserved fields.

Maybe not subplane :).
But maybe some data_offset for exporting only a part of the buffer will
be needed some day.
Moreover, the integration of DMABUF with the DMA synchronization framework
may involve passing additional parameters from the userspace.

Notice that flags and fd fields are not logically connected with
(type/index/plane) tuple.
Therefore both field sets should be separated by some reserved fields to
ensure that any of them can be extended if needed.

This was the rationale for the structure layout in v9.

Regards,
Tomasz Stanislawski

 Regards,
 
   Hans
 

 +  __u32   reserved[11];
 +};
 +

  /*
  
   *O V E R L A Y   P R E V I E W
   */


 

--
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: [PATCHv9 18/25] v4l: add buffer exporting via dmabuf

2012-10-08 Thread Tomasz Stanislawski

Hi Hans,

On 10/08/2012 11:54 AM, Hans Verkuil wrote:
 On Mon October 8 2012 11:40:37 Tomasz Stanislawski wrote:
 Hi Hans,

 On 10/07/2012 04:17 PM, Hans Verkuil wrote:
 On Sun October 7 2012 15:38:30 Laurent Pinchart wrote:
 Hi Hans,

 On Friday 05 October 2012 10:55:40 Hans Verkuil wrote:
 On Tue October 2 2012 16:27:29 Tomasz Stanislawski wrote:
 This patch adds extension to V4L2 api. It allow to export a mmap buffer 
 as
 file descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer
 offset used by mmap and return a file descriptor on success.

 Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
[snip]
 +struct v4l2_exportbuffer {
 +__s32   fd;
 +__u32   flags;
 +__u32   type; /* enum v4l2_buf_type */
 +__u32   index;
 +__u32   plane;

 As suggested in my comments in the previous patch, I think it is a more
 natural order to have the type/index/plane fields first in this struct.

 Actually, I think that flags should also come before fd:

 struct v4l2_exportbuffer {
   __u32   type; /* enum v4l2_buf_type */
   __u32   index;
   __u32   plane;
   __u32   flags;
   __s32   fd;
   __u32   reserved[11];
 };

 It would indeed feel more natural, but putting them right before the 
 reserved 
 fields allows creating an anonymous union around type, index and plane and 
 extending it with reserved fields if needed. That's (at least to my 
 understanding) the rationale behind the current structure layout.

 The anonymous union argument makes no sense to me, to be honest.

 I agree that the anonymous unions are not good solutions because they are not
 supported in many C dialects. However I have nothing against using named 
 unions.
 
 Named or unnamed, I don't see how a union will help. What do you want to do
 with a union?
 

Currently, there exist three sane layouts of the structure, that use
only one reserved field:

A)
struct v4l2_exportbuffer {
__s32   fd;
__u32   flags;
__u32   type; /* enum v4l2_buf_type */
__u32   index;
__u32   plane;
__u32   reserved[11];
}

B)
struct v4l2_exportbuffer {
__u32   type; /* enum v4l2_buf_type */
__u32   index;
__u32   plane;
__u32   flags;
__s32   fd;
__u32   reserved[11];
}

C)
struct v4l2_exportbuffer {
__u32   type; /* enum v4l2_buf_type */
__u32   index;
__u32   plane;
__u32   reserved[11];
__u32   flags;
__s32   fd;
}

Only the layout B follows 'input/output/reserved' rule.

The layouts A and C allows to extend (type/index/plane) tuple without mixing
it with (flags,fd).

For layouts A and C it is possible to use unions to provide new
means of describing a buffer to be exported.

struct v4l2_exportbuffer {
__s32   fd;
__u32   flags;
union {
struct by_tip { /* type, index, plane */
__u32   type; /* enum v4l2_buf_type */
__u32   index;
__u32   plane;
} by_tip;
struct by_userptr {
u64 userptr;
u64 length;
} by_userptr;
__u32   reserved[6];
} b;
__u32   union_type; /* BY_TIP or BY_USERPTR */
__u32   reserved[4];
};

No such an extension can be applied for layout B.

The similar scheme can be used for layout C. Moreover it support
extensions and variants for (flags/fd) tuple. It might be
useful if one day we would like to export a buffer as something
different from DMABUF file descriptors.

Anyway, we have to choose between the elegance of the layout
and the extensibility.

I think that layout A is a good trade-off.
We could swap fd and flags to get little closer to the rule.


 It's standard practice within V4L2 to have the IN fields first, then the 
 OUT fields, followed
 by reserved fields for future expansion.

 IMO, the input/output/reserved rule is only a recommendation.
 The are places in V4L2 where this rule is violated with structure
 v4l2_buffer being the most notable example.

 Notice that if at least one of the reserved fields becomes an input
 file then the rule will be violated anyway.
 
 Sure, but there is no legacy yet, so why not keep to the recommendation?
 
 Should we ever need a, say, sub-plane
 index (whatever that might be), then we can use one of the reserved fields.

 Maybe not subplane :).
 But maybe some data_offset for exporting only a part of the buffer will
 be needed some day.
 Moreover, the integration of DMABUF with the DMA synchronization framework
 may involve passing

[GIT PULL FOR v3.7] media: s5p-hdmi: add HPD GPIO to platform data

2012-10-05 Thread Tomasz Stanislawski

Hi Mauro,
This patch is a part of [PATCH v1 00/14] drm: exynos: hdmi: add dt based 
support for exynos5 hdmi
patchset. The patchset refers to DRM tree (exynos-drm-next to be more exact).
However the patch 'media: s5p-hdmi: add HPD GPIO to platform data' belong to 
the media tree.

Regards,
Tomasz Stanislawski

The following changes since commit 2425bb3d4016ed95ce83a90b53bd92c7f31091e4:

  em28xx: regression fix: use DRX-K sync firmware requests on em28xx 
(2012-10-02 17:15:22 -0300)

are available in the git repository at:

  git://git.infradead.org/users/kmpark/linux-samsung v4l-s5p-tv-for3.7

for you to fetch changes up to b26bab928dd6f6e1d5613b68fa6fea1d29c9005e:

  media: s5p-hdmi: add HPD GPIO to platform data (2012-10-05 14:53:05 +0200)


Tomasz Stanislawski (1):
  media: s5p-hdmi: add HPD GPIO to platform data

 include/media/s5p_hdmi.h |2 ++
 1 file changed, 2 insertions(+)

--
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

[PATCHv9 00/25] Integration of videobuf2 with DMABUF

 MEMORY_DMABUF
  v4l: vb2-dma-contig: add support for dma_buf importing

Tomasz Stanislawski (15):
  Documentation: media: description of DMABUF importing in V4L2
  v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer
  v4l: vb2-dma-contig: add support for scatterlist in userptr mode
  v4l: vb2-vmalloc: add support for dmabuf importing
  v4l: vivi: support for dmabuf importing
  v4l: s5p-tv: mixer: support for dmabuf importing
  v4l: s5p-fimc: support for dmabuf importing
  Documentation: media: description of DMABUF exporting in V4L2
  v4l: add buffer exporting via dmabuf
  v4l: vb2: add buffer exporting via dmabuf
  v4l: vb2-dma-contig: add support for DMABUF exporting
  v4l: vb2-dma-contig: add reference counting for a device from
allocator context
  v4l: s5p-fimc: support for dmabuf exporting
  v4l: s5p-tv: mixer: support for dmabuf exporting
  v4l: s5p-mfc: support for dmabuf exporting

 Documentation/DocBook/media/v4l/compat.xml |7 +
 Documentation/DocBook/media/v4l/io.xml |  183 +-
 Documentation/DocBook/media/v4l/v4l2.xml   |1 +
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
 Documentation/DocBook/media/v4l/vidioc-expbuf.xml  |  212 ++
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 +
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 +-
 drivers/media/video/Kconfig|2 +
 drivers/media/video/s5p-fimc/fimc-capture.c|   11 +-
 drivers/media/video/s5p-mfc/s5p_mfc_dec.c  |   14 +
 drivers/media/video/s5p-mfc/s5p_mfc_enc.c  |   14 +
 drivers/media/video/s5p-tv/mixer_video.c   |   12 +-
 drivers/media/video/v4l2-compat-ioctl32.c  |   19 +
 drivers/media/video/v4l2-dev.c |1 +
 drivers/media/video/v4l2-ioctl.c   |   11 +
 drivers/media/video/videobuf-core.c|4 +
 drivers/media/video/videobuf2-core.c   |  300 -
 drivers/media/video/videobuf2-dma-contig.c |  695 ++--
 drivers/media/video/videobuf2-memops.c |   40 --
 drivers/media/video/videobuf2-vmalloc.c|   56 ++
 drivers/media/video/vivi.c |2 +-
 include/linux/videodev2.h  |   35 +
 include/media/v4l2-ioctl.h |2 +
 include/media/videobuf2-core.h |   38 ++
 include/media/videobuf2-memops.h   |5 -
 25 files changed, 1608 insertions(+), 136 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/vidioc-expbuf.xml

-- 
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

[PATCHv9 01/25] v4l: Add DMABUF as a memory type

From: Sumit Semwal sumit.sem...@ti.com

Adds DMABUF memory type to v4l framework. Also adds the related file
descriptor in v4l2_plane and v4l2_buffer.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/v4l2-compat-ioctl32.c |   18 ++
 drivers/media/video/v4l2-ioctl.c  |1 +
 include/linux/videodev2.h |7 +++
 3 files changed, 26 insertions(+)

diff --git a/drivers/media/video/v4l2-compat-ioctl32.c 
b/drivers/media/video/v4l2-compat-ioctl32.c
index 9ebd5c5..f0b5aba 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -304,6 +304,7 @@ struct v4l2_plane32 {
union {
__u32   mem_offset;
compat_long_t   userptr;
+   __s32   fd;
} m;
__u32   data_offset;
__u32   reserved[11];
@@ -325,6 +326,7 @@ struct v4l2_buffer32 {
__u32   offset;
compat_long_t   userptr;
compat_caddr_t  planes;
+   __s32   fd;
} m;
__u32   length;
__u32   reserved2;
@@ -348,6 +350,9 @@ static int get_v4l2_plane32(struct v4l2_plane *up, struct 
v4l2_plane32 *up32,
up_pln = compat_ptr(p);
if (put_user((unsigned long)up_pln, up-m.userptr))
return -EFAULT;
+   } else if (memory == V4L2_MEMORY_DMABUF) {
+   if (copy_in_user(up-m.fd, up32-m.fd, sizeof(int)))
+   return -EFAULT;
} else {
if (copy_in_user(up-m.mem_offset, up32-m.mem_offset,
sizeof(__u32)))
@@ -371,6 +376,11 @@ static int put_v4l2_plane32(struct v4l2_plane *up, struct 
v4l2_plane32 *up32,
if (copy_in_user(up32-m.mem_offset, up-m.mem_offset,
sizeof(__u32)))
return -EFAULT;
+   /* For DMABUF, driver might've set up the fd, so copy it back. */
+   if (memory == V4L2_MEMORY_DMABUF)
+   if (copy_in_user(up32-m.fd, up-m.fd,
+   sizeof(int)))
+   return -EFAULT;
 
return 0;
 }
@@ -453,6 +463,10 @@ static int get_v4l2_buffer32(struct v4l2_buffer *kp, 
struct v4l2_buffer32 __user
if (get_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+   case V4L2_MEMORY_DMABUF:
+   if (get_user(kp-m.fd, up-m.fd))
+   return -EFAULT;
+   break;
}
}
 
@@ -517,6 +531,10 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp, 
struct v4l2_buffer32 __user
if (put_user(kp-m.offset, up-m.offset))
return -EFAULT;
break;
+   case V4L2_MEMORY_DMABUF:
+   if (put_user(kp-m.fd, up-m.fd))
+   return -EFAULT;
+   break;
}
}
 
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index 6bc47fc..dffd3c9 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -155,6 +155,7 @@ static const char *v4l2_memory_names[] = {
[V4L2_MEMORY_MMAP]= mmap,
[V4L2_MEMORY_USERPTR] = userptr,
[V4L2_MEMORY_OVERLAY] = overlay,
+   [V4L2_MEMORY_DMABUF] = dmabuf,
 };
 
 #define prt_names(a, arr) a) = 0)  ((a)  ARRAY_SIZE(arr))) ? \
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 7a147c8..e04a73e 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -186,6 +186,7 @@ enum v4l2_memory {
V4L2_MEMORY_MMAP = 1,
V4L2_MEMORY_USERPTR  = 2,
V4L2_MEMORY_OVERLAY  = 3,
+   V4L2_MEMORY_DMABUF   = 4,
 };
 
 /* see also http://vektor.theorem.ca/graphics/ycbcr/ */
@@ -596,6 +597,8 @@ struct v4l2_requestbuffers {
  * should be passed to mmap() called on the video node)
  * @userptr:   when memory is V4L2_MEMORY_USERPTR, a userspace pointer
  * pointing to this plane
+ * @fd:when memory is V4L2_MEMORY_DMABUF, a userspace 
file
+ * descriptor associated with this plane
  * @data_offset:   offset in the plane to the start of data; usually 0,
  * unless there is a header in front of the data
  *
@@ -610,6 +613,7 @@ struct v4l2_plane {
union {
__u32

[PATCHv9 02/25] Documentation: media: description of DMABUF importing in V4L2

This patch adds description and usage examples for importing
DMABUF file descriptor in V4L2.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: linux-...@vger.kernel.org
---
 Documentation/DocBook/media/v4l/compat.xml |4 +
 Documentation/DocBook/media/v4l/io.xml |  180 +++-
 .../DocBook/media/v4l/vidioc-create-bufs.xml   |   16 +-
 Documentation/DocBook/media/v4l/vidioc-qbuf.xml|   17 ++
 Documentation/DocBook/media/v4l/vidioc-reqbufs.xml |   47 ++---
 5 files changed, 234 insertions(+), 30 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index faa0fd1..a46f95b 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2621,6 +2621,10 @@ ioctls./para
 listitem
  paraSupport for frequency band enumeration: 
VIDIOC-ENUM-FREQ-BANDS; ioctl./para
 /listitem
+listitem
+ paraImporting DMABUF file descriptors as a new IO method described
+ in xref linkend=dmabuf /./para
+/listitem
   /itemizedlist
 /section
 
diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 1885cc0..5b58657 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By 
default
 outgoing queue. When the constantO_NONBLOCK/constant flag was
 given to the func-open; function, constantVIDIOC_DQBUF/constant
 returns immediately with an EAGAIN; when no buffer is available. The
-func-select; or func-poll; function are always available./para
+func-select; or func-poll; functions are always available./para
 
 paraTo start and stop capturing or output applications call the
 VIDIOC-STREAMON; and VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,161 @@ rest should be evident./para
   /footnote/para
   /section
 
+  section id=dmabuf
+titleStreaming I/O (DMA buffer importing)/title
+
+note
+  titleExperimental/title
+  paraThis is an link linkend=experimental experimental /link
+  interface and may change in the future./para
+/note
+
+paraThe DMABUF framework provides a generic method for sharing buffers
+between multiple devices. Device drivers that support DMABUF can export a DMA
+buffer to userspace as a file descriptor (known as the exporter role), import a
+DMA buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2./para
+
+paraInput and output devices support the streaming I/O method when the
+constantV4L2_CAP_STREAMING/constant flag in the
+structfieldcapabilities/structfield field of v4l2-capability; returned by
+the VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+VIDIOC-REQBUFS; ioctl with the memory type set to
+constantV4L2_MEMORY_DMABUF/constant./para
+
+paraThis I/O method is dedicated for sharing DMA buffers between V4L and
+other APIs.  Buffers (planes) are allocated by a driver on behalf of an
+application. Next, these buffers are exported to the application as file
+descriptors using an API which is specific for an allocator driver.  Only such
+file descriptor are exchanged. The descriptors and meta-information are passed
+in v4l2-buffer; (or in v4l2-plane; in the multi-planar API case).  The driver
+must be switched into DMABUF I/O mode by calling the VIDIOC-REQBUFS; with the
+desired buffer type./para
+
+example
+  titleInitiating streaming I/O with DMABUF file descriptors/title
+
+  programlisting
+v4l2-requestbuffers; reqbuf;
+
+memset (amp;reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+reqbuf.count = 1;
+
+if (ioctl (fd, VIDIOC-REQBUFS;, amp;reqbuf) == -1) {
+   if (errno == EINVAL)
+   printf(Video capturing or DMABUF streaming is not 
supported\n);
+   else
+   perror(VIDIOC_REQBUFS);
+
+   exit(EXIT_FAILURE);
+}
+  /programlisting
+/example
+
+paraThe buffer (plane) file descriptor is passed on the fly with the
+VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
+associated with a different DMABUF descriptor. Although buffers are commonly
+cycled, applications can pass a different DMABUF descriptor at each
+constantVIDIOC_QBUF/constant call./para
+
+example
+  titleQueueing DMABUF using single plane API/title
+
+  programlisting
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+   v4l2-buffer; buf;
+
+   memset(amp;buf, 0, sizeof buf);
+   buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+   buf.memory = V4L2_MEMORY_DMABUF;
+   buf.index = index

[PATCHv9 03/25] v4l: vb2: add support for shared buffer (dma_buf)

From: Sumit Semwal sumit.sem...@ti.com

This patch adds support for DMABUF memory type in videobuf2. It calls relevant
APIs of dma_buf for v4l reqbuf / qbuf / dqbuf operations.

For this version, the support is for videobuf2 as a user of the shared buffer;
so the allocation of the buffer is done outside of V4L2. [A sample allocator of
dma-buf shared buffer is given at [1]]

[1]: Rob Clark's DRM:
   https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
   [original work in the PoC for buffer sharing]
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/Kconfig  |1 +
 drivers/media/video/videobuf2-core.c |  207 +-
 include/media/videobuf2-core.h   |   27 +
 3 files changed, 232 insertions(+), 3 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c128fac..c558d37 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -45,6 +45,7 @@ config V4L2_MEM2MEM_DEV
depends on VIDEOBUF2_CORE
 
 config VIDEOBUF2_CORE
+   select DMA_SHARED_BUFFER
tristate
 
 config VIDEOBUF2_MEMOPS
diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 268c7dd..901bc56 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -109,6 +109,36 @@ static void __vb2_buf_userptr_put(struct vb2_buffer *vb)
 }
 
 /**
+ * __vb2_plane_dmabuf_put() - release memory associated with
+ * a DMABUF shared plane
+ */
+static void __vb2_plane_dmabuf_put(struct vb2_queue *q, struct vb2_plane *p)
+{
+   if (!p-mem_priv)
+   return;
+
+   if (p-dbuf_mapped)
+   call_memop(q, unmap_dmabuf, p-mem_priv);
+
+   call_memop(q, detach_dmabuf, p-mem_priv);
+   dma_buf_put(p-dbuf);
+   memset(p, 0, sizeof(*p));
+}
+
+/**
+ * __vb2_buf_dmabuf_put() - release memory associated with
+ * a DMABUF shared buffer
+ */
+static void __vb2_buf_dmabuf_put(struct vb2_buffer *vb)
+{
+   struct vb2_queue *q = vb-vb2_queue;
+   unsigned int plane;
+
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   __vb2_plane_dmabuf_put(q, vb-planes[plane]);
+}
+
+/**
  * __setup_offsets() - setup unique offsets (cookies) for every plane in
  * every buffer on the queue
  */
@@ -230,6 +260,8 @@ static void __vb2_free_mem(struct vb2_queue *q, unsigned 
int buffers)
/* Free MMAP buffers or release USERPTR buffers */
if (q-memory == V4L2_MEMORY_MMAP)
__vb2_buf_mem_free(vb);
+   else if (q-memory == V4L2_MEMORY_DMABUF)
+   __vb2_buf_dmabuf_put(vb);
else
__vb2_buf_userptr_put(vb);
}
@@ -363,6 +395,8 @@ static int __fill_v4l2_buffer(struct vb2_buffer *vb, struct 
v4l2_buffer *b)
b-m.offset = vb-v4l2_planes[0].m.mem_offset;
else if (q-memory == V4L2_MEMORY_USERPTR)
b-m.userptr = vb-v4l2_planes[0].m.userptr;
+   else if (q-memory == V4L2_MEMORY_DMABUF)
+   b-m.fd = vb-v4l2_planes[0].m.fd;
}
 
/*
@@ -454,13 +488,28 @@ static int __verify_mmap_ops(struct vb2_queue *q)
 }
 
 /**
+ * __verify_dmabuf_ops() - verify that all memory operations required for
+ * DMABUF queue type have been provided
+ */
+static int __verify_dmabuf_ops(struct vb2_queue *q)
+{
+   if (!(q-io_modes  VB2_DMABUF) || !q-mem_ops-attach_dmabuf ||
+   !q-mem_ops-detach_dmabuf  || !q-mem_ops-map_dmabuf ||
+   !q-mem_ops-unmap_dmabuf)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
  * __verify_memory_type() - Check whether the memory type and buffer type
  * passed to a buffer operation are compatible with the queue.
  */
 static int __verify_memory_type(struct vb2_queue *q,
enum v4l2_memory memory, enum v4l2_buf_type type)
 {
-   if (memory != V4L2_MEMORY_MMAP  memory != V4L2_MEMORY_USERPTR) {
+   if (memory != V4L2_MEMORY_MMAP  memory != V4L2_MEMORY_USERPTR 
+   memory != V4L2_MEMORY_DMABUF) {
dprintk(1, reqbufs: unsupported memory type\n);
return -EINVAL;
}
@@ -484,6 +533,11 @@ static int __verify_memory_type(struct vb2_queue *q,
return -EINVAL;
}
 
+   if (memory == V4L2_MEMORY_DMABUF  __verify_dmabuf_ops(q)) {
+   dprintk(1, reqbufs: DMABUF for current setup unsupported\n);
+   return -EINVAL;
+   }
+
/*
 * Place the busy tests at the end: -EBUSY can be ignored when
 * create_bufs is called with count == 0, but count == 0 should still
@@ -853,6 +907,16 @@ static int __fill_vb2_buffer(struct vb2_buffer *vb, const 
struct

[PATCHv9 04/25] v4l: vb: remove warnings about MEMORY_DMABUF

From: Sumit Semwal sumit.sem...@ti.com

Adding DMABUF memory type causes videobuf to complain about not using it
in some switch cases. This patch removes these warnings.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf-core.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/video/videobuf-core.c 
b/drivers/media/video/videobuf-core.c
index bf7a326..5449e8a 100644
--- a/drivers/media/video/videobuf-core.c
+++ b/drivers/media/video/videobuf-core.c
@@ -335,6 +335,9 @@ static void videobuf_status(struct videobuf_queue *q, 
struct v4l2_buffer *b,
case V4L2_MEMORY_OVERLAY:
b-m.offset  = vb-boff;
break;
+   case V4L2_MEMORY_DMABUF:
+   /* DMABUF is not handled in videobuf framework */
+   break;
}
 
b-flags= 0;
@@ -405,6 +408,7 @@ int __videobuf_mmap_setup(struct videobuf_queue *q,
break;
case V4L2_MEMORY_USERPTR:
case V4L2_MEMORY_OVERLAY:
+   case V4L2_MEMORY_DMABUF:
/* nothing */
break;
}
-- 
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

[PATCHv9 05/25] v4l: vb2-dma-contig: shorten vb2_dma_contig prefix to vb2_dc

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-dma-contig.c |   36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 4b71326..a05784f 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -32,9 +32,9 @@ struct vb2_dc_buf {
struct vb2_vmarea_handler   handler;
 };
 
-static void vb2_dma_contig_put(void *buf_priv);
+static void vb2_dc_put(void *buf_priv);
 
-static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned long size)
+static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
struct vb2_dc_buf *buf;
@@ -56,7 +56,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
buf-size = size;
 
buf-handler.refcount = buf-refcount;
-   buf-handler.put = vb2_dma_contig_put;
+   buf-handler.put = vb2_dc_put;
buf-handler.arg = buf;
 
atomic_inc(buf-refcount);
@@ -64,7 +64,7 @@ static void *vb2_dma_contig_alloc(void *alloc_ctx, unsigned 
long size)
return buf;
 }
 
-static void vb2_dma_contig_put(void *buf_priv)
+static void vb2_dc_put(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
@@ -75,14 +75,14 @@ static void vb2_dma_contig_put(void *buf_priv)
}
 }
 
-static void *vb2_dma_contig_cookie(void *buf_priv)
+static void *vb2_dc_cookie(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
return buf-dma_addr;
 }
 
-static void *vb2_dma_contig_vaddr(void *buf_priv)
+static void *vb2_dc_vaddr(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
if (!buf)
@@ -91,14 +91,14 @@ static void *vb2_dma_contig_vaddr(void *buf_priv)
return buf-vaddr;
 }
 
-static unsigned int vb2_dma_contig_num_users(void *buf_priv)
+static unsigned int vb2_dc_num_users(void *buf_priv)
 {
struct vb2_dc_buf *buf = buf_priv;
 
return atomic_read(buf-refcount);
 }
 
-static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma)
+static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
 
@@ -111,7 +111,7 @@ static int vb2_dma_contig_mmap(void *buf_priv, struct 
vm_area_struct *vma)
  vb2_common_vm_ops, buf-handler);
 }
 
-static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr,
+static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
 {
struct vb2_dc_buf *buf;
@@ -138,7 +138,7 @@ static void *vb2_dma_contig_get_userptr(void *alloc_ctx, 
unsigned long vaddr,
return buf;
 }
 
-static void vb2_dma_contig_put_userptr(void *mem_priv)
+static void vb2_dc_put_userptr(void *mem_priv)
 {
struct vb2_dc_buf *buf = mem_priv;
 
@@ -150,14 +150,14 @@ static void vb2_dma_contig_put_userptr(void *mem_priv)
 }
 
 const struct vb2_mem_ops vb2_dma_contig_memops = {
-   .alloc  = vb2_dma_contig_alloc,
-   .put= vb2_dma_contig_put,
-   .cookie = vb2_dma_contig_cookie,
-   .vaddr  = vb2_dma_contig_vaddr,
-   .mmap   = vb2_dma_contig_mmap,
-   .get_userptr= vb2_dma_contig_get_userptr,
-   .put_userptr= vb2_dma_contig_put_userptr,
-   .num_users  = vb2_dma_contig_num_users,
+   .alloc  = vb2_dc_alloc,
+   .put= vb2_dc_put,
+   .cookie = vb2_dc_cookie,
+   .vaddr  = vb2_dc_vaddr,
+   .mmap   = vb2_dc_mmap,
+   .get_userptr= vb2_dc_get_userptr,
+   .put_userptr= vb2_dc_put_userptr,
+   .num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
 
-- 
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

[PATCHv9 06/25] v4l: vb2-dma-contig: remove reference of alloc_ctx from a buffer

This patch removes a reference to alloc_ctx from an instance of a DMA
contiguous buffer. It helps to avoid a risk of a dangling pointer if the
context is released while the buffer is still valid. Moreover it removes one
dereference step while accessing a device structure.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-dma-contig.c |   13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index a05784f..20c95da 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -23,7 +23,7 @@ struct vb2_dc_conf {
 };
 
 struct vb2_dc_buf {
-   struct vb2_dc_conf  *conf;
+   struct device   *dev;
void*vaddr;
dma_addr_t  dma_addr;
unsigned long   size;
@@ -37,22 +37,21 @@ static void vb2_dc_put(void *buf_priv);
 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
struct vb2_dc_conf *conf = alloc_ctx;
+   struct device *dev = conf-dev;
struct vb2_dc_buf *buf;
 
buf = kzalloc(sizeof *buf, GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
 
-   buf-vaddr = dma_alloc_coherent(conf-dev, size, buf-dma_addr,
-   GFP_KERNEL);
+   buf-vaddr = dma_alloc_coherent(dev, size, buf-dma_addr, GFP_KERNEL);
if (!buf-vaddr) {
-   dev_err(conf-dev, dma_alloc_coherent of size %ld failed\n,
-   size);
+   dev_err(dev, dma_alloc_coherent of size %ld failed\n, size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
 
-   buf-conf = conf;
+   buf-dev = dev;
buf-size = size;
 
buf-handler.refcount = buf-refcount;
@@ -69,7 +68,7 @@ static void vb2_dc_put(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
 
if (atomic_dec_and_test(buf-refcount)) {
-   dma_free_coherent(buf-conf-dev, buf-size, buf-vaddr,
+   dma_free_coherent(buf-dev, buf-size, buf-vaddr,
  buf-dma_addr);
kfree(buf);
}
-- 
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

[PATCHv9 07/25] v4l: vb2-dma-contig: reorder functions

From: Laurent Pinchart laurent.pinch...@ideasonboard.com

Group functions by buffer type.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-dma-contig.c |   92 
 1 file changed, 54 insertions(+), 38 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 20c95da..daac2b2 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -25,14 +25,56 @@ struct vb2_dc_conf {
 struct vb2_dc_buf {
struct device   *dev;
void*vaddr;
-   dma_addr_t  dma_addr;
unsigned long   size;
-   struct vm_area_struct   *vma;
-   atomic_trefcount;
+   dma_addr_t  dma_addr;
+
+   /* MMAP related */
struct vb2_vmarea_handler   handler;
+   atomic_trefcount;
+
+   /* USERPTR related */
+   struct vm_area_struct   *vma;
 };
 
-static void vb2_dc_put(void *buf_priv);
+/*/
+/* callbacks for all buffers */
+/*/
+
+static void *vb2_dc_cookie(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return buf-dma_addr;
+}
+
+static void *vb2_dc_vaddr(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return buf-vaddr;
+}
+
+static unsigned int vb2_dc_num_users(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   return atomic_read(buf-refcount);
+}
+
+/*/
+/*callbacks for MMAP buffers */
+/*/
+
+static void vb2_dc_put(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+
+   if (!atomic_dec_and_test(buf-refcount))
+   return;
+
+   dma_free_coherent(buf-dev, buf-size, buf-vaddr, buf-dma_addr);
+   kfree(buf);
+}
 
 static void *vb2_dc_alloc(void *alloc_ctx, unsigned long size)
 {
@@ -63,40 +105,6 @@ static void *vb2_dc_alloc(void *alloc_ctx, unsigned long 
size)
return buf;
 }
 
-static void vb2_dc_put(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   if (atomic_dec_and_test(buf-refcount)) {
-   dma_free_coherent(buf-dev, buf-size, buf-vaddr,
- buf-dma_addr);
-   kfree(buf);
-   }
-}
-
-static void *vb2_dc_cookie(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   return buf-dma_addr;
-}
-
-static void *vb2_dc_vaddr(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-   if (!buf)
-   return NULL;
-
-   return buf-vaddr;
-}
-
-static unsigned int vb2_dc_num_users(void *buf_priv)
-{
-   struct vb2_dc_buf *buf = buf_priv;
-
-   return atomic_read(buf-refcount);
-}
-
 static int vb2_dc_mmap(void *buf_priv, struct vm_area_struct *vma)
 {
struct vb2_dc_buf *buf = buf_priv;
@@ -110,6 +118,10 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
  vb2_common_vm_ops, buf-handler);
 }
 
+/*/
+/*   callbacks for USERPTR buffers   */
+/*/
+
 static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
unsigned long size, int write)
 {
@@ -148,6 +160,10 @@ static void vb2_dc_put_userptr(void *mem_priv)
kfree(buf);
 }
 
+/*/
+/*   DMA CONTIG exported functions   */
+/*/
+
 const struct vb2_mem_ops vb2_dma_contig_memops = {
.alloc  = vb2_dc_alloc,
.put= vb2_dc_put,
-- 
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

[PATCHv9 08/25] v4l: vb2-dma-contig: add support for scatterlist in userptr mode

This patch introduces usage of dma_map_sg to map memory behind
a userspace pointer to a device as dma-contiguous mapping.

This patch contains some of the code kindly provided by Marek Szyprowski
m.szyprow...@samsung.com and Kamil Debski k.deb...@samsung.com and Andrzej
Pietrasiewicz andrze...@samsung.com. Kind thanks for bug reports from Laurent
Pinchart laurent.pinch...@ideasonboard.com and Seung-Woo Kim
sw0312@samsung.com.

Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-dma-contig.c |  226 ++--
 1 file changed, 210 insertions(+), 16 deletions(-)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index daac2b2..8486e06 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -11,6 +11,8 @@
  */
 
 #include linux/module.h
+#include linux/scatterlist.h
+#include linux/sched.h
 #include linux/slab.h
 #include linux/dma-mapping.h
 
@@ -27,6 +29,8 @@ struct vb2_dc_buf {
void*vaddr;
unsigned long   size;
dma_addr_t  dma_addr;
+   enum dma_data_direction dma_dir;
+   struct sg_table *dma_sgt;
 
/* MMAP related */
struct vb2_vmarea_handler   handler;
@@ -37,6 +41,44 @@ struct vb2_dc_buf {
 };
 
 /*/
+/*scatterlist table functions*/
+/*/
+
+
+static void vb2_dc_sgt_foreach_page(struct sg_table *sgt,
+   void (*cb)(struct page *pg))
+{
+   struct scatterlist *s;
+   unsigned int i;
+
+   for_each_sg(sgt-sgl, s, sgt-orig_nents, i) {
+   struct page *page = sg_page(s);
+   unsigned int n_pages = PAGE_ALIGN(s-offset + s-length)
+PAGE_SHIFT;
+   unsigned int j;
+
+   for (j = 0; j  n_pages; ++j, ++page)
+   cb(page);
+   }
+}
+
+static unsigned long vb2_dc_get_contiguous_size(struct sg_table *sgt)
+{
+   struct scatterlist *s;
+   dma_addr_t expected = sg_dma_address(sgt-sgl);
+   unsigned int i;
+   unsigned long size = 0;
+
+   for_each_sg(sgt-sgl, s, sgt-nents, i) {
+   if (sg_dma_address(s) != expected)
+   break;
+   expected = sg_dma_address(s) + sg_dma_len(s);
+   size += sg_dma_len(s);
+   }
+   return size;
+}
+
+/*/
 /* callbacks for all buffers */
 /*/
 
@@ -122,42 +164,194 @@ static int vb2_dc_mmap(void *buf_priv, struct 
vm_area_struct *vma)
 /*   callbacks for USERPTR buffers   */
 /*/
 
+static inline int vma_is_io(struct vm_area_struct *vma)
+{
+   return !!(vma-vm_flags  (VM_IO | VM_PFNMAP));
+}
+
+static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
+   int n_pages, struct vm_area_struct *vma, int write)
+{
+   if (vma_is_io(vma)) {
+   unsigned int i;
+
+   for (i = 0; i  n_pages; ++i, start += PAGE_SIZE) {
+   unsigned long pfn;
+   int ret = follow_pfn(vma, start, pfn);
+
+   if (ret) {
+   pr_err(no page for address %lu\n, start);
+   return ret;
+   }
+   pages[i] = pfn_to_page(pfn);
+   }
+   } else {
+   int n;
+
+   n = get_user_pages(current, current-mm, start  PAGE_MASK,
+   n_pages, write, 1, pages, NULL);
+   /* negative error means that no page was pinned */
+   n = max(n, 0);
+   if (n != n_pages) {
+   pr_err(got only %d of %d user pages\n, n, n_pages);
+   while (n)
+   put_page(pages[--n]);
+   return -EFAULT;
+   }
+   }
+
+   return 0;
+}
+
+static void vb2_dc_put_dirty_page(struct page *page)
+{
+   set_page_dirty_lock(page);
+   put_page(page);
+}
+
+static void vb2_dc_put_userptr(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   dma_unmap_sg(buf-dev, sgt-sgl, sgt-orig_nents, buf-dma_dir);
+   if (!vma_is_io(buf-vma))
+   vb2_dc_sgt_foreach_page(sgt, vb2_dc_put_dirty_page);
+
+   sg_free_table(sgt);
+   kfree(sgt);
+   vb2_put_vma(buf-vma);
+   kfree(buf);
+}
+
 static void *vb2_dc_get_userptr(void *alloc_ctx, unsigned long vaddr,
-   unsigned long size

[PATCHv9 09/25] v4l: vb2: add prepare/finish callbacks to allocators

From: Marek Szyprowski m.szyprow...@samsung.com

This patch adds support for prepare/finish callbacks in VB2 allocators. These
callback are used for buffer flushing.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-core.c |   11 +++
 include/media/videobuf2-core.h   |7 +++
 2 files changed, 18 insertions(+)

diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 901bc56..05da3b4 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -844,6 +844,7 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
 {
struct vb2_queue *q = vb-vb2_queue;
unsigned long flags;
+   unsigned int plane;
 
if (vb-state != VB2_BUF_STATE_ACTIVE)
return;
@@ -854,6 +855,10 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum 
vb2_buffer_state state)
dprintk(4, Done processing on buffer %d, state: %d\n,
vb-v4l2_buf.index, vb-state);
 
+   /* sync buffers */
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   call_memop(q, finish, vb-planes[plane].mem_priv);
+
/* Add the buffer to the done buffers list */
spin_lock_irqsave(q-done_lock, flags);
vb-state = state;
@@ -1148,9 +1153,15 @@ err:
 static void __enqueue_in_driver(struct vb2_buffer *vb)
 {
struct vb2_queue *q = vb-vb2_queue;
+   unsigned int plane;
 
vb-state = VB2_BUF_STATE_ACTIVE;
atomic_inc(q-queued_count);
+
+   /* sync buffers */
+   for (plane = 0; plane  vb-num_planes; ++plane)
+   call_memop(q, prepare, vb-planes[plane].mem_priv);
+
q-ops-buf_queue(vb);
 }
 
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 84f11f2..c306fec 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -56,6 +56,10 @@ struct vb2_fileio_data;
  * dmabuf
  * @unmap_dmabuf: releases access control to the dmabuf - allocator is notified
  *   that this driver is done using the dmabuf for now
+ * @prepare:   called everytime the buffer is passed from userspace to the
+ * driver, usefull for cache synchronisation, optional
+ * @finish:called everytime the buffer is passed back from the driver
+ * to the userspace, also optional
  * @vaddr: return a kernel virtual address to a given memory buffer
  * associated with the passed private structure or NULL if no
  * such mapping exists
@@ -82,6 +86,9 @@ struct vb2_mem_ops {
unsigned long size, int write);
void(*put_userptr)(void *buf_priv);
 
+   void(*prepare)(void *buf_priv);
+   void(*finish)(void *buf_priv);
+
void*(*attach_dmabuf)(void *alloc_ctx, struct dma_buf *dbuf,
unsigned long size, int write);
void(*detach_dmabuf)(void *buf_priv);
-- 
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

[PATCHv9 10/25] v4l: vb2-dma-contig: add prepare/finish to dma-contig allocator

From: Marek Szyprowski m.szyprow...@samsung.com

Add prepare/finish callbacks to vb2-dma-contig allocator.

Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/videobuf2-dma-contig.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 8486e06..494a824 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -103,6 +103,28 @@ static unsigned int vb2_dc_num_users(void *buf_priv)
return atomic_read(buf-refcount);
 }
 
+static void vb2_dc_prepare(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
+static void vb2_dc_finish(void *buf_priv)
+{
+   struct vb2_dc_buf *buf = buf_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (!sgt)
+   return;
+
+   dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
+}
+
 /*/
 /*callbacks for MMAP buffers */
 /*/
@@ -366,6 +388,8 @@ const struct vb2_mem_ops vb2_dma_contig_memops = {
.mmap   = vb2_dc_mmap,
.get_userptr= vb2_dc_get_userptr,
.put_userptr= vb2_dc_put_userptr,
+   .prepare= vb2_dc_prepare,
+   .finish = vb2_dc_finish,
.num_users  = vb2_dc_num_users,
 };
 EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
-- 
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

[PATCHv9 11/25] v4l: vb2-dma-contig: add support for dma_buf importing

From: Sumit Semwal sumit.sem...@ti.com

This patch makes changes for adding dma-contig as a dma_buf user. It provides
function implementations for the {attach, detach, map, unmap}_dmabuf()
mem_ops of DMABUF memory type.

Signed-off-by: Sumit Semwal sumit.sem...@ti.com
Signed-off-by: Sumit Semwal sumit.sem...@linaro.org
[author of the original patch]
Signed-off-by: Tomasz Stanislawski t.stanisl...@samsung.com
[integration with refactored dma-contig allocator]
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/media/video/Kconfig|1 +
 drivers/media/video/videobuf2-dma-contig.c |  120 +++-
 2 files changed, 119 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index c558d37..ec089da 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -54,6 +54,7 @@ config VIDEOBUF2_MEMOPS
 config VIDEOBUF2_DMA_CONTIG
select VIDEOBUF2_CORE
select VIDEOBUF2_MEMOPS
+   select DMA_SHARED_BUFFER
tristate
 
 config VIDEOBUF2_VMALLOC
diff --git a/drivers/media/video/videobuf2-dma-contig.c 
b/drivers/media/video/videobuf2-dma-contig.c
index 494a824..a5804cf 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -10,6 +10,7 @@
  * the Free Software Foundation.
  */
 
+#include linux/dma-buf.h
 #include linux/module.h
 #include linux/scatterlist.h
 #include linux/sched.h
@@ -38,6 +39,9 @@ struct vb2_dc_buf {
 
/* USERPTR related */
struct vm_area_struct   *vma;
+
+   /* DMABUF related */
+   struct dma_buf_attachment   *db_attach;
 };
 
 /*/
@@ -108,7 +112,8 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
 
-   if (!sgt)
+   /* DMABUF exporter will flush the cache for us */
+   if (!sgt || buf-db_attach)
return;
 
dma_sync_sg_for_device(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -119,7 +124,8 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf-dma_sgt;
 
-   if (!sgt)
+   /* DMABUF exporter will flush the cache for us */
+   if (!sgt || buf-db_attach)
return;
 
dma_sync_sg_for_cpu(buf-dev, sgt-sgl, sgt-nents, buf-dma_dir);
@@ -377,6 +383,112 @@ fail_buf:
 }
 
 /*/
+/*   callbacks for DMABUF buffers*/
+/*/
+
+static int vb2_dc_map_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct sg_table *sgt;
+   unsigned long contig_size;
+
+   if (WARN_ON(!buf-db_attach)) {
+   pr_err(trying to pin a non attached buffer\n);
+   return -EINVAL;
+   }
+
+   if (WARN_ON(buf-dma_sgt)) {
+   pr_err(dmabuf buffer is already pinned\n);
+   return 0;
+   }
+
+   /* get the associated scatterlist for this buffer */
+   sgt = dma_buf_map_attachment(buf-db_attach, buf-dma_dir);
+   if (IS_ERR_OR_NULL(sgt)) {
+   pr_err(Error getting dmabuf scatterlist\n);
+   return -EINVAL;
+   }
+
+   /* checking if dmabuf is big enough to store contiguous chunk */
+   contig_size = vb2_dc_get_contiguous_size(sgt);
+   if (contig_size  buf-size) {
+   pr_err(contiguous chunk is too small %lu/%lu b\n,
+   contig_size, buf-size);
+   dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+   return -EFAULT;
+   }
+
+   buf-dma_addr = sg_dma_address(sgt-sgl);
+   buf-dma_sgt = sgt;
+
+   return 0;
+}
+
+static void vb2_dc_unmap_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+   struct sg_table *sgt = buf-dma_sgt;
+
+   if (WARN_ON(!buf-db_attach)) {
+   pr_err(trying to unpin a not attached buffer\n);
+   return;
+   }
+
+   if (WARN_ON(!sgt)) {
+   pr_err(dmabuf buffer is already unpinned\n);
+   return;
+   }
+
+   dma_buf_unmap_attachment(buf-db_attach, sgt, buf-dma_dir);
+
+   buf-dma_addr = 0;
+   buf-dma_sgt = NULL;
+}
+
+static void vb2_dc_detach_dmabuf(void *mem_priv)
+{
+   struct vb2_dc_buf *buf = mem_priv;
+
+   /* if vb2 works correctly you should never detach mapped buffer */
+   if (WARN_ON(buf-dma_addr))
+   vb2_dc_unmap_dmabuf(buf);
+
+   /* detach this attachment */
+   dma_buf_detach(buf-db_attach-dmabuf, buf-db_attach);
+   kfree(buf);
+}
+
+static void *vb2_dc_attach_dmabuf(void *alloc_ctx, struct dma_buf *dbuf,
+   unsigned long size, int write)
+{
+   struct vb2_dc_conf *conf = alloc_ctx;
+   struct vb2_dc_buf *buf;
+   struct

[PATCHv9 12/25] v4l: vb2-vmalloc: add support for dmabuf importing