Re: [PATCH v4 1/2] rc: Add DT bindings for hix5hd2
On 09/01/2014 11:49 AM, Varka Bhadram wrote: On 08/31/2014 08:09 AM, Zhangfei Gao wrote: From: Guoxiong Yan Signed-off-by: Guoxiong Yan Signed-off-by: Zhangfei Gao --- .../devicetree/bindings/media/hix5hd2-ir.txt | 25 1 file changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt new file mode 100644 index 000..fb5e760 --- /dev/null +++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt @@ -0,0 +1,25 @@ +Device-Tree bindings for hix5hd2 ir IP + +Required properties: +- compatible: Should contain "hisilicon,hix5hd2-ir". +- reg: Base physical address of the controller and length of memory + mapped region. +- interrupts: interrupt-specifier for the sole interrupt generated by + the device. The interrupt specifier format depends on the interrupt + controller parent. +- clocks: clock phandle and specifier pair. +- hisilicon,power-syscon: phandle of syscon used to control power. + No need of tab space before -compatible Give tab spaces after properties... ex: Required properties: - compatible: Should contain "hisilicon,hix5hd2-ir". - reg: Base physical address of the controller and length of memory mapped region. ... Its not standard, but in my view it is understandable. Now every one following this one. Really, I still prefer the original one. Have checked several bindings under media, so add tab ahead like st-rc.txt, gpio-ir-receiver.txt Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] rc: Add DT bindings for hix5hd2
On 08/31/2014 08:09 AM, Zhangfei Gao wrote:
From: Guoxiong Yan
Signed-off-by: Guoxiong Yan
Signed-off-by: Zhangfei Gao
---
.../devicetree/bindings/media/hix5hd2-ir.txt | 25
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
new file mode 100644
index 000..fb5e760
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
@@ -0,0 +1,25 @@
+Device-Tree bindings for hix5hd2 ir IP
+
+Required properties:
+ - compatible: Should contain "hisilicon,hix5hd2-ir".
+ - reg: Base physical address of the controller and length of memory
+ mapped region.
+ - interrupts: interrupt-specifier for the sole interrupt generated by
+ the device. The interrupt specifier format depends on the interrupt
+ controller parent.
+ - clocks: clock phandle and specifier pair.
+ - hisilicon,power-syscon: phandle of syscon used to control power.
+
No need of tab space before -compatible Give tab spaces after properties...
ex:
Required properties:
- compatible: Should contain "hisilicon,hix5hd2-ir".
- reg : Base physical address of the controller and length of
memory
mapped region.
...
Its not standard, but in my view it is understandable. Now every one following
this
one.
Thanks..
+Optional properties:
+ - linux,rc-map-name : Remote control map name.
+
+Example node:
+
+ ir: ir@f8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0xf8001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock HIX5HD2_FIXED_24M>;
+ hisilicon,power-syscon = <&sysctrl>;
+ linux,rc-map-name = "rc-tivo";
+ };
--
Regards,
Varka Bhadram.
--
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: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Sep 1 04:00:20 CEST 2014 git branch: test git hash: b250392f7b5062cf026b1423e27265e278fd6b30 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-1.slh.1-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: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-i686: OK linux-3.17-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-x86_64: OK linux-3.17-rc1-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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: [PATCH v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
On 08/31/2014 04:32 PM, Akihiro TSUKADA wrote: Hi Matthias, thanks for the comment. it sounds wrong to export a second function besides tc90522_attach. This way there is a hard dependency of the bridge driver to the demod driver. In this case it is the only possible demod, but in general it violates the design of demod drivers and their connection to bridge drivers. I agree. I missed that point. si2168_probe at least has a solution for this: Write the pointer to the new i2c adapter into location stored in "struct i2c_adapter **" in the config structure. I'll look into the si2168 code and update tc90522 in v3. Also, I would like to see all new drivers (demod and tuner) implemented as a standard kernel I2C drivers (or any other bus). I have converted already quite many drivers, si2168, si2157, m88ds3103, m88ts2022, it913x, tda18212, ... When drivers are using proper kernel driver models, it allows using kernel services. For example dev_ / pr_ logging (it does not work properly without), RegMap API, I2C client, I2C multiplex, and so... Here is few recent examples: https://patchwork.linuxtv.org/patch/25495/ https://patchwork.linuxtv.org/patch/25152/ https://patchwork.linuxtv.org/patch/25146/ 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 v2 2/2] adv7604: Use DT parsing in dummy creation
Hi Jean-Michel,
Thank you for the patch.
On Friday 29 August 2014 17:15:03 Jean-Michel Hautbois wrote:
> This patch uses DT in order to parse addresses for dummy devices of adv7604.
> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
> I²C ports. Each map has it own I²C address and acts
> as a standard slave device on the I²C bus.
>
> If nothing is defined, it uses default addresses.
> The main prupose is using two adv76xx on the same i2c bus.
>
> Signed-off-by: Jean-Michel Hautbois
> ---
> .../devicetree/bindings/media/i2c/adv7604.txt | 17 +-
> drivers/media/i2c/adv7604.c| 60 ---
> 2 files changed, 55 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
> c27cede..8486b5c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
> @@ -10,8 +10,12 @@ Required Properties:
>
>- compatible: Must contain one of the following
> - "adi,adv7611" for the ADV7611
> +- "adi,adv7604" for the ADV7604
Addition of ADV7604 support is unrelated to the subject and needs to be split
into a separate patch.
> - - reg: I2C slave address
> + - reg: I2C slave addresses
> +The ADV7604 has thirteen 256-byte maps that can be accessed via the
> main
> +I²C ports. Each map has it own I²C address and acts
> +as a standard slave device on the I²C bus.
>
>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
> detection pins, one per HDMI input. The active flag indicates the GPIO
> @@ -32,6 +36,12 @@ The digital output port node must contain at least one
> endpoint. Optional Properties:
>
>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
> + - reg-names : Names of maps with programmable addresses.
> + It can contain any map needing another address than default one.
> + Possible maps names are :
> +ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
> "rep",
> + "edid", "hdmi", "test", "cp", "vdp"
> +ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
>
> Optional Endpoint Properties:
>
> @@ -50,7 +60,10 @@ Example:
>
> hdmi_receiver@4c {
> compatible = "adi,adv7611";
> - reg = <0x4c>;
> + /* edid page will be accessible @ 0x66 on i2c bus */
> + /* other maps keep their default addresses */
> + reg = <0x4c 0x66>;
> + reg-names = "main", "edid";
>
> reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
> hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index d4fa213..56037dd 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -326,6 +326,22 @@ static const struct adv7604_video_standards
> adv7604_prim_mode_hdmi_gr[] = { { },
> };
>
> +static const char const *adv7604_secondary_names[] = {
> + "main", /* ADV7604_PAGE_IO */
> + "avlink", /* ADV7604_PAGE_AVLINK */
> + "cec", /* ADV7604_PAGE_CEC */
> + "infoframe", /* ADV7604_PAGE_INFOFRAME */
> + "esdp", /* ADV7604_PAGE_ESDP */
> + "dpp", /* ADV7604_PAGE_DPP */
> + "afe", /* ADV7604_PAGE_AFE */
> + "rep", /* ADV7604_PAGE_REP */
> + "edid", /* ADV7604_PAGE_EDID */
> + "hdmi", /* ADV7604_PAGE_HDMI */
> + "test", /* ADV7604_PAGE_TEST */
> + "cp", /* ADV7604_PAGE_CP */
> + "vdp" /* ADV7604_PAGE_VDP */
> +};
> +
> /* ---
> */
>
> static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
> @@ -2528,13 +2544,31 @@ static void adv7604_unregister_clients(struct
> adv7604_state *state) }
>
> static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
> - u8 addr, u8 io_reg)
> + unsigned int i)
> {
> struct i2c_client *client = v4l2_get_subdevdata(sd);
> + struct adv7604_platform_data *pdata = client->dev.platform_data;
> + unsigned int io_reg = 0xf2 + i;
> + unsigned int default_addr = io_read(sd, io_reg) >> 1;
This modifies the behaviour of the driver. It previously used fixed default
addresses in the DT case, and now defaults to whatever has been programmed in
the chip. This might not be an issue in itself, but it should be documented in
the commit message (and possibly split to a separate patch).
> + struct i2c_client *new_client;
> +
> + if (IS_ENABLED(CONFIG_OF)) {
> + /* Try to find it in DT */
> + new_client = i2c_new_secondary_device(client,
> + adv7604_secondary_names[i], default_addr);
> + } else if (pdata) {
> + if (pdata->i2c_addresses
Re: strange empia device
On Sun, Aug 31, 2014 at 04:50:08PM +0200, Frank Schäfer wrote: > Hmm... could you send us the output of "lsusb -v -d 1b80:e31d ? Sure, here is it. However it seems that roxio violated the most sacred USB rule (i.e. they use that vid/pid for two different kinds of hardware); in fact even people on Windows have troubles with it (and a guaranteed blue screen on Win8, it seems :D) I already had some experience in reverse engineering a webcam (in fact I even 'patched' the 8051 firmware and fully disassembled the win driver for one chinese Cypress EZ2 based cam), but that was very painful and I don't actually want to repeat the experience :D Bus 002 Device 005: ID 1b80:e31d Afatech Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1b80 Afatech idProduct 0xe31d bcdDevice1.00 iManufacturer 0 iProduct1 Roxio Video Capture USB iSerial 2 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 406 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0001 1x 1 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x 1x 0 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x03ac 1x 940 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes2 Transfer TypeBulk
Re: HVR 900 (USB ID 2040:6500) no analogue sound reloaded
Am 22.08.2014 um 21:03 schrieb Oravecz Csaba: > I reported this issue earlier but for some reason it went pretty much > unnoticed. The essence is that with the newest em28xx drivers now present in > 3.14 kernels (i'm on stock fedora 3.14.15-100.fc19.i686.PAE) I can't get > analogue sound from this card. > > I see that the code snippet that produced this output in the pre 3.14 versions > > em2882/3 #0: Config register raw data: 0x50 > em2882/3 #0: AC97 vendor ID = 0x > em2882/3 #0: AC97 features = 0x6a90 > em2882/3 #0: Empia 202 AC97 audio processor detected > > is still there in em28xx-core.c, however, there is nothing like that in > current kernel logs so it seems that this part of the code is just skipped, > which I tend to think is not the intended behaviour. I have not gone any > further to investigate the issue, rather I've simply copied the 'old' em28xx > directory over the current one in the latest source and compiled the drivers > in this way and so got back the old em28xx version, which is working well in > the current kernel as well. > > I don't consider this an optimal solution so > I would very much appreciate any help in this issue. > > best, > o.cs. Thank you for reporting this issue. I suspect reverting commit b99f0aadd3 "[media] em28xx: check if a device has audio earlier" will resolve it. Can you check that ? Regards, Frank -- 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: strange empia device
Am 31.08.2014 um 16:47 schrieb Frank Schäfer: > Hi Lorenzo, > > Am 25.08.2014 um 21:01 schrieb Lorenzo Marcantonio: >> Just bought a roxio video capture dongle. Read around that it was an >> easycap clone (supported, then); it seems it's not so anymore :( >> >> It identifies as 1b80:e31d Roxio Video Capture USB >> >> (it also uses audio class for audio) >> >> Now comes the funny thing. Inside there is the usual E2P memory, >> a regulator or two and an empia marked EM2980 (*not* em2890!); some >> passive and nothing else. >> >> Digging around in the driver cab (emBDA.inf) shows that it seems an >> em28285 driver rebranded by roxio... it installs emBDAA.sys and >> emOEMA.sys (pretty big: about 1.5MB combined!); also a 16KB merlinFW.rom >> (presumably a firmware for the em chip? I tought they were fixed >> function); also the usual directshow .ax filter and some exe in >> autorun (emmona.exe: firmware/setup loader?). >> >> Looking in the em28xx gave me the idea that that thing is not >> supported (at least in my current 3.6.6)... however the empia sites says >> (here http://www.empiatech.com/wp/video-grabber-em282xx/) 28284 should >> be linux supported. Nothing said about 28285. And the chip is marked >> 2980?! by the way, forcing the driver to load I get this: >> >> [ 3439.787701] em28xx: New device Roxio Video Capture USB @ 480 Mbps >> (1b80:e31d, interface 0, class 0) >> [ 3439.787704] em28xx: Video interface 0 found >> [ 3439.787705] em28xx: DVB interface 0 found >> [ 3439.787866] em28xx #0: em28xx chip ID = 146 >> >> Is there any hope to make it work (even on git kernel there is nothing >> for chip id 146...)? >> > See http://www.spinics.net/lists/linux-media/msg73699.html > > HTH, > Frank Hmm... could you send us the output of "lsusb -v -d 1b80:e31d ? Thanks, Frank -- 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: strange empia device
Hi Lorenzo, Am 25.08.2014 um 21:01 schrieb Lorenzo Marcantonio: > Just bought a roxio video capture dongle. Read around that it was an > easycap clone (supported, then); it seems it's not so anymore :( > > It identifies as 1b80:e31d Roxio Video Capture USB > > (it also uses audio class for audio) > > Now comes the funny thing. Inside there is the usual E2P memory, > a regulator or two and an empia marked EM2980 (*not* em2890!); some > passive and nothing else. > > Digging around in the driver cab (emBDA.inf) shows that it seems an > em28285 driver rebranded by roxio... it installs emBDAA.sys and > emOEMA.sys (pretty big: about 1.5MB combined!); also a 16KB merlinFW.rom > (presumably a firmware for the em chip? I tought they were fixed > function); also the usual directshow .ax filter and some exe in > autorun (emmona.exe: firmware/setup loader?). > > Looking in the em28xx gave me the idea that that thing is not > supported (at least in my current 3.6.6)... however the empia sites says > (here http://www.empiatech.com/wp/video-grabber-em282xx/) 28284 should > be linux supported. Nothing said about 28285. And the chip is marked > 2980?! by the way, forcing the driver to load I get this: > > [ 3439.787701] em28xx: New device Roxio Video Capture USB @ 480 Mbps > (1b80:e31d, interface 0, class 0) > [ 3439.787704] em28xx: Video interface 0 found > [ 3439.787705] em28xx: DVB interface 0 found > [ 3439.787866] em28xx #0: em28xx chip ID = 146 > > Is there any hope to make it work (even on git kernel there is nothing > for chip id 146...)? > See http://www.spinics.net/lists/linux-media/msg73699.html HTH, Frank -- 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 v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
Hi Matthias, thanks for the comment. > it sounds wrong to export a second function besides tc90522_attach. > This way there is a hard dependency of the bridge driver to the demod > driver. > In this case it is the only possible demod, but in general it violates > the design of demod drivers and their connection to bridge drivers. I agree. I missed that point. > > si2168_probe at least has a solution for this: > Write the pointer to the new i2c adapter into location stored in "struct > i2c_adapter **" in the config structure. I'll look into the si2168 code and update tc90522 in v3. regards, akihiro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] [media] cx231xx: Add support for Hauppauge WinTV-HVR-901H (1114xx)
Add support for:
[2040:b139] Hauppauge WinTV HVR-901H (1114xx)
According to the inf file, the hardware is similar to [2040:b131] Hauppauge
WinTV 930C-HD (model 1114xx)
The only difference is the demod Si2161 instead of Si2165 (but both are
supported by the si2165 driver).
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index a03a31a..791f00c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -744,7 +744,7 @@ struct cx231xx_board cx231xx_boards[] = {
} },
},
[CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx] = {
- .name = "Hauppauge WinTV 930C-HD (1114xx) / PCTV QuatroStick
522e",
+ .name = "Hauppauge WinTV 930C-HD (1114xx) / HVR-901H (1114xx) /
PCTV QuatroStick 522e",
.tuner_type = TUNER_ABSENT,
.tuner_addr = 0x60,
.tuner_gpio = RDE250_XCV_TUNER,
@@ -818,6 +818,9 @@ struct usb_device_id cx231xx_id_table[] = {
/* Hauppauge WinTV-HVR-900-H */
{USB_DEVICE(0x2040, 0xb138),
.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
+ /* Hauppauge WinTV-HVR-901-H */
+ {USB_DEVICE(0x2040, 0xb139),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx},
{USB_DEVICE(0x2040, 0xb140),
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xc200),
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] [media] cx231xx: Add support for Hauppauge WinTV-HVR-900H (111xxx)
Add support for:
[2040:b138] Hauppauge WinTV HVR-900H (111xxx)
The hardware is similar to [2040:b130] Hauppauge WinTV 930C-HD (model 1113xx)
The only difference is the demod Si2161 instead of Si2165 (but both are
supported by the si2165 driver).
Signed-off-by: Matthias Schwarzott
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index 8039b76..a03a31a 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -705,7 +705,7 @@ struct cx231xx_board cx231xx_boards[] = {
},
},
[CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx] = {
- .name = "Hauppauge WinTV 930C-HD (1113xx) / PCTV QuatroStick
521e",
+ .name = "Hauppauge WinTV 930C-HD (1113xx) / HVR-900H (111xxx) /
PCTV QuatroStick 521e",
.tuner_type = TUNER_NXP_TDA18271,
.tuner_addr = 0x60,
.tuner_gpio = RDE250_XCV_TUNER,
@@ -815,6 +815,9 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb131),
.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx},
+ /* Hauppauge WinTV-HVR-900-H */
+ {USB_DEVICE(0x2040, 0xb138),
+.driver_info = CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx},
{USB_DEVICE(0x2040, 0xb140),
.driver_info = CX231XX_BOARD_HAUPPAUGE_EXETER},
{USB_DEVICE(0x2040, 0xc200),
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] get_dvb_firmware: si2165: drop the extra header from the firmware
Store it with a different name based on hardware revision.
Signed-off-by: Matthias Schwarzott
---
Documentation/dvb/get_dvb_firmware | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 26c623d..a0971fa 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -787,7 +787,8 @@ sub si2165 {
my $sourcefile = "model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip";
my $url = "http://www.hauppauge.de/files/drivers/";;
my $hash = "76633e7c76b0edee47c3ba18ded99336";
-my $fwfile = "dvb-demod-si2165.fw";
+my $fwfile = "dvb-demod-si2165-D.fw";
+my $fwhash = "1255c70a53fe562a89d5ff08d7461e2c";
my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
checkstandard();
@@ -795,21 +796,8 @@ sub si2165 {
wgetfile($sourcefile, $url . $sourcefile);
verify($sourcefile, $hash);
unzip($sourcefile, $tmpdir);
-extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788,
"$tmpdir/fw1");
-
-delzero("$tmpdir/fw1","$tmpdir/fw1-1");
-#verify("$tmpdir/fw1","5e0909858fdf0b5b09ad48b9fe622e70");
-
-my $CRC="\x0A\xCC";
-my $BLOCKS_MAIN="\x27";
-open FW,">$fwfile";
-print FW "\x01\x00"; # just a version id for the driver itself
-print FW "\x9A"; # fw version
-print FW "\x00"; # padding
-print FW "$BLOCKS_MAIN"; # number of blocks of main part
-print FW "\x00"; # padding
-print FW "$CRC"; # 16bit crc value of main part
-appendfile(FW,"$tmpdir/fw1");
+extract("$tmpdir/Driver10/Hcw10bda.sys", 0x80788, 0x81E08-0x80788,
"$fwfile");
+verify($fwfile, $fwhash);
"$fwfile";
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] [media] mceusb: add support for more cx231xx devices
From: Mauro Carvalho Chehab
Add support for the si2161-based cx231xx devices:
[2040:b138] Hauppauge WinTV HVR-900-H (model 111xxx)
[2040:b139] Hauppauge WinTV HVR-901-H (model 1114xx)
They're similar to the already supported:
[2040:b130] Hauppauge WinTV 930C-HD (model 1113xx)
Signed-off-by: Matthias Schwarzott
---
drivers/media/rc/mceusb.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 45b0894..383e24a 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -397,6 +397,10 @@ static struct usb_device_id mceusb_dev_table[] = {
.driver_info = HAUPPAUGE_CX_HYBRID_TV },
{ USB_DEVICE(VENDOR_HAUPPAUGE, 0xb131),
.driver_info = HAUPPAUGE_CX_HYBRID_TV },
+ { USB_DEVICE(VENDOR_HAUPPAUGE, 0xb138),
+ .driver_info = HAUPPAUGE_CX_HYBRID_TV },
+ { USB_DEVICE(VENDOR_HAUPPAUGE, 0xb139),
+ .driver_info = HAUPPAUGE_CX_HYBRID_TV },
{ USB_DEVICE(VENDOR_PCTV, 0x0259),
.driver_info = HAUPPAUGE_CX_HYBRID_TV },
{ USB_DEVICE(VENDOR_PCTV, 0x025e),
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Add support for Si2161 demod and improve firmware handling
This series adds support for Si2161 based devices. cx231xx based WinTV-HVR-900-H works with it. cx231xx based WinTV-HVR-901-H should also work. Additionally it simplifies firmware structure by no longer adding a seperate header as suggested by Antti. Regards Matthias -- 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 7/7] si2165: do load firmware without extra header
The new file has a different name: dvb-demod-si2165-D.fw
Count blocks instead of reading count from extra header.
Calculate CRC during upload and compare result to what chip calcuated.
Use 0x01 instead of real patch version, because this is only used to
check if something was uploaded but not to check the version of it.
Signed-off-by: Matthias Schwarzott
---
drivers/media/dvb-frontends/Kconfig | 1 +
drivers/media/dvb-frontends/si2165.c | 105 ++
drivers/media/dvb-frontends/si2165_priv.h | 2 +-
3 files changed, 66 insertions(+), 42 deletions(-)
diff --git a/drivers/media/dvb-frontends/Kconfig
b/drivers/media/dvb-frontends/Kconfig
index aa5ae22..c57ec49 100644
--- a/drivers/media/dvb-frontends/Kconfig
+++ b/drivers/media/dvb-frontends/Kconfig
@@ -66,6 +66,7 @@ config DVB_TDA18271C2DD
config DVB_SI2165
tristate "Silicon Labs si2165 based"
depends on DVB_CORE && I2C
+ select CRC_ITU_T
default m if !MEDIA_SUBDRV_AUTOSELECT
help
A DVB-C/T demodulator.
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index fe4e8f2..c807180 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include "dvb_frontend.h"
#include "dvb_math.h"
@@ -327,8 +328,50 @@ static bool si2165_wait_init_done(struct si2165_state
*state)
return ret;
}
+static int si2165_count_fw_blocks(struct si2165_state *state, const u8 *data,
+ u32 len)
+{
+ int block_count = 0;
+ u32 offset = 0;
+
+ if (len % 4 != 0) {
+ dev_warn(&state->i2c->dev, "%s: firmware size is not multiple
of 4\n",
+ KBUILD_MODNAME);
+ return -EINVAL;
+ }
+
+ while (offset + 4 <= len) {
+ u8 wordcount = data[offset];
+
+ if (wordcount < 1 || data[offset+1] ||
+ data[offset+2] || data[offset+3]) {
+ dev_warn(&state->i2c->dev,
+"%s: bad fw data[0..3] = %*ph at offset=%d\n",
+ KBUILD_MODNAME, 4, data, offset);
+ return -EINVAL;
+ }
+ offset += 8 + 4 * wordcount;
+ ++block_count;
+ }
+ if (offset != len) {
+ dev_warn(&state->i2c->dev,
+ "%s: firmware length does not match content,
len=%d, offset=%d\n",
+ KBUILD_MODNAME, len, offset);
+ return -EINVAL;
+ }
+ if (block_count < 6) {
+ dev_err(&state->i2c->dev, "%s: firmware is too short: Only %d
blocks\n",
+ KBUILD_MODNAME, block_count);
+ return -EINVAL;
+ }
+ block_count -= 6;
+ dev_info(&state->i2c->dev, "%s: si2165_upload_firmware counted %d main
blocks\n",
+ KBUILD_MODNAME, block_count);
+ return block_count;
+}
+
static int si2165_upload_firmware_block(struct si2165_state *state,
- const u8 *data, u32 len, u32 *poffset, u32 block_count)
+ const u8 *data, u32 len, u32 *poffset, u32 block_count, u16 *crc)
{
int ret;
u8 buf_ctrl[4] = { 0x00, 0x00, 0x00, 0xc0 };
@@ -374,6 +417,10 @@ static int si2165_upload_firmware_block(struct
si2165_state *state,
offset += 8;
while (wordcount > 0) {
+ *crc = crc_itu_t_byte(*crc, *(data+offset+3));
+ *crc = crc_itu_t_byte(*crc, *(data+offset+2));
+ *crc = crc_itu_t_byte(*crc, *(data+offset+1));
+ *crc = crc_itu_t_byte(*crc, *(data+offset+0));
ret = si2165_write(state, 0x36c, data+offset, 4);
if (ret < 0)
goto error;
@@ -408,10 +455,9 @@ static int si2165_upload_firmware(struct si2165_state
*state)
u8 *fw_file;
const u8 *data;
u32 len;
- u32 offset;
- u8 patch_version;
- u8 block_count;
- u16 crc_expected;
+ u32 offset = 0;
+ int main_block_count;
+ u16 crc = 0;
switch (state->chip_revcode) {
case 0x03: /* revision D */
@@ -437,32 +483,13 @@ static int si2165_upload_firmware(struct si2165_state
*state)
dev_info(&state->i2c->dev, "%s: downloading firmware from file '%s'
size=%d\n",
KBUILD_MODNAME, fw_file, len);
- if (len % 4 != 0) {
- dev_warn(&state->i2c->dev, "%s: firmware size is not multiple
of 4\n",
- KBUILD_MODNAME);
- ret = -EINVAL;
- goto error;
- }
-
- /* check header (8 bytes) */
- if (len < 8) {
- dev_warn(&state->i2c->dev, "%s: firmware header is missing\n",
-
[PATCH 1/7] si2165: Load driver for all hardware revisions
Current firmware is only for revision D.
Signed-off-by: Matthias Schwarzott
---
drivers/media/dvb-frontends/si2165.c | 26 +-
drivers/media/dvb-frontends/si2165_priv.h | 2 +-
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index 3a2d6c5..65e0dc9 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -44,9 +44,7 @@ struct si2165_state {
struct si2165_config config;
- /* chip revision */
- u8 revcode;
- /* chip type */
+ u8 chip_revcode;
u8 chip_type;
/* calculated by xtal and div settings */
@@ -407,7 +405,7 @@ static int si2165_upload_firmware(struct si2165_state
*state)
int ret;
const struct firmware *fw = NULL;
- u8 *fw_file = SI2165_FIRMWARE;
+ u8 *fw_file;
const u8 *data;
u32 len;
u32 offset;
@@ -415,10 +413,20 @@ static int si2165_upload_firmware(struct si2165_state
*state)
u8 block_count;
u16 crc_expected;
+ switch (state->chip_revcode) {
+ case 0x03: /* revision D */
+ fw_file = SI2165_FIRMWARE_REV_D;
+ break;
+ default:
+ dev_info(&state->i2c->dev, "%s: no firmware file for
revision=%d\n",
+ KBUILD_MODNAME, state->chip_revcode);
+ return 0;
+ }
+
/* request the firmware, this will block and timeout */
ret = request_firmware(&fw, fw_file, state->i2c->dev.parent);
if (ret) {
- dev_warn(&state->i2c->dev, "%s: firmare file '%s' not found\n",
+ dev_warn(&state->i2c->dev, "%s: firmware file '%s' not found\n",
KBUILD_MODNAME, fw_file);
goto error;
}
@@ -984,7 +992,7 @@ struct dvb_frontend *si2165_attach(const struct
si2165_config *config,
if (val != state->config.chip_mode)
goto error;
- io_ret = si2165_readreg8(state, 0x0023 , &state->revcode);
+ io_ret = si2165_readreg8(state, 0x0023, &state->chip_revcode);
if (io_ret < 0)
goto error;
@@ -998,13 +1006,13 @@ struct dvb_frontend *si2165_attach(const struct
si2165_config *config,
goto error;
dev_info(&state->i2c->dev, "%s: hardware revision 0x%02x, chip type
0x%02x\n",
-KBUILD_MODNAME, state->revcode, state->chip_type);
+KBUILD_MODNAME, state->chip_revcode, state->chip_type);
/* It is a guess that register 0x0118 (chip type?) can be used to
* differ between si2161, si2163 and si2165
* Only si2165 has been tested.
*/
- if (state->revcode == 0x03 && state->chip_type == 0x07) {
+ if (state->chip_type == 0x07) {
state->has_dvbt = true;
state->has_dvbc = true;
} else {
@@ -1037,4 +1045,4 @@ MODULE_PARM_DESC(debug, "Turn on/off frontend debugging
(default:off).");
MODULE_DESCRIPTION("Silicon Labs Si2165 DVB-C/-T Demodulator driver");
MODULE_AUTHOR("Matthias Schwarzott ");
MODULE_LICENSE("GPL");
-MODULE_FIRMWARE(SI2165_FIRMWARE);
+MODULE_FIRMWARE(SI2165_FIRMWARE_REV_D);
diff --git a/drivers/media/dvb-frontends/si2165_priv.h
b/drivers/media/dvb-frontends/si2165_priv.h
index d4cc93f..2b70cf1 100644
--- a/drivers/media/dvb-frontends/si2165_priv.h
+++ b/drivers/media/dvb-frontends/si2165_priv.h
@@ -18,6 +18,6 @@
#ifndef _DVB_SI2165_PRIV
#define _DVB_SI2165_PRIV
-#define SI2165_FIRMWARE "dvb-demod-si2165.fw"
+#define SI2165_FIRMWARE_REV_D "dvb-demod-si2165.fw"
#endif /* _DVB_SI2165_PRIV */
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] si2165: enable Si2161 support
Additionally print chip name with revision symbolically.
This is a preparation for supporting new Hauppauge WinTV-HVR-900-H based
on cx231xx.
Signed-off-by: Matthias Schwarzott
---
drivers/media/dvb-frontends/si2165.c | 39 +---
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2165.c
b/drivers/media/dvb-frontends/si2165.c
index 65e0dc9..fe4e8f2 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -1,5 +1,5 @@
/*
-Driver for Silicon Labs SI2165 DVB-C/-T Demodulator
+Driver for Silicon Labs Si2161 DVB-T and Si2165 DVB-C/-T Demodulator
Copyright (C) 2013-2014 Matthias Schwarzott
@@ -916,7 +916,7 @@ static void si2165_release(struct dvb_frontend *fe)
static struct dvb_frontend_ops si2165_ops = {
.info = {
- .name = "Silicon Labs Si2165",
+ .name = "Silicon Labs ",
.caps = FE_CAN_FEC_1_2 |
FE_CAN_FEC_2_3 |
FE_CAN_FEC_3_4 |
@@ -956,6 +956,8 @@ struct dvb_frontend *si2165_attach(const struct
si2165_config *config,
int n;
int io_ret;
u8 val;
+ char rev_char;
+ const char *chip_name;
if (config == NULL || i2c == NULL)
goto error;
@@ -1005,22 +1007,35 @@ struct dvb_frontend *si2165_attach(const struct
si2165_config *config,
if (io_ret < 0)
goto error;
- dev_info(&state->i2c->dev, "%s: hardware revision 0x%02x, chip type
0x%02x\n",
-KBUILD_MODNAME, state->chip_revcode, state->chip_type);
+ if (state->chip_revcode < 26)
+ rev_char = 'A' + state->chip_revcode;
+ else
+ rev_char = '?';
- /* It is a guess that register 0x0118 (chip type?) can be used to
-* differ between si2161, si2163 and si2165
-* Only si2165 has been tested.
-*/
- if (state->chip_type == 0x07) {
+ switch (state->chip_type) {
+ case 0x06:
+ chip_name = "Si2161";
+ state->has_dvbt = true;
+ break;
+ case 0x07:
+ chip_name = "Si2165";
state->has_dvbt = true;
state->has_dvbc = true;
- } else {
- dev_err(&state->i2c->dev, "%s: Unsupported chip.\n",
- KBUILD_MODNAME);
+ break;
+ default:
+ dev_err(&state->i2c->dev, "%s: Unsupported Silicon Labs chip
(type %d, rev %d)\n",
+ KBUILD_MODNAME, state->chip_type, state->chip_revcode);
goto error;
}
+ dev_info(&state->i2c->dev,
+ "%s: Detected Silicon Labs %s-%c (type %d, rev %d)\n",
+ KBUILD_MODNAME, chip_name, rev_char, state->chip_type,
+ state->chip_revcode);
+
+ strlcat(state->frontend.ops.info.name, chip_name,
+ sizeof(state->frontend.ops.info.name));
+
n = 0;
if (state->has_dvbt) {
state->frontend.ops.delsys[n++] = SYS_DVBT;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cx23885-dvb.c:undefined reference to `tda18271_attach'
tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: fd5984d7c8e8e249aca0c515817ab1e7dee1502c commit: 7b34be71db533f3e0cf93d53cf62d036cdb5418a [media] use IS_ENABLED() macro date: 1 year, 7 months ago config: i386-randconfig-x1-08311744 (attached as .config) All error/warnings: drivers/built-in.o: In function `dvb_register': >> cx23885-dvb.c:(.text+0x180a60): undefined reference to `tda18271_attach' --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.8.0-rc3 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT="elf32-i386" CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-ecx -fcall-saved-edx" CONFIG_ARCH_CPU_PROBE_RELEASE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SYSVIPC is not set CONFIG_FHANDLE=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_IRQ_TIME_ACCOUNTING=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_NOCB_CPU=y CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set # CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_HAVE_UID16=y # CONFIG_UID16 is not set CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_PCSPKR_PLATFORM is not set CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y # CONFIG_AIO is not set CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set # CONFIG_VM_EVENT_COUNTERS is
Re: [PATCH v2 4/5] tc90522: add driver for Toshiba TC90522 quad demodulator
On 27.08.2014 17:29, tsk...@gmail.com wrote:
> From: Akihiro Tsukada
>
Hi Akihiro,
> This patch adds driver for tc90522 demodulator chips.
> The chip contains 4 demod modules that run in parallel and are independently
> controllable via separate I2C addresses.
> Two of the modules are for ISDB-T and the rest for ISDB-S.
> It is used in earthsoft pt3 cards.
>
> Note that this driver does not init the chip,
> because the initilization sequence / register setting is not disclosed.
> Thus, the driver assumes that the chips are initilized externally
> by its parent board driver before fe->ops->init() are called.
> Earthsoft PT3 PCIe card, for example, contains the init sequence
> in its private memory and provides a command to trigger the sequence.
>
> Signed-off-by: Akihiro Tsukada
> +
> +struct dvb_frontend *
> +tc90522_attach(const struct tc90522_config *cfg, struct i2c_adapter *i2c)
> +{
> + struct tc90522_state *state;
> + const struct dvb_frontend_ops *ops;
> + struct i2c_adapter *adap;
> + int ret;
> +
> + state = kzalloc(sizeof(*state), GFP_KERNEL);
> + if (!state)
> + return NULL;
> +
> + memcpy(&state->cfg, cfg, sizeof(*cfg));
> + state->i2c = i2c;
> + ops = TC90522_IS_ISDBS(cfg->addr) ? &tc90522_ops_sat : &tc90522_ops_ter;
> + memcpy(&state->dvb_fe.ops, ops, sizeof(*ops));
> + state->dvb_fe.demodulator_priv = state;
> +
> + adap = &state->tuner_i2c;
> + adap->owner = i2c->owner;
> + adap->algo = &tc90522_tuner_i2c_algo;
> + adap->dev.parent = i2c->dev.parent;
> + strlcpy(adap->name, "tc90522 tuner", sizeof(adap->name));
> + i2c_set_adapdata(adap, state);
> + ret = i2c_add_adapter(adap);
> + if (ret < 0) {
> + kfree(state);
> + return NULL;
> + }
> + dev_info(&i2c->dev, "Toshiba TC90522 attached.\n");
> + return &state->dvb_fe;
> +}
> +EXPORT_SYMBOL(tc90522_attach);
> +
> +
> +struct i2c_adapter *tc90522_get_tuner_i2c(struct dvb_frontend *fe)
> +{
> + struct tc90522_state *state;
> +
> + state = fe->demodulator_priv;
> + return &state->tuner_i2c;
> +}
> +EXPORT_SYMBOL(tc90522_get_tuner_i2c);
> +
> +
> +MODULE_DESCRIPTION("Toshiba TC90522 frontend");
> +MODULE_AUTHOR("Akihiro TSUKADA");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/media/dvb-frontends/tc90522.h
> b/drivers/media/dvb-frontends/tc90522.h
> new file mode 100644
> index 000..d55a6be
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/tc90522.h
> @@ -0,0 +1,63 @@
> +/*
> + * Toshiba TC90522 Demodulator
> + *
> + * Copyright (C) 2014 Akihiro Tsukada
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation version 2.
> + *
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +/*
> + * The demod has 4 input (2xISDB-T and 2xISDB-S),
> + * and provides independent sub modules for each input.
> + * As the sub modules work in parallel and have the separate i2c addr's,
> + * this driver treats each sub module as one demod device.
> + */
> +
> +#ifndef TC90522_H
> +#define TC90522_H
> +
> +#include
> +#include
> +#include "dvb_frontend.h"
> +
> +#define TC90522_IS_ISDBS(addr) (addr & 1)
> +
> +#define TC90522T_CMD_SET_LNA 1
> +#define TC90522S_CMD_SET_LNB 1
> +
> +struct tc90522_config {
> + u8 addr;
> +};
> +
> +#if IS_ENABLED(CONFIG_DVB_TC90522)
> +
> +extern struct dvb_frontend *tc90522_attach(const struct tc90522_config *cfg,
> + struct i2c_adapter *i2c);
> +
> +extern struct i2c_adapter *tc90522_get_tuner_i2c(struct dvb_frontend *fe);
> +
it sounds wrong to export a second function besides tc90522_attach.
This way there is a hard dependency of the bridge driver to the demod
driver.
In this case it is the only possible demod, but in general it violates
the design of demod drivers and their connection to bridge drivers.
si2168_probe at least has a solution for this:
Write the pointer to the new i2c adapter into location stored in "struct
i2c_adapter **" in the config structure.
Regards
Matthias
--
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] videobuf: Allow reqbufs(0) to free current buffers
All the infrastructure for this is already there, and despite our desires for
the old videobuf code to go away, it is currently still in use in 18 drivers.
Allowing reqbufs(0) makes these drivers behave consistent with modern drivers,
making live easier for userspace, see e.g. :
https://bugzilla.gnome.org/show_bug.cgi?id=735660
Signed-off-by: Hans de Goede
---
drivers/media/v4l2-core/videobuf-core.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf-core.c
b/drivers/media/v4l2-core/videobuf-core.c
index fb5ee5d..b91a266 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -441,11 +441,6 @@ int videobuf_reqbufs(struct videobuf_queue *q,
unsigned int size, count;
int retval;
- if (req->count < 1) {
- dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
- return -EINVAL;
- }
-
if (req->memory != V4L2_MEMORY_MMAP &&
req->memory != V4L2_MEMORY_USERPTR &&
req->memory != V4L2_MEMORY_OVERLAY) {
@@ -471,6 +466,12 @@ int videobuf_reqbufs(struct videobuf_queue *q,
goto done;
}
+ if (req->count == 0) {
+ dprintk(1, "reqbufs: count invalid (%d)\n", req->count);
+ retval = __videobuf_free(q);
+ goto done;
+ }
+
count = req->count;
if (count > VIDEO_MAX_FRAME)
count = VIDEO_MAX_FRAME;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
