Re: [RFC 2/2] tda18218: use generic dvb_wr_regs()
On Thu, 10 Nov 2011 01:01:57 +0200, Antti Palosaari wrote: > Hello > After today discussion I think at least following configuration options > could be possible: > > address len, for format msg > register value len, for format msg > max write len, for splitting > max read len, for splitting > option for repeated start, for splitting > conditional error logging > callback for I2C-mux (I2C-gate) > general functions implemented: wr_regs, rd_regs, wr_reg, rd_reg, > wr_reg_mask, wr_reg_bits, rd_reg_bits > support for register banks? > > That's full list of ideas I have as now. At least in first phase I think > only basic register reads and writes are enough. Yes, I suggest starting simple, and adding things later on as they become needed. I also suggest spelling out "read" and "write", and also don't forget to prefix your public function names to avoid namespace collisions. > I wonder if Jean could be as main leader of development since he has > surely best knowledge about I2C and all possible users. Otherwise, I > think I could do it only as linux-media common functionality, because I > don't have enough knowledge about other users. If you want it to happen fast, then I suggest that you drive development yourself, and indeed implement it as a common linux-media functionality for now. Later on, once the code has been in place for some time with success, if other subsystems need something similar then we can consider moving the code to i2c-core or some generic i2c helper module. If you count on me to drive it, I am afraid it will take months, given my current workload and various tasks with a much higher priority than this. I will however be happy to help with code review. -- Jean Delvare -- 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 1/2] dvb-core: add generic helper function for I2C register
On Wed, 09 Nov 2011 10:02:08 -0200, Mauro Carvalho Chehab wrote: > Em 09-11-2011 08:37, Jean Delvare escreveu: > > Speaking of struct i2c_client, I seem to remember that the dvb > > subsystem doesn't use it much at the moment. This might be an issue if > > you intend to get the generic code into i2c-core, as most helper > > functions rely on a valid i2c_client structure by design. > > Yes, DVB uses the low level I2C ops. I don't see any reason why not > changing it to use struct i2c_client (well, except that such change > would require lots of changes and tests). The "lots of changes and tests" part is indeed the problem. Furthermore I clearly remember discussing this with Michael a couple years ago (during the i2c device driver model rework) and telling him I would never force DVB to make use of i2c_client if they did not want to. I gave my word, taking it back now would be unfair. Well at least the new i2c model would make it possible, this wasn't the case before, but this is such a huge amount of work that I certainly don't want to push this on anyone. -- Jean Delvare -- 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
soc_camera.h compiler warning: should be fixed
Hi Guennadi,
The daily build gives these compiler warnings when compiling on a 64-bit
platform:
In file included from drivers/media/video/imx074.c:19:0:
include/media/soc_camera.h: In function ‘soc_camera_i2c_to_vdev’:
include/media/soc_camera.h:257:34: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
In file included from drivers/media/video/mt9m111.c:18:0:
include/media/soc_camera.h: In function ‘soc_camera_i2c_to_vdev’:
include/media/soc_camera.h:257:34: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
(and a whole bunch more of these warnings).
The culprit is this inline function:
static inline struct video_device *soc_camera_i2c_to_vdev(const struct
i2c_client *client)
{
struct v4l2_subdev *sd = i2c_get_clientdata(client);
struct soc_camera_device *icd = (struct soc_camera_device *)sd->grp_id;
return icd ? icd->vdev : NULL;
}
sd->grp_id is a u32, so obviously this will fail on a 64-bit arch.
Since ARM is moving to 64-bits as well we should fix this.
Instead of abusing grp_id it is better to use the relatively new v4l2_subdev
'host_priv' field. This is a proper void pointer, and can be used by the host
driver as it pleases.
Can you make a patch for this? It would be nice to get rid of these warnings.
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: MediaController support in LinuxDVB demux
Hi Patrick, > Would it be a problem for you to elaborate a little bit more around > the why and how and what around MC in DVB? Before starting to > implement it like Mauro suggested. Could you go more in detail for you > actual problem (like what is missing in the current dvb-demux)? > > I think it is absolutely necessary to know more about the reasoning > around MC - as it has a big potential - before any implementation. > > Maybe there are some block-diagrams and presentations around somewhere. > Until now I only saw this Email-thread and this: > http://www.linuxtv.org/events.php (at the very bottom). Unfortunately, the slides we presented last month in Prague are not available online. In our SoCs, it is possible to create one or several PES filters from one or multiple demux devices. Those PES can then be either pulled to user space via the demux or dvr device node or tunneled in the kernel directly to audio and video decoders. (we have several audio or video decoders that we can use in parallel). So what we end up with is several sets of demux/audio/video entry points in order to exercise our demux and decoders. We also have to keep a relation between our decoders input (in LinuxDVB world) and output (in V4L2 worlds) since after decode, V4L2 capture, A/V sync, display stuff are done via the V4L2 world. So at the end we now have stuff like demux0 -- audio0 |-- video0 demux1 -- audio1 |-- video1 This mapping helps to "know" which audio/video decoder will be use when doing direct tunneling between demux and decoders. (in real nothing prevent the demux0 to be ordered to send stuff to audio1 also ... ). We however have some use case where we need to demux/decode more than 2 PES/streams in parallel (ex: 2 audio/1 video in case of you have a video stream displayed on TV with 1 language sent to TV speakers and a second language sent to headsets let say). In such case the demux0->(audio0,video0) mapping is not enough and we need to have a way to say demux0 will send its data to yet another decoder that is not audio0 not video0. MediaController for sure would allow us to do that by linking demux output pad (PES filter) with a decoder entity. That said, actually MediaController is not the only solution here and we can actually think of something even more simple such as adding outputs in the dmx_output_t field of struct dmx_pes_filter_params. For example in our case we would have DMX_OUT_DECODER1, DMX_OUT_DECODER2, DMX_OUT_DECODER3 and so on. So my feeling is that the MediaController would most probably help in some cases in the LinuxDVB and also it seems to be good to be able to link all together within a same pipeline LinuxDVB FE/DEMUX and V4L2 decoders/planes and outputs (in our cases). That done it would allow to exercise the whole pipeline from a single place in the pipeline (V4L2 or LinuxDVB) while currently we have to configure and control LinuxDVB and V4L2 separately. However, for the very time being, the first solution that it would solve it the case described above. Regards, Alain -- 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/5] v4l: emulate old crop API using extended crop/compose API
This patch allows new video drivers to work correctly with applications that
use the old-style crop API. The old crop ioctl is emulated by using selection
callbacks.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-ioctl.c | 82 +++---
1 files changed, 76 insertions(+), 6 deletions(-)
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index f3b0faf..d9cef24 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1549,11 +1549,32 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops->vidioc_g_crop)
+ if (!ops->vidioc_g_crop && !ops->vidioc_g_selection)
break;
dbgarg(cmd, "type=%s\n", prt_names(p->type, v4l2_type_names));
- ret = ops->vidioc_g_crop(file, fh, p);
+
+ if (ops->vidioc_g_crop) {
+ ret = ops->vidioc_g_crop(file, fh, p);
+ } else {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p->type,
+ };
+
+ /* crop means compose for output devices */
+ if (V4L2_TYPE_IS_OUTPUT(p->type))
+ s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
+ else
+ s.target = V4L2_SEL_TGT_CROP_ACTIVE;
+
+ ret = ops->vidioc_g_selection(file, fh, &s);
+
+ /* copying results to old structure on success */
+ if (!ret)
+ p->c = s.r;
+ }
+
if (!ret)
dbgrect(vfd, "", &p->c);
break;
@@ -1562,15 +1583,33 @@ static long __video_do_ioctl(struct file *file,
{
struct v4l2_crop *p = arg;
- if (!ops->vidioc_s_crop)
+ if (!ops->vidioc_s_crop && !ops->vidioc_s_selection)
break;
+
if (ret_prio) {
ret = ret_prio;
break;
}
dbgarg(cmd, "type=%s\n", prt_names(p->type, v4l2_type_names));
dbgrect(vfd, "", &p->c);
- ret = ops->vidioc_s_crop(file, fh, p);
+
+ if (ops->vidioc_s_crop) {
+ ret = ops->vidioc_s_crop(file, fh, p);
+ } else {
+ /* simulate capture crop using selection api */
+ struct v4l2_selection s = {
+ .type = p->type,
+ .r = p->c,
+ };
+
+ /* crop means compose for output devices */
+ if (V4L2_TYPE_IS_OUTPUT(p->type))
+ s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
+ else
+ s.target = V4L2_SEL_TGT_CROP_ACTIVE;
+
+ ret = ops->vidioc_s_selection(file, fh, &s);
+ }
break;
}
case VIDIOC_G_SELECTION:
@@ -1610,11 +1649,42 @@ static long __video_do_ioctl(struct file *file,
struct v4l2_cropcap *p = arg;
/*FIXME: Should also show v4l2_fract pixelaspect */
- if (!ops->vidioc_cropcap)
+ if (!ops->vidioc_cropcap && !ops->vidioc_g_selection)
break;
dbgarg(cmd, "type=%s\n", prt_names(p->type, v4l2_type_names));
- ret = ops->vidioc_cropcap(file, fh, p);
+ if (ops->vidioc_cropcap) {
+ ret = ops->vidioc_cropcap(file, fh, p);
+ } else {
+ struct v4l2_selection s = { .type = p->type };
+
+ /* obtaining bounds */
+ if (V4L2_TYPE_IS_OUTPUT(p->type))
+ s.target = V4L2_SEL_TGT_COMPOSE_BOUNDS;
+ else
+ s.target = V4L2_SEL_TGT_CROP_BOUNDS;
+
+ ret = ops->vidioc_g_selection(file, fh, &s);
+ if (ret)
+ break;
+ p->bounds = s.r;
+
+ /* obtaining defrect */
+ if (V4L2_TYPE_IS_OUTPUT(p->type))
+ s.target = V4L2_SEL_TGT_COMPOSE_DEFAULT;
+ else
+ s.target = V4L2_SEL_TGT_CROP_DEFAULT;
+
+ ret = ops->vidioc_g_selection(file, fh, &s);
+ if (ret)
+ break;
+ p->defrect = s.r;
+
+ /* setting trivial pixelaspect */
+
[PATCHv6 0/5] v4l: introduce selection API
Hello Everyone,
This is the sixth version of extended crop/compose RFC. The patch-set
introduces new ioctls to V4L2 API for the configuration of the selection
rectangles like crop and compose areas. Please refer to the link below for more
details about the API development.
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/32152
Changelog:
v5:
- changed naming of constraints flags to form V4L2_SEL_FLAG_*
- changed naming of selection target to form V4L2_SEL_TGT_*
- size of PNG files in the documentation is greatly reduced
- fixes to handling of output queues for old cropping emulation
- VIDIOC_{S/G}_SELECTION for s5p-mixer accepts single- and multiplane buffers
as VIDIOC_{S/G}_CROP did
v4:
- typos, style fixes
- added piorority support to VIDIOC_S_SELECTION
- removed deprecation of current crop API
- marked selection as experimental API
- removed references to pipeline configuration rules
- added subsection about deficiencies of current cropping API
- moved patches to binaries to separate patch
- updated V4L2 changelog
v3:
- added target for padded buffer
- reduced number of constraint flags to SIZE_LE and SIZE_GE
- removed try flag
- added documentation for selection ioctls
- added documentation for new model of cropping, composing and scaling
- support of selection api for s5p-tv
- fixed returning ioctl's structures on failure
v2:
- reduced number of hints and its semantics to be more practical and less
restrictive
- combined EXTCROP and COMPOSE ioctls into VIDIOC_{S/G}_SELECTION
- introduced crop and compose targets
- introduced try flag that prevents passing configuration to a hardware
- added usage examples
Tomasz Stanislawski (5):
v4l: add support for selection api
doc: v4l: add binary images for selection API
doc: v4l: add documentation for selection API
v4l: emulate old crop API using extended crop/compose API
v4l: s5p-tv: mixer: add support for selection API
Documentation/DocBook/media/constraints.png.b64| 59
Documentation/DocBook/media/selection.png.b64 | 206
Documentation/DocBook/media/v4l/common.xml |2 +
Documentation/DocBook/media/v4l/compat.xml |9 +
Documentation/DocBook/media/v4l/selection-api.xml | 327 +++
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../DocBook/media/v4l/vidioc-g-selection.xml | 304 +
drivers/media/video/s5p-tv/mixer.h | 14 +-
drivers/media/video/s5p-tv/mixer_grp_layer.c | 157 +++--
drivers/media/video/s5p-tv/mixer_video.c | 342 +---
drivers/media/video/s5p-tv/mixer_vp_layer.c| 108 ---
drivers/media/video/v4l2-compat-ioctl32.c |2 +
drivers/media/video/v4l2-ioctl.c | 116 +++-
include/linux/videodev2.h | 46 +++
include/media/v4l2-ioctl.h |4 +
15 files changed, 1495 insertions(+), 202 deletions(-)
create mode 100644 Documentation/DocBook/media/constraints.png.b64
create mode 100644 Documentation/DocBook/media/selection.png.b64
create mode 100644 Documentation/DocBook/media/v4l/selection-api.xml
create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-selection.xml
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] v4l: add support for selection api
This patch introduces new api for a precise control of cropping and composing
features for video devices. The new ioctls are VIDIOC_S_SELECTION and
VIDIOC_G_SELECTION.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/v4l2-compat-ioctl32.c |2 +
drivers/media/video/v4l2-ioctl.c | 34 +
include/linux/videodev2.h | 46 +
include/media/v4l2-ioctl.h|4 ++
4 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/v4l2-compat-ioctl32.c
b/drivers/media/video/v4l2-compat-ioctl32.c
index c68531b..af4419e 100644
--- a/drivers/media/video/v4l2-compat-ioctl32.c
+++ b/drivers/media/video/v4l2-compat-ioctl32.c
@@ -985,6 +985,8 @@ long v4l2_compat_ioctl32(struct file *file, unsigned int
cmd, unsigned long arg)
case VIDIOC_CROPCAP:
case VIDIOC_G_CROP:
case VIDIOC_S_CROP:
+ case VIDIOC_G_SELECTION:
+ case VIDIOC_S_SELECTION:
case VIDIOC_G_JPEGCOMP:
case VIDIOC_S_JPEGCOMP:
case VIDIOC_QUERYSTD:
diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c
index e1da8fc..f3b0faf 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -238,6 +238,8 @@ static const char *v4l2_ioctls[] = {
[_IOC_NR(VIDIOC_CROPCAP)] = "VIDIOC_CROPCAP",
[_IOC_NR(VIDIOC_G_CROP)] = "VIDIOC_G_CROP",
[_IOC_NR(VIDIOC_S_CROP)] = "VIDIOC_S_CROP",
+ [_IOC_NR(VIDIOC_G_SELECTION)] = "VIDIOC_G_SELECTION",
+ [_IOC_NR(VIDIOC_S_SELECTION)] = "VIDIOC_S_SELECTION",
[_IOC_NR(VIDIOC_G_JPEGCOMP)] = "VIDIOC_G_JPEGCOMP",
[_IOC_NR(VIDIOC_S_JPEGCOMP)] = "VIDIOC_S_JPEGCOMP",
[_IOC_NR(VIDIOC_QUERYSTD)] = "VIDIOC_QUERYSTD",
@@ -1571,6 +1573,38 @@ static long __video_do_ioctl(struct file *file,
ret = ops->vidioc_s_crop(file, fh, p);
break;
}
+ case VIDIOC_G_SELECTION:
+ {
+ struct v4l2_selection *p = arg;
+
+ if (!ops->vidioc_g_selection)
+ break;
+
+ dbgarg(cmd, "type=%s\n", prt_names(p->type, v4l2_type_names));
+
+ ret = ops->vidioc_g_selection(file, fh, p);
+ if (!ret)
+ dbgrect(vfd, "", &p->r);
+ break;
+ }
+ case VIDIOC_S_SELECTION:
+ {
+ struct v4l2_selection *p = arg;
+
+ if (!ops->vidioc_s_selection)
+ break;
+
+ if (ret_prio) {
+ ret = ret_prio;
+ break;
+ }
+
+ dbgarg(cmd, "type=%s\n", prt_names(p->type, v4l2_type_names));
+ dbgrect(vfd, "", &p->r);
+
+ ret = ops->vidioc_s_selection(file, fh, p);
+ break;
+ }
case VIDIOC_CROPCAP:
{
struct v4l2_cropcap *p = arg;
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..df26f3c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -742,6 +742,48 @@ struct v4l2_crop {
struct v4l2_rectc;
};
+/* Hints for adjustments of selection rectangle */
+#define V4L2_SEL_FLAG_GE 0x0001
+#define V4L2_SEL_FLAG_LE 0x0002
+
+/* Selection targets */
+
+/* current cropping area */
+#define V4L2_SEL_TGT_CROP_ACTIVE 0
+/* default cropping area */
+#define V4L2_SEL_TGT_CROP_DEFAULT 1
+/* cropping bounds */
+#define V4L2_SEL_TGT_CROP_BOUNDS 2
+/* current composing area */
+#define V4L2_SEL_TGT_COMPOSE_ACTIVE256
+/* default composing area */
+#define V4L2_SEL_TGT_COMPOSE_DEFAULT 257
+/* composing bounds */
+#define V4L2_SEL_TGT_COMPOSE_BOUNDS258
+/* current composing area plus all padding pixels */
+#define V4L2_SEL_TGT_COMPOSE_PADDED259
+
+/**
+ * struct v4l2_selection - selection info
+ * @type: buffer type (do not use *_MPLANE types)
+ * @target:selection target, used to choose one of possible rectangles
+ * @flags: constraints flags
+ * @r: coordinates of selection window
+ * @reserved: for future use, rounds structure size to 64 bytes, set to zero
+ *
+ * Hardware may use multiple helper window to process a video stream.
+ * The structure is used to exchange this selection areas between
+ * an application and a driver.
+ */
+struct v4l2_selection {
+ __u32 type;
+ __u32 target;
+ __u32 flags;
+ struct v4l2_rectr;
+ __u32 reserved[9];
+};
+
+
/*
* A N A L O G V I D E O S T A N D A R D
*/
@@ -2255,6 +2297,10 @@ struct v4l2_create_buffers {
#define VIDIOC_CREATE_BUFS _IOWR('V', 92, struct v4l2_create_buffers)
#define VIDIOC_PREPARE_BUF _IOWR('V', 93, struct v4l2_buffer)
+
[PATCH 2/5] doc: v4l: add binary images for selection API
This patch adds images in binary format for the V4L2 selection API. Signed-off-by: Tomasz Stanislawski Signed-off-by: Kyungmin Park --- Documentation/DocBook/media/constraints.png.b64 | 59 +++ Documentation/DocBook/media/selection.png.b64 | 206 +++ 2 files changed, 265 insertions(+), 0 deletions(-) create mode 100644 Documentation/DocBook/media/constraints.png.b64 create mode 100644 Documentation/DocBook/media/selection.png.b64 diff --git a/Documentation/DocBook/media/constraints.png.b64 b/Documentation/DocBook/media/constraints.png.b64 new file mode 100644 index 000..125b4a9 --- /dev/null +++ b/Documentation/DocBook/media/constraints.png.b64 @@ -0,0 +1,59 @@ +iVBORw0KGgoNSUhEUgAAAlQAAAFYCAYAAACVsmLPAXNSR0IArs4c6QZiS0dEAP8A +/wD/oL2nkwlwSFlzAAAOxAAADsQBlSsOGwd0SU1FB9sLCBIAKVtZsMxxSURBVHja +7d3ZbqvIAkDRLsv//8v0QytXvpYZap7Wko56OAnE2AXbBSbhOI7jHwAAkr1sAgAAQQUAIKgAAAQV +AICgAgBAUAEACCoAAEEFACCoAAAQVAAAzb2jvyMEWw0AmFvh37xnhgoAQFABAPT1zvruwtNlAADV +VLxsyQwVAICgAgAQVAAAggoAQFABACCoYEohuFkugKACsmLq178DIKiAyJgSVQCCCigQU6IKQFAB +BWJKVAEIKqBgKIkqAEEFFAgkUQUgqIACYSSqAAQViKkwxjIAEFSwbUyJKgBBBWJq8GUCIKhgm5gS +VQCCCsSUqAIQVMBYoSOqAAQVLOk41lwXAIIKhoqqJyFUYhkACCpYMqpiQqjEMgAQVLBUVKWEUIll +ACCoYImoygmhEssAQFDBElHVexkACCoAAEEFACCoAAAQVAAAggoAQFABAAgqAAAEFQCAoAIAEFQA +AIIKAABBBQAgqAAABBUAgKACAOA/b5sAGjsO2wBgMWaoAAAEFQCAoAIAEFQAADtzUXohIQQbAYDi +Dh9kmYIZKgAAQQUAIKgAAAQVAICgAgAgmU/5VeSTGQDE8InxeZmhAgAQVAAAggoAQFABAAgqAAAE +FQCAoAIAEFQAAHtyY0/o4O7efe4JCzAXM1QAAIIKAEBQAQAIKgAAQQUAgKACABBUAACCCgBAUAEA +IKgAAAQVAICgAgAQVAAACCoAAEEFACCoAAAEFVBICGMsAwBBBVPHVE4QlVgGAIIKpo6ps/9utQwA +BBUsEVMpQVRiGQAIKlgqpmKCqMQyABBUsGRMzbouAAQVNHMca64LAEEFy0WVmAIQVCCqxBSAoAL6 +hI+YAhBUIKrEFICgAvqEkJgCEFQgqo4+3wuAoILto0pMAQgqICOQxBSAoAIyQklMAQgqICOYxBSA +oAIyokpMAQgqICOqxBTAvN42AYwTVQDMyQwVAICgAgAQVAAAggoAQFABAJDMp/y4FIJtwJx8ehJo +yQwVAICgAgDoyyk/HnMKhdE5RQ30YoYKAEBQAQAIKgAAQQUAIKgAABBUAACCCgBAUAEACCoAAAQV +AICgAgAQVAAAggoAAEEFACCoAAAEFQCAoAIAQFABAAgqAABBBQAgqAAAEFQAAIIKAEBQAQAIKgAA +BBUAgKACABBUAACCCgAAQQUAIKgAAAQVAICgAgBAUAEACCoAAEEFACCoAAAQVAAAggoAQFABAAgq +AACGCKoQPAs2JQAIquwCUAI2JQAIqowCOPtvbEoAEFQRBaAEbEoAEFQFCkAJ2JQAIKgKFIASsClh +szEKrDGoXkNuiOPwwim4iezYoc9+39iDfQbVq+mGEFOiCjZ7E23swR6D6tV8Q4gpUQWb7PeNPdhn +UL26bAgxJapgk/2+sQd7DKr3EDE1y96mUPT1fqgh6Ffosbsz9mDdQfXquiEY/rUKlBtLYgoqDJZB +Dmjlg8qRWlSBMSSmYLOoKhtUjtCiCowdMQUbRtXLswUgpkBU5XkXf9CmPJZ9nQJrft6Gife9XmC/ +t0mHg9tr3FcJYgrmjilgn8Fa55SfI7WYAvtnYKNBW+8+VLGn/zY6wtd4qDY1iCngx+BtdNCre1G6 +W3gPt7MXUwAwW1CJKjEFCzB2wODtH1SiSkyB/TKw+KB9DfnARJWYAvtnYKLB+m7+AJ+UgL2WTQmT +jz1jEJVf0ASD7jXck2/vY1PCQscwE+6wfkz1CaqrB6wAbEoQVcBkMdUvqH49cAVgU4KoAiaMqb5B +9bkBFIBNCaIKmDSm+geVArApYaOxZ4zCuoPq5VkDqL//F1Ow9qASVACV9/9iCtYfVIIKoOL+X0zB +HoNKUAFU2v+LKdhnUAkqgAZvqoG1B5WgAgAQVAAAggoAQFABAAgqAAAEFQCAoAIAEFQAAIIKAABB +BQAgqAAABBUAgKACAEBQAQAIKgAAQQUAIKgAABBUAACCCgBAUAEACCoAAAQVAICgAgAY3NsmIEYI +//3zONK/7u/v/nx+zdPl/1rO0++LWd6vZZ59Xe7jSfnZSq3z6jnJ2ValX09PHj9AD2aoiPJ34Lo6 +wJWKiJQD7N2BN/WAzbNtZTsCuzJDRZeD8XHkH3zPZo5CSJudeTKbdrX+lkE7QkzFbq8VHj/AGTNU +dDkY1ziw1jjY7nAA/wzKqxnIu5gSPICggoTIuDroXh1YRz3ohuCUlcgESOOUH81iZdR1fJ9+zL1Q +use1Y6nrvLsearR46rHNAQQVw6l14HtyOurJz5USVqs9LynXt8V+ShBAUMHHQfdzFuMsQGqHSW5M +PQmrVtdsjRCkOwY5gKBiGne3Okg5WJaMqbuw2uX5+P6aX4H8/f922F4AgorlgyD3hp47z3ycPfZf +p/FSb00BIKjg4kD8/cm4mFNjKfd/OpsJyb2GJ+V+UzEXSK9wAfuvqGr9s7ooHRiV2yYgDCe8xUOp +gHny2GNjVdwAOzJDRbUYSfnep8srfdCOWV6tr225ztzt3PpxiTRgdGaoAAAEFQBAX075sbS7C6dH +OJU0w8/ocQEIKjY2w0F71bAQTMBOnPIDABBUAAB9OeXHY36tCAD8ZoYKAEBQAQD05ZQfl3xSCwDu +maECABBUAACCCgBAUAEACCqgiRDczwtAUAFZMfXr3wEQVEBkTIkqAEEFFIgpUQUgqIACMSWqAAQV +UDCURBWAoAIKBJKoAhBUQIEwElUAggrEVBhjGQAIKtg2pkQVgKACMTX4MgEQVLBNTIkqAEEFYkpU +AQgqYKzQEVUAggqWdBxrrgsAQQVDRdWTECqxDAAEFSwZVTEhVGIZAAgqWCqqUkKoxDIAEFSwRFTl +hFCJZQAgqGCJqOq9DAAEFQCAoAIAEFQAAAgqAABBBQAwibdNAECqcPKLJo8fH1cNN7+U8up7jpOP +v6as//PvPr+/xPpTlsEazFABUDSmnsRTie/pvX74ZIYKgKz4+J55+fu7EMLPWZmU2auY9YsjejBD +BUDRmDk7pdZq/Vf/P2bZT7/2OI7/rU/ICSoAiHIVLS2uFyq5Dtc3kcspPwCairmQvHUghhBOT1U+ +eQx/fyfQBBUALBNrtcPmc/l/QYagAoDqYi9ib/2zPZ2l+hVw7Ms1VAAkKXXbgpIXkH9eIF7r8T15 +bEJLUAHA4wD6FQ5PPoVXc/0ll3/3db/+sCen/ABIio7PU3U5YfIdY0++78n6RzPqxfiUYYYKqh94 +rv/AzFGV8nelouLue3JC5e5XzTx57E777SUcsa+4zxeIo8HlOw/vOgBwLBlqA1drGDNUAACCCgBA +UAEATM2n/CpyQSIA7MEMFQCAoAIAEFQAAIIKAGBnLkovxI3XAGBfZqgAAAQVAEBfTvlBbXf3I3O6 +GGB6ZqgAAAQVAICgAgAQVAAAggoAAEEFACCoAAAEFQCAoAIAQFABAAgqAABBBQAgqAAAEFQAAIIK +AEBQAQAIKiBFCGMsAwBBBVPHVE4QlVgGAM29bQIoGFOf/30c7ZcBrV/zd6/Rq6/7fs1/fs3T5Z+9 +AckZO2dvaL6XeffGJ/XxpPxspdZ59ZzkbKve278BM1RQOqaeDvbSy4CW/g5WV6/RUhHRcuwYc2W2 +VY3tP/hzY4YKar5bfLIDeLIMM1WsOnaOI/9AeTZzETt2YmbTrtbfMmhH2PfFbq/Syxxk/2iGCmrF +1Kzrgplez78OpjUOsDu8qfkMyqsZyLvwSdleNZYpqGASLQe3GSpGHgNXB92r1+6or+sQvInptV+a +eF/nlB/kDv7aO14xxUpahErqOr7Hc+yF9y3Hbul13l27NPJ+aJBTgYIKRo4qMcXK46b2wTVlHb9m +3VpcXD/i85Kyb4v9lGCvZQoq2CiqxBQzvfY/ZzHOAqR2mOTG1JOwanXN1ghBunucR3INFYw4qMUU +K/sLsO9rlXKuXSoZU99jcfXxmPpp5LP7f5W+B9Ukz4GggtGiSkxBn5ja/UL0v3D5/nO1jyq1zWos +szGn/KDGTinnoliY9TV/FzZnr++U+z+dfcIw93qblPtNxVwUvcIF7N/7uZJRlbLMQS5KN0MFtQ4
[PATCH 5/5] v4l: s5p-tv: mixer: add support for selection API
This patch add support for V4L2 selection API to s5p-tv driver. Moreover it
removes old API for cropping. Old applications would still work because the
crop ioctls are emulated using the selection API.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-tv/mixer.h | 14 +-
drivers/media/video/s5p-tv/mixer_grp_layer.c | 157 +---
drivers/media/video/s5p-tv/mixer_video.c | 342 +-
drivers/media/video/s5p-tv/mixer_vp_layer.c | 108 +---
4 files changed, 425 insertions(+), 196 deletions(-)
diff --git a/drivers/media/video/s5p-tv/mixer.h
b/drivers/media/video/s5p-tv/mixer.h
index 51ad59b..1597078 100644
--- a/drivers/media/video/s5p-tv/mixer.h
+++ b/drivers/media/video/s5p-tv/mixer.h
@@ -86,6 +86,17 @@ struct mxr_crop {
unsigned int field;
};
+/** stages of geometry operations */
+enum mxr_geometry_stage {
+ MXR_GEOMETRY_SINK,
+ MXR_GEOMETRY_COMPOSE,
+ MXR_GEOMETRY_CROP,
+ MXR_GEOMETRY_SOURCE,
+};
+
+/* flag indicating that offset should be 0 */
+#define MXR_NO_OFFSET 0x8000
+
/** description of transformation from source to destination image */
struct mxr_geometry {
/** cropping for source image */
@@ -133,7 +144,8 @@ struct mxr_layer_ops {
/** streaming stop/start */
void (*stream_set)(struct mxr_layer *, int);
/** adjusting geometry */
- void (*fix_geometry)(struct mxr_layer *);
+ void (*fix_geometry)(struct mxr_layer *,
+ enum mxr_geometry_stage, unsigned long);
};
/** layer instance, a single window and content displayed on output */
diff --git a/drivers/media/video/s5p-tv/mixer_grp_layer.c
b/drivers/media/video/s5p-tv/mixer_grp_layer.c
index de8270c..b93a21f 100644
--- a/drivers/media/video/s5p-tv/mixer_grp_layer.c
+++ b/drivers/media/video/s5p-tv/mixer_grp_layer.c
@@ -101,47 +101,132 @@ static void mxr_graph_format_set(struct mxr_layer *layer)
layer->fmt, &layer->geo);
}
-static void mxr_graph_fix_geometry(struct mxr_layer *layer)
+static inline unsigned int closest(unsigned int x, unsigned int a,
+ unsigned int b, unsigned long flags)
+{
+ unsigned int mid = (a + b) / 2;
+
+ /* choosing closest value with constraints according to table:
+* -+-+-+-+---+
+* flags| 0 | LE | GE | LE|GE |
+* -+-+-+-+---+
+* x <= a | a | a | a | a |
+* a < x <= mid | a | a | b | a |
+* mid < x < b | b | a | b | b |
+* b <= x | b | b | b | b |
+* -+-+-+-+---+
+*/
+
+ /* remove all non-constraint flags */
+ flags &= V4L2_SEL_FLAG_LE | V4L2_SEL_FLAG_GE;
+
+ if (x <= a)
+ return a;
+ if (x >= b)
+ return b;
+ if (flags == V4L2_SEL_FLAG_LE)
+ return a;
+ if (flags == V4L2_SEL_FLAG_GE)
+ return b;
+ if (x <= mid)
+ return a;
+ return b;
+}
+
+static inline unsigned int do_center(unsigned int center,
+ unsigned int size, unsigned int upper, unsigned int flags)
+{
+ unsigned int lower;
+
+ if (flags & MXR_NO_OFFSET)
+ return 0;
+
+ lower = center - min(center, size / 2);
+ return min(lower, upper - size);
+}
+
+static void mxr_graph_fix_geometry(struct mxr_layer *layer,
+ enum mxr_geometry_stage stage, unsigned long flags)
{
struct mxr_geometry *geo = &layer->geo;
+ struct mxr_crop *src = &geo->src;
+ struct mxr_crop *dst = &geo->dst;
+ unsigned int x_center, y_center;
- /* limit to boundary size */
- geo->src.full_width = clamp_val(geo->src.full_width, 1, 32767);
- geo->src.full_height = clamp_val(geo->src.full_height, 1, 2047);
- geo->src.width = clamp_val(geo->src.width, 1, geo->src.full_width);
- geo->src.width = min(geo->src.width, 2047U);
- /* not possible to crop of Y axis */
- geo->src.y_offset = min(geo->src.y_offset, geo->src.full_height - 1);
- geo->src.height = geo->src.full_height - geo->src.y_offset;
- /* limitting offset */
- geo->src.x_offset = min(geo->src.x_offset,
- geo->src.full_width - geo->src.width);
-
- /* setting position in output */
- geo->dst.width = min(geo->dst.width, geo->dst.full_width);
- geo->dst.height = min(geo->dst.height, geo->dst.full_height);
-
- /* Mixer supports only 1x and 2x scaling */
- if (geo->dst.width >= 2 * geo->src.width) {
- geo->x_ratio = 1;
- geo->dst.width = 2 * geo->src.width;
- } else {
- geo->x_ratio = 0;
- geo->dst.width = geo->src.width;
- }
+ switch (stage) {
- if (geo->dst.height >= 2 * geo->src.height) {
- geo->y_ratio = 1;
[PATCH 3/5] doc: v4l: add documentation for selection API
This patch adds a documentation for VIDIOC_{G/S}_SELECTION ioctl. Moreover, the
patch adds the description of modeling of composing, cropping and scaling
features in V4L2. Finally, some examples are presented.
Signed-off-by: Tomasz Stanislawski
Signed-off-by: Kyungmin Park
---
Documentation/DocBook/media/v4l/common.xml |2 +
Documentation/DocBook/media/v4l/compat.xml |9 +
Documentation/DocBook/media/v4l/selection-api.xml | 327
Documentation/DocBook/media/v4l/v4l2.xml |1 +
.../DocBook/media/v4l/vidioc-g-selection.xml | 304 ++
5 files changed, 643 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/media/v4l/selection-api.xml
create mode 100644 Documentation/DocBook/media/v4l/vidioc-g-selection.xml
diff --git a/Documentation/DocBook/media/v4l/common.xml
b/Documentation/DocBook/media/v4l/common.xml
index a86f7a0..9c8db86 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -1168,6 +1168,8 @@ dheight = format.fmt.pix.height;
+ &sub-selection-api;
+
Streaming Parameters
diff --git a/Documentation/DocBook/media/v4l/compat.xml
b/Documentation/DocBook/media/v4l/compat.xml
index b68698f..433933a 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2376,6 +2376,12 @@ that used it. It was originally scheduled for removal in
2.6.35.
V4L2_CTRL_FLAG_VOLATILE was added to signal volatile controls
to userspace.
+
+ Add selection API for extended control over cropping and
+composing. Does not affect the compatibility of current drivers and
+applications. See selection API for
+details.
+
@@ -2489,6 +2495,9 @@ ioctls.
&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.
+
+ Selection API.
+
diff --git a/Documentation/DocBook/media/v4l/selection-api.xml
b/Documentation/DocBook/media/v4l/selection-api.xml
new file mode 100644
index 000..46cb47a
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/selection-api.xml
@@ -0,0 +1,327 @@
+
+
+ Experimental API for cropping, composing and scaling
+
+
+ Experimental
+
+ This is an experimental
+interface and may change in the future.
+
+
+
+Introduction
+
+Some video capture devices can sample a subsection of a picture and
+shrink or enlarge it to an image of arbitrary size. Next, the devices can
+insert the image into larger one. Some video output devices can crop part of an
+input image, scale it up or down and insert it at an arbitrary scan line and
+horizontal offset into a video signal. We call these abilities cropping,
+scaling and composing.
+
+On a video capture device the source is a video
+signal, and the cropping target determine the area actually sampled. The sink
+is an image stored in a memory buffer. The composing area specifies which part
+of the buffer is actually written to by the hardware.
+
+On a video output device the source is an image in a
+memory buffer, and the cropping target is a part of an image to be shown on a
+display. The sink is the display or the graphics screen. The application may
+select the part of display where the image should be displayed. The size and
+position of such a window is controlled by the compose target.
+
+Rectangles for all cropping and composing targets are defined even if the
+device does supports neither cropping nor composing. Their size and position
+will be fixed in such a case. If the device does not support scaling then the
+cropping and composing rectangles have the same size.
+
+
+
+
+ Selection targets
+
+
+ Cropping and composing targets
+
+
+
+
+
+ Targets used by a cropping, composing and scaling
+process
+
+
+
+
+
+
+
+ Configuration
+
+Applications can use the selection
+API to select an area in a video signal or a buffer, and to query for
+default settings and hardware limits.
+
+Video hardware can have various cropping, composing and scaling
+limitations. It may only scale up or down, support only discrete scaling
+factors, or have different scaling abilities in the horizontal and vertical
+directions. Also it may not support scaling at all. At the same time the
+cropping/composing rectangles may have to be aligned, and both the source and
+the sink may have arbitrary upper and lower size limits. Therefore, as usual,
+drivers are expected to adjust the requested parameters and return the actual
+values selected. An application can control the rounding behaviour using constraint flags .
+
+
+
+ Configuration of video capture
+
+See figure for examples of the
+selection targets available for a video capture device. It is recommended to
+configure the cropping tar
Re: [RFC] SUBDEV_S/G_SELECTION IOCTLs
Hi Sakari, On 11/08/2011 10:55 PM, Sakari Ailus wrote: > Hi all, > > This RFC discusses the SUBDEV_S_SELECTION/SUBDEV_G_SELECTION API which is > intended to amend and replace the existing SUBDEV_[SG]_CROP API. These > IOCTLs have previously been discussed in the Cambridge V4L2 brainstorming > meeting [0] and their intent is to provide more configurability for subdevs, > including cropping on the source pads and composing for a display. > > The S_SELECTION patches for V4L2 nodes are available here [1] and the > existing documentation for the V4L2 subdev pad format configuration can be > found in [2]. > > SUBDEV_[SG]_SELECTION is intended to fully replace SUBDEV_[SG]_CROP in > drivers as the latter can be implemented in SUBDEV_[SG]_SELECTION using > active CROP target on sink pads. That can be done in v4l2-ioctl.c so drivers > only will need to implement SUBDEV_[SG]_SELECTION. > > > Questions, comments and thoughts are welcome, especially regarding new use > cases. > > > Order of configuration > == > > The proposed order of the subdev configuration is as follows. Individual > steps may be omitted since any of the steps will reset the rectangles / > sizes for any following step. > > 1. SUBDEV_S_FMT on the SINK pad. The user will issue SUBDEV_S_FMT to set the > subdev sink pad image size and media bus format code and other parameters in > v4l2_mbus_framefmt as necessary. > > 2. SUBDEV_S_SELECTION with CROP target on the SINK pad. The crop rectangle > is set related to the image size given in step 1). > > 3. SUBDEV_S_SELECTION with COMPOSE target on the SINK pad. The size of the > compose rectangle, if it differs from the size of the rectangle given in 2), > signifies user's wish to perform scaling. > > 4. SUBDEV_S_SELECTION with CROP target on the SOURCE pad. Configure cropping > performed by the subdev after scaling. > > 5. SUBDEV_S_SELECTION with COMPOSE target on the SOURCE pad. This configures > composition on the display if relevant for the subdevice. (In this case the > COMPOSE bounds will yield to the size of the display.) > > 6. SUBDEV_S_FMT on the SOURCE pad. The size of the image is defined by > setting CROP on the SOURCE pad, so SUBDEV_S_FMT only has an effect of > changing other parameters than size. > > As defined in [2], when performing any of the configuration phases above, > the formats and selections are reset to defaults from each phase onwards. > For example, SUBDEV_S_SELECTION with CROP target on the SINK pad will > --- beyond its obvious function of setting CROP selection target on the SINK > pad --- reset the COMPOSE selection target on SINK pad, as well as the CROP > selection target and format on the SOURCE pad. I thought we agreed that the spec will not be enforcing resetting parameters to defaults from each phase onwards. Also I couldn't find anything explicitly telling this in [2]. Let's consider simple use case: video pipeline with image sensor, scaler, composer and DMA engine. Initially user performs the configuration in the above described order. Then video stream is started and user wants to change the area cropped at image sensor, which will then appear in the configured compose window. We assume the H/W supports changing crop window position during streaming. We can't reset existing configuration below/after CROP phase at the scaler sink pad, because we want the compose window unchanged. I guess this is where we need the flag to disable propagating the configuration inside single subdev, don't we ? [snip] > Open questions > == > > 1. Keep subdev configuration flag. In Cambourne meeting the case of the OMAP > 3 ISP resizer configuration dilemma was discussed, and the proposal was to > add a flag to disable propagating the configuration inside a single subdev. > Propagating inside a single subdev is the default. Where do we need this > flag; is just SUBDEV_S_SELECTION enough? [0] > > 2. Are PADDED targets relevant for media bus formats? [3] > > > References > == > > [0] http://www.mail-archive.com/linux-media@vger.kernel.org/msg35361.html > > [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg36206.html > > [2] http://hverkuil.home.xs4all.nl/spec/media.html#subdev > > [3] http://www.mail-archive.com/linux-media@vger.kernel.org/msg36203.html --- Regards, Sylwester -- 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: DVBv5 frontend library
Em 10-11-2011 05:08, Rémi Denis-Courmont escreveu: >Hello kernel-space friends, > > On Wed, 09 Nov 2011 17:01:59 -0200, Mauro Carvalho Chehab > wrote: >> As I've commented with some at the KS, I started writing a new DVB >> library, based on DVBv5. >> It is currently at very early stages. Help and suggestions are welcome. >> > >> It is at: >> > > http://git.linuxtv.org/mchehab/experimental-v4l-utils.git/shortlog/refs/heads/dvb-utils >> >> It currently doesn't do much, but the hole idea is to offer a library that >> can easily upgraded to support new standards, and based on DVBv5. > > IMHO, adding new standards with DVBv5 is already fairly easy, as opposed > to with DVBv3. > > The only issue I've had (while porting VLC to DVBv5) lied in determining > which parameters needed to be set and what values they would accept. Yes, this is one of the problems on implementing a proper DVBv5 support: there was a gap at the specs and the parameters/accepted values for each delivery system. In order to fix it, we've created a topics inside the DVB specs where the parameters to be used for each delivery system are defined. I'm sure some improvements there are needed, but writing a reference library will help to detect and address such gaps. As discussed at KS Workshop, some gaps were already identified, and Steven offered to work fixing them. They are, basically: - DVB delivery support enumeration, in order to properly identify what delivery systems are supported by each frontend; - Satellite properties that weren't implemented so far. >> The frontend library is inside: >> dvb-fe.c >> dvb-fe.h >> >> And the pertinent parameters needed by each delivery system is provided >> into a separate header: >> dvb-v5-std.h > > As a documentation, it's nice to have. It should also enumerate the legal > values, a bit like V4L2 user controls. I'd say it should also document there the default value, when pertinent (e. g. *_AUTO). I'll add it soon to the library. > However, I'm not sure how useful it can really be used to abstract away > tuning standards. There are a number of problems remaining: > > 1) User-space may need localization of parameters names and enumeration > value names. Yes, locales can be added in future. Enumeration of value names are generated by the perl script. I opted for this approach, as it will likely simplify the sync between new additions at the Kernel and the userspace counterpart. > For frequency, we also need a unit, since it depends on the > delivery system. The spec says: DTV_FREQUENCY Central frequency of the channel, in HZ. So, the unit should be Hz. If is there any place where something different is used, we should fix it to match what's specified there. > In VLC, we have to replicate and keep the list of > well-known V4L2 controls parameters just so gettext sees them. The same > problem would affect DVB if you carry on with this. > > And unfortunately, even if v4l-utils had its own gettext domain, I doubt > it would get as good visibility among translators as end-user applications > have (e.g. VLC has 78 locales as of today). Maintaining locales database can be painful. Not sure if is there an easy way of keeping it inside a library, or if the better is to let userspace apps that use it to have their own locales. > 2) Some user-space are cross-platform, say across Linux DVB and Windows > BDA. Since Windows BDA does not abstract delivery subsystems, such software > cannot leverage dvb-v5-std.h. I'd say that the usage of it should be internal to the OS-specific part of the code, e. g. if you'll need an abstraction layer on the top of it, in order to make it work with Windows and Linux. Another alternative would be to have a separate plugin for Windows and for Linux. > 3) Some settings are absolutely required (e.g. frequency), some may be > required depending on hardware and/or driver, some are not normally > required to tune. When writing a UI, you need to know that. It all depends on the channel to be tuned. For example, for normal usage, an ISDB-T tuning requires just the same parameters as a DVB-T. But, if you want to tune to radio stations, the layers info are needed. In other words, IMO, the scan tool needs to provide a more complete set of fields, delivery-system-specific, that would include all the parameters that can be used for that delivery system, using the default value when some parameter is not needed, in order to tune to that channel. > 4) Systems like DVB-H (R.I.P.) or ATSC-M/H cannot be abstracted > meaningfully as they don't provide a TS feed, so the user-space can't use > them. Yes, delivery systems like that will require more work. I opted to release the code on such early stage as Michael told us at KS that he's working on a solution for ATSC-M/H. So, releasing the code early would give him the opportunity to propose some ways to abstract the differences between those IP-based delivery sys
Re: DVBv5 frontend library
On 10.11.2011 13:05, Mauro Carvalho Chehab wrote: > Em 10-11-2011 05:08, Rémi Denis-Courmont escreveu: >> For frequency, we also need a unit, since it depends on the >> delivery system. > > The spec says: > DTV_FREQUENCY > > Central frequency of the channel, in HZ. > > So, the unit should be Hz. If is there any place where something different is > used, we should fix it to match what's specified there. For DVB-S, the unit is and has always been kHz. The spec is wrong. >> 5) Unless/Until the library implements scanning and some kind of channel >> or transponder abstraction (e.g. unique ID per transponder), it is dubious >> that it can really abstract new delivery systems. I mean, the tuning >> parameters need to come from somewhere, so the application will have to >> know about the delivery systems. > > Sure. This is the next item on my TODO list ;) Make sure to generate globally unique IDs. Even though onid + tsid + sid *should* identify a DVB service, in reality they don't. There are many duplicates, especially with - but not limited to - reception of multiple satellites. Regards, Andreas -- 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: Query DVB frontend capabilities
Hi,
Currently, for a multi standard frontend it is assumed that it just
has a single standard capability. This is fine in some cases, but
makes things hard when there are incompatible standards in conjuction.
Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
the same for DSS. This is not specific to any driver as it is, but a
generic issue. This was handled correctly in the multiproto tree,
while such functionality is missing from the v5 API update.
http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
issue in the v5 API, but that hack is incapable of addressing the
issue, as it can be used to simply distinguish between DVB-S and
DVB-S2 alone, or another x vs X2 modulation. If there are more
systems, then you have a potential issue.
In addition to the patch, for illustrative purposes the stb0899 driver
is depicted providing the said capability information.
An application needs to query the device capabilities before
requesting an operation from the device.
If people don't have any objections, Probably other drivers can be
adapted similarly. In fact the change is quite simple.
Comments ?
Regards,
Manu
diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Nov 09 19:52:36 2011 +0530
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Nov 10 13:51:35 2011 +0530
@@ -973,6 +973,8 @@
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+
+ _DTV_CMD(DTV_DELIVERY_CAPS, 0, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1226,7 +1228,18 @@
c = &cdetected;
}
+ dprintk("%s\n", __func__);
+
switch(tvp->cmd) {
+ case DTV_DELIVERY_CAPS:
+ if (fe->ops.delivery_caps) {
+ r = fe->ops.delivery_caps(fe, tvp);
+ if (r < 0)
+return r;
+ else
+goto done;
+ }
+ break;
case DTV_FREQUENCY:
tvp->u.data = c->frequency;
break;
@@ -1350,7 +1363,7 @@
if (r < 0)
return r;
}
-
+done:
dtv_property_dump(tvp);
return 0;
diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Nov 09 19:52:36 2011 +0530
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Thu Nov 10 13:51:35 2011 +0530
@@ -305,6 +305,8 @@
int (*set_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
int (*get_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
+
+ int (*delivery_caps)(struct dvb_frontend *fe, struct dtv_property *tvp);
};
#define MAX_EVENT 8
@@ -362,6 +364,8 @@
/* DVB-T2 specifics */
u32 dvbt2_plp_id;
+
+ fe_delivery_system_t delivery_caps[32];
};
struct dvb_frontend {
diff -r b6eb04718aa9 linux/drivers/media/dvb/frontends/stb0899_drv.c
--- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Nov 09 19:52:36 2011 +0530
+++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Thu Nov 10 13:51:35 2011 +0530
@@ -1605,6 +1605,19 @@
return DVBFE_ALGO_CUSTOM;
}
+static int stb0899_delivery_caps(struct dvb_frontend *fe, struct dtv_property *caps)
+{
+ struct stb0899_state *state = fe->demodulator_priv;
+
+ dprintk(state->verbose, FE_DEBUG, 1, "Get caps");
+ caps->u.buffer.data[0] = SYS_DSS;
+ caps->u.buffer.data[1] = SYS_DVBS;
+ caps->u.buffer.data[2] = SYS_DVBS2;
+ caps->u.buffer.len = 3;
+
+ return 0;
+}
+
static struct dvb_frontend_ops stb0899_ops = {
.info = {
@@ -1647,6 +1660,8 @@
.diseqc_send_master_cmd = stb0899_send_diseqc_msg,
.diseqc_recv_slave_reply = stb0899_recv_slave_reply,
.diseqc_send_burst = stb0899_send_diseqc_burst,
+
+ .delivery_caps = stb0899_delivery_caps,
};
struct dvb_frontend *stb0899_attach(struct stb0899_config *config, struct i2c_adapter *i2c)
diff -r b6eb04718aa9 linux/include/linux/dvb/frontend.h
--- a/linux/include/linux/dvb/frontend.h Wed Nov 09 19:52:36 2011 +0530
+++ b/linux/include/linux/dvb/frontend.h Thu Nov 10 13:51:35 2011 +0530
@@ -316,7 +316,9 @@
#define DTV_DVBT2_PLP_ID 43
-#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
+#define DTV_DELIVERY_CAPS 44
+
+#define DTV_MAX_COMMANDDTV_DELIVERY_CAPS
typedef enum fe_pilot {
PILOT_ON,
Re: PATCH: Query DVB frontend capabilities
Hello Manu,
please see my comments below:
On 10.11.2011 15:18, Manu Abraham wrote:
> Hi,
>
> Currently, for a multi standard frontend it is assumed that it just
> has a single standard capability. This is fine in some cases, but
> makes things hard when there are incompatible standards in conjuction.
> Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
> the same for DSS. This is not specific to any driver as it is, but a
> generic issue. This was handled correctly in the multiproto tree,
> while such functionality is missing from the v5 API update.
>
> http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
>
> Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
> issue in the v5 API, but that hack is incapable of addressing the
> issue, as it can be used to simply distinguish between DVB-S and
> DVB-S2 alone, or another x vs X2 modulation. If there are more
> systems, then you have a potential issue.
>
> In addition to the patch, for illustrative purposes the stb0899 driver
> is depicted providing the said capability information.
>
> An application needs to query the device capabilities before
> requesting an operation from the device.
>
> If people don't have any objections, Probably other drivers can be
> adapted similarly. In fact the change is quite simple.
>
> Comments ?
>
> Regards,
> Manu
>
>
> query_frontend_capabilities.diff
>
>
> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Nov 09 19:52:36
> 2011 +0530
> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Nov 10 13:51:35
> 2011 +0530
> @@ -973,6 +973,8 @@
> _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
> _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
> _DTV_CMD(DTV_HIERARCHY, 0, 0),
> +
> + _DTV_CMD(DTV_DELIVERY_CAPS, 0, 0),
> };
>
> static void dtv_property_dump(struct dtv_property *tvp)
> @@ -1226,7 +1228,18 @@
> c = &cdetected;
> }
>
> + dprintk("%s\n", __func__);
> +
> switch(tvp->cmd) {
> + case DTV_DELIVERY_CAPS:
> + if (fe->ops.delivery_caps) {
> + r = fe->ops.delivery_caps(fe, tvp);
> + if (r < 0)
> + return r;
> + else
> + goto done;
What's the reason for introducing that label and goto?
> + }
> + break;
> case DTV_FREQUENCY:
> tvp->u.data = c->frequency;
> break;
> @@ -1350,7 +1363,7 @@
> if (r < 0)
> return r;
> }
> -
> +done:
> dtv_property_dump(tvp);
>
> return 0;
> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Nov 09 19:52:36
> 2011 +0530
> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Thu Nov 10 13:51:35
> 2011 +0530
> @@ -305,6 +305,8 @@
>
> int (*set_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
> int (*get_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
> +
> + int (*delivery_caps)(struct dvb_frontend *fe, struct dtv_property *tvp);
> };
I don't think that another function pointer is required. Drivers can
implement this in their get_property callback. The core could provide a
default implementation, returning values derived from fe->ops.info.type
and the 2G flag.
> #define MAX_EVENT 8
> @@ -362,6 +364,8 @@
>
> /* DVB-T2 specifics */
> u32 dvbt2_plp_id;
> +
> + fe_delivery_system_tdelivery_caps[32];
> };
This array seems to be unused.
Regards,
Andreas
> struct dvb_frontend {
> diff -r b6eb04718aa9 linux/drivers/media/dvb/frontends/stb0899_drv.c
> --- a/linux/drivers/media/dvb/frontends/stb0899_drv.c Wed Nov 09 19:52:36
> 2011 +0530
> +++ b/linux/drivers/media/dvb/frontends/stb0899_drv.c Thu Nov 10 13:51:35
> 2011 +0530
> @@ -1605,6 +1605,19 @@
> return DVBFE_ALGO_CUSTOM;
> }
>
> +static int stb0899_delivery_caps(struct dvb_frontend *fe, struct
> dtv_property *caps)
> +{
> + struct stb0899_state *state = fe->demodulator_priv;
> +
> + dprintk(state->verbose, FE_DEBUG, 1, "Get caps");
> + caps->u.buffer.data[0] = SYS_DSS;
> + caps->u.buffer.data[1] = SYS_DVBS;
> + caps->u.buffer.data[2] = SYS_DVBS2;
> + caps->u.buffer.len = 3;
> +
> + return 0;
> +}
> +
> static struct dvb_frontend_ops stb0899_ops = {
>
> .info = {
> @@ -1647,6 +1660,8 @@
> .diseqc_send_master_cmd = stb0899_send_diseqc_msg,
> .diseqc_recv_slave_reply= stb0899_recv_slave_reply,
> .diseqc_send_burst = stb0899_send_diseqc_burst,
> +
> + .delivery_caps = stb0899_delivery_caps,
> };
>
> struct dvb_frontend *stb0899_attach(struct stb0899_config *config, struct
> i2c_adapter *i2c)
> diff -r b6eb04718aa9 linux/include/li
Re: [RFC] SUBDEV_S/G_SELECTION IOCTLs
Hi Sakari,
On 11/08/2011 10:55 PM, Sakari Ailus wrote:
Hi all,
This RFC discusses the SUBDEV_S_SELECTION/SUBDEV_G_SELECTION API which is
intended to amend and replace the existing SUBDEV_[SG]_CROP API. These
IOCTLs have previously been discussed in the Cambridge V4L2 brainstorming
meeting [0] and their intent is to provide more configurability for subdevs,
including cropping on the source pads and composing for a display.
The S_SELECTION patches for V4L2 nodes are available here [1] and the
existing documentation for the V4L2 subdev pad format configuration can be
found in [2].
SUBDEV_[SG]_SELECTION is intended to fully replace SUBDEV_[SG]_CROP in
drivers as the latter can be implemented in SUBDEV_[SG]_SELECTION using
active CROP target on sink pads. That can be done in v4l2-ioctl.c so drivers
only will need to implement SUBDEV_[SG]_SELECTION.
Questions, comments and thoughts are welcome, especially regarding new use
cases.
Order of configuration
==
Sorry, what is exactly the SOURCE pad and SINK pad? The spec says "Data
flows from a source pad to a sink pad.". Does in refer to a subdev or to
a link? Look at the image below:
data link0 --> (pad0) [subdev] (pad1) > link1
From subdev's point of view, pad0 is data source, pad1 is the sink.
From link0's point of view, pad0 is a data sink. Which interpretation
is correct?
The proposed order of the subdev configuration is as follows. Individual
steps may be omitted since any of the steps will reset the rectangles /
sizes for any following step.
I assume that SOURCE and SINK are defined from the link's point of view.
Otherwise it would mean that configuration goes in order opposite to
data flow order.
I do not think that resetting is a good idea. It is better to state in
spec that change of a given target guarantee that targets/formats
earlier in pipeline are not modified. Part below pipeline may change or
not. The application should check if the configuration of lower parts of
pipeline is suitable. For example
Change of COMPOSE target on SINK pad must not modify
- format on the SINK pad
- CROP on the SINK pad
All other parameters may change. Of course the configuration of lower
part must be consistent with higher part of the pipeline.
1. SUBDEV_S_FMT on the SINK pad. The user will issue SUBDEV_S_FMT to set the
subdev sink pad image size and media bus format code and other parameters in
v4l2_mbus_framefmt as necessary.
2. SUBDEV_S_SELECTION with CROP target on the SINK pad. The crop rectangle
is set related to the image size given in step 1).
3. SUBDEV_S_SELECTION with COMPOSE target on the SINK pad. The size of the
compose rectangle, if it differs from the size of the rectangle given in 2),
signifies user's wish to perform scaling.
4. SUBDEV_S_SELECTION with CROP target on the SOURCE pad. Configure cropping
performed by the subdev after scaling.
5. SUBDEV_S_SELECTION with COMPOSE target on the SOURCE pad. This configures
composition on the display if relevant for the subdevice. (In this case the
COMPOSE bounds will yield to the size of the display.)
6. SUBDEV_S_FMT on the SOURCE pad. The size of the image is defined by
setting CROP on the SOURCE pad, so SUBDEV_S_FMT only has an effect of
changing other parameters than size.
As defined in [2], when performing any of the configuration phases above,
the formats and selections are reset to defaults from each phase onwards.
For example, SUBDEV_S_SELECTION with CROP target on the SINK pad will
--- beyond its obvious function of setting CROP selection target on the SINK
pad --- reset the COMPOSE selection target on SINK pad, as well as the CROP
selection target and format on the SOURCE pad.
I think that formal definitions of CROP,COMPOSE for pads are needed.
As I remember from Cambridge brainstorming we agreed that SINK.COMPOSE
and SOURCE.CROP are expressed in subdev's internal coordinate system.
The SINK.CROP is expressed in link0's coordinate system and
SOURCE.COMPOSE is expressed in link1's coordinate system.
Definitions
===
/**
* struct v4l2_subdev_selection - selection info
*
* @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
* @pad: pad number, as reported by the media API
* @target: selection target, used to choose one of possible rectangles
* @flags: constraints flags
* @r: coordinates of selection window
* @reserved: for future use, rounds structure size to 64 bytes, set to zero
*
* Hardware may use multiple helper window to process a video stream.
* The structure is used to exchange this selection areas between
* an application and a driver.
*/
struct v4l2_subdev_selection {
__u32 which;
__u32 pad;
__u32 target;
__u32 flags;
struct v4l2_rect r;
__u32 reserved[8];
};
Both SUBDEV_S_SELECTION and SUBDEV_G_SELECTION would take struct
v4l2_subdev_selection as the IOCTL argument (RW).
The same target definitions and flags apply as
Re: PATCH: Query DVB frontend capabilities
Hi Andreas,
On Thu, Nov 10, 2011 at 8:14 PM, Andreas Oberritter wrote:
> Hello Manu,
>
> please see my comments below:
>
> On 10.11.2011 15:18, Manu Abraham wrote:
>> Hi,
>>
>> Currently, for a multi standard frontend it is assumed that it just
>> has a single standard capability. This is fine in some cases, but
>> makes things hard when there are incompatible standards in conjuction.
>> Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
>> the same for DSS. This is not specific to any driver as it is, but a
>> generic issue. This was handled correctly in the multiproto tree,
>> while such functionality is missing from the v5 API update.
>>
>> http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
>>
>> Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
>> issue in the v5 API, but that hack is incapable of addressing the
>> issue, as it can be used to simply distinguish between DVB-S and
>> DVB-S2 alone, or another x vs X2 modulation. If there are more
>> systems, then you have a potential issue.
>>
>> In addition to the patch, for illustrative purposes the stb0899 driver
>> is depicted providing the said capability information.
>>
>> An application needs to query the device capabilities before
>> requesting an operation from the device.
>>
>> If people don't have any objections, Probably other drivers can be
>> adapted similarly. In fact the change is quite simple.
>>
>> Comments ?
>>
>> Regards,
>> Manu
>>
>>
>> query_frontend_capabilities.diff
>>
>>
>> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Nov 09 19:52:36
>> 2011 +0530
>> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Nov 10 13:51:35
>> 2011 +0530
>> @@ -973,6 +973,8 @@
>> _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
>> _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
>> _DTV_CMD(DTV_HIERARCHY, 0, 0),
>> +
>> + _DTV_CMD(DTV_DELIVERY_CAPS, 0, 0),
>> };
>>
>> static void dtv_property_dump(struct dtv_property *tvp)
>> @@ -1226,7 +1228,18 @@
>> c = &cdetected;
>> }
>>
>> + dprintk("%s\n", __func__);
>> +
>> switch(tvp->cmd) {
>> + case DTV_DELIVERY_CAPS:
>> + if (fe->ops.delivery_caps) {
>> + r = fe->ops.delivery_caps(fe, tvp);
>> + if (r < 0)
>> + return r;
>> + else
>> + goto done;
>
> What's the reason for introducing that label and goto?
The idea was to avoid using get_property callback being called.
>
>> + }
>> + break;
>> case DTV_FREQUENCY:
>> tvp->u.data = c->frequency;
>> break;
>> @@ -1350,7 +1363,7 @@
>> if (r < 0)
>> return r;
>> }
>> -
>> +done:
>> dtv_property_dump(tvp);
>>
>> return 0;
>> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
>> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Nov 09 19:52:36
>> 2011 +0530
>> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Thu Nov 10 13:51:35
>> 2011 +0530
>> @@ -305,6 +305,8 @@
>>
>> int (*set_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
>> int (*get_property)(struct dvb_frontend* fe, struct dtv_property* tvp);
>> +
>> + int (*delivery_caps)(struct dvb_frontend *fe, struct dtv_property
>> *tvp);
>> };
>
> I don't think that another function pointer is required. Drivers can
> implement this in their get_property callback. The core could provide a
> default implementation, returning values derived from fe->ops.info.type
> and the 2G flag.
I see your point. While trying to address the issue I had originally
get_property being used. One Issue that came across to me was that:
- while currently this is just one capability field, things do look
fine. As we move ahead we will possibly have more capability related
information, given the idea that with shared hardware infrastructure
on frontends, this list of properties could grow.
- Once we have a few properties, then we will need to have switches in
that callback, given that it is generic and that length will grow.
Considering different hardware capabilities, we will have quite a bit
of shared code amongst drivers in that large switch, causing code
duplication.
Eg: with hardware having shared infrastructure - while globally it
might have a larger set of capabilities, when a sub part of it is run
in some mode, the other sub parts would have reduced set of
capabilities, which won't be the same as that exists globally for the
device. The driver alone will know the change depending on what's
being used.
- Additionally, though insignificant a separate callback for each
capability will make the drivers look a bit more consistent with
regards to code style.
The basic issue is a switch that will be duplicated across drivers and
that which is expected to
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:Thu Nov 10 19:00:16 CET 2011 git hash:e9eb0dadba932940f721f9d27544a7818b2fa1c5 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.7-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification 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: Hauppauge HVR900H don't work with kernel 3.*
Same problem here since upgrade to ubuntu 11.10 I've found these topics but no solutions http://forum.ubuntuusers.de/topic/dvb-t-stick-wird-nicht-erkannt http://forum.ubuntu-it.org/index.php/topic,59926.160.html http://forums.gentoo.org/viewtopic-t-900714.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: [RFC] SUBDEV_S/G_SELECTION IOCTLs
Hi Sylwester, Thanks for the comments! On Thu, Nov 10, 2011 at 12:57:10PM +0100, Sylwester Nawrocki wrote: > Hi Sakari, > > On 11/08/2011 10:55 PM, Sakari Ailus wrote: > > Hi all, > > > > This RFC discusses the SUBDEV_S_SELECTION/SUBDEV_G_SELECTION API which is > > intended to amend and replace the existing SUBDEV_[SG]_CROP API. These > > IOCTLs have previously been discussed in the Cambridge V4L2 brainstorming > > meeting [0] and their intent is to provide more configurability for subdevs, > > including cropping on the source pads and composing for a display. > > > > The S_SELECTION patches for V4L2 nodes are available here [1] and the > > existing documentation for the V4L2 subdev pad format configuration can be > > found in [2]. > > > > SUBDEV_[SG]_SELECTION is intended to fully replace SUBDEV_[SG]_CROP in > > drivers as the latter can be implemented in SUBDEV_[SG]_SELECTION using > > active CROP target on sink pads. That can be done in v4l2-ioctl.c so drivers > > only will need to implement SUBDEV_[SG]_SELECTION. > > > > > > Questions, comments and thoughts are welcome, especially regarding new use > > cases. > > > > > > Order of configuration > > == > > > > The proposed order of the subdev configuration is as follows. Individual > > steps may be omitted since any of the steps will reset the rectangles / > > sizes for any following step. > > > > 1. SUBDEV_S_FMT on the SINK pad. The user will issue SUBDEV_S_FMT to set the > > subdev sink pad image size and media bus format code and other parameters in > > v4l2_mbus_framefmt as necessary. > > > > 2. SUBDEV_S_SELECTION with CROP target on the SINK pad. The crop rectangle > > is set related to the image size given in step 1). > > > > 3. SUBDEV_S_SELECTION with COMPOSE target on the SINK pad. The size of the > > compose rectangle, if it differs from the size of the rectangle given in 2), > > signifies user's wish to perform scaling. > > > > 4. SUBDEV_S_SELECTION with CROP target on the SOURCE pad. Configure cropping > > performed by the subdev after scaling. > > > > 5. SUBDEV_S_SELECTION with COMPOSE target on the SOURCE pad. This configures > > composition on the display if relevant for the subdevice. (In this case the > > COMPOSE bounds will yield to the size of the display.) > > > > 6. SUBDEV_S_FMT on the SOURCE pad. The size of the image is defined by > > setting CROP on the SOURCE pad, so SUBDEV_S_FMT only has an effect of > > changing other parameters than size. > > > > As defined in [2], when performing any of the configuration phases above, > > the formats and selections are reset to defaults from each phase onwards. > > For example, SUBDEV_S_SELECTION with CROP target on the SINK pad will > > --- beyond its obvious function of setting CROP selection target on the SINK > > pad --- reset the COMPOSE selection target on SINK pad, as well as the CROP > > selection target and format on the SOURCE pad. > > I thought we agreed that the spec will not be enforcing resetting parameters > to defaults from each phase onwards. Also I couldn't find anything explicitly > telling this in [2]. Let's consider simple use case: video pipeline with image > sensor, scaler, composer and DMA engine. > Initially user performs the configuration in the above described order. > Then video stream is started and user wants to change the area cropped at > image sensor, which will then appear in the configured compose window. We > assume > the H/W supports changing crop window position during streaming. > > We can't reset existing configuration below/after CROP phase at the scaler > sink > pad, because we want the compose window unchanged. > > I guess this is where we need the flag to disable propagating the > configuration > inside single subdev, don't we ? Yes, the intent is to define one. See open question number 1. I think a note of the behaviour must be added to the spec. It might have been left open on purpose since no consensus had been reached on how to best handle it. I'll make the needed changes to the next version of the RFC. > > [snip] > > > Open questions > > == > > > > 1. Keep subdev configuration flag. In Cambourne meeting the case of the OMAP > > 3 ISP resizer configuration dilemma was discussed, and the proposal was to > > add a flag to disable propagating the configuration inside a single subdev. > > Propagating inside a single subdev is the default. Where do we need this > > flag; is just SUBDEV_S_SELECTION enough? [0] > > > > 2. Are PADDED targets relevant for media bus formats? [3] > > > > > > References > > == > > > > [0] http://www.mail-archive.com/linux-media@vger.kernel.org/msg35361.html > > > > [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg36206.html > > > > [2] http://hverkuil.home.xs4all.nl/spec/media.html#subdev > > > > [3] http://www.mail-archive.com/linux-media@vger.kernel.org/msg36203.html > > --- > Regards, > Sylwester -- Sakari Ailus e-mail: sakari.
Re: PATCH: Query DVB frontend capabilities
Em 10-11-2011 13:30, Manu Abraham escreveu:
> Hi Andreas,
>
> On Thu, Nov 10, 2011 at 8:14 PM, Andreas Oberritter wrote:
>> Hello Manu,
>>
>> please see my comments below:
>>
>> On 10.11.2011 15:18, Manu Abraham wrote:
>>> Hi,
>>>
>>> Currently, for a multi standard frontend it is assumed that it just
>>> has a single standard capability. This is fine in some cases, but
>>> makes things hard when there are incompatible standards in conjuction.
>>> Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
>>> the same for DSS. This is not specific to any driver as it is, but a
>>> generic issue. This was handled correctly in the multiproto tree,
>>> while such functionality is missing from the v5 API update.
>>>
>>> http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
>>>
>>> Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
>>> issue in the v5 API, but that hack is incapable of addressing the
>>> issue, as it can be used to simply distinguish between DVB-S and
>>> DVB-S2 alone, or another x vs X2 modulation. If there are more
>>> systems, then you have a potential issue.
For sure something like that is needed.
DVB TURBO is another example where the FE_CAN_2G_MODULATION approach doesn't
properly address.
>>>
>>> In addition to the patch, for illustrative purposes the stb0899 driver
>>> is depicted providing the said capability information.
>>>
>>> An application needs to query the device capabilities before
>>> requesting an operation from the device.
>>>
>>> If people don't have any objections, Probably other drivers can be
>>> adapted similarly. In fact the change is quite simple.
>>>
>>> Comments ?
>>>
>>> Regards,
>>> Manu
>>>
>>>
>>> query_frontend_capabilities.diff
>>>
>>>
>>> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
>>> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Nov 09 19:52:36
>>> 2011 +0530
>>> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Nov 10 13:51:35
>>> 2011 +0530
>>> @@ -973,6 +973,8 @@
>>> _DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
>>> _DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
>>> _DTV_CMD(DTV_HIERARCHY, 0, 0),
>>> +
>>> + _DTV_CMD(DTV_DELIVERY_CAPS, 0, 0),
>>> };
>>>
>>> static void dtv_property_dump(struct dtv_property *tvp)
>>> @@ -1226,7 +1228,18 @@
>>> c = &cdetected;
>>> }
>>>
>>> + dprintk("%s\n", __func__);
>>> +
>>> switch(tvp->cmd) {
>>> + case DTV_DELIVERY_CAPS:
>>> + if (fe->ops.delivery_caps) {
>>> + r = fe->ops.delivery_caps(fe, tvp);
>>> + if (r < 0)
>>> + return r;
>>> + else
>>> + goto done;
>>
>> What's the reason for introducing that label and goto?
>
>
> The idea was to avoid using get_property callback being called.
Nothing warrants that the only property will be DTV_DELIVERY_CAPS.
calling get_property callback will likely work better.
>
>
>
>>
>>> + }
>>> + break;
>>> case DTV_FREQUENCY:
>>> tvp->u.data = c->frequency;
>>> break;
>>> @@ -1350,7 +1363,7 @@
>>> if (r < 0)
>>> return r;
>>> }
>>> -
>>> +done:
>>> dtv_property_dump(tvp);
>>>
>>> return 0;
>>> diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
>>> --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Nov 09 19:52:36
>>> 2011 +0530
>>> +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Thu Nov 10 13:51:35
>>> 2011 +0530
>>> @@ -305,6 +305,8 @@
>>>
>>> int (*set_property)(struct dvb_frontend* fe, struct dtv_property*
>>> tvp);
>>> int (*get_property)(struct dvb_frontend* fe, struct dtv_property*
>>> tvp);
>>> +
>>> + int (*delivery_caps)(struct dvb_frontend *fe, struct dtv_property
>>> *tvp);
>>> };
>>
>> I don't think that another function pointer is required. Drivers can
>> implement this in their get_property callback. The core could provide a
>> default implementation, returning values derived from fe->ops.info.type
>> and the 2G flag.
>
>
> I see your point. While trying to address the issue I had originally
> get_property being used. One Issue that came across to me was that:
>
> - while currently this is just one capability field, things do look
> fine. As we move ahead we will possibly have more capability related
> information, given the idea that with shared hardware infrastructure
> on frontends, this list of properties could grow.
There are two DVBv5 calls that are likely designed to address this
need:
DTV_FE_CAPABILITY_COUNT
DTV_FE_CAPABILITY
Unfortunately, those were never implemented. I _suspect_ that the original
idea were to allow passing an arbritary count to the driver, and let it fill
each capability.
> - Once we have a few properties, then we will need to have switches in
> that callback, given that it is generic and that lengt
Re: [RFC] SUBDEV_S/G_SELECTION IOCTLs
Hi Tomasz, Thanks for your comments! On Thu, Nov 10, 2011 at 04:23:19PM +0100, Tomasz Stanislawski wrote: > Hi Sakari, > > > On 11/08/2011 10:55 PM, Sakari Ailus wrote: > >Hi all, > > > >This RFC discusses the SUBDEV_S_SELECTION/SUBDEV_G_SELECTION API which is > >intended to amend and replace the existing SUBDEV_[SG]_CROP API. These > >IOCTLs have previously been discussed in the Cambridge V4L2 brainstorming > >meeting [0] and their intent is to provide more configurability for subdevs, > >including cropping on the source pads and composing for a display. > > > >The S_SELECTION patches for V4L2 nodes are available here [1] and the > >existing documentation for the V4L2 subdev pad format configuration can be > >found in [2]. > > > >SUBDEV_[SG]_SELECTION is intended to fully replace SUBDEV_[SG]_CROP in > >drivers as the latter can be implemented in SUBDEV_[SG]_SELECTION using > >active CROP target on sink pads. That can be done in v4l2-ioctl.c so drivers > >only will need to implement SUBDEV_[SG]_SELECTION. > > > > > >Questions, comments and thoughts are welcome, especially regarding new use > >cases. > > > > > >Order of configuration > >== > > Sorry, what is exactly the SOURCE pad and SINK pad? The spec says > "Data flows from a source pad to a sink pad.". Does in refer to a > subdev or to a link? Look at the image below: > > data link0 --> (pad0) [subdev] (pad1) > link1 > > From subdev's point of view, pad0 is data source, pad1 is the sink. > From link0's point of view, pad0 is a data sink. Which > interpretation is correct? It should say "link" in the spec. That needs to be clarified in the spec... > >The proposed order of the subdev configuration is as follows. Individual > >steps may be omitted since any of the steps will reset the rectangles / > >sizes for any following step. > > I assume that SOURCE and SINK are defined from the link's point of > view. Otherwise it would mean that configuration goes in order > opposite to data flow order. > > I do not think that resetting is a good idea. It is better to state > in spec that change of a given target guarantee that targets/formats > earlier in pipeline are not modified. Part below pipeline may change > or not. The application should check if the configuration of lower > parts of pipeline is suitable. For example I don't think the above text in the RFC would be a change on how it works at the moment. Inside a subdev the following stages of configuration (as in the flow of data) are indeed reset. Much of the hardware actually needs this unless they're scalers. > Change of COMPOSE target on SINK pad must not modify > - format on the SINK pad > - CROP on the SINK pad > > All other parameters may change. Of course the configuration of > lower part must be consistent with higher part of the pipeline. The above two would not be changed since they are before the compose window in the sink pad. If the user wishes the following stages also not to be modified, (s)he can specify it using a flag. We could call it V4L2_SUBDEV_SEL_FLAG_LOCALCHANGE. Better names are always welcome. :) See also open question 1. > > > >1. SUBDEV_S_FMT on the SINK pad. The user will issue SUBDEV_S_FMT to set the > >subdev sink pad image size and media bus format code and other parameters in > >v4l2_mbus_framefmt as necessary. > > > >2. SUBDEV_S_SELECTION with CROP target on the SINK pad. The crop rectangle > >is set related to the image size given in step 1). > > > >3. SUBDEV_S_SELECTION with COMPOSE target on the SINK pad. The size of the > >compose rectangle, if it differs from the size of the rectangle given in 2), > >signifies user's wish to perform scaling. > > > >4. SUBDEV_S_SELECTION with CROP target on the SOURCE pad. Configure cropping > >performed by the subdev after scaling. > > > >5. SUBDEV_S_SELECTION with COMPOSE target on the SOURCE pad. This configures > >composition on the display if relevant for the subdevice. (In this case the > >COMPOSE bounds will yield to the size of the display.) > > > >6. SUBDEV_S_FMT on the SOURCE pad. The size of the image is defined by > >setting CROP on the SOURCE pad, so SUBDEV_S_FMT only has an effect of > >changing other parameters than size. > > > >As defined in [2], when performing any of the configuration phases above, > >the formats and selections are reset to defaults from each phase onwards. > >For example, SUBDEV_S_SELECTION with CROP target on the SINK pad will > >--- beyond its obvious function of setting CROP selection target on the SINK > >pad --- reset the COMPOSE selection target on SINK pad, as well as the CROP > >selection target and format on the SOURCE pad. > > > > > > I think that formal definitions of CROP,COMPOSE for pads are needed. > As I remember from Cambridge brainstorming we agreed that > SINK.COMPOSE and SOURCE.CROP are expressed in subdev's internal > coordinate system. > The SINK.CROP is expressed in link0's coordinate system and > SOURCE.COMPOSE is expressed in li
[PATCH 00/25] Add PCTV-80e Support to v4l
These are the files required to support the Pinnacle PCTV-80e USB Tuner in video-4-linux. The files were originally downloaded from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and modified to fix compilation errors and also to move the driver files from the drx39xy subdirectory to the frontends directory. There are still coding style errors (mainly trailing whitespace and DOS Line Endings, but some other style errors exist as well). I have successfully compiled and installed this under the 3.0.x kernel, but haven't tried under any later kernels. Patrick Dickey (25): added PCTV80e information to cardlist file added bsp_host for pctv80e support added bsp_i2c for pctv80e support added bsp_tuner for pctv80e support added bsp_types for pctv80e support added drx39xxj for pctv80e support added drx39xxj header for pctv80e support added drx39_dummy for pctv80e support added drx_dap_fasi for pctv80e support added drx_dap_fasi header for pctv80e support added drx_driver for pctv80e support added drx_driver header for pctv80e support added drx_driver_version header for pctv80e support added drxj for pctv80e support added drxj header for pctv80e support added drxj_map header for pctv80e support added drxj_mc header for pctv80e support added drxj_mc_vsb header for pctv80e support added drxj_mc_vsbqam header for pctv80e support added drxj_options header for pctv80e support modified Kconfig to include pctv80e support modified Makefile for pctv80e support modified em28xx-cards for pctv80e support modified em28xx-dvb for pctv80e support modified em28xx header for pctv80e support Documentation/video4linux/CARDLIST.em28xx|1 + drivers/media/dvb/frontends/Kconfig |8 + drivers/media/dvb/frontends/Makefile |2 + drivers/media/dvb/frontends/bsp_host.h | 80 + drivers/media/dvb/frontends/bsp_i2c.h| 217 + drivers/media/dvb/frontends/bsp_tuner.h | 215 + drivers/media/dvb/frontends/bsp_types.h | 229 + drivers/media/dvb/frontends/drx39xxj.c | 464 + drivers/media/dvb/frontends/drx39xxj.h | 40 + drivers/media/dvb/frontends/drx39xxj_dummy.c | 135 + drivers/media/dvb/frontends/drx_dap_fasi.c | 670 + drivers/media/dvb/frontends/drx_dap_fasi.h | 268 + drivers/media/dvb/frontends/drx_driver.c | 1504 +++ drivers/media/dvb/frontends/drx_driver.h | 2588 drivers/media/dvb/frontends/drx_driver_version.h | 82 + drivers/media/dvb/frontends/drxj.c |15732 ++ drivers/media/dvb/frontends/drxj.h | 990 ++ drivers/media/dvb/frontends/drxj_map.h |15359 + drivers/media/dvb/frontends/drxj_mc.h| 3939 ++ drivers/media/dvb/frontends/drxj_mc_vsb.h| 744 + drivers/media/dvb/frontends/drxj_mc_vsbqam.h | 1437 ++ drivers/media/dvb/frontends/drxj_options.h | 65 + drivers/media/video/em28xx/em28xx-cards.c| 20 + drivers/media/video/em28xx/em28xx-dvb.c | 25 + drivers/media/video/em28xx/em28xx.h |1 + 25 files changed, 44815 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/bsp_host.h create mode 100644 drivers/media/dvb/frontends/bsp_i2c.h create mode 100644 drivers/media/dvb/frontends/bsp_tuner.h create mode 100644 drivers/media/dvb/frontends/bsp_types.h create mode 100644 drivers/media/dvb/frontends/drx39xxj.c create mode 100644 drivers/media/dvb/frontends/drx39xxj.h create mode 100644 drivers/media/dvb/frontends/drx39xxj_dummy.c create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.c create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.h create mode 100644 drivers/media/dvb/frontends/drx_driver.c create mode 100644 drivers/media/dvb/frontends/drx_driver.h create mode 100644 drivers/media/dvb/frontends/drx_driver_version.h create mode 100644 drivers/media/dvb/frontends/drxj.c create mode 100644 drivers/media/dvb/frontends/drxj.h create mode 100644 drivers/media/dvb/frontends/drxj_map.h create mode 100644 drivers/media/dvb/frontends/drxj_mc.h create mode 100644 drivers/media/dvb/frontends/drxj_mc_vsb.h create mode 100644 drivers/media/dvb/frontends/drxj_mc_vsbqam.h create mode 100644 drivers/media/dvb/frontends/drxj_options.h -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/25] added bsp_host for pctv80e support
---
drivers/media/dvb/frontends/bsp_host.h | 80
1 files changed, 80 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_host.h
diff --git a/drivers/media/dvb/frontends/bsp_host.h
b/drivers/media/dvb/frontends/bsp_host.h
new file mode 100644
index 000..75a5f7b
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_host.h
@@ -0,0 +1,80 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_host.h,v 1.3 2009/07/07 14:20:30 justin Exp $
+*
+* \brief Host and OS dependent type definitions, macro's and functions
+*
+*/
+
+#ifndef __DRXBSP_HOST_H__
+#define __DRXBSP_HOST_H__
+/*-
+INCLUDES
+-*/
+#include "bsp_types.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*-
+TYPEDEFS
+-*/
+
+
+/*-
+DEFINES
+-*/
+
+/*-
+Exported FUNCTIONS
+-*/
+DRXStatus_t DRXBSP_HST_Init(void);
+
+DRXStatus_t DRXBSP_HST_Term(void);
+
+void* DRXBSP_HST_Memcpy(void *to, void *from, u32_t n);
+
+int DRXBSP_HST_Memcmp(void *s1, void *s2, u32_t n);
+
+u32_t DRXBSP_HST_Clock(void);
+
+DRXStatus_t DRXBSP_HST_Sleep(u32_t n);
+
+/*-
+THE END
+-*/
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __DRXBSP_HOST_H__ */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/25] added PCTV80e information to cardlist file
--- Documentation/video4linux/CARDLIST.em28xx |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index d8c8544..319a9b2 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -78,3 +78,4 @@ 78 -> PCTV nanoStick T2 290e (em28174) 79 -> Terratec Cinergy H5 (em2884) [0ccd:0043,0ccd:10a2] 80 -> PCTV DVB-S2 Stick (460e) (em28174) +81 -> Pinnacle PCTV HD Mini(em2874)[2304:023f] -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/25] added bsp_i2c for pctv80e support
---
drivers/media/dvb/frontends/bsp_i2c.h | 217 +
1 files changed, 217 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_i2c.h
diff --git a/drivers/media/dvb/frontends/bsp_i2c.h
b/drivers/media/dvb/frontends/bsp_i2c.h
new file mode 100644
index 000..628c616
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_i2c.h
@@ -0,0 +1,217 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_i2c.h,v 1.5 2009/07/07 14:20:30 justin Exp $
+*
+* \brief I2C API, implementation depends on board specifics
+*
+* This module encapsulates I2C access.In some applications several devices
+* share one I2C bus. If these devices have the same I2C address some kind
+* off "switch" must be implemented to ensure error free communication with
+* one device. In case such a "switch" is used, the device ID can be used
+* to implement control over this "switch".
+*
+*
+*/
+
+#ifndef __BSPI2C_H__
+#define __BSPI2C_H__
+/*--
+INCLUDES
+--*/
+#include "bsp_types.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+/*--
+TYPEDEFS
+--*/
+/**
+* \typedef I2Caddr_t
+* \brief I2C device address (7-bit or 10-bit)
+*/
+typedef u16_t I2Caddr_t;
+
+/**
+* \typedef I2CdevId_t
+* \brief Device identifier.
+*
+* The device ID can be useful if several devices share an I2C address,
+* or if multiple I2C busses are used.
+* It can be used to control a "switch" selecting the correct device and/or
+* I2C bus.
+*
+*/
+typedef u16_t I2CdevId_t;
+
+/**
+* \struct _I2CDeviceAddr_t
+* \brief I2C device parameters.
+*
+* This structure contains the I2C address, the device ID and a userData
pointer.
+* The userData pointer can be used for application specific purposes.
+*
+*/
+struct _I2CDeviceAddr_t {
+ I2Caddr_t i2cAddr;/**< The I2C address of the device. */
+ I2CdevId_t i2cDevId; /**< The device identifier. */
+ void*userData; /**< User data pointer */
+};
+
+/**
+* \typedef I2CDeviceAddr_t
+* \brief I2C device parameters.
+*
+* This structure contains the I2C address and the device ID.
+*
+*/
+typedef struct _I2CDeviceAddr_t I2CDeviceAddr_t;
+
+/**
+* \typedef pI2CDeviceAddr_t
+* \brief Pointer to I2C device parameters.
+*/
+typedef I2CDeviceAddr_t *pI2CDeviceAddr_t;
+
+/*--
+DEFINES
+--*/
+
+/*--
+MACROS
+--*/
+
+/**
+* \def IS_I2C_10BIT(addr)
+* \brief Determine if I2C address 'addr' is a 10 bits address or not.
+* \param addr The I2C address.
+* \return int.
+* \retval 0 if address is not a 10 bits I2C address.
+* \retval 1 if address is a 10 bits I2C address.
+*/
+#define IS_I2C_10BIT(addr) \
+(((addr) & 0xF8) == 0xF0)
+
+/*--
+ENUM
+-
[PATCH 04/25] added bsp_tuner for pctv80e support
---
drivers/media/dvb/frontends/bsp_tuner.h | 215 +++
1 files changed, 215 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_tuner.h
diff --git a/drivers/media/dvb/frontends/bsp_tuner.h
b/drivers/media/dvb/frontends/bsp_tuner.h
new file mode 100644
index 000..b67027f
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_tuner.h
@@ -0,0 +1,215 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_tuner.h,v 1.5 2009/10/19 22:15:13 dingtao Exp $
+*
+* \brief Tuner dependable type definitions, macro's and functions
+*
+*/
+
+#ifndef __DRXBSP_TUNER_H__
+#define __DRXBSP_TUNER_H__
+/*--
+INCLUDES
+--*/
+#include "bsp_types.h"
+#include "bsp_i2c.h"
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/*--
+DEFINES
+--*/
+
+
+ /* Sub-mode bits should be adjacent and incremental */
+#define TUNER_MODE_SUB00x0001 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB10x0002 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB20x0004 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB30x0008 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB40x0010 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB50x0020 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB60x0040 /* for sub-mode (e.g. RF-AGC setting) */
+#define TUNER_MODE_SUB70x0080 /* for sub-mode (e.g. RF-AGC setting) */
+
+#define TUNER_MODE_DIGITAL 0x0100 /* for digital channel (e.g. DVB-T) */
+#define TUNER_MODE_ANALOG 0x0200 /* for analog channel (e.g. PAL) */
+#define TUNER_MODE_SWITCH 0x0400 /* during channel switch & scanning */
+#define TUNER_MODE_LOCK0x0800 /* after tuner has locked */
+#define TUNER_MODE_6MHZ0x1000 /* for 6MHz bandwidth channels*/
+#define TUNER_MODE_7MHZ0x2000 /* for 7MHz bandwidth channels*/
+#define TUNER_MODE_8MHZ0x4000 /* for 8MHz bandwidth channels*/
+
+#define TUNER_MODE_SUB_MAX 8
+#define TUNER_MODE_SUBALL (TUNER_MODE_SUB0 | TUNER_MODE_SUB1 | \
+ TUNER_MODE_SUB2 | TUNER_MODE_SUB3 | \
+ TUNER_MODE_SUB4 | TUNER_MODE_SUB5 | \
+ TUNER_MODE_SUB6 | TUNER_MODE_SUB7)
+
+/*--
+TYPEDEFS
+--*/
+
+typedef u32_t TUNERMode_t;
+typedef pu32_t pTUNERMode_t;
+
+typedef char* TUNERSubMode_t;/* description of submode */
+typedef TUNERSubMode_t *pTUNERSubMode_t;
+
+
+typedef enum {
+
+ TUNER_LOCKED,
+ TUNER_NOT_LOCKED
+
+} TUNERLockStatus_t, *pTUNERLockStatus_t;
+
+
+typedef struct {
+
+ char *name; /* Tuner brand & type name */
+ DRXFrequency_t minFreqRF; /* Lowest RF input frequency, in kHz */
+ DRXFrequency_t maxFreqRF; /* Highest RF input frequency, in kHz */
+
+ u8_tsubMode;
[PATCH 07/25] added drx39xxj header for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj.h
diff --git a/drivers/media/dvb/frontends/drx39xxj.h
b/drivers/media/dvb/frontends/drx39xxj.h
new file mode 100644
index 000..168d251
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj.h
@@ -0,0 +1,40 @@
+/*
+ * Driver for Micronas DRX39xx family (drx3933j)
+ *
+ * Written by Devin Heitmueller
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=
+ */
+
+#ifndef DRX39XXJ_H
+#define DRX39XXJ_H
+
+#include
+#include "dvb_frontend.h"
+#include "drx_driver.h"
+
+struct drx39xxj_state {
+ struct i2c_adapter *i2c;
+ DRXDemodInstance_t *demod;
+ DRXStandard_t current_standard;
+ struct dvb_frontend frontend;
+ int powered_up:1;
+ unsigned int i2c_gate_open:1;
+};
+
+extern struct dvb_frontend *drx39xxj_attach(struct i2c_adapter *i2c);
+
+#endif // DRX39XXJ_H
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/25] added drx_dap_fasi for pctv80e support
--- drivers/media/dvb/frontends/drx_dap_fasi.c | 670 1 files changed, 670 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.c diff --git a/drivers/media/dvb/frontends/drx_dap_fasi.c b/drivers/media/dvb/frontends/drx_dap_fasi.c new file mode 100644 index 000..f34641d --- /dev/null +++ b/drivers/media/dvb/frontends/drx_dap_fasi.c @@ -0,0 +1,670 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/*** +* FILENAME: $Id: drx_dap_fasi.c,v 1.7 2009/12/28 14:36:21 carlo Exp $ +* +* DESCRIPTION: +* Part of DRX driver. +* Data access protocol: Fast Access Sequential Interface (fasi) +* Fast access, because of short addressing format (16 instead of 32 bits addr) +* Sequential, because of I2C. +* These functions know how the chip's memory and registers are to be accessed, +* but nothing more. +* +* These functions should not need adapting to a new platform. +* +* USAGE: +* - +* +* NOTES: +* +* +***/ + +#include "drx_dap_fasi.h" +#include "bsp_host.h" /* for DRXBSP_HST_Memcpy() */ + +/**/ + +/* Function prototypes */ +static DRXStatus_t DRXDAP_FASI_WriteBlock ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register/memory */ + u16_t datasize, /* size of data */ + pu8_t data, /* data to send */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadBlock ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register/memory */ + u16_t datasize, /* size of data */ + pu8_t data, /* data to send */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_WriteReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register */ + u8_t data, /* data to write*/ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t addr, /* address of register */ + pu8_t data, /* buffer to receive data */ + DRXflags_tflags);/* special device flags */ + +static DRXStatus_t DRXDAP_FASI_ReadModifyWriteReg8 ( + pI2CDeviceAddr_t devAddr, /* address of I2C device*/ + DRXaddr_t waddr, /* address of register */ + DRXaddr_t raddr, /* address to read back from*/ + u8_t datain,/* data to send */ + pu8_t dataout); /* data to receive back */ + +static DRXStatus_t DRXDAP_FASI_WriteReg16 ( + pI2CDeviceAddr_t devAddr, /*
[PATCH 06/25] added drx39xxj for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj.c | 464
1 files changed, 464 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj.c
diff --git a/drivers/media/dvb/frontends/drx39xxj.c
b/drivers/media/dvb/frontends/drx39xxj.c
new file mode 100644
index 000..a74e81b
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj.c
@@ -0,0 +1,464 @@
+/*
+ * Driver for Micronas DRX39xx family (drx3933j)
+ *
+ * Written by Devin Heitmueller
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.=
+ */
+
+#include
+#include
+#include
+#include
+
+#include "dvb_frontend.h"
+#include "drx39xxj.h"
+#include "drx_driver.h"
+#include "bsp_types.h"
+#include "bsp_tuner.h"
+#include "drxj_mc.h"
+#include "drxj.h"
+
+static int drx39xxj_set_powerstate(struct dvb_frontend* fe, int enable)
+{
+ struct drx39xxj_state *state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXPowerMode_t powerMode;
+
+ if (enable)
+ powerMode = DRX_POWER_UP;
+ else
+ powerMode = DRX_POWER_DOWN;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_POWER_MODE, &powerMode);
+ if (result != DRX_STS_OK) {
+ printk("Power state change failed\n");
+ return 0;
+ }
+
+ state->powered_up = enable;
+ return 0;
+}
+
+static int drx39xxj_read_status(struct dvb_frontend* fe, fe_status_t* status)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXLockStatus_t lock_status;
+
+ *status = 0;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_LOCK_STATUS, &lock_status);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get lock status!\n");
+ *status = 0;
+ }
+
+ switch (lock_status) {
+ case DRX_NEVER_LOCK:
+ *status = 0;
+ printk("drx says NEVER_LOCK\n");
+ break;
+ case DRX_NOT_LOCKED:
+ *status = 0;
+ break;
+ case DRX_LOCK_STATE_1:
+ case DRX_LOCK_STATE_2:
+ case DRX_LOCK_STATE_3:
+ case DRX_LOCK_STATE_4:
+ case DRX_LOCK_STATE_5:
+ case DRX_LOCK_STATE_6:
+ case DRX_LOCK_STATE_7:
+ case DRX_LOCK_STATE_8:
+ case DRX_LOCK_STATE_9:
+ *status = FE_HAS_SIGNAL
+ | FE_HAS_CARRIER
+ | FE_HAS_VITERBI
+ | FE_HAS_SYNC;
+ break;
+ case DRX_LOCKED:
+ *status = FE_HAS_SIGNAL
+ | FE_HAS_CARRIER
+ | FE_HAS_VITERBI
+ | FE_HAS_SYNC
+ | FE_HAS_LOCK;
+ break;
+ default:
+ printk("Lock state unknown %d\n", lock_status);
+ }
+
+ return 0;
+}
+
+static int drx39xxj_read_ber(struct dvb_frontend* fe, u32* ber)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXSigQuality_t sig_quality;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_SIG_QUALITY, &sig_quality);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get ber!\n");
+ *ber = 0;
+ return 0;
+ }
+
+ *ber = sig_quality.postReedSolomonBER;
+ return 0;
+}
+
+static int drx39xxj_read_signal_strength(struct dvb_frontend* fe, u16*
strength)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demod;
+ DRXStatus_t result;
+ DRXSigQuality_t sig_quality;
+
+ result = DRX_Ctrl(demod, DRX_CTRL_SIG_QUALITY, &sig_quality);
+ if (result != DRX_STS_OK) {
+ printk("drx39xxj: could not get signal strength!\n");
+ *strength = 0;
+ return 0;
+ }
+
+ /* 1-100% scaled to 0-65535 */
+ *strength = (sig_quality.indicator * 65535 / 100);
+ return 0;
+}
+
+static int drx39xxj_read_snr(struct dvb_frontend* fe, u16* snr)
+{
+ struct drx39xxj_state* state = fe->demodulator_priv;
+ DRXDemodInstance_t *demod = state->demo
[PATCH 11/25] added drx_driver for pctv80e support
--- drivers/media/dvb/frontends/drx_driver.c | 1504 ++ 1 files changed, 1504 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_driver.c diff --git a/drivers/media/dvb/frontends/drx_driver.c b/drivers/media/dvb/frontends/drx_driver.c new file mode 100644 index 000..1f58de7 --- /dev/null +++ b/drivers/media/dvb/frontends/drx_driver.c @@ -0,0 +1,1504 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/** +* \file $Id: drx_driver.c,v 1.40 2010/01/12 01:24:56 lfeng Exp $ +* +* \brief Generic DRX functionality, DRX driver core. +* +*/ + +/*-- +INCLUDE FILES +--*/ +#include "drx_driver.h" +#include "bsp_host.h" + +#define VERSION_FIXED 0 +#if VERSION_FIXED +#define VERSION_MAJOR 0 +#define VERSION_MINOR 0 +#define VERSION_PATCH 0 +#else +#include "drx_driver_version.h" +#endif + +/*-- +DEFINES +--*/ + +/**/ +/*=== MICROCODE RELATED DEFINES ==*/ +/**/ + +/** \brief Magic word for checking correct Endianess of microcode data. */ +#ifndef DRX_UCODE_MAGIC_WORD +#define DRX_UCODE_MAGIC_WORD u16_t)'H')<<8)+((u16_t)'L')) +#endif + +/** \brief CRC flag in ucode header, flags field. */ +#ifndef DRX_UCODE_CRC_FLAG +#define DRX_UCODE_CRC_FLAG (0x0001) +#endif + +/** \brief Compression flag in ucode header, flags field. */ +#ifndef DRX_UCODE_COMPRESSION_FLAG +#define DRX_UCODE_COMPRESSION_FLAG (0x0002) +#endif + +/** \brief Maximum size of buffer used to verify the microcode. + Must be an even number. */ +#ifndef DRX_UCODE_MAX_BUF_SIZE +#define DRX_UCODE_MAX_BUF_SIZE (DRXDAP_MAX_RCHUNKSIZE) +#endif +#if DRX_UCODE_MAX_BUF_SIZE & 1 +#error DRX_UCODE_MAX_BUF_SIZE must be an even number +#endif + +/**/ +/*=== CHANNEL SCAN RELATED DEFINES ===*/ +/**/ + +/** +* \brief Maximum progress indication. +* +* Progress indication will run from 0 upto DRX_SCAN_MAX_PROGRESS during scan. +* +*/ +#ifndef DRX_SCAN_MAX_PROGRESS +#define DRX_SCAN_MAX_PROGRESS 1000 +#endif + +/**/ +/*=== MACROS =*/ +/**/ + +#define DRX_ISPOWERDOWNMODE(mode) ((mode == DRX_POWER_MODE_9) || \ + (mode == DRX_POWER_MODE_10) || \ + (mode == DRX_POWER_MODE_11) || \ + (mode == DRX_POWER_MODE_12) || \ + (mode == DRX_POWER_MODE_13) || \ + (mode == DRX_POWER_MODE_14) || \ + (mode == DRX_POWE
[PATCH 13/25] added drx_driver_version header for pctv80e support
---
drivers/media/dvb/frontends/drx_driver_version.h | 82 ++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx_driver_version.h
diff --git a/drivers/media/dvb/frontends/drx_driver_version.h
b/drivers/media/dvb/frontends/drx_driver_version.h
new file mode 100644
index 000..b6a37d8
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx_driver_version.h
@@ -0,0 +1,82 @@
+/*
+
***
+ * WARNING - THIS FILE HAS BEEN GENERATED - DO NOT CHANGE
+ *
+ * Filename:drx_driver_version.h
+ * Generated on:Mon Jan 18 12:09:23 2010
+ * Generated by:IDF:x 1.3.0
+ * Generated from: ../../../device/drxj/version
+ * Output start:[entry point]
+ *
+ * filename last modified re-use
+ *
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/* -
+ * version.idf Mon Jan 18 11:56:10 2010-
+ *
+ */
+
+#ifndef __DRX_DRIVER_VERSION__H__
+#define __DRX_DRIVER_VERSION__H__ INCLUDED
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#ifdef _REGISTERTABLE_
+#include
+extern RegisterTable_t drx_driver_version[];
+extern RegisterTableInfo_t drx_driver_version_info[];
+#endif /* _REGISTERTABLE_ */
+
+
+/*
+
*==
+ * VERSION
+ * version@/var/cvs/projects/drxj.cvsroot/hostcode/drxdriver/device/drxj
+
*==
+ */
+
+#define VERSION__A 0x0
+#define VERSION_MAJOR 1
+#define VERSION_MINOR 0
+#define VERSION_PATCH 56
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif /* __DRX_DRIVER_VERSION__H__ */
+
+/*
+ * End of file (drx_driver_version.h)
+
***
+ */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/25] added drx39_dummy for pctv80e support
---
drivers/media/dvb/frontends/drx39xxj_dummy.c | 135 ++
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drx39xxj_dummy.c
diff --git a/drivers/media/dvb/frontends/drx39xxj_dummy.c
b/drivers/media/dvb/frontends/drx39xxj_dummy.c
new file mode 100644
index 000..3ed2c39
--- /dev/null
+++ b/drivers/media/dvb/frontends/drx39xxj_dummy.c
@@ -0,0 +1,135 @@
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "drx_driver.h"
+#include "bsp_types.h"
+#include "bsp_tuner.h"
+#include "drx39xxj.h"
+
+/* Dummy function to satisfy drxj.c */
+DRXStatus_t DRXBSP_TUNER_Open(pTUNERInstance_t tuner)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_TUNER_Close(pTUNERInstance_t tuner)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_TUNER_SetFrequency(pTUNERInstance_t tuner,
+ TUNERMode_t mode,
+ DRXFrequency_t centerFrequency)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t
+DRXBSP_TUNER_GetFrequency(pTUNERInstance_t tuner,
+ TUNERMode_t mode,
+ pDRXFrequency_t RFfrequency,
+ pDRXFrequency_t IFfrequency)
+{
+ return DRX_STS_OK;
+}
+
+DRXStatus_t DRXBSP_HST_Sleep(u32_t n)
+{
+ msleep(n);
+ return DRX_STS_OK;
+}
+
+u32_t DRXBSP_HST_Clock(void)
+{
+ return jiffies_to_msecs(jiffies);
+}
+
+int DRXBSP_HST_Memcmp(void *s1, void *s2, u32_t n)
+{
+ return (memcmp(s1, s2, (size_t) n));
+}
+
+void* DRXBSP_HST_Memcpy(void *to, void *from, u32_t n)
+{
+ return (memcpy(to, from, (size_t) n));
+}
+
+DRXStatus_t DRXBSP_I2C_WriteRead(pI2CDeviceAddr_t wDevAddr,
+ u16_twCount,
+ pu8_twData,
+ pI2CDeviceAddr_t rDevAddr,
+ u16_trCount,
+ pu8_trData)
+{
+ struct drx39xxj_state *state;
+ struct i2c_msg msg[2];
+ unsigned int num_msgs;
+
+ if (wDevAddr == NULL) {
+ /* Read only */
+ state = rDevAddr->userData;
+ msg[0].addr = rDevAddr->i2cAddr >> 1;
+ msg[0].flags = I2C_M_RD;
+ msg[0].buf = rData;
+ msg[0].len = rCount;
+ num_msgs = 1;
+ } else if (rDevAddr == NULL) {
+ /* Write only */
+ state = wDevAddr->userData;
+ msg[0].addr = wDevAddr->i2cAddr >> 1;
+ msg[0].flags = 0;
+ msg[0].buf = wData;
+ msg[0].len = wCount;
+ num_msgs = 1;
+ } else {
+ /* Both write and read */
+ state = wDevAddr->userData;
+ msg[0].addr = wDevAddr->i2cAddr >> 1;
+ msg[0].flags = 0;
+ msg[0].buf = wData;
+ msg[0].len = wCount;
+ msg[1].addr = rDevAddr->i2cAddr >> 1;
+ msg[1].flags = I2C_M_RD;
+ msg[1].buf = rData;
+ msg[1].len = rCount;
+ num_msgs = 2;
+ }
+
+ if (state->i2c == NULL) {
+ printk("i2c was zero, aborting\n");
+ return 0;
+ }
+ if (i2c_transfer(state->i2c, msg, num_msgs) != num_msgs) {
+ printk(KERN_WARNING "drx3933: I2C write/read failed\n");
+ return -EREMOTEIO;
+ }
+
+ return DRX_STS_OK;
+
+#ifdef DJH_DEBUG
+
+ struct drx39xxj_state *state = wDevAddr->userData;
+
+ struct i2c_msg msg[2] = {
+ { .addr = wDevAddr->i2cAddr,
+ .flags = 0, .buf = wData, .len = wCount },
+ { .addr = rDevAddr->i2cAddr,
+ .flags = I2C_M_RD, .buf = rData, .len = rCount },
+ };
+
+ printk("drx3933 i2c operation addr=%x i2c=%p, wc=%x rc=%x\n",
+ wDevAddr->i2cAddr, state->i2c, wCount, rCount);
+
+ if (i2c_transfer(state->i2c, msg, 2) != 2) {
+ printk(KERN_WARNING "drx3933: I2C write/read failed\n");
+ return -EREMOTEIO;
+ }
+#endif
+ return 0;
+}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/25] modified Kconfig to include pctv80e support
--- drivers/media/dvb/frontends/Kconfig |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/Kconfig b/drivers/media/dvb/frontends/Kconfig index 4a2d2e6..352815e 100644 --- a/drivers/media/dvb/frontends/Kconfig +++ b/drivers/media/dvb/frontends/Kconfig @@ -683,6 +683,14 @@ config DVB_IX2505V help A DVB-S tuner module. Say Y when you want to support this frontend. +config DVB_DRX39XYJ + tristate "Micronas DRX-J demodulator" + depends on DVB_CORE && I2C + default m if DVB_FE_CUSTOMISE + help + An ATSC 8VSB and QAM64/256 tuner module. Say Y when you want + to support this frontend. + config DVB_IT913X_FE tristate "it913x frontend and it9137 tuner" depends on DVB_CORE && I2C -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 22/25] modified Makefile for pctv80e support
--- drivers/media/dvb/frontends/Makefile |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/Makefile b/drivers/media/dvb/frontends/Makefile index f639f67..4709ebc 100644 --- a/drivers/media/dvb/frontends/Makefile +++ b/drivers/media/dvb/frontends/Makefile @@ -11,6 +11,7 @@ au8522-objs = au8522_dig.o au8522_decoder.o drxd-objs = drxd_firm.o drxd_hard.o cxd2820r-objs = cxd2820r_core.o cxd2820r_c.o cxd2820r_t.o cxd2820r_t2.o drxk-objs := drxk_hard.o +drx39xyj-objs := drx39xxj.o drx_driver.o drx39xxj_dummy.o drxj.o drx_dap_fasi.o obj-$(CONFIG_DVB_PLL) += dvb-pll.o obj-$(CONFIG_DVB_STV0299) += stv0299.o @@ -86,6 +87,7 @@ obj-$(CONFIG_DVB_ISL6423) += isl6423.o obj-$(CONFIG_DVB_EC100) += ec100.o obj-$(CONFIG_DVB_DS3000) += ds3000.o obj-$(CONFIG_DVB_MB86A16) += mb86a16.o +obj-$(CONFIG_DVB_DRX39XYJ) += drx39xyj.o obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o obj-$(CONFIG_DVB_IX2505V) += ix2505v.o obj-$(CONFIG_DVB_STV0367) += stv0367.o -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 24/25] modified em28xx-dvb for pctv80e support
---
drivers/media/video/em28xx/em28xx-dvb.c | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-dvb.c
b/drivers/media/video/em28xx/em28xx-dvb.c
index cef7a2d..b69e5f3 100644
--- a/drivers/media/video/em28xx/em28xx-dvb.c
+++ b/drivers/media/video/em28xx/em28xx-dvb.c
@@ -36,6 +36,7 @@
#include "mt352.h"
#include "mt352_priv.h" /* FIXME */
#include "tda1002x.h"
+#include "drx39xxj.h"
#include "tda18271.h"
#include "s921.h"
#include "drxd.h"
@@ -309,6 +310,20 @@ static struct drxd_config em28xx_drxd = {
.disable_i2c_gate_ctrl = 1,
};
+
+static struct tda18271_std_map drx_j_std_map = {
+ .atsc_6 = { .if_freq = 5000, .agc_mode = 3, .std = 0, .if_lvl = 1,
+ .rfagc_top = 0x37, },
+ .qam_6= { .if_freq = 5380, .agc_mode = 3, .std = 3, .if_lvl = 1,
+ .rfagc_top = 0x37, },
+};
+
+static struct tda18271_config pinnacle_80e_dvb_config = {
+ .std_map = &drx_j_std_map,
+ .gate= TDA18271_GATE_DIGITAL,
+ .role= TDA18271_MASTER,
+};
+
struct drxk_config terratec_h5_drxk = {
.adr = 0x29,
.single_master = 1,
@@ -625,6 +640,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
{
int result = 0, mfe_shared = 0;
struct em28xx_dvb *dvb;
+ struct dvb_frontend *fe;
if (!dev->board.has_dvb) {
/* This device does not support the extension */
@@ -752,6 +768,15 @@ static int em28xx_dvb_init(struct em28xx *dev)
}
}
break;
+ case EM2874_BOARD_PCTV_HD_MINI_80E:
+ dvb->fe[0] = dvb_attach(drx39xxj_attach, &dev->i2c_adap);
+ if (dvb->fe[0] != NULL) {
+ fe = dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
+ &dev->i2c_adap,
+ &pinnacle_80e_dvb_config);
+ printk(KERN_ERR "dvb_attach tuner result=%p\n", fe);
+ }
+ break;
case EM2870_BOARD_KWORLD_A340:
dvb->fe[0] = dvb_attach(lgdt3305_attach,
&em2870_lgdt3304_dev,
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 23/25] modified em28xx-cards for pctv80e support
---
drivers/media/video/em28xx/em28xx-cards.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 9b747c2..550bb8e 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -195,6 +195,17 @@ static struct em28xx_reg_seq pinnacle_hybrid_pro_digital[]
= {
{ -1, -1, -1, -1},
};
+/* PCTV HD Mini (80e) GPIOs
+ 0-5: not used
+ 6: demod reset, active low
+ 7: LED on, active high */
+static struct em28xx_reg_seq em2874_pctv_80e_digital[] = {
+ {EM28XX_R06_I2C_CLK,0x45, 0xff, 10}, /*400 KHz*/
+ {EM2874_R80_GPIO, 0x80, 0xff, 100},/*Demod reset*/
+ {EM2874_R80_GPIO, 0xc0, 0xff, 10},
+ { -1, -1, -1, -1},
+};
+
static struct em28xx_reg_seq terratec_cinergy_USB_XS_FR_analog[] = {
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{EM2880_R04_GPO,0x00, 0xff, 10},
@@ -1808,6 +1819,13 @@ struct em28xx_board em28xx_boards[] = {
.tuner_gpio= reddo_dvb_c_usb_box,
.has_dvb = 1,
},
+ [EM2874_BOARD_PCTV_HD_MINI_80E] = {
+ .name = "Pinnacle PCTV HD Mini",
+ .tuner_type = TUNER_ABSENT,
+ .has_dvb = 1,
+ .dvb_gpio = em2874_pctv_80e_digital,
+ .decoder = EM28XX_NODECODER,
+ },
/* 1b80:a340 - Empia EM2870, NXP TDA18271HD and LG DT3304, sold
* initially as the KWorld PlusTV 340U, then as the UB435-Q.
* Early variants have a TDA18271HD/C1, later ones a TDA18271HD/C2 */
@@ -1961,6 +1979,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2882_BOARD_PINNACLE_HYBRID_PRO_330E },
{ USB_DEVICE(0x2304, 0x0227),
.driver_info = EM2880_BOARD_PINNACLE_PCTV_HD_PRO },
+ { USB_DEVICE(0x2304, 0x023f),
+ .driver_info = EM2874_BOARD_PCTV_HD_MINI_80E },
{ USB_DEVICE(0x0413, 0x6023),
.driver_info = EM2800_BOARD_LEADTEK_WINFAST_USBII },
{ USB_DEVICE(0x093b, 0xa005),
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/25] added drxj_options header for pctv80e support
---
drivers/media/dvb/frontends/drxj_options.h | 65
1 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drxj_options.h
diff --git a/drivers/media/dvb/frontends/drxj_options.h
b/drivers/media/dvb/frontends/drxj_options.h
new file mode 100644
index 000..962bd61
--- /dev/null
+++ b/drivers/media/dvb/frontends/drxj_options.h
@@ -0,0 +1,65 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: drxj_options.h,v 1.5 2009/10/05 21:32:49 dingtao Exp $
+*
+* \brief DRXJ optional settings
+*
+* \author Tao Ding
+*/
+
+/* Note: Please add preprocessor DRXJ_OPTIONS_H for drxj.c to include this
file */
+#ifndef __DRXJ_OPTIONS_H__
+#define __DRXJ_OPTIONS_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* #define DRXJ_DIGITAL_ONLY */
+/* #define DRXJ_VSB_ONLY */
+/* #define DRXJ_SIGNAL_ACCUM_ERR */
+/* #define MPEG_SERIAL_OUTPUT_PIN_DRIVE_STRENGTH 0x03 */
+/* #define MPEG_PARALLEL_OUTPUT_PIN_DRIVE_STRENGTH 0x04 */
+/* #define MPEG_OUTPUT_CLK_DRIVE_STRENGTH0x05 */
+/* #define OOB_CRX_DRIVE_STRENGTH0x04 */
+/* #define OOB_DRX_DRIVE_STRENGTH0x05 */
+/* #define DRXJ_QAM_MAX_WAITTIME 1000 */
+/* #define DRXJ_QAM_FEC_LOCK_WAITTIME200 */
+/* #define DRXJ_QAM_DEMOD_LOCK_EXT_WAITTIME 250 */
+
+/*-
+THE END
+-*/
+#ifdef __cplusplus
+}
+#endif
+#endif /* __DRXJ_OPTIONS_H__ */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 25/25] modified em28xx header for pctv80e support
--- drivers/media/video/em28xx/em28xx.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx.h b/drivers/media/video/em28xx/em28xx.h index 2a2cb7e..ead2cfe 100644 --- a/drivers/media/video/em28xx/em28xx.h +++ b/drivers/media/video/em28xx/em28xx.h @@ -121,6 +121,7 @@ #define EM28174_BOARD_PCTV_290E 78 #define EM2884_BOARD_TERRATEC_H5 79 #define EM28174_BOARD_PCTV_460E 80 +#define EM2874_BOARD_PCTV_HD_MINI_80E81 /* Limits minimum and default number of buffers */ #define EM28XX_MIN_BUF 4 -- 1.7.5.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/25] added drxj header for pctv80e support
---
drivers/media/dvb/frontends/drxj.h | 990
1 files changed, 990 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/drxj.h
diff --git a/drivers/media/dvb/frontends/drxj.h
b/drivers/media/dvb/frontends/drxj.h
new file mode 100644
index 000..5899537
--- /dev/null
+++ b/drivers/media/dvb/frontends/drxj.h
@@ -0,0 +1,990 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: drxj.h,v 1.132 2009/12/22 12:13:48 danielg Exp $
+*
+* \brief DRXJ specific header file
+*
+* \author Dragan Savic, Milos Nikolic, Mihajlo Katona, Tao Ding, Paul Janssen
+*/
+
+#ifndef __DRXJ_H__
+#define __DRXJ_H__
+/*-
+INCLUDES
+-*/
+
+#include "drx_driver.h"
+#include "drx_dap_fasi.h"
+
+#ifdef __cplusplus
+extern "C" {
+
+#endif /*
+ */
+
+/* Check DRX-J specific dap condition */
+/* Multi master mode and short addr format only will not work.
+ RMW, CRC reset, broadcast and switching back to single master mode
+ cannot be done with short addr only in multi master mode. */
+#if ((DRXDAP_SINGLE_MASTER==0)&&(DRXDAPFASI_LONG_ADDR_ALLOWED==0))
+#error "Multi master mode and short addressing only is an illegal combination"
+ *; /* Generate a fatal compiler error to make sure
it stops here,
+ this is necesarry because not all compilers
stop after a #error. */
+
+#endif /*
+ */
+
+/*-
+TYPEDEFS
+-*/
+/**/
+/**/
+/*== code support
*/
+/**/
+/**/
+
+/**/
+/**/
+/*== SCU cmd if
=*/
+/**/
+/**/
+
+typedef struct {
+
+u16_t command;
+/**< Command number */
+
+u16_t parameterLen;
+/**< Data length in byte */
+
+u16_t resultLen;
+/**< result length in byte */
+
+u16_t * parameter;
+/**< General purpous param */
+
+u16_t * result;
+/**< General purpous param */
+
+} DRXJSCUCmd_t, *pDRXJSCUCmd_t;
+
+
+
+/**/
+/**/
+/*== CTRL CFG related data structures
*/
+/**/
+/*==
[PATCH 10/25] added drx_dap_fasi header for pctv80e support
--- drivers/media/dvb/frontends/drx_dap_fasi.h | 268 1 files changed, 268 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/frontends/drx_dap_fasi.h diff --git a/drivers/media/dvb/frontends/drx_dap_fasi.h b/drivers/media/dvb/frontends/drx_dap_fasi.h new file mode 100644 index 000..b1c0eb6 --- /dev/null +++ b/drivers/media/dvb/frontends/drx_dap_fasi.h @@ -0,0 +1,268 @@ +/* + Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc. + All rights reserved. + + Redistribution and use in source and binary forms, with or without + modification, are permitted provided that the following conditions are met: + + * Redistributions of source code must retain the above copyright notice, +this list of conditions and the following disclaimer. + * Redistributions in binary form must reproduce the above copyright notice, +this list of conditions and the following disclaimer in the documentation + and/or other materials provided with the distribution. + * Neither the name of Trident Microsystems nor Hauppauge Computer Works +nor the names of its contributors may be used to endorse or promote + products derived from this software without specific prior written + permission. + + THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" + AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE + LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR + CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN + CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE + POSSIBILITY OF SUCH DAMAGE. +*/ + +/*** +* FILENAME: $Id: drx_dap_fasi.h,v 1.5 2009/07/07 14:21:40 justin Exp $ +* +* DESCRIPTION: +* Part of DRX driver. +* Data access protocol: Fast Access Sequential Interface (fasi) +* Fast access, because of short addressing format (16 instead of 32 bits addr) +* Sequential, because of I2C. +* +* USAGE: +* Include. +* +* NOTES: +* +* +***/ + +/* compilation control switches --*/ + +#ifndef __DRX_DAP_FASI_H__ +#define __DRX_DAP_FASI_H__ + +/* Required includes -*/ + +#include "drx_driver.h" + +/* Defines, configuring the API --*/ + +/ +* Allowed address formats +/ + +/* +* Comments about short/long addressing format: +* +* The DAP FASI offers long address format (4 bytes) and short address format +* (2 bytes). The DAP can operate in 3 modes: +* (1) only short +* (2) only long +* (3) both long and short but short preferred and long only when necesarry +* +* These modes must be selected compile time via compile switches. +* Compile switch settings for the diffrent modes: +* (1) DRXDAPFASI_LONG_ADDR_ALLOWED=0, DRXDAPFASI_SHORT_ADDR_ALLOWED=1 +* (2) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=0 +* (3) DRXDAPFASI_LONG_ADDR_ALLOWED=1, DRXDAPFASI_SHORT_ADDR_ALLOWED=1 +* +* The default setting will be (3) both long and short. +* The default setting will need no compile switches. +* The default setting must be overridden if compile switches are already +* defined. +* +*/ + +/* set default */ +#if !defined(DRXDAPFASI_LONG_ADDR_ALLOWED) +#define DRXDAPFASI_LONG_ADDR_ALLOWED 1 +#endif + +/* set default */ +#if !defined(DRXDAPFASI_SHORT_ADDR_ALLOWED) +#define DRXDAPFASI_SHORT_ADDR_ALLOWED 1 +#endif + +/* check */ +#if ((DRXDAPFASI_LONG_ADDR_ALLOWED==0) && \ + (DRXDAPFASI_SHORT_ADDR_ALLOWED==0)) +#error At least one of short- or long-addressing format must be allowed. +*; /* illegal statement to force compiler error */ +#endif + + +/ +* Single/master multi master setting +/ +/* +* Comments about SINGLE MASTER/MULTI MASTER modes: +* +* Consider the two sides:1) the master and 2)the slave. +* +* Master: +* Single/multimaster operation set via DRXDAP_SINGLE_MASTER compile switch +* + single master mode means no use of repeated starts +* + multi master mode means use of repeated starts +* Default is single master. +* Default can be overriden by setting the compile switch DRXDAP_SINGLE_MASTER. +* +* Slave: +* Single/multi master selected via the flags in the FASI protocol. +* + single master m
[PATCH 05/25] added bsp_types for pctv80e support
---
drivers/media/dvb/frontends/bsp_types.h | 229 +++
1 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/bsp_types.h
diff --git a/drivers/media/dvb/frontends/bsp_types.h
b/drivers/media/dvb/frontends/bsp_types.h
new file mode 100644
index 000..1c48046
--- /dev/null
+++ b/drivers/media/dvb/frontends/bsp_types.h
@@ -0,0 +1,229 @@
+/*
+ Copyright (c), 2004-2005,2007-2010 Trident Microsystems, Inc.
+ All rights reserved.
+
+ Redistribution and use in source and binary forms, with or without
+ modification, are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright notice,
+this list of conditions and the following disclaimer in the documentation
+ and/or other materials provided with the distribution.
+ * Neither the name of Trident Microsystems nor Hauppauge Computer Works
+nor the names of its contributors may be used to endorse or promote
+ products derived from this software without specific prior written
+ permission.
+
+ THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ POSSIBILITY OF SUCH DAMAGE.
+*/
+
+/**
+* \file $Id: bsp_types.h,v 1.5 2009/08/06 12:55:57 carlo Exp $
+*
+* \brief General type definitions for board support packages
+*
+* This file contains type definitions that are needed for almost any
+* board support package.
+* The definitions are host and project independent.
+*
+*/
+
+#ifndef __BSP_TYPES_H__
+#define __BSP_TYPES_H__
+/*-
+INCLUDES
+-*/
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+/*-
+TYPEDEFS
+-*/
+
+/**
+* \typedef unsigned char u8_t
+* \brief type definition of an unsigned 8 bits integer
+*/
+typedef unsigned char u8_t;
+/**
+* \typedef char s8_t
+* \brief type definition of a signed 8 bits integer
+*/
+typedef char s8_t;
+/**
+* \typedef unsigned short u16_t *pu16_t
+* \brief type definition of an unsigned 16 bits integer
+*/
+typedef unsigned short u16_t;
+/**
+* \typedef short s16_t
+* \brief type definition of a signed 16 bits integer
+*/
+typedef short s16_t;
+/**
+* \typedef unsigned long u32_t
+* \brief type definition of an unsigned 32 bits integer
+*/
+typedef unsigned long u32_t;
+/**
+* \typedef long s32_t
+* \brief type definition of a signed 32 bits integer
+*/
+typedef long s32_t;
+/*
+* \typedef struct ... u64_t
+* \brief type definition of an usigned 64 bits integer
+*/
+typedef struct {
+ u32_t MSLW;
+ u32_t LSLW;
+} u64_t;
+/*
+* \typedef struct ... i64_t
+* \brief type definition of a signed 64 bits integer
+*/
+typedef struct {
+ s32_t MSLW;
+ u32_t LSLW;
+} s64_t;
+
+/**
+* \typedef u8_t *pu8_t
+* \brief type definition of pointer to an unsigned 8 bits integer
+*/
+typedef u8_t *pu8_t;
+/**
+* \typedef s8_t *ps8_t
+* \brief type definition of pointer to a signed 8 bits integer
+*/
+typedef s8_t *ps8_t;
+/**
+* \typedef u16_t *pu16_t
+* \brief type definition of pointer to an unsigned 16 bits integer
+*/
+typedef u16_t*pu16_t;
+/**
+* \typedef s16_t *ps16_t
+* \brief type definition of pointer to a signed 16 bits integer
+*/
+typedef s16_t*ps16_t;
+/**
+* \typedef u32_t *pu32_t
+* \brief type definition of pointer to an unsigned 32 bits integer
+*/
+typedef u32_t*pu32_t;
+/**
+* \typedef s32_t *ps32_t
+* \brief type definition of pointer to a signed 32 bits integer
+*/
+typedef s32_t*ps32_t;
+/**
+* \typedef u64_t *pu64_t
+* \brief type definition of pointer to an usigned 64 bits integer
+*/
+typedef u64_t*pu64_t;
+/**
+* \typedef s64_t *ps64_t
+* \brief type definition of pointer to a signed 64 bits integer
+*/
+typedef s64_t*ps64_t;
+
+
+/**
+* \typedef s32_t DRXFrequency_t
+* \brief type definition of frequency
+*/
+typedef s32_t DRXFrequ
Re: [PATCH 00/25] Add PCTV-80e Support to v4l
On Thu, Nov 10, 2011 at 6:31 PM, Patrick Dickey wrote: > These are the files required to support the Pinnacle PCTV-80e USB Tuner in > video-4-linux. The files were originally downloaded from > http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and modified to fix > compilation errors and also to move the driver files from the drx39xy > subdirectory to the frontends directory. Hi Patrick, It's great to see someone taking the time to work to get this upstream. A few comments though: None of these patches appear to have an Signed-off-by line. Since I'm the one vouching for the Micronas code being legitimately allowed to be submitted (in conformance with the Developer's Certificate of Origin), I am the one who needs to be the top signed-off-by (in fact, by arbitrarily breaking my tree into 25 patches, you effectively stripped off my authorship). Further, while it's commendable that you broke this into 25 patches, I think it's perfectly fine that it essentially be the two patches as found in my hg tree (plus the very minor change needed to get the code to compile against 3.x). In fact, I suspect you could probably take my two patches, apply them to the current 3.x tree, fix the two or three conflicts, and have something that is submittable to staging. It's not clear to me why you moved the driver files from frontends/drx39xxj to just frontends. I don't think anybody has ever complained about having a subdirectory if there is a large enough set of files. Did somebody ask you to do that and I didn't see the email? As you indicated, the code hasn't gone through any form of codingstyle cleanup, and as a result needs to go against the staging tree instead of the main tree. You should consult with Mauro on how to approach this problem, because currently you cannot do a demodulator driver against staging because of the dependency on the em28xx bridge which is already in stable (adding Mauro to the cc: to get his opinion). In short, it almost feels like you did *too much* work given you didn't make any material changes to the code itself as it's in my tree. I would suggest just submitting my two patches, and then on top of that you can submit a whole series of patches doing cleanups. And you should definitely review the following page on submitting patches if you haven't already: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] Add PCTV-80e Support to v4l
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/2011 07:45 PM, Devin Heitmueller wrote: > On Thu, Nov 10, 2011 at 6:31 PM, Patrick Dickey > wrote: >> These are the files required to support the Pinnacle PCTV-80e USB >> Tuner in video-4-linux. The files were originally downloaded >> from http://www.kernellabs.com/hg/~dheitmueller/v4l-dvb-80e and >> modified to fix compilation errors and also to move the driver >> files from the drx39xy subdirectory to the frontends directory. > > > Hi Patrick, > > It's great to see someone taking the time to work to get this > upstream. A few comments though: > > None of these patches appear to have an Signed-off-by line. Since > I'm the one vouching for the Micronas code being legitimately > allowed to be submitted (in conformance with the Developer's > Certificate of Origin), I am the one who needs to be the top > signed-off-by (in fact, by arbitrarily breaking my tree into 25 > patches, you effectively stripped off my authorship). > I thought the signed off lines were there. When I generated the patches, I used "git format-patch -s --subject-prefix='PATCH] [SIGNED-OFF' media-master " which I thought would add that in. However it must not have. I'll resubmit the patches with your name on the top and then mine below. It'll probably be tomorrow or Saturday before I get to that, though. > Further, while it's commendable that you broke this into 25 > patches, I think it's perfectly fine that it essentially be the two > patches as found in my hg tree (plus the very minor change needed > to get the code to compile against 3.x). In fact, I suspect you > could probably take my two patches, apply them to the current 3.x > tree, fix the two or three conflicts, and have something that is > submittable to staging. > The reason that I broke it up into 25 patches is because I did a test send to myself (as one patch for the entire driver) and it was almost 3MB in size. So, I decided to break it into a single patch for each file to reduce the size--and so each file could be dealt with separately. If that was the wrong thing to do, I'll fix it. > It's not clear to me why you moved the driver files from > frontends/drx39xxj to just frontends. I don't think anybody has > ever complained about having a subdirectory if there is a large > enough set of files. Did somebody ask you to do that and I didn't > see the email? > This was another unilateral decision. When I was trying to get this working on my computer, I found that make wouldn't even go into the subdirectory. Which meant that whenever I plugged the USB Tuner in, it would fail because it couldn't find the dvb_attach() method (from one of the driver files). After moving them from the subdirectory to frontends (and fixing the Makefile and Kconfig appropriately) everything compiled and loaded correctly. In the end, that was the only thing I found that worked. However, I can send them in the subdirectory also. > As you indicated, the code hasn't gone through any form of > codingstyle cleanup, and as a result needs to go against the > staging tree instead of the main tree. You should consult with > Mauro on how to approach this problem, because currently you cannot > do a demodulator driver against staging because of the dependency > on the em28xx bridge which is already in stable (adding Mauro to > the cc: to get his opinion). > This brings up a question for me. Most of the "trailing whitespace" errors aren't showing up in any of my editors (nano or meld to name two of them). And most of the trailing whitespace errors are in the comments. So are those really issues that will block the files from being submitted? Also, would they be happening because of the "DOS Line Ending" errors on most of the same lines? Also, I started to clean up the files tonight. Then I started thinking about what you told me about the as102 drivers, and thought I should submit them "as is" and then start the cleanup and submit those patches separately. Also that way others could help with some of the cleanup. I have to figure out if there's an easy way to convert all of the "DOS Line Endings" to the appropriate style, or if I'll have to do that manually (and whether my editor(s) caused this). For Mauro: I can either resubmit everything once it's cleaned up, go from here, start over and submit the original patches from Devin's tree, or whatever you think is best. > In short, it almost feels like you did *too much* work given you > didn't make any material changes to the code itself as it's in my > tree. I would suggest just submitting my two patches, and then on > top of that you can submit a whole series of patches doing > cleanups. One reason I did the extra work is because your tree had other files (the cx18 drivers for example) that didn't seem to be needed by the tuner. So, I cleaned them out (partially because I have two cards that use those drivers and didn't want to break those). I can review all of the files to
Re: [PATCH 00/25] Add PCTV-80e Support to v4l
On Thu, Nov 10, 2011 at 9:36 PM, Patrick Dickey wrote: > Also, I started to clean up the files tonight. Then I started thinking > about what you told me about the as102 drivers, and thought I should > submit them "as is" and then start the cleanup and submit those > patches separately. Also that way others could help with some of the > cleanup. I have to figure out if there's an easy way to convert all of > the "DOS Line Endings" to the appropriate style, or if I'll have to do > that manually (and whether my editor(s) caused this). Definitely you want the cleanup fixes to be in separate patches from the original patch with the driver. This is necessary because it makes it *much* easier to figure out if something got broken as a result of a cleanup patch (which isn't supposed to make any functional change). > One reason I did the extra work is because your tree had other files > (the cx18 drivers for example) that didn't seem to be needed by the > tuner. So, I cleaned them out (partially because I have two cards that > use those drivers and didn't want to break those). I can review all > of the files to make sure that I didn't miss any. And I can update > all of the files from your tree to the most current versions and > submit everything again. This shouldn't be the case (the two patches will have no interaction with any driver other than em28xx). I would suggest that instead of treating it as a tree, just suck the two patches off the top and apply them to your current tree one at a time, and fix any conflicts that pop up. http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/c119f08c4dd2 http://kernellabs.com/hg/~dheitmueller/v4l-dvb-80e/raw-rev/30c6512030ac If you just apply the patches instead of trying to hand-merge the two trees together, you will only get the delta and will likely just have to fix the 4 or five conflicts in em28xx.h and em28xx-cards.c (related to the fact that subsequent boards were added to the driver after my patch). That approach should only take a few minutes, given the conflicts are trivial to resolve. Good luck! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH: Query DVB frontend capabilities
On Fri, Nov 11, 2011 at 2:50 AM, Mauro Carvalho Chehab
wrote:
> Em 10-11-2011 13:30, Manu Abraham escreveu:
>> Hi Andreas,
>>
>> On Thu, Nov 10, 2011 at 8:14 PM, Andreas Oberritter wrote:
>>> Hello Manu,
>>>
>>> please see my comments below:
>>>
>>> On 10.11.2011 15:18, Manu Abraham wrote:
Hi,
Currently, for a multi standard frontend it is assumed that it just
has a single standard capability. This is fine in some cases, but
makes things hard when there are incompatible standards in conjuction.
Eg: DVB-S can be seen as a subset of DVB-S2, but the same doesn't hold
the same for DSS. This is not specific to any driver as it is, but a
generic issue. This was handled correctly in the multiproto tree,
while such functionality is missing from the v5 API update.
http://www.linuxtv.org/pipermail/vdr/2008-November/018417.html
Later on a FE_CAN_2G_MODULATION was added as a hack to workaround this
issue in the v5 API, but that hack is incapable of addressing the
issue, as it can be used to simply distinguish between DVB-S and
DVB-S2 alone, or another x vs X2 modulation. If there are more
systems, then you have a potential issue.
>
> For sure something like that is needed.
>
> DVB TURBO is another example where the FE_CAN_2G_MODULATION approach doesn't
> properly address.
>
It is similar to a DVB-S system with a different modulation and FEC.
It was specifically designed to make it proprietary. Nothing wrong
with it as it is now.
In addition to the patch, for illustrative purposes the stb0899 driver
is depicted providing the said capability information.
An application needs to query the device capabilities before
requesting an operation from the device.
If people don't have any objections, Probably other drivers can be
adapted similarly. In fact the change is quite simple.
Comments ?
Regards,
Manu
query_frontend_capabilities.diff
diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Wed Nov 09 19:52:36
2011 +0530
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Nov 10 13:51:35
2011 +0530
@@ -973,6 +973,8 @@
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+
+ _DTV_CMD(DTV_DELIVERY_CAPS, 0, 0),
};
static void dtv_property_dump(struct dtv_property *tvp)
@@ -1226,7 +1228,18 @@
c = &cdetected;
}
+ dprintk("%s\n", __func__);
+
switch(tvp->cmd) {
+ case DTV_DELIVERY_CAPS:
+ if (fe->ops.delivery_caps) {
+ r = fe->ops.delivery_caps(fe, tvp);
+ if (r < 0)
+ return r;
+ else
+ goto done;
>>>
>>> What's the reason for introducing that label and goto?
>>
>>
>> The idea was to avoid using get_property callback being called.
>
> Nothing warrants that the only property will be DTV_DELIVERY_CAPS.
> calling get_property callback will likely work better.
It is indeed called within a case switch:
+ case DTV_DELIVERY_CAPS:
+ if (fe->ops.delivery_caps) {
+ r = fe->ops.delivery_caps(fe, tvp);
So, It does warrant that delivery caps are filled only with the
DTV_DELIVERY_CAPS, just like any other command, no difference in
there. But as I stated earlier, using get_property is just as fine.
>>
>>
>>
>>>
+ }
+ break;
case DTV_FREQUENCY:
tvp->u.data = c->frequency;
break;
@@ -1350,7 +1363,7 @@
if (r < 0)
return r;
}
-
+done:
dtv_property_dump(tvp);
return 0;
diff -r b6eb04718aa9 linux/drivers/media/dvb/dvb-core/dvb_frontend.h
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Wed Nov 09 19:52:36
2011 +0530
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.h Thu Nov 10 13:51:35
2011 +0530
@@ -305,6 +305,8 @@
int (*set_property)(struct dvb_frontend* fe, struct dtv_property*
tvp);
int (*get_property)(struct dvb_frontend* fe, struct dtv_property*
tvp);
+
+ int (*delivery_caps)(struct dvb_frontend *fe, struct dtv_property
*tvp);
};
>>>
>>> I don't think that another function pointer is required. Drivers can
>>> implement this in their get_property callback. The core could provide a
>>> default implementation, returning values derived from fe->ops.info.type
>>> and the 2G flag.
>>
>>
>> I see your point. While trying to address the issue I had originally
>> get_property being used. One Issue t
