On Thu, 2011-04-28 at 17:13 +0200, David Härdeman wrote:
> The following series is what's in my current patch queue for rc-core.
>
> It only been lightly tested so far and it's based on the "for_v2.6.39" branch,
> but I still wanted to send it to the list so that I can get some feedback
> while
>
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:Thu Apr 28 19:00:31 CEST 2011
git hash:a4761a092fd3b6bf8b5f9cfe361670c86cdcc8ca
gcc version: i686-linux-gcc (GCC) 4.5
On Fri, 26 Nov 2010 08:17:36 -0800 Randy Dunlap wrote:
> On Fri, 26 Nov 2010 17:15:11 +0100 Michal Marek wrote:
>
> > On Fri, Nov 26, 2010 at 11:31:16AM +0100, Michal Marek wrote:
> > > On 25.11.2010 18:06, Arnaud Lacombe wrote:
> > > > Hi folks,
> > > >
> > > > On Sat, Nov 6, 2010 at 5:30 PM, A
Mauro,
Please pull in these four changes (against Linus' tree) for 2.6.39. The
critical piece here is the imon patch, which fixes a nasty deadlock that
triggers when change_protocol is initiated from userspace (i.e., by
ir-keytable), followed by use of an imon device's display (or simply a
second
Dear list,
I try to get the "new" tt-1500 model using the BSBE1-D01A tuner to work with a
diseqc switch.
Currently I am working with a Gentoo 2.6.36 kernel patched with this patch
(http://www.mail-archive.com/linux-media@vger.kernel.org/msg29871.html) by Oliver Endriss. This runs
great if the
The lirc TX functionality expects the process which writes (TX) data to
the lirc dev to sleep until the actual data has been transmitted by the
hardware.
Since the same timeout calculation is duplicated in more than one driver
(and would have to be duplicated in even more drivers as they gain TX
s
Durations can never be negative, so it makes sense to consistently use
unsigned int for LIRC transmission. Contrary to the initial impression,
this shouldn't actually change the userspace API.
Signed-off-by: David Härdeman
---
drivers/media/rc/ene_ir.c|4 ++--
drivers/media/rc/ene_ir
Now that the protocol is part of the scancode, it is pretty easy to merge
the rc5 and streamzap decoders. An additional advantage is that the decoder
is now stricter as it waits for the trailing silence before determining that
a command is a valid rc5/streamzap command (which avoids collisions that
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality.
Signed-off-by: David Härdeman
---
drivers/media/dvb/dvb-usb/af9015.c | 22 ++
drivers/media/rc/ir-nec-decoder.c | 28 --
If an IR command is sent (using the LIRC userspace) to rc-loopback
which doesn't include a trailing space, the result is that the message
won't be completely decoded. In addition, "leftovers" from a previous
transmission can be left until the next one. Fix this by faking a long
silence after the en
This patch adds preliminary IR TX capabilities to the
winbond-cir driver.
Signed-off-by: David Härdeman
---
drivers/media/rc/winbond-cir.c | 431 +---
1 files changed, 356 insertions(+), 75 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/m
Using ir_raw_event_store_with_filter() saves about 20 lines of code.
Signed-off-by: David Härdeman
---
drivers/media/rc/winbond-cir.c | 63 +---
1 files changed, 21 insertions(+), 42 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/r
Using bool instead of an int helps readability a bit.
Signed-off-by: David Härdeman
---
drivers/media/rc/winbond-cir.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/rc/winbond-cir.c b/drivers/media/rc/winbond-cir.c
index b0a5fdc..cdb5ef4 10
The following series is what's in my current patch queue for rc-core.
It only been lightly tested so far and it's based on the "for_v2.6.39" branch,
but I still wanted to send it to the list so that I can get some feedback while
I refresh the patches to "for_v2.6.40" and do more testing.
The most
Yupeng,
Can you take a look at this as well? After all, Qualcomm is one of the
intended users.
Regards,
Hans
On Thursday, April 28, 2011 14:46:27 Hans de Goede wrote:
> Hi,
>
> First of all my apologies for taking so long to get around to
> reviewing this.
>
> Over all it looks good,
Hans de Goede wrote:
> Hi,
Hi Hans, Yordan,
> First of all my apologies for taking so long to get around to
> reviewing this.
>
> Over all it looks good, I've put some small remarks inline, if
> you fix these I can merge this. I wonder though, given the recent
> limbo around Nokia's change of fo
Hi,
First of all my apologies for taking so long to get around to
reviewing this.
Over all it looks good, I've put some small remarks inline, if
you fix these I can merge this. I wonder though, given the recent
limbo around Nokia's change of focus, if there are any plans to
actually move forward
> -Original Message-
> From: ext Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 28. huhtikuuta 2011 14:15
> To: Jokiniemi Kalle (Nokia-SD/Tampere)
> Cc: l...@slimlogic.co.uk; mche...@infradead.org; svarba...@mm-sol.com;
> saagui...@ti.com; grosikopu...@mm-sol.com; Z
Hi Bastian,
On Thursday 28 April 2011 13:04:15 Bastian Hecht wrote:
> 2011/4/27 Laurent Pinchart :
> > On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote:
> >> 2011/4/27 Bastian Hecht :
> >> > 2011/4/26 Laurent Pinchart :
> >> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
> >> >>>
On Thu, Apr 28, 2011 at 11:08:08AM +, kalle.jokini...@nokia.com wrote:
> I don't have a full set of regulators described, that's why things broke when
> I tried the regulator_full_constraints call earlier. But I don't think it
> would be too
> big issue to check the current after boot configu
Hi,
> -Original Message-
> From: ext Mark Brown [mailto:broo...@opensource.wolfsonmicro.com]
> Sent: 28. huhtikuuta 2011 13:06
> To: Jokiniemi Kalle (Nokia-SD/Tampere)
> Cc: l...@slimlogic.co.uk; mche...@infradead.org; svarba...@mm-sol.com;
> saagui...@ti.com; grosikopu...@mm-sol.com
Mark Brown wrote:
> On Thu, Apr 28, 2011 at 01:27:46PM +0300, Sakari Ailus wrote:
>> Mark Brown wrote:
>
>>> I'm not sure what "supply_nasty" would mean? This also doesn't seem
>>> like something that we can set up per supply - it's going to affect the
>>> whole regulator state, it's not somethin
2011/4/27 Laurent Pinchart :
> Hi Bastian,
>
> On Wednesday 27 April 2011 12:55:24 Bastian Hecht wrote:
>> 2011/4/27 Bastian Hecht :
>> > 2011/4/26 Laurent Pinchart :
>> >> On Tuesday 26 April 2011 17:39:41 Bastian Hecht wrote:
>> >>> 2011/4/21 Laurent Pinchart :
>> >>> > On Tuesday 19 April 2011 0
On Thu, Apr 28, 2011 at 01:27:46PM +0300, Sakari Ailus wrote:
> Mark Brown wrote:
> > I'm not sure what "supply_nasty" would mean? This also doesn't seem
> > like something that we can set up per supply - it's going to affect the
> > whole regulator state, it's not something that only affects a s
Hello all
Before anythings, i beg pardon of whom the matter of this e-mail is
not related to; please excuse me.
--
Unfortunately i could not until now, use any DVB hardware on any
version of linux; i tested many of them but none o
Mark Brown wrote:
> On Thu, Apr 28, 2011 at 09:44:10AM +, kalle.jokini...@nokia.com wrote:
>
>> > Another alternative to the first option you proposed could be to add a
>> > flags field to regulator_consumer_supply, and use a flag to recognise
>> > regulators which need to be disabled durin
On Thu, Apr 28, 2011 at 09:44:10AM +, kalle.jokini...@nokia.com wrote:
> > Another alternative to the first option you proposed could be to add a
> > flags field to regulator_consumer_supply, and use a flag to recognise
> > regulators which need to be disabled during initialisation. The fla
On Thu, Apr 28, 2011 at 09:01:03AM +, kalle.jokini...@nokia.com wrote:
> If the device driver using the regulator does not enable and disable the
> regulator after regulator_get, the regulator is left in the state that it was
> after bootloader. In case of N900 this is a problem as the regulat
hello Patrick,
Did you have the time to look into this issue? I noticed tuning is more
reliable using a devel vdr (1.7.17): this vdr version seems to use a good
strategy if the device fails to lock in it's first attempt. The stable vdr
(1.6.0), kaffeine (1.2) and tzap still fail to lock with ke
Hi,
> -Original Message-
> From: Sakari Ailus [mailto:sakari.ai...@nokia.com]
> Sent: 28. huhtikuuta 2011 12:34
> To: Jokiniemi Kalle (Nokia-SD/Tampere)
> Cc: broo...@opensource.wolfsonmicro.com; l...@slimlogic.co.uk;
> mche...@infradead.org; svarba...@mm-sol.com; saagui...@ti.com;
Hello,
Jokiniemi Kalle (Nokia-SD/Tampere) wrote:
> Hello regulator FW and OMAP3 ISP fellows,
>
> I'm currently optimizing power management for Nokia N900 MeeGo DE release,
> and found an issue with how regulators are handled at boot.
>
> The N900 uses VAUX2 regulator in OMAP3430 to power the CSI
>
> Please try the patch at
>
> http://thread.gmane.org/gmane.linux.ports.arm.omap/56662
>
That fixed it, thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscr
Hello regulator FW and OMAP3 ISP fellows,
I'm currently optimizing power management for Nokia N900 MeeGo DE release,
and found an issue with how regulators are handled at boot.
The N900 uses VAUX2 regulator in OMAP3430 to power the CSIb IO complex
that is used by the camera. While implementing re
33 matches
Mail list logo
