Payment
Dear Winner, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146. This compensation funds from the United Nation.Send us your personal details to deliver your funds. Gloria Peter -- 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] radio-bcm2048: Fix region selection
Removed Japan wide band region since this is impossible to do just
like that. Additionally it's now possible to go back to non-Japanese regions
without having to reload the module.
Greetings
Jan Roemisch
On Sat, May 16, 2015 at 07:06:17AM -0700, Greg KH wrote:
On Sat, May 16, 2015 at 01:22:27PM +0200, Jan Roemisch wrote:
Oh sorry, the real name is Jan Roemisch.
Ok, thanks, can someone please fix up the patches and resend them?
greg k-h
diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 5382506..d2e7f1e 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -342,14 +342,6 @@ static struct region_info region_configs[] = {
.deemphasis = 50,
.region = 3,
},
- /* Japan wide band */
- {
- .channel_spacing= 10,
- .bottom_frequency = 76000,
- .top_frequency = 108000,
- .deemphasis = 50,
- .region = 4,
- },
};
/*
@@ -741,6 +733,18 @@ static int bcm2048_set_region(struct bcm2048_device *bdev,
u8 region)
mutex_lock(bdev-mutex);
bdev-region_info = region_configs[region];
+
+ if (region_configs[region].bottom_frequency 87500)
+ bdev-cache_fm_ctrl |= BCM2048_BAND_SELECT;
+ else
+ bdev-cache_fm_ctrl = ~BCM2048_BAND_SELECT;
+
+ err = bcm2048_send_command(bdev, BCM2048_I2C_FM_CTRL,
+ bdev-cache_fm_ctrl);
+ if (err) {
+ mutex_unlock(bdev-mutex);
+ goto done;
+ }
mutex_unlock(bdev-mutex);
if (bdev-frequency region_configs[region].bottom_frequency ||
Payment
Dear Winner, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146. This compensation funds from the United Nation.Send us your personal details to deliver your funds. Gloria Peter -- 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] radio-bcm2048: Fix region selection
On Sat, May 16, 2015 at 01:22:27PM +0200, Jan Roemisch wrote: Oh sorry, the real name is Jan Roemisch. Ok, thanks, can someone please fix up the patches and resend them? greg k-h -- 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: rtl28xx Leadtek
On 16/05/15 13:23, Vincent McIntyre wrote: Hi, I have been trying to get support going for a Leadtek WinFast DTV2000DS Plus (usbid 0413:6f12) In case it matters here, I have these cards and am using the driver built from git clone git://linuxtv.org/media_build.git git clone g...@github.com:jaredquinn/DVB-Realtek-RTL2832U.git I get rather reliable tuning with hardly any of the old problems of zero length recordings of fails to tune some channels. I run old fedora 19 though, and things may have deteriorated since? Last time I needed to build was Jan 31 for kernel 3.14.27-100.fc19.x86_64. Is this driver included with the kernel these days? cheers Eyal Christian Dale (cc:d) posted a patch a while ago and since that time there have been a few patches from Olle and others that have significantly improved things. However I am still having issues with the card; sometimes it does not scan any of the multiplexes I look at with it, sometimes it does some of them and sometimes it pulls out some program ids on one mulitplex but not the others in the scan. The behaviour is different between the two tuners on the card as well. I've written a test script that turns on various kernel dynamic debug entries and tries to scan, using the old dvb-apps 'scan' (1.1.1+rev1500) and the latest dvbv5-scan from git. Would anyone on the list interested in helping please take a look at the attached logs of the run I did? It includes the script output and what was happening in syslog at each step. There should be no signal issues, as the same test script on the same system with the same coax input works perfectly when I swap the Leadtek for a DVICO card using the cx23885 driver. Both drivers are built from the media_build git. My questions: - are there debug items that could be turned on or off to help diagnose the issues? - are there some perf traces that could be run that would be helpful? Kind regards Vince -- Eyal Lebedinsky (e...@eyal.emu.id.au) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: change clk_ops' -round_rate() prototype
On 05/15/2015 06:40 PM, Boris Brezillon wrote:
Hi Stephen,
Adding Mikko in the loop (after all, he was the one complaining about
this signed long limitation in the first place, and I forgot to add
him in the Cc list :-/).
I think I got it through linux-tegra anyway, but thanks :)
Mikko, are you okay with the approach proposed by Stephen (adding a
new method) ?
Yes, sounds good to me. If a driver uses the existing methods with too
large frequencies, the issue is pretty discoverable anyway. I think
adjust_rate sounds a bit too much like it sets the clock's rate,
though; perhaps adjust_rate_request or something like that?
Thanks,
Mikko
On Thu, 7 May 2015 09:37:02 +0200
Boris Brezillon boris.brezil...@free-electrons.com wrote:
Hi Stephen,
On Wed, 6 May 2015 23:39:53 -0700
Stephen Boyd sb...@codeaurora.org wrote:
On 04/30, Boris Brezillon wrote:
Clock rates are stored in an unsigned long field, but -round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -round_rate() prototype to return 0 or an error code, and pass the
requested rate as a pointer so that it can be adjusted depending on
hardware capabilities.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Tested-by: Heiko Stuebner he...@sntech.de
Tested-by: Mikko Perttunen mikko.perttu...@kapsi.fi
Reviewed-by: Heiko Stuebner he...@sntech.de
This patch is fairly invasive, and it probably doesn't even
matter for most of these clock providers to be able to round a
rate above 2GHz.
Fair enough.
I've been trying to remove the .round_rate op
from the framework by encouraging new features via the
.determine_rate op.
Oh, I wasn't aware of that (BTW, that's a good thing).
Maybe this should be clearly stated (both in the struct clk_ops
kerneldoc header and in Documentation/clk.txt).
Sadly, we still have to do a flag day and
change all the .determine_rate ops when we want to add things.
Yes, but the number of clk drivers implementing -determine_rate() is
still quite limited compared to those implementing -round_rate().
What if we changed determine_rate ops to take a struct
clk_determine_info (or some better named structure) instead of
the current list of arguments that it currently takes? Then when
we want to make these sorts of framework wide changes we can just
throw a new member into that structure and be done.
I really like this idea, especially since I was wondering if we could
pass other 'clk rate requirements' like the rounding policy (down,
closest, up), or the maximum clk inaccuracy.
It doesn't solve the unsigned long to int return value problem
though. We can solve that by gradually introducing a new op and
handling another case in the rounding path. If we can come up
with some good name for that new op like .decide_rate or
something then it makes things nicer in the long run. I like the
name .determine_rate though :/
Okay, if you want a new method, how about this one:
struct clk_adjust_rate_req {
/* fields filled by the caller */
unsigned long rate; /* rate is updated by the clk driver */
unsigned long min;
unsigned long max;
/* fields filled by the clk driver */
struct clk_hw *best_parent;
unsigned long best_parent_rate;
/*
* new fields I'd like to add at some point:
* unsigned long max_inaccuracy;
* something about the power consumption constraints :-)
*/
};
int (*adjust_rate)(struct clk_hw *hw, struct clk_adjust_rate_req *req);
Why not changing the -determine_rate() prototype. As said above, the
number of clk drivers implementing this function is still quite
limited, and I guess we can have an ack for all of them.
The benefit of all this is that we don't have to worry about
finding the random clk providers that get added into other
subsystems and fixing them up. If drivers actually care about
this problem then they'll be fixed to use the proper op. FYI,
last time we updated the function signature of .determine_rate we
broke a couple drivers along the way.
Hm, IMHO, adding a new op is not a good thing. I agree that it eases
the transition, but ITOH you'll have to live with old/deprecated ops in
your clk_ops structure with people introducing new drivers still using
the old ops (see the number of clk drivers implementing -round_rate()
instead of -determine_rate()).
Best Regards,
Boris
--
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] radio-bcm2048: Fix region selection
Oh sorry, the real name is Jan Roemisch. Greetings Jan -- 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: fix vidioc-qbuf.xml doc validation
element varlistentry: validity error : Element varlistentry content does not follow the DTD, expecting (term+ , listitem), got (term listitem term listitem ) commit 8cee396bfa77ce3a2e5fe48f597206c1cd547f9c [media] DocBook media: document codec draining flow breaks document validation. Fix it. Cc: Philipp Zabel p.za...@pengutronix.de Cc: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Antti Palosaari cr...@iki.fi --- Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 6cfc53b..f5cef97 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -186,6 +186,8 @@ In that case the application should be able to safely reuse the buffer and continue streaming. /para /listitem + /varlistentry + varlistentry termerrorcodeEPIPE/errorcode/term listitem paraconstantVIDIOC_DQBUF/constant returns this on an empty -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun May 17 04:00:15 CEST 2015 git branch: test git hash: 0fae1997f09796aca8ada5edc028aef587f6716c gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-1.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: 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: OK linux-3.3.8-i686: OK 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-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: 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: OK linux-3.3.8-x86_64: OK 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-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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: dvb_usb_af9015: command failed=1 _ kernel = 4.1.x
On 05/13/2015 06:56 AM, poma wrote: On 12.05.2015 16:11, Antti Palosaari wrote: On 05/11/2015 09:43 PM, poma wrote: On 05/11/2015 12:25 AM, poma wrote: On 10.05.2015 12:38, poma wrote: On 08.05.2015 12:59, poma wrote: Is a beer keg enough as bribe? :) Just do not say that you drink juice. After the reverting of all changes http://git.linuxtv.org/cgit.cgi/media_tree.git/log/drivers/media/tuners/mxl5007t.c device now survives both, 'lsdvb' and rc kernels. Besides, despite all this, this device is already not working at its full potential. One of the tuners can withstand a few hours and then hangs. After that, in the application e.g. vlc is needed to select the second tuner and so continue to use the device. So this is actually a single-seater as Formula 1. Vroom vroom! try that http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/commit/?h=af9015_mxl5007t_1 Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
