Hello,
if I look at the vl4-dvb wiki, it says that diversity isn't currently supported
http://www.linuxtv.org/wiki/index.php?title=Special%3ASearch&search=diversity&go=Go
however grepping the git tree there are various mentions of diversity at least
for some dibcom based devices:
http://git.li
This option is a merge of both analog TV and DVB CUSTOMISE.
At the merge, the dependencies were not done right: the menu
currently appears only for analog TV. It should also be opened
for digital TV. As there are other I2C devices there (flash
devices, etc) that aren't related to either one, it is
Those items don't have any menu anymore; they're auto-selected by
USB/PCI/MMC drivers. So, there's no sense on keeping any help
there anymore.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/b2c2/Kconfig | 5 -
drivers/media/common/siano/Kconfig | 7 ---
2 files changed, 1
Remote controller support should be optional on all drivers.
Make it optional at Siano's driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/Kconfig| 7 +++
drivers/media/common/siano/Kconfig | 10 +-
drivers/media/common/siano/Makefile | 3 ++-
drivers/
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:Wed Oct 17 19:00:24 CEST 2012
git hash:1fdead8ad31d3aa833bc37739273fcde89ace93c
gcc version: i686-linux-gcc (GC
Remote controller support should be optional on all drivers.
Make it optional at Siano's driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/common/Kconfig| 7 +++
drivers/media/common/b2c2/Kconfig | 5 -
drivers/media/common/siano/Kconfig | 17 +
This option is a merge of both analog TV and DVB CUSTOMISE.
At the merge, the dependencies were not done right: the menu
currently appears only for analog TV. It should also be opened
for digital TV. As there are other I2C devices there (flash
devices, etc) that aren't related to either one, it is
On 09/26/12 21:42, Keith Pyle wrote:
I recently purchased a Hauppauge HD-PVR (the 1212 version, label on
bottom 49001LF, Rev F2). I have consistent capture failures on Linux
where data from the device simply stops, generally within a few
minutes of starting a capture. Yet, the device works fl
---
MDaemon has detected restricted attachments within an email message
---
>From : linux-media@vger.kernel.org
To: mydu...@asmara-vietnam.com
Subject : de
On Wed, Oct 17, 2012 at 4:43 PM, Guennadi Liakhovetski
wrote:
> On Wed, 17 Oct 2012, Guennadi Liakhovetski wrote:
>
>> Hi
>>
>> I've got a situation, for which I currently don't have a (good) solution.
>
> Ok, right, would it be acceptable to just do something like
>
> if (dev->par
On 10/17/2012 05:35 PM, Sachin Kamat wrote:
>> Most of the s5p-* drivers have already added support for clk_(un)prepare.
>> Thus most of your changes in this patch are not needed. I seem to have only
>> missed fimc-mdevice.c, other modules are already reworked
>
> I did not find these changes in y
"54fd321 [media] winbond: remove space from driver name" inadvertently
renamed the input device name.
Signed-off-by: Sean Young
---
drivers/media/rc/winbond-cir.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir
Hi Sylwester,
Thanks for the review.
On 17 October 2012 20:03, Sylwester Nawrocki wrote:
> Hi Sachin,
>
> On 10/17/2012 01:11 PM, Sachin Kamat wrote:
>> Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
>> as required by the common clock framework.
>
> You need to be
On Wed, 17 Oct 2012, Greg Kroah-Hartman wrote:
> On Wed, Oct 17, 2012 at 10:27:36AM +0200, Guennadi Liakhovetski wrote:
> > Hi
> >
> > I've got a situation, for which I currently don't have a (good) solution.
> >
> > Let's say device A depends on device B and as long as B hasn't probed, A
> > r
On Wed, Oct 17, 2012 at 10:27:36AM +0200, Guennadi Liakhovetski wrote:
> Hi
>
> I've got a situation, for which I currently don't have a (good) solution.
>
> Let's say device A depends on device B and as long as B hasn't probed, A
> requests deferred probing. Now B probes, which causes A to also
Hi Sachin,
On 10/17/2012 01:11 PM, Sachin Kamat wrote:
> Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
> as required by the common clock framework.
I think this statement is misleading. In my understanding it is not the
common clock framework requirement to use clk
The uapi changeset forgot to fix the header locations, needed
for the DocBook specs. Fix it.
Cc: David Howells
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/DocBook/media/Makefile | 76 ++--
1 file changed, 38 insertions(+), 38 deletions(-)
diff --git a
Hi all,
This is an RFC for a patch completing full video capture support on i.MX3x.
It adds missing video formats and automatic format associations according to the
underlying sensor capabilities.
It also fixes a spurious IPU interrupt issue that I have encountered on i.MX31
with earlier kernel
On Tue, Oct 16, 2012 at 4:06 PM, Jesper Juhl wrote:
> On Mon, 15 Oct 2012, Ezequiel Garcia wrote:
>
>> On Mon, Oct 15, 2012 at 9:03 PM, Jesper Juhl wrote:
>> > On Mon, 15 Oct 2012, Ezequiel Garcia wrote:
>> >
>> >> On Mon, Oct 15, 2012 at 7:52 PM, Jesper Juhl wrote:
>> >> > On Mon, 15 Oct 2012,
On Wednesday, October 17, 2012 11:14:06 AM, Christoph Fritz wrote:
> On Tue, Oct 16, 2012 at 11:04:36PM +0200, Benoît Thébaudeau wrote:
> > On Tuesday, October 16, 2012 10:04:57 PM, Laurent Pinchart wrote:
> > > > Is there a current (kernel ~3.6) git tree which shows how to
> > > > add
> > > > mt9p
Fixes the following sparse warning:
drivers/media/platform/s5p-fimc/fimc-mdevice.c:216:5: warning:
symbol 'fimc_pipeline_s_stream' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-fimc/fimc-mdevice.c |2 +-
1 files changed, 1 insertions(+), 1
Fixes the following sparse warning:
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c:31:10: warning:
symbol 'clk_ref' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
Cc: Kamil Debski
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |2 +-
1 files changed, 1 insertions(+), 1 del
Used type casting to avoid the following compilation warning:
drivers/media/platform/exynos-gsc/gsc-core.c:983:37: warning:
incorrect type in assignment (different modifiers)
drivers/media/platform/exynos-gsc/gsc-core.c:983:37:
expected struct gsc_driverdata *driver_data
drivers/media/platform/exy
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/exynos-gsc/gsc-core.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
Signed-off-by: Sachin Kamat
Cc: Tomasz Stanislawski
---
drivers/media/platform/s5p-tv/hdmi_drv.c | 20 ++--
drivers/media/platform/s5p-tv/mixer_drv.c | 12
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
Signed-off-by: Sachin Kamat
Cc: Kamil Debski
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/driver
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
Signed-off-by: Sachin Kamat
Cc: Kamil Debski
---
drivers/media/platform/s5p-g2d/g2d.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media
Replace clk_enable/clk_disable with clk_prepare_enable/clk_disable_unprepare
as required by the common clock framework.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-fimc/fimc-core.c| 10 +-
drivers/media/platform/s5p-fimc/fimc-lite.c|4 ++--
drivers/media/plat
> From the fact this patch keeps getting resubmitted despite repeated
> objection I deduce they are in fact of the view it does matter and that
> therefore it is a licensing change and they are scared of the
> consequences of ignoring it.
>
No I think they just want to have to write a pointless ha
On 10/17/2012 01:09 PM, Oliver Schinagl wrote:
On 17-10-12 12:01, Antti Palosaari wrote:
Hello Oliver
On 10/17/2012 12:20 PM, Oliver Schinagl wrote:
Hey antti, list,
whilst trying to help some Asus U3100+ users with the recent patches I
ran into an issue. For some strange reason his chip_id w
On Wed, 17 Oct 2012 20:22:04 +1000
Dave Airlie wrote:
> On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote:
> >> > Please go and discuss estoppel, wilful infringement and re-licensing with
> >> > your corporate attorneys. If you want to relicense components of the code
> >> > then please take the m
On 17-10-12 12:01, Antti Palosaari wrote:
Hello Oliver
On 10/17/2012 12:20 PM, Oliver Schinagl wrote:
Hey antti, list,
whilst trying to help some Asus U3100+ users with the recent patches I
ran into an issue. For some strange reason his chip_id was 0xff. I'd
hope this is somehow supplied by th
On Wed, Oct 17, 2012 at 8:25 PM, Alan Cox wrote:
>> > Please go and discuss estoppel, wilful infringement and re-licensing with
>> > your corporate attorneys. If you want to relicense components of the code
>> > then please take the matter up with the corporate attorneys of the rights
>> > holders
> > Please go and discuss estoppel, wilful infringement and re-licensing with
> > your corporate attorneys. If you want to relicense components of the code
> > then please take the matter up with the corporate attorneys of the rights
> > holders concerned.
>
> Alan please stick with the facts. Thi
b>>
>> Alan please stick with the facts. This isn't a relicense of anything.
>> EXPORT_SYMBOL_GPL isn't a license its nothing like a license. Its a
>> totally pointless thing, it should be
>> EXPORT_SYMBOL_USERS_MIGHT_BE_DERIVED_CONSULT_YOUR_LAWYER, but it
>> really should be EXPORT_SYMBOL, and rea
>> Please go and discuss estoppel, wilful infringement and re-licensing with
>> your corporate attorneys. If you want to relicense components of the code
>> then please take the matter up with the corporate attorneys of the rights
>> holders concerned.
>
> Alan please stick with the facts. This isn
Hello Oliver
On 10/17/2012 12:20 PM, Oliver Schinagl wrote:
Hey antti, list,
whilst trying to help some Asus U3100+ users with the recent patches I
ran into an issue. For some strange reason his chip_id was 0xff. I'd
hope this is somehow supplied by the firmware. I think I had the exact
same is
On Wed, Oct 17, 2012 at 7:53 PM, Alan Cox wrote:
>> I believe that the developers and maintainers of dma-buf have provided
>> the needed signoff, both in person and in this thread. If there are any
>> objections from that group, I'm happy to discuss any changes necessary to get
>> this merged.
>
> I believe that the developers and maintainers of dma-buf have provided
> the needed signoff, both in person and in this thread. If there are any
> objections from that group, I'm happy to discuss any changes necessary to get
> this merged.
You need the permission of the owners of all the depend
Hi Laurent,
2012/10/17 Laurent Pinchart :
> Hi Enric,
>
> On Monday 15 October 2012 14:03:20 Enric Balletbo Serra wrote:
>> 2012/10/11 Laurent Pinchart :
>> > On Thursday 11 October 2012 10:14:26 Enric Balletbò i Serra wrote:
>> >> 2012/10/10 Enric Balletbò i Serra :
>> >> > 2012/9/6 John Weber :
Hey antti, list,
whilst trying to help some Asus U3100+ users with the recent patches I
ran into an issue. For some strange reason his chip_id was 0xff. I'd
hope this is somehow supplied by the firmware. I think I had the exact
same issue until I used Antti's latest firmware for the AF9035.
From: Hans Verkuil
The STDI block may measure wrong values, especially for lcvs and lcf. If the
driver can not find any valid timing, the STDI block is restarted to measure
the video timings again. The function will return an error, but the restart of
STDI will generate a new STDI interrupt and t
From: Hans Verkuil
Changes the way the primary mode is handled:
- Remove it from platform_data since it doesn't belong there.
- Add a new mode enum for use with s_routing.
- Collapse the two HDMI modes into one HDMI mode: when setting up the
timings manually we do not need to select HDMI_COMP
From: Hans Verkuil
Use predefined video timings (prim_mode/vid_std) when available as recommended
by Analog Devices (http://ez.analog.com/message/48267#48267).
Also remove 720p30 support since the ADV7604 can't handle that.
(http://ez.analog.com/message/61488#61488)
Signed-off-by: Mats Randgaar
This patch series syncs up the adv7604 driver in 3.7-rc1 with the latest
version that's in the Cisco internal tree.
Nothing major, just a small cleanup and three bug fixes.
There were no changes for the ad9389b that was also merged for 3.7-rc1.
If there are no comments, then I'll make a pull req
From: Hans Verkuil
Signed-off-by: Mats Randgaard
Signed-off-by: Hans Verkuil
---
drivers/media/i2c/adv7604.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 109bc9b..75a8395 100644
--- a/drivers/media/
On Tue, Oct 16, 2012 at 11:04:36PM +0200, Benoît Thébaudeau wrote:
> On Tuesday, October 16, 2012 10:04:57 PM, Laurent Pinchart wrote:
> > > Is there a current (kernel ~3.6) git tree which shows how to add
> > > mt9p031
> > > to platform code?
> >
> > Yes, at
> > http://git.linuxtv.org/pinchartl/m
On Wed, 17 Oct 2012, Guennadi Liakhovetski wrote:
> Hi
>
> I've got a situation, for which I currently don't have a (good) solution.
Ok, right, would it be acceptable to just do something like
if (dev->parent)
device_lock(dev->parent);
dev
Hi
I've got a situation, for which I currently don't have a (good) solution.
Let's say device A depends on device B and as long as B hasn't probed, A
requests deferred probing. Now B probes, which causes A to also succeed
its probing. Next we want to remove B, say, by unloading its driver. A ha
49 matches
Mail list logo
