Re: Agenda for the Edinburgh mini-summit
On 08/30/2013 03:01 PM, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. I got another one: VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code. We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL. Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REGRESSION 3.11-rc1+] wm8775 9-001b: I2C: cannot write ??? to register R??
Hi Linus! It would be nice to have head cx88fix of git.linuxtv.org/hverkuil/media_tree.git (git.linuxtv.org/hverkuil/media_tree.git/commit/5dce3635bf803cfe9dde84e00f5f9594439e6c02) in 3.11 as it is a trivial and tested fix for a regression introduced between 3.10 and 3.11-rc1. see http://www.gossamer-threads.com/lists/linux/kernel/1771751?#1771751 cu, Knut -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: davinci vpif_capture
On Fri, Aug 30, 2013 at 10:09 PM, Darryl ddegr...@licor.com wrote:
I am working on an application involving the davinci using the vpif. My
board file has the inputs configured to use VPIF_IF_RAW_BAYER if_type.
When my application starts up, I have it enumerate the formats
(VIDIOC_ENUM_FMT) and it indicates that the only available format is
YCbCr4:2:2 YC Planar (from vpif_enum_fmt_vid_cap). It looks to me that
the culprit is vpif_open().
struct channel_obj.vpifparams.iface is initialized at vpif_probe() time in
the function vpif_set_input. Open the device file (/dev/video0) overwrites
this. I suspect that it is __not__ supposed to do this, since I don't see
any method for restoring the iface.
NAK, Ideally the application should go in the following manner,
you open the device say example /dev/video0 , then you issue
a VIDIOC_ENUMINPUT IOCTL, this will enumerate the inputs
then you do VIDIOC_S_INPUT this will select the input device
so when this IOCTL is called vpif_s_input() is called in vpif_capture
driver this function will internally call the vpif_set_input() which
will set the iface for you on line 1327.
In the probe it calls vpif_set_input() to select input 0 as a default device.
Hope this clears your doubt.
Regards,
--Prabhakar Lad
I'm using linux-3.10.4, but the problem appears in 3.10.9, 3.11.rc7 and a
version I checked out at
https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git. I
have supplied a patch for 3.10.9.
diff -pubwr
linux-3.10.9-pristine/drivers/media/platform/davinci/vpif_capture.c
linux-3.10.9/drivers/media/platform/davinci/vpif_capture.c
--- linux-3.10.9-pristine/drivers/media/platform/davinci/vpif_capture.c
2013-08-20 17:40:47.0 -0500
+++ linux-3.10.9/drivers/media/platform/davinci/vpif_capture.c 2013-08-30
11:18:29.0 -0500
@@ -914,9 +914,11 @@ static int vpif_open(struct file *filep)
fh-initialized = 0;
/* If decoder is not initialized. initialize it */
if (!ch-initialized) {
+struct vpif_interface iface = ch-vpifparams.iface;
fh-initialized = 1;
ch-initialized = 1;
memset((ch-vpifparams), 0, sizeof(struct vpif_params));
+ch-vpifparams.iface = iface;
}
/* Increment channel usrs counter */
ch-usrs++;
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] si4713 : Modified i2c driver to handle cases where interrupts are not used
Dinesh, Hi
On Fri, Aug 30, 2013 at 7:28 AM, Dinesh Ram din...@cisco.com wrote:
Checks have been introduced at several places in the code to test if an
interrupt is set or not.
For devices which do not use the interrupt, to get a valid response, within a
specified timeout,
the device is polled instead.
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/si4713.c | 110
drivers/media/radio/si4713/si4713.h | 1 +
2 files changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index ac727e3..55c4d27 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -27,7 +27,6 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/gpio.h
-#include linux/regulator/consumer.h
#include linux/module.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -213,6 +212,7 @@ static int si4713_send_command(struct si4713_device
*sdev, const u8 command,
u8 response[], const int respn, const int
usecs)
{
struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
+ unsigned long until_jiffies;
u8 data1[MAX_ARGS + 1];
int err;
@@ -228,30 +228,39 @@ static int si4713_send_command(struct si4713_device
*sdev, const u8 command,
if (err != argn + 1) {
v4l2_err(sdev-sd, Error while sending command 0x%02x\n,
command);
- return (err 0) ? -EIO : err;
+ return err 0 ? err : -EIO;
Why did you change the semantics here?
}
+ until_jiffies = jiffies + usecs_to_jiffies(usecs) + 1;
+
/* Wait response from interrupt */
- if (!wait_for_completion_timeout(sdev-work,
+ if (client-irq) {
+ if (!wait_for_completion_timeout(sdev-work,
usecs_to_jiffies(usecs) + 1))
- v4l2_warn(sdev-sd,
+ v4l2_warn(sdev-sd,
(%s) Device took too much time to answer.\n,
__func__);
-
- /* Then get the response */
- err = i2c_master_recv(client, response, respn);
- if (err != respn) {
- v4l2_err(sdev-sd,
- Error while reading response for command 0x%02x\n,
- command);
- return (err 0) ? -EIO : err;
}
- DBG_BUFFER(sdev-sd, Response, response, respn);
- if (check_command_failed(response[0]))
- return -EBUSY;
+ do {
+ err = i2c_master_recv(client, response, respn);
+ if (err != respn) {
+ v4l2_err(sdev-sd,
+ Error %d while reading response for
command 0x%02x\n,
+ err, command);
+ return err 0 ? err : -EIO;
Again?
+ }
- return 0;
+ DBG_BUFFER(sdev-sd, Response, response, respn);
+ if (!check_command_failed(response[0]))
+ return 0;
+
+ if (client-irq)
+ return -EBUSY;
+ msleep(1);
+ } while (jiffies = until_jiffies);
+
+ return -EBUSY;
}
/*
@@ -344,14 +353,15 @@ static int si4713_write_property(struct si4713_device
*sdev, u16 prop, u16 val)
*/
static int si4713_powerup(struct si4713_device *sdev)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
int err;
u8 resp[SI4713_PWUP_NRESP];
/*
* .First byte = Enabled interrupts and boot function
* .Second byte = Input operation mode
*/
- const u8 args[SI4713_PWUP_NARGS] = {
- SI4713_PWUP_CTSIEN | SI4713_PWUP_GPO2OEN |
SI4713_PWUP_FUNC_TX,
+ u8 args[SI4713_PWUP_NARGS] = {
+ SI4713_PWUP_GPO2OEN | SI4713_PWUP_FUNC_TX,
SI4713_PWUP_OPMOD_ANALOG,
};
@@ -369,18 +379,22 @@ static int si4713_powerup(struct si4713_device *sdev)
gpio_set_value(sdev-gpio_reset, 1);
}
+ if (client-irq)
+ args[0] |= SI4713_PWUP_CTSIEN;
+
err = si4713_send_command(sdev, SI4713_CMD_POWER_UP,
args, ARRAY_SIZE(args),
resp, ARRAY_SIZE(resp),
TIMEOUT_POWER_UP);
-
+
Please, do not insert tabulation in blank lines.
if (!err) {
v4l2_dbg(1, debug, sdev-sd, Powerup response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in power up mode\n);
sdev-power_state = POWER_ON;
- err = si4713_write_property(sdev,
Re: [PATCH 2/6] si4713 : Modified i2c driver to handle cases where interrupts are not used
On Fri, Aug 30, 2013 at 7:28 AM, Dinesh Ram din...@cisco.com wrote:
Checks have been introduced at several places in the code to test if an
interrupt is set or not.
For devices which do not use the interrupt, to get a valid response, within a
specified timeout,
the device is polled instead.
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/si4713.c | 110
drivers/media/radio/si4713/si4713.h | 1 +
2 files changed, 63 insertions(+), 48 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index ac727e3..55c4d27 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -27,7 +27,6 @@
#include linux/i2c.h
#include linux/slab.h
#include linux/gpio.h
-#include linux/regulator/consumer.h
#include linux/module.h
#include media/v4l2-device.h
#include media/v4l2-ioctl.h
@@ -213,6 +212,7 @@ static int si4713_send_command(struct si4713_device
*sdev, const u8 command,
u8 response[], const int respn, const int
usecs)
{
struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
+ unsigned long until_jiffies;
u8 data1[MAX_ARGS + 1];
int err;
@@ -228,30 +228,39 @@ static int si4713_send_command(struct si4713_device
*sdev, const u8 command,
if (err != argn + 1) {
v4l2_err(sdev-sd, Error while sending command 0x%02x\n,
command);
- return (err 0) ? -EIO : err;
+ return err 0 ? err : -EIO;
}
+ until_jiffies = jiffies + usecs_to_jiffies(usecs) + 1;
+
/* Wait response from interrupt */
- if (!wait_for_completion_timeout(sdev-work,
+ if (client-irq) {
+ if (!wait_for_completion_timeout(sdev-work,
usecs_to_jiffies(usecs) + 1))
- v4l2_warn(sdev-sd,
+ v4l2_warn(sdev-sd,
(%s) Device took too much time to answer.\n,
__func__);
-
- /* Then get the response */
- err = i2c_master_recv(client, response, respn);
- if (err != respn) {
- v4l2_err(sdev-sd,
- Error while reading response for command 0x%02x\n,
- command);
- return (err 0) ? -EIO : err;
}
- DBG_BUFFER(sdev-sd, Response, response, respn);
- if (check_command_failed(response[0]))
- return -EBUSY;
+ do {
+ err = i2c_master_recv(client, response, respn);
+ if (err != respn) {
+ v4l2_err(sdev-sd,
+ Error %d while reading response for
command 0x%02x\n,
+ err, command);
+ return err 0 ? err : -EIO;
+ }
- return 0;
+ DBG_BUFFER(sdev-sd, Response, response, respn);
+ if (!check_command_failed(response[0]))
+ return 0;
+
+ if (client-irq)
+ return -EBUSY;
+ msleep(1);
+ } while (jiffies = until_jiffies);
+
+ return -EBUSY;
}
/*
@@ -344,14 +353,15 @@ static int si4713_write_property(struct si4713_device
*sdev, u16 prop, u16 val)
*/
static int si4713_powerup(struct si4713_device *sdev)
{
+ struct i2c_client *client = v4l2_get_subdevdata(sdev-sd);
int err;
u8 resp[SI4713_PWUP_NRESP];
/*
* .First byte = Enabled interrupts and boot function
* .Second byte = Input operation mode
*/
- const u8 args[SI4713_PWUP_NARGS] = {
- SI4713_PWUP_CTSIEN | SI4713_PWUP_GPO2OEN |
SI4713_PWUP_FUNC_TX,
+ u8 args[SI4713_PWUP_NARGS] = {
+ SI4713_PWUP_GPO2OEN | SI4713_PWUP_FUNC_TX,
SI4713_PWUP_OPMOD_ANALOG,
};
@@ -369,18 +379,22 @@ static int si4713_powerup(struct si4713_device *sdev)
gpio_set_value(sdev-gpio_reset, 1);
}
+ if (client-irq)
+ args[0] |= SI4713_PWUP_CTSIEN;
+
err = si4713_send_command(sdev, SI4713_CMD_POWER_UP,
args, ARRAY_SIZE(args),
resp, ARRAY_SIZE(resp),
TIMEOUT_POWER_UP);
-
+
if (!err) {
v4l2_dbg(1, debug, sdev-sd, Powerup response: 0x%02x\n,
resp[0]);
v4l2_dbg(1, debug, sdev-sd, Device in power up mode\n);
sdev-power_state = POWER_ON;
- err = si4713_write_property(sdev, SI4713_GPO_IEN,
+ if (client-irq)
+ err = si4713_write_property(sdev,
Re: [PATCH 3/6] si4713 : Bug fix for si4713_tx_tune_power() method in the i2c driver
Hi Dinesh,
On Fri, Aug 30, 2013 at 7:28 AM, Dinesh Ram din...@cisco.com wrote:
In the si4713_tx_tune_power() method, the args array element 'power' can take
values between
SI4713_MIN_POWER and SI4713_MAX_POWER. power = 0 is also valid.
All the values (0 power SI4713_MIN_POWER) are illegal and hence
are all mapped to SI4713_MIN_POWER.
While do we need to assume min power in these cases?
Signed-off-by: Dinesh Ram din...@cisco.com
---
drivers/media/radio/si4713/si4713.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/radio/si4713/si4713.c
b/drivers/media/radio/si4713/si4713.c
index 55c4d27..5d0be87 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -550,14 +550,14 @@ static int si4713_tx_tune_freq(struct si4713_device
*sdev, u16 frequency)
}
/*
- * si4713_tx_tune_power - Sets the RF voltage level between 88 and 115 dBuV
in
+ * si4713_tx_tune_power - Sets the RF voltage level between 88 and 120 dBuV
in
* 1 dB units. A value of 0x00 indicates off. The command
* also sets the antenna tuning capacitance. A value of 0
* indicates autotuning, and a value of 1 - 191 indicates
* a manual override, which results in a tuning
* capacitance of 0.25 pF x @antcap.
* @sdev: si4713_device structure for the device we are communicating
- * @power: tuning power (88 - 115 dBuV, unit/step 1 dB)
+ * @power: tuning power (88 - 120 dBuV, unit/step 1 dB)
* @antcap: value of antenna tuning capacitor (0 - 191)
*/
static int si4713_tx_tune_power(struct si4713_device *sdev, u8 power,
@@ -571,16 +571,16 @@ static int si4713_tx_tune_power(struct si4713_device
*sdev, u8 power,
* .Third byte = power
* .Fourth byte = antcap
*/
- const u8 args[SI4713_TXPWR_NARGS] = {
+ u8 args[SI4713_TXPWR_NARGS] = {
0x00,
0x00,
power,
antcap,
};
- if (((power 0) (power SI4713_MIN_POWER)) ||
- power SI4713_MAX_POWER || antcap SI4713_MAX_ANTCAP)
- return -EDOM;
+ /* Map power values 1-87 to MIN_POWER (88) */
+ if (power 0 power SI4713_MIN_POWER)
+ args[2] = power = SI4713_MIN_POWER;
Why are you allowing antcap SI4713_MAX_ANTCAP? and power
SI4713_MAX_POWER too?
err = si4713_send_command(sdev, SI4713_CMD_TX_TUNE_POWER,
args, ARRAY_SIZE(args), val,
@@ -1457,9 +1457,9 @@ static int si4713_probe(struct i2c_client *client,
V4L2_CID_TUNE_PREEMPHASIS,
V4L2_PREEMPHASIS_75_uS, 0, V4L2_PREEMPHASIS_50_uS);
sdev-tune_pwr_level = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
- V4L2_CID_TUNE_POWER_LEVEL, 0, 120, 1,
DEFAULT_POWER_LEVEL);
+ V4L2_CID_TUNE_POWER_LEVEL, 0, SI4713_MAX_POWER, 1,
DEFAULT_POWER_LEVEL);
sdev-tune_ant_cap = v4l2_ctrl_new_std(hdl, si4713_ctrl_ops,
- V4L2_CID_TUNE_ANTENNA_CAPACITOR, 0, 191, 1, 0);
+ V4L2_CID_TUNE_ANTENNA_CAPACITOR, 0,
SI4713_MAX_ANTCAP, 1, 0);
if (hdl-error) {
rval = hdl-error;
--
1.8.4.rc2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Eduardo Bezerra Valentin
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Hinweis: Wenn Sie auf diese Nachricht antworten möchten, müssen Sie zu einer Antwort auf diese E-MAIL SENDEN firsteasyra...@qq.com Komplimente des Tages, sind Sie ein Business-Mann oder Frau? Haben Sie keine finanziellen Schlamassel oder brauchen Sie Geld auf Ihr eigenes Unternehmen gründen? Sie benötigen Darlehen, um Ihre Schulden zu begleichen oder zahlen Sie Ihre Rechnungen oder starten Sie ein nettes Geschäft? Sie brauchen finanzielle Mittel, um Ihr Projekt zu finanzieren? Wir bieten Darlehen Dienstleistungen von Wert, um überall in der Welt (Einzelpersonen, Unternehmen, Immobilien-Makler und juristische Personen) in unseren hervorragenden Zinssatz von 3% FÜR WEITERE INFORMATIONEN KONTAKTIEREN SIE UNS HEUTE BEI UNS EMAIL firsteasyra...@qq.com _ NOTE IF YOU WISH TO REPLY THIS MESSAGE , YOU MUST HAVE TO SEND A REPLY TO THIS EMAIL firsteasyra...@qq.com Compliments of the day, are you a business man or woman? Have any financial mess or do you need funds to start your own business? Do you need loan to settle your debt or pay off your bills or start a nice business? Do you need funds to finance your project? We offer loan services of any value to anywhere in the world (individuals, businesses, real estate broker and legal persons) in our superb interest rate of 3% FOR MORE INFORMATION CONTACT US TODAY AT OUR EMAIL firsteasyra...@qq.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Linux Media mini-summit in Edinburgh
Hi Mauro, On Fri, Aug 30, 2013 at 08:39:23AM -0300, Mauro Carvalho Chehab wrote: Hi media developers, This year, we're planning to do a media mini-summit together with the conferences that will be hosted in Edinburgh (LinuxCon EU/ELCE/KS/...), at the Oct 21-25 week. We don't have the specific days for the event yet (we're still closing it with Linux Foundation). Yet, I'd like to know who is interested on participate on the event, and ask for the theme proposals for the discussions. As we're doing over the last years, we'll be using the media-works...@linuxtv.org mailing list for such discussions. I'm very interested in having a media mini-summit in Edinburgh. I'll be there. -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
On Fri, Aug 30, 2013 at 03:01:25PM +0200, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html - Multi-format frames and metadata. Support would be needed on video nodes and V4L2 subdev nodes. I'll prepare the RFC for the former; the latter has an RFC here: URL:http://www.spinics.net/lists/linux-media/msg67295.html -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel 3.10.x Regression
Could someone please look at these issue posted in bugzilla as well as in two separate mails: https://bugzilla.kernel.org/show_bug.cgi?id=60645 http://www.spinics.net/lists/linux-media/msg66804.html http://www.spinics.net/lists/linux-media/msg67107.html On Thu, Aug 08, 2013 at 05:52:53PM +0200, mario tillmann wrote: With the latest kernel 3.10.x I get an error message when loading the firmware sms1xxx-hcw-55xxx-dvbt-02.fw: smscore_load_firmware_family2: line: 986: sending MSG_SMS_DATA_VALIDITY_REQ expecting 0xcfed1755 smscore_onresponse: line: 1565: MSG_SMS_DATA_VALIDITY_RES, checksum = 0xcfed1755 This error is reported for 32/64 bit systems. If you need more details please let me know. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1.1 3/5] media: Pads that are not connected by even a disabled link are fine
Do not require a connected link to a pad if a pad has no links connected to
it.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Hi Laurent,
This goes on top of patch 2/4. I can combine the two in the end but I think
this is cleaner as a separate change.
drivers/media/media-entity.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index a99396b..2ad291f 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -236,6 +236,7 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
while ((entity = media_entity_graph_walk_next(graph))) {
DECLARE_BITMAP(active, entity-num_pads);
+ DECLARE_BITMAP(has_no_links, entity-num_pads);
unsigned int i;
entity-stream_count++;
@@ -250,6 +251,7 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
continue;
bitmap_zero(active, entity-num_pads);
+ bitmap_fill(has_no_links, entity-num_pads);
for (i = 0; i entity-num_links; i++) {
struct media_link *link = entity-links[i];
@@ -257,6 +259,11 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
? link-sink : link-source;
/*
+* Mark that a pad is connected by a link.
+*/
+ bitmap_clear(has_no_links, pad-index, 1);
+
+ /*
* Pads that either do not need to connect or
* are connected through an enabled link are
* fine.
@@ -278,6 +285,9 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
goto error;
}
+ /* Either no links or validated links are fine. */
+ bitmap_or(active, active, has_no_links, entity-num_pads);
+
if (!bitmap_full(active, entity-num_pads)) {
ret = -EPIPE;
goto error;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION 3.11-rc1+] wm8775 9-001b: I2C: cannot write ??? to register R??
On Sat, Aug 31, 2013 at 1:00 AM, Knut Petersen knut_peter...@t-online.de wrote: Hi Linus! It would be nice to have head cx88fix of git.linuxtv.org/hverkuil/media_tree.git (git.linuxtv.org/hverkuil/media_tree.git/commit/5dce3635bf803cfe9dde84e00f5f9594439e6c02) in 3.11 as it is a trivial and tested fix for a regression introduced between 3.10 and 3.11-rc1. I can't take partial pull requests - I can take individual patches from email (with proper sign-off chains etc, of course), but I don't do take this patch from this git tree. Git pulls need to go through the tree owner and with all the normal pull request rules, and the rest of that tree doesn't look critical. Linus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 14/19] v4l: Add v4l2_buffer flags for VP8-specific special frames.
Hi Hans and Pawel, On Fri, Aug 30, 2013 at 10:12:45AM +0200, Hans Verkuil wrote: Are prev/golden/altref frames mutually exclusive? If so, then perhaps we Does that apply to other types of frames as well (key, p and b)? If yes, the existing frame bits could be used for VP8 frame flags while the existing codecs could keep using the old definitions, i.e. same bits, but different macros. Just my five euro cents. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 14/19] v4l: Add v4l2_buffer flags for VP8-specific special frames.
Hi Pawel,
On Fri, Aug 30, 2013 at 11:17:13AM +0900, Pawel Osciak wrote:
Add bits for previous, golden and altref frame types.
Signed-off-by: Pawel Osciak posc...@chromium.org
---
include/uapi/linux/videodev2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 437f1b0..c011ee0 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -687,6 +687,10 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x
#define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC0x2000
#define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x4000
+/* VP8 special frames */
+#define V4L2_BUF_FLAG_PREV_FRAME 0x1 /* VP8 prev frame */
+#define V4L2_BUF_FLAG_GOLDEN_FRAME 0x2 /* VP8 golden frame */
+#define V4L2_BUF_FLAG_ALTREF_FRAME 0x4 /* VP8 altref frame */
Whichever way this patch is changed, could you rebased it on v4l: Use full
32 bits for buffer flags? It changes the definitions of the flags use
32-bit values.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 18/19] v4l: Add V4L2_PIX_FMT_VP8_SIMULCAST format.
Hi Pawel,
Thanks for the patchset.
On Fri, Aug 30, 2013 at 11:17:17AM +0900, Pawel Osciak wrote:
This format is used by UVC 1.5 VP8-encoding cameras. When it is used, the
camera
may encode captured frames into one or more streams, each of which may
be configured differently. This allows simultaneous capture of streams
with different resolutions, bitrates, and other settings, depending on the
camera capabilities.
Signed-off-by: Pawel Osciak posc...@chromium.org
---
include/uapi/linux/videodev2.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c011ee0..8b0d4ad 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -402,6 +402,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_VC1_ANNEX_G v4l2_fourcc('V', 'C', '1', 'G') /* SMPTE
421M Annex G compliant stream */
#define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE
421M Annex L compliant stream */
#define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
+#define V4L2_PIX_FMT_VP8_SIMULCAST v4l2_fourcc('V', 'P', '8', 'S') /* VP8
simulcast */
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
@@ -691,6 +692,9 @@ struct v4l2_buffer {
#define V4L2_BUF_FLAG_PREV_FRAME 0x1 /* VP8 prev frame */
#define V4L2_BUF_FLAG_GOLDEN_FRAME 0x2 /* VP8 golden frame */
#define V4L2_BUF_FLAG_ALTREF_FRAME 0x4 /* VP8 altref frame */
+/* Simulcast layer structure. */
+#define V4L2_BUF_FLAG_LAYER_STRUCTURE_SHIFT 19 /* Bits 19-20 for layer */
+#define V4L2_BUF_FLAG_LAYER_STRUCTURE_MASK 0x3 /* structure information. */
What do these bits signify? It'd be also nice to document them.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
On Sat, 31 Aug 2013, Hans Verkuil wrote: On 08/30/2013 03:01 PM, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): - Discuss ideas/use-cases for a property-based API. An initial discussion appeared in this thread: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/65195 - What is needed to share i2c video transmitters between drm and v4l? Hopefully we will know more after the upcoming LPC. - Decide on how v4l2 support libraries should be organized. There is code for handling raw-to-sliced VBI decoding, ALSA looping, finding associated video/alsa nodes and for TV frequency tables. We should decide how that should be organized into libraries and how they should be documented. The first two aren't libraries at the moment, but I think they should be. The last two are libraries but they aren't installed. Some work is also being done on an improved version of the 'associating nodes' library that uses the MC if available. - Define the interaction between selection API, ENUM_FRAMESIZES and S_FMT. See this thread for all the nasty details: http://www.spinics.net/lists/linux-media/msg65137.html Feel free to add suggestions to this list. I got another one: VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code. We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL. Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. Just to make sure I understand right - that kind of excludes cameras, right? Still, even for (other) video capture devices, like TV decoders, is there a real serious enough reason to _change_ the specs, which says http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html EINVAL The struct v4l2_format type field is invalid or the requested buffer type not supported. If we have a spec, that says A, and some drivers drivers do A, but others do B, and we want to change the specs to B? Instead of either changing the (wrong) drivers to A (yes, some applications expect that wrong behaviour) or at least extending the spec to allow both A and B? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: dvb-frontends: Remove unused SIZEOF_ARRAY
SIZEOF_ARRAY is not used (anymore). Besides, ARRAY_SIZE, defined in include/linux/kernel.h, should be used rather than explicitly coding some variant of it. Signed-off-by: Christoph Jaeger christophjae...@linux.com --- drivers/media/dvb-frontends/drxd_hard.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/media/dvb-frontends/drxd_hard.c b/drivers/media/dvb-frontends/drxd_hard.c index 9a213479..cbd7c92 100644 --- a/drivers/media/dvb-frontends/drxd_hard.c +++ b/drivers/media/dvb-frontends/drxd_hard.c @@ -46,10 +46,6 @@ #define DRX_I2C_MODEFLAGS 0xC0 #define DRX_I2C_FLAGS 0xF0 -#ifndef SIZEOF_ARRAY -#define SIZEOF_ARRAY(array) (sizeof((array))/sizeof((array)[0])) -#endif - #define DEFAULT_LOCK_TIMEOUT1100 #define DRX_CHANNEL_AUTO 0 -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
On Saturday 31 August 2013 09:04:14 Pawel Osciak wrote: On Sat, Aug 31, 2013 at 9:03 AM, Laurent Pinchart wrote: On Saturday 31 August 2013 08:58:41 Pawel Osciak wrote: On Sat, Aug 31, 2013 at 1:54 AM, Laurent Pinchart wrote: On Friday 30 August 2013 10:31:23 Mauro Carvalho Chehab wrote: Em Fri, 30 Aug 2013 15:21:05 +0200 Oliver Schinagl escreveu: [snip] What about a hardware accelerated decoding API/framework? Is there a proper framework for this at all? I see the broadcom module is still in staging and may never come out of it, but how are other video decoding engines handled that don't have cameras or displays. Reason for asking is that we from linux-sunxi have made some positive progress in Reverse engineering the video decoder blob of the Allwinner A10 and this knowledge will need a kernel side driver in some framework. I looked at the exynos video decoders and googling for linux-media hardware accelerated decoding doesn't yield much either. Anyway, just a thought; if you think it's the wrong place for it to be discussed, that's ok :) Well, the mem2mem V4L2 devices should provide all that would be needed for accelerated encoders/decoders. If not, then feel free to propose extensionsto fit your needs. Two comments regarding this: - V4L2 mem-to-mem is great for frame-based codecs, but SoCs sometimes only implement part of the codec in hardware, leaving the rest to the software. Encoded bistream parsing is one of those areas that are left to the CPU, for instance on some ST SoCs (CC'ing Benjamin Gaignard). This is an interesting topic for me as well, although I'm still not sure if I can make it to the workshop. Would it make sense to have v4l parser plugins hook up to qbuf and do the parsing there? Do you mean in libv4l ? Yes... Let's discuss that in Edinburgh then. The major problem as I see it is that the hardware codec might consume and produce data that wouldn't fit the spirit of the current V4L2 API. We might end up with passing register lists in a V4L2 buffer, which would be pretty ugly. Benjamin, do you plan to attend the conference ? - http://www.linuxplumbersconf.org/2013/ocw/sessions/1605 -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
Hi Guennadi, On Saturday 31 August 2013 20:38:54 Guennadi Liakhovetski wrote: On Sat, 31 Aug 2013, Hans Verkuil wrote: On 08/30/2013 03:01 PM, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): [snip] Feel free to add suggestions to this list. I got another one: VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code. We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL. Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. Just to make sure I understand right - that kind of excludes cameras, right? Still, even for (other) video capture devices, like TV decoders, is there a real serious enough reason to _change_ the specs, which says http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html EINVAL The struct v4l2_format type field is invalid or the requested buffer type not supported. I think Hans meant unsupported fmt.pix.pixelformat (or the equivalent for multiplane) values. For instance the uvcvideo driver will return a default fourcc if an application tries an unsupported fourcc, some other drivers return -EINVAL. If we have a spec, that says A, and some drivers drivers do A, but others do B, and we want to change the specs to B? Instead of either changing the (wrong) drivers to A (yes, some applications expect that wrong behaviour) or at least extending the spec to allow both A and B? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
UBS Benachrichtigung - Ihre Internet-Banking gesperrt
UBS Sehr geehrter Kunde, kürzlich zeigten unsere Aufzeichnungen, dass Ihr UBS-Konto durch einen Dritten unbefugten Zutritt hatte.Die Sicherheit Ihres Kontos ist unser wichtigstes Anliegen. Deshalb haben wir beschlossen, den Zugang zu Ihrem Konto vorübergehend zu begrenzen. Für den vollen Zugang zu Ihrem Konto, müssen Ihre Daten wiederhergestellt werden, daher bestätigen Sie Ihr Konto über diesen Link: http://karryupdatemenw.com/deu.html?loginlocale=de-CH Sobald Ihre Angaben überprüft und bestätigt ist, erhalten Sie eine Anruf aus von uns. Und somit wird auf Ihr Konto wieder komplettes Zugreifen wiederhergestellt. Wir danken Ihnen für Ihre Kooperation. Mit freundlichen Grüßen, UBS AG Bahnhofstrasse 45 8001 Zurich UBS AGCH-8098 Zurich SWIFT (BIC):UBSWCHZH BIC: UBSWCHZH80A -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: Memory acquisition problem with yavta and media control.
Hi Nilesh, On Saturday 31 August 2013 10:07:14 purch...@utopiacontrol.com wrote: //= linux-media@vger.kernel.org laurent.pinch...@ideasonboard.com //= Hi laurent pinchart, Just Laurent will do :-) You have done a great work for snapshot mode image sensor driver for linux. I am using your media control tool with yavta test application for interfacing the mt9v032 image sensor with Gumstix Overo Water Com board. I have successfully tested the snapshot mode with this combination. But the problem is that, when I attempt to grab lots of images (thousands) of images by this test application yavta. I found that the free memory goes increasing by some amount which will not get free. Afterwards I have calculate the amount of ram acquires on every snap is about 0.618 KB (after averaging 10 frames). Will you please Give me any reason why this is happening with this test application? And how can I get overcome on this problem. That's definitely not expected and should be debugged. First of all, is the memory released when you stop yavta ? If it isn't then we have a kernel bug, if it is the bug could be either on the kernel side or the application side. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] Agenda for the Edinburgh mini-summit
On Sat, 31 Aug 2013, Laurent Pinchart wrote: Hi Guennadi, On Saturday 31 August 2013 20:38:54 Guennadi Liakhovetski wrote: On Sat, 31 Aug 2013, Hans Verkuil wrote: On 08/30/2013 03:01 PM, Hans Verkuil wrote: OK, I know, we don't even know yet when the mini-summit will be held but I thought I'd just start this thread to collect input for the agenda. I have these topics (and I *know* that I am forgetting a few): [snip] Feel free to add suggestions to this list. I got another one: VIDIOC_TRY_FMT shouldn't return -EINVAL when an unsupported pixelformat is provided, but in practice video capture board tend to do that, while webcam drivers tend to map it silently to a valid pixelformat. Some applications rely on the -EINVAL error code. We need to decide how to adjust the spec. I propose to just say that some drivers will map it silently and others will return -EINVAL and that you don't know what a driver will do. Also specify that an unsupported pixelformat is the only reason why TRY_FMT might return -EINVAL. Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. Just to make sure I understand right - that kind of excludes cameras, right? Still, even for (other) video capture devices, like TV decoders, is there a real serious enough reason to _change_ the specs, which says http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-g-fmt.html EINVAL The struct v4l2_format type field is invalid or the requested buffer type not supported. I think Hans meant unsupported fmt.pix.pixelformat (or the equivalent for multiplane) values. Good, then I understood him correctly :) For instance the uvcvideo driver will return a default fourcc if an application tries an unsupported fourcc, Yes, that's what I would do too and that's what the spec dictates. some other drivers return -EINVAL. that just seems plain wrong to me. So, as I said, to not break the userspace we can extend the specs, but not prohibit the currently defined behaviour. So, that last option: Alternatively we might want to specify explicitly that EINVAL should be returned for video capture devices (i.e. devices supporting S_STD or S_DV_TIMINGS) and 0 for all others. I'm not sure I like a lot, unless those drivers are very special and they all already behave like that. Thanks Guennadi If we have a spec, that says A, and some drivers drivers do A, but others do B, and we want to change the specs to B? Instead of either changing the (wrong) drivers to A (yes, some applications expect that wrong behaviour) or at least extending the spec to allow both A and B? -- Regards, Laurent Pinchart --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4.1 3/3] v4l: Add V4L2_BUF_FLAG_TIMESTAMP_SOF and use it
Hi Sakari, On Friday 30 August 2013 19:08:48 Sakari Ailus wrote: On Fri, Aug 30, 2013 at 01:31:44PM +0200, Laurent Pinchart wrote: On Thursday 29 August 2013 14:33:39 Sakari Ailus wrote: On Thu, Aug 29, 2013 at 01:25:05AM +0200, Laurent Pinchart wrote: On Wednesday 28 August 2013 19:39:19 Sakari Ailus wrote: On Wed, Aug 28, 2013 at 06:14:44PM +0200, Laurent Pinchart wrote: ... UVC devices timestamp frames when the frame is captured, not when the first pixel is transmitted. I.e. we shouldn't set the SOF flag? When the frame is captured doesn't say much, or almost anything in terms of *when*. The frames have exposure time and rolling shutter makes a difference, too. The UVC 1.1 specification defines the timestamp as The source clock time in native deviceclock units when the raw frame capture begins. What devices do in practice may differ :-) I think that this should mean start-of-frame - exposure time. I'd really wonder if any practical implementation does that however. It's start-of-frame - exposure time - internal delays (UVC webcams are supposed to report their internal delay value as well). Do they report it? How about the exposure time? It's supposed to be configurable. Is the exposure reported with the frame so it could be used to construct the per-frame SOF timestamp? Not when auto-exposure is turned on I'm afraid :-S I believe that the capture timestamp makes more sense than the SOF timestamp for applications. SOF/EOF are more of a poor man's timestamp in case nothing else is available, but when you want to synchronize multiple audio and/or video streams the capture timestamp is what you're interested in. I don't think converting a capture timestamp to an SOF would be a good idea. If you know them all you can calculate the SOF timestamp. The fewer timestamps are available for user programs the better. It's another matter then if there are webcams that report these values wrong. There most probably are :-) Then you could get timestamps that are complete garbage. But I guess you could compare them to the current monotonic timestamp and detect such cases. What's your suggestion; should we use the SOF flag for this or do you prefer the end-of-frame timestamp instead? I think it'd be quite nice for drivers to know which one is which without having to guess, and based on the above start-of-frame comes as close to that definition as is meaningful. SOF is better than EOF. Do we need a start-of-capture flag, or could we document SOF as meaning start-of-capture or start-of-reception depending on what the device can do ? One possibility is to dedicate a few flags for this; by using three bits we'd get eight different timestamps already. But I have to say that fewer is better. :-) Does it really need to be a per-buffer flag ? This seems to be a driver-wide (or at least device-wide) behaviour to me. Same goes for timestamp clock sources. It was concluded to use buffer flags for those as well. Yes, and I don't think I was convinced, so I'm not convinced here either :-) Using a control for the purpose would however require quite non-zero amount of initialisation code from each driver so that would probably need to be sorted out first. We could also use a capabilities flag. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: width and height of JPEG compressed images
Hi Thomas,
I sincerely apologise for not having replied earlier. Looks like I'm
being pulled in too many directions. :/
On 08/06/2013 06:26 PM, Thomas Vajzovic wrote:
On 24 July 2013 10:30 Sylwester Nawrocki wrote:
On 07/22/2013 10:40 AM, Thomas Vajzovic wrote:
On 21 July 2013 21:38 Sylwester Nawrocki wrote:
On 07/19/2013 10:28 PM, Sakari Ailus wrote:
On Sat, Jul 06, 2013 at 09:58:23PM +0200, Sylwester Nawrocki wrote:
On 07/05/2013 10:22 AM, Thomas Vajzovic wrote:
The hardware reads AxB sensor pixels from its array, resamples
them to CxD image pixels, and then compresses them to ExF bytes.
If the sensor driver is only told the user's requested sizeimage, it
can be made to factorize (ExF) into (E,F) itself, but then both the
parallel interface and the 2D DMA peripheral need to be told the
particular factorization that it has chosen.
If the user requests sizeimage which cannot be satisfied (eg: a prime
number) then it will need to return (E,F) to the bridge driver which
does not multiply exactly to sizeimage. Because of this the bridge
driver must set the corrected value of sizeimage which it returns to
userspace to the product ExF.
Ok, let's consider following data structure describing the frame:
struct v4l2_frame_desc_entry {
u32 flags;
u32 pixelcode;
u32 samples_per_line;
u32 num_lines;
u32 size;
};
I think we could treat the frame descriptor to be at lower lever in
the protocol stack than struct v4l2_mbus_framefmt.
Then the bridge would set size and pixelcode and the subdev would
return (E, F) in (samples_per_frame, num_lines) and adjust size if
required. Number of bits per sample can be determined by pixelcode.
It needs to be considered that for some sensor drivers it might not
be immediately clear what samples_per_line, num_lines values are.
In such case those fields could be left zeroed and bridge driver
could signal such condition as a more or less critical error. In
end of the day specific sensor driver would need to be updated to
interwork with a bridge that requires samples_per_line, num_lines.
I think we ought to try to consider the four cases:
1D sensor and 1D bridge: already works
2D sensor and 2D bridge: my use case
1D sensor and 2D bridge, 2D sensor and 1D bridge:
Perhaps both of these cases could be made to work by setting:
num_lines = 1; samples_per_line = ((size * 8) / bpp);
(Obviously this would also require the appropriate pull-up/down
on the second sync input on a 2D bridge).
So to determine when this has to be done, e.g. we could see that either
num_lines or samples_per_line == 1 ?
Since the frame descriptor interface is still new and used in so
few drivers, is it reasonable to expect them all to be fixed to
do this?
Certainly, I'll be happy to rework those drivers to whatever the
re-designed API, as long as it supports the current functionality.
Not sure if we need to add image width and height in pixels to the
above structure. It wouldn't make much sensor when single frame
carries multiple images, e.g. interleaved YUV and compressed image
data at different resolutions.
If image size were here then we are duplicating get_fmt/set_fmt.
But then, by having pixelcode here we are already duplicating part
of get_fmt/set_fmt. If the bridge changes pixelcode and calls
set_frame_desc then is this equivalent to calling set_fmt?
I would like to see as much data normalization as possible and
eliminate the redundancy.
Perhaps we could replace pixelcode in the above struct by something
else that would have conveyed required data. But I'm not sure what it
would have been. Perhaps just bits_per_sample for starters ?
The frame descriptors were also supposed to cover interleaved image data.
Then we need something like pixelcode (MIPI CSI-2 Data Type) in each
frame_desc entry.
Not sure if it would have been sensible to put some of the above
information into struct v4l2_mbus_frame_desc rather than to struct
v4l2_mbus_frame_desc_entry.
Whatever mechanism is chosen needs to have corresponding get/set/try
methods to be used when the user calls
VIDIOC_G_FMT/VIDIOC_S_FMT/VIDIOC_TRY_FMT.
Agreed, it seems we need some sort of negotiation of those low
level parameters.
Should there be set/get/try function pointers, or should the struct
include an enum member like v4l2_subdev_format.which to determine
which operation is to be perfomed?
Personally I think that it is a bit ugly having two different
function pointers for set_fmt/get_fmt but then a structure member
to determine between set/try. IMHO it should be three function
pointers or one function with a three valued enum in the struct.
I'm fine either way, with a slight preference for three separate callbacks.
WRT to making frame_desc read-only, subdevices for which it doesn't make
sense to set anything could always adjust passed data to their fixed or
depending on other calls, like the pad level set_fmt op, values. And we
seem to have use cases already for at least try_frame_desc.
--
Regards,
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Sep 1 04:00:18 CEST 2013 git branch: test git hash: 26a20eb09d44dc064c4f5d1f024bd501c09edb4b gcc version:i686-linux-gcc (GCC) 4.8.1 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.10.1 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.10.1-i686: OK linux-3.1.10-i686: OK linux-3.11-rc1-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.10.1-x86_64: OK linux-3.1.10-x86_64: OK linux-3.11-rc1-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK apps: WARNINGS spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
em28xx disabled when compiling on Debian wheezy?
Hi, I don't quite understand. When I follow instructions from http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I seem to have different results. When I download/install the drivers on an Ubuntu 11.04 machine (it hasn't been updated in a while..) the em28xx driver is enabled in v4l/.config. When I try the same on a Debian stable (wheezy, kernel 3.2.0-4-amd64) install, the em28xx driver gets outcommented and not set in v4l/.config. If I enable it anyway, the driver won't load and produce errors like em28xx: Unknown symbol vb2_queue_init. Seemingly em28xx is disabled for a reason, but why? I would think Debian wheezy is in every way better (and newer) than Ubuntu 11.04. Am I missing some package? How can I fix it? Best regards, P. van Gaans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
