Region of interest and window controls in UVC
Has anyone been looking into CT_DIGITAL_WINDOW_CONTROL or CT_REGION_OF_INTEREST_CONTROL support? Just starting to look at the uvc 1.5 spec and seeing these features. Sean -- 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 v2 0/5] Common Display Framework
Hi Rahul, On Wednesday 09 January 2013 13:53:30 Rahul Sharma wrote: > Hi Laurent, > > CDF will also be helpful in supporting Panels with integrated audio > (HDMI/DP) if we can add audio related control operations to > display_entity_control_ops. Video controls will be called by crtc in DRM/V4L > and audio controls from Alsa. I knew that would come up at some point :-) I agree with you that adding audio support would be a very nice improvement, and I'm totally open to that, but I will concentrate on video, at least to start with. The first reason is that I'm not familiar enough with ALSA, and the second that there's only 24h per day :-) Please feel free, of course, to submit a proposal for audio support. > Secondly, if I need to support get_modes operation in hdmi/dp panel, I need > to implement edid parser inside the panel driver. It will be meaningful to > add get_edid control operation for hdmi/dp. Even if EDID data is parsed in the panel driver, raw EDID will still need to be exported, so a get_edid control operation (or something similar) is definitely needed. There's no disagreement on this, I just haven't included that operation yet because my test hardware is purely panel-based. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Marcus, On Tuesday 08 January 2013 11:12:26 Marcus Lorentzon wrote: [snip] > I also looked at the video source in Tomi's git tree > (http://gitorious.org/linux-omap-dss2/linux/blobs/work/dss-dev-model-cdf/inc > lude/video/display.h). I think I would prefer a single "setup" op taking a > "struct dsi_config" as argument. Then each DSI formatter/encoder driver > could decide best way to set that up. We have something similar at > http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f=inc > lude/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD#l118 A single setup function indeed seems easier, but I don't have enough experience with DSI to have a strong opinion on that. We'll have to compare implementations if there's a disagreement on this. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 0/5] Common Display Framework
Hi Marcus,
On Tuesday 08 January 2013 18:08:19 Marcus Lorentzon wrote:
> On 01/08/2013 05:36 PM, Tomasz Figa wrote:
> > On Tuesday 08 of January 2013 11:12:26 Marcus Lorentzon wrote:
[snip]
> >> FYI,
> >> here is STE "DSI API":
> >> http://www.igloocommunity.org/gitweb/?p=kernel/igloo-kernel.git;a=blob;f
> >> =include/video/mcde.h;h=499ce5cfecc9ad77593e761cdcc1624502f28432;hb=HEAD
> >> #l361
Thank you.
> >> But it is not perfect. After a couple of products we realized that most
> >> panel drivers want an easy way to send a bunch of init commands in one
> >> go. So I think it should be an op for sending an array of commands at
> >> once. Something like
> >>
> >> struct dsi_cmd {
> >> enum mipi_pkt_type type; /* MIPI DSI, DCS, SetPacketLen, ... */
> >> u8 cmd;
> >> int dataLen;
> >> u8 *data;
> >> }
> >>
> >> struct dsi_ops {
> >> int dsi_write(source, int num_cmds, struct dsi_cmd *cmds);
> >> ...
> >> }
Do you have DSI IP(s) that can handle a list of commands ? Or would all DSI
transmitter drivers need to iterate over the commands manually ? In the later
case a lower-level API might be easier to implement in DSI transmitter
drivers. Helper functions could provide the higher-level API you proposed.
> > Yes, this should be flexible enough to cover most of (or even whole) DSI
> > specification.
> >
> > However I'm not sure whether the dsi_write name would be appropriate,
> > since DSI packet types include also read and special transactions. So,
> > according to DSI terminology, maybe dsi_transaction would be better?
Or dsi_transfer or dsi_xfer ? Does the DSI bus have a concept of transactions
?
> I think read should still be separate. At least on my HW read and write
> are quite different. But all "transactions" are very much the same in HW
> setup. The ... was dsi_write etc ;) Like set_max_packet_size should
> maybe be an ops. Since only the implementer of the "video source" will
> know what the max read return packet size for that DSI IP is. The panels
> don't know that. Maybe another ops to retrieve some info about the caps
> of the video source would help that. Then a helper could call that and
> then the dsi_write one.
If panels (or helper functions) need information about the DSI transmitter
capabilities, sure, we can add an op.
> >> And I think I still prefer the dsi_bus in favor of the abstract video
> >> source. It just looks like a home made bus with bus-ops ... can't you do
> >> something similar using the normal driver framework? enable/disable
> >> looks like suspend/resume, register/unregister_vid_src is like
> >> bus_(un)register_device, ... the video source anyway seems unattached
> >> to the panel stuff with the find_video_source call.
The Linux driver framework is based on control busses. DSI usually handles
both control and video transfer, but the control and data busses can also be
separate (think DPI + SPI/I2C for instance). In that case the panel will be a
child of its control bus master, and will need a separate interface to access
video data operations. As a separate video interface is thus needed, I think
we should use it for DSI as well.
My initial proposal included a DBI bus (as I don't have any DSI hardware - DBI
and DSI can be used interchangeably in this discussions, they both share the
caracteristic of having a common control + data bus), and panels were children
of the DBI bus master. The DBI bus API was only used for control, not for data
transfers. Tomi then removed the DBI bus and moved the control operations to
the video source, turning the DBI panels into platform devices. I still favor
my initial approach, but I can agree to drop the DBI bus if there's a
consensus on that. Video bus operations will be separate in any case.
> > DSI needs specific power management. It's necessary to power up the panel
> > first to make it wait for Tinit event and then enable DSI master to
> > trigger such event. Only then rest of panel initialization can be
> > completed.
>
> I know, we have a very complex sequence for our HDMI encoder which uses
> sort of continuous DSI cmmand mode. And power/clock on sequences are
> tricky to get right in our current "CDF" API (mcde_display). But I fail
> to see how the current video source API is different from just using the
> bus/device APIs.
As mentioned above, the video source API handles video transfers, while the
bus/device API handles control transfers. Operations such as "start the video
stream" will thus be video source APIs. Operations such as "enable the DSI
master", used to trigger the Tinit event (whatever that is :-)) at power up
time would probably be DSI bus operations.
> > Also, as discussed in previous posts, some panels might use DSI only for
> > video data and another interface (I2C, SPI) for control data. In such case
> > it would be impossible to represent such device in a reasonable way using
> > current driver model.
>
> I understand that you need to get h
[PATCH 8/8] saa7134: v4l2-compliance: clear reserved part of VBI structure
Make saa7134 driver more V4L2 compliant: clear reserved space of VBI structure to make sure no garbage is left there Signed-off-by: Ondrej Zary --- drivers/media/pci/saa7134/saa7134-video.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/pci/saa7134/saa7134-video.c b/drivers/media/pci/saa7134/saa7134-video.c index 8b4..0b23fc8 100644 --- a/drivers/media/pci/saa7134/saa7134-video.c +++ b/drivers/media/pci/saa7134/saa7134-video.c @@ -1552,6 +1552,7 @@ static int saa7134_try_get_set_fmt_vbi_cap(struct file *file, void *priv, struct saa7134_dev *dev = fh->dev; struct saa7134_tvnorm *norm = dev->tvnorm; + memset(&f->fmt.vbi.reserved, 0, sizeof(f->fmt.vbi.reserved)); f->fmt.vbi.sampling_rate = 675 * 4; f->fmt.vbi.samples_per_line = 2048 /* VBI_LINE_LENGTH */; f->fmt.vbi.sample_format = V4L2_PIX_FMT_GREY; -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] saa7134: v4l2-compliance: remove bogus g_parm
Make saa7134 driver more V4L2 compliant: remove empty g_parm function
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index f7e6d5c..8b4 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2237,12 +2237,6 @@ static int saa7134_streamoff(struct file *file, void
*priv,
return 0;
}
-static int saa7134_g_parm(struct file *file, void *fh,
- struct v4l2_streamparm *parm)
-{
- return 0;
-}
-
#ifdef CONFIG_VIDEO_ADV_DEBUG
static int vidioc_g_register (struct file *file, void *priv,
struct v4l2_dbg_register *reg)
@@ -2395,7 +2389,6 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_g_fbuf = saa7134_g_fbuf,
.vidioc_s_fbuf = saa7134_s_fbuf,
.vidioc_overlay = saa7134_overlay,
- .vidioc_g_parm = saa7134_g_parm,
.vidioc_g_frequency = saa7134_g_frequency,
.vidioc_s_frequency = saa7134_s_frequency,
#ifdef CONFIG_VIDEO_ADV_DEBUG
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] saa7134: v4l2-compliance: remove bogus audio input support
Make saa7134 driver more V4L2 compliant: remove empty g_audio and s_audio
functions and don't set audioset in enum_input
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c | 30 -
1 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 3274994..f7e6d5c 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -1750,7 +1750,6 @@ static int saa7134_enum_input(struct file *file, void
*priv,
strcpy(i->name, card_in(dev, n).name);
if (card_in(dev, n).tv)
i->type = V4L2_INPUT_TYPE_TUNER;
- i->audioset = 1;
if (n == dev->ctl_input) {
int v1 = saa_readb(SAA7134_STATUS_VIDEO1);
int v2 = saa_readb(SAA7134_STATUS_VIDEO2);
@@ -2084,17 +2083,6 @@ static int saa7134_s_frequency(struct file *file, void
*priv,
return 0;
}
-static int saa7134_g_audio(struct file *file, void *priv, struct v4l2_audio *a)
-{
- strcpy(a->name, "audio");
- return 0;
-}
-
-static int saa7134_s_audio(struct file *file, void *priv, const struct
v4l2_audio *a)
-{
- return 0;
-}
-
static int saa7134_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
@@ -2335,20 +2323,6 @@ static int radio_g_input(struct file *filp, void *priv,
unsigned int *i)
return 0;
}
-static int radio_g_audio(struct file *file, void *priv,
- struct v4l2_audio *a)
-{
- memset(a, 0, sizeof(*a));
- strcpy(a->name, "Radio");
- return 0;
-}
-
-static int radio_s_audio(struct file *file, void *priv,
- const struct v4l2_audio *a)
-{
- return 0;
-}
-
static int radio_s_input(struct file *filp, void *priv, unsigned int i)
{
return 0;
@@ -2399,8 +2373,6 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_g_fmt_vbi_cap = saa7134_try_get_set_fmt_vbi_cap,
.vidioc_try_fmt_vbi_cap = saa7134_try_get_set_fmt_vbi_cap,
.vidioc_s_fmt_vbi_cap = saa7134_try_get_set_fmt_vbi_cap,
- .vidioc_g_audio = saa7134_g_audio,
- .vidioc_s_audio = saa7134_s_audio,
.vidioc_cropcap = saa7134_cropcap,
.vidioc_reqbufs = saa7134_reqbufs,
.vidioc_querybuf= saa7134_querybuf,
@@ -2445,9 +2417,7 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_querycap= saa7134_querycap,
.vidioc_g_tuner = radio_g_tuner,
.vidioc_enum_input = radio_enum_input,
- .vidioc_g_audio = radio_g_audio,
.vidioc_s_tuner = radio_s_tuner,
- .vidioc_s_audio = radio_s_audio,
.vidioc_s_input = radio_s_input,
.vidioc_s_std = radio_s_std,
.vidioc_queryctrl = radio_queryctrl,
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] saa7134: v4l2-compliance: fix g_tuner/s_tuner
Make saa7134 driver more V4L2 compliant: return real frequency range in
g_tuner and fail in s_tuner for non-zero tuner
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index c8d3180..3274994 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2014,11 +2014,11 @@ static int saa7134_g_tuner(struct file *file, void
*priv,
if (NULL != card_in(dev, n).name) {
strcpy(t->name, "Television");
t->type = V4L2_TUNER_ANALOG_TV;
+ saa_call_all(dev, tuner, g_tuner, t);
t->capability = V4L2_TUNER_CAP_NORM |
V4L2_TUNER_CAP_STEREO |
V4L2_TUNER_CAP_LANG1 |
V4L2_TUNER_CAP_LANG2;
- t->rangehigh = 0xUL;
t->rxsubchans = saa7134_tvaudio_getstereo(dev);
t->audmode = saa7134_tvaudio_rx2mode(t->rxsubchans);
}
@@ -2034,6 +2034,9 @@ static int saa7134_s_tuner(struct file *file, void *priv,
struct saa7134_dev *dev = fh->dev;
int rx, mode;
+ if (0 != t->index)
+ return -EINVAL;
+
mode = dev->thread.mode;
if (UNSET == mode) {
rx = saa7134_tvaudio_getstereo(dev);
--
Ondrej Zary
--
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/8] saa7134: v4l2-compliance: return real frequency
Make saa7134 driver more V4L2 compliant: don't cache frequency in
s_frequency/g_frequency but return real one instead
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c |6 --
drivers/media/pci/saa7134/saa7134.h |1 -
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index cd4959e..c8d3180 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2051,8 +2051,11 @@ static int saa7134_g_frequency(struct file *file, void
*priv,
struct saa7134_fh *fh = priv;
struct saa7134_dev *dev = fh->dev;
+ if (0 != f->tuner)
+ return -EINVAL;
+
f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
- f->frequency = dev->ctl_freq;
+ saa_call_all(dev, tuner, g_frequency, f);
return 0;
}
@@ -2070,7 +2073,6 @@ static int saa7134_s_frequency(struct file *file, void
*priv,
if (1 == fh->radio && V4L2_TUNER_RADIO != f->type)
return -EINVAL;
mutex_lock(&dev->lock);
- dev->ctl_freq = f->frequency;
saa_call_all(dev, tuner, s_frequency, f);
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index 2ffe069..d0ee05e 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -604,7 +604,6 @@ struct saa7134_dev {
intctl_contrast;
intctl_hue;
intctl_saturation;
- intctl_freq;
intctl_mute; /* audio */
intctl_volume;
intctl_invert; /* private */
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] saa7134: v4l2-compliance: use v4l2_fh to fix priority handling
Make saa7134 driver more V4L2 compliant: remove broken priority handling
and use v4l2_fh instead
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-core.c |3 +-
drivers/media/pci/saa7134/saa7134-video.c | 61 +++-
drivers/media/pci/saa7134/saa7134.h |4 +-
3 files changed, 10 insertions(+), 58 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-core.c
b/drivers/media/pci/saa7134/saa7134-core.c
index 8976d0e..ba08bd6 100644
--- a/drivers/media/pci/saa7134/saa7134-core.c
+++ b/drivers/media/pci/saa7134/saa7134-core.c
@@ -805,6 +805,7 @@ static struct video_device *vdev_init(struct saa7134_dev
*dev,
vfd->debug = video_debug;
snprintf(vfd->name, sizeof(vfd->name), "%s %s (%s)",
dev->name, type, saa7134_boards[dev->board].name);
+ set_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
video_set_drvdata(vfd, dev);
return vfd;
}
@@ -1028,8 +1029,6 @@ static int __devinit saa7134_initdev(struct pci_dev
*pci_dev,
}
}
- v4l2_prio_init(&dev->prio);
-
mutex_lock(&saa7134_devlist_lock);
list_for_each_entry(mops, &mops_list, next)
mpeg_ops_attach(mops, dev);
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 62b6f6c..cd4959e 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -1176,14 +1176,6 @@ int saa7134_s_ctrl_internal(struct saa7134_dev *dev,
struct saa7134_fh *fh, str
int restart_overlay = 0;
int err;
- /* When called from the empress code fh == NULL.
- That needs to be fixed somehow, but for now this is
- good enough. */
- if (fh) {
- err = v4l2_prio_check(&dev->prio, fh->prio);
- if (0 != err)
- return err;
- }
err = -EINVAL;
mutex_lock(&dev->lock);
@@ -1352,6 +1344,7 @@ static int video_open(struct file *file)
if (NULL == fh)
return -ENOMEM;
+ v4l2_fh_init(&fh->fh, vdev);
file->private_data = fh;
fh->dev = dev;
fh->radio= radio;
@@ -1359,7 +1352,6 @@ static int video_open(struct file *file)
fh->fmt = format_by_fourcc(V4L2_PIX_FMT_BGR24);
fh->width= 720;
fh->height = 576;
- v4l2_prio_open(&dev->prio, &fh->prio);
videobuf_queue_sg_init(&fh->cap, &video_qops,
&dev->pci->dev, &dev->slock,
@@ -1384,6 +1376,8 @@ static int video_open(struct file *file)
/* switch to video/vbi mode */
video_mux(dev,dev->ctl_input);
}
+ v4l2_fh_add(&fh->fh);
+
return 0;
}
@@ -1504,7 +1498,8 @@ static int video_release(struct file *file)
saa7134_pgtable_free(dev->pci,&fh->pt_cap);
saa7134_pgtable_free(dev->pci,&fh->pt_vbi);
- v4l2_prio_close(&dev->prio, fh->prio);
+ v4l2_fh_del(&fh->fh);
+ v4l2_fh_exit(&fh->fh);
file->private_data = NULL;
kfree(fh);
return 0;
@@ -1784,11 +1779,6 @@ static int saa7134_s_input(struct file *file, void
*priv, unsigned int i)
{
struct saa7134_fh *fh = priv;
struct saa7134_dev *dev = fh->dev;
- int err;
-
- err = v4l2_prio_check(&dev->prio, fh->prio);
- if (0 != err)
- return err;
if (i >= SAA7134_INPUT_MAX)
return -EINVAL;
@@ -1856,16 +1846,8 @@ int saa7134_s_std_internal(struct saa7134_dev *dev,
struct saa7134_fh *fh, v4l2_
unsigned long flags;
unsigned int i;
v4l2_std_id fixup;
- int err;
- /* When called from the empress code fh == NULL.
- That needs to be fixed somehow, but for now this is
- good enough. */
- if (fh) {
- err = v4l2_prio_check(&dev->prio, fh->prio);
- if (0 != err)
- return err;
- } else if (res_locked(dev, RESOURCE_OVERLAY)) {
+ if (!fh && res_locked(dev, RESOURCE_OVERLAY)) {
/* Don't change the std from the mpeg device
if overlay is active. */
return -EBUSY;
@@ -2050,11 +2032,7 @@ static int saa7134_s_tuner(struct file *file, void *priv,
{
struct saa7134_fh *fh = priv;
struct saa7134_dev *dev = fh->dev;
- int rx, mode, err;
-
- err = v4l2_prio_check(&dev->prio, fh->prio);
- if (0 != err)
- return err;
+ int rx, mode;
mode = dev->thread.mode;
if (UNSET == mode) {
@@ -2084,11 +2062,6 @@ static int saa7134_s_frequency(struct file *file, void
*priv,
{
struct saa7134_fh *fh = priv;
struct saa7134_dev *dev = fh->dev;
- int err;
-
- err = v4l2_prio_check(&dev->prio, fh->prio);
- if (0 != err)
- return err;
if (0 != f->tuner)
return -EINVAL
[PATCH 2/8] saa7134: v4l2-compliance: don't report invalid audio modes for radio
Make saa7134 driver more V4L2 compliant: filter audio modes that came from
tuner - keep only MONO/STEREO in radio mode
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index c8ed685..62b6f6c 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2336,6 +2336,7 @@ static int radio_g_tuner(struct file *file, void *priv,
t->type = V4L2_TUNER_RADIO;
saa_call_all(dev, tuner, g_tuner, t);
+ t->audmode &= V4L2_TUNER_MODE_MONO | V4L2_TUNER_MODE_STEREO;
if (dev->input->amux == TV) {
t->signal = 0xf800 - ((saa_readb(0x581) & 0x1f) << 11);
t->rxsubchans = (saa_readb(0x529) & 0x08) ?
--
Ondrej Zary
--
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/8] saa7134: v4l2-compliance: implement V4L2_CAP_DEVICE_CAPS
Make saa7134 driver more V4L2 compliant: implement V4L2_CAP_DEVICE_CAPS support
and fix all capabilities problems reported by v4l2-compliance.
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-video.c | 58 +
1 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 3abf527..c8ed685 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -1805,6 +1805,8 @@ static int saa7134_querycap(struct file *file, void
*priv,
{
struct saa7134_fh *fh = priv;
struct saa7134_dev *dev = fh->dev;
+ struct video_device *vdev = video_devdata(file);
+ u32 radio_caps, video_caps, vbi_caps;
unsigned int tuner_type = dev->tuner_type;
@@ -1812,19 +1814,40 @@ static int saa7134_querycap(struct file *file, void
*priv,
strlcpy(cap->card, saa7134_boards[dev->board].name,
sizeof(cap->card));
sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
- cap->capabilities =
- V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_VBI_CAPTURE |
- V4L2_CAP_READWRITE |
- V4L2_CAP_STREAMING |
- V4L2_CAP_TUNER;
+
+ cap->device_caps = V4L2_CAP_READWRITE | V4L2_CAP_STREAMING;
+ if ((tuner_type != TUNER_ABSENT) && (tuner_type != UNSET))
+ cap->device_caps |= V4L2_CAP_TUNER;
+
+ radio_caps = V4L2_CAP_RADIO;
if (dev->has_rds)
- cap->capabilities |= V4L2_CAP_RDS_CAPTURE;
+ radio_caps |= V4L2_CAP_RDS_CAPTURE;
+
+ video_caps = V4L2_CAP_VIDEO_CAPTURE;
if (saa7134_no_overlay <= 0)
- cap->capabilities |= V4L2_CAP_VIDEO_OVERLAY;
+ video_caps |= V4L2_CAP_VIDEO_OVERLAY;
+
+ vbi_caps = V4L2_CAP_VBI_CAPTURE;
+
+ switch (vdev->vfl_type) {
+ case VFL_TYPE_RADIO:
+ cap->device_caps |= radio_caps;
+ break;
+ case VFL_TYPE_GRABBER:
+ cap->device_caps |= video_caps;
+ break;
+ case VFL_TYPE_VBI:
+ cap->device_caps |= vbi_caps;
+ break;
+ }
+ cap->capabilities = radio_caps | video_caps | vbi_caps |
+ cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+ if (vdev->vfl_type == VFL_TYPE_RADIO) {
+ cap->device_caps &= ~V4L2_CAP_STREAMING;
+ if (!dev->has_rds)
+ cap->device_caps &= ~V4L2_CAP_READWRITE;
+ }
- if ((tuner_type == TUNER_ABSENT) || (tuner_type == UNSET))
- cap->capabilities &= ~V4L2_CAP_TUNER;
return 0;
}
@@ -2299,19 +2322,6 @@ static int vidioc_s_register (struct file *file, void
*priv,
}
#endif
-static int radio_querycap(struct file *file, void *priv,
- struct v4l2_capability *cap)
-{
- struct saa7134_fh *fh = file->private_data;
- struct saa7134_dev *dev = fh->dev;
-
- strcpy(cap->driver, "saa7134");
- strlcpy(cap->card, saa7134_boards[dev->board].name, sizeof(cap->card));
- sprintf(cap->bus_info, "PCI:%s", pci_name(dev->pci));
- cap->capabilities = V4L2_CAP_TUNER;
- return 0;
-}
-
static int radio_g_tuner(struct file *file, void *priv,
struct v4l2_tuner *t)
{
@@ -2473,7 +2483,7 @@ static const struct v4l2_file_operations radio_fops = {
};
static const struct v4l2_ioctl_ops radio_ioctl_ops = {
- .vidioc_querycap= radio_querycap,
+ .vidioc_querycap= saa7134_querycap,
.vidioc_g_tuner = radio_g_tuner,
.vidioc_enum_input = radio_enum_input,
.vidioc_g_audio = radio_g_audio,
--
Ondrej Zary
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] saa7134: improve v4l2-compliance
This patch series improves v4l2-compliance of saa7134 driver. This includes only easy-to-fix things. More work is needed to fix the other problems. -- Ondrej Zary -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC v2] media: tvp514x: add OF support
Hi Prabhakar,
On 01/29/2013 02:07 PM, Prabhakar Lad wrote:
[...]
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
new file mode 100644
index 000..55d3ffd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
@@ -0,0 +1,38 @@
+* Texas Instruments TVP514x video decoder
+
+The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
+digital video decoder that digitizes and decodes all popular baseband analog
+video formats into digital video component. The tvp514x decoder supports
analog-
+to-digital (A/D) conversion of component RGB and YPbPr signals as well as A/D
+conversion and decoding of NTSC, PAL and SECAM composite and S-video into
+component YCbCr.
+
+Required Properties :
+- compatible: Must be "ti,tvp514x-decoder"
There are no significant differences among TVP514* devices as listed above,
you would like to handle above ?
I'm just wondering if you don't need ,for instance, two separate compatible
properties, e.g. "ti,tvp5146-decoder" and "ti,tvp5147-decoder" ?
+- hsync-active: HSYNC Polarity configuration for current interface.
+- vsync-active: VSYNC Polarity configuration for current interface.
+- data-active: Clock polarity of the current interface.
I guess you mean "pclk-sample: Clock polarity..." ?
+
+Example:
+
+i2c0@1c22000 {
+ ...
+ ...
+
+ tvp514x@5c {
+ compatible = "ti,tvp514x-decoder";
+ reg =<0x5c>;
+
+ port {
+ tvp514x_1: endpoint {
+ /* Active high (Defaults to 0) */
+ hsync-active =<1>;
+ /* Active high (Defaults to 0) */
+ hsync-active =<1>;
Should it be vsync-active ?
+ /* Active low (Defaults to 0) */
+ data-active =<0>;
and this pclk-sample ?
+ };
+ };
+ };
+ ...
+};
diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
index a4f0a70..24ce759 100644
--- a/drivers/media/i2c/tvp514x.c
+++ b/drivers/media/i2c/tvp514x.c
@@ -12,6 +12,7 @@
* Hardik Shah
* Manjunath Hadli
* Karicheri Muralidharan
+ * Prabhakar Lad
*
* This package is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -33,7 +34,9 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -930,6 +933,58 @@ static struct tvp514x_decoder tvp514x_dev = {
};
+#if defined(CONFIG_OF)
+static const struct of_device_id tvp514x_of_match[] = {
+ {.compatible = "ti,tvp514x-decoder", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, tvp514x_of_match);
+
+static struct tvp514x_platform_data
+ *tvp514x_get_pdata(struct i2c_client *client)
+{
+ if (!client->dev.platform_data&& client->dev.of_node) {
+ struct tvp514x_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *endpoint;
+
+ pdata = devm_kzalloc(&client->dev,
+ sizeof(struct tvp514x_platform_data),
+ GFP_KERNEL);
+ client->dev.platform_data = pdata;
Do you really need to set client->dev.platform_data this way ?
What about passing struct tvp514x_decoder pointer to this function
and initializing struct tvp514x_decoder::pdata instead ?
+ if (!pdata)
+ return NULL;
+
+ endpoint = of_get_child_by_name(client->dev.of_node, "port");
+ if (endpoint)
+ endpoint = of_get_child_by_name(endpoint, "endpoint");
I think you could replace these two calls above with
endpoint = v4l2_of_get_next_endpoint(client->dev.of_node);
Now I see I should have modified this function to ensure it works also when
'port' nodes are grouped in a 'ports' node.
+ if (!endpoint) {
+ v4l2_info(client, "Using default data!!\n");
+ } else {
+ v4l2_of_parse_parallel_bus(endpoint,&bus_cfg);
+
+ if (bus_cfg.mbus_flags& V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pdata->hs_polarity = 1;
+ if (bus_cfg.mbus_flags& V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pdata->vs_polarity = 1;
+ if (bus_cfg.mbus_flags& V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pdata->clk_polarity = 1;
+ }
+ }
+
+ return client->dev.platform_data;
+}
+#else
+#define tvp514x_of_match NULL
+
+static struct tvp514x_platform_data
+ *tvp514x_get_pdata(struct i2c_client *client)
+{
+ return client->dev.platform_data;
+}
+#endif
+
/**
* tvp514x_
Re: [PATCH 1/1] v4l: Document timestamp behaviour to correspond to reality
Hi Hans, Thanks for your comments. On Mon, Jan 28, 2013 at 10:55:14AM +0100, Hans Verkuil wrote: > On Fri January 25 2013 19:03:29 Sakari Ailus wrote: > > Document that monotonic timestamps are taken after the corresponding frame > > has been received, not when the reception has begun. This corresponds to the > > reality of current drivers: the timestamp is naturally taken when the > > hardware triggers an interrupt to tell the driver to handle the received > > frame. > > > > Signed-off-by: Sakari Ailus > > --- > > Documentation/DocBook/media/v4l/io.xml | 27 ++- > > 1 files changed, 14 insertions(+), 13 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/io.xml > > b/Documentation/DocBook/media/v4l/io.xml > > index 2c4646d..3b8bf61 100644 > > --- a/Documentation/DocBook/media/v4l/io.xml > > +++ b/Documentation/DocBook/media/v4l/io.xml > > @@ -654,19 +654,20 @@ plane, are stored in struct > > v4l2_plane instead. > > In that case, struct v4l2_buffer contains an > > array of > > plane structures. > > > > - Nominally timestamps refer to the first data byte transmitted. > > -In practice however the wide range of hardware covered by the V4L2 API > > -limits timestamp accuracy. Often an interrupt routine will > > -sample the system clock shortly after the field or frame was stored > > -completely in memory. So applications must expect a constant > > -difference up to one field or frame period plus a small (few scan > > -lines) random error. The delay and error can be much > > -larger due to compression or transmission over an external bus when > > -the frames are not properly stamped by the sender. This is frequently > > -the case with USB cameras. Here timestamps refer to the instant the > > -field or frame was received by the driver, not the capture time. These > > -devices identify by not enumerating any video standards, see > -linkend="standard" />. > > + On timestamp types that are sampled from the system clock > > +(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is > > +taken after the complete frame has been received. > > add: " (or transmitted for video output devices)" Ack. > > For other kinds of > > +timestamps this may vary depending on the driver. In practice however the > > +wide range of hardware covered by the V4L2 API limits timestamp accuracy. > > +Often an interrupt routine will sample the system clock shortly after the > > +field or frame was stored completely in memory. So applications must expect > > +a constant difference up to one field or frame period plus a small (few > > scan > > +lines) random error. The delay and error can be much larger due to > > +compression or transmission over an external bus when the frames are not > > +properly stamped by the sender. This is frequently the case with USB > > +cameras. Here timestamps refer to the instant the field or frame was > > +received by the driver, not the capture time. These devices identify by not > > +enumerating any video standards, see . > > I'm not sure if there is any reliable way at the moment to identify such > devices. At least in the past (that may not be true anymore) some webcam > drivers *did* implement S_STD. via-camera, for instance, does. I can add removal to the patchset. > There are also devices where one input is a webcam and another input is a > composite (TV) input (the vino driver for old SGIs is one of those). True. One may well connect an TV tuner to the parallel interface of the OMAP 3 ISP, and a camera sensor to the CSI-2 receiver. > The best method I know is to check the capabilities field returned by > ENUMINPUT for the current input and see if any of the STD/DV_TIMINGS/PRESETS > caps are set. If not, then it is a camera. Of course, this assumes there are > no more webcam drivers that use S_STD. I wonder if timestamp jitter is a real issue. These devices, I presume, have no large buffers where the data could be stored to cause jitter without losing frames. > I would much prefer to add a proper webcam input type to ENUMINPUT, but I'm > afraid that would break apps. How much jitter is enough so that we should say the timestamps are unstable? > > > >Similar limitations apply to output timestamps. Typically > > the video hardware locks to a clock controlling the video timing, the > > > > This paragraph on output timestamps can be deleted IMHO. Thanks for reminding me. I think it doesn't deserve to be put into a separate patch. > And the paragraph after that can probably be removed completely as well > that we no longer use gettimeofday: > > "Apart of limitations of the video device and natural inaccuracies of > all clocks, it should be noted system time itself is not perfectly stable. > It can be affected by power saving cycles, warped to insert leap seconds, > or even turned back or forth by the system administrator affecting long > term measurements." > > Ditto for the footnote at the end of that
Re: RFC: add parameters to V4L controls
Hi Sylwester, On Thursday 31 January 2013 18:17:42 Sylwester Nawrocki wrote: > On 01/07/2013 01:10 PM, Hans Verkuil wrote: > > On Mon January 7 2013 11:46:38 Andrzej Hajda wrote: > [...] > > >> Currently V4L2 controls can have only single value (of type int, int64, > >> string). Some hardware controls require more than single int parameter, > >> for example to set auto-focus (AF) rectangle four coordinates should be > >> passed, to set auto-focus spot two coordinates should be passed. > >> > >> Current solution > >> > >> In case of AF rectangle we can reuse selection API as in "[PATCH RFC > >> 0/2] V4L: Add auto focus area control and selection" post. > >> Pros: > >> - reuse existing API, > >> Cons: > >> - two IOCTL's to perform one action, > >> - non-atomic operation, > >> - fits well only for rectangles and spots (but with unused fields width, > >> height), in case of other parameters we should find a different way. > >> > >> Proposed solution > >> > >> The solution takes an advantage of the fact VIDIOC_(G/S/TRY)_EXT_CTRLS > >> ioctls can be called with multiple controls per call. > >> > >> I will present it using AF area control example. > >> > >> There could be added four pseudo-controls, lets call them for short: > >> LEFT, TOP, WIDTH, HEIGHT. Those controls could be passed together with > >> V4L2_AUTO_FOCUS_AREA_RECTANGLE control in one ioctl as a kind of > >> parameters. > >> > >> For example setting auto-focus spot would require calling > >> VIDIOC_S_EXT_CTRLS with the following controls: > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE > >> - LEFT = ... > >> - RIGHT = ... > >> > >> Setting AF rectangle: > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_RECTANGLE > >> - LEFT = ... > >> - TOP = ... > >> - WIDTH = ... > >> - HEIGHT = ... > >> > >> Setting AF object detection (no parameters required): > >> - V4L2_CID_AUTO_FOCUS_AREA = V4L2_AUTO_FOCUS_AREA_OBJECT_DETECTION > > > > If you want to do this, then you have to make LEFT/TOP/WIDTH/HEIGHT real > > controls. There is no such thing as a pseudo control. So you need five > > new controls in total: > > > > V4L2_CID_AUTO_FOCUS_AREA > > V4L2_CID_AUTO_FOCUS_LEFT > > V4L2_CID_AUTO_FOCUS_RIGHT > > V4L2_CID_AUTO_FOCUS_WIDTH > > V4L2_CID_AUTO_FOCUS_HEIGHT > > > > I have no problem with this from the point of view of the control API, but > > whether this is the best solution for implementing auto-focus is a > > different issue and input from sensor specialists is needed as well > > (added Laurent and Sakari to the CC list). > > > > The primary concern I have is that this does not scale to multiple focus > > rectangles. This might not be relevant to auto focus, though. > > I think for more advanced hardware/configurations there is a need to > associate more information with the rectangles anyway. So the selections > API seems too limited. Probably a new IOCTL would be needed for that, > either standard or private. > > We've discussed it here with Andrzej and using such 4 controls to specify > the AF rectangle looks sufficient from our POV. > > I would just probably rename LEFT/RIGHT to POS_X/POS_Y or something, > as these 2 controls could be used in a focus mode where only spot > position needs to be specified. If position and size are sufficient, could we use the selection API instead ? An alternative would be to introduce rectangle controls. I'm a bit uncomfortable with using 4 controls here, as this could quickly grow out of control. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: omapdss/omap3isp/omapfb: Picture from omap3isp can't recover after a blank/unblank (or overlay disables after resuming)
Hi Florian, On Thursday 31 January 2013 13:06:53 Florian Neuhaus wrote: > Hi Laurent, > > Thank you for your help, see my notes below: > > Laurent Pinchart wrote on 2013-01-30: > >> Will result in the following and the following (screen flickers and goes > >> black again): > >> [ 5293.617095] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling the > >> overlay > >> [ 5293.678283] omapdss DISPC error: FIFO UNDERFLOW on vid2, disabling the > >> overlay > >> > >> Output of mediactl -p while streaming: > >> http://pastebin.com/d9zDfKXu > >> > >> OMAPDSS-config: > >> http://pastebin.com/JjF0CcCS > >> > >> Now my questions: > >> Is this behaviour expected? > > > > I don't think so. I'm not an expert on the OMAP DSS, but I wouldn't > > consider the above messages as normal. > > Just as a note: This does not happen, if I disable the fb0 upon start of the > streamer. > My DSS config before the streamer start: > > fb0 --- gfx --- lcd --- LCD > fb1 --- vid1 -/ > vid2 / > > Description: I am using fb0 for the framebuffer-console. The fb1 is > connected with the overlay vid1 and used as the colorkey in your streamer > application. vid2 is directly used from within the streamer app for the > ISP-output (at least I think so ;)). Everything is connected to the > lcd-manager and outputted to a physical attached LCD. > > My DSS config when streamer is running: > > fb0 gfx --- lcd --- LCD > fb1 --- vid1 -/ > vid2 / > > With this workaround the streamer will continue streaming after a > blank/unblank. > > > As buffers will stop flowing until the screen is unblanked, the live > > application will exit after a short select() timeout. This is an > > application issue. > > If the AF/AEWB unit is enabled, the timeout doesn't happen as the > H3A-unit delivers still OMAP3_ISP_EVENT_EXCEPTION events. Ah right. My live application should still be fixed not to timeout when AEWB is disabled, but that's out of scope here. > > It doesn't explain the omapdss error, Tomi might be able to provide more > > information about that (but he is currently away until beginning of > > February if I'm not mistaken). > > That would be very nice! As this seems to be mostly a DSS issue I'll let Tomi handle it :-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 4:03 PM, Chris Clayton wrote: > Yes, I noticed that but even with the tuning timeout set at medium or > longest, I doesn't find any channels. However, I've been following the debug > messages through the code and ended up at > drivers/media/pci/cx23885/cx23885-i2c.c. > > I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved > results from scanning. With that delay doubled, scandvb now finds 49 > channels over 3 frequencies. That's with all debugging turned off, so no > extra delays provided by the production of debug messages. > > I'll play around more tomorrow and update then. It could be that the cx23885 driver doesn't properly implement I2C clock stretching, which is something you don't encounter on most tuners but is an issue when communicating with the Xceive parts. 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Feb 1 19:00:27 CET 2013 git branch: for_v3.9 git hash: 24dec5dabfcc1d424d7bc86d393d31f57ebcc975 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.4.07-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: OK apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
Hi Devin, On 02/01/13 14:19, Devin Heitmueller wrote: On Fri, Feb 1, 2013 at 9:16 AM, Chris Clayton wrote: I've got some more diagnostics. I tuned on the 12c debugging in the cx23885 driver and ran the scan again. Surprisingly, the scan found 22 channels on a single frequency (that carries the BBC channels). I've attached two files - the output from dvbscan and the kernel log covering the loading of the drivers and running the scan. I'm no kernel guru, but is it possible that the root cause of the scan failures is a timing problem which is being partially offset by the time taken to produce all the debug output? w_scan does have some arguments that let you increase the timeout for tuning. You may wish to see if that has any effect. Maybe the w_scan timeout is just too short for that device. Yes, I noticed that but even with the tuning timeout set at medium or longest, I doesn't find any channels. However, I've been following the debug messages through the code and ended up at drivers/media/pci/cx23885/cx23885-i2c.c. I've found that by amending I2C_WAIT_DELAY from 32 to 64, I get improved results from scanning. With that delay doubled, scandvb now finds 49 channels over 3 frequencies. That's with all debugging turned off, so no extra delays provided by the production of debug messages. I'll play around more tomorrow and update then. Chris Devin -- 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] crystalhd git.linuxtv.org kernel driver: FIX kernel unhandled paging request BUG triggered by multithreaded or faulty apps
This patch should pass the 3rd test case of this bug (kernel unhandled paging request) and maybe the PM resume issue, too: 21370-Feb 1 18:39:52 tom3 kernel: [59853.620636] crystalhd :03:00.0: Opening new user[0] handle 21371-Feb 1 18:39:52 tom3 kernel: [59853.875306] crystalhd :03:00.0: Closing user[0] handle with mode 21372-Feb 1 18:39:52 tom3 kernel: [59854.079584] crystalhd :03:00.0: Opening new user[0] handle 21373-Feb 1 18:39:52 tom3 kernel: [59854.079607] crystalhd :03:00.0: Opening new user[0] handle 21374-Feb 1 18:39:52 tom3 kernel: [59854.079633] crystalhd :03:00.0: Closing user[0] handle with mode 21375-Feb 1 18:39:52 tom3 kernel: [59854.080022] crystalhd :03:00.0: Opening new user[0] handle 21376:Feb 1 18:39:52 tom3 kernel: [59854.283228] BUG: unable to handle kernel paging request at 071e 21377-Feb 1 18:39:52 tom3 kernel: [59854.283358] IP: [<071e>] 0x71d 21378-Feb 1 18:39:52 tom3 kernel: [59854.283447] PGD 0 21379-Feb 1 18:39:52 tom3 kernel: [59854.283490] Oops: 0010 [#1] PREEMPT SMP 21380-Feb 1 18:39:52 tom3 kernel: [59854.283575] CPU 0 21381-Feb 1 18:39:52 tom3 kernel: [59854.283609] Modules linked in: crystalhd(O) nfs fscache uinput parport_pc ppdev lp parport bluetooth nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs acpi_cpufreq mperf cpufreq_powersave cpufreq_stats cpufreq_conservative cpufreq_performance cpufreq_ondemand freq_table fuse dm_mod ext3 jbd pciehp arc4 ath5k ath mac80211 snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_usb_audio snd_pcm_oss cfg80211 thinkpad_acpi snd_mixer_oss snd_hwdep snd_pcm snd_usbmidi_lib snd_seq_dummy snd_seq_oss rfkill snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer pcmcia snd_seq_device gspca_zc3xx gspca_main snd yenta_socket psmouse pcmcia_rsrc videodev tpm_tis tpm tpm_bios v4l2_compat_ioctl32 pcmcia_core i2c_i801 nvram pcspkr usb_storage soundcore serio_raw snd_page_alloc rtc_cmos wmi ac battery processor evdev nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_limit xt_tcpudp iptable_filte r ip_tables x_tables ext4 mbcach 21382-Feb 1 18:39:52 tom3 kernel: e jbd2 crc16 usbhid hid sg sr_mod sd_mod cdrom crc_t10dif ata_generic uhci_hcd ahci libahci xhci_hcd ata_piix libata ehci_hcd atkbd thermal e1000e usbcore usb_common [last unloaded: crystalhd] 21383-Feb 1 18:39:52 tom3 kernel: [59854.284016] 21384-Feb 1 18:39:52 tom3 kernel: [59854.284016] Pid: 12285, comm: matroskademux0: Tainted: G O 3.2.37-dirty #8 LENOVO 7735Y1T/7735Y1T 21385-Feb 1 18:39:52 tom3 kernel: [59854.284016] RIP: 0010:[<071e>] [<071e>] 0x71d 21386-Feb 1 18:39:52 tom3 kernel: [59854.284016] RSP: 0018:8800164d3b50 EFLAGS: 00010292 21387-Feb 1 18:39:52 tom3 kernel: [59854.284016] RAX: 007f RBX: 880004b9a400 RCX: 21388-Feb 1 18:39:52 tom3 kernel: [59854.284016] RDX: 0001 RSI: 0034 RDI: 88000f437400 21389-Feb 1 18:39:52 tom3 kernel: [59854.284016] RBP: 8800164d3b68 R08: 0001 R09: 21390-Feb 1 18:39:52 tom3 kernel: [59854.284016] R10: R11: 8800084d86c0 R12: 88007c256090 21391-Feb 1 18:39:52 tom3 kernel: [59854.284016] R13: 88000f437400 R14: 88000f4374d0 R15: a0489f20 21392-Feb 1 18:39:52 tom3 kernel: [59854.284016] FS: 7f70d559c700() GS:88007f40() knlGS: 21393-Feb 1 18:39:52 tom3 kernel: [59854.284016] CS: 0010 DS: ES: CR0: 80050033 21394-Feb 1 18:39:52 tom3 kernel: [59854.284016] CR2: 071e CR3: 339b1000 CR4: 06f0 21395-Feb 1 18:39:52 tom3 kernel: [59854.284016] DR0: DR1: DR2: 21396-Feb 1 18:39:52 tom3 kernel: [59854.284016] DR3: DR6: 0ff0 DR7: 0400 21397-Feb 1 18:39:52 tom3 kernel: [59854.284016] Process matroskademux0: (pid: 12285, threadinfo 8800164d2000, task 8800084d8000) 21398-Feb 1 18:39:52 tom3 kernel: [59854.284016] Stack: 21399-Feb 1 18:39:52 tom3 kernel: [59854.284016] a047df98 8800164d3b88 880004b9a400 8800164d3b88 21400-Feb 1 18:39:52 tom3 kernel: [59854.284016] a047e48b 880004b9a400 88007c256090 8800164d3bb8 21401-Feb 1 18:39:52 tom3 kernel: [59854.284016] a047c6fa 88000f4374c0 21402-Feb 1 18:39:52 tom3 kernel: [59854.284016] Call Trace: 21403-Feb 1 18:39:52 tom3 kernel: [59854.284016] [] ? crystalhd_link_soft_rst+0x28/0x80 [crystalhd] 21404-Feb 1 18:39:52 tom3 kernel: [59854.284016] [] crystalhd_link_start_device+0xcb/0x150 [crystalhd] 21405-Feb 1 18:39:52 tom3 kernel: [59854.284016] [] crystalhd_hw_open+0x23a/0x400 [crystalhd] 21406-Feb 1 18:39:52 tom3 kernel: [59854.284016] [] crys
[PATCH 4/4] saa7134: Add AverMedia A706 AverTV Satellite Hybrid+FM
Add AverMedia AverTV Satellite Hybrid+FM (A706) card to saa7134 driver.
Working: analog inputs, TV, FM radio and IR remote control.
Untested: DVB-S.
Signed-off-by: Ondrej Zary
---
drivers/media/i2c/ir-kbd-i2c.c | 13 ++-
drivers/media/pci/saa7134/saa7134-cards.c | 53 +++
drivers/media/pci/saa7134/saa7134-dvb.c | 23
drivers/media/pci/saa7134/saa7134-i2c.c |1 +
drivers/media/pci/saa7134/saa7134-input.c |3 ++
drivers/media/pci/saa7134/saa7134-tvaudio.c |1 +
drivers/media/pci/saa7134/saa7134.h |1 +
7 files changed, 94 insertions(+), 1 deletions(-)
diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index 08ae067..c1f6e7c 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -230,7 +230,7 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir,
return 0;
dprintk(1, "read key 0x%02x/0x%02x\n", key, keygroup);
- if (keygroup < 2 || keygroup > 3) {
+ if (keygroup < 2 || keygroup > 4) {
/* Only a warning */
dprintk(1, "warning: invalid key group 0x%02x for key 0x%02x\n",
keygroup, key);
@@ -239,6 +239,10 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir,
*ir_key = key;
*ir_raw = key;
+ if (!strcmp(ir->ir_codes, RC_MAP_AVERMEDIA_M733A_RM_K6)) {
+ *ir_key |= keygroup << 8;
+ *ir_raw |= keygroup << 8;
+ }
return 1;
}
@@ -332,6 +336,13 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
rc_type = RC_BIT_OTHER;
ir_codes= RC_MAP_AVERMEDIA_CARDBUS;
break;
+ case 0x41:
+ name= "AVerMedia EM78P153";
+ ir->get_key = get_key_avermedia_cardbus;
+ rc_type = RC_BIT_OTHER;
+ /* RM-KV remote, seems to be same as RM-K6 */
+ ir_codes= RC_MAP_AVERMEDIA_M733A_RM_K6;
+ break;
case 0x71:
name= "Hauppauge/Zilog Z8";
ir->get_key = get_key_haup_xvr;
diff --git a/drivers/media/pci/saa7134/saa7134-cards.c
b/drivers/media/pci/saa7134/saa7134-cards.c
index fe54f88..c603064 100644
--- a/drivers/media/pci/saa7134/saa7134-cards.c
+++ b/drivers/media/pci/saa7134/saa7134-cards.c
@@ -50,6 +50,11 @@ static char name_svideo[] = "S-Video";
/* -- */
/* board config info */
+static struct tda18271_std_map aver_a706_std_map = {
+ .fm_radio = { .if_freq = 5500, .fm_rfn = 0, .agc_mode = 3, .std = 0,
+ .if_lvl = 0, .rfagc_top = 0x2c, },
+};
+
/* If radio_type !=UNSET, radio_addr should be specified
*/
@@ -5773,6 +5778,37 @@ struct saa7134_board saa7134_boards[] = {
.gpio = 0x000,
},
},
+ [SAA7134_BOARD_AVERMEDIA_A706] = {
+ .name = "AverMedia AverTV Satellite Hybrid+FM A706",
+ .audio_clock= 0x00187de7,
+ .tuner_type = TUNER_PHILIPS_TDA8290,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda829x_conf = { .lna_cfg = 0, .no_i2c_gate = 1,
+ .tda18271_std_map = &aver_a706_std_map },
+ .gpiomask = 1 << 11,
+ .mpeg = SAA7134_MPEG_DVB,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ }, {
+ .name = name_comp,
+ .vmux = 4,
+ .amux = LINE1,
+ }, {
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ } },
+ .radio = {
+ .name = name_radio,
+ .amux = TV,
+ .gpio = 0x800,
+ },
+ },
};
@@ -7020,6 +7056,12 @@ struct pci_device_id saa7134_pci_tbl[] = {
.subdevice= 0x0911,
.driver_data = SAA7134_BOARD_SENSORAY811_911,
}, {
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7133,
+ .subvendor= 0x1461, /* Avermedia Technologies Inc */
+ .subdevice= 0x2055, /* AverTV Satellite Hybrid+FM A706 */
+ .driver_data = SAA7134_BOARD_AVERMEDIA_A706,
+ }, {
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_
[PATCH 3/4] tuner-core: Change config from unsigned int to void *
config looks like a hack that was added to tuner-core to allow some
configuration of TDA8290 tuner (it's not used by any other driver).
But with the new configuration options of tda8290 driver (no_i2c_gate
and std_map), it's no longer sufficient.
Change config to be void * instead, which allows passing tuner-dependent
config struct to drivers.
Also update saa7134 driver to reflect this change (no other driver uses this).
Signed-off-by: Ondrej Zary
---
drivers/media/pci/saa7134/saa7134-cards.c | 40 ++--
drivers/media/pci/saa7134/saa7134.h |3 +-
drivers/media/v4l2-core/tuner-core.c | 20 +-
include/media/tuner.h |2 +-
4 files changed, 30 insertions(+), 35 deletions(-)
diff --git a/drivers/media/pci/saa7134/saa7134-cards.c
b/drivers/media/pci/saa7134/saa7134-cards.c
index bc08f1d..fe54f88 100644
--- a/drivers/media/pci/saa7134/saa7134-cards.c
+++ b/drivers/media/pci/saa7134/saa7134-cards.c
@@ -2760,7 +2760,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 0,
+ .tda829x_conf = { .lna_cfg = 0 },
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x020,
.inputs = {{
@@ -3291,7 +3291,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 1,
+ .tda829x_conf = { .lna_cfg = 1 },
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x00020,
.inputs = {{
@@ -3395,7 +3395,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 1,
+ .tda829x_conf = { .lna_cfg = 1 },
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x0200100,
.inputs = {{
@@ -3426,7 +3426,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 3,
+ .tda829x_conf = { .lna_cfg = 3 },
.mpeg = SAA7134_MPEG_DVB,
.ts_type= SAA7134_MPEG_TS_SERIAL,
.ts_force_val = 1,
@@ -3459,7 +3459,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 3,
+ .tda829x_conf = { .lna_cfg = 3 },
.mpeg = SAA7134_MPEG_DVB,
.ts_type= SAA7134_MPEG_TS_SERIAL,
.gpiomask = 0x0800100, /* GPIO 21 is an INPUT */
@@ -3683,7 +3683,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 2,
+ .tda829x_conf = { .lna_cfg = 2 },
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x020,
.inputs = {{
@@ -3736,7 +3736,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 2,
+ .tda829x_conf = { .lna_cfg = 2 },
.mpeg = SAA7134_MPEG_DVB,
.gpiomask = 0x020,
.inputs = {{
@@ -3754,7 +3754,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 2,
+ .tda829x_conf = { .lna_cfg = 2 },
.gpiomask = 1 << 21,
.mpeg = SAA7134_MPEG_DVB,
.inputs = {{
@@ -3887,7 +3887,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .tuner_config = 0,
+ .tda829x_conf = { .lna_cfg = 0 },
.mpeg = SAA7134_MPEG_DVB,
.inputs = {{
.name = name_tv, /* FIXME: analog tv untested */
@@ -3903,7 +3903,7 @@ struct saa7134_board saa7134_boards[] = {
.radio_type = UNSET,
.tuner_addr = ADDR_UNSET,
.radi
[PATCH 2/4] tda8290: Allow custom std_map for tda18271
Allow specifying a custom std_map for tda18271 by external configuration.
This is required by cards that require custom std_map for analog TV or radio,
like AverMedia A706.
Signed-off-by: Ondrej Zary
---
drivers/media/tuners/tda8290.c |8 ++--
drivers/media/tuners/tda8290.h |2 ++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index a2b7a9f..c1ade88 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -54,6 +54,7 @@ struct tda8290_priv {
#define TDA18271 16
struct tda827x_config cfg;
+ struct tda18271_std_map *tda18271_std_map;
};
/*-*/
@@ -635,6 +636,7 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
if ((data == 0x83) || (data == 0x84)) {
priv->ver |= TDA18271;
tda829x_tda18271_config.config = priv->cfg.config;
+ tda829x_tda18271_config.std_map = priv->tda18271_std_map;
dvb_attach(tda18271_attach, fe, priv->tda827x_addr,
priv->i2c_props.adap, &tda829x_tda18271_config);
} else {
@@ -746,8 +748,10 @@ struct dvb_frontend *tda829x_attach(struct dvb_frontend
*fe,
priv->i2c_props.addr = i2c_addr;
priv->i2c_props.adap = i2c_adap;
priv->i2c_props.name = "tda829x";
- if (cfg)
- priv->cfg.config = cfg->lna_cfg;
+ if (cfg) {
+ priv->cfg.config = cfg->lna_cfg;
+ priv->tda18271_std_map = cfg->tda18271_std_map;
+ }
if (tda8290_probe(&priv->i2c_props) == 0) {
priv->ver = TDA8290;
diff --git a/drivers/media/tuners/tda8290.h b/drivers/media/tuners/tda8290.h
index 9959cc8..280b70d 100644
--- a/drivers/media/tuners/tda8290.h
+++ b/drivers/media/tuners/tda8290.h
@@ -19,6 +19,7 @@
#include
#include "dvb_frontend.h"
+#include "tda18271.h"
struct tda829x_config {
unsigned int lna_cfg;
@@ -27,6 +28,7 @@ struct tda829x_config {
#define TDA829X_PROBE_TUNER 0
#define TDA829X_DONT_PROBE 1
unsigned int no_i2c_gate:1;
+ struct tda18271_std_map *tda18271_std_map;
};
#if defined(CONFIG_MEDIA_TUNER_TDA8290) ||
(defined(CONFIG_MEDIA_TUNER_TDA8290_MODULE) && defined(MODULE))
--
Ondrej Zary
--
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/4] tda8290: Allow disabling I2C gate
Allow disabling I2C gate handling by external configuration.
This is required by cards that have all devices on a single I2C bus,
like AverMedia A706.
Signed-off-by: Ondrej Zary
---
drivers/media/tuners/tda8290.c | 49 +++
drivers/media/tuners/tda8290.h |1 +
2 files changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index 8c48521..a2b7a9f 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -233,7 +233,8 @@ static void tda8290_set_params(struct dvb_frontend *fe,
}
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (fe->ops.tuner_ops.set_analog_params)
fe->ops.tuner_ops.set_analog_params(fe, params);
@@ -302,7 +303,8 @@ static void tda8290_set_params(struct dvb_frontend *fe,
}
}
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
tuner_i2c_xfer_send(&priv->i2c_props, if_agc_set, 2);
}
@@ -424,7 +426,8 @@ static void tda8295_set_params(struct dvb_frontend *fe,
tuner_i2c_xfer_send(&priv->i2c_props, blanking_mode, 2);
msleep(20);
- tda8295_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (fe->ops.tuner_ops.set_analog_params)
fe->ops.tuner_ops.set_analog_params(fe, params);
@@ -437,7 +440,8 @@ static void tda8295_set_params(struct dvb_frontend *fe,
else
tuner_dbg("tda8295 not locked, no signal?\n");
- tda8295_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
}
/*-*/
@@ -465,11 +469,13 @@ static void tda8290_standby(struct dvb_frontend *fe)
unsigned char tda8290_agc_tri[] = { 0x02, 0x20 };
struct i2c_msg msg = {.addr = priv->tda827x_addr, .flags=0, .buf=cb1,
.len = 2};
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
if (priv->ver & TDA8275A)
cb1[1] = 0x90;
i2c_transfer(priv->i2c_props.adap, &msg, 1);
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
tuner_i2c_xfer_send(&priv->i2c_props, tda8290_agc_tri, 2);
tuner_i2c_xfer_send(&priv->i2c_props, tda8290_standby, 2);
}
@@ -537,9 +543,11 @@ static void tda8290_init_tuner(struct dvb_frontend *fe)
if (priv->ver & TDA8275A)
msg.buf = tda8275a_init;
- tda8290_i2c_bridge(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
i2c_transfer(priv->i2c_props.adap, &msg, 1);
- tda8290_i2c_bridge(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
}
/*-*/
@@ -565,19 +573,13 @@ static struct tda18271_config tda829x_tda18271_config = {
static int tda829x_find_tuner(struct dvb_frontend *fe)
{
struct tda8290_priv *priv = fe->analog_demod_priv;
- struct analog_demod_ops *analog_ops = &fe->ops.analog_ops;
int i, ret, tuners_found;
u32 tuner_addrs;
u8 data;
struct i2c_msg msg = { .flags = I2C_M_RD, .buf = &data, .len = 1 };
- if (!analog_ops->i2c_gate_ctrl) {
- printk(KERN_ERR "tda8290: no gate control were provided!\n");
-
- return -EINVAL;
- }
-
- analog_ops->i2c_gate_ctrl(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
/* probe for tuner chip */
tuners_found = 0;
@@ -595,7 +597,8 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
give a response now
*/
- analog_ops->i2c_gate_ctrl(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 0);
if (tuners_found > 1)
for (i = 0; i < tuners_found; i++) {
@@ -618,12 +621,14 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
priv->tda827x_addr = tuner_addrs;
msg.addr = tuner_addrs;
- analog_ops->i2c_gate_ctrl(fe, 1);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+ fe->ops.analog_ops.i2c_gate_ctrl(fe, 1);
ret = i2c_transfer(priv->i2c_props.adap, &msg, 1);
if (ret != 1) {
tuner_warn("tuner access failed!\n");
- analog_ops->i2c_gate_ctrl(fe, 0);
+ if (fe->ops.analog_ops.i2c_gate_ctrl)
+
[PATCH v2 0/4] saa7134: Add AverMedia A706 AverTV Satellite Hybrid+FM
Add AverMedia AverTV Satellite Hybrid+FM (A706) card to saa7134 driver. This requires some changes to tda8290 - disabling I2C gate control and passing custom std_map to tda18271. Also tuner-core needs to be changed because there's currently no way to pass any complex configuration to analog tuners. -- Ondrej Zary -- 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 v4 10/10] ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs
Add separate nodes for the CAMCLK pin and turn off pull-up on camera
ports A, B. The video bus pins and the clock output (CAMCLK) pin need
separate nodes since full camera port is not used in some configurations,
e.g. for MIPI CSI-2 bus on CAMCLK is required and data/clock signal
use separate dedicated pins.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Changes since v3:
- corrected camera port B part and removed entries for
"inactive" state
---
arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
index 8e6115a..4c3a2c3 100644
--- a/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
+++ b/arch/arm/boot/dts/exynos4x12-pinctrl.dtsi
@@ -401,15 +401,21 @@
samsung,pin-drv = <0>;
};
- cam_port_a: cam-port-a {
+ cam_port_a_io: cam-port-a-io {
samsung,pins = "gpj0-0", "gpj0-1", "gpj0-2", "gpj0-3",
"gpj0-4", "gpj0-5", "gpj0-6", "gpj0-7",
- "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-3",
- "gpj1-4";
+ "gpj1-0", "gpj1-1", "gpj1-2", "gpj1-4";
samsung,pin-function = <2>;
- samsung,pin-pud = <3>;
+ samsung,pin-pud = <0>;
samsung,pin-drv = <0>;
};
+
+ cam_port_a_clk_active: cam-port-a-clk-active {
+ samsung,pins = "gpj1-3";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
};
pinctrl@1100 {
@@ -834,16 +840,22 @@
samsung,pin-drv = <0>;
};
- cam_port_b: cam-port-b {
+ cam_port_b_io: cam-port-b-io {
samsung,pins = "gpm0-0", "gpm0-1", "gpm0-2", "gpm0-3",
"gpm0-4", "gpm0-5", "gpm0-6", "gpm0-7",
- "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1",
- "gpm2-2";
+ "gpm1-0", "gpm1-1", "gpm2-0", "gpm2-1";
samsung,pin-function = <3>;
samsung,pin-pud = <3>;
samsung,pin-drv = <0>;
};
+ cam_port_b_clk_active: cam-port-b-clk-active {
+ samsung,pins = "gpm2-2";
+ samsung,pin-function = <3>;
+ samsung,pin-pud = <0>;
+ samsung,pin-drv = <3>;
+ };
+
eint0: ext-int0 {
samsung,pins = "gpx0-0";
samsung,pin-function = <0xf>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 09/10] ARM: dts: Add FIMC and MIPI CSIS device nodes for Exynos4x12
Add common camera node and fimc nodes specific to Exynos4212 and
Exynos4412 SoCs. fimc-is is a node for the Exynos4x12 FIMC-IS
subsystem and fimc-lite nodes are created as its child nodes,
among others due to FIMC-LITE device dependencies on FIMC-IS
related clocks.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 9c809b72..59b2b8e 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -26,6 +26,8 @@
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
+ fimc-lite0 = &fimc_lite_0;
+ fimc-lite1 = &fimc_lite_1;
};
pd_isp: isp-power-domain@10023CA0 {
@@ -71,4 +73,49 @@
reg = <0x106E 0x1000>;
interrupts = <0 72 0>;
};
+
+ camera {
+ fimc_0: fimc@1180 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = "samsung,exynos4212-fimc";
+ };
+
+ fimc_is: fimc-is@1200 {
+ compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ reg = <0x1200 0x26>;
+ interrupts = <0 90 0>, <0 95 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fimc_lite_0: fimc-lite@1239 {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x1239 0x1000>;
+ interrupts = <0 105 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ };
+
+ fimc_lite_1: fimc-lite@123A {
+ compatible = "samsung,exynos4212-fimc-lite";
+ reg = <0x123A 0x1000>;
+ interrupts = <0 106 0>;
+ samsung,power-domain = <&pd_isp>;
+ status = "disabled";
+ };
+ };
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 07/10] ARM: dts: Add camera to node exynos4.dtsi
This patch adds common FIMC device nodes for all Exynos4 SoCs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4.dtsi | 64
1 file changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index e1347fc..75c388b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -36,6 +36,12 @@
i2c5 = &i2c_5;
i2c6 = &i2c_6;
i2c7 = &i2c_7;
+ csis0 = &csis_0;
+ csis1 = &csis_1;
+ fimc0 = &fimc_0;
+ fimc1 = &fimc_1;
+ fimc2 = &fimc_2;
+ fimc3 = &fimc_3;
};
pd_mfc: mfc-power-domain@10023C40 {
@@ -82,6 +88,64 @@
reg = <0x1044 0x1000>;
};
+ camera {
+ compatible = "samsung,fimc", "simple-bus";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ fimc_0: fimc@1180 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1180 0x1000>;
+ interrupts = <0 84 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_1: fimc@1181 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1181 0x1000>;
+ interrupts = <0 85 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_2: fimc@1182 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1182 0x1000>;
+ interrupts = <0 86 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ fimc_3: fimc@1183 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1183 0x1000>;
+ interrupts = <0 87 0>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ csis_0: csis@1188 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1188 0x4000>;
+ interrupts = <0 78 0>;
+ bus-width = <4>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+
+ csis_1: csis@1189 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1189 0x4000>;
+ interrupts = <0 80 0>;
+ bus-width = <2>;
+ samsung,power-domain = <&pd_cam>;
+ status = "disabled";
+ };
+ };
+
watchdog@1006 {
compatible = "samsung,s3c2410-wdt";
reg = <0x1006 0x100>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 08/10] ARM: dts: Add ISP power domain node for Exynos4x12
The ISP power domain is a common power domain for fimc-lite
and fimc-is (ISP) devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
arch/arm/boot/dts/exynos4x12.dtsi |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi
index 179a62e..9c809b72 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -28,6 +28,11 @@
pinctrl3 = &pinctrl_3;
};
+ pd_isp: isp-power-domain@10023CA0 {
+ compatible = "samsung,exynos4210-pd";
+ reg = <0x10023CA0 0x20>;
+ };
+
combiner:interrupt-controller@1044 {
interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>,
<0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 05/10] s5p-fimc: Add device tree based sensors registration
The sensor (I2C and/or SPI client) devices are instantiated by their
corresponding control bus drivers. Since the I2C client's master clock
is often provided by a video bus receiver (host interface) or other
than I2C/SPI controller device, the drivers of those client devices
are not accessing hardware in their driver's probe() callback. Instead,
after enabling clock, the host driver calls back into a sub-device
when it wants to activate them. This pattern is used by some in-tree
drivers and this patch also uses it for DT case. This patch is intended
as a first step for adding device tree support to the S5P/Exynos SoC
camera drivers. The second one is adding support for asynchronous
sub-devices registration and clock control from sub-device driver
level. The bindings shall not change when asynchronous probing support
is added.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 89
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 231 +---
include/media/s5p_fimc.h | 16 ++
3 files changed, 311 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
index 2b932f2..6b81ad1 100644
--- a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -56,6 +56,29 @@ For every fimc-lite node a numbered alias should be present
in the aliases
node. Aliases are in form of fimc-lite, where is an integer (0...N)
specifying the IP's instance index.
+
+'parallel-ports' node
+-
+
+This node should contain child 'port' nodes specifying active parallel video
+input ports. It includes camera A and camera B inputs. 'reg' property in the
+port nodes specifies data input - 0, 1 indicates input A, B respectively.
+
+Optional properties
+
+- samsung,camclk-out: specifies clock output for remote sensor,
+ 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+
+Image sensor nodes
+--
+
+The sensor device nodes should be added as their control bus controller
+(e.g. I2C0) child nodes and linked to a port node in the csis or parallel-ports
+node, using common the common video interfaces bindings, i.e. port/endpoint
+node pairs. The implementation of this binding requires clock-frequency
+property to be present in the sensor device nodes.
+
+
Example:
aliases {
@@ -63,12 +86,68 @@ Example:
fimc0 = &fimc_0;
};
+ /* Parallel bus IF sensor */
+ i2c_0: i2c@1386 {
+ s5k6aa: sensor@3c {
+ compatible = "samsung,s5k6aafx";
+ reg = <0x3c>;
+ vddio-supply = <...>;
+
+ clock-frequency = <2400>;
+ clocks = <...>;
+ clock-names = "mclk";
+
+ port {
+ s5k6aa_ep: endpoint {
+ remote-endpoint = <&fimc0_ep>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ hsync-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+ };
+
+ /* MIPI CSI-2 bus IF sensor */
+ s5c73m3: sensor@0x1a {
+ compatible = "samsung,s5c73m3";
+ reg = <0x1a>;
+ vddio-supply = <...>;
+
+ clock-frequency = <2400>;
+ clocks = <...>;
+ clock-names = "mclk";
+
+ port {
+ s5c73m3_1: endpoint {
+ data-lanes = <1>, <2>, <3>, <4>;
+ remote-endpoint = <&csis0_ep>;
+ };
+ };
+ };
+
camera {
compatible = "samsung,fimc", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
status = "okay";
+ /* parallel camera ports */
+ parallel-ports {
+ /* camera A input */
+ port@0 {
+ reg = <1>;
+ fimc0_ep: endpoint {
+ remote-endpoint = <&s5k6aa_ep>;
+ bus-width = <8>;
+ hsync-active = <0>;
+ hsync-active = <1>;
+ pclk-sample = <1>;
+ };
+ };
+ };
+
fimc_0: fimc@1180 {
compatible = "samsung,exynos4210-fimc";
[PATCH v4 06/10] s5p-fimc: Use pinctrl API for camera ports configuration
Before the camera ports can be used the pinmux needs to be configured
properly. This patch adds a function to set the camera ports pinctrl
to a default state within the media driver's probe().
The camera port(s) are then configured for the video bus operation.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
Changes since v3:
- removed the "inactive" pinctrl state, it will be added later if required
---
.../devicetree/bindings/media/soc/samsung-fimc.txt |7 +++
drivers/media/platform/s5p-fimc/fimc-mdevice.c |9 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
index 6b81ad1..3788305 100644
--- a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -18,6 +18,10 @@ Required properties:
- compatible : must be "samsung,fimc", "simple-bus"
+- pinctrl-names: pinctrl names for camera port pinmux control, at least
+"default" needs to be specified.
+- pinctrl-0...N : pinctrl properties corresponding to pinctrl-names
+
The 'camera' node must include at least one 'fimc' child node.
@@ -133,6 +137,9 @@ Example:
#size-cells = <1>;
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_port_a_clk_active>;
+
/* parallel camera ports */
parallel-ports {
/* camera A input */
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index 2bb501f..6c2c9e3 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1197,6 +1198,14 @@ static int fimc_md_probe(struct platform_device *pdev)
/* Protect the media graph while we're registering entities */
mutex_lock(&fmd->media_dev.graph_mutex);
+ if (dev->of_node) {
+ struct pinctrl *pctl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR(pctl)) {
+ ret = PTR_ERR(pctl);
+ goto err_unlock;
+ }
+ }
+
if (fmd->pdev->dev.of_node)
ret = fimc_md_register_of_platform_entities(fmd, dev->of_node);
else
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 04/10] s5p-fimc: Add device tree support for the main media device driver
This patch adds changes required for the main camera media device
driver to be initialized on systems instantiated from the device tree.
The platform devices corresponding to child nodes of the 'camera'
node are looked up and and registered as sub-devices to the common
media device. The main driver's probing is deferred if any of the
sub-device drivers is not yet initialized and ready.
An OF matching table is added for the main driver associated with
the 'camera' node.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/platform/s5p-fimc/fimc-core.c|1 -
drivers/media/platform/s5p-fimc/fimc-mdevice.c | 77 +---
drivers/media/platform/s5p-fimc/fimc-mdevice.h |4 ++
include/media/s5p_fimc.h |1 +
4 files changed, 75 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.c
b/drivers/media/platform/s5p-fimc/fimc-core.c
index 07ca0e0..ba743a5 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.c
+++ b/drivers/media/platform/s5p-fimc/fimc-core.c
@@ -1276,7 +1276,6 @@ static const struct platform_device_id fimc_driver_ids[]
= {
},
{ },
};
-MODULE_DEVICE_TABLE(platform, fimc_driver_ids);
static const struct of_device_id fimc_of_match[] = {
{
diff --git a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
index f49f6f1..c113734 100644
--- a/drivers/media/platform/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/platform/s5p-fimc/fimc-mdevice.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -457,6 +459,51 @@ static int fimc_md_pdev_match(struct device *dev, void
*data)
return 0;
}
+/* Register FIMC, FIMC-LITE and CSIS media entities */
+#ifdef CONFIG_OF
+static int fimc_md_register_of_platform_entities(struct fimc_md *fmd,
+struct device_node *parent)
+{
+ struct device_node *node;
+ int ret = 0;
+
+ for_each_available_child_of_node(parent, node) {
+ struct platform_device *pdev;
+ int plat_entity = -1;
+
+ pdev = of_find_device_by_node(node);
+ if (!pdev)
+ continue;
+
+ /* If driver of any entity isn't ready try all again later. */
+ if (!strcmp(node->name, CSIS_OF_NODE_NAME))
+ plat_entity = IDX_CSIS;
+ else if (!strcmp(node->name, FIMC_LITE_OF_NODE_NAME))
+ plat_entity = IDX_FLITE;
+ else if (!strcmp(node->name, FIMC_OF_NODE_NAME))
+ plat_entity = IDX_FIMC;
+
+ if (plat_entity >= 0)
+ ret = fimc_md_register_platform_entity(fmd, pdev,
+ plat_entity);
+ put_device(&pdev->dev);
+ if (ret < 0)
+ break;
+
+ /* FIMC-IS child devices */
+ if (plat_entity == IDX_IS_ISP) {
+ ret = fimc_md_register_of_platform_entities(fmd, node);
+ if (ret < 0)
+ break;
+ }
+ }
+
+ return ret;
+}
+#else
+#define fimc_md_register_platform_entities(fmd) (-ENOSYS)
+#endif
+
static void fimc_md_unregister_entities(struct fimc_md *fmd)
{
int i;
@@ -948,8 +995,8 @@ static int fimc_md_probe(struct platform_device *pdev)
v4l2_dev = &fmd->v4l2_dev;
v4l2_dev->mdev = &fmd->media_dev;
v4l2_dev->notify = fimc_sensor_notify;
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "%s",
-dev_name(&pdev->dev));
+ strlcpy(v4l2_dev->name, "s5p-fimc-md", sizeof(v4l2_dev->name));
+
ret = v4l2_device_register(&pdev->dev, &fmd->v4l2_dev);
if (ret < 0) {
@@ -965,13 +1012,16 @@ static int fimc_md_probe(struct platform_device *pdev)
if (ret)
goto err_clk;
- fmd->user_subdev_api = false;
+ fmd->user_subdev_api = (dev->of_node != NULL);
/* Protect the media graph while we're registering entities */
mutex_lock(&fmd->media_dev.graph_mutex);
- ret = bus_for_each_dev(&platform_bus_type, NULL, fmd,
- fimc_md_pdev_match);
+ if (fmd->pdev->dev.of_node)
+ ret = fimc_md_register_of_platform_entities(fmd, dev->of_node);
+ else
+ ret = bus_for_each_dev(&platform_bus_type, NULL, fmd,
+ fimc_md_pdev_match);
if (ret)
goto err_unlock;
@@ -1019,12 +1069,25 @@ static int fimc_md_remove(struct platform_device *pdev)
return 0;
}
+static struct platform_device_id fimc_driver_ids[] __always_unused = {
+ { .name = "s5p-fimc-md" },
+ { },
+};
+MODULE_DEVICE_TABLE(platform, fimc_driver_ids
[PATCH v4 03/10] s5p-fimc: Add device tree support for FIMC-LITE devices
This patch add support for binding the driver to FIMC-LITE devices
instantiated from the device tree.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 15 +
drivers/media/platform/s5p-fimc/fimc-lite.c| 65 ++--
2 files changed, 61 insertions(+), 19 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
index 916b2c3..2b932f2 100644
--- a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -41,6 +41,21 @@ Optional properties
- clock-frequency - maximum FIMC local clock (LCLK) frequency
+'fimc-lite' device nodes
+---
+
+Required properties:
+
+- compatible : should be "samsung,exynos4212-fimc" for Exynos4212 and
+ Exynos4412 SoCs;
+- reg : physical base address and size of the device memory mapped
+ registers;
+- interrupts : should contain FIMC-LITE interrupt;
+
+For every fimc-lite node a numbered alias should be present in the aliases
+node. Aliases are in form of fimc-lite, where is an integer (0...N)
+specifying the IP's instance index.
+
Example:
aliases {
diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.c
b/drivers/media/platform/s5p-fimc/fimc-lite.c
index e18babf..a0a70bc 100644
--- a/drivers/media/platform/s5p-fimc/fimc-lite.c
+++ b/drivers/media/platform/s5p-fimc/fimc-lite.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1480,18 +1481,34 @@ static int fimc_lite_clk_get(struct fimc_lite *fimc)
return ret;
}
+static const struct of_device_id flite_of_match[];
+
static int fimc_lite_probe(struct platform_device *pdev)
{
- struct flite_drvdata *drv_data = fimc_lite_get_drvdata(pdev);
+ struct flite_drvdata *drv_data = NULL;
+ struct device *dev = &pdev->dev;
+ const struct of_device_id *of_id;
struct fimc_lite *fimc;
struct resource *res;
int ret;
- fimc = devm_kzalloc(&pdev->dev, sizeof(*fimc), GFP_KERNEL);
+ fimc = devm_kzalloc(dev, sizeof(*fimc), GFP_KERNEL);
if (!fimc)
return -ENOMEM;
- fimc->index = pdev->id;
+ if (dev->of_node) {
+ of_id = of_match_node(flite_of_match, dev->of_node);
+ if (of_id)
+ drv_data = (struct flite_drvdata *)of_id->data;
+ fimc->index = of_alias_get_id(dev->of_node, "fimc-lite");
+ } else {
+ drv_data = fimc_lite_get_drvdata(pdev);
+ fimc->index = pdev->id;
+ }
+
+ if (!drv_data || fimc->index < 0 || fimc->index >= FIMC_LITE_MAX_DEVS)
+ return -EINVAL;
+
fimc->variant = drv_data->variant[fimc->index];
fimc->pdev = pdev;
@@ -1500,15 +1517,15 @@ static int fimc_lite_probe(struct platform_device *pdev)
mutex_init(&fimc->lock);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- fimc->regs = devm_request_and_ioremap(&pdev->dev, res);
+ fimc->regs = devm_request_and_ioremap(dev, res);
if (fimc->regs == NULL) {
- dev_err(&pdev->dev, "Failed to obtain io memory\n");
+ dev_err(dev, "Failed to obtain io memory\n");
return -ENOENT;
}
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (res == NULL) {
- dev_err(&pdev->dev, "Failed to get IRQ resource\n");
+ dev_err(dev, "Failed to get IRQ resource\n");
return -ENXIO;
}
@@ -1516,10 +1533,10 @@ static int fimc_lite_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = devm_request_irq(&pdev->dev, res->start, flite_irq_handler,
- 0, dev_name(&pdev->dev), fimc);
+ ret = devm_request_irq(dev, res->start, flite_irq_handler,
+ 0, dev_name(dev), fimc);
if (ret) {
- dev_err(&pdev->dev, "Failed to install irq (%d)\n", ret);
+ dev_err(dev, "Failed to install irq (%d)\n", ret);
goto err_clk;
}
@@ -1529,23 +1546,23 @@ static int fimc_lite_probe(struct platform_device *pdev)
goto err_clk;
platform_set_drvdata(pdev, fimc);
- pm_runtime_enable(&pdev->dev);
- ret = pm_runtime_get_sync(&pdev->dev);
+ pm_runtime_enable(dev);
+ ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err_sd;
- fimc->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
+ fimc->alloc_ctx = vb2_dma_contig_init_ctx(dev);
if (IS_ERR(fimc->alloc_ctx)) {
ret = PTR_ERR(fimc->alloc_ctx);
goto err_pm;
}
- pm_runtime_put(&pdev->dev);
+ pm_runtime_put(dev);
[PATCH v4 02/10] s5p-fimc: Add device tree support for FIMC devices
This patch adds support for FIMC devices instantiated from devicetree
for S5PV210 and Exynos4 SoCs. The FIMC IP features include colorspace
conversion and scaling (mem-to-mem) and parallel/MIPI CSI2 bus video
capture interface.
Multiple SoC revisions specific parameters are defined statically in
the driver and are used for both dt and non-dt. The driver's static
data is selected based on the compatible property. Previously the
platform device name was used to match driver data and a specific
SoC/IP version.
Aliases are used to determine an index of the IP which is essential
for linking FIMC IP with other entities, like MIPI-CSIS (the MIPI
CSI-2 bus frontend) or FIMC-LITE and FIMC-IS ISP.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v3:
- added optional clock-frequency property to specify local bus
(FIMCn_LCLK) clock frequency
---
.../devicetree/bindings/media/soc/samsung-fimc.txt | 72 +++
drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
drivers/media/platform/s5p-fimc/fimc-core.c| 93 +---
3 files changed, 135 insertions(+), 32 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
new file mode 100644
index 000..916b2c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt
@@ -0,0 +1,72 @@
+Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC)
+--
+
+The Exynos Camera subsystem comprises of multiple sub-devices that are
+represented by separate platform devices. Some of the IPs come in different
+variants across the SoC revisions (FIMC) and some remain mostly unchanged
+(MIPI CSIS, FIMC-LITE).
+
+All those sub-subdevices are defined as parent nodes of the common device
+node, which also includes common properties of the whole subsystem not really
+specific to any single sub-device, like common camera port pins or external
+clocks for image sensors attached to the SoC.
+
+Common 'camera' node
+
+
+Required properties:
+
+- compatible : must be "samsung,fimc", "simple-bus"
+
+The 'camera' node must include at least one 'fimc' child node.
+
+
+'fimc' device nodes
+---
+
+Required properties:
+
+- compatible : "samsung,s5pv210-fimc" for S5PV210,
+ "samsung,exynos4210-fimc" for Exynos4210,
+ "samsung,exynos4212-fimc" for Exynos4212/4412 SoCs;
+- reg : physical base address and size of the device memory mapped
+ registers;
+- interrupts : FIMC interrupt to the CPU should be described here;
+
+For every fimc node a numbered alias should be present in the aliases node.
+Aliases are of the form fimc, where is an integer (0...N) specifying
+the IP's instance index.
+
+Optional properties
+
+ - clock-frequency - maximum FIMC local clock (LCLK) frequency
+
+Example:
+
+ aliases {
+ csis0 = &csis_0;
+ fimc0 = &fimc_0;
+ };
+
+ camera {
+ compatible = "samsung,fimc", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ status = "okay";
+
+ fimc_0: fimc@1180 {
+ compatible = "samsung,exynos4210-fimc";
+ reg = <0x1180 0x1000>;
+ interrupts = <0 85 0>;
+ status = "okay";
+ };
+
+ csis_0: csis@1188 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1188 0x1000>;
+ interrupts = <0 78 0>;
+ max-data-lanes = <4>;
+ };
+ };
+
+[1] Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index f822b8e..bc84301 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1883,7 +1883,7 @@ int fimc_initialize_capture_subdev(struct fimc_dev *fimc)
v4l2_subdev_init(sd, &fimc_subdev_ops);
sd->flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
- snprintf(sd->name, sizeof(sd->name), "FIMC.%d", fimc->pdev->id);
+ snprintf(sd->name, sizeof(sd->name), "FIMC.%d", fimc->id);
fimc->vid_cap.sd_pads[FIMC_SD_PAD_SINK].flags = MEDIA_PAD_FL_SINK;
fimc->vid_cap.sd_pads[FIMC_SD_PAD_SOURCE].flags = MEDIA_PAD_FL_SOURCE;
diff --git a/drivers/media/platform/s5p-fimc/fimc-core.c
b/drivers/media/platform/s5p-fimc/fimc-core.c
index 29f7bb7..07ca0e0 100644
--- a/drivers/media/platform/s5p-fimc/fimc-core.c
+++ b/drivers/media/platform/s5p-fimc/fimc-core.c
@@ -21,6 +21,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -8
[PATCH v4 01/10] s5p-csis: Add device tree support
s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC
device. This patch support for binding the driver to the MIPI-CSIS
devices instantiated from device tree and for parsing all SoC and
board specific properties.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
Changes since v3:
- dropped 'bus-width' property, hard coded the number of supported
data lanes per device also in dt case, it can be derived from the
compatible property if required;
- "samsung,s5pv210-csis" renamed to "samsung,exynos3110-csis",
updated the bindings description.
---
.../bindings/media/soc/samsung-mipi-csis.txt | 82 +++
drivers/media/platform/s5p-fimc/mipi-csis.c| 154 +++-
drivers/media/platform/s5p-fimc/mipi-csis.h|1 +
3 files changed, 202 insertions(+), 35 deletions(-)
create mode 100644
Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
diff --git a/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
new file mode 100644
index 000..c142272
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt
@@ -0,0 +1,82 @@
+Samsung S5P/EXYNOS SoC MIPI-CSI2 receiver (MIPI CSIS)
+-
+
+Required properties:
+
+- compatible : "samsung,exynos3110-csis" for Exynos3110 (S5PC110, S5PV210)
+SoCs;
+ "samsung,exynos4210-csis" for Exynos4210 (S5PC210, S5PV310)
+ and later SoCs;
+- reg: physical base address and size of the device memory mapped
+ registers;
+- interrupts : should contain MIPI CSIS interrupt; the format of the
+ interrupt specifier depends on the interrupt controller;
+- vddio-supply: MIPI CSIS I/O and PLL voltage supply (e.g. 1.8V);
+- vddcore-supply : MIPI CSIS Core voltage supply (e.g. 1.1V).
+
+Optional properties:
+
+- clock-frequency : The IP's main (system bus) clock frequency in Hz, default
+ value when this property is not specified is 166 MHz;
+- samsung,csis-wclk : CSI-2 wrapper clock selection. If this property is
present
+ external clock from CMU will be used, if not bus clock will
+ be selected.
+
+The device node should contain one 'port' child node with one child 'endpoint'
+node, as outlined in the common media bindings specification. See
+Documentation/devicetree/bindings/media/video-interfaces.txt for details.
+The following are properties specific to these nodes.
+
+port node
+-
+
+- reg: (required) must be 3 for camera C input (CSIS0) or 4 for
+ camera D input (CSIS1);
+
+endpoint node
+-
+
+- data-lanes : (required) an array specifying active physical MIPI-CSI2
+ data input lanes and their mapping to logical lanes; the
+ array's content is unused, only its length is meaningful;
+
+- samsung,csis-hs-settle : (optional) differential receiver (HS-RX) settle
time;
+
+
+Example:
+
+ reg0: regulator@0 {
+ };
+
+ reg1: regulator@1 {
+ };
+
+/* SoC properties */
+
+ aliases {
+ csis0 = &csis_0;
+ };
+
+ csis_0: csis@1188 {
+ compatible = "samsung,exynos4210-csis";
+ reg = <0x1188 0x1000>;
+ interrupts = <0 78 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+/* Board properties */
+
+ csis_0: csis@1188 {
+ clock-frequency = <16600>;
+ vddio-supply = <®0>;
+ vddcore-supply = <®1>;
+ port {
+ reg = <3>; /* 3 - CSIS0, 4 - CSIS1 */
+ csis0_ep: endpoint {
+ remote-endpoint = <...>;
+ data-lanes = <1>, <2>;
+ samsung,csis-hs-settle = <12>;
+ };
+ };
+ };
diff --git a/drivers/media/platform/s5p-fimc/mipi-csis.c
b/drivers/media/platform/s5p-fimc/mipi-csis.c
index 0f5104c..b906bfe 100644
--- a/drivers/media/platform/s5p-fimc/mipi-csis.c
+++ b/drivers/media/platform/s5p-fimc/mipi-csis.c
@@ -19,12 +19,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include "mipi-csis.h"
@@ -113,6 +115,7 @@ static char *csi_clock_name[] = {
[CSIS_CLK_GATE] = "csis",
};
#define NUM_CSIS_CLOCKSARRAY_SIZE(csi_clock_name)
+#define DEFAULT_SCLK_CSIS_FREQ 16600UL
static const char * const csis_supply_name[] = {
"vddcore", /* CSIS Core (1.0V, 1.1V or 1.2V) suppply */
@@ -167,6 +170,11 @@ struct csis_pktbuf {
* @clock: CSIS clocks
* @irq: requested s5p-mipi-csis irq number
* @flags: the st
[PATCH v4 00/10] Device tree support for Exynos SoC camera subsystem
This is an updated patch series adding initial support for the Exynos4 SoC series camera subsystem. It is based on the video interfaces common device tree bindings and depends on patch series [1]. The full source tree can be browsed at [2]. I've dropped the RFC tag from this series and I'm going to continue with adding support for asynchronous sensor subdevs registration and the FIMC-IS on top of it. Unless there are further changes in the bindings. Still, any comments are welcome. The changes are listed in each patch, if any. This series likely won't make it to v3.9. It would be nice, but there seems not to be much interest in getting [1] in the mainline and the reviews are relatively slow. Any Ack/nack from the device tree maintainers are welcome, so I could finally have this patch set merged and carry on with other, even more interesting things. :) Thanks, Sylwester [1] http://www.spinics.net/lists/linux-media/msg59471.html [2] http://git.linuxtv.org/snawrocki/samsung.git/exynos_fimc Sylwester Nawrocki (10): s5p-csis: Add device tree support s5p-fimc: Add device tree support for FIMC devices s5p-fimc: Add device tree support for FIMC-LITE devices s5p-fimc: Add device tree support for the main media device driver s5p-fimc: Add device tree based sensors registration s5p-fimc: Use pinctrl API for camera ports configuration ARM: dts: Add camera to node exynos4.dtsi ARM: dts: Add ISP power domain node for Exynos4x12 ARM: dts: Add FIMC and MIPI CSIS device nodes for Exynos4x12 ARM: dts: Correct camera pinctrl nodes for Exynos4x12 SoCs .../devicetree/bindings/media/soc/samsung-fimc.txt | 183 +++ .../bindings/media/soc/samsung-mipi-csis.txt | 82 + arch/arm/boot/dts/exynos4.dtsi | 64 arch/arm/boot/dts/exynos4x12-pinctrl.dtsi | 26 +- arch/arm/boot/dts/exynos4x12.dtsi | 52 drivers/media/platform/s5p-fimc/fimc-capture.c |2 +- drivers/media/platform/s5p-fimc/fimc-core.c| 94 -- drivers/media/platform/s5p-fimc/fimc-lite.c| 65 ++-- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 319 ++-- drivers/media/platform/s5p-fimc/fimc-mdevice.h |4 + drivers/media/platform/s5p-fimc/mipi-csis.c| 154 +++--- drivers/media/platform/s5p-fimc/mipi-csis.h|1 + include/media/s5p_fimc.h | 17 ++ 13 files changed, 936 insertions(+), 127 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-fimc.txt create mode 100644 Documentation/devicetree/bindings/media/soc/samsung-mipi-csis.txt -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.9] Samsung media driver updates
Mauro, I've added one more patch, here is an updated version: The following changes since commit 520f1fdfb9378b3718c6ce1c3ced5e784cfcaee0: s5p-csis: Fix clock handling on error path in probe() (2013-01-30 18:41:12 +0100) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for_v3.9 for you to fetch changes up to 6c53ab7205e2e64d4c8a26129b3ac1a2980333c2: s5p-fimc: Redefine platform data structure for fimc-is (2013-02-01 19:01:37 +0100) Andrzej Hajda (2): V4L: Add S5C73M3 camera driver MAINTAINERS: Add s5c73m3 driver entry Arun Kumar K (1): s5p-mfc: Fix kernel warning on memory init Kamil Debski (1): s5p-mfc: Fix a watchdog bug Sachin Kamat (7): s5p-mfc: Use NULL instead of 0 for pointer s5p-g2d: Add support for G2D H/W Rev.4.1 s5k6aa: Use devm_regulator_bulk_get API s5p-mfc: Use WARN_ON(condition) directly s5p-csis: Use devm_regulator_bulk_get API s5c73m3: Staticize some symbols s5c73m3: Use devm_regulator_bulk_get API Sylwester Nawrocki (13): s5p-fimc: Fix bytesperline value for V4L2_PIX_FMT_YUV420M format noon010p30: Remove unneeded v4l2 control compatibility ops s5p-fimc: fimc-lite: Remove empty s_power subdev callback s5p-fimc: fimc-lite: Prevent deadlock at STREAMON/OFF ioctls s5p-fimc: Add missing line breaks s5p-fimc: Change platform subdevs registration method s5p-fimc: Check return value of clk_enable/clk_set_rate s5p-csis: Check return value of clk_enable/clk_set_rate s5p-fimc: Avoid null pointer dereference in fimc_capture_ctrls_create() s5p-fimc: Set default image format at device open() s5p-fimc: Fix FIMC.n subdev set_selection ioctl handler s5p-fimc: Add clk_prepare/unprepare for sclk_cam clocks s5p-fimc: Redefine platform data structure for fimc-is MAINTAINERS |7 + arch/arm/mach-exynos/mach-nuri.c|8 +- arch/arm/mach-exynos/mach-universal_c210.c |8 +- arch/arm/mach-s5pv210/mach-goni.c |6 +- drivers/media/i2c/Kconfig |7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/noon010pc30.c |7 - drivers/media/i2c/s5c73m3/Makefile |2 + drivers/media/i2c/s5c73m3/s5c73m3-core.c| 1704 +++ drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c | 563 drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 156 +++ drivers/media/i2c/s5c73m3/s5c73m3.h | 459 ++ drivers/media/i2c/s5k6aa.c |7 +- drivers/media/platform/s5p-fimc/fimc-capture.c | 27 +- drivers/media/platform/s5p-fimc/fimc-core.c | 75 +- drivers/media/platform/s5p-fimc/fimc-core.h |9 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.c | 10 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.h |4 +- drivers/media/platform/s5p-fimc/fimc-lite.c | 60 +- drivers/media/platform/s5p-fimc/fimc-lite.h |2 +- drivers/media/platform/s5p-fimc/fimc-m2m.c | 134 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 276 ++-- drivers/media/platform/s5p-fimc/fimc-mdevice.h |2 +- drivers/media/platform/s5p-fimc/fimc-reg.c | 34 +- drivers/media/platform/s5p-fimc/fimc-reg.h |6 +- drivers/media/platform/s5p-fimc/mipi-csis.c | 37 +- drivers/media/platform/s5p-g2d/g2d-hw.c | 16 +- drivers/media/platform/s5p-g2d/g2d-regs.h |7 + drivers/media/platform/s5p-g2d/g2d.c| 31 +- drivers/media/platform/s5p-g2d/g2d.h| 17 +- drivers/media/platform/s5p-mfc/s5p_mfc.c| 81 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c|2 +- include/media/s5c73m3.h | 55 + include/media/s5p_fimc.h| 49 +- 35 files changed, 3464 insertions(+), 407 deletions(-) create mode 100644 drivers/media/i2c/s5c73m3/Makefile create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-core.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-spi.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3.h create mode 100644 include/media/s5c73m3.h And here are updated and corrected patchwork commands: pwclient update -s accepted 16219 pwclient update -s accepted 16588 pwclient update -s accepted 16311 pwclient update -s accepted 16221 pwclient update -s superseded 16159 pwclient update -s accepted 16289 pwclient update -s accepted 16179 pwclient update -s accepted 16180 pwclient update -s accepted 16250 pwclient update -s accepted 16390 pwclient update -s accepted 16511 pwclient update -s accepted 16569 pwclient update -s accepted 16205 pwclient update -s accepted 16345 pwclient update -s accepted 1
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Kukjin Kim wrote: > Oops, I'm re-sending due to my e-mail client problem :-( > Sylwester Nawrocki wrote: > > > > On 02/01/2013 09:33 AM, Sachin Kamat wrote: > > > On 1 February 2013 06:57, Inki Dae wrote: > > >> > > >> For example, > > >> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be > > >> reasonable. But what if that compatible string is added to exynos4.dtsi?. > > >> This case isn't considered for exynos4412 SoC with v4.1. > > > > > > In case of Exynos4 series the base address of G2D ip is different > > > across series. Hence we cannot define it in exynos4.dtsi and need to > > > define the nodes in exynos4xxx.dtsi or specific board files. Thus we > > > can use the version appended compatible string. > > > > > > However even the second option suggested by Sylwester is OK with me > or > > > to be even more specific we could go for both SoC as well as version > > > option something like this. > > > > > > compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, > > Exynos4210 */ > > > compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, > > Exynos4412 */ > > > > > > In any case please let me know the final preferred one so that I can > > > update the code send the revised patches. > > > > The version with SoC name embedded in it seems most reliable and correct > > to me. > > > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > > S5PV210), > > Exynos4210 */ > > If this convention will be used, I hope, the known name, S5PV210 can be > used. Why don't you use same SoC name with using in arch/arm/? > > > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, > Exynos4412 > > */ > > > > FIMG stands for Fully Interactive Mobile Graphics, and other multimedia > > IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), > > FIMC (Camera), etc. > > > How about MFC? > > > This is just my opinion though, and it seems this is a most common scheme > > from greping the device tree bindings documentation. > > > IMO, you can grep '$ git grep compatible.*samsung'...or IP name. > > > As Stephen pointed out, and I also did in some other mail thread in the > > past, not only an IP revision might be required, but also its integration > > details, specific to an SoC type are important. This actually happens > > to be the case with FIMC, where same version of one instance of the IP > > has more data interfaces routed to other SoC subsystems on one SoC type > > than on other one. > > > Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and > nowadays the EXYNOS SoCs include many Samsung own IPs such as > multimedia. And the IPs are reused on across Samsung SoCs, and I hope on > other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and > can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so > on. How are their IPs implemented in kernel? Why should Samsung use the > SoC name for their IP? And why should we use old SoC name in futre? For > example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, > no one didn't know Samsung should prepare some brand name or future at > that time...Just I don't want to undergo trial and error again. I'm still > saying > why Samsung own IPs cannot be used as IP vendors' ones... > > > I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0" > > Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... > > > for all IPs. And I would much more like to see a uniform naming convention > > used, rather than living with a chaotic set of compatible properties, that > > has a potential to become even more chaotic in the future. > Thanks. - Kukjin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 5/5] s5p-fimc: Redefine platform data structure for fimc-is
Sylwester Nawrocki wrote: > > On 01/30/2013 06:23 PM, Sylwester Nawrocki wrote: > > Newer Exynos4 SoC are equipped with a local camera ISP that > > controls external raw image sensor directly. Such sensors > > can be connected through FIMC-LITEn (and MIPI-CSISn) IPs to > > the ISP, which then feeds image data to the FIMCn IP. Thus > > there can be two busses associated with an image source > > (sensor). Rename struct s5p_fimc_isp_info describing external > > image sensor (video decoder) to struct fimc_source_info to > > avoid confusion. bus_type is split into fimc_bus_type and > > sensor_bus_type. The bus type enumeration is extended to > > include both FIMC Writeback input types. > > > > The bus_type enumeration and the data structure name in the > > board files are modified according to the above changes. > > > > Cc: Kukjin Kim > > Cc: linux-samsung-...@vger.kernel.org > > Signed-off-by: Sylwester Nawrocki > > Signed-off-by: Kyungmin Park > > Kukjin, can I please have your ack on this patch so it can be > merged through the media tree ? > Sure, why not? Please go ahead with my ack: Acked-by: Kukjin Kim -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
Sylwester Nawrocki wrote: > > On 02/01/2013 09:33 AM, Sachin Kamat wrote: > > On 1 February 2013 06:57, Inki Dae wrote: > >> > >> For example, > >> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be > >> reasonable. But what if that compatible string is added to exynos4.dtsi?. > >> This case isn't considered for exynos4412 SoC with v4.1. > > > > In case of Exynos4 series the base address of G2D ip is different > > across series. Hence we cannot define it in exynos4.dtsi and need to > > define the nodes in exynos4xxx.dtsi or specific board files. Thus we > > can use the version appended compatible string. > > > > However even the second option suggested by Sylwester is OK with me or > > to be even more specific we could go for both SoC as well as version > > option something like this. > > > > compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, > Exynos4210 */ > > compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, > Exynos4412 */ > > > > In any case please let me know the final preferred one so that I can > > update the code send the revised patches. > > The version with SoC name embedded in it seems most reliable and correct > to me. > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > S5PV210), > Exynos4210 */ If this convention will be used, I hope, the known name, S5PV210 can be used. Why don't you use same SoC name with using in arch/arm/? > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 > */ > > FIMG stands for Fully Interactive Mobile Graphics, and other multimedia > IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), > FIMC (Camera), etc. > How about MFC? > This is just my opinion though, and it seems this is a most common scheme > from greping the device tree bindings documentation. > IMO, you can grep '$ git grep compatible.*samsung'...or IP name. > As Stephen pointed out, and I also did in some other mail thread in the > past, not only an IP revision might be required, but also its integration > details, specific to an SoC type are important. This actually happens > to be the case with FIMC, where same version of one instance of the IP > has more data interfaces routed to other SoC subsystems on one SoC type > than on other one. > Well, I don't think so. As you know Samsung makes many EXYNOS SoCs and nowadays the EXYNOS SoCs include many Samsung own IPs such as multimedia. And the IPs are reused on across Samsung SoCs, and I hope on other SoC vendor's SoC. It means Samsung is no longer just SoC vendor and can be called IP vendor. So let's see other IP vendors, ARM, Synopsys and so on. How are their IPs implemented in kernel? Why should Samsung use the SoC name for their IP? And why should we use old SoC name in futre? For example, see the s3c2410-xxx for i2c, wdt, rtc, i2s and so on. Unfortunately, no one didn't know Samsung should prepare some brand name or future at that time...Just I don't want to undergo trial and error again. I'm still saying why Samsung own IPs cannot be used as IP vendors' ones... > I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0" Hmm...I think, the name, 'EXYNOS' is not a brand name for IP... > for all IPs. And I would much more like to see a uniform naming convention > used, rather than living with a chaotic set of compatible properties, that > has a potential to become even more chaotic in the future. > Thanks. - Kukjin -- 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 v3 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
On Fri, Feb 1, 2013 at 6:59 AM, Vikas Sajjan wrote:
> This patch adds display-timing node parsing using video helper function
>
> Signed-off-by: Leela Krishna Amudala
> Signed-off-by: Vikas Sajjan
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39
> +++---
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index bf0d9ba..8eee13f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -905,16 +906,46 @@ static int __devinit fimd_probe(struct platform_device
> *pdev)
> struct exynos_drm_subdrv *subdrv;
> struct exynos_drm_fimd_pdata *pdata;
> struct exynos_drm_panel_info *panel;
> + struct fb_videomode *fbmode;
> + struct pinctrl *pctrl;
> struct resource *res;
> int win;
> int ret = -EINVAL;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> - pdata = pdev->dev.platform_data;
> - if (!pdata) {
> - dev_err(dev, "no platform data specified\n");
> - return -EINVAL;
> + if (pdev->dev.of_node) {
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + DRM_ERROR("memory allocation for pdata failed\n");
> + return -ENOMEM;
> + }
> +
> + fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
> + if (!fbmode) {
> + DRM_ERROR("memory allocation for fbmode failed\n");
> + return -ENOMEM;
> + }
> +
> + ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
> + if (ret) {
> + DRM_ERROR("failed to get fb_videomode\n");
> + return -EINVAL;
This should probably return ret instead of -EINVAL. It would also be
useful to print ret in the error msg.
> + }
> + pdata->panel.timing = (struct fb_videomode) *fbmode;
> +
> + pctrl = devm_pinctrl_get_select_default(dev);
> + if (IS_ERR(pctrl)) {
> + DRM_ERROR("no pinctrl data provided.\n");
> + return -EINVAL;
I think the error message here is misleading. If there's no pinctrl
provided, doesn't get_select_default return NULL? In which case, this
error would never be printed?
I think this behavior is actually desired since there is no pinctrl
for exynos5 and we don't want it to break. However I think your error
should be more along the lines of "pinctrl_get_select_default failed".
You should also print and return PTR_RET(pctrl) instead of EINVAL.
Sean
> + }
> +
> + } else {
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + DRM_ERROR("no platform data specified\n");
> + return -EINVAL;
> + }
> }
>
> panel = &pdata->panel;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: WinTV-HVR-1400: scandvb (and kaffeine) fails to find any channels
On Fri, Feb 1, 2013 at 9:16 AM, Chris Clayton wrote: > I've got some more diagnostics. I tuned on the 12c debugging in the cx23885 > driver and ran the scan again. Surprisingly, the scan found 22 channels on a > single frequency (that carries the BBC channels). I've attached two files - > the output from dvbscan and the kernel log covering the loading of the > drivers and running the scan. > > I'm no kernel guru, but is it possible that the root cause of the scan > failures is a timing problem which is being partially offset by the time > taken to produce all the debug output? w_scan does have some arguments that let you increase the timeout for tuning. You may wish to see if that has any effect. Maybe the w_scan timeout is just too short for that device. 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
[GIT PULL FOR 3.9] Samsung media driver updates
Hi Mauro, The following change set includes various fixes and cleanups for the S5P/Exynos SoC media drivers (camera, video codec, g2d), some Samsung camera sensor driver updates and a new driver for the S5C73M3 camera. The branch is on top of staging/for_v3.9 branch and a bugfix patch that was in my previous pull request [1]. [1] http://patchwork.linuxtv.org/patch/16317 The following changes since commit 520f1fdfb9378b3718c6ce1c3ced5e784cfcaee0: s5p-csis: Fix clock handling on error path in probe() (2013-01-30 18:41:12 +0100) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for_v3.9 for you to fetch changes up to 50c26256ca6bb8723da296edb8df0863663d871c: MAINTAINERS: Add s5c73m3 driver entry (2013-02-01 13:50:51 +0100) Andrzej Hajda (2): V4L: Add S5C73M3 camera driver MAINTAINERS: Add s5c73m3 driver entry Arun Kumar K (1): s5p-mfc: Fix kernel warning on memory init Kamil Debski (1): s5p-mfc: Fix a watchdog bug Sachin Kamat (7): s5p-mfc: Use NULL instead of 0 for pointer s5p-g2d: Add support for G2D H/W Rev.4.1 s5k6aa: Use devm_regulator_bulk_get API s5p-mfc: Use WARN_ON(condition) directly s5p-csis: Use devm_regulator_bulk_get API s5c73m3: Staticize some symbols s5c73m3: Use devm_regulator_bulk_get API Sylwester Nawrocki (12): s5p-fimc: Fix bytesperline value for V4L2_PIX_FMT_YUV420M format noon010p30: Remove unneeded v4l2 control compatibility ops s5p-fimc: fimc-lite: Remove empty s_power subdev callback s5p-fimc: fimc-lite: Prevent deadlock at STREAMON/OFF ioctls s5p-fimc: Add missing line breaks s5p-fimc: Change platform subdevs registration method s5p-fimc: Check return value of clk_enable/clk_set_rate s5p-csis: Check return value of clk_enable/clk_set_rate s5p-fimc: Avoid null pointer dereference in fimc_capture_ctrls_create() s5p-fimc: Set default image format at device open() s5p-fimc: Fix FIMC.n subdev set_selection ioctl handler s5p-fimc: Add clk_prepare/unprepare for sclk_cam clocks MAINTAINERS |7 + drivers/media/i2c/Kconfig |7 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/noon010pc30.c |7 - drivers/media/i2c/s5c73m3/Makefile |2 + drivers/media/i2c/s5c73m3/s5c73m3-core.c| 1704 +++ drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c | 563 drivers/media/i2c/s5c73m3/s5c73m3-spi.c | 156 +++ drivers/media/i2c/s5c73m3/s5c73m3.h | 459 ++ drivers/media/i2c/s5k6aa.c |7 +- drivers/media/platform/s5p-fimc/fimc-capture.c | 27 +- drivers/media/platform/s5p-fimc/fimc-core.c | 75 +- drivers/media/platform/s5p-fimc/fimc-core.h |9 +- drivers/media/platform/s5p-fimc/fimc-lite-reg.c |2 +- drivers/media/platform/s5p-fimc/fimc-lite.c | 60 +- drivers/media/platform/s5p-fimc/fimc-lite.h |2 +- drivers/media/platform/s5p-fimc/fimc-m2m.c | 134 +- drivers/media/platform/s5p-fimc/fimc-mdevice.c | 260 ++-- drivers/media/platform/s5p-fimc/mipi-csis.c | 37 +- drivers/media/platform/s5p-g2d/g2d-hw.c | 16 +- drivers/media/platform/s5p-g2d/g2d-regs.h |7 + drivers/media/platform/s5p-g2d/g2d.c| 31 +- drivers/media/platform/s5p-g2d/g2d.h| 17 +- drivers/media/platform/s5p-mfc/s5p_mfc.c| 81 +- drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc_opr.c|2 +- include/media/s5c73m3.h | 55 + 27 files changed, 3385 insertions(+), 345 deletions(-) create mode 100644 drivers/media/i2c/s5c73m3/Makefile create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-core.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-ctrls.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3-spi.c create mode 100644 drivers/media/i2c/s5c73m3/s5c73m3.h create mode 100644 include/media/s5c73m3.h The corresponding patchwork commands are: pwclient -s accepted 16219 pwclient -s accepted 16588 pwclient -s accepted 16311 pwclient -s accepted 16221 pwclient -s superseded 16159 pwclient -s accepted 16289 pwclient -s accepted 16179 pwclient -s accepted 16180 pwclient -s accepted 16250 pwclient -s accepted 16390 pwclient -s accepted 16511 pwclient -s accepted 16569 pwclient -s accepted 16205 pwclient -s accepted 16345 pwclient -s accepted 16312 pwclient -s accepted 16313 pwclient -s accepted 16431 pwclient -s accepted 16432 pwclient -s accepted 16556 pwclient -s accepted 16557 pwclient -s accepted 16558 pwclient -s accepted 16559 pwclient -s accepted 16561 --- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@
Re: [PATCH RFC] media: Rename media_entity_remote_source to media_entity_remote_pad
Hi Andrzej, Thanks for the patch. On 01/22/2013 09:24 AM, Andrzej Hajda wrote: > Function media_entity_remote_source actually returns the remote pad to > the given one, regardless if this is the source or the sink pad. > Name media_entity_remote_pad is more adequate for this function. > > Signed-off-by: Andrzej Hajda > Signed-off-by: Kyungmin Park Acked-by: Sylwester Nawrocki > --- > Documentation/media-framework.txt|2 +- > drivers/media/media-entity.c | 13 ++--- > drivers/media/platform/omap3isp/isp.c|6 +++--- > drivers/media/platform/omap3isp/ispccdc.c|2 +- > drivers/media/platform/omap3isp/ispccp2.c|2 +- > drivers/media/platform/omap3isp/ispcsi2.c|2 +- > drivers/media/platform/omap3isp/ispvideo.c |6 +++--- > drivers/media/platform/s3c-camif/camif-capture.c |2 +- > drivers/media/platform/s5p-fimc/fimc-capture.c |8 > drivers/media/platform/s5p-fimc/fimc-lite.c |4 ++-- > drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +- > drivers/staging/media/davinci_vpfe/vpfe_video.c | 12 ++-- > include/media/media-entity.h |2 +- > 13 files changed, 31 insertions(+), 32 deletions(-) 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: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
2013. 2. 1. 오후 8:52 Inki Dae 작성: > > >> -Original Message- >> From: linux-media-ow...@vger.kernel.org [mailto:linux-media- >> ow...@vger.kernel.org] On Behalf Of Sachin Kamat >> Sent: Friday, February 01, 2013 8:40 PM >> To: Inki Dae >> Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- >> me...@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree- >> disc...@lists.ozlabs.org; patc...@linaro.org >> Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery >> support for G2D >> >> On 1 February 2013 17:02, Inki Dae wrote: >>> >>> How about using like below? >>>Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, >>> Exynos4412 */ >>> It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is >> for >>> exynos4212 and exynos4412. >> >> AFAIK, compatible strings are not supposed to have any wildcard > characters. >> Compatible string should suggest the first SoC that contained this IP. >> Hence IMO 4212 is OK. >> Oops, one more thing. AFAIK Exynos4210 also has fimg-2d ip. In this case, we should use "samsung,exynos4210-fimg-2d" as comparible string and add it to exynos4210.dtsi? And please check if exynos4212 and 4412 SoCs have same fimg-2d ip. If it's different, we might need to add ip version property or compatible string to each dtsi file to identify the ip version. Sorry but give me your opinions. Thanks, Inki Dae > > Got it. Please post it again. > >> >> -- >> With warm regards, >> Sachin >> -- >> 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 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
[RFC PATCH 2/6] tm6000: convert to the control framework.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/usb/tm6000/tm6000-video.c | 232 +--
drivers/media/usb/tm6000/tm6000.h |3 +
2 files changed, 68 insertions(+), 167 deletions(-)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index 7a653b2..4329fbc 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -63,71 +63,6 @@ static bool keep_urb;/* keep urb
buffers allocated */
int tm6000_debug;
EXPORT_SYMBOL_GPL(tm6000_debug);
-static const struct v4l2_queryctrl no_ctrl = {
- .name = "42",
- .flags = V4L2_CTRL_FLAG_DISABLED,
-};
-
-/* supported controls */
-static struct v4l2_queryctrl tm6000_qctrl[] = {
- {
- .id= V4L2_CID_BRIGHTNESS,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = "Brightness",
- .minimum = 0,
- .maximum = 255,
- .step = 1,
- .default_value = 54,
- .flags = 0,
- }, {
- .id= V4L2_CID_CONTRAST,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = "Contrast",
- .minimum = 0,
- .maximum = 255,
- .step = 0x1,
- .default_value = 119,
- .flags = 0,
- }, {
- .id= V4L2_CID_SATURATION,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = "Saturation",
- .minimum = 0,
- .maximum = 255,
- .step = 0x1,
- .default_value = 112,
- .flags = 0,
- }, {
- .id= V4L2_CID_HUE,
- .type = V4L2_CTRL_TYPE_INTEGER,
- .name = "Hue",
- .minimum = -128,
- .maximum = 127,
- .step = 0x1,
- .default_value = 0,
- .flags = 0,
- },
- /* --- audio --- */
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = "Mute",
- .minimum = 0,
- .maximum = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- }, {
- .id= V4L2_CID_AUDIO_VOLUME,
- .name = "Volume",
- .minimum = -15,
- .maximum = 15,
- .step = 1,
- .default_value = 0,
- .type = V4L2_CTRL_TYPE_INTEGER,
- }
-};
-
-static const unsigned int CTRLS = ARRAY_SIZE(tm6000_qctrl);
-static int qctl_regs[ARRAY_SIZE(tm6000_qctrl)];
-
static struct tm6000_fmt format[] = {
{
.name = "4:2:2, packed, YVY2",
@@ -144,16 +79,6 @@ static struct tm6000_fmt format[] = {
}
};
-static const struct v4l2_queryctrl *ctrl_by_id(unsigned int id)
-{
- unsigned int i;
-
- for (i = 0; i < CTRLS; i++)
- if (tm6000_qctrl[i].id == id)
- return tm6000_qctrl+i;
- return NULL;
-}
-
/* --
* DMA and thread functions
* --
@@ -1215,79 +1140,40 @@ static int vidioc_s_input(struct file *file, void
*priv, unsigned int i)
}
/* --- controls -- */
-static int vidioc_queryctrl(struct file *file, void *priv,
- struct v4l2_queryctrl *qc)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(tm6000_qctrl); i++)
- if (qc->id && qc->id == tm6000_qctrl[i].id) {
- memcpy(qc, &(tm6000_qctrl[i]),
- sizeof(*qc));
- return 0;
- }
-
- return -EINVAL;
-}
-static int vidioc_g_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
+static int tm6000_s_ctrl(struct v4l2_ctrl *ctrl)
{
- struct tm6000_fh *fh = priv;
- struct tm6000_core *dev= fh->dev;
- int val;
+ struct tm6000_core *dev = container_of(ctrl->handler, struct
tm6000_core, ctrl_handler);
+ u8 val = ctrl->val;
- /* FIXME: Probably, those won't work! Maybe we need shadow regs */
switch (ctrl->id) {
case V4L2_CID_CONTRAST:
- val = tm6000_get_reg(dev, TM6010_REQ07_R08_LUMA_CONTRAST_ADJ,
0);
- break;
+ tm6000_set_reg(dev, TM6010_REQ07_R08_LUMA_CONTRAST_ADJ, val);
+ return 0;
case V4L2_CID_BRIGHTNESS:
- val = tm6000_get_reg(dev, TM6010_REQ07_R09_LUMA_BRIGHTNESS_ADJ,
[RFC PATCH 3/6] tm6000: add support for control events and prio handling.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/usb/tm6000/tm6000-video.c | 31 +++
drivers/media/usb/tm6000/tm6000.h |2 ++
2 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index 4329fbc..25202a7 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1350,6 +1351,7 @@ static int __tm6000_open(struct file *file)
return -ENOMEM;
}
+ v4l2_fh_init(&fh->fh, vdev);
file->private_data = fh;
fh->dev = dev;
fh->radio= radio;
@@ -1393,6 +1395,7 @@ static int __tm6000_open(struct file *file)
tm6000_prepare_isoc(dev);
tm6000_start_thread(dev);
}
+ v4l2_fh_add(&fh->fh);
return 0;
}
@@ -1433,29 +1436,35 @@ tm6000_read(struct file *file, char __user *data,
size_t count, loff_t *pos)
static unsigned int
__tm6000_poll(struct file *file, struct poll_table_struct *wait)
{
+ unsigned long req_events = poll_requested_events(wait);
struct tm6000_fh*fh = file->private_data;
struct tm6000_buffer*buf;
+ int res = 0;
+ if (v4l2_event_pending(&fh->fh))
+ res = POLLPRI;
+ else if (req_events & POLLPRI)
+ poll_wait(file, &fh->fh.wait, wait);
if (V4L2_BUF_TYPE_VIDEO_CAPTURE != fh->type)
- return POLLERR;
+ return res | POLLERR;
if (!!is_res_streaming(fh->dev, fh))
- return POLLERR;
+ return res | POLLERR;
if (!is_res_read(fh->dev, fh)) {
/* streaming capture */
if (list_empty(&fh->vb_vidq.stream))
- return POLLERR;
+ return res | POLLERR;
buf = list_entry(fh->vb_vidq.stream.next, struct tm6000_buffer,
vb.stream);
- } else {
+ } else if (req_events & (POLLIN | POLLRDNORM)) {
/* read() capture */
- return videobuf_poll_stream(file, &fh->vb_vidq, wait);
+ return res | videobuf_poll_stream(file, &fh->vb_vidq, wait);
}
poll_wait(file, &buf->vb.done, wait);
if (buf->vb.state == VIDEOBUF_DONE ||
buf->vb.state == VIDEOBUF_ERROR)
- return POLLIN | POLLRDNORM;
- return 0;
+ return res | POLLIN | POLLRDNORM;
+ return res;
}
static unsigned int tm6000_poll(struct file *file, struct poll_table_struct
*wait)
@@ -1505,7 +1514,8 @@ static int tm6000_release(struct file *file)
if (!fh->radio)
videobuf_mmap_free(&fh->vb_vidq);
}
-
+ v4l2_fh_del(&fh->fh);
+ v4l2_fh_exit(&fh->fh);
kfree(fh);
mutex_unlock(&dev->lock);
@@ -1555,6 +1565,8 @@ static const struct v4l2_ioctl_ops video_ioctl_ops = {
.vidioc_querybuf = vidioc_querybuf,
.vidioc_qbuf = vidioc_qbuf,
.vidioc_dqbuf = vidioc_dqbuf,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
static struct video_device tm6000_template = {
@@ -1579,6 +1591,8 @@ static const struct v4l2_ioctl_ops radio_ioctl_ops = {
.vidioc_s_tuner = radio_s_tuner,
.vidioc_g_frequency = vidioc_g_frequency,
.vidioc_s_frequency = vidioc_s_frequency,
+ .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+ .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
static struct video_device tm6000_radio_template = {
@@ -1607,6 +1621,7 @@ static struct video_device *vdev_init(struct tm6000_core
*dev,
vfd->release = video_device_release;
vfd->debug = tm6000_debug;
vfd->lock = &dev->lock;
+ set_bit(V4L2_FL_USE_FH_PRIO, &vfd->flags);
snprintf(vfd->name, sizeof(vfd->name), "%s %s", dev->name, type_name);
diff --git a/drivers/media/usb/tm6000/tm6000.h
b/drivers/media/usb/tm6000/tm6000.h
index a9ac262..08bd074 100644
--- a/drivers/media/usb/tm6000/tm6000.h
+++ b/drivers/media/usb/tm6000/tm6000.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include "dvb_demux.h"
@@ -290,6 +291,7 @@ struct tm6000_ops {
};
struct tm6000_fh {
+ struct v4l2_fh fh;
struct tm6000_core *dev;
unsigned int radio;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 6/6] tm6000: fix G/TRY_FMT.
From: Hans Verkuil
Two fixes:
- the priv field wasn't set to 0.
- only V4L2_FIELD_INTERLACED is supported.
Signed-off-by: Hans Verkuil
---
drivers/media/usb/tm6000/tm6000-video.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index f41dbb1..eab2341 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -918,6 +918,7 @@ static int vidioc_g_fmt_vid_cap(struct file *file, void
*priv,
(f->fmt.pix.width * fh->fmt->depth) >> 3;
f->fmt.pix.sizeimage =
f->fmt.pix.height * f->fmt.pix.bytesperline;
+ f->fmt.pix.priv = 0;
return 0;
}
@@ -948,12 +949,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
field = f->fmt.pix.field;
- if (field == V4L2_FIELD_ANY)
- field = V4L2_FIELD_SEQ_TB;
- else if (V4L2_FIELD_INTERLACED != field) {
- dprintk(dev, V4L2_DEBUG_IOCTL_ARG, "Field type invalid.\n");
- return -EINVAL;
- }
+ field = V4L2_FIELD_INTERLACED;
tm6000_get_std_res(dev);
@@ -963,6 +959,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void
*priv,
f->fmt.pix.width &= ~0x01;
f->fmt.pix.field = field;
+ f->fmt.pix.priv = 0;
f->fmt.pix.bytesperline =
(f->fmt.pix.width * fmt->depth) >> 3;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 5/6] tm6000: add poll op for radio device node.
From: Hans Verkuil
Signed-off-by: Hans Verkuil
---
drivers/media/usb/tm6000/tm6000-video.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index ac25885..f41dbb1 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -1583,6 +1583,7 @@ static struct video_device tm6000_template = {
static const struct v4l2_file_operations radio_fops = {
.owner = THIS_MODULE,
.open = tm6000_open,
+ .poll = v4l2_ctrl_poll,
.release= tm6000_release,
.unlocked_ioctl = video_ioctl2,
};
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 4/6] tm6000: set colorspace field.
From: Hans Verkuil Signed-off-by: Hans Verkuil --- drivers/media/usb/tm6000/tm6000-video.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/tm6000/tm6000-video.c b/drivers/media/usb/tm6000/tm6000-video.c index 25202a7..ac25885 100644 --- a/drivers/media/usb/tm6000/tm6000-video.c +++ b/drivers/media/usb/tm6000/tm6000-video.c @@ -913,6 +913,7 @@ static int vidioc_g_fmt_vid_cap(struct file *file, void *priv, f->fmt.pix.height = fh->height; f->fmt.pix.field= fh->vb_vidq.field; f->fmt.pix.pixelformat = fh->fmt->fourcc; + f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; f->fmt.pix.bytesperline = (f->fmt.pix.width * fh->fmt->depth) >> 3; f->fmt.pix.sizeimage = @@ -967,6 +968,7 @@ static int vidioc_try_fmt_vid_cap(struct file *file, void *priv, (f->fmt.pix.width * fmt->depth) >> 3; f->fmt.pix.sizeimage = f->fmt.pix.height * f->fmt.pix.bytesperline; + f->fmt.pix.colorspace = V4L2_COLORSPACE_SMPTE170M; return 0; } -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 1/6] tm6000: fix querycap and input/tuner compliance issues.
From: Hans Verkuil
- add device_caps support
- fix bus_info
- fix numerous tuner-related problems due to incorrect tests
and setting v4l2_tuner fields to wrong values.
- remove (audio) input support from the radio: it doesn't belong
there. This also fixed a nasty issue where opening the radio
would set dev->input to 5 for no good reason. This was never
set back to a valid TV input after closing the radio device,
thus leaving it at 5 which is out of bounds of the vinput
card array.
Signed-off-by: Hans Verkuil
---
drivers/media/usb/tm6000/tm6000-video.c | 147 +++
1 file changed, 31 insertions(+), 116 deletions(-)
diff --git a/drivers/media/usb/tm6000/tm6000-video.c
b/drivers/media/usb/tm6000/tm6000-video.c
index e3c567c..7a653b2 100644
--- a/drivers/media/usb/tm6000/tm6000-video.c
+++ b/drivers/media/usb/tm6000/tm6000-video.c
@@ -948,16 +948,21 @@ static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
struct tm6000_core *dev = ((struct tm6000_fh *)priv)->dev;
+ struct video_device *vdev = video_devdata(file);
strlcpy(cap->driver, "tm6000", sizeof(cap->driver));
strlcpy(cap->card, "Trident TVMaster TM5600/6000/6010",
sizeof(cap->card));
- cap->capabilities = V4L2_CAP_VIDEO_CAPTURE |
- V4L2_CAP_STREAMING |
- V4L2_CAP_AUDIO |
- V4L2_CAP_READWRITE;
-
+ usb_make_path(dev->udev, cap->bus_info, sizeof(cap->bus_info));
if (dev->tuner_type != TUNER_ABSENT)
- cap->capabilities |= V4L2_CAP_TUNER;
+ cap->device_caps |= V4L2_CAP_TUNER;
+ if (vdev->vfl_type == VFL_TYPE_GRABBER)
+ cap->device_caps |= V4L2_CAP_VIDEO_CAPTURE |
+ V4L2_CAP_STREAMING |
+ V4L2_CAP_READWRITE;
+ else
+ cap->device_caps |= V4L2_CAP_RADIO;
+ cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS |
+ V4L2_CAP_RADIO | V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE;
return 0;
}
@@ -965,7 +970,7 @@ static int vidioc_querycap(struct file *file, void *priv,
static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
- if (unlikely(f->index >= ARRAY_SIZE(format)))
+ if (f->index >= ARRAY_SIZE(format))
return -EINVAL;
strlcpy(f->description, format[f->index].name, sizeof(f->description));
@@ -1301,14 +1306,14 @@ static int vidioc_g_tuner(struct file *file, void *priv,
struct tm6000_fh *fh = priv;
struct tm6000_core *dev = fh->dev;
- if (unlikely(UNSET == dev->tuner_type))
- return -EINVAL;
+ if (UNSET == dev->tuner_type)
+ return -ENOTTY;
if (0 != t->index)
return -EINVAL;
strcpy(t->name, "Television");
t->type = V4L2_TUNER_ANALOG_TV;
- t->capability = V4L2_TUNER_CAP_NORM;
+ t->capability = V4L2_TUNER_CAP_NORM | V4L2_TUNER_CAP_STEREO;
t->rangehigh = 0xUL;
t->rxsubchans = V4L2_TUNER_SUB_STEREO;
@@ -1326,11 +1331,14 @@ static int vidioc_s_tuner(struct file *file, void *priv,
struct tm6000_core *dev = fh->dev;
if (UNSET == dev->tuner_type)
- return -EINVAL;
+ return -ENOTTY;
if (0 != t->index)
return -EINVAL;
- dev->amode = t->audmode;
+ if (t->audmode > V4L2_TUNER_MODE_STEREO)
+ dev->amode = V4L2_TUNER_MODE_STEREO;
+ else
+ dev->amode = t->audmode;
dprintk(dev, 3, "audio mode: %x\n", t->audmode);
v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_tuner, t);
@@ -1344,10 +1352,11 @@ static int vidioc_g_frequency(struct file *file, void
*priv,
struct tm6000_fh *fh = priv;
struct tm6000_core *dev = fh->dev;
- if (unlikely(UNSET == dev->tuner_type))
+ if (UNSET == dev->tuner_type)
+ return -ENOTTY;
+ if (f->tuner)
return -EINVAL;
- f->type = fh->radio ? V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
f->frequency = dev->freq;
v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, g_frequency, f);
@@ -1361,13 +1370,9 @@ static int vidioc_s_frequency(struct file *file, void
*priv,
struct tm6000_fh *fh = priv;
struct tm6000_core *dev = fh->dev;
- if (unlikely(UNSET == dev->tuner_type))
- return -EINVAL;
- if (unlikely(f->tuner != 0))
- return -EINVAL;
- if (0 == fh->radio && V4L2_TUNER_ANALOG_TV != f->type)
- return -EINVAL;
- if (1 == fh->radio && V4L2_TUNER_RADIO != f->type)
+ if (UNSET == dev->tuner_type)
+ return -ENOTTY;
+ if (f->tuner != 0)
[RFC PATCH 0/6] tm6000: v4l2-compliance fixes
This patch series is also based on work I did a few months ago. This fixes all v4l2-compliance failures except for two: fail: v4l2-test-formats.cpp(698): Global format mismatch: 56595559/720x480 vs 59565955/720x480 This is due to the fact that the format is stored in the fh struct instead of globally. Something to work on in a future patch as that's quite a bit more work. fail: v4l2-test-buffers.cpp(109): can_stream && !mmap_valid && !userptr_valid && !dmabuf_valid This is due to the fact that tm6000 doesn't support vb2. Again, more work than I have time for now. All the other fixes have been done, the conversion to the control framework being the most important. 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
[PATCH v3 1/1] video: drm: exynos: Adds display-timing node parsing using video helper function
This patch adds display-timing node parsing using video helper function
Signed-off-by: Leela Krishna Amudala
Signed-off-by: Vikas Sajjan
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 +++---
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index bf0d9ba..8eee13f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -905,16 +906,46 @@ static int __devinit fimd_probe(struct platform_device
*pdev)
struct exynos_drm_subdrv *subdrv;
struct exynos_drm_fimd_pdata *pdata;
struct exynos_drm_panel_info *panel;
+ struct fb_videomode *fbmode;
+ struct pinctrl *pctrl;
struct resource *res;
int win;
int ret = -EINVAL;
DRM_DEBUG_KMS("%s\n", __FILE__);
- pdata = pdev->dev.platform_data;
- if (!pdata) {
- dev_err(dev, "no platform data specified\n");
- return -EINVAL;
+ if (pdev->dev.of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ DRM_ERROR("memory allocation for pdata failed\n");
+ return -ENOMEM;
+ }
+
+ fbmode = devm_kzalloc(dev, sizeof(*fbmode), GFP_KERNEL);
+ if (!fbmode) {
+ DRM_ERROR("memory allocation for fbmode failed\n");
+ return -ENOMEM;
+ }
+
+ ret = of_get_fb_videomode(dev->of_node, fbmode, -1);
+ if (ret) {
+ DRM_ERROR("failed to get fb_videomode\n");
+ return -EINVAL;
+ }
+ pdata->panel.timing = (struct fb_videomode) *fbmode;
+
+ pctrl = devm_pinctrl_get_select_default(dev);
+ if (IS_ERR(pctrl)) {
+ DRM_ERROR("no pinctrl data provided.\n");
+ return -EINVAL;
+ }
+
+ } else {
+ pdata = pdev->dev.platform_data;
+ if (!pdata) {
+ DRM_ERROR("no platform data specified\n");
+ return -EINVAL;
+ }
}
panel = &pdata->panel;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/1] Adds display-timing node parsing to exynos drm fimd
This patch adds display-timing node parsing to drm fimd, this depends on the display helper patchset at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html It also adds pinctrl support for drm fimd. changes since v2: - moved 'devm_pinctrl_get_select_default' function call under 'if (pdev->dev.of_node)', this makes NON-DT code unchanged. (reported by: Rahul Sharma ) changes since v1: - addressed comments from Sean Paul patch is based on branch "exynos-drm-next" at http://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git Is tested on Exynos5250 and Exynos4412 by applying dependent patches available at http://lists.freedesktop.org/archives/dri-devel/2013-January/033998.html Vikas Sajjan (1): video: drm: exynos: Adds display-timing node parsing using video helper function drivers/gpu/drm/exynos/exynos_drm_fimd.c | 39 +++--- 1 file changed, 35 insertions(+), 4 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Sachin Kamat > Sent: Friday, February 01, 2013 8:40 PM > To: Inki Dae > Cc: Sylwester Nawrocki; Kukjin Kim; Sylwester Nawrocki; linux- > me...@vger.kernel.org; dri-de...@lists.freedesktop.org; devicetree- > disc...@lists.ozlabs.org; patc...@linaro.org > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > On 1 February 2013 17:02, Inki Dae wrote: > > > > How about using like below? > > Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, > > Exynos4412 */ > > It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is > for > > exynos4212 and exynos4412. > > AFAIK, compatible strings are not supposed to have any wildcard characters. > Compatible string should suggest the first SoC that contained this IP. > Hence IMO 4212 is OK. > Got it. Please post it again. > > -- > With warm regards, > Sachin > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: media_build: getting a TerraTec H7 working?
Hi, On Fri, Feb 1, 2013 at 9:07 AM, Mauro Carvalho Chehab wrote: > > Well, I prefer to not use w_scan for DVB-C. It will take a long time to > run, as it will try a large number of possibilities and still it might > not find the channels, if your cable operator is using some weird setup I don't think my cable operator is doing anything weird. As I wrote in my original post: " (using a different DVBC-adapter, w_scan finds almost 200 channels)". FWIW, w_scan completes in about 30 minutes here. > > w_scan by default tries only QAM-64 and QAM-256, as those are the typical > modulation types used, but it is up to your cable operator to decide. They > might be doing something weird. See my comment above; w_scan works with another DVB-C adapter, and finds almost 200 channels. Why wouldn't it work with the H7? > It should be noticed that DVB-C2 is not supported by this frontend. Noted. Not that I think it matters for me. -- Regards, Torfinn Ingolfsen -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 1 February 2013 17:02, Inki Dae wrote: > > How about using like below? > Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, > Exynos4412 */ > It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is for > exynos4212 and exynos4412. AFAIK, compatible strings are not supposed to have any wildcard characters. Compatible string should suggest the first SoC that contained this IP. Hence IMO 4212 is OK. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
> -Original Message- > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > ow...@vger.kernel.org] On Behalf Of Sachin Kamat > Sent: Friday, February 01, 2013 8:13 PM > To: Sylwester Nawrocki > Cc: Inki Dae; Kukjin Kim; Sylwester Nawrocki; linux-media@vger.kernel.org; > dri-de...@lists.freedesktop.org; devicetree-disc...@lists.ozlabs.org; > patc...@linaro.org > Subject: Re: [PATCH 2/2] drm/exynos: Add device tree based discovery > support for G2D > > >> In any case please let me know the final preferred one so that I can > >> update the code send the revised patches. > > > > The version with SoC name embedded in it seems most reliable and correct > > to me. > > > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > S5PV210), > > Exynos4210 */ > > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 > */ > > > Looks good to me. > > Inki, Kukjin, please let us know your opinion so that we can freeze > this. Also please suggest the SoC name for Exynos5 (5250?). > How about using like below? Compatible = ""samsung,exynos4x12-fimg-2d" /* for Exynos4212, Exynos4412 */ It looks odd to use "samsung,exynos4212-fimg-2d" saying that this ip is for exynos4212 and exynos4412. > -- > With warm regards, > Sachin > -- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
>> In any case please let me know the final preferred one so that I can >> update the code send the revised patches. > > The version with SoC name embedded in it seems most reliable and correct > to me. > > compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, > S5PV210), > Exynos4210 */ > compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 */ > Looks good to me. Inki, Kukjin, please let us know your opinion so that we can freeze this. Also please suggest the SoC name for Exynos5 (5250?). -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] s5p-fimc: Redefine platform data structure for fimc-is
On 01/30/2013 06:23 PM, Sylwester Nawrocki wrote:
> Newer Exynos4 SoC are equipped with a local camera ISP that
> controls external raw image sensor directly. Such sensors
> can be connected through FIMC-LITEn (and MIPI-CSISn) IPs to
> the ISP, which then feeds image data to the FIMCn IP. Thus
> there can be two busses associated with an image source
> (sensor). Rename struct s5p_fimc_isp_info describing external
> image sensor (video decoder) to struct fimc_source_info to
> avoid confusion. bus_type is split into fimc_bus_type and
> sensor_bus_type. The bus type enumeration is extended to
> include both FIMC Writeback input types.
>
> The bus_type enumeration and the data structure name in the
> board files are modified according to the above changes.
>
> Cc: Kukjin Kim
> Cc: linux-samsung-...@vger.kernel.org
> Signed-off-by: Sylwester Nawrocki
> Signed-off-by: Kyungmin Park
Kukjin, can I please have your ack on this patch so it can be
merged through the media tree ?
--
Thanks,
Sylwester
> ---
> arch/arm/mach-exynos/mach-nuri.c|8 ++--
> arch/arm/mach-exynos/mach-universal_c210.c |8 ++--
> arch/arm/mach-s5pv210/mach-goni.c |6 +--
> drivers/media/platform/s5p-fimc/fimc-lite-reg.c |8 ++--
> drivers/media/platform/s5p-fimc/fimc-lite-reg.h |4 +-
> drivers/media/platform/s5p-fimc/fimc-mdevice.c | 16
> drivers/media/platform/s5p-fimc/fimc-mdevice.h |2 +-
> drivers/media/platform/s5p-fimc/fimc-reg.c | 34 +---
> drivers/media/platform/s5p-fimc/fimc-reg.h |6 +--
> include/media/s5p_fimc.h| 49
> ++-
> 10 files changed, 79 insertions(+), 62 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-nuri.c
> b/arch/arm/mach-exynos/mach-nuri.c
> index 27d4ed8..7c2600e 100644
> --- a/arch/arm/mach-exynos/mach-nuri.c
> +++ b/arch/arm/mach-exynos/mach-nuri.c
> @@ -1209,25 +1209,25 @@ static struct i2c_board_info m5mols_board_info = {
> .platform_data = &m5mols_platdata,
> };
>
> -static struct s5p_fimc_isp_info nuri_camera_sensors[] = {
> +static struct fimc_source_info nuri_camera_sensors[] = {
> {
> .flags = V4L2_MBUS_PCLK_SAMPLE_RISING |
> V4L2_MBUS_VSYNC_ACTIVE_LOW,
> - .bus_type = FIMC_ITU_601,
> + .fimc_bus_type = FIMC_BUS_TYPE_ITU_601,
> .board_info = &s5k6aa_board_info,
> .clk_frequency = 2400UL,
> .i2c_bus_num= 6,
> }, {
> .flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
> V4L2_MBUS_VSYNC_ACTIVE_LOW,
> - .bus_type = FIMC_MIPI_CSI2,
> + .fimc_bus_type = FIMC_BUS_TYPE_MIPI_CSI2,
> .board_info = &m5mols_board_info,
> .clk_frequency = 2400UL,
> },
> };
>
> static struct s5p_platform_fimc fimc_md_platdata = {
> - .isp_info = nuri_camera_sensors,
> + .source_info= nuri_camera_sensors,
> .num_clients= ARRAY_SIZE(nuri_camera_sensors),
> };
>
> diff --git a/arch/arm/mach-exynos/mach-universal_c210.c
> b/arch/arm/mach-exynos/mach-universal_c210.c
> index 9e3340f..c09290a 100644
> --- a/arch/arm/mach-exynos/mach-universal_c210.c
> +++ b/arch/arm/mach-exynos/mach-universal_c210.c
> @@ -988,12 +988,12 @@ static struct i2c_board_info m5mols_board_info = {
> .platform_data = &m5mols_platdata,
> };
>
> -static struct s5p_fimc_isp_info universal_camera_sensors[] = {
> +static struct fimc_source_info universal_camera_sensors[] = {
> {
> .mux_id = 0,
> .flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
> V4L2_MBUS_VSYNC_ACTIVE_LOW,
> - .bus_type = FIMC_ITU_601,
> + .fimc_bus_type = FIMC_BUS_TYPE_ITU_601,
> .board_info = &s5k6aa_board_info,
> .i2c_bus_num= 0,
> .clk_frequency = 2400UL,
> @@ -1001,7 +1001,7 @@ static struct s5p_fimc_isp_info
> universal_camera_sensors[] = {
> .mux_id = 0,
> .flags = V4L2_MBUS_PCLK_SAMPLE_FALLING |
> V4L2_MBUS_VSYNC_ACTIVE_LOW,
> - .bus_type = FIMC_MIPI_CSI2,
> + .fimc_bus_type = FIMC_BUS_TYPE_MIPI_CSI2,
> .board_info = &m5mols_board_info,
> .i2c_bus_num= 0,
> .clk_frequency = 2400UL,
> @@ -1009,7 +1009,7 @@ static struct s5p_fimc_isp_info
> universal_camera_sensors[] = {
> };
>
> static struct s5p_platform_fimc fimc_md_platdata = {
> - .isp_info = universal_camera_sensors,
> + .source_info= universal_camera_sensors,
> .num_clients= ARRAY_SIZE(universal_camera_sensors),
> };
>
> diff --git a/arch/arm/mach-s5pv210/mach-goni.c
> b/arch/arm/mach-s5pv210/mach-goni.c
> index
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 02/01/2013 09:33 AM, Sachin Kamat wrote: > On 1 February 2013 06:57, Inki Dae wrote: >> >> For example, >> If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be >> reasonable. But what if that compatible string is added to exynos4.dtsi?. >> This case isn't considered for exynos4412 SoC with v4.1. > > In case of Exynos4 series the base address of G2D ip is different > across series. Hence we cannot define it in exynos4.dtsi and need to > define the nodes in exynos4xxx.dtsi or specific board files. Thus we > can use the version appended compatible string. > > However even the second option suggested by Sylwester is OK with me or > to be even more specific we could go for both SoC as well as version > option something like this. > > compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, Exynos4210 */ > compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, Exynos4412 */ > > In any case please let me know the final preferred one so that I can > update the code send the revised patches. The version with SoC name embedded in it seems most reliable and correct to me. compatible = "samsung,exynos3110-fimg-2d" /* for Exynos3110 (S5PC110, S5PV210), Exynos4210 */ compatible = "samsung,exynos4212-fimg-2d" /* for Exynos4212, Exynos4412 */ FIMG stands for Fully Interactive Mobile Graphics, and other multimedia IPs follow this naming convention, e.g. FIMG-3D, FIMD (Display Controller), FIMC (Camera), etc. This is just my opinion though, and it seems this is a most common scheme from greping the device tree bindings documentation. As Stephen pointed out, and I also did in some other mail thread in the past, not only an IP revision might be required, but also its integration details, specific to an SoC type are important. This actually happens to be the case with FIMC, where same version of one instance of the IP has more data interfaces routed to other SoC subsystems on one SoC type than on other one. I think it won't be possible to use a scheme like "samsung-exynos-g2d-3.0" for all IPs. And I would much more like to see a uniform naming convention used, rather than living with a chaotic set of compatible properties, that has a potential to become even more chaotic in the future. -- Thanks, 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: [PATCH v17 4/7] fbmon: add videomode helpers
On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote
>
> Add a function to convert from the generic videomode to a fb_videomode.
>
> Signed-off-by: Steffen Trumtrar
> Reviewed-by: Thierry Reding
> Acked-by: Thierry Reding
> Tested-by: Thierry Reding
> Tested-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> Acked-by: Laurent Pinchart
> Tested-by: Afzal Mohammed
> Tested-by: Rob Clark
> Tested-by: Leela Krishna Amudala
> ---
> drivers/video/fbmon.c | 52
> +
> include/linux/fb.h|4
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index cef6557..17ce135 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #ifdef CONFIG_PPC_OF
> #include
> #include
> @@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct
> fb_var_screeninfo *var, struct fb_inf
> kfree(timings);
> return err;
> }
> +
> +#if IS_ENABLED(CONFIG_VIDEOMODE)
> +int fb_videomode_from_videomode(const struct videomode *vm,
> + struct fb_videomode *fbmode)
> +{
> + unsigned int htotal, vtotal;
> +
> + fbmode->xres = vm->hactive;
> + fbmode->left_margin = vm->hback_porch;
> + fbmode->right_margin = vm->hfront_porch;
> + fbmode->hsync_len = vm->hsync_len;
> +
> + fbmode->yres = vm->vactive;
> + fbmode->upper_margin = vm->vback_porch;
> + fbmode->lower_margin = vm->vfront_porch;
> + fbmode->vsync_len = vm->vsync_len;
> +
> + /* prevent division by zero in KHZ2PICOS macro */
> + fbmode->pixclock = vm->pixelclock ?
> + KHZ2PICOS(vm->pixelclock / 1000) : 0;
> +
> + fbmode->sync = 0;
> + fbmode->vmode = 0;
> + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
Hi Steffen Trumtrar,
Um, it seems to be a type. 'H'SYNC -> 'V'SYNC
Thus, it would be changed as below:
VESA_DMT_HSYNC_HIGH -> VESA_DMT_VSYNC_HIGH
Best regards,
Jingoo Han
> + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> + if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> + fbmode->vmode |= FB_VMODE_INTERLACED;
> + if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
> + fbmode->vmode |= FB_VMODE_DOUBLE;
> + fbmode->flag = 0;
> +
> + htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
> + vm->hsync_len;
> + vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
> + vm->vsync_len;
> + /* prevent division by zero */
> + if (htotal && vtotal) {
> + fbmode->refresh = vm->pixelclock / (htotal * vtotal);
> + /* a mode must have htotal and vtotal != 0 or it is invalid */
> + } else {
> + fbmode->refresh = 0;
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
> +#endif
> +
> #else
> int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
> {
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index c7a9571..100a176 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -19,6 +19,7 @@ struct vm_area_struct;
> struct fb_info;
> struct device;
> struct file;
> +struct videomode;
>
> /* Definitions below are used in the parsed monitor specs */
> #define FB_DPMS_ACTIVE_OFF 1
> @@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode
> *modedb);
> extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
> extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
>
> +extern int fb_videomode_from_videomode(const struct videomode *vm,
> +struct fb_videomode *fbmode);
> +
> /* drivers/video/modedb.c */
> #define VESA_MODEDB_SIZE 34
> extern void fb_var_to_videomode(struct fb_videomode *mode,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v17 4/7] fbmon: add videomode helpers
On Friday, January 25, 2013 6:02 PM, Steffen Trumtrar wrote
>
> Add a function to convert from the generic videomode to a fb_videomode.
>
> Signed-off-by: Steffen Trumtrar
> Reviewed-by: Thierry Reding
> Acked-by: Thierry Reding
> Tested-by: Thierry Reding
> Tested-by: Philipp Zabel
> Reviewed-by: Laurent Pinchart
> Acked-by: Laurent Pinchart
> Tested-by: Afzal Mohammed
> Tested-by: Rob Clark
> Tested-by: Leela Krishna Amudala
> ---
> drivers/video/fbmon.c | 52
> +
> include/linux/fb.h|4
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/video/fbmon.c b/drivers/video/fbmon.c
> index cef6557..17ce135 100644
> --- a/drivers/video/fbmon.c
> +++ b/drivers/video/fbmon.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #ifdef CONFIG_PPC_OF
> #include
> #include
> @@ -1373,6 +1374,57 @@ int fb_get_mode(int flags, u32 val, struct
> fb_var_screeninfo *var, struct fb_inf
> kfree(timings);
> return err;
> }
> +
> +#if IS_ENABLED(CONFIG_VIDEOMODE)
> +int fb_videomode_from_videomode(const struct videomode *vm,
> + struct fb_videomode *fbmode)
> +{
> + unsigned int htotal, vtotal;
> +
> + fbmode->xres = vm->hactive;
> + fbmode->left_margin = vm->hback_porch;
> + fbmode->right_margin = vm->hfront_porch;
> + fbmode->hsync_len = vm->hsync_len;
> +
> + fbmode->yres = vm->vactive;
> + fbmode->upper_margin = vm->vback_porch;
> + fbmode->lower_margin = vm->vfront_porch;
> + fbmode->vsync_len = vm->vsync_len;
> +
> + /* prevent division by zero in KHZ2PICOS macro */
> + fbmode->pixclock = vm->pixelclock ?
> + KHZ2PICOS(vm->pixelclock / 1000) : 0;
> +
> + fbmode->sync = 0;
> + fbmode->vmode = 0;
> + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
> + fbmode->sync |= FB_SYNC_HOR_HIGH_ACT;
> + if (vm->dmt_flags & VESA_DMT_HSYNC_HIGH)
Hi Steffen Trumtrar,
Um, it seems to be a type. 'H'SYNC -> 'V'SYNC
Thus, it would be changed as below:
VESA_DMT_HSYNC_HIGH -> VESA_DMT_VSYNC_HIGH
Best regards,
Jingoo Han
> + fbmode->sync |= FB_SYNC_VERT_HIGH_ACT;
> + if (vm->data_flags & DISPLAY_FLAGS_INTERLACED)
> + fbmode->vmode |= FB_VMODE_INTERLACED;
> + if (vm->data_flags & DISPLAY_FLAGS_DOUBLESCAN)
> + fbmode->vmode |= FB_VMODE_DOUBLE;
> + fbmode->flag = 0;
> +
> + htotal = vm->hactive + vm->hfront_porch + vm->hback_porch +
> + vm->hsync_len;
> + vtotal = vm->vactive + vm->vfront_porch + vm->vback_porch +
> + vm->vsync_len;
> + /* prevent division by zero */
> + if (htotal && vtotal) {
> + fbmode->refresh = vm->pixelclock / (htotal * vtotal);
> + /* a mode must have htotal and vtotal != 0 or it is invalid */
> + } else {
> + fbmode->refresh = 0;
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(fb_videomode_from_videomode);
> +#endif
> +
> #else
> int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var)
> {
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index c7a9571..100a176 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -19,6 +19,7 @@ struct vm_area_struct;
> struct fb_info;
> struct device;
> struct file;
> +struct videomode;
>
> /* Definitions below are used in the parsed monitor specs */
> #define FB_DPMS_ACTIVE_OFF 1
> @@ -714,6 +715,9 @@ extern void fb_destroy_modedb(struct fb_videomode
> *modedb);
> extern int fb_find_mode_cvt(struct fb_videomode *mode, int margins, int rb);
> extern unsigned char *fb_ddc_read(struct i2c_adapter *adapter);
>
> +extern int fb_videomode_from_videomode(const struct videomode *vm,
> +struct fb_videomode *fbmode);
> +
> /* drivers/video/modedb.c */
> #define VESA_MODEDB_SIZE 34
> extern void fb_var_to_videomode(struct fb_videomode *mode,
> --
> 1.7.10.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drm/exynos: Add device tree based discovery support for G2D
On 1 February 2013 06:57, Inki Dae wrote: > > For example, > If compatible = "samsung,g2d-3.0" is added to exynos4210.dtsi, it'd be > reasonable. But what if that compatible string is added to exynos4.dtsi?. > This case isn't considered for exynos4412 SoC with v4.1. In case of Exynos4 series the base address of G2D ip is different across series. Hence we cannot define it in exynos4.dtsi and need to define the nodes in exynos4xxx.dtsi or specific board files. Thus we can use the version appended compatible string. However even the second option suggested by Sylwester is OK with me or to be even more specific we could go for both SoC as well as version option something like this. compatible = "samsung,exynos3110-g2d-3.0" /* for Exynos3110, Exynos4210 */ compatible = "samsung,exynos4212-g2d-4.1" /* for Exynos4212, Exynos4412 */ In any case please let me know the final preferred one so that I can update the code send the revised patches. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: media_build: getting a TerraTec H7 working?
Em Thu, 31 Jan 2013 22:38:13 +0100 Torfinn Ingolfsen escreveu: > Hi, > I'm trying to get a TerraTec H7 working. I started with Xubuntu 12.04, > using kernel 3.2.24: > tingo@kg-f4:~/work/w_scan-2012$ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 12.04.1 LTS > Release: 12.04 > Codename: precise > > tingo@kg-f4:~/work/w_scan-2012$ uname -a > Linux kg-f4 3.2.24 #2 SMP Wed Sep 5 01:14:55 CEST 2012 x86_64 x86_64 > x86_64 GNU/Linux > > I have this H7 variant: > tingo@kg-f4:~/work/w_scan-2012$ lsusb -s 2:2 > Bus 002 Device 002: ID 0ccd:10a3 TerraTec Electronic GmbH > > I added the media_build tree, by following these instructions: > http://git.linuxtv.org/media_build.git > > relevant parts of dmesg output: > [9.008181] WARNING: You are using an experimental version of the > media stack. > [9.008186] As the driver is backported to an older kernel, it doesn't > offer > [9.008188] enough quality for its usage in production. > [9.008190] Use it with care. > [9.008191] Latest git patches (needed if you report a bug to > linux-media@vger.kernel.org): > [9.008193] a32f7d1ad3744914273c6907204c2ab3b5d496a0 Merge branch > 'v4l_for_linus' into staging/for_v3.9 > [9.008195] 6b9e50c463efc5c361496ae6a895cc966ff8025b [media] > stv090x: On STV0903 do not set registers of the second path > [9.008198] f67102c49a123b32a4469b28407feb52b37144f5 [media] > mb86a20s: remove global BER/PER counters if per-layer counters vanish > [9.013452] usbcore: registered new interface driver dvb_usb_az6007 > > [9.014108] usb 2-1: dvb_usb_v2: found a 'Terratec H7' in cold state > > [9.746658] usb 2-1: dvb_usb_v2: downloading firmware from file > 'dvb-usb-terratec-h7-az6007.fw' > [9.770522] usb 2-1: dvb_usb_v2: found a 'Terratec H7' in warm state > > [ 11.008581] usb 2-1: dvb_usb_v2: will pass the complete MPEG2 > transport stream to the software demuxer > [ 11.008625] DVB: registering new adapter (Terratec H7) > [ 11.011489] usb 2-1: dvb_usb_v2: MAC address: c2:cd:0c:a3:10:00 > [ 11.025188] drxk: frontend initialized. > [ 11.036565] usb 2-1: DVB: registering adapter 0 frontend 0 (DRXK)... > [ 11.047302] mt2063_attach: Attaching MT2063 > [ 11.072035] Registered IR keymap rc-nec-terratec-cinergy-xs > [ 11.072230] input: Terratec H7 as > /devices/pci:00/:00:13.2/usb2/2-1/rc/rc0/input13 > [ 11.072346] rc0: Terratec H7 as > /devices/pci:00/:00:13.2/usb2/2-1/rc/rc0 > [ 11.072354] usb 2-1: dvb_usb_v2: schedule remote query interval to 400 > msecs > [ 11.072361] usb 2-1: dvb_usb_v2: 'Terratec H7' successfully > initialized and connected > [ 11.088076] drxk: status = 0x439130d9 > [ 11.088085] drxk: detected a drx-3913k, spin A2, xtal 27.000 MHz It looks ok so far. > > I get this in /dev: > tingo@kg-f4:~/work/w_scan-2012$ ls -l /dev/dvb/adapter0 > total 0 > crw-rw+ 1 root video 212, 3 Jan 31 21:06 ca0 > crw-rw+ 1 root video 212, 0 Jan 31 21:06 demux0 > crw-rw+ 1 root video 212, 1 Jan 31 21:06 dvr0 > crw-rw+ 1 root video 212, 4 Jan 31 21:06 frontend0 > crw-rw+ 1 root video 212, 2 Jan 31 21:06 net0 > > But when I scan with w_scan, it doesn't find any channels: > tingo@kg-f4:~/work/w_scan-2012$ ./w_scan -fc -c NO -C ISO-8859-1 > w_scan version 2012 (compiled for DVB API 5.4) ... > And yes - the H7 is connected to a cable with a DVB-C signal on it > (using a different DVBC-adapter, w_scan finds lamost 200 channels). > > What more can I do to get this H7 working? Well, I prefer to not use w_scan for DVB-C. It will take a long time to run, as it will try a large number of possibilities and still it might not find the channels, if your cable operator is using some weird setup (still, it has some options to make it more pedantic and increase the scan time to a few hours). I prefer, instead, to have a simple file with something like: # Frequency Symbol_rate FEC Modulation C 57300 5217000 NONEQAM256 Where frequency and symbol rates that typically can be get easily from the STB. You don't need to set FEC, as this device supports FEC_AUTO. Modulation can be QAM-16, QAM-32, QAM-64, QAM-128 or QAM-256. w_scan by default tries only QAM-64 and QAM-256, as those are the typical modulation types used, but it is up to your cable operator to decide. They might be doing something weird. In doubt, you could have more than one line with all possible alternatives, like: # Frequency Symbol_rate FEC Modulation C 57300 5217000 NONEQAM256 C 57300 5217000 NONEQAM128 ... C 57300 5217000 NONEQAM16 Assuming that the above file is called "~/dvbc-freq", you can scan the channels with: $ dvbv5-scan -I channel ~/dvbc-freq Once it gets succeeded, the tool will get the other frequencies from the stream and
Re: [RFC PATCH 00/18] tlg2300: various v4l2-compliance fixes
On Fri February 1 2013 09:02:13 Huang Shijie wrote: > On Fri, Feb 1, 2013 at 3:49 PM, Hans Verkuil wrote: > > On Fri February 1 2013 03:22:22 Huang Shijie wrote: > >> Hi Hans: > >> > >> On Thu, Jan 31, 2013 at 6:25 PM, Hans Verkuil wrote: > >> > Hi all, > >> > > >> > Last year I worked on this driver to improve it and fix v4l2-compliance > >> > issues. > >> > >> I am glad to know that there are still some people use the > >> tlg2300. thanks a lot. > >> > >> > > >> > It required a lot of effort to even find a USB stick with this chipset > >> > (telegent no longer exists) and unfortunately at some point I managed > >> > to break the USB stick, so I am no longer able to work on it. > >> > > >> > This patch series represents that part of the work I've done that has > >> > been tested. I have additional patches in my tlg2300-wip branch: > >> > > >> > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/tlg2300-wip > >> > > >> > but since I am no longer certain at what point in those remaining patches > >> > things broke down I've decided not to post them for upstreaming. If I or > >> > someone else ever manages to get a working tlg2300 that code might be > >> > used > >> > for further work. > >> > >> Could you tell me how did you test your patch set? > > > > I used the v4l2-compliance tool which we use to validate drivers. It's part > > of > > v4l-utils.git: http://git.linuxtv.org/v4l-utils.git > > > > > > ok. > > >> did you test the hibernate and suspend/resume? > > > > No, it was on my todo list but the stick broke before I had a chance to > > test it. > > However, none of the patches touch on suspend/resume. > > > Could you test the hibernate and suspend with your patch > set (hibernate when the gmplayer is playing the tv). And if you do not > meet any issue, please send the patch set out again. As I told you, my USB stick died. I can't test this anymore. Regards, Hans > > thanks a lot. > > thanks > Huang Shijie > > >> > Huang Shijie, are you still able to act as maintainer? If not, then I can > >> > put my name in. The MAINTAINER status should probably move to 'Odd Fixes' > >> > >> Yes, you can put your name in. > > > > OK, I'll update that patch. > > > > Regards, > > > > Hans > > > >> I am busy some other drivers recently. > >> > >> thanks > >> Huang Shijie > >> > >> > as well. > >> > > >> > 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: [RFC PATCH 00/18] tlg2300: various v4l2-compliance fixes
On Fri, Feb 1, 2013 at 3:49 PM, Hans Verkuil wrote: > On Fri February 1 2013 03:22:22 Huang Shijie wrote: >> Hi Hans: >> >> On Thu, Jan 31, 2013 at 6:25 PM, Hans Verkuil wrote: >> > Hi all, >> > >> > Last year I worked on this driver to improve it and fix v4l2-compliance >> > issues. >> >> I am glad to know that there are still some people use the >> tlg2300. thanks a lot. >> >> > >> > It required a lot of effort to even find a USB stick with this chipset >> > (telegent no longer exists) and unfortunately at some point I managed >> > to break the USB stick, so I am no longer able to work on it. >> > >> > This patch series represents that part of the work I've done that has >> > been tested. I have additional patches in my tlg2300-wip branch: >> > >> > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/tlg2300-wip >> > >> > but since I am no longer certain at what point in those remaining patches >> > things broke down I've decided not to post them for upstreaming. If I or >> > someone else ever manages to get a working tlg2300 that code might be used >> > for further work. >> >> Could you tell me how did you test your patch set? > > I used the v4l2-compliance tool which we use to validate drivers. It's part of > v4l-utils.git: http://git.linuxtv.org/v4l-utils.git > > ok. >> did you test the hibernate and suspend/resume? > > No, it was on my todo list but the stick broke before I had a chance to test > it. > However, none of the patches touch on suspend/resume. > Could you test the hibernate and suspend with your patch set (hibernate when the gmplayer is playing the tv). And if you do not meet any issue, please send the patch set out again. thanks a lot. thanks Huang Shijie >> > Huang Shijie, are you still able to act as maintainer? If not, then I can >> > put my name in. The MAINTAINER status should probably move to 'Odd Fixes' >> >> Yes, you can put your name in. > > OK, I'll update that patch. > > Regards, > > Hans > >> I am busy some other drivers recently. >> >> thanks >> Huang Shijie >> >> > as well. >> > >> > 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
