[PATCH v2 5/5] ASoC: tpa6130a2: Remove goto err_gpio
Replace goto err_gpio by return ret
Signed-off-by: Helen Koike
---
Changes since v1:
- this is a new patch in the series
sound/soc/codecs/tpa6130a2.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index cc83870..a919308 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -255,7 +255,7 @@ static int tpa6130a2_probe(struct i2c_client *client,
if (ret < 0) {
dev_err(dev, "Failed to request power GPIO (%d)\n",
data->power_gpio);
- goto err_gpio;
+ return ret;
}
gpio_direction_output(data->power_gpio, 0);
}
@@ -276,12 +276,12 @@ static int tpa6130a2_probe(struct i2c_client *client,
if (IS_ERR(data->supply)) {
ret = PTR_ERR(data->supply);
dev_err(dev, "Failed to request supply: %d\n", ret);
- goto err_gpio;
+ return ret;
}
ret = tpa6130a2_power(data, true);
if (ret != 0)
- goto err_gpio;
+ return ret;
/* Read version */
@@ -293,13 +293,10 @@ static int tpa6130a2_probe(struct i2c_client *client,
/* Disable the chip */
ret = tpa6130a2_power(data, false);
if (ret != 0)
- goto err_gpio;
+ return ret;
return devm_snd_soc_register_component(&client->dev,
&tpa6130a2_component_driver, NULL, 0);
-
-err_gpio:
- return ret;
}
static const struct i2c_device_id tpa6130a2_id[] = {
--
1.9.1
[PATCH v2 0/5] ASoC: tpa6130a2: Add support for multiple instances
The current tpa6130a2 driver supports only a single instance.
This patch series add support for multiple instances by removing the global
variable that holds the instance.
This is performed by using the component API, regmap, the
snd_soc_{info,put,get}_volsw API and DAPM.
This patch series also touches code from the Nokia RX51 which I didn't tested
(as
I am testing the tpa6130a2 in another board that is not upstream).
I would appreciate is if someone who possesses the Nokia RX51 (n900) could
please
test the code.
This patch series is based on
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Available at
https://git.collabora.com/cgit/user/koike/linux.git/log/?h=sound/review/tpa6130a2
Helen Koike (5):
ASoC: tpa6130a2: Register component
ASoC: tap6130a2: Use regmap
ASoC: tpa6130a2: Use snd soc volsw functions
ASoC: tpa6130a2: Add DAPM support
ASoC: tpa6130a2: Remove goto err_gpio
sound/soc/codecs/tpa6130a2.c | 393 ---
sound/soc/codecs/tpa6130a2.h | 14 +-
sound/soc/omap/rx51.c| 46 ++---
3 files changed, 136 insertions(+), 317 deletions(-)
Changes since v1:
ASoC: tpa6130a2: Register component
- Remove prefix from snd_kcontrol_new in tpa6130a2.c
- Add tested-by and reviewd-by from Sebastian
ASoC: tap6130a2: Use regmap
- Add tested-by from Sebastian
ASoC: tpa6130a2: Use snd soc volsw functions
- Add tested-by from Sebastian
ASoC: tpa6130a2: Add DAPM support
- Replace
+ {"TPA6130A2 HPLEFT", NULL, "LLOUT"},
+ {"TPA6130A2 HPRIGHT", NULL, "RLOUT"}
by
+ {"TPA6130A2 LEFTIN", NULL, "LLOUT"},
+ {"TPA6130A2 RIGHTIN", NULL, "RLOUT"},
- Add tested-by and reviewed-by from Sebastian
- Add struct device dev* in struct tpa6130a2_data and pass data instead
of dev to tpa6130a2_power function
- remove #include "../codecs/tpa6130a2.h" in rx51.c
ASoC: tpa6130a2: Remove goto err_gpio
- this is a new patch in the series
--
1.9.1
[PATCH v2 3/5] ASoC: tpa6130a2: Use snd soc volsw functions
Use snd_soc_{info,get,put}_volsw instead of custom volume functions
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
[On N900]
Tested-By: Sebastian Reichel
---
Changes since v1:
- Add tested-by from Sebastian
sound/soc/codecs/tpa6130a2.c | 64 ++--
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index d90388a..81bf584 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -114,64 +114,6 @@ exit:
return ret;
}
-static int tpa6130a2_get_volsw(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
-{
- struct soc_mixer_control *mc =
- (struct soc_mixer_control *)kcontrol->private_value;
- struct tpa6130a2_data *data;
- unsigned int reg = mc->reg;
- unsigned int shift = mc->shift;
- int max = mc->max, val;
- unsigned int mask = (1 << fls(max)) - 1;
- unsigned int invert = mc->invert;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- mutex_lock(&data->mutex);
-
- regmap_read(data->regmap, reg, &val);
- ucontrol->value.integer.value[0] = (val >> shift) & mask;
-
- if (invert)
- ucontrol->value.integer.value[0] =
- max - ucontrol->value.integer.value[0];
-
- mutex_unlock(&data->mutex);
- return 0;
-}
-
-static int tpa6130a2_put_volsw(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
-{
- struct soc_mixer_control *mc =
- (struct soc_mixer_control *)kcontrol->private_value;
- struct tpa6130a2_data *data;
- unsigned int reg = mc->reg;
- unsigned int shift = mc->shift;
- int max = mc->max;
- unsigned int mask = (1 << fls(max)) - 1;
- unsigned int invert = mc->invert;
- unsigned int val = (ucontrol->value.integer.value[0] & mask);
- bool change;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- if (invert)
- val = max - val;
-
- mutex_lock(&data->mutex);
- regmap_update_bits_check(data->regmap, reg, mask << shift, val << shift,
-&change);
- mutex_unlock(&data->mutex);
-
- return change;
-}
-
/*
* TPA6130 volume. From -59.5 to 4 dB with increasing step size when going
* down in gain.
@@ -190,9 +132,8 @@ static const DECLARE_TLV_DB_RANGE(tpa6130_tlv,
);
static const struct snd_kcontrol_new tpa6130a2_controls[] = {
- SOC_SINGLE_EXT_TLV("Headphone Playback Volume",
+ SOC_SINGLE_TLV("Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 0, 0x3f, 0,
- tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6130_tlv),
};
@@ -203,9 +144,8 @@ static const DECLARE_TLV_DB_RANGE(tpa6140_tlv,
);
static const struct snd_kcontrol_new tpa6140a2_controls[] = {
- SOC_SINGLE_EXT_TLV("Headphone Playback Volume",
+ SOC_SINGLE_TLV("Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 1, 0x1f, 0,
- tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6140_tlv),
};
--
1.9.1
[PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support
Add DAPM support and updated rx51 accordingly.
As a consequence:
- the exported function tpa6130a2_stereo_enable is not needed anymore
- the mutex is dealt in the DAPM
- the power state is tracked by the DAPM
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
Tested-By: Sebastian Reichel
Reviewed-By: Sebastian Reichel
---
Changes since v1:
- Replace
+ {"TPA6130A2 HPLEFT", NULL, "LLOUT"},
+ {"TPA6130A2 HPRIGHT", NULL, "RLOUT"}
by
+ {"TPA6130A2 LEFTIN", NULL, "LLOUT"},
+ {"TPA6130A2 RIGHTIN", NULL, "RLOUT"},
- Add tested-by and reviewed-by from Sebastian
- Add struct device dev* in struct tpa6130a2_data and pass data instead
of dev to tpa6130a2_power function
- remove #include "../codecs/tpa6130a2.h" in rx51.c
sound/soc/codecs/tpa6130a2.c | 184 ++-
sound/soc/codecs/tpa6130a2.h | 11 +--
sound/soc/omap/rx51.c| 23 ++
3 files changed, 88 insertions(+), 130 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 81bf584..cc83870 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -41,79 +41,73 @@ enum tpa_model {
TPA6140A2,
};
-static struct i2c_client *tpa6130a2_client;
-
/* This struct is used to save the context */
struct tpa6130a2_data {
- struct mutex mutex;
+ struct device *dev;
struct regmap *regmap;
struct regulator *supply;
int power_gpio;
- u8 power_state:1;
enum tpa_model id;
};
-static int tpa6130a2_power(u8 power)
+static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
{
- struct tpa6130a2_data *data;
- int ret = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- mutex_lock(&data->mutex);
- if (power == data->power_state)
- goto exit;
+ int ret;
- if (power) {
+ if (enable) {
ret = regulator_enable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
+ dev_err(data->dev,
"Failed to enable supply: %d\n", ret);
- goto exit;
+ return ret;
}
/* Power on */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 1);
-
- data->power_state = 1;
- ret = regcache_sync(data->regmap);
- if (ret < 0) {
- dev_err(&tpa6130a2_client->dev,
- "Failed to initialize chip\n");
- if (data->power_gpio >= 0)
- gpio_set_value(data->power_gpio, 0);
- regulator_disable(data->supply);
- data->power_state = 0;
- goto exit;
- }
} else {
- /* set SWS */
- regmap_update_bits(data->regmap, TPA6130A2_REG_CONTROL,
- TPA6130A2_SWS, TPA6130A2_SWS);
-
/* Power off */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 0);
ret = regulator_disable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
+ dev_err(data->dev,
"Failed to disable supply: %d\n", ret);
- goto exit;
+ return ret;
}
- data->power_state = 0;
/* device regs does not match the cache state anymore */
regcache_mark_dirty(data->regmap);
}
-exit:
- mutex_unlock(&data->mutex);
return ret;
}
+static int tpa6130a2_power_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *kctrl, int event)
+{
+ struct snd_soc_component *c = snd_soc_dapm_to_component(w->dapm);
+ struct tpa6130a2_data *data = snd_soc_component_get_drvdata(c);
+ int ret;
+
+ /* before widget power up */
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /* Turn on the chip */
+ tpa6130a2_power(data, true);
+ /* Sync the registers */
+ ret = regcache_sync(data->regmap);
+ if (ret < 0) {
+ dev_err(c->dev, "Failed to initialize chip\n");
+ tpa6130a2_power(data, false);
+ return ret;
+ }
+
[PATCH v2 1/5] ASoC: tpa6130a2: Register component
Add tpa6130a2 controls by the component API and update rx51 accordingly
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
Tested-By: Sebastian Reichel
Reviewed-By: Sebastian Reichel
---
Changes since v1:
- Remove prefix from snd_kcontrol_new in tpa6130a2.c
- Add tested-by and reviewd-by from Sebastian
sound/soc/codecs/tpa6130a2.c | 30 +++---
sound/soc/codecs/tpa6130a2.h | 1 -
sound/soc/omap/rx51.c| 23 ---
3 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 11d85c5..f31326a 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -273,7 +273,7 @@ static const DECLARE_TLV_DB_RANGE(tpa6130_tlv,
);
static const struct snd_kcontrol_new tpa6130a2_controls[] = {
- SOC_SINGLE_EXT_TLV("TPA6130A2 Headphone Playback Volume",
+ SOC_SINGLE_EXT_TLV("Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 0, 0x3f, 0,
tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6130_tlv),
@@ -286,7 +286,7 @@ static const DECLARE_TLV_DB_RANGE(tpa6140_tlv,
);
static const struct snd_kcontrol_new tpa6140a2_controls[] = {
- SOC_SINGLE_EXT_TLV("TPA6140A2 Headphone Playback Volume",
+ SOC_SINGLE_EXT_TLV("Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 1, 0x1f, 0,
tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6140_tlv),
@@ -348,23 +348,22 @@ int tpa6130a2_stereo_enable(struct snd_soc_codec *codec,
int enable)
}
EXPORT_SYMBOL_GPL(tpa6130a2_stereo_enable);
-int tpa6130a2_add_controls(struct snd_soc_codec *codec)
+static int tpa6130a2_component_probe(struct snd_soc_component *component)
{
- struct tpa6130a2_data *data;
-
- if (tpa6130a2_client == NULL)
- return -ENODEV;
-
- data = i2c_get_clientdata(tpa6130a2_client);
+ struct tpa6130a2_data *data = snd_soc_component_get_drvdata(component);
if (data->id == TPA6140A2)
- return snd_soc_add_codec_controls(codec, tpa6140a2_controls,
- ARRAY_SIZE(tpa6140a2_controls));
+ return snd_soc_add_component_controls(component,
+ tpa6140a2_controls, ARRAY_SIZE(tpa6140a2_controls));
else
- return snd_soc_add_codec_controls(codec, tpa6130a2_controls,
- ARRAY_SIZE(tpa6130a2_controls));
+ return snd_soc_add_component_controls(component,
+ tpa6130a2_controls, ARRAY_SIZE(tpa6130a2_controls));
}
-EXPORT_SYMBOL_GPL(tpa6130a2_add_controls);
+
+struct snd_soc_component_driver tpa6130a2_component_driver = {
+ .name = "tpa6130a2",
+ .probe = tpa6130a2_component_probe,
+};
static int tpa6130a2_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -451,7 +450,8 @@ static int tpa6130a2_probe(struct i2c_client *client,
if (ret != 0)
goto err_gpio;
- return 0;
+ return devm_snd_soc_register_component(&client->dev,
+ &tpa6130a2_component_driver, NULL, 0);
err_gpio:
tpa6130a2_client = NULL;
diff --git a/sound/soc/codecs/tpa6130a2.h b/sound/soc/codecs/tpa6130a2.h
index 4174440..78ee723 100644
--- a/sound/soc/codecs/tpa6130a2.h
+++ b/sound/soc/codecs/tpa6130a2.h
@@ -56,7 +56,6 @@
/* TPA6130A2_REG_VERSION (0x04) */
#define TPA6130A2_VERSION_MASK (0x0f)
-extern int tpa6130a2_add_controls(struct snd_soc_codec *codec);
extern int tpa6130a2_stereo_enable(struct snd_soc_codec *codec, int enable);
#endif /* __TPA6130A2_H__ */
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index 5494924..b59cf89 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -286,16 +286,10 @@ static const struct snd_kcontrol_new
aic34_rx51_controls[] = {
static int rx51_aic34_init(struct snd_soc_pcm_runtime *rtd)
{
- struct snd_soc_codec *codec = rtd->codec;
struct snd_soc_card *card = rtd->card;
struct rx51_audio_pdata *pdata = snd_soc_card_get_drvdata(card);
int err;
- err = tpa6130a2_add_controls(codec);
- if (err < 0) {
- dev_err(card->dev, "Failed to add TPA6130A2 controls\n");
- return err;
- }
snd_soc_limit_volume(card, "TPA6130A2 Headphone Playback Volume", 42);
err = omap_mcbsp_st_add_controls(rtd, 2);
@@ -357,6 +351,10 @@ static struct snd_soc_aux_dev rx51_aux_dev[] = {
.name = "TLV320AIC34b",
.codec_name = "tlv320aic3x-codec.2-0019",
},
+ {
+ .name = "TPA61320A2",
+ .codec_n
[PATCH v2 2/5] ASoC: tap6130a2: Use regmap
Use regmap instead of open-coding IO access and caching
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
[On N900]
Tested-By: Sebastian Reichel
---
Changes since v1:
- Add tested-by from Sebastian
sound/soc/codecs/tpa6130a2.c | 166 ---
sound/soc/codecs/tpa6130a2.h | 2 -
2 files changed, 46 insertions(+), 122 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index f31326a..d90388a 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "tpa6130a2.h"
@@ -45,92 +46,16 @@ static struct i2c_client *tpa6130a2_client;
/* This struct is used to save the context */
struct tpa6130a2_data {
struct mutex mutex;
- unsigned char regs[TPA6130A2_CACHEREGNUM];
+ struct regmap *regmap;
struct regulator *supply;
int power_gpio;
u8 power_state:1;
enum tpa_model id;
};
-static int tpa6130a2_i2c_read(int reg)
-{
- struct tpa6130a2_data *data;
- int val;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- /* If powered off, return the cached value */
- if (data->power_state) {
- val = i2c_smbus_read_byte_data(tpa6130a2_client, reg);
- if (val < 0)
- dev_err(&tpa6130a2_client->dev, "Read failed\n");
- else
- data->regs[reg] = val;
- } else {
- val = data->regs[reg];
- }
-
- return val;
-}
-
-static int tpa6130a2_i2c_write(int reg, u8 value)
-{
- struct tpa6130a2_data *data;
- int val = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- if (data->power_state) {
- val = i2c_smbus_write_byte_data(tpa6130a2_client, reg, value);
- if (val < 0) {
- dev_err(&tpa6130a2_client->dev, "Write failed\n");
- return val;
- }
- }
-
- /* Either powered on or off, we save the context */
- data->regs[reg] = value;
-
- return val;
-}
-
-static u8 tpa6130a2_read(int reg)
-{
- struct tpa6130a2_data *data;
-
- if (WARN_ON(!tpa6130a2_client))
- return 0;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- return data->regs[reg];
-}
-
-static int tpa6130a2_initialize(void)
-{
- struct tpa6130a2_data *data;
- int i, ret = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- for (i = 1; i < TPA6130A2_REG_VERSION; i++) {
- ret = tpa6130a2_i2c_write(i, data->regs[i]);
- if (ret < 0)
- break;
- }
-
- return ret;
-}
-
static int tpa6130a2_power(u8 power)
{
struct tpa6130a2_data *data;
- u8 val;
int ret = 0;
if (WARN_ON(!tpa6130a2_client))
@@ -153,7 +78,7 @@ static int tpa6130a2_power(u8 power)
gpio_set_value(data->power_gpio, 1);
data->power_state = 1;
- ret = tpa6130a2_initialize();
+ ret = regcache_sync(data->regmap);
if (ret < 0) {
dev_err(&tpa6130a2_client->dev,
"Failed to initialize chip\n");
@@ -165,9 +90,8 @@ static int tpa6130a2_power(u8 power)
}
} else {
/* set SWS */
- val = tpa6130a2_read(TPA6130A2_REG_CONTROL);
- val |= TPA6130A2_SWS;
- tpa6130a2_i2c_write(TPA6130A2_REG_CONTROL, val);
+ regmap_update_bits(data->regmap, TPA6130A2_REG_CONTROL,
+ TPA6130A2_SWS, TPA6130A2_SWS);
/* Power off */
if (data->power_gpio >= 0)
@@ -181,6 +105,8 @@ static int tpa6130a2_power(u8 power)
}
data->power_state = 0;
+ /* device regs does not match the cache state anymore */
+ regcache_mark_dirty(data->regmap);
}
exit:
@@ -196,7 +122,7 @@ static int tpa6130a2_get_volsw(struct snd_kcontrol
*kcontrol,
struct tpa6130a2_data *data;
unsigned int reg = mc->reg;
unsigned int shift = mc->shift;
- int max = mc->max;
+ int max = mc->max, val;
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
@@ -206,8 +132,8 @@ static int tpa6130a2_get_volsw(struct snd_kcontrol
*kcontrol,
mutex_lock(&data->mutex);
- ucontrol->value.integer.value[0
Re: [PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support
Hi Sebastian,
Thank you for reviewing the patches.
On 20-06-2016 14:12, Helen Koike wrote:
Add DAPM support and updated rx51 accordingly.
As a consequence:
- the exported function tpa6130a2_stereo_enable is not needed anymore
- the mutex is dealt in the DAPM
- the power state is tracked by the DAPM
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
Tested-By: Sebastian Reichel
Reviewed-By: Sebastian Reichel
---
Changes since v1:
- Replace
+ {"TPA6130A2 HPLEFT", NULL, "LLOUT"},
+ {"TPA6130A2 HPRIGHT", NULL, "RLOUT"}
by
+ {"TPA6130A2 LEFTIN", NULL, "LLOUT"},
+ {"TPA6130A2 RIGHTIN", NULL, "RLOUT"},
- Add tested-by and reviewed-by from Sebastian
- Add struct device dev* in struct tpa6130a2_data and pass data instead
of dev to tpa6130a2_power function
- remove #include "../codecs/tpa6130a2.h" in rx51.c
I added these changes above and kept your tested-by and reviewed-by,
could you please confirm that I can keep them? As I changed more things
then you suggested.
Thank you
Helen
sound/soc/codecs/tpa6130a2.c | 184 ++-
sound/soc/codecs/tpa6130a2.h | 11 +--
sound/soc/omap/rx51.c| 23 ++
3 files changed, 88 insertions(+), 130 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 81bf584..cc83870 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -41,79 +41,73 @@ enum tpa_model {
TPA6140A2,
};
-static struct i2c_client *tpa6130a2_client;
-
/* This struct is used to save the context */
struct tpa6130a2_data {
- struct mutex mutex;
+ struct device *dev;
struct regmap *regmap;
struct regulator *supply;
int power_gpio;
- u8 power_state:1;
enum tpa_model id;
};
-static int tpa6130a2_power(u8 power)
+static int tpa6130a2_power(struct tpa6130a2_data *data, bool enable)
{
- struct tpa6130a2_data *data;
- int ret = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- mutex_lock(&data->mutex);
- if (power == data->power_state)
- goto exit;
+ int ret;
- if (power) {
+ if (enable) {
ret = regulator_enable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
+ dev_err(data->dev,
"Failed to enable supply: %d\n", ret);
- goto exit;
+ return ret;
}
/* Power on */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 1);
-
- data->power_state = 1;
- ret = regcache_sync(data->regmap);
- if (ret < 0) {
- dev_err(&tpa6130a2_client->dev,
- "Failed to initialize chip\n");
- if (data->power_gpio >= 0)
- gpio_set_value(data->power_gpio, 0);
- regulator_disable(data->supply);
- data->power_state = 0;
- goto exit;
- }
} else {
- /* set SWS */
- regmap_update_bits(data->regmap, TPA6130A2_REG_CONTROL,
- TPA6130A2_SWS, TPA6130A2_SWS);
-
/* Power off */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 0);
ret = regulator_disable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
+ dev_err(data->dev,
"Failed to disable supply: %d\n", ret);
- goto exit;
+ return ret;
}
- data->power_state = 0;
/* device regs does not match the cache state anymore */
regcache_mark_dirty(data->regmap);
}
-exit:
- mutex_unlock(&data->mutex);
return ret;
}
+static int tpa6130a2_power_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *kctrl, int event)
+{
+ struct snd_soc_component *c = snd_soc_dapm_to_component(w->dapm);
+ struct tpa6130a2_data *data = snd_soc_component_get_drvdata(c);
+ int ret;
+
+ /* before widget power up */
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /* Turn on the chip */
+ tpa6130a2_power(data, true);
+ /* Syn
[PATCH] ASoC: max9877: Remove unused function declaration
Remove unused function declaration from header Signed-off-by: Helen Koike --- sound/soc/codecs/max9877.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/codecs/max9877.h b/sound/soc/codecs/max9877.h index 6da7229..368343f 100644 --- a/sound/soc/codecs/max9877.h +++ b/sound/soc/codecs/max9877.h @@ -32,6 +32,4 @@ #define MAX9877_BYPASS (1 << 6) #define MAX9877_SHDN (1 << 7) -extern int max9877_add_controls(struct snd_soc_codec *codec); - #endif -- 1.9.1
[PATCH] ALSA: hda - Remove compilation warning
Remove the warning:
warning: ‘err’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Signed-off-by: Helen Koike
---
sound/hda/hdac_regmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c
index 87041dd..7be6ca1 100644
--- a/sound/hda/hdac_regmap.c
+++ b/sound/hda/hdac_regmap.c
@@ -279,7 +279,7 @@ static int hda_reg_write(void *context, unsigned int reg,
unsigned int val)
{
struct hdac_device *codec = context;
unsigned int verb;
- int i, bytes, err;
+ int i, bytes, err = 0;
int pm_lock = 0;
if (codec->caps_overwriting)
--
1.9.1
Re: [PATCH v2 4/5] ASoC: tpa6130a2: Add DAPM support
On 20-06-2016 16:44, Lars-Peter Clausen wrote:
+ /* before widget power up */
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /* Turn on the chip */
+ tpa6130a2_power(data, true);
+ /* Sync the registers */
+ ret = regcache_sync(data->regmap);
+ if (ret < 0) {
+ dev_err(c->dev, "Failed to initialize chip\n");
+ tpa6130a2_power(data, false);
+ return ret;
+ }
+ /* after widget power down */
+ } else
+ tpa6130a2_power(data, false);
checkpatch.pl should complain about this. Kernel code style is if one branch
has branches the other has to have it as well.
Weird, checkpatch.pl doesn't complain. I'll add the braces in v3, thank
you for reviewing
[PATCH] media: vimc: fix start stream when link is disabled
If link is disabled, media_entity_remote_pad returns NULL, causing a NULL pointer deference. Ignore links that are not enabled instead. Signed-off-by: Helen Koike --- drivers/media/platform/vimc/vimc-common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/vimc/vimc-common.c b/drivers/media/platform/vimc/vimc-common.c index dee1b9dfc4f6..867e24dbd6b5 100644 --- a/drivers/media/platform/vimc/vimc-common.c +++ b/drivers/media/platform/vimc/vimc-common.c @@ -276,6 +276,8 @@ int vimc_pipeline_s_stream(struct media_entity *ent, int enable) /* Start the stream in the subdevice direct connected */ pad = media_entity_remote_pad(&ent->pads[i]); + if (!pad) + continue; if (!is_media_entity_v4l2_subdev(pad->entity)) return -EINVAL; -- 2.19.1
[PATCH] media: vimc: add configfs API to configure the topology
Add API to allow userspace to create any type of topology in vimc using basic system calls such as mkdir/rmdir/read/write. Signed-off-by: Helen Koike --- Hi, This patch introduces the configufs API for configuring the topology in vimc while it removes the hardcoded topology, so now, when you load the module you need to create a device (no device will appear in your system by default) using mkdir/rmdir/write/read. Please see documentation in the patch. I was thinking in adding a device by default, but if I do it in configfs, userspace won't be able to delete the device (which might not be a problem), as I need to create it as a "default" group in configfs, or I can just not expose the default device in the configfs. What do you think? Thanks Helen Documentation/media/v4l-drivers/vimc.rst| 172 + drivers/media/platform/vimc/Kconfig | 7 +- drivers/media/platform/vimc/Makefile| 7 +- drivers/media/platform/vimc/vimc-capture.c | 46 +- drivers/media/platform/vimc/vimc-common.h | 58 +- drivers/media/platform/vimc/vimc-configfs.c | 665 drivers/media/platform/vimc/vimc-configfs.h | 30 + drivers/media/platform/vimc/vimc-core.c | 283 ++--- drivers/media/platform/vimc/vimc-core.h | 17 + drivers/media/platform/vimc/vimc-debayer.c | 51 +- drivers/media/platform/vimc/vimc-scaler.c | 49 +- drivers/media/platform/vimc/vimc-sensor.c | 43 +- 12 files changed, 1153 insertions(+), 275 deletions(-) create mode 100644 Documentation/media/v4l-drivers/vimc.rst create mode 100644 drivers/media/platform/vimc/vimc-configfs.c create mode 100644 drivers/media/platform/vimc/vimc-configfs.h create mode 100644 drivers/media/platform/vimc/vimc-core.h diff --git a/Documentation/media/v4l-drivers/vimc.rst b/Documentation/media/v4l-drivers/vimc.rst new file mode 100644 index ..28d3b02c7d30 --- /dev/null +++ b/Documentation/media/v4l-drivers/vimc.rst @@ -0,0 +1,172 @@ +The Virtual Media Controller Driver (vimc) += + +This driver emulates video4linux hardware of varios media topologies. It exposes +media devices through /dev/mediaX notes, video capture devices through +/dev/videoX and sub-devices through /dev/v4l-subdevX. + +A subdevice can be a sensor, a debayer or a scaler. + +To configure a media device of a given topology, a ConfigFS API is provided. + + +Configuring the driver through ConfigFS (Experimental) +-- + +.. note:: +This API is not finished yet and might change in the future. + +Mount configfs: +:: + $ mkdir /configfs + $ mount -t configfs none /configfs + +When loading the module, you see a folders name vimc +:: + $ tree /configfs/ + /configfs/ + `-- vimc + +1) Creating a media device +~~ + +To create a media device just create a new folder under /configfs/vimc/ + +Example: +:: + $ mkdir /configfs/vimc/mdev + $ tree /configfs/vimc/mdev + /configfs/vimc/mdev/ + |-- entities/ + |-- hotplug + `-- links/ + + 2 directories, 1 file + +2) Creating entities + + +To create an entity in the media device's topology, just create a folder under +/configfs/vimc//entities/ with the following format: + + : + +Where is one of the following: +:: + vimc-sensor + vimc-scaler + vimc-debayer + vimc-capture + +Example: +:: + $ mkdir /configfs/vimc/mdev/entities/vimc-sensor:my-sensor + $ mkdir /configfs/vimc/mdev/entities/vimc-capture:my-capture + $ tree /configfs/ + /configfs/ + `-- vimc/ + `-- mdev/ + |-- entities/ + | |-- vimc-capture:my-capture/ + | | `-- pad:sink:0/ + | `-- vimc-sensor:my-sensor/ + | `-- pad:source:0/ + |-- hotplug + `-- links/ + + 8 directories, 1 file + +3) Creating links +~ + +To create links between two entities in the topology, just create a folder under +/configfs/vimc//links/ with the following format: + + ":" + +Example: +:: + $ mkdir "/configfs/vimc/mdev/links/my-sensor:0->my-capture:0" + $ tree /configfs + /configfs/ + `-- vimc/ + `-- mdev/ + |-- entities/ + | |-- vimc-capture:my-capture/ + | | `-- pad:sink:0/ + | `-- vimc-sensor:my-sensor/ + | `-- pad:source:0/ + |-- hotplug + `-- links/ + `-- my-sensor:0->my-capture:0/ + `-- flags + + 9 directories, 2 files + +Change the attributes of the link by writing in the file +"/configfs/vimc//links//flags" + +Flag values are defined in :ref:`include/uapi/linux/media.h ` +( seek for ``MEDIA_LNK_FL_*``) + +1 - Ena
[PATCH] configfs: fix wrong name of struct in documentation
The name of the struct is configfs_bin_attribute instead of
configfs_attribute
Signed-off-by: Helen Koike
---
Documentation/filesystems/configfs/configfs.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/filesystems/configfs/configfs.txt
b/Documentation/filesystems/configfs/configfs.txt
index 3828e85345ae..16e606c11f40 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -216,7 +216,7 @@ be called whenever userspace asks for a write(2) on the
attribute.
[struct configfs_bin_attribute]
- struct configfs_attribute {
+ struct configfs_bin_attribute {
struct configfs_attribute cb_attr;
void*cb_private;
size_t cb_max_size;
--
2.19.1
Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE
Hi Tomasz, On 12/13/18 2:02 AM, Tomasz Figa wrote: > On Thu, Dec 6, 2018 at 1:12 AM Helen Koike wrote: >> >> Hi Ville >> >> On 11/27/18 11:34 AM, Ville Syrjälä wrote: >>> On Fri, Nov 23, 2018 at 07:53:26PM -0200, Helen Koike wrote: >>>> Allow userspace to identify if the driver supports async update. >>> >>> And what exactly is an "async update"? >> >> I agree we are lacking docs on this, I'll send in the next version as >> soon as we agree on a name (please see below). >> >> For reference: >> https://lists.freedesktop.org/archives/dri-devel/2017-April/138586.html >> >>> >>> I keep asking people to come up with the a better name for this, and to >>> document what it actually means. Recently I've been think we should >>> maybe just adopt the vulkan terminology (immediate/fifo/mailbox) to >>> avoid introducing yet another set of names for the same thing. We'd >>> still want to document things properly though. >> >> Another name it was suggested was "atomic amend", this feature basically >> allows userspace to complement an update previously sent (i.e. its in >> the queue and wasn't commited yet), it allows adding a plane update to >> the next commit. So what do you think in renaming it to "atomic amend"? > > Note that it doesn't seem to be what the code currently is doing. For > example, for cursor updates, it doesn't seem to be working on the > currently pending commit, but just directly issues an atomic async > update call to the planes. The code actually seems to fall back to a > normal sync commit, if there is an already pending commit touching the > same plane or including a modeset. It should fail as discussed at: https://patchwork.freedesktop.org/patch/243088/ There was the following code inside the drm_atomic_helper_async_check() in the previous patch which would fallback to a normal commit if there isn't any pending commit to amend: + if (!old_plane_state->commit) + return -EINVAL; In the v2 of the patch https://patchwork.freedesktop.org/patch/263712/ this got removed, but which means that async update will be enabled anyway. So the following code is wrong: - if (state->legacy_cursor_update) + if (state->async_update || state->legacy_cursor_update) state->async_update = !drm_atomic_helper_async_check(dev, state); Does it make sense? If yes I'll fix this in the next version of the Atomic IOCTL patch (and also those two patches should be in the same series, I'll send them together next time). Thanks for pointing this out. Please let me know if you still don't agree on the name "atomic amend", or if I am missing something. Helen > > Best regards, > Tomasz > >> Or do you suggest another name? I am not familiar with vulkan terminology. >> >> >> Thanks >> Helen >> >>> >>>> >>>> Signed-off-by: Enric Balletbo i Serra >>>> [prepared for upstream] >>>> Signed-off-by: Helen Koike >>>> >>>> --- >>>> Hi, >>>> >>>> This patch introduces the ASYNC_UPDATE cap, which originated from the >>>> discussion regarding DRM_MODE_ATOMIC_AMEND on [1], to allow user to >>>> figure that async_update exists. >>>> >>>> This was tested using a small program that exercises the uAPI for easy >>>> sanity testing. The program was created by Alexandros and modified by >>>> Enric to test the capability flag [2]. >>>> >>>> The test worked on a rockchip Ficus v1.1 board on top of mainline plus >>>> the patch to update cursors asynchronously through atomic plus the patch >>>> that introduces the ATOMIC_AMEND flag for the drm/rockchip driver. >>>> >>>> To test, just build the program and use the --atomic flag to use the cursor >>>> plane with the ATOMIC_AMEND flag. E.g. >>>> >>>> drm_cursor --atomic >>>> >>>> [1] https://patchwork.freedesktop.org/patch/243088/ >>>> [2] >>>> https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability >>>> >>>> Thanks >>>> Helen >>>> >>>> >>>> drivers/gpu/drm/drm_ioctl.c | 11 +++ >>>> include/uapi/drm/drm.h | 1 + >>>> 2 files changed, 12 insertions(+) >>>> >>>> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c >>>> index 94bd872
Re: [PATCH v2] drm/atomic: add ATOMIC_AMEND flag to the Atomic IOCTL.
Hello, On 12/13/18 7:01 AM, Daniel Vetter wrote: > On Thu, Dec 13, 2018 at 04:43:57PM +0900, Tomasz Figa wrote: >> Hi Helen, >> >> On Sat, Nov 24, 2018 at 6:54 AM Helen Koike >> wrote: >>> >>> This flag tells core to jump ahead the queued update if the conditions >>> in drm_atomic_async_check() are met. That means we are only able to do an >>> async update if no modeset is pending and update for the same plane is >>> not queued. >> >> First of all, thanks for the patch. Please see my comments below. >> >> If the description above applies (and AFAICT that's what the existing >> code does indeed), then this doesn't sound like "amend" to me. It >> sounds exactly as the kernel code calls it - "async update" or perhaps >> "instantaneous commit" could better describe it? There is an error in this patch (please, see below). Async should fail if there is no pending commit, at least is what I understand from the discussion at https://patchwork.freedesktop.org/patch/243088/ >> >>> >>> It uses the already in place infrastructure for async updates. >>> >>> It is useful for cursor updates and async PageFlips over the atomic >>> ioctl, otherwise in some cases updates may be delayed to the point the >>> user will notice it. Note that for now it's only enabled for cursor >>> planes. >>> >>> DRM_MODE_ATOMIC_AMEND should be passed to the Atomic IOCTL to use this >>> feature. >>> >>> Signed-off-by: Gustavo Padovan >>> Signed-off-by: Enric Balletbo i Serra >>> [updated for upstream] >>> Signed-off-by: Helen Koike >>> --- >>> Hi, >>> >>> This is the second attempt to introduce the new ATOMIC_AMEND flag for atomic >>> operations, see the commit message for a more detailed description. >>> >>> This was tested using a small program that exercises the uAPI for easy >>> sanity testing. The program was created by Alexandros and modified by >>> Enric to test the capability flag [2]. >>> >>> To test, just build the program and use the --atomic flag to use the cursor >>> plane with the ATOMIC_AMEND flag. E.g. >>> >>> drm_cursor --atomic >>> >>> The test worked on a rockchip Ficus v1.1 board on top of mainline plus >>> the patch to update cursors asynchronously through atomic for the >>> drm/rockchip driver plus the DRM_CAP_ASYNC_UPDATE patch. >>> >>> Alexandros also did a proof-of-concept to use this flag and draw cursors >>> using atomic if possible on ozone [1]. >>> >>> Thanks >>> Helen >>> >>> [1] https://chromium-review.googlesource.com/c/chromium/src/+/1092711 >>> [2] >>> https://gitlab.collabora.com/eballetbo/drm-cursor/commits/async-capability >>> >>> >>> Changes in v2: >>> - rebase tree >>> - do not fall back to a non-async update if if there isn't any >>> pending commit to amend >>> >>> Changes in v1: >>> - https://patchwork.freedesktop.org/patch/243088/ >>> - Only enable it if userspace requests it. >>> - Only allow async update for cursor type planes. >>> - Rename ASYNC_UPDATE for ATOMIC_AMEND. >>> >>> drivers/gpu/drm/drm_atomic_helper.c | 6 +- >>> drivers/gpu/drm/drm_atomic_uapi.c | 6 ++ >>> include/uapi/drm/drm_mode.h | 4 +++- >>> 3 files changed, 14 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >>> b/drivers/gpu/drm/drm_atomic_helper.c >>> index 269f1a74de38..333190c6a0a4 100644 >>> --- a/drivers/gpu/drm/drm_atomic_helper.c >>> +++ b/drivers/gpu/drm/drm_atomic_helper.c >>> @@ -934,7 +934,7 @@ int drm_atomic_helper_check(struct drm_device *dev, >>> if (ret) >>> return ret; >>> >>> - if (state->legacy_cursor_update) >>> + if (state->async_update || state->legacy_cursor_update) >>> state->async_update = !drm_atomic_helper_async_check(dev, >>> state); I just realized this is wrong, drm_atomic_helper_async_check() should return error if there is a pending old_plane_state->commit (this v2 patch is not doing this, but v1 was), if drm_atomic_helper_async_check() returned because of it, then we should return error here to scale this failure to userspace. Make sense? Tomasz, do you agree? >>> >>> return ret; >>> @@ -1602,6 +1602,10
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Hi Mauro, On 12/15/18 4:01 PM, Mauro Carvalho Chehab wrote: > Hi Lucas, > > > Em Sat, 15 Dec 2018 14:46:31 -0200 > Lucas A. M. Magalhães escreveu: > >> The previous code pipeline used the stack to walk on the graph and >> process a frame. Basically the vimc-sensor entity starts a thread that >> generates the frames and calls the propagate_process function to send >> this frame to each entity linked with a sink pad. The propagate_process >> will call the process_frame of the entities which will call the >> propagate_frame for each one of it's sink pad. This cycle will continue >> until it reaches a vimc-capture entity that will finally return and >> unstack. > > I didn't review the code yet, but I have a few comments about the > way you're describing this patch. > > When you mention about a "previous code pipeline". Well, by adding it > at the main body of the patch description, reviewers should expect > that you're mentioning an implementation that already reached upstream. > > I suspect that this is not the case here, as I don't think we merged > any recursive algorithm using the stack, as this is something that > we shouldn't do at Kernelspace, as a 4K stack is usually not OK > with recursive algorithms. > > So, it seems that this entire patch description (as-is) is bogus[1]. > > [1] if this is not the case and a recursive approach was indeed > sneaked into the Kernel, this is a bug. So, you should really > use the "Fixes:" meta-tag indicating what changeset this patch is > fixing, and a "Cc: sta...@vger.kernel.org", in order to hint > stable maintainers that this require backports. Just fyi, this is not the case, the current implementation in mainline is bogus indeed (implemented by me when I was starting kernel development, sorry about that and thanks Lucas for sending a fix). Not only when propagating the frame [1] but also when activating the pipeline [2]. But in any case this should be better written in the commit message. [1] Every entity calls vimc_propagate_frame() https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n506 That calls the process_frame() of each entity directly connected, that calls vimc_propagate_frame() again: https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-common.c#n237 [2] .s_stream is calling the .s_stream of the subdevices directly connected https://git.linuxtv.org/media_tree.git/tree/drivers/media/platform/vimc/vimc-debayer.c#n355 I was actually wondering if this is worthy in sending this to stable, as this implementation is not a real problem, because the topology in vimc is hardcoded and limited, and according to: https://www.kernel.org/doc/Documentation/process/stable-kernel-rules.rst "It must fix a real bug that bothers people" So as the topology is fixed (in the current implementation), the max number of nested calls is 4 (in the sensor->debayer->scaler->capture path), this doesn't triggers any bug to users. But this will be a problem once we have the configfs API in vimc. You could say that if your memory is low, this can be a problem in the current implementation, but then your system won't have memory for any 4 nested function calls anyway (which I think the kernel wouldn't work at all). Mauro, with that said, do you still think we should send this to stable? Thanks Helen > > Please notice that the patch description will be stored forever > at the git tree. Mentioning something that were never merged > (and that, years from now people will hardly remember, and will > have lots of trouble to seek as you didn't even mentioned any > ML archive with the past solution) shouldn't be done. > > So, you should rewrite the entire patch description explaining > what the current approach took by this patch does. Then, in order > to make easier for reviewers to compare with a previous implementation, > you can add a "---" line and then a description about why this approach > is better than the first version, e. g. something like: > > [PATCH v2] media: vimc: Add vimc-streamer for stream control > > Add a logic that will create a linear pipeline walking > backwards on the graph. When the stream starts it will simply > loop through the pipeline calling the respective process_frame > function for each entity on the pipeline. > > Signed-off-by: Your Name > > --- > > v2: The previous approach were to use a recursive function that > it was using the stack to walk on the graph and > process a frame. Basically the vimc-sensor entity starts a thread that > generates the frames and calls the propagate_process function to send > this frame to each entity linked with a sink pad. The propagate_process > will call the process_frame of the entities which will call the > propagate_frame for each one of it's sink pad. This cycle will continue > until it reaches a vimc-capture entity that will finally return and >
Re: [Lkcamp][PATCH] media: vimc: Add vimc-streamer for stream control
Hi Lucas,
Thank you for your patch, just some small comments below.
On 12/15/18 2:46 PM, Lucas A. M. Magalhães wrote:
> The previous code pipeline used the stack to walk on the graph and
> process a frame. Basically the vimc-sensor entity starts a thread that
> generates the frames and calls the propagate_process function to send
> this frame to each entity linked with a sink pad. The propagate_process
> will call the process_frame of the entities which will call the
> propagate_frame for each one of it's sink pad. This cycle will continue
> until it reaches a vimc-capture entity that will finally return and
> unstack.
>
> This solution had many problems:
> * It was a little bit slow
> * It was susceptible to a stack overflow as it made indiscriminate
> use of the stack.
> * It doesn't allow frame rate control
> * It was complex to understand
> * It doesn't allow pipeline control
>
> This commit proposes an alternative way to control vimc streams by
> having a streamer object. This object will create a linear pipeline
> walking backwards on the graph. When the stream starts it will simply
> loop through the pipeline calling the respective process_frame function
> for each entity on the pipeline.
>
> This solution has some premises which are true for now:
> * Two paths can never be enabled and streaming at the same time.
> * There is no entity streaming frames to two source pads at the same
> time.
> * There is no entity receiving frames from two sink pads at the same
> time.
>
> Signed-off-by: Lucas A. M. Magalhães
I won't comment on the commit message, as Mauro already sent a good review.
> ---
> Hi,
>
> This patch introduces a streamer controller library for the vimc
> driver. It's a step towards a optimized mode I've been discussing with
> Helen.
> I plan to pass a tpg struct through the pipeline. This tpg struct
> will be configured in each entity and the capture will generate the
> frames with the correct format at the end of the pipeline.
>
> Thanks,
> Lucas
>
> drivers/media/platform/vimc/Makefile| 3 +-
> drivers/media/platform/vimc/vimc-capture.c | 18 +-
> drivers/media/platform/vimc/vimc-common.c | 50 ++
> drivers/media/platform/vimc/vimc-common.h | 15 +-
> drivers/media/platform/vimc/vimc-debayer.c | 26 +--
> drivers/media/platform/vimc/vimc-scaler.c | 28 +---
> drivers/media/platform/vimc/vimc-sensor.c | 56 ++-
> drivers/media/platform/vimc/vimc-streamer.c | 176
> drivers/media/platform/vimc/vimc-streamer.h | 38 +
> 9 files changed, 268 insertions(+), 142 deletions(-)
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.c
> create mode 100644 drivers/media/platform/vimc/vimc-streamer.h
>
> diff --git a/drivers/media/platform/vimc/Makefile
> b/drivers/media/platform/vimc/Makefile
> index 4b2e3de7856e..c4fc8e7d365a 100644
> --- a/drivers/media/platform/vimc/Makefile
> +++ b/drivers/media/platform/vimc/Makefile
> @@ -5,6 +5,7 @@ vimc_common-objs := vimc-common.o
> vimc_debayer-objs := vimc-debayer.o
> vimc_scaler-objs := vimc-scaler.o
> vimc_sensor-objs := vimc-sensor.o
> +vimc_streamer-objs := vimc-streamer.o
>
> obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc_capture.o vimc_common.o
> vimc-debayer.o \
> - vimc_scaler.o vimc_sensor.o
> + vimc_scaler.o vimc_sensor.o vimc_streamer.o
> diff --git a/drivers/media/platform/vimc/vimc-capture.c
> b/drivers/media/platform/vimc/vimc-capture.c
> index 3f7e9ed56633..80d7515ec420 100644
> --- a/drivers/media/platform/vimc/vimc-capture.c
> +++ b/drivers/media/platform/vimc/vimc-capture.c
> @@ -24,6 +24,7 @@
> #include
>
> #include "vimc-common.h"
> +#include "vimc-streamer.h"
>
> #define VIMC_CAP_DRV_NAME "vimc-capture"
>
> @@ -44,7 +45,7 @@ struct vimc_cap_device {
> spinlock_t qlock;
> struct mutex lock;
> u32 sequence;
> - struct media_pipeline pipe;
> + struct vimc_stream stream;
> };
>
> static const struct v4l2_pix_format fmt_default = {
> @@ -248,14 +249,13 @@ static int vimc_cap_start_streaming(struct vb2_queue
> *vq, unsigned int count)
> vcap->sequence = 0;
>
> /* Start the media pipeline */
> - ret = media_pipeline_start(entity, &vcap->pipe);
> + ret = media_pipeline_start(entity, &vcap->stream.pipe);
> if (ret) {
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> return ret;
> }
>
> - /* Enable streaming from the pipe */
> - ret = vimc_pipeline_s_stream(&vcap->vdev.entity, 1);
> + ret = vimc_streamer_s_stream(&vcap->stream, &vcap->ved, 1);
> if (ret) {
> media_pipeline_stop(entity);
> vimc_cap_return_all_buffers(vcap, VB2_BUF_STATE_QUEUED);
> @@ -273,8 +273,7 @@ static void vimc_cap_stop_streaming(struct vb2_queue *vq)
> {
> struct vimc_cap_device *vcap = vb2_get_drv_priv(vq);
>
> - /* Disable streaming f
Re: [PATCH] media: vimc: add configfs API to configure the topology
Hi Hans, On 12/10/18 9:31 AM, Hans Verkuil wrote: > On 12/7/18 7:22 PM, Helen Koike wrote: >> Add API to allow userspace to create any type of topology in vimc using >> basic system calls such as mkdir/rmdir/read/write. >> >> Signed-off-by: Helen Koike >> >> --- >> Hi, >> >> This patch introduces the configufs API for configuring the topology in >> vimc while it removes the hardcoded topology, so now, when you load the >> module you need to create a device (no device will appear in your system >> by default) using mkdir/rmdir/write/read. >> Please see documentation in the patch. >> I was thinking in adding a device by default, but if I do it in >> configfs, userspace won't be able to delete the device (which might not >> be a problem), as I need to create it as a "default" group in configfs, >> or I can just not expose the default device in the configfs. >> What do you think? > > I don't like the idea of having a special default device. > > So I think the way this patch does it is fine. ok, nice. > >> >> Thanks >> Helen >> >> Documentation/media/v4l-drivers/vimc.rst| 172 + >> drivers/media/platform/vimc/Kconfig | 7 +- >> drivers/media/platform/vimc/Makefile| 7 +- >> drivers/media/platform/vimc/vimc-capture.c | 46 +- >> drivers/media/platform/vimc/vimc-common.h | 58 +- >> drivers/media/platform/vimc/vimc-configfs.c | 665 >> drivers/media/platform/vimc/vimc-configfs.h | 30 + >> drivers/media/platform/vimc/vimc-core.c | 283 ++--- >> drivers/media/platform/vimc/vimc-core.h | 17 + >> drivers/media/platform/vimc/vimc-debayer.c | 51 +- >> drivers/media/platform/vimc/vimc-scaler.c | 49 +- >> drivers/media/platform/vimc/vimc-sensor.c | 43 +- >> 12 files changed, 1153 insertions(+), 275 deletions(-) >> create mode 100644 Documentation/media/v4l-drivers/vimc.rst >> create mode 100644 drivers/media/platform/vimc/vimc-configfs.c >> create mode 100644 drivers/media/platform/vimc/vimc-configfs.h >> create mode 100644 drivers/media/platform/vimc/vimc-core.h >> >> diff --git a/Documentation/media/v4l-drivers/vimc.rst >> b/Documentation/media/v4l-drivers/vimc.rst >> new file mode 100644 >> index ..28d3b02c7d30 >> --- /dev/null >> +++ b/Documentation/media/v4l-drivers/vimc.rst >> @@ -0,0 +1,172 @@ >> +The Virtual Media Controller Driver (vimc) >> += >> + >> +This driver emulates video4linux hardware of varios media topologies. It >> exposes > > varios -> various ops, sorry about so many spelling mistakes, I'll pay more attention on this next time. > >> +media devices through /dev/mediaX notes, video capture devices through > > notes -> nodes > >> +/dev/videoX and sub-devices through /dev/v4l-subdevX. > > I'd add 'nodes' after videoX and v4l-subdevX as well. > >> + >> +A subdevice can be a sensor, a debayer or a scaler. >> + >> +To configure a media device of a given topology, a ConfigFS API is provided. >> + >> + >> +Configuring the driver through ConfigFS (Experimental) >> +-- >> + >> +.. note:: >> +This API is not finished yet and might change in the future. >> + >> +Mount configfs: >> +:: >> +$ mkdir /configfs >> +$ mount -t configfs none /configfs >> + >> +When loading the module, you see a folders name vimc >> +:: >> +$ tree /configfs/ >> +/configfs/ >> +`-- vimc >> + >> +1) Creating a media device >> +~~ >> + >> +To create a media device just create a new folder under /configfs/vimc/ >> + >> +Example: >> +:: >> +$ mkdir /configfs/vimc/mdev >> +$ tree /configfs/vimc/mdev >> +/configfs/vimc/mdev/ >> +|-- entities/ >> +|-- hotplug >> +`-- links/ >> + >> +2 directories, 1 file >> + >> +2) Creating entities >> + >> + >> +To create an entity in the media device's topology, just create a folder >> under >> +/configfs/vimc//entities/ with the following format: >> + >> +: >> + >> +Where is one of the following: >> +:: >> +vimc-sensor >> +vimc-scaler >> +vimc-debayer >> +vimc-capture >> + >> +Example: >> +:: >> +$ mkdir /configfs/vimc/mdev/entities
Re: [Lkcamp] [PATCH 2/4] Renames variable to fix shadow warning.
Hi Leonardo,
Thanks for the patch, just some small comments below.
Please, check previous log messages with git log
arch/x86/entry/vdso/vdso2c.h, you will see that most patches had the
prefix "x86/vdso:" in the commit message.
On 10/16/18 9:08 PM, Leonardo Brás wrote:
> Renames the char variable to avoid shadowing a variable previously
> declared on this function.
>
> Signed-off-by: Leonardo Brás
> ---
> arch/x86/entry/vdso/vdso2c.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/vdso2c.h b/arch/x86/entry/vdso/vdso2c.h
> index fa847a620f40..9466998d0f28 100644
> --- a/arch/x86/entry/vdso/vdso2c.h
> +++ b/arch/x86/entry/vdso/vdso2c.h
> @@ -93,11 +93,11 @@ static void BITSFUNC(go)(void *raw_addr, size_t raw_len,
> int k;
> ELF(Sym) *sym = raw_addr + GET_LE(&symtab_hdr->sh_offset) +
> GET_LE(&symtab_hdr->sh_entsize) * i;
> - const char *name = raw_addr + GET_LE(&strtab_hdr->sh_offset) +
> + const char *name2 = raw_addr + GET_LE(&strtab_hdr->sh_offset) +
> GET_LE(&sym->st_name);
Could you please use a more meaningful name instead of name2 please? I
believe sym_name should be fine.
>
> for (k = 0; k < NSYMS; k++) {
> - if (!strcmp(name, required_syms[k].name)) {
> + if (!strcmp(name2, required_syms[k].name)) {
> if (syms[k]) {
> fail("duplicate symbol %s\n",
>required_syms[k].name);
>
Regards
Helen
Re: [Lkcamp] [PATCH 3/4] kbuild: Removes unnecessary shadowed local variable and optimize testing.
Hi Leonardo,
On 10/16/18 9:09 PM, Leonardo Brás wrote:
> Removes an unnecessary shadowed local variable (start).
> Optimize test of isdigit:
> - If isalpha returns true, isdigit will return false, so no need to test.
This patch does two different things, it should be in two separated patches.
>
> Signed-off-by: Leonardo Brás
> ---
> scripts/asn1_compiler.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/scripts/asn1_compiler.c b/scripts/asn1_compiler.c
> index c146020fc783..08bb6e5fd6ad 100644
> --- a/scripts/asn1_compiler.c
> +++ b/scripts/asn1_compiler.c
> @@ -413,7 +413,7 @@ static void tokenise(char *buffer, char *end)
>
> /* Handle string tokens */
> if (isalpha(*p)) {
> - const char **dir, *start = p;
> + const char **dir;
>
> /* Can be a directive, type name or element
>* name. Find the end of the name.
> @@ -454,10 +454,9 @@ static void tokenise(char *buffer, char *end)
>
> tokens[tix++].token_type = TOKEN_TYPE_NAME;
> continue;
> - }
> + } else if (isdigit(*p)) {
> + /* Handle numbers */
Actually you can't do that, p is being altered in the first if statement.
>
> - /* Handle numbers */
> - if (isdigit(*p)) {
> /* Find the end of the number */
> q = p + 1;
> while (q < nl && (isdigit(*q)))
>
Regards
Helen
Re: [Lkcamp] [PATCH 4/4] Changes macro usage to avoid shadowing a variable.
Hi Leonardo,
Thanks for the patch, just some small comments below.
On 10/16/18 9:09 PM, Leonardo Brás wrote:
> Changes the usage of DEF_FIELD_ADDR in this function to create a
> reference and operate over it using an aux variable.
> It also changes the loop logic used to find duplicates, to avoid
> creating another variable.
>
> Signed-off-by: Leonardo Brás
> ---
> scripts/mod/file2alias.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 7be43697ff84..9ea1db2aefdb 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -641,25 +641,27 @@ static void do_pnp_card_entries(void *symval, unsigned
> long size,
> unsigned int i;
>
> device_id_check(mod->name, "pnp", size, id_size, symval);
> + DEF_FIELD_ADDR(symval, pnp_card_device_id, devs);
> + typeof(devs) devs_last;
>
> for (i = 0; i < count; i++) {
> unsigned int j;
> - DEF_FIELD_ADDR(symval + i*id_size, pnp_card_device_id, devs);
> + devs_last = devs + i * id_size;
>
> for (j = 0; j < PNP_MAX_DEVICES; j++) {
> - const char *id = (char *)(*devs)[j].id;
> - int i2, j2;
> + const char *id = (char *)(*devs_last)[j].id;
> + int j2;
> int dup = 0;
>
> if (!id[0])
> break;
>
> /* find duplicate, already added value */
> - for (i2 = 0; i2 < i && !dup; i2++) {
> - DEF_FIELD_ADDR(symval + i2*id_size,
> pnp_card_device_id, devs);
> + while ((devs_last -= id_size) >= devs) {
You forgot to consider the dup variable.
Also you inverted the order of this loop, I am not sure this is
important (I just took a quick look) but you need to be careful.
This is also hard to read, I would define another variant macro where
you can set any name of the variable, e.g.
#define DEF_FIELD_ADDR_VAR(m, devid, f, var) \
typeof(((struct devid *)0)->f) *var = ((m) + OFF_##devid##_##f)
In this way you don't need to change the logic, just the name of the
variable.
>
> for (j2 = 0; j2 < PNP_MAX_DEVICES; j2++) {
> - const char *id2 = (char
> *)(*devs)[j2].id;
> + const char *id2 =
> + (char *)(*devs_last)[j2].id;
>
> if (!id2[0])
> break;
>
Regards,
Helen
Re: [Lkcamp] [PATCH 1/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS
Hi Leonardo, Thanks for the patch. On 10/16/18 9:08 PM, Leonardo Brás wrote: > Adds -Wshadow=local on KBUILD_HOSTCFLAGS to show shadow warnings > on tools built for HOST. > > Signed-off-by: Leonardo Brás > --- > Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Makefile b/Makefile > index e8b599b4dcde..fb0a9ac195e7 100644 > --- a/Makefile > +++ b/Makefile > @@ -360,7 +360,7 @@ HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null) > > HOSTCC = gcc > HOSTCXX = g++ > -KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ > +KBUILD_HOSTCFLAGS := -Wall -Wshadow=local -Wmissing-prototypes > -Wstrict-prototypes -O2 \ > -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) \ > $(HOSTCFLAGS) > KBUILD_HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS) > I believe this should be the last patch on this series and not the first one to avoid commits in between where we have those warnings. Regards Helen
Re: [Lkcamp] [PATCH 0/4] Adds -Wshadow=local on KBUILD_HOSTCFLAGS
Hi Leonardo, Thanks for the patches. On 10/16/18 9:07 PM, Leonardo Brás wrote: > This patchset add -Wshadow=local on KBUILD_HOSTCFLAGS and fixes > all code that show this warning. > > The third patch was already submitted, but was not merged yet. > I like to think it's part of this patchset, but if it was > already merged, please ignore it. You can check if it was merged in the maintainers' tree, if it is not there then it is not merged :) imho, I would prefer if you submitted it as a v2 with an explanation of what changed since v1 (e.g. new commits) or even stating that nothing has changed and you just regrouped it. Or better, you could also not re-submit it and just point out that this series depends on a previous commit (with a link to it). > > Leonardo Brás (4): > Adds -Wshadow=local on KBUILD_HOSTCFLAGS > Renames variable to fix shadow warning. > kbuild: Removes unnecessary shadowed local variable and optimize > testing. > Changes macro usage to avoid shadowing a variable. > > Makefile | 2 +- > arch/x86/entry/vdso/vdso2c.h | 4 ++-- > scripts/asn1_compiler.c | 7 +++ > scripts/mod/file2alias.c | 14 -- > 4 files changed, 14 insertions(+), 13 deletions(-) > I hope this helps. Regards, Helen
Re: [PATCH v2 3/5] Creates macro to avoid variable shadowing
Hi Leonardo,
Thanks for your patch.
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
> the var name is the same as the struct element name.
>
> Signed-off-by: Leonardo Brás
> ---
> scripts/mod/file2alias.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 7be43697ff84..3015c0bdecb2 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -95,12 +95,20 @@ extern struct devtable *__start___devtable[],
> *__stop___devtable[];
> */
> #define DEF_FIELD(m, devid, f) \
> typeof(((struct devid *)0)->f) f = TO_NATIVE(*(typeof(f) *)((m) +
> OFF_##devid##_##f))
> +
> +/* Define a variable v that holds the address of field f of struct devid
> + * based at address m. Due to the way typeof works, for a field of type
> + * T[N] the variable has type T(*)[N], _not_ T*.
> + */
> +#define DEF_FIELD_ADDR_VAR(m, devid, f, v) \
> + typeof(((struct devid *)0)->f) *v = ((m) + OFF_##devid##_##f)
You created this macro but you don't use it below, maybe you forgot to
update the patch? Please check.
Helen
> +
> /* Define a variable f that holds the address of field f of struct devid
> * based at address m. Due to the way typeof works, for a field of type
> * T[N] the variable has type T(*)[N], _not_ T*.
> */
> #define DEF_FIELD_ADDR(m, devid, f) \
> - typeof(((struct devid *)0)->f) *f = ((m) + OFF_##devid##_##f)
> + DEF_FIELD_ADDR_VAR(m, devid, f, f)
>
> /* Add a table entry. We test function type matches while we're here. */
> #define ADD_TO_DEVTABLE(device_id, type, function) \
> @@ -641,25 +649,27 @@ static void do_pnp_card_entries(void *symval, unsigned
> long size,
> unsigned int i;
>
> device_id_check(mod->name, "pnp", size, id_size, symval);
> + DEF_FIELD_ADDR(symval, pnp_card_device_id, devs);
> + typeof(devs) devs_last;
>
> for (i = 0; i < count; i++) {
> unsigned int j;
> - DEF_FIELD_ADDR(symval + i*id_size, pnp_card_device_id, devs);
> + devs_last = devs + i * id_size;
>
> for (j = 0; j < PNP_MAX_DEVICES; j++) {
> - const char *id = (char *)(*devs)[j].id;
> - int i2, j2;
> + const char *id = (char *)(*devs_last)[j].id;
> + int j2;
> int dup = 0;
>
> if (!id[0])
> break;
>
> /* find duplicate, already added value */
> - for (i2 = 0; i2 < i && !dup; i2++) {
> - DEF_FIELD_ADDR(symval + i2*id_size,
> pnp_card_device_id, devs);
> + while ((devs_last -= id_size) >= devs && !dup) {
>
> for (j2 = 0; j2 < PNP_MAX_DEVICES; j2++) {
> - const char *id2 = (char
> *)(*devs)[j2].id;
> + const char *id2 =
> + (char *)(*devs_last)[j2].id;
>
> if (!id2[0])
> break;
>
Re: [PATCH v2 3/5] Creates macro to avoid variable shadowing
Hi Leonardo,
On 10/22/18 11:10 PM, Leonardo Brás wrote:
> Creates DEF_FIELD_ADDR_VAR as a more generic version of the DEF_FIELD_ADD
> macro, allowing usage of a variable name other than the struct element name.
> Also, sets DEF_FIELD_ADDR as a specific usage of DEF_FILD_ADDR_VAR in which
> the var name is the same as the struct element name.
>
> Signed-off-by: Leonardo Brás
> ---
> scripts/mod/file2alias.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 7be43697ff84..3015c0bdecb2 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -95,12 +95,20 @@ extern struct devtable *__start___devtable[],
> *__stop___devtable[];
> */
> #define DEF_FIELD(m, devid, f) \
> typeof(((struct devid *)0)->f) f = TO_NATIVE(*(typeof(f) *)((m) +
> OFF_##devid##_##f))
> +
> +/* Define a variable v that holds the address of field f of struct devid
> + * based at address m. Due to the way typeof works, for a field of type
> + * T[N] the variable has type T(*)[N], _not_ T*.
> + */
> +#define DEF_FIELD_ADDR_VAR(m, devid, f, v) \
> + typeof(((struct devid *)0)->f) *v = ((m) + OFF_##devid##_##f)
> +
> /* Define a variable f that holds the address of field f of struct devid
> * based at address m. Due to the way typeof works, for a field of type
> * T[N] the variable has type T(*)[N], _not_ T*.
> */
> #define DEF_FIELD_ADDR(m, devid, f) \
> - typeof(((struct devid *)0)->f) *f = ((m) + OFF_##devid##_##f)
> + DEF_FIELD_ADDR_VAR(m, devid, f, f)
>
> /* Add a table entry. We test function type matches while we're here. */
> #define ADD_TO_DEVTABLE(device_id, type, function) \
> @@ -641,25 +649,27 @@ static void do_pnp_card_entries(void *symval, unsigned
> long size,
> unsigned int i;
>
> device_id_check(mod->name, "pnp", size, id_size, symval);
> + DEF_FIELD_ADDR(symval, pnp_card_device_id, devs);
> + typeof(devs) devs_last;
>
> for (i = 0; i < count; i++) {
> unsigned int j;
> - DEF_FIELD_ADDR(symval + i*id_size, pnp_card_device_id, devs);
> + devs_last = devs + i * id_size;
Instead of doing all these changes, you could just modify here with
DEF_FIELD_ADDR_VAR(symval + i*id_size, pnp_card_device_id, devs,
devs_aux);
Like this you are not changing the logic in this file, you are just
renaming the variable which is more then enough to solve the -Wshadow
warning.
I don't it is worthy changing the logic.
Regards,
Helen.
>
> for (j = 0; j < PNP_MAX_DEVICES; j++) {
> - const char *id = (char *)(*devs)[j].id;
> - int i2, j2;
> + const char *id = (char *)(*devs_last)[j].id;
> + int j2;
> int dup = 0;
>
> if (!id[0])
> break;
>
> /* find duplicate, already added value */
> - for (i2 = 0; i2 < i && !dup; i2++) {
> - DEF_FIELD_ADDR(symval + i2*id_size,
> pnp_card_device_id, devs);
> + while ((devs_last -= id_size) >= devs && !dup) {
>
> for (j2 = 0; j2 < PNP_MAX_DEVICES; j2++) {
> - const char *id2 = (char
> *)(*devs)[j2].id;
> + const char *id2 =
> + (char *)(*devs_last)[j2].id;
>
> if (!id2[0])
> break;
>
Re: [PATCH 3/6] drm/rockchip: dsi: add ability to work as a phy instead of full dsi
ret;
+ mutex_lock(&dsi->usage_mutex);
+
+ if (dsi->usage_mode != DW_DSI_USAGE_IDLE) {
+ DRM_DEV_ERROR(dsi->dev, "dsi controller already in use\n");
+ mutex_unlock(&dsi->usage_mutex);
+ return -EBUSY;
+ }
+
+ dsi->usage_mode = DW_DSI_USAGE_DSI;
+ mutex_unlock(&dsi->usage_mutex);
+
ret = component_add(dsi->dev, &dw_mipi_dsi_rockchip_ops);
if (ret) {
DRM_DEV_ERROR(dsi->dev, "Failed to register component: %d\n",
@@ -1000,6 +1035,10 @@ static int dw_mipi_dsi_rockchip_host_detach(void
*priv_data,
component_del(dsi->dev, &dw_mipi_dsi_rockchip_ops);
+ mutex_lock(&dsi->usage_mutex);
+ dsi->usage_mode = DW_DSI_USAGE_IDLE;
+ mutex_unlock(&dsi->usage_mutex);
+
return 0;
}
@@ -1008,11 +1047,227 @@ static const struct dw_mipi_dsi_host_ops dw_mipi_dsi_rockchip_host_ops = {
.detach = dw_mipi_dsi_rockchip_host_detach,
};
+static int dw_mipi_dsi_rockchip_dphy_bind(struct device *dev,
+ struct device *master,
+ void *data)
+{
+ /*
+* Nothing to do when used as a dphy.
+* Just make the rest of Rockchip-DRM happy
+* by being here.
+*/
+
+ return 0;
+}
+
+static void dw_mipi_dsi_rockchip_dphy_unbind(struct device *dev,
+struct device *master,
+void *data)
+{
+ /* Nothing to do when used as a dphy. */
+}
+
+static const struct component_ops dw_mipi_dsi_rockchip_dphy_ops = {
+ .bind = dw_mipi_dsi_rockchip_dphy_bind,
+ .unbind = dw_mipi_dsi_rockchip_dphy_unbind,
+};
+
+static int dw_mipi_dsi_dphy_init(struct phy *phy)
+{
+ struct dw_mipi_dsi_rockchip *dsi = phy_get_drvdata(phy);
+ int ret;
+
+ mutex_lock(&dsi->usage_mutex);
+
+ if (dsi->usage_mode != DW_DSI_USAGE_IDLE) {
+ DRM_DEV_ERROR(dsi->dev, "dsi controller already in use\n");
+ mutex_unlock(&dsi->usage_mutex);
+ return -EBUSY;
+ }
+
+ dsi->usage_mode = DW_DSI_USAGE_PHY;
+ mutex_unlock(&dsi->usage_mutex);
+
+ ret = component_add(dsi->dev, &dw_mipi_dsi_rockchip_dphy_ops);
+ if (ret < 0)
+ goto err_graph;
+
+ if (dsi->cdata->dphy_rx_init) {
+ ret = clk_prepare_enable(dsi->pclk);
+ if (ret < 0)
+ goto err_init;
+
+ ret = clk_prepare_enable(dsi->grf_clk);
+ if (ret) {
+ clk_disable_unprepare(dsi->pclk);
+ goto err_init;
+ }
+
+ ret = dsi->cdata->dphy_rx_init(phy);
+ clk_disable_unprepare(dsi->grf_clk);
+ clk_disable_unprepare(dsi->pclk);
+ if (ret < 0)
+ goto err_init;
+ }
+
+ return 0;
+
+err_init:
+ component_del(dsi->dev, &dw_mipi_dsi_rockchip_dphy_ops);
+err_graph:
+ mutex_lock(&dsi->usage_mutex);
+ dsi->usage_mode = DW_DSI_USAGE_IDLE;
+ mutex_unlock(&dsi->usage_mutex);
+
+ return ret;
+}
+
+static int dw_mipi_dsi_dphy_exit(struct phy *phy)
+{
+ struct dw_mipi_dsi_rockchip *dsi = phy_get_drvdata(phy);
+
+ component_del(dsi->dev, &dw_mipi_dsi_rockchip_dphy_ops);
+
+ mutex_lock(&dsi->usage_mutex);
+ dsi->usage_mode = DW_DSI_USAGE_IDLE;
+ mutex_unlock(&dsi->usage_mutex);
+
+ return 0;
+}
+
+static int dw_mipi_dsi_dphy_configure(struct phy *phy, union
phy_configure_opts *opts)
+{
+ struct phy_configure_opts_mipi_dphy *config = &opts->mipi_dphy;
+ struct dw_mipi_dsi_rockchip *dsi = phy_get_drvdata(phy);
+ int ret;
+
+ ret = phy_mipi_dphy_config_validate(&opts->mipi_dphy);
+ if (ret)
+ return ret;
+
+ dsi->dphy_config = *config;
+ dsi->lane_mbps = div_u64(config->hs_clk_rate, 1000 * 1000 * 1);
+
+ return 0;
+}
+
+static int dw_mipi_dsi_dphy_power_on(struct phy *phy)
+{
+ struct dw_mipi_dsi_rockchip *dsi = phy_get_drvdata(phy);
+ int i, ret;
It seems "i" could be removed, use ret instead.
In general, the patch doesn't look wrong to me.
For the whole serie:
Acked-by: Helen Koike
Thanks
Helen
+
+ DRM_DEV_DEBUG(dsi->dev, "lanes %d - data_rate_mbps %u\n",
+ dsi->dphy_config.lanes, dsi->lane_mbps);
+
+ i = max_mbps_to_parameter(dsi->lane_mbps);
+ if (i < 0) {
+ DRM_DEV_ERROR(dsi->dev, "failed to get parameter for %dmbps
clock\n",
+ dsi->lane_mbps);
+ return i
Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update
On 3/15/19 8:29 AM, Michel Dänzer wrote:
> On 2019-03-15 11:25 a.m., Boris Brezillon wrote:
>> On Fri, 15 Mar 2019 11:11:36 +0100
>> Michel Dänzer wrote:
>>
>>> On 2019-03-14 6:51 p.m., Helen Koike wrote:
>>>> On 3/14/19 6:15 AM, Michel Dänzer wrote:
>>>>> On 2019-03-13 7:08 p.m., Helen Koike wrote:
>>>>>> On 3/13/19 6:58 AM, Michel Dänzer wrote:
>>>>>>> On 2019-03-13 4:42 a.m., Tomasz Figa wrote:
>>>>>>>> On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
>>>>>>>> wrote:
>>>>>>>>> On Tue, 12 Mar 2019 12:34:45 -0300
>>>>>>>>> Helen Koike wrote:
>>>>>>>>>> On 3/12/19 3:34 AM, Boris Brezillon wrote:
>>>>>>>>>>> On Mon, 11 Mar 2019 23:21:59 -0300
>>>>>>>>>>> Helen Koike wrote:
>>>>>>>>>>>
>>>>>>>>>>>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>>>>>>>>>>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>>>>>>>>>>>> @@ -912,30 +912,31 @@ static void
>>>>>>>>>>>> vop_plane_atomic_async_update(struct drm_plane *plane,
>>>>>>>>>>>> struct drm_plane_state
>>>>>>>>>>>> *new_state)
>>>>>>>>>>>> {
>>>>>>>>>>>>struct vop *vop = to_vop(plane->state->crtc);
>>>>>>>>>>>> - struct drm_plane_state *plane_state;
>>>>>>>>>>>> + struct drm_framebuffer *old_fb = plane->state->fb;
>>>>>>>>>>>>
>>>>>>>>>>>> - plane_state = plane->funcs->atomic_duplicate_state(plane);
>>>>>>>>>>>> - plane_state->crtc_x = new_state->crtc_x;
>>>>>>>>>>>> - plane_state->crtc_y = new_state->crtc_y;
>>>>>>>>>>>> - plane_state->crtc_h = new_state->crtc_h;
>>>>>>>>>>>> - plane_state->crtc_w = new_state->crtc_w;
>>>>>>>>>>>> - plane_state->src_x = new_state->src_x;
>>>>>>>>>>>> - plane_state->src_y = new_state->src_y;
>>>>>>>>>>>> - plane_state->src_h = new_state->src_h;
>>>>>>>>>>>> - plane_state->src_w = new_state->src_w;
>>>>>>>>>>>> -
>>>>>>>>>>>> - if (plane_state->fb != new_state->fb)
>>>>>>>>>>>> - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
>>>>>>>>>>>> -
>>>>>>>>>>>> - swap(plane_state, plane->state);
>>>>>>>>>>>> -
>>>>>>>>>>>> - if (plane->state->fb && plane->state->fb != new_state->fb) {
>>>>>>>>>>>> + /*
>>>>>>>>>>>> + * A scanout can still be occurring, so we can't drop the
>>>>>>>>>>>> reference to
>>>>>>>>>>>> + * the old framebuffer. To solve this we get a reference to
>>>>>>>>>>>> old_fb and
>>>>>>>>>>>> + * set a worker to release it later.
>>>>>>>>>>>
>>>>>>>>>>> Hm, doesn't look like an async update to me if we have to wait for
>>>>>>>>>>> the
>>>>>>>>>>> next VBLANK to happen to get the new content on the screen. Maybe we
>>>>>>>>>>> should reject async updates when old_fb != new_fb in the rk
>>>>>>>>>>> ->async_check() hook.
>>>>>>>>>>
>>>>>>>>>> Unless I am misunderstanding this, we don't wait here, we just grab a
>>>>>>>>>> reference to the fb in case it is being still used by the hw, so it
>>>>>>>>>> doesn't get released prematurely.
>>>>>>>>>
>>>>>>>>> I was just reacting to the comment that says the new FB should stay
>&g
Re: [Lkcamp] [PATCH] staging/rtl8723bs: Fix code indent.
Hi Beatriz,
Thank you for the patch, just some small comments.
Regarding the patch title, if you run
git log drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
You will see that commits starts with the following tags "staging:
rtl8723bs: "
Also, try to add a bit more information to the title, for example:
"staging: rtl8723bs: replace spaces by tabs"
See my other comments below:
On Wed, Apr 3, 2019 at 3:42 PM Beatriz Martins de Carvalho
wrote:
>
> Fix Error: code indent
Please, add more information to your messages, you can add which
checkpatch error you fixed.
See this example: https://lkml.org/lkml/2019/4/2/1184
Please, re-submit version 2 of this patch, it should start with: [PATCH v2]
If you are using git send-email, you can use the option "-v2" and it
will fix the title for you.
Remember to add a change log, see this example:
https://marc.info/?l=linux-kernel&m=154201089629031&w=2
See the change log after the "---". It is important to be after the
triple dashes, as this is a comment to help reviewers and it is not
meant for mainline.
I hope this helps! Let me know if you have any questions :)
Regards,
Helen
>
> Signed-off-by: Beatriz Martins de Carvalho
>
> ---
> drivers/staging/rtl8723bs/hal/hal_com_phycfg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> index 828b328adab8..fc49cdfcd477 100644
> --- a/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> +++ b/drivers/staging/rtl8723bs/hal/hal_com_phycfg.c
> @@ -1723,7 +1723,7 @@ s8 phy_get_tx_pwr_lmt(struct adapter *adapter, u32
> reg_pwr_tbl_sel,
> idx_rate_sctn = get_rate_sctn_idx(data_rate);
>
> if (band_type == BAND_ON_5G && idx_rate_sctn == 0)
> -DBG_871X("Wrong rate 0x%x: No CCK in 5G Band\n", DataRate);
> + DBG_871X("Wrong rate 0x%x: No CCK in 5G Band\n", DataRate);
>
> /* workaround for wrong index combination to obtain tx power limit,
> */
> /* OFDM only exists in BW 20M */
> --
> 2.17.1
>
>
> ___
> Lkcamp mailing list
> lkc...@lists.libreplanetbr.org
> https://lists.libreplanetbr.org/mailman/listinfo/lkcamp
Re: [RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)
Hi Hans,
Thank you for your comment, please see my reply below.
On 2/23/21 9:35 AM, Hans Verkuil wrote:
Hi Helen,
On 14/01/2021 19:07, Helen Koike wrote:
This is part of the multiplanar and singleplanar unification process.
v4l2_ext_pix_format is supposed to work for both cases.
We also add the concept of modifiers already employed in DRM to expose
HW-specific formats (like tiled or compressed formats) and allow
exchanging this information with the DRM subsystem in a consistent way.
Note that only V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] are accepted in
v4l2_ext_format, other types will be rejected if you use the
{G,S,TRY}_EXT_PIX_FMT ioctls.
New hooks have been added to v4l2_ioctl_ops to support those new ioctls
in drivers, but, in the meantime, the core takes care of converting
{S,G,TRY}_EXT_PIX_FMT requests into {S,G,TRY}_FMT so that old drivers can
still work if the userspace app/lib uses the new ioctls.
The conversion is also done the other around to allow userspace
apps/libs using {S,G,TRY}_FMT to work with drivers implementing the
_ext_ hooks.
I have some small comments below, but also one high level comment:
Regarding M variants of pixelformats: this patch 'normalizes' them to
regular pixelformats in the extended API. This makes life complicated,
and I wonder if this is the right approach.
Currently there are two reasons for a driver to support e.g. NV12M:
either luma and chroma need to be in two memory banks, or the luma
and chroma planes cannot be contiguous due to alignment requirements.
The first requirement is still valid for drivers that support the extended API.
The second requirement is no longer a reason to support NV12M. But I
don't think we should just drop NV12M support if it was already supported
before the conversion to this extended API. Since NV12M allocates two buffers
instead of one, it is still different from a regular NV12.
I don't see what would be the difference when using NV12 and NV12M in
Ext API.
NV12 could be used for both requirements. It would even allow the second
requirement with a single memory buffer.
I would prefer that such drivers support both NV12 and NV12M, so no
automatic conversion.
A related question is how to handle pixelformat enumeration: with the
extended API an NV12 format might work, but not with the old API (e.g.
due to memory alignment requirements). I wonder if a VIDIOC_ENUM_EXT_PIX_FMT
isn't needed.
We need VIDIOC_ENUM_EXT_PIX_FMT for modifiers, but we can add it later.
If the driver reports NV12M, userspace can use it and the framework
normilizes it.
VIDIOC_ENUM_EXT_PIX_FMT would report NV12 and NV12M, while VIDIOC_ENUM_FMT
would just report NV12M.
If NV12 and NV12M are equivalent in Ext API, I don't see why we would
report both (unless I'm missing something, which is probably the case).
The idea was to deprecate the M-variants one day.
Regards,
Helen
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
The main change here was fixing the conversion, so planes reflects color
planes,
and to implement this properly I made major refactors compared to the previous
version.
- struct v4l2_plane_ext_pix_format removed, using struct v4l2_plane_pix_format
instead (Tomasz)
- refer to drm_fourcc.h in struct v4l2_ext_pix_format docs (Hans)
- reorder colorimetry fields in struct v4l2_ext_pix_format (Hans)
- do not set Ext ioctls as valid for vid_out_overlay (Tomasz)
- refactor conversion functions, so planes are color planes (Tomasz)
- Don't explicitly check for e->modifier != 0 in
v4l2_ext_pix_format_to_format() (Tomasz)
- Use "ef" for extended formats in the framework for consistency (Tomasz)
- Handle xfer_func field in conversions (Tomasz)
- Zero reserved fields in v4l_s_ext_pix_fmt() and v4l_try_ext_pix_fmt() (Tomasz)
- Refactor format functions to use v4l_fmt_ioctl_via_ext()
- Several fixes/refactoring/changes
- Remove EXT API for touch devices
Changes in v5:
- change sizes and reorder fields to avoid holes in the struct and make
it the same for 32 and 64 bits
- removed __attribute__ ((packed)) from uapi structs
- Fix doc warning from make htmldocs
- Updated commit message with EXT_PIX prefix for the ioctls.
Changes in v4:
- Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
- Add reserved fields
- Removed num_planes from struct v4l2_ext_pix_format
- Removed flag field from struct v4l2_ext_pix_format, since the only
defined value is V4L2_PIX_FMT_FLAG_PREMUL_ALPHA only used by vsp1,
where we can use modifiers, or add it back later through the reserved
bits.
- In v4l2_ext_format_to_format(), check if modifier is != MOD_LINEAR &&
!= MOD_INVALID
- Fix type assignment in v4l_g_fmt_ext_pix()
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
-
[PATCH] test-media: wrap vivid code around $vivid variable
The script was trying to load vivid and run some commands on top of it even when $vivid = 0. Wrap all vivid code under $vivid variable. Signed-off-by: Helen Koike --- contrib/test/test-media | 66 - 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/contrib/test/test-media b/contrib/test/test-media index 10b7e89d..8cd8bc37 100755 --- a/contrib/test/test-media +++ b/contrib/test/test-media @@ -146,29 +146,29 @@ if [ $kmemleak -eq 1 ]; then echo clear >/sys/kernel/debug/kmemleak fi -rmmod vivid 2&>/dev/null -modprobe vivid n_devs=3 multiplanar=1,2,2 cache_hints=1,0,0 #allocators=0,1,1 -sleep 1 +if [ $vivid -eq 1 ]; then + rmmod vivid 2&>/dev/null + modprobe vivid n_devs=3 multiplanar=1,2,2 cache_hints=1,0,0 #allocators=0,1,1 + sleep 1 -tmp=`mktemp` + tmp=`mktemp` -if ! $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap ; then - echo "FAIL: the vivid module failed to load" | tee -a $tmp - echo "Grand Total for vivid: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp - echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - exit 0 -fi + if ! $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap ; then + echo "FAIL: the vivid module failed to load" | tee -a $tmp + echo "Grand Total for vivid: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp + echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" + exit 0 + fi -$v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-out -o1 -x width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-cap -i3 -v width=3840,height=2160,pixelformat=NM16 -$v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 -$v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-out -o1 -x width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-cap -i3 -v width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 -echo + echo -if [ $vivid -eq 1 ]; then dmesg -n notice echo echo vivid compliance tests, contiguous planes | tee /dev/kmsg @@ -287,6 +287,18 @@ if [ $vivid -eq 1 ]; then echo echo echo + + date + echo + echo unbind vivid | tee /dev/kmsg + echo + echo -n vivid.0 >/sys/bus/platform/drivers/vivid/unbind + sleep $unbind_time + echo + echo rmmod vivid | tee /dev/kmsg + echo + rmmod vivid + sleep $rmmod_time fi if [ $vim2m -eq 1 ]; then @@ -300,7 +312,7 @@ if [ $vim2m -eq 1 ]; then echo "FAIL: the vim2m module failed to load" | tee -a $tmp echo "Grand Total for vim2m: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - rmmod vivid + rmmod vim2m exit 0 fi @@ -373,7 +385,7 @@ if [ $vimc -eq 1 ]; then echo "FAIL: the vimc module failed to load" | tee -a $tmp echo "Grand Total for vimc: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - rmmod vivid + rmmod vimc exit 0 fi @@ -467,7 +479,7 @@ if [ $vicodec -eq 1 ]; then echo "FAIL: the vicodec module failed to load" | tee -a $tmp echo "Grand Total for vicodec: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - rmmod vivid + rmmod vicodec exit 0 fi @@ -603,18 +615,6 @@ if [ $vicodec -eq 1 ]; then echo fi -date -echo -echo unbind vivid | tee /dev/kmsg -echo -echo -n vivid.0 >/sys/bus/platform/drivers/vivid/unbind -sleep $unbind_time -echo -echo rmmod vivid | tee /dev/kmsg -echo -rmmod vivid -sleep $rmmod_time - if [ $vidtv -eq 1 ]; then rmmod dvb_vidtv_bridge dvb_vidtv_tuner dvb_vidtv_demod 2&>/dev/null modprobe vidtv -- 2.30.1
Re: [PATCH] test-media: wrap vivid code around $vivid variable
On 2/17/21 3:22 PM, Hans Verkuil wrote: On 17/02/2021 19:11, Helen Koike wrote: The script was trying to load vivid and run some commands on top of it even when $vivid = 0. Wrap all vivid code under $vivid variable. Signed-off-by: Helen Koike --- contrib/test/test-media | 66 - 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/contrib/test/test-media b/contrib/test/test-media index 10b7e89d..8cd8bc37 100755 --- a/contrib/test/test-media +++ b/contrib/test/test-media @@ -146,29 +146,29 @@ if [ $kmemleak -eq 1 ]; then echo clear >/sys/kernel/debug/kmemleak fi -rmmod vivid 2&>/dev/null -modprobe vivid n_devs=3 multiplanar=1,2,2 cache_hints=1,0,0 #allocators=0,1,1 Ah, no. Vivid is also used to test dmabuf for vim2m, vimc and vicodec tests. It functions as the allocator for the dma buffers in that case. So even if vivid isn't given, but only vim2m, vimc or vicodec, it should still be loaded. I see, thanks, ignore this patch then. At some point I had a doubt if the script was testing vimc or vivid for some nodes, but this was my mistake. Thanks Helen It isn't needed for vidtv, so I guess it could be disabled if only vidtv is tested. Regards, Hans -sleep 1 +if [ $vivid -eq 1 ]; then + rmmod vivid 2&>/dev/null + modprobe vivid n_devs=3 multiplanar=1,2,2 cache_hints=1,0,0 #allocators=0,1,1 + sleep 1 -tmp=`mktemp` + tmp=`mktemp` -if ! $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap ; then - echo "FAIL: the vivid module failed to load" | tee -a $tmp - echo "Grand Total for vivid: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp - echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - exit 0 -fi + if ! $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap ; then + echo "FAIL: the vivid module failed to load" | tee -a $tmp + echo "Grand Total for vivid: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp + echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" + exit 0 + fi -$v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-out -o1 -x width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-cap -i3 -v width=3840,height=2160,pixelformat=NM16 -$v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 -$v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 -$v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-000 -d vivid-000-vid-out -o1 -x width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-cap -i3 -v width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-001 -d vivid-001-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 + $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-cap -i3 -v width=3840,height=2160,pixelformat=NV24 + $v4l2_ctl -z platform:vivid-002 -d vivid-002-vid-out -o1 -x width=3840,height=2160,pixelformat=NM16 -echo + echo -if [ $vivid -eq 1 ]; then dmesg -n notice echo echo vivid compliance tests, contiguous planes | tee /dev/kmsg @@ -287,6 +287,18 @@ if [ $vivid -eq 1 ]; then echo echo echo + + date + echo + echo unbind vivid | tee /dev/kmsg + echo + echo -n vivid.0 >/sys/bus/platform/drivers/vivid/unbind + sleep $unbind_time + echo + echo rmmod vivid | tee /dev/kmsg + echo + rmmod vivid + sleep $rmmod_time fi if [ $vim2m -eq 1 ]; then @@ -300,7 +312,7 @@ if [ $vim2m -eq 1 ]; then echo "FAIL: the vim2m module failed to load" | tee -a $tmp echo "Grand Total for vim2m: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - rmmod vivid + rmmod vim2m exit 0 fi @@ -373,7 +385,7 @@ if [ $vimc -eq 1 ]; then echo "FAIL: the vimc module failed to load" | tee -a $tmp echo "Grand Total for vimc: Succeeded: 0, Failed: 1, Warnings: 0" | tee -a $tmp echo "Final Summary: 1, Succeeded: 0, Failed: 1, Warnings: 0" - rmmod vivid + rmmod vimc exit 0 fi @@ -467,7 +479,7 @@ if [ $vicodec -eq 1 ]; then echo "
Re: [RFC PATCH v6 00/11] media: v4l2: Add extended fmt and buffer ioctls
Hello,
On 1/14/21 3:07 PM, Helen Koike wrote:
> Hello,
>
> This is v6 of the Extended API for formats and buffers (see below the new
> API).
>
> The new API comes for free for old drivers through the conversion layer, which
> is independent of vb2.
>
> I completly refactored several patches. I would like to request comments not
> only in the uAPI, but also the kAPI for drivers, and I would appreciate any
> ideas on improving the quality of the code (in short: please review
> everything).
>
> NOTE: The Ext API wans't tested yet. My next step is to patch v4l2-compliance.
I implemented on libcamera to test it, please check:
https://lists.libcamera.org/pipermail/libcamera-devel/2021-February/017169.html
Thanks,
Helen
>
> Regression tests - v4l2-compliance with test-media script:
> vivid: http://ix.io/2M0G - Final Summary: 1856, Succeeded: 1856,
> Failed: 0, Warnings: 0)
> vimc: http://ix.io/2M0I - Final Summary: 488, Succeeded: 488, Failed:
> 0, Warnings: 0
>
> Git: https://gitlab.collabora.com/koike/linux/-/tree/v4l2/ext-api/v6
>
> v5:
> https://patchwork.linuxtv.org/project/linux-media/cover/20200804192939.2251988-1-helen.ko...@collabora.com/
> v4:
> https://patchwork.linuxtv.org/project/linux-media/cover/20200717115435.2632623-1-helen.ko...@collabora.com/
> v3: https://patchwork.linuxtv.org/cover/59345/
> v2: https://patchwork.kernel.org/project/linux-media/list/?series=101153
> v1: https://patchwork.kernel.org/project/linux-media/list/?series=93707
>
> Conversion layer:
> =
>
> * Old drivers implementing only ops->vidioc_*_fmt_vid_cap supports
> VIDIOC_*_EXT_PIX_FMT automatically with limitations[1].
>
> * New drivers implementing only ops->vidioc_*_ext_pix_fmt_vid_cap supports
> VIDIOC_*_FMT automatically.
>
> * Old drivers implementing only ops->vidioc_*buf support
> VIDIOC_EXT_*BUF automatically with limitations[2].
>
> * New drivers should implement both ops->vidioc_*buf and ops->vidioc_*buf
> to overcome limitations[2] and support both APIs.
> Which is easy with vb2:
> static const struct v4l2_ioctl_ops ioctl_ops = {
> ...
> + .vidioc_ext_qbuf = vb2_ioctl_ext_qbuf,
> + .vidioc_ext_dqbuf = vb2_ioctl_ext_dqbuf,
> ...
> }
> ...
> + /* Inform vb2 how to split the memory buffer in case a single one
> is used */
> + vb2_set_pixelformat(dev->pixelformat)
>
> [1] There are some limitations in the conversion such as modifiers that are
> ignored when converting v4l2_ext_pix_format to v4l_format
>
> [2] Ext API allows a single buffer with planes placed in random locations,
> which is not possible with v4l2_buffer.
>
>
> Major changes in v6:
>
>
> Fixed color planes vs memory planes handling.
>
> Removed VIDIOC_EXT_PREPARE_BUF, since this is an optimization, it doesn't
> blocks
> the API, we can add it later (my goal was to simplify this patchset).
>
> Removed VIDIOC_EXT_CREATE_BUFS, since this is useful only to MMAP (thus low
> priority)
> with the new format.
> Classic VIDIOC_CREATE_BUFS and VIDIOC_REQBUFS can still be used.
>
> Reformulated conversion layer as per above.
>
> Removed conversions in vb2, it is easier to add hooks to drivers.
>
> Fixed vb2 to allow Ext API only to Video types.
>
> API updates:
> * remove buffer and plane lengths
> * move `memory` field to v4l2_ext_buffer instead of v4l2_ext_plane
> * remove struct v4l2_plane_ext_pix_format
> * reordering
>
> Make Ext API valid only for Video types, and not for touch, vbi, meta, etc.
>
> Sereval code refactoring, simplification, fixes and applied suggestions from
> v5.
>
> New API (for convenience):
> ==
>
> int ioctl(int fd, VIDIOC_G_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
> int ioctl(int fd, VIDIOC_S_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
> int ioctl(int fd, VIDIOC_TRY_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
> int ioctl(int fd, VIDIOC_EXT_QBUF, struct v4l2_ext_buffer *argp)
> int ioctl(int fd, VIDIOC_EXT_DQBUF, struct v4l2_ext_buffer *argp)
>
> struct v4l2_ext_pix_format {
> __u32 type;
> __u32 width;
> __u32 height;
> __u32 field;
> struct v4l2_plane_pix_format plane_fmt[VIDEO_MAX_PLANES];
> __u32 pixelformat;
> __u64 modifier;
> __u32 colorspace;
> __u32 xfer_func;
> union {
> __u32 ycbcr_enc;
> __u32 hsv_enc;
> };
> __u32 quantization;
> __u32 reserved[9];
> };
>
> struct v4l2_ext_buffer {
> __u32 index;
>
Re: [PATCH] vimc: debayer: Add support for ARGB format
On 6/1/20 9:37 AM, Laurent Pinchart wrote:
> On Mon, Jun 01, 2020 at 05:46:26PM +0530, Kaaira Gupta wrote:
>> On Fri, May 29, 2020 at 05:43:57PM +0200, Dafna Hirschfeld wrote:
>>> Hi,
>>> Thanks for the patch
>>>
>>> I don't know how real devices handle ARGB formats,
>>> I wonder if it should be the part of the debayer.
>>
>> Hi! qcam tries to support BA24 as it is one of the formats that vimc
>> lists as its supported formats wih --list-formats. Shouldn't BA24 be
>> possible to capture with vimc?
>>
>> If yes, which entity should support it, if not debayer? Should there be
>> a separate conversion entity, or should we keep the support in debayer
>> itself for efficiency issues?
>
> At the hardware level, the de-bayering block usually produces RGB with 8
> or more bits per colour components (so 3xn, 24 bits for 8-bit depths).
> The conversion to 32-bit ARGB usually happens at the DMA engine level,
> in the formatter right in front of the DMA engine. Ideally the vimc
> pipeline should expose the same.
>
> From a performance point of view, it makes little sense to process the
> image in vimc through multiple steps. I think it would be best to
> generate the final image directly at the output of the pipeline.
[+ Lucas Magalhães]
Lucas was working on a patch for that, he sent an RFC[1] some time ago.
[1] https://patchwork.linuxtv.org/patch/60445/
It would be nice to have this indeed.
Regards,
Helen
>
>>> On 28.05.20 20:57, Kaaira Gupta wrote:
Running qcam for pixelformat 0x34324142 showed that vimc debayer does
not support it. Hence, add the support for Alpha (255).
>>>
>>> I would change the commit log to:
>>>
>>> Add support for V4L2_PIX_FMT_RGB24 format in the debayer
>>> and set the alpha channel to constant 255.
>>>
Signed-off-by: Kaaira Gupta
---
.../media/test-drivers/vimc/vimc-debayer.c| 27 ---
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/media/test-drivers/vimc/vimc-debayer.c
b/drivers/media/test-drivers/vimc/vimc-debayer.c
index c3f6fef34f68..f34148717a40 100644
--- a/drivers/media/test-drivers/vimc/vimc-debayer.c
+++ b/drivers/media/test-drivers/vimc/vimc-debayer.c
@@ -62,6 +62,7 @@ static const u32 vimc_deb_src_mbus_codes[] = {
MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
MEDIA_BUS_FMT_RGB888_1X32_PADHI,
+ MEDIA_BUS_FMT_ARGB_1X32
};
static const struct vimc_deb_pix_map vimc_deb_pix_map_list[] = {
@@ -322,15 +323,23 @@ static void vimc_deb_process_rgb_frame(struct
vimc_deb_device *vdeb,
unsigned int i, index;
vpix = vimc_pix_map_by_code(vdeb->src_code);
- index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
- for (i = 0; i < 3; i++) {
- switch (vpix->pixelformat) {
- case V4L2_PIX_FMT_RGB24:
- vdeb->src_frame[index + i] = rgb[i];
- break;
- case V4L2_PIX_FMT_BGR24:
- vdeb->src_frame[index + i] = rgb[2 - i];
- break;
+
+ if (vpix->pixelformat == V4L2_PIX_FMT_ARGB32) {
+ index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 4);
+ vdeb->src_frame[index] = 255;
+ for (i = 0; i < 3; i++)
+ vdeb->src_frame[index + i + 1] = rgb[i];
+ } else {
+ index = VIMC_FRAME_INDEX(lin, col, vdeb->sink_fmt.width, 3);
+ for (i = 0; i < 3; i++) {
+ switch (vpix->pixelformat) {
+ case V4L2_PIX_FMT_RGB24:
+ vdeb->src_frame[index + i] = rgb[i];
+ break;
+ case V4L2_PIX_FMT_BGR24:
+ vdeb->src_frame[index + i] = rgb[2 - i];
+ break;
+ }
}
}
}
>
Re: vimc: Add color descriptions to test image
On 6/1/20 10:53 AM, Kaaira Gupta wrote: > Hi! > > Currently there is no method to know if the test image generated by vimc > is correct (except for comparing it with a known 'correct' image). So, I > wanted to investigate about a possibility to add text to each color bar > of the generated pattern. I think currently vivid supports this > functionality as an optional control, so can we move it to a common > platform so that both VIVID and VIMC can supoort it? > > Thanks, > Kaaira > If it is useful I don't oppose, but I'm not sure how this is implemented in vivid (or if it is in tpg). I guess it is easier to judge from an RFC code :) Regards, Helen
Re: [PATCH v3 2/4] media: v4l2-common: add helper functions to call s_stream() callbacks
Hi Dafna,
On 5/21/20 9:03 AM, Dafna Hirschfeld wrote:
> Hi
>
> On 15.04.20 03:30, Helen Koike wrote:
>> Add v4l2_pipeline_stream_{enable,disable} helper functions to iterate
>> through the subdevices in a given stream (i.e following links from sink
>> to source) and call .s_stream() callback.
>>
>> Add stream_count on the subdevice object for simultaneous streaming from
>> different video devices which shares subdevices.
>>
>> Prevent calling .s_stream(true) if it was already called previously by
>> another stream.
>>
>> Prevent calling .s_stream(false) from one stream when there are still
>> others active.
>>
>> If .s_stream(true) fails, call .s_stream(false) in the reverse order.
>>
>> Signed-off-by: Helen Koike
>> ---
>>
>> Changes in v3:
>> - re-write helpers to use media walkers as in v1, but with
>> v4l2_pipeline_subdevs_get() to reverse the order we call s_stream(true)
>> in subdevices.
>> - rename size to max_size (and update docs) in v4l2_pipeline_subdevs_get() to
>> reflect the meaning of the argument.
>> - add if defined(CONFIG_MEDIA_CONTROLLER) around helpers
>>
>> Changes in v2:
>> - re-write helpers to not use media walkers
>>
>> drivers/media/v4l2-core/v4l2-common.c | 125 ++
>> include/media/v4l2-common.h | 43 +
>> include/media/v4l2-subdev.h | 2 +
>> 3 files changed, 170 insertions(+)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-common.c
>> b/drivers/media/v4l2-core/v4l2-common.c
>> index 9e8eb45a5b03c..2f991a1a57d7c 100644
>> --- a/drivers/media/v4l2-core/v4l2-common.c
>> +++ b/drivers/media/v4l2-core/v4l2-common.c
>> @@ -442,3 +442,128 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt,
>> u32 pixelformat,
>> return 0;
>> }
>> EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt);
>> +
>> +#if defined(CONFIG_MEDIA_CONTROLLER)
>> +
>> +/*
>> + * v4l2_pipeline_subdevs_get - Assemble a list of subdevices in a pipeline
>> + * @subdevs: the array to be filled.
>> + * @max_size: max number of elements that can fit in subdevs array.
>> + *
>> + * Walk from a video node, following links from sink to source and fill the
>> + * array with subdevices in the path.
>> + * The walker performs a depth-first traversal, which means that, in a
>> topology
>> + * sd1->sd2->sd3->vdev, sd1 will be the first element placed in the array.
>> + *
>> + * Return the number of subdevices filled in the array.
>> + */
>> +static int v4l2_pipeline_subdevs_get(struct video_device *vdev,
>> + struct media_pipeline *pipe,
>> + struct v4l2_subdev **subdevs,
>> + unsigned int max_size)
>> +{
>> + struct media_entity *entity = &vdev->entity;
>> + struct media_device *mdev = entity->graph_obj.mdev;
>> + int idx = 0;
>> + int ret;
>> +
>> + mutex_lock(&mdev->graph_mutex);
>> +
>> + if (!pipe->streaming_count) {
>> + ret = media_graph_walk_init(&pipe->graph, mdev);
>> + if (ret) {
>> + mutex_unlock(&mdev->graph_mutex);
>> + return ret;
>> + }
>> + }
>> +
>> + media_graph_walk_start(&pipe->graph, entity);
>> +
>> + while ((entity = media_graph_walk_next_stream(&pipe->graph))) {
>> + if (!is_media_entity_v4l2_subdev(entity))
>> + continue;
>> + if (WARN_ON(idx >= max_size)) {
>> + mutex_unlock(&mdev->graph_mutex);
>> + return -EINVAL;
>> + }
>> + subdevs[idx++] = media_entity_to_v4l2_subdev(entity);
>> + }
>> +
>> + if (!pipe->streaming_count)
>> + media_graph_walk_cleanup(&pipe->graph);
>> +
>> + mutex_unlock(&mdev->graph_mutex);
>> +
>> + return idx;
>> +}
>> +
>> +__must_check int v4l2_pipeline_stream_enable(struct video_device *vdev,
>> + struct media_pipeline *pipe)
>> +{
>> + struct media_device *mdev = vdev->entity.graph_obj.mdev;
>> + struct v4l2_subdev *subdevs[MEDIA_ENTITY_ENUM_MAX_DEPTH];
>> + struct v4l2_subdev *sd;
>> + int i, size, ret;
>> +
>> + size = v4l2_pipeline_subdevs_get(vdev, pipe,
>> + subdevs, ARRAY_SIZE(subdevs));
>> + if (size <= 0)
>> + return size;
>> +
>> + /* Call s_stream() in reverse o
Re: [PATCH v2 0/3] media: vimc: Allow multiple capture devices to use the same sensor
Hi, On 7/29/20 12:24 PM, Dafna Hirschfeld wrote: > > > On 29.07.20 15:27, Kieran Bingham wrote: >> Hi Dafna, Kaaira, >> >> On 29/07/2020 14:16, Dafna Hirschfeld wrote: >>> >>> >>> On 29.07.20 15:05, Kieran Bingham wrote: >>>> Hi Dafna, >>>> >>>> On 28/07/2020 15:00, Dafna Hirschfeld wrote: >>>>> >>>>> >>>>> On 28.07.20 14:07, Dafna Hirschfeld wrote: >>>>>> Hi >>>>>> >>>>>> On 28.07.20 13:39, Kaaira Gupta wrote: >>>>>>> On Mon, Jul 27, 2020 at 02:54:30PM -0300, Helen Koike wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 7/27/20 11:31 AM, Kieran Bingham wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> +Dafna for the thread discussion, as she's missed from the to/cc >>>>>>>>> list. >>>>>>>>> >>>>>>>>> >>>>>>>>> On 24/07/2020 13:21, Kaaira Gupta wrote: >>>>>>>>>> On Fri, Jul 24, 2020 at 02:15:21PM +0200, Niklas Söderlund wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>>> Hi Kaaira, >>>>>>>>>>> >>>>>>>>>>> Thanks for your work. >>>>>>>>>> >>>>>>>>>> Thanks for yours :D >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2020-07-24 17:32:10 +0530, Kaaira Gupta wrote: >>>>>>>>>>>> This is version 2 of the patch series posted by Niklas for >>>>>>>>>>>> allowing >>>>>>>>>>>> multiple streams in VIMC. >>>>>>>>>>>> The original series can be found here: >>>>>>>>>>>> https://patchwork.kernel.org/cover/10948831/ >>>>>>>>>>>> >>>>>>>>>>>> This series adds support for two (or more) capture devices to be >>>>>>>>>>>> connected to the same sensors and run simultaneously. Each >>>>>>>>>>>> capture device >>>>>>>>>>>> can be started and stopped independent of each other. >>>>>>>>>>>> >>>>>>>>>>>> Patch 1/3 and 2/3 deals with solving the issues that arises once >>>>>>>>>>>> two >>>>>>>>>>>> capture devices can be part of the same pipeline. While 3/3 >>>>>>>>>>>> allows for >>>>>>>>>>>> two capture devices to be part of the same pipeline and thus >>>>>>>>>>>> allows for >>>>>>>>>>>> simultaneously use. >>>>>> >>>>>> I wonder if these two patches are enough, since each vimc entity also >>>>>> have >>>>>> a 'process_frame' callback, but only one allocated frame. That means >>>>>> that the 'process_frame' can be called concurrently by two different >>>>>> streams >>>>>> on the same frame and cause corruption. >>>>>> >>>>> >>>>> I think we should somehow change the vimc-stream.c code so that we have >>>>> only >>>>> one stream process per pipe. So if one capture is already streaming, >>>>> then the new >>>>> capture that wants to stream uses the same thread so we don't have two >>>>> threads >>>>> both calling 'process_frame'. >>>> >>>> >>>> Yes, I think it looks and sounds like there are two threads running when >>>> there are two streams. >>>> >>>> so in effect, although they 'share a pipe', aren't they in effect just >>>> sending two separate buffers through their stream-path? >>>> >>>> If that's the case, then I don't think there's any frame corruption, >>>> because they would both have grabbed their own frame separately. >>> >>> But each entity allocates just one buffer. So the same buffer is used for >>> both stream. >> >>
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Tomasz,
On 12/21/20 12:13 AM, Tomasz Figa wrote:
> On Thu, Dec 17, 2020 at 10:20 PM Helen Koike
> wrote:
>>
>> Hi Tomasz,
>>
>> Thanks for your comments, I have a few questions below.
>>
>> On 12/16/20 12:13 AM, Tomasz Figa wrote:
>>> On Tue, Dec 15, 2020 at 11:37 PM Helen Koike
>>> wrote:
>>>>
>>>> Hi Tomasz,
>>>>
>>>> On 12/14/20 7:46 AM, Tomasz Figa wrote:
>>>>> On Fri, Dec 4, 2020 at 4:52 AM Helen Koike
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please see my 2 points below (about v4l2_ext_buffer and another about
>>>>>> timestamp).
>>>>>>
>>>>>> On 12/3/20 12:11 PM, Hans Verkuil wrote:
>>>>>>> On 23/11/2020 18:40, Helen Koike wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/23/20 12:46 PM, Tomasz Figa wrote:
>>>>>>>>> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Hans,
>>>>>>>>>>
>>>>>>>>>> Thank you for your review.
>>>>>>>>>>
>>>>>>>>>> On 9/9/20 9:27 AM, Hans Verkuil wrote:
>>>>>>>>>>> Hi Helen,
>>>>>>>>>>>
>>>>>>>>>>> Again I'm just reviewing the uAPI.
>>>>>>>>>>>
>>>>>>>>>>> On 04/08/2020 21:29, Helen Koike wrote:
> [snip]
>>>
>>>>
>>>> Output: userspace fills plane information, informing in which memory
>>>> buffer each
>>>> plane was placed (Or should this be pre-determined by the driver?)
>>>>
>>>> For MMAP
>>>> ---
>>>> userspace performs EXT_CREATE_BUF ioctl to reserve a buffer "index" range
>>>> in
>>>> that mode, to be used in EXT_QBUF and EXT_DQBUF
>>>>
>>>> Should the API allow userspace to select how many memory buffers it wants?
>>>> (maybe not)
>>>
>>> I think it does allow that - it accepts the v4l2_ext_format struct.
>>
>> hmmm, I thought v4l2_ext_format would describe color planes, and not memory
>> planes.
>> Should it describe memory planes instead? Since planes are defined by the
>> pixelformat.
>> But is this information relevant to ext_{set/get/try} format?
>>
>
> Good point. I ended up assuming the current convention, where giving
> an M format would imply num_memory_planes == num_color_planes and
> non-M format num_memory_planes == 1. Sounds like we might want
> something like a flags field and that could have bits defined to
> select that. I think it would actually be useful for S_FMT as well,
> because that's what REQBUFS would use.
Would this flag select between memory and color planes?
I didn't understand how this flag would be useful to S_FMT, could you
please clarify?
Thanks
Helen
>
>>>
>>>>
>>>> userspace performs EXT_QUERY_MMAP_BUF to get the mmap offset/cookie and
>>>> length
>>>> for each memory buffer.
>>>>
>>>> On EXT_QBUF, userspace doesn't need to fill membuf information. Should the
>>>> mmap offset and length be filled by the kernel and returned to userspace
>>>> here
>>>> as well? I'm leaning towards: no.
>>>
>>> Yeah, based on my comment above, I think the answer should be no.
>>>
>>>>
>>>> If the answer is no, then here is my proposal:
>>>> --
>>>>
>>>> /* If MMAP, drivers decide how many memory buffers to allocate */
>>>> int ioctl( int fd, VIDIOC_EXT_CREATE_BUFS, struct v4l2_ext_buffer *argp )
>>>>
>>>> /* Returns -EINVAL if not MMAP */
>>>> int ioctl( int fd, VIDIOC_EXT_MMAP_QUERYBUF, struct v4l2_ext_mmap_querybuf
>>>> *argp )
>>>>
>>>> /* userspace fills v4l2_ext_buffer.membufs if DMA-fd or Userptr, leave it
>>>> zero for MMAP
>>>> * Should userspace also fill v4l2_ext_buffer.planes?
>>>> */
>>>> int ioctl( int fd, VIDIOC_EXT_QBUF, struct v4l2_ext_buffer *argp )
>>>>
>>>> /* v4l2_ext_buffer.membufs is set to zero by the driver */
>>>&
Re: [PATCH v5 7/7] media: docs: add documentation for the Extended API
On 11/20/20 10:20 AM, Hans Verkuil wrote: > On 20/11/2020 13:40, Tomasz Figa wrote: >> On Fri, Nov 20, 2020 at 9:24 PM Hans Verkuil wrote: >>> >>> On 20/11/2020 12:06, Tomasz Figa wrote:z >>>> Hi Helen, >>>> >>>> On Tue, Aug 04, 2020 at 04:29:39PM -0300, Helen Koike wrote: >>>>> Add documentation and update references in current documentation for the >>>>> Extended API. >>>>> >>>> >>>> Thank you for the patch. Please see my comments inline. >>>> >>>>> Signed-off-by: Helen Koike >>>>> --- >>>>> Changes in v5: >>>>> - new patch >>>>> >>>>> .../userspace-api/media/v4l/buffer.rst| 5 + >>>>> .../userspace-api/media/v4l/common.rst| 1 + >>>>> .../userspace-api/media/v4l/dev-capture.rst | 5 + >>>>> .../userspace-api/media/v4l/dev-output.rst| 5 + >>>>> .../userspace-api/media/v4l/ext-api.rst | 107 + >>>>> .../userspace-api/media/v4l/format.rst| 16 +- >>>>> .../userspace-api/media/v4l/user-func.rst | 5 + >>>>> .../media/v4l/vidioc-ext-create-bufs.rst | 95 >>>>> .../media/v4l/vidioc-ext-prepare-buf.rst | 62 ++ >>>>> .../media/v4l/vidioc-ext-qbuf.rst | 204 ++ >>>>> .../media/v4l/vidioc-ext-querybuf.rst | 79 +++ >>>>> .../media/v4l/vidioc-g-ext-pix-fmt.rst| 117 ++ >>>>> 12 files changed, 697 insertions(+), 4 deletions(-) >>>>> create mode 100644 Documentation/userspace-api/media/v4l/ext-api.rst >>>>> create mode 100644 >>>>> Documentation/userspace-api/media/v4l/vidioc-ext-create-bufs.rst >>>>> create mode 100644 >>>>> Documentation/userspace-api/media/v4l/vidioc-ext-prepare-buf.rst >>>>> create mode 100644 >>>>> Documentation/userspace-api/media/v4l/vidioc-ext-qbuf.rst >>>>> create mode 100644 >>>>> Documentation/userspace-api/media/v4l/vidioc-ext-querybuf.rst >>>>> create mode 100644 >>>>> Documentation/userspace-api/media/v4l/vidioc-g-ext-pix-fmt.rst >>>>> >>>>> diff --git a/Documentation/userspace-api/media/v4l/buffer.rst >>>>> b/Documentation/userspace-api/media/v4l/buffer.rst >>>>> index 57e752aaf414a..c832bedd64e4c 100644 >>>>> --- a/Documentation/userspace-api/media/v4l/buffer.rst >>>>> +++ b/Documentation/userspace-api/media/v4l/buffer.rst >>>>> @@ -27,6 +27,11 @@ such as pointers and sizes for each plane, are stored >>>>> in >>>>> struct :c:type:`v4l2_plane` instead. In that case, >>>>> struct :c:type:`v4l2_buffer` contains an array of plane structures. >>>>> >>>>> +.. note:: >>>>> + >>>>> +The :ref:`ext_api` version can also be used, and it is >>>>> +preferable when applicable. >>>> >>>> Would rephrasing this as below making a bit more definitive? >>>> >>>> For modern applications, these operations are replaced by their >>>> :ref:`ext_api` counterparts, which should be used instead. >>> >>> You can't say that, since especially in the beginning userspace will be >>> running >>> on older kernels that do not support this. >>> >>> This will work: "should be used instead, if supported by the driver." >>> >> >> With the wrappers that the patches provide, all drivers would support >> the new API, so this boils down to the kernel version only, not >> specific drivers. >> >> Agreed, though, that application developers must be made aware that >> the new API is only available in new kernels and old API must be used >> for compatibility with old kernels. > > Is the conversion layer fully independent of vb2? We still have older > drivers that do not use vb2, and I'm not sure if the extended buffer > operations work with those drivers as well. (Sorry, it's been a while > since I last looked at this series, so I can't remember). The conversion layer should be independent of vb2 (please check v6, I think it is cleaner). > >> >>>> >>>>> + >>>>> Dequeued video buffers come with timestamps. The driver decides at which >>>>> part of the frame and with w
[PATCH 0/3] v4l2 framework minor improvements
Just minor things. Add capabilities to v4l_print_create_buffers(), clarify docs and remove a redundant check. Helen Koike (3): media: v4l2-ioctl: print capabilities in v4l_print_create_buffers() media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero media: videobuf2-v4l2: remove redundant error test drivers/media/common/videobuf2/videobuf2-v4l2.c | 5 - drivers/media/v4l2-core/v4l2-ioctl.c| 6 +++--- include/uapi/linux/videodev2.h | 1 + 3 files changed, 4 insertions(+), 8 deletions(-) -- 2.29.2
[PATCH 2/3] media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero
sizeimage field should be set to zero for unused planes, even when
v4l2_pix_format_mplane.num_planes is smaller then the index of planes.
Signed-off-by: Helen Koike
---
I caught this with v4l2-compliance, which throws an error if we dirty
planes, even if invalid, so I would like to make it clear in the docs.
---
include/uapi/linux/videodev2.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 79dbde3bcf8d..d9b7c9177605 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2227,6 +2227,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv {
* struct v4l2_plane_pix_format - additional, per-plane format definition
* @sizeimage: maximum size in bytes required for data, for which
* this plane will be used
+ * Drivers should be set it zero for unused planes.
* @bytesperline: distance in bytes between the leftmost pixels in two
* adjacent lines
*/
--
2.29.2
[PATCH 3/3] media: videobuf2-v4l2: remove redundant error test
request_fd is validated under media_request_get_by_fd() just below this
check. Thus remove it.
Suggested-by: Tomasz Figa
Signed-off-by: Helen Koike
---
drivers/media/common/videobuf2/videobuf2-v4l2.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 96d3b2b2aa31..bb642c0775d1 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -488,11 +488,6 @@ static int vb2_queue_or_prepare_buf(struct vb2_queue *q,
struct media_device *md
!q->ops->buf_out_validate))
return -EINVAL;
- if (b->request_fd < 0) {
- dprintk(q, 1, "%s: request_fd < 0\n", opname);
- return -EINVAL;
- }
-
req = media_request_get_by_fd(mdev, b->request_fd);
if (IS_ERR(req)) {
dprintk(q, 1, "%s: invalid request_fd\n", opname);
--
2.29.2
[PATCH 1/3] media: v4l2-ioctl: print capabilities in v4l_print_create_buffers()
Print capabilities field from struct v4l2_create_buffers for better
debugging.
Signed-off-by: Helen Koike
---
drivers/media/v4l2-core/v4l2-ioctl.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 3198abdd538c..848286a284f6 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -518,9 +518,9 @@ static void v4l_print_create_buffers(const void *arg, bool
write_only)
{
const struct v4l2_create_buffers *p = arg;
- pr_cont("index=%d, count=%d, memory=%s, ",
- p->index, p->count,
- prt_names(p->memory, v4l2_memory_names));
+ pr_cont("index=%d, count=%d, memory=%s, capabilities=0x%08x, ",
+ p->index, p->count, prt_names(p->memory, v4l2_memory_names),
+ p->capabilities);
v4l_print_format(&p->format, write_only);
}
--
2.29.2
[RFC PATCH v6 01/11] media: v4l2-common: add normalized pixelformat field to struct v4l2_format_info
Add normalization to pixelformats, so we can fallback to it when using
Ext API, and eliminating the handling of two variantes (M and non-M
formats).
Signed-off-by: Helen Koike
---
Changes in v6:
- New patch
---
drivers/media/v4l2-core/v4l2-common.c | 16
include/media/v4l2-common.h | 3 +++
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-common.c
b/drivers/media/v4l2-core/v4l2-common.c
index 78007dba4677..002051b9dc0c 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -276,17 +276,17 @@ const struct v4l2_format_info *v4l2_format_info(u32
format)
{ .format = V4L2_PIX_FMT_GREY,.pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
.hdiv = 1, .vdiv = 1 },
/* YUV planar formats, non contiguous variant */
- { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 2 },
- { .format = V4L2_PIX_FMT_YVU420M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 2 },
- { .format = V4L2_PIX_FMT_YUV422M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_YUV420M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 2, .norm= V4L2_PIX_FMT_YUV420 },
+ { .format = V4L2_PIX_FMT_YVU420M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 2, .norm= V4L2_PIX_FMT_YVU420 },
+ { .format = V4L2_PIX_FMT_YUV422M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1, .norm= V4L2_PIX_FMT_YUV422P },
{ .format = V4L2_PIX_FMT_YVU422M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 2, .vdiv = 1 },
- { .format = V4L2_PIX_FMT_YUV444M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 1, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_YUV444M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 1, .vdiv = 1, .norm= V4L2_PIX_FMT_YUV444 },
{ .format = V4L2_PIX_FMT_YVU444M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 3, .comp_planes = 3, .bpp = { 1, 1, 1, 0 },
.hdiv = 1, .vdiv = 1 },
- { .format = V4L2_PIX_FMT_NV12M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2 },
- { .format = V4L2_PIX_FMT_NV21M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2 },
- { .format = V4L2_PIX_FMT_NV16M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 1 },
- { .format = V4L2_PIX_FMT_NV61M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 1 },
+ { .format = V4L2_PIX_FMT_NV12M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2, .norm = V4L2_PIX_FMT_NV12 },
+ { .format = V4L2_PIX_FMT_NV21M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 2, .norm = V4L2_PIX_FMT_NV21 },
+ { .format = V4L2_PIX_FMT_NV16M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 1, .norm = V4L2_PIX_FMT_NV16 },
+ { .format = V4L2_PIX_FMT_NV61M, .pixel_enc =
V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 2, 0, 0 },
.hdiv = 2, .vdiv = 1, .norm = V4L2_PIX_FMT_NV61 },
/* Bayer RGB formats */
{ .format = V4L2_PIX_FMT_SBGGR8,.pixel_enc =
V4L2_PIXEL_ENC_BAYER, .mem_planes = 1, .comp_planes = 1, .bpp = { 1, 0, 0, 0 },
.hdiv = 1, .vdiv = 1 },
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index be36cbdcc1bd..7236af1cfa2f 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -483,6 +483,8 @@ enum v4l2_pixel_encoding {
* @vdiv: Vertical chroma subsampling factor
* @block_w: Per-plane macroblock pixel width (optional)
* @block_h: Per-plane macroblock pixel height (optional)
+ * @norm: The normalized format that should be used in Ext API. Should be set
+ * to zero if @format is already the normalized version.
*/
struct v4l2_format_info {
u32 format;
@@ -494,6 +496,7 @@ struct v4l2_format_info {
u8
[RFC PATCH v6 00/11] media: v4l2: Add extended fmt and buffer ioctls
Hello,
This is v6 of the Extended API for formats and buffers (see below the new API).
The new API comes for free for old drivers through the conversion layer, which
is independent of vb2.
I completly refactored several patches. I would like to request comments not
only in the uAPI, but also the kAPI for drivers, and I would appreciate any
ideas on improving the quality of the code (in short: please review everything).
NOTE: The Ext API wans't tested yet. My next step is to patch v4l2-compliance.
Regression tests - v4l2-compliance with test-media script:
vivid: http://ix.io/2M0G - Final Summary: 1856, Succeeded: 1856,
Failed: 0, Warnings: 0)
vimc: http://ix.io/2M0I - Final Summary: 488, Succeeded: 488, Failed:
0, Warnings: 0
Git: https://gitlab.collabora.com/koike/linux/-/tree/v4l2/ext-api/v6
v5:
https://patchwork.linuxtv.org/project/linux-media/cover/20200804192939.2251988-1-helen.ko...@collabora.com/
v4:
https://patchwork.linuxtv.org/project/linux-media/cover/20200717115435.2632623-1-helen.ko...@collabora.com/
v3: https://patchwork.linuxtv.org/cover/59345/
v2: https://patchwork.kernel.org/project/linux-media/list/?series=101153
v1: https://patchwork.kernel.org/project/linux-media/list/?series=93707
Conversion layer:
=
* Old drivers implementing only ops->vidioc_*_fmt_vid_cap supports
VIDIOC_*_EXT_PIX_FMT automatically with limitations[1].
* New drivers implementing only ops->vidioc_*_ext_pix_fmt_vid_cap supports
VIDIOC_*_FMT automatically.
* Old drivers implementing only ops->vidioc_*buf support
VIDIOC_EXT_*BUF automatically with limitations[2].
* New drivers should implement both ops->vidioc_*buf and ops->vidioc_*buf
to overcome limitations[2] and support both APIs.
Which is easy with vb2:
static const struct v4l2_ioctl_ops ioctl_ops = {
...
+ .vidioc_ext_qbuf = vb2_ioctl_ext_qbuf,
+ .vidioc_ext_dqbuf = vb2_ioctl_ext_dqbuf,
...
}
...
+ /* Inform vb2 how to split the memory buffer in case a single one
is used */
+ vb2_set_pixelformat(dev->pixelformat)
[1] There are some limitations in the conversion such as modifiers that are
ignored when converting v4l2_ext_pix_format to v4l_format
[2] Ext API allows a single buffer with planes placed in random locations,
which is not possible with v4l2_buffer.
Major changes in v6:
Fixed color planes vs memory planes handling.
Removed VIDIOC_EXT_PREPARE_BUF, since this is an optimization, it doesn't blocks
the API, we can add it later (my goal was to simplify this patchset).
Removed VIDIOC_EXT_CREATE_BUFS, since this is useful only to MMAP (thus low
priority)
with the new format.
Classic VIDIOC_CREATE_BUFS and VIDIOC_REQBUFS can still be used.
Reformulated conversion layer as per above.
Removed conversions in vb2, it is easier to add hooks to drivers.
Fixed vb2 to allow Ext API only to Video types.
API updates:
* remove buffer and plane lengths
* move `memory` field to v4l2_ext_buffer instead of v4l2_ext_plane
* remove struct v4l2_plane_ext_pix_format
* reordering
Make Ext API valid only for Video types, and not for touch, vbi, meta, etc.
Sereval code refactoring, simplification, fixes and applied suggestions from v5.
New API (for convenience):
==
int ioctl(int fd, VIDIOC_G_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
int ioctl(int fd, VIDIOC_S_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
int ioctl(int fd, VIDIOC_TRY_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp)
int ioctl(int fd, VIDIOC_EXT_QBUF, struct v4l2_ext_buffer *argp)
int ioctl(int fd, VIDIOC_EXT_DQBUF, struct v4l2_ext_buffer *argp)
struct v4l2_ext_pix_format {
__u32 type;
__u32 width;
__u32 height;
__u32 field;
struct v4l2_plane_pix_format plane_fmt[VIDEO_MAX_PLANES];
__u32 pixelformat;
__u64 modifier;
__u32 colorspace;
__u32 xfer_func;
union {
__u32 ycbcr_enc;
__u32 hsv_enc;
};
__u32 quantization;
__u32 reserved[9];
};
struct v4l2_ext_buffer {
__u32 index;
__u32 type;
__u32 field;
__u32 sequence;
__u64 flags;
__u64 timestamp;
__u32 memory;
__s32 request_fd;
struct v4l2_ext_plane planes[VIDEO_MAX_PLANES];
__u32 reserved[10];
};
struct v4l2_ext_plane {
__u32 offset;
__u32 bytesused;
union {
__u32 mmap_offset;
__u64 userptr;
__s32 dmabuf_fd;
} m;
__u32 reserved[6];
};
Helen Koike (11):
media: v4l2-common: add normalized pixelformat field to struct
v4l2_format_info
media: v4l2: Extend pixel formats to unify single/multi-planar
handling (and more)
media: v4l2: Add extended buffer (de)queue operations for video types
media: videobuf2-v4l2: reorganize flags handling
media: v
[RFC PATCH v6 02/11] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)
This is part of the multiplanar and singleplanar unification process.
v4l2_ext_pix_format is supposed to work for both cases.
We also add the concept of modifiers already employed in DRM to expose
HW-specific formats (like tiled or compressed formats) and allow
exchanging this information with the DRM subsystem in a consistent way.
Note that only V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] are accepted in
v4l2_ext_format, other types will be rejected if you use the
{G,S,TRY}_EXT_PIX_FMT ioctls.
New hooks have been added to v4l2_ioctl_ops to support those new ioctls
in drivers, but, in the meantime, the core takes care of converting
{S,G,TRY}_EXT_PIX_FMT requests into {S,G,TRY}_FMT so that old drivers can
still work if the userspace app/lib uses the new ioctls.
The conversion is also done the other around to allow userspace
apps/libs using {S,G,TRY}_FMT to work with drivers implementing the
_ext_ hooks.
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
The main change here was fixing the conversion, so planes reflects color
planes,
and to implement this properly I made major refactors compared to the previous
version.
- struct v4l2_plane_ext_pix_format removed, using struct v4l2_plane_pix_format
instead (Tomasz)
- refer to drm_fourcc.h in struct v4l2_ext_pix_format docs (Hans)
- reorder colorimetry fields in struct v4l2_ext_pix_format (Hans)
- do not set Ext ioctls as valid for vid_out_overlay (Tomasz)
- refactor conversion functions, so planes are color planes (Tomasz)
- Don't explicitly check for e->modifier != 0 in
v4l2_ext_pix_format_to_format() (Tomasz)
- Use "ef" for extended formats in the framework for consistency (Tomasz)
- Handle xfer_func field in conversions (Tomasz)
- Zero reserved fields in v4l_s_ext_pix_fmt() and v4l_try_ext_pix_fmt() (Tomasz)
- Refactor format functions to use v4l_fmt_ioctl_via_ext()
- Several fixes/refactoring/changes
- Remove EXT API for touch devices
Changes in v5:
- change sizes and reorder fields to avoid holes in the struct and make
it the same for 32 and 64 bits
- removed __attribute__ ((packed)) from uapi structs
- Fix doc warning from make htmldocs
- Updated commit message with EXT_PIX prefix for the ioctls.
Changes in v4:
- Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
- Add reserved fields
- Removed num_planes from struct v4l2_ext_pix_format
- Removed flag field from struct v4l2_ext_pix_format, since the only
defined value is V4L2_PIX_FMT_FLAG_PREMUL_ALPHA only used by vsp1,
where we can use modifiers, or add it back later through the reserved
bits.
- In v4l2_ext_format_to_format(), check if modifier is != MOD_LINEAR &&
!= MOD_INVALID
- Fix type assignment in v4l_g_fmt_ext_pix()
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- Move the modifier in v4l2_ext_format (was formerly placed in
v4l2_ext_plane)
- Fix a few bugs in the converters and add a strict parameter to
allow conversion of uninitialized/mis-initialized objects
---
drivers/media/v4l2-core/v4l2-dev.c | 27 +-
drivers/media/v4l2-core/v4l2-ioctl.c | 538 +--
include/media/v4l2-ioctl.h | 28 ++
include/uapi/linux/videodev2.h | 41 ++
4 files changed, 602 insertions(+), 32 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index f9cff033d0dc..5add58cb6d45 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -608,27 +608,42 @@ static void determine_valid_ioctls(struct video_device
*vdev)
ops->vidioc_enum_fmt_vid_overlay)) ||
(is_tx && ops->vidioc_enum_fmt_vid_out))
set_bit(_IOC_NR(VIDIOC_ENUM_FMT), valid_ioctls);
+ if ((is_rx && ops->vidioc_g_fmt_vid_overlay) ||
+ (is_tx && ops->vidioc_g_fmt_vid_out_overlay))
+set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
if ((is_rx && (ops->vidioc_g_fmt_vid_cap ||
ops->vidioc_g_fmt_vid_cap_mplane ||
- ops->vidioc_g_fmt_vid_overlay)) ||
+ ops->vidioc_g_ext_pix_fmt_vid_cap)) ||
(is_tx && (ops->vidioc_g_fmt_vid_out ||
ops->vidioc_g_fmt_vid_out_mplane ||
- ops->vidioc_g_fmt_vid_out_overlay)))
+ ops->vidioc_g_ext_pix_fmt_vid_out))) {
set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
+set_bit(_IOC_NR(VIDIOC_G_EXT_PIX_FMT), valid_ioctls);
+ }
+ if ((is_rx && ops->vidioc_s_fmt_vid_overlay) ||
+
[RFC PATCH v6 04/11] media: videobuf2-v4l2: reorganize flags handling
Reorganize flags handling to be easily reuseble when Ext functions get
added.
No logic is changed, just moving around code.
- Two new functions:
v4l2_clear_buffer_flags()
vb2_fill_vb2_v4l2_buffer_flags()
- set_buffer_cache_hints() receives a pointer to flags instead of the
v4l2_buffer object, making it undependent of this struct.
Signed-off-by: Helen Koike
---
Changes in v6:
- New patch
---
.../media/common/videobuf2/videobuf2-v4l2.c | 176 ++
1 file changed, 97 insertions(+), 79 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index bb642c0775d1..aa4f17ec0982 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -174,6 +174,43 @@ static void vb2_warn_zero_bytesused(struct vb2_buffer *vb)
pr_warn("use the actual size instead.\n");
}
+static void
+vb2_fill_vb2_v4l2_buffer_flags(struct vb2_buffer *vb,
+ u32 type, u32 field, u32 flags)
+{
+ struct vb2_queue *q = vb->vb2_queue;
+ struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
+
+ /* Zero flags that we handle */
+ vbuf->flags = flags & ~V4L2_BUFFER_MASK_FLAGS;
+ if (!vb->vb2_queue->copy_timestamp || V4L2_TYPE_IS_CAPTURE(type)) {
+ /*
+* Non-COPY timestamps and non-OUTPUT queues will get
+* their timestamp and timestamp source flags from the
+* queue.
+*/
+ vbuf->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
+ }
+
+ if (V4L2_TYPE_IS_OUTPUT(type)) {
+ /*
+* For output buffers mask out the timecode flag:
+* this will be handled later in vb2_qbuf().
+* The 'field' is valid metadata for this output buffer
+* and so that needs to be copied here.
+*/
+ vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
+ vbuf->field = field;
+ if (!(q->subsystem_flags &
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF))
+ vbuf->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+ } else {
+ /* Zero any output buffer flags as this is a capture buffer */
+ vbuf->flags &= ~V4L2_BUFFER_OUT_FLAGS;
+ /* Zero last flag, this is a signal from driver to userspace */
+ vbuf->flags &= ~V4L2_BUF_FLAG_LAST;
+ }
+}
+
static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer *vb, struct v4l2_buffer
*b)
{
struct vb2_queue *q = vb->vb2_queue;
@@ -310,41 +347,14 @@ static int vb2_fill_vb2_v4l2_buffer(struct vb2_buffer
*vb, struct v4l2_buffer *b
}
- /* Zero flags that we handle */
- vbuf->flags = b->flags & ~V4L2_BUFFER_MASK_FLAGS;
- if (!vb->vb2_queue->copy_timestamp || V4L2_TYPE_IS_CAPTURE(b->type)) {
- /*
-* Non-COPY timestamps and non-OUTPUT queues will get
-* their timestamp and timestamp source flags from the
-* queue.
-*/
- vbuf->flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
- }
-
- if (V4L2_TYPE_IS_OUTPUT(b->type)) {
- /*
-* For output buffers mask out the timecode flag:
-* this will be handled later in vb2_qbuf().
-* The 'field' is valid metadata for this output buffer
-* and so that needs to be copied here.
-*/
- vbuf->flags &= ~V4L2_BUF_FLAG_TIMECODE;
- vbuf->field = b->field;
- if (!(q->subsystem_flags &
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF))
- vbuf->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
- } else {
- /* Zero any output buffer flags as this is a capture buffer */
- vbuf->flags &= ~V4L2_BUFFER_OUT_FLAGS;
- /* Zero last flag, this is a signal from driver to userspace */
- vbuf->flags &= ~V4L2_BUF_FLAG_LAST;
- }
+ vb2_fill_vb2_v4l2_buffer_flags(vb, b->type, b->field, b->flags);
return 0;
}
static void set_buffer_cache_hints(struct vb2_queue *q,
struct vb2_buffer *vb,
- struct v4l2_buffer *b)
+ u32 *flags)
{
/*
* DMA exporter should take care of cache syncs, so we can avoid
@@ -370,8 +380,8 @@ static void set_buffer_cache_hints(struct vb2_queue *q,
* space hints. That's to indicate to userspace that these
* flags won't work.
*/
- b->flags &= ~V4L2_BUF_FLAG_NO_CACH
[RFC PATCH v6 03/11] media: v4l2: Add extended buffer (de)queue operations for video types
Those extended buffer ops have several purpose:
1/ Fix y2038 issues by converting the timestamp into an u64 counting
the number of ns elapsed since 1970
2/ Unify single/multiplanar handling
3/ Add a new start offset field to each v4l2 plane buffer info struct
to support the case where a single buffer object is storing all
planes data, each one being placed at a different offset
New hooks are created in v4l2_ioctl_ops so that drivers can start using
these new objects.
Note that the timecode field is gone, since there doesn't seem to be
in-kernel users. We can be added back in the reserved area if needed or
use the Request API to collect more metadata information from the
frame.
Signed-off-by: Hans Verkuil
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
This patch was completely refactored, and based on previous version from
Hans and Boris.
- Refactor conversions v4l2_buffer <-> v4l2_ext_buffer for (d)qbuf
- I removed EXT_CREATE_BUFS since it is basically only usefull to MMAP.
If this is going towards DMA-fd centric, then we can use the current
REQUESTBUF to switch to it, and we can think a better way to support
MMAP later if there are usecases.
I also moved memory field from v4l2_ext_plane to v4l2_ext_buffer,
since it is very unlikely to mix memory types, and REQUESTBUF can
switch the whole buffer object to a given type.
- I removed EXT_QUERYBUF, since it is only useful to MMAP, for the
same reason above.
- I removed EXT_PREPARE_BUF, since it is basically just an optimization,
we can add it later (my intention is to simplify this patchset).
- These ioctls are only valid for video types (and not for overlay,
vbi, touch, meta, etc).
- Refactor struct v4l2_ext_buffer and struct v4l2_ext_planes as
discussed with Tomasz:
- add bytesused back
- remove lenght field
- move memory field from planes to buffer object
- Fix order in documentation of struct v4l2_ext_buffer (Tomasz)
- Fix flags documentation of struct v4l2_ext_buffer, don't say when flags are
ignored (Tomasz)
- v4l_print_ext_buffer(): print request_fd and offset/userptr (Tomasz)
Changes in v5:
- migrate memory from v4l2_ext_buffer to v4l2_ext_plane
- return mem_offset to struct v4l2_ext_plane
- change sizes and reorder fields to avoid holes in the struct and make
it the same for 32 and 64 bits
Changes in v4:
- Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
- Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
I think we can add this later, so I removed it from this RFC to simplify it.
- Remove num_planes field from struct v4l2_ext_buffer
- Add flags field to struct v4l2_ext_create_buffers
- Reformulate struct v4l2_ext_plane
- Fix some bugs caught by v4l2-compliance
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- Add reserved space to v4l2_ext_buffer so that new fields can be added
later on
Signed-off-by: Helen Koike
---
drivers/media/v4l2-core/v4l2-dev.c | 4 +
drivers/media/v4l2-core/v4l2-ioctl.c | 184 +++
include/media/v4l2-ioctl.h | 8 ++
include/uapi/linux/videodev2.h | 55
4 files changed, 251 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-dev.c
b/drivers/media/v4l2-core/v4l2-dev.c
index 5add58cb6d45..94c9f1e04704 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -664,6 +664,10 @@ static void determine_valid_ioctls(struct video_device
*vdev)
set_bit(_IOC_NR(VIDIOC_S_CROP), valid_ioctls);
SET_VALID_IOCTL(ops, VIDIOC_G_SELECTION, vidioc_g_selection);
SET_VALID_IOCTL(ops, VIDIOC_S_SELECTION, vidioc_s_selection);
+ SET_VALID_IOCTL(ops, VIDIOC_EXT_QBUF, vidioc_ext_qbuf);
+ SET_VALID_IOCTL(ops, VIDIOC_EXT_QBUF, vidioc_qbuf);
+ SET_VALID_IOCTL(ops, VIDIOC_EXT_DQBUF, vidioc_ext_dqbuf);
+ SET_VALID_IOCTL(ops, VIDIOC_EXT_DQBUF, vidioc_dqbuf);
}
if (is_meta && is_rx) {
/* metadata capture specific ioctls */
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index a9c07c0a73ec..ba633e7efd6d 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -533,6 +533,24 @@ static void v4l_print_buffer(const void *arg, bool
write_only)
tc->type, tc->flags, tc->frames, *(__u32
*)tc->userbits);
}
+static void v4l_print_ext_buffer(const void *arg, bool write_only)
+{
+ const struct v4l2_ext_buffer *e = arg;
+ unsigned int i;
+
+ pr_cont("%lld index=%d, type=%s, request_fd=%d, flags=0x%08llx,
field=%s, seq
[RFC PATCH v6 05/11] media: videobuf2: Expose helpers for Ext qbuf/dqbuf
To overcome the limitations of Ext ioctls, that is being converted to
classic hooks, add helpers to allow applications support layouts such as
using the same buffer with planes in different offsets.
To use the new hooks, drivers should:
static const struct v4l2_ioctl_ops ioctl_ops = {
...
+ .vidioc_ext_qbuf = vb2_ioctl_ext_qbuf,
+ .vidioc_ext_dqbuf = vb2_ioctl_ext_dqbuf,
...
}
+ vb2_set_pixelformat(dev->pixelformat)
The old hooks should be kept to keep the driver compatible with classic
Api.
Add mem_offset field to struct vb2_plane, to allow tracking where the plane
starts in a buffer, as defined from userspace.
When returning the buffer to userspace, this offset can be adjusted
depending on the data_offset returned from the driver.
Add pixelformat field to struct vb2_buffer, to allow vb2 to know how to
decompose the payload set with vb2_set_plane_payload() into color planes
when a single memory buffer is used.
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
This patch is based on original "media: videobuf2: Expose helpers to implement
the _ext_fmt and _ext_buf hooks"
- This patch was completly refactored
- Conversions from v4l2_buffer to v4l2_ext_buffer was removed from vb2.
Both v4l2_buffer and v4l2_ext_buffer need to be supported, since Ext is only
valid
for video devices, v4l2_buffer needs to be supported for vbi, meta, and
others.
- Zero v4l2_ext_buffer.planes.m field (Tomasz for DMA-fd)
Changes in v5:
- Update with new format and buffer structs
- Updated commit message with the uAPI prefix
Changes in v4:
- Update with new format and buffer structs
- Fix some bugs caught by v4l2-compliance
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- New patch
---
.../media/common/videobuf2/videobuf2-core.c | 46 ++-
.../media/common/videobuf2/videobuf2-v4l2.c | 326 +-
include/media/videobuf2-core.h| 33 +-
include/media/videobuf2-v4l2.h| 8 +-
4 files changed, 388 insertions(+), 25 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 02281d13505f..b034bd525ea4 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1569,8 +1569,10 @@ static int vb2_start_streaming(struct vb2_queue *q)
return ret;
}
-int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
- struct media_request *req)
+static int
+vb2_core_qbuf_common(struct vb2_queue *q, unsigned int index,
+struct v4l2_buffer *pb, struct v4l2_ext_buffer *eb,
+struct media_request *req)
{
struct vb2_buffer *vb;
int ret;
@@ -1642,6 +1644,9 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int
index, void *pb,
if (pb) {
call_void_bufop(q, copy_timestamp, vb, pb);
call_void_bufop(q, fill_user_buffer, vb, pb);
+ } else if (eb) {
+ call_void_bufop(q, copy_timestamp_ext, vb, eb);
+ call_void_bufop(q, fill_user_ext_buffer, vb, eb);
}
dprintk(q, 2, "qbuf of buffer %d succeeded\n", vb->index);
@@ -1680,6 +1685,8 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int
index, void *pb,
if (pb)
call_void_bufop(q, copy_timestamp, vb, pb);
+ else if (eb)
+ call_void_bufop(q, copy_timestamp_ext, vb, eb);
trace_vb2_qbuf(q, vb);
@@ -1693,6 +1700,8 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int
index, void *pb,
/* Fill buffer information for the userspace */
if (pb)
call_void_bufop(q, fill_user_buffer, vb, pb);
+ else if (eb)
+ call_void_bufop(q, fill_user_ext_buffer, vb, eb);
/*
* If streamon has been called, and we haven't yet called
@@ -1710,8 +1719,21 @@ int vb2_core_qbuf(struct vb2_queue *q, unsigned int
index, void *pb,
dprintk(q, 2, "qbuf of buffer %d succeeded\n", vb->index);
return 0;
}
+
+int vb2_core_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct media_request *req)
+{
+ return vb2_core_qbuf_common(q, index, pb, NULL, req);
+}
EXPORT_SYMBOL_GPL(vb2_core_qbuf);
+int vb2_core_ext_qbuf(struct vb2_queue *q, unsigned int index, void *pb,
+ struct media_request *req)
+{
+ return vb2_core_qbuf_common(q, index, NULL, pb, req);
+}
+EXPORT_SYMBOL_GPL(vb2_core_ext_qbuf);
+
/*
* __vb2_wait_for_done_vb() - wait for a buffer to become available
* for dequeuing
@@ -1861,8 +1883,10 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
call_void_bufop(q, init_buffer, vb);
}
-int vb2_core_dqbuf(struct
[RFC PATCH v6 06/11] media: vivid: use vb2_ioctls_ext_{d}qbuf hooks
Add vb2 ext hooks and call vb2_set_pixelformat().
This allows more flexibility with buffer handling.
Signed-off-by: Helen Koike
---
Changes in v6:
- New patch to exemplify how drivers would easily support features from Ext Buf
---
drivers/media/test-drivers/vivid/vivid-core.c| 2 ++
drivers/media/test-drivers/vivid/vivid-vid-cap.c | 1 +
drivers/media/test-drivers/vivid/vivid-vid-out.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/media/test-drivers/vivid/vivid-core.c
b/drivers/media/test-drivers/vivid/vivid-core.c
index 0dc65ef3aa14..eacb23808c7e 100644
--- a/drivers/media/test-drivers/vivid/vivid-core.c
+++ b/drivers/media/test-drivers/vivid/vivid-core.c
@@ -723,6 +723,8 @@ static const struct v4l2_ioctl_ops vivid_ioctl_ops = {
.vidioc_querybuf= vb2_ioctl_querybuf,
.vidioc_qbuf= vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
+ .vidioc_ext_qbuf= vb2_ioctl_ext_qbuf,
+ .vidioc_ext_dqbuf = vb2_ioctl_ext_dqbuf,
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon= vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
diff --git a/drivers/media/test-drivers/vivid/vivid-vid-cap.c
b/drivers/media/test-drivers/vivid/vivid-vid-cap.c
index b9caa4b26209..882b0c4a6591 100644
--- a/drivers/media/test-drivers/vivid/vivid-vid-cap.c
+++ b/drivers/media/test-drivers/vivid/vivid-vid-cap.c
@@ -169,6 +169,7 @@ static int vid_cap_buf_prepare(struct vb2_buffer *vb)
}
vb2_set_plane_payload(vb, p, size);
+ vb2_set_pixelformat(vb, dev->fmt_cap->fourcc);
vb->planes[p].data_offset = dev->fmt_cap->data_offset[p];
}
diff --git a/drivers/media/test-drivers/vivid/vivid-vid-out.c
b/drivers/media/test-drivers/vivid/vivid-vid-out.c
index ac1e981e8342..6be61112065d 100644
--- a/drivers/media/test-drivers/vivid/vivid-vid-out.c
+++ b/drivers/media/test-drivers/vivid/vivid-vid-out.c
@@ -136,6 +136,7 @@ static int vid_out_buf_prepare(struct vb2_buffer *vb)
return -EINVAL;
}
}
+ vb2_set_pixelformat(vb, dev->fmt_out->fourcc);
return 0;
}
--
2.29.2
[RFC PATCH v6 08/11] media: mediabus: Add helpers to convert a ext_pix format to/from a mbus_fmt
Just a new version of v4l2_fill_mbus_format() and v4l2_fill_ext_pix_format()
to deal with the new v4l2_ext_pix_format struct.
This is needed to convert the VIMC driver to the EXT_FMT/EXT_BUF iocts.
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
- Rename v4l2_fill_ext_pix_format() to v4l2_fill_ext_pix_format_from_mbus()
(Tomasz)
Changes in v4:
- Add helper v4l2_fill_ext_pix_format()
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- New patch
---
include/media/v4l2-mediabus.h | 42 +++
1 file changed, 42 insertions(+)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 841e190aedd9..055e2abbc1dd 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -209,4 +209,46 @@ v4l2_fill_mbus_format_mplane(struct v4l2_mbus_framefmt
*mbus_fmt,
mbus_fmt->xfer_func = pix_mp_fmt->xfer_func;
}
+/**
+ * v4l2_fill_ext_pix_format_from_mbus - Ancillary routine that fills a &struct
+ * v4l2_ext_pix_format fields from a &struct v4l2_mbus_framefmt.
+ *
+ * @pix_fmt: pointer to &struct v4l2_ext_pix_format to be filled
+ * @mbus_fmt: pointer to &struct v4l2_mbus_framefmt to be used as model
+ */
+static inline void
+v4l2_fill_ext_pix_format_from_mbus(struct v4l2_ext_pix_format *pix_fmt,
+ const struct v4l2_mbus_framefmt *mbus_fmt)
+{
+ pix_fmt->width = mbus_fmt->width;
+ pix_fmt->height = mbus_fmt->height;
+ pix_fmt->field = mbus_fmt->field;
+ pix_fmt->colorspace = mbus_fmt->colorspace;
+ pix_fmt->ycbcr_enc = mbus_fmt->ycbcr_enc;
+ pix_fmt->quantization = mbus_fmt->quantization;
+ pix_fmt->xfer_func = mbus_fmt->xfer_func;
+}
+
+/**
+ * v4l2_fill_mbus_format_ext - Ancillary routine that fills a &struct
+ * v4l2_mbus_framefmt from a &struct v4l2_ext_pix_format.
+ *
+ * @mbus_fmt: pointer to &struct v4l2_mbus_framefmt to be filled
+ * @pix_fmt: pointer to &struct v4l2_ext_pix_format to be used as model
+ * @code: data format code (from &enum v4l2_mbus_pixelcode)
+ */
+static inline void
+v4l2_fill_mbus_format_ext(struct v4l2_mbus_framefmt *mbus_fmt,
+ const struct v4l2_ext_pix_format *pix_fmt, u32 code)
+{
+ mbus_fmt->width = pix_fmt->width;
+ mbus_fmt->height = pix_fmt->height;
+ mbus_fmt->field = pix_fmt->field;
+ mbus_fmt->colorspace = pix_fmt->colorspace;
+ mbus_fmt->ycbcr_enc = pix_fmt->ycbcr_enc;
+ mbus_fmt->quantization = pix_fmt->quantization;
+ mbus_fmt->xfer_func = pix_fmt->xfer_func;
+ mbus_fmt->code = code;
+}
+
#endif
--
2.29.2
[RFC PATCH v6 07/11] media: vimc: use vb2_ioctls_ext_{d}qbuf hooks
Add vb2 ext hooks and call vb2_set_pixelformat().
This allows more flexibility with buffer handling.
Signed-off-by: Helen Koike
---
Changes in v6:
- New patch to exemplify how drivers would easily support features from Ext Buf
---
drivers/media/test-drivers/vimc/vimc-capture.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/test-drivers/vimc/vimc-capture.c
b/drivers/media/test-drivers/vimc/vimc-capture.c
index 5e9fd902cd37..729614d19002 100644
--- a/drivers/media/test-drivers/vimc/vimc-capture.c
+++ b/drivers/media/test-drivers/vimc/vimc-capture.c
@@ -217,6 +217,8 @@ static const struct v4l2_ioctl_ops vimc_cap_ioctl_ops = {
.vidioc_querybuf = vb2_ioctl_querybuf,
.vidioc_qbuf = vb2_ioctl_qbuf,
.vidioc_dqbuf = vb2_ioctl_dqbuf,
+ .vidioc_ext_qbuf = vb2_ioctl_ext_qbuf,
+ .vidioc_ext_dqbuf = vb2_ioctl_ext_dqbuf,
.vidioc_expbuf = vb2_ioctl_expbuf,
.vidioc_streamon = vb2_ioctl_streamon,
.vidioc_streamoff = vb2_ioctl_streamoff,
@@ -389,6 +391,7 @@ static void *vimc_cap_process_frame(struct vimc_ent_device
*ved,
/* Set it as ready */
vb2_set_plane_payload(&vimc_buf->vb2.vb2_buf, 0,
vcap->format.sizeimage);
+ vb2_set_pixelformat(&vimc_buf->vb2.vb2_buf, vcap->format.pixelformat);
vb2_buffer_done(&vimc_buf->vb2.vb2_buf, VB2_BUF_STATE_DONE);
return NULL;
}
--
2.29.2
[RFC PATCH v6 11/11] media: docs: add documentation for the Extended API
Add documentation and update references in current documentation for the Extended API. Signed-off-by: Helen Koike --- Changes in v6: - Update note saying ext_api should be used for new applications on newer kernels (Tomasz and Hans) - Fix typos pointed in v5 (Hand and Tomasz) - Change order, mention Ext first in format.rst (Tomasz) - Mention planes[i].offset should be set to zero for userptr - Remove ext_create_buf and ext_prep_buf from the docs - s/displayed/consumed for output (Tomasz) - Remove references for plane length - Drop EIO sentence mentioning signal loss (Hans) - Removed first half of the note in EIO (Tomas and Hans) - Update text to mention EXT_TRY_FMT is mandatory (Hans and Tomasz) - Remove requirement to fill `memory` field for dqbuf (Tomasz) - EXT_DQBUF sets `m` field to zero (Tomasz for DMA-fd) Changes in v5: - new patch --- .../userspace-api/media/v4l/buffer.rst| 5 + .../userspace-api/media/v4l/common.rst| 1 + .../userspace-api/media/v4l/dev-capture.rst | 6 + .../userspace-api/media/v4l/dev-output.rst| 6 + .../userspace-api/media/v4l/ext-api.rst | 89 + .../userspace-api/media/v4l/format.rst| 18 +- .../userspace-api/media/v4l/user-func.rst | 5 + .../media/v4l/vidioc-ext-qbuf.rst | 188 ++ .../media/v4l/vidioc-g-ext-pix-fmt.rst| 116 +++ .../userspace-api/media/v4l/vidioc-qbuf.rst | 2 +- 10 files changed, 431 insertions(+), 5 deletions(-) create mode 100644 Documentation/userspace-api/media/v4l/ext-api.rst create mode 100644 Documentation/userspace-api/media/v4l/vidioc-ext-qbuf.rst create mode 100644 Documentation/userspace-api/media/v4l/vidioc-g-ext-pix-fmt.rst diff --git a/Documentation/userspace-api/media/v4l/buffer.rst b/Documentation/userspace-api/media/v4l/buffer.rst index 1b0fdc160533..89652fa7a098 100644 --- a/Documentation/userspace-api/media/v4l/buffer.rst +++ b/Documentation/userspace-api/media/v4l/buffer.rst @@ -21,6 +21,11 @@ such as pointers and sizes for each plane, are stored in struct :c:type:`v4l2_plane` instead. In that case, struct :c:type:`v4l2_buffer` contains an array of plane structures. +.. note:: + +For modern applications on newer kernels, these operations are replaced +by their :ref:`ext_api` counterparts, which should be used instead. + Dequeued video buffers come with timestamps. The driver decides at which part of the frame and with which clock the timestamp is taken. Please see flags in the masks ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` and diff --git a/Documentation/userspace-api/media/v4l/common.rst b/Documentation/userspace-api/media/v4l/common.rst index 8c263c5a85d8..61a64065f9f3 100644 --- a/Documentation/userspace-api/media/v4l/common.rst +++ b/Documentation/userspace-api/media/v4l/common.rst @@ -53,6 +53,7 @@ applicable to all devices. ext-ctrls-detect fourcc format +ext-api planar-apis selection-api crop diff --git a/Documentation/userspace-api/media/v4l/dev-capture.rst b/Documentation/userspace-api/media/v4l/dev-capture.rst index fe58fd450e2f..73580e16057c 100644 --- a/Documentation/userspace-api/media/v4l/dev-capture.rst +++ b/Documentation/userspace-api/media/v4l/dev-capture.rst @@ -93,6 +93,12 @@ and :ref:`VIDIOC_S_FMT ` ioctl, even if :ref:`VIDIOC_S_FMT ` does. :ref:`VIDIOC_TRY_FMT ` is optional. +.. note:: + +For modern applications on newer kernels, these operations are replaced +by their :ref:`ext_api` counterparts, which should be used instead. + + Reading Images == diff --git a/Documentation/userspace-api/media/v4l/dev-output.rst b/Documentation/userspace-api/media/v4l/dev-output.rst index eadcb4aa813b..676578c099b6 100644 --- a/Documentation/userspace-api/media/v4l/dev-output.rst +++ b/Documentation/userspace-api/media/v4l/dev-output.rst @@ -90,6 +90,12 @@ and :ref:`VIDIOC_S_FMT ` ioctl, even if :ref:`VIDIOC_S_FMT ` does. :ref:`VIDIOC_TRY_FMT ` is optional. +.. note:: + +For modern applications on newer kernels, these operations are replaced +by their :ref:`ext_api` counterparts, which should be used instead. + + Writing Images == diff --git a/Documentation/userspace-api/media/v4l/ext-api.rst b/Documentation/userspace-api/media/v4l/ext-api.rst new file mode 100644 index ..e73d5b77a550 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/ext-api.rst @@ -0,0 +1,89 @@ +.. Permission is granted to copy, distribute and/or modify this +.. document under the terms of the GNU Free Documentation License, +.. Version 1.1 or any later version published by the Free Software +.. Foundation, with no Invariant Sections, no Front-Cover Texts +.. and no Back-Cover Texts. A copy of the license is included at +.. Documentation/userspace-api/media/fdl-appendix.rst. +.. +.. TODO: replace it to GFDL-1.1-or-later WITH no-invariant-sections + +.. _ext_api: + +* +Extended API +* + +Introduction
[RFC PATCH v6 10/11] media: vimc: Convert to v4l2_ext_pix_format
Simplify Multi/Single planer API handling by converting to v4l2_ext_pix_format.
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
- Update with new format and buffer structs
Changes in v4:
- Update with new format and buffer structs
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- New patch
---
.../media/test-drivers/vimc/vimc-capture.c| 54 ++-
drivers/media/test-drivers/vimc/vimc-common.c | 6 +--
drivers/media/test-drivers/vimc/vimc-common.h | 2 +-
3 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/media/test-drivers/vimc/vimc-capture.c
b/drivers/media/test-drivers/vimc/vimc-capture.c
index 729614d19002..51191dc9661b 100644
--- a/drivers/media/test-drivers/vimc/vimc-capture.c
+++ b/drivers/media/test-drivers/vimc/vimc-capture.c
@@ -15,7 +15,7 @@
struct vimc_cap_device {
struct vimc_ent_device ved;
struct video_device vdev;
- struct v4l2_pix_format format;
+ struct v4l2_ext_pix_format format;
struct vb2_queue queue;
struct list_head buf_list;
/*
@@ -32,7 +32,8 @@ struct vimc_cap_device {
struct media_pad pad;
};
-static const struct v4l2_pix_format fmt_default = {
+static const struct v4l2_ext_pix_format fmt_default = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
.width = 640,
.height = 480,
.pixelformat = V4L2_PIX_FMT_RGB24,
@@ -63,7 +64,7 @@ static int vimc_cap_querycap(struct file *file, void *priv,
}
static void vimc_cap_get_format(struct vimc_ent_device *ved,
- struct v4l2_pix_format *fmt)
+ struct v4l2_ext_pix_format *fmt)
{
struct vimc_cap_device *vcap = container_of(ved, struct vimc_cap_device,
ved);
@@ -72,19 +73,18 @@ static void vimc_cap_get_format(struct vimc_ent_device *ved,
}
static int vimc_cap_g_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_format *f)
+ struct v4l2_ext_pix_format *f)
{
struct vimc_cap_device *vcap = video_drvdata(file);
- f->fmt.pix = vcap->format;
+ *f = vcap->format;
return 0;
}
static int vimc_cap_try_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_format *f)
+ struct v4l2_ext_pix_format *format)
{
- struct v4l2_pix_format *format = &f->fmt.pix;
const struct vimc_pix_map *vpix;
format->width = clamp_t(u32, format->width, VIMC_FRAME_MIN_WIDTH,
@@ -99,8 +99,10 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file, void
*priv,
vpix = vimc_pix_map_by_pixelformat(format->pixelformat);
}
/* TODO: Add support for custom bytesperline values */
- format->bytesperline = format->width * vpix->bpp;
- format->sizeimage = format->bytesperline * format->height;
+ memset(format->plane_fmt, 0, sizeof(format->plane_fmt));
+ format->plane_fmt[0].bytesperline = format->width * vpix->bpp;
+ format->plane_fmt[0].sizeimage = format->plane_fmt[0].bytesperline *
+format->height;
if (format->field == V4L2_FIELD_ANY)
format->field = fmt_default.field;
@@ -114,7 +116,7 @@ static int vimc_cap_try_fmt_vid_cap(struct file *file, void
*priv,
}
static int vimc_cap_s_fmt_vid_cap(struct file *file, void *priv,
- struct v4l2_format *f)
+ struct v4l2_ext_pix_format *f)
{
struct vimc_cap_device *vcap = video_drvdata(file);
int ret;
@@ -136,12 +138,10 @@ static int vimc_cap_s_fmt_vid_cap(struct file *file, void
*priv,
vcap->format.quantization, vcap->format.xfer_func,
vcap->format.ycbcr_enc,
/* new */
- f->fmt.pix.width, f->fmt.pix.height,
- f->fmt.pix.pixelformat, f->fmt.pix.colorspace,
- f->fmt.pix.quantization, f->fmt.pix.xfer_func,
- f->fmt.pix.ycbcr_enc);
+ f->width, f->height, f->pixelformat, f->colorspace,
+ f->quantization, f->xfer_func, f->ycbcr_enc);
- vcap->format = f->fmt.pix;
+ vcap->format = *f;
return 0;
}
@@ -205,9 +205,9 @@ static const struct v4l2_file_operations vimc_cap_fops = {
static const struct v4l2_ioctl_ops vimc_cap_ioctl_ops = {
.vidioc_querycap = vimc_cap_querycap,
- .vidioc_g_fmt_vid_cap = vimc_cap_g_fmt_vid_cap,
- .vidioc_s_fmt_vid_cap = vimc_cap_s_fmt_vid_cap,
- .vidioc_try_fmt_vid_cap = vimc_cap_try_fmt_vid_cap,
+ .vidioc_g_ext_pix_fmt_vid_
[RFC PATCH v6 09/11] media: vivid: Convert to v4l2_ext_pix_format
Simplify Multi/Single planer API handling by converting to v4l2_ext_pix_format.
Duplicate v4l2_ioctl_ops for touch devices. This is done to force the
framework to use the ext hooks when the classic Api is used from
userspace in Vid devices, and to keep touch devices with classic hook.
Signed-off-by: Boris Brezillon
Signed-off-by: Helen Koike
---
Changes in v6:
- Update with new format and buffer structs
- duplicate v4l2_ioctl_ops for touch devices.
Changes in v4:
- Update with new format and buffer structs
- Rebased on top of media/master (post 5.8-rc1)
Changes in v3:
- Rebased on top of media/master (post 5.4-rc1)
Changes in v2:
- New patch
---
---
drivers/media/test-drivers/vivid/vivid-core.c | 207 ++
.../media/test-drivers/vivid/vivid-vid-cap.c | 202 ++---
.../media/test-drivers/vivid/vivid-vid-cap.h | 15 +-
.../media/test-drivers/vivid/vivid-vid-out.c | 197 ++---
.../media/test-drivers/vivid/vivid-vid-out.h | 15 +-
5 files changed, 271 insertions(+), 365 deletions(-)
diff --git a/drivers/media/test-drivers/vivid/vivid-core.c
b/drivers/media/test-drivers/vivid/vivid-core.c
index eacb23808c7e..cebd2032e209 100644
--- a/drivers/media/test-drivers/vivid/vivid-core.c
+++ b/drivers/media/test-drivers/vivid/vivid-core.c
@@ -477,76 +477,6 @@ static int vivid_s_input(struct file *file, void *priv,
unsigned int i)
return vidioc_s_input(file, priv, i);
}
-static int vivid_enum_fmt_cap(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_enum_fmt_tch(file, priv, f);
- return vivid_enum_fmt_vid(file, priv, f);
-}
-
-static int vivid_g_fmt_cap(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch(file, priv, f);
- return vidioc_g_fmt_vid_cap(file, priv, f);
-}
-
-static int vivid_try_fmt_cap(struct file *file, void *priv,
-struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch(file, priv, f);
- return vidioc_try_fmt_vid_cap(file, priv, f);
-}
-
-static int vivid_s_fmt_cap(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch(file, priv, f);
- return vidioc_s_fmt_vid_cap(file, priv, f);
-}
-
-static int vivid_g_fmt_cap_mplane(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch_mplane(file, priv, f);
- return vidioc_g_fmt_vid_cap_mplane(file, priv, f);
-}
-
-static int vivid_try_fmt_cap_mplane(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch_mplane(file, priv, f);
- return vidioc_try_fmt_vid_cap_mplane(file, priv, f);
-}
-
-static int vivid_s_fmt_cap_mplane(struct file *file, void *priv,
- struct v4l2_format *f)
-{
- struct video_device *vdev = video_devdata(file);
-
- if (vdev->vfl_type == VFL_TYPE_TOUCH)
- return vivid_g_fmt_tch_mplane(file, priv, f);
- return vidioc_s_fmt_vid_cap_mplane(file, priv, f);
-}
-
static bool vivid_is_in_use(bool valid, struct video_device *vdev)
{
unsigned long flags;
@@ -656,24 +586,129 @@ static const struct v4l2_file_operations
vivid_radio_fops = {
.unlocked_ioctl = video_ioctl2,
};
+static const struct v4l2_ioctl_ops vivid_ioctl_ops_tch = {
+ .vidioc_querycap= vidioc_querycap,
+
+ .vidioc_enum_fmt_vid_cap = vivid_enum_fmt_tch,
+ .vidioc_g_fmt_vid_cap = vivid_g_fmt_tch,
+ .vidioc_try_fmt_vid_cap = vivid_g_fmt_tch,
+ .vidioc_s_fmt_vid_cap = vivid_g_fmt_tch,
+ .vidioc_g_fmt_vid_cap_mplane = vivid_g_fmt_tch_mplane,
+ .vidioc_try_fmt_vid_cap_mplane = vivid_g_fmt_tch_mplane,
+ .vidioc_s_fmt_vid_cap_mplane = vivid_g_fmt_tch_mplane,
+
+ .vidioc_g_selection = vidioc_g_selection,
+ .vidioc_s_selection = vidioc_s_selection,
+ .vidioc_g_pixelaspect = vidioc_g_pixelaspect,
+
+ .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_s_fmt_vbi_cap =
[PATCH 1/2] media: videobuf2: use dmabuf size for length
Always use dmabuf size when considering the length of the buffer.
Discard userspace provided length.
Fix length check error in _verify_length(), which was handling single and
multiplanar diferently, and also not catching the case where userspace
provides a bigger length and bytesused then the underlying buffer.
Suggested-by: Hans Verkuil
Signed-off-by: Helen Koike
---
Hello,
As discussed on
https://patchwork.linuxtv.org/project/linux-media/patch/gh5kef5bkeel3o6b2dkgc2dfagu9klj...@4ax.com/
This patch also helps the conversion layer of the Ext API patchset,
where we are not exposing the length field.
It was discussed that userspace might use a smaller length field to
limit the usage of the underlying buffer, but I'm not sure if this is
really usefull and just complicates things.
If this is usefull, then we should also expose a length field in the Ext
API, and document this feature properly.
What do you think?
---
.../media/common/videobuf2/videobuf2-core.c | 21 ---
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++
include/uapi/linux/videodev2.h| 7 +--
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 02281d13505f..2cbde14af051 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1205,6 +1205,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+ unsigned int bytesused;
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(q, 1, "invalid dmabuf fd for plane %d\n",
@@ -1213,9 +1214,23 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
goto err;
}
- /* use DMABUF size if length is not provided */
- if (planes[plane].length == 0)
- planes[plane].length = dbuf->size;
+ planes[plane].length = dbuf->size;
+ bytesused = planes[plane].bytesused ?
+ planes[plane].bytesused : dbuf->size;
+
+ if (planes[plane].bytesused > planes[plane].length) {
+ dprintk(q, 1, "bytesused is bigger then dmabuf length
for plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (planes[plane].data_offset >= bytesused) {
+ dprintk(q, 1, "data_offset >= bytesused for plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
if (planes[plane].length < vb->planes[plane].min_length) {
dprintk(q, 1, "invalid dmabuf length %u for plane %d,
minimum length %u\n",
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 7e96f67c60ba..ffc7ed46f74a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -98,14 +98,14 @@ static int __verify_length(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int bytesused;
unsigned int plane;
- if (V4L2_TYPE_IS_CAPTURE(b->type))
+ /* length check for dmabuf is performed in _prepare_dmabuf() */
+ if (V4L2_TYPE_IS_CAPTURE(b->type) || b->memory == VB2_MEMORY_DMABUF)
return 0;
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
for (plane = 0; plane < vb->num_planes; ++plane) {
- length = (b->memory == VB2_MEMORY_USERPTR ||
- b->memory == VB2_MEMORY_DMABUF)
- ? b->m.planes[plane].length
+ length = b->memory == VB2_MEMORY_USERPTR
+ ? b->m.planes[plane].length
: vb->planes[plane].length;
bytesused = b->m.planes[plane].bytesused
? b->m.planes[plane].bytesused : length;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8d15f6ccc4b4..79b3b2893513 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -968,7 +968,9 @@ struct v4l2_requestbuffers {
/**
* struct v4l2_plane - plane info for multi-planar buffers
* @bytesused: number of bytes occupied by data in the plane (payload)
- * @length:size of this plane (NOT the payload) in bytes
+ * @length:size of this plane (NOT the payload) in bytes. Filled
+ * by userspace for USER
[PATCH 2/2] media: videobuf2: cleanup size argument from attach_dmabuf()
Since we always use the size of the underlying buffer for dmabuf, remove
the size parameter from the attach_dmabuf() callback.
Suggested-by: Hans Verkuil
Signed-off-by: Helen Koike
---
drivers/media/common/videobuf2/videobuf2-core.c | 2 +-
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 7 ++-
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 7 ++-
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 7 ++-
include/media/videobuf2-core.h| 1 -
5 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 2cbde14af051..86af4f3c72eb 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1266,7 +1266,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
/* Acquire each plane's memory */
mem_priv = call_ptr_memop(vb, attach_dmabuf,
q->alloc_devs[plane] ? : q->dev,
- dbuf, planes[plane].length, q->dma_dir);
+ dbuf, q->dma_dir);
if (IS_ERR(mem_priv)) {
dprintk(q, 1, "failed to attach dmabuf\n");
ret = PTR_ERR(mem_priv);
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index a7f61ba85440..a26aa52f954b 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -661,14 +661,11 @@ static void vb2_dc_detach_dmabuf(void *mem_priv)
}
static void *vb2_dc_attach_dmabuf(struct device *dev, struct dma_buf *dbuf,
- unsigned long size, enum dma_data_direction dma_dir)
+ enum dma_data_direction dma_dir)
{
struct vb2_dc_buf *buf;
struct dma_buf_attachment *dba;
- if (dbuf->size < size)
- return ERR_PTR(-EFAULT);
-
if (WARN_ON(!dev))
return ERR_PTR(-EINVAL);
@@ -686,7 +683,7 @@ static void *vb2_dc_attach_dmabuf(struct device *dev,
struct dma_buf *dbuf,
}
buf->dma_dir = dma_dir;
- buf->size = size;
+ buf->size = dbuf->size;
buf->db_attach = dba;
return buf;
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index c5b06a509566..8c006f79bed4 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -606,7 +606,7 @@ static void vb2_dma_sg_detach_dmabuf(void *mem_priv)
}
static void *vb2_dma_sg_attach_dmabuf(struct device *dev, struct dma_buf *dbuf,
- unsigned long size, enum dma_data_direction dma_dir)
+ enum dma_data_direction dma_dir)
{
struct vb2_dma_sg_buf *buf;
struct dma_buf_attachment *dba;
@@ -614,9 +614,6 @@ static void *vb2_dma_sg_attach_dmabuf(struct device *dev,
struct dma_buf *dbuf,
if (WARN_ON(!dev))
return ERR_PTR(-EINVAL);
- if (dbuf->size < size)
- return ERR_PTR(-EFAULT);
-
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
@@ -631,7 +628,7 @@ static void *vb2_dma_sg_attach_dmabuf(struct device *dev,
struct dma_buf *dbuf,
}
buf->dma_dir = dma_dir;
- buf->size = size;
+ buf->size = dmabuf->size;
buf->db_attach = dba;
return buf;
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 83f95258ec8c..c2d41b375c10 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -404,20 +404,17 @@ static void vb2_vmalloc_detach_dmabuf(void *mem_priv)
}
static void *vb2_vmalloc_attach_dmabuf(struct device *dev, struct dma_buf
*dbuf,
- unsigned long size, enum dma_data_direction dma_dir)
+ enum dma_data_direction dma_dir)
{
struct vb2_vmalloc_buf *buf;
- if (dbuf->size < size)
- return ERR_PTR(-EFAULT);
-
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
return ERR_PTR(-ENOMEM);
buf->dbuf = dbuf;
buf->dma_dir = dma_dir;
- buf->size = size;
+ buf->size = dbuf->size;
return buf;
}
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 12955cb460d2..db07001cada8 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -134,7 +134,6 @@ struct vb2_mem_ops {
void*(*attach_dmabuf)(struct device *dev,
Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length
Hi John,
On 3/25/21 7:20 AM, John Cox wrote:
Hi
Always use dmabuf size when considering the length of the buffer.
Discard userspace provided length.
Fix length check error in _verify_length(), which was handling single and
multiplanar diferently, and also not catching the case where userspace
provides a bigger length and bytesused then the underlying buffer.
Suggested-by: Hans Verkuil
Signed-off-by: Helen Koike
---
Hello,
As discussed on
https://patchwork.linuxtv.org/project/linux-media/patch/gh5kef5bkeel3o6b2dkgc2dfagu9klj...@4ax.com/
This patch also helps the conversion layer of the Ext API patchset,
where we are not exposing the length field.
It was discussed that userspace might use a smaller length field to
limit the usage of the underlying buffer, but I'm not sure if this is
really usefull and just complicates things.
If this is usefull, then we should also expose a length field in the Ext
API, and document this feature properly.
What do you think?
---
.../media/common/videobuf2/videobuf2-core.c | 21 ---
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++
include/uapi/linux/videodev2.h| 7 +--
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 02281d13505f..2cbde14af051 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1205,6 +1205,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+ unsigned int bytesused;
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(q, 1, "invalid dmabuf fd for plane %d\n",
@@ -1213,9 +1214,23 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
goto err;
}
- /* use DMABUF size if length is not provided */
- if (planes[plane].length == 0)
- planes[plane].length = dbuf->size;
+ planes[plane].length = dbuf->size;
+ bytesused = planes[plane].bytesused ?
+ planes[plane].bytesused : dbuf->size;
+
+ if (planes[plane].bytesused > planes[plane].length) {
+ dprintk(q, 1, "bytesused is bigger then dmabuf length for
plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (planes[plane].data_offset >= bytesused) {
+ dprintk(q, 1, "data_offset >= bytesused for plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
if (planes[plane].length < vb->planes[plane].min_length) {
dprintk(q, 1, "invalid dmabuf length %u for plane %d,
minimum length %u\n",
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 7e96f67c60ba..ffc7ed46f74a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -98,14 +98,14 @@ static int __verify_length(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int bytesused;
unsigned int plane;
- if (V4L2_TYPE_IS_CAPTURE(b->type))
+ /* length check for dmabuf is performed in _prepare_dmabuf() */
+ if (V4L2_TYPE_IS_CAPTURE(b->type) || b->memory == VB2_MEMORY_DMABUF)
return 0;
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
for (plane = 0; plane < vb->num_planes; ++plane) {
- length = (b->memory == VB2_MEMORY_USERPTR ||
- b->memory == VB2_MEMORY_DMABUF)
- ? b->m.planes[plane].length
+ length = b->memory == VB2_MEMORY_USERPTR
+ ? b->m.planes[plane].length
: vb->planes[plane].length;
bytesused = b->m.planes[plane].bytesused
? b->m.planes[plane].bytesused : length;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8d15f6ccc4b4..79b3b2893513 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -968,7 +968,9 @@ struct v4l2_requestbuffers {
/**
* struct v4l2_plane - plane info for multi-planar buffers
* @bytesused: number of bytes occupied by data in the plane (payload)
- * @length:size of this plane (NOT the payload) in bytes
+ * @length:size of this plane (NOT the payload) in bytes.
Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length
Hi Laurent,
On 3/25/21 7:53 AM, Laurent Pinchart wrote:
Hi Helen,
On Wed, Mar 24, 2021 at 09:17:11PM -0300, Helen Koike wrote:
Always use dmabuf size when considering the length of the buffer.
Discard userspace provided length.
Fix length check error in _verify_length(), which was handling single and
multiplanar diferently, and also not catching the case where userspace
provides a bigger length and bytesused then the underlying buffer.
Suggested-by: Hans Verkuil
Signed-off-by: Helen Koike
---
Hello,
As discussed on
https://patchwork.linuxtv.org/project/linux-media/patch/gh5kef5bkeel3o6b2dkgc2dfagu9klj...@4ax.com/
This patch also helps the conversion layer of the Ext API patchset,
where we are not exposing the length field.
It was discussed that userspace might use a smaller length field to
limit the usage of the underlying buffer, but I'm not sure if this is
really usefull and just complicates things.
If this is usefull, then we should also expose a length field in the Ext
API, and document this feature properly.
What do you think?
I think a limit could be useful, as a single dmabuf object could hold
multiple planes, which should be addressed by an offset from the
beginning of the buffer. Giving a length to the kernel could help
catching errors. As the existing API doesn't support offsets, a length
limit is likely not very useful at the moment, but should I believe be
included at least in the new API.
For the new API, If there are no users, we can leave space to add it later
if such a feature becomes interesting for userspace in the future.
For the existing implementation, I'd say that we should be pragmatic. If
using the provided length as a maximum boundary makes the implementation
more complex for very little gain, let's not do it. But on the other
hand, considering existing userspace, would there be added value in
implementing such a mechanism ?
I'm guessing that userspace doesn't use this field as a boundary, since this
usage is not documented. So I'm guessing it makes things more complex for
little gain, so it doesn't seem we are adding much value to userspace.
And with this patch, it will be much easier to implement Ext API with a
conversion layer to/from the existing API.
Regards,
Helen
---
.../media/common/videobuf2/videobuf2-core.c | 21 ---
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++
include/uapi/linux/videodev2.h| 7 +--
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 02281d13505f..2cbde14af051 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1205,6 +1205,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+ unsigned int bytesused;
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(q, 1, "invalid dmabuf fd for plane %d\n",
@@ -1213,9 +1214,23 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
goto err;
}
- /* use DMABUF size if length is not provided */
- if (planes[plane].length == 0)
- planes[plane].length = dbuf->size;
+ planes[plane].length = dbuf->size;
+ bytesused = planes[plane].bytesused ?
+ planes[plane].bytesused : dbuf->size;
+
+ if (planes[plane].bytesused > planes[plane].length) {
+ dprintk(q, 1, "bytesused is bigger then dmabuf length for
plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (planes[plane].data_offset >= bytesused) {
+ dprintk(q, 1, "data_offset >= bytesused for plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
if (planes[plane].length < vb->planes[plane].min_length) {
dprintk(q, 1, "invalid dmabuf length %u for plane %d,
minimum length %u\n",
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 7e96f67c60ba..ffc7ed46f74a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -98,14 +98,14 @@ static int __verify_length(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int bytesused;
unsigned int plane;
- if (V4L2_TYPE_IS_CAPTURE(b->type))
+ /* length check for dmabuf is performed in _prepare_dmabuf() *
Re: [PATCH 1/2] media: videobuf2: use dmabuf size for length
On 3/26/21 10:03 AM, John Cox wrote:
Hi Helen
Hi John,
On 3/25/21 7:20 AM, John Cox wrote:
Hi
Always use dmabuf size when considering the length of the buffer.
Discard userspace provided length.
Fix length check error in _verify_length(), which was handling single and
multiplanar diferently, and also not catching the case where userspace
provides a bigger length and bytesused then the underlying buffer.
Suggested-by: Hans Verkuil
Signed-off-by: Helen Koike
---
Hello,
As discussed on
https://patchwork.linuxtv.org/project/linux-media/patch/gh5kef5bkeel3o6b2dkgc2dfagu9klj...@4ax.com/
This patch also helps the conversion layer of the Ext API patchset,
where we are not exposing the length field.
It was discussed that userspace might use a smaller length field to
limit the usage of the underlying buffer, but I'm not sure if this is
really usefull and just complicates things.
If this is usefull, then we should also expose a length field in the Ext
API, and document this feature properly.
What do you think?
---
.../media/common/videobuf2/videobuf2-core.c | 21 ---
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++
include/uapi/linux/videodev2.h| 7 +--
3 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 02281d13505f..2cbde14af051 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -1205,6 +1205,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
+ unsigned int bytesused;
if (IS_ERR_OR_NULL(dbuf)) {
dprintk(q, 1, "invalid dmabuf fd for plane %d\n",
@@ -1213,9 +1214,23 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
goto err;
}
- /* use DMABUF size if length is not provided */
- if (planes[plane].length == 0)
- planes[plane].length = dbuf->size;
+ planes[plane].length = dbuf->size;
+ bytesused = planes[plane].bytesused ?
+ planes[plane].bytesused : dbuf->size;
+
+ if (planes[plane].bytesused > planes[plane].length) {
+ dprintk(q, 1, "bytesused is bigger then dmabuf length for
plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
+
+ if (planes[plane].data_offset >= bytesused) {
+ dprintk(q, 1, "data_offset >= bytesused for plane %d\n",
+ plane);
+ ret = -EINVAL;
+ goto err;
+ }
if (planes[plane].length < vb->planes[plane].min_length) {
dprintk(q, 1, "invalid dmabuf length %u for plane %d,
minimum length %u\n",
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 7e96f67c60ba..ffc7ed46f74a 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -98,14 +98,14 @@ static int __verify_length(struct vb2_buffer *vb, const
struct v4l2_buffer *b)
unsigned int bytesused;
unsigned int plane;
- if (V4L2_TYPE_IS_CAPTURE(b->type))
+ /* length check for dmabuf is performed in _prepare_dmabuf() */
+ if (V4L2_TYPE_IS_CAPTURE(b->type) || b->memory == VB2_MEMORY_DMABUF)
return 0;
if (V4L2_TYPE_IS_MULTIPLANAR(b->type)) {
for (plane = 0; plane < vb->num_planes; ++plane) {
- length = (b->memory == VB2_MEMORY_USERPTR ||
- b->memory == VB2_MEMORY_DMABUF)
- ? b->m.planes[plane].length
+ length = b->memory == VB2_MEMORY_USERPTR
+ ? b->m.planes[plane].length
: vb->planes[plane].length;
bytesused = b->m.planes[plane].bytesused
? b->m.planes[plane].bytesused : length;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 8d15f6ccc4b4..79b3b2893513 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -968,7 +968,9 @@ struct v4l2_requestbuffers {
/**
* struct v4l2_plane - plane info for multi-planar buffers
* @bytesused:number of bytes occupied by data in the plane
(payload)
- * @length:size of this plane (NOT the payload) in bytes
+ * @length:
[PATCH] media: admin-guide/pixfmt-meta-rkisp1.rst: pixfmt reference conforming with macro
Fix warnings from make htmlddocs:
Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must precede
a section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must
precede a section header)
Fixes: df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer
format")
Signed-off-by: Helen Koike
Reported-by: Stephen Rothwell
---
Documentation/admin-guide/media/rkisp1.rst | 4 ++--
Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/media/rkisp1.rst
b/Documentation/admin-guide/media/rkisp1.rst
index 42e37ed255f6..2267e4fb475e 100644
--- a/Documentation/admin-guide/media/rkisp1.rst
+++ b/Documentation/admin-guide/media/rkisp1.rst
@@ -86,7 +86,7 @@ the driver through the rkisp_params node to improve image
quality during a
video stream.
The buffer format is defined by struct :c:type:`rkisp1_stat_buffer`, and
userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A ` as the
+:ref:`V4L2_META_FMT_RK_ISP1_STAT_3A ` as the
dataformat.
.. _rkisp1_params:
@@ -100,7 +100,7 @@ and others.
The buffer format is defined by struct :c:type:`rkisp1_params_cfg`, and
userspace should set
-:ref:`V4L2_META_FMT_RK_ISP1_PARAMS ` as the
+:ref:`V4L2_META_FMT_RK_ISP1_PARAMS ` as the
dataformat.
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
index f3671472d410..922fa1d59898 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-meta-rkisp1.rst
@@ -1,7 +1,7 @@
.. SPDX-License-Identifier: GPL-2.0
-.. _v4l2-meta-fmt-params-rkisp1:
-.. _v4l2-meta-fmt-stat-rkisp1:
+.. _v4l2-meta-fmt-rk-isp1-params:
+.. _v4l2-meta-fmt-rk-isp1-stat-3a:
*
V4L2_META_FMT_RK_ISP1_PARAMS ('rk1p'), V4L2_META_FMT_RK_ISP1_STAT_3A ('rk1s')
--
2.29.2
Re: linux-next: build warnings after merge of the v4l-dvb tree
Hi Stephen,
On 11/18/20 2:32 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the v4l-dvb tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
> v4l2-meta-fmt-rk-isp1-params (if the link has no caption the label must
> precede a section header)
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label:
> v4l2-meta-fmt-rk-isp1-stat-3a (if the link has no caption the label must
> precede a section header)
>
> Introduced by commit
>
> df22026aebd8 ("media: videodev2.h, v4l2-ioctl: add rkisp1 meta buffer
> format")
>
Thanks for catching this, fix sent:
https://patchwork.linuxtv.org/project/linux-media/patch/20201118142400.3540109-1-helen.ko...@collabora.com/
Regards,
Helen
Re: [PATCH v5 1/7] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)
Hi Tomasz,
On 11/19/20 2:45 AM, Tomasz Figa wrote:
> On Sat, Nov 14, 2020 at 11:21:26AM -0300, Helen Koike wrote:
>> Hi Tomasz,
>>
>> On 10/2/20 4:49 PM, Tomasz Figa wrote:
>>> Hi Helen,
>>>
>>> On Tue, Aug 04, 2020 at 04:29:33PM -0300, Helen Koike wrote:
> [snip]
>>>> +static void v4l_print_ext_pix_format(const void *arg, bool write_only)
>>>> +{
>>>> + const struct v4l2_ext_pix_format *pix = arg;
>>>> + unsigned int i;
>>>> +
>>>> + pr_cont("type=%s, width=%u, height=%u, format=%c%c%c%c, modifier %llx,
>>>> field=%s, colorspace=%d, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
>>>> + prt_names(pix->type, v4l2_type_names),
>>>> + pix->width, pix->height,
>>>> + (pix->pixelformat & 0xff),
>>>> + (pix->pixelformat >> 8) & 0xff,
>>>> + (pix->pixelformat >> 16) & 0xff,
>>>> + (pix->pixelformat >> 24) & 0xff,
>>>> + pix->modifier, prt_names(pix->field, v4l2_field_names),
>>>> + pix->colorspace, pix->ycbcr_enc,
>>>> + pix->quantization, pix->xfer_func);
>>>> + for (i = 0; i < VIDEO_MAX_PLANES && pix->plane_fmt[i].sizeimage; i++)
>>>
>>> This is going to print 8 lines every time. Maybe we could skip 0-sized
>>> planes or something?
>>
>> I'm already checking pix->plane_fmt[i].sizeimage in the loop, it shouldn't
>> print 8 lines every time.
>>
>
> Oops, how could I not notice it. Sorry for the noise.
>
> [snip]
>>>> +int v4l2_ext_pix_format_to_format(const struct v4l2_ext_pix_format *e,
>>>> +struct v4l2_format *f, bool mplane_cap,
>>>> +bool strict)
>>>> +{
>>>> + const struct v4l2_plane_ext_pix_format *pe;
>>>> + struct v4l2_plane_pix_format *p;
>>>> + unsigned int i;
>>>> +
>>>> + memset(f, 0, sizeof(*f));
>>>> +
>>>> + /*
>>>> + * Make sure no modifier is required before doing the
>>>> + * conversion.
>>>> + */
>>>> + if (e->modifier && strict &&
>>>
>>> Do we need the explicit check for e->modifier != 0 if we have to check for
>>> the 2 specific values below anyway?
>>
>> We don't, since DRM_FORMAT_MOD_LINEAR is zero.
>>
>> But I wanted to make it explicit we don't support modifiers in this
>> conversion.
>> But I can remove this check, no problem.
>>
>
> Yes, please. I think the double checking is confusing for the reader.
ok.
>
>>>
>>>> + e->modifier != DRM_FORMAT_MOD_LINEAR &&
>>>> + e->modifier != DRM_FORMAT_MOD_INVALID)
>>>> + return -EINVAL;
>>>> +
>>>> + if (!e->plane_fmt[0].sizeimage && strict)
>>>> + return -EINVAL;
>>>
>>> Why is this incorrect?
>>
>> !sizeimage for the first plane means that there are no planes in ef.
>> strict is true if the result for the conversion should be returned to
>> userspace
>> and it is not some internal handling.
>>
>> So if there are no planes, we would return an incomplete v4l2_format struct
>> to userspace.
>>
>> But this is not very clear, I'll improve this for the next version.
>>
>
> So I can see 2 cases here:
>
> 1) Userspace gives ext struct and driver accepts legacy.
>
> In this case, the kernel needs to adjust the structure to be correct.
> -EINVAL is only valid if
>
> "The struct v4l2_format type field is invalid or the requested buffer type
> not supported."
>
> as per the current uAPI documentation.
>
> 2) Driver gives ext struct and userspace accepts legacy.
>
> If at this point we get a struct with no planes, that sounds like a
> driver bug, so rather than signaling -EINVAL to the userspace, we should
> probably WARN()?
>
> Or am I getting something wrong? :)
Make sense, I'll restructure this for the next version.
>
> [snip]
>>>> +{
>>>> + const struct v4l2_plane_pix_format *p;
>>>> + struct v4l2_plane_ext_pix_format *pe;
>>>> + unsigned int i;
>>>> +
>>>> + memset(e, 0, sizeof(*e));
>>>> +
>>>> + switch (f->type) {
>>>> + case V4L2_BUF_TYPE_VIDEO_CAPTURE:
Re: [PATCH v5 7/7] media: docs: add documentation for the Extended API
On 8/4/20 4:29 PM, Helen Koike wrote: > Add documentation and update references in current documentation for the > Extended API. > > Signed-off-by: Helen Koike > --- > Changes in v5: > - new patch > > .../userspace-api/media/v4l/buffer.rst| 5 + > .../userspace-api/media/v4l/common.rst| 1 + > .../userspace-api/media/v4l/dev-capture.rst | 5 + > .../userspace-api/media/v4l/dev-output.rst| 5 + > .../userspace-api/media/v4l/ext-api.rst | 107 + > .../userspace-api/media/v4l/format.rst| 16 +- > .../userspace-api/media/v4l/user-func.rst | 5 + > .../media/v4l/vidioc-ext-create-bufs.rst | 95 > .../media/v4l/vidioc-ext-prepare-buf.rst | 62 ++ > .../media/v4l/vidioc-ext-qbuf.rst | 204 ++ > .../media/v4l/vidioc-ext-querybuf.rst | 79 +++ > .../media/v4l/vidioc-g-ext-pix-fmt.rst| 117 ++ > 12 files changed, 697 insertions(+), 4 deletions(-) > create mode 100644 Documentation/userspace-api/media/v4l/ext-api.rst > create mode 100644 > Documentation/userspace-api/media/v4l/vidioc-ext-create-bufs.rst > create mode 100644 > Documentation/userspace-api/media/v4l/vidioc-ext-prepare-buf.rst > create mode 100644 Documentation/userspace-api/media/v4l/vidioc-ext-qbuf.rst > create mode 100644 > Documentation/userspace-api/media/v4l/vidioc-ext-querybuf.rst > create mode 100644 > Documentation/userspace-api/media/v4l/vidioc-g-ext-pix-fmt.rst > > diff --git a/Documentation/userspace-api/media/v4l/buffer.rst > b/Documentation/userspace-api/media/v4l/buffer.rst > index 57e752aaf414a..c832bedd64e4c 100644 > --- a/Documentation/userspace-api/media/v4l/buffer.rst > +++ b/Documentation/userspace-api/media/v4l/buffer.rst > @@ -27,6 +27,11 @@ such as pointers and sizes for each plane, are stored in > struct :c:type:`v4l2_plane` instead. In that case, > struct :c:type:`v4l2_buffer` contains an array of plane structures. > > +.. note:: > + > +The :ref:`ext_api` version can also be used, and it is > +preferable when applicable. > + > Dequeued video buffers come with timestamps. The driver decides at which > part of the frame and with which clock the timestamp is taken. Please > see flags in the masks ``V4L2_BUF_FLAG_TIMESTAMP_MASK`` and > diff --git a/Documentation/userspace-api/media/v4l/common.rst > b/Documentation/userspace-api/media/v4l/common.rst > index 7d81c58a13cd7..3430e0bdad667 100644 > --- a/Documentation/userspace-api/media/v4l/common.rst > +++ b/Documentation/userspace-api/media/v4l/common.rst > @@ -59,6 +59,7 @@ applicable to all devices. > ext-ctrls-detect > fourcc > format > +ext-api > planar-apis > selection-api > crop > diff --git a/Documentation/userspace-api/media/v4l/dev-capture.rst > b/Documentation/userspace-api/media/v4l/dev-capture.rst > index 44d3094093ab6..5077639787d92 100644 > --- a/Documentation/userspace-api/media/v4l/dev-capture.rst > +++ b/Documentation/userspace-api/media/v4l/dev-capture.rst > @@ -102,6 +102,11 @@ and :ref:`VIDIOC_S_FMT ` ioctl, even if > :ref:`VIDIOC_S_FMT requests and always returns default parameters as :ref:`VIDIOC_G_FMT > ` does. > :ref:`VIDIOC_TRY_FMT ` is optional. > > +.. note:: > + > +The :ref:`ext_api` version can also be used, and it is > +preferable when applicable. > + > > Reading Images > == > diff --git a/Documentation/userspace-api/media/v4l/dev-output.rst > b/Documentation/userspace-api/media/v4l/dev-output.rst > index e4f2a1d8b0fc7..f8f40c708e49f 100644 > --- a/Documentation/userspace-api/media/v4l/dev-output.rst > +++ b/Documentation/userspace-api/media/v4l/dev-output.rst > @@ -99,6 +99,11 @@ and :ref:`VIDIOC_S_FMT ` ioctl, even if > :ref:`VIDIOC_S_FMT requests and always returns default parameters as :ref:`VIDIOC_G_FMT > ` does. > :ref:`VIDIOC_TRY_FMT ` is optional. > > +.. note:: > + > +The :ref:`ext_api` version can also be used, and it is > +preferable when applicable. > + > > Writing Images > == > diff --git a/Documentation/userspace-api/media/v4l/ext-api.rst > b/Documentation/userspace-api/media/v4l/ext-api.rst > new file mode 100644 > index 0..da2a82960d22f > --- /dev/null > +++ b/Documentation/userspace-api/media/v4l/ext-api.rst > @@ -0,0 +1,107 @@ > +.. Permission is granted to copy, distribute and/or modify this > +.. document under the terms of the GNU Free Documentation License, > +.. Version 1.1 or any later version published by the Free Software > +.. Foundation, with no Invariant Sections, no Front-Cover Texts > +.. and no Back-Cover Texts.
Re: [PATCH v5 1/7] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)
On 11/19/20 7:08 AM, Helen Koike wrote:
> Hi Tomasz,
>
> On 11/19/20 2:45 AM, Tomasz Figa wrote:
>> On Sat, Nov 14, 2020 at 11:21:26AM -0300, Helen Koike wrote:
>>> Hi Tomasz,
>>>
>>> On 10/2/20 4:49 PM, Tomasz Figa wrote:
>>>> Hi Helen,
>>>>
>>>> On Tue, Aug 04, 2020 at 04:29:33PM -0300, Helen Koike wrote:
>> [snip]
>>>>> +static void v4l_print_ext_pix_format(const void *arg, bool write_only)
>>>>> +{
>>>>> + const struct v4l2_ext_pix_format *pix = arg;
>>>>> + unsigned int i;
>>>>> +
>>>>> + pr_cont("type=%s, width=%u, height=%u, format=%c%c%c%c, modifier %llx,
>>>>> field=%s, colorspace=%d, ycbcr_enc=%u, quantization=%u, xfer_func=%u\n",
>>>>> + prt_names(pix->type, v4l2_type_names),
>>>>> + pix->width, pix->height,
>>>>> + (pix->pixelformat & 0xff),
>>>>> + (pix->pixelformat >> 8) & 0xff,
>>>>> + (pix->pixelformat >> 16) & 0xff,
>>>>> + (pix->pixelformat >> 24) & 0xff,
>>>>> + pix->modifier, prt_names(pix->field, v4l2_field_names),
>>>>> + pix->colorspace, pix->ycbcr_enc,
>>>>> + pix->quantization, pix->xfer_func);
>>>>> + for (i = 0; i < VIDEO_MAX_PLANES && pix->plane_fmt[i].sizeimage; i++)
>>>>
>>>> This is going to print 8 lines every time. Maybe we could skip 0-sized
>>>> planes or something?
>>>
>>> I'm already checking pix->plane_fmt[i].sizeimage in the loop, it shouldn't
>>> print 8 lines every time.
>>>
>>
>> Oops, how could I not notice it. Sorry for the noise.
>>
>> [snip]
>>>>> +int v4l2_ext_pix_format_to_format(const struct v4l2_ext_pix_format *e,
>>>>> + struct v4l2_format *f, bool mplane_cap,
>>>>> + bool strict)
>>>>> +{
>>>>> + const struct v4l2_plane_ext_pix_format *pe;
>>>>> + struct v4l2_plane_pix_format *p;
>>>>> + unsigned int i;
>>>>> +
>>>>> + memset(f, 0, sizeof(*f));
>>>>> +
>>>>> + /*
>>>>> + * Make sure no modifier is required before doing the
>>>>> + * conversion.
>>>>> + */
>>>>> + if (e->modifier && strict &&
>>>>
>>>> Do we need the explicit check for e->modifier != 0 if we have to check for
>>>> the 2 specific values below anyway?
>>>
>>> We don't, since DRM_FORMAT_MOD_LINEAR is zero.
>>>
>>> But I wanted to make it explicit we don't support modifiers in this
>>> conversion.
>>> But I can remove this check, no problem.
>>>
>>
>> Yes, please. I think the double checking is confusing for the reader.
>
> ok.
>
>>
>>>>
>>>>> + e->modifier != DRM_FORMAT_MOD_LINEAR &&
>>>>> + e->modifier != DRM_FORMAT_MOD_INVALID)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + if (!e->plane_fmt[0].sizeimage && strict)
>>>>> + return -EINVAL;
>>>>
>>>> Why is this incorrect?
>>>
>>> !sizeimage for the first plane means that there are no planes in ef.
>>> strict is true if the result for the conversion should be returned to
>>> userspace
>>> and it is not some internal handling.
>>>
>>> So if there are no planes, we would return an incomplete v4l2_format struct
>>> to userspace.
>>>
>>> But this is not very clear, I'll improve this for the next version.
>>>
>>
>> So I can see 2 cases here:
>>
>> 1) Userspace gives ext struct and driver accepts legacy.
>>
>> In this case, the kernel needs to adjust the structure to be correct.
>> -EINVAL is only valid if
>>
>> "The struct v4l2_format type field is invalid or the requested buffer type
>> not supported."
>>
>> as per the current uAPI documentation.
>>
>> 2) Driver gives ext struct and userspace accepts legacy.
>>
>> If at this point we get a struct with no planes, that sounds like a
>> driver bug, so rather than signaling -EINVAL to the userspace, we should
>> probably WARN()?
>>
>> Or am I getting something
Re: [PATCH v5 1/7] media: v4l2: Extend pixel formats to unify single/multi-planar handling (and more)
Hi Alexandre,
Thanks for your review.
On 8/14/20 4:49 AM, Alexandre Courbot wrote:
> On Wed, Aug 5, 2020 at 4:32 AM Helen Koike wrote:
>>
>> This is part of the multiplanar and singleplanar unification process.
>> v4l2_ext_pix_format is supposed to work for both cases.
>>
>> We also add the concept of modifiers already employed in DRM to expose
>> HW-specific formats (like tiled or compressed formats) and allow
>> exchanging this information with the DRM subsystem in a consistent way.
>>
>> Note that only V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] are accepted in
>> v4l2_ext_format, other types will be rejected if you use the
>> {G,S,TRY}_EXT_PIX_FMT ioctls.
>>
>> New hooks have been added to v4l2_ioctl_ops to support those new ioctls
>> in drivers, but, in the meantime, the core takes care of converting
>> {S,G,TRY}_EXT_PIX_FMT requests into {S,G,TRY}_FMT so that old drivers can
>> still work if the userspace app/lib uses the new ioctls.
>> The conversion is also done the other around to allow userspace
>> apps/libs using {S,G,TRY}_FMT to work with drivers implementing the
>> _ext_ hooks.
>>
>> Signed-off-by: Boris Brezillon
>> Signed-off-by: Helen Koike
>> ---
>> Changes in v5:
>> - change sizes and reorder fields to avoid holes in the struct and make
>> it the same for 32 and 64 bits
>> - removed __attribute__ ((packed)) from uapi structs
>> - Fix doc warning from make htmldocs
>> - Updated commit message with EXT_PIX prefix for the ioctls.
>>
>> Changes in v4:
>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>> - Add reserved fields
>> - Removed num_planes from struct v4l2_ext_pix_format
>> - Removed flag field from struct v4l2_ext_pix_format, since the only
>> defined value is V4L2_PIX_FMT_FLAG_PREMUL_ALPHA only used by vsp1,
>> where we can use modifiers, or add it back later through the reserved
>> bits.
>> - In v4l2_ext_format_to_format(), check if modifier is != MOD_LINEAR &&
>> != MOD_INVALID
>> - Fix type assignment in v4l_g_fmt_ext_pix()
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - Move the modifier in v4l2_ext_format (was formerly placed in
>> v4l2_ext_plane)
>> - Fix a few bugs in the converters and add a strict parameter to
>> allow conversion of uninitialized/mis-initialized objects
>> ---
>> drivers/media/v4l2-core/v4l2-dev.c | 21 +-
>> drivers/media/v4l2-core/v4l2-ioctl.c | 585 +++
>> include/media/v4l2-ioctl.h | 34 ++
>> include/uapi/linux/videodev2.h | 56 +++
>> 4 files changed, 615 insertions(+), 81 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index a593ea0598b55..e1829906bc086 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -607,25 +607,37 @@ static void determine_valid_ioctls(struct video_device
>> *vdev)
>> set_bit(_IOC_NR(VIDIOC_ENUM_FMT), valid_ioctls);
>> if ((is_rx && (ops->vidioc_g_fmt_vid_cap ||
>>ops->vidioc_g_fmt_vid_cap_mplane ||
>> + ops->vidioc_g_ext_pix_fmt_vid_cap ||
>>ops->vidioc_g_fmt_vid_overlay)) ||
>> (is_tx && (ops->vidioc_g_fmt_vid_out ||
>>ops->vidioc_g_fmt_vid_out_mplane ||
>> - ops->vidioc_g_fmt_vid_out_overlay)))
>> + ops->vidioc_g_ext_pix_fmt_vid_out ||
>> + ops->vidioc_g_fmt_vid_out_overlay))) {
>> set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
>> +set_bit(_IOC_NR(VIDIOC_G_EXT_PIX_FMT),
>> valid_ioctls);
>> + }
>> if ((is_rx && (ops->vidioc_s_fmt_vid_cap ||
>>ops->vidioc_s_fmt_vid_cap_mplane ||
>> + ops->vidioc_s_ext_pix_fmt_vid_cap ||
>>ops->vidioc_s_fmt_vid_overlay)) ||
>> (is_tx && (ops->vidioc_s_fmt_vid_out ||
>>ops->vidioc_s_fmt_vid_out_mplane ||
>> -
Re: [PATCH] media: rockchip: rkisp1: remove some dead code
Hi Dan,
Thank you for your patch.
On 11/30/20 9:53 AM, Dan Carpenter wrote:
> The debugfs_create_dir() function never returns NULLs. It's not supposed
> to checked for errors in the normal case and there is no need to check
> in this function so let's just delete this dead code.
>
> Signed-off-by: Dan Carpenter
> ---
> drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 9af137e4967f..68da1eed753d 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -430,10 +430,6 @@ static void rkisp1_debug_init(struct rkisp1_device
> *rkisp1)
> struct rkisp1_debug *debug = &rkisp1->debug;
>
> debug->debugfs_dir = debugfs_create_dir(RKISP1_DRIVER_NAME, NULL);
> - if (!debug->debugfs_dir) {
> - dev_dbg(rkisp1->dev, "failed to create debugfs directory\n");
> - return;
> - }
I was taking a look at the debugfs_create_dir() code, and I saw it can
return ERR_PTR(), so ideally we should check for errors with IS_ERR() /
PTR_ERR().
Also from the docs:
* If an error occurs, ERR_PTR(-ERROR) will be
* returned.
*
* If debugfs is not enabled in the kernel, the value -%ENODEV will be
* returned.
> debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
>&debug->data_loss);
> debugfs_create_ulong("outform_size_err", 0444, debug->debugfs_dir,
>
nit: I would change the name of the commit just to make it clear what it
does.
Example: Remove useless error check from debugfs_create_dir()
Thanks,
Helen
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Hans,
Thank you for your review.
On 9/9/20 9:27 AM, Hans Verkuil wrote:
> Hi Helen,
>
> Again I'm just reviewing the uAPI.
>
> On 04/08/2020 21:29, Helen Koike wrote:
>> From: Hans Verkuil
>>
>> Those extended buffer ops have several purpose:
>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>the number of ns elapsed since 1970
>> 2/ Unify single/multiplanar handling
>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>to support the case where a single buffer object is storing all
>>planes data, each one being placed at a different offset
>>
>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>> these new objects.
>>
>> The core takes care of converting new ioctls requests to old ones
>> if the driver does not support the new hooks, and vice versa.
>>
>> Note that the timecode field is gone, since there doesn't seem to be
>> in-kernel users. We can be added back in the reserved area if needed or
>> use the Request API to collect more metadata information from the
>> frame.
>>
>> Signed-off-by: Hans Verkuil
>> Signed-off-by: Boris Brezillon
>> Signed-off-by: Helen Koike
>> ---
>> Changes in v5:
>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane
>> - return mem_offset to struct v4l2_ext_plane
>> - change sizes and reorder fields to avoid holes in the struct and make
>> it the same for 32 and 64 bits
>>
>> Changes in v4:
>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>> I think we can add this later, so I removed it from this RFC to simplify it.
>> - Remove num_planes field from struct v4l2_ext_buffer
>> - Add flags field to struct v4l2_ext_create_buffers
>> - Reformulate struct v4l2_ext_plane
>> - Fix some bugs caught by v4l2-compliance
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>> later on
>> ---
>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++-
>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +--
>> include/media/v4l2-ioctl.h | 26 ++
>> include/uapi/linux/videodev2.h | 90 +++
>> 4 files changed, 476 insertions(+), 22 deletions(-)
>>
>
>
>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 7123c6a4d9569..334cafdd2be97 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -996,6 +996,41 @@ struct v4l2_plane {
>> __u32 reserved[11];
>> };
>>
>> +/**
>> + * struct v4l2_ext_plane - extended plane buffer info
>> + * @buffer_length: size of the entire buffer in bytes, should fit
>> + * @offset + @plane_length
>> + * @plane_length: size of the plane in bytes.
>> + * @mem_offset: If V4L2_MEMORY_MMAP is used, then it can be a
>> "cookie"
>> + * that should be passed to mmap() called on the video
>> node.
>> + * @userptr:when memory is V4L2_MEMORY_USERPTR, a userspace
>> pointer pointing
>> + * to this plane.
>> + * @dmabuf_fd: when memory is V4L2_MEMORY_DMABUF, a userspace
>> file descriptor
>> + * associated with this plane.
>> + * @offset: offset in the memory buffer where the plane starts.
>> + * @memory: enum v4l2_memory; the method, in which the actual video
>> + * data is passed
>> + * @reserved: extra space reserved for future fields, must be
>> set to 0.
>> + *
>> + *
>> + * Buffers consist of one or more planes, e.g. an YCbCr buffer with two
>> planes
>> + * can have one plane for Y, and another for interleaved CbCr components.
>> + * Each plane can reside in a separate memory buffer, or even in
>> + * a completely separate memory node (e.g. in embedded devices).
>> + */
>> +struct v4l2_ext_plane {
>> +__u32 buffer_length;
>> +__u32 plane_length;
>> +union {
>> +__u32 mem_offset;
>> +__u64 userptr;
>> +
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
On 11/23/20 12:46 PM, Tomasz Figa wrote:
> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike
> wrote:
>>
>> Hi Hans,
>>
>> Thank you for your review.
>>
>> On 9/9/20 9:27 AM, Hans Verkuil wrote:
>>> Hi Helen,
>>>
>>> Again I'm just reviewing the uAPI.
>>>
>>> On 04/08/2020 21:29, Helen Koike wrote:
>>>> From: Hans Verkuil
>>>>
>>>> Those extended buffer ops have several purpose:
>>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>>>the number of ns elapsed since 1970
>>>> 2/ Unify single/multiplanar handling
>>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>>>to support the case where a single buffer object is storing all
>>>>planes data, each one being placed at a different offset
>>>>
>>>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>>>> these new objects.
>>>>
>>>> The core takes care of converting new ioctls requests to old ones
>>>> if the driver does not support the new hooks, and vice versa.
>>>>
>>>> Note that the timecode field is gone, since there doesn't seem to be
>>>> in-kernel users. We can be added back in the reserved area if needed or
>>>> use the Request API to collect more metadata information from the
>>>> frame.
>>>>
>>>> Signed-off-by: Hans Verkuil
>>>> Signed-off-by: Boris Brezillon
>>>> Signed-off-by: Helen Koike
>>>> ---
>>>> Changes in v5:
>>>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane
>>>> - return mem_offset to struct v4l2_ext_plane
>>>> - change sizes and reorder fields to avoid holes in the struct and make
>>>> it the same for 32 and 64 bits
>>>>
>>>> Changes in v4:
>>>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>>>> I think we can add this later, so I removed it from this RFC to simplify
>>>> it.
>>>> - Remove num_planes field from struct v4l2_ext_buffer
>>>> - Add flags field to struct v4l2_ext_create_buffers
>>>> - Reformulate struct v4l2_ext_plane
>>>> - Fix some bugs caught by v4l2-compliance
>>>> - Rebased on top of media/master (post 5.8-rc1)
>>>>
>>>> Changes in v3:
>>>> - Rebased on top of media/master (post 5.4-rc1)
>>>>
>>>> Changes in v2:
>>>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>>> later on
>>>> ---
>>>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++-
>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +--
>>>> include/media/v4l2-ioctl.h | 26 ++
>>>> include/uapi/linux/videodev2.h | 90 +++
>>>> 4 files changed, 476 insertions(+), 22 deletions(-)
>>>>
>>>
>>>
>>>
>>>> diff --git a/include/uapi/linux/videodev2.h
>>>> b/include/uapi/linux/videodev2.h
>>>> index 7123c6a4d9569..334cafdd2be97 100644
>>>> --- a/include/uapi/linux/videodev2.h
>>>> +++ b/include/uapi/linux/videodev2.h
>>>> @@ -996,6 +996,41 @@ struct v4l2_plane {
>>>> __u32 reserved[11];
>>>> };
>>>>
>>>> +/**
>>>> + * struct v4l2_ext_plane - extended plane buffer info
>>>> + * @buffer_length: size of the entire buffer in bytes, should fit
>>>> + * @offset + @plane_length
>>>> + * @plane_length: size of the plane in bytes.
>>>> + * @mem_offset: If V4L2_MEMORY_MMAP is used, then it can be a
>>>> "cookie"
>>>> + * that should be passed to mmap() called on the video
>>>> node.
>>>> + * @userptr:when memory is V4L2_MEMORY_USERPTR, a
>>>> userspace pointer pointing
>>>> + * to this plane.
>>>> + * @dmabuf_fd: when memory is V4L2_MEMORY_DMABUF, a
>>>> userspace file descriptor
>>>> + * associated with this plane.
>>>> + * @offset:
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Tomasz,
On 11/20/20 8:14 AM, Tomasz Figa wrote:
> Hi Helen,
>
> On Tue, Aug 04, 2020 at 04:29:34PM -0300, Helen Koike wrote:
>> From: Hans Verkuil
>>
>> Those extended buffer ops have several purpose:
>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>the number of ns elapsed since 1970
>> 2/ Unify single/multiplanar handling
>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>to support the case where a single buffer object is storing all
>>planes data, each one being placed at a different offset
>>
>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>> these new objects.
>>
>> The core takes care of converting new ioctls requests to old ones
>> if the driver does not support the new hooks, and vice versa.
>>
>> Note that the timecode field is gone, since there doesn't seem to be
>> in-kernel users. We can be added back in the reserved area if needed or
>> use the Request API to collect more metadata information from the
>> frame.
>>
>
> Thanks for the patch. Please see my comments inline.
Thank you for your detailed review, please see my comments below.
>
>> Signed-off-by: Hans Verkuil
>> Signed-off-by: Boris Brezillon
>> Signed-off-by: Helen Koike
>> ---
>> Changes in v5:
>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane
>> - return mem_offset to struct v4l2_ext_plane
>> - change sizes and reorder fields to avoid holes in the struct and make
>> it the same for 32 and 64 bits
>>
>> Changes in v4:
>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>> I think we can add this later, so I removed it from this RFC to simplify it.
>> - Remove num_planes field from struct v4l2_ext_buffer
>> - Add flags field to struct v4l2_ext_create_buffers
>> - Reformulate struct v4l2_ext_plane
>> - Fix some bugs caught by v4l2-compliance
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>> later on
>> ---
>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++-
>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +--
>> include/media/v4l2-ioctl.h | 26 ++
>> include/uapi/linux/videodev2.h | 90 +++
>> 4 files changed, 476 insertions(+), 22 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
>> b/drivers/media/v4l2-core/v4l2-dev.c
>> index e1829906bc086..cb21ee8eb075c 100644
>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>> @@ -720,15 +720,34 @@ static void determine_valid_ioctls(struct video_device
>> *vdev)
>> SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_sdr_out);
>> }
>>
>> +if (is_vid || is_tch) {
>> +/* ioctls valid for video and touch */
>> +if (ops->vidioc_querybuf || ops->vidioc_ext_querybuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_QUERYBUF), valid_ioctls);
>> +if (ops->vidioc_qbuf || ops->vidioc_ext_qbuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_QBUF), valid_ioctls);
>> +if (ops->vidioc_dqbuf || ops->vidioc_ext_dqbuf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_DQBUF), valid_ioctls);
>> +if (ops->vidioc_create_bufs || ops->vidioc_ext_create_bufs)
>> +set_bit(_IOC_NR(VIDIOC_EXT_CREATE_BUFS), valid_ioctls);
>> +if (ops->vidioc_prepare_buf || ops->vidioc_ext_prepare_buf)
>> +set_bit(_IOC_NR(VIDIOC_EXT_PREPARE_BUF), valid_ioctls);
>
> nit: Could we stick to the SET_VALID_IOCTL() macro and just call it twice,
> once for the new and once for the legacy callback?
Ack.
>
>> +}
>> +
>> if (is_vid || is_vbi || is_sdr || is_tch || is_meta) {
>> /* ioctls valid for video, vbi, sdr, touch and metadata */
>> SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
>> -SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
>> -SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
>> SET_VALID_IOCTL(ops, VIDIOC_E
Re: [PATCH] media: rockchip: rkisp1: Fix typos in comments and macro definitions
Hi Peilin,
On 11/26/20 9:21 AM, Peilin Ye wrote:
> Fix 4 typos under drivers/media/platform/rockchip/rkisp1/ found by
> checkpatch, including the RKISP1_CIF_MI_{M,S}P_PINGPONG_ENABLE macro
> definitions.
>
> Signed-off-by: Peilin Ye
Thanks
Acked-by: Helen Koike
> ---
> Hi Helen, Dafna,
>
> I noticed that the RKISP1_CIF_MI_{M,S}P_PINGPONG_ENABLE macros are not
> being used yet, but according to page 12 of this developer guide [1] I
> think they are for *enabling* the ping-pong ("double buffers") mode?
Looks like. The documentation I have doesn't explain much about this
mode, it just mention that bit is used to enable it, and that
MI_{MP,SP}_{CR,CB}_BASE_AD_INIT2 are used to configure base address 2.
Regards,
Helen
>
> Based on linux-next 9d3e48f20e11 ("Add linux-next specific files for
> 20201125").
>
> Thanks,
> Peilin Ye
>
> [1]
> https://dl.vamrs.com/products/rock960/docs/sw/Rockchip%C2%A0Linux%20Camera%C2%A0Developer%20Guide%20V1.1.pdf#page=12
>
> drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c | 4 ++--
> drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h| 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> index b81235afd053..94b65680c4c1 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
> @@ -46,7 +46,7 @@ enum rkisp1_plane {
> /*
> * @fourcc: pixel format
> * @fmt_type: helper filed for pixel format
> - * @uv_swap: if cb cr swaped, for yuv
> + * @uv_swap: if cb cr swapped, for yuv
> * @write_format: defines how YCbCr self picture data is written to memory
> * @output_format: defines sp output format
> * @mbus: the mbus code on the src resizer pad that matches the pixel format
> @@ -870,7 +870,7 @@ static void rkisp1_cap_stream_disable(struct
> rkisp1_capture *cap)
> {
> int ret;
>
> - /* Stream should stop in interrupt. If it dosn't, stop it by force. */
> + /* Stream should stop in interrupt. If it doesn't, stop it by force. */
> cap->is_stopping = true;
> ret = wait_event_timeout(cap->done,
>!cap->is_streaming,
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> index 049f6c3a11df..8a8d960a679c 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> @@ -106,8 +106,8 @@
> #define RKISP1_CIF_MI_SP_Y_FULL_YUV2RGB BIT(8)
> #define RKISP1_CIF_MI_SP_CBCR_FULL_YUV2RGB BIT(9)
> #define RKISP1_CIF_MI_SP_422NONCOSITEED BIT(10)
> -#define RKISP1_CIF_MI_MP_PINGPONG_ENABEL BIT(11)
> -#define RKISP1_CIF_MI_SP_PINGPONG_ENABEL BIT(12)
> +#define RKISP1_CIF_MI_MP_PINGPONG_ENABLE BIT(11)
> +#define RKISP1_CIF_MI_SP_PINGPONG_ENABLE BIT(12)
> #define RKISP1_CIF_MI_MP_AUTOUPDATE_ENABLE BIT(13)
> #define RKISP1_CIF_MI_SP_AUTOUPDATE_ENABLE BIT(14)
> #define RKISP1_CIF_MI_LAST_PIXEL_SIG_ENABLE BIT(15)
>
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Tomasz, Thanks for your comments, I have a few questions below. On 12/16/20 12:13 AM, Tomasz Figa wrote: > On Tue, Dec 15, 2020 at 11:37 PM Helen Koike > wrote: >> >> Hi Tomasz, >> >> On 12/14/20 7:46 AM, Tomasz Figa wrote: >>> On Fri, Dec 4, 2020 at 4:52 AM Helen Koike >>> wrote: >>>> >>>> Hi, >>>> >>>> Please see my 2 points below (about v4l2_ext_buffer and another about >>>> timestamp). >>>> >>>> On 12/3/20 12:11 PM, Hans Verkuil wrote: >>>>> On 23/11/2020 18:40, Helen Koike wrote: >>>>>> >>>>>> >>>>>> On 11/23/20 12:46 PM, Tomasz Figa wrote: >>>>>>> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike >>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Hans, >>>>>>>> >>>>>>>> Thank you for your review. >>>>>>>> >>>>>>>> On 9/9/20 9:27 AM, Hans Verkuil wrote: >>>>>>>>> Hi Helen, >>>>>>>>> >>>>>>>>> Again I'm just reviewing the uAPI. >>>>>>>>> >>>>>>>>> On 04/08/2020 21:29, Helen Koike wrote: >>>>>>>>>> From: Hans Verkuil >>>>>>>>>> >>>>>>>>>> Those extended buffer ops have several purpose: >>>>>>>>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting >>>>>>>>>>the number of ns elapsed since 1970 >>>>>>>>>> 2/ Unify single/multiplanar handling >>>>>>>>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct >>>>>>>>>>to support the case where a single buffer object is storing all >>>>>>>>>>planes data, each one being placed at a different offset >>>>>>>>>> >>>>>>>>>> New hooks are created in v4l2_ioctl_ops so that drivers can start >>>>>>>>>> using >>>>>>>>>> these new objects. >>>>>>>>>> >>>>>>>>>> The core takes care of converting new ioctls requests to old ones >>>>>>>>>> if the driver does not support the new hooks, and vice versa. >>>>>>>>>> >>>>>>>>>> Note that the timecode field is gone, since there doesn't seem to be >>>>>>>>>> in-kernel users. We can be added back in the reserved area if needed >>>>>>>>>> or >>>>>>>>>> use the Request API to collect more metadata information from the >>>>>>>>>> frame. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Hans Verkuil >>>>>>>>>> Signed-off-by: Boris Brezillon >>>>>>>>>> Signed-off-by: Helen Koike >>>>>>>>>> --- >>>>>>>>>> Changes in v5: >>>>>>>>>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane >>>>>>>>>> - return mem_offset to struct v4l2_ext_plane >>>>>>>>>> - change sizes and reorder fields to avoid holes in the struct and >>>>>>>>>> make >>>>>>>>>> it the same for 32 and 64 bits >>>>>>>>>> >>>>>>>>>> Changes in v4: >>>>>>>>>> - Use v4l2_ext_pix_format directly in the ioctl, drop >>>>>>>>>> v4l2_ext_format, >>>>>>>>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types. >>>>>>>>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from >>>>>>>>>> VIDIOC_EXPBUF >>>>>>>>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at >>>>>>>>>> once. >>>>>>>>>> I think we can add this later, so I removed it from this RFC to >>>>>>>>>> simplify it. >>>>>>>>>> - Remove num_planes field from struct v4l2_ext_buffer >>>>>>>>>> - Add flags field to struct v4l2_ext_create_buffers >>>>>>>>>&g
Re: [PATCH] media: rockchip: rkisp1: remove some dead code
Hi Dan,
On 12/1/20 11:27 AM, Dan Carpenter wrote:
> On Mon, Nov 30, 2020 at 11:20:05AM -0300, Helen Koike wrote:
>> Hi Dan,
>>
>> Thank you for your patch.
>>
>> On 11/30/20 9:53 AM, Dan Carpenter wrote:
>>> The debugfs_create_dir() function never returns NULLs. It's not supposed
>>> to checked for errors in the normal case and there is no need to check
>>> in this function so let's just delete this dead code.
>>>
>>> Signed-off-by: Dan Carpenter
>>> ---
>>> drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4
>>> 1 file changed, 4 deletions(-)
>>>
>>> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>> b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>> index 9af137e4967f..68da1eed753d 100644
>>> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
>>> @@ -430,10 +430,6 @@ static void rkisp1_debug_init(struct rkisp1_device
>>> *rkisp1)
>>> struct rkisp1_debug *debug = &rkisp1->debug;
>>>
>>> debug->debugfs_dir = debugfs_create_dir(RKISP1_DRIVER_NAME, NULL);
>>> - if (!debug->debugfs_dir) {
>>> - dev_dbg(rkisp1->dev, "failed to create debugfs directory\n");
>>> - return;
>>> - }
>>
>> I was taking a look at the debugfs_create_dir() code, and I saw it can
>> return ERR_PTR(), so ideally we should check for errors with IS_ERR() /
>> PTR_ERR().
>
> Debugfs functions aren't meant to be error checked in the normal case.
> There are some drivers which dereference the dentry pointer so those
> need to check it but that's not very common and isn't the case here.
right, I just saw the functions in inode.c already checks the parent with
IS_ERR(). the debugfs_create_*() function calls start_creating() which
already checks the parent.
ok, fair enough, I'll ack v2.
Regards,
Helen
>
> I'm really sure this must be documented somewhere but I can't find it
> at all. :P But look at commit 057e212eae72 ("media: usb: uvc: no need
> to check return value of debugfs_create functions") for example.
>
> regards,
> dan carpenter
>
Re: [PATCH v2] media: rockchip: rkisp1: remove useless debugfs checks
On 12/1/20 11:30 AM, Dan Carpenter wrote:
> The debugfs_create_dir() function never returns NULLs so this code will
> never be executed. It's not intended that callers will check for
> debugfs errors in the normal case and it's not necessary in this driver,
> so we can just delete this code.
>
> Signed-off-by: Dan Carpenter
Since the debugfs_create_*() functions already check the parent
with IS_ERR(), this looks good to me.
Acked-by: Helen Koike
Thanks
Helen
> ---
> v2: Fix subject
>
> drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> index 9af137e4967f..68da1eed753d 100644
> --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-dev.c
> @@ -430,10 +430,6 @@ static void rkisp1_debug_init(struct rkisp1_device
> *rkisp1)
> struct rkisp1_debug *debug = &rkisp1->debug;
>
> debug->debugfs_dir = debugfs_create_dir(RKISP1_DRIVER_NAME, NULL);
> - if (!debug->debugfs_dir) {
> - dev_dbg(rkisp1->dev, "failed to create debugfs directory\n");
> - return;
> - }
> debugfs_create_ulong("data_loss", 0444, debug->debugfs_dir,
>&debug->data_loss);
> debugfs_create_ulong("outform_size_err", 0444, debug->debugfs_dir,
>
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi,
Please see my 2 points below (about v4l2_ext_buffer and another about
timestamp).
On 12/3/20 12:11 PM, Hans Verkuil wrote:
> On 23/11/2020 18:40, Helen Koike wrote:
>>
>>
>> On 11/23/20 12:46 PM, Tomasz Figa wrote:
>>> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike
>>> wrote:
>>>>
>>>> Hi Hans,
>>>>
>>>> Thank you for your review.
>>>>
>>>> On 9/9/20 9:27 AM, Hans Verkuil wrote:
>>>>> Hi Helen,
>>>>>
>>>>> Again I'm just reviewing the uAPI.
>>>>>
>>>>> On 04/08/2020 21:29, Helen Koike wrote:
>>>>>> From: Hans Verkuil
>>>>>>
>>>>>> Those extended buffer ops have several purpose:
>>>>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>>>>>the number of ns elapsed since 1970
>>>>>> 2/ Unify single/multiplanar handling
>>>>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>>>>>to support the case where a single buffer object is storing all
>>>>>>planes data, each one being placed at a different offset
>>>>>>
>>>>>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>>>>>> these new objects.
>>>>>>
>>>>>> The core takes care of converting new ioctls requests to old ones
>>>>>> if the driver does not support the new hooks, and vice versa.
>>>>>>
>>>>>> Note that the timecode field is gone, since there doesn't seem to be
>>>>>> in-kernel users. We can be added back in the reserved area if needed or
>>>>>> use the Request API to collect more metadata information from the
>>>>>> frame.
>>>>>>
>>>>>> Signed-off-by: Hans Verkuil
>>>>>> Signed-off-by: Boris Brezillon
>>>>>> Signed-off-by: Helen Koike
>>>>>> ---
>>>>>> Changes in v5:
>>>>>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane
>>>>>> - return mem_offset to struct v4l2_ext_plane
>>>>>> - change sizes and reorder fields to avoid holes in the struct and make
>>>>>> it the same for 32 and 64 bits
>>>>>>
>>>>>> Changes in v4:
>>>>>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>>>>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>>>>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>>>>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>>>>>> I think we can add this later, so I removed it from this RFC to simplify
>>>>>> it.
>>>>>> - Remove num_planes field from struct v4l2_ext_buffer
>>>>>> - Add flags field to struct v4l2_ext_create_buffers
>>>>>> - Reformulate struct v4l2_ext_plane
>>>>>> - Fix some bugs caught by v4l2-compliance
>>>>>> - Rebased on top of media/master (post 5.8-rc1)
>>>>>>
>>>>>> Changes in v3:
>>>>>> - Rebased on top of media/master (post 5.4-rc1)
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>>>>> later on
>>>>>> ---
>>>>>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++-
>>>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +--
>>>>>> include/media/v4l2-ioctl.h | 26 ++
>>>>>> include/uapi/linux/videodev2.h | 90 +++
>>>>>> 4 files changed, 476 insertions(+), 22 deletions(-)
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> diff --git a/include/uapi/linux/videodev2.h
>>>>>> b/include/uapi/linux/videodev2.h
>>>>>> index 7123c6a4d9569..334cafdd2be97 100644
>>>>>> --- a/include/uapi/linux/videodev2.h
>>>>>> +++ b/include/uapi/linux/videodev2.h
>>>>>> @@ -996,6 +996,41 @@ struct v4l2_plane {
>>>>>> __u32 reserved[11];
>>>>>> };
>>>>>>
>>>>>> +/**
>>>>>> + * struct v4l2_ext_plane - extended plane bu
[PATCH] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
YUV 4:4:4 is not subsampled, fix this in the docs.
Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV formats
to common file")
Signed-off-by: Helen Koike
---
Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
index 7d4d39201a3f..bcb4ef24c334 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -396,8 +396,8 @@ number of lines as the luma plane.
NV24 and NV42
-
-Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
-horizontal direction. Chroma lines contain half the number of pixels and the
+Semi-planar YUV 4:4:4 formats. No sub-sampling.
+Chroma lines contain the same number of pixels and the
same number of bytes as luma lines, and the chroma plane contains the same
number of lines as the luma plane.
--
2.30.0
Re: [PATCH] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
On 1/23/21 6:56 AM, Laurent Pinchart wrote:
> Hi Helen,
>
> Thank you for the patch.
>
> On Fri, Jan 22, 2021 at 03:27:23PM -0300, Helen Koike wrote:
>> YUV 4:4:4 is not subsampled, fix this in the docs.
>>
>> Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV
>> formats to common file")
>> Signed-off-by: Helen Koike
>> ---
>> Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> index 7d4d39201a3f..bcb4ef24c334 100644
>> --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>> @@ -396,8 +396,8 @@ number of lines as the luma plane.
>> NV24 and NV42
>> -
>>
>> -Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
>> -horizontal direction. Chroma lines contain half the number of pixels and the
>> +Semi-planar YUV 4:4:4 formats. No sub-sampling.
>
> "The chroma plane is not subsampled." ?
Ack.
>
>> +Chroma lines contain the same number of pixels and the
>> same number of bytes as luma lines, and the chroma plane contains the same
>> number of lines as the luma plane.
>
> That's not quite right, the chroma lines contain twice the number of
> pixels and bytes, as there's one Cb and one Cr value in the chroma line
> for each Y value in the luma line.
>
>
> Maybe the text could be reflowed ?
>
Ack.
I'll submit v2 updating the text.
Thanks,
Helen
Re: [PATCH] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
On 1/25/21 10:57 AM, Helen Koike wrote:
>
>
> On 1/23/21 6:56 AM, Laurent Pinchart wrote:
>> Hi Helen,
>>
>> Thank you for the patch.
>>
>> On Fri, Jan 22, 2021 at 03:27:23PM -0300, Helen Koike wrote:
>>> YUV 4:4:4 is not subsampled, fix this in the docs.
>>>
>>> Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV
>>> formats to common file")
>>> Signed-off-by: Helen Koike
>>> ---
>>> Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> index 7d4d39201a3f..bcb4ef24c334 100644
>>> --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
>>> @@ -396,8 +396,8 @@ number of lines as the luma plane.
>>> NV24 and NV42
>>> -
>>>
>>> -Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
>>> -horizontal direction. Chroma lines contain half the number of pixels and
>>> the
>>> +Semi-planar YUV 4:4:4 formats. No sub-sampling.
>>
>> "The chroma plane is not subsampled." ?
>
> Ack.
>
>>
>>> +Chroma lines contain the same number of pixels and the
>>> same number of bytes as luma lines, and the chroma plane contains the same
>>> number of lines as the luma plane.
>>
>> That's not quite right, the chroma lines contain twice the number of
>> pixels and bytes, as there's one Cb and one Cr value in the chroma line
>> for each Y value in the luma line.
Actually, it is the same number o pixels, but twice the number o bytes.
Since a trio (YCbCr) compose a pixel.
At least this is how I understand comparing the logic of the text description
of NV16 YUV4:2:2.
Regards,
Helen
>>
>>
>> Maybe the text could be reflowed ?
>>
>
> Ack.
>
> I'll submit v2 updating the text.
>
> Thanks,
> Helen
>
[PATCH v2] media: doc: pixfmt-yuv: Fix 4:4:4 subsampling info
YUV 4:4:4 is not subsampled, fix this in the docs.
Fixes: da785536e007 ("media: doc: pixfmt-yuv: Move all semi-planar YUV formats
to common file")
Signed-off-by: Helen Koike
---
Changes in v2:
- s/No sub-sampling/The chroma plane is not subsampled/ (Laurent)
- Fixed description regarding the number of bytes (Laurent)
---
Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
index 7d4d39201a3f..1e0db602cc1b 100644
--- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
+++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst
@@ -396,9 +396,9 @@ number of lines as the luma plane.
NV24 and NV42
-
-Semi-planar YUV 4:4:4 formats. The chroma plane is subsampled by 2 in the
-horizontal direction. Chroma lines contain half the number of pixels and the
-same number of bytes as luma lines, and the chroma plane contains the same
+Semi-planar YUV 4:4:4 formats. The chroma plane is not subsampled.
+Chroma lines contain the same number of pixels and twice the
+number of bytes as luma lines, and the chroma plane contains the same
number of lines as the luma plane.
.. flat-table:: Sample 4x4 NV24 Image
--
2.30.0
Re: [PATCH 2/3] media: videodev2.h: clarify v4l2_pix_format_mplane.sizeimage docs when to set to zero
On 1/25/21 6:31 AM, Hans Verkuil wrote:
> On 14/01/2021 19:01, Helen Koike wrote:
>> sizeimage field should be set to zero for unused planes, even when
>> v4l2_pix_format_mplane.num_planes is smaller then the index of planes.
>
> then -> than
Ack.
>
>>
>> Signed-off-by: Helen Koike
>>
>> ---
>>
>> I caught this with v4l2-compliance, which throws an error if we dirty
>> planes, even if invalid, so I would like to make it clear in the docs.
>
> What is the error? And with which driver?
I was implementing conversions to/from Ext API, and I thought v4l2-compliance
wasn't happy if I didn't zero the other entries, but I'm trying to reproduce
it now by adding a non-zero value to sizeimage and I can't reproduce it, so
it was probably my mistake.
Please ignore this patch and sorry for the noise.
>
> I wonder if this isn't a v4l2-compliance bug. And if we want this to be
> zeroed, then it wouldn't it be better to do that in the V4L2 core rather
> than bother drivers with this?
>
>> ---
>> include/uapi/linux/videodev2.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 79dbde3bcf8d..d9b7c9177605 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -2227,6 +2227,7 @@ struct v4l2_mpeg_vbi_fmt_ivtv {
>> * struct v4l2_plane_pix_format - additional, per-plane format definition
>> * @sizeimage: maximum size in bytes required for data, for
>> which
>> * this plane will be used
>> + * Drivers should be set it zero for unused planes.
>
> This sentence is a bit garbled.
>
> You probably meant: Drivers must set this to zero for unused planes.
>
> But it makes no sense to just zero this field. I would zero the whole struct
> contents for the unused planes.
>
>> * @bytesperline: distance in bytes between the leftmost pixels in two
>> * adjacent lines
>> */
>>
>
> The API doesn't mention whether unused plane formats should be zeroed or not,
> but it does make sense that they are. I don't think that the userspace API
> should be changed (esp. since there are apparently already drivers that do
> not zero these unused plane formats), but it makes sense that the compliance
> test does verify this, and that the V4L2 core would zero unused plane formats.
>
> I never like it when undefined values are allowed in an API, so it makes sense
> that this is done.
Ack.
Thanks
Helen
>
> Regards,
>
> Hans
>
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Tomasz, On 12/14/20 7:46 AM, Tomasz Figa wrote: > On Fri, Dec 4, 2020 at 4:52 AM Helen Koike wrote: >> >> Hi, >> >> Please see my 2 points below (about v4l2_ext_buffer and another about >> timestamp). >> >> On 12/3/20 12:11 PM, Hans Verkuil wrote: >>> On 23/11/2020 18:40, Helen Koike wrote: >>>> >>>> >>>> On 11/23/20 12:46 PM, Tomasz Figa wrote: >>>>> On Tue, Nov 24, 2020 at 12:08 AM Helen Koike >>>>> wrote: >>>>>> >>>>>> Hi Hans, >>>>>> >>>>>> Thank you for your review. >>>>>> >>>>>> On 9/9/20 9:27 AM, Hans Verkuil wrote: >>>>>>> Hi Helen, >>>>>>> >>>>>>> Again I'm just reviewing the uAPI. >>>>>>> >>>>>>> On 04/08/2020 21:29, Helen Koike wrote: >>>>>>>> From: Hans Verkuil >>>>>>>> >>>>>>>> Those extended buffer ops have several purpose: >>>>>>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting >>>>>>>>the number of ns elapsed since 1970 >>>>>>>> 2/ Unify single/multiplanar handling >>>>>>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct >>>>>>>>to support the case where a single buffer object is storing all >>>>>>>>planes data, each one being placed at a different offset >>>>>>>> >>>>>>>> New hooks are created in v4l2_ioctl_ops so that drivers can start using >>>>>>>> these new objects. >>>>>>>> >>>>>>>> The core takes care of converting new ioctls requests to old ones >>>>>>>> if the driver does not support the new hooks, and vice versa. >>>>>>>> >>>>>>>> Note that the timecode field is gone, since there doesn't seem to be >>>>>>>> in-kernel users. We can be added back in the reserved area if needed or >>>>>>>> use the Request API to collect more metadata information from the >>>>>>>> frame. >>>>>>>> >>>>>>>> Signed-off-by: Hans Verkuil >>>>>>>> Signed-off-by: Boris Brezillon >>>>>>>> Signed-off-by: Helen Koike >>>>>>>> --- >>>>>>>> Changes in v5: >>>>>>>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane >>>>>>>> - return mem_offset to struct v4l2_ext_plane >>>>>>>> - change sizes and reorder fields to avoid holes in the struct and make >>>>>>>> it the same for 32 and 64 bits >>>>>>>> >>>>>>>> Changes in v4: >>>>>>>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format, >>>>>>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types. >>>>>>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF >>>>>>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at >>>>>>>> once. >>>>>>>> I think we can add this later, so I removed it from this RFC to >>>>>>>> simplify it. >>>>>>>> - Remove num_planes field from struct v4l2_ext_buffer >>>>>>>> - Add flags field to struct v4l2_ext_create_buffers >>>>>>>> - Reformulate struct v4l2_ext_plane >>>>>>>> - Fix some bugs caught by v4l2-compliance >>>>>>>> - Rebased on top of media/master (post 5.8-rc1) >>>>>>>> >>>>>>>> Changes in v3: >>>>>>>> - Rebased on top of media/master (post 5.4-rc1) >>>>>>>> >>>>>>>> Changes in v2: >>>>>>>> - Add reserved space to v4l2_ext_buffer so that new fields can be added >>>>>>>> later on >>>>>>>> --- >>>>>>>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++- >>>>>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +-- >>>>>>>> include/media/v4l2-ioctl.h | 26 ++ >>>>>>>> include/uapi/linux/videodev2.h | 90 +
Re: [PATCH v5 3/7] media: videobuf2: Expose helpers to implement the _ext_fmt and _ext_buf hooks
Hi Tomasz,
Thank you for your comments,
On 12/14/20 5:52 AM, Tomasz Figa wrote:
> Hi Helen,
>
> On Tue, Aug 04, 2020 at 04:29:35PM -0300, Helen Koike wrote:
>> The VB2 layer is used by a lot of drivers. Patch it to support the
>> _EXT_PIX_FMT and _EXT_BUF ioctls in order to ease conversion of existing
>> drivers to these new APIs.
>>
>> Note that internally, the VB2 core is now only using ext structs and old
>> APIs are supported through conversion wrappers.
>
> We decided to only support V4L2_BUF_TYPE_VIDEO* for the ext structs. Still,
> existing drivers may use vb2 with the other, legacy, buf types. How would
> they be handled with this change?
I completly refactored this patch in my wip branch, I'll submit for comments
soon after finishing addressing the other comments.
The way I'm approaching this is to support both structures v4l2_buffer and
v4l2_ext_buffer, but only in the vb2 entry points, since all the
information we need is in vb2_buffer struct.
To implement this I had to use new hooks in the framework. I think it is easier
if you take a look in next version when I submited it.
>
>>
>> Signed-off-by: Boris Brezillon
>> Signed-off-by: Helen Koike
>> ---
>> Changes in v5:
>> - Update with new format and buffer structs
>> - Updated commit message with the uAPI prefix
>>
>> Changes in v4:
>> - Update with new format and buffer structs
>> - Fix some bugs caught by v4l2-compliance
>> - Rebased on top of media/master (post 5.8-rc1)
>>
>> Changes in v3:
>> - Rebased on top of media/master (post 5.4-rc1)
>>
>> Changes in v2:
>> - New patch
>> ---
>> .../media/common/videobuf2/videobuf2-core.c | 2 +
>> .../media/common/videobuf2/videobuf2-v4l2.c | 560 ++
>> include/media/videobuf2-core.h| 6 +-
>> include/media/videobuf2-v4l2.h| 21 +-
>> 4 files changed, 345 insertions(+), 244 deletions(-)
>>
>> diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
>> b/drivers/media/common/videobuf2/videobuf2-core.c
>> index f544d3393e9d6..d719b1e9c148b 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-core.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-core.c
>> @@ -1270,6 +1270,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
>> vb->planes[plane].length = 0;
>> vb->planes[plane].m.fd = 0;
>> vb->planes[plane].data_offset = 0;
>> +vb->planes[plane].dbuf_offset = 0;
>>
>> /* Acquire each plane's memory */
>> mem_priv = call_ptr_memop(vb, attach_dmabuf,
>> @@ -1313,6 +1314,7 @@ static int __prepare_dmabuf(struct vb2_buffer *vb)
>> vb->planes[plane].length = planes[plane].length;
>> vb->planes[plane].m.fd = planes[plane].m.fd;
>> vb->planes[plane].data_offset = planes[plane].data_offset;
>> +vb->planes[plane].dbuf_offset = planes[plane].dbuf_offset;
>> }
>>
>> if (reacquired) {
>> diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> index 30caad27281e1..911681d24b3ae 100644
>> --- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> +++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -56,72 +57,39 @@ module_param(debug, int, 0644);
>> V4L2_BUF_FLAG_TIMECODE | \
>> V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF)
>>
>> -/*
>> - * __verify_planes_array() - verify that the planes array passed in struct
>> - * v4l2_buffer from userspace can be safely used
>> - */
>> -static int __verify_planes_array(struct vb2_buffer *vb, const struct
>> v4l2_buffer *b)
>> -{
>> -if (!V4L2_TYPE_IS_MULTIPLANAR(b->type))
>> -return 0;
>> -
>> -/* Is memory for copying plane information present? */
>> -if (b->m.planes == NULL) {
>> -dprintk(vb->vb2_queue, 1,
>> -"multi-planar buffer passed but planes array not
>> provided\n");
>> -return -EINVAL;
>> -}
>> -
>> -if (b->length < vb->num_planes || b->length > VB2_MAX_PLANES) {
>> -dprintk(vb->vb2_queue, 1,
>> -"incorrect planes array length, expected %d, got %d\n",
>> -
Re: [PATCH v5 2/7] media: v4l2: Add extended buffer operations
Hi Tomasz,
Thank you for your comments,
On 12/14/20 7:36 AM, Tomasz Figa wrote:
> On Tue, Nov 24, 2020 at 5:33 AM Helen Koike wrote:
>>
>> Hi Tomasz,
>>
>>
>> On 11/20/20 8:14 AM, Tomasz Figa wrote:
>>> Hi Helen,
>>>
>>> On Tue, Aug 04, 2020 at 04:29:34PM -0300, Helen Koike wrote:
>>>> From: Hans Verkuil
>>>>
>>>> Those extended buffer ops have several purpose:
>>>> 1/ Fix y2038 issues by converting the timestamp into an u64 counting
>>>>the number of ns elapsed since 1970
>>>> 2/ Unify single/multiplanar handling
>>>> 3/ Add a new start offset field to each v4l2 plane buffer info struct
>>>>to support the case where a single buffer object is storing all
>>>>planes data, each one being placed at a different offset
>>>>
>>>> New hooks are created in v4l2_ioctl_ops so that drivers can start using
>>>> these new objects.
>>>>
>>>> The core takes care of converting new ioctls requests to old ones
>>>> if the driver does not support the new hooks, and vice versa.
>>>>
>>>> Note that the timecode field is gone, since there doesn't seem to be
>>>> in-kernel users. We can be added back in the reserved area if needed or
>>>> use the Request API to collect more metadata information from the
>>>> frame.
>>>>
>>>
>>> Thanks for the patch. Please see my comments inline.
>>
>> Thank you for your detailed review, please see my comments below.
>>
>>>
>>>> Signed-off-by: Hans Verkuil
>>>> Signed-off-by: Boris Brezillon
>>>> Signed-off-by: Helen Koike
>>>> ---
>>>> Changes in v5:
>>>> - migrate memory from v4l2_ext_buffer to v4l2_ext_plane
>>>> - return mem_offset to struct v4l2_ext_plane
>>>> - change sizes and reorder fields to avoid holes in the struct and make
>>>> it the same for 32 and 64 bits
>>>>
>>>> Changes in v4:
>>>> - Use v4l2_ext_pix_format directly in the ioctl, drop v4l2_ext_format,
>>>> making V4L2_BUF_TYPE_VIDEO_[OUTPUT,CAPTURE] the only valid types.
>>>> - Drop VIDIOC_EXT_EXPBUF, since the only difference from VIDIOC_EXPBUF
>>>> was that with VIDIOC_EXT_EXPBUF we could export multiple planes at once.
>>>> I think we can add this later, so I removed it from this RFC to simplify
>>>> it.
>>>> - Remove num_planes field from struct v4l2_ext_buffer
>>>> - Add flags field to struct v4l2_ext_create_buffers
>>>> - Reformulate struct v4l2_ext_plane
>>>> - Fix some bugs caught by v4l2-compliance
>>>> - Rebased on top of media/master (post 5.8-rc1)
>>>>
>>>> Changes in v3:
>>>> - Rebased on top of media/master (post 5.4-rc1)
>>>>
>>>> Changes in v2:
>>>> - Add reserved space to v4l2_ext_buffer so that new fields can be added
>>>> later on
>>>> ---
>>>> drivers/media/v4l2-core/v4l2-dev.c | 29 ++-
>>>> drivers/media/v4l2-core/v4l2-ioctl.c | 353 +--
>>>> include/media/v4l2-ioctl.h | 26 ++
>>>> include/uapi/linux/videodev2.h | 90 +++
>>>> 4 files changed, 476 insertions(+), 22 deletions(-)
>>>>
>>>> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
>>>> b/drivers/media/v4l2-core/v4l2-dev.c
>>>> index e1829906bc086..cb21ee8eb075c 100644
>>>> --- a/drivers/media/v4l2-core/v4l2-dev.c
>>>> +++ b/drivers/media/v4l2-core/v4l2-dev.c
>>>> @@ -720,15 +720,34 @@ static void determine_valid_ioctls(struct
>>>> video_device *vdev)
>>>> SET_VALID_IOCTL(ops, VIDIOC_TRY_FMT, vidioc_try_fmt_sdr_out);
>>>> }
>>>>
>>>> +if (is_vid || is_tch) {
>>>> +/* ioctls valid for video and touch */
>>>> +if (ops->vidioc_querybuf || ops->vidioc_ext_querybuf)
>>>> +set_bit(_IOC_NR(VIDIOC_EXT_QUERYBUF), valid_ioctls);
>>>> +if (ops->vidioc_qbuf || ops->vidioc_ext_qbuf)
>>>> +set_bit(_IOC_NR(VIDIOC_EXT_QBUF), valid_ioctls);
>>>> +if (ops->vidioc_dqbuf || ops->vidioc_ext_dqbuf)
>>>> +set_bit(_IOC_NR(VIDIOC_EXT_DQBUF), valid_ioctls);
>>>> +if (ops->vidioc_create_bufs || ops->vidioc_ext_create_bufs)
>>>
Re: [PATCH v5 0/7] media: v4l2: Add extended fmt and buffer ioctls
Hello, On 8/4/20 4:29 PM, Helen Koike wrote: > Hello, > > This is v5 of the Extended API for formats and buffers, which introduces > the following new ioctls: > > int ioctl(int fd, VIDIOC_G_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp) > int ioctl(int fd, VIDIOC_S_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp) > int ioctl(int fd, VIDIOC_TRY_EXT_PIX_FMT, struct v4l2_ext_pix_format *argp) > > int ioctl(int fd, VIDIOC_EXT_CREATE_BUFS, struct v4l2_ext_create_buffers > *argp) > int ioctl(int fd, VIDIOC_EXT_QUERYBUF, struct v4l2_ext_buffer *argp) > int ioctl(int fd, VIDIOC_EXT_QBUF, struct v4l2_ext_buffer *argp) > int ioctl(int fd, VIDIOC_EXT_DQBUF, struct v4l2_ext_buffer *argp) > int ioctl(int fd, VIDIOC_EXT_PREPARE_BUF, struct v4l2_ext_buffer *argp) > > Please check v4 cover letter specific topic past discussions > https://patchwork.linuxtv.org/project/linux-media/cover/20200717115435.2632623-1-helen.ko...@collabora.com/ > > Documentation > = > I added a first version of the documentation. > I would appreciate some tips in how to organize this better, since there are > several parts of the docs which reference the "old" API, and for now > I just added a note pointing to the Extended API. > > Instead of duplicating documentation from the code to the Docs (as used by > most part of v4l2 documentation), I just added a reference to let Sphinx get > the structs documentation from the code, so we can avoid duplicating. > > For reviewing convenience, I uploaded the generated html docs at > https://people.collabora.com/~koike/ext-doc-v5/userspace-api/media/v4l/ext-api.html > > There is room for improvements, it would be great to get your suggestions. > > uAPI > > This version have some minor changes in the uAPI structs, highlight to the > mem_offset that was returned to struct v4l2_ext_plane, memory field that now > is per plane, and some adjustments in field sizes and re-ordering to make > structs the same for 32 and 64 bits (which I verified with pahole tool). > > I also updated v4l2-compliance: > https://gitlab.collabora.com/koike/v4l-utils/-/tree/ext-api/wip > > We need to decide the size of the reserved fields left, how much reserved > fields do you think we should leave for each struct? > > What is next > > I would like to improve implementation (for the kernel and v4l2-compliane) and > drop the RFC tag for next version, so please review the uAPI. > > > List of changes in v5: > == > * first version of Documentation > * migrate memory from v4l2_ext_buffer to v4l2_ext_plane > * return mem_offset to struct v4l2_ext_plane > * change sizes and reorder fields to avoid holes in the struct and make it > the same for 32 and 64 bits > * removed __attribute__ ((packed)) from uapi structs > * set request_fd to signed > * add documentation > * updated some commit messages > > Hans Verkuil (1): > media: v4l2: Add extended buffer operations > > Helen Koike (6): > media: v4l2: Extend pixel formats to unify single/multi-planar > handling (and more) > media: videobuf2: Expose helpers to implement the _ext_fmt and > _ext_buf hooks > media: mediabus: Add helpers to convert a ext_pix format to/from a > mbus_fmt > media: vivid: Convert the capture and output drivers to > EXT_FMT/EXT_BUF > media: vimc: Implement the ext_fmt and ext_buf hooks > media: docs: add documentation for the Extended API > > .../userspace-api/media/v4l/buffer.rst| 5 + > .../userspace-api/media/v4l/common.rst| 1 + > .../userspace-api/media/v4l/dev-capture.rst | 5 + > .../userspace-api/media/v4l/dev-output.rst| 5 + > .../userspace-api/media/v4l/ext-api.rst | 107 ++ > .../userspace-api/media/v4l/format.rst| 16 +- > .../userspace-api/media/v4l/user-func.rst | 5 + > .../media/v4l/vidioc-ext-create-bufs.rst | 95 ++ > .../media/v4l/vidioc-ext-prepare-buf.rst | 62 ++ > .../media/v4l/vidioc-ext-qbuf.rst | 204 > .../media/v4l/vidioc-ext-querybuf.rst | 79 ++ > .../media/v4l/vidioc-g-ext-pix-fmt.rst| 117 +++ > .../media/common/videobuf2/videobuf2-core.c | 2 + > .../media/common/videobuf2/videobuf2-v4l2.c | 560 ++- > .../media/test-drivers/vimc/vimc-capture.c| 61 +- > drivers/media/test-drivers/vimc/vimc-common.c | 6 +- > drivers/media/test-drivers/vimc/vimc-common.h | 2 +- > drivers/media/test-drivers/vivid/vivid-core.c | 70 +- > .../test-drivers/vivid/vivid-touch-cap.c | 26 +- > .../test-drivers/vivid/vivid-touch-cap.h | 3 +- > .../media/test-drivers/vivid/vivid-vid-cap.c | 169 +--- > .../media/test-
Re: [PATCH v2] char: tpm: add i2c driver for cr50
Hello Adrian, I just spotted small things (nothing major), please see below. On 11/20/20 2:23 PM, Adrian Ratiu wrote: > From: "dlau...@chromium.org" > > Add TPM 2.0 compatible I2C interface for chips with cr50 firmware. > > The firmware running on the currently supported H1 MCU requires a > special driver to handle its specific protocol, and this makes it > unsuitable to use tpm_tis_core_* and instead it must implement the > underlying TPM protocol similar to the other I2C TPM drivers. > > - All 4 byes of status register must be read/written at once. s/byes/bytes > - FIFO and burst count is limited to 63 and must be drained by AP. > - Provides an interrupt to indicate when read response data is ready > and when the TPM is finished processing write data. > > This driver is based on the existing infineon I2C TPM driver, which > most closely matches the cr50 i2c protocol behavior. > > Cc: Helen Koike > Signed-off-by: Duncan Laurie > [swb...@chromium.org: Depend on i2c even if it's a module, replace > boilier plate with SPDX tag, drop asm/byteorder.h include, simplify > return from probe] > Signed-off-by: Stephen Boyd > Signed-off-by: Fabien Lahoudere > Signed-off-by: Adrian Ratiu > --- > Changes in v2: > - Various small fixes all over (reorder includes, MAX_BUFSIZE, comments, > etc) > - Reworked return values of i2c_wait_tpm_ready() to fix timeout mis-handling > so ret == 0 now means success, the wait period jiffies is ignored because that > number is meaningless and return a proper timeout error in case jiffies == 0. > - Make i2c default to 1 message per transfer (requested by Helen) > - Move -EIO error reporting to transfer function to cleanup transfer() > itself > and its R/W callers > - Remove magic value hardcodings and introduce enum force_release. > > v1 posted at https://lkml.org/lkml/2020/2/25/349 > > Applies on next-20201120, tested on Chromebook EVE. > --- > drivers/char/tpm/Kconfig| 10 + > drivers/char/tpm/Makefile | 2 + > drivers/char/tpm/tpm_tis_i2c_cr50.c | 768 > 3 files changed, 780 insertions(+) > create mode 100644 drivers/char/tpm/tpm_tis_i2c_cr50.c > > diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig > index a18c314da211..4308f9ca7a43 100644 > --- a/drivers/char/tpm/Kconfig > +++ b/drivers/char/tpm/Kconfig > @@ -86,6 +86,16 @@ config TCG_TIS_SYNQUACER > To compile this driver as a module, choose M here; > the module will be called tpm_tis_synquacer. > > +config TCG_TIS_I2C_CR50 > + tristate "TPM Interface Specification 2.0 Interface (I2C - CR50)" > + depends on I2C > + select TCG_CR50 > + help > + This is a driver for the Google cr50 I2C TPM interface which is a > + custom microcontroller and requires a custom i2c protocol interface > + to handle the limitations of the hardware. To compile this driver > + as a module, choose M here; the module will be called > tcg_tis_i2c_cr50. > + > config TCG_TIS_I2C_ATMEL > tristate "TPM Interface Specification 1.2 Interface (I2C - Atmel)" > depends on I2C > diff --git a/drivers/char/tpm/Makefile b/drivers/char/tpm/Makefile > index 84db4fb3a9c9..66d39ea6bd10 100644 > --- a/drivers/char/tpm/Makefile > +++ b/drivers/char/tpm/Makefile > @@ -27,6 +27,8 @@ obj-$(CONFIG_TCG_TIS_SPI) += tpm_tis_spi.o > tpm_tis_spi-y := tpm_tis_spi_main.o > tpm_tis_spi-$(CONFIG_TCG_TIS_SPI_CR50) += tpm_tis_spi_cr50.o > > +obj-$(CONFIG_TCG_TIS_I2C_CR50) += tpm_tis_i2c_cr50.o > + > obj-$(CONFIG_TCG_TIS_I2C_ATMEL) += tpm_i2c_atmel.o > obj-$(CONFIG_TCG_TIS_I2C_INFINEON) += tpm_i2c_infineon.o > obj-$(CONFIG_TCG_TIS_I2C_NUVOTON) += tpm_i2c_nuvoton.o > diff --git a/drivers/char/tpm/tpm_tis_i2c_cr50.c > b/drivers/char/tpm/tpm_tis_i2c_cr50.c > new file mode 100644 > index ..37555dafdca0 > --- /dev/null > +++ b/drivers/char/tpm/tpm_tis_i2c_cr50.c > @@ -0,0 +1,768 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright 2016 Google Inc. > + * > + * Based on Linux Kernel TPM driver by > + * Peter Huewe > + * Copyright (C) 2011 Infineon Technologies > + */ > + > +/* > + * cr50 is a firmware for H1 secure modules that requires special > + * handling for the I2C interface. > + * > + * - Use an interrupt for transaction status instead of hardcoded delays > + * - Must use write+wait+read read protocol > + * - All 4 bytes of status register must be read/written at once > + * - Burst count max is 63 bytes, and burst count behaves > + * slightly differently than other I2C TPMs > + * - When reading from FIFO the full burstcnt must be
Re: [PATCH v8 04/14] media: rkisp1: add Rockchip MIPI Synopsys DPHY driver
Hi Laurent, Thanks for your review, I just have some comments/questions below. On 8/15/19 2:54 PM, Laurent Pinchart wrote: > Hi Helen, > > Thank you for the patch. > > On Wed, Aug 07, 2019 at 10:37:55AM -0300, Helen Koike wrote: >> On 8/7/19 10:05 AM, Sakari Ailus wrote: >>> On Tue, Jul 30, 2019 at 03:42:46PM -0300, Helen Koike wrote: >>>> From: Jacob Chen >>>> >>>> This commit adds a subdev driver for Rockchip MIPI Synopsys DPHY driver >>>> >>>> Signed-off-by: Jacob Chen >>>> Signed-off-by: Shunqian Zheng >>>> Signed-off-by: Tomasz Figa >>>> [migrate to phy framework] >>>> Signed-off-by: Ezequiel Garcia >>>> [update for upstream] >>>> Signed-off-by: Helen Koike >>>> >>>> --- >>>> >>>> Changes in v8: >>>> - Remove boiler plate license text >>>> >>>> Changes in v7: >>>> - Migrate dphy specific code from >>>> drivers/media/platform/rockchip/isp1/mipi_dphy_sy.c >>>> to drivers/phy/rockchip/phy-rockchip-dphy.c >>>> - Drop support for rk3288 >>>> - Drop support for dphy txrx >>>> - code styling and checkpatch fixes >>>> >>>> drivers/phy/rockchip/Kconfig | 8 + >>>> drivers/phy/rockchip/Makefile| 1 + >>>> drivers/phy/rockchip/phy-rockchip-dphy.c | 408 +++ >>>> 3 files changed, 417 insertions(+) >>>> create mode 100644 drivers/phy/rockchip/phy-rockchip-dphy.c >>>> >>>> diff --git a/drivers/phy/rockchip/Kconfig b/drivers/phy/rockchip/Kconfig >>>> index c454c90cd99e..afd072f135e6 100644 >>>> --- a/drivers/phy/rockchip/Kconfig >>>> +++ b/drivers/phy/rockchip/Kconfig >>>> @@ -9,6 +9,14 @@ config PHY_ROCKCHIP_DP >>>>help >>>> Enable this to support the Rockchip Display Port PHY. >>>> >>>> +config PHY_ROCKCHIP_DPHY >>>> + tristate "Rockchip MIPI Synopsys DPHY driver" > > How much of this PHY is Rockchip-specific ? Would it make sense to turn > it into a Synopsys DPHY driver, with some Rockchip glue ? I suppose this > could always be done later, if needed (and I also suppose there's no > existing driver in drivers/phy/ that support the same Synopsys IP). > >>>> + depends on ARCH_ROCKCHIP && OF >>> >>> How about (...) || COMPILE_TEST ? >>> >>>> + select GENERIC_PHY_MIPI_DPHY >>>> + select GENERIC_PHY >>>> + help >>>> +Enable this to support the Rockchip MIPI Synopsys DPHY. >>>> + >>>> config PHY_ROCKCHIP_EMMC >>>>tristate "Rockchip EMMC PHY Driver" >>>>depends on ARCH_ROCKCHIP && OF >>>> diff --git a/drivers/phy/rockchip/Makefile b/drivers/phy/rockchip/Makefile >>>> index fd21cbaf40dd..f62e9010bcaf 100644 >>>> --- a/drivers/phy/rockchip/Makefile >>>> +++ b/drivers/phy/rockchip/Makefile >>>> @@ -1,5 +1,6 @@ >>>> # SPDX-License-Identifier: GPL-2.0 >>>> obj-$(CONFIG_PHY_ROCKCHIP_DP) += phy-rockchip-dp.o >>>> +obj-$(CONFIG_PHY_ROCKCHIP_DPHY) += phy-rockchip-dphy.o >>>> obj-$(CONFIG_PHY_ROCKCHIP_EMMC) += phy-rockchip-emmc.o >>>> obj-$(CONFIG_PHY_ROCKCHIP_INNO_HDMI) += phy-rockchip-inno-hdmi.o >>>> obj-$(CONFIG_PHY_ROCKCHIP_INNO_USB2) += phy-rockchip-inno-usb2.o >>>> diff --git a/drivers/phy/rockchip/phy-rockchip-dphy.c >>>> b/drivers/phy/rockchip/phy-rockchip-dphy.c >>>> new file mode 100644 >>>> index ..3a29976c2dff >>>> --- /dev/null >>>> +++ b/drivers/phy/rockchip/phy-rockchip-dphy.c >>>> @@ -0,0 +1,408 @@ >>>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >>>> +/* >>>> + * Rockchip MIPI Synopsys DPHY driver >>>> + * >>>> + * Based on: >>>> + * >>>> + * Copyright (C) 2016 FuZhou Rockchip Co., Ltd. >>>> + * Author: Yakir Yang >>>> + */ >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +#define RK3399_GRF_SOC_CON9 0x6224 >>>> +#define RK3399_GRF_SOC
Re: [PATCH v8 05/14] media: rkisp1: add Rockchip ISP1 subdev driver
Hi Sakari, Thanks for your review. I just have some comments/questions below. On 8/8/19 6:14 AM, Sakari Ailus wrote: > Hi Helen, > > On Tue, Jul 30, 2019 at 03:42:47PM -0300, Helen Koike wrote: >> From: Jacob Chen >> >> Add the subdev driver for rockchip isp1. >> >> Signed-off-by: Jacob Chen >> Signed-off-by: Shunqian Zheng >> Signed-off-by: Yichong Zhong >> Signed-off-by: Jacob Chen >> Signed-off-by: Eddie Cai >> Signed-off-by: Jeffy Chen >> Signed-off-by: Allon Huang >> Signed-off-by: Tomasz Figa >> [fixed unknown entity type / switched to PIXEL_RATE] >> Signed-off-by: Ezequiel Garcia >> [update for upstream] >> Signed-off-by: Helen Koike >> >> --- >> >> Changes in v8: None >> Changes in v7: >> - fixed warning because of unknown entity type >> - fixed v4l2-compliance errors regarding rkisp1 formats, try formats >> and default values >> - fix typo riksp1/rkisp1 >> - redesign: remove mipi/csi subdevice, sensors connect directly to the >> isp subdevice in the media topology now. As a consequence, remove the >> hack in mipidphy_g_mbus_config() where information from the sensor was >> being propagated through the topology. >> - From the old dphy: >> * cache get_remote_sensor() in s_stream >> * use V4L2_CID_PIXEL_RATE instead of V4L2_CID_LINK_FREQ >> - Replace stream state with a boolean >> - code styling and checkpatch fixes >> - fix stop_stream (return after calling stop, do not reenable the stream) >> - fix rkisp1_isp_sd_get_selection when V4L2_SUBDEV_FORMAT_TRY is set >> - fix get format in output (isp_sd->out_fmt.mbus_code was being ignored) >> - s/intput/input >> - remove #define sd_to_isp_sd(_sd), add a static inline as it will be >> reused by the capture >> >> drivers/media/platform/rockchip/isp1/rkisp1.c | 1286 + >> drivers/media/platform/rockchip/isp1/rkisp1.h | 111 ++ >> 2 files changed, 1397 insertions(+) >> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.c >> create mode 100644 drivers/media/platform/rockchip/isp1/rkisp1.h >> >> diff --git a/drivers/media/platform/rockchip/isp1/rkisp1.c >> b/drivers/media/platform/rockchip/isp1/rkisp1.c >> new file mode 100644 >> index ..6d0c0ffb5e03 >> --- /dev/null >> +++ b/drivers/media/platform/rockchip/isp1/rkisp1.c >> @@ -0,0 +1,1286 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >> +/* >> + * Rockchip isp1 driver >> + * >> + * Copyright (C) 2017 Rockchip Electronics Co., Ltd. >> + */ >> + >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> +#include >> + >> +#include "common.h" >> +#include "regs.h" >> + >> +#define CIF_ISP_INPUT_W_MAX 4032 >> +#define CIF_ISP_INPUT_H_MAX 3024 >> +#define CIF_ISP_INPUT_W_MIN 32 >> +#define CIF_ISP_INPUT_H_MIN 32 >> +#define CIF_ISP_OUTPUT_W_MAXCIF_ISP_INPUT_W_MAX >> +#define CIF_ISP_OUTPUT_H_MAXCIF_ISP_INPUT_H_MAX >> +#define CIF_ISP_OUTPUT_W_MINCIF_ISP_INPUT_W_MIN >> +#define CIF_ISP_OUTPUT_H_MINCIF_ISP_INPUT_H_MIN >> + >> +/* >> + * NOTE: MIPI controller and input MUX are also configured in this file, >> + * because ISP Subdev is not only describe ISP submodule(input size,format, >> + * output size, format), but also a virtual route device. >> + */ >> + >> +/* >> + * There are many variables named with format/frame in below code, >> + * please see here for their meaning. >> + * >> + * Cropping regions of ISP >> + * >> + * +-+ >> + * | Sensor image| >> + * | +---+ | >> + * | | ISP_ACQ (for black level) | | >> + * | | in_frm| | >> + * | | ++| | >> + * | | |ISP_OUT || | >> + * | | |in_crop || | >> + * | | |+-+ || | >> + * | | || ISP_IS| || | >> + * | | || rkisp1_isp_subdev: out_crop | || | >> + * | | |+-+ || | >> + * | | +
Re: [PATCH v2 0/2] Collapse vimc into single monolithic driver
Hi Shuah,
Thanks for the patches.
On 8/15/19 4:42 PM, Shuah Khan wrote:
> vimc uses Component API to split the driver into functional components.
> The real hardware resembles a monolith structure than component and
> component structure added a level of complexity making it hard to
> maintain without adding any real benefit.
>
> The sensor is one vimc component that would makes sense to be a separate
> module to closely align with the real hardware. It would be easier to
> collapse vimc into single monolithic driver first and then split the
> sensor off as a separate module.
>
> This patch series removes the component API and makes minimal changes to
> the code base preserving the functional division of the code structure.
> Preserving the functional structure allows us to split the sensor off
> as a separate module in the future.
>
> Major design elements in this change are:
> - Use existing struct vimc_ent_config and struct vimc_pipeline_config
> to drive the initialization of the functional components.
> - Make vimc_device and vimc_ent_config global by moving them to
> vimc-common.h
> - Add two new hooks add and rm to initialize and register, unregister
> and free subdevs.
> - All component API is now gone and bind and unbind hooks are modified
> to do "add" and "rm" with minimal changes to just add and rm subdevs.
> - vimc-core's bind and unbind are now register and unregister.
> - vimc-core invokes "add" hooks from its vimc_register_devices().
> The "add" hooks remain the same and register subdevs. They don't
> create platform devices of their own and use vimc's pdev.dev as
> their reference device. The "add" hooks save their vimc_ent_device(s)
> in the corresponding vimc_ent_config.
> - vimc-core invokes "rm" hooks from its unregister to unregister
> subdevs and cleanup.
> - vimc-core invokes "add" and "rm" hooks with pointer to struct
> vimc_device and the corresponding struct vimc_ent_config pointer.
>
> The following configure and stream test works on all devices.
>
> media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
> media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
> media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
> media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
>
> v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
> v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
> v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
>
> v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1
> v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2
> v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3
>
> The second patch in the series fixes a general protection fault found
> when rmmod is done while stream is active.
>
> - rmmod while streaming returns vimc is in use
> - rmmod without active stream works correctly
>
> Changes since v1:
> Patch 1 & 2: (patch 1 in this series)
> - Collapsed the two patches into one
> - Added common defines (vimc_device and vimc_ent_config) to vimc-common.h
> based on our discussion.
> - Addressed review comments from Helen and Laurent
> - Use vimc-common.h instead of creating a new file.
> - Other minor comments from Helen on int vs. unsigned int and
> not needing to initialize ret in vimc_add_subdevs()
> Patch 3 (patch 2 in this series):
> - The second patch is the fix for gpf. Updated the patch after looking
> at the test results from Andre and Helen. This problem is in a common
> code and impacts all subdevs. The fix addresses the core problem and
> fixes it. Fix removes pads release from v4l2_device_unregister_subdev()
> and pads are now released from the sd release handler with all other
> resources.
>
> Outstanding:
> - Update documentation with the correct topology.
> - There is one outstanding gpf remaining in the unbind path. I will
> fix that in a separate patch. This is an existing problem and will
> be easier to fix on top of this patch series.
>
> vimc_print_dot (--print-dot) topology after this change: (no change
> compared to media master)
> digraph board {
> rankdir=TB
> n0001 [label="{{} | Sensor A\n/dev/v4l-subdev0 | { 0}}",
> shape=Mrecord, style=filled, fillcolor=green]
> n0001:port0 -> n0005:port0 [style=bold]
> n0001:port0 -> n000b [style=bold]
> n0003 [label="{{} | Sensor B\n/dev/v4l-subdev1 | { 0}}",
> shape=Mrecord, style=filled, fillcolor=green]
> n0003:port0 -> n0008:port0 [style=bold]
> n0003:port0 -> n000f [style=bold]
> n0005 [label="{{ 0} | Debayer A\n/dev/v4l-subdev2 |
> { 1}}", shape=Mrecord, style=filled, fillcolor=green]
> n0005:port1 -> n0015:port0
> n0008 [label="{{ 0} | Debayer B\n/dev/v4l-subdev3 |
>
Re: [PATCH v2 1/2] media: vimc: Collapse component structure into a single monolithic driver
Hi Shuah, Thanks for the patch, just some small comments below. On 8/15/19 4:42 PM, Shuah Khan wrote: > vimc uses Component API to split the driver into functional components. > The real hardware resembles a monolith structure than component and > component structure added a level of complexity making it hard to > maintain without adding any real benefit. > > The sensor is one vimc component that would makes sense to be a separate > module to closely align with the real hardware. It would be easier to > collapse vimc into single monolithic driver first and then split the > sensor off as a separate module. > > Collapse it into a single monolithic driver removing the Component API. > This patch removes the component API and makes minimal changes to the > code base preserving the functional division of the code structure. > Preserving the functional structure allows us to split the sensor off > as a separate module in the future. > > Major design elements in this change are: > - Use existing struct vimc_ent_config and struct vimc_pipeline_config > to drive the initialization of the functional components. > - Make vimc_device and vimc_ent_config global by moving them to > vimc-common.h > - Add two new hooks add and rm to initialize and register, unregister > and free subdevs. > - All component API is now gone and bind and unbind hooks are modified > to do "add" and "rm" with minimal changes to just add and rm subdevs. > - vimc-core's bind and unbind are now register and unregister. > - vimc-core invokes "add" hooks from its vimc_register_devices(). > The "add" hooks remain the same and register subdevs. They don't > create platform devices of their own and use vimc's pdev.dev as > their reference device. The "add" hooks save their vimc_ent_device(s) > in the corresponding vimc_ent_config. > - vimc-core invokes "rm" hooks from its unregister to unregister subdevs > and cleanup. > - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device > and the corresponding struct vimc_ent_config pointer. > > The following configure and stream test works on all devices. > > media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' > > v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 > v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 > v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 > > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 > > Signed-off-by: Shuah Khan > --- > drivers/media/platform/vimc/Makefile | 7 +- > drivers/media/platform/vimc/vimc-capture.c | 75 ++--- > drivers/media/platform/vimc/vimc-common.h | 54 ++ > drivers/media/platform/vimc/vimc-core.c| 182 +++-- > drivers/media/platform/vimc/vimc-debayer.c | 68 ++-- > drivers/media/platform/vimc/vimc-scaler.c | 68 ++-- > drivers/media/platform/vimc/vimc-sensor.c | 69 ++-- > 7 files changed, 157 insertions(+), 366 deletions(-) > > diff --git a/drivers/media/platform/vimc/Makefile > b/drivers/media/platform/vimc/Makefile > index 96d06f030c31..a53b2b532e9f 100644 > --- a/drivers/media/platform/vimc/Makefile > +++ b/drivers/media/platform/vimc/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > -vimc-y := vimc-core.o vimc-common.o vimc-streamer.o > +vimc-y := vimc-core.o vimc-common.o vimc-streamer.o vimc-capture.o \ > + vimc-debayer.o vimc-scaler.o vimc-sensor.o > + > +obj-$(CONFIG_VIDEO_VIMC) += vimc.o > > -obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc-capture.o vimc-debayer.o \ > -vimc-scaler.o vimc-sensor.o > diff --git a/drivers/media/platform/vimc/vimc-capture.c > b/drivers/media/platform/vimc/vimc-capture.c > index 664855708fdf..0b5cd38fbeb9 100644 > --- a/drivers/media/platform/vimc/vimc-capture.c > +++ b/drivers/media/platform/vimc/vimc-capture.c > @@ -5,10 +5,6 @@ > * Copyright (C) 2015-2017 Helen Koike > */ > > -#include > -#include > -#include > -#include > #include > #include > #include > @@ -16,8 +12,6 @@ > #include "vimc-common.h" > #include "vimc-streamer.h" > > -#d
Re: [PATCH v4 5/5] MAINTAINERS: Add reviewer to vimc driver
On 9/6/19 11:42 PM, Shuah Khan wrote: > After practically re-writing the driver to collpase it into a monolith, > I am adding myself as a reviewer for vimc driver. Thank you! > > Signed-off-by: Shuah Khan Acked-by: Helen Koike > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7c62b45201d7..4529d257f8db 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17041,6 +17041,7 @@ F:include/media/videobuf2-* > > VIMC VIRTUAL MEDIA CONTROLLER DRIVER > M: Helen Koike > +R: Shuah Khan > L: linux-me...@vger.kernel.org > T: git git://linuxtv.org/media_tree.git > W: https://linuxtv.org >
Re: [PATCH v4 2/5] media: vimc: Fix gpf in rmmod path when stream is active
On 9/6/19 11:42 PM, Shuah Khan wrote:
> If vimc module is removed while streaming is in progress, sensor subdev
> unregister runs into general protection fault when it tries to unregister
> media entities. This is a common subdev problem related to releasing
> pads from v4l2_device_unregister_subdev() before calling unregister.
> Unregister references pads during unregistering subdev.
>
> The sd release handler is the right place for releasing all sd resources
> including pads. The release handlers currently release all resources
> except the pads.
>
> Fix v4l2_device_unregister_subdev() not release pads and release pads
> from the sd_int_op release handlers.
>
> kernel: [ 4136.715839] general protection fault: [#1] SMP PTI
> kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4
> kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18
> 09/24/2013
> kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60
> kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
> 55 48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03
> <48> 83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89
> kernel: [ 4136.715866] RSP: 0018:9b2248fe3cb0 EFLAGS: 00010246
> kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: 88c3eb37e9c0 RCX:
> 802a0018
> kernel: [ 4136.715873] RDX: 88c3e4f6a078 RSI: 88c3eb37e9c0 RDI:
> b0cf7f00
> kernel: [ 4136.715876] RBP: 9b2248fe3cb8 R08: 0102 R09:
> b0492b00
> kernel: [ 4136.715879] R10: 9b2248fe3c28 R11: 0001 R12:
> 0038
> kernel: [ 4136.715881] R13: c09a1628 R14: 88c3e4f6a028 R15:
> fff2
> kernel: [ 4136.715885] FS: 7f8389647740() GS:88c46550()
> knlGS:
> kernel: [ 4136.715888] CS: 0010 DS: ES: CR0: 80050033
> kernel: [ 4136.715891] CR2: 55d008f80fd8 CR3: 0001996ec005 CR4:
> 000606e0
> kernel: [ 4136.715894] Call Trace:
> kernel: [ 4136.715903] media_gobj_destroy+0x14/0x20
> kernel: [ 4136.715908] __media_device_unregister_entity+0xb3/0xe0
> kernel: [ 4136.715915] media_device_unregister_entity+0x30/0x40
> kernel: [ 4136.715920] v4l2_device_unregister_subdev+0xa8/0xe0
> kernel: [ 4136.715928] vimc_ent_sd_unregister+0x1e/0x30 [vimc]
> kernel: [ 4136.715933] vimc_sen_rm+0x16/0x20 [vimc]
> kernel: [ 4136.715938] vimc_remove+0x3e/0xa0 [vimc]
> kernel: [ 4136.715945] platform_drv_remove+0x25/0x50
> kernel: [ 4136.715951] device_release_driver_internal+0xe0/0x1b0
> kernel: [ 4136.715956] device_driver_detach+0x14/0x20
> kernel: [ 4136.715960] unbind_store+0xd1/0x130
> kernel: [ 4136.715965] drv_attr_store+0x27/0x40
> kernel: [ 4136.715971] sysfs_kf_write+0x48/0x60
> kernel: [ 4136.715976] kernfs_fop_write+0x128/0x1b0
> kernel: [ 4136.715982] __vfs_write+0x1b/0x40
> kernel: [ 4136.715987] vfs_write+0xc3/0x1d0
> kernel: [ 4136.715993] ksys_write+0xaa/0xe0
> kernel: [ 4136.715999] __x64_sys_write+0x1a/0x20
> kernel: [ 4136.716005] do_syscall_64+0x5a/0x130
> kernel: [ 4136.716010] entry_SYSCALL_64_after_hwframe+0x4
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> drivers/media/platform/vimc/vimc-common.c | 3 +--
> drivers/media/platform/vimc/vimc-debayer.c | 1 +
> drivers/media/platform/vimc/vimc-scaler.c | 1 +
> drivers/media/platform/vimc/vimc-sensor.c | 1 +
> 4 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index 7e1ae0b12f1e..a3120f4f7a90 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -375,7 +375,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
> {
> int ret;
>
> - /* Allocate the pads */
> + /* Allocate the pads. Should be released from the sd_int_op release */
> ved->pads = vimc_pads_init(num_pads, pads_flag);
> if (IS_ERR(ved->pads))
> return PTR_ERR(ved->pads);
> @@ -424,7 +424,6 @@ EXPORT_SYMBOL_GPL(vimc_ent_sd_register);
> void vimc_ent_sd_unregister(struct vimc_ent_device *ved, struct v4l2_subdev
> *sd)
> {
> media_entity_cleanup(ved->ent);
> - vimc_pads_cleanup(ved->pads);
> v4l2_device_unregister_subdev(sd);
> }
> EXPORT_SYMBOL_GPL(vimc_ent_sd_unregister);
> diff --git a/drivers/media/platform/vimc/vimc-debayer.c
> b/drivers/media/platform/vimc/vimc-debayer.c
> index 00850f2501ad..b38b55f51a24 100644
> --- a/drivers/media/platform/vimc/vimc-debayer.c
> +++ b/drivers/media/platform/vimc/vimc-debayer.c
>
Re: [PATCH v4 4/5] doc: media: vimc: Update module parameter usage information
On 9/6/19 11:42 PM, Shuah Khan wrote: > vimc driver is now a monolithic driver. Update the module parameter > usage information to reflect that. > > Signed-off-by: Shuah Khan Acked-by: Helen Koike > --- > Documentation/media/v4l-drivers/vimc.rst | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/media/v4l-drivers/vimc.rst > b/Documentation/media/v4l-drivers/vimc.rst > index 406417680db5..a582af0509ee 100644 > --- a/Documentation/media/v4l-drivers/vimc.rst > +++ b/Documentation/media/v4l-drivers/vimc.rst > @@ -76,22 +76,22 @@ vimc-capture: > * 1 Pad sink > * 1 Pad source > > -Module options > + > +Module options > --- > > -Vimc has a few module parameters to configure the driver. You should pass > -those arguments to each subdevice, not to the vimc module. For example:: > +Vimc has a few module parameters to configure the driver. > > -vimc_subdevice.param=value > +param=value > > -* ``vimc_scaler.sca_mult=`` > +* ``sca_mult=`` > > Image size multiplier factor to be used to multiply both width and > height, so the image size will be ``sca_mult^2`` bigger than the > original one. Currently, only supports scaling up (the default value > is 3). > > -* ``vimc_debayer.deb_mean_win_size=`` > +* ``deb_mean_win_size=`` > > Window size to calculate the mean. Note: the window size needs to be > an > odd number, as the main pixel stays in the center of the window, >
Re: [PATCH v4 1/5] media: vimc: Collapse component structure into a single monolithic driver
Hi Shuah, Thanks for the patch. On 9/6/19 11:42 PM, Shuah Khan wrote: > vimc uses Component API to split the driver into functional components. > The real hardware resembles a monolith structure than component and > component structure added a level of complexity making it hard to > maintain without adding any real benefit. > > The sensor is one vimc component that would makes sense to be a separate > module to closely align with the real hardware. It would be easier to > collapse vimc into single monolithic driver first and then split the > sensor off as a separate module. > > Collapse it into a single monolithic driver removing the Component API. > This patch removes the component API and makes minimal changes to the > code base preserving the functional division of the code structure. > Preserving the functional structure allows us to split the sensor off > as a separate module in the future. > > Major design elements in this change are: > - Use existing struct vimc_ent_config and struct vimc_pipeline_config > to drive the initialization of the functional components. > - Make vimc_device and vimc_ent_config global by moving them to > vimc-common.h > - Add two new hooks add and rm to initialize and register, unregister > and free subdevs. > - All component API is now gone and bind and unbind hooks are modified > to do "add" and "rm" with minimal changes to just add and rm subdevs. > - vimc-core's bind and unbind are now register and unregister. > - Add a new field to vimc_device structure for saving the pointers to > struct vimc_ent_device(s) subdevs create in their "add" hooks. These > get used to create links and removing the subdevs. vimc-core allocates > this array which sized to number of entries in the topology defined in > the vimc_pipeline_config structure. > - vimc-core invokes "add" hooks from its vimc_register_devices(). > The "add" hooks remain the same and register subdevs. They don't > create platform devices of their own and use vimc's pdev.dev as > their reference device. Each "add" hook returns pointer to its struct > vimc_ent_device. This is saved in the vimc_device ent_devs array. > - vimc-core invokes "rm" hooks from its unregister to unregister subdevs > and cleanup. > - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device > and the corresponding vimc_ent_device saved in the ent_devs. > > The following configure and stream test works on all devices. > > media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' > > v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 > v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 > v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 > > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 > > Signed-off-by: Shuah Khan > --- > drivers/media/platform/vimc/Makefile | 7 +- > drivers/media/platform/vimc/vimc-capture.c | 81 ++-- > drivers/media/platform/vimc/vimc-common.h | 54 ++ > drivers/media/platform/vimc/vimc-core.c| 216 + > drivers/media/platform/vimc/vimc-debayer.c | 69 ++- > drivers/media/platform/vimc/vimc-scaler.c | 73 ++- > drivers/media/platform/vimc/vimc-sensor.c | 73 ++- > 7 files changed, 193 insertions(+), 380 deletions(-) > > diff --git a/drivers/media/platform/vimc/Makefile > b/drivers/media/platform/vimc/Makefile > index 96d06f030c31..a53b2b532e9f 100644 > --- a/drivers/media/platform/vimc/Makefile > +++ b/drivers/media/platform/vimc/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > -vimc-y := vimc-core.o vimc-common.o vimc-streamer.o > +vimc-y := vimc-core.o vimc-common.o vimc-streamer.o vimc-capture.o \ > + vimc-debayer.o vimc-scaler.o vimc-sensor.o > + > +obj-$(CONFIG_VIDEO_VIMC) += vimc.o > > -obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc-capture.o vimc-debayer.o \ > -vimc-scaler.o vimc-sensor.o > diff --git a/drivers/media/platform/vimc/vimc-capture.c > b/drivers/media/platform/vimc/vimc-capture.c > index 1d56b91830ba..602f80323031 100644 > --- a/drivers/media/platform/vimc/vimc-capture.c >
Re: [PATCH v4 3/5] vimc: move duplicated IS_SRC and IS_SINK to common header
Hi Shuah,
On 9/6/19 11:42 PM, Shuah Khan wrote:
> Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
> them to VIMC_IS_SRC and VIM_IS_SINK.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/media/platform/vimc/vimc-common.h | 4
> drivers/media/platform/vimc/vimc-debayer.c | 11 ---
> drivers/media/platform/vimc/vimc-scaler.c | 8 +++-
> 3 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.h
> b/drivers/media/platform/vimc/vimc-common.h
> index 87ee84f78322..236412ad7548 100644
> --- a/drivers/media/platform/vimc/vimc-common.h
> +++ b/drivers/media/platform/vimc/vimc-common.h
> @@ -27,6 +27,10 @@
>
> #define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp)
>
> +/* Source and sink pad checks */
> +#define VIMC_IS_SRC(pad) (pad)
> +#define VIMC_IS_SINK(pad)(!(pad))
This is true now, but it might not be true in the future.
In the output video device (that was sent by André but not yet upstream) for
instance, only have a single
source pad (which I suppose the index will be 0), and this macro won't be true.
Maybe we could check pad flags in sd->entity->pads[index].flags ?
Thanks
Helen
> +
> /**
> * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
> *
> diff --git a/drivers/media/platform/vimc/vimc-debayer.c
> b/drivers/media/platform/vimc/vimc-debayer.c
> index b38b55f51a24..37f3767db469 100644
> --- a/drivers/media/platform/vimc/vimc-debayer.c
> +++ b/drivers/media/platform/vimc/vimc-debayer.c
> @@ -22,9 +22,6 @@ MODULE_PARM_DESC(deb_mean_win_size, " the window size to
> calculate the mean.\n"
> "stays in the center of the window, otherwise the next odd number "
> "is considered");
>
> -#define IS_SINK(pad) (!pad)
> -#define IS_SRC(pad) (pad)
> -
> enum vimc_deb_rgb_colors {
> VIMC_DEB_RED = 0,
> VIMC_DEB_GREEN = 1,
> @@ -157,7 +154,7 @@ static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
> struct v4l2_subdev_mbus_code_enum *code)
> {
> /* We only support one format for source pads */
> - if (IS_SRC(code->pad)) {
> + if (VIMC_IS_SRC(code->pad)) {
> struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
>
> if (code->index)
> @@ -183,7 +180,7 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev
> *sd,
> if (fse->index)
> return -EINVAL;
>
> - if (IS_SINK(fse->pad)) {
> + if (VIMC_IS_SINK(fse->pad)) {
> const struct vimc_deb_pix_map *vpix =
> vimc_deb_pix_map_by_code(fse->code);
>
> @@ -213,7 +210,7 @@ static int vimc_deb_get_fmt(struct v4l2_subdev *sd,
> vdeb->sink_fmt;
>
> /* Set the right code for the source pad */
> - if (IS_SRC(fmt->pad))
> + if (VIMC_IS_SRC(fmt->pad))
> fmt->format.code = vdeb->src_code;
>
> return 0;
> @@ -260,7 +257,7 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
>* Do not change the format of the source pad,
>* it is propagated from the sink
>*/
> - if (IS_SRC(fmt->pad)) {
> + if (VIMC_IS_SRC(fmt->pad)) {
> fmt->format = *sink_fmt;
> /* TODO: Add support for other formats */
> fmt->format.code = vdeb->src_code;
> diff --git a/drivers/media/platform/vimc/vimc-scaler.c
> b/drivers/media/platform/vimc/vimc-scaler.c
> index 05db5070e268..a5a0855ad9cd 100644
> --- a/drivers/media/platform/vimc/vimc-scaler.c
> +++ b/drivers/media/platform/vimc/vimc-scaler.c
> @@ -16,8 +16,6 @@ static unsigned int sca_mult = 3;
> module_param(sca_mult, uint, );
> MODULE_PARM_DESC(sca_mult, " the image size multiplier");
>
> -#define IS_SINK(pad) (!pad)
> -#define IS_SRC(pad) (pad)
> #define MAX_ZOOM 8
>
> struct vimc_sca_device {
> @@ -93,7 +91,7 @@ static int vimc_sca_enum_frame_size(struct v4l2_subdev *sd,
> fse->min_width = VIMC_FRAME_MIN_WIDTH;
> fse->min_height = VIMC_FRAME_MIN_HEIGHT;
>
> - if (IS_SINK(fse->pad)) {
> + if (VIMC_IS_SINK(fse->pad)) {
> fse->max_width = VIMC_FRAME_MAX_WIDTH;
> fse->max_height = VIMC_FRAME_MAX_HEIGHT;
> } else {
> @@ -116,7 +114,7 @@ static int vimc_sca_get_fmt(struct v4l2_subdev *sd,
>vsca->sink_fmt;
>
> /* Scale the frame size for the source pad */
> - if (IS_SRC(format->pad)) {
> + if (VIMC_IS_SRC(format->pad)) {
> format->format.width = vsca->sink_fmt.width * sca_mult;
> format->format.height = vsca->sink_fmt.height * sca_mult;
> }
> @@ -165,7 +163,7 @@ static int vimc_sca_set_fmt(struct v4l2_subdev *sd,
>* Do not change the format of the source pad,
>* it is propagated from the sink
>*/
> - if (IS_SRC(fmt->pad)) {
> + if (VIMC_IS_SRC(fmt->pad)) {
> fmt->format = *sink_fmt;
> fmt->format.width = s
Re: [PATCH v4 3/5] vimc: move duplicated IS_SRC and IS_SINK to common header
On 9/15/19 8:52 PM, Shuah Khan wrote: > On 9/15/19 1:25 PM, Helen Koike wrote: >> Hi Shuah, >> >> On 9/6/19 11:42 PM, Shuah Khan wrote: >>> Move duplicated IS_SRC and IS_SINK dfines to common header. Rename >>> them to VIMC_IS_SRC and VIM_IS_SINK. >>> >>> Signed-off-by: Shuah Khan >>> --- >>> drivers/media/platform/vimc/vimc-common.h | 4 >>> drivers/media/platform/vimc/vimc-debayer.c | 11 --- >>> drivers/media/platform/vimc/vimc-scaler.c | 8 +++- >>> 3 files changed, 11 insertions(+), 12 deletions(-) >>> >>> diff --git a/drivers/media/platform/vimc/vimc-common.h >>> b/drivers/media/platform/vimc/vimc-common.h >>> index 87ee84f78322..236412ad7548 100644 >>> --- a/drivers/media/platform/vimc/vimc-common.h >>> +++ b/drivers/media/platform/vimc/vimc-common.h >>> @@ -27,6 +27,10 @@ >>> #define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * >>> bpp) >>> +/* Source and sink pad checks */ >>> +#define VIMC_IS_SRC(pad) (pad) >>> +#define VIMC_IS_SINK(pad) (!(pad)) >> >> This is true now, but it might not be true in the future. >> In the output video device (that was sent by André but not yet upstream) for >> instance, only have a single >> source pad (which I suppose the index will be 0), and this macro won't be >> true. >> > >> Maybe we could check pad flags in sd->entity->pads[index].flags ? >> > > I think this change should be done in André's patch? Could be yes, making it generic since the start would be nice, but I don't mind updating this latter when needed. Then: Acked-by: Helen Koike > > thanks, > -- Shuah Thanks Helen
Re: media: vimc-debayer: lock problem
Hi Randy, On 9/14/19 11:16 PM, Randy Dunlap wrote: > Kernel is 5.3-rc8 on x86_64. > > Loading, unloading, and then loading the vimc-debayer module causes: > > > [ 793.542496] [ cut here ] > [ 793.542518] DEBUG_LOCKS_WARN_ON(lock->magic != lock) > [ 793.542536] WARNING: CPU: 3 PID: 2029 at ../kernel/locking/mutex.c:912 > __mutex_lock+0xd7c/0x1480 > [ 793.542559] Modules linked in: vimc_debayer(+) vimc_capture vimc_scaler > vimc_sensor v4l2_tpg vimc v4l2_common ccm xt_tcpudp ip6t_rpfilter ip6t_REJECT > nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 af_packet xt_conntrack ip_set > nfnetlink ebtable_nat ebtable_broute ip6table_nat ip6table_mangle > ip6table_raw ip6table_security iptable_nat scsi_transport_iscsi nf_nat > nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw > iptable_security ebtable_filter ebtables ip6table_filter ip6_tables > iptable_filter ip_tables x_tables bpfilter coretemp hwmon intel_rapl_msr > intel_rapl_common x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm > irqbypass crct10dif_pclmul crc32_generic crc32_pclmul ghash_clmulni_intel msr > ghash_generic gf128mul uvcvideo hid_generic btrfs videobuf2_vmalloc gcm > videobuf2_memops xor videobuf2_v4l2 iTCO_wdt zstd_compress videobuf2_common > videodev iTCO_vendor_support usbmouse usb_debug mei_hdcp usbserial xts > raid6_pq mc usbhid libcrc32c crc32c_intel hid > [ 793.542617] zstd_decompress iwldvm ctr snd_hda_codec_hdmi aesni_intel > mac80211 aes_x86_64 snd_hda_codec_realtek crypto_simd snd_hda_codec_generic > cryptd ledtrig_audio glue_helper libarc4 snd_hda_intel intel_cstate iwlwifi > snd_hda_codec intel_uncore intel_rapl_perf snd_hda_core joydev snd_hwdep > input_leds cfg80211 mousedev sdhci_pci toshiba_acpi cqhci sparse_keymap > sr_mod snd_pcm uio_pdrv_genirq sdhci uio snd_timer wmi serio_raw pcspkr > mmc_core cdrom rfkill led_class snd rtc_cmos mei_me industrialio evdev mei > thermal lpc_ich mac_hid soundcore toshiba_haps ac battery sg dm_multipath > dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua autofs4 [last unloaded: > vimc_debayer] > [ 793.542817] CPU: 3 PID: 2029 Comm: modprobe Not tainted 5.3.0-rc8 #3 > [ 793.542829] Hardware name: TOSHIBA PORTEGE R835/Portable PC, BIOS Version > 4.10 01/08/2013 > [ 793.542845] RIP: 0010:__mutex_lock+0xd7c/0x1480 > [ 793.542857] Code: d2 0f 85 35 05 00 00 44 8b 0d 50 7f b2 01 45 85 c9 0f 85 > b1 f3 ff ff 48 c7 c6 60 15 89 9c 48 c7 c7 00 14 89 9c e8 b4 86 eb fd <0f> 0b > e9 97 f3 ff ff 48 8b 85 88 fe ff ff 48 c1 e8 03 42 80 3c 28 > [ 793.542882] RSP: 0018:88812a5eefd0 EFLAGS: 00010282 > [ 793.542894] RAX: dc08 RBX: c1c0f7e0 RCX: > 9a2b67f4 > [ 793.542906] RDX: 13a3dfc5 RSI: 0004 RDI: > 0246 > [ 793.542919] RBP: 88812a5ef150 R08: fbfff3a3dfc5 R09: > fbfff3a3dfc5 > [ 793.542931] R10: 0001 R11: fbfff3a3dfc4 R12: > > [ 793.542944] R13: R14: dc00 R15: > 9e700400 > [ 793.542957] FS: 7f080c4a6b80() GS:88812aa0() > knlGS: > [ 793.542970] CS: 0010 DS: ES: CR0: 80050033 > [ 793.542981] CR2: 7ffeab8adee8 CR3: 00010fd66005 CR4: > 000606e0 > [ 793.542993] Call Trace: > [ 793.543007] ? do_raw_spin_unlock+0x54/0x220 > [ 793.543026] ? media_device_register_entity+0x1fd/0x710 [mc] > [ 793.543044] ? mutex_lock_io_nested+0x1380/0x1380 > [ 793.543055] ? ida_alloc_range+0x5b7/0x6e0 > [ 793.543068] ? ida_destroy+0x260/0x260 > [ 793.543080] ? save_stack+0x21/0x90 > [ 793.543090] ? __kasan_kmalloc.constprop.8+0xa7/0xd0 > [ 793.543101] ? kasan_kmalloc+0x9/0x10 > [ 793.543111] ? __kmalloc+0x11f/0x260 > [ 793.543123] ? vimc_pads_init+0x33/0x130 [vimc] > [ 793.543134] ? vimc_ent_sd_register+0x36/0x350 [vimc] > [ 793.543147] ? vimc_sen_comp_bind+0x280/0x520 [vimc_sensor] > [ 793.543160] ? component_bind_all+0x2ef/0xa60 > [ 793.543171] ? vimc_comp_bind+0x74/0x630 [vimc] > [ 793.543188] ? driver_probe_device+0xf0/0x3a0 > [ 793.543199] ? device_driver_attach+0xec/0x120 > [ 793.543212] mutex_lock_nested+0x16/0x20 > [ 793.543223] ? mutex_lock_nested+0x16/0x20 > [ 793.543236] media_device_register_entity+0x1fd/0x710 [mc] > [ 793.543249] ? __x64_sys_finit_module+0x6e/0xb0 > [ 793.543260] ? do_syscall_64+0xaa/0x380 > [ 793.543271] ? check_object+0xb2/0x300 > [ 793.543282] ? vimc_pads_init+0x33/0x130 [vimc] > [ 793.543296] ? media_device_unregister_entity_notify+0xf0/0xf0 [mc] > [ 793.543311] ? ___slab_alloc+0x5b3/0x600 > [ 793.543321] ? ___slab_alloc+0x5b3/0x600 > [ 793.543335] ? kasan_unpoison_shadow+0x35/0x50 > [ 793.543346] ? __kasan_kmalloc.constprop.8+0xa7/0xd0 > [ 793.543358] ? kasan_kmalloc+0x9/0x10 > [ 793.543377] v4l2_device_register_subdev+0x261/0x620 [videodev] > [ 793.543392] vimc_ent_sd_register+0x26b/0x350 [vimc] > [ 793.543406] vimc_sen_comp_bind+0x2
Re: [PATCH v5 1/5] media: vimc: Collapse component structure into a single monolithic driver
On 9/17/19 1:35 PM, Shuah Khan wrote: > vimc uses Component API to split the driver into functional components. > The real hardware resembles a monolith structure than component and > component structure added a level of complexity making it hard to > maintain without adding any real benefit. > > The sensor is one vimc component that would makes sense to be a separate > module to closely align with the real hardware. It would be easier to > collapse vimc into single monolithic driver first and then split the > sensor off as a separate module. > > Collapse it into a single monolithic driver removing the Component API. > This patch removes the component API and makes minimal changes to the > code base preserving the functional division of the code structure. > Preserving the functional structure allows us to split the sensor off > as a separate module in the future. > > Major design elements in this change are: > - Use existing struct vimc_ent_config and struct vimc_pipeline_config > to drive the initialization of the functional components. > - Make vimc_device and vimc_ent_config global by moving them to > vimc-common.h > - Add two new hooks add and rm to initialize and register, unregister > and free subdevs. > - All component API is now gone and bind and unbind hooks are modified > to do "add" and "rm" with minimal changes to just add and rm subdevs. > - vimc-core's bind and unbind are now register and unregister. > - Add a new field to vimc_device structure for saving the pointers to > struct vimc_ent_device(s) subdevs create in their "add" hooks. These > get used to create links and removing the subdevs. vimc-core allocates > this array which sized to number of entries in the topology defined in > the vimc_pipeline_config structure. > - vimc-core invokes "add" hooks from its vimc_register_devices(). > The "add" hooks remain the same and register subdevs. They don't > create platform devices of their own and use vimc's pdev.dev as > their reference device. Each "add" hook returns pointer to its struct > vimc_ent_device. This is saved in the vimc_device ent_devs array. > - vimc-core invokes "rm" hooks from its unregister to unregister subdevs > and cleanup. > - vimc-core invokes "add" and "rm" hooks with pointer to struct vimc_device > and the corresponding vimc_ent_device saved in the ent_devs. > > The following configure and stream test works on all devices. > > media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]' > media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]' > > v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440 > v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81 > v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81 > > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video1 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video2 > v4l2-ctl --stream-mmap --stream-count=100 -d /dev/video3 > > Signed-off-by: Shuah Khan Acked-by: Helen Koike > --- > drivers/media/platform/vimc/Makefile| 7 +- > drivers/media/platform/vimc/vimc-capture.c | 81 ++-- > drivers/media/platform/vimc/vimc-common.h | 54 + > drivers/media/platform/vimc/vimc-core.c | 216 > drivers/media/platform/vimc/vimc-debayer.c | 73 ++- > drivers/media/platform/vimc/vimc-scaler.c | 75 ++- > drivers/media/platform/vimc/vimc-sensor.c | 73 +-- > drivers/media/platform/vimc/vimc-streamer.c | 1 - > 8 files changed, 195 insertions(+), 385 deletions(-) > > diff --git a/drivers/media/platform/vimc/Makefile > b/drivers/media/platform/vimc/Makefile > index 96d06f030c31..a53b2b532e9f 100644 > --- a/drivers/media/platform/vimc/Makefile > +++ b/drivers/media/platform/vimc/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > -vimc-y := vimc-core.o vimc-common.o vimc-streamer.o > +vimc-y := vimc-core.o vimc-common.o vimc-streamer.o vimc-capture.o \ > + vimc-debayer.o vimc-scaler.o vimc-sensor.o > + > +obj-$(CONFIG_VIDEO_VIMC) += vimc.o > > -obj-$(CONFIG_VIDEO_VIMC) += vimc.o vimc-capture.o vimc-debayer.o \ > -vimc-scaler.o vimc-sensor.o > diff --git a/drivers/media/platform/vimc/vimc-capture.c > b/drivers/media/platform/vimc/vimc-capture.c > index 1d56b91830ba..602f80323031 100644 > --- a/dri
Re: [PATCH v5 2/5] media: vimc: Fix gpf in rmmod path when stream is active
On 9/17/19 1:35 PM, Shuah Khan wrote:
> If vimc module is removed while streaming is in progress, sensor subdev
> unregister runs into general protection fault when it tries to unregister
> media entities. This is a common subdev problem related to releasing
> pads from v4l2_device_unregister_subdev() before calling unregister.
> Unregister references pads during unregistering subdev.
>
> The sd release handler is the right place for releasing all sd resources
> including pads. The release handlers currently release all resources
> except the pads.
>
> Fix v4l2_device_unregister_subdev() not release pads and release pads
> from the sd_int_op release handlers.
>
> kernel: [ 4136.715839] general protection fault: [#1] SMP PTI
> kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4
> kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18
> 09/24/2013
> kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60
> kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90
> 55 48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03
> <48> 83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89
> kernel: [ 4136.715866] RSP: 0018:9b2248fe3cb0 EFLAGS: 00010246
> kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: 88c3eb37e9c0 RCX:
> 802a0018
> kernel: [ 4136.715873] RDX: 88c3e4f6a078 RSI: 88c3eb37e9c0 RDI:
> b0cf7f00
> kernel: [ 4136.715876] RBP: 9b2248fe3cb8 R08: 0102 R09:
> b0492b00
> kernel: [ 4136.715879] R10: 9b2248fe3c28 R11: 0001 R12:
> 0038
> kernel: [ 4136.715881] R13: c09a1628 R14: 88c3e4f6a028 R15:
> fff2
> kernel: [ 4136.715885] FS: 7f8389647740() GS:88c46550()
> knlGS:
> kernel: [ 4136.715888] CS: 0010 DS: ES: CR0: 80050033
> kernel: [ 4136.715891] CR2: 55d008f80fd8 CR3: 0001996ec005 CR4:
> 000606e0
> kernel: [ 4136.715894] Call Trace:
> kernel: [ 4136.715903] media_gobj_destroy+0x14/0x20
> kernel: [ 4136.715908] __media_device_unregister_entity+0xb3/0xe0
> kernel: [ 4136.715915] media_device_unregister_entity+0x30/0x40
> kernel: [ 4136.715920] v4l2_device_unregister_subdev+0xa8/0xe0
> kernel: [ 4136.715928] vimc_ent_sd_unregister+0x1e/0x30 [vimc]
> kernel: [ 4136.715933] vimc_sen_rm+0x16/0x20 [vimc]
> kernel: [ 4136.715938] vimc_remove+0x3e/0xa0 [vimc]
> kernel: [ 4136.715945] platform_drv_remove+0x25/0x50
> kernel: [ 4136.715951] device_release_driver_internal+0xe0/0x1b0
> kernel: [ 4136.715956] device_driver_detach+0x14/0x20
> kernel: [ 4136.715960] unbind_store+0xd1/0x130
> kernel: [ 4136.715965] drv_attr_store+0x27/0x40
> kernel: [ 4136.715971] sysfs_kf_write+0x48/0x60
> kernel: [ 4136.715976] kernfs_fop_write+0x128/0x1b0
> kernel: [ 4136.715982] __vfs_write+0x1b/0x40
> kernel: [ 4136.715987] vfs_write+0xc3/0x1d0
> kernel: [ 4136.715993] ksys_write+0xaa/0xe0
> kernel: [ 4136.715999] __x64_sys_write+0x1a/0x20
> kernel: [ 4136.716005] do_syscall_64+0x5a/0x130
> kernel: [ 4136.716010] entry_SYSCALL_64_after_hwframe+0x4
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> drivers/media/platform/vimc/vimc-common.c | 3 +--
> drivers/media/platform/vimc/vimc-debayer.c | 1 +
> drivers/media/platform/vimc/vimc-scaler.c | 1 +
> drivers/media/platform/vimc/vimc-sensor.c | 1 +
> 4 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index 7e1ae0b12f1e..a3120f4f7a90 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -375,7 +375,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
> {
> int ret;
>
> - /* Allocate the pads */
> + /* Allocate the pads. Should be released from the sd_int_op release */
> ved->pads = vimc_pads_init(num_pads, pads_flag);
> if (IS_ERR(ved->pads))
> return PTR_ERR(ved->pads);
> @@ -424,7 +424,6 @@ EXPORT_SYMBOL_GPL(vimc_ent_sd_register);
> void vimc_ent_sd_unregister(struct vimc_ent_device *ved, struct v4l2_subdev
> *sd)
> {
> media_entity_cleanup(ved->ent);
> - vimc_pads_cleanup(ved->pads);
> v4l2_device_unregister_subdev(sd);
> }
> EXPORT_SYMBOL_GPL(vimc_ent_sd_unregister);
> diff --git a/drivers/media/platform/vimc/vimc-debayer.c
> b/drivers/media/platform/vimc/vimc-debayer.c
> index 2c291447807e..4125159e8f31 100644
> --- a/drivers/media/platform/vimc/vimc-debayer.c
> +++ b/drivers/media/platform/vimc/vimc-debayer.c
>
Re: [PATCH v5 3/5] vimc: move duplicated IS_SRC and IS_SINK to common header
On 9/17/19 1:35 PM, Shuah Khan wrote:
> Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
> them to VIMC_IS_SRC and VIM_IS_SINK.
>
> Signed-off-by: Shuah Khan
Acked-by: Helen Koike
> ---
> drivers/media/platform/vimc/vimc-common.h | 4
> drivers/media/platform/vimc/vimc-debayer.c | 11 ---
> drivers/media/platform/vimc/vimc-scaler.c | 8 +++-
> 3 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.h
> b/drivers/media/platform/vimc/vimc-common.h
> index d7aaf31175bc..698db7c07645 100644
> --- a/drivers/media/platform/vimc/vimc-common.h
> +++ b/drivers/media/platform/vimc/vimc-common.h
> @@ -27,6 +27,10 @@
>
> #define VIMC_FRAME_INDEX(lin, col, width, bpp) ((lin * width + col) * bpp)
>
> +/* Source and sink pad checks */
> +#define VIMC_IS_SRC(pad) (pad)
> +#define VIMC_IS_SINK(pad)(!(pad))
> +
> /**
> * struct vimc_colorimetry_clamp - Adjust colorimetry parameters
> *
> diff --git a/drivers/media/platform/vimc/vimc-debayer.c
> b/drivers/media/platform/vimc/vimc-debayer.c
> index 4125159e8f31..feac47d79449 100644
> --- a/drivers/media/platform/vimc/vimc-debayer.c
> +++ b/drivers/media/platform/vimc/vimc-debayer.c
> @@ -20,9 +20,6 @@ MODULE_PARM_DESC(deb_mean_win_size, " the window size to
> calculate the mean.\n"
> "stays in the center of the window, otherwise the next odd number "
> "is considered");
>
> -#define IS_SINK(pad) (!pad)
> -#define IS_SRC(pad) (pad)
> -
> enum vimc_deb_rgb_colors {
> VIMC_DEB_RED = 0,
> VIMC_DEB_GREEN = 1,
> @@ -155,7 +152,7 @@ static int vimc_deb_enum_mbus_code(struct v4l2_subdev *sd,
> struct v4l2_subdev_mbus_code_enum *code)
> {
> /* We only support one format for source pads */
> - if (IS_SRC(code->pad)) {
> + if (VIMC_IS_SRC(code->pad)) {
> struct vimc_deb_device *vdeb = v4l2_get_subdevdata(sd);
>
> if (code->index)
> @@ -181,7 +178,7 @@ static int vimc_deb_enum_frame_size(struct v4l2_subdev
> *sd,
> if (fse->index)
> return -EINVAL;
>
> - if (IS_SINK(fse->pad)) {
> + if (VIMC_IS_SINK(fse->pad)) {
> const struct vimc_deb_pix_map *vpix =
> vimc_deb_pix_map_by_code(fse->code);
>
> @@ -211,7 +208,7 @@ static int vimc_deb_get_fmt(struct v4l2_subdev *sd,
> vdeb->sink_fmt;
>
> /* Set the right code for the source pad */
> - if (IS_SRC(fmt->pad))
> + if (VIMC_IS_SRC(fmt->pad))
> fmt->format.code = vdeb->src_code;
>
> return 0;
> @@ -258,7 +255,7 @@ static int vimc_deb_set_fmt(struct v4l2_subdev *sd,
>* Do not change the format of the source pad,
>* it is propagated from the sink
>*/
> - if (IS_SRC(fmt->pad)) {
> + if (VIMC_IS_SRC(fmt->pad)) {
> fmt->format = *sink_fmt;
> /* TODO: Add support for other formats */
> fmt->format.code = vdeb->src_code;
> diff --git a/drivers/media/platform/vimc/vimc-scaler.c
> b/drivers/media/platform/vimc/vimc-scaler.c
> index 1a593d81ea7c..a6a3cc5be872 100644
> --- a/drivers/media/platform/vimc/vimc-scaler.c
> +++ b/drivers/media/platform/vimc/vimc-scaler.c
> @@ -16,8 +16,6 @@ static unsigned int sca_mult = 3;
> module_param(sca_mult, uint, );
> MODULE_PARM_DESC(sca_mult, " the image size multiplier");
>
> -#define IS_SINK(pad) (!pad)
> -#define IS_SRC(pad) (pad)
> #define MAX_ZOOM 8
>
> struct vimc_sca_device {
> @@ -93,7 +91,7 @@ static int vimc_sca_enum_frame_size(struct v4l2_subdev *sd,
> fse->min_width = VIMC_FRAME_MIN_WIDTH;
> fse->min_height = VIMC_FRAME_MIN_HEIGHT;
>
> - if (IS_SINK(fse->pad)) {
> + if (VIMC_IS_SINK(fse->pad)) {
> fse->max_width = VIMC_FRAME_MAX_WIDTH;
> fse->max_height = VIMC_FRAME_MAX_HEIGHT;
> } else {
> @@ -116,7 +114,7 @@ static int vimc_sca_get_fmt(struct v4l2_subdev *sd,
>vsca->sink_fmt;
>
> /* Scale the frame size for the source pad */
> - if (IS_SRC(format->pad)) {
> + if (VIMC_IS_SRC(format->pad)) {
> format->format.width = vsca->sink_fmt.width * sca_mult;
> format->format.height = vsca->sink_fmt.height * sca_mult;
> }
> @@ -165,7 +163,7 @@ static int vimc_sca_set_fmt(struct v4l2_subdev *sd,
>* Do not change the format of the source pad,
>* it is propagated from the sink
>*/
> - if (IS_SRC(fmt->pad)) {
> + if (VIMC_IS_SRC(fmt->pad)) {
> fmt->format = *sink_fmt;
> fmt->format.width = sink_fmt->width * sca_mult;
> fmt->format.height = sink_fmt->height * sca_mult;
>
Re: [PATCH v5 4/5] doc: media: vimc: Update module parameter usage information
On 9/17/19 1:35 PM, Shuah Khan wrote: > vimc driver is now a monolithic driver. Update the module parameter > usage information to reflect that. > > Signed-off-by: Shuah Khan Acked-by: Helen Koike > --- > Documentation/media/v4l-drivers/vimc.rst | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/Documentation/media/v4l-drivers/vimc.rst > b/Documentation/media/v4l-drivers/vimc.rst > index 406417680db5..a582af0509ee 100644 > --- a/Documentation/media/v4l-drivers/vimc.rst > +++ b/Documentation/media/v4l-drivers/vimc.rst > @@ -76,22 +76,22 @@ vimc-capture: > * 1 Pad sink > * 1 Pad source > > -Module options > + > +Module options > --- > > -Vimc has a few module parameters to configure the driver. You should pass > -those arguments to each subdevice, not to the vimc module. For example:: > +Vimc has a few module parameters to configure the driver. > > -vimc_subdevice.param=value > +param=value > > -* ``vimc_scaler.sca_mult=`` > +* ``sca_mult=`` > > Image size multiplier factor to be used to multiply both width and > height, so the image size will be ``sca_mult^2`` bigger than the > original one. Currently, only supports scaling up (the default value > is 3). > > -* ``vimc_debayer.deb_mean_win_size=`` > +* ``deb_mean_win_size=`` > > Window size to calculate the mean. Note: the window size needs to be > an > odd number, as the main pixel stays in the center of the window, >
Re: [PATCH v5 5/5] MAINTAINERS: Add reviewer to vimc driver
On 9/17/19 1:35 PM, Shuah Khan wrote: > After practically re-writing the driver to collpase it into a monolith, > I am adding myself as a reviewer for vimc driver. > > Signed-off-by: Shuah Khan Acked-by: Helen Koike > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7c62b45201d7..4529d257f8db 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -17041,6 +17041,7 @@ F:include/media/videobuf2-* > > VIMC VIRTUAL MEDIA CONTROLLER DRIVER > M: Helen Koike > +R: Shuah Khan > L: linux-me...@vger.kernel.org > T: git git://linuxtv.org/media_tree.git > W: https://linuxtv.org > Thanks! Helen
