Re: SOLO6x10: fix a race in IRQ handler.
2014-11-15 1:33 GMT+04:00 Krzysztof Hałasa : > The SOLO IRQ controller does the common thing, all drivers (for chips > using the relatively modern "write 1 to clear") have to follow this > sequence: first ACK the interrupts sources (so they are deasserted, > though they can be asserted again if new events arrive), and only then > service the chip. Thanks for explanation. > I think my patch does exactly this, merges both writes. Ah right, sorry. -- Andrey Utkin -- 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
cron job: media_tree daily build: ERRORS
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: Sat Nov 15 04:00:21 CET 2014 git branch: test git hash: c02ef64aab828d80040b5dce934729312e698c33 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-2.slh.2-amd64 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.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16-i686: ERRORS linux-3.17-i686: ERRORS linux-3.18-rc1-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16-x86_64: ERRORS linux-3.17-x86_64: ERRORS linux-3.18-rc1-x86_64: ERRORS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
Re: [RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"
On Fri, Nov 14, 2014 at 05:09:55AM +0400, Andrey Utkin wrote: > There's no such thing as "list_struct". > > Signed-off-by: Andrey Utkin May as well get group rates on the acks... ;-) Acked-by: Paul E. McKenney > --- > drivers/gpu/drm/radeon/mkregtable.c | 24 > drivers/media/pci/cx18/cx18-driver.h | 2 +- > include/linux/list.h | 34 +- > include/linux/plist.h| 10 +- > include/linux/rculist.h | 8 > scripts/kconfig/list.h | 6 +++--- > tools/usb/usbip/libsrc/list.h| 2 +- > 7 files changed, 43 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/mkregtable.c > b/drivers/gpu/drm/radeon/mkregtable.c > index 4a85bb6..b928c17 100644 > --- a/drivers/gpu/drm/radeon/mkregtable.c > +++ b/drivers/gpu/drm/radeon/mkregtable.c > @@ -347,7 +347,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_entry - get the struct for this entry > * @ptr: the &struct list_head pointer. > * @type:the type of the struct this is embedded in. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_entry(ptr, type, member) \ > container_of(ptr, type, member) > @@ -356,7 +356,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_first_entry - get the first element from a list > * @ptr: the list head to take the element from. > * @type:the type of the struct this is embedded in. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Note, that list is expected to be not empty. > */ > @@ -406,7 +406,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry - iterate over list of given type > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_for_each_entry(pos, head, member) > \ > for (pos = list_entry((head)->next, typeof(*pos), member); \ > @@ -417,7 +417,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_reverse - iterate backwards over list of given type. > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_for_each_entry_reverse(pos, head, member) > \ > for (pos = list_entry((head)->prev, typeof(*pos), member); \ > @@ -428,7 +428,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_prepare_entry - prepare a pos entry for use in > list_for_each_entry_continue() > * @pos: the type * to use as a start point > * @head:the head of the list > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Prepares a pos entry for use as a start point in > list_for_each_entry_continue(). > */ > @@ -439,7 +439,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_continue - continue iteration over list of given type > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Continue to iterate over list of given type, continuing after > * the current position. > @@ -453,7 +453,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_continue_reverse - iterate backwards from the given > point > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Start to iterate over list of given type backwards, continuing after > * the current position. > @@ -467,7 +467,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_from - iterate over list of given type from the > current point > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Iterate over list of given type, continuing from current position. > */ > @@ -480,7 +480,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * @pos: the type * to u
Re: [PATCH 1/3] tuners: si2157: Si2148 support.
On 11/15/2014 03:22 AM, CrazyCat wrote: 2148 is 2158 without analog support. Same firmware. 15.11.2014, 03:02, "Antti Palosaari" : I wonder if we should define own firmware for Si2148-A20 just for sure. Olli? But still... I have seen one case where even same revision of si2168 needs different firmware. It is not very clear for me how SiLabs uses these firmwares, but at least it seems to be: * There is different versions done from same chips. A10 < A20 < A30 < B40 and so. I think that means digital logic inside of chip is changed when they change that revision number. * Every chip has a ROM, containing default firmware. Firmware which driver downloads is just a patch to that ROM. ROM is updated regularly when new patch of chips are manufactured. So currently I have feeling it is better to define as many firmware files as there chip revisions available, even same firmware works for multiple chip models/versions/revisions. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] tuners: si2157: Si2148 support.
2148 is 2158 without analog support. Same firmware. 15.11.2014, 03:02, "Antti Palosaari" : > I wonder if we should define own firmware for Si2148-A20 just for sure. > Olli? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] rtl28xxu: add support for Panasonic MN88472 slave demod
Em Sat, 15 Nov 2014 01:42:43 +0200
Antti Palosaari escreveu:
>
>
> On 11/14/2014 09:39 PM, Mauro Carvalho Chehab wrote:
> > Em Wed, 12 Nov 2014 06:23:06 +0200
> > Antti Palosaari escreveu:
> >
> >> There is RTL2832P devices having extra MN88472 demodulator. This
> >> patch add support for such configuration. Logically MN88472 slave
> >> demodulator is connected to RTL2832 master demodulator, both I2C
> >> bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
> >> chips. Chip version RTL2832P has extra TS interface for connecting
> >> slave demodulator.
> >>
> >> Signed-off-by: Antti Palosaari
> >> ---
> >> drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
> >> drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 143
> >> +---
> >> drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 5 ++
> >> 3 files changed, 118 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
> >> b/drivers/media/usb/dvb-usb-v2/Kconfig
> >> index 7423033..9050933 100644
> >> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> >> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> >> @@ -130,6 +130,7 @@ config DVB_USB_RTL28XXU
> >>select DVB_RTL2830
> >>select DVB_RTL2832
> >>select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT)
> >> + select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT
> >>select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> >>select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> >>select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT
> >
> > This is not a good idea, as the MN88472 is in staging.
> >
> > Select is not recursive, and won't select STAGING. Also, we don't want
> > to enable a staging driver by default on distros.
>
> I think it should work just fine. It is I2C driver. If distributions
> disables stating nothing will happen but MN88472 driver is not compiled.
> When there is no driver load, it will continue with reduced mode using
> single demod. I tested that scenario where driver was missing. Anyhow, I
> didn't test case where CONFIG_STAGING Kconfig option was disable, but I
> will do.
select will just ignore config_staging, enabling this driver even if
staging is disabled.
Perhaps one way to solve would be to do:
select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT && STAGING
Still, I the best would be to just remove that line, and add a
documentation on our wiki (and/or via printk) warning the user to
manually enable the driver on staging, if the user has a device that
needs it.
Regards,
Mauro
PS.: I'll do a deeper look on your comments about patch 2/8 likely
tomorrow or next week.
>
> regards
> Antti
>
>
> >
> >> diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> >> b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> >> index 5ea52c7..e3c20f4 100644
> >> --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> >> +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> >> @@ -24,6 +24,7 @@
> >>
> >> #include "rtl2830.h"
> >> #include "rtl2832.h"
> >> +#include "mn88472.h"
> >>
> >> #include "qt1010.h"
> >> #include "mt2060.h"
> >> @@ -420,6 +421,7 @@ static int rtl2832u_read_config(struct dvb_usb_device
> >> *d)
> >>struct rtl28xxu_req req_tda18272 = {0x00c0, CMD_I2C_RD, 2, buf};
> >>struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
> >>struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
> >> + struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
> >>
> >>dev_dbg(&d->udev->dev, "%s:\n", __func__);
> >>
> >> @@ -449,7 +451,7 @@ static int rtl2832u_read_config(struct dvb_usb_device
> >> *d)
> >>if (ret == 0 && buf[0] == 0xa1) {
> >>priv->tuner = TUNER_RTL2832_FC0012;
> >>priv->tuner_name = "FC0012";
> >> - goto found;
> >> + goto tuner_found;
> >>}
> >>
> >>/* check FC0013 ID register; reg=00 val=a3 */
> >> @@ -457,7 +459,7 @@ static int rtl2832u_read_config(struct dvb_usb_device
> >> *d)
> >>if (ret == 0 && buf[0] == 0xa3) {
> >>priv->tuner = TUNER_RTL2832_FC0013;
> >>priv->tuner_name = "FC0013";
> >> - goto found;
> >> + goto tuner_found;
> >>}
> >>
> >>/* check MT2266 ID register; reg=00 val=85 */
> >> @@ -465,7 +467,7 @@ static int rtl2832u_read_config(struct dvb_usb_device
> >> *d)
> >>if (ret == 0 && buf[0] == 0x85) {
> >>priv->tuner = TUNER_RTL2832_MT2266;
> >>priv->tuner_name = "MT2266";
> >> - goto found;
> >> + goto tuner_found;
> >>}
> >>
> >>/* check FC2580 ID register; reg=01 val=56 */
> >> @@ -473,7 +475,7 @@ static int rtl2832u_read_config(struct dvb_usb_device
> >> *d)
> >>if (ret == 0 && buf[0] == 0x56) {
> >>priv->tuner = TUNER_RTL2832_FC2580;
> >>priv->tuner_name = "FC2580";
> >> - goto found;
> >> + goto tuner_found;
> >>}
> >>
> >>/* check MT2063 ID register; reg=00 val=9e || 9c */
> >> @@ -481,7 +483,7 @@ static int rtl2
Re: [PATCH 1/3] tuners: si2157: Si2148 support.
Hello
I wonder if we should define own firmware for Si2148-A20 just for sure.
Olli?
regards
Antti
On 11/14/2014 11:19 PM, CrazyCat wrote:
Si2148-A20 silicon tuner support.
Signed-off-by: Evgeny Plehov
---
drivers/media/tuners/si2157.c | 10 ++
drivers/media/tuners/si2157.h | 2 +-
drivers/media/tuners/si2157_priv.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 25146fa..91f8290 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
@@ -112,11 +112,13 @@ static int si2157_init(struct dvb_frontend *fe)
cmd.args[4] << 0;
#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
+ #define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
switch (chip_id) {
case SI2158_A20:
+ case SI2148_A20:
fw_file = SI2158_A20_FIRMWARE;
break;
case SI2157_A30:
@@ -309,7 +311,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe,
u32 *frequency)
static const struct dvb_tuner_ops si2157_ops = {
.info = {
- .name = "Silicon Labs Si2157/Si2158",
+ .name = "Silicon Labs Si2147/2148/2157/Si2158",
.frequency_min = 11000,
.frequency_max = 86200,
},
@@ -373,7 +375,7 @@ static int si2157_probe(struct i2c_client *client,
i2c_set_clientdata(client, s);
dev_info(&s->client->dev,
- "Silicon Labs Si2157/Si2158 successfully attached\n");
+ "Silicon Labs Si2147/2148/2157/Si2158 successfully
attached\n");
return 0;
err:
dev_dbg(&client->dev, "failed=%d\n", ret);
@@ -414,7 +416,7 @@ static struct i2c_driver si2157_driver = {
module_i2c_driver(si2157_driver);
-MODULE_DESCRIPTION("Silicon Labs Si2157/Si2158 silicon tuner driver");
+MODULE_DESCRIPTION("Silicon Labs Si2147/2148/2157/Si2158 silicon tuner
driver");
MODULE_AUTHOR("Antti Palosaari ");
MODULE_LICENSE("GPL");
MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
diff --git a/drivers/media/tuners/si2157.h b/drivers/media/tuners/si2157.h
index d3b19ca..c439d0e 100644
--- a/drivers/media/tuners/si2157.h
+++ b/drivers/media/tuners/si2157.h
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
diff --git a/drivers/media/tuners/si2157_priv.h
b/drivers/media/tuners/si2157_priv.h
index e71ffaf..6d2aac4 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] rtl28xxu: add support for Panasonic MN88472 slave demod
On 11/14/2014 09:39 PM, Mauro Carvalho Chehab wrote:
Em Wed, 12 Nov 2014 06:23:06 +0200
Antti Palosaari escreveu:
There is RTL2832P devices having extra MN88472 demodulator. This
patch add support for such configuration. Logically MN88472 slave
demodulator is connected to RTL2832 master demodulator, both I2C
bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
chips. Chip version RTL2832P has extra TS interface for connecting
slave demodulator.
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 143 +---
drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 5 ++
3 files changed, 118 insertions(+), 31 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 7423033..9050933 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -130,6 +130,7 @@ config DVB_USB_RTL28XXU
select DVB_RTL2830
select DVB_RTL2832
select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT)
+ select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT
This is not a good idea, as the MN88472 is in staging.
Select is not recursive, and won't select STAGING. Also, we don't want
to enable a staging driver by default on distros.
I think it should work just fine. It is I2C driver. If distributions
disables stating nothing will happen but MN88472 driver is not compiled.
When there is no driver load, it will continue with reduced mode using
single demod. I tested that scenario where driver was missing. Anyhow, I
didn't test case where CONFIG_STAGING Kconfig option was disable, but I
will do.
regards
Antti
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 5ea52c7..e3c20f4 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -24,6 +24,7 @@
#include "rtl2830.h"
#include "rtl2832.h"
+#include "mn88472.h"
#include "qt1010.h"
#include "mt2060.h"
@@ -420,6 +421,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
struct rtl28xxu_req req_tda18272 = {0x00c0, CMD_I2C_RD, 2, buf};
struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
+ struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
dev_dbg(&d->udev->dev, "%s:\n", __func__);
@@ -449,7 +451,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0xa1) {
priv->tuner = TUNER_RTL2832_FC0012;
priv->tuner_name = "FC0012";
- goto found;
+ goto tuner_found;
}
/* check FC0013 ID register; reg=00 val=a3 */
@@ -457,7 +459,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0xa3) {
priv->tuner = TUNER_RTL2832_FC0013;
priv->tuner_name = "FC0013";
- goto found;
+ goto tuner_found;
}
/* check MT2266 ID register; reg=00 val=85 */
@@ -465,7 +467,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x85) {
priv->tuner = TUNER_RTL2832_MT2266;
priv->tuner_name = "MT2266";
- goto found;
+ goto tuner_found;
}
/* check FC2580 ID register; reg=01 val=56 */
@@ -473,7 +475,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x56) {
priv->tuner = TUNER_RTL2832_FC2580;
priv->tuner_name = "FC2580";
- goto found;
+ goto tuner_found;
}
/* check MT2063 ID register; reg=00 val=9e || 9c */
@@ -481,7 +483,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && (buf[0] == 0x9e || buf[0] == 0x9c)) {
priv->tuner = TUNER_RTL2832_MT2063;
priv->tuner_name = "MT2063";
- goto found;
+ goto tuner_found;
}
/* check MAX3543 ID register; reg=00 val=38 */
@@ -489,7 +491,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x38) {
priv->tuner = TUNER_RTL2832_MAX3543;
priv->tuner_name = "MAX3543";
- goto found;
+ goto tuner_found;
}
/* check TUA9001 ID register; reg=7e val=2328 */
@@ -497,7 +499,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
if (ret == 0 && buf[0] == 0x23 && buf[1] == 0x28) {
priv->tuner = TUNER_RTL2832_TUA9001;
Re: [PATCH 2/8] rtl2832: implement PIP mode
Moikka!
On 11/14/2014 09:34 PM, Mauro Carvalho Chehab wrote:
Em Wed, 12 Nov 2014 06:23:04 +0200
Antti Palosaari escreveu:
Implement PIP mode to stream from slave demodulator. PIP mode is
enabled when .set_frontend is called with RF frequency 0, otherwise
normal demod mode is enabled.
This would be an API change, so, a DocBook patch is required.
You are wrong. PIP mode is driver/device internal thing and will not be
revealed to userspace.
Anyway, using frequency=0 for PIP doesn't seem to be a good idea,
as a read from GET_PROPERTY should override the cache with the real
frequency.
Yes, it is a hackish solution, used to put demod#0 on certain config
when demod#1 is used. When PIP mode is set that demod#0 is totally
useless as demod#1 is in use instead. Cache is garbage and no meaning at
all.
Also, someone came with me with a case where auto-frequency would
be interesting, and proposed frequency=0. I was not convinced
(and patches weren't sent), but using 0 for AUTO seems more
appropriate, as we do the same for bandwidth (and may do the same
for symbol_rate).
I totally agree that is is hackish solution. That is called from
rtl28xxu.c driver and I added already comment it is hackish solution,
but you didn't apply that commit.
So, the best seems to add a new property to enable PIP mode.
No, no, no. It is like a PIP filter. It is actually special case of PID
filter, having mux, to multiplex 2 TS interfaces to one (PIP = Picture
in Picture).
.
. RTL2832P integrates RTL2832 demodulator .
. .
.| USB IF | | demod| . | demod|
.|| || . ||
.| RTL2832P | | RTL2832 | . | MN88472 |
.||TS bus|-/ -|-.---TS bus||
.|| || . ||
.
So the basically both demod PID filters are now implemented in RTL2832
demod. Currently PIP mode is configured just to pass all the PIDs from
MN88472 and reject RTL2832 PIDs. And when PIP mode is off, at pass all
the PIDs from RTL2832, but rejects all PIDs from MN88472.
regards
Antti
Regards,
Mauro
Signed-off-by: Antti Palosaari
---
drivers/media/dvb-frontends/rtl2832.c | 42 ---
1 file changed, 39 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index eb737cf..a58b456 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -258,13 +258,11 @@ static int rtl2832_rd_regs(struct rtl2832_priv *priv, u8
reg, u8 page, u8 *val,
return rtl2832_rd(priv, reg, val, len);
}
-#if 0 /* currently not used */
/* write single register */
static int rtl2832_wr_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8 val)
{
return rtl2832_wr_regs(priv, reg, page, &val, 1);
}
-#endif
/* read single register */
static int rtl2832_rd_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8 *val)
@@ -595,6 +593,44 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
"%s: frequency=%d bandwidth_hz=%d inversion=%d\n",
__func__, c->frequency, c->bandwidth_hz, c->inversion);
+ /* PIP mode */
+ if (c->frequency == 0) {
+ dev_dbg(&priv->i2c->dev, "%s: setting PIP mode\n", __func__);
+ ret = rtl2832_wr_regs(priv, 0x0c, 1, "\x5f\xff", 2);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_demod_reg(priv, DVBT_PIP_ON, 0x1);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_reg(priv, 0xbc, 0, 0x18);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_reg(priv, 0x22, 0, 0x01);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_reg(priv, 0x26, 0, 0x1f);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_reg(priv, 0x27, 0, 0xff);
+ if (ret)
+ goto err;
+
+ ret = rtl2832_wr_regs(priv, 0x92, 1, "\x7f\xf7\xff", 3);
+ if (ret)
+ goto err;
+
+ goto exit_soft_reset;
+ } else {
+ ret = rtl2832_wr_regs(priv, 0x92, 1, "\x00\x0f\xff", 3);
+ if (ret)
+ goto err;
+ }
+
/* program tuner */
if (fe->ops.tuner_ops.set_params)
fe->ops.tuner_ops.set_params(fe);
@@ -661,7 +697,7 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
-
+exit_soft_reset:
/* soft reset */
ret = rtl2832_wr_dem
RE: [RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"
> -Original Message- > From: Andrey Utkin [mailto:andrey.krieger.ut...@gmail.com] > Sent: Thursday, November 13, 2014 8:10 PM > To: linux-...@vger.kernel.org; linux-kbu...@vger.kernel.org; linux- > me...@vger.kernel.org; linux-ker...@vger.kernel.org; dri- > de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org; > gre...@linuxfoundation.org; mgor...@suse.de; ddstr...@ieee.org; > jeffrey.t.kirs...@intel.com; yamad...@jp.panasonic.com; > kenhel...@firemail.de; o...@redhat.com; a...@linux-foundation.org; > shuah...@samsung.com; valentina.mane...@gmail.com; > yann.morin.1...@free.fr; la...@cn.fujitsu.com; > mathieu.desnoy...@efficios.com; rost...@goodmis.org; > j...@joshtriplett.org; paul...@linux.vnet.ibm.com; > m.che...@samsung.com; awa...@md.metrocast.net; airl...@linux.ie; > Koenig, Christian; Deucher, Alexander; triv...@kernel.org > Cc: Andrey Utkin > Subject: [RESUBMIT] [PATCH] Replace mentions of "list_struct" to > "list_head" > > There's no such thing as "list_struct". > > Signed-off-by: Andrey Utkin Acked-by: Alex Deucher > --- > drivers/gpu/drm/radeon/mkregtable.c | 24 > drivers/media/pci/cx18/cx18-driver.h | 2 +- > include/linux/list.h | 34 +- > include/linux/plist.h| 10 +- > include/linux/rculist.h | 8 > scripts/kconfig/list.h | 6 +++--- > tools/usb/usbip/libsrc/list.h| 2 +- > 7 files changed, 43 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/mkregtable.c > b/drivers/gpu/drm/radeon/mkregtable.c > index 4a85bb6..b928c17 100644 > --- a/drivers/gpu/drm/radeon/mkregtable.c > +++ b/drivers/gpu/drm/radeon/mkregtable.c > @@ -347,7 +347,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_entry - get the struct for this entry > * @ptr: the &struct list_head pointer. > * @type:the type of the struct this is embedded in. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_entry(ptr, type, member) \ > container_of(ptr, type, member) > @@ -356,7 +356,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_first_entry - get the first element from a list > * @ptr: the list head to take the element from. > * @type:the type of the struct this is embedded in. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Note, that list is expected to be not empty. > */ > @@ -406,7 +406,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry - iterate over list of given type > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_for_each_entry(pos, head, member) > \ > for (pos = list_entry((head)->next, typeof(*pos), member); \ > @@ -417,7 +417,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_reverse - iterate backwards over list of given type. > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > */ > #define list_for_each_entry_reverse(pos, head, member) > \ > for (pos = list_entry((head)->prev, typeof(*pos), member); \ > @@ -428,7 +428,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_prepare_entry - prepare a pos entry for use in > list_for_each_entry_continue() > * @pos: the type * to use as a start point > * @head:the head of the list > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Prepares a pos entry for use as a start point in > list_for_each_entry_continue(). > */ > @@ -439,7 +439,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_continue - continue iteration over list of given type > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct within the struct. > + * @member: the name of the list_head within the struct. > * > * Continue to iterate over list of given type, continuing after > * the current position. > @@ -453,7 +453,7 @@ static inline void list_splice_tail_init(struct list_head > *list, > * list_for_each_entry_continue_reverse - iterate backwards from the given > point > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > - * @member: the name of the list_struct
[GIT PULL FOR v3.19] omap24xx/tcm825x: remove deprecated omap2 camera drivers
The omap2 camera driver has been deprecated for a year and it is now time to remove it. It is unmaintained and it uses an internal API that has long since been superseded by a much better API. Worse, that internal API has been abused by out-of-kernel trees (i.MX6). In addition, Sakari stated that these drivers have never been in a usable state in the mainline kernel due to missing platform data. Regards, Hans The following changes since commit dd0a6fe2bc3055cd61e369f97982c88183b1f0a0: [media] dvb-usb-dvbsky: fix i2c adapter for sp2 device (2014-11-11 12:55:32 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git omap24xx for you to fetch changes up to edfb7368e96f0a83f4f80ebd33b4dac81f13e707: omap24xx/tcm825x: remove deprecated omap2 camera drivers. (2014-11-14 23:15:12 +0100) Hans Verkuil (2): mach-omap2: remove deprecated VIDEO_OMAP2 support omap24xx/tcm825x: remove deprecated omap2 camera drivers. arch/arm/mach-omap2/devices.c| 31 - drivers/staging/media/Kconfig|2 - drivers/staging/media/Makefile |2 - drivers/staging/media/omap24xx/Kconfig | 35 -- drivers/staging/media/omap24xx/Makefile |5 - drivers/staging/media/omap24xx/omap24xxcam-dma.c | 598 --- drivers/staging/media/omap24xx/omap24xxcam.c | 1882 --- drivers/staging/media/omap24xx/omap24xxcam.h | 596 --- drivers/staging/media/omap24xx/tcm825x.c | 938 - drivers/staging/media/omap24xx/tcm825x.h | 200 --- drivers/staging/media/omap24xx/v4l2-int-device.c | 164 -- drivers/staging/media/omap24xx/v4l2-int-device.h | 305 -- 12 files changed, 4758 deletions(-) delete mode 100644 drivers/staging/media/omap24xx/Kconfig delete mode 100644 drivers/staging/media/omap24xx/Makefile delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam-dma.c delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam.c delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam.h delete mode 100644 drivers/staging/media/omap24xx/tcm825x.c delete mode 100644 drivers/staging/media/omap24xx/tcm825x.h delete mode 100644 drivers/staging/media/omap24xx/v4l2-int-device.c delete mode 100644 drivers/staging/media/omap24xx/v4l2-int-device.h -- 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] exynos4-is: fix error handling of irq_of_parse_and_map
Return value of irq_of_parse_and_map() is unsigned int, with 0
indicating failure, so testing for negative result never works.
Signed-off-by: Dmitry Torokhov
---
Not tested, found by casual code inspection.
drivers/media/platform/exynos4-is/fimc-is.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-is.c
b/drivers/media/platform/exynos4-is/fimc-is.c
index 94c6b47..0fdca86 100644
--- a/drivers/media/platform/exynos4-is/fimc-is.c
+++ b/drivers/media/platform/exynos4-is/fimc-is.c
@@ -814,9 +814,9 @@ static int fimc_is_probe(struct platform_device *pdev)
return -ENOMEM;
is->irq = irq_of_parse_and_map(dev->of_node, 0);
- if (is->irq < 0) {
+ if (!is->irq) {
dev_err(dev, "no irq found\n");
- return is->irq;
+ return -EINVAL;
}
ret = fimc_is_get_clocks(is);
--
2.1.0.rc2.206.gedb03e5
--
Dmitry
--
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: SOLO6x10: fix a race in IRQ handler.
Andrey Utkin writes: > could you please point to some reading which explains this moment? Or > you just know this from experience? The solo device specs are very > terse about this, so I considered that it should work fine without > regard to how fast we write back to that register. The SOLO IRQ controller does the common thing, all drivers (for chips using the relatively modern "write 1 to clear") have to follow this sequence: first ACK the interrupts sources (so they are deasserted, though they can be asserted again if new events arrive), and only then service the chip. > Also while you're at it, and if this really makes sense, you could > merge these two writes (unrecognized bits, then recognized bits) to > one write act. I think my patch does exactly this, merges both writes. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] si2168: TS clock inversion control.
TS clock polarity control implemented.
Signed-off-by: Evgeny Plehov
---
drivers/media/dvb-frontends/si2168.c | 7 +--
drivers/media/dvb-frontends/si2168.h | 4
drivers/media/dvb-frontends/si2168_priv.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 7bac748..16a347a 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -308,14 +308,16 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- memcpy(cmd.args, "\x14\x00\x09\x10\xe3\x18", 6);
+ memcpy(cmd.args, "\x14\x00\x09\x10\xe3\x08", 6);
+ cmd.args[5] |= s->ts_clock_inv ? 0x00 : 0x10;
cmd.wlen = 6;
cmd.rlen = 4;
ret = si2168_cmd_execute(s, &cmd);
if (ret)
goto err;
- memcpy(cmd.args, "\x14\x00\x08\x10\xd7\x15", 6);
+ memcpy(cmd.args, "\x14\x00\x08\x10\xd7\x05", 6);
+ cmd.args[5] |= s->ts_clock_inv ? 0x00 : 0x10;
cmd.wlen = 6;
cmd.rlen = 4;
ret = si2168_cmd_execute(s, &cmd);
@@ -669,6 +671,7 @@ static int si2168_probe(struct i2c_client *client,
*config->i2c_adapter = s->adapter;
*config->fe = &s->fe;
s->ts_mode = config->ts_mode;
+ s->ts_clock_inv = config->ts_clock_inv;
s->fw_loaded = false;
i2c_set_clientdata(client, s);
diff --git a/drivers/media/dvb-frontends/si2168.h
b/drivers/media/dvb-frontends/si2168.h
index e086d67..87bc121 100644
--- a/drivers/media/dvb-frontends/si2168.h
+++ b/drivers/media/dvb-frontends/si2168.h
@@ -37,6 +37,10 @@ struct si2168_config {
/* TS mode */
u8 ts_mode;
+
+ /* TS clock inverted */
+ bool ts_clock_inv;
+
};
#define SI2168_TS_PARALLEL 0x06
diff --git a/drivers/media/dvb-frontends/si2168_priv.h
b/drivers/media/dvb-frontends/si2168_priv.h
index 132df67..66ed675 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -36,6 +36,7 @@ struct si2168 {
fe_delivery_system_t delivery_system;
fe_status_t fe_status;
u8 ts_mode;
+ bool ts_clock_inv;
bool active;
bool fw_loaded;
};
--
1.9.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
[PATCH 3/3] cxusb: Geniatech T230 support.
Geniatech Mygica T230 DVB-T/T2/C USB stick support.
Signed-off-by: Evgeny Plehov
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/usb/dvb-usb/cxusb.c| 127 +++
2 files changed, 128 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index e07a84e..80ab8d0 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -356,6 +356,7 @@
#define USB_PID_MSI_DIGI_VOX_MINI_III 0x8807
#define USB_PID_SONY_PLAYTV0x0003
#define USB_PID_MYGICA_D6890xd811
+#define USB_PID_MYGICA_T2300xc688
#define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
#define USB_PID_ELGATO_EYETV_DTT 0x0021
#define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index b46f84d..7346698 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1408,6 +1408,76 @@ static int cxusb_mygica_d689_frontend_attach(struct
dvb_usb_adapter *adap)
return 0;
}
+static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+{
+ struct dvb_usb_device *d = adap->dev;
+ struct cxusb_state *st = d->priv;
+ struct i2c_adapter *adapter;
+ struct i2c_client *client_demod;
+ struct i2c_client *client_tuner;
+ struct i2c_board_info info;
+ struct si2168_config si2168_config;
+ struct si2157_config si2157_config;
+
+ /* Select required USB configuration */
+ if (usb_set_interface(d->udev, 0, 0) < 0)
+ err("set interface failed");
+
+ /* Unblock all USB pipes */
+ usb_clear_halt(d->udev,
+ usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
+ usb_clear_halt(d->udev,
+ usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint));
+ usb_clear_halt(d->udev,
+ usb_rcvbulkpipe(d->udev,
d->props.adapter[0].fe[0].stream.endpoint));
+
+ /* attach frontend */
+ si2168_config.i2c_adapter = &adapter;
+ si2168_config.fe = &adap->fe_adap[0].fe;
+ si2168_config.ts_mode = SI2168_TS_PARALLEL;
+ si2168_config.ts_clock_inv = 1;
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "si2168", I2C_NAME_SIZE);
+ info.addr = 0x64;
+ info.platform_data = &si2168_config;
+ request_module(info.type);
+ client_demod = i2c_new_device(&d->i2c_adap, &info);
+ if (client_demod == NULL || client_demod->dev.driver == NULL)
+ return -ENODEV;
+
+ if (!try_module_get(client_demod->dev.driver->owner)) {
+ i2c_unregister_device(client_demod);
+ return -ENODEV;
+ }
+
+ st->i2c_client_demod = client_demod;
+
+ /* attach tuner */
+ memset(&si2157_config, 0, sizeof(si2157_config));
+ si2157_config.fe = adap->fe_adap[0].fe;
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+ info.addr = 0x60;
+ info.platform_data = &si2157_config;
+ request_module(info.type);
+ client_tuner = i2c_new_device(adapter, &info);
+ if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
+ module_put(client_demod->dev.driver->owner);
+ i2c_unregister_device(client_demod);
+ return -ENODEV;
+ }
+ if (!try_module_get(client_tuner->dev.driver->owner)) {
+ i2c_unregister_device(client_tuner);
+ module_put(client_demod->dev.driver->owner);
+ i2c_unregister_device(client_demod);
+ return -ENODEV;
+ }
+
+ st->i2c_client_tuner = client_tuner;
+
+ return 0;
+}
+
static int cxusb_tt_ct2_4400_attach(struct dvb_usb_adapter *adap)
{
struct dvb_usb_device *d = adap->dev;
@@ -1609,6 +1679,7 @@ static struct dvb_usb_device_properties
cxusb_bluebird_nano2_needsfirmware_prope
static struct dvb_usb_device_properties cxusb_aver_a868r_properties;
static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
static struct dvb_usb_device_properties cxusb_tt_ct2_4400_properties;
static int cxusb_probe(struct usb_interface *intf,
@@ -1640,6 +1711,8 @@ static int cxusb_probe(struct usb_interface *intf,
THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, &cxusb_mygica_d689_properties,
THIS_MODULE, NULL, adapter_nr) ||
+ 0 == dvb_usb_device_init(intf, &cxusb_mygica_t230_properties,
+THIS_MODULE, NULL, a
[PATCH 1/3] tuners: si2157: Si2148 support.
Si2148-A20 silicon tuner support.
Signed-off-by: Evgeny Plehov
---
drivers/media/tuners/si2157.c | 10 ++
drivers/media/tuners/si2157.h | 2 +-
drivers/media/tuners/si2157_priv.h | 2 +-
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 25146fa..91f8290 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
@@ -112,11 +112,13 @@ static int si2157_init(struct dvb_frontend *fe)
cmd.args[4] << 0;
#define SI2158_A20 ('A' << 24 | 58 << 16 | '2' << 8 | '0' << 0)
+ #define SI2148_A20 ('A' << 24 | 48 << 16 | '2' << 8 | '0' << 0)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
switch (chip_id) {
case SI2158_A20:
+ case SI2148_A20:
fw_file = SI2158_A20_FIRMWARE;
break;
case SI2157_A30:
@@ -309,7 +311,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe,
u32 *frequency)
static const struct dvb_tuner_ops si2157_ops = {
.info = {
- .name = "Silicon Labs Si2157/Si2158",
+ .name = "Silicon Labs Si2147/2148/2157/Si2158",
.frequency_min = 11000,
.frequency_max = 86200,
},
@@ -373,7 +375,7 @@ static int si2157_probe(struct i2c_client *client,
i2c_set_clientdata(client, s);
dev_info(&s->client->dev,
- "Silicon Labs Si2157/Si2158 successfully attached\n");
+ "Silicon Labs Si2147/2148/2157/Si2158 successfully
attached\n");
return 0;
err:
dev_dbg(&client->dev, "failed=%d\n", ret);
@@ -414,7 +416,7 @@ static struct i2c_driver si2157_driver = {
module_i2c_driver(si2157_driver);
-MODULE_DESCRIPTION("Silicon Labs Si2157/Si2158 silicon tuner driver");
+MODULE_DESCRIPTION("Silicon Labs Si2147/2148/2157/Si2158 silicon tuner
driver");
MODULE_AUTHOR("Antti Palosaari ");
MODULE_LICENSE("GPL");
MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
diff --git a/drivers/media/tuners/si2157.h b/drivers/media/tuners/si2157.h
index d3b19ca..c439d0e 100644
--- a/drivers/media/tuners/si2157.h
+++ b/drivers/media/tuners/si2157.h
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
diff --git a/drivers/media/tuners/si2157_priv.h
b/drivers/media/tuners/si2157_priv.h
index e71ffaf..6d2aac4 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -1,5 +1,5 @@
/*
- * Silicon Labs Si2147/2157/2158 silicon tuner driver
+ * Silicon Labs Si2147/2148/2157/2158 silicon tuner driver
*
* Copyright (C) 2014 Antti Palosaari
*
--
1.9.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: [RESUBMIT] [PATCH] Replace mentions of "list_struct" to "list_head"
Em Thu, 13 Nov 2014 20:48:41 -0500 Steven Rostedt escreveu: > On Fri, 14 Nov 2014 05:09:55 +0400 > Andrey Utkin wrote: > > > There's no such thing as "list_struct". > > I guess there isn't. Indeed ;) > > > > > Signed-off-by: Andrey Utkin > > Acked-by: Steven Rostedt Acked-by: Mauro Carvalho Chehab > > -- Steve > > > --- > > drivers/gpu/drm/radeon/mkregtable.c | 24 > > drivers/media/pci/cx18/cx18-driver.h | 2 +- > > include/linux/list.h | 34 > > +- > > include/linux/plist.h| 10 +- > > include/linux/rculist.h | 8 > > scripts/kconfig/list.h | 6 +++--- > > tools/usb/usbip/libsrc/list.h| 2 +- > > 7 files changed, 43 insertions(+), 43 deletions(-) > > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] Panasonic MN8847 and MN88473
Em Fri, 14 Nov 2014 03:52:13 +0200 Antti Palosaari escreveu: > The following changes since commit dd0a6fe2bc3055cd61e369f97982c88183b1f0a0: > >[media] dvb-usb-dvbsky: fix i2c adapter for sp2 device (2014-11-11 > 12:55:32 -0200) > > are available in the git repository at: > >git://linuxtv.org/anttip/media_tree.git astrometa > > for you to fetch changes up to 9e0d9707648a6ef3def5a468ac57047bf8632d29: > >rtl28xxu: add SDR module for devices having R828D tuner (2014-11-12 > 05:58:07 +0200) > > > Antti Palosaari (28): >mn88472: Panasonic MN88472 demod driver (DVB-C only) >mn88472: correct attach symbol name >mn88472: add small delay to wait DVB-C lock >mn88472: rename mn88472_c.c => mn88472.c >mn88472: rename state to dev >mn88472: convert driver to I2C client >mn88472: Convert driver to I2C RegMap API >mn88472: implement DVB-T and DVB-T2 >mn88472: move to staging >mn88472: add staging TODO >MAINTAINERS: add mn88472 (Panasonic MN88472) >mn88473: Panasonic MN88473 DVB-T/T2/C demod driver >mn88473: add support for DVB-T2 >mn88473: implement DVB-T mode >mn88473: improve IF frequency and BW handling >mn88473: convert driver to I2C binding >mn88473: convert to RegMap API >mn88473: move to staging >mn88473: add staging TODO >MAINTAINERS: add mn88473 (Panasonic MN88473) >r820t: add DVB-C config Applied, thanks. >rtl2832: implement PIP mode Not applied - need API discussions. >rtl28xxu: enable demod ADC only when needed Applied, thanks. >rtl28xxu: add support for Panasonic MN88472 slave demod >rtl28xxu: add support for Panasonic MN88473 slave demod >rtl28xxu: rename tuner I2C client pointer >rtl28xxu: remove unused SDR attach logic >rtl28xxu: add SDR module for devices having R828D tuner Not applied, due to the staging dependencies, as explained. I opted to not apply the patches after "add support for Panasonic MN88472", to avoid merging troubles. Regards, Mauro > > MAINTAINERS | 22 +++ > drivers/media/dvb-frontends/mn88472.h| 38 > drivers/media/dvb-frontends/mn88473.h| 38 > drivers/media/dvb-frontends/rtl2832.c| 42 - > drivers/media/tuners/r820t.c | 12 > drivers/media/usb/dvb-usb-v2/Kconfig | 2 + > drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 239 > > drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 8 ++- > drivers/staging/media/Kconfig| 4 ++ > drivers/staging/media/Makefile | 2 + > drivers/staging/media/mn88472/Kconfig| 7 +++ > drivers/staging/media/mn88472/Makefile | 5 ++ > drivers/staging/media/mn88472/TODO | 21 +++ > drivers/staging/media/mn88472/mn88472.c | 523 > ++ > drivers/staging/media/mn88472/mn88472_priv.h | 36 +++ > drivers/staging/media/mn88473/Kconfig| 7 +++ > drivers/staging/media/mn88473/Makefile | 5 ++ > drivers/staging/media/mn88473/TODO | 21 +++ > drivers/staging/media/mn88473/mn88473.c | 464 > > drivers/staging/media/mn88473/mn88473_priv.h | 36 +++ > 20 files changed, 1464 insertions(+), 68 deletions(-) > create mode 100644 drivers/media/dvb-frontends/mn88472.h > create mode 100644 drivers/media/dvb-frontends/mn88473.h > create mode 100644 drivers/staging/media/mn88472/Kconfig > create mode 100644 drivers/staging/media/mn88472/Makefile > create mode 100644 drivers/staging/media/mn88472/TODO > create mode 100644 drivers/staging/media/mn88472/mn88472.c > create mode 100644 drivers/staging/media/mn88472/mn88472_priv.h > create mode 100644 drivers/staging/media/mn88473/Kconfig > create mode 100644 drivers/staging/media/mn88473/Makefile > create mode 100644 drivers/staging/media/mn88473/TODO > create mode 100644 drivers/staging/media/mn88473/mn88473.c > create mode 100644 drivers/staging/media/mn88473/mn88473_priv.h > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] rtl28xxu: add support for Panasonic MN88473 slave demod
Em Wed, 12 Nov 2014 06:23:07 +0200
Antti Palosaari escreveu:
> There is RTL2832P devices having extra MN88473 demodulator. This
> patch add support for such configuration. Logically MN88473 slave
> demodulator is connected to RTL2832 master demodulator, both I2C
> bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
> chips. Chip version RTL2832P has extra TS interface for connecting
> slave demodulator.
>
> Signed-off-by: Antti Palosaari
> ---
> drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
> drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 31 +++
> drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 3 ++-
> 3 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
> b/drivers/media/usb/dvb-usb-v2/Kconfig
> index 9050933..f452a11 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> @@ -131,6 +131,7 @@ config DVB_USB_RTL28XXU
> select DVB_RTL2832
> select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT)
> select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT
> + select DVB_MN88473 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT
This is not a good idea, as the MN88473 is in staging.
Select is not recursive, and won't select STAGING. Also, we don't want
to enable a staging driver by default on distros.
> diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> index e3c20f4..93f8afc 100644
> --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> @@ -25,6 +25,7 @@
> #include "rtl2830.h"
> #include "rtl2832.h"
> #include "mn88472.h"
> +#include "mn88473.h"
>
> #include "qt1010.h"
> #include "mt2060.h"
> @@ -422,6 +423,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
> struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
> struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
> + struct rtl28xxu_req req_mn88473 = {0xff38, CMD_I2C_RD, 1, buf};
>
> dev_dbg(&d->udev->dev, "%s:\n", __func__);
>
> @@ -567,6 +569,13 @@ tuner_found:
> priv->slave_demod = SLAVE_DEMOD_MN88472;
> goto demod_found;
> }
> +
> + ret = rtl28xxu_ctrl_msg(d, &req_mn88473);
> + if (ret == 0 && buf[0] == 0x03) {
> + dev_dbg(&d->udev->dev, "%s: MN88473 found\n", __func__);
> + priv->slave_demod = SLAVE_DEMOD_MN88473;
> + goto demod_found;
> + }
> }
>
> demod_found:
> @@ -889,6 +898,28 @@ static int rtl2832u_frontend_attach(struct
> dvb_usb_adapter *adap)
> }
>
> priv->i2c_client_slave_demod = client;
> + } else {
> + struct mn88473_config mn88473_config = {};
> +
> + mn88473_config.fe = &adap->fe[1];
> + mn88473_config.i2c_wr_max = 22,
> + strlcpy(info.type, "mn88473", I2C_NAME_SIZE);
> + info.addr = 0x18;
> + info.platform_data = &mn88473_config;
> + request_module(info.type);
> + client = i2c_new_device(priv->demod_i2c_adapter, &info);
> + if (client == NULL || client->dev.driver == NULL) {
> + priv->slave_demod = SLAVE_DEMOD_NONE;
> + goto err_slave_demod_failed;
> + }
> +
> + if (!try_module_get(client->dev.driver->owner)) {
> + i2c_unregister_device(client);
> + priv->slave_demod = SLAVE_DEMOD_NONE;
> + goto err_slave_demod_failed;
> + }
> +
> + priv->i2c_client_slave_demod = client;
> }
>
> /* override init as we want configure RTL2832 as TS input */
> diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
> b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
> index 58f2730..9c059ac 100644
> --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
> +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
> @@ -62,7 +62,8 @@ struct rtl28xxu_priv {
> int (*init)(struct dvb_frontend *fe);
> #define SLAVE_DEMOD_NONE 0
> #define SLAVE_DEMOD_MN884721
> - unsigned int slave_demod:1;
> + #define SLAVE_DEMOD_MN884732
> + unsigned int slave_demod:2;
> };
>
> enum rtl28xxu_chip_id {
--
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.kerne
Re: [PATCH 4/8] rtl28xxu: add support for Panasonic MN88472 slave demod
Em Wed, 12 Nov 2014 06:23:06 +0200
Antti Palosaari escreveu:
> There is RTL2832P devices having extra MN88472 demodulator. This
> patch add support for such configuration. Logically MN88472 slave
> demodulator is connected to RTL2832 master demodulator, both I2C
> bus and TS input. RTL2832 is integrated to RTL2832U and RTL2832P
> chips. Chip version RTL2832P has extra TS interface for connecting
> slave demodulator.
>
> Signed-off-by: Antti Palosaari
> ---
> drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
> drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 143
> +---
> drivers/media/usb/dvb-usb-v2/rtl28xxu.h | 5 ++
> 3 files changed, 118 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
> b/drivers/media/usb/dvb-usb-v2/Kconfig
> index 7423033..9050933 100644
> --- a/drivers/media/usb/dvb-usb-v2/Kconfig
> +++ b/drivers/media/usb/dvb-usb-v2/Kconfig
> @@ -130,6 +130,7 @@ config DVB_USB_RTL28XXU
> select DVB_RTL2830
> select DVB_RTL2832
> select DVB_RTL2832_SDR if (MEDIA_SUBDRV_AUTOSELECT && MEDIA_SDR_SUPPORT)
> + select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_QT1010 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT
This is not a good idea, as the MN88472 is in staging.
Select is not recursive, and won't select STAGING. Also, we don't want
to enable a staging driver by default on distros.
> diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> index 5ea52c7..e3c20f4 100644
> --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
> @@ -24,6 +24,7 @@
>
> #include "rtl2830.h"
> #include "rtl2832.h"
> +#include "mn88472.h"
>
> #include "qt1010.h"
> #include "mt2060.h"
> @@ -420,6 +421,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> struct rtl28xxu_req req_tda18272 = {0x00c0, CMD_I2C_RD, 2, buf};
> struct rtl28xxu_req req_r820t = {0x0034, CMD_I2C_RD, 1, buf};
> struct rtl28xxu_req req_r828d = {0x0074, CMD_I2C_RD, 1, buf};
> + struct rtl28xxu_req req_mn88472 = {0xff38, CMD_I2C_RD, 1, buf};
>
> dev_dbg(&d->udev->dev, "%s:\n", __func__);
>
> @@ -449,7 +451,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0xa1) {
> priv->tuner = TUNER_RTL2832_FC0012;
> priv->tuner_name = "FC0012";
> - goto found;
> + goto tuner_found;
> }
>
> /* check FC0013 ID register; reg=00 val=a3 */
> @@ -457,7 +459,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0xa3) {
> priv->tuner = TUNER_RTL2832_FC0013;
> priv->tuner_name = "FC0013";
> - goto found;
> + goto tuner_found;
> }
>
> /* check MT2266 ID register; reg=00 val=85 */
> @@ -465,7 +467,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0x85) {
> priv->tuner = TUNER_RTL2832_MT2266;
> priv->tuner_name = "MT2266";
> - goto found;
> + goto tuner_found;
> }
>
> /* check FC2580 ID register; reg=01 val=56 */
> @@ -473,7 +475,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0x56) {
> priv->tuner = TUNER_RTL2832_FC2580;
> priv->tuner_name = "FC2580";
> - goto found;
> + goto tuner_found;
> }
>
> /* check MT2063 ID register; reg=00 val=9e || 9c */
> @@ -481,7 +483,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && (buf[0] == 0x9e || buf[0] == 0x9c)) {
> priv->tuner = TUNER_RTL2832_MT2063;
> priv->tuner_name = "MT2063";
> - goto found;
> + goto tuner_found;
> }
>
> /* check MAX3543 ID register; reg=00 val=38 */
> @@ -489,7 +491,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0x38) {
> priv->tuner = TUNER_RTL2832_MAX3543;
> priv->tuner_name = "MAX3543";
> - goto found;
> + goto tuner_found;
> }
>
> /* check TUA9001 ID register; reg=7e val=2328 */
> @@ -497,7 +499,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0x23 && buf[1] == 0x28) {
> priv->tuner = TUNER_RTL2832_TUA9001;
> priv->tuner_name = "TUA9001";
> - goto found;
> + goto tuner_found;
> }
>
> /* check MXL5007R ID register; reg=d9 val=14 */
> @@ -505,7 +507,7 @@ static int rtl2832u_read_config(struct dvb_usb_device *d)
> if (ret == 0 && buf[0] == 0x14) {
> priv->tuner = TUNER_RTL2832_MXL5007T;
>
Re: [PATCH 2/8] rtl2832: implement PIP mode
Em Wed, 12 Nov 2014 06:23:04 +0200
Antti Palosaari escreveu:
> Implement PIP mode to stream from slave demodulator. PIP mode is
> enabled when .set_frontend is called with RF frequency 0, otherwise
> normal demod mode is enabled.
This would be an API change, so, a DocBook patch is required.
Anyway, using frequency=0 for PIP doesn't seem to be a good idea,
as a read from GET_PROPERTY should override the cache with the real
frequency.
Also, someone came with me with a case where auto-frequency would
be interesting, and proposed frequency=0. I was not convinced
(and patches weren't sent), but using 0 for AUTO seems more
appropriate, as we do the same for bandwidth (and may do the same
for symbol_rate).
So, the best seems to add a new property to enable PIP mode.
Regards,
Mauro
>
> Signed-off-by: Antti Palosaari
> ---
> drivers/media/dvb-frontends/rtl2832.c | 42
> ---
> 1 file changed, 39 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/rtl2832.c
> b/drivers/media/dvb-frontends/rtl2832.c
> index eb737cf..a58b456 100644
> --- a/drivers/media/dvb-frontends/rtl2832.c
> +++ b/drivers/media/dvb-frontends/rtl2832.c
> @@ -258,13 +258,11 @@ static int rtl2832_rd_regs(struct rtl2832_priv *priv,
> u8 reg, u8 page, u8 *val,
> return rtl2832_rd(priv, reg, val, len);
> }
>
> -#if 0 /* currently not used */
> /* write single register */
> static int rtl2832_wr_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8 val)
> {
> return rtl2832_wr_regs(priv, reg, page, &val, 1);
> }
> -#endif
>
> /* read single register */
> static int rtl2832_rd_reg(struct rtl2832_priv *priv, u8 reg, u8 page, u8
> *val)
> @@ -595,6 +593,44 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
> "%s: frequency=%d bandwidth_hz=%d inversion=%d\n",
> __func__, c->frequency, c->bandwidth_hz, c->inversion);
>
> + /* PIP mode */
> + if (c->frequency == 0) {
> + dev_dbg(&priv->i2c->dev, "%s: setting PIP mode\n", __func__);
> + ret = rtl2832_wr_regs(priv, 0x0c, 1, "\x5f\xff", 2);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_demod_reg(priv, DVBT_PIP_ON, 0x1);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_reg(priv, 0xbc, 0, 0x18);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_reg(priv, 0x22, 0, 0x01);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_reg(priv, 0x26, 0, 0x1f);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_reg(priv, 0x27, 0, 0xff);
> + if (ret)
> + goto err;
> +
> + ret = rtl2832_wr_regs(priv, 0x92, 1, "\x7f\xf7\xff", 3);
> + if (ret)
> + goto err;
> +
> + goto exit_soft_reset;
> + } else {
> + ret = rtl2832_wr_regs(priv, 0x92, 1, "\x00\x0f\xff", 3);
> + if (ret)
> + goto err;
> + }
> +
> /* program tuner */
> if (fe->ops.tuner_ops.set_params)
> fe->ops.tuner_ops.set_params(fe);
> @@ -661,7 +697,7 @@ static int rtl2832_set_frontend(struct dvb_frontend *fe)
> if (ret)
> goto err;
>
> -
> +exit_soft_reset:
> /* soft reset */
> ret = rtl2832_wr_demod_reg(priv, DVBT_SOFT_RST, 0x1);
> if (ret)
--
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: SOLO6x10: fix a race in IRQ handler.
Also while you're at it, and if this really makes sense, you could merge these two writes (unrecognized bits, then recognized bits) to one write act. -- Andrey Utkin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mach-omap2: remove deprecated VIDEO_OMAP2 support
* Hans Verkuil [141114 01:25]:
> From: Hans Verkuil
>
> The omap2 camera driver has been deprecated for a year and is now
> going to be removed. It is unmaintained and it uses an internal API
> that has long since been superseded by a much better API. Worse, that
> internal API has been abused by out-of-kernel trees (i.MX6).
>
> In addition, Sakari stated that these drivers have never been in a
> usable state in the mainline kernel due to missing platform data.
>
> Signed-off-by: Hans Verkuil
> Cc: Sakari Ailus
> Cc: David Cohen
This applies with fuzz to what I have queued but should not
cause merge conflicts and should be safe to merge along with
other camera related patches:
Acked-by: Tony Lindgren
> ---
> arch/arm/mach-omap2/devices.c | 31 ---
> 1 file changed, 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
> index 324f02b..1b623a0 100644
> --- a/arch/arm/mach-omap2/devices.c
> +++ b/arch/arm/mach-omap2/devices.c
> @@ -101,28 +101,6 @@ static int __init omap4_l3_init(void)
> }
> omap_postcore_initcall(omap4_l3_init);
>
> -#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> -
> -static struct resource omap2cam_resources[] = {
> - {
> - .start = OMAP24XX_CAMERA_BASE,
> - .end= OMAP24XX_CAMERA_BASE + 0xfff,
> - .flags = IORESOURCE_MEM,
> - },
> - {
> - .start = 24 + OMAP_INTC_START,
> - .flags = IORESOURCE_IRQ,
> - }
> -};
> -
> -static struct platform_device omap2cam_device = {
> - .name = "omap24xxcam",
> - .id = -1,
> - .num_resources = ARRAY_SIZE(omap2cam_resources),
> - .resource = omap2cam_resources,
> -};
> -#endif
> -
> #if defined(CONFIG_IOMMU_API)
>
> #include
> @@ -245,14 +223,6 @@ int omap3_init_camera(struct isp_platform_data *pdata)
>
> #endif
>
> -static inline void omap_init_camera(void)
> -{
> -#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
> - if (cpu_is_omap24xx())
> - platform_device_register(&omap2cam_device);
> -#endif
> -}
> -
> #if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
> static inline void __init omap_init_mbox(void)
> {
> @@ -431,7 +401,6 @@ static int __init omap2_init_devices(void)
>* in alphabetical order so they're easier to sort through.
>*/
> omap_init_audio();
> - omap_init_camera();
> /* If dtb is there, the devices will be created dynamically */
> if (!of_have_populated_dt()) {
> omap_init_mbox();
> --
> 2.1.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR v3.19] si4713 improvements and vb2_start_streaming_called() helper
Hi Hans, On Fri, Nov 14, 2014 at 11:21:27AM +0100, Hans Verkuil wrote: > This is the full si4713 patch series (with some small changes to fix compiler > warnings), Thanks for taking care of this. -- Sebastian signature.asc Description: Digital signature
Re: [RFC PATCH 04/11] v4l2-ctrls: add config store support
Hi Hans,
Some comments below.
On Sun, Sep 21, 2014 at 04:48:22PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 150
> +--
> drivers/media/v4l2-core/v4l2-ioctl.c | 4 +-
> include/media/v4l2-ctrls.h | 14
> 3 files changed, 141 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index 35d1f3d..df0f3ee 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -1478,6 +1478,15 @@ static int cur_to_user(struct v4l2_ext_control *c,
> return ptr_to_user(c, ctrl, ctrl->p_cur);
> }
>
> +/* Helper function: copy the store's control value back to the caller */
> +static int store_to_user(struct v4l2_ext_control *c,
> +struct v4l2_ctrl *ctrl, unsigned store)
> +{
> + if (store == 0)
> + return ptr_to_user(c, ctrl, ctrl->p_new);
> + return ptr_to_user(c, ctrl, ctrl->p_stores[store - 1]);
> +}
> +
> /* Helper function: copy the new control value back to the caller */
> static int new_to_user(struct v4l2_ext_control *c,
> struct v4l2_ctrl *ctrl)
> @@ -1585,6 +1594,14 @@ static void new_to_cur(struct v4l2_fh *fh, struct
> v4l2_ctrl *ctrl, u32 ch_flags)
> }
> }
>
> +/* Helper function: copy the new control value to the store */
> +static void new_to_store(struct v4l2_ctrl *ctrl)
> +{
> + /* has_changed is set by cluster_changed */
> + if (ctrl && ctrl->has_changed)
> + ptr_to_ptr(ctrl, ctrl->p_new, ctrl->p_stores[ctrl->store - 1]);
> +}
> +
> /* Copy the current value to the new value */
> static void cur_to_new(struct v4l2_ctrl *ctrl)
> {
> @@ -1603,13 +1620,18 @@ static int cluster_changed(struct v4l2_ctrl *master)
>
> for (i = 0; i < master->ncontrols; i++) {
> struct v4l2_ctrl *ctrl = master->cluster[i];
> + union v4l2_ctrl_ptr ptr;
> bool ctrl_changed = false;
>
> if (ctrl == NULL)
> continue;
> + if (ctrl->store)
> + ptr = ctrl->p_stores[ctrl->store - 1];
> + else
> + ptr = ctrl->p_cur;
> for (idx = 0; !ctrl_changed && idx < ctrl->elems; idx++)
> ctrl_changed = !ctrl->type_ops->equal(ctrl, idx,
> - ctrl->p_cur, ctrl->p_new);
> + ptr, ctrl->p_new);
> ctrl->has_changed = ctrl_changed;
> changed |= ctrl->has_changed;
> }
> @@ -1740,6 +1762,13 @@ void v4l2_ctrl_handler_free(struct v4l2_ctrl_handler
> *hdl)
> list_del(&ctrl->node);
> list_for_each_entry_safe(sev, next_sev, &ctrl->ev_subs, node)
> list_del(&sev->node);
> + if (ctrl->p_stores) {
> + unsigned s;
> +
> + for (s = 0; s < ctrl->nr_of_stores; s++)
> + kfree(ctrl->p_stores[s].p);
> + }
> + kfree(ctrl->p_stores);
> kfree(ctrl);
> }
> kfree(hdl->buckets);
> @@ -1970,7 +1999,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> handler_set_err(hdl, -ERANGE);
> return NULL;
> }
> - if (is_array &&
> + if ((is_array || (flags & V4L2_CTRL_FLAG_CAN_STORE)) &&
> (type == V4L2_CTRL_TYPE_BUTTON ||
>type == V4L2_CTRL_TYPE_CTRL_CLASS)) {
> handler_set_err(hdl, -EINVAL);
> @@ -2084,8 +2113,10 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
> v4l2_ctrl_handler *hdl,
> is_menu ? cfg->menu_skip_mask : step, def,
> cfg->dims, cfg->elem_size,
> flags, qmenu, qmenu_int, priv);
> - if (ctrl)
> + if (ctrl) {
I think it'd be cleaner to return NULL here if ctrl == NULL. Up to you.
> ctrl->is_private = cfg->is_private;
> + ctrl->can_store = cfg->can_store;
> + }
> return ctrl;
> }
> EXPORT_SYMBOL(v4l2_ctrl_new_custom);
> @@ -2452,6 +2483,7 @@ int v4l2_ctrl_handler_setup(struct v4l2_ctrl_handler
> *hdl)
> cur_to_new(master->cluster[i]);
> master->cluster[i]->is_new = 1;
> master->cluster[i]->done = true;
> + master->cluster[i]->store = 0;
> }
> }
> ret = call_op(master, s_ctrl);
> @@ -2539,6 +2571,8 @@ int v4l2_query_ext_ctrl(struct v4l2_ctrl_handler *hdl,
> struct v4l2_query_ext_ctr
> qc->id = ctrl->id;
> strlcpy(qc->name, ctrl->name, sizeof(qc->name));
> qc->flags = ctrl->flags;
> + if (ctrl->can_store)
> + qc->flags |= V4L2_CTRL_FLAG_CAN_STORE;
> q
Re: [RFC PATCH 03/11] videodev2.h: rename reserved2 to config_store in v4l2_buffer.
Hi Hans,
One more comment...
On Sun, Sep 21, 2014 at 04:48:21PM +0200, Hans Verkuil wrote:
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 83ef28a..2ca44ed 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -672,6 +672,7 @@ struct v4l2_plane {
> * @length: size in bytes of the buffer (NOT its payload) for single-plane
> * buffers (when type != *_MPLANE); number of elements in the
> * planes array for multi-plane buffers
> + * @config_store: this buffer should use this configuration store
> *
> * Contains data exchanged by application and driver using one of the
> Streaming
> * I/O methods.
> @@ -695,7 +696,7 @@ struct v4l2_buffer {
> __s32 fd;
> } m;
> __u32 length;
> - __u32 reserved2;
> + __u32 config_store;
> __u32 reserved;
> };
>
I would use __u16 instead since the value is 16-bit on the control
interface.
--
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] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Hi Sakari, On Fri, 14 Nov 2014 15:58:31 +0200 Sakari Ailus wrote: > Hi Boris, > > On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote: > > Add RGB444_1X12 and RGB565_1X16 format definitions and update the > > documentation. > > > > Signed-off-by: Boris Brezillon > > Acked-by: Mauro Carvalho Chehab > > --- > > Documentation/DocBook/media/v4l/subdev-formats.xml | 40 > > ++ > > include/uapi/linux/media-bus-format.h | 4 ++- > > 2 files changed, 43 insertions(+), 1 deletion(-) > > > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > > b/Documentation/DocBook/media/v4l/subdev-formats.xml > > index 18730b9..8c396db 100644 > > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > > @@ -563,6 +563,46 @@ > > b1 > > b0 > > > > + > > + MEDIA_BUS_FMT_RGB444_1X12 > > + 0x100d > > + > > + &dash-ent-20; > > + r3 > > + r2 > > + r1 > > + r0 > > + g3 > > + g2 > > + g1 > > + g0 > > + b3 > > + b2 > > + b1 > > + b0 > > + > > + > > + MEDIA_BUS_FMT_RGB565_1X16 > > + 0x100d > > + > > + &dash-ent-16; > > + r4 > > + r3 > > + r2 > > + r1 > > + r0 > > + g5 > > + g4 > > + g3 > > + g2 > > + g1 > > + g0 > > + b4 > > + b3 > > + b2 > > + b1 > > + b0 > > + > > > > > > > > diff --git a/include/uapi/linux/media-bus-format.h > > b/include/uapi/linux/media-bus-format.h > > index 23b4090..cc7b79e 100644 > > --- a/include/uapi/linux/media-bus-format.h > > +++ b/include/uapi/linux/media-bus-format.h > > @@ -33,7 +33,7 @@ > > > > #define MEDIA_BUS_FMT_FIXED0x0001 > > > > -/* RGB - next is 0x100e */ > > +/* RGB - next is 0x1010 */ > > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 > > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 > > #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 > > @@ -47,6 +47,8 @@ > > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > > #define MEDIA_BUS_FMT_ARGB_1X320x100d > > +#define MEDIA_BUS_FMT_RGB444_1X12 0x100e > > +#define MEDIA_BUS_FMT_RGB565_1X16 0x100f > > I'd arrange these according to BPP and bits per sample, both in the header > and documentation. I cannot keep both macro values and BPP/bits per sample in incrementing order. Are you sure you prefer to order macros in BPP/bits per sample order ? -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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
em28xx: Terratec G1 USB stick doesn't start recording
Hi My Terratec G1 USB Stick seems to be recognized ok but doesn't start recording when I push the recording button on the Terratec. (Recording light doesn't go red either). I'm aware that the device isn't listed in the Validated em28xx boards but I'm quite sure I've seen some info om people who've been successful with that device. Do I need firmware to make it work ? If yes, could someone point me to the right firmware ? Thanks in advance for any help. uname -a Linux PC32750 3.13.0-39-generic #66-Ubuntu SMP Tue Oct 28 13:30:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux dmesg [28789.658015] usb 2-2: new high-speed USB device number 6 using xhci_hcd [28789.680840] usb 2-2: New USB device found, idVendor=0ccd, idProduct=10af [28789.680843] usb 2-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0 [28789.680844] usb 2-2: Product: Terratec G1 [28789.680846] usb 2-2: Manufacturer: TerraTec Electronic GmbH [28789.714496] em28xx: New device TerraTec Electronic GmbH Terratec G1 @ 480 Mbps (0ccd:10af, interface 0, class 0) [28789.714499] em28xx: Video interface 0 found: isoc [28789.714528] em28xx: chip ID is em2860 [28789.838639] em2860 #0: i2c eeprom 00: 1a eb 67 95 cd 0c af 10 50 00 11 03 6a 1a 84 34 [28789.838650] em2860 #0: i2c eeprom 10: 00 00 06 57 06 02 00 00 00 00 00 00 00 00 00 00 [28789.838657] em2860 #0: i2c eeprom 20: 02 00 01 00 f0 10 01 00 00 00 00 00 5b 00 00 00 [28789.838665] em2860 #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 00 00 00 00 [28789.838672] em2860 #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838680] em2860 #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838687] em2860 #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 1a 03 54 00 65 00 [28789.838695] em2860 #0: i2c eeprom 70: 72 00 72 00 61 00 74 00 65 00 63 00 20 00 47 00 [28789.838702] em2860 #0: i2c eeprom 80: 31 00 00 00 34 03 54 00 65 00 72 00 72 00 61 00 [28789.838710] em2860 #0: i2c eeprom 90: 54 00 65 00 63 00 20 00 45 00 6c 00 65 00 63 00 [28789.838717] em2860 #0: i2c eeprom a0: 74 00 72 00 6f 00 6e 00 69 00 63 00 20 00 47 00 [28789.838725] em2860 #0: i2c eeprom b0: 6d 00 62 00 48 00 00 00 00 00 00 00 00 00 00 00 [28789.838732] em2860 #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838740] em2860 #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838747] em2860 #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838754] em2860 #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [28789.838764] em2860 #0: EEPROM ID = 1a eb 67 95, EEPROM hash = 0x9d3b7386 [28789.838766] em2860 #0: EEPROM info: [28789.838767] em2860 #0: AC97 audio (5 sample rates) [28789.838768] em2860 #0: 500mA max power [28789.838770] em2860 #0: Table at offset 0x06, strings=0x1a6a, 0x3484, 0x [28789.838773] em2860 #0: Identified as Terratec Grabby (card=67) [28790.230122] saa7115 8-0025: saa7113 found @ 0x4a (em2860 #0) [28790.997655] em2860 #0: Config register raw data: 0x50 [28791.021641] em2860 #0: AC97 vendor ID = 0x83847650 [28791.033530] em2860 #0: AC97 features = 0x6a90 [28791.033539] em2860 #0: Empia 202 AC97 audio processor detected [28791.505330] em2860 #0: v4l2 driver version 0.2.0 [28793.440703] em2860 #0: V4L2 video device registered as video1 [28793.440707] em2860 #0: V4L2 VBI device registered as vbi0 [28793.440709] em2860 #0: analog set to isoc mode. [28793.440729] em28xx audio device (0ccd:10af): interface 1, class 1 [28793.440737] em28xx audio device (0ccd:10af): interface 2, class 1 [28793.440753] usbcore: registered new interface driver em28xx [28793.462288] usbcore: registered new interface driver snd-usb-audio sudo lsusb -vd 0ccd:10af Bus 002 Device 006: ID 0ccd:10af TerraTec Electronic GmbH Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x0ccd TerraTec Electronic GmbH idProduct 0x10af bcdDevice1.00 iManufacturer 2 TerraTec Electronic GmbH iProduct1 Terratec G1 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 555 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7
Re: SOLO6x10: fix a race in IRQ handler.
2014-11-14 16:35 GMT+04:00 Krzysztof Hałasa : > The IRQs have to be acknowledged before they are serviced, otherwise some > events > may be skipped. Also, acknowledging IRQs just before returning from the > handler > doesn't leave enough time for the device to deassert the INTx line, and for > bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6 > dual core CPU. Thanks! I'm not experienced in interaction with hardware in this regard... could you please point to some reading which explains this moment? Or you just know this from experience? The solo device specs are very terse about this, so I considered that it should work fine without regard to how fast we write back to that register. -- Andrey Utkin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] videodev2.h: rename reserved2 to config_store in v4l2_buffer.
Hi Hans,
On Sun, Sep 21, 2014 at 04:48:21PM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> When queuing buffers allow for passing the configuration store ID that
> should be associated with this buffer. Use the 'reserved2' field for this.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/usb/cpia2/cpia2_v4l.c | 2 +-
> drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 4 ++--
> drivers/media/v4l2-core/videobuf2-core.c | 4 +++-
> include/uapi/linux/videodev2.h| 3 ++-
> 4 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/cpia2/cpia2_v4l.c
> b/drivers/media/usb/cpia2/cpia2_v4l.c
> index 9caea83..0f28d2b 100644
> --- a/drivers/media/usb/cpia2/cpia2_v4l.c
> +++ b/drivers/media/usb/cpia2/cpia2_v4l.c
> @@ -952,7 +952,7 @@ static int cpia2_dqbuf(struct file *file, void *fh,
> struct v4l2_buffer *buf)
> buf->sequence = cam->buffers[buf->index].seq;
> buf->m.offset = cam->buffers[buf->index].data - cam->frame_buffer;
> buf->length = cam->frame_size;
> - buf->reserved2 = 0;
> + buf->config_store = 0;
> buf->reserved = 0;
> memset(&buf->timecode, 0, sizeof(buf->timecode));
>
> diff --git a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> index e502a5f..5afef3a 100644
> --- a/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> +++ b/drivers/media/v4l2-core/v4l2-compat-ioctl32.c
> @@ -324,7 +324,7 @@ struct v4l2_buffer32 {
> __s32 fd;
> } m;
> __u32 length;
> - __u32 reserved2;
> + __u32 config_store;
> __u32 reserved;
> };
>
> @@ -489,7 +489,7 @@ static int put_v4l2_buffer32(struct v4l2_buffer *kp,
> struct v4l2_buffer32 __user
> put_user(kp->timestamp.tv_usec, &up->timestamp.tv_usec) ||
> copy_to_user(&up->timecode, &kp->timecode, sizeof(struct
> v4l2_timecode)) ||
> put_user(kp->sequence, &up->sequence) ||
> - put_user(kp->reserved2, &up->reserved2) ||
> + put_user(kp->config_store, &up->config_store) ||
> put_user(kp->reserved, &up->reserved))
> return -EFAULT;
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index 7e6aff6..e3b6c50 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -655,7 +655,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
> struct v4l2_buffer *b)
>
> /* Copy back data such as timestamp, flags, etc. */
> memcpy(b, &vb->v4l2_buf, offsetof(struct v4l2_buffer, m));
> - b->reserved2 = vb->v4l2_buf.reserved2;
> + b->config_store = vb->v4l2_buf.config_store;
> b->reserved = vb->v4l2_buf.reserved;
>
> if (V4L2_TYPE_IS_MULTIPLANAR(q->type)) {
> @@ -680,6 +680,7 @@ static void __fill_v4l2_buffer(struct vb2_buffer *vb,
> struct v4l2_buffer *b)
> else if (q->memory == V4L2_MEMORY_DMABUF)
> b->m.fd = vb->v4l2_planes[0].m.fd;
> }
> + b->config_store = vb->v4l2_buf.config_store;
Either this chunk or the one above it is redundant. I'd keep the upper one.
>
> /*
>* Clear any buffer state related flags.
> @@ -1324,6 +1325,7 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
>*/
> vb->v4l2_buf.flags &= ~V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> }
> + vb->v4l2_buf.config_store = b->config_store;
>
> if (V4L2_TYPE_IS_OUTPUT(b->type)) {
> /*
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 83ef28a..2ca44ed 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -672,6 +672,7 @@ struct v4l2_plane {
> * @length: size in bytes of the buffer (NOT its payload) for single-plane
> * buffers (when type != *_MPLANE); number of elements in the
> * planes array for multi-plane buffers
> + * @config_store: this buffer should use this configuration store
> *
> * Contains data exchanged by application and driver using one of the
> Streaming
> * I/O methods.
> @@ -695,7 +696,7 @@ struct v4l2_buffer {
> __s32 fd;
> } m;
> __u32 length;
> - __u32 reserved2;
> + __u32 config_store;
> __u32 reserved;
> };
>
--
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] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Hi Boris, On Fri, Nov 14, 2014 at 11:36:00AM +0100, Boris Brezillon wrote: > Add RGB444_1X12 and RGB565_1X16 format definitions and update the > documentation. > > Signed-off-by: Boris Brezillon > Acked-by: Mauro Carvalho Chehab > --- > Documentation/DocBook/media/v4l/subdev-formats.xml | 40 > ++ > include/uapi/linux/media-bus-format.h | 4 ++- > 2 files changed, 43 insertions(+), 1 deletion(-) > > diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml > b/Documentation/DocBook/media/v4l/subdev-formats.xml > index 18730b9..8c396db 100644 > --- a/Documentation/DocBook/media/v4l/subdev-formats.xml > +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml > @@ -563,6 +563,46 @@ > b1 > b0 > > + > + MEDIA_BUS_FMT_RGB444_1X12 > + 0x100d > + > + &dash-ent-20; > + r3 > + r2 > + r1 > + r0 > + g3 > + g2 > + g1 > + g0 > + b3 > + b2 > + b1 > + b0 > + > + > + MEDIA_BUS_FMT_RGB565_1X16 > + 0x100d > + > + &dash-ent-16; > + r4 > + r3 > + r2 > + r1 > + r0 > + g5 > + g4 > + g3 > + g2 > + g1 > + g0 > + b4 > + b3 > + b2 > + b1 > + b0 > + > > > > diff --git a/include/uapi/linux/media-bus-format.h > b/include/uapi/linux/media-bus-format.h > index 23b4090..cc7b79e 100644 > --- a/include/uapi/linux/media-bus-format.h > +++ b/include/uapi/linux/media-bus-format.h > @@ -33,7 +33,7 @@ > > #define MEDIA_BUS_FMT_FIXED 0x0001 > > -/* RGB - next is 0x100e */ > +/* RGB - next is 0x1010 */ > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE0x1001 > #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE0x1002 > #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE0x1003 > @@ -47,6 +47,8 @@ > #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b > #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c > #define MEDIA_BUS_FMT_ARGB_1X32 0x100d > +#define MEDIA_BUS_FMT_RGB444_1X120x100e > +#define MEDIA_BUS_FMT_RGB565_1X160x100f I'd arrange these according to BPP and bits per sample, both in the header and documentation. > /* YUV (including grey) - next is0x2024 */ > #define MEDIA_BUS_FMT_Y8_1X8 0x2001 -- 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
SOLO6x10: fix a race in IRQ handler.
The IRQs have to be acknowledged before they are serviced, otherwise some events
may be skipped. Also, acknowledging IRQs just before returning from the handler
doesn't leave enough time for the device to deassert the INTx line, and for
bridges to propagate this change. This resulted in twice the IRQ rate on ARMv6
dual core CPU.
Signed-off-by: Krzysztof Hałasa
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data)
if (!status)
return IRQ_NONE;
- if (status & ~solo_dev->irq_mask) {
- solo_reg_write(solo_dev, SOLO_IRQ_STAT,
- status & ~solo_dev->irq_mask);
- status &= solo_dev->irq_mask;
- }
+ /* Acknowledge all interrupts immediately */
+ solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
if (status & SOLO_IRQ_PCI_ERR)
solo_p2m_error_isr(solo_dev);
@@ -132,9 +129,6 @@ static irqreturn_t solo_isr(int irq, void *data)
if (status & SOLO_IRQ_G723)
solo_g723_isr(solo_dev);
- /* Clear all interrupts handled */
- solo_reg_write(solo_dev, SOLO_IRQ_STAT, status);
-
return IRQ_HANDLED;
}
--
Krzysztof Halasa
Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
2014-11-14 15:00 GMT+04:00 Krzysztof Hałasa : > There is a race condition in the IRQ handler, at least in 3.17. > I don't know if it's related, will post a patch. Thank you for your interest. Looking forward for your patch. If you don't have time, please just say what races with what, I'll check by myself. -- Andrey Utkin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] media: ti-vpe: Add support for SEQ_TB buffers
The video source can generate the data in the SEQ_TB buffer format.
In the case of TI SoC, the IVA_HD can generate the interlaced content in
the SEQ_TB buffer format. This is the format where the top and bottom field
data can be contained in a single buffer. For example, for NV12, interlaced
format, the data in Y buffer will be arranged as Y-top followed by Y-bottom.
And likewise for UV plane.
Also, queueing one buffer of SEQ_TB is euivalent to queueing two different
buffers for top and bottom fields. Driver needs to take care of this when
handling source buffer lists.
Signed-off-by: Nikhil Devshatwar
---
Changes from v1:
* Add check for valid field in qbuf ioctl
* Fix issue with swapped fields
drivers/media/platform/ti-vpe/vpe.c | 124 ---
1 file changed, 102 insertions(+), 22 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 939f083..65885c4 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -318,9 +318,13 @@ struct vpe_q_data {
};
/* vpe_q_data flag bits */
-#defineQ_DATA_FRAME_1D (1 << 0)
-#defineQ_DATA_MODE_TILED (1 << 1)
-#defineQ_DATA_INTERLACED (1 << 2)
+#defineQ_DATA_FRAME_1D (1 << 0)
+#defineQ_DATA_MODE_TILED (1 << 1)
+#defineQ_DATA_INTERLACED_ALTERNATE (1 << 2)
+#defineQ_DATA_INTERLACED_SEQ_TB(1 << 3)
+
+#define Q_IS_INTERLACED(Q_DATA_INTERLACED_ALTERNATE | \
+ Q_DATA_INTERLACED_SEQ_TB)
enum {
Q_DATA_SRC = 0,
@@ -646,7 +650,7 @@ static void set_us_coefficients(struct vpe_ctx *ctx)
cp = &us_coeffs[0].anchor_fid0_c0;
- if (s_q_data->flags & Q_DATA_INTERLACED)/* interlaced */
+ if (s_q_data->flags & Q_IS_INTERLACED) /* interlaced */
cp += sizeof(us_coeffs[0]) / sizeof(*cp);
end_cp = cp + sizeof(us_coeffs[0]) / sizeof(*cp);
@@ -773,8 +777,7 @@ static void set_dei_regs(struct vpe_ctx *ctx)
* for both progressive and interlace content in interlace bypass mode.
* It has been recommended not to use progressive bypass mode.
*/
- if ((!ctx->deinterlacing && (s_q_data->flags & Q_DATA_INTERLACED)) ||
- !(s_q_data->flags & Q_DATA_INTERLACED)) {
+ if (!(s_q_data->flags & Q_IS_INTERLACED) || !ctx->deinterlacing) {
deinterlace = false;
val = VPE_DEI_INTERLACE_BYPASS;
}
@@ -842,8 +845,8 @@ static int set_srcdst_params(struct vpe_ctx *ctx)
ctx->sequence = 0;
ctx->field = V4L2_FIELD_TOP;
- if ((s_q_data->flags & Q_DATA_INTERLACED) &&
- !(d_q_data->flags & Q_DATA_INTERLACED)) {
+ if ((s_q_data->flags & Q_IS_INTERLACED) &&
+ !(d_q_data->flags & Q_IS_INTERLACED)) {
int bytes_per_line;
const struct vpdma_data_format *mv =
&vpdma_misc_fmts[VPDMA_DATA_FMT_MV];
@@ -1067,6 +1070,27 @@ static void add_in_dtd(struct vpe_ctx *ctx, int port)
vpdma_fmt = fmt->vpdma_fmt[plane];
dma_addr = vb2_dma_addr_plus_data_offset(vb, plane);
+
+ if (q_data->flags & Q_DATA_INTERLACED_SEQ_TB) {
+ /*
+* Use top or bottom field from same vb alternately
+* f,f-1,f-2 = TBT when seq is even
+* f,f-1,f-2 = BTB when seq is odd
+*/
+ field = (p_data->vb_index + (ctx->sequence % 2)) % 2;
+
+ if (field) {
+ /* bottom field of a SEQ_TB buffer
+* Skip the top field data by */
+ int height = q_data->height / 2;
+ int bpp = fmt->fourcc == V4L2_PIX_FMT_NV12 ?
+ 1 : (vpdma_fmt->depth >> 3);
+ if (plane)
+ height /= 2;
+ dma_addr += q_data->width * height * bpp;
+ }
+ }
+
if (!dma_addr) {
vpe_err(ctx->dev,
"acquiring input buffer(%d) dma_addr failed\n",
@@ -1121,9 +1145,22 @@ static void device_run(void *priv)
struct vpe_ctx *ctx = priv;
struct sc_data *sc = ctx->dev->sc;
struct vpe_q_data *d_q_data = &ctx->q_data[Q_DATA_DST];
+ struct vpe_q_data *s_q_data = &ctx->q_data[Q_DATA_SRC];
+
+ if (ctx->deinterlacing && s_q_data->flags & Q_DATA_INTERLACED_SEQ_TB &&
+ ctx->sequence % 2 == 0) {
+ /* When using SEQ_TB buffers, When using it first time,
+* No need to remove the buffer as the next field is presen
[PATCH v2 3/4] media: ti-vpe: Do not perform job transaction atomically
Current VPE driver does not start the job untill all the buffers for
a transaction are not queued. When running in multiple context, this might
increase the processing latency.
Alternate solution would be to try to continue the same context as long as
buffers for the transaction are ready; else switch the conext. This may
increase number of context switches but it reduces latency significantly.
In this approach, the job_ready always succeeds as long as there are buffers
on the CAPTURE and OUTPUT stream. Processing may start immediately as the
first 2 iterations don't need extra source buffers. Shift all the source buffers
after each iteration and remove the oldest buffer.
Also, with this removes the constraint of pre buffering 3 buffers before call
to STREAMON in case of deinterlacing.
Signed-off-by: Nikhil Devshatwar
---
drivers/media/platform/ti-vpe/vpe.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 4d3ab43..939f083 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -906,15 +906,14 @@ static struct vpe_ctx *file2ctx(struct file *file)
static int job_ready(void *priv)
{
struct vpe_ctx *ctx = priv;
- int needed = ctx->bufs_per_job;
- if (ctx->deinterlacing && ctx->src_vbs[2] == NULL)
- needed += 2;/* need additional two most recent fields */
-
- if (v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) < needed)
- return 0;
-
- if (v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) < needed)
+ /*
+* This check is needed as this might be called directly from driver
+* When called by m2m framework, this will always satisy, but when
+* called from vpe_irq, this might fail. (src stream with zero buffers)
+*/
+ if (v4l2_m2m_num_src_bufs_ready(ctx->m2m_ctx) <= 0 ||
+ v4l2_m2m_num_dst_bufs_ready(ctx->m2m_ctx) <= 0)
return 0;
return 1;
@@ -1123,19 +1122,20 @@ static void device_run(void *priv)
struct sc_data *sc = ctx->dev->sc;
struct vpe_q_data *d_q_data = &ctx->q_data[Q_DATA_DST];
- if (ctx->deinterlacing && ctx->src_vbs[2] == NULL) {
- ctx->src_vbs[2] = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
- WARN_ON(ctx->src_vbs[2] == NULL);
- ctx->src_vbs[1] = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
- WARN_ON(ctx->src_vbs[1] == NULL);
- }
-
ctx->src_vbs[0] = v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
WARN_ON(ctx->src_vbs[0] == NULL);
ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
WARN_ON(ctx->dst_vb == NULL);
if (ctx->deinterlacing) {
+
+ if (ctx->src_vbs[2] == NULL) {
+ ctx->src_vbs[2] = ctx->src_vbs[0];
+ WARN_ON(ctx->src_vbs[2] == NULL);
+ ctx->src_vbs[1] = ctx->src_vbs[0];
+ WARN_ON(ctx->src_vbs[1] == NULL);
+ }
+
/*
* we have output the first 2 frames through line average, we
* now switch to EDI de-interlacer
@@ -1359,7 +1359,7 @@ static irqreturn_t vpe_irq(int irq_vpe, void *data)
}
ctx->bufs_completed++;
- if (ctx->bufs_completed < ctx->bufs_per_job) {
+ if (ctx->bufs_completed < ctx->bufs_per_job && job_ready(ctx)) {
device_run(ctx);
goto handled;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] media: ti-vpe: Use data offset for getting dma_addr for a plane
The data_offset in v4l2_planes structure will help us point to the start of
data content for that particular plane. This may be useful when a single
buffer contains the data for different planes e.g. Y planes of two fields in
the same buffer. With this, user space can pass queue top field and
bottom field with same dmafd and different data_offsets.
Signed-off-by: Nikhil Devshatwar
---
drivers/media/platform/ti-vpe/vpe.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index 0ae19ee..e59eb81 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -495,6 +495,14 @@ struct vpe_mmr_adb {
#define VPE_SET_MMR_ADB_HDR(ctx, hdr, regs, offset_a) \
VPDMA_SET_MMR_ADB_HDR(ctx->mmr_adb, vpe_mmr_adb, hdr, regs, offset_a)
+
+static inline dma_addr_t vb2_dma_addr_plus_data_offset(struct vb2_buffer *vb,
+ unsigned int plane_no)
+{
+ return vb2_dma_contig_plane_dma_addr(vb, plane_no) +
+ vb->v4l2_planes[plane_no].data_offset;
+}
+
/*
* Set the headers for all of the address/data block structures.
*/
@@ -1002,7 +1010,7 @@ static void add_out_dtd(struct vpe_ctx *ctx, int port)
int plane = fmt->coplanar ? p_data->vb_part : 0;
vpdma_fmt = fmt->vpdma_fmt[plane];
- dma_addr = vb2_dma_contig_plane_dma_addr(vb, plane);
+ dma_addr = vb2_dma_addr_plus_data_offset(vb, plane);
if (!dma_addr) {
vpe_err(ctx->dev,
"acquiring output buffer(%d) dma_addr failed\n",
@@ -1042,7 +1050,7 @@ static void add_in_dtd(struct vpe_ctx *ctx, int port)
vpdma_fmt = fmt->vpdma_fmt[plane];
- dma_addr = vb2_dma_contig_plane_dma_addr(vb, plane);
+ dma_addr = vb2_dma_addr_plus_data_offset(vb, plane);
if (!dma_addr) {
vpe_err(ctx->dev,
"acquiring input buffer(%d) dma_addr failed\n",
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] media: ti-vpe: Use line average de-interlacing for first 2 frames
From: Archit Taneja
For n input fields, the VPE de-interlacer creates n - 2 progressive frames.
To support this, we use line average mode of de-interlacer for the first 2
input fields to generate 2 progressive frames. We then revert back to the
preferred EDI method, and create n - 2 frames, creating a sum of n frames.
Signed-off-by: Archit Taneja
Signed-off-by: Nikhil Devshatwar
---
drivers/media/platform/ti-vpe/vpe.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/media/platform/ti-vpe/vpe.c
b/drivers/media/platform/ti-vpe/vpe.c
index e59eb81..4d3ab43 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -806,6 +806,23 @@ static void set_dei_shadow_registers(struct vpe_ctx *ctx)
ctx->load_mmrs = true;
}
+static void config_edi_input_mode(struct vpe_ctx *ctx, int mode)
+{
+ struct vpe_mmr_adb *mmr_adb = ctx->mmr_adb.addr;
+ u32 *edi_config_reg = &mmr_adb->dei_regs[3];
+
+ if (mode & 0x2)
+ write_field(edi_config_reg, 1, 1, 2); /* EDI_ENABLE_3D */
+
+ if (mode & 0x3)
+ write_field(edi_config_reg, 1, 1, 3); /* EDI_CHROMA_3D */
+
+ write_field(edi_config_reg, mode, VPE_EDI_INP_MODE_MASK,
+ VPE_EDI_INP_MODE_SHIFT);
+
+ ctx->load_mmrs = true;
+}
+
/*
* Set the shadow registers whose values are modified when either the
* source or destination format is changed.
@@ -1118,6 +1135,15 @@ static void device_run(void *priv)
ctx->dst_vb = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
WARN_ON(ctx->dst_vb == NULL);
+ if (ctx->deinterlacing) {
+ /*
+* we have output the first 2 frames through line average, we
+* now switch to EDI de-interlacer
+*/
+ if (ctx->sequence == 2)
+ config_edi_input_mode(ctx, 0x3); /* EDI (Y + UV) */
+ }
+
/* config descriptors */
if (ctx->dev->loaded_mmrs != ctx->mmr_adb.dma_addr || ctx->load_mmrs) {
vpdma_map_desc_buf(ctx->dev->vpdma, &ctx->mmr_adb);
@@ -1779,6 +1805,9 @@ static int vpe_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
{
struct vpe_ctx *ctx = file2ctx(file);
+ if (ctx->deinterlacing)
+ config_edi_input_mode(ctx, 0x0);
+
return v4l2_m2m_streamon(file, ctx->m2m_ctx, type);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] VPE improvements
This patchset adds following improvements for the ti-vpe driver. * Support SEQ_TB format for interlaced buffers Some of the video decoders generate interlaced content in SEQ_TB format Y top, T bottom in one plane and UV top, UV bottom in another * Improve multi instance latency Improve m2m job scheduling in multi instance use cases Start processing even if all buffers aren't present * N frame de-interlace support For N input fields, generate N progressive frames Archit Taneja (1): media: ti-vpe: Use line average de-interlacing for first 2 frames Nikhil Devshatwar (3): media: ti-vpe: Use data offset for getting dma_addr for a plane media: ti-vpe: Do not perform job transaction atomically media: ti-vpe: Add support for SEQ_TB buffers drivers/media/platform/ti-vpe/vpe.c | 193 --- 1 file changed, 155 insertions(+), 38 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] solo6x10: just pass frame motion flag from hardware, drop additional handling as complicated and unstable
Hi Andrew,
FYI: I need to test this myself and understand it better, so it will take some
time before I get to this. It is in my TODO list, so it won't be forgotten.
Regards,
Hans
On 11/05/2014 09:11 PM, Andrey Utkin wrote:
> Dropping code (introduced in 316d9e84a72069e04e483de0d5934c1d75f6a44c)
> which intends to make raising of motion events more "smooth"(?).
>
> It made motion event never appear in my installation.
> That code is complicated, so I couldn't figure out quickly how to fix
> it, so dropping it seems better to me.
>
> Another justification is that anyway application would implement
> "motion signal stabilization" if required, it is not necessarily kernel
> driver's job.
>
> Signed-off-by: Andrey Utkin
> ---
> drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 30
> +-
> drivers/media/pci/solo6x10/solo6x10.h | 2 --
> 2 files changed, 1 insertion(+), 31 deletions(-)
>
> diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> index 30e09d9..866f7b3 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
> @@ -239,8 +239,6 @@ static int solo_enc_on(struct solo_enc_dev *solo_enc)
> if (solo_enc->bw_weight > solo_dev->enc_bw_remain)
> return -EBUSY;
> solo_enc->sequence = 0;
> - solo_enc->motion_last_state = false;
> - solo_enc->frames_since_last_motion = 0;
> solo_dev->enc_bw_remain -= solo_enc->bw_weight;
>
> if (solo_enc->type == SOLO_ENC_TYPE_EXT)
> @@ -555,36 +553,12 @@ static int solo_enc_fillbuf(struct solo_enc_dev
> *solo_enc,
> }
>
> if (!ret) {
> - bool send_event = false;
> -
> vb->v4l2_buf.sequence = solo_enc->sequence++;
> vb->v4l2_buf.timestamp.tv_sec = vop_sec(vh);
> vb->v4l2_buf.timestamp.tv_usec = vop_usec(vh);
>
> /* Check for motion flags */
> - if (solo_is_motion_on(solo_enc)) {
> - /* It takes a few frames for the hardware to detect
> - * motion. Once it does it clears the motion detection
> - * register and it takes again a few frames before
> - * motion is seen. This means in practice that when the
> - * motion field is 1, it will go back to 0 for the next
> - * frame. This leads to motion detection event being
> - * sent all the time, which is not what we want.
> - * Instead wait a few frames before deciding that the
> - * motion has halted. After some experimentation it
> - * turns out that waiting for 5 frames works well.
> - */
> - if (enc_buf->motion == 0 &&
> - solo_enc->motion_last_state &&
> - solo_enc->frames_since_last_motion++ > 5)
> - send_event = true;
> - else if (enc_buf->motion) {
> - solo_enc->frames_since_last_motion = 0;
> - send_event = !solo_enc->motion_last_state;
> - }
> - }
> -
> - if (send_event) {
> + if (solo_is_motion_on(solo_enc) && enc_buf->motion) {
> struct v4l2_event ev = {
> .type = V4L2_EVENT_MOTION_DET,
> .u.motion_det = {
> @@ -594,8 +568,6 @@ static int solo_enc_fillbuf(struct solo_enc_dev *solo_enc,
> },
> };
>
> - solo_enc->motion_last_state = enc_buf->motion;
> - solo_enc->frames_since_last_motion = 0;
> v4l2_event_queue(solo_enc->vfd, &ev);
> }
> }
> diff --git a/drivers/media/pci/solo6x10/solo6x10.h
> b/drivers/media/pci/solo6x10/solo6x10.h
> index 72017b7..dc503fd 100644
> --- a/drivers/media/pci/solo6x10/solo6x10.h
> +++ b/drivers/media/pci/solo6x10/solo6x10.h
> @@ -159,8 +159,6 @@ struct solo_enc_dev {
> u16 motion_thresh;
> boolmotion_global;
> boolmotion_enabled;
> - boolmotion_last_state;
> - u8 frames_since_last_motion;
> u16 width;
> u16 height;
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?
Andrey Utkin writes: > The problem is the following: after ~1 hour of uptime with working > application reading the streams, one card (the same one every time) > stops producing interrupts (counter in /proc/interrupts freezes), and > all threads reading from that card hang forever in > ioctl(VIDIOC_DQBUF). There is a race condition in the IRQ handler, at least in 3.17. I don't know if it's related, will post a patch. -- Krzysztof Halasa Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] Add RGB444_1X12 and RGB565_1X16 media bus formats
Add RGB444_1X12 and RGB565_1X16 format definitions and update the documentation. Signed-off-by: Boris Brezillon Acked-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/subdev-formats.xml | 40 ++ include/uapi/linux/media-bus-format.h | 4 ++- 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 18730b9..8c396db 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -563,6 +563,46 @@ b1 b0 + + MEDIA_BUS_FMT_RGB444_1X12 + 0x100d + + &dash-ent-20; + r3 + r2 + r1 + r0 + g3 + g2 + g1 + g0 + b3 + b2 + b1 + b0 + + + MEDIA_BUS_FMT_RGB565_1X16 + 0x100d + + &dash-ent-16; + r4 + r3 + r2 + r1 + r0 + g5 + g4 + g3 + g2 + g1 + g0 + b4 + b3 + b2 + b1 + b0 + diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h index 23b4090..cc7b79e 100644 --- a/include/uapi/linux/media-bus-format.h +++ b/include/uapi/linux/media-bus-format.h @@ -33,7 +33,7 @@ #define MEDIA_BUS_FMT_FIXED0x0001 -/* RGB - next is 0x100e */ +/* RGB - next is 0x1010 */ #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE 0x1001 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE 0x1002 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE 0x1003 @@ -47,6 +47,8 @@ #define MEDIA_BUS_FMT_RGB888_2X12_BE 0x100b #define MEDIA_BUS_FMT_RGB888_2X12_LE 0x100c #define MEDIA_BUS_FMT_ARGB_1X320x100d +#define MEDIA_BUS_FMT_RGB444_1X12 0x100e +#define MEDIA_BUS_FMT_RGB565_1X16 0x100f /* YUV (including grey) - next is 0x2024 */ #define MEDIA_BUS_FMT_Y8_1X8 0x2001 -- 1.9.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
[GIT PULL FOR v3.19] si4713 improvements and vb2_start_streaming_called() helper
Hi Mauro, This is the full si4713 patch series (with some small changes to fix compiler warnings), and two patches to use the vb2_start_streaming_called() helper where appropriate. Regards, Hans The following changes since commit dd0a6fe2bc3055cd61e369f97982c88183b1f0a0: [media] dvb-usb-dvbsky: fix i2c adapter for sp2 device (2014-11-11 12:55:32 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19g for you to fetch changes up to 6058ab17af213b8b3f226c4ed620af5de42030fe: media: cx88: use vb2_start_streaming_called() helper (2014-11-14 11:17:21 +0100) Prabhakar Lad (2): media: vivid: use vb2_start_streaming_called() helper media: cx88: use vb2_start_streaming_called() helper Sebastian Reichel (8): si4713: switch to devm regulator API si4713: switch reset gpio to devm_gpiod API si4713: use managed memory allocation si4713: use managed irq request si4713: add device tree support si4713: add DT binding documentation ARM: OMAP2: RX-51: update si4713 platform data si4713: cleanup platform data Documentation/devicetree/bindings/media/si4713.txt | 30 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 69 ++- drivers/media/pci/cx88/cx88-blackbird.c| 2 +- drivers/media/platform/vivid/vivid-ctrls.c | 10 ++--- drivers/media/radio/si4713/radio-platform-si4713.c | 28 +++-- drivers/media/radio/si4713/si4713.c| 164 +++-- drivers/media/radio/si4713/si4713.h| 15 --- include/media/radio-si4713.h | 30 -- include/media/si4713.h | 4 +- 9 files changed, 189 insertions(+), 163 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/si4713.txt delete mode 100644 include/media/radio-si4713.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v7 3/3] Documentation: leds: Add description of LED Flash Class extension
Hi Bryan, Thanks for a review. On 11/13/2014 07:58 PM, Bryan Wu wrote: On Wed, Nov 12, 2014 at 8:09 AM, Jacek Anaszewski wrote: The documentation being added contains overall description of the LED Flash Class and the related sysfs attributes. Signed-off-by: Jacek Anaszewski Acked-by: Kyungmin Park Cc: Bryan Wu Cc: Richard Purdie --- Documentation/leds/leds-class-flash.txt | 39 +++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/leds/leds-class-flash.txt diff --git a/Documentation/leds/leds-class-flash.txt b/Documentation/leds/leds-class-flash.txt new file mode 100644 index 000..0164329 --- /dev/null +++ b/Documentation/leds/leds-class-flash.txt @@ -0,0 +1,39 @@ + +Flash LED handling under Linux +== + +Some LED devices support two modes - torch and flash. In order to enable I think I asked this question before, Torch, Flash and Indicator. As you answered torch is implemented by sync led brightness set operation in our LEDS_CLASS and Flash is implemented in this LEDS_CLASS_FLASH. I suggest put this information in document or code comments. Then people know how to use torch and flash. Good point. For indicator I still don't know why we need this since indicator is like blinking and it should be support by LEDS_CLASS right? Indicator led is strictly related to flash devices. It is also called a "privacy led" because of its purpose - protecting a privacy of a person being recorded by providing a light signal signifying that a camera is on. It is a low current led, but some devices use the same led as for torch and flash and only apply reduced current in the indicator mode. In the V4L2 subsystem I see only one driver supporting indicator leds: /drivers/media/i2c/as3645a.c. It looks like indicator intensity can be set only when flash mode is V4L2_FLASH_LED_MODE_NONE, i.e. torch and flash leds cannot be active simultaneously with indicator led. It is reasonable, as active torch led is a sufficient signalization of recording. In the LED subsystem I also see indicators in some drivers, e.g. leds-lm355x.c, but they are registered as a separate LED class devices. Moreover the driver adds also a "pattern" sysfs attribute for choosing indicator blinking pattern so that is something to be added to the LED Flash class. I think that similar improvement to the V4L2 Flash API should be made. Sakari, what is your opinion? Flash is for some camera capture, right? +support for flash LEDs CONFIG_LEDS_CLASS_FLASH symbol must be defined +in the kernel config. A flash LED driver must register in the LED subsystem +with led_classdev_flash_register to gain flash capabilities. + +Following sysfs attributes are exposed for controlling flash led devices: + + - flash_brightness - flash LED brightness in microamperes (RW) + - max_flash_brightness - maximum available flash LED brightness (RO) + - indicator_brightness - privacy LED brightness in microamperes (RW) + - max_indicator_brightness - maximum privacy LED brightness in +microamperes (RO) What's the privacy mean here? Indeed, consistent naming should be applied, so I will modify it to: "maximum indicator LED brightness in microaperes (RO)" + - flash_timeout - flash strobe duration in microseconds (RW) + - max_flash_timeout - maximum available flash strobe duration (RO) + - flash_strobe - flash strobe state (RW) + - flash_fault - bitmask of flash faults that may have occurred, + possible flags are: + * 0x01 - flash controller voltage to the flash LED has exceeded +the limit specific to the flash controller + * 0x02 - the flash strobe was still on when the timeout set by +the user has expired; not all flash controllers may +set this in all such conditions + * 0x04 - the flash controller has overheated + * 0x08 - the short circuit protection of the flash controller +has been triggered + * 0x10 - current in the LED power supply has exceeded the limit +specific to the flash controller + * 0x40 - flash controller voltage to the flash LED has been +below the minimum limit specific to the flash + * 0x80 - the input voltage of the flash controller is below +the limit under which strobing the flash at full +current will not be possible. The condition persists +until this flag is no longer set + * 0x100 - the temperature of the LED has exceeded its allowed + upper limit Are these error code the same for all the LED controller? Or just for some specific chip? They are generic error codes, and map directly to V4L2 Flash er
Re: [PATCH 1/2] mach-omap2: remove deprecated VIDEO_OMAP2 support
On Fri, Nov 14, 2014 at 10:23:13AM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > The omap2 camera driver has been deprecated for a year and is now > going to be removed. It is unmaintained and it uses an internal API > that has long since been superseded by a much better API. Worse, that > internal API has been abused by out-of-kernel trees (i.MX6). > > In addition, Sakari stated that these drivers have never been in a > usable state in the mainline kernel due to missing platform data. For both: Acked-by: Sakari Ailus -- 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
[PATCH 1/2] mach-omap2: remove deprecated VIDEO_OMAP2 support
From: Hans Verkuil
The omap2 camera driver has been deprecated for a year and is now
going to be removed. It is unmaintained and it uses an internal API
that has long since been superseded by a much better API. Worse, that
internal API has been abused by out-of-kernel trees (i.MX6).
In addition, Sakari stated that these drivers have never been in a
usable state in the mainline kernel due to missing platform data.
Signed-off-by: Hans Verkuil
Cc: Sakari Ailus
Cc: David Cohen
---
arch/arm/mach-omap2/devices.c | 31 ---
1 file changed, 31 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 324f02b..1b623a0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -101,28 +101,6 @@ static int __init omap4_l3_init(void)
}
omap_postcore_initcall(omap4_l3_init);
-#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
-
-static struct resource omap2cam_resources[] = {
- {
- .start = OMAP24XX_CAMERA_BASE,
- .end= OMAP24XX_CAMERA_BASE + 0xfff,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = 24 + OMAP_INTC_START,
- .flags = IORESOURCE_IRQ,
- }
-};
-
-static struct platform_device omap2cam_device = {
- .name = "omap24xxcam",
- .id = -1,
- .num_resources = ARRAY_SIZE(omap2cam_resources),
- .resource = omap2cam_resources,
-};
-#endif
-
#if defined(CONFIG_IOMMU_API)
#include
@@ -245,14 +223,6 @@ int omap3_init_camera(struct isp_platform_data *pdata)
#endif
-static inline void omap_init_camera(void)
-{
-#if defined(CONFIG_VIDEO_OMAP2) || defined(CONFIG_VIDEO_OMAP2_MODULE)
- if (cpu_is_omap24xx())
- platform_device_register(&omap2cam_device);
-#endif
-}
-
#if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE)
static inline void __init omap_init_mbox(void)
{
@@ -431,7 +401,6 @@ static int __init omap2_init_devices(void)
* in alphabetical order so they're easier to sort through.
*/
omap_init_audio();
- omap_init_camera();
/* If dtb is there, the devices will be created dynamically */
if (!of_have_populated_dt()) {
omap_init_mbox();
--
2.1.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
[PATCH 2/2] omap24xx/tcm825x: remove deprecated omap2 camera drivers.
From: Hans Verkuil The omap2 camera driver and the tcm825x sensor driver have been deprecated for a year and are now being removed. They are unmaintained and they use an internal API that has long since been superseded by a much better API. Worse, that internal API has been abused by out-of-kernel trees (i.MX6). In addition, Sakari stated that these drivers have never been in a usable state in the mainline kernel due to missing platform data. Signed-off-by: Hans Verkuil Cc: Sakari Ailus Cc: David Cohen --- drivers/staging/media/Kconfig|2 - drivers/staging/media/Makefile |2 - drivers/staging/media/omap24xx/Kconfig | 35 - drivers/staging/media/omap24xx/Makefile |5 - drivers/staging/media/omap24xx/omap24xxcam-dma.c | 598 --- drivers/staging/media/omap24xx/omap24xxcam.c | 1882 -- drivers/staging/media/omap24xx/omap24xxcam.h | 596 --- drivers/staging/media/omap24xx/tcm825x.c | 938 --- drivers/staging/media/omap24xx/tcm825x.h | 200 --- drivers/staging/media/omap24xx/v4l2-int-device.c | 164 -- drivers/staging/media/omap24xx/v4l2-int-device.h | 305 11 files changed, 4727 deletions(-) delete mode 100644 drivers/staging/media/omap24xx/Kconfig delete mode 100644 drivers/staging/media/omap24xx/Makefile delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam-dma.c delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam.c delete mode 100644 drivers/staging/media/omap24xx/omap24xxcam.h delete mode 100644 drivers/staging/media/omap24xx/tcm825x.c delete mode 100644 drivers/staging/media/omap24xx/tcm825x.h delete mode 100644 drivers/staging/media/omap24xx/v4l2-int-device.c delete mode 100644 drivers/staging/media/omap24xx/v4l2-int-device.h diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig index 655cf50..c8979d8 100644 --- a/drivers/staging/media/Kconfig +++ b/drivers/staging/media/Kconfig @@ -27,8 +27,6 @@ source "drivers/staging/media/davinci_vpfe/Kconfig" source "drivers/staging/media/dt3155v4l/Kconfig" -source "drivers/staging/media/omap24xx/Kconfig" - source "drivers/staging/media/omap4iss/Kconfig" # Keep LIRC at the end, as it has sub-menus diff --git a/drivers/staging/media/Makefile b/drivers/staging/media/Makefile index 6dbe578..b6bc3ba 100644 --- a/drivers/staging/media/Makefile +++ b/drivers/staging/media/Makefile @@ -4,6 +4,4 @@ obj-$(CONFIG_LIRC_STAGING) += lirc/ obj-$(CONFIG_VIDEO_DT3155) += dt3155v4l/ obj-$(CONFIG_VIDEO_DM365_VPFE) += davinci_vpfe/ obj-$(CONFIG_VIDEO_OMAP4) += omap4iss/ -obj-$(CONFIG_VIDEO_OMAP2) += omap24xx/ -obj-$(CONFIG_VIDEO_TCM825X) += omap24xx/ diff --git a/drivers/staging/media/omap24xx/Kconfig b/drivers/staging/media/omap24xx/Kconfig deleted file mode 100644 index 82e569a..000 --- a/drivers/staging/media/omap24xx/Kconfig +++ /dev/null @@ -1,35 +0,0 @@ -config VIDEO_V4L2_INT_DEVICE - tristate - -config VIDEO_OMAP2 - tristate "OMAP2 Camera Capture Interface driver (DEPRECATED)" - depends on VIDEO_DEV && ARCH_OMAP2 - select VIDEOBUF_DMA_SG - select VIDEO_V4L2_INT_DEVICE - ---help--- - This is a v4l2 driver for the TI OMAP2 camera capture interface - - It uses the deprecated int-device API. Since this driver is no - longer actively maintained and nobody is interested in converting - it to the subdev API, this driver will be removed soon. - - If you do want to keep this driver in the kernel, and are willing - to convert it to the subdev API, then please contact the linux-media - mailinglist. - -config VIDEO_TCM825X - tristate "TCM825x camera sensor support (DEPRECATED)" - depends on I2C && VIDEO_V4L2 - depends on MEDIA_CAMERA_SUPPORT - select VIDEO_V4L2_INT_DEVICE - ---help--- - This is a driver for the Toshiba TCM825x VGA camera sensor. - It is used for example in Nokia N800. - - It uses the deprecated int-device API. Since this driver is no - longer actively maintained and nobody is interested in converting - it to the subdev API, this driver will be removed soon. - - If you do want to keep this driver in the kernel, and are willing - to convert it to the subdev API, then please contact the linux-media - mailinglist. diff --git a/drivers/staging/media/omap24xx/Makefile b/drivers/staging/media/omap24xx/Makefile deleted file mode 100644 index c2e7175..000 --- a/drivers/staging/media/omap24xx/Makefile +++ /dev/null @@ -1,5 +0,0 @@ -omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o - -obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o -obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o -obj-$(CONFIG_VIDEO_V4L2_INT_DEVICE) += v4l2-int-device.o diff --git a/drivers/staging/media/omap24xx/omap24xxcam-dma.c b/drivers/staging/media/omap24xx/omap24xxcam-dma.c deleted file mode 1
[GIT PULL FOR v3.19] Move mediabus format definition to a more standard place
The following changes since commit dd0a6fe2bc3055cd61e369f97982c88183b1f0a0: [media] dvb-usb-dvbsky: fix i2c adapter for sp2 device (2014-11-11 12:55:32 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.19h for you to fetch changes up to 7de21705a75d97f84dd5f1ef0295f79edca8b0f2: v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel (2014-11-14 09:56:58 +0100) Boris BREZILLON (10): Move mediabus format definition to a more standard place v4l: Update subdev-formats doc with new MEDIA_BUS_FMT values Make use of the new media_bus_format definitions i2c: Make use of media_bus_format enum pci: Make use of MEDIA_BUS_FMT definitions platform: Make use of media_bus_format enum usb: Make use of media_bus_format enum staging: media: Make use of MEDIA_BUS_FMT_ definitions gpu: ipu-v3: Make use of media_bus_format enum v4l: Forbid usage of V4L2_MBUS_FMT definitions inside the kernel Documentation/DocBook/media/v4l/subdev-formats.xml | 308 +-- Documentation/video4linux/soc-camera.txt | 2 +- arch/arm/mach-davinci/board-dm355-evm.c | 2 +- arch/arm/mach-davinci/board-dm365-evm.c | 4 +- arch/arm/mach-davinci/dm355.c| 7 +- arch/arm/mach-davinci/dm365.c| 7 +- arch/arm/mach-shmobile/board-mackerel.c | 2 +- arch/sh/boards/mach-ap325rxa/setup.c | 2 +- drivers/gpu/ipu-v3/ipu-csi.c | 66 +++ drivers/media/i2c/adv7170.c | 16 ++-- drivers/media/i2c/adv7175.c | 16 ++-- drivers/media/i2c/adv7180.c | 6 +- drivers/media/i2c/adv7183.c | 6 +- drivers/media/i2c/adv7604.c | 72 drivers/media/i2c/adv7842.c | 6 +- drivers/media/i2c/ak881x.c | 8 +- drivers/media/i2c/cx25840/cx25840-core.c | 2 +- drivers/media/i2c/m5mols/m5mols_core.c | 6 +- drivers/media/i2c/ml86v7667.c| 6 +- drivers/media/i2c/mt9m032.c | 6 +- drivers/media/i2c/mt9p031.c | 8 +- drivers/media/i2c/mt9t001.c | 8 +- drivers/media/i2c/mt9v011.c | 6 +- drivers/media/i2c/mt9v032.c | 12 +-- drivers/media/i2c/noon010pc30.c | 12 +-- drivers/media/i2c/ov7670.c | 16 ++-- drivers/media/i2c/ov9650.c | 10 +-- drivers/media/i2c/s5c73m3/s5c73m3.h | 6 +- drivers/media/i2c/s5k4ecgx.c | 4 +- drivers/media/i2c/s5k5baf.c | 14 ++-- drivers/media/i2c/s5k6a3.c | 2 +- drivers/media/i2c/s5k6aa.c | 8 +- drivers/media/i2c/saa6752hs.c| 6 +- drivers/media/i2c/saa7115.c | 2 +- drivers/media/i2c/saa717x.c | 2 +- drivers/media/i2c/smiapp/smiapp-core.c | 32 +++ drivers/media/i2c/soc_camera/imx074.c| 8 +- drivers/media/i2c/soc_camera/mt9m001.c | 14 ++-- drivers/media/i2c/soc_camera/mt9m111.c | 70 drivers/media/i2c/soc_camera/mt9t031.c | 10 +-- drivers/media/i2c/soc_camera/mt9t112.c | 22 ++--- drivers/media/i2c/soc_camera/mt9v022.c | 26 +++--- drivers/media/i2c/soc_camera/ov2640.c| 54 ++-- drivers/media/i2c/soc_camera/ov5642.c| 8 +- drivers/media/i2c/soc_camera/ov6650.c| 58 ++--- drivers/media/i2c/soc_camera/ov772x.c| 20 ++--- drivers/media/i2c/soc_camera/ov9640.c| 40 - drivers/media/i2c/soc_camera/ov9740.c| 12 +-- drivers/media/i2c/soc_camera/rj54n1cb0c.c| 54 ++-- drivers/media/i2c/soc_camera/tw9910.c| 10 +-- drivers/media/i2c/sr030pc30.c| 14 ++-- drivers/media/i2c/tvp514x.c | 12 +-- drivers/media/i2c/tvp5150.c | 6 +- drivers/media/i2c/tvp7002.c | 10 +-- drivers/media/i2c/vs6624.c | 18 ++-- drivers/media/pci/cx18/cx18-av-core.c
Re: [PATCH 2/3] v4l: Add V4L2_SEL_TGT_NATIVE_SIZE selection target
On 11/09/2014 12:04 AM, Sakari Ailus wrote: > The V4L2_SEL_TGT_NATIVE_SIZE target is used to denote e.g. the size of a > sensor's pixel array. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/selections-common.xml |8 > include/uapi/linux/v4l2-common.h |2 ++ > 2 files changed, 10 insertions(+) > > diff --git a/Documentation/DocBook/media/v4l/selections-common.xml > b/Documentation/DocBook/media/v4l/selections-common.xml > index 7502f78..5fc833a 100644 > --- a/Documentation/DocBook/media/v4l/selections-common.xml > +++ b/Documentation/DocBook/media/v4l/selections-common.xml > @@ -63,6 +63,14 @@ > Yes > > > + V4L2_SEL_TGT_NATIVE_SIZE > + 0x0003 > + The native size of the device, e.g. a sensor's > + pixel array. You might want to state that top and left are always 0. > + Yes > + Yes > + > + > V4L2_SEL_TGT_COMPOSE > 0x0100 > Compose rectangle. Used to configure scaling > diff --git a/include/uapi/linux/v4l2-common.h > b/include/uapi/linux/v4l2-common.h > index 2f6f8ca..1527398 100644 > --- a/include/uapi/linux/v4l2-common.h > +++ b/include/uapi/linux/v4l2-common.h > @@ -43,6 +43,8 @@ > #define V4L2_SEL_TGT_CROP_DEFAULT0x0001 > /* Cropping bounds */ > #define V4L2_SEL_TGT_CROP_BOUNDS 0x0002 > +/* Native frame size */ > +#define V4L2_SEL_TGT_NATIVE_SIZE 0x0003 > /* Current composing area */ > #define V4L2_SEL_TGT_COMPOSE 0x0100 > /* Default composing area */ > I like this. This would also make it possible to set the 'canvas' size of an mem2mem device. Currently calling S_FMT for a mem2mem device cannot setup any scaler since there is no native size. Instead S_FMT effectively *sets* the native size. The same is true for webcams with a scaler, which is why you added this in the first place. Obviously for sensors this target is read-only, but for a mem2mem device it can be writable as well. However, to make full use of this you also need to add input and output capabilities if the native size can be set: V4L2_IN_CAP_NATIVE_SIZE V4L2_OUT_CAP_NATIVE_SIZE (see ENUMINPUT/ENUMOUTPUT) This would nicely fill in a hole in the V4L2 Spec. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] v4l: Clean up sub-device format documentation
Two small notes... On 11/09/2014 12:04 AM, Sakari Ailus wrote: > The sub-device format documentation documented scaling configuration through > formats. Instead the compose selection rectangle is elsewhere documented to > be used for the purpose. Remove scaling related part of the documentation. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/dev-subdev.xml | 108 > ++-- > 1 file changed, 62 insertions(+), 46 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml > b/Documentation/DocBook/media/v4l/dev-subdev.xml > index d15aaf8..dbf9965 100644 > --- a/Documentation/DocBook/media/v4l/dev-subdev.xml > +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml > @@ -195,53 +195,59 @@ > Sample Pipeline Configuration > > > - > - > - > - > - > + > + > + > + > + > + > > > > - Sensor/0 > - Frontend/0 > - Frontend/1 > - Scaler/0 > - Scaler/1 > + Sensor/0 format > + Frontend/0 format > + Frontend/1 format > + Scaler/0 format > + Scaler/0 compose selection rectangle > + Scaler/1 format > > > > > Initial state > - 2048x1536 > - - > - - > - - > - - > + 2048x1536/SGRBG8_1X8 > + (default) > + (default) > + (default) > + (default) > + (default) > > > - Configure frontend input > - 2048x1536 > - 2048x1536 > - 2046x1534 > - - > - - > + Configure frontend sink format > + 2048x1536/SGRBG8_1X8 > + 2048x1536/SGRBG8_1X8 > + 2046x1534/SGRBG8_1X8 > + (default) > + (default) > + (default) > > > - Configure scaler input > - 2048x1536 > - 2048x1536 > - 2046x1534 > - 2046x1534 > - 2046x1534 > + Configure scaler sink format > + 2048x1536/SGRBG8_1X8 > + 2048x1536/SGRBG8_1X8 > + 2046x1534/SGRBG8_1X8 > + 2046x1534/SGRBG8_1X8 > + 0,0/2046x1534 > + 2046x1534/SGRBG8_1X8 > > > - Configure scaler output > - 2048x1536 > - 2048x1536 > - 2046x1534 > - 2046x1534 > - 1280x960 > + Configure scaler sink compose selection > + 2048x1536/SGRBG8_1X8 > + 2048x1536/SGRBG8_1X8 > + 2046x1534/SGRBG8_1X8 > + 2046x1534/SGRBG8_1X8 > + 0,0/1280x960 > + 1280x960/SGRBG8_1X8 > > > > @@ -249,19 +255,29 @@ > > > > - Initial state. The sensor output is set to its native > 3MP > - resolution. Resolutions on the host frontend and scaler input and output > - pads are undefined. > - The application configures the frontend input pad > resolution to > - 2048x1536. The driver propagates the format to the frontend output pad. > - Note that the propagated output format can be different, as in this > case, > - than the input format, as the hardware might need to crop pixels (for > - instance when converting a Bayer filter pattern to RGB or YUV). Does this Bayer filter note no longer apply? > > - The application configures the scaler input pad > resolution to > - 2046x1534 to match the frontend output resolution. The driver propagates > - the format to the scaler output pad. > - The application configures the scaler output pad > resolution to > - 1280x960. > + Initial state. The sensor source pad format is > + set to its native 3MP size and V4L2_MBUS_FMT_SGRBG8_1X8 > + media bus code. Formats on the host frontend and scaler sink > + and source pads have the default values, as well as the > + compose rectangle on the scaler's sind pad. sind -> sink > + > + The application configures the frontend sink > + pad format's size to 2048x1536 and its media bus code to > + V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the format to > + the frontend source pad. > + > + The application configures the scaler sink pad > + format's size to 2046x1534 and the media bus code to > + V4L2_MBUS_FMT_SGRBG_1X8 to match the frontend source size and > + media bus code. The media bus code on the sink pad is set to > + V4L2_MBUS_FMT_SGRBG_1X8. The driver propagates the size to the > + compose selection rectangle on the scaler's sink pad, and the > + format to the scaler source pad. > + > + The application configures the compose > + selection rectangle of the scaler's sink pad and scaler source > + pad format's size
