[GIT PULL] Staging driver warning fixes for 4.11-rc2

[Greg KH]

The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:

  Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/ 
tags/staging-4.11-rc2

for you to fetch changes up to 69eb1596b4df8ca834ba6f9a3df40f78943f6dca:

  staging: octeon: remove unused variable (2017-03-08 09:45:07 +0100)


Staging driver fixes for 4.11-rc2

Here are two small build warning fixes for some staging drivers that
Arnd has found on his valiant quest to get the kernel to build properly
with no warnings.  Both of these have been in linux-next this week and
resolve the reported issues.

Signed-off-by: Greg Kroah-Hartman 


Arnd Bergmann (2):
  staging/vc04_services: add CONFIG_OF dependency
  staging: octeon: remove unused variable

 drivers/staging/octeon/ethernet-rx.c  | 1 -
 drivers/staging/vc04_services/Kconfig | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH 1/3] staging: sm750fb: function prototype argument should have an identifier name

[Julia Lawall]

On Sat, 11 Mar 2017, Arushi Singhal wrote:

> function prototype arguments like 'struct vb_device_info *','unsigned
> long' etc. should have an identifier name.
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/sm750fb/ddk750_display.h | 2 +-
>  drivers/staging/sm750fb/ddk750_mode.h| 2 +-
>  drivers/staging/sm750fb/ddk750_power.h   | 2 +-
>  drivers/staging/sm750fb/sm750.h  | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_display.h 
> b/drivers/staging/sm750fb/ddk750_display.h
> index e2a3f84ca4c5..609bf742efff 100644
> --- a/drivers/staging/sm750fb/ddk750_display.h
> +++ b/drivers/staging/sm750fb/ddk750_display.h
> @@ -102,6 +102,6 @@ typedef enum _disp_output_t {
>  }
>  disp_output_t;
>
> -void ddk750_setLogicalDispOut(disp_output_t);
> +void ddk750_setLogicalDispOut(disp_output_t output);
>
>  #endif
> diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
> b/drivers/staging/sm750fb/ddk750_mode.h
> index 2183e664cf4b..6d204b8b4a01 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.h
> +++ b/drivers/staging/sm750fb/ddk750_mode.h
> @@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
>  }
>  mode_parameter_t;
>
> -int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
> +int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);

There are typedefs here that you could get rid of in a future patch.

>
>  #endif
> diff --git a/drivers/staging/sm750fb/ddk750_power.h 
> b/drivers/staging/sm750fb/ddk750_power.h
> index ec0b99d6a7ad..44c4fc587e96 100644
> --- a/drivers/staging/sm750fb/ddk750_power.h
> +++ b/drivers/staging/sm750fb/ddk750_power.h
> @@ -14,7 +14,7 @@ DPMS_t;
>  (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
>  }
>
> -void ddk750_set_dpms(DPMS_t);
> +void ddk750_set_dpms(DPMS_t state);
>  void sm750_set_power_mode(unsigned int powerMode);
>  void sm750_set_current_gate(unsigned int gate);
>
> diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
> index 306711ed55f9..5ea455dee949 100644
> --- a/drivers/staging/sm750fb/sm750.h
> +++ b/drivers/staging/sm750fb/sm750.h
> @@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
>  }
>
>  int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
> -int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
> +int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
>  void hw_sm750_initAccel(struct sm750_dev *);

This prototype should be updated too.

julia

>  int hw_sm750_deWait(void);
>  int hw_sm750le_deWait(void);
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170311032410.8265-2-arushisinghal19971997%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH 3/3] staging: sm750fb: Alignment should match open parenthesis

[Julia Lawall]

On Sat, 11 Mar 2017, Arushi Singhal wrote:

> Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".
>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/sm750fb/ddk750_mode.c | 79 
> +--
>  1 file changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
> b/drivers/staging/sm750fb/ddk750_mode.c
> index 45af806c8d55..eea5aef2956f 100644
> --- a/drivers/staging/sm750fb/ddk750_mode.c
> +++ b/drivers/staging/sm750fb/ddk750_mode.c
> @@ -28,9 +28,9 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>   poke32(CRT_AUTO_CENTERING_TL, 0);
>
>   poke32(CRT_AUTO_CENTERING_BR,
> - (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> - CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> - ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
> +(((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
> + CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
> +((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
>
>   /*
>* Assume common fields in dispControl have been properly set before
> @@ -72,8 +72,7 @@ static unsigned long 
> displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
>  }
>
>  /* only timing related registers will be  programed */
> -static int programModeRegisters(mode_parameter_t *pModeParam,
> - struct pll_value *pll)
> +static int programModeRegisters(mode_parameter_t *pModeParam, struct 
> pll_value *pll)
>  {
>   int ret = 0;
>   int cnt = 0;
> @@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t 
> *pModeParam,
>   /* programe secondary pixel clock */
>   poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
>   poke32(CRT_HORIZONTAL_TOTAL,
> - (((pModeParam->horizontal_total - 1) <<
> - CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> - CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->horizontal_display_end - 1) &
> - CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->horizontal_total - 1) <<
> +  CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
> + CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->horizontal_display_end - 1) &
> + CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));

This code seems quite hard to read.  Maybe you could introduce some new
variables based on the parameter names of poke32, and store the argument
of poke32 in those variables before making the call.  Then you could also
shorten the names of the constants a little, by using HORIZ and VERT
instead of HORIZONTAL and VERTICAL.  That might let eg the shift
operations fit on one line.

To find out the types of the new variables, you would need to look at the
definition of poke32 and see how the variables are used there.
Unfortunately poke32 is a macro, so it doesn't give type information
directly.

julia


>
>   poke32(CRT_HORIZONTAL_SYNC,
> - ((pModeParam->horizontal_sync_width <<
> - CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> - CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> - ((pModeParam->horizontal_sync_start - 1) &
> - CRT_HORIZONTAL_SYNC_START_MASK));
> +((pModeParam->horizontal_sync_width <<
> +  CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
> + CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
> +((pModeParam->horizontal_sync_start - 1) &
> + CRT_HORIZONTAL_SYNC_START_MASK));
>
>   poke32(CRT_VERTICAL_TOTAL,
> - (((pModeParam->vertical_total - 1) <<
> - CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> - CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> - ((pModeParam->vertical_display_end - 1) &
> - CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
> +(((pModeParam->vertical_total - 1) <<
> +  CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
> + CRT_VERTICAL_TOTAL_TOTAL_MASK) |
> +((pModeParam->vertical_display_end - 1) &
> + CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
>
>   poke32(CRT_VERTICAL_SYNC,
> - ((pModeParam->vertical_sync_height <<
> - CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
> - CRT_VERTICAL_SYNC_HEIGHT_MASK) |
> - ((pModeParam->vertical_sync_start - 1) &
> - CRT_VERTICAL_SYNC_START_MASK));
> +((pModeParam->vertical_sync_height <<
> +  

Re: [Outreachy kernel] [PATCH 00/10] staging: iio: Remove exceptional & on functions name

[Julia Lawall]

On Sat, 11 Mar 2017, simran singhal wrote:

> This patch-series removes exceptional & on functions name.

The semantic patch shown does nothing to check that the use of & is
exception in the given file.  It just removes all the & on function names.

julia

>
> simran singhal (10):
>   staging: iio: ad7192: Remove exceptional & on function name
>   staging: iio: ad7780: Remove exceptional & on function name
>   staging: iio: cdc: ad7746: Remove exceptional & on function name
>   staging: iio: cdc: ad7152: Remove exceptional & on function name
>   staging: iio: adis16240: Remove exceptional & on function name
>   staging: iio: adis16201: Remove exceptional & on function name
>   staging: iio: adis16209: Remove exceptional & on function name
>   staging: iio: adis16203: Remove exceptional & on function name
>   staging: iio: resolver: Remove exceptional & on function name
>   staging: iio: gyro: Remove exceptional & on function name
>
>  drivers/staging/iio/accel/adis16201.c |  4 ++--
>  drivers/staging/iio/accel/adis16203.c |  4 ++--
>  drivers/staging/iio/accel/adis16209.c |  4 ++--
>  drivers/staging/iio/accel/adis16240.c |  4 ++--
>  drivers/staging/iio/adc/ad7192.c  | 12 ++--
>  drivers/staging/iio/adc/ad7780.c  |  2 +-
>  drivers/staging/iio/cdc/ad7152.c  |  6 +++---
>  drivers/staging/iio/cdc/ad7746.c  |  4 ++--
>  drivers/staging/iio/gyro/adis16060_core.c |  2 +-
>  drivers/staging/iio/resolver/ad2s1200.c   |  2 +-
>  drivers/staging/iio/resolver/ad2s90.c |  2 +-
>  11 files changed, 23 insertions(+), 23 deletions(-)
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1489203401-17518-1-git-send-email-singhalsimran0%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 10/10] staging: iio: gyro: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/gyro/adis16060_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/gyro/adis16060_core.c 
b/drivers/staging/iio/gyro/adis16060_core.c
index ab816a2..c9d46e7 100644
--- a/drivers/staging/iio/gyro/adis16060_core.c
+++ b/drivers/staging/iio/gyro/adis16060_core.c
@@ -117,7 +117,7 @@ static int adis16060_read_raw(struct iio_dev *indio_dev,
 }
 
 static const struct iio_info adis16060_info = {
-   .read_raw = _read_raw,
+   .read_raw = adis16060_read_raw,
.driver_module = THIS_MODULE,
 };
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 08/10] staging: iio: adis16203: Remove exceptional & on function name

[simran singhal]

In this file, function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/accel/adis16203.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16203.c 
b/drivers/staging/iio/accel/adis16203.c
index 68189ad..b59755a 100644
--- a/drivers/staging/iio/accel/adis16203.c
+++ b/drivers/staging/iio/accel/adis16203.c
@@ -233,8 +233,8 @@ static const struct iio_chan_spec adis16203_channels[] = {
 };
 
 static const struct iio_info adis16203_info = {
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
+   .read_raw = adis16203_read_raw,
+   .write_raw = adis16203_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
 };
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 09/10] staging: iio: resolver: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/resolver/ad2s1200.c | 2 +-
 drivers/staging/iio/resolver/ad2s90.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/resolver/ad2s1200.c 
b/drivers/staging/iio/resolver/ad2s1200.c
index 82b2d88..a37e199 100644
--- a/drivers/staging/iio/resolver/ad2s1200.c
+++ b/drivers/staging/iio/resolver/ad2s1200.c
@@ -97,7 +97,7 @@ static const struct iio_chan_spec ad2s1200_channels[] = {
 };
 
 static const struct iio_info ad2s1200_info = {
-   .read_raw = _read_raw,
+   .read_raw = ad2s1200_read_raw,
.driver_module = THIS_MODULE,
 };
 
diff --git a/drivers/staging/iio/resolver/ad2s90.c 
b/drivers/staging/iio/resolver/ad2s90.c
index 5b1c0db..b227090 100644
--- a/drivers/staging/iio/resolver/ad2s90.c
+++ b/drivers/staging/iio/resolver/ad2s90.c
@@ -47,7 +47,7 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
 }
 
 static const struct iio_info ad2s90_info = {
-   .read_raw = _read_raw,
+   .read_raw = ad2s90_read_raw,
.driver_module = THIS_MODULE,
 };
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 04/10] staging: iio: cdc: ad7152: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/cdc/ad7152.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7152.c b/drivers/staging/iio/cdc/ad7152.c
index e8609b8..59ef93c 100644
--- a/drivers/staging/iio/cdc/ad7152.c
+++ b/drivers/staging/iio/cdc/ad7152.c
@@ -441,9 +441,9 @@ static int ad7152_write_raw_get_fmt(struct iio_dev 
*indio_dev,
 
 static const struct iio_info ad7152_info = {
.attrs = _attribute_group,
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
-   .write_raw_get_fmt = _write_raw_get_fmt,
+   .read_raw = ad7152_read_raw,
+   .write_raw = ad7152_write_raw,
+   .write_raw_get_fmt = ad7152_write_raw_get_fmt,
.driver_module = THIS_MODULE,
 };
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 05/10] staging: iio: adis16240: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/accel/adis16240.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16240.c 
b/drivers/staging/iio/accel/adis16240.c
index 27d7f6a..37a29dc 100644
--- a/drivers/staging/iio/accel/adis16240.c
+++ b/drivers/staging/iio/accel/adis16240.c
@@ -373,8 +373,8 @@ static const struct attribute_group 
adis16240_attribute_group = {
 
 static const struct iio_info adis16240_info = {
.attrs = _attribute_group,
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
+   .read_raw = adis16240_read_raw,
+   .write_raw = adis16240_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
 };
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 06/10] staging: iio: adis16201: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/accel/adis16201.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16201.c 
b/drivers/staging/iio/accel/adis16201.c
index d6c8658..7565268 100644
--- a/drivers/staging/iio/accel/adis16201.c
+++ b/drivers/staging/iio/accel/adis16201.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16201_channels[] = {
 };
 
 static const struct iio_info adis16201_info = {
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
+   .read_raw = adis16201_read_raw,
+   .write_raw = adis16201_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
 };
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 00/10] staging: iio: Remove exceptional & on functions name

[simran singhal]

This patch-series removes exceptional & on functions name.

simran singhal (10):
  staging: iio: ad7192: Remove exceptional & on function name
  staging: iio: ad7780: Remove exceptional & on function name
  staging: iio: cdc: ad7746: Remove exceptional & on function name
  staging: iio: cdc: ad7152: Remove exceptional & on function name
  staging: iio: adis16240: Remove exceptional & on function name
  staging: iio: adis16201: Remove exceptional & on function name
  staging: iio: adis16209: Remove exceptional & on function name
  staging: iio: adis16203: Remove exceptional & on function name
  staging: iio: resolver: Remove exceptional & on function name
  staging: iio: gyro: Remove exceptional & on function name

 drivers/staging/iio/accel/adis16201.c |  4 ++--
 drivers/staging/iio/accel/adis16203.c |  4 ++--
 drivers/staging/iio/accel/adis16209.c |  4 ++--
 drivers/staging/iio/accel/adis16240.c |  4 ++--
 drivers/staging/iio/adc/ad7192.c  | 12 ++--
 drivers/staging/iio/adc/ad7780.c  |  2 +-
 drivers/staging/iio/cdc/ad7152.c  |  6 +++---
 drivers/staging/iio/cdc/ad7746.c  |  4 ++--
 drivers/staging/iio/gyro/adis16060_core.c |  2 +-
 drivers/staging/iio/resolver/ad2s1200.c   |  2 +-
 drivers/staging/iio/resolver/ad2s90.c |  2 +-
 11 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 07/10] staging: iio: adis16209: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/accel/adis16209.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/accel/adis16209.c 
b/drivers/staging/iio/accel/adis16209.c
index 8ff537f..56bc2ac 100644
--- a/drivers/staging/iio/accel/adis16209.c
+++ b/drivers/staging/iio/accel/adis16209.c
@@ -285,8 +285,8 @@ static const struct iio_chan_spec adis16209_channels[] = {
 };
 
 static const struct iio_info adis16209_info = {
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
+   .read_raw = adis16209_read_raw,
+   .write_raw = adis16209_write_raw,
.update_scan_mode = adis_update_scan_mode,
.driver_module = THIS_MODULE,
 };
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 01/10] staging: iio: ad7192: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/adc/ad7192.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c
index 4fc8588..d11c6de 100644
--- a/drivers/staging/iio/adc/ad7192.c
+++ b/drivers/staging/iio/adc/ad7192.c
@@ -564,18 +564,18 @@ static int ad7192_write_raw_get_fmt(struct iio_dev 
*indio_dev,
 }
 
 static const struct iio_info ad7192_info = {
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
-   .write_raw_get_fmt = _write_raw_get_fmt,
+   .read_raw = ad7192_read_raw,
+   .write_raw = ad7192_write_raw,
+   .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = _attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
 };
 
 static const struct iio_info ad7195_info = {
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
-   .write_raw_get_fmt = _write_raw_get_fmt,
+   .read_raw = ad7192_read_raw,
+   .write_raw = ad7192_write_raw,
+   .write_raw_get_fmt = ad7192_write_raw_get_fmt,
.attrs = _attribute_group,
.validate_trigger = ad_sd_validate_trigger,
.driver_module = THIS_MODULE,
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 03/10] staging: iio: cdc: ad7746: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/cdc/ad7746.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/iio/cdc/ad7746.c b/drivers/staging/iio/cdc/ad7746.c
index 81f8b9e..6294de7 100644
--- a/drivers/staging/iio/cdc/ad7746.c
+++ b/drivers/staging/iio/cdc/ad7746.c
@@ -664,8 +664,8 @@ static int ad7746_read_raw(struct iio_dev *indio_dev,
 
 static const struct iio_info ad7746_info = {
.attrs = _attribute_group,
-   .read_raw = _read_raw,
-   .write_raw = _write_raw,
+   .read_raw = ad7746_read_raw,
+   .write_raw = ad7746_write_raw,
.driver_module = THIS_MODULE,
 };
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 02/10] staging: iio: ad7780: Remove exceptional & on function name

[simran singhal]

In this file,function names are otherwise used as pointers without &.
Found using coccinelle.
// 
@r@
identifier f;
@@

f(...) { ... }
@@
identifier r.f;
@@

- 
+ f
// 

Signed-off-by: simran singhal 
---
 drivers/staging/iio/adc/ad7780.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/adc/ad7780.c b/drivers/staging/iio/adc/ad7780.c
index e149600..dec3ba6 100644
--- a/drivers/staging/iio/adc/ad7780.c
+++ b/drivers/staging/iio/adc/ad7780.c
@@ -154,7 +154,7 @@ static const struct ad7780_chip_info ad7780_chip_info_tbl[] 
= {
 };
 
 static const struct iio_info ad7780_info = {
-   .read_raw = _read_raw,
+   .read_raw = ad7780_read_raw,
.driver_module = THIS_MODULE,
 };
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/3] staging: sm750fb: multiple checkpatch issues

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in sm750fb driver.

Arushi Singhal (3):
  staging: sm750fb: function prototype argument should have an
identifier name
  staging: sm750fb: fixes add blank line after
function/struct/union/enum declarations
  staging: sm750fb: Alignment should match open parenthesis

 drivers/staging/sm750fb/ddk750_display.h |  2 +-
 drivers/staging/sm750fb/ddk750_mode.c| 79 
 drivers/staging/sm750fb/ddk750_mode.h|  2 +-
 drivers/staging/sm750fb/ddk750_power.h   |  2 +-
 drivers/staging/sm750fb/sm750.h  |  2 +-
 drivers/staging/sm750fb/sm750_cursor.c   |  3 ++
 6 files changed, 46 insertions(+), 44 deletions(-)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: sm750fb: fixes add blank line after function/struct/union/enum declarations

[Arushi Singhal]

This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/sm750_cursor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/sm750fb/sm750_cursor.c 
b/drivers/staging/sm750fb/sm750_cursor.c
index 612e9ab9d569..b64dc8a4a8fb 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -54,6 +54,7 @@ void sm750_hw_cursor_enable(struct lynx_cursor *cursor)
reg = (cursor->offset & HWC_ADDRESS_ADDRESS_MASK) | HWC_ADDRESS_ENABLE;
poke32(HWC_ADDRESS, reg);
 }
+
 void sm750_hw_cursor_disable(struct lynx_cursor *cursor)
 {
poke32(HWC_ADDRESS, 0);
@@ -65,6 +66,7 @@ void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
cursor->w = w;
cursor->h = h;
 }
+
 void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
int x, int y)
 {
@@ -74,6 +76,7 @@ void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
   (x & HWC_LOCATION_X_MASK);
poke32(HWC_LOCATION, reg);
 }
+
 void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
u32 fg, u32 bg)
 {
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: sm750fb: Alignment should match open parenthesis

[Arushi Singhal]

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_mode.c | 79 +--
 1 file changed, 39 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index 45af806c8d55..eea5aef2956f 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -28,9 +28,9 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
poke32(CRT_AUTO_CENTERING_TL, 0);
 
poke32(CRT_AUTO_CENTERING_BR,
-   (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
-   CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
-   ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
+  (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
+   CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
+  ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
 
/*
 * Assume common fields in dispControl have been properly set before
@@ -72,8 +72,7 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
 }
 
 /* only timing related registers will be  programed */
-static int programModeRegisters(mode_parameter_t *pModeParam,
-   struct pll_value *pll)
+static int programModeRegisters(mode_parameter_t *pModeParam, struct pll_value 
*pll)
 {
int ret = 0;
int cnt = 0;
@@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam,
/* programe secondary pixel clock */
poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
poke32(CRT_HORIZONTAL_TOTAL,
-   (((pModeParam->horizontal_total - 1) <<
-   CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
-   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
-   ((pModeParam->horizontal_display_end - 1) &
-   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
+  (((pModeParam->horizontal_total - 1) <<
+CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
+   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
+  ((pModeParam->horizontal_display_end - 1) &
+   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
 
poke32(CRT_HORIZONTAL_SYNC,
-   ((pModeParam->horizontal_sync_width <<
-   CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
-   ((pModeParam->horizontal_sync_start - 1) &
-   CRT_HORIZONTAL_SYNC_START_MASK));
+  ((pModeParam->horizontal_sync_width <<
+CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
+   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
+  ((pModeParam->horizontal_sync_start - 1) &
+   CRT_HORIZONTAL_SYNC_START_MASK));
 
poke32(CRT_VERTICAL_TOTAL,
-   (((pModeParam->vertical_total - 1) <<
-   CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
-   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
-   ((pModeParam->vertical_display_end - 1) &
-   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
+  (((pModeParam->vertical_total - 1) <<
+CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
+   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
+  ((pModeParam->vertical_display_end - 1) &
+   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
 
poke32(CRT_VERTICAL_SYNC,
-   ((pModeParam->vertical_sync_height <<
-   CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
-   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
-   ((pModeParam->vertical_sync_start - 1) &
-   CRT_VERTICAL_SYNC_START_MASK));
+  ((pModeParam->vertical_sync_height <<
+CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
+   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
+  ((pModeParam->vertical_sync_start - 1) &
+   CRT_VERTICAL_SYNC_START_MASK));
 
tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
if (pModeParam->vertical_sync_polarity)
@@ -140,25 +139,25 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam,
poke32(PANEL_HORIZONTAL_TOTAL, reg);
 
poke32(PANEL_HORIZONTAL_SYNC,
-   ((pModeParam->horizontal_sync_width <<
-   PANEL_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   PANEL_HORIZONTAL_SYNC_WIDTH_MASK) |
-

[PATCH 1/3] staging: sm750fb: function prototype argument should have an identifier name

[Arushi Singhal]

function prototype arguments like 'struct vb_device_info *','unsigned
long' etc. should have an identifier name.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_display.h | 2 +-
 drivers/staging/sm750fb/ddk750_mode.h| 2 +-
 drivers/staging/sm750fb/ddk750_power.h   | 2 +-
 drivers/staging/sm750fb/sm750.h  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index e2a3f84ca4c5..609bf742efff 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -102,6 +102,6 @@ typedef enum _disp_output_t {
 }
 disp_output_t;
 
-void ddk750_setLogicalDispOut(disp_output_t);
+void ddk750_setLogicalDispOut(disp_output_t output);
 
 #endif
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 2183e664cf4b..6d204b8b4a01 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
 }
 mode_parameter_t;
 
-int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
+int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
 
 #endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h 
b/drivers/staging/sm750fb/ddk750_power.h
index ec0b99d6a7ad..44c4fc587e96 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -14,7 +14,7 @@ DPMS_t;
   (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
 }
 
-void ddk750_set_dpms(DPMS_t);
+void ddk750_set_dpms(DPMS_t state);
 void sm750_set_power_mode(unsigned int powerMode);
 void sm750_set_current_gate(unsigned int gate);
 
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 306711ed55f9..5ea455dee949 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
 }
 
 int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
-int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
+int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
 void hw_sm750_initAccel(struct sm750_dev *);
 int hw_sm750_deWait(void);
 int hw_sm750le_deWait(void);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH V2] Staging: bcm2835: Fixed style of block comments

[Derek Robson]

Fixed style of block comments across whole driver
Found using checkpatch

Signed-off-by: Derek Robson 
---
Version #1 had ugly long subject name.

 .../media/platform/bcm2835/bcm2835-camera.c| 24 ++
 drivers/staging/media/platform/bcm2835/controls.c  | 22 +++-
 .../staging/media/platform/bcm2835/mmal-msg-port.h |  6 --
 drivers/staging/media/platform/bcm2835/mmal-msg.h  | 18 
 .../staging/media/platform/bcm2835/mmal-vchiq.c|  3 ++-
 .../staging/media/platform/bcm2835/mmal-vchiq.h|  4 ++--
 6 files changed, 45 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index ca15a698e018..25beca62a8a9 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -239,8 +239,9 @@ static struct mmal_fmt *get_format(struct v4l2_format *f)
 }
 
 /* --
-   Videobuf queue operations
-   --*/
+ * Videobuf queue operations
+ * --
+ */
 
 static int queue_setup(struct vb2_queue *vq,
   unsigned int *nbuffers, unsigned int *nplanes,
@@ -668,8 +669,9 @@ static struct vb2_ops bm2835_mmal_video_qops = {
 };
 
 /* --
-   IOCTL operations
-   --*/
+ * IOCTL operations
+ * --
+ */
 
 static int set_overlay_params(struct bm2835_mmal_dev *dev,
  struct vchiq_mmal_port *port)
@@ -834,7 +836,8 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
 struct v4l2_framebuffer *a)
 {
/* The video overlay must stay within the framebuffer and can't be
-  positioned independently. */
+* positioned independently.
+*/
struct bm2835_mmal_dev *dev = video_drvdata(file);
struct vchiq_mmal_port *preview_port =
>component[MMAL_COMPONENT_CAMERA]->
@@ -1291,7 +1294,8 @@ static int vidioc_s_fmt_vid_cap(struct file *file, void 
*priv,
}
 
/* If the format is unsupported v4l2 says we should switch to
-* a supported one and not return an error. */
+* a supported one and not return an error.
+*/
mfmt = get_format(f);
if (!mfmt) {
v4l2_dbg(1, bcm2835_v4l2_debug, >v4l2_dev,
@@ -1485,7 +1489,8 @@ static const struct v4l2_ioctl_ops 
camera0_ioctl_ops_gstreamer = {
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
/* Remove this function ptr to fix gstreamer bug
-   .vidioc_enum_framesizes = vidioc_enum_framesizes, */
+* .vidioc_enum_framesizes = vidioc_enum_framesizes,
+*/
.vidioc_enum_frameintervals = vidioc_enum_frameintervals,
.vidioc_g_parm= vidioc_g_parm,
.vidioc_s_parm= vidioc_s_parm,
@@ -1498,8 +1503,9 @@ static const struct v4l2_ioctl_ops 
camera0_ioctl_ops_gstreamer = {
 };
 
 /* --
-   Driver init/finalise
-   --*/
+ * Driver init/finalise
+ * --
+ */
 
 static const struct v4l2_file_operations camera0_fops = {
.owner = THIS_MODULE,
diff --git a/drivers/staging/media/platform/bcm2835/controls.c 
b/drivers/staging/media/platform/bcm2835/controls.c
index a40987b2e75d..16fa40c904e7 100644
--- a/drivers/staging/media/platform/bcm2835/controls.c
+++ b/drivers/staging/media/platform/bcm2835/controls.c
@@ -90,7 +90,8 @@ struct bm2835_mmal_v4l2_ctrl {
u32 id; /* v4l2 control identifier */
enum bm2835_mmal_ctrl_type type;
/* control minimum value or
-* mask for MMAL_CONTROL_TYPE_STD_MENU */
+* mask for MMAL_CONTROL_TYPE_STD_MENU
+*/
s32 min;
s32 max; /* maximum value of control */
s32 def;  /* default value of control */
@@ -398,10 +399,10 @@ static int ctrl_set_metering_mode(struct bm2835_mmal_dev 
*dev,
break;
 
/* todo matrix weighting not added to Linux API till 3.9
-   case V4L2_EXPOSURE_METERING_MATRIX:
-   dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
-   break;
-   */
+* case V4L2_EXPOSURE_METERING_MATRIX:
+*  dev->metering_mode = MMAL_PARAM_EXPOSUREMETERINGMODE_MATRIX;
+*  break;
+*/
}
 
if (dev->scene_mode == V4L2_SCENE_MODE_NONE) {
@@ -982,8 +983,9 @@ static const struct 

Re: [PATCH 0/5] staging: rtl8192e: Clean up tests if NULL returned on failure

[SIMRAN SINGHAL]

On Sat, Mar 11, 2017 at 2:43 AM, Dan Carpenter  wrote:
> Don't resend, but next time if you wanted to fold all these patches and
> send them as one patch that would be fine.
>

Hi Dan,

Before I sent this patches as single patch only, but then greg asked
me to resend
them as different patches.

Thanks,
Simran Singhal

> regards,
> dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: ks7010: remove trailing whitespaces

[Thibaut SAUTEREAU]

Remove trailing whitespaces as pointed out by checkpatch.pl.

Signed-off-by: Thibaut SAUTEREAU 
---
 drivers/staging/ks7010/ks_hostif.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.h 
b/drivers/staging/ks7010/ks_hostif.h
index 61c2f96d7d1b..ce46cb723a53 100644
--- a/drivers/staging/ks7010/ks_hostif.h
+++ b/drivers/staging/ks7010/ks_hostif.h
@@ -1,6 +1,6 @@
 /*
  *   Driver for KeyStream wireless LAN
- *   
+ *
  *   Copyright (c) 2005-2008 KeyStream Corp.
  *   Copyright (C) 2009 Renesas Technology Corp.
  *
@@ -360,7 +360,7 @@ struct hostif_ps_adhoc_set_request_t {
 #define CTS_MODE_TRUE  1
uint16_t channel;
struct rate_set16_t rate_set;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0
 * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
uint16_t scan_type;
 } __packed;
@@ -376,7 +376,7 @@ struct hostif_infrastructure_set_request_t {
uint16_t cts_mode;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0
 * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
uint16_t beacon_lost_count;
uint16_t auth_type;
@@ -392,7 +392,7 @@ struct hostif_infrastructure_set2_request_t {
uint16_t cts_mode;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0
 * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
uint16_t beacon_lost_count;
uint16_t auth_type;
@@ -415,7 +415,7 @@ struct hostif_adhoc_set_request_t {
uint16_t channel;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0
 * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
uint16_t scan_type;
 } __packed;
@@ -427,7 +427,7 @@ struct hostif_adhoc_set2_request_t {
uint16_t reserved;
struct rate_set16_t rate_set;
struct ssid_t ssid;
-   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0 
+   uint16_t capability;/* bit5:preamble bit6:pbcc pbcc not supported 
always 0
 * bit10:ShortSlotTime bit13:DSSS-OFDM 
DSSS-OFDM not supported always 0 */
uint16_t scan_type;
struct channel_list_t channel_list;
@@ -568,7 +568,7 @@ struct hostif_mic_failure_confirm_t {
 #define TX_RATE_48M(uint8_t)(480 / 5)
 #define TX_RATE_54M(uint8_t)(540 / 5)
 
-#define IS_11B_RATE(A) (((A & RATE_MASK) == TX_RATE_1M ) || ((A & RATE_MASK) 
== TX_RATE_2M) || \
+#define IS_11B_RATE(A) (((A & RATE_MASK) == TX_RATE_1M) || ((A & RATE_MASK) == 
TX_RATE_2M) || \
 ((A & RATE_MASK) == TX_RATE_5M) || ((A & RATE_MASK) == 
TX_RATE_11M))
 
 #define IS_OFDM_RATE(A) (((A & RATE_MASK) == TX_RATE_6M) || ((A & RATE_MASK) 
== TX_RATE_12M) || \
@@ -612,7 +612,7 @@ enum {
 #define IS_HIF_CONF(_EVENT) ((_EVENT & HIF_EVENT_MASK) == 0xE800  && \
  (_EVENT & ~HIF_EVENT_MASK) > 0x  && \
  (_EVENT & ~HIF_EVENT_MASK) < 0x0012  && \
- !IS_HIF_IND(_EVENT) )
+ !IS_HIF_IND(_EVENT))
 
 #ifdef __KERNEL__
 
-- 
2.12.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/10/2017 03:30 PM, Pavel Machek wrote:

On Fri 2017-03-10 10:37:21, Steve Longerbeam wrote:

Hi Hans,

On 03/10/2017 04:03 AM, Hans Verkuil wrote:

On 10/03/17 05:52, Steve Longerbeam wrote:

Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
output device has measured an interval between the reception or transmit
completion of two consecutive frames of video that is outside the nominal
frame interval by some tolerance value.


Reading back what was said on this I agree with Sakari that this doesn't
belong here.

Userspace can detect this just as easily (if not easier) with a timeout.




Unfortunately measuring frame intervals from userland is not accurate
enough for i.MX6.

The issue here is that the IPUv3, specifically the CSI unit, can
permanently lose vertical sync if there are truncated frames sent
on the bt.656 bus. We have seen a single missing line of video cause
loss of vertical sync. The only way to correct this is to shutdown
the IPU capture hardware and restart, which can be accomplished
simply by restarting streaming from userland.

There are no other indicators from the sensor about these short
frame events (believe me, we've exhausted all avenues with the ADV718x).
And the IPUv3 DMA engine has no status indicators for short frames
either. So the only way to detect them is by measuring frame intervals.

The intervals have to be able to resolve a single line of missing video.
With a PAL video source that requires better than 58 usec accuracy.

There is too much uncertainty to resolve this at user level. The
driver is able to resolve this by measuring intervals between hardware
interrupts as long as interrupt latency is reasonably low, and we
have another method using the i.MX6 hardware input capture support
that can measure these intervals very accurately with no errors
introduced by interrupt latency.


Requiring < 58 usec interrupt latency for correct operation is a
little too optimistic, no?



No it's not too optimistic, from experience the imx6 kernel has irq
latency less than 10 usec under normal system load. False events can be
generated if the latency gets bad, it's true, and that's why there is
the imx6 timer input capture approach.

Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 22/39] media: Add userspace header file for i.MX

[Pavel Machek]

Hi!

> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
>  # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> new file mode 100644
> index 000..f573de4
> --- /dev/null
> +++ b/include/uapi/media/imx.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> + *
> + * 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
> + */
> +
> +#ifndef __UAPI_MEDIA_IMX_H__
> +#define __UAPI_MEDIA_IMX_H__
> +
> +enum imx_ctrl_id {
> + V4L2_CID_IMX_FIM_ENABLE = (V4L2_CID_USER_IMX_BASE + 0),
> + V4L2_CID_IMX_FIM_NUM,
> + V4L2_CID_IMX_FIM_TOLERANCE_MIN,
> + V4L2_CID_IMX_FIM_TOLERANCE_MAX,
> + V4L2_CID_IMX_FIM_NUM_SKIP,
> +};
> +

Should this #include something so that if userland includes it, it
will not get compile error?

Should there be some documentation of userland API?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Pavel Machek]

On Fri 2017-03-10 10:37:21, Steve Longerbeam wrote:
> Hi Hans,
> 
> On 03/10/2017 04:03 AM, Hans Verkuil wrote:
> >On 10/03/17 05:52, Steve Longerbeam wrote:
> >>Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
> >>output device has measured an interval between the reception or transmit
> >>completion of two consecutive frames of video that is outside the nominal
> >>frame interval by some tolerance value.
> >
> >Reading back what was said on this I agree with Sakari that this doesn't
> >belong here.
> >
> >Userspace can detect this just as easily (if not easier) with a timeout.
> >
> 
> 
> Unfortunately measuring frame intervals from userland is not accurate
> enough for i.MX6.
> 
> The issue here is that the IPUv3, specifically the CSI unit, can
> permanently lose vertical sync if there are truncated frames sent
> on the bt.656 bus. We have seen a single missing line of video cause
> loss of vertical sync. The only way to correct this is to shutdown
> the IPU capture hardware and restart, which can be accomplished
> simply by restarting streaming from userland.
> 
> There are no other indicators from the sensor about these short
> frame events (believe me, we've exhausted all avenues with the ADV718x).
> And the IPUv3 DMA engine has no status indicators for short frames
> either. So the only way to detect them is by measuring frame intervals.
> 
> The intervals have to be able to resolve a single line of missing video.
> With a PAL video source that requires better than 58 usec accuracy.
> 
> There is too much uncertainty to resolve this at user level. The
> driver is able to resolve this by measuring intervals between hardware
> interrupts as long as interrupt latency is reasonably low, and we
> have another method using the i.MX6 hardware input capture support
> that can measure these intervals very accurately with no errors
> introduced by interrupt latency.

Requiring < 58 usec interrupt latency for correct operation is a
little too optimistic, no?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 00/39] i.MX Media Driver

[Steve Longerbeam]

On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote:

Version 5 gives me no v4l2 controls exposed through the video device
interface.

Just like with version 4, version 5 is completely useless with IMX219:

imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110

So, like v4, I can't do any further testing.



Is the imx219 placing the csi-2 bus in LP-11 state on exit
from s_power(ON)?

I realize that probably means bringing the chip up to a
completely operational state and then setting it to stream
OFF in the s_power() op.

The same had to be done for the OV5640.

Steve
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

[Brijesh Singh]

Hi Boris,

On 03/10/2017 05:06 AM, Borislav Petkov wrote:

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:

If kernel_maps_pages_in_pgd is called early in boot process to change the


kernel_map_pages_in_pgd()


memory attributes then it fails to allocate memory when spliting large
pages. The patch extends the cpa_data to provide the support to use
memblock_alloc when slab allocator is not available.

The feature will be used in Secure Encrypted Virtualization (SEV) mode,
where we may need to change the memory region attributes in early boot
process.

Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/pageattr.c |   51 
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index 46cc89d..9e4ab3b 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -37,6 +38,7 @@ struct cpa_data {
int flags;
unsigned long   pfn;
unsignedforce_split : 1;
+   unsignedforce_memblock :1;
int curpage;
struct page **pages;
 };
@@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long address,

 static int
 __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
-  struct page *base)
+ pte_t *pbase, unsigned long new_pfn)
 {
-   pte_t *pbase = (pte_t *)page_address(base);
unsigned long ref_pfn, pfn, pfninc = 1;
unsigned int i, level;
pte_t *tmp;
@@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 1;
}

-   paravirt_alloc_pte(_mm, page_to_pfn(base));
+   paravirt_alloc_pte(_mm, new_pfn);

switch (level) {
case PG_LEVEL_2M:
@@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
 * pagetable protections, the actual ptes set above control the
 * primary protection behavior:
 */
-   __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
+   __set_pmd_pte(kpte, address,
+   native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));

/*
 * Intel Atom errata AAH41 workaround.
@@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
unsigned long address,
return 0;
 }

+static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
+{
+   unsigned long phys;
+   struct page *base;
+
+   if (cpa->force_memblock) {
+   phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);


Maybe there's a reason this fires:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the 
function __change_page_attr() to the function .init.text:memblock_alloc()
The function __change_page_attr() references
the function __init memblock_alloc().
This is often because __change_page_attr lacks a __init
annotation or the annotation of memblock_alloc is wrong.

WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the 
function __change_page_attr() to the function .meminit.text:memblock_free()
The function __change_page_attr() references
the function __meminit memblock_free().
This is often because __change_page_attr lacks a __meminit
annotation or the annotation of memblock_free is wrong.



I can take a look at fixing those warning. In my initial attempt was to create
a new function to clear encryption bit but it ended up looking very similar to
__change_page_attr_set_clr() hence decided to extend the exiting function to
use memblock_alloc().



Why do we need this whole early mapping? For the guest? I don't like
that memblock thing at all.


Early in boot process, guest kernel allocates some structure (its either
statically allocated or dynamic allocated via memblock_alloc). And shares the 
physical
address of these structure with hypervisor. Since entire guest memory area is 
mapped
as encrypted hence those structure's are mapped as encrypted memory range. We 
need
a method to clear the encryption bit. Sometime these structure maybe part of 2M 
pages
and need to split into smaller pages.



So I think the approach with the .data..percpu..hv_shared section is
fine and we should consider SEV-ES

http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf

and do this right from the get-go so that when SEV-ES comes along, we
should simply be ready and extend that mechanism to put the whole Guest
Hypervisor Communication Block in there.




But then the fact that you're mapping those decrypted in init_mm.pgd
makes me think you don't need that early mapping thing at all. Those are
the decrypted mappings 

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Sakari Ailus]

Hi Mauro (and others),

On Fri, Mar 10, 2017 at 12:53:42PM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 10 Mar 2017 15:20:48 +0100
> Hans Verkuil  escreveu:
> 
> > 
> > > As I've already mentioned, from talking about this with Mauro, it seems
> > > Mauro is in agreement with permitting the control inheritence... I wish
> > > Mauro would comment for himself, as I can't quote our private discussion
> > > on the subject.  
> > 
> > I can't comment either, not having seen his mail and reasoning.
> 
> The rationale is that we should support the simplest use cases first.
> 
> In the case of the first MC-based driver (and several subsequent
> ones), the simplest use case required MC, as it was meant to suport
> a custom-made sophisticated application that required fine control
> on each component of the pipeline and to allow their advanced
> proprietary AAA userspace-based algorithms to work.

The first MC based driver (omap3isp) supports what the hardware can do, it
does not support applications as such.

Adding support to drivers for different "operation modes" --- this is
essentially what is being asked for --- is not an approach which could serve
either purpose (some functionality with simple interface vs. fully support
what the hardware can do, with interfaces allowing that) adequately in the
short or the long run.

If we are missing pieces in the puzzle --- in this case the missing pieces
in the puzzle are a generic pipeline configuration library and another
library that, with the help of pipeline autoconfiguration would implement
"best effort" service for regular V4L2 on top of the MC + V4L2 subdev + V4L2
--- then these pieces need to be impelemented. The solution is
*not* to attempt to support different types of applications in each driver
separately. That will make writing drivers painful, error prone and is
unlikely ever deliver what either purpose requires.

So let's continue to implement the functionality that the hardware supports.
Making a different choice here is bound to create a lasting conflict between
having to change kernel interface behaviour and the requirement of
supporting new functionality that hasn't been previously thought of, pushing
away SoC vendors from V4L2 ecosystem. This is what we all do want to avoid.

As far as i.MX6 driver goes, it is always possible to implement i.MX6 plugin
for libv4l to perform this. This should be much easier than getting the
automatic pipe configuration library and the rest working, and as it is
custom for i.MX6, the resulting plugin may make informed technical choices
for better functionality. Jacek has been working on such a plugin for
Samsung Exynos hardware, but I don't think he has quite finished it yey.

The original plan was and continues to be sound, it's just that there have
always been too few hands to implement it. :-(

> 
> That's not true, for example, for the UVC driver. There, MC
> is optional, as it should be.

UVC is different. The device simply provides additional information through
MC to the user but MC (or V4L2 sub-device interface) is not used for
controlling the device.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/3] multiple checkpatch issues

[Greg KH]

On Sat, Mar 11, 2017 at 03:26:54AM +0530, Arushi Singhal wrote:
> Improve readability by fixing multiple checkpatch.pl
> issues in sm750fb driver. 

Note, _PLEASE_ put the subsystem/driver name in this 0/X email subject
line, like your patches have them.  It makes it easier when I sort
patches by driver/subsystem when reviewing them.  As it is, I end up
always ignoring these 0/X emails.

thanks,

greg k-h
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

[Fabio Estevam]

On Fri, Mar 10, 2017 at 6:57 PM, Pavel Machek  wrote:

> And it should not depend on configuration. Hardware vendor should be
> able to ship board with working device tree...

We are talking about pin conflict here. Please read the commit log of
this patch for details.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

[Pavel Machek]

On Fri 2017-03-10 16:17:28, Fabio Estevam wrote:
> On Fri, Mar 10, 2017 at 3:59 PM, Troy Kisky
>  wrote:
> > On 3/9/2017 8:52 PM, Steve Longerbeam wrote:
> >> There is a pin conflict with GPIO_6. This pin functions as a power
> >> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
> >> workaround for erratum ERR006687, to wake-up the ARM cores on normal
> >> RX and TX packet done events. So we need to remove the h/w workaround
> >> to support the OV5642. The result is that the CPUidle driver will no
> >> longer allow entering the deep idle states on the sabrelite.
> >>
> >> This is a partial revert of
> >>
> >> commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
> >>   interrupt.")
> >> commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW 
> >> workaround
> >>   for ERR006687")
> >>
> >> Signed-off-by: Steve Longerbeam 
> >> ---
> >>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
> >>  1 file changed, 4 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
> >> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> index 8413179..89dce27 100644
> >> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> >> @@ -270,9 +270,6 @@
> >>   txd1-skew-ps = <0>;
> >>   txd2-skew-ps = <0>;
> >>   txd3-skew-ps = <0>;
> >
> > How about
> >
> > +#if !IS_ENABLED(CONFIG_VIDEO_OV5642)

dts is supposed to be hardware description.

> Or maybe just create a new device tree for using the camera, like
> imx6q-sabrelite-camera.dts.

And it should not depend on configuration. Hardware vendor should be
able to ship board with working device tree...

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/3] staging: sm750fb: function prototype argument should have an identifier name

[Arushi Singhal]

function prototype arguments like 'struct vb_device_info *','unsigned
long' etc. should have an identifier name.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_display.h | 2 +-
 drivers/staging/sm750fb/ddk750_mode.h| 2 +-
 drivers/staging/sm750fb/ddk750_power.h   | 2 +-
 drivers/staging/sm750fb/sm750.h  | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_display.h 
b/drivers/staging/sm750fb/ddk750_display.h
index e2a3f84ca4c5..609bf742efff 100644
--- a/drivers/staging/sm750fb/ddk750_display.h
+++ b/drivers/staging/sm750fb/ddk750_display.h
@@ -102,6 +102,6 @@ typedef enum _disp_output_t {
 }
 disp_output_t;
 
-void ddk750_setLogicalDispOut(disp_output_t);
+void ddk750_setLogicalDispOut(disp_output_t output);
 
 #endif
diff --git a/drivers/staging/sm750fb/ddk750_mode.h 
b/drivers/staging/sm750fb/ddk750_mode.h
index 2183e664cf4b..6d204b8b4a01 100644
--- a/drivers/staging/sm750fb/ddk750_mode.h
+++ b/drivers/staging/sm750fb/ddk750_mode.h
@@ -34,6 +34,6 @@ typedef struct _mode_parameter_t {
 }
 mode_parameter_t;
 
-int ddk750_setModeTiming(mode_parameter_t *, clock_type_t);
+int ddk750_setModeTiming(mode_parameter_t *parm, clock_type_t clock);
 
 #endif
diff --git a/drivers/staging/sm750fb/ddk750_power.h 
b/drivers/staging/sm750fb/ddk750_power.h
index ec0b99d6a7ad..44c4fc587e96 100644
--- a/drivers/staging/sm750fb/ddk750_power.h
+++ b/drivers/staging/sm750fb/ddk750_power.h
@@ -14,7 +14,7 @@ DPMS_t;
   (peek32(MISC_CTRL) & ~MISC_CTRL_DAC_POWER_OFF) | (off)); \
 }
 
-void ddk750_set_dpms(DPMS_t);
+void ddk750_set_dpms(DPMS_t state);
 void sm750_set_power_mode(unsigned int powerMode);
 void sm750_set_current_gate(unsigned int gate);
 
diff --git a/drivers/staging/sm750fb/sm750.h b/drivers/staging/sm750fb/sm750.h
index 306711ed55f9..5ea455dee949 100644
--- a/drivers/staging/sm750fb/sm750.h
+++ b/drivers/staging/sm750fb/sm750.h
@@ -184,7 +184,7 @@ static inline unsigned long ps_to_hz(unsigned int psvalue)
 }
 
 int hw_sm750_map(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
-int hw_sm750_inithw(struct sm750_dev*, struct pci_dev *);
+int hw_sm750_inithw(struct sm750_dev *sm750_dev, struct pci_dev *pdev);
 void hw_sm750_initAccel(struct sm750_dev *);
 int hw_sm750_deWait(void);
 int hw_sm750le_deWait(void);
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/3] staging: sm750fb: fixes add blank line after function/struct/union/enum declarations

[Arushi Singhal]

This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/sm750_cursor.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/sm750fb/sm750_cursor.c 
b/drivers/staging/sm750fb/sm750_cursor.c
index 612e9ab9d569..b64dc8a4a8fb 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -54,6 +54,7 @@ void sm750_hw_cursor_enable(struct lynx_cursor *cursor)
reg = (cursor->offset & HWC_ADDRESS_ADDRESS_MASK) | HWC_ADDRESS_ENABLE;
poke32(HWC_ADDRESS, reg);
 }
+
 void sm750_hw_cursor_disable(struct lynx_cursor *cursor)
 {
poke32(HWC_ADDRESS, 0);
@@ -65,6 +66,7 @@ void sm750_hw_cursor_setSize(struct lynx_cursor *cursor,
cursor->w = w;
cursor->h = h;
 }
+
 void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
int x, int y)
 {
@@ -74,6 +76,7 @@ void sm750_hw_cursor_setPos(struct lynx_cursor *cursor,
   (x & HWC_LOCATION_X_MASK);
poke32(HWC_LOCATION, reg);
 }
+
 void sm750_hw_cursor_setColor(struct lynx_cursor *cursor,
u32 fg, u32 bg)
 {
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 3/3] staging: sm750fb: Alignment should match open parenthesis

[Arushi Singhal]

Fix checkpatch issues: "CHECK: Alignment should match open parenthesis".

Signed-off-by: Arushi Singhal 
---
 drivers/staging/sm750fb/ddk750_mode.c | 79 +--
 1 file changed, 39 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/sm750fb/ddk750_mode.c 
b/drivers/staging/sm750fb/ddk750_mode.c
index 45af806c8d55..eea5aef2956f 100644
--- a/drivers/staging/sm750fb/ddk750_mode.c
+++ b/drivers/staging/sm750fb/ddk750_mode.c
@@ -28,9 +28,9 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
poke32(CRT_AUTO_CENTERING_TL, 0);
 
poke32(CRT_AUTO_CENTERING_BR,
-   (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
-   CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
-   ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
+  (((y - 1) << CRT_AUTO_CENTERING_BR_BOTTOM_SHIFT) &
+   CRT_AUTO_CENTERING_BR_BOTTOM_MASK) |
+  ((x - 1) & CRT_AUTO_CENTERING_BR_RIGHT_MASK));
 
/*
 * Assume common fields in dispControl have been properly set before
@@ -72,8 +72,7 @@ static unsigned long 
displayControlAdjust_SM750LE(mode_parameter_t *pModeParam,
 }
 
 /* only timing related registers will be  programed */
-static int programModeRegisters(mode_parameter_t *pModeParam,
-   struct pll_value *pll)
+static int programModeRegisters(mode_parameter_t *pModeParam, struct pll_value 
*pll)
 {
int ret = 0;
int cnt = 0;
@@ -83,32 +82,32 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam,
/* programe secondary pixel clock */
poke32(CRT_PLL_CTRL, sm750_format_pll_reg(pll));
poke32(CRT_HORIZONTAL_TOTAL,
-   (((pModeParam->horizontal_total - 1) <<
-   CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
-   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
-   ((pModeParam->horizontal_display_end - 1) &
-   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
+  (((pModeParam->horizontal_total - 1) <<
+CRT_HORIZONTAL_TOTAL_TOTAL_SHIFT) &
+   CRT_HORIZONTAL_TOTAL_TOTAL_MASK) |
+  ((pModeParam->horizontal_display_end - 1) &
+   CRT_HORIZONTAL_TOTAL_DISPLAY_END_MASK));
 
poke32(CRT_HORIZONTAL_SYNC,
-   ((pModeParam->horizontal_sync_width <<
-   CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
-   ((pModeParam->horizontal_sync_start - 1) &
-   CRT_HORIZONTAL_SYNC_START_MASK));
+  ((pModeParam->horizontal_sync_width <<
+CRT_HORIZONTAL_SYNC_WIDTH_SHIFT) &
+   CRT_HORIZONTAL_SYNC_WIDTH_MASK) |
+  ((pModeParam->horizontal_sync_start - 1) &
+   CRT_HORIZONTAL_SYNC_START_MASK));
 
poke32(CRT_VERTICAL_TOTAL,
-   (((pModeParam->vertical_total - 1) <<
-   CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
-   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
-   ((pModeParam->vertical_display_end - 1) &
-   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
+  (((pModeParam->vertical_total - 1) <<
+CRT_VERTICAL_TOTAL_TOTAL_SHIFT) &
+   CRT_VERTICAL_TOTAL_TOTAL_MASK) |
+  ((pModeParam->vertical_display_end - 1) &
+   CRT_VERTICAL_TOTAL_DISPLAY_END_MASK));
 
poke32(CRT_VERTICAL_SYNC,
-   ((pModeParam->vertical_sync_height <<
-   CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
-   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
-   ((pModeParam->vertical_sync_start - 1) &
-   CRT_VERTICAL_SYNC_START_MASK));
+  ((pModeParam->vertical_sync_height <<
+CRT_VERTICAL_SYNC_HEIGHT_SHIFT) &
+   CRT_VERTICAL_SYNC_HEIGHT_MASK) |
+  ((pModeParam->vertical_sync_start - 1) &
+   CRT_VERTICAL_SYNC_START_MASK));
 
tmp = DISPLAY_CTRL_TIMING | DISPLAY_CTRL_PLANE;
if (pModeParam->vertical_sync_polarity)
@@ -140,25 +139,25 @@ static int programModeRegisters(mode_parameter_t 
*pModeParam,
poke32(PANEL_HORIZONTAL_TOTAL, reg);
 
poke32(PANEL_HORIZONTAL_SYNC,
-   ((pModeParam->horizontal_sync_width <<
-   PANEL_HORIZONTAL_SYNC_WIDTH_SHIFT) &
-   PANEL_HORIZONTAL_SYNC_WIDTH_MASK) |
-

[PATCH 0/3] multiple checkpatch issues

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in sm750fb driver. 

Arushi Singhal (3):
  staging: sm750fb: function prototype argument should have an
identifier name
  staging: sm750fb: fixes add blank line after
function/struct/union/enum declarations
  staging: sm750fb: Alignment should match open parenthesis

 drivers/staging/sm750fb/ddk750_display.h |  2 +-
 drivers/staging/sm750fb/ddk750_mode.c| 79 
 drivers/staging/sm750fb/ddk750_mode.h|  2 +-
 drivers/staging/sm750fb/ddk750_power.h   |  2 +-
 drivers/staging/sm750fb/sm750.h  |  2 +-
 drivers/staging/sm750fb/sm750_cursor.c   |  3 ++
 6 files changed, 46 insertions(+), 44 deletions(-)

-- 
2.11.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Pavel Machek]

Hi!

> Argh! that is indeed a bug at libv4l (and maybe at gstreamer).
> 
> I guess that the always_needs_conversion logic was meant to be used to
> really odd proprietary formats, e. g:
>   
> /*  Vendor-specific formats   */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
> #define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw 
> compress */
> #define V4L2_PIX_FMT_SN9C10X  v4l2_fourcc('S', '9', '1', '0') /* SN9C10x 
> compression */
> ...
> 
> I suspect that nobody uses libv4l2 with MC-based V4L2 devices. That's
> likely why nobody reported this bug before (that I know of).
> 
> In any case, for non-proprietary formats, the default should be to
> always offer both the emulated format and the original one.
> 
> I suspect that the enclosed patch should fix the issue with bayer formats.

...
> @@ -178,7 +178,7 @@ struct v4lconvert_data 
> *v4lconvert_create_with_dev_ops(int fd, void *dev_ops_pri
>   /* This keeps tracks of devices which have only formats for which apps
>  most likely will need conversion and we can thus safely add software
>  processing controls without a performance impact. */
> - int always_needs_conversion = 1;
> + int always_needs_conversion = 0;
>  
>   if (!data) {
>   fprintf(stderr, "libv4lconvert: error: out of memory!\n");
> @@ -208,8 +208,8 @@ struct v4lconvert_data 
> *v4lconvert_create_with_dev_ops(int fd, void *dev_ops_pri
>   if (j < ARRAY_SIZE(supported_src_pixfmts)) {
>   data->supported_src_formats |= 1ULL << j;
>   v4lconvert_get_framesizes(data, fmt.pixelformat, j);
> - if (!supported_src_pixfmts[j].needs_conversion)
> - always_needs_conversion = 0;
> + if (supported_src_pixfmts[j].needs_conversion)
> + always_needs_conversion = 1;
>   } else
>   always_needs_conversion = 0;
>   }

Is the else still needed? You changed default to 0...


Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 0/5] staging: rtl8192e: Clean up tests if NULL returned on failure

[Dan Carpenter]

Don't resend, but next time if you wanted to fold all these patches and
send them as one patch that would be fine.

regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: speakup: fixes braces {} should be used on all arms of this statement

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   |  3 ++-
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 +++-
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 3ecf2e41bf1f..6786cfab7460 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -405,8 +405,9 @@ static void say_attributes(struct vc_data *vc)
if (bg > 7) {
synth_printf(" %s ", spk_msg_get(MSG_ON_BLINKING));
bg -= 8;
-   } else
+   } else {
synth_printf(" %s ", spk_msg_get(MSG_ON));
+   }
synth_printf("%s\n", spk_msg_get(MSG_COLORS_START + bg));
 }
 
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 34e03c6b1ae5..77a935658af5 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -194,11 +194,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
spk_serial_out(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index afe2da34a3f7..100c65b38860 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -409,11 +409,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
dt_sendchar(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/speakup_dectlk.c 
b/drivers/staging/speakup/speakup_dectlk.c
index e0f2d6121890..d7d5e0e6e297 100644
--- a/drivers/staging/speakup/speakup_dectlk.c
+++ b/drivers/staging/speakup/speakup_dectlk.c
@@ -259,11 +259,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
spk_serial_out(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..066f8461f4d3 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -258,10 +258,11 @@ int spk_set_string_var(const char *page, struct 
st_var_header *var, int len)
if (var->p_val != var_data->u.s.default_val)
strcpy((char *)var->p_val, var_data->u.s.default_val);
return -ERESTART;
-   } else if (var->p_val)
+   } else if (var->p_val) {
strcpy((char *)var->p_val, page);
-   else
+   } else {
return -E2BIG;
+   }
return 0;
 }
 
@@ -281,17 +282,18 @@ int spk_set_mask_bits(const char *input, const int which, 
const int how)
spk_chartab[*cp] &= ~mask;
}
cp = (u_char *)input;
-   if (!cp)
+   if (!cp) {
cp = spk_punc_info[which].value;
-   else {
+   } else {
for (; *cp; cp++) {
if (*cp < SPACE)

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Fri, 10 Mar 2017 15:57:09 +
Russell King - ARM Linux  escreveu:

> On Fri, Mar 10, 2017 at 12:26:34PM -0300, Mauro Carvalho Chehab wrote:
> > Hi Russell,
> > 
> > Em Fri, 10 Mar 2017 13:07:33 +
> > Russell King - ARM Linux  escreveu:
> >   
> > > The idea that the v4l libraries should intercept the format negotiation
> > > between the application and kernel is a particularly painful one - the
> > > default gstreamer build detects the v4l libraries, and links against it.
> > > That much is fine.
> > > 
> > > However, the problem comes when you're trying to use bayer formats. The
> > > v4l libraries "helpfully" (or rather unhelpfully) intercept the format
> > > negotiation, and decide that they'll invoke v4lconvert to convert the
> > > bayer to RGB for you, whether you want them to do that or not.
> > > 
> > > v4lconvert may not be the most efficient way to convert, or even what
> > > is desired (eg, you may want to receive the raw bayer image.)  However,
> > > since the v4l libraries/v4lconvert gives you no option but to have its
> > > conversion forced into the pipeline, other options (such as using the
> > > gstreamer neon accelerated de-bayer plugin) isn't an option   
> > 
> > That's not true. There is an special flag, used only by libv4l2
> > emulated formats, that indicates when a video format is handled
> > via v4lconvert:  
> 
> I'm afraid that my statement comes from trying to use gstreamer with
> libv4l2 and _not_ being able to use the 8-bit bayer formats there at
> all - they are simply not passed across to the application through
> libv4l2/v4lconvert.
> 
> Instead, the formats that are passed across are the emulated formats.
> As I said above, that forces applications to use only the v4lconvert
> formats, the raw formats are not available.
> 
> So, the presence or absence of the V4L2_FMT_FLAG_EMULATED is quite
> meaningless if you can't even enumerate the non-converted formats.
> 
> The problem comes from the "always needs conversion" stuff in
> v4lconvert coupled with the way this subdev stuff works - since it
> requires manual configuration of all the pads within the kernel
> media pipeline, the kernel ends up only advertising _one_ format
> to userspace - in my case, that's RGGB8.
> 
> When v4lconvert_create_with_dev_ops() enumerates the formats from
> the kernel, it gets only RGGB8.  That causes always_needs_conversion
> in there to remain true, so the special v4l control which enables/
> disables conversion gets created with a default value of "true".
> The RGGB8 bit is also set in data->supported_src_formats.
> 
> This causes v4lconvert_supported_dst_fmt_only() to return true.
> 
> What this all means is that v4lconvert_enum_fmt() will _not_ return
> any of the kernel formats, only the faked formats.
> 
> Ergo, the RGGB8 format from the kernel is completely hidden from the
> application, and only the emulated format is made available.  As I
> said above, this forces v4lconvert's debayering on the application,
> whether you want it or not.
> 
> In the gstreamer case, it knows nothing about this special control,
> which means that trying to use this gstreamer pipeline:
> 
> $ gst-launch-1.0 v4l2src device=/dev/video6 ! bayer2rgbneon ! xvimagesink
> 
> is completely impossible without first rebuilding gstreamer _without_
> libv4l support.  Build gstreamer without libv4l support, and the above
> works.
> 
> Enabling debug output in gstreamer's v4l2src plugin confirms that
> the kernel's bayer format are totally hidden from gstreamer when
> linked with libv4l2, but are present when it isn't linked with
> libv4l2.

Argh! that is indeed a bug at libv4l (and maybe at gstreamer).

I guess that the always_needs_conversion logic was meant to be used to
really odd proprietary formats, e. g:

/*  Vendor-specific formats   */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
#define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw 
compress */
#define V4L2_PIX_FMT_SN9C10X  v4l2_fourcc('S', '9', '1', '0') /* SN9C10x 
compression */
...

I suspect that nobody uses libv4l2 with MC-based V4L2 devices. That's
likely why nobody reported this bug before (that I know of).

In any case, for non-proprietary formats, the default should be to
always offer both the emulated format and the original one.

I suspect that the enclosed patch should fix the issue with bayer formats.

> 

Thanks,
Mauro

[PATCH RFC] libv4lconvert: by default, offer the original format to the client

Applications should have the right to decide between using a
libv4lconvert emulated format or to implement the decoding themselves,
as this may have significative performance impact.

So, change the default to always show both formats.

Change also the default for Bayer encoded formats, as userspace
likely will want to handle it directly.

Signed-off-by: Mauro Carvalho Chehab 


diff --git 

[PATCH 0/2] Improve code readability

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues.

Arushi Singhal (2):
  staging: speakup: Avoid multiple assignments on same line
  staging: speakup: fixes braces {} should be used on all arms of this
statement

 drivers/staging/speakup/main.c   |  6 --
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 +++-
 5 files changed, 20 insertions(+), 16 deletions(-)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: speakup: Avoid multiple assignments on same line

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 00335eb2ff20..3ecf2e41bf1f 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2093,7 +2093,8 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
spk_keydown = 0;
goto out;
}
-   value = spk_lastkey = pad_chars[value];
+   value = pad_chars[value];
+   spk_lastkey = value;
spk_keydown++;
spk_parked &= 0xfe;
goto no_map;
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 00/39] i.MX Media Driver

[Russell King - ARM Linux]

Version 5 gives me no v4l2 controls exposed through the video device
interface.

Just like with version 4, version 5 is completely useless with IMX219:

imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200
ipu1_csi0: pipeline start failed with -110

So, like v4, I can't do any further testing.

On Thu, Mar 09, 2017 at 08:52:40PM -0800, Steve Longerbeam wrote:
> In version 5:
> 
> - ov5640: renamed "pwdn-gpios" to "powerdown-gpios"
> 
> - ov5640: add mutex lock around the subdev op entry points.
> 
> - ov5640: don't attempt to program the new mode in ov5640_set_fmt().
>   Instead set a new flag, pending_mode_change, and program the new
>   mode at s_stream() if flag is set.
> 
> - ov5640: implement [gs]_frame_interval. As part of that, create
>   ov5640_try_frame_interval(), which is used by both [gs]_frame_interval
>   and [gs]_parm.
> 
> - ov5640: don't attempt to set controls in ov5640_s_ctrl(), or at
>   mode change, do it instead after first power-up.
> 
> - video-multiplexer: include link_validate in media_entity_operations.
> 
> - video-multiplexer: enforce that output pad frame interval must match
>   input pad frame interval in vidsw_s_frame_interval().
> 
> - video-multiplexer: initialize frame interval to a default 30 fps.
> 
> - mipi csi-2: renamed "cfg" clock name property to "ref". This is the
>   27 MHz mipi csi-2 PLL reference clock.
> 
> - mipi csi-2: create a hsfreq_map[] table based on
>   https://community.nxp.com/docs/DOC-94312. Use it to select
>   a hsfreqrange_sel value when programming the D-PHY, based on
>   a max Mbps per lane. This is computed from the source subdev
>   via V4L2_CID_LINK_FREQ control, and if the subdev doesn't implement
>   that control, use a default hard-coded max Mbps per lane.
> 
> - added required ports property description to imx-media binding doc.
> 
> - removed event V4L2_EVENT_FRAME_TIMEOUT. On a frame timeout, which
>   is always unrecoverable, call vb2_queue_error() instead.
> 
> - export the remaining custom events to V4L2_EVENT_FRAME_INTERVAL_ERROR
>   and V4L2_EVENT_NEW_FRAME_BEFORE_EOF.
> 
> - vdic: use V4L2_CID_DEINTERLACING_MODE for motion compensation control
>   instead of a custom control.
> 
> - add v4l2_subdev_link_validate_frame_interval(). Call this in the
>   link_validate imx-media subdev callbacks and video-multiplexer.
> 
> - fix subdev event registration: implementation of subscribe_event()
>   and unsubscribe_event() subdev ops were missing.
> 
> - all calls from the pipeline to the sensor subdev have been removed.
>   Only the CSI subdev still refers to a sensor, and only to retrieve
>   its media bus config, which is necessary to setup the CSI interface.
> 
> - add mutex locks around the imx-media subdev op entry points.
> 
> - completed the propagation of all pad format parameters from sink
>   pads to source pads within every imx-media subdev.
> 
> - implement [gs]_frame_interval in all the imx-media subdevs.
> 
> - imx-ic-prpencvf: there isn't necessarily a CSI subdev in the pipeline
>   in the future, so make sure this is optional when calling the CSI's
>   FIM.
> 
> - the source pads that attach to capture device nodes now require the
>   IPU internal pixel codes. The capture device translates these to
>   v4l2 fourcc memory formats.
> 
> - fix control inheritance to the capture device. When the pipeline
>   was modified, the inherited controls were not being refreshed.
>   v4l2_pipeline_inherit_controls() is now called only in imx-media
>   link_notify() callback when a pipelink link is disabled or modified.
>   imx_media_find_pipeline_video_device() is created to locate the
>   capture device in the pipeline.
> 
> - fix a possible race when propagating formats to the capture device.
>   The subdevs and capture device use different mutex locks when setting
>   formats. imx_media_capture_device_set_format() is created which acquires
>   the capture device mutex when updating the capture device format.
> 
> - verify all subdevs were bound in the async completion callback.
>  
> 
> Philipp Zabel (7):
>   [media] dt-bindings: Add bindings for video-multiplexer device
>   ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
> connections
>   add mux and video interface bridge entity functions
>   platform: add video-multiplexer subdevice driver
>   media: imx: csi: fix crop rectangle changes in set_fmt
>   media: imx: csi: add frame skipping support
>   media: imx: csi: fix crop rectangle reset in sink set_fmt
> 
> Russell King (4):
>   media: imx: add support for bayer formats
>   media: imx: csi: add support for bayer formats
>   media: imx: mipi-csi2: enable setting and getting of frame rates
>   media: imx: csi/fim: add support for frame intervals
> 
> Steve Longerbeam (28):
>   [media] dt-bindings: Add bindings 

Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

[Fabio Estevam]

On Fri, Mar 10, 2017 at 3:59 PM, Troy Kisky
 wrote:
> On 3/9/2017 8:52 PM, Steve Longerbeam wrote:
>> There is a pin conflict with GPIO_6. This pin functions as a power
>> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
>> workaround for erratum ERR006687, to wake-up the ARM cores on normal
>> RX and TX packet done events. So we need to remove the h/w workaround
>> to support the OV5642. The result is that the CPUidle driver will no
>> longer allow entering the deep idle states on the sabrelite.
>>
>> This is a partial revert of
>>
>> commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
>>   interrupt.")
>> commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
>>   for ERR006687")
>>
>> Signed-off-by: Steve Longerbeam 
>> ---
>>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
>>  1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
>> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> index 8413179..89dce27 100644
>> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
>> @@ -270,9 +270,6 @@
>>   txd1-skew-ps = <0>;
>>   txd2-skew-ps = <0>;
>>   txd3-skew-ps = <0>;
>
> How about
>
> +#if !IS_ENABLED(CONFIG_VIDEO_OV5642)

Or maybe just create a new device tree for using the camera, like
imx6q-sabrelite-camera.dts.

This way we can keep the FEC erratum for the existing sabrelite dtb's.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

[Troy Kisky]

On 3/9/2017 8:52 PM, Steve Longerbeam wrote:
> There is a pin conflict with GPIO_6. This pin functions as a power
> input pin to the OV5642 camera sensor, but ENET uses it as the h/w
> workaround for erratum ERR006687, to wake-up the ARM cores on normal
> RX and TX packet done events. So we need to remove the h/w workaround
> to support the OV5642. The result is that the CPUidle driver will no
> longer allow entering the deep idle states on the sabrelite.
> 
> This is a partial revert of
> 
> commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
>   interrupt.")
> commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
>   for ERR006687")
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
> b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> index 8413179..89dce27 100644
> --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
> @@ -270,9 +270,6 @@
>   txd1-skew-ps = <0>;
>   txd2-skew-ps = <0>;
>   txd3-skew-ps = <0>;

How about

+#if !IS_ENABLED(CONFIG_VIDEO_OV5642)

> - interrupts-extended = < 6 IRQ_TYPE_LEVEL_HIGH>,
> -   < 0 119 IRQ_TYPE_LEVEL_HIGH>;
> - fsl,err006687-workaround-present;

+#endif

Is that allowed ?


>   status = "okay";
>  };
>  
> @@ -373,7 +370,6 @@
>   MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
>   /* Phy reset */
>   MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x000b0
> - MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>   >;
>   };
>  
> 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: Comparison to NULL could be written

[Arushi Singhal]

Fixed coding style for null comparisons in speakup driver to be more
consistant with the rest of the kernel coding style.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/selection.c   | 2 +-
 drivers/staging/speakup/varhandlers.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/selection.c 
b/drivers/staging/speakup/selection.c
index 3d15eec37163..08f68fc2864e 100644
--- a/drivers/staging/speakup/selection.c
+++ b/drivers/staging/speakup/selection.c
@@ -175,7 +175,7 @@ static struct speakup_paste_work speakup_paste_work = {
 
 int speakup_paste_selection(struct tty_struct *tty)
 {
-   if (cmpxchg(_paste_work.tty, NULL, tty) != NULL)
+   if (cmpxchg(_paste_work.tty, NULL, tty))
return -EBUSY;
 
tty_kref_get(tty);
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index cc984196020f..5910fe0b1365 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -98,7 +98,7 @@ void speakup_register_var(struct var_t *var)
}
}
p_header = var_ptrs[var->var_id];
-   if (p_header->data != NULL)
+   if (p_header->data)
return;
p_header->data = var;
switch (p_header->var_type) {
@@ -210,11 +210,11 @@ int spk_set_num_var(int input, struct st_var_header *var, 
int how)
return -ERANGE;
 
var_data->u.n.value = val;
-   if (var->var_type == VAR_TIME && p_val != NULL) {
+   if (var->var_type == VAR_TIME && p_val) {
*p_val = msecs_to_jiffies(val);
return 0;
}
-   if (p_val != NULL)
+   if (p_val)
*p_val = val;
if (var->var_id == PUNC_LEVEL) {
spk_punc_mask = spk_punc_masks[val];
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: fixes braces {} should be used on all arms of this statement

[Arushi Singhal]

This patch fixes the checks reported by checkpatch.pl
for braces {} should be used on all arms of this statement.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c   |  3 ++-
 drivers/staging/speakup/speakup_decext.c |  6 +++---
 drivers/staging/speakup/speakup_decpc.c  |  6 +++---
 drivers/staging/speakup/speakup_dectlk.c |  6 +++---
 drivers/staging/speakup/varhandlers.c| 12 +++-
 5 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index a3daf4ae5c0a..47cea629ba0b 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -408,8 +408,9 @@ static void say_attributes(struct vc_data *vc)
if (bg > 7) {
synth_printf(" %s ", spk_msg_get(MSG_ON_BLINKING));
bg -= 8;
-   } else
+   } else {
synth_printf(" %s ", spk_msg_get(MSG_ON));
+   }
synth_printf("%s\n", spk_msg_get(MSG_COLORS_START + bg));
 }
 
diff --git a/drivers/staging/speakup/speakup_decext.c 
b/drivers/staging/speakup/speakup_decext.c
index 5f9f3a7543db..6ebd56e07e71 100644
--- a/drivers/staging/speakup/speakup_decext.c
+++ b/drivers/staging/speakup/speakup_decext.c
@@ -193,11 +193,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
spk_serial_out(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 600eb057f830..dc860c4b8279 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -410,11 +410,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
dt_sendchar(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/speakup_dectlk.c 
b/drivers/staging/speakup/speakup_dectlk.c
index 26036050cdb2..2429232ee649 100644
--- a/drivers/staging/speakup/speakup_dectlk.c
+++ b/drivers/staging/speakup/speakup_dectlk.c
@@ -258,11 +258,11 @@ static void do_catch_up(struct spk_synth *synth)
spin_lock_irqsave(_info.spinlock, flags);
synth_buffer_getc();
spin_unlock_irqrestore(_info.spinlock, flags);
-   if (ch == '[')
+   if (ch == '[') {
in_escape = 1;
-   else if (ch == ']')
+   } else if (ch == ']') {
in_escape = 0;
-   else if (ch <= SPACE) {
+   } else if (ch <= SPACE) {
if (!in_escape && strchr(",.!?;:", last))
spk_serial_out(PROCSPEECH);
if (time_after_eq(jiffies, jiff_max)) {
diff --git a/drivers/staging/speakup/varhandlers.c 
b/drivers/staging/speakup/varhandlers.c
index 5910fe0b1365..d37d24e26641 100644
--- a/drivers/staging/speakup/varhandlers.c
+++ b/drivers/staging/speakup/varhandlers.c
@@ -258,10 +258,11 @@ int spk_set_string_var(const char *page, struct 
st_var_header *var, int len)
if (var->p_val != var_data->u.s.default_val)
strcpy((char *)var->p_val, var_data->u.s.default_val);
return -ERESTART;
-   } else if (var->p_val)
+   } else if (var->p_val) {
strcpy((char *)var->p_val, page);
-   else
+   } else {
return -E2BIG;
+   }
return 0;
 }
 
@@ -281,17 +282,18 @@ int spk_set_mask_bits(const char *input, const int which, 
const int how)
spk_chartab[*cp] &= ~mask;
}
cp = (u_char *)input;
-   if (!cp)
+   if (!cp) {
cp = spk_punc_info[which].value;
-   else {
+   } else {
for (; *cp; cp++) {
if (*cp < SPACE)

[PATCH] Add blank line after function/struct/union/enum declarations

[Arushi Singhal]

This patch fixes the warnings reported by checkpatch.pl
for please use a blank line after function/struct/union/enum
declarations.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 1 +
 drivers/staging/speakup/serialio.c | 1 +
 drivers/staging/speakup/speakup_dtlk.c | 1 +
 3 files changed, 3 insertions(+)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 01eabc19039c..17df20ec94be 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -108,6 +108,7 @@ enum {
CT_Window,
CT_Max
 };
+
 #define read_all_mode CT_Max
 
 static struct tty_struct *tty;
diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 7e6bc3b05da3..9b2626e85042 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -21,6 +21,7 @@ static void start_serial_interrupt(int irq);
 static const struct old_serial_port rs_table[] = {
SERIAL_PORT_DFNS
 };
+
 static const struct old_serial_port *serstate;
 static int timeouts;
 
diff --git a/drivers/staging/speakup/speakup_dtlk.c 
b/drivers/staging/speakup/speakup_dtlk.c
index 1ebe5012ec0b..e36360f65f36 100644
--- a/drivers/staging/speakup/speakup_dtlk.c
+++ b/drivers/staging/speakup/speakup_dtlk.c
@@ -43,6 +43,7 @@ static int port_forced;
 static unsigned int synth_portlist[] = {
 0x25e, 0x29e, 0x2de, 0x31e, 0x35e, 0x39e, 0
 };
+
 static u_char synth_status;
 
 static struct var_t vars[] = {
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: Blank lines removed after an open brace '{'

[Arushi Singhal]

Blank lines aren't necessary after an open brace '{' as reported by
Checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/kobjects.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/speakup/kobjects.c 
b/drivers/staging/speakup/kobjects.c
index edde9e68779e..441f14f07382 100644
--- a/drivers/staging/speakup/kobjects.c
+++ b/drivers/staging/speakup/kobjects.c
@@ -761,7 +761,6 @@ static ssize_t message_store_helper(const char *buf, size_t 
count,
enum msg_index_t curmessage;
 
while (cp < end) {
-
while ((cp < end) && (*cp == ' ' || *cp == '\t'))
cp++;
 
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

Hi Hans,

On 03/10/2017 04:03 AM, Hans Verkuil wrote:

On 10/03/17 05:52, Steve Longerbeam wrote:

Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
output device has measured an interval between the reception or transmit
completion of two consecutive frames of video that is outside the nominal
frame interval by some tolerance value.


Reading back what was said on this I agree with Sakari that this doesn't
belong here.

Userspace can detect this just as easily (if not easier) with a timeout.




Unfortunately measuring frame intervals from userland is not accurate
enough for i.MX6.

The issue here is that the IPUv3, specifically the CSI unit, can
permanently lose vertical sync if there are truncated frames sent
on the bt.656 bus. We have seen a single missing line of video cause
loss of vertical sync. The only way to correct this is to shutdown
the IPU capture hardware and restart, which can be accomplished
simply by restarting streaming from userland.

There are no other indicators from the sensor about these short
frame events (believe me, we've exhausted all avenues with the ADV718x).
And the IPUv3 DMA engine has no status indicators for short frames
either. So the only way to detect them is by measuring frame intervals.

The intervals have to be able to resolve a single line of missing video.
With a PAL video source that requires better than 58 usec accuracy.

There is too much uncertainty to resolve this at user level. The
driver is able to resolve this by measuring intervals between hardware
interrupts as long as interrupt latency is reasonably low, and we
have another method using the i.MX6 hardware input capture support
that can measure these intervals very accurately with no errors
introduced by interrupt latency.

I made this event a private event to imx-media driver in a previous
iteration, so I can return it to a private event, but this can't be
done at user level.

Steve






Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
 Documentation/media/videodev2.h.rst.exceptions  | 1 +
 include/uapi/linux/videodev2.h  | 1 +
 3 files changed, 8 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index 8d663a7..dc77363 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -197,6 +197,12 @@ call.
the regions changes. This event has a struct
:c:type:`v4l2_event_motion_det`
associated with it.
+* - ``V4L2_EVENT_FRAME_INTERVAL_ERROR``
+  - 7
+  - This event is triggered when the video capture or output device
+   has measured an interval between the reception or transmit
+   completion of two consecutive frames of video that is outside
+   the nominal frame interval by some tolerance value.
 * - ``V4L2_EVENT_PRIVATE_START``
   - 0x0800
   - Base event number for driver-private events.
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index e11a0d0..c7d8fad 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -459,6 +459,7 @@ replace define V4L2_EVENT_CTRL event-type
 replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
+replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
 replace define V4L2_EVENT_PRIVATE_START event-type

 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 45184a2..cf5a0d0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2131,6 +2131,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_FRAME_INTERVAL_ERROR7
 #define V4L2_EVENT_PRIVATE_START   0x0800

 /* Payload for V4L2_EVENT_VSYNC */





___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH] staging: speakup: Avoid multiple assignments on same line

[Julia Lawall]

On Fri, 10 Mar 2017, Arushi Singhal wrote:

> Should I resend the patch

Maybe let it go.  If Greg asked for a resend, he's probably fine with it
as is.  It's more me who would rather know whether it is something I have
seen before :)

julia

>
> On Friday, March 10, 2017 at 10:50:28 PM UTC+5:30, Julia Lawall wrote:
>
>
>   On Fri, 10 Mar 2017, Arushi Singhal wrote:
>
>   > This patch fixes the checkpatch.pl warning "multiple
>   assignments
>   > should be avoided."
>
>   Is this something that you have sent before that Greg asked you
>   to resend?
>   It could be good to put RESEND in [PATCH] in that case.
>
>   julia
>
>   >
>   > Signed-off-by: Arushi Singhal 
>   > ---
>   >  drivers/staging/speakup/main.c | 18 --
>   >  1 file changed, 12 insertions(+), 6 deletions(-)
>   >
>   > diff --git a/drivers/staging/speakup/main.c
>   b/drivers/staging/speakup/main.c
>   > index c1c3ee7dc95a..6c21ae1ae2d3 100644
>   > --- a/drivers/staging/speakup/main.c
>   > +++ b/drivers/staging/speakup/main.c
>   > @@ -269,9 +269,12 @@ static unsigned char
>   get_attributes(struct vc_data *vc, u16 *pos)
>   >
>   >  static void speakup_date(struct vc_data *vc)
>   >  {
>   > -spk_x = spk_cx = vc->vc_x;
>   > -spk_y = spk_cy = vc->vc_y;
>   > -spk_pos = spk_cp = vc->vc_pos;
>   > +spk_x = vc->vc_x;
>   > +spk_cx = spk_x;
>   > +spk_y = vc->vc_y;
>   > +spk_cy = spk_y;
>   > +spk_pos = vc->vc_pos;
>   > +spk_cp = spk_pos;
>   >  spk_old_attr = spk_attr;
>   >  spk_attr = get_attributes(vc, (u_short *)spk_pos);
>   >  }
>   > @@ -1643,9 +1646,12 @@ static int speak_highlight(struct
>   vc_data *vc)
>   >  spk_do_flush();
>   >
>    spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
>   >    
>    speakup_console[vc_num]->ht.highsize[hc]);
>   > -spk_pos = spk_cp =
>   speakup_console[vc_num]->ht.rpos[hc];
>   > -spk_x = spk_cx =
>   speakup_console[vc_num]->ht.rx[hc];
>   > -spk_y = spk_cy =
>   speakup_console[vc_num]->ht.ry[hc];
>   > +spk_pos =
>   speakup_console[vc_num]->ht.rpos[hc];
>   > +spk_cp =
>   speakup_console[vc_num]->ht.rpos[hc];
>   > +spk_x = speakup_console[vc_num]->ht.rx[hc];
>   > +spk_cx = speakup_console[vc_num]->ht.rx[hc];
>   > +spk_y = speakup_console[vc_num]->ht.ry[hc];
>   > +spk_cy = speakup_console[vc_num]->ht.ry[hc];
>   >  return 1;
>   >  }
>   >  return 0;
>   > --
>   > 2.11.0
>   >
>   > --
>   > You received this message because you are subscribed to the
>   Google Groups "outreachy-kernel" group.
>   > To unsubscribe from this group and stop receiving emails from
>   it, send an email to outreachy-kern...@googlegroups.com.
>   > To post to this group, send email to
>   outreach...@googlegroups.com.
>   > To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/20170310171337.GA4940%40
>   arushi-HP-Pavilion-Notebook.
>   > For more options, visit https://groups.google.com/d/optout.
>   >
>
> --
> You received this message because you are subscribed to the Google Groups
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web 
> visithttps://groups.google.com/d/msgid/outreachy-kernel/3f1d5d12-ab81-46ae-84a7-
> 9dd421baec05%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Outreachy kernel] [PATCH] staging: speakup: Avoid multiple assignments on same line

[Julia Lawall]

On Fri, 10 Mar 2017, Arushi Singhal wrote:

> This patch fixes the checkpatch.pl warning "multiple assignments
> should be avoided."

Is this something that you have sent before that Greg asked you to resend?
It could be good to put RESEND in [PATCH] in that case.

julia

>
> Signed-off-by: Arushi Singhal 
> ---
>  drivers/staging/speakup/main.c | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
> index c1c3ee7dc95a..6c21ae1ae2d3 100644
> --- a/drivers/staging/speakup/main.c
> +++ b/drivers/staging/speakup/main.c
> @@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
> u16 *pos)
>
>  static void speakup_date(struct vc_data *vc)
>  {
> - spk_x = spk_cx = vc->vc_x;
> - spk_y = spk_cy = vc->vc_y;
> - spk_pos = spk_cp = vc->vc_pos;
> + spk_x = vc->vc_x;
> + spk_cx = spk_x;
> + spk_y = vc->vc_y;
> + spk_cy = spk_y;
> + spk_pos = vc->vc_pos;
> + spk_cp = spk_pos;
>   spk_old_attr = spk_attr;
>   spk_attr = get_attributes(vc, (u_short *)spk_pos);
>  }
> @@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
>   spk_do_flush();
>   spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
>   speakup_console[vc_num]->ht.highsize[hc]);
> - spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> - spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
> - spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
> + spk_pos = speakup_console[vc_num]->ht.rpos[hc];
> + spk_cp = speakup_console[vc_num]->ht.rpos[hc];
> + spk_x = speakup_console[vc_num]->ht.rx[hc];
> + spk_cx = speakup_console[vc_num]->ht.rx[hc];
> + spk_y = speakup_console[vc_num]->ht.ry[hc];
> + spk_cy = speakup_console[vc_num]->ht.ry[hc];
>   return 1;
>   }
>   return 0;
> --
> 2.11.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170310171337.GA4940%40arushi-HP-Pavilion-Notebook.
> For more options, visit https://groups.google.com/d/optout.
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: speakup: Avoid multiple assignments on same line

[Arushi Singhal]

This patch fixes the checkpatch.pl warning "multiple assignments
should be avoided."

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index c1c3ee7dc95a..6c21ae1ae2d3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -269,9 +269,12 @@ static unsigned char get_attributes(struct vc_data *vc, 
u16 *pos)
 
 static void speakup_date(struct vc_data *vc)
 {
-   spk_x = spk_cx = vc->vc_x;
-   spk_y = spk_cy = vc->vc_y;
-   spk_pos = spk_cp = vc->vc_pos;
+   spk_x = vc->vc_x;
+   spk_cx = spk_x;
+   spk_y = vc->vc_y;
+   spk_cy = spk_y;
+   spk_pos = vc->vc_pos;
+   spk_cp = spk_pos;
spk_old_attr = spk_attr;
spk_attr = get_attributes(vc, (u_short *)spk_pos);
 }
@@ -1643,9 +1646,12 @@ static int speak_highlight(struct vc_data *vc)
spk_do_flush();
spkup_write(speakup_console[vc_num]->ht.highbuf[hc],
speakup_console[vc_num]->ht.highsize[hc]);
-   spk_pos = spk_cp = speakup_console[vc_num]->ht.rpos[hc];
-   spk_x = spk_cx = speakup_console[vc_num]->ht.rx[hc];
-   spk_y = spk_cy = speakup_console[vc_num]->ht.ry[hc];
+   spk_pos = speakup_console[vc_num]->ht.rpos[hc];
+   spk_cp = speakup_console[vc_num]->ht.rpos[hc];
+   spk_x = speakup_console[vc_num]->ht.rx[hc];
+   spk_cx = speakup_console[vc_num]->ht.rx[hc];
+   spk_y = speakup_console[vc_num]->ht.ry[hc];
+   spk_cy = speakup_console[vc_num]->ht.ry[hc];
return 1;
}
return 0;
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 10, 2017 at 03:57:09PM +, Russell King - ARM Linux wrote:
> Enabling debug output in gstreamer's v4l2src plugin confirms that
> the kernel's bayer format are totally hidden from gstreamer when
> linked with libv4l2, but are present when it isn't linked with
> libv4l2.

Here's the information to back up my claims:

root@hbi2ex:~# v4l2-ctl -d 6 --list-formats-ext
ioctl: VIDIOC_ENUM_FMT
Index   : 0
Type: Video Capture
Pixel Format: 'RGGB'
Name: 8-bit Bayer RGRG/GBGB

root@hbi2ex:~# DISPLAY=:0 GST_DEBUG_NO_COLOR=1 GST_DEBUG=v4l2:9 gst-launch-1.0 
v4l2src device=/dev/video6 ! bayer2rgbneon ! xvimagesink > gst-v4l2-1.log 2>&1
root@hbi2ex:~# cut -b65- gst-v4l2-1.log|less
v4l2_calls.c:519:gst_v4l2_open: Trying to open device /dev/video6
v4l2_calls.c:69:gst_v4l2_get_capabilities: getting capabilities
v4l2_calls.c:77:gst_v4l2_get_capabilities: driver:  
'imx-media-camif'
v4l2_calls.c:78:gst_v4l2_get_capabilities: card:
'imx-media-camif'
v4l2_calls.c:79:gst_v4l2_get_capabilities: bus_info:''
v4l2_calls.c:80:gst_v4l2_get_capabilities: version: 00040a00
v4l2_calls.c:81:gst_v4l2_get_capabilities: capabilites: 8521
...
v4l2_calls.c:258:gst_v4l2_fill_lists:   controls+menus
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 
v4l2_calls.c:319:gst_v4l2_fill_lists: starting control class 'User 
Controls'
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 00980001
v4l2_calls.c:389:gst_v4l2_fill_lists: Adding ControlID 
white_balance_automatic (98090c)
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 0098090c
v4l2_calls.c:389:gst_v4l2_fill_lists: Adding ControlID gamma (980910)
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 00980910
v4l2_calls.c:389:gst_v4l2_fill_lists: Adding ControlID gain (980913)
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 00980913
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 00980914
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 00980915
v4l2_calls.c:319:gst_v4l2_fill_lists: starting control class 'Camera 
Controls'
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009a0001
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID 
exposure_time_absolute (9a0902) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009a0902
v4l2_calls.c:319:gst_v4l2_fill_lists: starting control class 'Image 
Source Controls'
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0001
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID vertical_blanking 
(9e0901) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0901
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID horizontal_blanking 
(9e0902) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0902
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID analogue_gain 
(9e0903) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0903
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID red_pixel_value 
(9e0904) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0904
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID green_red_pixel_value 
(9e0905) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0905
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID blue_pixel_value 
(9e0906) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0906
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID 
green_blue_pixel_value (9e0907) unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009e0907
v4l2_calls.c:319:gst_v4l2_fill_lists: starting control class 'Image 
Processing Controls'
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009f0001
v4l2_calls.c:340:gst_v4l2_fill_lists: Control type for 'Pixel Rate' 
not suppored for extra controls.
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID Pixel Rate (9f0902) 
unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009f0902
v4l2_calls.c:382:gst_v4l2_fill_lists: ControlID test_pattern (9f0903) 
unhandled, FIXME
v4l2_calls.c:278:gst_v4l2_fill_lists: checking control 009f0903
v4l2_calls.c:284:gst_v4l2_fill_lists: controls finished
v4l2_calls.c:451:gst_v4l2_fill_lists: done
v4l2_calls.c:587:gst_v4l2_open: Opened device 'imx-media-camif' 
(/dev/video6) successfully
gstv4l2object.c:804:gst_v4l2_set_defaults: tv_norm=0x0, norm=(nil)
v4l2_calls.c:734:gst_v4l2_get_norm: getting norm
v4l2_calls.c:1021:gst_v4l2_get_input: trying to get input
v4l2_calls.c:1031:gst_v4l2_get_input: input: 0

gstv4l2object.c:1106:gst_v4l2_object_fill_format_list: getting src 
format enumerations
gstv4l2object.c:1124:gst_v4l2_object_fill_format_list: index:   0
gstv4l2object.c:1125:gst_v4l2_object_fill_format_list: type:1
gstv4l2object.c:1126:gst_v4l2_object_fill_format_list: flags:   
0002
gstv4l2object.c:1128:gst_v4l2_object_fill_format_list: description: 
'RGB3'
gstv4l2object.c:1130:gst_v4l2_object_fill_format_list: 

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/10/2017 06:27 AM, Brian Starkey wrote:
> On Fri, Mar 10, 2017 at 11:46:42AM +, Robin Murphy wrote:
>> On 10/03/17 10:31, Brian Starkey wrote:
>>> Hi,
>>>
>>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
 On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>>
>>> [snip]
>>>
>
> For me those patches are going in the right direction.
>
> I still have few questions:
> - since alignment management has been remove from ion-core, should it
> be also removed from ioctl structure ?

 Yes, I think I'm going to go with the suggestion to fixup the ABI
 so we don't need the compat layer and as part of that I'm also
 dropping the align argument.

>>>
>>> Is the only motivation for removing the alignment parameter that
>>> no-one got around to using it for something useful yet?
>>> The original comment was true - different devices do have different
>>> alignment requirements.
>>>
>>> Better alignment can help SMMUs use larger blocks when mapping,
>>> reducing TLB pressure and the chance of a page table walk causing
>>> display underruns.
>>
>> For that use-case, though, alignment alone doesn't necessarily help -
>> you need the whole allocation granularity to match your block size (i.e.
>> given a 1MB block size, asking for 17KB and getting back 17KB starting
>> at a 1MB boundary doesn't help much - that whole 1MB needs to be
>> allocated and everyone needs to know it to ensure that the whole lot can
>> be mapped safely). Now, whether it's down to the callers or the heap
>> implementations to decide and enforce that granularity is another
>> question, but provided allocations are at least naturally aligned to
>> whatever the granularity is (which is a reasonable assumption to bake
>> in) then it's all good.
>>
>> Robin.
> 
> Agreed, alignment alone isn't enough. But lets assume that an app
> knows what a "good" granularity is, and always asks for allocation
> sizes which are suitably rounded to allow blocks to be used. Currently
> it looks like a "standard" ION_HEAP_TYPE_CARVEOUT heap would give me
> back just a PAGE_SIZE aligned buffer. So even *if* the caller knows
> its desired block size, there's no way for it to get guaranteed better
> alignment, which wouldn't be a bad feature to have.
> 
> Anyway as Daniel and Rob say, if the interface is designed properly
> this kind of extension would be possible later, or you can have a
> special heap with a larger granule.
> 
> I suppose it makes sense to remove it while there's no-one actually
> implementing it, in case an alternate method proves more usable.
> 
> -Brian

Part of the reason I want to remove it is to avoid confusion over
callers thinking it will do anything on most heaps. I agree being
able to specify a larger granularity would be beneficial but I
don't think a dedicated field in the ABI is the right approach.

Thanks,
Laura

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v2 12/32] x86: Add early boot support when running with SEV active

[Brijesh Singh]

Hi Boris and Paolo,

On 03/09/2017 10:29 AM, Borislav Petkov wrote:

On Thu, Mar 09, 2017 at 05:13:33PM +0100, Paolo Bonzini wrote:

This is not how you check if running under a hypervisor; you should
check the HYPERVISOR bit, i.e. bit 31 of cpuid(1).ecx.  This in turn
tells you if leaf 0x4000 is valid.


Ah, good point, I already do that in the microcode loader :)

/*
 * CPUID(1).ECX[31]: reserved for hypervisor use. This is still not
 * completely accurate as xen pv guests don't see that CPUID bit set but
 * that's good enough as they don't land on the BSP path anyway.
 */
if (native_cpuid_ecx(1) & BIT(31))
return *res;


That said, the main issue with this function is that it hardcodes the
behavior for KVM.  It is possible that another hypervisor defines its
0x4001 leaf in such a way that KVM_FEATURE_SEV has a different meaning.

Instead, AMD should define a "well-known" bit in its own space (i.e.
0x80xx) that is only used by hypervisors that support SEV.  This is
similar to how Intel defined one bit in leaf 1 to say "is leaf
0x4000 valid".


+   if (eax > 0x4000) {
+   eax = 0x4001;
+   ecx = 0;
+   native_cpuid(, , , );
+   if (!(eax & BIT(KVM_FEATURE_SEV)))
+   goto out;
+
+   eax = 0x801f;
+   ecx = 0;
+   native_cpuid(, , , );
+   if (!(eax & 1))


Right, so this is testing CPUID_0x801f_ECX(0)[0], SME. Why not
simply set that bit for the guest too, in kvm?



CPUID_8000_001F[EAX] indicates whether the feature is supported.
CPUID_0x801F[EAX]:
 * Bit 0 - SME supported
 * Bit 1 - SEV supported
 * Bit 3 - SEV-ES supported

We can use MSR_K8_SYSCFG[MemEncryptionModeEnc] to check if memory encryption is 
enabled.
Currently, KVM returns zero when guest OS read MSR_K8_SYSCFG. I can update my 
patch sets
to set this bit for SEV enabled guests.

We could update this patch to use the below logic:

 * CPUID(0) - Check for AuthenticAMD
 * CPID(1) - Check if under hypervisor
 * CPUID(0x8000) - Check for highest supported leaf
 * CPUID(0x801F).EAX - Check for SME and SEV support
 * rdmsr (MSR_K8_SYSCFG)[MemEncryptionModeEnc] - Check if SMEE is set


Paolo,

One question, do we need "AuthenticAMD" check when we are running under 
hypervisor ?
I was looking at qemu code and found that qemu exposes parameters to change the 
CPU
vendor id. The above check will fail if user changes the vendor id while 
launching
the SEV guest.

-Brijesh

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 10, 2017 at 12:26:34PM -0300, Mauro Carvalho Chehab wrote:
> Hi Russell,
> 
> Em Fri, 10 Mar 2017 13:07:33 +
> Russell King - ARM Linux  escreveu:
> 
> > The idea that the v4l libraries should intercept the format negotiation
> > between the application and kernel is a particularly painful one - the
> > default gstreamer build detects the v4l libraries, and links against it.
> > That much is fine.
> > 
> > However, the problem comes when you're trying to use bayer formats. The
> > v4l libraries "helpfully" (or rather unhelpfully) intercept the format
> > negotiation, and decide that they'll invoke v4lconvert to convert the
> > bayer to RGB for you, whether you want them to do that or not.
> > 
> > v4lconvert may not be the most efficient way to convert, or even what
> > is desired (eg, you may want to receive the raw bayer image.)  However,
> > since the v4l libraries/v4lconvert gives you no option but to have its
> > conversion forced into the pipeline, other options (such as using the
> > gstreamer neon accelerated de-bayer plugin) isn't an option 
> 
> That's not true. There is an special flag, used only by libv4l2
> emulated formats, that indicates when a video format is handled
> via v4lconvert:

I'm afraid that my statement comes from trying to use gstreamer with
libv4l2 and _not_ being able to use the 8-bit bayer formats there at
all - they are simply not passed across to the application through
libv4l2/v4lconvert.

Instead, the formats that are passed across are the emulated formats.
As I said above, that forces applications to use only the v4lconvert
formats, the raw formats are not available.

So, the presence or absence of the V4L2_FMT_FLAG_EMULATED is quite
meaningless if you can't even enumerate the non-converted formats.

The problem comes from the "always needs conversion" stuff in
v4lconvert coupled with the way this subdev stuff works - since it
requires manual configuration of all the pads within the kernel
media pipeline, the kernel ends up only advertising _one_ format
to userspace - in my case, that's RGGB8.

When v4lconvert_create_with_dev_ops() enumerates the formats from
the kernel, it gets only RGGB8.  That causes always_needs_conversion
in there to remain true, so the special v4l control which enables/
disables conversion gets created with a default value of "true".
The RGGB8 bit is also set in data->supported_src_formats.

This causes v4lconvert_supported_dst_fmt_only() to return true.

What this all means is that v4lconvert_enum_fmt() will _not_ return
any of the kernel formats, only the faked formats.

Ergo, the RGGB8 format from the kernel is completely hidden from the
application, and only the emulated format is made available.  As I
said above, this forces v4lconvert's debayering on the application,
whether you want it or not.

In the gstreamer case, it knows nothing about this special control,
which means that trying to use this gstreamer pipeline:

$ gst-launch-1.0 v4l2src device=/dev/video6 ! bayer2rgbneon ! xvimagesink

is completely impossible without first rebuilding gstreamer _without_
libv4l support.  Build gstreamer without libv4l support, and the above
works.

Enabling debug output in gstreamer's v4l2src plugin confirms that
the kernel's bayer format are totally hidden from gstreamer when
linked with libv4l2, but are present when it isn't linked with
libv4l2.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Fri, 10 Mar 2017 15:20:48 +0100
Hans Verkuil  escreveu:

> 
> > As I've already mentioned, from talking about this with Mauro, it seems
> > Mauro is in agreement with permitting the control inheritence... I wish
> > Mauro would comment for himself, as I can't quote our private discussion
> > on the subject.  
> 
> I can't comment either, not having seen his mail and reasoning.

The rationale is that we should support the simplest use cases first.

In the case of the first MC-based driver (and several subsequent
ones), the simplest use case required MC, as it was meant to suport
a custom-made sophisticated application that required fine control
on each component of the pipeline and to allow their advanced
proprietary AAA userspace-based algorithms to work.

That's not true, for example, for the UVC driver. There, MC
is optional, as it should be.

> > Right now, my view is that v4l2 is currently being screwed up by people
> > with different opinions - there is no unified concensus on how any of
> > this stuff is supposed to work, everyone is pulling in different
> > directions.  That needs solving _really_ quickly, so I suggest that
> > v4l2 people urgently talk to each other and thrash out some of the
> > issues that Steve's patch set has brought up, and settle on a way
> > forward, rather than what is seemingly happening today - which is
> > everyone working in isolation of everyone else with their own bias on
> > how things should be done.  
> 
> The simple fact is that to my knowledge no other MC applications inherit
> controls from subdevs. Suddenly doing something different here seems very
> wrong to me and needs very good reasons.

That's because it was not needed before, as other subdev-based drivers
are meant to be used only on complex scenarios with custom-made apps.

Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: dvb-frontends: removed code in comments.

[Arushi Singhal]

Commenting Code Is a Bad Idea.
Comments are their to explain the code and how the code achieves its
goal and as codes in the comments  does not explain what the code is
doing so there is no use of commenting them.
So in this patch codes in the comments are removed.

Signed-off-by: Arushi Singhal 
---
 drivers/media/dvb-frontends/drxk_hard.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/drxk_hard.c 
b/drivers/media/dvb-frontends/drxk_hard.c
index 7e1bbbaad625..2fe493768003 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -5283,7 +5283,6 @@ static int qam_set_symbolrate(struct drxk_state *state)
/* Select & calculate correct IQM rate */
adc_frequency = (state->m_sys_clock_freq * 1000) / 3;
ratesel = 0;
-   /* printk(KERN_DEBUG "drxk: SR %d\n", state->props.symbol_rate); */
if (state->props.symbol_rate <= 1188750)
ratesel = 3;
else if (state->props.symbol_rate <= 2377500)
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] checkpatch cleanups

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver.

Arushi Singhal (2):
  staging: speakup: identation should use tabs
  staging: dvb-frontends: removed code in comments.

 drivers/media/dvb-frontends/drxk_hard.c |  1 -
 drivers/staging/speakup/speakup_dtlk.h  | 10 +-
 2 files changed, 5 insertions(+), 6 deletions(-)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: speakup: identation should use tabs

[Arushi Singhal]

Indentation should always use tabs and never spaces.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/speakup_dtlk.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/speakup/speakup_dtlk.h 
b/drivers/staging/speakup/speakup_dtlk.h
index b3b3cfc3db07..46d885fcfb20 100644
--- a/drivers/staging/speakup/speakup_dtlk.h
+++ b/drivers/staging/speakup/speakup_dtlk.h
@@ -24,11 +24,11 @@
 * usec later.
 */
 #define TTS_ALMOST_FULL0x08/* mask for AF bit: When set to 1,
-* indicates that less than 300 bytes
-* are available in the TTS input
-* buffer. AF is always 0 in the PCM,
-* TGN and CVSD modes.
-*/
+* indicates that less than 300 bytes
+* are available in the TTS input
+* buffer. AF is always 0 in the PCM,
+* TGN and CVSD modes.
+*/
 #define TTS_ALMOST_EMPTY 0x04  /* mask for AE bit: When set to 1,
 * indicates that less than 300 bytes
 * are remaining in DoubleTalk's input
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Hi Russell,

Em Fri, 10 Mar 2017 13:07:33 +
Russell King - ARM Linux  escreveu:

> The idea that the v4l libraries should intercept the format negotiation
> between the application and kernel is a particularly painful one - the
> default gstreamer build detects the v4l libraries, and links against it.
> That much is fine.
> 
> However, the problem comes when you're trying to use bayer formats. The
> v4l libraries "helpfully" (or rather unhelpfully) intercept the format
> negotiation, and decide that they'll invoke v4lconvert to convert the
> bayer to RGB for you, whether you want them to do that or not.
> 
> v4lconvert may not be the most efficient way to convert, or even what
> is desired (eg, you may want to receive the raw bayer image.)  However,
> since the v4l libraries/v4lconvert gives you no option but to have its
> conversion forced into the pipeline, other options (such as using the
> gstreamer neon accelerated de-bayer plugin) isn't an option 

That's not true. There is an special flag, used only by libv4l2
emulated formats, that indicates when a video format is handled
via v4lconvert:

* - ``V4L2_FMT_FLAG_EMULATED``
  - 0x0002
  - This format is not native to the device but emulated through
software (usually libv4l2), where possible try to use a native
format instead for better performance.

Using this flag, if the application supports a video format directly
supported by the hardware, it can use their own video format decoder.
If not, it is still possible to use the V4L2 hardware, by using
v4lconvert.

Unfortunately, very few applications currently check it.

I wrote a patch for zbar (a multi-format barcode reader) in the past,
adding a logic there that gives a high priority to hardware formats,
and a low priority to emulated ones:

https://lists.fedoraproject.org/pipermail/scm-commits/2010-December/537428.html

> without
> rebuilding gstreamer _without_ linking against the v4l libraries.

I guess it wouldn't be complex to add a logic similar to that at
gstreamer.

AFAIKT, there's another problem that would prevent to make
libv4l the default on gstreamer: right now, libv4l doesn't support
DMABUF. As gstreamer is being used on embedded hardware, I'd say
that DMABUF support should be default there.

Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Fri, 10 Mar 2017 13:54:28 +0100
Hans Verkuil  escreveu:

> > Devices that have complex pipeline that do essentially require using the
> > Media controller interface to configure them are out of that scope.
> >   
> 
> Way too much of how the MC devices should be used is in the minds of 
> developers.
> There is a major lack for good detailed documentation, utilities, compliance
> test (really needed!) and libv4l plugins.

Unfortunately, we merged an incomplete MC support at the Kernel. We knew
all the problems with MC-based drivers and V4L2 applications by the time
it was developed, and we requested Nokia developers (with was sponsoring MC
develoment, on that time) to work on a solution to allow standard V4L2
applications to work with MC based boards.

Unfortunately, we took the decision to merge MC without that, because 
Nokia was giving up on Linux development, and we didn't want to lose the
2 years of discussions and work around it, as Nokia employers were leaving
the company. Also, on that time, there was already some patches floating
around adding backward support via libv4l. Unfortunately, those patches
were never finished.

The net result is that MC was merged with some huge gaps, including
the lack of a proper solution for a generic V4L2 program to work
with V4L2 devices that use the subdev API.

That was not that bad by then, as MC was used only on cell phones
that run custom-made applications. 

The reallity changed, as now, we have lots of low cost SoC based
boards, used for all sort of purposes. So, we need a quick solution
for it.

In other words, while that would be acceptable support special apps
on really embedded systems, it is *not OK* for general purpose SoC
harware[1].

[1] I'm calling "general purpose SoC harware" those ARM boards
like Raspberry Pi that are shipped to the mass and used by a wide
range of hobbyists and other people that just wants to run Linux on
ARM. It is possible to buy such boards for a very cheap price,
making them to be used not only on special projects, where a custom
made application could be interesting, but also for a lot of
users that just want to run Linux on a low cost ARM board, while
keeping using standard V4L2 apps, like "camorama".

That's perhaps one of the reasons why it took a long time for us to
start receiving drivers upstream for such hardware: it is quite 
intimidating and not logical to require developers to implement
on their drivers 2 complex APIs (MC, subdev) for those
hardware that most users won't care. From user's perspective,
being able to support generic applications like "camorama" and
"zbar" is all they want.

In summary, I'm pretty sure we need to support standard V4L2 
applications on boards like Raspberry Pi and those low-cost 
SoC-based boards that are shipped to end users.

> Anyway, regarding this specific patch and for this MC-aware driver: no, you
> shouldn't inherit controls from subdevs. It defeats the purpose.

Sorry, but I don't agree with that. The subdev API is an optional API
(and even the MC API can be optional).

I see the rationale for using MC and subdev APIs on cell phones,
ISV and other embedded hardware, as it will allow fine-tuning
the driver's support to allow providing the required quality for
certain custom-made applications. but on general SoC hardware,
supporting standard V4L2 applications is a need.

Ok, perhaps supporting both subdev API and V4L2 API at the same
time doesn't make much sense. We could disable one in favor of the
other, either at compilation time or at runtime.

This way, if the subdev API is disabled, the driver will be
functional for V4L2-based applications that don't support neither
MC or subdev APIs.

> As mentioned, I will attempt to try and get some time to work on this
> later this year. Fingers crossed.

That will be good, and, once we have a solution that works, we can
work on cleanup the code, but, until then, drivers for arm-based boards
sold to end consumers should work out of the box with standard V4L2 apps.

While we don't have that, I'm OK to merge patches adding such support
upstream.

Thanks,
Mauro
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

On Fri, Mar 10, 2017 at 11:46:42AM +, Robin Murphy wrote:

On 10/03/17 10:31, Brian Starkey wrote:

Hi,

On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:

On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:


[snip]



For me those patches are going in the right direction.

I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed from ioctl structure ?


Yes, I think I'm going to go with the suggestion to fixup the ABI
so we don't need the compat layer and as part of that I'm also
dropping the align argument.



Is the only motivation for removing the alignment parameter that
no-one got around to using it for something useful yet?
The original comment was true - different devices do have different
alignment requirements.

Better alignment can help SMMUs use larger blocks when mapping,
reducing TLB pressure and the chance of a page table walk causing
display underruns.


For that use-case, though, alignment alone doesn't necessarily help -
you need the whole allocation granularity to match your block size (i.e.
given a 1MB block size, asking for 17KB and getting back 17KB starting
at a 1MB boundary doesn't help much - that whole 1MB needs to be
allocated and everyone needs to know it to ensure that the whole lot can
be mapped safely). Now, whether it's down to the callers or the heap
implementations to decide and enforce that granularity is another
question, but provided allocations are at least naturally aligned to
whatever the granularity is (which is a reasonable assumption to bake
in) then it's all good.

Robin.


Agreed, alignment alone isn't enough. But lets assume that an app
knows what a "good" granularity is, and always asks for allocation
sizes which are suitably rounded to allow blocks to be used. Currently
it looks like a "standard" ION_HEAP_TYPE_CARVEOUT heap would give me
back just a PAGE_SIZE aligned buffer. So even *if* the caller knows
its desired block size, there's no way for it to get guaranteed better
alignment, which wouldn't be a bad feature to have.

Anyway as Daniel and Rob say, if the interface is designed properly
this kind of extension would be possible later, or you can have a
special heap with a larger granule.

I suppose it makes sense to remove it while there's no-one actually
implementing it, in case an alternate method proves more usable.

-Brian





-Brian

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Hans Verkuil]

On 10/03/17 15:01, Russell King - ARM Linux wrote:
> On Fri, Mar 10, 2017 at 02:22:29PM +0100, Hans Verkuil wrote:
>> And nobody of the media core developers has the time to work on the docs,
>> utilities and libraries you need to make this all work cleanly and reliably.
> 
> Well, talking about docs, and in connection to control inheritence,
> this is already documented in at least three separate places:
> 
> Documentation/media/uapi/v4l/dev-subdev.rst:
> 
>   Controls
>   
>   ...
>   Depending on the driver, those controls might also be exposed through
>   one (or several) V4L2 device nodes.
> 
> Documentation/media/kapi/v4l2-subdev.rst:
> 
>   ``VIDIOC_QUERYCTRL``,
>   ``VIDIOC_QUERYMENU``,
>   ``VIDIOC_G_CTRL``,
>   ``VIDIOC_S_CTRL``,
>   ``VIDIOC_G_EXT_CTRLS``,
>   ``VIDIOC_S_EXT_CTRLS`` and
>   ``VIDIOC_TRY_EXT_CTRLS``:
>   
>   The controls ioctls are identical to the ones defined in V4L2. They
>   behave identically, with the only exception that they deal only with
>   controls implemented in the sub-device. Depending on the driver, 
> those
>   controls can be also be accessed through one (or several) V4L2 
> device
>   nodes.
> 
> Then there's Documentation/media/kapi/v4l2-controls.rst, which gives a
> step by step approach to the main video device inheriting controls from
> its subdevices, and it says:
> 
>   Inheriting Controls
>   ---
>   
>   When a sub-device is registered with a V4L2 driver by calling
>   v4l2_device_register_subdev() and the ctrl_handler fields of both 
> v4l2_subdev
>   and v4l2_device are set, then the controls of the subdev will become
>   automatically available in the V4L2 driver as well. If the subdev driver
>   contains controls that already exist in the V4L2 driver, then those will be
>   skipped (so a V4L2 driver can always override a subdev control).
>   
>   What happens here is that v4l2_device_register_subdev() calls
>   v4l2_ctrl_add_handler() adding the controls of the subdev to the controls
>   of v4l2_device.
> 
> So, either the docs are wrong, or the advice being mentioned in emails
> about subdev control inheritence is misleading.  Whatever, the two are
> currently inconsistent.

These docs were written for non-MC drivers, and for those the documentation
is correct. Unfortunately, this was never updated for MC drivers.

> As I've already mentioned, from talking about this with Mauro, it seems
> Mauro is in agreement with permitting the control inheritence... I wish
> Mauro would comment for himself, as I can't quote our private discussion
> on the subject.

I can't comment either, not having seen his mail and reasoning.

> Right now, my view is that v4l2 is currently being screwed up by people
> with different opinions - there is no unified concensus on how any of
> this stuff is supposed to work, everyone is pulling in different
> directions.  That needs solving _really_ quickly, so I suggest that
> v4l2 people urgently talk to each other and thrash out some of the
> issues that Steve's patch set has brought up, and settle on a way
> forward, rather than what is seemingly happening today - which is
> everyone working in isolation of everyone else with their own bias on
> how things should be done.

The simple fact is that to my knowledge no other MC applications inherit
controls from subdevs. Suddenly doing something different here seems very
wrong to me and needs very good reasons.

But yes, the current situation sucks. Yelling doesn't help though if nobody
has time and there are several other high-prio projects that need our
attention as well.

If you know a good kernel developer who has a few months to spare, please
point him/her in our direction!

Regards,

Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 10, 2017 at 02:22:29PM +0100, Hans Verkuil wrote:
> And nobody of the media core developers has the time to work on the docs,
> utilities and libraries you need to make this all work cleanly and reliably.

Well, talking about docs, and in connection to control inheritence,
this is already documented in at least three separate places:

Documentation/media/uapi/v4l/dev-subdev.rst:

  Controls
  
  ...
  Depending on the driver, those controls might also be exposed through
  one (or several) V4L2 device nodes.

Documentation/media/kapi/v4l2-subdev.rst:

  ``VIDIOC_QUERYCTRL``,
  ``VIDIOC_QUERYMENU``,
  ``VIDIOC_G_CTRL``,
  ``VIDIOC_S_CTRL``,
  ``VIDIOC_G_EXT_CTRLS``,
  ``VIDIOC_S_EXT_CTRLS`` and
  ``VIDIOC_TRY_EXT_CTRLS``:
  
  The controls ioctls are identical to the ones defined in V4L2. They
  behave identically, with the only exception that they deal only with
  controls implemented in the sub-device. Depending on the driver, those
  controls can be also be accessed through one (or several) V4L2 device
  nodes.

Then there's Documentation/media/kapi/v4l2-controls.rst, which gives a
step by step approach to the main video device inheriting controls from
its subdevices, and it says:

  Inheriting Controls
  ---
  
  When a sub-device is registered with a V4L2 driver by calling
  v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev
  and v4l2_device are set, then the controls of the subdev will become
  automatically available in the V4L2 driver as well. If the subdev driver
  contains controls that already exist in the V4L2 driver, then those will be
  skipped (so a V4L2 driver can always override a subdev control).
  
  What happens here is that v4l2_device_register_subdev() calls
  v4l2_ctrl_add_handler() adding the controls of the subdev to the controls
  of v4l2_device.

So, either the docs are wrong, or the advice being mentioned in emails
about subdev control inheritence is misleading.  Whatever, the two are
currently inconsistent.

As I've already mentioned, from talking about this with Mauro, it seems
Mauro is in agreement with permitting the control inheritence... I wish
Mauro would comment for himself, as I can't quote our private discussion
on the subject.

Right now, my view is that v4l2 is currently being screwed up by people
with different opinions - there is no unified concensus on how any of
this stuff is supposed to work, everyone is pulling in different
directions.  That needs solving _really_ quickly, so I suggest that
v4l2 people urgently talk to each other and thrash out some of the
issues that Steve's patch set has brought up, and settle on a way
forward, rather than what is seemingly happening today - which is
everyone working in isolation of everyone else with their own bias on
how things should be done.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Rob Clark]

On Fri, Mar 10, 2017 at 7:40 AM, Daniel Vetter  wrote:
> On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote:
>> Hi,
>>
>> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>>
>> [snip]
>>
>> > >
>> > > For me those patches are going in the right direction.
>> > >
>> > > I still have few questions:
>> > > - since alignment management has been remove from ion-core, should it
>> > > be also removed from ioctl structure ?
>> >
>> > Yes, I think I'm going to go with the suggestion to fixup the ABI
>> > so we don't need the compat layer and as part of that I'm also
>> > dropping the align argument.
>> >
>>
>> Is the only motivation for removing the alignment parameter that
>> no-one got around to using it for something useful yet?
>> The original comment was true - different devices do have different
>> alignment requirements.
>>
>> Better alignment can help SMMUs use larger blocks when mapping,
>> reducing TLB pressure and the chance of a page table walk causing
>> display underruns.
>
> Extending ioctl uapi is easy, trying to get rid of bad uapi is much
> harder. Given that right now we don't have an ion allocator that does
> alignment I think removing it makes sense. And if we go with lots of
> heaps, we might as well have an ion heap per alignment that your hw needs,
> so there's different ways to implement this in the future.

slight correction:  if you plan ahead (and do things like zero init if
userspace passes in a smaller ioctl struct like drm_ioctl does),
extending ioctl uapi is easy.. might be something worth fixing from
the get-go..

BR,
-R

> At least from the unix device memory allocator pov it's probably simpler
> to encode stuff like this into the heap name, instead of having to pass
> heap + list of additional properties/constraints.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v1] staging: media: Remove unused function atomisp_set_stop_timeout()

[simran singhal]

The function atomisp_set_stop_timeout on being called, simply returns
back. The function hasn't been mentioned in the TODO and doesn't have
FIXME code around. Hence, atomisp_set_stop_timeout and its calls have been
removed.

This was done using Coccinelle.

@@
identifier f;
@@

void f(...) {

-return;

}

Signed-off-by: simran singhal 
---
 v1:
   -Change Subject to include name of function
   -change commit message to include the coccinelle script
   
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c  | 1 -
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h   | 1 -
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c | 5 -
 3 files changed, 7 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index d9a5c24..9720756 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -1692,7 +1692,6 @@ void atomisp_wdt_work(struct work_struct *work)
}
}
 #endif
-   atomisp_set_stop_timeout(ATOMISP_CSS_STOP_TIMEOUT_US);
dev_err(isp->dev, "timeout recovery handling done\n");
atomic_set(>wdt_work_queued, 0);
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
index e6b0cce..fb8b8fa 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat.h
@@ -660,7 +660,6 @@ int atomisp_css_set_acc_parameters(struct atomisp_acc_fw 
*acc_fw);
 int atomisp_css_isr_thread(struct atomisp_device *isp,
   bool *frame_done_found,
   bool *css_pipe_done);
-void atomisp_set_stop_timeout(unsigned int timeout);
 
 bool atomisp_css_valid_sof(struct atomisp_device *isp);
 
diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
index 6697d72..cfa0ad4 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_css20.c
@@ -4699,11 +4699,6 @@ int atomisp_css_isr_thread(struct atomisp_device *isp,
return 0;
 }
 
-void atomisp_set_stop_timeout(unsigned int timeout)
-{
-   return;
-}
-
 bool atomisp_css_valid_sof(struct atomisp_device *isp)
 {
unsigned int i, j;
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Hans Verkuil]

On 10/03/17 14:07, Russell King - ARM Linux wrote:
> On Fri, Mar 10, 2017 at 01:54:28PM +0100, Hans Verkuil wrote:
>> But there was always meant to be a layer (libv4l plugin) that could be
>> used to setup a 'default scenario' that existing applications could use,
>> but that was never enforced, sadly.
> 
> However, there's other painful issues lurking in userspace, particularly
> to do with the v4l libraries.
> 
> The idea that the v4l libraries should intercept the format negotiation
> between the application and kernel is a particularly painful one - the
> default gstreamer build detects the v4l libraries, and links against it.
> That much is fine.
> 
> However, the problem comes when you're trying to use bayer formats. The
> v4l libraries "helpfully" (or rather unhelpfully) intercept the format
> negotiation, and decide that they'll invoke v4lconvert to convert the
> bayer to RGB for you, whether you want them to do that or not.
> 
> v4lconvert may not be the most efficient way to convert, or even what
> is desired (eg, you may want to receive the raw bayer image.)  However,
> since the v4l libraries/v4lconvert gives you no option but to have its
> conversion forced into the pipeline, other options (such as using the
> gstreamer neon accelerated de-bayer plugin) isn't an option without
> rebuilding gstreamer _without_ linking against the v4l libraries.
> 
> At that point, saying "this should be done in a libv4l plugin" becomes
> a total nonsense, because if you need to avoid libv4l due to its
> stupidities, you don't get the benefit of subdevs, and it yet again
> _forces_ people down the route of custom applications.
> 
> So, I really don't agree with pushing this into a userspace library
> plugin - at least not with the current state there.
> 
> _At least_ the debayering in the v4l libraries needs to become optional.
> 

I *thought* that when a plugin is used the format conversion code was disabled.
But I'm not sure.

The whole problem is that we still don't have a decent plugin for an MC driver.
There is one for the exynos4 floating around, but it's still not accepted.

Companies write the driver, but the plugin isn't really needed since their
customers won't use it anyway since they make their own embedded driver.

And nobody of the media core developers has the time to work on the docs,
utilities and libraries you need to make this all work cleanly and reliably.

As mentioned, I will attempt to try and get some time to work on this
later this year. Fingers crossed.

We also have a virtual MC driver floating around. I've pinged the author if
she can fix the last round of review comments and post a new version. Having
a virtual driver makes life much easier when writing docs, utilities, etc.
since you don't need real hardware which can be hard to obtain and run.

Again, I agree completely with you. But we don't have many core developers
who can do something like this, and it's even harder for them to find the time.

Solutions on a postcard...

BTW, Steve: this has nothing to do with your work, it's a problem in our 
subsystem.

Regards,

Hans
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Russell King - ARM Linux]

On Fri, Mar 10, 2017 at 01:54:28PM +0100, Hans Verkuil wrote:
> But there was always meant to be a layer (libv4l plugin) that could be
> used to setup a 'default scenario' that existing applications could use,
> but that was never enforced, sadly.

However, there's other painful issues lurking in userspace, particularly
to do with the v4l libraries.

The idea that the v4l libraries should intercept the format negotiation
between the application and kernel is a particularly painful one - the
default gstreamer build detects the v4l libraries, and links against it.
That much is fine.

However, the problem comes when you're trying to use bayer formats. The
v4l libraries "helpfully" (or rather unhelpfully) intercept the format
negotiation, and decide that they'll invoke v4lconvert to convert the
bayer to RGB for you, whether you want them to do that or not.

v4lconvert may not be the most efficient way to convert, or even what
is desired (eg, you may want to receive the raw bayer image.)  However,
since the v4l libraries/v4lconvert gives you no option but to have its
conversion forced into the pipeline, other options (such as using the
gstreamer neon accelerated de-bayer plugin) isn't an option without
rebuilding gstreamer _without_ linking against the v4l libraries.

At that point, saying "this should be done in a libv4l plugin" becomes
a total nonsense, because if you need to avoid libv4l due to its
stupidities, you don't get the benefit of subdevs, and it yet again
_forces_ people down the route of custom applications.

So, I really don't agree with pushing this into a userspace library
plugin - at least not with the current state there.

_At least_ the debayering in the v4l libraries needs to become optional.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 1/2] staging: css2400/sh_css: Remove parentheses from return arguments

[simran singhal]

The sematic patch used for this is:
@@
identifier i;
constant c;
@@
return
- (
\(i\|-i\|i(...)\|c\)
- )
  ;

Signed-off-by: simran singhal 
Acked-by: Julia Lawall 
---
 .../media/atomisp/pci/atomisp2/css2400/sh_css.c  | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
index 0a1544d..c442d22 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css.c
@@ -1989,7 +1989,7 @@ enum ia_css_err ia_css_suspend(void)
for(i=0;i after 1: seed %d 
(%p)\n", i, my_css_save.stream_seeds[i].stream);
ia_css_debug_dtrace(IA_CSS_DEBUG_TRACE, "ia_css_suspend() leave\n");
-   return(IA_CSS_SUCCESS);
+   return IA_CSS_SUCCESS;
 }
 
 enum ia_css_err
@@ -2001,10 +2001,10 @@ ia_css_resume(void)
 
err = ia_css_init(&(my_css_save.driver_env), my_css_save.loaded_fw, 
my_css_save.mmu_base, my_css_save.irq_type);
if (err != IA_CSS_SUCCESS)
-   return(err);
+   return err;
err = ia_css_start_sp();
if (err != IA_CSS_SUCCESS)
-   return(err);
+   return err;
my_css_save.mode = sh_css_mode_resume;
for(i=0;i

[PATCH 0/2] staging: media: Remove parentheses from return arguments

[simran singhal]

This patch-series removes unnecessary parantheses from return arguments.

simran singhal (2):
  staging: css2400/sh_css: Remove parentheses from return arguments
  staging: sh_css_firmware: Remove parentheses from return arguments

 .../media/atomisp/pci/atomisp2/css2400/sh_css.c  | 20 ++--
 .../atomisp/pci/atomisp2/css2400/sh_css_firmware.c   |  2 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: sh_css_firmware: Remove parentheses from return arguments

[simran singhal]

The sematic patch used for this is:
@@
identifier i;
constant c;
@@
return
- (
\(i\|-i\|i(...)\|c\)
- )
  ;

Signed-off-by: simran singhal 
Acked-by: Julia Lawall 
---
 drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c 
b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
index b294e6d..0d7e8cd 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/css2400/sh_css_firmware.c
@@ -74,7 +74,7 @@ static struct fw_param *fw_minibuffer;
 
 char *sh_css_get_fw_version(void)
 {
-   return(FW_rel_ver_name);
+   return FW_rel_ver_name;
 }
 
 
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Hans Verkuil]

On 04/03/17 14:13, Sakari Ailus wrote:
> Hi Russell,
> 
> On Fri, Mar 03, 2017 at 11:06:45PM +, Russell King - ARM Linux wrote:
>> On Thu, Mar 02, 2017 at 06:02:57PM +0200, Sakari Ailus wrote:
>>> Hi Steve,
>>>
>>> On Wed, Feb 15, 2017 at 06:19:16PM -0800, Steve Longerbeam wrote:
 v4l2_pipeline_inherit_controls() will add the v4l2 controls from
 all subdev entities in a pipeline to a given video device.

 Signed-off-by: Steve Longerbeam 
 ---
  drivers/media/v4l2-core/v4l2-mc.c | 48 
 +++
  include/media/v4l2-mc.h   | 25 
  2 files changed, 73 insertions(+)

 diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
 b/drivers/media/v4l2-core/v4l2-mc.c
 index 303980b..09d4d97 100644
 --- a/drivers/media/v4l2-core/v4l2-mc.c
 +++ b/drivers/media/v4l2-core/v4l2-mc.c
 @@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
 +#include 
  #include 
  #include 
  #include 
 @@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
  }
  EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
  
 +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
 +   struct media_entity *start_entity)
>>>
>>> I have a few concerns / questions:
>>>
>>> - What's the purpose of this patch? Why not to access the sub-device node
>>>   directly?
>>
>> What tools are in existance _today_ to provide access to these controls
>> via the sub-device nodes?
> 
> yavta, for instance:
> 
> 
> 
> VIDIOC_QUERYCAP isn't supported on sub-devices and v4l2-ctl appears to be
> checking for that. That check should be removed (with possible other
> implications taken into account).

No, the subdev API should get a similar QUERYCAP ioctl. There isn't a single
ioctl that is guaranteed to be available for all subdev devices. I've made
proposals for this in the past, and those have all been shot down.

Add that, and I'll add support for subdevs in v4l2-ctl.

> 
>>
>> v4l-tools doesn't last time I looked - in fact, the only tool in v4l-tools
>> which is capable of accessing the subdevices is media-ctl, and that only
>> provides functionality for configuring the pipeline.
>>
>> So, pointing people at vapourware userspace is really quite rediculous.
> 
> Do bear in mind that there are other programs that can make use of these
> interfaces. It's not just the test programs, or a test program you attempted
> to use.
> 
>>
>> The established way to control video capture is through the main video
>> capture device, not through the sub-devices.  Yes, the controls are
>> exposed through sub-devices too, but that does not mean that is the
>> correct way to access them.
> 
> It is. That's the very purpose of the sub-devices: to provide access to the
> hardware independently of how the links are configured.
> 
>>
>> The v4l2 documentation (Documentation/media/kapi/v4l2-controls.rst)
>> even disagrees with your statements.  That talks about control
>> inheritence from sub-devices to the main video device, and the core
>> v4l2 code provides _automatic_ support for this - see
>> v4l2_device_register_subdev():
>>
>> /* This just returns 0 if either of the two args is NULL */
>> err = v4l2_ctrl_add_handler(v4l2_dev->ctrl_handler, 
>> sd->ctrl_handler, NULL);
>>
>> which merges the subdev's controls into the main device's control
>> handler.
> 
> That's done on different kind of devices: those that provide plain V4L2 API
> to control the entire device. V4L2 sub-device interface is used *in kernel*
> as an interface to control sub-devices that do not need to be exposed to the
> user space.
> 
> Devices that have complex pipeline that do essentially require using the
> Media controller interface to configure them are out of that scope.
> 

Way too much of how the MC devices should be used is in the minds of developers.
There is a major lack for good detailed documentation, utilities, compliance
test (really needed!) and libv4l plugins.

Russell's comments are spot on and it is a thorn in my side that this still
hasn't been addressed.

I want to see if I can get time from my boss to work on this this summer, but
there is no guarantee.

The main reason this hasn't been a much bigger problem is that most end-users
make custom applications for this hardware. It makes sense, if you need full
control over everything you make the application yourself, that's the whole 
point.

But there was always meant to be a layer (libv4l plugin) that could be used to
setup a 'default scenario' that existing applications could use, but that was
never enforced, sadly.

Anyway, regarding this specific patch and for this MC-aware driver: no, you
shouldn't inherit controls from subdevs. It defeats the purpose.

Regards,

Hans
___
devel mailing 

[PATCH] staging: comedi: amplc_pci224: Convert macro GAT_CONFIG to static inline function

[simran singhal]

Convert macro GAT_CONFIG to static inline function as static inline
functions are preferred over macros. This change is possible since the
arguments at all call sites have the same type.

This was done using Coccinelle:

@r@
expression e;
@@
- #define GAT_CONFIG(chan, src) e
+ static inline unsigned int pci230_gat_config(unsigned int chan,
+  unsigned int src)
+{
+   return ((chan & 3) << 3) | (src & 7);
+}

@r1@
expression dev,reg,chan,src;
@@
-GAT_CONFIG(chan, src)
+pci230_gat_config(chan, src)

Also, the comment describing the macro has been removed manually.

Signed-off-by: simran singhal 
---
 drivers/staging/comedi/drivers/amplc_pci224.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/amplc_pci224.c 
b/drivers/staging/comedi/drivers/amplc_pci224.c
index 2e6decf..46026f5 100644
--- a/drivers/staging/comedi/drivers/amplc_pci224.c
+++ b/drivers/staging/comedi/drivers/amplc_pci224.c
@@ -216,8 +216,12 @@
 #define GAT_GND1   /* GND (i.e. disabled) */
 #define GAT_EXT2   /* reserved (external gate input) */
 #define GAT_NOUTNM23   /* inverted output of channel-2 modulo total */
-/* Macro to construct gate input configuration register value. */
-#define GAT_CONFIG(chan, src)  chan) & 3) << 3) | ((src) & 7))
+
+static inline unsigned int pci230_gat_config(unsigned int chan,
+unsigned int src)
+{
+   return ((chan & 3) << 3) | (src & 7);
+}
 
 /*
  * Summary of CLK_OUTNM1 and GAT_NOUTNM2 connections for PCI224 and PCI234:
@@ -817,10 +821,12 @@ static void pci224_ao_start_pacer(struct comedi_device 
*dev,
 * source.
 */
/* Make sure Z2-0 is gated on.  */
-   outb(GAT_CONFIG(0, GAT_VCC), devpriv->iobase1 + PCI224_ZGAT_SCE);
+   outb(pci230_gat_config(0, GAT_VCC),
+devpriv->iobase1 + PCI224_ZGAT_SCE);
/* Cascading with Z2-2. */
/* Make sure Z2-2 is gated on.  */
-   outb(GAT_CONFIG(2, GAT_VCC), devpriv->iobase1 + PCI224_ZGAT_SCE);
+   outb(pci230_gat_config(2, GAT_VCC),
+devpriv->iobase1 + PCI224_ZGAT_SCE);
/* Z2-2 needs 10 MHz clock. */
outb(CLK_CONFIG(2, CLK_10MHZ), devpriv->iobase1 + PCI224_ZCLK_SCE);
/* Z2-0 is clocked from Z2-2's output. */
-- 
2.7.4

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Daniel Vetter]

On Fri, Mar 10, 2017 at 10:31:13AM +, Brian Starkey wrote:
> Hi,
> 
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
> > On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 
> [snip]
> 
> > > 
> > > For me those patches are going in the right direction.
> > > 
> > > I still have few questions:
> > > - since alignment management has been remove from ion-core, should it
> > > be also removed from ioctl structure ?
> > 
> > Yes, I think I'm going to go with the suggestion to fixup the ABI
> > so we don't need the compat layer and as part of that I'm also
> > dropping the align argument.
> > 
> 
> Is the only motivation for removing the alignment parameter that
> no-one got around to using it for something useful yet?
> The original comment was true - different devices do have different
> alignment requirements.
> 
> Better alignment can help SMMUs use larger blocks when mapping,
> reducing TLB pressure and the chance of a page table walk causing
> display underruns.

Extending ioctl uapi is easy, trying to get rid of bad uapi is much
harder. Given that right now we don't have an ion allocator that does
alignment I think removing it makes sense. And if we go with lots of
heaps, we might as well have an ion heap per alignment that your hw needs,
so there's different ways to implement this in the future.

At least from the unix device memory allocator pov it's probably simpler
to encode stuff like this into the heap name, instead of having to pass
heap + list of additional properties/constraints.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event

[Hans Verkuil]

On 10/03/17 05:52, Steve Longerbeam wrote:
> Add a NEW_FRAME_BEFORE_EOF event to signal that a video capture or
> output device has signaled a new frame is ready before a previous
> frame has completed reception or transmission. This usually indicates
> a DMA read/write channel is having trouble gaining bus access.

This too is a weird event. Based on what you describe this basically means
that the previous frame is incomplete, in which case you would typically
return the buffer with the V4L2_BUF_FLAG_ERROR bit set.

Using an event for this is not a good idea.

Regards,

Hans

> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
>  Documentation/media/videodev2.h.rst.exceptions  | 1 +
>  include/uapi/linux/videodev2.h  | 1 +
>  3 files changed, 8 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
> b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> index dc77363..54bc7ae 100644
> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> @@ -203,6 +203,12 @@ call.
>   has measured an interval between the reception or transmit
>   completion of two consecutive frames of video that is outside
>   the nominal frame interval by some tolerance value.
> +* - ``V4L2_EVENT_NEW_FRAME_BEFORE_EOF``
> +  - 8
> +  - This event is triggered when the video capture or output device
> + has signaled a new frame is ready before a previous frame has
> + completed reception or transmission. This usually indicates a
> + DMA read/write channel is having trouble gaining bus access.
>  * - ``V4L2_EVENT_PRIVATE_START``
>- 0x0800
>- Base event number for driver-private events.
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index c7d8fad..be6f332 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -460,6 +460,7 @@ replace define V4L2_EVENT_FRAME_SYNC event-type
>  replace define V4L2_EVENT_SOURCE_CHANGE event-type
>  replace define V4L2_EVENT_MOTION_DET event-type
>  replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
> +replace define V4L2_EVENT_NEW_FRAME_BEFORE_EOF event-type
>  replace define V4L2_EVENT_PRIVATE_START event-type
>  
>  replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index cf5a0d0..f54a82a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
>  #define V4L2_EVENT_SOURCE_CHANGE 5
>  #define V4L2_EVENT_MOTION_DET6
>  #define V4L2_EVENT_FRAME_INTERVAL_ERROR  7
> +#define V4L2_EVENT_NEW_FRAME_BEFORE_EOF  8
>  #define V4L2_EVENT_PRIVATE_START 0x0800
>  
>  /* Payload for V4L2_EVENT_VSYNC */
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Hans Verkuil]

On 10/03/17 05:52, Steve Longerbeam wrote:
> Add a new FRAME_INTERVAL_ERROR event to signal that a video capture or
> output device has measured an interval between the reception or transmit
> completion of two consecutive frames of video that is outside the nominal
> frame interval by some tolerance value.

Reading back what was said on this I agree with Sakari that this doesn't
belong here.

Userspace can detect this just as easily (if not easier) with a timeout.

Regards,

Hans

> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++
>  Documentation/media/videodev2.h.rst.exceptions  | 1 +
>  include/uapi/linux/videodev2.h  | 1 +
>  3 files changed, 8 insertions(+)
> 
> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
> b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> index 8d663a7..dc77363 100644
> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> @@ -197,6 +197,12 @@ call.
>   the regions changes. This event has a struct
>   :c:type:`v4l2_event_motion_det`
>   associated with it.
> +* - ``V4L2_EVENT_FRAME_INTERVAL_ERROR``
> +  - 7
> +  - This event is triggered when the video capture or output device
> + has measured an interval between the reception or transmit
> + completion of two consecutive frames of video that is outside
> + the nominal frame interval by some tolerance value.
>  * - ``V4L2_EVENT_PRIVATE_START``
>- 0x0800
>- Base event number for driver-private events.
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index e11a0d0..c7d8fad 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -459,6 +459,7 @@ replace define V4L2_EVENT_CTRL event-type
>  replace define V4L2_EVENT_FRAME_SYNC event-type
>  replace define V4L2_EVENT_SOURCE_CHANGE event-type
>  replace define V4L2_EVENT_MOTION_DET event-type
> +replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
>  replace define V4L2_EVENT_PRIVATE_START event-type
>  
>  replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 45184a2..cf5a0d0 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2131,6 +2131,7 @@ struct v4l2_streamparm {
>  #define V4L2_EVENT_FRAME_SYNC4
>  #define V4L2_EVENT_SOURCE_CHANGE 5
>  #define V4L2_EVENT_MOTION_DET6
> +#define V4L2_EVENT_FRAME_INTERVAL_ERROR  7
>  #define V4L2_EVENT_PRIVATE_START 0x0800
>  
>  /* Payload for V4L2_EVENT_VSYNC */
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 22/39] media: Add userspace header file for i.MX

[Hans Verkuil]

On 10/03/17 05:53, Steve Longerbeam wrote:
> This adds a header file for use by userspace programs wanting to interact
> with the i.MX media driver. It defines custom v4l2 controls for the
> i.MX v4l2 subdevices.
> 
> Signed-off-by: Steve Longerbeam 

I would not export this while the imx driver is in staging.

Also, traditionally exported media headers are in linux, not media.

I would like to have a discussion about that before deciding where to
place this header.

For the record: I am not opposed to placing this in media.

Regards,

Hans

> ---
>  include/uapi/media/Kbuild |  1 +
>  include/uapi/media/imx.h  | 21 +
>  2 files changed, 22 insertions(+)
>  create mode 100644 include/uapi/media/imx.h
> 
> diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
> index aafaa5a..fa78958 100644
> --- a/include/uapi/media/Kbuild
> +++ b/include/uapi/media/Kbuild
> @@ -1 +1,2 @@
>  # UAPI Header export list
> +header-y += imx.h
> diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
> new file mode 100644
> index 000..f573de4
> --- /dev/null
> +++ b/include/uapi/media/imx.h
> @@ -0,0 +1,21 @@
> +/*
> + * Copyright (c) 2014-2015 Mentor Graphics Inc.
> + *
> + * 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
> + */
> +
> +#ifndef __UAPI_MEDIA_IMX_H__
> +#define __UAPI_MEDIA_IMX_H__
> +
> +enum imx_ctrl_id {
> + V4L2_CID_IMX_FIM_ENABLE = (V4L2_CID_USER_IMX_BASE + 0),
> + V4L2_CID_IMX_FIM_NUM,
> + V4L2_CID_IMX_FIM_TOLERANCE_MIN,
> + V4L2_CID_IMX_FIM_TOLERANCE_MAX,
> + V4L2_CID_IMX_FIM_NUM_SKIP,
> +};
> +
> +#endif
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Robin Murphy]

On 10/03/17 10:31, Brian Starkey wrote:
> Hi,
> 
> On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:
>> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 
> [snip]
> 
>>>
>>> For me those patches are going in the right direction.
>>>
>>> I still have few questions:
>>> - since alignment management has been remove from ion-core, should it
>>> be also removed from ioctl structure ?
>>
>> Yes, I think I'm going to go with the suggestion to fixup the ABI
>> so we don't need the compat layer and as part of that I'm also
>> dropping the align argument.
>>
> 
> Is the only motivation for removing the alignment parameter that
> no-one got around to using it for something useful yet?
> The original comment was true - different devices do have different
> alignment requirements.
> 
> Better alignment can help SMMUs use larger blocks when mapping,
> reducing TLB pressure and the chance of a page table walk causing
> display underruns.

For that use-case, though, alignment alone doesn't necessarily help -
you need the whole allocation granularity to match your block size (i.e.
given a 1MB block size, asking for 17KB and getting back 17KB starting
at a 1MB boundary doesn't help much - that whole 1MB needs to be
allocated and everyone needs to know it to ensure that the whole lot can
be mapped safely). Now, whether it's down to the callers or the heap
implementations to decide and enforce that granularity is another
question, but provided allocations are at least naturally aligned to
whatever the granularity is (which is a reasonable assumption to bake
in) then it's all good.

Robin.

> 
> -Brian
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v5 17/39] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Hans Verkuil]

On 10/03/17 05:52, Steve Longerbeam wrote:
> v4l2_pipeline_inherit_controls() will add the v4l2 controls from
> all subdev entities in a pipeline to a given video device.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/media/v4l2-core/v4l2-mc.c | 48 
> +++
>  include/media/v4l2-mc.h   | 25 
>  2 files changed, 73 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
> b/drivers/media/v4l2-core/v4l2-mc.c
> index 303980b..09d4d97 100644
> --- a/drivers/media/v4l2-core/v4l2-mc.c
> +++ b/drivers/media/v4l2-core/v4l2-mc.c
> @@ -22,6 +22,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
>  }
>  EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
>  
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity)
> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + struct media_entity *entity;
> + struct media_graph graph;
> + struct v4l2_subdev *sd;
> + int ret;
> +
> + ret = media_graph_walk_init(, mdev);
> + if (ret)
> + return ret;
> +
> + media_graph_walk_start(, start_entity);
> +
> + while ((entity = media_graph_walk_next())) {
> + if (!is_media_entity_v4l2_subdev(entity))
> + continue;
> +
> + sd = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
> + sd->ctrl_handler,
> + NULL);
> + if (ret)
> + break;
> + }
> +
> + media_graph_walk_cleanup();
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
> +
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity)
> +{
> + struct media_device *mdev = start_entity->graph_obj.mdev;
> + int ret;
> +
> + mutex_lock(>graph_mutex);
> + ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
> + mutex_unlock(>graph_mutex);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
> +
>  /* 
> -
>   * Pipeline power management
>   *
> diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
> index 2634d9d..9848e77 100644
> --- a/include/media/v4l2-mc.h
> +++ b/include/media/v4l2-mc.h
> @@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
>   */
>  int v4l_vb2q_enable_media_source(struct vb2_queue *q);
>  
> +/**
> + * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
> + *   subdev entities in a pipeline to
> + *   the given video device.
> + * @vfd: the video device
> + * @start_entity: Starting entity
> + */
> +int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +  struct media_entity *start_entity);
> +int v4l2_pipeline_inherit_controls(struct video_device *vfd,
> +struct media_entity *start_entity);

Please document which is the unlocked variant and which lock the locked
variant takes.

Regards,

Hans

>  
>  /**
>   * v4l2_pipeline_pm_use - Update the use count of an entity
> @@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
> vb2_queue *q)
>   return 0;
>  }
>  
> +static inline int __v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
> +static inline int v4l2_pipeline_inherit_controls(
> + struct video_device *vfd,
> + struct media_entity *start_entity)
> +{
> + return 0;
> +}
> +
>  static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
>  {
>   return 0;
> 

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/10] staging: bcm2835-camera: Fix buffer overflow calculation on query of camera properties

[Dave Stevenson]

On 10 March 2017 at 11:16, Michael Zoran  wrote:
> On Fri, 2017-03-10 at 11:11 +, Dave Stevenson wrote:
>> On 10 March 2017 at 05:08, Michael Zoran  wrote:
>> > The code that queries properties on the camera has a check
>> > for buffer overruns if the firmware sends too much data.  This
>> > check is incorrect, and during testing I was seeing stack
>> > corruption.
>> >
>> > I believe this error can actually happen in normal use, just for
>> > some reason it doesn't appear on 32 bit as often.  So perhaps
>> > it's best for the check to be fixed.
>>
>> That sounds like it is related to a report I couldn't nail down as it
>> only happened on ArchLinux -
>> https://github.com/raspberrypi/linux/issues/1447
>>
>> Comparing against the original MMAL implementation at
>> https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc
>> /mmal_vc_api.c#L1187
>> there are a few subtle differences. Your patch is a belt and braces
>> to
>> ensure that it never copies too much, so reasonable in that regard.
>>
>> I'm actually more worried that it implies we have a structure
>> mismatch
>> against the firmware, but I currently can't see where it is. A load
>> of
>> debug prints for sizeof(struct) required
>>
>> > Signed-off-by: Michael Zoran 
>> > ---
>> >  drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-
>> > vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> > index 41de8956e421..976aa08365f2 100644
>> > --- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> > +++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
>> > @@ -1442,7 +1442,7 @@ static int port_parameter_get(struct
>> > vchiq_mmal_instance *instance,
>> > }
>> >
>> > ret = -rmsg->u.port_parameter_get_reply.status;
>> > -   if (ret) {
>> > +   if (ret || (rmsg->u.port_parameter_get_reply.size >
>> > *value_size)) {
>> > /* Copy only as much as we have space for
>> >  * but report true size of parameter
>> >  */
>> > --
>> > 2.11.0
>> >
>
> I actually tracked it while debugging down to these structures.  I was
> going to let you know, but I went with the band-aid for now.
>
> The firmware thinks the structure should be 8 bytes longer.  I'm
> wondering if it should be 4 cameras and 4 flashes. That would explain
> the extra 8 bytes.

The userland repo is the extraction of the relevant IPC files from the
firmware source tree. What you see there is the same code the firmware
is being built from. It's only a 32bit compiler so I can't see why it
would suddenly be aligning the flash structures to 64bits.

I'll do some debugging on the firmware side to work out how/where it
is going wrong, but this patch is valid regardless.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/10] staging: bcm2835-camera: Fix buffer overflow calculation on query of camera properties

[Michael Zoran]

On Fri, 2017-03-10 at 11:11 +, Dave Stevenson wrote:
> On 10 March 2017 at 05:08, Michael Zoran  wrote:
> > The code that queries properties on the camera has a check
> > for buffer overruns if the firmware sends too much data.  This
> > check is incorrect, and during testing I was seeing stack
> > corruption.
> > 
> > I believe this error can actually happen in normal use, just for
> > some reason it doesn't appear on 32 bit as often.  So perhaps
> > it's best for the check to be fixed.
> 
> That sounds like it is related to a report I couldn't nail down as it
> only happened on ArchLinux -
> https://github.com/raspberrypi/linux/issues/1447
> 
> Comparing against the original MMAL implementation at
> https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc
> /mmal_vc_api.c#L1187
> there are a few subtle differences. Your patch is a belt and braces
> to
> ensure that it never copies too much, so reasonable in that regard.
> 
> I'm actually more worried that it implies we have a structure
> mismatch
> against the firmware, but I currently can't see where it is. A load
> of
> debug prints for sizeof(struct) required
> 
> > Signed-off-by: Michael Zoran 
> > ---
> >  drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-
> > vchiq.c b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> > index 41de8956e421..976aa08365f2 100644
> > --- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> > +++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> > @@ -1442,7 +1442,7 @@ static int port_parameter_get(struct
> > vchiq_mmal_instance *instance,
> > }
> > 
> > ret = -rmsg->u.port_parameter_get_reply.status;
> > -   if (ret) {
> > +   if (ret || (rmsg->u.port_parameter_get_reply.size >
> > *value_size)) {
> > /* Copy only as much as we have space for
> >  * but report true size of parameter
> >  */
> > --
> > 2.11.0
> > 

I actually tracked it while debugging down to these structures.  I was
going to let you know, but I went with the band-aid for now.

The firmware thinks the structure should be 8 bytes longer.  I'm
wondering if it should be 4 cameras and 4 flashes. That would explain
the extra 8 bytes.

#define MMAL_PARAMETER_CAMERA_INFO_MAX_CAMERAS 4
#define MMAL_PARAMETER_CAMERA_INFO_MAX_FLASHES 2
#define MMAL_PARAMETER_CAMERA_INFO_MAX_STR_LEN 16

struct mmal_parameter_camera_info_camera_t {
u32port_id;
u32max_width;
u32max_height;
u32lens_present;
u8 camera_name[MMAL_PARAMETER_CAMERA_INFO_MAX_STR_LEN];
};

enum mmal_parameter_camera_info_flash_type_t {
/* Make values explicit to ensure they match values in config
ini */
MMAL_PARAMETER_CAMERA_INFO_FLASH_TYPE_XENON = 0,
MMAL_PARAMETER_CAMERA_INFO_FLASH_TYPE_LED   = 1,
MMAL_PARAMETER_CAMERA_INFO_FLASH_TYPE_OTHER = 2,
MMAL_PARAMETER_CAMERA_INFO_FLASH_TYPE_MAX = 0x7FFF
};

struct mmal_parameter_camera_info_flash_t {
enum mmal_parameter_camera_info_flash_type_t flash_type;
};

struct mmal_parameter_camera_info_t {
u32num_cameras;
u32num_flashes;
struct mmal_parameter_camera_info_camera_t
cameras[MMAL_PARAMETER_CAMERA_INFO_MAX_
CAMERAS];
struct mmal_parameter_camera_info_flash_t
flashes[MMAL_PARAMETER_CAMERA_INFO_MAX_
FLASHES];
};
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 08/10] staging: bcm2835-camera: Fix buffer overflow calculation on query of camera properties

[Dave Stevenson]

On 10 March 2017 at 05:08, Michael Zoran  wrote:
> The code that queries properties on the camera has a check
> for buffer overruns if the firmware sends too much data.  This
> check is incorrect, and during testing I was seeing stack corruption.
>
> I believe this error can actually happen in normal use, just for
> some reason it doesn't appear on 32 bit as often.  So perhaps
> it's best for the check to be fixed.

That sounds like it is related to a report I couldn't nail down as it
only happened on ArchLinux -
https://github.com/raspberrypi/linux/issues/1447

Comparing against the original MMAL implementation at
https://github.com/raspberrypi/userland/blob/master/interface/mmal/vc/mmal_vc_api.c#L1187
there are a few subtle differences. Your patch is a belt and braces to
ensure that it never copies too much, so reasonable in that regard.

I'm actually more worried that it implies we have a structure mismatch
against the firmware, but I currently can't see where it is. A load of
debug prints for sizeof(struct) required

> Signed-off-by: Michael Zoran 
> ---
>  drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c 
> b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> index 41de8956e421..976aa08365f2 100644
> --- a/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> +++ b/drivers/staging/vc04_services/bcm2835-camera/mmal-vchiq.c
> @@ -1442,7 +1442,7 @@ static int port_parameter_get(struct 
> vchiq_mmal_instance *instance,
> }
>
> ret = -rmsg->u.port_parameter_get_reply.status;
> -   if (ret) {
> +   if (ret || (rmsg->u.port_parameter_get_reply.size > *value_size)) {
> /* Copy only as much as we have space for
>  * but report true size of parameter
>  */
> --
> 2.11.0
>
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH v2 14/32] x86: mm: Provide support to use memblock when spliting large pages

[Borislav Petkov]

On Thu, Mar 02, 2017 at 10:15:15AM -0500, Brijesh Singh wrote:
> If kernel_maps_pages_in_pgd is called early in boot process to change the

kernel_map_pages_in_pgd()

> memory attributes then it fails to allocate memory when spliting large
> pages. The patch extends the cpa_data to provide the support to use
> memblock_alloc when slab allocator is not available.
> 
> The feature will be used in Secure Encrypted Virtualization (SEV) mode,
> where we may need to change the memory region attributes in early boot
> process.
> 
> Signed-off-by: Brijesh Singh 
> ---
>  arch/x86/mm/pageattr.c |   51 
> 
>  1 file changed, 42 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
> index 46cc89d..9e4ab3b 100644
> --- a/arch/x86/mm/pageattr.c
> +++ b/arch/x86/mm/pageattr.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -37,6 +38,7 @@ struct cpa_data {
>   int flags;
>   unsigned long   pfn;
>   unsignedforce_split : 1;
> + unsignedforce_memblock :1;
>   int curpage;
>   struct page **pages;
>  };
> @@ -627,9 +629,8 @@ try_preserve_large_page(pte_t *kpte, unsigned long 
> address,
>  
>  static int
>  __split_large_page(struct cpa_data *cpa, pte_t *kpte, unsigned long address,
> -struct page *base)
> +   pte_t *pbase, unsigned long new_pfn)
>  {
> - pte_t *pbase = (pte_t *)page_address(base);
>   unsigned long ref_pfn, pfn, pfninc = 1;
>   unsigned int i, level;
>   pte_t *tmp;
> @@ -646,7 +647,7 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>   return 1;
>   }
>  
> - paravirt_alloc_pte(_mm, page_to_pfn(base));
> + paravirt_alloc_pte(_mm, new_pfn);
>  
>   switch (level) {
>   case PG_LEVEL_2M:
> @@ -707,7 +708,8 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>* pagetable protections, the actual ptes set above control the
>* primary protection behavior:
>*/
> - __set_pmd_pte(kpte, address, mk_pte(base, __pgprot(_KERNPG_TABLE)));
> + __set_pmd_pte(kpte, address,
> + native_make_pte((new_pfn << PAGE_SHIFT) + _KERNPG_TABLE));
>  
>   /*
>* Intel Atom errata AAH41 workaround.
> @@ -723,21 +725,50 @@ __split_large_page(struct cpa_data *cpa, pte_t *kpte, 
> unsigned long address,
>   return 0;
>  }
>  
> +static pte_t *try_alloc_pte(struct cpa_data *cpa, unsigned long *pfn)
> +{
> + unsigned long phys;
> + struct page *base;
> +
> + if (cpa->force_memblock) {
> + phys = memblock_alloc(PAGE_SIZE, PAGE_SIZE);

Maybe there's a reason this fires:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'

WARNING: vmlinux.o(.text+0x48edc): Section mismatch in reference from the 
function __change_page_attr() to the function .init.text:memblock_alloc()
The function __change_page_attr() references
the function __init memblock_alloc().
This is often because __change_page_attr lacks a __init
annotation or the annotation of memblock_alloc is wrong.

WARNING: vmlinux.o(.text+0x491d1): Section mismatch in reference from the 
function __change_page_attr() to the function .meminit.text:memblock_free()
The function __change_page_attr() references
the function __meminit memblock_free().
This is often because __change_page_attr lacks a __meminit
annotation or the annotation of memblock_free is wrong.

Why do we need this whole early mapping? For the guest? I don't like
that memblock thing at all.

So I think the approach with the .data..percpu..hv_shared section is
fine and we should consider SEV-ES

http://support.amd.com/TechDocs/Protecting%20VM%20Register%20State%20with%20SEV-ES.pdf

and do this right from the get-go so that when SEV-ES comes along, we
should simply be ready and extend that mechanism to put the whole Guest
Hypervisor Communication Block in there.

But then the fact that you're mapping those decrypted in init_mm.pgd
makes me think you don't need that early mapping thing at all. Those are
the decrypted mappings of the hypervisor. And that you can do late.

Now, what would be better, IMHO (and I have no idea about virtualization
design so take with a grain of salt) is if the guest would allocate
enough memory for the GHCB and mark it decrypted from the very
beginning. It will be the communication vehicle with the hypervisor
anyway.

And we already do similar things in sme_map_bootdata() for the baremetal
kernel to map boot_data, initrd, EFI, ... and so on things decrypted.

And we should extend that mechanism to map the GHCB in the guest too and
then we can get rid of all that need for ->force_memblock which makes
the crazy mess in pageattr.c even crazier. And it would be lovely if 

[PATCH v2 2/2] staging: speakup: spaces preferred around operator

[Arushi Singhal]

Fixed the checkpatch.pl issues like:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
etc.

Signed-off-by: Arushi Singhal 
---
 changes in v2
 - add the space where forgot to add

 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 14 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 14 +++---
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 7 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 657a48b6f8d3..aade52ee15a0 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -120,8 +120,8 @@ static void start_serial_interrupt(int irq)
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2,
speakup_info.port_tts + UART_MCR);
/* Turn on Interrupts */
-   outb(UART_IER_MSI|UART_IER_RLSI|UART_IER_RDI,
-   speakup_info.port_tts + UART_IER);
+   outb(UART_IER_MSI | UART_IER_RLSI | UART_IER_RDI,
+speakup_info.port_tts + UART_IER);
inb(speakup_info.port_tts + UART_LSR);
inb(speakup_info.port_tts + UART_RX);
inb(speakup_info.port_tts + UART_IIR);
diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index 0bc8d6afadfa..a654334c98b9 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -20,7 +20,7 @@
 #define A_CAP 0x0007
 #define B_NUM 0x0008
 #define NUM 0x0009
-#define ALPHANUM (B_ALPHA|B_NUM)
+#define ALPHANUM (B_ALPHA | B_NUM)
 #define SOME 0x0010
 #define MOST 0x0020
 #define PUNC 0x0040
@@ -30,14 +30,14 @@
 #define B_EXNUM 0x0100
 #define CH_RPT 0x0200
 #define B_CTL 0x0400
-#define A_CTL (B_CTL+SYNTH_OK)
+#define A_CTL (B_CTL + SYNTH_OK)
 #define B_SYM 0x0800
-#define B_CAPSYM (B_CAP|B_SYM)
+#define B_CAPSYM (B_CAP | B_SYM)
 
 /* FIXME: u16 */
-#define IS_WDLM(x) (spk_chartab[((u_char)x)]_WDLM)
-#define IS_CHAR(x, type) (spk_chartab[((u_char)x)])
-#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)]) == type)
+#define IS_WDLM(x) (spk_chartab[((u_char)x)] & B_WDLM)
+#define IS_CHAR(x, type) (spk_chartab[((u_char)x)] & type)
+#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)] & type) == type)
 
 int speakup_thread(void *data);
 void spk_reset_default_chars(void);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index 56ece087ff88..cde77b75d44a 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -281,7 +281,7 @@ static int synth_probe(struct spk_synth *synth)
if (port_val == 0x53fc) {
/* 'S' and out bits */
synth_port_control = synth_portlist[i];
-   speakup_info.port_tts = synth_port_control+1;
+   speakup_info.port_tts = synth_port_control + 1;
break;
}
}
@@ -304,7 +304,7 @@ static int synth_probe(struct spk_synth *synth)
 static void accent_release(void)
 {
if (speakup_info.port_tts)
-   synth_release_region(speakup_info.port_tts-1, SYNTH_IO_EXTENT);
+   synth_release_region(speakup_info.port_tts - 1, 
SYNTH_IO_EXTENT);
speakup_info.port_tts = 0;
 }
 
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 4cd9730ee03d..afe2da34a3f7 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -249,7 +249,7 @@ static int dt_getstatus(void)
 static void dt_sendcmd(u_int cmd)
 {
outb_p(cmd & 0xFF, speakup_info.port_tts);
-   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts+1);
+   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts + 1);
 }
 
 static int dt_waitbit(int bit)
@@ -271,7 +271,7 @@ static int dt_wait_dma(void)
if (!dt_waitbit(STAT_dma_ready))
return 0;
while (--timeout > 0) {
-   if ((dt_getstatus()_dma_state) == state)
+   if ((dt_getstatus() & STAT_dma_state) == state)
return 1;
udelay(50);
}
@@ -317,8 +317,8 @@ udelay(50);
break;
 udelay(50);
}
-   outb_p(DMA_sync, speakup_info.port_tts+4);
-   outb_p(0, speakup_info.port_tts+4);
+   outb_p(DMA_sync, speakup_info.port_tts + 4);
+   outb_p(0, speakup_info.port_tts + 4);
udelay(100);
for (timeout = 0; timeout < 10; timeout++) {
 

[PATCH v2 0/2] staging: speakup: checkpatch guided cleanups

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver. 

Arushi Singhal (2):
  staging: speakup: Placed Logical on the previous line
  staging: speakup: spaces preferred around operator

 drivers/staging/speakup/main.c   |  8 
 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 14 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 14 +++---
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 8 files changed, 35 insertions(+), 35 deletions(-)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH v2 1/2] staging: speakup: Placed Logical on the previous line

[Arushi Singhal]

Placed Logical continuations on the previous line as reported by
checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 6d9c9c858c75..00335eb2ff20 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2159,10 +2159,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (up_flag || spk_killed || type == KT_SHIFT)
goto out;
spk_shut_up &= 0xfe;
-   kh = (value == KVAL(K_DOWN))
-   || (value == KVAL(K_UP))
-   || (value == KVAL(K_LEFT))
-   || (value == KVAL(K_RIGHT));
+   kh = ((value == KVAL(K_DOWN)) ||
+ (value == KVAL(K_UP)) ||
+ (value == KVAL(K_LEFT)) ||
+ (value == KVAL(K_RIGHT)));
if ((cursor_track != read_all_mode) || !kh)
if (!spk_no_intr)
spk_do_flush();
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Brian Starkey]

Hi,

On Thu, Mar 09, 2017 at 09:38:49AM -0800, Laura Abbott wrote:

On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:


[snip]



For me those patches are going in the right direction.

I still have few questions:
- since alignment management has been remove from ion-core, should it
be also removed from ioctl structure ?


Yes, I think I'm going to go with the suggestion to fixup the ABI
so we don't need the compat layer and as part of that I'm also
dropping the align argument.



Is the only motivation for removing the alignment parameter that
no-one got around to using it for something useful yet?
The original comment was true - different devices do have different
alignment requirements.

Better alignment can help SMMUs use larger blocks when mapping,
reducing TLB pressure and the chance of a page table walk causing
display underruns.

-Brian
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 2/2] staging: speakup: spaces preferred around operator

[Arushi Singhal]

Fixed the checkpatch.pl issues like:
CHECK: spaces preferred around that '&' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)
CHECK: spaces preferred around that '-' (ctx:VxV)
CHECK: spaces preferred around that '+' (ctx:VxV)
etc.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 14 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 14 +++---
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 7 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/speakup/serialio.c 
b/drivers/staging/speakup/serialio.c
index 657a48b6f8d3..aade52ee15a0 100644
--- a/drivers/staging/speakup/serialio.c
+++ b/drivers/staging/speakup/serialio.c
@@ -120,8 +120,8 @@ static void start_serial_interrupt(int irq)
outb(UART_MCR_DTR | UART_MCR_RTS | UART_MCR_OUT2,
speakup_info.port_tts + UART_MCR);
/* Turn on Interrupts */
-   outb(UART_IER_MSI|UART_IER_RLSI|UART_IER_RDI,
-   speakup_info.port_tts + UART_IER);
+   outb(UART_IER_MSI | UART_IER_RLSI | UART_IER_RDI,
+speakup_info.port_tts + UART_IER);
inb(speakup_info.port_tts + UART_LSR);
inb(speakup_info.port_tts + UART_RX);
inb(speakup_info.port_tts + UART_IIR);
diff --git a/drivers/staging/speakup/speakup.h 
b/drivers/staging/speakup/speakup.h
index 0bc8d6afadfa..a654334c98b9 100644
--- a/drivers/staging/speakup/speakup.h
+++ b/drivers/staging/speakup/speakup.h
@@ -20,7 +20,7 @@
 #define A_CAP 0x0007
 #define B_NUM 0x0008
 #define NUM 0x0009
-#define ALPHANUM (B_ALPHA|B_NUM)
+#define ALPHANUM (B_ALPHA | B_NUM)
 #define SOME 0x0010
 #define MOST 0x0020
 #define PUNC 0x0040
@@ -30,14 +30,14 @@
 #define B_EXNUM 0x0100
 #define CH_RPT 0x0200
 #define B_CTL 0x0400
-#define A_CTL (B_CTL+SYNTH_OK)
+#define A_CTL (B_CTL + SYNTH_OK)
 #define B_SYM 0x0800
-#define B_CAPSYM (B_CAP|B_SYM)
+#define B_CAPSYM (B_CAP | B_SYM)
 
 /* FIXME: u16 */
-#define IS_WDLM(x) (spk_chartab[((u_char)x)]_WDLM)
-#define IS_CHAR(x, type) (spk_chartab[((u_char)x)])
-#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)]) == type)
+#define IS_WDLM(x) (spk_chartab[((u_char)x)] & B_WDLM)
+#define IS_CHAR(x, type) (spk_chartab[((u_char)x)] & type)
+#define IS_TYPE(x, type) ((spk_chartab[((u_char)x)] & type) == type)
 
 int speakup_thread(void *data);
 void spk_reset_default_chars(void);
diff --git a/drivers/staging/speakup/speakup_acntpc.c 
b/drivers/staging/speakup/speakup_acntpc.c
index 56ece087ff88..cde77b75d44a 100644
--- a/drivers/staging/speakup/speakup_acntpc.c
+++ b/drivers/staging/speakup/speakup_acntpc.c
@@ -281,7 +281,7 @@ static int synth_probe(struct spk_synth *synth)
if (port_val == 0x53fc) {
/* 'S' and out bits */
synth_port_control = synth_portlist[i];
-   speakup_info.port_tts = synth_port_control+1;
+   speakup_info.port_tts = synth_port_control + 1;
break;
}
}
@@ -304,7 +304,7 @@ static int synth_probe(struct spk_synth *synth)
 static void accent_release(void)
 {
if (speakup_info.port_tts)
-   synth_release_region(speakup_info.port_tts-1, SYNTH_IO_EXTENT);
+   synth_release_region(speakup_info.port_tts - 1, 
SYNTH_IO_EXTENT);
speakup_info.port_tts = 0;
 }
 
diff --git a/drivers/staging/speakup/speakup_decpc.c 
b/drivers/staging/speakup/speakup_decpc.c
index 4cd9730ee03d..afe2da34a3f7 100644
--- a/drivers/staging/speakup/speakup_decpc.c
+++ b/drivers/staging/speakup/speakup_decpc.c
@@ -249,7 +249,7 @@ static int dt_getstatus(void)
 static void dt_sendcmd(u_int cmd)
 {
outb_p(cmd & 0xFF, speakup_info.port_tts);
-   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts+1);
+   outb_p((cmd >> 8) & 0xFF, speakup_info.port_tts + 1);
 }
 
 static int dt_waitbit(int bit)
@@ -271,7 +271,7 @@ static int dt_wait_dma(void)
if (!dt_waitbit(STAT_dma_ready))
return 0;
while (--timeout > 0) {
-   if ((dt_getstatus()_dma_state) == state)
+   if ((dt_getstatus() & STAT_dma_state) == state)
return 1;
udelay(50);
}
@@ -317,8 +317,8 @@ udelay(50);
break;
 udelay(50);
}
-   outb_p(DMA_sync, speakup_info.port_tts+4);
-   outb_p(0, speakup_info.port_tts+4);
+   outb_p(DMA_sync, speakup_info.port_tts + 4);
+   outb_p(0, speakup_info.port_tts + 4);
udelay(100);
for (timeout = 0; timeout < 10; timeout++) {
if (!(dt_getstatus() & STAT_flushing))
@@ -336,8 

[PATCH 1/2] staging: speakup: Placed Logical on the previous line

[Arushi Singhal]

Placed Logical continuations on the previous line as reported by
checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index 6d9c9c858c75..00335eb2ff20 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -2159,10 +2159,10 @@ speakup_key(struct vc_data *vc, int shift_state, int 
keycode, u_short keysym,
if (up_flag || spk_killed || type == KT_SHIFT)
goto out;
spk_shut_up &= 0xfe;
-   kh = (value == KVAL(K_DOWN))
-   || (value == KVAL(K_UP))
-   || (value == KVAL(K_LEFT))
-   || (value == KVAL(K_RIGHT));
+   kh = ((value == KVAL(K_DOWN)) ||
+ (value == KVAL(K_UP)) ||
+ (value == KVAL(K_LEFT)) ||
+ (value == KVAL(K_RIGHT)));
if ((cursor_track != read_all_mode) || !kh)
if (!spk_no_intr)
spk_do_flush();
-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 0/2] staging: speakup: checkpatch guided cleanups

[Arushi Singhal]

Improve readability by fixing multiple checkpatch.pl
issues in speakup driver. 

Arushi Singhal (2):
  staging: speakup: Placed Logical on the previous line
  staging: speakup: spaces preferred around operator

 drivers/staging/speakup/main.c   |  8 
 drivers/staging/speakup/serialio.c   |  4 ++--
 drivers/staging/speakup/speakup.h| 12 ++--
 drivers/staging/speakup/speakup_acntpc.c |  4 ++--
 drivers/staging/speakup/speakup_decpc.c  | 14 +++---
 drivers/staging/speakup/speakup_dtlk.c   | 14 +++---
 drivers/staging/speakup/speakup_keypc.c  | 12 ++--
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 8 files changed, 35 insertions(+), 35 deletions(-)

-- 
2.11.0

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4.10 135/167] VME: restore bus_remove function causing incomplete module unload

[Greg Kroah-Hartman]

4.10-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Babic 

commit 9797484ba83d68f18fe1cbd964b7cd830f78f0f7 upstream.

Commit 050c3d52cc7810d9d17b8cd231708609af6876ae ("vme: make core
vme support explicitly non-modular") dropped the remove function
because it appeared as if it was for removal of the bus, which is
not supported.

However, vme_bus_remove() is called when a VME device is removed
from the bus and not when the bus is removed; as it calls the VME
device driver's cleanup function.  Without this function, the
remove() in the VME device driver is never called and VME device
drivers cannot be reloaded again.

Here we restore the remove function that was deleted in that
commit, and the reference to the function in the bus structure.

Fixes: 050c3d52cc78 ("vme: make core vme support explicitly non-modular")
Cc: Manohar Vanga 
Acked-by: Martyn Welch 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Stefano Babic 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/vme/vme.c |   15 +++
 1 file changed, 15 insertions(+)

--- a/drivers/vme/vme.c
+++ b/drivers/vme/vme.c
@@ -1625,10 +1625,25 @@ static int vme_bus_probe(struct device *
return retval;
 }
 
+static int vme_bus_remove(struct device *dev)
+{
+   int retval = -ENODEV;
+   struct vme_driver *driver;
+   struct vme_dev *vdev = dev_to_vme_dev(dev);
+
+   driver = dev->platform_data;
+
+   if (driver->remove != NULL)
+   retval = driver->remove(vdev);
+
+   return retval;
+}
+
 struct bus_type vme_bus_type = {
.name = "vme",
.match = vme_bus_match,
.probe = vme_bus_probe,
+   .remove = vme_bus_remove,
 };
 EXPORT_SYMBOL(vme_bus_type);
 


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH v4 13/36] [media] v4l2: add a frame timeout event

[Russell King - ARM Linux]

On Thu, Mar 09, 2017 at 06:38:18PM -0800, Steve Longerbeam wrote:
> On 03/05/2017 02:41 PM, Russell King - ARM Linux wrote:
> >I'm not sure that statement is entirely accurate.  With the IMX219
> >camera, I _could_ (with previous iterations of the iMX capture code)
> >stop it streaming, wait a while, and restart it, and everything
> >continues to work.
> 
> Hi Russell, did you see the "EOF timeout" kernel error message when you
> stopped the IMX219 from streaming? Only a "EOF timeout" message
> indicates the unrecoverable case.

I really couldn't tell you anymore - I can't go back and test at all,
because:

(a) your v4 patch set never worked for me
(b) I've now moved forward to v4.11-rc1, which conflicts with your v4
and older patch sets.

In any case, I'm in complete disagreement with many of the points that
Sakari has been bringing up, and I'm finding the direction that things
are progressing to be abhorrent.

I've discussed with Mauro about (eg) the application interface, and
unsurprisingly to me, Mauro immediately said about control inheritence
to the main v4l2 device, contradicting what Sakari has been saying.
The subdev API is supposed to be there to allow for finer control, it's
not a "one or the other" thing.  The controls are still supposed to be
exposed through the main v4l2 subdev device.

Since the v4l2 stuff is becoming abhorrent, and I've also come to
realise that I'm going to have to write an entirely new userspace
application to capture, debayer and encode efficiently, I'm finding
that I've little motivation to take much of a further interest in
iMX6 capture, or indeed continue my reverse engineering efforts of
the IMX219 sensor.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] Allows setting bpp from dt

[Radoslaw Pietrzyk]

Allows setting bpp from dt

Radoslaw Pietrzyk (1):
  staging: fbtft: Allows bpp to be set from dt

 drivers/staging/fbtft/fbtft-core.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] staging: fbtft: Allows bpp to be set from dt

[Radoslaw Pietrzyk]

Allows bpp to be set from dt

Signed-off-by: Radoslaw Pietrzyk 
---
 drivers/staging/fbtft/fbtft-core.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/fbtft/fbtft-core.c 
b/drivers/staging/fbtft/fbtft-core.c
index 7c8af29..b25288b 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/staging/fbtft/fbtft-core.c
@@ -685,6 +685,8 @@ struct fb_info *fbtft_framebuffer_alloc(struct 
fbtft_display *display,
/* override driver values? */
if (pdata->fps)
fps = pdata->fps;
+   if (pdata->bpp)
+   bpp = pdata->bpp;
if (pdata->txbuflen)
txbuflen = pdata->txbuflen;
if (pdata->display.init_sequence)
-- 
1.9.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH 4.9 122/153] VME: restore bus_remove function causing incomplete module unload

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stefano Babic 

commit 9797484ba83d68f18fe1cbd964b7cd830f78f0f7 upstream.

Commit 050c3d52cc7810d9d17b8cd231708609af6876ae ("vme: make core
vme support explicitly non-modular") dropped the remove function
because it appeared as if it was for removal of the bus, which is
not supported.

However, vme_bus_remove() is called when a VME device is removed
from the bus and not when the bus is removed; as it calls the VME
device driver's cleanup function.  Without this function, the
remove() in the VME device driver is never called and VME device
drivers cannot be reloaded again.

Here we restore the remove function that was deleted in that
commit, and the reference to the function in the bus structure.

Fixes: 050c3d52cc78 ("vme: make core vme support explicitly non-modular")
Cc: Manohar Vanga 
Acked-by: Martyn Welch 
Cc: de...@driverdev.osuosl.org
Signed-off-by: Stefano Babic 
Signed-off-by: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/vme/vme.c |   15 +++
 1 file changed, 15 insertions(+)

--- a/drivers/vme/vme.c
+++ b/drivers/vme/vme.c
@@ -1625,10 +1625,25 @@ static int vme_bus_probe(struct device *
return retval;
 }
 
+static int vme_bus_remove(struct device *dev)
+{
+   int retval = -ENODEV;
+   struct vme_driver *driver;
+   struct vme_dev *vdev = dev_to_vme_dev(dev);
+
+   driver = dev->platform_data;
+
+   if (driver->remove != NULL)
+   retval = driver->remove(vdev);
+
+   return retval;
+}
+
 struct bus_type vme_bus_type = {
.name = "vme",
.match = vme_bus_match,
.probe = vme_bus_probe,
+   .remove = vme_bus_remove,
 };
 EXPORT_SYMBOL(vme_bus_type);
 


___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [RFC PATCH 08/12] cma: Store a name in the cma structure

[Sumit Semwal]

Hi Laura,

Thanks for the patch.

On 3 March 2017 at 03:14, Laura Abbott  wrote:
>
> Frameworks that may want to enumerate CMA heaps (e.g. Ion) will find it
> useful to have an explicit name attached to each region. Store the name
> in each CMA structure.
>
> Signed-off-by: Laura Abbott 
> ---
>  drivers/base/dma-contiguous.c |  5 +++--
>  include/linux/cma.h   |  4 +++-
>  mm/cma.c  | 11 +--
>  mm/cma.h  |  1 +
>  mm/cma_debug.c|  2 +-
>  5 files changed, 17 insertions(+), 6 deletions(-)
>

> +const char *cma_get_name(const struct cma *cma)
> +{
> +   return cma->name ? cma->name : "(undefined)";
> +}
> +
Would it make sense to perhaps have the idx stored as the name,
instead of 'undefined'? That would make sure that the various cma
names are still unique.

>  static unsigned long cma_bitmap_aligned_mask(const struct cma *cma,
>  int align_order)
>  {
> @@ -168,6 +173,7 @@ core_initcall(cma_init_reserved_areas);
>   */
>  int __init cma_init_reserved_mem(phys_addr_t base, phys_addr_t size,
>  unsigned int order_per_bit,
> +const char *name,
>  struct cma **res_cma)
>  {

Best regards,
Sumit.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel