date:20140312

Re: [git:media_tree/master] [media] Siano: smsusb - Add a device id for PX-S1UD

2014-03-12 Thread Sat

Thank you for the update, Mauro.
I didn't know how to check the status, now I get it :-)

Thanks,
Satoshi

(2014/03/12 0:12), Mauro Carvalho Chehab wrote:
 This is an automatic generated email to let you know that the following patch 
 were queued at the
 http://git.linuxtv.org/media_tree.git tree:
 
 Subject: [media] Siano: smsusb - Add a device id for PX-S1UD
 Author:  Satoshi Nagahama satt...@aim.com
 Date:Mon Feb 10 06:45:29 2014 -0300
 
 Add a device id to support for PX-S1UD (PLEX ISDB-T usb dongle) which
 has sms2270.
 
 Signed-off-by: Satoshi Nagahama satt...@aim.com
 Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
 
   drivers/media/usb/siano/smsusb.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
 
 ---
 
 http://git.linuxtv.org/media_tree.git?a=commitdiff;h=f61e2268a06c3ea7354a1f4b3d878bedb8b776b1
 
 diff --git a/drivers/media/usb/siano/smsusb.c 
 b/drivers/media/usb/siano/smsusb.c
 index 05bd91a..1836a41 100644
 --- a/drivers/media/usb/siano/smsusb.c
 +++ b/drivers/media/usb/siano/smsusb.c
 @@ -653,6 +653,8 @@ static const struct usb_device_id smsusb_id_table[] = {
   .driver_info = SMS1XXX_BOARD_ZTE_DVB_DATA_CARD },
   { USB_DEVICE(0x19D2, 0x0078),
   .driver_info = SMS1XXX_BOARD_ONDA_MDTV_DATA_CARD },
 + { USB_DEVICE(0x3275, 0x0080),
 + .driver_info = SMS1XXX_BOARD_SIANO_RIO },
   { } /* Terminating entry */
   };
   
 

--
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: problems with Cinergy HTC HD Rev. 2 (0x0ccd:0x0101) Conexant 231xx

2014-03-12 Thread Matthias Schwarzott

On 10.03.2014 10:51, Jan Gebhardt wrote:
Hi,

i have some problems using the Terratec Cinergy HTC Stick HD Rev. 2 .

The driver or the specification is currenty not implemented into
driverset of media-build.

That means nothing happened when plugging the stick in?

All i know is, that there is a buildin Conexant Chip (I think the
CX23102) and a SiliconLabs Tuner (SI2173). I already tried to adapt this
knownledge combined with the configuration of the windows driver to the
driver(cx231xx) but sadly without success.

How did you check the chips that are present?
Did you read through the inf file of the windows driver or open the device?

Looking at the inf file you attached, it most likely has a si2165
dvb-c/t demod.

I wrote a first driver for this demod.

But I think the tuner is unsupported (si2173 or si2170 as inf file says).
Google only found these documents:
- https://www.silabs.com/Support%20Documents/TechnicalDocs/Si2173-short.pdf
- http://electronix.ru/forum/index.php?act=attachtype=postid=66442

But both documents skip the detailed programming.

And I found this driver for si2176:
https://github.com/fards/AMlogic_Meson6_030812release/blob/master/drivers/amlogic/tuners/si2176_func.c
But I am not sure about the relation between si2170, si2173 and si2176

For adding support your device, you need to go through the normal
process described in the wiki.
Part of this is recording usb traffic.
This can then partially be matched to the existing drivers.

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

Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of

2014-03-12 Thread Russell King - ARM Linux

On Mon, Mar 10, 2014 at 02:52:53PM +0100, Laurent Pinchart wrote:
 In theory unidirectional links in DT are indeed enough. However, let's not 
 forget the following.
 
 - There's no such thing as single start points for graphs. Sure, in some 
 simple cases the graph will have a single start point, but that's not a 
 generic rule. For instance the camera graphs 
 http://ideasonboard.org/media/omap3isp.ps and 
 http://ideasonboard.org/media/eyecam.ps have two camera sensors, and thus two 
 starting points from a data flow point of view.

I think we need to stop thinking of a graph linked in terms of data
flow - that's really not useful.

Consider a display subsystem.  The CRTC is the primary interface for
the CPU - this is the most interesting interface, it's the interface
which provides access to the picture to be displayed for the CPU.  Other
interfaces are secondary to that purpose - reading the I2C DDC bus for
the display information is all secondary to the primary purpose of
displaying a picture.

For a capture subsystem, the primary interface for the CPU is the frame
grabber (whether it be an already encoded frame or not.)  The sensor
devices are all secondary to that.

So, the primary software interface in each case is where the data for
the primary purpose is transferred.  This is the point at which these
graphs should commence since this is where we would normally start
enumeration of the secondary interfaces.

V4L2 even provides interfaces for this: you open the capture device,
which then allows you to enumerate the capture device's inputs, and
this in turn allows you to enumerate their properties.  You don't open
a particular sensor and work back up the tree.

I believe trying to do this according to the flow of data is just wrong.
You should always describe things from the primary device for the CPU
towards the peripheral devices and never the opposite direction.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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

45 matches

Mail list logo