Re: Kudos for the new vtl2 ctrls framework
On Sunday, July 03, 2011 22:04:45 Hans de Goede wrote: > Hi all, > > After making some serious use of it in the pwc driver cleanup > I would like to thank Hans V. for all his hard work on the > new ctrl framework. > > The clusters bit got a bit getting used to / but once I did > it is great. > > Once you get it, it really makes sense to group certain ctrls > into clusters which then get set in a single call to the driver, > allowing more or less atomic handling of things like autofoo + > foo changing. And in the pwc case also grouping the pan and > tilt controls, which get set with a single usb command, > so that with s_ex_ctrls an app can in theory do diagonal > moving of the camera rather then stair case moving. > > Thanks Hans V.! My pleasure! I'll review the pwc patches this week. The pwc driver is used for some astronomy work including things like long exposure settings. So I'll make sure that that part is still working (or better, is working again since it broken after the V4L1 removal). Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New ctrl framework also enumerates classes
On Monday, July 04, 2011 08:23:10 Hans de Goede wrote: > Hi All, > > One last thing before I really leave on vacation which just popped > in my mind as something which I had not mentioned yet. > > The new ctrl framework also enumerates classes when enumerating > ctrls with the next flag. I wonder if this is intentional? It's absolutely intentional. It's needed to produce the headers of the tabs in e.g. qv4l2. It's been part of the spec for several years now. > IOW if this is a feature or a bug? > > Either way this confuses various userspace apps, gtk-v4l prints > warnings about an unknown control type, It should just skip such types. > and v4l2ucp gets a very > messed up UI because of this change. Thus unless there are > really strong reasons to do this, I suggest we skip classes > when enumerating controls. Those apps should be fixed. If apps see an unknown type, then they should always just skip such controls (and later add support for it, of course). Another control type (bitmask) will be merged soon as well, so the same problem will occur with that, but this is all really an application bug. Apps should be tested with vivi: that driver has all control types that we have, so that's a good driver to test with. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
New ctrl framework also enumerates classes
Hi All, One last thing before I really leave on vacation which just popped in my mind as something which I had not mentioned yet. The new ctrl framework also enumerates classes when enumerating ctrls with the next flag. I wonder if this is intentional? IOW if this is a feature or a bug? Either way this confuses various userspace apps, gtk-v4l prints warnings about an unknown control type, and v4l2ucp gets a very messed up UI because of this change. Thus unless there are really strong reasons to do this, I suggest we skip classes when enumerating controls. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [ RFC PATCH 0/8] RFC for Media Controller capture driver for DM365
Sakari, Thank you for the comments. My responses inlined. -Manjunath On Thu, Jun 30, 2011 at 19:27:36, Sakari Ailus wrote: > Hi Manjunath, > > Thanks for the patches. > > On Thu, Jun 30, 2011 at 06:43:09PM +0530, Manjunath Hadli wrote: > > Thease are the RFC patches for the DM365 video capture, of which the > > current set includes only CCDC and the VPFE framework. Once the > > present set is reviewed, I will send out the other parts like H3A, > > sensor additions etc. > > > > Introduction > > > > This is the proposal of the initial version of design and > > implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video > > Port Front End) drivers using Media Controloler , the initial version > > which supports the following: > > 1) dm365 vpfe > > 2) ccdc,previewer,resizer,h3a,af blocks > > 3) supports both continuous and single-shot modes > > 4) supports user pointer exchange and memory mapped modes for buffer > > allocation > > > > This driver bases its design on Laurent Pinchart's Media Controller > > Design whose patches for Media Controller and subdev enhancements form the > > base. > > The driver also takes copious elements taken from Laurent Pinchart and > > others' OMAP ISP driver based on Media Controller. So thank you all > > the people who are responsible for the Media Controller and the OMAP ISP > > driver. > > This may be a stupid question, but how much changes are there between this > driver and the OMAP 3 ISP driver? The elements which pertain to how to write to media controller driver for a capture device have been imbibed from the OMAP3 but as such the code is very different. For example the v4l2 video routines as an almost separate library is a good element we took as a design, but the rest of it is entirely different. > > I understand that not all the blocks are there. Are there any major > functional differences between those in Davinci and those in OMAP 3? Could > the OMAP 3 ISP driver made support Davinci ISP as well? Yes, there are a lot of major differences between OMAP3 and Dm365/Dm355, both in terms of features, there IP, and the software interface, including all the registers which are entirely different. The closest omap3 would come to is only to DM6446. I do not think OMAP3 driver can be made to support Dm355 and Dm365. It is good to keep the OMAP3 neat and clean to cater for OMAP4 and beyond, and keep the Davinci family separate. The names might look similar and hence confusing for you, but the names can as well be made the same as Dm365 blocks like ISIF and IPIPE and IPIPEIF which are different. > > There are number of possible improvements that still should be made to the > OMAP 3 ISP driver so this way both of the driver would easily get them. To > mention some: > > - Multiple output pipeline > - Switch to videobuf2 > - Switch to GENIRQ Sure. There is definitely a design element convergence, and overtime I think some of these would get into the core v4l2 infrastructure. > > Cc Laurent. > > Regards, > > -- > Sakari Ailus > sakari.ai...@iki.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
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
Hi, On Thu, Jun 16, 2011 at 12:06:07AM +0200, Arnd Bergmann wrote: > On Wednesday 15 June 2011 23:39:58 Larry Bassel wrote: > > On 15 Jun 11 10:36, Marek Szyprowski wrote: > > > On Tuesday, June 14, 2011 10:42 PM Arnd Bergmann wrote: > > > > > > > On Tuesday 14 June 2011 20:58:25 Zach Pfeffer wrote: > > > > > I've seen this split bank allocation in Qualcomm and TI SoCs, with > > > > > Samsung, that makes 3 major SoC vendors (I would be surprised if > > > > > Nvidia didn't also need to do this) - so I think some configurable > > > > > method to control allocations is necessarily. The chips can't do > > > > > decode without it (and by can't do I mean 1080P and higher decode is > > > > > not functionally useful). Far from special, this would appear to be > > > > > the default. > > > > We at Qualcomm have some platforms that have memory of different > > performance characteristics, some drivers will need a way of > > specifying that they need fast memory for an allocation (and would prefer > > an error if it is not available rather than a fallback to slower > > memory). It would also be bad if allocators who don't need fast > > memory got it "accidentally", depriving those who really need it. > > Can you describe how the memory areas differ specifically? > Is there one that is always faster but very small, or are there > just specific circumstances under which some memory is faster than > another? > > > > > The possible conflict that I still see with per-bank CMA regions are: > > > > > > > > * It completely destroys memory power management in cases where that > > > > is based on powering down entire memory banks. > > > > We already established that we have to know something about the banks, > and your additional input makes it even clearer that we need to consider > the bigger picture here: We need to describe parts of memory separately > regarding general performance, device specific allocations and hotplug > characteristics. > > It still sounds to me that this can be done using the NUMA properties > that Linux already understands, and teaching more subsystems about it, > but maybe the memory hotplug developers have already come up with > another scheme. The way that memory hotplug and CMA choose their > memory regions certainly needs to take both into account. As far as > I can see there are both conflicting and synergistic effects when > you combine the two. > Recently, we proposed a generic 'memory regions' framework to exploit the memory power management capabilities on the embedded boards. Think of some of the above CMA requirements could be met by this fraemwork. One of the main goals of regions is to make the VM aware of the hardware memory boundaries, like bank. For managing memory power consumption, memory regions are created aligned to the hardware granularity at which the power can be managed (ie, the memory power consumption operations like on/off can be performed). If attributed are associated with each of these regions, some of these regions could be marked as CMA-only, ensuring that only movable and per-bank memory is allocated. More details on the design can be found here: http://lkml.org/lkml/2011/5/27/177 http://lkml.org/lkml/2011/6/29/202 http://lwn.net/Articles/446493/ -- Regards, Ankita Garg (ank...@in.ibm.com) Linux Technology Center IBM India Systems & Technology Labs, Bangalore, India -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
> -Original Message- > From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] > Sent: Saturday, July 02, 2011 12:19 AM > To: Hiremath, Vaibhav > Cc: linux-media@vger.kernel.org > Subject: Re: [GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup > > Em 22-06-2011 16:32, hvaib...@ti.com escreveu: > > The following changes since commit > af0d6a0a3a30946f7df69c764791f1b0643f7cd6: > > Linus Torvalds (1): > > Merge branch 'x86-urgent-for-linus' of > git://git.kernel.org/.../tip/linux-2.6-tip > > > > are available in the git repository at: > > > > git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for- > linux-media > > > > > Archit Taneja (3): > > OMAP_VOUT: CLEANUP: Move generic functions and macros to common > files > > OMAP_VOUT: CLEANUP: Make rotation related helper functions more > descriptive > > OMAP_VOUT: Create separate file for VRFB related API's > > Those are cleanup patches. NACK for 3.0. Cleanups should be sent to -next > kernel (3.1). > [Hiremath, Vaibhav] Ok, will queue it for 3.1. > > Vaibhav Hiremath (2): > > OMAP_VOUT: Change hardcoded device node number to -1 > > omap_vout: Added check in reqbuf & mmap for buf_size allocation > > > > Vladimir Pantelic (1): > > OMAP_VOUTLIB: Fix wrong resizer calculation > > The 3 above patches are ok for 3.0. Added. > [Hiremath, Vaibhav] Thanks, Thanks, Vaibhav > Thanks, > Mauro. -- 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] media: initial driver for ov5642 CMOS sensor
>
> Hi, Bastian,
>
> Could the setting in ov5642.c like ov5642_default_regs_init and
> ov5642_default_regs_finalise adapt to different board? From my experience,
> ov5642 may have difference settings for differnt boards. So could we put the
> setting in another file instead of in the common driver?
>
> Best Regards,
> Angela Wan
>
> Application Processor Systems Engineering,
> Marvell Technology Group Ltd.
>
>
> On Tue, Jun 28, 2011 at 5:48 AM, Bastian Hecht wrote:
>>
>> 2011/6/27 Laurent Pinchart :
>> > Hi Bastian,
>> >
>> > Thanks for the patch.
>> >
>> > On Friday 24 June 2011 12:57:36 Bastian Hecht wrote:
>> >> This is an initial driver release for the Omnivision 5642 CMOS sensor.
>> >>
>> >> Signed-off-by: Bastian Hecht
>> >> ---
>> >>
>> >> diff --git a/drivers/media/video/ov5642.c b/drivers/media/video/ov5642.c
>> >> new file mode 100644
>> >> index 000..3cdae97
>> >> --- /dev/null
>> >> +++ b/drivers/media/video/ov5642.c
>> >> @@ -0,0 +1,1011 @@
>> >> +/*
>> >> + * Driver for OV5642 CMOS Image Sensor from Omnivision
>> >> + *
>> >> + * Copyright (C) 2011, Bastian Hecht
>> >> + *
>> >> + * Based on Sony IMX074 Camera Driver
>> >> + * Copyright (C) 2010, Guennadi Liakhovetski
>> >> + *
>> >> + * Based on Omnivision OV7670 Camera Driver
>> >> + * Copyright (C) 2006-7 Jonathan Corbet
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or modify
>> >> + * it under the terms of the GNU General Public License version 2 as
>> >> + * published by the Free Software Foundation.
>> >> + */
>> >> +
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +/* OV5642 registers */
>> >> +#define REG_CHIP_ID_HIGH 0x300a
>> >> +#define REG_CHIP_ID_LOW 0x300b
>> >> +
>> >> +#define REG_WINDOW_START_X_HIGH 0x3800
>> >> +#define REG_WINDOW_START_X_LOW 0x3801
>> >> +#define REG_WINDOW_START_Y_HIGH 0x3802
>> >> +#define REG_WINDOW_START_Y_LOW 0x3803
>> >> +#define REG_WINDOW_WIDTH_HIGH 0x3804
>> >> +#define REG_WINDOW_WIDTH_LOW 0x3805
>> >> +#define REG_WINDOW_HEIGHT_HIGH 0x3806
>> >> +#define REG_WINDOW_HEIGHT_LOW 0x3807
>> >> +#define REG_OUT_WIDTH_HIGH 0x3808
>> >> +#define REG_OUT_WIDTH_LOW 0x3809
>> >> +#define REG_OUT_HEIGHT_HIGH 0x380a
>> >> +#define REG_OUT_HEIGHT_LOW 0x380b
>> >> +#define REG_OUT_TOTAL_WIDTH_HIGH 0x380c
>> >> +#define REG_OUT_TOTAL_WIDTH_LOW 0x380d
>> >> +#define REG_OUT_TOTAL_HEIGHT_HIGH 0x380e
>> >> +#define REG_OUT_TOTAL_HEIGHT_LOW 0x380f
>> >> +
>> >> +/*
>> >> + * define standard resolution.
>> >> + * Works currently only for up to 720 lines
>> >> + * eg. 320x240, 640x480, 800x600, 1280x720, 2048x720
>> >> + */
>> >> +
>> >> +#define OV5642_WIDTH 1280
>> >> +#define OV5642_HEIGHT 720
>> >> +#define OV5642_TOTAL_WIDTH 3200
>> >> +#define OV5642_TOTAL_HEIGHT 2000
>> >> +#define OV5642_SENSOR_SIZE_X 2592
>> >> +#define OV5642_SENSOR_SIZE_Y 1944
>> >> +
>> >> +struct regval_list {
>> >> + u16 reg_num;
>> >> + u8 value;
>> >> +};
>> >> +
>> >> +static struct regval_list ov5642_default_regs_init[] = {
>> >> + { 0x3103, 0x93 },
>> >> + { 0x3008, 0x82 },
>> >> + { 0x3017, 0x7f },
>> >> + { 0x3018, 0xfc },
>> >> + { 0x3810, 0xc2 },
>> >> + { 0x3615, 0xf0 },
>> >> + { 0x3000, 0x0 },
>> >> + { 0x3001, 0x0 },
>> >> + { 0x3002, 0x0 },
>> >> + { 0x3003, 0x0 },
>> >> + { 0x3004, 0xff },
>> >> + { 0x3030, 0x2b },
>> >> + { 0x3011, 0x8 },
>> >> + { 0x3010, 0x10 },
>> >> + { 0x3604, 0x60 },
>> >> + { 0x3622, 0x60 },
>> >> + { 0x3621, 0x9 },
>> >> + { 0x3709, 0x0 },
>> >> + { 0x4000, 0x21 },
>> >> + { 0x401d, 0x22 },
>> >> + { 0x3600, 0x54 },
>> >> + { 0x3605, 0x4 },
>> >> + { 0x3606, 0x3f },
>> >> + { 0x3c01, 0x80 },
>> >> + { 0x300d, 0x22 },
>> >> + { 0x3623, 0x22 },
>> >> + { 0x5000, 0x4f },
>> >> + { 0x5020, 0x4 },
>> >> + { 0x5181, 0x79 },
>> >> + { 0x5182, 0x0 },
>> >> + { 0x5185, 0x22 },
>> >> + { 0x5197, 0x1 },
>> >> + { 0x5500, 0xa },
>> >> + { 0x5504, 0x0 },
>> >> + { 0x5505, 0x7f },
>> >> + { 0x5080, 0x8 },
>> >> + { 0x300e, 0x18 },
>> >> + { 0x4610, 0x0 },
>> >> + { 0x471d, 0x5 },
>> >> + { 0x4708, 0x6 },
>> >> + { 0x370c, 0xa0 },
>> >> + { 0x5687, 0x94 },
>> >> + { 0x501f, 0x0 },
>> >> + { 0x5000, 0x4f },
>> >> + { 0x5001, 0xcf },
>> >> + { 0x4300, 0x30 },
>> >> + { 0x4300, 0x30 },
>> >> + { 0x460b, 0x35 },
>> >> + { 0x471d, 0x0 },
>> >> + { 0x3002, 0xc },
>> >> + { 0x3002, 0x0 },
>> >> + { 0x4713, 0x3 },
>> >> + { 0x471c, 0x50 },
>> >> + { 0x4721, 0x2 },
>> >> + { 0x4402, 0x90 },
>> >
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Em 03-07-2011 20:24, Oliver Endriss escreveu:
> Hi Mauro,
>
> On Monday 04 July 2011 00:27:54 Mauro Carvalho Chehab wrote:
>> Hi Oliver,
>>
>> Em 03-07-2011 18:21, Oliver Endriss escreveu:
>>> [PATCH 1/5] ddbridge: Initial check-in
>>> [PATCH 2/5] ddbridge: Codingstyle fixes
>>> [PATCH 3/5] ddbridge: Allow compiling of the driver
>>> [PATCH 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n
>>> [PATCH 5/5] cxd2099: Update Kconfig descrition (ddbridge support)
>>>
>>> Note:
>>> This patch series depends on the previous one:
>>> [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
>>
>> I've applied both series today on an experimental tree that I use when
>> merging
>> some complex drivers. They are at:
>>
>> http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/ngene
>>
>> I didn't actually reviewed the patch series yet, but I noticed some troubles
>> related to Coding Style, and 2 compilation breakages, when all drivers are
>> selected,
>> due to some duplicated symbols. So, I've applied some patches fixing the
>> issues
>> I noticed. It would be great if you could test if the changes didn't break
>> anything.
>
> Apparently these duplicated symbols did not show up here,
> because I compiled the drivers as modules. :-(
Likely. When merging things, I compile here with allyesconfig, in order to
catch duplicated
symbols.
>> There's a problem that I've noticed already at the patch series: the usage of
>> CHK_ERROR macro hided a trouble on some places, especially at drxd_hard.c.
>>
>> As you know, the macro was defined as:
>> #define CHK_ERROR(s) if ((status = s)) break
>>
>> I've replaced it, on all places, using a small perl script, as the above is
>> a CodingStyle
>> violation, and may hide some troubles[1].
>
> True.
>
>> [1]
>> http://git.linuxtv.org/mchehab/experimental.git?a=commit;h=792ecdd1cc494a1e10ed494052ed697ab4e1aa8a
>>
>> After the removal, I've noticed that this works fine on several places
>> where the code have things like:
>> do {
>> status = foo()
>> if (status < 0)
>> break;
>>
>> } while (0);
>>
>> There are places, however, that there are two loops, like, for example, at:
>>
>> static int DRX_Start(struct drxd_state *state, s32 off)
>> {
>> ...
>> do {
>> ...
>> switch (p->transmission_mode) {
>> case TRANSMISSION_MODE_8K:
>> transmissionParams |= SC_RA_RAM_OP_PARAM_MODE_8K;
>> if (state->type_A) {
>> status = Write16(state, EC_SB_REG_TR_MODE__A,
>> EC_SB_REG_TR_MODE_8K, 0x);
>> if (status < 0)
>> break;
>> }
>> break;
>> ...
>> }
>>
>> ...
>> } while (0);
>>
>> return status;
>>
>> On those cases, instead of returning the error status, the function
>> will just ignore the error and proceed to the next switch(). In this
>> specific
>> routine, as there are no locks inside the code, the better fix would be to
>> just replace:
>> if (status < 0)
>> break;
>> by
>> if (status < 0)
>> return (status);
>>
>> But I suspect that the same trouble is also present on other parts of the
>> code.
>>
>> Another issue that I've noticed alread is that, on some places, instead of
>> doing
>> "return -EINVAL" (or some other proper error code), the code is just doing:
>> "return -1".
>>
>> Could you please take a look on those issues?
>
> That CHK_ERROR stuff appears very dangerous to me.
> Btw, this is why I did not remove the curly braces { } in some cases:
> if (...) {
> CHK_ERROR(...)
> }
> It would have caused really nasty effects.
True.
> Anyway, I spent the whole weekend to re-format the code carefully
> and create both patch series, trying not to break anything.
> I simply cannot go through the driver code and verify everything.
As the changes on CHK_ERROR were done via script, it is unlikely that it
introduced any problems (well, except if some function is returning
a positive value as an error code, but I think that this is not the
case).
I did the same replacement when I've cleanup the drx-d driver (well, the
script were not the same, but it used a similar approach), and the changes
didn't break anything, but it is safer to have a test, to be sure that no
functional changes were introduced.
A simple test with the code and some working board is probably enough
to verify that nothing broke.
The bad error check logic, checking for "break" inside two loops instead just
one will require a careful code inspection, though.
> Please note that I am not the driver author!
> I think Ralph should comment on this.
Ralph,
Could you please take a look on it?
Thanks!
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body
Re: [PATCH 5/5] cxd2099: Update Kconfig description (ddbridge support)
Oliver Endriss schreef op Sun 03-07-2011 om 23:27 [+0200]: > Update Kconfig description (ddbridge with cxd2099) > > Signed-off-by: Oliver Endriss > --- > drivers/staging/cxd2099/Kconfig | 11 ++- > 1 files changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/staging/cxd2099/Kconfig b/drivers/staging/cxd2099/Kconfig > index 9d638c3..b48aefd 100644 > --- a/drivers/staging/cxd2099/Kconfig > +++ b/drivers/staging/cxd2099/Kconfig > @@ -1,9 +1,10 @@ > config DVB_CXD2099 > -tristate "CXD2099AR Common Interface driver" > -depends on DVB_CORE && PCI && I2C && DVB_NGENE > ----help--- > - Support for the CI module found on cineS2 DVB-S2, supported by > - the Micronas PCIe device driver (ngene). > + tristate "CXD2099AR Common Interface driver" > + depends on DVB_CORE && PCI && I2C > + ---help--- > + Support for the CI module found on cards based on > + - Micronas ngene PCIe bridge: cineS2 etc. > + - Digital Devices PCIe bridge: Octopus series > > For now, data is passed through '/dev/dvb/adapterX/sec0': > - Encrypted data must be written to 'sec0'. Hi Oliver, => can you explain a bit more on "data is passed through '/dev/dvb/adapterX/sec0':" How is the idea behind the setup? Is each adapter having its own sec0? Walter -- 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 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Hi Mauro,
On Monday 04 July 2011 00:27:54 Mauro Carvalho Chehab wrote:
> Hi Oliver,
>
> Em 03-07-2011 18:21, Oliver Endriss escreveu:
> > [PATCH 1/5] ddbridge: Initial check-in
> > [PATCH 2/5] ddbridge: Codingstyle fixes
> > [PATCH 3/5] ddbridge: Allow compiling of the driver
> > [PATCH 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n
> > [PATCH 5/5] cxd2099: Update Kconfig descrition (ddbridge support)
> >
> > Note:
> > This patch series depends on the previous one:
> > [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
>
> I've applied both series today on an experimental tree that I use when merging
> some complex drivers. They are at:
>
> http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/ngene
>
> I didn't actually reviewed the patch series yet, but I noticed some troubles
> related to Coding Style, and 2 compilation breakages, when all drivers are
> selected,
> due to some duplicated symbols. So, I've applied some patches fixing the
> issues
> I noticed. It would be great if you could test if the changes didn't break
> anything.
Apparently these duplicated symbols did not show up here,
because I compiled the drivers as modules. :-(
> There's a problem that I've noticed already at the patch series: the usage of
> CHK_ERROR macro hided a trouble on some places, especially at drxd_hard.c.
>
> As you know, the macro was defined as:
> #define CHK_ERROR(s) if ((status = s)) break
>
> I've replaced it, on all places, using a small perl script, as the above is a
> CodingStyle
> violation, and may hide some troubles[1].
True.
> [1]
> http://git.linuxtv.org/mchehab/experimental.git?a=commit;h=792ecdd1cc494a1e10ed494052ed697ab4e1aa8a
>
> After the removal, I've noticed that this works fine on several places
> where the code have things like:
> do {
> status = foo()
> if (status < 0)
> break;
>
> } while (0);
>
> There are places, however, that there are two loops, like, for example, at:
>
> static int DRX_Start(struct drxd_state *state, s32 off)
> {
> ...
> do {
> ...
> switch (p->transmission_mode) {
> case TRANSMISSION_MODE_8K:
> transmissionParams |= SC_RA_RAM_OP_PARAM_MODE_8K;
> if (state->type_A) {
> status = Write16(state, EC_SB_REG_TR_MODE__A,
> EC_SB_REG_TR_MODE_8K, 0x);
> if (status < 0)
> break;
> }
> break;
> ...
> }
>
> ...
> } while (0);
>
> return status;
>
> On those cases, instead of returning the error status, the function
> will just ignore the error and proceed to the next switch(). In this specific
> routine, as there are no locks inside the code, the better fix would be to
> just replace:
> if (status < 0)
> break;
> by
> if (status < 0)
> return (status);
>
> But I suspect that the same trouble is also present on other parts of the
> code.
>
> Another issue that I've noticed alread is that, on some places, instead of
> doing
> "return -EINVAL" (or some other proper error code), the code is just doing:
> "return -1".
>
> Could you please take a look on those issues?
That CHK_ERROR stuff appears very dangerous to me.
Btw, this is why I did not remove the curly braces { } in some cases:
if (...) {
CHK_ERROR(...)
}
It would have caused really nasty effects.
Anyway, I spent the whole weekend to re-format the code carefully
and create both patch series, trying not to break anything.
I simply cannot go through the driver code and verify everything.
Please note that I am not the driver author!
I think Ralph should comment on this.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
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] TT S-1500b tuning issue
On Wednesday 29 June 2011 15:16:10 Sébastien RAILLARD wrote:
> Dear all,
>
> We have found what seems to be a tuning issue in the driver for the ALPS
> BSBE1-D01A used in the new TT-S-1500b card from Technotrend.
> On some transponders, like ASTRA 19.2E 11817-V-27500, the card can work very
> well (no lock issues) for hours.
>
> On some other transponders, like ASTRA 19.2E 11567-V-22000, the card nearly
> never manage to get the lock: it's looking like the signal isn't good
> enough.
Afaics the problem is caused by the tuning loop
for (tm = -6; tm < 7;)
in stv0288_set_frontend().
I doubt that this code works reliably.
Apparently it never obtains a lock within the given delay (30us).
Could you please try the attached patch?
It disables the loop and tries to tune to the center frequency.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
diff --git a/drivers/media/dvb/frontends/stv0288.c b/drivers/media/dvb/frontends/stv0288.c
index 8e0cfad..4ffe7da 100644
--- a/drivers/media/dvb/frontends/stv0288.c
+++ b/drivers/media/dvb/frontends/stv0288.c
@@ -488,6 +488,10 @@ static int stv0288_set_frontend(struct dvb_frontend *fe,
/* Carrier lock control register */
stv0288_writeregI(state, 0x15, 0xc5);
+#if 1 /* TEST */
+ stv0288_writeregI(state, 0x2b, 0);
+ stv0288_writeregI(state, 0x2c, 0);
+#else
tda[0] = 0x2b; /* CFRM */
tda[2] = 0x0; /* CFRL */
for (tm = -6; tm < 7;) {
@@ -503,6 +507,7 @@ static int stv0288_set_frontend(struct dvb_frontend *fe,
stv0288_writeregI(state, 0x2c, tda[2]);
udelay(30);
}
+#endif
state->tuner_frequency = c->frequency;
state->fec_inner = FEC_AUTO;
Re: [PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
Hi Oliver,
Em 03-07-2011 18:21, Oliver Endriss escreveu:
> [PATCH 1/5] ddbridge: Initial check-in
> [PATCH 2/5] ddbridge: Codingstyle fixes
> [PATCH 3/5] ddbridge: Allow compiling of the driver
> [PATCH 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n
> [PATCH 5/5] cxd2099: Update Kconfig descrition (ddbridge support)
>
> Note:
> This patch series depends on the previous one:
> [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
I've applied both series today on an experimental tree that I use when merging
some complex drivers. They are at:
http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/ngene
I didn't actually reviewed the patch series yet, but I noticed some troubles
related to Coding Style, and 2 compilation breakages, when all drivers are
selected,
due to some duplicated symbols. So, I've applied some patches fixing the issues
I noticed. It would be great if you could test if the changes didn't break
anything.
There's a problem that I've noticed already at the patch series: the usage of
CHK_ERROR macro hided a trouble on some places, especially at drxd_hard.c.
As you know, the macro was defined as:
#define CHK_ERROR(s) if ((status = s)) break
I've replaced it, on all places, using a small perl script, as the above is a
CodingStyle
violation, and may hide some troubles[1].
[1]
http://git.linuxtv.org/mchehab/experimental.git?a=commit;h=792ecdd1cc494a1e10ed494052ed697ab4e1aa8a
After the removal, I've noticed that this works fine on several places
where the code have things like:
do {
status = foo()
if (status < 0)
break;
} while (0);
There are places, however, that there are two loops, like, for example, at:
static int DRX_Start(struct drxd_state *state, s32 off)
{
...
do {
...
switch (p->transmission_mode) {
case TRANSMISSION_MODE_8K:
transmissionParams |= SC_RA_RAM_OP_PARAM_MODE_8K;
if (state->type_A) {
status = Write16(state, EC_SB_REG_TR_MODE__A,
EC_SB_REG_TR_MODE_8K, 0x);
if (status < 0)
break;
}
break;
...
}
...
} while (0);
return status;
On those cases, instead of returning the error status, the function
will just ignore the error and proceed to the next switch(). In this specific
routine, as there are no locks inside the code, the better fix would be to
just replace:
if (status < 0)
break;
by
if (status < 0)
return (status);
But I suspect that the same trouble is also present on other parts of the code.
Another issue that I've noticed alread is that, on some places, instead of
doing
"return -EINVAL" (or some other proper error code), the code is just doing:
"return -1".
Could you please take a look on those issues?
Thanks!
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n
Fix compilation of ngene/ddbridge for DVB_CXD2099=n.
Note: Bug was introduced by commit 'cxd2099: Update to latest version'.
Signed-off-by: Oliver Endriss
---
drivers/staging/cxd2099/cxd2099.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/cxd2099/cxd2099.h
b/drivers/staging/cxd2099/cxd2099.h
index 75459d4..19c588a 100644
--- a/drivers/staging/cxd2099/cxd2099.h
+++ b/drivers/staging/cxd2099/cxd2099.h
@@ -41,7 +41,7 @@ struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg *cfg,
#else
static inline struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg *cfg,
- void *priv, struct i2c_adapter *i2c);
+ void *priv, struct i2c_adapter *i2c)
{
printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
return NULL;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] cxd2099: Update Kconfig description (ddbridge support)
Update Kconfig description (ddbridge with cxd2099) Signed-off-by: Oliver Endriss --- drivers/staging/cxd2099/Kconfig | 11 ++- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/staging/cxd2099/Kconfig b/drivers/staging/cxd2099/Kconfig index 9d638c3..b48aefd 100644 --- a/drivers/staging/cxd2099/Kconfig +++ b/drivers/staging/cxd2099/Kconfig @@ -1,9 +1,10 @@ config DVB_CXD2099 -tristate "CXD2099AR Common Interface driver" -depends on DVB_CORE && PCI && I2C && DVB_NGENE ----help--- - Support for the CI module found on cineS2 DVB-S2, supported by - the Micronas PCIe device driver (ngene). + tristate "CXD2099AR Common Interface driver" + depends on DVB_CORE && PCI && I2C + ---help--- + Support for the CI module found on cards based on + - Micronas ngene PCIe bridge: cineS2 etc. + - Digital Devices PCIe bridge: Octopus series For now, data is passed through '/dev/dvb/adapterX/sec0': - Encrypted data must be written to 'sec0'. -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ddbridge: Allow compiling of the driver
Driver added to Makefile and Kconfig.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/Kconfig |4
drivers/media/dvb/Makefile |3 ++-
drivers/media/dvb/ddbridge/Kconfig | 18 ++
drivers/media/dvb/ddbridge/Makefile | 14 ++
4 files changed, 38 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/dvb/ddbridge/Kconfig
create mode 100644 drivers/media/dvb/ddbridge/Makefile
diff --git a/drivers/media/dvb/Kconfig b/drivers/media/dvb/Kconfig
index ee214c3..f6e40b3 100644
--- a/drivers/media/dvb/Kconfig
+++ b/drivers/media/dvb/Kconfig
@@ -80,6 +80,10 @@ comment "Supported nGene Adapters"
depends on DVB_CORE && PCI && I2C
source "drivers/media/dvb/ngene/Kconfig"
+comment "Supported ddbridge ('Octopus') Adapters"
+ depends on DVB_CORE && PCI && I2C
+ source "drivers/media/dvb/ddbridge/Kconfig"
+
comment "Supported DVB Frontends"
depends on DVB_CORE
source "drivers/media/dvb/frontends/Kconfig"
diff --git a/drivers/media/dvb/Makefile b/drivers/media/dvb/Makefile
index a1a0875..b2cefe6 100644
--- a/drivers/media/dvb/Makefile
+++ b/drivers/media/dvb/Makefile
@@ -15,6 +15,7 @@ obj-y:= dvb-core/ \
dm1105/ \
pt1/\
mantis/ \
- ngene/
+ ngene/ \
+ ddbridge/
obj-$(CONFIG_DVB_FIREDTV) += firewire/
diff --git a/drivers/media/dvb/ddbridge/Kconfig
b/drivers/media/dvb/ddbridge/Kconfig
new file mode 100644
index 000..d099e1a
--- /dev/null
+++ b/drivers/media/dvb/ddbridge/Kconfig
@@ -0,0 +1,18 @@
+config DVB_DDBRIDGE
+ tristate "Digital Devices bridge support"
+ depends on DVB_CORE && PCI && I2C
+ select DVB_LNBP21 if !DVB_FE_CUSTOMISE
+ select DVB_STV6110x if !DVB_FE_CUSTOMISE
+ select DVB_STV090x if !DVB_FE_CUSTOMISE
+ select DVB_DRXK if !DVB_FE_CUSTOMISE
+ select DVB_TDA18271C2DD if !DVB_FE_CUSTOMISE
+ ---help---
+ Support for cards with the Digital Devices PCI express bridge:
+ - Octopus PCIe Bridge
+ - Octopus mini PCIe Bridge
+ - Octopus LE
+ - DuoFlex S2 Octopus
+ - DuoFlex CT Octopus
+ - cineS2(v6)
+
+ Say Y if you own such a card and want to use it.
diff --git a/drivers/media/dvb/ddbridge/Makefile
b/drivers/media/dvb/ddbridge/Makefile
new file mode 100644
index 000..de4fe19
--- /dev/null
+++ b/drivers/media/dvb/ddbridge/Makefile
@@ -0,0 +1,14 @@
+#
+# Makefile for the ddbridge device driver
+#
+
+ddbridge-objs := ddbridge-core.o
+
+obj-$(CONFIG_DVB_DDBRIDGE) += ddbridge.o
+
+EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core/
+EXTRA_CFLAGS += -Idrivers/media/dvb/frontends/
+EXTRA_CFLAGS += -Idrivers/media/common/tuners/
+
+# For the staging CI driver cxd2099
+EXTRA_CFLAGS += -Idrivers/staging/cxd2099/
--
1.7.4.1
--
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 2/5] ddbridge: Codingstyle fixes
Codingstyle fixes
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ddbridge/ddbridge-core.c | 191
drivers/media/dvb/ddbridge/ddbridge-regs.h | 62 +-
drivers/media/dvb/ddbridge/ddbridge.h |8 +-
3 files changed, 144 insertions(+), 117 deletions(-)
diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c
b/drivers/media/dvb/ddbridge/ddbridge-core.c
index ba9974b..81634f1 100644
--- a/drivers/media/dvb/ddbridge/ddbridge-core.c
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -55,7 +55,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
{
struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1 }};
+ .buf = val, .len = 1 } };
return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
}
@@ -64,7 +64,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
u8 reg, u8 *val)
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
.buf = ®, .len = 1 },
{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1 }};
+ .buf = val, .len = 1 } };
return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
}
@@ -75,7 +75,7 @@ static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
.buf = msg, .len = 2},
{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1}};
+ .buf = val, .len = 1} };
return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
}
@@ -89,15 +89,15 @@ static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32
cmd)
ddbwritel((adr << 9) | cmd, i2c->regs + I2C_COMMAND);
stat = wait_event_timeout(i2c->wq, i2c->done == 1, HZ);
if (stat <= 0) {
- printk("I2C timeout\n");
+ printk(KERN_ERR "I2C timeout\n");
{ /* MSI debugging*/
u32 istat = ddbreadl(INTERRUPT_STATUS);
- printk("IRS %08x\n", istat);
+ printk(KERN_ERR "IRS %08x\n", istat);
ddbwritel(istat, INTERRUPT_ACK);
}
return -EIO;
}
- val=ddbreadl(i2c->regs+I2C_COMMAND);
+ val = ddbreadl(i2c->regs+I2C_COMMAND);
if (val & 0x7)
return -EIO;
return 0;
@@ -108,7 +108,7 @@ static int ddb_i2c_master_xfer(struct i2c_adapter *adapter,
{
struct ddb_i2c *i2c = (struct ddb_i2c *)i2c_get_adapdata(adapter);
struct ddb *dev = i2c->dev;
- u8 addr=0;
+ u8 addr = 0;
if (num)
addr = msg[0].addr;
@@ -116,7 +116,7 @@ static int ddb_i2c_master_xfer(struct i2c_adapter *adapter,
if (num == 2 && msg[1].flags & I2C_M_RD &&
!(msg[0].flags & I2C_M_RD)) {
memcpy_toio(dev->regs + I2C_TASKMEM_BASE + i2c->wbuf,
- msg[0].buf,msg[0].len);
+ msg[0].buf, msg[0].len);
ddbwritel(msg[0].len|(msg[1].len << 16),
i2c->regs+I2C_TASKLENGTH);
if (!ddb_i2c_cmd(i2c, addr, 1)) {
@@ -128,7 +128,7 @@ static int ddb_i2c_master_xfer(struct i2c_adapter *adapter,
}
if (num == 1 && !(msg[0].flags & I2C_M_RD)) {
- ddbcpyto(I2C_TASKMEM_BASE + i2c->wbuf,msg[0].buf, msg[0].len);
+ ddbcpyto(I2C_TASKMEM_BASE + i2c->wbuf, msg[0].buf, msg[0].len);
ddbwritel(msg[0].len, i2c->regs + I2C_TASKLENGTH);
if (!ddb_i2c_cmd(i2c, addr, 2))
return num;
@@ -217,6 +217,7 @@ static int ddb_i2c_init(struct ddb *dev)
/**/
/**/
+#if 0
static void set_table(struct ddb *dev, u32 off,
dma_addr_t *pbuf, u32 num)
{
@@ -230,6 +231,7 @@ static void set_table(struct ddb *dev, u32 off,
ddbwritel(mem >> 32, base + i * 8 + 4);
}
}
+#endif
static void ddb_address_table(struct ddb *dev)
{
@@ -401,7 +403,7 @@ static void ddb_output_start(struct ddb_output *output)
ddbwritel(1, DMA_BASE_READ);
ddbwritel(3, DMA_BUFFER_CONTROL(output->nr + 8));
- //ddbwritel(0xbd, TS_OUTPUT_CONTROL(output->nr));
+ /* ddbwritel(0xbd, TS_OUTPUT_CONTROL(output->nr)); */
ddbwritel(0x1d, TS_OUTPUT_CONTROL(output->nr));
output->running = 1;
spin_unlock_irq(&output->lock);
@@ -438,7 +440,7 @@ static u32 ddb_output_free(struct ddb_output *output)
return 0;
}
PATCH 1/5] ddbridge: Initial check-in
From: Ralph Metzler
Driver support for Digital Devices ddbridge-based cards:
Octopus, Octopus mini, Octopus LE, cineS2(v6)
with DuoFlex S2 and/or DuoFlex CT tuners.
Driver was taken from ddbridge-0.6.1.tar.bz2.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ddbridge/ddbridge-core.c | 1690
drivers/media/dvb/ddbridge/ddbridge-regs.h | 151 +++
drivers/media/dvb/ddbridge/ddbridge.h | 187 +++
3 files changed, 2028 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/ddbridge/ddbridge-core.c
create mode 100644 drivers/media/dvb/ddbridge/ddbridge-regs.h
create mode 100644 drivers/media/dvb/ddbridge/ddbridge.h
diff --git a/drivers/media/dvb/ddbridge/ddbridge-core.c
b/drivers/media/dvb/ddbridge/ddbridge-core.c
new file mode 100644
index 000..ba9974b
--- /dev/null
+++ b/drivers/media/dvb/ddbridge/ddbridge-core.c
@@ -0,0 +1,1690 @@
+/*
+ * ddbridge.c: Digital Devices PCIe bridge driver
+ *
+ * Copyright (C) 2010-2011 Digital Devices GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ddbridge.h"
+
+#include "ddbridge-regs.h"
+
+#include "tda18271c2dd.h"
+#include "stv6110x.h"
+#include "stv090x.h"
+#include "lnbh24.h"
+#include "drxk.h"
+
+DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
+
+/* MSI had problems with lost interrupts, fixed but needs testing */
+#undef CONFIG_PCI_MSI
+
+/**/
+
+static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
+{
+ struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1 }};
+ return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
+}
+
+static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr, u8 reg, u8 *val)
+{
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = ®, .len = 1 },
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1 }};
+ return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
+}
+
+static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
+ u16 reg, u8 *val)
+{
+ u8 msg[2] = {reg>>8, reg&0xff};
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = msg, .len = 2},
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1}};
+ return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
+}
+
+static int ddb_i2c_cmd(struct ddb_i2c *i2c, u32 adr, u32 cmd)
+{
+ struct ddb *dev = i2c->dev;
+ int stat;
+ u32 val;
+
+ i2c->done = 0;
+ ddbwritel((adr << 9) | cmd, i2c->regs + I2C_COMMAND);
+ stat = wait_event_timeout(i2c->wq, i2c->done == 1, HZ);
+ if (stat <= 0) {
+ printk("I2C timeout\n");
+ { /* MSI debugging*/
+ u32 istat = ddbreadl(INTERRUPT_STATUS);
+ printk("IRS %08x\n", istat);
+ ddbwritel(istat, INTERRUPT_ACK);
+ }
+ return -EIO;
+ }
+ val=ddbreadl(i2c->regs+I2C_COMMAND);
+ if (val & 0x7)
+ return -EIO;
+ return 0;
+}
+
+static int ddb_i2c_master_xfer(struct i2c_adapter *adapter,
+ struct i2c_msg msg[], int num)
+{
+ struct ddb_i2c *i2c = (struct ddb_i2c *)i2c_get_adapdata(adapter);
+ struct ddb *dev = i2c->dev;
+ u8 addr=0;
+
+ if (num)
+ addr = msg[0].addr;
+
+ if (num == 2 && msg[1].flags & I2C_M_RD &&
+ !(msg[0].flags & I2C_M_RD)) {
+ memcpy_toio(dev->regs + I2C_TASKMEM_BASE + i2c->wbuf,
+ msg[0].buf,msg[0].len);
+ ddbwritel(msg[0].len|(msg[1].len << 16),
+ i2c->regs+I2C_TASKLENGTH);
+ if (!ddb_i2c_cmd(i2c, addr, 1)) {
+ memcpy_fromio(msg[1].buf,
+
[PATCH 0/5] Driver support for cards based on Digital Devices bridge (ddbridge)
[PATCH 1/5] ddbridge: Initial check-in [PATCH 2/5] ddbridge: Codingstyle fixes [PATCH 3/5] ddbridge: Allow compiling of the driver [PATCH 4/5] cxd2099: Fix compilation of ngene/ddbridge for DVB_CXD2099=n [PATCH 5/5] cxd2099: Update Kconfig descrition (ddbridge support) Note: This patch series depends on the previous one: [PATCH 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] STV0288 Fast Channel Acquisition
On Fri, 2011-07-01 at 10:15 +0200, Sébastien RAILLARD (COEXSI) wrote: > > > -Original Message- > > From: linux-media-ow...@vger.kernel.org [mailto:linux-media- > > ow...@vger.kernel.org] On Behalf Of Malcolm Priestley > > Sent: vendredi 1 juillet 2011 00:22 > > To: Linux Media Mailing List > > Cc: Sébastien RAILLARD (COEXSI) > > Subject: [PATCH] STV0288 Fast Channel Acquisition > > > > On Wed, 2011-06-29 at 15:16 +0200, Sébastien RAILLARD (COEXSI) wrote: > > > > > On some other transponders, like ASTRA 19.2E 11567-V-22000, the card > > > nearly never manage to get the lock: it's looking like the signal > > > isn't good enough. > > > I turned on the debugging of the stb6000 and stv0288 modules, but I > > > can't see anything wrong. > > > > I have had similar problems with the stv0288 on astra 19.2 and 28.2 with > > various frequencies. > > > > I have been using this patch for some time which seems to improve > > things. > > > > The STV0288 has a fast channel function which eliminates the need for > > software carrier search. > > > > The patch removes the slow carrier search and replaces it with this > > faster and more reliable built-in chip function. > > > > If carrier is lost while channel is running, fast channel attempts to > > recover it. > > > > The patch also reguires registers 50-57 to be set correctly with > > inittab. All current combinations in the kernel media tree have been > > checked and tested. > > > > Thanks Macolm for this patch! > > Regarding the TT-S-1500b, it's using a specific inittab, I hope Oliver can > have a look and check if this patch is compatible with the ALPS BSBE1 tuner. > > Sebastien > For some reason, I have had nothing but trouble today testing this patch scanning and tuning certain frequencies. Especially 11426V on Astra 28.2. So this patch is for review only and marked not applicable on Patchwork. tvboxspy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mceusb: Timeout unit corrections
Unit missmatch in mceusb_handle_command. It should be converting to us,
not 1/10th of ms.
mceusb_dev_printdata 100us/ms -> 1000us/ms
Signed-off-by: Rafi Rubin
---
Fixing the interpretation of the timeout corrects buggy behavior,
particularly when using a mceusb reciever in lirc mode for arbitrary
remote controls (the mce remotes actually worked, don't know why).
---
drivers/media/rc/mceusb.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index ad927fc..377f826 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -551,7 +551,7 @@ static void mceusb_dev_printdata(struct mceusb_dev *ir,
char *buf,
case MCE_CMD_S_TIMEOUT:
/* value is in units of 50us, so x*50/100 or x/2 ms */
dev_info(dev, "%s receive timeout of %d ms\n",
-inout, ((data1 << 8) | data2) / 2);
+inout, ((data1 << 8) | data2) / 20);
break;
case MCE_CMD_G_TIMEOUT:
dev_info(dev, "Get receive timeout\n");
@@ -835,7 +835,7 @@ static void mceusb_handle_command(struct mceusb_dev *ir,
int index)
switch (ir->buf_in[index]) {
/* 2-byte return value commands */
case MCE_CMD_S_TIMEOUT:
- ir->rc->timeout = US_TO_NS((hi << 8 | lo) / 2);
+ ir->rc->timeout = US_TO_NS((hi << 8 | lo) * MCE_TIME_UNIT);
break;
/* 1-byte return value commands */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mceusb: increase default timeout to 100ms
Signed-off-by: Rafi Rubin
---
This changes the default to something a little more sane. I have one
mceusb device that currently does not respond properly to the initial
polling and is left using the default timeout. 1ms does not work well.
I propose changing the default to 100ms to match the timeout reported by
my other mceusb device and works fine for me.
---
drivers/media/rc/mceusb.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
index 377f826..956d296 100644
--- a/drivers/media/rc/mceusb.c
+++ b/drivers/media/rc/mceusb.c
@@ -1082,7 +1082,7 @@ static struct rc_dev *mceusb_init_rc_dev(struct
mceusb_dev *ir)
rc->priv = ir;
rc->driver_type = RC_DRIVER_IR_RAW;
rc->allowed_protos = RC_TYPE_ALL;
- rc->timeout = US_TO_NS(1000);
+ rc->timeout = MS_TO_NS(100);
if (!ir->flags.no_tx) {
rc->s_tx_mask = mceusb_set_tx_mask;
rc->s_tx_carrier = mceusb_set_tx_carrier;
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Media subsystem workshop 2011 - Prague - Oct 24-26
Hi Mauro, On Wednesday 22 June 2011 20:33:34 Mauro Carvalho Chehab wrote: Media subsystem workshop 2011 - Prague - Oct 24-26 Since 2007, we're doing annual mini-summits for the media subsystem, in order to plan the new features that will be introduced there. Last year, during the Kernel Summit 2010, it was decided that the Kernel Summit 2011 format will be modified, in order to strength the interaction between the several sub-system mini-summits and the main Kernel Summit. If this idea works well, the next Kernel Summits will also follow the same format. So, some mini-summits were proposed to happen together with the Kernel Summit 2011. Among a few others, the Media subsystem was accepted to be held with this year's Kernel Summit. So, we'd like to announce that the Media subsystem workshop 2011 will happen together with the Kernel Summit 2011. > The Media subsystem workshop is on early planning stages, but the idea is that we'll have an entire day to do the media discussions. We'll also planning to have workshop presentations inside the Kernel Summit 2011 with the workshop and Kernel Summit attendants present, where workshop results will be presented. So, I'd like to invite V4L, DVB and RC developers to submit proposals for the themes to be discussed. Please email me if you're interested on being invited for the event. This has convinced me to come to Prague for this + kernel summit. So I hope I can get an invitation :) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Vacation
Hi All, This will be one of my last mails as I'm leaving for vacation tomorrow. I'll be back July 12th Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kudos for the new vtl2 ctrls framework
Hi all, After making some serious use of it in the pwc driver cleanup I would like to thank Hans V. for all his hard work on the new ctrl framework. The clusters bit got a bit getting used to / but once I did it is great. Once you get it, it really makes sense to group certain ctrls into clusters which then get set in a single call to the driver, allowing more or less atomic handling of things like autofoo + foo changing. And in the pwc case also grouping the pan and tilt controls, which get set with a single usb command, so that with s_ex_ctrls an app can in theory do diagonal moving of the camera rather then stair case moving. Thanks Hans V.! Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.1] New SE401 driver + major pwc driver cleanup
Hi All, I'm happy to present my latest webcam work to you: I could not just stand by watching the old v4l1 se401 driver (which has been broken for a long while btw) get removed from the kernel, without writing a replacement, so I'm happy to present a new, actually working, gspca based v4l2 driver for se401 based webcams :) I've also wanted to do some much needed cleanups to the pwc driver for a long while. When I finally started with this I ended up with just replacing large parts with the new v4l2 framework, so after this patch set pwc now features: -videobuf2 for buffer management -ctrls handled by the control framework, including proper setting inactive of foo controls when autofoo is on, etc. -new v4l2 controls for pan/tilt on models with pan/tilt to replace the non standard sysfs interface for this May I also point your attention to the feature-removal-schedule commit, which adds a whole bunch of custom pwc API's / ioctls for removal, since we can handle this all fine with v4l2. If you think some of these should not be removed speak up now, or hold your silence for ever :) The following changes since commit 0c2ec360f0228bbc0c0eb6f115839d39fbbd9c61: [media] v4l2-event.h: add overview documentation to the header (2011-07-01 20:54:03 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v3.1 Hans Verkuil (1): [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK Hans de Goede (22): videodev2.h Add SE401 compressed RGB format gspca: reset image_len to 0 on LAST_PACKET when discarding frame gspca: Add new se401 camera driver gspca_sunplus: Fix streaming on logitech quicksmart 420 gspca: s/strncpy/strlcpy/ pwc: better usb disconnect handling pwc: Remove a bunch of bogus sanity checks / don't return EFAULT wrongly pwc: remove __cplusplus guards from private header pwc: Replace private buffer management code with videobuf2 pwc: Fix non CodingStyle compliant 3 space indent in pwc.h pwc: Get rid of error_status and unplugged variables pwc: Remove some unused PWC_INT_PIPE left overs pwc: Make power-saving a per device option pwc: Move various initialization to driver load and / or stream start pwc: Allow multiple opens pwc: properly allocate dma-able memory for ISO buffers pwc: Replace control code with v4l2-ctrls framework pwc: Allow dqbuf / read to complete while waiting for controls pwc: Add v4l2 controls for pan/tilt on Logitech QuickCam Orbit/Sphere pwc: Add a bunch of pwc custom API to feature-removal-schedule.txt pwc: Enable power-management by default on tested models pwc: clean-up header files Documentation/DocBook/media/v4l/pixfmt.xml |5 + .../DocBook/media/v4l/vidioc-subscribe-event.xml | 36 +- Documentation/feature-removal-schedule.txt | 35 + drivers/media/video/gspca/Kconfig | 10 + drivers/media/video/gspca/Makefile |2 + drivers/media/video/gspca/gspca.c | 11 +- drivers/media/video/gspca/se401.c | 774 +++ drivers/media/video/gspca/se401.h | 90 ++ drivers/media/video/gspca/sunplus.c|3 - drivers/media/video/gspca/t613.c |2 +- drivers/media/video/pwc/Kconfig|1 + drivers/media/video/pwc/pwc-ctrl.c | 805 ++-- drivers/media/video/pwc/pwc-dec1.c | 28 +- drivers/media/video/pwc/pwc-dec1.h |8 +- drivers/media/video/pwc/pwc-dec23.c| 22 - drivers/media/video/pwc/pwc-dec23.h| 10 - drivers/media/video/pwc/pwc-if.c | 1399 ++-- drivers/media/video/pwc/pwc-ioctl.h| 322 - drivers/media/video/pwc/pwc-kiara.c|1 - drivers/media/video/pwc/pwc-misc.c |4 - drivers/media/video/pwc/pwc-uncompress.c | 17 +- drivers/media/video/pwc/pwc-uncompress.h | 40 - drivers/media/video/pwc/pwc-v4l.c | 1256 +++ drivers/media/video/pwc/pwc.h | 404 +++--- drivers/media/video/v4l2-ctrls.c |3 +- include/linux/videodev2.h |4 +- 26 files changed, 2473 insertions(+), 2819 deletions(-) create mode 100644 drivers/media/video/gspca/se401.c create mode 100644 drivers/media/video/gspca/se401.h delete mode 100644 drivers/media/video/pwc/pwc-ioctl.h delete mode 100644 drivers/media/video/pwc/pwc-uncompress.h Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media/at91sam9x5-video: new driver for the high end overlay on at91sam9x5
Hello Sylwester,
On Sun, Jul 03, 2011 at 05:29:25PM +0200, Sylwester Nawrocki wrote:
> On 07/02/2011 10:09 PM, Uwe Kleine-König wrote:
> >>> + if (rect->left< 0)
> >>> + hwxpos = 0;
> >>> + else
> >>> + hwxpos = rect->left;
> >>
> >> Could be rewritten as:
> >>
> >>hwxpos = rect->left< 0 ? 0 : rect->left;
> > could even be rewritten as
> >
> > hwxpos = max(rect->left, 0);
>
> ok, I give up, couldn't make it any simpler;)
:-)
> >>> +static void at91sam9x5_video_vb_wait_prepare(struct vb2_queue *q)
> >>> +{
> >>> + struct at91sam9x5_video_priv *priv =
> >>> + container_of(q, struct at91sam9x5_video_priv, queue);
> >>> + unsigned long flags;
> >>> +
> >>> + debug("cfgupdate=%d hwstate=%d cfgstate=%d\n",
> >>> + priv->cfgupdate, priv->hwstate, priv->cfgstate);
> >>> + debug("bufs=%p,%p\n", priv->cur.vb, priv->next.vb);
> >>> + spin_lock_irqsave(&priv->lock, flags);
> >>> +
> >>> + at91sam9x5_video_handle_irqstat(priv);
> >>> +
> >>> + at91sam9x5_video_write32(priv, REG_HEOIER,
> >>> + REG_HEOIxR_ADD | REG_HEOIxR_DMA |
> >>> + REG_HEOIxR_UADD | REG_HEOIxR_UDMA |
> >>> + REG_HEOIxR_VADD | REG_HEOIxR_VDMA);
> >>
> >> What the above two calls are intended to be doing ?
> >
> > handle_irqstat handles the eventual pending irqs. The second call
> > enables irqs for "frame done" (..._DMA) and "new descriptor loaded"
> > (..._ADD).
>
> OK, so it looks to me like irqs are unmasked in wait_prepare and masked
> back in wait_finish. I would try to move this logic to start_streaming and
> the interrupt handler.
The upside of my approach is that if the driver always has two buffers
it never needs to interrupt the cpu and so improves overall system
performance.
> It seems this way too much dependant on when wait_prepare/wait_finish are
> called by videobuf2. AFAIK those callbacks are not called in non-blocking
> mode.
Even when I don't enable irqs I give buffers back in the
at91sam9x5_video_handle_irqstat routine.
> >>> +const struct vb2_ops at91sam9x5_video_vb_ops = {
> >>> + .queue_setup = at91sam9x5_video_vb_queue_setup,
> >>> +
> >>> + .wait_prepare = at91sam9x5_video_vb_wait_prepare,
> >>> + .wait_finish = at91sam9x5_video_vb_wait_finish,
> >>
> >> These 2 functions are intended to unlock and lock respectively the mutex
> >> that is used to serialize ioctl handlers, in particular DQBUF.
> >> I'm not sure if you're doing the right thing in
> >> at91sam9x5_video_vb_wait_prepare/at91sam9x5_video_vb_wait_finish.
> > I'm not taking a mutex for sure.
>
> All right, so this needs to be changed. If you decide to add a file
> operations mutex and protect each file operation individually in the driver,
> rather than assigning a pointer to such mutex to struct video_device::lock
> and let the core serialize file ops, then wait_prepare/wait_finish
> could be omitted.
I didn't notice there is a lock member in struct video_device. I'll take
a look to benefit from it.
> >>> +
> >>> + .buf_prepare = at91sam9x5_video_vb_buf_prepare,
> >>> + .buf_queue = at91sam9x5_video_vb_buf_queue,
> >>> +};
>
> Also if your driver is supposed to support write() method,
> vidioc_streamon/vidioc_streamoff should be just a pass-through for
> vb2_streamon/vb2_streamoff and the hardware control should happen in
> start_streaming, stop_streaming callbacks.
>
> I can't see a stop_streaming callback in your vb2 operations set.
> It's been made mandatory recently, thus it would be good to add it.
The logic is in at91sam9x5_video_vb_buf_queue because I can enable the
channel only with a buffer at hand.
> >>> +
> >>> +static int at91sam9x5_video_vidioc_querycap(struct file *filp,
> >>> + void *fh, struct v4l2_capability *cap)
> >>> +{
> >>> + strcpy(cap->driver, DRIVER_NAME);
>
> I would go for a strlcpy here, better to be safe than sorry. ;-)
Right.
> >>> + cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING |
> >>> + V4L2_CAP_VIDEO_OVERLAY;
> >>> +
> >>> + /* XXX */
> >>> + cap->version = 0;
> >>
> >> There is no need to set this field any more. It will be overwritten
> >> with kernel versions in __video_do_ioctl(). See this for more details:
> >> http://git.linuxtv.org/media_tree.git?a=commit;h=33436a81b0d4d1036ffcf0edb7e3bfa65d18ad08
> > I saw the discussion on the ML, but missed that it was already
> > committed.
> >
> >>> + cap->card[0] = '\0';
> >>> + cap->bus_info[0] = '\0';
> > I assume I need to fill these with more sensible values?
>
> I think bus_info is not very useful for this driver and can be left as is.
> As for cap->card, I'm not sure. Some drivers just just fill it in with
> a video node name (/dev/video*), some are more creative.
> Here is what the V4L2 specifications says:
> http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Jul 3 19:00:33 CEST 2011 git hash:df6aabbeb2b8799d97f3886fc994c318bc6a6843 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS spec-git: ERRORS sparse: 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 V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/16] DRX-K: Initial check-in
As the patch is too large, it is available from here: http://escape-edv.de/endriss/tmp/dvb-20110703/0003-drxk-Initial-check-in.patch CU Oliver -- 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 04/16] DRX-K: Shrink size of drxk_map.h
As the patch is too large, it is available from here: http://escape-edv.de/endriss/tmp/dvb-20110703/0004-drxk-Shrink-size-of-drxk_map.h.patch CU Oliver -- 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 16/16] ngene: Strip dummy packets inserted by the driver
As the CI requires a continuous data stream, the driver inserts dummy
packets when necessary. Do not pass these packets to userspace anymore.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c |2 +-
drivers/media/dvb/ngene/ngene-dvb.c | 42 +-
drivers/media/dvb/ngene/ngene.h |2 +
3 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index df0f0bd..f129a93 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -507,7 +507,7 @@ void FillTSBuffer(void *Buffer, int Length, u32 Flags)
{
u32 *ptr = Buffer;
- memset(Buffer, 0xff, Length);
+ memset(Buffer, TS_FILLER, Length);
while (Length > 0) {
if (Flags & DF_SWAP32)
*ptr = 0x471FFF10;
diff --git a/drivers/media/dvb/ngene/ngene-dvb.c
b/drivers/media/dvb/ngene/ngene-dvb.c
index ba209cb..fcb16a6 100644
--- a/drivers/media/dvb/ngene/ngene-dvb.c
+++ b/drivers/media/dvb/ngene/ngene-dvb.c
@@ -118,6 +118,16 @@ static void swap_buffer(u32 *p, u32 len)
}
}
+/* start of filler packet */
+static u8 fill_ts[] = { 0x47, 0x1f, 0xff, 0x10, TS_FILLER };
+
+/* #define DEBUG_CI_XFER */
+#ifdef DEBUG_CI_XFER
+static u32 ok;
+static u32 overflow;
+static u32 stripped;
+#endif
+
void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)
{
struct ngene_channel *chan = priv;
@@ -126,21 +136,41 @@ void *tsin_exchange(void *priv, void *buf, u32 len, u32
clock, u32 flags)
if (flags & DF_SWAP32)
swap_buffer(buf, len);
+
if (dev->ci.en && chan->number == 2) {
- if (dvb_ringbuffer_free(&dev->tsin_rbuf) > len) {
- dvb_ringbuffer_write(&dev->tsin_rbuf, buf, len);
- wake_up_interruptible(&dev->tsin_rbuf.queue);
+ while (len >= 188) {
+ if (memcmp(buf, fill_ts, sizeof fill_ts) != 0) {
+ if (dvb_ringbuffer_free(&dev->tsin_rbuf) >=
188) {
+ dvb_ringbuffer_write(&dev->tsin_rbuf,
buf, 188);
+ wake_up(&dev->tsin_rbuf.queue);
+#ifdef DEBUG_CI_XFER
+ ok++;
+#endif
+ }
+#ifdef DEBUG_CI_XFER
+ else
+ overflow++;
+#endif
+ }
+#ifdef DEBUG_CI_XFER
+ else
+ stripped++;
+
+ if (ok % 100 == 0 && overflow)
+ printk(KERN_WARNING "%s: ok %u overflow %u
dropped %u\n", __func__, ok, overflow, stripped);
+#endif
+ buf += 188;
+ len -= 188;
}
- return 0;
+ return NULL;
}
+
if (chan->users > 0)
dvb_dmx_swfilter(&chan->demux, buf, len);
return NULL;
}
-u8 fill_ts[188] = { 0x47, 0x1f, 0xff, 0x10 };
-
void *tsout_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)
{
struct ngene_channel *chan = priv;
diff --git a/drivers/media/dvb/ngene/ngene.h b/drivers/media/dvb/ngene/ngene.h
index 90fa136..5443dc0 100644
--- a/drivers/media/dvb/ngene/ngene.h
+++ b/drivers/media/dvb/ngene/ngene.h
@@ -789,6 +789,8 @@ struct ngene {
u8uart_rbuf[UART_RBUF_LEN];
int uart_rp, uart_wp;
+#define TS_FILLER 0x6f
+
u8 *tsout_buf;
#define TSOUT_BUF_SIZE (512*188*8)
struct dvb_ringbuffer tsout_rbuf;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] ngene: Update for latest cxd2099
Modifications for latest cxd2099.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-core.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-core.c
b/drivers/media/dvb/ngene/ngene-core.c
index fa4b3eb..df0f0bd 100644
--- a/drivers/media/dvb/ngene/ngene-core.c
+++ b/drivers/media/dvb/ngene/ngene-core.c
@@ -1582,11 +1582,18 @@ static int init_channels(struct ngene *dev)
return 0;
}
+static struct cxd2099_cfg cxd_cfg = {
+ .bitrate = 62000,
+ .adr = 0x40,
+ .polarity = 0,
+ .clock_mode = 0,
+};
+
static void cxd_attach(struct ngene *dev)
{
struct ngene_ci *ci = &dev->ci;
- ci->en = cxd2099_attach(0x40, dev, &dev->channel[0].i2c_adapter);
+ ci->en = cxd2099_attach(&cxd_cfg, dev, &dev->channel[0].i2c_adapter);
ci->dev = dev;
return;
}
--
1.7.4.1
--
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 14/16] cxd2099: Codingstyle fixes
Codingstyle fixes.
Signed-off-by: Oliver Endriss
---
drivers/staging/cxd2099/cxd2099.c | 75 ++---
drivers/staging/cxd2099/cxd2099.h |6 +-
2 files changed, 40 insertions(+), 41 deletions(-)
diff --git a/drivers/staging/cxd2099/cxd2099.c
b/drivers/staging/cxd2099/cxd2099.c
index 803a592..6ec30c1 100644
--- a/drivers/staging/cxd2099/cxd2099.c
+++ b/drivers/staging/cxd2099/cxd2099.c
@@ -64,7 +64,7 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
u8 reg, u8 data)
{
u8 m[2] = {reg, data};
- struct i2c_msg msg = {.addr=adr, .flags=0, .buf=m, .len=2};
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
if (i2c_transfer(adapter, &msg, 1) != 1) {
printk(KERN_ERR "Failed to write to I2C register %02x@%02x!\n",
@@ -77,7 +77,7 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
static int i2c_write(struct i2c_adapter *adapter, u8 adr,
u8 *data, u8 len)
{
- struct i2c_msg msg = {.addr=adr, .flags=0, .buf=data, .len=len};
+ struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
if (i2c_transfer(adapter, &msg, 1) != 1) {
printk(KERN_ERR "Failed to write to I2C!\n");
@@ -92,7 +92,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
.buf = ®, .len = 1},
{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1}};
+ .buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
printk(KERN_ERR "error in i2c_read_reg\n");
@@ -107,7 +107,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
.buf = ®, .len = 1},
{.addr = adr, .flags = I2C_M_RD,
-.buf = data, .len = n}};
+.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
printk(KERN_ERR "error in i2c_read\n");
@@ -139,7 +139,7 @@ static int read_pccard(struct cxd *ci, u16 address, u8
*data, u8 n)
int status;
u8 addr[3] = {2, address & 0xff, address >> 8};
- status=i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
+ status = i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
if (!status)
status = i2c_read(ci->i2c, ci->cfg.adr, 3, data, n);
return status;
@@ -150,7 +150,7 @@ static int write_pccard(struct cxd *ci, u16 address, u8
*data, u8 n)
int status;
u8 addr[3] = {2, address & 0xff, address >> 8};
- status=i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
+ status = i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
if (!status) {
u8 buf[256] = {3};
memcpy(buf+1, data, n);
@@ -213,8 +213,8 @@ static int write_regm(struct cxd *ci, u8 reg, u8 val, u8
mask)
{
int status;
- status=i2c_write_reg(ci->i2c, ci->cfg.adr, 0, reg);
- if (!status && reg >= 6 && reg <=8 && mask != 0xff)
+ status = i2c_write_reg(ci->i2c, ci->cfg.adr, 0, reg);
+ if (!status && reg >= 6 && reg <= 8 && mask != 0xff)
status = i2c_read_reg(ci->i2c, ci->cfg.adr, 1, &ci->regs[reg]);
ci->regs[reg] = (ci->regs[reg] & (~mask)) | val;
if (!status) {
@@ -294,14 +294,14 @@ static void cam_mode(struct cxd *ci, int mode)
-#define CHK_ERROR(s) if( (status = s) ) break
+#define CHK_ERROR(s) if ((status = s)) break
static int init(struct cxd *ci)
{
int status;
mutex_lock(&ci->lock);
- ci->mode=-1;
+ ci->mode = -1;
do {
CHK_ERROR(write_reg(ci, 0x00, 0x00));
CHK_ERROR(write_reg(ci, 0x01, 0x00));
@@ -322,7 +322,7 @@ static int init(struct cxd *ci)
CHK_ERROR(write_regm(ci, 0x14, 0x00, 0x0F));
CHK_ERROR(write_reg(ci, 0x15, ci->clk_reg_b));
CHK_ERROR(write_regm(ci, 0x16, 0x00, 0x0F));
- CHK_ERROR(write_reg(ci, 0x17,ci->clk_reg_f));
+ CHK_ERROR(write_reg(ci, 0x17, ci->clk_reg_f));
if (ci->cfg.clock_mode) {
if (ci->cfg.polarity) {
@@ -352,9 +352,9 @@ static int init(struct cxd *ci)
/* Put TS in bypass */
CHK_ERROR(write_regm(ci, 0x09, 0x08, 0x08));
- ci->cammode=-1;
+ ci->cammode = -1;
cam_mode(ci, 0);
- } while(0);
+ } while (0);
mutex_unlock(&ci->lock);
return 0;
@@ -366,7 +366,7 @@ static int read_attribute_mem(struct dvb_ca_en50221 *ca,
struct cxd *ci = ca->data;
#if 0
if (ci->amem_read) {
- if (address <=0 || address>1024)
+
[PATCH 13/16] cxd2099: Update to latest version
From: Ralph Metzler
Import latest driver from ddbridge-0.6.1.tar.bz2.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/staging/cxd2099/cxd2099.c | 250 -
drivers/staging/cxd2099/cxd2099.h | 16 ++-
2 files changed, 178 insertions(+), 88 deletions(-)
diff --git a/drivers/staging/cxd2099/cxd2099.c
b/drivers/staging/cxd2099/cxd2099.c
index b49186c..803a592 100644
--- a/drivers/staging/cxd2099/cxd2099.c
+++ b/drivers/staging/cxd2099/cxd2099.c
@@ -1,7 +1,7 @@
/*
* cxd2099.c: Driver for the CXD2099AR Common Interface Controller
*
- * Copyright (C) 2010 DigitalDevices UG
+ * Copyright (C) 2010-2011 Digital Devices GmbH
*
*
* This program is free software; you can redistribute it and/or
@@ -42,13 +42,13 @@ struct cxd {
struct dvb_ca_en50221 en;
struct i2c_adapter *i2c;
- u8 adr;
+ struct cxd2099_cfg cfg;
+
u8 regs[0x23];
u8 lastaddress;
u8 clk_reg_f;
u8 clk_reg_b;
intmode;
- u32bitrate;
intready;
intdr;
intslot_stat;
@@ -64,7 +64,7 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
u8 reg, u8 data)
{
u8 m[2] = {reg, data};
- struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
+ struct i2c_msg msg = {.addr=adr, .flags=0, .buf=m, .len=2};
if (i2c_transfer(adapter, &msg, 1) != 1) {
printk(KERN_ERR "Failed to write to I2C register %02x@%02x!\n",
@@ -77,7 +77,7 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
static int i2c_write(struct i2c_adapter *adapter, u8 adr,
u8 *data, u8 len)
{
- struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
+ struct i2c_msg msg = {.addr=adr, .flags=0, .buf=data, .len=len};
if (i2c_transfer(adapter, &msg, 1) != 1) {
printk(KERN_ERR "Failed to write to I2C!\n");
@@ -90,9 +90,9 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
u8 reg, u8 *val)
{
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
- .buf = ®, .len = 1 },
+ .buf = ®, .len = 1},
{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1 } };
+ .buf = val, .len = 1}};
if (i2c_transfer(adapter, msgs, 2) != 2) {
printk(KERN_ERR "error in i2c_read_reg\n");
@@ -105,9 +105,9 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
u8 reg, u8 *data, u8 n)
{
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
- .buf = ®, .len = 1 },
- {.addr = adr, .flags = I2C_M_RD,
- .buf = data, .len = n } };
+.buf = ®, .len = 1},
+ {.addr = adr, .flags = I2C_M_RD,
+.buf = data, .len = n}};
if (i2c_transfer(adapter, msgs, 2) != 2) {
printk(KERN_ERR "error in i2c_read\n");
@@ -120,10 +120,10 @@ static int read_block(struct cxd *ci, u8 adr, u8 *data,
u8 n)
{
int status;
- status = i2c_write_reg(ci->i2c, ci->adr, 0, adr);
+ status = i2c_write_reg(ci->i2c, ci->cfg.adr, 0, adr);
if (!status) {
ci->lastaddress = adr;
- status = i2c_read(ci->i2c, ci->adr, 1, data, n);
+ status = i2c_read(ci->i2c, ci->cfg.adr, 1, data, n);
}
return status;
}
@@ -137,24 +137,24 @@ static int read_reg(struct cxd *ci, u8 reg, u8 *val)
static int read_pccard(struct cxd *ci, u16 address, u8 *data, u8 n)
{
int status;
- u8 addr[3] = { 2, address&0xff, address>>8 };
+ u8 addr[3] = {2, address & 0xff, address >> 8};
- status = i2c_write(ci->i2c, ci->adr, addr, 3);
+ status=i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
if (!status)
- status = i2c_read(ci->i2c, ci->adr, 3, data, n);
+ status = i2c_read(ci->i2c, ci->cfg.adr, 3, data, n);
return status;
}
static int write_pccard(struct cxd *ci, u16 address, u8 *data, u8 n)
{
int status;
- u8 addr[3] = { 2, address&0xff, address>>8 };
+ u8 addr[3] = {2, address & 0xff, address >> 8};
- status = i2c_write(ci->i2c, ci->adr, addr, 3);
+ status=i2c_write(ci->i2c, ci->cfg.adr, addr, 3);
if (!status) {
u8 buf[256] = {3};
memcpy(buf+1, data, n);
- status = i2c_write(ci->i2c, ci->adr, buf, n+1);
+ status = i2c_write(ci->i2c, ci->cfg.adr, buf, n+1);
}
return status;
}
@@ -162,39 +162,64 @@ static int write_pccard(struct cxd *ci, u16 address, u8
*data, u8 n)
static in
[PATCH 12/16] ngene: Support DuoFlex CT attached to CineS2 and SaTiX-S2
Support DuoFlex CT with Digital Devices CineS2 and Mystique SaTiX-S2.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index e6d5176..9f72dd8 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -401,7 +401,7 @@ static struct ngene_info ngene_info_satixS2v2 = {
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN,
NGENE_IO_TSOUT},
.demod_attach = {demod_attach_stv0900, demod_attach_stv0900,
cineS2_probe, cineS2_probe},
- .tuner_attach = {tuner_attach_stv6110, tuner_attach_stv6110,
tuner_attach_stv6110, tuner_attach_stv6110},
+ .tuner_attach = {tuner_attach_stv6110, tuner_attach_stv6110,
tuner_attach_probe, tuner_attach_probe},
.fe_config = {&fe_cineS2, &fe_cineS2, &fe_cineS2_2, &fe_cineS2_2},
.tuner_config = {&tuner_cineS2_0, &tuner_cineS2_1, &tuner_cineS2_0,
&tuner_cineS2_1},
.lnb= {0x0a, 0x08, 0x0b, 0x09},
@@ -416,7 +416,7 @@ static struct ngene_info ngene_info_cineS2v5 = {
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN,
NGENE_IO_TSOUT},
.demod_attach = {demod_attach_stv0900, demod_attach_stv0900,
cineS2_probe, cineS2_probe},
- .tuner_attach = {tuner_attach_stv6110, tuner_attach_stv6110,
tuner_attach_stv6110, tuner_attach_stv6110},
+ .tuner_attach = {tuner_attach_stv6110, tuner_attach_stv6110,
tuner_attach_probe, tuner_attach_probe},
.fe_config = {&fe_cineS2, &fe_cineS2, &fe_cineS2_2, &fe_cineS2_2},
.tuner_config = {&tuner_cineS2_0, &tuner_cineS2_1, &tuner_cineS2_0,
&tuner_cineS2_1},
.lnb= {0x0a, 0x08, 0x0b, 0x09},
--
1.7.4.1
--
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 11/16] ngene: Fix name of Digital Devices PCIe/miniPCIe
Fix name of Digital Devices PCIe/miniPCIe.
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 0d879cb..e6d5176 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -426,9 +426,9 @@ static struct ngene_info ngene_info_cineS2v5 = {
};
-static struct ngene_info ngene_info_duoFlexS2 = {
+static struct ngene_info ngene_info_duoFlex = {
.type = NGENE_SIDEWINDER,
- .name = "Digital Devices DuoFlex S2 miniPCIe",
+ .name = "Digital Devices DuoFlex PCIe or miniPCIe",
.io_type= {NGENE_IO_TSIN, NGENE_IO_TSIN, NGENE_IO_TSIN,
NGENE_IO_TSIN,
NGENE_IO_TSOUT},
.demod_attach = {cineS2_probe, cineS2_probe, cineS2_probe,
cineS2_probe},
@@ -480,8 +480,8 @@ static const struct pci_device_id ngene_id_tbl[]
__devinitdata = {
NGENE_ID(0x18c3, 0xdb01, ngene_info_satixS2),
NGENE_ID(0x18c3, 0xdb02, ngene_info_satixS2v2),
NGENE_ID(0x18c3, 0xdd00, ngene_info_cineS2v5),
- NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlexS2),
- NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlexS2),
+ NGENE_ID(0x18c3, 0xdd10, ngene_info_duoFlex),
+ NGENE_ID(0x18c3, 0xdd20, ngene_info_duoFlex),
NGENE_ID(0x1461, 0x062e, ngene_info_m780),
{0}
};
--
1.7.4.1
--
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 10/16] ngene: Fix return code if no demux was found
Fix return code if no demux was found (cineS2_probe).
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index 0d550a9..0d879cb 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -274,6 +274,7 @@ static int cineS2_probe(struct ngene_channel *chan)
demod_attach_drxk(chan, i2c);
} else {
printk(KERN_ERR "No demod found on chan %d\n", chan->number);
+ return -ENODEV;
}
return 0;
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/16] ngene: Support Digital Devices DuoFlex CT
From: Ralph Metzler
Support Digital Devices DuoFlex CT with ngene.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/Kconfig |2 +
drivers/media/dvb/ngene/ngene-cards.c | 176 ++---
drivers/media/dvb/ngene/ngene-core.c | 15 +++-
drivers/media/dvb/ngene/ngene.h |3 +
4 files changed, 156 insertions(+), 40 deletions(-)
diff --git a/drivers/media/dvb/ngene/Kconfig b/drivers/media/dvb/ngene/Kconfig
index cec242b..64c8470 100644
--- a/drivers/media/dvb/ngene/Kconfig
+++ b/drivers/media/dvb/ngene/Kconfig
@@ -5,6 +5,8 @@ config DVB_NGENE
select DVB_STV6110x if !DVB_FE_CUSTOMISE
select DVB_STV090x if !DVB_FE_CUSTOMISE
select DVB_LGDT330X if !DVB_FE_CUSTOMISE
+ select DVB_DRXK if !DVB_FE_CUSTOMISE
+ select DVB_TDA18271C2DD if !DVB_FE_CUSTOMISE
select MEDIA_TUNER_MT2131 if !MEDIA_TUNER_CUSTOMISE
---help---
Support for Micronas PCI express cards with nGene bridge.
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index fcf4be9..ca2e146 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -40,6 +40,7 @@
#include "lnbh24.h"
#include "lgdt330x.h"
#include "mt2131.h"
+#include "drxk.h"
//
@@ -83,6 +84,52 @@ static int tuner_attach_stv6110(struct ngene_channel *chan)
}
+static int drxk_gate_ctrl(struct dvb_frontend *fe, int enable)
+{
+ struct ngene_channel *chan = fe->sec_priv;
+ int status;
+
+ if (enable) {
+ down(&chan->dev->pll_mutex);
+ status = chan->gate_ctrl(fe, 1);
+ } else {
+ status = chan->gate_ctrl(fe, 0);
+ up(&chan->dev->pll_mutex);
+ }
+ return status;
+}
+
+struct dvb_frontend *tda18271c2dd_attach(struct dvb_frontend *fe,
+struct i2c_adapter *i2c, u8 adr);
+
+static int tuner_attach_tda18271(struct ngene_channel *chan)
+{
+ struct i2c_adapter *i2c;
+ struct dvb_frontend *fe;
+
+ i2c = &chan->dev->channel[0].i2c_adapter;
+ if (chan->fe->ops.i2c_gate_ctrl)
+ chan->fe->ops.i2c_gate_ctrl(chan->fe, 1);
+ fe = dvb_attach(tda18271c2dd_attach, chan->fe, i2c, 0x60);
+ if (chan->fe->ops.i2c_gate_ctrl)
+ chan->fe->ops.i2c_gate_ctrl(chan->fe, 0);
+ if (!fe) {
+ printk("No TDA18271 found!\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int tuner_attach_probe(struct ngene_channel *chan)
+{
+ if (chan->demod_type == 0)
+ return tuner_attach_stv6110(chan);
+ if (chan->demod_type == 1)
+ return tuner_attach_tda18271(chan);
+ return -EINVAL;
+}
+
static int demod_attach_stv0900(struct ngene_channel *chan)
{
struct i2c_adapter *i2c;
@@ -130,6 +177,60 @@ static void cineS2_tuner_i2c_lock(struct dvb_frontend *fe,
int lock)
up(&chan->dev->pll_mutex);
}
+static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
+{
+ struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1 }};
+ return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
+}
+
+static int i2c_read_reg16(struct i2c_adapter *adapter, u8 adr,
+ u16 reg, u8 *val)
+{
+ u8 msg[2] = {reg>>8, reg&0xff};
+ struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
+ .buf = msg, .len = 2},
+ {.addr = adr, .flags = I2C_M_RD,
+ .buf = val, .len = 1}};
+ return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
+}
+
+static int port_has_stv0900(struct i2c_adapter *i2c, int port)
+{
+ u8 val;
+ if (i2c_read_reg16(i2c, 0x68+port/2, 0xf100, &val) < 0)
+ return 0;
+ return 1;
+}
+
+static int port_has_drxk(struct i2c_adapter *i2c, int port)
+{
+ u8 val;
+
+ if (i2c_read(i2c, 0x29+port, &val) < 0)
+ return 0;
+ printk("DRXK@%02x\n", 0x29+port);
+ return 1;
+}
+
+static int demod_attach_drxk(struct ngene_channel *chan,
+struct i2c_adapter *i2c)
+{
+ struct dvb_frontend *fe;
+
+ chan->fe = fe = dvb_attach(drxk_attach,
+ i2c, 0x29 + (chan->number^2),
+ &chan->fe2);
+ if (!chan->fe) {
+ printk("No DRXK found!\n");
+ return -ENODEV;
+ }
+ fe->sec_priv = chan;
+ chan->gate_ctrl = fe->ops.i2c_gate_ctrl;
+ fe->ops.i2c_gate_ctrl = drxk_gate_ctrl;
+ return 0;
+}
+
static int cineS2_probe(struct ngene_channel *chan)
{
struct i2c_adapter *i2c;
@@ -144,43 +245,42 @@ static int cineS2_probe(s
[PATCH 09/16] ngene: Codingstyle fixes
Codingstyle fixes
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/ngene/ngene-cards.c | 36 +---
drivers/media/dvb/ngene/ngene-core.c | 14 ++--
drivers/media/dvb/ngene/ngene-dvb.c |4 +-
drivers/media/dvb/ngene/ngene.h |2 +-
4 files changed, 25 insertions(+), 31 deletions(-)
diff --git a/drivers/media/dvb/ngene/ngene-cards.c
b/drivers/media/dvb/ngene/ngene-cards.c
index ca2e146..0d550a9 100644
--- a/drivers/media/dvb/ngene/ngene-cards.c
+++ b/drivers/media/dvb/ngene/ngene-cards.c
@@ -40,6 +40,7 @@
#include "lnbh24.h"
#include "lgdt330x.h"
#include "mt2131.h"
+#include "tda18271c2dd.h"
#include "drxk.h"
@@ -99,9 +100,6 @@ static int drxk_gate_ctrl(struct dvb_frontend *fe, int
enable)
return status;
}
-struct dvb_frontend *tda18271c2dd_attach(struct dvb_frontend *fe,
-struct i2c_adapter *i2c, u8 adr);
-
static int tuner_attach_tda18271(struct ngene_channel *chan)
{
struct i2c_adapter *i2c;
@@ -114,7 +112,7 @@ static int tuner_attach_tda18271(struct ngene_channel *chan)
if (chan->fe->ops.i2c_gate_ctrl)
chan->fe->ops.i2c_gate_ctrl(chan->fe, 0);
if (!fe) {
- printk("No TDA18271 found!\n");
+ printk(KERN_ERR "No TDA18271 found!\n");
return -ENODEV;
}
@@ -180,7 +178,7 @@ static void cineS2_tuner_i2c_lock(struct dvb_frontend *fe,
int lock)
static int i2c_read(struct i2c_adapter *adapter, u8 adr, u8 *val)
{
struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1 }};
+ .buf = val, .len = 1 } };
return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
}
@@ -191,7 +189,7 @@ static int i2c_read_reg16(struct i2c_adapter *adapter, u8
adr,
struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0,
.buf = msg, .len = 2},
{.addr = adr, .flags = I2C_M_RD,
- .buf = val, .len = 1}};
+ .buf = val, .len = 1} };
return (i2c_transfer(adapter, msgs, 2) == 2) ? 0 : -1;
}
@@ -209,25 +207,22 @@ static int port_has_drxk(struct i2c_adapter *i2c, int
port)
if (i2c_read(i2c, 0x29+port, &val) < 0)
return 0;
- printk("DRXK@%02x\n", 0x29+port);
return 1;
}
static int demod_attach_drxk(struct ngene_channel *chan,
struct i2c_adapter *i2c)
{
- struct dvb_frontend *fe;
-
- chan->fe = fe = dvb_attach(drxk_attach,
+ chan->fe = dvb_attach(drxk_attach,
i2c, 0x29 + (chan->number^2),
&chan->fe2);
if (!chan->fe) {
- printk("No DRXK found!\n");
+ printk(KERN_ERR "No DRXK found!\n");
return -ENODEV;
}
- fe->sec_priv = chan;
- chan->gate_ctrl = fe->ops.i2c_gate_ctrl;
- fe->ops.i2c_gate_ctrl = drxk_gate_ctrl;
+ chan->fe->sec_priv = chan;
+ chan->gate_ctrl = chan->fe->ops.i2c_gate_ctrl;
+ chan->fe->ops.i2c_gate_ctrl = drxk_gate_ctrl;
return 0;
}
@@ -246,19 +241,18 @@ static int cineS2_probe(struct ngene_channel *chan)
i2c = &chan->dev->channel[1].i2c_adapter;
if (port_has_stv0900(i2c, chan->number)) {
- chan->demod_type=0;
+ chan->demod_type = 0;
fe_conf = chan->dev->card_info->fe_config[chan->number];
/* demod found, attach it */
rc = demod_attach_stv0900(chan);
if (rc < 0 || chan->number < 2)
return rc;
-
+
/* demod #2: reprogram outputs DPN1 & DPN2 */
i2c_msg.addr = fe_conf->address;
i2c_msg.len = 3;
buf[0] = 0xf1;
- switch (chan->number)
- {
+ switch (chan->number) {
case 2:
buf[1] = 0x5c;
buf[2] = 0xc2;
@@ -276,10 +270,10 @@ static int cineS2_probe(struct ngene_channel *chan)
return -EIO;
}
} else if (port_has_drxk(i2c, chan->number^2)) {
- chan->demod_type=1;
+ chan->demod_type = 1;
demod_attach_drxk(chan, i2c);
} else {
- printk("No demod found on chan %d\n", chan->number);
+ printk(KERN_ERR "No demod found on chan %d\n", chan->number);
}
return 0;
}
@@ -497,7 +491,7 @@ MODULE_DEVICE_TABLE(pci, ngene_id_tbl);
//
static pci_ers_result_t ngene_error_detected(struct pci_dev *dev,
- enum pci_channel_state state)
+
[PATCH 07/16] get_dvb_firmware: Get DRX-K firmware for Digital Devices DVB-CT cards
Get DRX-K firmware for Digital Devices DVB-CT cards
Signed-off-by: Oliver Endriss
---
Documentation/dvb/get_dvb_firmware | 20 +++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index 3348d31..224d9e6 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -27,7 +27,7 @@ use IO::Handle;
"or51211", "or51132_qam", "or51132_vsb", "bluebird",
"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
"af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
- "lme2510c_s7395_old");
+ "lme2510c_s7395_old", "drxk");
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -634,6 +634,24 @@ sub lme2510c_s7395_old {
$outfile;
}
+sub drxk {
+my $url = "http://l4m-daten.de/files/";;
+my $zipfile = "DDTuner.zip";
+my $hash = "f5a37b9a20a3534997997c0b1382a3e5";
+my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1);
+my $drvfile = "DDTuner.sys";
+my $fwfile = "drxk_a3.mc";
+
+checkstandard();
+
+wgetfile($zipfile, $url . $zipfile);
+verify($zipfile, $hash);
+unzip($zipfile, $tmpdir);
+extract("$tmpdir/$drvfile", 0x14dd8, 15634, "$fwfile");
+
+"$fwfile"
+}
+
# ---
# Utilities
--
1.7.4.1
--
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 06/16] DRX-K, TDA18271c2: Add build support
Add both drivers to Makefile and Kconfig. Signed-off-by: Oliver Endriss --- drivers/media/dvb/frontends/Kconfig | 21 + drivers/media/dvb/frontends/Makefile |3 +++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/frontends/Kconfig b/drivers/media/dvb/frontends/Kconfig index 44b816f..32e08e3 100644 --- a/drivers/media/dvb/frontends/Kconfig +++ b/drivers/media/dvb/frontends/Kconfig @@ -49,6 +49,27 @@ config DVB_STV6110x help A Silicon tuner that supports DVB-S and DVB-S2 modes +comment "Multistandard (cable + terrestrial) frontends" + depends on DVB_CORE + +config DVB_DRXK + tristate "Micronas DRXK based" + depends on DVB_CORE && I2C + default m if DVB_FE_CUSTOMISE + help + Micronas DRX-K DVB-C/T demodulator. + + Say Y when you want to support this frontend. + +config DVB_TDA18271C2DD + tristate "NXP TDA18271C2 silicon tuner" + depends on DVB_CORE && I2C + default m if DVB_FE_CUSTOMISE + help + NXP TDA18271 silicon tuner. + + Say Y when you want to support this tuner. + comment "DVB-S (satellite) frontends" depends on DVB_CORE diff --git a/drivers/media/dvb/frontends/Makefile b/drivers/media/dvb/frontends/Makefile index 2f3a6f7..6a6ba05 100644 --- a/drivers/media/dvb/frontends/Makefile +++ b/drivers/media/dvb/frontends/Makefile @@ -10,6 +10,7 @@ stv0900-objs = stv0900_core.o stv0900_sw.o au8522-objs = au8522_dig.o au8522_decoder.o drxd-objs = drxd_firm.o drxd_hard.o cxd2820r-objs = cxd2820r_core.o cxd2820r_c.o cxd2820r_t.o cxd2820r_t2.o +drxk-objs := drxk_hard.o obj-$(CONFIG_DVB_PLL) += dvb-pll.o obj-$(CONFIG_DVB_STV0299) += stv0299.o @@ -88,4 +89,6 @@ obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o obj-$(CONFIG_DVB_IX2505V) += ix2505v.o obj-$(CONFIG_DVB_STV0367) += stv0367.o obj-$(CONFIG_DVB_CXD2820R) += cxd2820r.o +obj-$(CONFIG_DVB_DRXK) += drxk.o +obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/16] tda18271c2dd: Initial check-in
From: Ralph Metzler
Driver for the NXP TDA18271c2 silicon tuner.
Signed-off-by: Ralph Metzler
Signed-off-by: Oliver Endriss
---
drivers/media/dvb/frontends/tda18271c2dd.c | 1063 +++
drivers/media/dvb/frontends/tda18271c2dd.h |5 +
drivers/media/dvb/frontends/tda18271c2dd_maps.h | 810 +
3 files changed, 1878 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/tda18271c2dd.c
create mode 100644 drivers/media/dvb/frontends/tda18271c2dd.h
create mode 100644 drivers/media/dvb/frontends/tda18271c2dd_maps.h
diff --git a/drivers/media/dvb/frontends/tda18271c2dd.c
b/drivers/media/dvb/frontends/tda18271c2dd.c
new file mode 100644
index 000..b4a23bf
--- /dev/null
+++ b/drivers/media/dvb/frontends/tda18271c2dd.c
@@ -0,0 +1,1063 @@
+/*
+ * tda18271c2dd: Driver for the TDA18271C2 tuner
+ *
+ * Copyright (C) 2010 Digital Devices GmbH
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 only, as published by the Free Software Foundation.
+ *
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA
+ * Or, point your browser to http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "dvb_frontend.h"
+
+struct SStandardParam {
+ s32 m_IFFrequency;
+ u32 m_BandWidth;
+ u8m_EP3_4_0;
+ u8m_EB22;
+};
+
+struct SMap {
+ u32 m_Frequency;
+ u8m_Param;
+};
+
+struct SMapI {
+ u32 m_Frequency;
+ s32m_Param;
+};
+
+struct SMap2 {
+ u32 m_Frequency;
+ u8m_Param1;
+ u8m_Param2;
+};
+
+struct SRFBandMap {
+ u32 m_RF_max;
+ u32 m_RF1_Default;
+ u32 m_RF2_Default;
+ u32 m_RF3_Default;
+};
+
+enum ERegister
+{
+ ID = 0,
+ TM,
+ PL,
+ EP1, EP2, EP3, EP4, EP5,
+ CPD, CD1, CD2, CD3,
+ MPD, MD1, MD2, MD3,
+ EB1, EB2, EB3, EB4, EB5, EB6, EB7, EB8, EB9, EB10,
+ EB11, EB12, EB13, EB14, EB15, EB16, EB17, EB18, EB19, EB20,
+ EB21, EB22, EB23,
+ NUM_REGS
+};
+
+struct tda_state {
+ struct i2c_adapter *i2c;
+ u8 adr;
+
+ u32 m_Frequency;
+ u32 IF;
+
+ u8m_IFLevelAnalog;
+ u8m_IFLevelDigital;
+ u8m_IFLevelDVBC;
+ u8m_IFLevelDVBT;
+
+ u8m_EP4;
+ u8m_EP3_Standby;
+
+ bool m_bMaster;
+
+ s32 m_SettlingTime;
+
+ u8m_Regs[NUM_REGS];
+
+ /* Tracking filter settings for band 0..6 */
+ u32 m_RF1[7];
+ s32 m_RF_A1[7];
+ s32 m_RF_B1[7];
+ u32 m_RF2[7];
+ s32 m_RF_A2[7];
+ s32 m_RF_B2[7];
+ u32 m_RF3[7];
+
+ u8m_TMValue_RFCal;/* Calibration temperatur */
+
+ bool m_bFMInput; /* true to use Pin 8 for FM Radio */
+
+};
+
+static int PowerScan(struct tda_state *state,
+u8 RFBand,u32 RF_in,
+u32 * pRF_Out, bool *pbcal);
+
+static int i2c_readn(struct i2c_adapter *adapter, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msgs[1] = {{.addr = adr, .flags = I2C_M_RD,
+ .buf = data, .len = len}};
+ return (i2c_transfer(adapter, msgs, 1) == 1) ? 0 : -1;
+}
+
+static int i2c_write(struct i2c_adapter *adap, u8 adr, u8 *data, int len)
+{
+ struct i2c_msg msg = {.addr = adr, .flags = 0,
+ .buf = data, .len = len};
+
+ if (i2c_transfer(adap, &msg, 1) != 1) {
+ printk("i2c_write error\n");
+ return -1;
+ }
+ return 0;
+}
+
+static int WriteRegs(struct tda_state *state,
+u8 SubAddr, u8 *Regs, u16 nRegs)
+{
+ u8 data[nRegs+1];
+
+ data[0] = SubAddr;
+ memcpy(data + 1, Regs, nRegs);
+ return i2c_write(state->i2c, state->adr, data, nRegs+1);
+}
+
+static int WriteReg(struct tda_state *state, u8 SubAddr,u8 Reg)
+{
+ u8 msg[2] = {SubAddr, Reg};
+
+ return i2c_write(state->i2c, state->adr, msg, 2);
+}
+
+static int Read(struct tda_state *state, u8 * Regs)
+{
+ return i2c_readn(state->i2c, state->adr, Regs, 16);
+}
+
+static int ReadExtented(struct tda_state *state, u8 * Regs)
+{
+ return i2c_readn(state->i2c, state->adr, Regs, NUM_REGS);
+}
+
+static int UpdateRegs(struct tda_state *state, u8 RegFrom,u8 RegTo)
+{
+ return WriteRegs(state, RegFrom,
+
[PATCH v4 2/2] USB: EHCI: Allow users to override 80% max periodic bandwidth
There are cases, when 80% max isochronous bandwidth is too limiting. For example I have two USB video capture cards which stream uncompressed video, and to stream full NTSC + PAL videos we'd need NTSC 640x480 YUV422 @30fps ~17.6 MB/s PAL 720x576 YUV422 @25fps ~19.7 MB/s isoc bandwidth. Now, due to limited alt settings in capture devices NTSC one ends up streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both with interval=1. In terms of microframe time allocation this gives NTSC~53us PAL ~57us and together ~110us > 100us == 80% of 125us uframe time. So those two devices can't work together simultaneously because the'd over allocate isochronous bandwidth. 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and both devices started to work together, so I though sometimes it would be a good idea for users to override hardcoded default of max 80% isoc bandwidth. After all, isn't it a user who should decide how to load the bus? If I can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB newcomer, but that 80% set in stone by USB 2.0 specification seems to be chosen pretty arbitrary to me, just to serve as a reasonable default. NOTE 1 ~~ for two streams with max_pkt_size=3072 (worst case) both time allocation would be 60us+60us=120us which is 96% periodic bandwidth leaving 4% for bulk and control. Alan Stern suggested that bulk then would be problematic (less than 300*8 bittimes left per microframe), but I think that is still enough for control traffic. NOTE 2 ~~ Sarah Sharp expressed concern that maxing out periodic bandwidth could lead to vendor-specific hardware bugs on host controllers, because > It's entirely possible that you'll run into > vendor-specific bugs if you try to pack the schedule with isochronous > transfers. I don't think any hardware designer would seriously test or > validate their hardware with a schedule that is basically a violation of > the USB bus spec (more than 80% for periodic transfers). So far I've only tested this patch on my HP Mini 5103 with N10 chipset kirr@mini:~$ lspci 00:00.0 Host bridge: Intel Corporation N10 Family DMI Bridge 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation N10 Family Integrated Graphics Controller 00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 1 (rev 02) 00:1c.3 PCI bridge: Intel Corporation N10/ICH 7 Family PCI Express Port 4 (rev 02) 00:1d.0 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation N10/ICH 7 Family USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation N10/ICH 7 Family USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation NM10 Family LPC Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation N10/ICH7 Family SATA AHCI Controller (rev 02) 01:00.0 Network controller: Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller (rev 01) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8059 PCI-E Gigabit Ethernet Controller (rev 11) and the system works stable with 110us/uframe (~88%) isoc bandwith allocated for above-mentioned isochronous transfers. NOTE 3 ~~ This feature is off by default. I mean max periodic bandwidth is set to 100us/uframe by default exactly as it was before the patch. So only those of us who need the extreme settings are taking the risk - normal users who do not alter uframe_periodic_max sysfs attribute should not see any change at all. NOTE 4 ~~ I've tried to update documentation in Documentation/ABI/ thoroughly, but only "TBD" was put into Documentation/usb/ehci.txt -- the text there seems to be outdated and much needing refreshing, before it could be amended. Cc: Sarah Sharp Signed-off-by: Kirill Smelkov Acked-by: Alan Stern --- Documentation/ABI/testing/sysfs-module | 23 +++ Documentation/usb/ehci.txt |2 + drivers/usb/host/ehci-hcd.c|6 ++ drivers/usb/host/ehci-sched.c | 17 ++--- drivers/usb/host/ehci-sysfs.c | 104 ++- drivers/usb/host/ehci.h|2 + 6 files changed, 140 insertions(+), 14 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index cfcec3b..9489ea8 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@
[PATCH v4 1/2] USB: EHCI: Move sysfs related bits into ehci-sysfs.c
The only sysfs attr implemented so far is "companion" from ehci-hub.c,
but in the next patch we are going to add another sysfs file, so prior
to that let's structure things and move already-in-there sysfs code to
separate file.
NOTE: All the code I'm moving into this new file was written by Alan
Stern (in 57e06c11 "EHCI: force high-speed devices to run at full
speed"; Jan 16 2007), that's why I'm putting
Copyright (C) 2007 by Alan Stern
there after explicit request from the author.
Signed-off-by: Kirill Smelkov
Acked-by: Alan Stern
---
drivers/usb/host/ehci-hcd.c |5 +-
drivers/usb/host/ehci-hub.c | 75
drivers/usb/host/ehci-sysfs.c | 94 +
3 files changed, 97 insertions(+), 77 deletions(-)
create mode 100644 drivers/usb/host/ehci-sysfs.c
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index e18862c..8306155 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -336,6 +336,7 @@ static void ehci_work(struct ehci_hcd *ehci);
#include "ehci-mem.c"
#include "ehci-q.c"
#include "ehci-sched.c"
+#include "ehci-sysfs.c"
/*-*/
@@ -520,7 +521,7 @@ static void ehci_stop (struct usb_hcd *hcd)
ehci_reset (ehci);
spin_unlock_irq(&ehci->lock);
- remove_companion_file(ehci);
+ remove_sysfs_files(ehci);
remove_debug_files (ehci);
/* root hub is shut down separately (first, when possible) */
@@ -754,7 +755,7 @@ static int ehci_run (struct usb_hcd *hcd)
* since the class device isn't created that early.
*/
create_debug_files(ehci);
- create_companion_file(ehci);
+ create_sysfs_files(ehci);
return 0;
}
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index ea6184b..d9e8d71 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -471,29 +471,6 @@ static int ehci_bus_resume (struct usb_hcd *hcd)
/*-*/
-/* Display the ports dedicated to the companion controller */
-static ssize_t show_companion(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- struct ehci_hcd *ehci;
- int nports, index, n;
- int count = PAGE_SIZE;
- char*ptr = buf;
-
- ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
- nports = HCS_N_PORTS(ehci->hcs_params);
-
- for (index = 0; index < nports; ++index) {
- if (test_bit(index, &ehci->companion_ports)) {
- n = scnprintf(ptr, count, "%d\n", index + 1);
- ptr += n;
- count -= n;
- }
- }
- return ptr - buf;
-}
-
/*
* Sets the owner of a port
*/
@@ -528,58 +505,6 @@ static void set_owner(struct ehci_hcd *ehci, int portnum,
int new_owner)
}
}
-/*
- * Dedicate or undedicate a port to the companion controller.
- * Syntax is "[-]portnum", where a leading '-' sign means
- * return control of the port to the EHCI controller.
- */
-static ssize_t store_companion(struct device *dev,
- struct device_attribute *attr,
- const char *buf, size_t count)
-{
- struct ehci_hcd *ehci;
- int portnum, new_owner;
-
- ehci = hcd_to_ehci(bus_to_hcd(dev_get_drvdata(dev)));
- new_owner = PORT_OWNER; /* Owned by companion */
- if (sscanf(buf, "%d", &portnum) != 1)
- return -EINVAL;
- if (portnum < 0) {
- portnum = - portnum;
- new_owner = 0; /* Owned by EHCI */
- }
- if (portnum <= 0 || portnum > HCS_N_PORTS(ehci->hcs_params))
- return -ENOENT;
- portnum--;
- if (new_owner)
- set_bit(portnum, &ehci->companion_ports);
- else
- clear_bit(portnum, &ehci->companion_ports);
- set_owner(ehci, portnum, new_owner);
- return count;
-}
-static DEVICE_ATTR(companion, 0644, show_companion, store_companion);
-
-static inline int create_companion_file(struct ehci_hcd *ehci)
-{
- int i = 0;
-
- /* with integrated TT there is no companion! */
- if (!ehci_is_TDI(ehci))
- i = device_create_file(ehci_to_hcd(ehci)->self.controller,
- &dev_attr_companion);
- return i;
-}
-
-static inline void remove_companion_file(struct ehci_hcd *ehci)
-{
- /* with integrated TT there is no companion! */
- if (!ehci_is_TDI(ehci))
- device_remove_file(ehci_to_hcd(ehci)->self.controller,
- &dev_attr_companion);
-}
-
-
/*--
[PATCH v4 0/2] USB: EHCI: Allow users to override 80% max periodic bandwidth
There are cases, when 80% max isochronous bandwidth is too limiting. Let's allow knowledgeable users to override that 80% max limit explicitly for extreme cases, like 2 high bandwidth isochronously streaming devices on the same High Speed USB bus in order to make them work simultaneously. See full details in PATCH 2/2. Changes since v3: - as suggested by Greg KH added new entry to Documentation/ABI/; - for consistency also touched Documentation/usb/ehci.txt reminding we now have new setting for periodic transfers scheduler. The base text in-there requires much updating regarding isochronous transfers, so only "TBD" with brief description was put because I'm not the best person to get EHCI description into shape; - added ACK to PATCH 2/2 from Alan Stern based on previous feedback. (I hope it's still semi-ok to put it, inspite of adding new not-reviewed text into docs); - minor cosmetics in patch descriptions. Changes since v2: - changed the copyright in ehci-sysfs from David Brownell to Alan Stern; - added ACK to PATCH 1/2 from Alan Stern; - inspired by concerns raised by Sarah Sharp, added more details about testing done on N10 chipset, system stability, and that no-harm-is-done for those, who do not change uframe_periodic_max from default 100us; - when decreasing uframe_periodic_max, compare with the maximum number of microseconds already allocated for any uframe, instead of stopping as soon as it finds something above the new limit. Changes since v1: - dropped RFC status as "this seems like the sort of feature somebody might reasonably want to use -- if they know exactly what they're doing"; - new preparatory patch (1/2) which moves already-in-there sysfs code into ehci-sysfs.c; - moved uframe_periodic_max parameter from module option to sysfs attribute, so that it can be set per controller and at runtime, added validity checks; - clarified a bit bandwidth analysis for 96% max periodic setup as noticed by Alan Stern; - clarified patch description saying that set in stone 80% max periodic is specified by USB 2.0; Kirill Smelkov (2): USB: EHCI: Move sysfs related bits into ehci-sysfs.c USB: EHCI: Allow users to override 80% max periodic bandwidth Documentation/ABI/testing/sysfs-module | 23 Documentation/usb/ehci.txt |2 + drivers/usb/host/ehci-hcd.c| 11 ++- drivers/usb/host/ehci-hub.c| 75 - drivers/usb/host/ehci-sched.c | 17 +-- drivers/usb/host/ehci-sysfs.c | 190 drivers/usb/host/ehci.h|2 + 7 files changed, 233 insertions(+), 87 deletions(-) create mode 100644 drivers/usb/host/ehci-sysfs.c -- 1.7.6.rc3 -- 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 00/16] New drivers: DRX-K, TDA18271c2, Updates: CXD2099 and ngene
[PATCH 01/16] tda18271c2dd: Initial check-in [PATCH 02/16] tda18271c2dd: Lots of coding-style fixes [PATCH 03/16] DRX-K: Initial check-in [PATCH 04/16] DRX-K: Shrink size of drxk_map.h [PATCH 05/16] DRX-K: Tons of coding-style fixes [PATCH 06/16] DRX-K, TDA18271c2: Add build support [PATCH 07/16] get_dvb_firmware: Get DRX-K firmware for Digital Devices DVB-CT cards [PATCH 08/16] ngene: Support Digital Devices DuoFlex CT [PATCH 09/16] ngene: Coding style fixes [PATCH 10/16] ngene: Fix return code if no demux was found [PATCH 11/16] ngene: Fix name of Digital Devices PCIe/miniPCIe [PATCH 12/16] ngene: Support DuoFlex CT attached to CineS2 and SaTiX-S2 [PATCH 13/16] cxd2099: Update to latest version [PATCH 14/16] cxd2099: Codingstyle fixes [PATCH 15/16] ngene: Update for latest cxd2099 [PATCH 16/16] ngene: Strip dummy packets inserted by the driver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] media/at91sam9x5-video: new driver for the high end overlay on at91sam9x5
Hello Uwe,
On 07/02/2011 10:09 PM, Uwe Kleine-König wrote:
> Hello Sylwester,
>
> thanks for your feedback. A few comments below. For the statements I
> don't reply to, you can consider a "OK, will be fixed in v2".
>
> On Fri, Jul 01, 2011 at 11:20:32PM +0200, Sylwester Nawrocki wrote:
>> On 06/29/2011 09:58 PM, Uwe Kleine-König wrote:
>>> + if (handled& heoimr)
>>> + return IRQ_HANDLED;
>>> + else
>>
>> else could be omitted
> I like the else, but don't care much.
sure, it was purely a personal preference.
>>> + if (rect->left< 0)
>>> + hwxpos = 0;
>>> + else
>>> + hwxpos = rect->left;
>>
>> Could be rewritten as:
>>
>> hwxpos = rect->left< 0 ? 0 : rect->left;
> could even be rewritten as
>
> hwxpos = max(rect->left, 0);
ok, I give up, couldn't make it any simpler;)
>
>>> +static void at91sam9x5_video_vb_wait_prepare(struct vb2_queue *q)
>>> +{
>>> + struct at91sam9x5_video_priv *priv =
>>> + container_of(q, struct at91sam9x5_video_priv, queue);
>>> + unsigned long flags;
>>> +
>>> + debug("cfgupdate=%d hwstate=%d cfgstate=%d\n",
>>> + priv->cfgupdate, priv->hwstate, priv->cfgstate);
>>> + debug("bufs=%p,%p\n", priv->cur.vb, priv->next.vb);
>>> + spin_lock_irqsave(&priv->lock, flags);
>>> +
>>> + at91sam9x5_video_handle_irqstat(priv);
>>> +
>>> + at91sam9x5_video_write32(priv, REG_HEOIER,
>>> + REG_HEOIxR_ADD | REG_HEOIxR_DMA |
>>> + REG_HEOIxR_UADD | REG_HEOIxR_UDMA |
>>> + REG_HEOIxR_VADD | REG_HEOIxR_VDMA);
>>
>> What the above two calls are intended to be doing ?
>
> handle_irqstat handles the eventual pending irqs. The second call
> enables irqs for "frame done" (..._DMA) and "new descriptor loaded"
> (..._ADD).
OK, so it looks to me like irqs are unmasked in wait_prepare and masked
back in wait_finish. I would try to move this logic to start_streaming and
the interrupt handler.
It seems this way too much dependant on when wait_prepare/wait_finish are
called by videobuf2. AFAIK those callbacks are not called in non-blocking
mode.
>
>>> +const struct vb2_ops at91sam9x5_video_vb_ops = {
>>> + .queue_setup = at91sam9x5_video_vb_queue_setup,
>>> +
>>> + .wait_prepare = at91sam9x5_video_vb_wait_prepare,
>>> + .wait_finish = at91sam9x5_video_vb_wait_finish,
>>
>> These 2 functions are intended to unlock and lock respectively the mutex
>> that is used to serialize ioctl handlers, in particular DQBUF.
>> I'm not sure if you're doing the right thing in
>> at91sam9x5_video_vb_wait_prepare/at91sam9x5_video_vb_wait_finish.
> I'm not taking a mutex for sure.
All right, so this needs to be changed. If you decide to add a file
operations mutex and protect each file operation individually in the driver,
rather than assigning a pointer to such mutex to struct video_device::lock
and let the core serialize file ops, then wait_prepare/wait_finish
could be omitted.
>
>>> +
>>> + .buf_prepare = at91sam9x5_video_vb_buf_prepare,
>>> + .buf_queue = at91sam9x5_video_vb_buf_queue,
>>> +};
Also if your driver is supposed to support write() method,
vidioc_streamon/vidioc_streamoff should be just a pass-through for
vb2_streamon/vb2_streamoff and the hardware control should happen in
start_streaming, stop_streaming callbacks.
I can't see a stop_streaming callback in your vb2 operations set.
It's been made mandatory recently, thus it would be good to add it.
>>> +
>>> +static int at91sam9x5_video_vidioc_querycap(struct file *filp,
>>> + void *fh, struct v4l2_capability *cap)
>>> +{
>>> + strcpy(cap->driver, DRIVER_NAME);
I would go for a strlcpy here, better to be safe than sorry. ;-)
>>> + cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING |
>>> + V4L2_CAP_VIDEO_OVERLAY;
>>> +
>>> + /* XXX */
>>> + cap->version = 0;
>>
>> There is no need to set this field any more. It will be overwritten
>> with kernel versions in __video_do_ioctl(). See this for more details:
>> http://git.linuxtv.org/media_tree.git?a=commit;h=33436a81b0d4d1036ffcf0edb7e3bfa65d18ad08
> I saw the discussion on the ML, but missed that it was already
> committed.
>
>>> + cap->card[0] = '\0';
>>> + cap->bus_info[0] = '\0';
> I assume I need to fill these with more sensible values?
I think bus_info is not very useful for this driver and can be left as is.
As for cap->card, I'm not sure. Some drivers just just fill it in with
a video node name (/dev/video*), some are more creative.
Here is what the V4L2 specifications says:
http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-querycap.html
--
Regards,
Sylwester
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Xawtv version 3.101 released
Today, we're releasing the version 3.101 of xawtv, with the following fixes: * Man fix to remove mention of v4l1, and describe libv4l instead * Fixes at fr/es manuals * Warning fixes * Addition of alsa streaming at xawtv: now, for devices with video associated with audio inputs. * Use X11 editres, instead of its on version, based on a port from a motif library released under a licence that is not GPL compatible * Add auto-detection logic for xawtv: by default, it will now seek for the first TV device. If not available, fall back to the first grabber device. * Add auto-detection logic for scanv: by default, it will now seek for the first TV device. If not available, fails. * Add optional support for libexplain at the v4l2/libv4l driver. Libexplain provides a more complete explanation for the error codes, helping developers to better track what's happened. * Don't expose tuner commands, on devices that are grabber or webcams at xawtv. Dmitry Butskoy fixed the manuals and some warnings. Asterios Dramis pointed to a trouble with a file imported from Motif, used on "motv" with a non-GPL license. The code were replaced to use a X11 library instead. Hans de Goede fixed the alsa stream code, added the auto-detection mode and fixing more warnings. The tarball is available at: http://linuxtv.org/downloads/xawtv/xawtv-3.101.tar.bz2 Enjoy! Mauro -- 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: Fwd: 0bda:2838 Ezcap DVB USB adaptor - no device files created / RTL2831U/RTL2832U
Joel Stanley wrote, on 03/07/11 12:17: Hello Jan, On Sun, Jul 3, 2011 at 05:53, Jan Hoogenraad wrote: I have decided AGAINST making it runnable on newer kernels, as there are some people working right now on a new release. I appreciate that you would prefer efforts to go towards a upstream driver. In the mean time I've updated the git tree[1] on my website. There were no real changes required; just a re-build with an updated dvb-usb.h and dvb_frontend.h from the kernel tree. Checkout the linux-3 branch. Thanks, I rebuilt this against the linux-3 branch and now see the device tree: # ls -alR /dev/dvb /dev/dvb: total 0 drwxr-xr-x 4 root root 80 Jul 3 13:33 . drwxr-xr-x 15 root root 3140 Jul 3 13:33 .. drwxr-xr-x 2 root root 120 Jul 3 13:33 adapter0 drwxr-xr-x 2 root root 120 Jul 3 13:33 adapter1 /dev/dvb/adapter0: total 0 drwxr-xr-x 2 root root 120 Jul 3 13:33 . drwxr-xr-x 4 root root 80 Jul 3 13:33 .. crw-rw+ 1 root video 212, 0 Jul 3 13:33 demux0 crw-rw+ 1 root video 212, 1 Jul 3 13:33 dvr0 crw-rw+ 1 root video 212, 3 Jul 3 13:33 frontend0 crw-rw+ 1 root video 212, 2 Jul 3 13:33 net0 /dev/dvb/adapter1: total 0 drwxr-xr-x 2 root root 120 Jul 3 13:33 . drwxr-xr-x 4 root root 80 Jul 3 13:33 .. crw-rw+ 1 root video 212, 4 Jul 3 13:33 demux0 crw-rw+ 1 root video 212, 5 Jul 3 13:33 dvr0 crw-rw+ 1 root video 212, 7 Jul 3 13:33 frontend0 crw-rw+ 1 root video 212, 6 Jul 3 13:33 net0 but haven't had time to test it further yet. I'd be interested to hear more about the new release. Arthur. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.1] gspca for_v3.1
The following changes since commit df6aabbeb2b8799d97f3886fc994c318bc6a6843: [media] v4l2-ctrls.c: add support for V4L2_EVENT_SUB_FL_ALLOW_FEEDBACK (2011-07-01 20:54:51 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.1 Frank Schaefer (1): gspca - sn9c20x: device 0c45:62b3: fix status LED Jean-François Moine (3): gspca - ov519: Fix sensor detection problems gspca - ov519: Fix a LED inversion gspca - jeilinj: Cleanup code Wolfram Sang (1): gspca - zc3xx: add usb_id for HP Premium Starter Cam Documentation/video4linux/gspca.txt |1 + drivers/media/video/gspca/jeilinj.c | 10 ++ drivers/media/video/gspca/ov519.c |6 +- drivers/media/video/gspca/sn9c20x.c |2 +- drivers/media/video/gspca/zc3xx.c |1 + 5 files changed, 10 insertions(+), 10 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 3.0] gspca for_v3.0
The following changes since commit 215c52702775556f4caf5872cc84fa8810e6fc7d: [media] V4L/videobuf2-memops: use pr_debug for debug messages (2011-06-01 18:20:34 -0300) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_v3.0 Jean-François Moine (2): gspca - ov519: Fix sensor detection problems gspca - ov519: Fix a LED inversion drivers/media/video/gspca/ov519.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] viacam: Don't explode if pci_find_bus() returns NULL
In the unlikely case that pci_find_bus() should return NULL viacam_serial_is_enabled() is going to dereference a NULL pointer and blow up. Better safe than sorry, so be defensive and check the pointer. Signed-off-by: Jesper Juhl --- drivers/media/video/via-camera.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Compile tested only. I don't have the hardware. diff --git a/drivers/media/video/via-camera.c b/drivers/media/video/via-camera.c index 85d3048..bb7f17f 100644 --- a/drivers/media/video/via-camera.c +++ b/drivers/media/video/via-camera.c @@ -1332,6 +1332,8 @@ static __devinit bool viacam_serial_is_enabled(void) struct pci_bus *pbus = pci_find_bus(0, 0); u8 cbyte; + if (!pbus) + return false; pci_bus_read_config_byte(pbus, VIACAM_SERIAL_DEVFN, VIACAM_SERIAL_CREG, &cbyte); if ((cbyte & VIACAM_SERIAL_BIT) == 0) -- 1.7.6 -- Jesper Juhlhttp://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. -- 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
