Em Sat, 15 Dec 2012 03:12:58 +0200
Antti Palosaari escreveu:
> On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
> > Em Sat, 15 Dec 2012 02:56:25 +0200
> > Antti Palosaari escreveu:
> >
> >> NACK. NEC variant selection logic is broken by design.
> >
> > If you think so, then feel free to fix
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari escreveu:
> On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
> > Em Fri, 14 Dec 2012 17:39:50 -0200
> > Mauro Carvalho Chehab escreveu:
> >
> >>> Anyway, first we have to GET the bytes from the hardware. That's our
> >>> current problem !
>
On 12/15/2012 03:03 AM, Mauro Carvalho Chehab wrote:
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari escreveu:
NACK. NEC variant selection logic is broken by design.
If you think so, then feel free to fix it without causing regressions to
the existing userspace.
While you don't do it, I
Em Sat, 15 Dec 2012 02:56:25 +0200
Antti Palosaari escreveu:
> NACK. NEC variant selection logic is broken by design.
If you think so, then feel free to fix it without causing regressions to
the existing userspace.
While you don't do it, I don't see anything wrong on this patch, as it
will beha
On 12/15/2012 02:26 AM, Mauro Carvalho Chehab wrote:
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab escreveu:
Anyway, first we have to GET the bytes from the hardware. That's our
current problem !
And the hardware seems to need a different setup for reg 0x50 for the
different NEC sub
Em Fri, 14 Dec 2012 22:26:31 -0200
Mauro Carvalho Chehab escreveu:
> Em Fri, 14 Dec 2012 17:39:50 -0200
> Mauro Carvalho Chehab escreveu:
>
> > > Anyway, first we have to GET the bytes from the hardware. That's our
> > > current problem !
> > > And the hardware seems to need a different setup f
Em Fri, 14 Dec 2012 17:39:50 -0200
Mauro Carvalho Chehab escreveu:
> > Anyway, first we have to GET the bytes from the hardware. That's our
> > current problem !
> > And the hardware seems to need a different setup for reg 0x50 for the
> > different NEC sub protocols.
> > Which means that the we
On Fri, Dec 14, 2012 at 6:02 PM, Antti Palosaari wrote:
> That one is better solution...
>
> but it is clearly DRXD driver bug - it should offer working I2C gate control
> after attach() :-( I looked quickly DRXD driver and there is clearly some
> other places to enhance too. But I suspect there
On 12/15/2012 12:31 AM, Patrice Chotard wrote:
Le 14/12/2012 18:55, Antti Palosaari a écrit :
On 12/14/2012 07:28 PM, Patrice Chotard wrote:
Before dvb_pll_attch call, be sure that drxd demodulator was
initialized, otherwise, dvb_pll_attach() will always failed.
In dvb_pll_attach(), first thin
Le 14/12/2012 18:55, Antti Palosaari a écrit :
> On 12/14/2012 07:28 PM, Patrice Chotard wrote:
>> Before dvb_pll_attch call, be sure that drxd demodulator was
>> initialized, otherwise, dvb_pll_attach() will always failed.
>>
>> In dvb_pll_attach(), first thing done is to enable the I2C gate
>> co
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Fri Dec 14 19:00:32 CET 2012
git hash:16427faf28674451a7a0485ab0a929402f355ffd
gcc version: i686-linux-gcc (GCC
Em Fri, 14 Dec 2012 16:33:34 +0100
Frank Schäfer escreveu:
> Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> > Em Tue, 11 Dec 2012 22:59:06 +0200
> > Antti Palosaari escreveu:
> >
> >> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
> >>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
> O
* Timo Kokkonen [121214 11:33]:
> On 12/14/12 19:26, Felipe Balbi wrote:
> >
> > if it's really for PWM, shouldn't we be using drivers/pwm/ ??
> >
>
> Now that Neil Brown posted the PWM driver for omap, I've been thinking
> about whether converting the ir-rx51 into the PWM API would work. Maybe
On 12/14/12 19:26, Felipe Balbi wrote:
> Hi,
>
> On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
>> * Tony Lindgren [121120 12:00]:
>>> Hi,
>>>
>>> * Timo Kokkonen [121118 07:15]:
--- a/drivers/media/rc/ir-rx51.c
+++ b/drivers/media/rc/ir-rx51.c
@@ -74,6 +74,19 @@ s
Hi,
On Fri, Dec 14, 2012 at 10:06:45AM -0800, Tony Lindgren wrote:
> * Felipe Balbi [121214 09:59]:
> > On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote:
> > > * Felipe Balbi [121214 09:36]:
> > > >
> > > > if it's really for PWM, shouldn't we be using drivers/pwm/ ??
> > > >
> >
* Felipe Balbi [121214 09:59]:
> On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote:
> > * Felipe Balbi [121214 09:36]:
> > >
> > > if it's really for PWM, shouldn't we be using drivers/pwm/ ??
> > >
> > > Meaning that $SUBJECT would just request a PWM device and use it. That
> > > d
Hi,
On Fri, Dec 14, 2012 at 09:46:29AM -0800, Tony Lindgren wrote:
> * Felipe Balbi [121214 09:36]:
> > Hi,
> >
> > On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
> > > * Tony Lindgren [121120 12:00]:
> > > > Hi,
> > > >
> > > > * Timo Kokkonen [121118 07:15]:
> > > > > --- a/
On 12/14/2012 07:28 PM, Patrice Chotard wrote:
Before dvb_pll_attch call, be sure that drxd demodulator was
initialized, otherwise, dvb_pll_attach() will always failed.
In dvb_pll_attach(), first thing done is to enable the I2C gate
control in order to probe the pll by performing a read access.
* Felipe Balbi [121214 09:36]:
> Hi,
>
> On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
> > * Tony Lindgren [121120 12:00]:
> > > Hi,
> > >
> > > * Timo Kokkonen [121118 07:15]:
> > > > --- a/drivers/media/rc/ir-rx51.c
> > > > +++ b/drivers/media/rc/ir-rx51.c
> > > > @@ -74,6 +
Hi,
On Fri, Dec 14, 2012 at 09:28:09AM -0800, Tony Lindgren wrote:
> * Tony Lindgren [121120 12:00]:
> > Hi,
> >
> > * Timo Kokkonen [121118 07:15]:
> > > --- a/drivers/media/rc/ir-rx51.c
> > > +++ b/drivers/media/rc/ir-rx51.c
> > > @@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51
Before dvb_pll_attch call, be sure that drxd demodulator was
initialized, otherwise, dvb_pll_attach() will always failed.
In dvb_pll_attach(), first thing done is to enable the I2C gate
control in order to probe the pll by performing a read access.
As demodulator was not initialized, every i2c acc
* Tony Lindgren [121120 12:00]:
> Hi,
>
> * Timo Kokkonen [121118 07:15]:
> > --- a/drivers/media/rc/ir-rx51.c
> > +++ b/drivers/media/rc/ir-rx51.c
> > @@ -74,6 +74,19 @@ static void lirc_rx51_off(struct lirc_rx51 *lirc_rx51)
> > OMAP_TIMER_TRIGGER_NONE);
> > }
> >
>
On 12/14/2012 06:28 PM, Frank Schäfer wrote:
- check i2c slave address range (only 7 bit addresses supported)
- do not pass USB specific error codes to userspace/i2c-subsystem
- unify the returned error codes and make them compliant with
the i2c subsystem spec
- check number of actually transf
On 12/14/2012 06:28 PM, Frank Schäfer wrote:
The em2800 can transfer up to 4 bytes per i2c message.
All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per message.
I2C adapters should never split messages transferred via the I2C subsystem
into multiple message transfers, because t
On 12/14/2012 06:32 PM, Antti Palosaari wrote:
On 12/14/2012 05:33 PM, Frank Schäfer wrote:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosa
On 12/14/2012 05:33 PM, Frank Schäfer wrote:
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
Em Tue, 11 Dec 2012 22:59:06 +0200
Antti Palosaari escreveu:
On 12/11/2012 10:51 PM, Frank Schäfer wrote:
Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrot
I2C_FUNC_SMBUS_EMUL includes flag I2C_FUNC_SMBUS_WRITE_BLOCK_DATA which signals
that up to 31 data bytes can be written to the ic2 client.
But the EM2800 supports only i2c messages with max. 4 data bytes.
I2C_FUNC_IC2 should be set if a master_xfer fucntion pointer is provided in
struct i2c_algorit
- check i2c slave address range (only 7 bit addresses supported)
- do not pass USB specific error codes to userspace/i2c-subsystem
- unify the returned error codes and make them compliant with
the i2c subsystem spec
- check number of actually transferred bytes (via USB) everywehere
- fix/improve
Function em2800_i2c_recv_bytes() has 2 severe bugs:
1) It does not wait for the i2c read to complete before reading the received
message content from the bridge registers
2) Reading more than 1 byte doesn't work
The former can result in data corruption, the latter always does.
The rewritten co
The em2800 can transfer up to 4 bytes per i2c message.
All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per message.
I2C adapters should never split messages transferred via the I2C subsystem
into multiple message transfers, because the result will almost always NOT be
the same as
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-i2c.c | 28 +++-
1 Datei geändert, 11 Zeilen hinzugefügt(+), 17 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
b/drivers/media/usb/em28xx/em28xx-i2c.c
index 1683bd9..44533e4 100644
This patch series contains some I2C bug fixes / cleanups / unifications and
improvements for the em28xx driver, which I've made while working on adding
support for the em25xx/em276x i2c bus B support and playing with the
Terratec Cinergy 200 USB which I've got recently.
Patches 1 and 5 are clea
Am 14.12.2012 16:29, schrieb Devin Heitmueller:
Yes, there will likely be heavy merge conflicts...
In which tree are the videobuf2 patches ?
>>> It's in a private tree right now, and it doesn't support VBI
>>> currently. Once I've setup a public tree with yours and Hans changes,
>>> I'll
Am 13.12.2012 21:23, schrieb Mauro Carvalho Chehab:
> Em Tue, 11 Dec 2012 22:59:06 +0200
> Antti Palosaari escreveu:
>
>> On 12/11/2012 10:51 PM, Frank Schäfer wrote:
>>> Am 10.12.2012 21:48, schrieb Antti Palosaari:
On 12/10/2012 09:24 PM, Frank Schäfer wrote:
> Am 10.12.2012 18:57, schr
>>> Yes, there will likely be heavy merge conflicts...
>>> In which tree are the videobuf2 patches ?
>> It's in a private tree right now, and it doesn't support VBI
>> currently. Once I've setup a public tree with yours and Hans changes,
>> I'll start merging in my changes.
>
> I suggest to do the
Am 13.12.2012 19:16, schrieb Devin Heitmueller:
> On Thu, Dec 13, 2012 at 12:56 PM, Frank Schäfer
> wrote:
>> Am 13.12.2012 18:36, schrieb Devin Heitmueller:
>>> On Sat, Dec 8, 2012 at 10:31 AM, Frank Schäfer
>>> wrote:
This patch series refactors the frame data processing code in
em28
Op 14-12-12 15:11, Rob Clark schreef:
> On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
> wrote:
>> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>>> From: Sumit Semwal
>>>
>>> Add debugfs support to make it easier to print debug information
>>> about the dma-buf buffers.
>>>
>> I like the i
Hi all,
As discussed in Barcelona I would write a text describing requirements for new
drivers and what to expect when submitting patches to linux-media.
This is the second rough draft and nothing is fixed yet.
I have incorporated all comments I received after I posted the first version,
althoug
Hi Jean-Philippe,
I have had exactly the same problem and the following workaround has
caused no regression on our board yet.
I can't explain exactly why it works and I think that it is internal to
the isp.
In function ccdc_set_stream, don't disable the ccdc_subclk when stopping
capture:
On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst
wrote:
> Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
>> From: Sumit Semwal
>>
>> Add debugfs support to make it easier to print debug information
>> about the dma-buf buffers.
>>
> I like the idea, I don't know if it could be done in a free m
Op 14-12-12 10:36, sumit.sem...@ti.com schreef:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
I like the idea, I don't know if it could be done in a free manner, but for
bonus points
could we also have the dma-buf fd be ob
During modiles initialization rc-core schedules work which calls
request_module() several times to load ir-*-decoder modules, but
it does not wait or cancel this work on module unloading.
rc-core should use request_module_nowait() instead, because it
anyway cannot load modules synchronously or can
Missed one ...
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> + list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
> + seq_printf(s, "\t\t");
> +
> + seq_printf(s, "%s\n", attach_obj->dev->init_name);
> + att
On Fri, Dec 14, 2012 at 10:36 AM, wrote:
> From: Sumit Semwal
>
> Add debugfs support to make it easier to print debug information
> about the dma-buf buffers.
>
> Signed-off-by: Sumit Semwal
Looks line, only nitpick is that we have no idea who exported a given
buffer. So what about adding a n
From: Sumit Semwal
Add debugfs support to make it easier to print debug information
about the dma-buf buffers.
Signed-off-by: Sumit Semwal
---
drivers/base/dma-buf.c | 149 +++
include/linux/dma-buf.h |6 +-
2 files changed, 154 insertions(+),
45 matches
Mail list logo
