date:20091207

Patrick Boettcher wrote:
 Hi Mauro,
 
 On Sat, 5 Dec 2009, Mauro Carvalho Chehab wrote:
 
 Patrick Boettcher wrote:
 Hi Mauro,

 please pull from

 http://linuxtv.org/hg/~pb/v4l-dvb/

 for the following changeset:

 DiB8090: Add the DiB0090 tuner driver and STK8096GP-board

 This is the adding support for the DiB809x-device you were asking 2
 weeks ago. If possible, please include it into the patches which will go
 for 2.6.33 .

 This repo also includes the changesets which were in my previous pull
 request.

 Hi Patrick,

 In the last patch, checkpatch.pl returned:

 total: 134 errors, 220 warnings, 3291 lines checked

 Would it be possible to correct the CodingStyle errors on it? There
 are lots of
 comments that aren't following C99 specs. Also, some code is indented
 with 4 spaces,
 instead of tabs, making really hard to read the code, among several
 other codingstyle
 violations.
 
 I committed and pushed the patch from Olivier which fixes most of the
 Codingstyle violations (all of them except 80 char/line).

Thanks.

 I didn't see them in the first place, because it seems the 'make commit'
 does not use a built-in checkpatch.pl if it does not find one in
 /usr/src . This is a new (maybe buggy) behaviour.

Weird. I'll try to fix this issue when I have some time.

 Still, if you take a look at dib0090.c you will find it odd. Why?
 Because as usual the DiBcom drivers are generated from internal source
 code by a script. This is done to keep in sync drivers in development
 and Linux easier. If someone has a problem with the dib-drivers he
 should contact DiBcom rather than trying to hack his solution
 (especially when it's about performance or other reception related
 problem) into the driver.

It seems that the script has some troubles with big lines. There are several
big lines that got a really weird format.

 I'm sorry that the drivers delivered like that are ugly from the
 artistic point-of-view, but that's the only way I have today to deliver
 drivers at all.
 
 Please pull now from
 
 http://linuxtv.org/hg/~pb/v4l-dvb/

Done. Thanks!

Cheers,
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: Success for Compro E650F analog television and alsa sound.

2009-12-07 Thread Igor M. liplianin

2009/12/7 Samuel Rakitnican samuel.rakitni...@gmail.com:
 On Mon, 07 Dec 2009 03:00:03 +0100, Igor M. Liplianin liplia...@me.by
 wrote:

 I'm able to watch now analog television with Compro E650F.

 That's great news for somebody :)

 Is remote working for this card? My card (T750F) and this card share the
 same remote, so I thought maybe keymap may be shared too. I started
 working on it several months ago but I didn't finished the keys
 associations due to that my card is not supported at all.
        http://www.spinics.net/lists/linux-media/msg07705.html

Currently Andy makes IR support for PCI-e cx23885 chip (like in
E650F), but I can test remote on some PCI cx23883 card or even saa7134
(I have one).
Why not to take your table as basic for them all?


 Regards,
 Samuel
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov wrote:
 On Sun, Dec 06, 2009 at 09:03:31AM -0200, Mauro Carvalho Chehab wrote:
 Dmitry Torokhov wrote:
 On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
 Em Fri, 4 Dec 2009 02:06:42 -0800
 Dmitry Torokhov dmitry.torok...@gmail.com escreveu:

 evdev does not really care what you use as scancode. So nobody stops
 your driver to report index as a scancode and accept index from the
 ioctl. The true scancode will thus be competely hidden from userspace.
 In fact a few drivers do just that.
 Let me better express here. It is all about how we'll expand the limits of 
 those
 ioctls to fulfill the needs.

 The point is that we'll have, let's say something like to 50-500 
 scancode/keycode tuples
 sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure 
 if is there any
 IR protocol/code with a bigger scancode).

 On such universe if we want to get all keycodes with the current ioctls 
 for a scancode in
 the range of 32 bits, we need to do something like:

 u32 code;
 int codes[2];
 for (code = 0; code = (unsigned u32) - 1; code++) {
codes[0] = (int)code;
if (!ioctl(fd, EVIOCGKEYCODE, codes))
printf(scancode 0x%08x = keycode 0x%08x\n, codes[0], 
 codes[1]);
 }

 So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE 
 ioctl to
 read the complete scancode space, to get those 50-500 useful codes.

 Right, currently there is no need to query all scancodes defined by
 device. Quite often drivers don't even know what scancodes device
 actually generates (ex AT keyboard).

 Could you describe in more detail how you are using this data?
 It is useful if you want to dump the keycode maps into file with the current
 scancode attribution, in order to modify some keystrokes.

 Right now, programs like dumpkeys (from kbd package) allow you to dump for 
 example
 the attribution keys from your keyboard.

 In the case of IR's this functionality is very important.

 For example, you may need to replace the scancode/KEY_CHANNELUP tuple by 
 scancode/KEY_UP,
 in order to make your IR to work with some applications that don't recognize 
 the IR
 specific keycodes.

 In practice, with such applications, you'll need to replace several 
 different scancodes.

 So, you may end by having different scancodes producing the same keycode, as 
 such applications
 aren't capable of differentiating an UP key from a CHANNELUP key. This is 
 the case, for example
 of the popular tvtime application.

 The better way is to just generate a dump file, modify the needed entries 
 and reload the
 table by calling EVIOSKEYCODE, in order to use the new table.

 I wrote a small application that just do the above, and I use to load some 
 special tables
 to work with some applications like tvtime and mplayer. (with mplayer, you 
 need to map 
 channel down as KEY_H and channel up as KEY_K).

 I hope that, after we finish addressing IR's, we'll finally have media 
 applications handling
 directly the proper keycodes, but people may still need to write different 
 keycodes to do
 other things. I used to have a keymap file in order to use an IR to control 
 the slide show
 with openoffice.

 Due to the current API limit, we don't have any way to use the full 64bits 
 space for scancodes.

 Can we probably reduce the scancode space? ARe all 64 bits in
 protocols used to represent keypresses or some are used for some kind of
 addressing?
 All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for 
 NEC extended protocol).
 However, currently, the drivers were getting only 7 bits, due to the old way 
 to implement
 EVIO[S|G]KEYCODE. 

 I know, however, one i2c chip that returns a 5 byte scancode when you press 
 a key. 
 We're currently just discarding the remaining bits, so I'm not really sure 
 what's there.


 The usage of 7 bits, in practice, were meaning that it weren't possible to 
 use
 a different remote than the one provided by the device manufacturer, as the 
 scancodes produced
 by other remotes differ on more than 7 bits. Also, this means that, if your 
 TV and your PC
 are using the same protocol, like RC5, if you press a button on your TV 
 remote, the PC will
 also get it.

 I know, however, one IR driver that produces 6 bytes when you press a key. 
 We're currently just discarding the remaining bits, so I'm not really sure
 what else is there. Some badly optimized protocol? a bigger scancode? a 
 protocol indication?

 In general, the scancode contains 8 or 16 bits for address, and 8 bits for 
 command.

 However, the scancode table needs to handle the address as well, since we 
 don't want that a
 scancode meant to go to your TV to be handled by the PC, but we may want to 
 get codes from
 different addresses there, as we may need to use the address to 
 differentiate the commands
 meant to control the TV volume, for example, than the same command meant to 
 control the PC
 master volume.
 
 Right, but this data is not interesting to

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 12:48 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? 

That's fine for me.

 In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.

This may occur in parallel, but, as we've been discussing, there are
still some needs there that will require kernel-user interfaces.

 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.

There are some tasks there that are independent of any API design.

For example, I'm currently doing some cleanups and improvements 
at the existing IR in-kernel code to create a common IR core that replaces
the already existing feature of handling 7-bits scancode/keycode table to
use the complete scancodes found at the current in-kernel drivers.

This approach works for the current drivers, as none of them currently support
any protocol that requires more than 16 bits for scancodes. However, the
current EVIOGKEYCODE implementation won't scale with bigger scancode spaces.

This code is written to be generic enough to be used by V4L, DVB and LIRC
drivers. So, after having this work done, it should be easy to connect the 
lirc_dev
to a decoder and to this core support. There are already some in-kernel decoders
that can be used for some protocols, but the better is to review the decoders in
the light of lirc. I expect that the lirc decoders will be in a better shape.

While I'm here, I intend also to create the sysfs bits to create 
sys/class/irrcv,
as already discussed and submit the patch here for discussions.

Of course, after writing different API's to control the IR tables, we'll
need to improve it, but this depends on the results of the architecture 
discussions.

Cheers,
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: Success for Compro E650F analog television and alsa sound.

2009-12-07 Thread Steven Toth

On Sun, Dec 6, 2009 at 9:00 PM, Igor M. Liplianin liplia...@me.by wrote:
 Hi Steve

 I'm able to watch now analog television with Compro E650F.
 I rich this by merging your cx23885-alsa tree and adding some modifications
 for Compro card definition.
 Actually, I take it from Mygica definition, only tuner type and DVB port is 
 different.
 Tested with Tvtime.

 tvtime | arecord -D hw:2,0 -r 32000 -c 2 -f S16_LE | aplay -

 My tv card is third for alsa, so parameter -D for arecord is hw:2,0.
 SECAM works well also.
 I didn't test component input, though it present in my card.

Thanks Igor, I'll merge this into the cx23885-alsa tree in the next
couple of days.

Regards,

-- 
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:
  
  Scancodes in input system never been real scancodes. Even if you look
  into atkbd it uses some synthetic data composed out of real scancodes
  sent to the keyboard, and noone cares. If you are unsatisfied with
  mapping you fire up evtest, press the key, take whatever the driver
  [mis]represents as a scancode and use it to load the new definition. And
  you don't care at all whether the thing that driver calls cancode makes
  any sense to the hardware device.
 
 We used a mis-represented scancode, but this proofed to be a broken design
 along the time.
 
 For users, whatever the scancode cookie means, the same IR device should
 provide the same cookie no matter what IR receiver is used, since the same
 IR may be found on different devices, or the user can simply buy a new card
 and opt to use their old IR (there are very good reasons for that, since
 several new devices are now coming with small IR's that has half of the
 keys of the ones available at the older models).

OK, this is a fair point. We need to keep the scancodes stable across
receivers.

However I am not sure if the index approach is the best - it will not
work well if driver decides to implement the keymap using data structure
different from array, let's say linked list or a hash table. Lists by
their nature do not have a stable index and even if we were to generate
one on fly we could not rely on it for subsequent EVIOSKEYCODE: some
other program may cause insertion or deletion of an element making the
artificial index refer to another entry in the map.

While extending scancode size is pretty straightforward (well, almost
;) ) I am not sure what is the best way to enumerate keymap for a given
device.

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?

On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote:
 Jon Smirl jonsm...@gmail.com writes:
 
  Once again: how about agreement about the LIRC interface
  (kernel-userspace) and merging the actual LIRC code first? In-kernel
  decoding can wait a bit, it doesn't change any kernel-user interface.
 
  I'd like to see a semi-complete design for an in-kernel IR system
  before anything is merged from any source.
 
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.
 
 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

This sounds like merge first, think later...

The question is why we need to merge lirc interface right now, before we
agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev
yet and, looking at the way things are shaping, no drivers will be
_directly_ using it after it is complete. So, even if we merge it right
away, the code will have to be restructured and reworked. Unfortunately,
just merging what Jarod posted, will introduce sysfs hierarchy which
is userspace interface as well (although we not as good maintaining it
at times) and will add more constraints on us.

That is why I think we should go the other way around - introduce the
core which receivers could plug into and decoder framework and once it
is ready register lirc-dev as one of the available decoders.

-- 
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS

2009-12-07 Thread Hans Verkuil

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:Mon Dec  7 19:00:05 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13588:065f9e34e07b
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-armv5: OK
linux-2.6.32-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-armv5-omap2: OK
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: ERRORS
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: OK
linux-2.6.31-i686: OK
linux-2.6.32-i686: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: OK
linux-2.6.31-mips: OK
linux-2.6.32-mips: OK
linux-2.6.30-powerpc64: OK
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: OK
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: ERRORS
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: OK
linux-2.6.32-x86_64: OK
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: WARNINGS
linux-2.6.17.14-i686: WARNINGS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.5-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: WARNINGS
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.5-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.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

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Krzysztof Halasa

Dmitry Torokhov dmitry.torok...@gmail.com writes:

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

 This sounds like merge first, think later...

I'd say merge the sane agreed and stable things first and think later
about improvements.

 The question is why we need to merge lirc interface right now, before we
 agreed on the sybsystem architecture?

Because we need the features and we can't improve something which is
outside the kernel. What subsystem architecture do you want to
discuss? Unrelated (input layer) interface?

Those are simple things. The only part which needs to be stable is the
(in this case LIRC) kernel-user interface.

 Noone _in kernel_ user lirc-dev
 yet and, looking at the way things are shaping, no drivers will be
 _directly_ using it after it is complete. So, even if we merge it right
 away, the code will have to be restructured and reworked.

Sure. We do this constantly to every part of the kernel.

 Unfortunately,
 just merging what Jarod posted, will introduce sysfs hierarchy which
 is userspace interface as well (although we not as good maintaining it
 at times) and will add more constraints on us.

Then perhaps it should be skipped, leaving only the things udev needs to
create /dev/ entries. They don't have to be particularly stable.
Perhaps it should go to the staging first. We can't work with the code
outside the kernel, staging has not such limitation.

 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

That means all the work has to be kept and then merged atomically,
it seems there is a lack of manpower for this.
-- 
Krzysztof Halasa
--
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

Which modules for the VP-2033? Where is the module mantis.ko?

2009-12-07 Thread Ruediger Dohmhardt

Hi Manu,

the driver from http://jusst.de/hg/v4l-dvb/ compiles fine on Suse-11.1
(2.6.27.39-0.2-default).

However, it does not build the module mantis.ko, as it used to be.
Where is it?
A search for mantis like

cd v4l-dvb-ccd0c555c680
find . -name mantis*.ko

- ./v4l/mantis_core.ko

shows up just the mantis_core.ko.

Which modules I'm supposed to load for the VP-2033?

Ciao Ruediger



--
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/4 v11] Support for TVP7002 in DM365

2009-12-07 Thread Santiago Nunez-Corrales


Hans,


Hi. Have you had a chance to look at this version of the driver?

Regards,


Santiago.

Santiago Nunez-Corrales wrote:

This series of patches provide support for the TVP7002 decoder in DM365.

Support includes:

* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support

This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
testing problems.  Tested on DM365 TI EVM with resolutions 720p,
10...@60, 576P and 480P with video capture application and video
output in 480P, 576P, 720P and 1080I. This driver depends upon
board-dm365-evm.c and vpfe_capture.c to be ready for complete
integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
Removed shadow register values. Removed unnecesary power down and up
of the device (tests work fine). Improved readability.





--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.com


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: New DibCom based ISDB-T device

2009-12-07 Thread Patrick Boettcher

On Monday 07 December 2009 21:25:25 Marcelo Blanes wrote:
 Hi Patrick,
 
 Ok I can test. Should I replace only the file dib8000.c or update the
  entire linuxtv project?

Yes, please use the v4l-dvb repository from 

http://linuxtv.org/hg/~pb/v4l-dvb/

not only the dib8000.c

PS: Please, don't chop off mailing lists when replying to a message received by 
one, You never know if someone else is following and this one may have the 
same questions as you.

-- 
Patrick 
http://www.kernellabs.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/5 - v0] V4L-vpfe capture - adding CCDC driver for DM365

2009-12-07 Thread Karicheri, Muralidharan

Sekhar,


Hi Murali,

Here is a (styling related) review from an non-video person. The


[MK] The styling was mostly done by one of our intern who is new to open source 
coding. So I will fix it based on your comments.

review is neither complete nor exhaustive (the patch is huge!),
but I thought will send across whatever I have for you to take a look.

[MK] Yes Sure!

On Wed, Dec 02, 2009 at 03:08:49, Karicheri, Muralidharan wrote:
 From: Muralidharan Karicheri m-kariche...@ti.com

 This patch is for adding support for DM365 CCDC. This will allow to
 capture YUV video frames from TVP5146 video decoder on DM365 EVM. The
vpfe
 capture driver will use this module to configure ISIF (a.k.a CCDC)
 module to allow YUV data capture. This driver is written for
ccdc_hw_device
 interface used by vpfe capture driver to configure the ccdc module.
 This patch is tested using NTSC  PAL video sources and verified for
 both formats.

 NOTE: This is the initial version for review.

Typically RFC is put instead of PATCH in subject line
to convey this.
[MK] IMO, RFC is for something that is a proposal to make some changes in the 
architecture/implementation to get feedback from the reviewers. But here it is 
a real code that is being reviewed. I just mentioned it to make sure no body 
complains that it doesn't apply to the latest tree :). This is based on
what I see in the mailing list.


 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
  drivers/media/video/davinci/dm365_ccdc.c  | 1529
+
  drivers/media/video/davinci/dm365_ccdc_regs.h |  293 +
  include/media/davinci/dm365_ccdc.h|  555 +
  3 files changed, 2377 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/dm365_ccdc.c
  create mode 100644 drivers/media/video/davinci/dm365_ccdc_regs.h
  create mode 100644 include/media/davinci/dm365_ccdc.h

 diff --git a/drivers/media/video/davinci/dm365_ccdc.c
b/drivers/media/video/davinci/dm365_ccdc.c

Hopefully it is possible to choose a generic name
instead of tying it to an SoC.

[MK]I agree there is problem here. For example, we have same ccdc IP used
across DM6446, OMAP34xx and Sitara (earlier Shiva). We have it named
currently as dm644x_ccdc.c. I have checked the DM6446 and OMAP34xx PRG
and finds that CCDC IP has a Peripheral identification (TID) and class
identification (CID). For OMAP  DM6446, they have the same values. So
We might be able to rename them as ccdc_TIDCID.c. But for CCDC on
DM355, we don't have a PID/CID for ccdc. So how do we name it? I don't
see a uniform way we can name the driver for these IPs.

Probably change dm365_ccdc.c to isif.c since that is the IP name on
DM365. ISIF stands for Image Sensor Interface.

 new file mode 100644
 index 000..2f27696
 --- /dev/null
 +++ b/drivers/media/video/davinci/dm365_ccdc.c
 @@ -0,0 +1,1529 @@

[...]

 +#include linux/delay.h
 +#include linux/platform_device.h
 +#include linux/uaccess.h
 +#include linux/io.h
 +#include linux/videodev2.h
 +#include mach/mux.h
 +#include media/davinci/dm365_ccdc.h
 +#include media/davinci/vpss.h
 +#include dm365_ccdc_regs.h
 +#include ccdc_hw_device.h

Typically the includes are grouped using empty lines
based on the folder linux, media mach etc.

[MK]This is not strictly followed in the community, But I think it is good
to do this for better readability.
 +
 +static struct device *dev;
 +
 +/* Defauts for module configuation paramaters */
 +static struct ccdc_config_params_raw ccdc_config_defaults = {
 +.linearize = {
 +.en = 0,
 +.corr_shft = CCDC_NO_SHIFT,
 +.scale_fact = {1, 0},
 +},
 +.df_csc = {
 +.df_or_csc = 0,
 +.csc = {
 +.en = 0

Should use ',' at the end of line so adding
new members leads to adding just one line.
There are more of these in this static init
below.

[MK] Ok.

 +},
 +},
 +.dfc = {
 +.en = 0
 +},
 +.bclamp = {
 +.en = 0
 +},
 +.gain_offset = {
 +.gain = {
 +.r_ye = {1, 0},
 +.gr_cy = {1, 0},
 +.gb_g = {1, 0},
 +.b_mg = {1, 0},
 +},
 +},
 +.culling = {
 +.hcpat_odd = 0xff,
 +.hcpat_even = 0xff,
 +.vcpat = 0xff
 +},
 +.compress = {
 +.alg = CCDC_ALAW,
 +},
 +};
 +
 +/* ISIF operation configuration */
 +struct ccdc_oper_config {
 +enum vpfe_hw_if_type if_type;
 +struct ccdc_ycbcr_config ycbcr;
 +struct ccdc_params_raw bayer;
 +enum ccdc_data_pack data_pack;
 +void *__iomem base_addr;
 +void *__iomem linear_tbl0_addr;
 +void *__iomem linear_tbl1_addr;

Usually it is void __iomem *foo;
[MK] Correct.


 +};
 +
 +static struct ccdc_oper_config ccdc_cfg = {
 +.ycbcr = {
 +.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
 +.frm_fmt = CCDC_FRMFMT_INTERLACED,
 +

Re: Details about DVB frontend API

Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com wrote:
 No activity in this thread for 2 weeks now.  Has there been any progress?

 I have stated that I like Manu's proposal, but I would prefer that the
 get_property (s2api) interface were used, because it totally provides
 an interface that is sufficient for this feature.

I've ported Manu's proposal to S2API way of handling it. It is just compiled
only. I haven't test it yet on a real driver.

Comments?

---

Add support for frontend statistics via S2API

The current DVB V3 API to handle statistics has two issues:
- Retrieving several values can't be done atomically;
- There's no indication about scale information.

This patch solves those two issues by adding a group of S2API
that handles the needed statistics operations. It basically ports the
proposal of Manu Abraham abraham.m...@gmail.com To S2API.

As the original patch, both of the above issues were addressed.

In order to demonstrate the changes on an existing driver for the new API, I've
implemented it at the cx24123 driver.

There are some advantages of using this approach over using the static structs
of the original proposal:
- userspace can select an arbitrary number of parameters on his get 
request;
- the latency to retrieve just one parameter is lower than retrieving
several parameters. On the cx24123 example, if user wants just signal strength,
the latency is the same as reading one register via i2c bus. If using the 
original
proposal, the latency would be 6 times worse, since you would need to get 3 
properties
at the same time;
- the latency for reading all 3 parameters at the same time is equal to
the latency of the original proposal;
- if newer statistics parameters will be needed in the future, it is 
just
a matter of adding additional S2API command/value pairs;
- the DVB V3 calls can be easily implemented as a call to the new 
get_stats ops,
without adding extra latency time.

Thanks to Manu Abraham abraham.m...@gmail.com for his initial proposal.

Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com


diff --git a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
--- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -975,6 +975,16 @@ static struct dtv_cmds_h dtv_cmds[] = {
_DTV_CMD(DTV_GUARD_INTERVAL, 0, 0),
_DTV_CMD(DTV_TRANSMISSION_MODE, 0, 0),
_DTV_CMD(DTV_HIERARCHY, 0, 0),
+
+   /* Statistics API */
+   _DTV_CMD(DTV_FE_QUALITY, 0, 0),
+   _DTV_CMD(DTV_FE_QUALITY_UNIT, 0, 0),
+   _DTV_CMD(DTV_FE_STRENGTH, 0, 0),
+   _DTV_CMD(DTV_FE_STRENGTH_UNIT, 0, 0),
+   _DTV_CMD(DTV_FE_ERROR, 0, 0),
+   _DTV_CMD(DTV_FE_ERROR_UNIT, 0, 0),
+   _DTV_CMD(DTV_FE_SIGNAL, 0, 0),
+   _DTV_CMD(DTV_FE_SIGNAL_UNIT, 0, 0),
 };
 
 static void dtv_property_dump(struct dtv_property *tvp)
@@ -1203,16 +1213,59 @@ static int dvb_frontend_ioctl_legacy(str
 static int dvb_frontend_ioctl_properties(struct inode *inode, struct file 
*file,
unsigned int cmd, void *parg);
 
+static int dtv_property_prepare_get_stats(struct dvb_frontend *fe,
+   struct dtv_property *tvp,
+   struct inode *inode, struct file *file)
+{
+   switch (tvp-cmd) {
+   case DTV_FE_QUALITY:
+   fe-dtv_property_cache.need_stats |= FE_NEED_QUALITY;
+   break;
+   case DTV_FE_QUALITY_UNIT:
+   fe-dtv_property_cache.need_stats |= FE_NEED_QUALITY_UNIT;
+   break;
+   case DTV_FE_STRENGTH:
+   fe-dtv_property_cache.need_stats |= FE_NEED_STRENGTH;
+   break;
+   case DTV_FE_STRENGTH_UNIT:
+   fe-dtv_property_cache.need_stats |= FE_NEED_STRENGTH_UNIT;
+   break;
+   case DTV_FE_ERROR:
+   fe-dtv_property_cache.need_stats |= FE_NEED_ERROR;
+   break;
+   case DTV_FE_ERROR_UNIT:
+   fe-dtv_property_cache.need_stats |= FE_NEED_ERROR_UNIT;
+   break;
+   case DTV_FE_SIGNAL:
+   fe-dtv_property_cache.need_stats |= FE_NEED_SIGNAL;
+   break;
+   case DTV_FE_SIGNAL_UNIT:
+   fe-dtv_property_cache.need_stats |= FE_NEED_SIGNAL_UNIT;
+   break;
+   case DTV_FE_UNC:
+   fe-dtv_property_cache.need_stats |= FE_NEED_SIGNAL;
+   break;
+   case DTV_FE_UNC_UNIT:
+   fe-dtv_property_cache.need_stats |= FE_NEED_SIGNAL_UNIT;
+   break;
+   default:
+   return 1;
+   };
+
+   return 0;
+}
+
 static int dtv_property_process_get(struct dvb_frontend *fe,
struct dtv_property *tvp,
-   struct inode *inode, struct file *file)
+

Re: Details about DVB frontend API

Mauro Carvalho Chehab wrote:
 Michael Krufky wrote:
 On Fri, Dec 4, 2009 at 3:02 PM, VDR User user@gmail.com wrote:
 No activity in this thread for 2 weeks now.  Has there been any progress?
 
 I have stated that I like Manu's proposal, but I would prefer that the
 get_property (s2api) interface were used, because it totally provides
 an interface that is sufficient for this feature.
 
 I've ported Manu's proposal to S2API way of handling it. It is just compiled
 only. I haven't test it yet on a real driver.
 
 Comments?
 
 ---
 
 Add support for frontend statistics via S2API
 
 The current DVB V3 API to handle statistics has two issues:
   - Retrieving several values can't be done atomically;
   - There's no indication about scale information.
 
 This patch solves those two issues by adding a group of S2API
 that handles the needed statistics operations. It basically ports the
 proposal of Manu Abraham abraham.m...@gmail.com To S2API.
 
 As the original patch, both of the above issues were addressed.
 
 In order to demonstrate the changes on an existing driver for the new API, 
 I've
 implemented it at the cx24123 driver.
 
 There are some advantages of using this approach over using the static structs
 of the original proposal:
   - userspace can select an arbitrary number of parameters on his get 
 request;
   - the latency to retrieve just one parameter is lower than retrieving
 several parameters. On the cx24123 example, if user wants just signal 
 strength,
 the latency is the same as reading one register via i2c bus. If using the 
 original
 proposal, the latency would be 6 times worse, since you would need to get 3 
 properties
 at the same time;
   - the latency for reading all 3 parameters at the same time is equal to
 the latency of the original proposal;
   - if newer statistics parameters will be needed in the future, it is 
 just
 a matter of adding additional S2API command/value pairs;
   - the DVB V3 calls can be easily implemented as a call to the new 
 get_stats ops,
 without adding extra latency time.

In time:

I only wrote the get callback. It could be interesting to implement also the 
set callback
for the DTV_FE*_UNIT parameters if there are some cases where the same driver 
can provide
a different set of units/parameters. This way, it is possible for userspace to
negotiate what parameter type he wants, on such drivers.
 
 Thanks to Manu Abraham abraham.m...@gmail.com for his initial proposal.
 

Cheers,
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

On Mon, Dec 07, 2009 at 09:08:57PM +0100, Krzysztof Halasa wrote:
 Dmitry Torokhov dmitry.torok...@gmail.com writes:
 
  There is only one thing which needs attention before/when merging LIRC:
  the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
  actually, making a correct IR core design without the LIRC merged can be
  only harder.
 
  This sounds like merge first, think later...
 
 I'd say merge the sane agreed and stable things first and think later
 about improvements.
 
  The question is why we need to merge lirc interface right now, before we
  agreed on the sybsystem architecture?
 
 Because we need the features and we can't improve something which is
 outside the kernel. What subsystem architecture do you want to
 discuss? Unrelated (input layer) interface?


No, the IR core responsible for registering receivers and decoders.

 Those are simple things. The only part which needs to be stable is the
 (in this case LIRC) kernel-user interface.

For which some questions are still open. I believe Jon just oulined some
of them.

 
  Noone _in kernel_ user lirc-dev
  yet and, looking at the way things are shaping, no drivers will be
  _directly_ using it after it is complete. So, even if we merge it right
  away, the code will have to be restructured and reworked.
 
 Sure. We do this constantly to every part of the kernel.

No we do not. We do not merge something that we expect to rework almost
completely (no, not the lirc-style device userspace inetrface, although
even it is not completely finalized I believe, but the rest of the
subsystem).

 
  Unfortunately,
  just merging what Jarod posted, will introduce sysfs hierarchy which
  is userspace interface as well (although we not as good maintaining it
  at times) and will add more constraints on us.
 
 Then perhaps it should be skipped, leaving only the things udev needs to
 create /dev/ entries. They don't have to be particularly stable.
 Perhaps it should go to the staging first. We can't work with the code
 outside the kernel, staging has not such limitation.

OK, say we add this to staging as is. What is next? Who will be using
this code that is now in staging? Do we encougrage driver's writers to
hook into it (given that we intend on redoing it soon)? Do something
else?

 
  That is why I think we should go the other way around - introduce the
  core which receivers could plug into and decoder framework and once it
  is ready register lirc-dev as one of the available decoders.
 
 That means all the work has to be kept and then merged atomically,
 it seems there is a lack of manpower for this.

No, not at all. You merge core subsystem code, then start addig
decoders... In the meantime driver-writers could start preparing their
drivers to plug into it.

In the mean time out-of-tree LIRC can be used by consumers undisturbed.

-- 
Dmitry
--
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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Jarod Wilson

On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:

 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
 Krzysztof Halasa wrote:
 Andy Walls awa...@radix.net writes:
 
 I would also note that RC-6 Mode 6A, used by most MCE remotes, was
 developed by Philips, but Microsoft has some sort of licensing interest
 in it and it is almost surely encumbered somwhow:
 
 I don't know about legal problems in some countries but from the
 technical POV handling the protocol in the kernel is more efficient
 or (/and) simpler.
 
 A software licensing from Microsoft won't apply to Linux kernel, so I'm
 assuming that you're referring to some patent that they could be filled
 about RC6 mode 6A.
 
 I don't know if is there any US patent pending about it (AFAIK, only US
 accepts software patents), but there are some prior-art for IR key
 decoding. So, I don't see what innovation RC6 would be adding. 
 If it is some new way to transmit waves, the patent issues
 aren't related to software, and the device manufacturer had already handled
 it when they made their devices.
 
 If it is just a new keytable, this issue 
 could be easily solved by loading the keytable via userspace.
 
 Also, assuming that you can use the driver only with a hardware that comes
 with a licensed software, the user has already the license for using it.
 
 Do you have any details on what patents they are claiming?
 
 The US Philips RC-6 patent is US Patent 5,877,702
 
 http://www.google.com/patents?vid=USPAT5877702
 
 Click on download PDF to get a copy of the whole patent.
 
 I am not a lawyer.  Philips claims' all appear to tie to a transmitter
 or receiver as part of a system, but most of the claims are about
 information and bit positions and lengths.
...
 IMO, given
 
 a. the dearth of public information about RC-6, indicating someone
 thinks it's their trade secret or intellectual property
 
 b. Microsoft claiming to license something related to the MCE remote
 protocols (which are obviously RC-6 Mode 6A),
 
 c. my inability to draw a clear, bright line that RC-6 Mode 6A
 encoding and decoding, as needed by MCE remotes, implemented in software
 doesn't violate anyone's government granted rights to exclusivity.
 
 I think it's much better to implement software RC-6 Mode 6A encoding and
 decoding in user space, doing only the minimum needed to get the
 hardware setup and going in the kernel.  
 
 Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
 worry me. 
 
 
 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.

So I had one of the people who does all the license and patent audits for 
Fedora packages look at the Philips patent on RC-6. He's 100% positive that the 
patent *only* covers hardware, there should be no problem whatsoever writing a 
software decoder for RC-6.

-- 
Jarod Wilson
ja...@wilsonet.com



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

dib0090.h need attention - copy-paste errors

2009-12-07 Thread Igor M. Liplianin

Part of dib0090.h:

91 static inline enum frontend_tune_state dib0090_get_tune_state(struct 
dvb_frontend *fe)
92 {
93 printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
94 return CT_DONE;
95 }
96
97 static inline int dib0090_set_tune_state(struct dvb_frontend *fe, enum 
frontend_tune_state 
tune_state)
98 {
99 printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
100 return -ENODEV;
101 }
102
103 static inline num frontend_tune_state dib0090_get_tune_state(struct 
dvb_frontend *fe)
104 {
105 printk(KERN_WARNING %s: driver disabled by Kconfig\n, __func__);
106 return CT_SHUTDOWN,}
107 

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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] What are the goals for the architecture of an in-kernel IR system?

Dmitry Torokhov wrote:
On Mon, Dec 07, 2009 at 01:34:10PM -0200, Mauro Carvalho Chehab wrote:

Scancodes in input system never been real scancodes. Even if you look
into atkbd it uses some synthetic data composed out of real scancodes
sent to the keyboard, and noone cares. If you are unsatisfied with
mapping you fire up evtest, press the key, take whatever the driver
[mis]represents as a scancode and use it to load the new definition. And
you don't care at all whether the thing that driver calls cancode makes
any sense to the hardware device.
We used a mis-represented scancode, but this proofed to be a broken design
along the time.

For users, whatever the scancode cookie means, the same IR device should
provide the same cookie no matter what IR receiver is used, since the same
IR may be found on different devices, or the user can simply buy a new card
and opt to use their old IR (there are very good reasons for that, since
several new devices are now coming with small IR's that has half of the
keys of the ones available at the older models).

OK, this is a fair point. We need to keep the scancodes stable across
receivers.

However I am not sure if the index approach is the best - it will not
work well if driver decides to implement the keymap using data structure
different from array, let's say linked list or a hash table. Lists by
their nature do not have a stable index and even if we were to generate
one on fly we could not rely on it for subsequent EVIOSKEYCODE: some
other program may cause insertion or deletion of an element making the
artificial index refer to another entry in the map.

Any addition/deletion of an element will cause problems, even with a simple
table. I don't think we should consider a case where two applications are
changing the table at the same time. The end result will likely be different
than what's expected anyway. Btw, while an index for EVIOGSKEYCODE is really
important, except for symmetry, there are no other reasons why we can't use
scancode as the primary key for EVIOSKEYCODE. We can't allow two identical
scancodes anyway at the scancode/keycode table. So, we can define the
EVIOSKEYCODE without an index.

While extending scancode size is pretty straightforward (well, almost
;) ) I am not sure what is the best way to enumerate keymap for a given
device.

Btw, if you want to take a look, I've finished to implement the table
insert/delete
logic. Extending/reducing space at the table required some care, but it is
working
fine:

http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=87d73cbd33235b162e8da62305ba8b5926a1fbf8

The code is not optimized by using a hash table or a binary search yet (patches
to
improve are welcome), but it is already working as expected.

Cheers,
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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
 
 On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:

 Maybe I'm being too conservative here, but I have a personal interest in
 keeping Linux free and unencumbered even in the US which, I cannot deny,
 has a patent system that is screwed up.
 
 So I had one of the people who does all the license and patent audits for 
 Fedora packages look at the Philips patent on RC-6. He's 100% positive 
 that the patent *only* covers hardware, there should be no problem whatsoever
 writing a software decoder for RC-6.

That's good!

Cheers,
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

Emmanuel Fusté wrote:
 Mauro Carvalho Chehab wrote:
 
 In summary,

 While the current EVIO[G|S]KEYCODE works sub-optimally for scancodes
 up to 16 bytes
 (since a read loop for 2^16 is not that expensive), the current approach
 won't scale with bigger scancode spaces. So, it is needed expand it
 to work with bigger scancode spaces, used by more recent IR protocols.

 I'm afraid that any tricks we may try to go around the current limits
 to still
 keep using the same ioctl definition will sooner or later cause big
 headaches.
 The better is to redesign it to allow using different scancode spaces.


   
 I second you: input layer events from drivers should be augmented with a
 protocol member,

Yeah, I added the protocol type info inside the internal representation of
the IR table. As I managed to do all the work inside one file (ir-keytable.c),
changing it to use arbitrary sized scancode lengths will be trivial (currently,
it is u16 just because just because it currently enough for the in-kernel 
drivers,
but this will be changed when integrating with lirc):

http://linuxtv.org/hg/v4l-dvb/rev/7b983cd30f0f

 allowing us to define new ioctl and new ways to
 efficiently store and manage sparse scancode spaces (tree, hashtable
 ). It will allow us to abstract the scancode value and to use
 variable length scancode depending on the used protocol, and using the
 most appropriate scheme to store the scancode/keycode mapping per protocol.

True.

 The today scancode space will be the legacy one, the default if not
 specified protocol. It will permit to progressively clean up the
 actual acceptable mess in the input layer and finally using real
 scancode - keycode mappings everywhere if it is cleaner/convenient.

Yes. By purpose, I added IR_TYPE_UNKNOWN as 0. This way, all tables that don't
specify a protocol can be considered legacy.

Cheers,
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

Let me add my view for those questions.

Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Jon Smirl jonsm...@gmail.com writes:

 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.
 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.
 
 Here's a few design review questions on the LIRC drivers that were posted
 
 How is the pulse data going to be communicated to user space?

lirc_dev will implement a revised version of the lirc API. I'm assuming that
Jerod and Christoph will do this review, in order to be sure that it is stable
enough for kernel inclusion (as proposed by Gerd).

 Can the pulse data be reported via an existing interface without
 creating a new one?

Raw pulse data should be reported only via lirc_dev, but it can be converted
into a keycode and reported via evdev as well, via an existing interface.

 Where is the documentation for the protocol?

I'm not sure what you're meaning here. I've started a doc about IR at the media
docbook. This is currently inside the kernel Documents/DocBook. If you want
to browse, it is also available as:

http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html

For sure we need to better document the IR's, and explain the API's there.

 Is it a device interface or something else?

lirc_dev should create a device interface.

 What about capabilities of the receiver, what frequencies?
 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

IMO, via sysfs.

 What about multiple apps simultaneously using the pulse data?

IMO, the better is to limit the raw interface to just one open.

 How big is the receive queue?

It should be big enough to receive at least one keycode event. Considering that
the driver will use kfifo (IMO, it is a good strategy, especially since you
won't need any lock if just one open is allowed), it will require a power of 
two size.

 How does access work, root only or any user?

IMO, it should be the same requirement as used by an input interface.

 How are capabilities exposed, sysfs, etc?

IMO, sysfs.

 What is the interface for attaching an in-kernel decoder?

IMO, it should use the kfifo for it. However, if we allow both raw data and
in-kernel decoders to read data there, we'll need a spinlock to protect the
kfifo.

 If there is an in-kernel decoder should the pulse data stop being
 reported, partially stopped, something else?

I don't have a strong opinion here, but, from the previous discussions, it
seems that people want it to be double-reported by default. If so, I think
we need to implement a command at the raw interface to allow disabling the
in-kernel decoder, while the raw interface is kept open.

 What is the mechanism to make sure both system don't process the same pulses?

I don't see a good way to avoid it.

 Does it work with poll, epoll, etc?
 What is the time standard for the data, where does it come from?
 How do you define the start and stop of sequences?
 Is receiving synchronous or queued?
 What about transmit, how do you get pulse data into the device?
 Transmitter frequencies?
 Multiple transmitters?
 Is transmitting synchronous or queued?
 How big is the transmit queue?

I don't have a clear answer for those. I'll let those to LIRC developers to 
answer.


Cheers,
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: architecture part of video driver patch

2009-12-07 Thread Kevin Hilman

Karicheri, Muralidharan m-kariche...@ti.com writes:

 Kevin,

 Following patch merged to v4l-dvb linux-next has an architectural 
 part as attached. If you have not merged it to your next branch
 for linux-davinci tree, please do so at your earliest convenience
 so that they are in sync.

OK, applying to davinci git, and queuing for 2.6.34.

 Patch merged to linux-next is available at

 http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=commitdiff;h=600cc66f7f3ec93ab4f09cf6b63980f4c5e8f8db

 I will be pushing some more patches to upstream that are having
 changes to arch part. I will notify once they are merged to linux-next.

OK, thanks,

Kevin

 Murali Karicheri
 Software Design Engineer
 Texas Instruments Inc.
 Germantown, MD 20874
 phone: 301-407-9583
 email: m-kariche...@ti.com

 From: Hiremath, Vaibhav hvaib...@ti.com
 Subject: [PATCH 3/6] Davinci VPFE Capture: Take i2c adapter id through 
 platform data
 To: linux-media@vger.kernel.org linux-media@vger.kernel.org
 CC: davinci-linux-open-sou...@linux.davincidsp.com 
 davinci-linux-open-sou...@linux.davincidsp.com
 Date: Tue, 13 Oct 2009 10:08:54 -0500

 From: Vaibhav Hiremath hvaib...@ti.com

 The I2C adapter ID is actually depends on Board and may vary, Davinci
 uses id=1, but in case of AM3517 id=3.

 So modified respective davinci board files.

 Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
 ---
  arch/arm/mach-davinci/board-dm355-evm.c  |1 +
  arch/arm/mach-davinci/board-dm644x-evm.c |1 +
  2 files changed, 2 insertions(+), 0 deletions(-)

 diff --git a/arch/arm/mach-davinci/board-dm355-evm.c 
 b/arch/arm/mach-davinci/board-dm355-evm.c
 index f683559..4a9252a 100644
 --- a/arch/arm/mach-davinci/board-dm355-evm.c
 +++ b/arch/arm/mach-davinci/board-dm355-evm.c
 @@ -372,6 +372,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
  
  static struct vpfe_config vpfe_cfg = {
   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
 + .i2c_adapter_id = 1,
   .sub_devs = vpfe_sub_devs,
   .card_name = DM355 EVM,
   .ccdc = DM355 CCDC,
 diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c 
 b/arch/arm/mach-davinci/board-dm644x-evm.c
 index cfd9afa..fed64e2 100644
 --- a/arch/arm/mach-davinci/board-dm644x-evm.c
 +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
 @@ -257,6 +257,7 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
  
  static struct vpfe_config vpfe_cfg = {
   .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
 + .i2c_adapter_id = 1,
   .sub_devs = vpfe_sub_devs,
   .card_name = DM6446 EVM,
   .ccdc = DM6446 CCDC,
 -- 
 1.6.2.4

 ___
 Davinci-linux-open-source mailing list
 davinci-linux-open-sou...@linux.davincidsp.com
 http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
 --
--
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] What are the goals for the architecture of an in-kernel IR system?

Christoph Bartelmus wrote:
 Hi Jon,
 
 on 04 Dec 09 at 19:28, Jon Smirl wrote:
 BTW, I just came across a XMP remote that seems to generate 3x64 bit
 scan codes. Anyone here has docs on the XMP protocol?
 Assuming a general purpose receiver (not one with fixed hardware
 decoding), is it important for Linux to receive IR signals from all
 possible remotes no matter how old or obscure? Or is it acceptable to
 [...]
 Of course transmitting is a completely different problem, but we
 haven't been talking about transmitting. I can see how we would need
 to record any IR protocol in order to retransmit it. But that's in the
 5% of users world, not the 90% that want MythTV to just work.  Use
 something like LIRC if you want to transmit.
 
 I don't think anyone here is in the position to be able to tell what is  
 90% or 5%.

True. Yet, cases like IR devices made by someone's own use is something
that we don't need to care to have an in-kernel driver.

 Personally I use LIRC exclusively for transmit to my settop box  
 using an old and obscure RECS80 protocol.
 No, I won't replace my setup just because it's old and obscure.
 
 Cable companies tend to provide XMP based boxes to subscribers more often  
 these days. Simply not supporting these setups is a no-go for me.

I don't see any reason why not supporting STB protocols. Several such
hardware use Linux, anyway. So, eventually the STB manufacturers may send
us decoders that work with their IR's.

Cheers,
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: Mantis – anyone?

2009-12-07 Thread Matthias Wächter

Hi Manu,

Just to give you some feedback on the first issue as well:

Am 06.12.2009 13:52, schrieb Matthias Wächter:
 • Can’t lock to 19.2/11303h (looks like something new, related to the
 change of the transponder’s feed, but other cards – e.g. TBS 6920 and
 Tevii 470 – do sync without a problem). Looks like a frontend issue to
 me (STB0899/STB6100), as mantis and budget-ci cards are affected in the
 same way. This correlates with perfect and quick lock of 19.2/11362h
 which is about the same frequency and has the same DVB parameters
 (22000/hC23M5O35S1).

One guy on vdrportal.de tried his card under Windows, and he can there
lock to that transponder. He tells that locking took quite some time,
though, and it appears that transponder shows unexpected low signal
strength, but I would take that with a grain of salt as it might be
different frontend handling and value scaling.

– Matthias
--
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] What are the goals for the architecture of an in-kernel IR system?

Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 

 struct input_keytable_entry {
  u16 index;
  u64 scancode;
  u32 keycode;
 } __attribute__ ((packed));

 (the attribute packed avoids needing a compat for 64 bits)
 
 Maybe { u64 scancode; u32 keycode; u16 index; u16 reserved } would be a
 bit better, no alignment problems and we could eventually change
 reserved into something useful.
 
 But I think, if we are going to redesign it, we better use scancodes of
 arbitrary length (e.g. protocol-dependent length). It should be opaque
 except for the protocol handler.

Yes, an opaque type for scancode at the userspace API can be better, but
passing a pointer to kernel will require some compat32 logic (as pointer
size is different on 32 and 64 bits).

We may use something like an u8[] with an arbitrary large number of bytes.
In this case, we need to take some care to avoid LSB/MSB troubles.

Cheers,
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 v1 - 1/4] V4L: vpfe_capture - remove clock and ccdc resource handling

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v0 of these patches.

In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpfe_capture.c |  131 +++-
 1 files changed, 13 insertions(+), 118 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c 
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..091750e 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -108,9 +108,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-   /* for storing mem maps for CCDC */
-   int ccdc_addr_size;
-   void *__iomem ccdc_addr;
 };
 
 /* data structures */
@@ -230,7 +227,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-   BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
 
mutex_lock(ccdc_lock);
@@ -241,25 +237,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
 * walk through it during vpfe probe
 */
printk(KERN_ERR vpfe capture not initialized\n);
-   ret = -1;
+   ret = -EFAULT;
goto unlock;
}
 
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-   ret = -1;
+   ret = -EINVAL;
goto unlock;
}
 
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-   ret = -1;
+   ret = -EINVAL;
goto unlock;
}
 
ccdc_dev = dev;
-   dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
 unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1787,61 +1781,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
 }
 
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-   struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-   clk_disable(vpfe_cfg-vpssclk);
-   clk_put(vpfe_cfg-vpssclk);
-   clk_disable(vpfe_cfg-slaveclk);
-   clk_put(vpfe_cfg-slaveclk);
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master  slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-   struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-   int ret = -ENOENT;
-
-   vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-   if (NULL == vpfe_cfg-vpssclk) {
-   v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-vpss_master\n);
-   return ret;
-   }
-
-   if (clk_enable(vpfe_cfg-vpssclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   vpfe vpss master clock not enabled\n);
-   goto out;
-   }
-   v4l2_info(vpfe_dev-pdev-driver,
-vpfe vpss master clock enabled\n);
-
-   vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
-   if (NULL == vpfe_cfg-slaveclk) {
-   v4l2_err(vpfe_dev-pdev-driver,
-   No clock defined for vpss slave\n);
-   goto out;
-   }
-
-   if (clk_enable(vpfe_cfg-slaveclk)) {
-   v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss slave clock not enabled\n);
-   goto out;
-   }
-   v4l2_info(vpfe_dev-pdev-driver, vpfe vpss slave clock enabled\n);
-   return 0;
-out:
-   if (vpfe_cfg-vpssclk)
-   clk_put(vpfe_cfg-vpssclk);
-   if (vpfe_cfg-slaveclk)
-   clk_put(vpfe_cfg-slaveclk);
-
-   return -1;
-}
-
 /*
  * vpfe_probe : This function creates device entries by register
  * itself to the V4L2 driver and initializes fields of each
@@ -1871,7 +1810,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
 
if (NULL == pdev-dev.platform_data) {
v4l2_err(pdev-dev.driver, Unable to get vpfe config\n);
-   ret = -ENOENT;
+   ret = -ENODEV;
goto probe_free_dev_mem;
}
 
@@ -1885,18 +1824,13 @@ static __init int vpfe_probe(struct platform_device 
*pdev)
goto probe_free_dev_mem;
}
 
-   /* enable vpss clocks */
-   ret = vpfe_enable_clock(vpfe_dev);
-   if (ret)
-   goto probe_free_dev_mem;
-
mutex_lock(ccdc_lock);

[PATCH v1 - 3/4] V4L - vpfe capture - Make dm355 ccdc a platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v0 of these patches.

In this patch, the probe() function is modified to do the vpss master and
slave clock configuration. It is assumed that the clock names are same
across all ccdc IPs. If not, this will have to use configurable clock names
as done in previous patch (Vaibhav to check this for OMAP). The static
variables used in the driver are encapsulated inside a structure (ccdc_cfg)
as part of clean up.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb linux-next
 drivers/media/video/davinci/dm355_ccdc.c |  409 +++---
 1 files changed, 256 insertions(+), 153 deletions(-)

diff --git a/drivers/media/video/davinci/dm355_ccdc.c 
b/drivers/media/video/davinci/dm355_ccdc.c
index 56fbefe..36cde21 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,8 +37,11 @@
 #include linux/platform_device.h
 #include linux/uaccess.h
 #include linux/videodev2.h
+#include linux/clk.h
+
 #include media/davinci/dm355_ccdc.h
 #include media/davinci/vpss.h
+
 #include dm355_ccdc_regs.h
 #include ccdc_hw_device.h
 
@@ -46,67 +49,75 @@ MODULE_LICENSE(GPL);
 MODULE_DESCRIPTION(CCDC Driver for DM355);
 MODULE_AUTHOR(Texas Instruments);
 
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
-   .pix_fmt = CCDC_PIXFMT_RAW,
-   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
-   .win = CCDC_WIN_VGA,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .gain = {
-   .r_ye = 256,
-   .gb_g = 256,
-   .gr_cy = 256,
-   .b_mg = 256
-   },
-   .config_params = {
-   .datasft = 2,
-   .data_sz = CCDC_DATA_10BITS,
-   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
-   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
-   .alaw = {
-   .gama_wd = 2,
+static struct ccdc_oper_config {
+   struct device *dev;
+   /* CCDC interface type */
+   enum vpfe_hw_if_type if_type;
+   /* Raw Bayer configuration */
+   struct ccdc_params_raw bayer;
+   /* YCbCr configuration */
+   struct ccdc_params_ycbcr ycbcr;
+   /* Master clock */
+   struct clk *mclk;
+   /* slave clock */
+   struct clk *sclk;
+   /* ccdc base address */
+   void __iomem *base_addr;
+} ccdc_cfg = {
+   /* Raw configurations */
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .gain = {
+   .r_ye = 256,
+   .gb_g = 256,
+   .gr_cy = 256,
+   .b_mg = 256
},
-   .blk_clamp = {
-   .sample_pixel = 1,
-   .dc_sub = 25
-   },
-   .col_pat_field0 = {
-   .olop = CCDC_GREEN_BLUE,
-   .olep = CCDC_BLUE,
-   .elop = CCDC_RED,
-   .elep = CCDC_GREEN_RED
-   },
-   .col_pat_field1 = {
-   .olop = CCDC_GREEN_BLUE,
-   .olep = CCDC_BLUE,
-   .elop = CCDC_RED,
-   .elep = CCDC_GREEN_RED
+   .config_params = {
+   .datasft = 2,
+   .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+   .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+   .alaw = {
+   .gama_wd = 2,
+   },
+   .blk_clamp = {
+   .sample_pixel = 1,
+   .dc_sub = 25
+   },
+   .col_pat_field0 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
+   .col_pat_field1 = {
+   .olop = CCDC_GREEN_BLUE,
+   .olep = CCDC_BLUE,
+   .elop = CCDC_RED,
+   .elep = CCDC_GREEN_RED
+   },
},
},
+   /* YCbCr configuration */
+   .ycbcr = {
+   .win = CCDC_WIN_PAL,
+

[PATCH v1 4/4] DaVinci - vpfe capture - converting ccdc drivers to platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v0 of these patches.

This adds platform code for ccdc driver on DM355 and DM6446.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-davinci tree
 arch/arm/mach-davinci/dm355.c  |   39 +++
 arch/arm/mach-davinci/dm644x.c |   18 +-
 2 files changed, 44 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..0a23820 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -665,6 +665,17 @@ static struct platform_device dm355_asp1_device = {
.resource   = dm355_asp1_resources,
 };
 
+static void dm355_ccdc_setup_pinmux(void)
+{
+   davinci_cfg_reg(DM355_VIN_PCLK);
+   davinci_cfg_reg(DM355_VIN_CAM_WEN);
+   davinci_cfg_reg(DM355_VIN_CAM_VD);
+   davinci_cfg_reg(DM355_VIN_CAM_HD);
+   davinci_cfg_reg(DM355_VIN_YIN_EN);
+   davinci_cfg_reg(DM355_VIN_CINL_EN);
+   davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
 static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +712,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags  = IORESOURCE_MEM,
@@ -708,8 +723,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
 };
+static struct platform_device dm355_ccdc_dev = {
+   .name   = dm355_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm355_ccdc_resource),
+   .resource   = dm355_ccdc_resource,
+   .dev = {
+   .dma_mask   = vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   .platform_data  = dm355_ccdc_setup_pinmux,
+   },
+};
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 static struct platform_device vpfe_capture_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
@@ -860,17 +885,7 @@ static int __init dm355_init_devices(void)
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(dm355_edma_device);
platform_device_register(dm355_vpss_device);
-   /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
-   davinci_cfg_reg(DM355_VIN_PCLK);
-   davinci_cfg_reg(DM355_VIN_CAM_WEN);
-   davinci_cfg_reg(DM355_VIN_CAM_VD);
-   davinci_cfg_reg(DM355_VIN_CAM_HD);
-   davinci_cfg_reg(DM355_VIN_YIN_EN);
-   davinci_cfg_reg(DM355_VIN_CINL_EN);
-   davinci_cfg_reg(DM355_VIN_CINH_EN);
+   platform_device_register(dm355_ccdc_dev);
platform_device_register(vpfe_capture_dev);
 
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..982be1f 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags  = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+   /* CCDC Base address */
{
.start  = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
 };
 
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+   .name   = dm644x_ccdc,
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
+   .resource   = dm644x_ccdc_resource,
+   .dev = {
+   .dma_mask   = vpfe_capture_dma_mask,
+   .coherent_dma_mask  = DMA_BIT_MASK(32),
+   },
+};
+
 static struct platform_device vpfe_capture_dev = {
.name   = CAPTURE_DRV_NAME,
.id = -1,
@@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
platform_device_register(dm644x_edma_device);
platform_device_register(dm644x_emac_device);
platform_device_register(dm644x_vpss_device);
+   platform_device_register(dm644x_ccdc_dev);
platform_device_register(vpfe_capture_dev);
 
return 0;
-- 
1.6.0.4

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message

[PATCH v1 - 2/4] V4L-vpfe capture - Make dm6446 ccdc a platform driver

From: Muralidharan Karicheri m-kariche...@ti.com

This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v0 of these patches.

In this patch, the probe() function is modified to do the vpss master and
slave clock configuration. It is assumed that the clock names are same
across all ccdc IPs. If not, this will have to use configurable clock names
as done in previous patch (Vaibhav to check this for OMAP). The static
variables used in the driver are encapsulated inside a structure (ccdc_cfg)
as part of clean up.

Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb linux-next
 drivers/media/video/davinci/dm644x_ccdc.c |  360 ++---
 1 files changed, 224 insertions(+), 136 deletions(-)

diff --git a/drivers/media/video/davinci/dm644x_ccdc.c 
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..6bd4bc8 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -37,8 +37,11 @@
 #include linux/platform_device.h
 #include linux/uaccess.h
 #include linux/videodev2.h
+#include linux/clk.h
+
 #include media/davinci/dm644x_ccdc.h
 #include media/davinci/vpss.h
+
 #include dm644x_ccdc_regs.h
 #include ccdc_hw_device.h
 
@@ -46,32 +49,44 @@ MODULE_LICENSE(GPL);
 MODULE_DESCRIPTION(CCDC Driver for DM6446);
 MODULE_AUTHOR(Texas Instruments);
 
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
-   .pix_fmt = CCDC_PIXFMT_RAW,
-   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
-   .win = CCDC_WIN_VGA,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .config_params = {
-   .data_sz = CCDC_DATA_10BITS,
+static struct ccdc_oper_config {
+   struct device *dev;
+   /* CCDC interface type */
+   enum vpfe_hw_if_type if_type;
+   /* Raw Bayer configuration */
+   struct ccdc_params_raw bayer;
+   /* YCbCr configuration */
+   struct ccdc_params_ycbcr ycbcr;
+   /* Master clock */
+   struct clk *mclk;
+   /* slave clock */
+   struct clk *sclk;
+   /* ccdc base address */
+   void __iomem *base_addr;
+} ccdc_cfg = {
+   /* Raw configurations */
+   .bayer = {
+   .pix_fmt = CCDC_PIXFMT_RAW,
+   .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+   .win = CCDC_WIN_VGA,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .config_params = {
+   .data_sz = CCDC_DATA_10BITS,
+   },
+   },
+   .ycbcr = {
+   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+   .frm_fmt = CCDC_FRMFMT_INTERLACED,
+   .win = CCDC_WIN_PAL,
+   .fid_pol = VPFE_PINPOL_POSITIVE,
+   .vd_pol = VPFE_PINPOL_POSITIVE,
+   .hd_pol = VPFE_PINPOL_POSITIVE,
+   .bt656_enable = 1,
+   .pix_order = CCDC_PIXORDER_CBYCRY,
+   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
},
-};
-
-/* Object for CCDC ycbcr mode */
-static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
-   .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
-   .frm_fmt = CCDC_FRMFMT_INTERLACED,
-   .win = CCDC_WIN_PAL,
-   .fid_pol = VPFE_PINPOL_POSITIVE,
-   .vd_pol = VPFE_PINPOL_POSITIVE,
-   .hd_pol = VPFE_PINPOL_POSITIVE,
-   .bt656_enable = 1,
-   .pix_order = CCDC_PIXORDER_CBYCRY,
-   .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
 };
 
 #define CCDC_MAX_RAW_YUV_FORMATS   2
@@ -84,25 +99,15 @@ static u32 ccdc_raw_bayer_pix_formats[] =
 static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
 
-static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
-static enum vpfe_hw_if_type ccdc_if_type;
-
 /* register access routines */
 static inline u32 regr(u32 offset)
 {
-   return __raw_readl(ccdc_base_addr + offset);
+   return __raw_readl(ccdc_cfg.base_addr + offset);
 }
 
 static inline void regw(u32 val, u32 offset)
 {
-   __raw_writel(val, ccdc_base_addr + offset);
-}
-
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
-   ccdc_base_addr = addr;
-   ccdc_addr_size = size;
+   __raw_writel(val, ccdc_cfg.base_addr + offset);
 }
 
 static void ccdc_enable(int flag)
@@ -132,7 +137,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
int vert_start, vert_nr_lines;
int val = 0, mid_img = 0;
 
-   dev_dbg(dev, \nStarting ccdc_setwin...);
+   dev_dbg(ccdc_cfg.dev, \nStarting ccdc_setwin...);
/*
 * ppc - per pixel count. indicates how many pixels per cell
 * output to SDRAM. example, for ycbcr, it is one y and one c, so 2.
@@ -171,7 +176,7 @@ void

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Jon Smirl

On Mon, Dec 7, 2009 at 6:44 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Let me add my view for those questions.

 Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
 Jon Smirl jonsm...@gmail.com writes:

 Once again: how about agreement about the LIRC interface
 (kernel-userspace) and merging the actual LIRC code first? In-kernel
 decoding can wait a bit, it doesn't change any kernel-user interface.
 I'd like to see a semi-complete design for an in-kernel IR system
 before anything is merged from any source.
 This is a way to nowhere, there is no logical dependency between LIRC
 and input layer IR.

 There is only one thing which needs attention before/when merging LIRC:
 the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
 actually, making a correct IR core design without the LIRC merged can be
 only harder.

 Here's a few design review questions on the LIRC drivers that were posted

 How is the pulse data going to be communicated to user space?

 lirc_dev will implement a revised version of the lirc API. I'm assuming that
 Jarod and Christoph will do this review, in order to be sure that it is stable
 enough for kernel inclusion (as proposed by Gerd).

 Can the pulse data be reported via an existing interface without
 creating a new one?

 Raw pulse data should be reported only via lirc_dev, but it can be converted
 into a keycode and reported via evdev as well, via an existing interface.

 Where is the documentation for the protocol?

 I'm not sure what you're meaning here. I've started a doc about IR at the 
 media

What is the format of the pulse stream data coming out of the lirc device?

 docbook. This is currently inside the kernel Documents/DocBook. If you want
 to browse, it is also available as:

        http://linuxtv.org/downloads/v4l-dvb-apis/ch17.html

 For sure we need to better document the IR's, and explain the API's there.

 Is it a device interface or something else?

 lirc_dev should create a device interface.

 What about capabilities of the receiver, what frequencies?
 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

 IMO, via sysfs.

Say you have a hardware device with two IR diodes, one at 38K and one
at 56K. Both of these receivers can get pulses. How do we tell the
user space app which frequency the pulses were received on? Seems to
me like there has to be a header on the pulse data indicating the
received carrier frequency. There is also baseband signaling. sysfs
won't work for this because of the queuing latency.

How is over-run signaled to the app? You'd get an over-run if the app
is too slow at reading the data out of the FIFO. If you ignore
over-run you'll be processing bad data because part of the message was
lost. An over-run signal tell the abort to abort the signal and start
over.

 What about multiple apps simultaneously using the pulse data?

 IMO, the better is to limit the raw interface to just one open.

 How big is the receive queue?

 It should be big enough to receive at least one keycode event. Considering 
 that
 the driver will use kfifo (IMO, it is a good strategy, especially since you
 won't need any lock if just one open is allowed), it will require a power of 
 two size.

How is end of a pulse train detected? timeout? without decoding the
protocol there is no way to tell the end of signal other than timeout.


 How does access work, root only or any user?

 IMO, it should be the same requirement as used by an input interface.

 How are capabilities exposed, sysfs, etc?

 IMO, sysfs.

 What is the interface for attaching an in-kernel decoder?

 IMO, it should use the kfifo for it. However, if we allow both raw data and
 in-kernel decoders to read data there, we'll need a spinlock to protect the
 kfifo.

 If there is an in-kernel decoder should the pulse data stop being
 reported, partially stopped, something else?

 I don't have a strong opinion here, but, from the previous discussions, it
 seems that people want it to be double-reported by default. If so, I think
 we need to implement a command at the raw interface to allow disabling the
 in-kernel decoder, while the raw interface is kept open.

Data could be sent to the in-kernel decoders first and then if they
don't handle it, send it to user space.



 What is the mechanism to make sure both system don't process the same pulses?

 I don't see a good way to avoid it.

 Does it work with poll, epoll, etc?
 What is the time standard for the data, where does it come from?
 How do you define the start and stop of sequences?
 Is receiving synchronous or queued?
 What about transmit, how do you get pulse data into the device?
 Transmitter frequencies?
 Multiple transmitters?
 Is transmitting synchronous or queued?
 How big is the transmit queue?

 I don't have a clear answer for those. I'll let those to LIRC developers to 
 answer.


 Cheers,
 Mauro






-- 
Jon Smirl
jonsm...@gmail.com
--
To

Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Jon Smirl

On Mon, Dec 7, 2009 at 1:41 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 That is why I think we should go the other way around - introduce the
 core which receivers could plug into and decoder framework and once it
 is ready register lirc-dev as one of the available decoders.

The core needs to allow for RF remotes too.

-Bluetooth remotes are already in kernel somehow, I don't know how they work,
-RF4CE, the 802.15.4 stack has been recently merged, the remotes use a
protocol on top of that. These remotes will hit the consumer market
next year. Sony, Panasonic and other big names are behind this.
-Zwave, the Harmony remotes use Zwave. There is no Zwave support in
the kernel that I am aware of. Zwave is proprietary.

After these protocols are decoded you end up with scancodes. The
scancodes need to get injected into input somehow and then flow
through the mapping process. Decoding down to the scancodes probably
happens over in the networking code.

After an in-kernel IR decoder runs it needs to hand off the scancodes
into the input subsystem. This same API can be used by the networking
code to hand off RF scancodes.

-- 
Jon Smirl
jonsm...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4 v11] Support for TVP7002 in DM365

2009-12-07 Thread Hans Verkuil

On Tuesday 08 December 2009 01:44:43 Santiago Nunez-Corrales wrote:
 Hans,
 
 
 Hi. Have you had a chance to look at this version of the driver?

Sorry, no. I hope to have some time on Thursday. I'm abroad for business at
the moment and unfortunately that leaves me with little time for reviewing.

This is not just true for this driver, but also for the dm365 series that was
posted recently. And possibly others that I missed :-(

Regards,

Hans

 
 Regards,
 
 
 Santiago.
 
 Santiago Nunez-Corrales wrote:
  This series of patches provide support for the TVP7002 decoder in DM365.
 
  Support includes:
 
  * Inclusion of the chip in v4l2 definitions
  * Definition of TVP7002 specific data structures
  * Kconfig and Makefile support
 
  This series corrects many issued pointed out by Snehaprabha Narnakaje,
  Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
  testing problems.  Tested on DM365 TI EVM with resolutions 720p,
  10...@60, 576P and 480P with video capture application and video
  output in 480P, 576P, 720P and 1080I. This driver depends upon
  board-dm365-evm.c and vpfe_capture.c to be ready for complete
  integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
  Removed shadow register values. Removed unnecesary power down and up
  of the device (tests work fine). Improved readability.
 
 
 
 
 -- 
 Santiago Nunez-Corrales, Eng.
 RidgeRun Engineering, LLC
 
 Guayabos, Curridabat
 San Jose, Costa Rica
 +(506) 2271 1487
 +(506) 8313 0536
 http://www.ridgerun.com
 
 
 
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

2009-12-07 Thread Andy Walls

On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
 On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
 
  On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
  Krzysztof Halasa wrote:
  Andy Walls awa...@radix.net writes:
  
  I would also note that RC-6 Mode 6A, used by most MCE remotes, was
  developed by Philips, but Microsoft has some sort of licensing interest
  in it and it is almost surely encumbered somwhow:
  
  I don't know about legal problems in some countries but from the
  technical POV handling the protocol in the kernel is more efficient
  or (/and) simpler.
  
  A software licensing from Microsoft won't apply to Linux kernel, so I'm
  assuming that you're referring to some patent that they could be filled
  about RC6 mode 6A.
  
  I don't know if is there any US patent pending about it (AFAIK, only US
  accepts software patents), but there are some prior-art for IR key
  decoding. So, I don't see what innovation RC6 would be adding. 
  If it is some new way to transmit waves, the patent issues
  aren't related to software, and the device manufacturer had already handled
  it when they made their devices.
  
  If it is just a new keytable, this issue 
  could be easily solved by loading the keytable via userspace.
  
  Also, assuming that you can use the driver only with a hardware that comes
  with a licensed software, the user has already the license for using it.
  
  Do you have any details on what patents they are claiming?
  
  The US Philips RC-6 patent is US Patent 5,877,702
  
  http://www.google.com/patents?vid=USPAT5877702
  
  Click on download PDF to get a copy of the whole patent.
  
  I am not a lawyer.  Philips claims' all appear to tie to a transmitter
  or receiver as part of a system, but most of the claims are about
  information and bit positions and lengths.
 ...
  IMO, given
  
  a. the dearth of public information about RC-6, indicating someone
  thinks it's their trade secret or intellectual property
  
  b. Microsoft claiming to license something related to the MCE remote
  protocols (which are obviously RC-6 Mode 6A),
  
  c. my inability to draw a clear, bright line that RC-6 Mode 6A
  encoding and decoding, as needed by MCE remotes, implemented in software
  doesn't violate anyone's government granted rights to exclusivity.
  
  I think it's much better to implement software RC-6 Mode 6A encoding and
  decoding in user space, doing only the minimum needed to get the
  hardware setup and going in the kernel.  
  
  Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
  worry me. 
  
  
  Maybe I'm being too conservative here, but I have a personal interest in
  keeping Linux free and unencumbered even in the US which, I cannot deny,
  has a patent system that is screwed up.
 
 So I had one of the people who does all the license and patent audits
 for Fedora packages look at the Philips patent on RC-6. He's 100%
 positive that the patent *only* covers hardware, there should be no
 problem whatsoever writing a software decoder for RC-6.

OK.  Thanks for having some professionals take a look.  (I'm assuming
that's the only patent.)

So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
end of the month.

I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
a common set of parameters, so I may be able to set up the decoders to
handle decoding from two different remote types at once.  The HVR boards
can ship with either type of remote AFAIK.

I wonder if I can flip the keytables on the fly or if I have to create
two different input devices?

Regards,
Andy

--
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] What are the goals for the architecture of an in-kernel IR system?

2009-12-07 Thread Andy Walls

On Sun, 2009-12-06 at 16:23 -0500, Jon Smirl wrote:
 On Sun, Dec 6, 2009 at 3:34 PM, Krzysztof Halasa k...@pm.waw.pl wrote:
  Jon Smirl jonsm...@gmail.com writes:
 
  Once again: how about agreement about the LIRC interface
  (kernel-userspace) and merging the actual LIRC code first? In-kernel
  decoding can wait a bit, it doesn't change any kernel-user interface.
 
  I'd like to see a semi-complete design for an in-kernel IR system
  before anything is merged from any source.
 
  This is a way to nowhere, there is no logical dependency between LIRC
  and input layer IR.
 
  There is only one thing which needs attention before/when merging LIRC:
  the LIRC user-kernel interface. In-kernel IR system is irrelevant and,
  actually, making a correct IR core design without the LIRC merged can be
  only harder.
 
 Here's a few design review questions on the LIRC drivers that were posted

I will answer based on my understanding of LIRC as it exists today, but
I'm tired and am not going to dig into too many details I can't find
easily.

(Christoph can correct me if I get anything wrong.)


An architecture drawing can be found here:

http://www.lirc.org/html/technical.html

 How is the pulse data going to be communicated to user space?

Currently that is via lirc_dev which shows up as /dev/lircN (IIRC) in
userspace.

The lirc_dev module is a helper and abstraction layer for other
modules. It registers /dev/lirc device in a system (including support
for devfs) and waits for plugin registration. After that it serves
device requests (open, read, poll, ioctl, close) and if needed calls
callback functions from plugin(s) to communicate with the physical
device.

The function call for hardware drivers to register with lirc_dev from
within kernel space is lirc_register_driver() which requires a structure
with points to hardware specifi operations, IIRC.


 Can the pulse data be reported via an existing interface without
 creating a new one?

Yes.


 Where is the documentation for the protocol?

http://www.lirc.org/html/technical.html


 Is it a device interface or something else?

Device for a kernelspace driver/plugin registering with lirc_dev.


 Does it work with poll, epoll, etc?

lirc_dev has an function irctl_poll() that will call a hardware specifi
poll operation if it exists, otherwise it has default poll logic.


 What is the time standard for the data, where does it come from?

I think it is usec, IIRC.

I know that the hardware I work with has sub 100 ns resolution, so
that's what is used as the basis for v4l2_subdev_ir_ops time values in
kernel.  The conversion to usec is rather trivial.

The hardware I work with is very configurable, but I always use the
BT.656 video pixel clock of of 13.5 MHz * 8 = 108 MHz as the master
frequency reference for all the pulse width measurement circuitry.


 How do you define the start and stop of sequences?

For the end of Rx signalling:

Well with the Conexant hardware I can set a maximum pulse (mark or
space) width, and the hardware will generate an Rx Timeout interrupt to
signal the end of Rx when a space ends up longer than that max pulse
width.  The hardware also puts a special marker in the hardware pulse
widht measurement FIFO (in band signalling essentially).

I'm not sure anything like that gets communicated to userspace via
lirc_dev, and I'm too tired to doublecheck right now.

If you have determined the protocol you are after, it's easy to know
what the pulse count should be and what the max pulse width should be (+
slop for crappy hardware) so finding the end of an Rx isn't hard.  The
button repeats intervals are *very* large.  I've never seen a remote
rapid fire codes back to back.


For the start of a sequence:

Easy, the first mark after a *very* long (10's of msec) space.
You could also look for very long mark header which many protocols (NEC,
RC-6, ...) have to help the IR hardware's AGC get set.


 What about capabilities of the receiver, what frequencies?

LIRC's API has a LIRC_GET_FEATURES ioctl().


 If a receiver has multiple frequencies, how do you report what
 frequency the data came in on?

I'm not sure most hardware can pick up a pulse on an arbitrary freq.
Usually you set a desired carrier and a window.  The windows can be very
generous on some hardware: Fc * 16/20 to Fc * 16/12 (e.g. for 38 kHz
that's 30.4 kHz to 50.667 kHz). 

Hardware can have a special learn mode to really make fine
measurements about the waveform without a specified carrier, but usually
requires some special setup and the user being prompted to take action
to get a good measurement.


 What about multiple apps simultaneously using the pulse data?

LIRC multiplexes a single device node with a daemon in userspace.


 Is receiving synchronous or queued?

kfifo's in lirc_dev IIRC.


 How big is the receive queue?

Device HW FIFO's can have a depth of 1 to 16.

My software queues for CX2388[58] devices are 512 pulse measurments deep
--  overkill except for maybe a protocol with a

Re: [PATCH] sound/usb: Relax urb data alignment restriciton for HVR-950Q only

2009-12-07 Thread Devin Heitmueller

On Fri, Dec 4, 2009 at 6:26 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Fri, Dec 4, 2009 at 5:15 PM, John S Gruber johnsgru...@gmail.com wrote:
 Addressing audio quality problem.

 In sound/usb/usbaudio.c, for the Hauppage HVR-950Q only, change
 retire_capture_urb to copy the entire byte stream while still counting
 entire audio frames. urbs unaligned on channel sample boundaries are
 still truncated to the next lowest stride (audio slot) size to try to
 retain channel alignment in cases of data loss over usb.

 With the HVR950Q the left and right channel samples can be split between
 two different urbs. Throwing away extra channel samples causes a sound
 quality problem for stereo streams as the left and right channels are
 swapped repeatedly.
 snip

 Hello John,

 Thanks for taking the time to dig into this.  I will try to review
 your patch this weekend (in conjunction with the spec).

 It's worth noting that there are actually nine different USB IDs that
 would need this change (see au0828-cards.c), so it might be nice to
 see if we can figure out a way for the au0828 driver to tell the
 usbaudio driver about the quirk without relying on embedding USB ids
 in the usbaudio driver.

Hi John,

After reviewing the patch as well as the spec, your change looks
pretty reasonable (aside from the fact that you need the other USB
IDs).  It seems pretty clear that the au0828 violates the spec, but
the spec does indicate how to handle that case, which is what your
code addresses.

All that said, the driver in question is managed by the ALSA project.
I would suggest posting a message with your patch on the alsa-devel
mailing list, so that it can be merged (and in fairness, those guys
are much better suited to review your patch).

On a separate note, I've been doing some testing with the device in a
low-latency application, and I think I've spotted a separate bug in
the usbaudio driver that causes the audio capture to stall.  I'll be
sending some email myself to alsa-devel as soon as I can test a patch.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Mon, Dec 07, 2009 at 09:42:22PM -0500, Andy Walls wrote:
 On Mon, 2009-12-07 at 13:19 -0500, Jarod Wilson wrote:
  On Nov 26, 2009, at 2:43 PM, Andy Walls wrote:
  
   On Thu, 2009-11-26 at 12:05 -0200, Mauro Carvalho Chehab wrote:
   Krzysztof Halasa wrote:
   Andy Walls awa...@radix.net writes:
   
   I would also note that RC-6 Mode 6A, used by most MCE remotes, was
   developed by Philips, but Microsoft has some sort of licensing interest
   in it and it is almost surely encumbered somwhow:
   
   I don't know about legal problems in some countries but from the
   technical POV handling the protocol in the kernel is more efficient
   or (/and) simpler.
   
   A software licensing from Microsoft won't apply to Linux kernel, so I'm
   assuming that you're referring to some patent that they could be filled
   about RC6 mode 6A.
   
   I don't know if is there any US patent pending about it (AFAIK, only US
   accepts software patents), but there are some prior-art for IR key
   decoding. So, I don't see what innovation RC6 would be adding. 
   If it is some new way to transmit waves, the patent issues
   aren't related to software, and the device manufacturer had already 
   handled
   it when they made their devices.
   
   If it is just a new keytable, this issue 
   could be easily solved by loading the keytable via userspace.
   
   Also, assuming that you can use the driver only with a hardware that 
   comes
   with a licensed software, the user has already the license for using it.
   
   Do you have any details on what patents they are claiming?
   
   The US Philips RC-6 patent is US Patent 5,877,702
   
   http://www.google.com/patents?vid=USPAT5877702
   
   Click on download PDF to get a copy of the whole patent.
   
   I am not a lawyer.  Philips claims' all appear to tie to a transmitter
   or receiver as part of a system, but most of the claims are about
   information and bit positions and lengths.
  ...
   IMO, given
   
   a. the dearth of public information about RC-6, indicating someone
   thinks it's their trade secret or intellectual property
   
   b. Microsoft claiming to license something related to the MCE remote
   protocols (which are obviously RC-6 Mode 6A),
   
   c. my inability to draw a clear, bright line that RC-6 Mode 6A
   encoding and decoding, as needed by MCE remotes, implemented in software
   doesn't violate anyone's government granted rights to exclusivity.
   
   I think it's much better to implement software RC-6 Mode 6A encoding and
   decoding in user space, doing only the minimum needed to get the
   hardware setup and going in the kernel.  
   
   Encoding/decoding of RC-6 by microcontrollers with firmware doesn't
   worry me. 
   
   
   Maybe I'm being too conservative here, but I have a personal interest in
   keeping Linux free and unencumbered even in the US which, I cannot deny,
   has a patent system that is screwed up.
  
  So I had one of the people who does all the license and patent audits
  for Fedora packages look at the Philips patent on RC-6. He's 100%
  positive that the patent *only* covers hardware, there should be no
  problem whatsoever writing a software decoder for RC-6.
 
 OK.  Thanks for having some professionals take a look.  (I'm assuming
 that's the only patent.)
 
 So I'll whip up an RC-6 Mode 6A decoder for cx23885-input.c before the
 end of the month.
 
 I can setup the CX2388[58] hardware to look for both RC-5 and RC-6 with
 a common set of parameters, so I may be able to set up the decoders to
 handle decoding from two different remote types at once.  The HVR boards
 can ship with either type of remote AFAIK.
 
 I wonder if I can flip the keytables on the fly or if I have to create
 two different input devices?
 

Can you distinguish between the 2 remotes (not receivers)? Like I said,
I think the preferred way is to represent every remote that can be
distinguished from each other as a separate input device. Applications
expect to query device capabilities and expect them to stay somewhat
stable (we do support keymap change but I don't think anyone expectes
flip-flopping).

-- 
Dmitry
--
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] What are the goals for the architecture of an in-kernel IR system?