Re: [PATCH] cx18: Fix VIDIOC_TRY_FMT to fill in sizeimage and bytesperline
On Tuesday 24 November 2015 21:27:33 Jean-Michel Hautbois wrote: > Hi, > Le 24 nov. 2015 19:46, "Simon Farnsworth" <simon.farnswo...@onelan.co.uk> a > écrit : > > > > I was having trouble capturing raw video from GStreamer; turns out that I > > now need VIDIOC_TRY_FMT to fill in sizeimage and bytesperline to make it > > work. > > You could have used v4l2-compliance tool it would give you at least (I don't > have the HW to test) this error. Would save your time :-) It only took me 2 minutes to find - I'd have spent longer getting v4l2-compliance running :) As I'm not going to have access to the hardware after Friday, I'll leave getting a full v4l2-compliance pass to someone else. > > Signed-off-by: Simon Farnsworth <simon.farnswo...@onelan.co.uk> > > --- > > > > I'm leaving ONELAN on Friday, so this is a drive-by patch being sent for the > > benefit of anyone else trying to use raw capture from a cx18 card. If it's > > not suitable for applying as-is, please feel free to just leave it in the > > archives so that someone else hitting the same problem can find my fix. > > -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.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
[PATCH] cx18: Fix VIDIOC_TRY_FMT to fill in sizeimage and bytesperline
I was having trouble capturing raw video from GStreamer; turns out that I
now need VIDIOC_TRY_FMT to fill in sizeimage and bytesperline to make it work.
Signed-off-by: Simon Farnsworth <simon.farnswo...@onelan.co.uk>
---
I'm leaving ONELAN on Friday, so this is a drive-by patch being sent for the
benefit of anyone else trying to use raw capture from a cx18 card. If it's
not suitable for applying as-is, please feel free to just leave it in the
archives so that someone else hitting the same problem can find my fix.
drivers/media/pci/cx18/cx18-ioctl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c
b/drivers/media/pci/cx18/cx18-ioctl.c
index 55525af..1c9924a 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -234,6 +234,13 @@ static int cx18_try_fmt_vid_cap(struct file *file, void
*fh,
fmt->fmt.pix.width = w;
fmt->fmt.pix.height = h;
+ if (fmt->fmt.pix.pixelformat == V4L2_PIX_FMT_HM12) {
+ fmt->fmt.pix.sizeimage = h * 720 * 3 / 2;
+ fmt->fmt.pix.bytesperline = 720; /* First plane */
+ } else {
+ fmt->fmt.pix.sizeimage = h * 720 * 2;
+ fmt->fmt.pix.bytesperline = 1440; /* Packed */
+ }
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx18: Fix bytes_per_line
Current GStreamer userspace respects the bytes_per_line from the driver. Set
it to something reasonable for the format chosen.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
I'm hoping this is trivially correct - I've only tested UYVY.
drivers/media/pci/cx18/cx18-driver.h | 1 +
drivers/media/pci/cx18/cx18-ioctl.c | 9 ++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/media/pci/cx18/cx18-driver.h
b/drivers/media/pci/cx18/cx18-driver.h
index 207d6e82..ec40f2d 100644
--- a/drivers/media/pci/cx18/cx18-driver.h
+++ b/drivers/media/pci/cx18/cx18-driver.h
@@ -409,6 +409,7 @@ struct cx18_stream {
/* Videobuf for YUV video */
u32 pixelformat;
u32 vb_bytes_per_frame;
+ u32 vb_bytes_per_line;
struct list_head vb_capture;/* video capture queue */
spinlock_t vb_lock;
struct timer_list vb_timeout;
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c
b/drivers/media/pci/cx18/cx18-ioctl.c
index b8e4b68..c2e0093 100644
--- a/drivers/media/pci/cx18/cx18-ioctl.c
+++ b/drivers/media/pci/cx18/cx18-ioctl.c
@@ -159,7 +159,7 @@ static int cx18_g_fmt_vid_cap(struct file *file, void *fh,
if (id-type == CX18_ENC_STREAM_TYPE_YUV) {
pixfmt-pixelformat = s-pixelformat;
pixfmt-sizeimage = s-vb_bytes_per_frame;
- pixfmt-bytesperline = 720;
+ pixfmt-bytesperline = s-vb_bytes_per_line;
} else {
pixfmt-pixelformat = V4L2_PIX_FMT_MPEG;
pixfmt-sizeimage = 128 * 1024;
@@ -287,10 +287,13 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
s-pixelformat = fmt-fmt.pix.pixelformat;
/* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
- if (s-pixelformat == V4L2_PIX_FMT_HM12)
+ if (s-pixelformat == V4L2_PIX_FMT_HM12) {
s-vb_bytes_per_frame = h * 720 * 3 / 2;
- else
+ s-vb_bytes_per_line = 720; /* First plane */
+ } else {
s-vb_bytes_per_frame = h * 720 * 2;
+ s-vb_bytes_per_line = 1440; /* Packed */
+ }
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DocBook media: Clarify V4L2_FIELD_ANY for drivers
Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY is only acceptable as input to the kernel, not as a response from the driver. Make it clear, to stop userspace developers like me assuming it can be returned by the driver. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Documentation/DocBook/media/v4l/io.xml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index e5e8325..8918bb2 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1422,7 +1422,10 @@ one of the constantV4L2_FIELD_NONE/constant, constantV4L2_FIELD_BOTTOM/constant, or constantV4L2_FIELD_INTERLACED/constant formats is acceptable. Drivers choose depending on hardware capabilities or e.nbsp;g. the -requested image size, and return the actual field order. v4l2-buffer; +requested image size, and return the actual field order. If multiple +field orders are possible the driver must choose one of the possible +field orders during VIDIOC-S-FMT; or VIDIOC-TRY-FMT; and must not +return V4L2_FIELD_ANY. v4l2-buffer; structfieldfield/structfield can never be constantV4L2_FIELD_ANY/constant./entry /row -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] DocBook media: Clarify V4L2_FIELD_ANY for drivers
Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY is only acceptable as input to the kernel, not as a response from the driver. Make it clear, to stop userspace developers like me assuming it can be returned by the driver. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Change wording as suggested by Hans. The new wording still makes sense to me, and leaves it clear that V4L2_FIELD_ANY is not a valid answer from TRY_FMT. Documentation/DocBook/media/v4l/io.xml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index e5e8325..1c17f80 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1422,7 +1422,10 @@ one of the constantV4L2_FIELD_NONE/constant, constantV4L2_FIELD_BOTTOM/constant, or constantV4L2_FIELD_INTERLACED/constant formats is acceptable. Drivers choose depending on hardware capabilities or e.nbsp;g. the -requested image size, and return the actual field order. v4l2-buffer; +requested image size, and return the actual field order. Drivers must +never return constantV4L2_FIELD_ANY/constant. If multiple +field orders are possible the driver must choose one of the possible +field orders during VIDIOC-S-FMT; or VIDIOC-TRY-FMT;. v4l2-buffer; structfieldfield/structfield can never be constantV4L2_FIELD_ANY/constant./entry /row -- 1.9.3 -- 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] DocBook media: Clarify V4L2_FIELD_ANY for drivers
On Friday 31 October 2014 15:54:01 Hans Verkuil wrote: On 10/31/2014 03:48 PM, Simon Farnsworth wrote: Documentation for enum v4l2_field did not make it clear that V4L2_FIELD_ANY is only acceptable as input to the kernel, not as a response from the driver. Make it clear, to stop userspace developers like me assuming it can be returned by the driver. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Documentation/DocBook/media/v4l/io.xml | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index e5e8325..8918bb2 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1422,7 +1422,10 @@ one of the constantV4L2_FIELD_NONE/constant, constantV4L2_FIELD_BOTTOM/constant, or constantV4L2_FIELD_INTERLACED/constant formats is acceptable. Drivers choose depending on hardware capabilities or e.nbsp;g. the -requested image size, and return the actual field order. v4l2-buffer; +requested image size, and return the actual field order. If multiple +field orders are possible the driver must choose one of the possible +field orders during VIDIOC-S-FMT; or VIDIOC-TRY-FMT; and must not +return V4L2_FIELD_ANY. v4l2-buffer; I would phrase it slightly differently: Drivers must never return constantV4L2_FIELD_ANY/constant. If multiple field orders are possible the driver must choose one of the possible field orders during VIDIOC-S-FMT; or VIDIOC-TRY-FMT;. I like your wording better than mine. v2 patch sent. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
[PATCH] saa7134: Fix crash when device is closed before streamoff
pm_qos_remove_request was not called on video_release, resulting in the PM
core's list of requests being corrupted when the file handle was freed.
This has no immediate symptoms, but later in operation, the kernel will
panic as the PM core dereferences a dangling pointer.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
Cc: sta...@vger.kernel.org
---
I didn't notice this when I first implemented the pm_qos_request as the
userspace I was using always called streamoff before closing the
device. I've since changed userspace components, and hit the kernel panic.
drivers/media/pci/saa7134/saa7134-video.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index e12bbd8..fb60da8 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -1455,6 +1455,7 @@ static int video_release(struct file *file)
/* stop video capture */
if (res_check(fh, RESOURCE_VIDEO)) {
+ pm_qos_remove_request(dev-qos_request);
videobuf_streamoff(fh-cap);
res_free(dev,fh,RESOURCE_VIDEO);
}
--
1.7.11.7
--
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 RFCv10 00/15] DVB QoS statistics API
On Wednesday 16 January 2013 23:56:48 Manu Abraham wrote: On Wed, Jan 16, 2013 at 10:51 PM, Mauro Carvalho Chehab snip It is a common sense that the existing API is broken. If my proposal requires adjustments, please comment on each specific patchset, instead of filling this thread of destructive and useless complains. No, the concept of such a generalization is broken, as each new device will be different and trying to make more generalization is a waste of developer time and effort. The simplest approach would be to do a coarse approach, which is not a perfect world, but it will do some good results for all the people who use Linux-DVB. Still, repeating myself we are not dealing with high end professional devices. If we have such devices, then it makes sense to start such a discussion. Anyway professional devices will need a lot of other API extensions, so your arguments on the need for professional devices that do not exist are pointless and not agreeable to. Let's step back a bit. As a sophisticated API user, I want to be able to give my end-users the following information: * Signal strength in dBm * Signal quality as poor, OK and good. * Ideally, increase signal strength to improve things or attenuate signal to improve things In a DVBv3 world, poor equates to UNC != 0, OK is UNC == 0, BER != 0, and good is UNC == BER == 0. The idea is that a user seeing poor knows that they will see glitches in the output; a user seeing OK knows that there's no glitching right now, but that the setup is marginal and may struggle if anything changes, and a user seeing good knows that they've got high quality signal. VDR wants even simpler - it just wants strength and quality on a 0 to 100 scale, where 100 is perfect, and 0 is nothing present. In both cases, we want per-layer quality for ISDB-T, for the reasons you've already outlined. So, how do you provide such information? Is it enough to simply provide strength in dBm, and quality as 0 to 100, where anything under 33 indicates uncorrected errors, and anything under 66 indicates that quality is marginal? -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Wednesday 9 January 2013 13:24:25 Mauro Carvalho Chehab wrote: snip Yes, it makes sense to document that the signal strength should be reported on either dBm or dBµW, if the scale is FE_SCALE_DECIBEL. I prefer to specify it in terms of Watt (or a submultiple) than in terms of voltage/impedance, as different Countries use different impedances on DTV cabling (typically, 50Ω or 75Ω). So, either dBm or dBµW works for me. As you said, applications can convert between those mesures as they wish, by simply adding some constant when displaying the power measure. As the wifi subsytem use dBm, I vote for using dBm for the signal measure at the subsystem (actually, 0.1 dBm). 0.1 dBm suits me. I just want something that I can present to the end user in a format that will match their aerial installer's kit. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Tuesday 8 January 2013 18:28:53 Devin Heitmueller wrote: On Tue, Jan 8, 2013 at 6:18 PM, Simon Farnsworth simon.farnswo...@onelan.com wrote: The wireless folk use dBm (reference point 1 milliwatt), as that's the reference point used in the 802.11 standard. Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference point (so suitable for carrier to noise etc, or for when the reference point is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is 1mW, so that frontends report in dBm? Note that if the frontend internally uses a different reference point, the conversion is always going to be adding or subtracting a constant. Hi Simon, Probably the biggest issue you're going to have is that very few of the consumer-grade demodulators actually report data in that format. And only a small subset of those actually provide the documentation in their datasheet. snip My specific concern is that we already see people complaining that their cable system or aerial installer's meter comes up with one number, and our documentation has completely different numbers. When we dig, this usually turns out to be because our documentation is in dBm, while their installer is using dBmV or dBµW, and no-one at the customer site knows the differences. If consumer demods don't report in a dB scale at all, we should drop dB as a unit; if they do report in a true dB scale, but the reference point is normally not documented, we need some way to distinguish demods where the reference point is unknown, and demods where someone has taken the time to find the reference point (which can be done with a signal generator). This is sounding more and more like an argument for adding FE_SCALE_DECIBEL_MILLIWATT - it gives those applications that care a way to tell the user that the signal strength reading from the application should match up to the signal strength reading on your installer's kit. Said applications could even choose to do the conversions for you, giving you all four commonly seen units (dBm, dBmV at 50Ω, dBmV at 75Ω, dBµW). For that matter, even the SNR field being reported in dB isn't going to allow you to reliably compare across different demodulator chips. If demod X says 28.3 dB and demod Y says 29.2 dB, that doesn't really mean demod Y performs better - just that it's reporting a better number. However it does allow you to compare the demod against itself either across multiple frequencies or under different signal conditions - which is what typical users really care about. I'm not expecting people to compare across demods - I only care about the case where a user has got in a professional installer to help with their setup. The problem I want to avoid is a Linux application saying -48 dB signal strength, 15 dB CNR, and the installer's kit saying 60 dBuV signal strength, 20 dB CNR, when we have enough information for the Linux application to say -48 dBm (60 dBuV at 75Ω), 15 dB CNR, cueing the professional to remember that not all dB use the same reference point, and from there into accepting that Linux is reporting a similar signal strength and CNR to his kit. This also has implications for things like VDR - if the scale is FE_SCALE_DECIBEL but the measurement is absolute, the application probably doesn't want to report the measurement as a dB measure, but as an arbitrary scale; again, you don't want the application saying 50 dB, when the professional installer tells you that you have 0 dBuV. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote: snip + itemizedlist mark='bullet' + listitemparaconstantFE_SCALE_NOT_AVAILABLE/constant - If it is not possible to collect a given parameter (could be a transitory or permanent condition)/para/listitem + listitemparaconstantFE_SCALE_DECIBEL/constant - parameter is a signed value, measured in 0.1 dB/para/listitem + listitemparaconstantFE_SCALE_RELATIVE/constant - parameter is a unsigned value, where 0 means 0% and 65535 means 100%./para/listitem + listitemparaconstantFE_SCALE_COUNTER/constant - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time./para/listitem + /itemizedlist snip + section id=DTV-QOS-SIGNAL-STRENGTH + titleconstantDTV_QOS_SIGNAL_STRENGTH/constant/title + paraIndicates the signal strength level at the analog part of the tuner./para + /section Signal strength is traditionally an absolute field strength; there's no way in this API for me to provide my reference point, so two different front ends could represent the same signal strength as 0 dB (where the reference point is one microwatt), -30 dB (where the reference point is one milliwatt), or 17 dB (using a reference point of 1 millivolt on a 50 ohm impedance). Could you choose a reference point for signal strength, and specify that if you're using FE_SCALE_DECIBEL, you're referenced against that point? My preference would be to reference against 1 microwatt, as (on the DVB-T and ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got perfect signal, negative number if your signal is weak, and positive numbers if your signal is strong. However, referenced against 1 milliwatt also works well for me, as the conversion is trivial. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFCv9 1/4] dvb: Add DVBv5 stats properties for Quality of Service
On Tuesday 8 January 2013 19:00:11 Frank Schäfer wrote: Am 08.01.2013 12:45, schrieb Simon Farnsworth: On Monday 7 January 2013 22:25:47 Mauro Carvalho Chehab wrote: snip + itemizedlist mark='bullet' + listitemparaconstantFE_SCALE_NOT_AVAILABLE/constant - If it is not possible to collect a given parameter (could be a transitory or permanent condition)/para/listitem + listitemparaconstantFE_SCALE_DECIBEL/constant - parameter is a signed value, measured in 0.1 dB/para/listitem + listitemparaconstantFE_SCALE_RELATIVE/constant - parameter is a unsigned value, where 0 means 0% and 65535 means 100%./para/listitem + listitemparaconstantFE_SCALE_COUNTER/constant - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time./para/listitem + /itemizedlist snip + section id=DTV-QOS-SIGNAL-STRENGTH + titleconstantDTV_QOS_SIGNAL_STRENGTH/constant/title + paraIndicates the signal strength level at the analog part of the tuner./para + /section Signal strength is traditionally an absolute field strength; there's no way in this API for me to provide my reference point, so two different front ends could represent the same signal strength as 0 dB (where the reference point is one microwatt), -30 dB (where the reference point is one milliwatt), or 17 dB (using a reference point of 1 millivolt on a 50 ohm impedance). Could you choose a reference point for signal strength, and specify that if you're using FE_SCALE_DECIBEL, you're referenced against that point? My preference would be to reference against 1 microwatt, as (on the DVB-T and ATSC cards I use) that leads to the signal measure being 0 dBµW if you've got perfect signal, negative number if your signal is weak, and positive numbers if your signal is strong. However, referenced against 1 milliwatt also works well for me, as the conversion is trivial. Yeah, that's one of the most popular mistakes in the technical world. Decibel is a relative unit. X dB says nothing about the absolute value without a reference value. Hence these reference values must be specified in the document. Otherwise the reported signal strengths are meaningless / not comparable. It might be worth to take a look at what the wireles network people have done. IIRC, they had the same discussion about signal strength reporting a (longer) while ago. The wireless folk use dBm (reference point 1 milliwatt), as that's the reference point used in the 802.11 standard. Perhaps we need an extra FE_SCALE constant; FE_SCALE_DECIBEL has no reference point (so suitable for carrier to noise etc, or for when the reference point is unknown), and FE_SCALE_DECIBEL_MILLIWATT for when the reference point is 1mW, so that frontends report in dBm? Note that if the frontend internally uses a different reference point, the conversion is always going to be adding or subtracting a constant. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.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
[PATCHv2] saa7134: Add pm_qos_request to fix video corruption
The SAA7134 appears to have trouble buffering more than one line of video
when doing DMA. Rather than try to fix the driver to cope (as has been done
by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep
sleep exit latencies.
The visible effect of not having this is that seemingly random lines are
only partly transferred - if you feed in a static image, you see a portion
of the image flicker into place.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
v2 changes: Reduced the latency further, based on a functional block level
datasheet. Comment updated to match.
As noted in the comment, I can't check this in detail.
My SandyBridge systems convert any value less than about 80 usec into 0
usec, as that's the hardware latency from the lightest deep sleep state, and
I'm not aware of any hardware that would let me set the latency directly.
If someone has register-level documentation for the SAA7134, checking our
FIFO configuration and matching the DMA latency to it would be useful.
drivers/media/pci/saa7134/saa7134-video.c | 13 +
drivers/media/pci/saa7134/saa7134.h | 2 ++
2 files changed, 15 insertions(+)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 4a77124..3f4a2a6 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2248,6 +2248,17 @@ static int saa7134_streamon(struct file *file, void
*priv,
if (!res_get(dev, fh, res))
return -EBUSY;
+ /* The SAA7134 has a 1K FIFO; the datasheet suggests that when
+* configured conservatively, there's 22 usec of buffering for video.
+ * We therefore request a DMA latency of 20 usec, giving us 2 usec of
+ * margin in case the FIFO is configured differently to the datasheet.
+ * Unfortunately, I lack register-level documentation to check the
+ * Linux FIFO setup and confirm the perfect value.
+*/
+ pm_qos_add_request(fh-qos_request,
+ PM_QOS_CPU_DMA_LATENCY,
+ 20);
+
return videobuf_streamon(saa7134_queue(fh));
}
@@ -2259,6 +2270,8 @@ static int saa7134_streamoff(struct file *file, void
*priv,
struct saa7134_dev *dev = fh-dev;
int res = saa7134_resource(fh);
+ pm_qos_remove_request(fh-qos_request);
+
err = videobuf_streamoff(saa7134_queue(fh));
if (err 0)
return err;
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index c24b651..d09393b 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -29,6 +29,7 @@
#include linux/notifier.h
#include linux/delay.h
#include linux/mutex.h
+#include linux/pm_qos_params.h
#include asm/io.h
@@ -469,6 +470,7 @@ struct saa7134_fh {
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
+ struct pm_qos_request_list qos_request;
/* video overlay */
struct v4l2_window win;
--
1.7.11.7
--
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] saa7134: Add pm_qos_request to fix video corruption
On Monday 22 October 2012 12:50:11 Simon Farnsworth wrote: The SAA7134 appears to have trouble buffering more than one line of video when doing DMA. Rather than try to fix the driver to cope (as has been done by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep sleep exit latencies. The visible effect of not having this is that seemingly random lines are only partly transferred - if you feed in a static image, you see a portion of the image flicker into place. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk Hello Mauro, I've just noticed that I forgot to CC you in on this patch I sent last week - Patchwork grabbed it at https://patchwork.kernel.org/patch/1625311/ but if you want me to resend it so that you've got it in a mailbox for consideration, just let me know. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption
On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote: I prefer if you don't c/c me on that ;) Patchwork is the main source that I use on my patch reviews. Noted. Btw, I saw your patch yesterday (and skipped it, for now), as I never played with those pm QoS stuff before, nor I ever noticed anything like what you reported on saa7134 (but I can't even remember the last time I tested something on a saa7134 board ;) - so, it can be some new bug). So, I'll postpone its review to when I have some time to actually test it especially as the same issue might also be happening on other drivers. It will affect other drivers as well; the basic cause is that modern chips can enter a package deep sleep state that affects both CPU speed and latency to start of DMA. On older systems, this couldn't happen - the Northbridge kept running at all times, and DMA latencies were low. However, on the Intel Sandybridge system I'm testing with, the maximum wake latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't hold onto data for that long, and overflows, resulting in the corruption I'm seeing. The pm QoS request fixes this for me, by telling the PM subsystem that the SAA7134 cannot cope with a long latency on the first write of a DMA transfer. Now, some media bridges (like the ones driven by the cx18 driver) can cope with very high latency before the beginning of a DMA burst. Andy Walls has worked on the cx18 driver to cope in this situation, so it doesn't fail even with the 109 microsecond DMA latency we have on Sandybridge. Others, like the SAA7134, just don't have that much buffering, and we need to ask the pm core to cope with it. I suspect that most old drivers will need updating if anyone wants to use them with modern systems; either they'll have an architecture like the cx18 series, and the type of work Andy has done will fix the problem, or they'll behave like the saa7134, and need a pm_qos request to ensure that the CPU package (and thus memory controller) stay awake. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption
On Monday 29 October 2012 09:32:27 Andy Walls wrote: On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote: It will affect other drivers as well; the basic cause is that modern chips can enter a package deep sleep state that affects both CPU speed and latency to start of DMA. On older systems, this couldn't happen - the Northbridge kept running at all times, and DMA latencies were low. However, on the Intel Sandybridge system I'm testing with, the maximum wake latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't hold onto data for that long, and overflows, resulting in the corruption I'm seeing. The pm QoS request fixes this for me, by telling the PM subsystem that the SAA7134 cannot cope with a long latency on the first write of a DMA transfer. Now, some media bridges (like the ones driven by the cx18 driver) can cope with very high latency before the beginning of a DMA burst. Andy Walls has worked on the cx18 driver to cope in this situation, so it doesn't fail even with the 109 microsecond DMA latency we have on Sandybridge. Well if brdige wake-up DMA latency is the problem, it is alos the case that the CX23418 has a *lot* of on board memory with which to collect video and compress it. (And lets face it, the CX23418 is an SoC with two ARM cores and a lot of dedicated external memory, as opposed to the SAA7134 with 1 kB of FIFO.) That hardware helps quite a bit, if the PCI bus is slow to wake up. I found a SAA7134 sheet for you: http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf Section 6.4.3 has a short description of the behaviour when the FIFO overflows. That's a good description of what I'm seeing, so fits with the idea that it's FIFO underflow. But this sheet (close enough): http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf Has much nicer examples of the programmed levels of the FIFO in section 6.4.3. That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio. So you're lucky if one full line of video fits in the FIFO. And that datasheet suggests that my 31 usec request is too high; in the fastidious configuration, I'd need a latency of 22 usec, not 31. Does anyone have register-level documentation for the SAA7134, to confirm the maximum tolerated latency with the FIFO configuration Linux uses? Others, like the SAA7134, just don't have that much buffering, and we need to ask the pm core to cope with it. I suspect that most old drivers will need updating if anyone wants to use them with modern systems; either they'll have an architecture like the cx18 series, and the type of work Andy has done will fix the problem, or they'll behave like the saa7134, and need a pm_qos request to ensure that the CPU package (and thus memory controller) stay awake. Unless the chip has a lot of internal memory and processing resources, I suspect a pm_qos solution is needed to ensure the PCI bus responds in time. This is a system level issue though. Having the drivers decide what QoS they need in the absences of total system requirements, is the right thing for the home user. It might not be very friendly for a professional solution where someone is trying to tune the use of the system IO bandwidth and CPU resources. The ivtv driver and cx18 driver unconditionally bumping up their PCI latency timer to 64 cycles minimum always bugged me: drivers shouldn't be deciding QoS in a vaccuum. But, then again, user complaints went away and the 64 PCI cycles seemed to be a minimum QoS that everyone needed. Also both drivers have a ivtv/cx18_pci_latency module option to override the behaviour anyway. So, one trick that the pm_qos request infrastructure gives us is that I only request reduced latency when we are actually streaming. It's up to the pm core to determine what that means - e.g. keep CPU awake, program chipset registers, ignore the request completely. The other part of this is that I'm flagging my QoS requirements; if the wakeup latency is higher than I'm requesting, I'll fail - that is clearly wrong. On the other hand, if you have reasons to want lower wakeup latencies, the core will combine all requests (both userspace and kernelspace), and choose the minimum. If you're sophisticated enough to accept the problems involved in not waking up in time to service DMA requests, you're probably also up to the task of changing the kernel slightly to not request lower latencies. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] saa7134: Add pm_qos_request to fix video corruption
On Monday 29 October 2012 13:44:45 Mauro Carvalho Chehab wrote: Thanks for digging into it and getting more data. Do you know if this change it also needed with USB devices that do DMA (isoc and/or bulk)? Or the USB core already handles that? I'm not a huge expert - the linux-pm list (cc'd) will have people around who know more. If I've understood correctly, though, the USB core should take care of pm_qos requests if they're needed for the hardware; remember that if the HCD has enough buffering, there's no need for a pm_qos request. It's only needed for devices like the SAA7134 where the buffer is small (1K split into pieces) compared to the sample data rate (27 megabytes/second raw video). For the benefit of the linux-pm list; this all starts with me providing a patch to have the saa7134 driver request reduced cpu_dma_latency when streaming, as I've seen buffer exhaustion. We've got far enough to know that the value I chose was wrong for the saa7134, but Mauro also wants guidance on whether USB devices (not host controllers) also need to request reduced latency. -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
[PATCH] saa7134: Add pm_qos_request to fix video corruption
The SAA7134 appears to have trouble buffering more than one line of video
when doing DMA. Rather than try to fix the driver to cope (as has been done
by Andy Walls for the cx18 driver), put in a pm_qos_request to limit deep
sleep exit latencies.
The visible effect of not having this is that seemingly random lines are
only partly transferred - if you feed in a static image, you see a portion
of the image flicker into place.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
As per the comment, note that I've not been able to nail down the maximum
latency the SAA7134 can cope with. I know that the chip has a 1KiB FIFO
buffer, so I'm assuming that it can store half a line of video at a time, on
the basis of 720 luma, 360 Cb, 360 Cr samples, totalling 1440 bytes per
line. If this is a bad assumption (I've not been able to find register-level
documentation for the chip, so I don't know what
saa_writel(SAA7134_FIFO_SIZE, 0x08070503) does in saa7134_hw_enable1() in
saa7134-core.c), that value will need adjusting to match the real FIFO
latency.
drivers/media/pci/saa7134/saa7134-video.c | 12
drivers/media/pci/saa7134/saa7134.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/media/pci/saa7134/saa7134-video.c
b/drivers/media/pci/saa7134/saa7134-video.c
index 4a77124..dbc0b5d 100644
--- a/drivers/media/pci/saa7134/saa7134-video.c
+++ b/drivers/media/pci/saa7134/saa7134-video.c
@@ -2248,6 +2248,15 @@ static int saa7134_streamon(struct file *file, void
*priv,
if (!res_get(dev, fh, res))
return -EBUSY;
+ /* The SAA7134 has a 1K FIFO; the assumption here is that that's
+* enough for half a line of video in the configuration Linux uses.
+* If it isn't, reduce the 31 usec down to the maximum FIFO time
+* allowance.
+*/
+ pm_qos_add_request(fh-qos_request,
+ PM_QOS_CPU_DMA_LATENCY,
+ 31);
+
return videobuf_streamon(saa7134_queue(fh));
}
@@ -2259,6 +2269,8 @@ static int saa7134_streamoff(struct file *file, void
*priv,
struct saa7134_dev *dev = fh-dev;
int res = saa7134_resource(fh);
+ pm_qos_remove_request(fh-qos_request);
+
err = videobuf_streamoff(saa7134_queue(fh));
if (err 0)
return err;
diff --git a/drivers/media/pci/saa7134/saa7134.h
b/drivers/media/pci/saa7134/saa7134.h
index c24b651..d09393b 100644
--- a/drivers/media/pci/saa7134/saa7134.h
+++ b/drivers/media/pci/saa7134/saa7134.h
@@ -29,6 +29,7 @@
#include linux/notifier.h
#include linux/delay.h
#include linux/mutex.h
+#include linux/pm_qos_params.h
#include asm/io.h
@@ -469,6 +470,7 @@ struct saa7134_fh {
enum v4l2_buf_type type;
unsigned int resources;
enum v4l2_priority prio;
+ struct pm_qos_request_list qos_request;
/* video overlay */
struct v4l2_window win;
--
1.7.11.2
--
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: [Intel-gfx] GPU RC6 breaks PCIe to PCI bridge connected to CPU PCIe slot on SandyBridge systems
On Friday 19 October 2012 17:10:17 Simon Farnsworth wrote: Mauro, Linux-Media I have an issue where an SAA7134-based TV capture card connected via a PCIe to PCI bridge chip works when the GPU is kept out of RC6 state, but sometimes skips updating lines of the capture when the GPU is in RC6. We've confirmed that a CX23418 based chip doesn't have the problem, so the question is whether the SAA7134 and the saa7134 driver are at fault, or whether it's the PCIe bus. This manifests as a regression, as I had no problems with kernel 3.3 (which never enabled RC6 on the Intel GPU), but I do have problems with 3.5 and with current Linus git master. I'm happy to try anything, I've attached lspci -vvx output (suitable for feeding to lspci -F) for when the corruption is present (lspci.faulty) and when it's not (lspci.working). The speculation is that the SAA7134 is somehow more sensitive to the changes in timings that RC6 introduces than the CX23418, and that someone who understands the saa7134 driver might be able to make it less sensitive. And timings are definitely the problem; I have a userspace provided pm_qos request asking for 0 exit latency, but I can see CPU cores entering C6. I'll take this problem to an appropriate list. There is still be a bug in the SAA7134 driver, as the card clearly wants a pm_qos request when streaming to stop the DMA latency becoming too high; this doesn't directly affect me, as my userspace always requests minimal DMA latency anyway, so consider this message as just closing down the thread for now, and as a marker for the future (if people see such corruption, the saa7134 driver needs a pm_qos request when streaming that isn't currently present). -- Simon Farnsworth Software Engineer ONELAN Ltd http://www.onelan.com signature.asc Description: This is a digitally signed message part.
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Friday 30 September 2011, Malcolm Priestley tvbox...@gmail.com wrote: On 28/09/11 13:50, Simon Farnsworth wrote: (note - the CC list is everyone over 50% certainty from get_maintainer.pl) I'm having problems getting a Hauppauge HVR-1110 card to successfully tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've determined that the tda18271 is tuning to a frequency 1.25 MHz lower than the vision frequency I've requested, so the following workaround fixes it for me. Are you sure the transmitter concerned doesn't have a VSB filter for an adjacent DVB-T digital transmitter? The transmitter concerned is a test pattern generator - it has no filters applied to its output. The intended customer for this device is in China, hence the use of PAL-D. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Friday 30 September 2011, Andy Walls awa...@md.metrocast.net wrote: Steven Toth st...@kernellabs.com wrote: The TDA18271 driver on linux DOES NOT use the same I/F's that the windows driver uses. Reason? Mike Decided to follow the data sheet and NOT use the Hauppauge specifically select IFs. If you have one of the latest HVR1600's with that analog tuner, does PAL-D work with it without and offset? I don't have a current model HVR-1600 to hand - if I get hold of one, I will test it. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Friday 30 September 2011, Mauro Carvalho Chehab mche...@infradead.org
wrote:
Em 28-09-2011 09:50, Simon Farnsworth escreveu:
(note - the CC list is everyone over 50% certainty from get_maintainer.pl)
I'm having problems getting a Hauppauge HVR-1110 card to successfully
tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've
determined that the tda18271 is tuning to a frequency 1.25 MHz lower
than the vision frequency I've requested, so the following workaround
fixes it for me.
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 63cc400..1a94e1a 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -1031,6 +1031,7 @@ static int tda18271_set_analog_params(struct
dvb_frontend *fe,
mode = I;
} else if (params-std V4L2_STD_DK) {
map = std_map-atv_dk;
+freq += 125;
mode = DK;
} else if (params-std V4L2_STD_SECAM_L) {
map = std_map-atv_l;
If I am to fix this bug, instead of a hack like that, it seems to be better
to split the .atv_dk line at the struct tda18271_std_map maps on
drivers/media/common/tuners/tda18271-maps.c.
Looking at the datasheet, on page 43, available at:
http://www.nxp.com/documents/data_sheet/TDA18271HD.pdf
The offset values for IF seem ok, but maybe your device is using some variant
of this chip that requires a different maps table.
How would I identify that?
I definitely need the hack on multiple different HVR1110 cards, in different
motherboards, so if it's a new variant needing a new maps table, it should
be possible to distinguish it from the other devices somehow - but I have no
idea how.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Friday 30 September 2011, Mauro Carvalho Chehab mche...@infradead.org
wrote:
Em 28-09-2011 09:50, Simon Farnsworth escreveu:
(note - the CC list is everyone over 50% certainty from get_maintainer.pl)
I'm having problems getting a Hauppauge HVR-1110 card to successfully
tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've
determined that the tda18271 is tuning to a frequency 1.25 MHz lower
than the vision frequency I've requested, so the following workaround
fixes it for me.
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 63cc400..1a94e1a 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -1031,6 +1031,7 @@ static int tda18271_set_analog_params(struct
dvb_frontend *fe,
mode = I;
} else if (params-std V4L2_STD_DK) {
map = std_map-atv_dk;
+freq += 125;
mode = DK;
} else if (params-std V4L2_STD_SECAM_L) {
map = std_map-atv_l;
If I am to fix this bug, instead of a hack like that, it seems to be better
to split the .atv_dk line at the struct tda18271_std_map maps on
drivers/media/common/tuners/tda18271-maps.c.
Looking at the datasheet, on page 43, available at:
http://www.nxp.com/documents/data_sheet/TDA18271HD.pdf
The offset values for IF seem ok, but maybe your device is using some variant
of this chip that requires a different maps table.
How would I identify this? I definitely need the hack on multiple different
HVR1110 cards, in different motherboards. I get apparently perfect reception
if I apply the hack, so clearly something is wrong.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.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
Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
(note - the CC list is everyone over 50% certainty from get_maintainer.pl)
I'm having problems getting a Hauppauge HVR-1110 card to successfully
tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've
determined that the tda18271 is tuning to a frequency 1.25 MHz lower
than the vision frequency I've requested, so the following workaround
fixes it for me.
diff --git a/drivers/media/common/tuners/tda18271-fe.c
b/drivers/media/common/tuners/tda18271-fe.c
index 63cc400..1a94e1a 100644
--- a/drivers/media/common/tuners/tda18271-fe.c
+++ b/drivers/media/common/tuners/tda18271-fe.c
@@ -1031,6 +1031,7 @@ static int tda18271_set_analog_params(struct
dvb_frontend *fe,
mode = I;
} else if (params-std V4L2_STD_DK) {
map = std_map-atv_dk;
+freq += 125;
mode = DK;
} else if (params-std V4L2_STD_SECAM_L) {
map = std_map-atv_l;
I've checked with a signal analyser, and confirmed that my signal
generator is getting the spectrum right - I am seeing vision peaking
at 85.25 MHz, with one sideband going down to 84.5 MHz, and the other
going up to 90.5MHz. I also see an audio carrier at 91.75 MHz.
I'm going to run with this hack in place, but I'd appreciate it if
someone who knew more about the TDA18271 looked at this, and either
gave me a proper fix for testing, or confirmed that what I'm doing is
right.
--
Simon Farnsworth
Software Engineer
ONELAN Limited
http://www.onelan.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems tuning PAL-D with a Hauppauge HVR-1110 (TDA18271 tuner) - workaround hack included
On Wednesday 28 September 2011, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hi Simon, On Wed, Sep 28, 2011 at 8:50 AM, Simon Farnsworth simon.farnswo...@onelan.com wrote: I'm having problems getting a Hauppauge HVR-1110 card to successfully tune PAL-D at 85.250 MHz vision frequency; by experimentation, I've determined that the tda18271 is tuning to a frequency 1.25 MHz lower than the vision frequency I've requested, so the following workaround fixes it for me. I'm going to run with this hack in place, but I'd appreciate it if someone who knew more about the TDA18271 looked at this, and either gave me a proper fix for testing, or confirmed that what I'm doing is right. Hi Simon, This is interesting. I did some testing with an 18271 based device a few months back (a Hauppauge cx231xx based tuner), and I believe PAL-DK was working (although I did have unrelated issues with the DIF configuration). When you are doing the tuning request, are you explicitly stating PAL-D in your calling application? Or are you passing PAL to the V4L layer and expecting it to work with a PAL-D feed? I'm noticing this problem because I fixed a bug of ours, where we were passing PAL to the V4L2 layer, and expecting it to work (video did, at the correct frequency, but audio did not, as the TDA18271 chose PAL-B). Having fixed the bug, I was having to either adjust my signal generator down by 1.25MHz, or adjust the frequency I passed to V4L2 up by 1.25MHz to make PAL-D work. Hence the hack - I've confirmed that with the hack in place, I can get colour video from the signal if I use PAL-B or PAL-D, and sound if I use PAL-D. Without the hack, I need to change the frequency as I toggle between PAL-B and PAL-D, or I lose video. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.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
[PATCH] cx18: Fix videobuf capture
When we moved to 3.0, we found that the cx18 driver was oopsing on close with:
NULL pointer deref at:
EIP: [c05ef145] __list_add+0x3e/0x81 SS:ESP 0068:f461be7c
[ 2290.461009] Call Trace:
[ 2290.461009] [c046007b] ? pm_qos_add_request+0xc/0x6e
[ 2290.461009] [c082631c] __mutex_lock_common+0x87/0x125
[ 2290.461009] [f8970e92] ? cx18_queue_flush+0x31/0x87 [cx18]
[ 2290.461009] [c0436b85] ? __might_sleep+0x29/0xe4
[ 2290.461009] [c0826515] __mutex_lock_slowpath+0x25/0x27
[ 2290.461009] [c08264b2] ? mutex_lock+0x2e/0x3b
[ 2290.461009] [c08264b2] mutex_lock+0x2e/0x3b
[ 2290.461009] [f88d3137] videobuf_queue_lock+0x13/0x15 [videobuf_core]
[ 2290.461009] [f88d3f86] __videobuf_free+0xfc/0x112 [videobuf_core]
[ 2290.461009] [f89741e6] cx18_v4l2_close+0x158/0x172 [cx18]
[ 2290.461009] [c0507522] ? cpumask_next+0x1a/0x1d
[ 2290.461009] [f88a319d] v4l2_release+0x35/0x52 [videodev]
[ 2290.461009] [c04f5717] fput+0x100/0x1a5
[ 2290.461009] [c04f2e09] filp_close+0x5c/0x64
[ 2290.461009] [c04f2e70] sys_close+0x5f/0x93
[ 2290.461009] [c082cd5f] sysenter_do_call+0x12/0x28
Some digging showed that a merge at some previous point partially
added broken mmap() support, causing this trace. Remove the broken
code completely.
On top of that, the calculation in place for buffer full depended on
UYUV instead of HM12, while our GStreamer code was picking HM12 in
some circumstances.
Finally, the V4L2_CAP_STREAMING capability was never exposed. Patch it
into the YUV encoder node only.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
This patch, against linuxtv/staging/for_v3.2, makes the upstream code
for videobuf-based YUV capture work for me. While it has a sign-off,
I'm sending it more in the spirit of not keeping bugfixes secret
rather than because I think it's in good state to apply.
drivers/media/video/cx18/cx18-driver.h |5 +
drivers/media/video/cx18/cx18-fileops.c |2 --
drivers/media/video/cx18/cx18-ioctl.c | 18 +++---
drivers/media/video/cx18/cx18-mailbox.c |2 +-
drivers/media/video/cx18/cx18-streams.c | 13 +
5 files changed, 26 insertions(+), 14 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-driver.h
b/drivers/media/video/cx18/cx18-driver.h
index 1834207..b9a94fc 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -409,6 +409,7 @@ struct cx18_stream {
/* Videobuf for YUV video */
u32 pixelformat;
+ u32 vb_bytes_per_frame;
struct list_head vb_capture;/* video capture queue */
spinlock_t vb_lock;
struct timer_list vb_timeout;
@@ -430,10 +431,6 @@ struct cx18_open_id {
u32 open_id;
int type;
struct cx18 *cx;
-
- struct videobuf_queue vbuf_q;
- spinlock_t s_lock; /* Protect vbuf_q */
- enum v4l2_buf_type vb_type;
};
static inline struct cx18_open_id *fh2id(struct v4l2_fh *fh)
diff --git a/drivers/media/video/cx18/cx18-fileops.c
b/drivers/media/video/cx18/cx18-fileops.c
index 07411f3..14cb961 100644
--- a/drivers/media/video/cx18/cx18-fileops.c
+++ b/drivers/media/video/cx18/cx18-fileops.c
@@ -784,8 +784,6 @@ int cx18_v4l2_close(struct file *filp)
cx18_release_stream(s);
} else {
cx18_stop_capture(id, 0);
- if (id-type == CX18_ENC_STREAM_TYPE_YUV)
- videobuf_mmap_free(id-vbuf_q);
}
kfree(id);
mutex_unlock(cx-serialize_lock);
diff --git a/drivers/media/video/cx18/cx18-ioctl.c
b/drivers/media/video/cx18/cx18-ioctl.c
index afe0a29..66b1c15 100644
--- a/drivers/media/video/cx18/cx18-ioctl.c
+++ b/drivers/media/video/cx18/cx18-ioctl.c
@@ -160,12 +160,7 @@ static int cx18_g_fmt_vid_cap(struct file *file, void *fh,
pixfmt-priv = 0;
if (id-type == CX18_ENC_STREAM_TYPE_YUV) {
pixfmt-pixelformat = s-pixelformat;
- /* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
- UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
- if (s-pixelformat == V4L2_PIX_FMT_HM12)
- pixfmt-sizeimage = pixfmt-height * 720 * 3 / 2;
- else
- pixfmt-sizeimage = pixfmt-height * 720 * 2;
+ pixfmt-sizeimage = s-vb_bytes_per_frame;
pixfmt-bytesperline = 720;
} else {
pixfmt-pixelformat = V4L2_PIX_FMT_MPEG;
@@ -296,6 +291,12 @@ static int cx18_s_fmt_vid_cap(struct file *file, void *fh,
return -EBUSY;
s-pixelformat = fmt-fmt.pix.pixelformat;
+ /* HM12 YUV size is (Y=(h*720) + UV=(h*(720/2)))
+ UYUV YUV size is (Y=(h*720) + UV=(h*(720))) */
+ if (s-pixelformat == V4L2_PIX_FMT_HM12)
+ s-vb_bytes_per_frame = h * 720 * 3 / 2;
+ else
+ s-vb_bytes_per_frame = h * 720 * 2;
mbus_fmt.width = cx-cxhdl.width = w;
mbus_fmt.height = cx-cxhdl.height = h;
@@ -463,13
[PATCH] cx18: Move spinlock and vb_type initialisation into stream_init
The initialisation of vb_type in serialized_open was preventing
REQBUFS from working reliably. Remove it, and move the spinlock into
stream_init for good measure - it's only used when we have a stream
that supports videobuf anyway.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,
This fixes a bug I introduced, and noticed while trying to work out
how videobuf works and interacts with the rest of the driver, in
preparation for working out how to port this code to videobuf2.
Briefly, if you open a device node at the wrong time, you lose
videobuf support forever.
Please consider this for 2.6.40,
Simon
drivers/media/video/cx18/cx18-fileops.c |3 ---
drivers/media/video/cx18/cx18-streams.c |2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-fileops.c
b/drivers/media/video/cx18/cx18-fileops.c
index 6609222..07411f3 100644
--- a/drivers/media/video/cx18/cx18-fileops.c
+++ b/drivers/media/video/cx18/cx18-fileops.c
@@ -810,9 +810,6 @@ static int cx18_serialized_open(struct cx18_stream *s,
struct file *filp)
item-cx = cx;
item-type = s-type;
- spin_lock_init(s-vbuf_q_lock);
- s-vb_type = 0;
-
item-open_id = cx-open_id++;
filp-private_data = item-fh;
diff --git a/drivers/media/video/cx18/cx18-streams.c
b/drivers/media/video/cx18/cx18-streams.c
index 24c9688..4282ff5 100644
--- a/drivers/media/video/cx18/cx18-streams.c
+++ b/drivers/media/video/cx18/cx18-streams.c
@@ -275,6 +275,8 @@ static void cx18_stream_init(struct cx18 *cx, int type)
init_timer(s-vb_timeout);
spin_lock_init(s-vb_lock);
if (type == CX18_ENC_STREAM_TYPE_YUV) {
+ spin_lock_init(s-vbuf_q_lock);
+
s-vb_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
videobuf_queue_vmalloc_init(s-vbuf_q, cx18_videobuf_qops,
cx-pci_dev-dev, s-vbuf_q_lock,
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx18: Fix warnings introduced during cleanup
I misused the ktime API, and failed to remove some traces of the
in-kernel format conversion. Fix these, so the the driver builds
without warnings.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,
You may want to squash this in with the cleanup patch itself - it's
plain and simple oversight on my part (I should have seen the compiler
warnings), and I should not have sent the cleanup patch to you without
fixing these errors.
Sorry,
Simon
drivers/media/video/cx18/cx18-mailbox.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-mailbox.c
b/drivers/media/video/cx18/cx18-mailbox.c
index 5ecae93..c07191e 100644
--- a/drivers/media/video/cx18/cx18-mailbox.c
+++ b/drivers/media/video/cx18/cx18-mailbox.c
@@ -164,10 +164,9 @@ static void cx18_mdl_send_to_videobuf(struct cx18_stream
*s,
{
struct cx18_videobuf_buffer *vb_buf;
struct cx18_buffer *buf;
- u8 *p, u;
+ u8 *p;
u32 offset = 0;
int dispatch = 0;
- int i;
if (mdl-bytesused == 0)
return;
@@ -203,7 +202,7 @@ static void cx18_mdl_send_to_videobuf(struct cx18_stream *s,
}
if (dispatch) {
- ktime_get_ts(vb_buf-vb.ts);
+ vb_buf-vb.ts = ktime_to_timeval(ktime_get());
list_del(vb_buf-vb.queue);
vb_buf-vb.state = VIDEOBUF_DONE;
wake_up(vb_buf-vb.done);
--
1.7.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
Re: [PATCH] cx18: Clean up mmap() support for raw YUV
On Thursday 5 May 2011, Mauro Carvalho Chehab mche...@redhat.com wrote: There are a few new warnings with your code: drivers/media/video/cx18/cx18-mailbox.c: In function ‘cx18_mdl_send_to_videobuf’: drivers/media/video/cx18/cx18-mailbox.c:206: warning: passing argument 1 of ‘ktime_get_ts’ from incompatible pointer type include/linux/ktime.h:331: note: expected ‘struct timespec *’ but argument is of type ‘struct timeval *’ drivers/media/video/cx18/cx18-mailbox.c:170: warning: unused variable ‘i’ drivers/media/video/cx18/cx18-mailbox.c:167: warning: unused variable ‘u’ Could you please fix them? I'm not doing well on the driving git front today, and I've managed to send the fix patch with a wrong In-reply-to; it's message ID is 1304599356-21951-1-git-send-email-simon.farnswo...@onelan.co.uk, and it's elsewhere in this thread (in reply to 4dc138f7.5050...@infradead.org) -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx18: Fix warnings introduced during cleanup
On Thursday 5 May 2011, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 05-05-2011 09:42, Simon Farnsworth escreveu: I misused the ktime API, and failed to remove some traces of the in-kernel format conversion. Fix these, so the the driver builds without warnings. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Mauro, You may want to squash this in with the cleanup patch itself - it's plain and simple oversight on my part (I should have seen the compiler warnings), and I should not have sent the cleanup patch to you without fixing these errors. It will all depend on how much time I'll have during the next merge window. I can't do it at the already-applied patches, as other people use it as basis, and a rebase there would break its clones. Mauro. No problem; if it ends up as a separate patch in the tree, it's not going to hurt, as the version with warnings functions adequately enough to not break bisection. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx18: Clean up mmap() support for raw YUV
On Tuesday 3 May 2011, Andy Walls awa...@md.metrocast.net wrote: Simon, If these two changes are going in, please also bump the driver version to 1.5.0 in cx18-version.c. These changes are significant enough perturbation. End users are going to look to driver version 1.4.1 as the first version for proper analog tuner support of the HVR1600 model 74351. Mauro, Is cx18 v1.4.1 with HVR1600 model 74351 analog tuner support, without these mmap() changes going to be visible in kernel version .39 ? Mauro, If you're going to accept these two patches, would you mind bumping the version in cx18-version.c for me as you apply them, or would you prefer me to provide either an incremental patch or a new patch with the bump added? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.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
[PATCH] cx18: Bump driver version to 1.5.0
To simplify maintainer support of this driver, bump the version to 1.5.0 - this will be the first version that is expected to support mmap() for raw video frames. Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk --- Mauro, This is an incremental patch to apply on top of my cleanup patch - if you would prefer a complete new patch with this squashed into the cleanup patch, just ask and it will be done. drivers/media/video/cx18/cx18-version.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/cx18/cx18-version.h b/drivers/media/video/cx18/cx18-version.h index 62c6ca2..cd189b6 100644 --- a/drivers/media/video/cx18/cx18-version.h +++ b/drivers/media/video/cx18/cx18-version.h @@ -24,8 +24,8 @@ #define CX18_DRIVER_NAME cx18 #define CX18_DRIVER_VERSION_MAJOR 1 -#define CX18_DRIVER_VERSION_MINOR 4 -#define CX18_DRIVER_VERSION_PATCHLEVEL 1 +#define CX18_DRIVER_VERSION_MINOR 5 +#define CX18_DRIVER_VERSION_PATCHLEVEL 0 #define CX18_VERSION __stringify(CX18_DRIVER_VERSION_MAJOR) . __stringify(CX18_DRIVER_VERSION_MINOR) . __stringify(CX18_DRIVER_VERSION_PATCHLEVEL) #define CX18_DRIVER_VERSION KERNEL_VERSION(CX18_DRIVER_VERSION_MAJOR, \ -- 1.7.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
Re: [git:v4l-dvb/for_v2.6.40] [media] cx18: mmap() support for raw YUV video capture
On Monday 2 May 2011, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 02-05-2011 16:11, Hans Verkuil escreveu: NACK. For two reasons: first of all it is not signed off by Andy Walls, the cx18 maintainer. I know he has had other things on his plate recently which is probably why he hasn't had the chance to review this. Secondly, while doing a quick scan myself I noticed that this code does a conversion from UYVY format to YUYV *in the driver*. Format conversion is not allowed in the kernel, we have libv4lconvert for that. So at the minimum this conversion code must be removed first. Patch is there at the ML since Apr, 6 and nobody acked/nacked it. If you or andy were against it, why none of you commented it there? Now that the patch were committed, I won't revert it without a very good reason. With respect to the conversion from UYVY format to YUYV, a simple patch could fix it, instead of removing the entire patchset. Steven/Simon, could you please work on such change? I received feedback, which I've been working on, and have converted to a new patch against the baseline tree without this patch applied. I can obviously rebase (thanks, git!) so that it applies on top of this patch. It massively cleans up the code, fixes a bug, and removes the in-kernel format conversion (we use libv4l here anyway, so it's not needed) I have one more work item, requested by Andy and Hans, and that's to convert just the YUV capture from videobuf to vb2, so that when Andy's got spare time again, it'll be easier for him to convert the whole driver. I've been delayed on this by other work committments, but I do have this on my schedule. How do you want me to proceed? -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v2.6.40] [media] cx18: mmap() support for raw YUV video capture
On Tuesday 3 May 2011, Hans Verkuil hansv...@cisco.com wrote: On Tuesday, May 03, 2011 14:49:43 Devin Heitmueller wrote: Asking us to be the guinea pig for this new framework just because cx18 is the most recent driver to get a videobuf related patch just isn't appropriate. I don't get it. What better non-embedded driver to implement vb2 in than one that doesn't yet do stream I/O? The risks of breaking anything are much smaller and it would be a good 'gentle introduction' to vb2. Also, it prevents the unnecessary overhead of having to replace videobuf in the future in cx18. Just for everyone's information; I've been caught up in other issues here, so I'm unlikely to get onto changing videobuf to vb2 in this code in the next week or so. However, if someone else had just enough free time to convert the existing patch for me, I can free up enough time to test with our application and with GStreamer, to confirm that the conversion works adequately. -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.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
[PATCH] cx18: mmap() support for raw YUV video capture
Add support for mmap method streaming of raw YUV video on cx18-based
hardware, in addition to the existing support for read() streaming of
raw YUV and MPEG-2 encoded video.
Signed-off-by: Steven Toth st...@kernellabs.com
I forward-ported this from Steven's original work, done under contract
to ONELAN. The original code is at
http://www.kernellabs.com/hg/~stoth/cx18-videobuf
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
I'm currently running an older version of this patch on a 2.6.37
kernel - I figured I should try and get this into mainline sooner
rather than later, given the current rate of change in V4L2.
I've compile tested this patch against
git://linuxtv.org/media_tree.git staging/for_v2.6.40
I can rework or port to a different tree as required, but for some of
the more complex changes, I may need a bit of guidance.
drivers/media/video/cx18/Kconfig|2 +
drivers/media/video/cx18/cx18-driver.h | 25
drivers/media/video/cx18/cx18-fileops.c | 214 +++
drivers/media/video/cx18/cx18-fileops.h |2 +
drivers/media/video/cx18/cx18-ioctl.c | 136 ++--
drivers/media/video/cx18/cx18-mailbox.c | 70 ++
drivers/media/video/cx18/cx18-streams.c | 23
drivers/media/video/cx18/cx23418.h |6 +
8 files changed, 466 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/cx18/Kconfig b/drivers/media/video/cx18/Kconfig
index d9d2f6a..104ad55e 100644
--- a/drivers/media/video/cx18/Kconfig
+++ b/drivers/media/video/cx18/Kconfig
@@ -2,6 +2,8 @@ config VIDEO_CX18
tristate Conexant cx23418 MPEG encoder support
depends on VIDEO_V4L2 DVB_CORE PCI I2C EXPERIMENTAL
select I2C_ALGOBIT
+ select VIDEOBUF_DVB
+ select VIDEOBUF_VMALLOC
depends on RC_CORE
select VIDEO_TUNER
select VIDEO_TVEEPROM
diff --git a/drivers/media/video/cx18/cx18-driver.h
b/drivers/media/video/cx18/cx18-driver.h
index b86a740..70e1e04 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -65,6 +65,10 @@
#include dvb_net.h
#include dvbdev.h
+/* Videobuf / YUV support */
+#include media/videobuf-core.h
+#include media/videobuf-vmalloc.h
+
#ifndef CONFIG_PCI
# error This driver requires kernel PCI support.
#endif
@@ -403,6 +407,23 @@ struct cx18_stream {
struct cx18_queue q_idle; /* idle - not in rotation */
struct work_struct out_work_order;
+
+ /* Videobuf for YUV video */
+ u32 pixelformat;
+ struct list_head vb_capture;/* video capture queue */
+ spinlock_t vb_lock;
+ struct v4l2_framebuffer fbuf;
+ v4l2_std_id tvnorm; /* selected tv norm */
+ struct timer_list vb_timeout;
+ int vbwidth;
+ int vbheight;
+};
+
+struct cx18_videobuf_buffer {
+ /* Common video buffer sub-system struct */
+ struct videobuf_buffer vb;
+ v4l2_std_id tvnorm; /* selected tv norm */
+ u32 bytes_used;
};
struct cx18_open_id {
@@ -410,6 +431,10 @@ struct cx18_open_id {
u32 open_id;
int type;
struct cx18 *cx;
+
+ struct videobuf_queue vbuf_q;
+ spinlock_t s_lock; /* Protect vbuf_q */
+ enum v4l2_buf_type vb_type;
};
static inline struct cx18_open_id *fh2id(struct v4l2_fh *fh)
diff --git a/drivers/media/video/cx18/cx18-fileops.c
b/drivers/media/video/cx18/cx18-fileops.c
index e9802d9..c74eafd 100644
--- a/drivers/media/video/cx18/cx18-fileops.c
+++ b/drivers/media/video/cx18/cx18-fileops.c
@@ -597,6 +597,13 @@ ssize_t cx18_v4l2_read(struct file *filp, char __user
*buf, size_t count,
mutex_unlock(cx-serialize_lock);
if (rc)
return rc;
+
+ if ((id-vb_type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ (id-type == CX18_ENC_STREAM_TYPE_YUV)) {
+ return videobuf_read_stream(id-vbuf_q, buf, count, pos, 0,
+ filp-f_flags O_NONBLOCK);
+ }
+
return cx18_read_pos(s, buf, count, pos, filp-f_flags O_NONBLOCK);
}
@@ -622,6 +629,11 @@ unsigned int cx18_v4l2_enc_poll(struct file *filp,
poll_table *wait)
CX18_DEBUG_FILE(Encoder poll started capture\n);
}
+ if ((id-vb_type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ (id-type == CX18_ENC_STREAM_TYPE_YUV)) {
+ return videobuf_poll_stream(filp, id-vbuf_q, wait);
+ }
+
/* add stream's waitq to the poll list */
CX18_DEBUG_HI_FILE(Encoder poll\n);
poll_wait(filp, s-waitq, wait);
@@ -633,6 +645,58 @@ unsigned int cx18_v4l2_enc_poll(struct file *filp,
poll_table *wait)
return 0;
}
+int cx18_v4l2_mmap(struct file *file, struct vm_area_struct *vma)
+{
+ struct cx18_open_id *id = file-private_data;
+ struct cx18 *cx = id-cx;
+ struct cx18_stream *s = cx-streams[id-type];
+ int eof = test_bit(CX18_F_S_STREAMOFF, s-s_flags);
+
+ if ((id-vb_type
Re: Adaptec VideOh! DVD Media Center
Paulo Assis wrote: For the box to function it needs a firmware upload. Currently this is managed by a udev script that in turn calls an application (multiload) that provides for the upload. What I would like to know is, if this the best way to handle it? The problem with this process is that it will always require installing and configuring additional software (multiload and udev script), besides the firmware. Is there any simpler/standard way of handling these firmware uploads ? Look at Documentation/firmware_class/README. There's a mechanism called request_firmware() that does what you want; it's used in several V4L drivers if you need an example usage. -- Simon Farnsworth -- 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: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Andy Walls wrote: Right, the windows driver code for the mxl5005s is better. Inform him that the linux driver for the mxl5005s could be better. If he has any contacts at MaxLinear to get the datasheet and programming manual released to me, I can make the linux driver better. We don't have contacts that we know of, but we're happy to chase after a datasheet for you if Devin's copy isn't enough - just let me know. The MXL5005s is the silicon tuner chip on the Digital TV side of the HVR-1600. A simple picture for you: Cable ---| MXL5005s || CX24227 || CX23418 |--- PCI bus Analog Waveform---|Digital Data-- That's nice and clear, and explains things to me perfectly. Thank you. Here's my HVR-1600 related entries from dmesg on startup. I have the MXL5005S showing up at 9.510: [9.510767] MXL5005S: Attached at address 0x63 So basically, I was being blind and/or stupid - with this to hand, I've found the equivalent message in my dmesg. -- Simon Farnsworth -- 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
Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Hello, I'm having problems with glitchy reception on a HVR-1600 card using ClearQAM digital cable channels. Unfortunately, I'm remote from the box, so can't describe the visual appearance, but I do have SSH access. Looking at the output of femon -c 100 (attached as femon.txt), I'm seeing the occasional burst of UNC errors. I've attached dmesg as dmesg.txt in case it gives any clues; the v4l drivers are as in kernel 2.6.30 from Linus, with no extra patches. I'm using Xine to decode the channel - my channels.conf line for the channel in question is: WTAE:567012500:QAM_256:0:0:5 Any ideas? -- I can do any further investigation or experiments required, Simon Farnsworth Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.30-1.NTB5.fc8.i686.PAE (sfarnswo...@f8simon.office.onelan.co.uk) (gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)) #1 SMP Thu Jul 30 19:28:43 BST 2009 KERNEL supported cpus: Intel GenuineIntel AMD AuthenticAMD NSC Geode by NSC Cyrix CyrixInstead Centaur CentaurHauls Transmeta GenuineTMx86 Transmeta TransmetaCPU UMC UMC UMC UMC BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3f79 (usable) BIOS-e820: 3f79 - 3f79e000 (ACPI data) BIOS-e820: 3f79e000 - 3f7efa60 (ACPI NVS) BIOS-e820: 3f7efa60 - 3f80 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) DMI present. AMI BIOS detected: BIOS may corrupt low RAM, working around it. e820 update range: - 0001 (usable) == (reserved) last_pfn = 0x3f790 max_arch_pfn = 0x10 MTRR default type: uncachable MTRR fixed ranges enabled: 0-9 write-back A-D uncachable E-E3FFF write-protect E4000-E7FFF write-through E8000-EBFFF write-protect EC000-E write-through F-F write-protect MTRR variable ranges enabled: 0 base 0 mask FC000 write-back 1 base 03F80 mask FFF80 uncachable 2 disabled 3 disabled 4 disabled 5 disabled 6 disabled 7 disabled x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 original variable MTRRs reg 0, base: 0GB, range: 1GB, type WB reg 1, base: 1016MB, range: 8MB, type UC total RAM coverred: 1016M Found optimal setting for mtrr clean up gran_size: 64K chunk_size: 16M num_reg: 2 lose cover RAM: 0G New variable MTRRs reg 0, base: 0GB, range: 1GB, type WB reg 1, base: 1016MB, range: 8MB, type UC x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 init_memory_mapping: -377fe000 Using x86 segment limits to approximate NX protection 00 - 40 page 4k 40 - 003740 page 2M 003740 - 00377fe000 page 4k kernel direct mapping tables up to 377fe000 @ 1-15000 RAMDISK: 37e04000 - 37fef2e9 Allocated new RAMDISK: 0010 - 002eb2e9 Move RAMDISK from 37e04000 - 37fef2e8 to 0010 - 002eb2e8 ACPI: RSDP 000f9120 00014 (v00 ACPIAM) ACPI: RSDT 3f79 00040 (v01 110608 RSDT1528 20081106 MSFT 0097) ACPI: FACP 3f790200 00084 (v02 110608 FACP1528 20081106 MSFT 0097) ACPI: DSDT 3f790430 05DF9 (v01 965GA 965GA013 0013 INTL 20051117) ACPI: FACS 3f79e000 00040 ACPI: APIC 3f790390 0005C (v01 110608 APIC1528 20081106 MSFT 0097) ACPI: MCFG 3f7903f0 0003C (v01 110608 OEMMCFG 20081106 MSFT 0097) ACPI: OEMB 3f79e040 00071 (v01 110608 OEMB1528 20081106 MSFT 0097) ACPI: GSCI 3f79e0c0 02024 (v01 110608 GMCHSCI 20081106 MSFT 0097) ACPI: TCPA 3f796230 00032 (v01 110608 TBLOEMID 0001 MSFT 0097) ACPI: SSDT 3f7a2810 004E6 (v01 PmRefCpuPm 3000 INTL 20051117) ACPI: Local APIC address 0xfee0 127MB HIGHMEM available. 887MB LOWMEM available. mapped low ram: 0 - 377fe000 low ram: 0 - 377fe000 node 0 low ram: - 377fe000 node 0 bootmap 00011000 - 00017f00 (9 early reservations) == bootmem [00 - 00377fe000] #0 [00 - 001000] BIOS data page == [00 - 001000] #1 [001000 - 002000]EX TRAMPOLINE == [001000 - 002000] #2 [006000 - 007000] TRAMPOLINE == [006000 - 007000] #3 [40 - a14008]TEXT DATA BSS == [40 - a14008] #4 [09fc00 - 10]BIOS reserved == [09fc00 - 10] #5 [a15000 - a18193] BRK == [a15000 - a18193] #6 [01 - 011000] PGTABLE == [01 - 011000] #7 [10 - 2eb2e9] NEW RAMDISK == [10 - 2eb2e9] #8 [011000 - 018000] BOOTMAP == [011000 - 018000] found SMP MP-table at [c00ff780] ff780 Zone PFN ranges: DMA 0x0010 - 0x1000 Normal 0x1000
Re: Poor reception with Hauppauge HVR-1600 on a ClearQAM cable feed
Andy Walls wrote: Have your remote user read http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take any actions that seem appropriate/easy. I'll try that again - they're grouching, because their TV is fine, and the same card in a Windows PC is also fine. It's just under Linux that they're seeing problems, so I may not be able to get them to co-operate. The in kernel mxl5005s driver is known to have about 3 dB worse performance for QAM vs 8-VSB (Steven Toth took some measurements once). Am I misunderstanding dmesg here? I see references to a Samsung S5H1409, not to an mxl5005s; if I've read the driver code correctly, I'd see a KERN_INFO printk for the mxl5005s when it comes up. -- Simon Farnsworth -- 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
ALSA support in cx18
Hello Andy, Just a brief note to let you know that ALSA support in cx18 is near the top of my priorities now. I'm going to start with your work at http://linuxtv.org/hg/~awalls/mc-lab -- I'll send patches as and when I get things working, Simon Farnsworth -- 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: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Hans de Goede wrote: Hi, On 09/02/2009 06:32 PM, Simon Farnsworth wrote: I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to simply not work with libv4l2, due to lack of mmap support. My code works adequately (modulo a nice pile of bugs) with a HVR1110r3, so it appears to be driver level. Which is the better route to handling this; adding code to input_v4l to use libv4lconvert when mmap isn't available, or converting the cx18 driver to use mmap? Or modify libv4l2 to also handle devices which can only do read. There have been some changes to libv4l2 recently which would make doing that feasible. Roughly what would I need to do to libv4l2? I can see four new cases to handle: 1) driver supports read(), client wants read(), format supported by both. Just pass read() through to the driver. 2) driver supports read(), client wants mmap(), format supported by both. Allocate buffers when REQBUFs happens, handle QBUF and DQBUF by read()ing frame size chunks into the buffer at the head of the internal queue when a DQBUF happens, and passing it back out. 3) As 1, but needs conversion. read() into a temporary buffer, convert with libv4lconvert (I think this needs a secondary buffer), and supply data from the secondary buffer to read() 4) As 2, but needs conversion. Change DQBUF handling to read() frame size chunks into a temporary buffer, then use libv4lconvert to copy those chunks from the temporary buffer into the buffer you're about to pass out. Have I missed anything? If it's a case of converting the cx18 driver, how would I go about doing that? I have no experience of the driver, so I'm not sure what I'd have to do - noting that if I break the existing read() support, other users will get upset. I don't believe that modifying the driver is the answer, we need to either fix this at the libv4l or xine level. I wonder though, doesn't the cx18 offer any format that xine can handle directly? Not sensibly; it offers HM12 only, and Xine needs an RGB format, YV12, or YUYV. With a lot of rework, I could have the cx18 encode video to MPEG-2, then have Xine decode the resulting MPEG-2 stream, but this seems like overkill for uncompressed video. I could also teach Xine to handle HM12 natively, but that would duplicate effort already done in libv4l2 and libv4lconvert, which seems a bit silly to me. -- Simon Farnsworth -- 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: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Hans de Goede wrote: Ok, That was even easier then I thought it would be. Attached is a patch (against libv4l-0.6.1), which implements 1) and 3) from above. I applied it to a clone of your HG repository, and had to make a minor change to get it to compile. I've attached the updated patch. It looks like the read() from the card isn't reading entire frames ata a time - I'm using a piece of test gear that I have to return in a couple of hours to send colourbars to it, and I'm seeing bad colour, and the picture moving across the screen. I'll try and chase this, see whether there's something obviously wrong. The repository I went against was http://linuxtv.org/hg/~hgoede/libv4l/ identified as: $ hg identify c51a90c0f62f+ tip -- Simon Farnsworth diff -r c51a90c0f62f v4l2-apps/libv4l/libv4l2/libv4l2.c --- a/v4l2-apps/libv4l/libv4l2/libv4l2.cTue Sep 01 10:03:27 2009 +0200 +++ b/v4l2-apps/libv4l/libv4l2/libv4l2.cThu Sep 03 11:17:05 2009 +0100 @@ -526,10 +526,9 @@ return -1; } - /* we only add functionality for video capture devices, and we do not - handle devices which don't do mmap */ + /* we only add functionality for video capture devices */ if (!(cap.capabilities V4L2_CAP_VIDEO_CAPTURE) || - !(cap.capabilities V4L2_CAP_STREAMING)) + !(cap.capabilities (V4L2_CAP_STREAMING|V4L2_CAP_READWRITE))) return fd; /* Get current cam format */ @@ -564,6 +563,8 @@ devices[index].flags = v4l2_flags; if (cap.capabilities V4L2_CAP_READWRITE) devices[index].flags |= V4L2_SUPPORTS_READ; + if (!(cap.capabilities V4L2_CAP_STREAMING)) +devices[index].flags |= V4L2_USE_READ_FOR_READ; if (!strcmp((char *)cap.driver, uvcvideo)) devices[index].flags |= V4L2_IS_UVC; devices[index].open_count = 1; @@ -571,7 +572,7 @@ devices[index].dest_fmt = fmt; /* When a user does a try_fmt with the current dest_fmt and the dest_fmt - is a supported one we will align the resulution (see try_fmt for why). + is a supported one we will align the resolution (see try_fmt for why). Do the same here now, so that a try_fmt on the result of a get_fmt done immediately after open leaves the fmt unchanged. */ if (v4lconvert_supported_dst_format(
Re: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Simon Farnsworth wrote:
Hans de Goede wrote:
Ok,
That was even easier then I thought it would be. Attached is a
patch (against libv4l-0.6.1), which implements 1) and 3) from
above.
I applied it to a clone of your HG repository, and had to make a
minor change to get it to compile. I've attached the updated patch.
It looks like the read() from the card isn't reading entire frames
ata a time - I'm using a piece of test gear that I have to return in
a couple of hours to send colourbars to it, and I'm seeing bad
colour, and the picture moving across the screen. I'll try and chase
this, see whether there's something obviously wrong.
There is indeed something obviously wrong; at line 315 of libv4l2.c, we
expand the buffer we read into, then ask for that many bytes.
diff -r c51a90c0f62f v4l2-apps/libv4l/libv4l2/libv4l2.c
--- a/v4l2-apps/libv4l/libv4l2/libv4l2.cTue Sep 01 10:03:27 2009 +0200
+++ b/v4l2-apps/libv4l/libv4l2/libv4l2.cThu Sep 03 11:32:40 2009 +0100
@@ -326,7 +326,7 @@
}
do {
-result = SYS_READ(devices[index].fd, devices[index].readbuf, buf_size);
+result = SYS_READ(devices[index].fd, devices[index].readbuf,
devices[index].dest_fmt.fmt.pix.sizeimage);
if (result = 0) {
if (result errno != EAGAIN) {
int saved_err = errno;
fixes it for me.
I appear to lose colour after a few seconds of capture, which I shall chase
further.
--
Simon Farnsworth
--
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: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Simon Farnsworth wrote: I appear to lose colour after a few seconds of capture, which I shall chase further. And resolved - I was off-frequency by 2MHz, which leaves me surprised that I got picture. Only thing left for me to sort out is audio support. -- Thanks for your help, Simon Farnsworth -- 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
Audio on cx18 based cards (Hauppauge HVR1600)
Hello, I'm trying to make a Hauppauge HVR1600 (using the cx18 driver) work well with Xine; Hans de Goede has sorted out the video side of the card for me, and I now need to get the audio side cleared up. I'm used to cards like the Hauppauge HVR1110, which exports an ALSA interface for audio capture; the HVR1600 doesn't do this. Instead, it exports a video device, /dev/video24 that appears to have some variation on PCM audio on it instead of video. How should I handle this in Xine's input_v4l.c? Should the driver be changed to use ALSA? If not, how do I detect this case, and how should I configure the PCM audio device? If the driver needs modifying, I can do this, but I'll need an explanation of how to do so without breaking things for other people - I've not done much with ALSA drivers or with V4L2 drivers. -- Simon Farnsworth -- 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: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Andy Walls wrote: But I suspect no user pays for the extra cost of the CX2341[568] hardware MPEG encoder, if the user primarily wants uncompressed YUV video as their main format. Actually, we're doing exactly that. We want a PCI card from a reputable manufacturer which provides uncompressed YUV and ATSC (both OTA and ClearQAM cable). As we already buy Hauppauge HVR-1110s for DVB-T and uncompressed analogue, a Hauppauge card suits us, and the only thing they have that fits the needs is the HVR-1600; the MPEG encoder is thus left idle. -- Simon Farnsworth -- 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: libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Andy Walls wrote: On Thu, 2009-09-03 at 12:23 +0100, Simon Farnsworth wrote: Andy Walls wrote: But I suspect no user pays for the extra cost of the CX2341[568] hardware MPEG encoder, if the user primarily wants uncompressed YUV video as their main format. Actually, we're doing exactly that. We want a PCI card from a reputable manufacturer which provides uncompressed YUV and ATSC (both OTA and ClearQAM cable). As we already buy Hauppauge HVR-1110s for DVB-T and uncompressed analogue, a Hauppauge card suits us, and the only thing they have that fits the needs is the HVR-1600; the MPEG encoder is thus left idle. Ah. OK, this is more than an academic exercise. :) If you can prioritize your needs for the cx18 driver, I can see what I can get done. The video side is now working well for me on the HVR1110 and HVR1600 - in an ideal world, I'd have an ALSA driver for cx18 audio instead of the video24 device. The read() bug isn't major for me, as I can just use a slightly modified libv4l2 to cope. If you'd like to submit patches, I'll be happy to review them to make sure they don't break anything and then get them integrated. I'll be discussing this with my management next week, and they'll be making a judgement call on whether we can cope without analogue audio on the RF input only. If we can't, I'll be tasked with working on this; I take it you'd prefer to have ALSA added to the driver than for me to teach Xine to read from /dev/video24 for PCM audio? In any case, I have some more work to do on the reworked input_v4l for Xine, as I need to get it into a state where I can work with the Xine guys on merging it into their mainline. This will have to be finished before I can really dive into the cx18 driver. -- Thank you for the offer of help - I'll let you know if I'm going to start working on ALSA support in cx18, Simon Farnsworth -- 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
libv4l2 and the Hauppauge HVR1600 (cx18 driver) not working well together
Hello, I'm in the process of reworking Xine's input_v4l to use libv4l2, so that it gets the benefit of all the work done on modern cards and webcams, and I've hit a stumbling block. I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to simply not work with libv4l2, due to lack of mmap support. My code works adequately (modulo a nice pile of bugs) with a HVR1110r3, so it appears to be driver level. Which is the better route to handling this; adding code to input_v4l to use libv4lconvert when mmap isn't available, or converting the cx18 driver to use mmap? If it's a case of converting the cx18 driver, how would I go about doing that? I have no experience of the driver, so I'm not sure what I'd have to do - noting that if I break the existing read() support, other users will get upset. -- Advice appreciated, Simon Farnsworth -- 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
