On 25/03/15 16:45, Philipp Zabel wrote:
Issuing a cache flush for the whole bitstream buffer is not optimal in the first
place when only a part of it was written. But given that the buffer is mapped in
writecombine mode, it is not needed at all.
Signed-off-by: Philipp Zabel
Tested-by: Ian
Hi folks,
I've been discussing some issues with the CODA driver on gstreamer-devel and
the thread seems better suited to this list;
Here's a copy of what's been said thus far:
I wrote:
I've located the cause of the "giant oops" I noted a couple of days ago.
because ctx->
> Fixed kernel WARNINGs for me! \o/
> Ian, perhaps it makes sense for me to take these patches into my hands?
I'm planning to respin these tomorrow - is that OK? I have test hardware with
two different frontends here.
-Ian
--
To unsubscribe from this list: send the line "unsubscribe lin
et.
>
> Valid values are?
Chip dependent. 0 for 7611, 0-1 for 7612, I expect there are other chips in the
family with differing numbers of inputs.
> > +if (!of_property_read_u32(endpoint, "default_input", &v))
>
> This doesn't match the binding
ay of formats,
to allow the 7180 driver to select a YUV mode?? but I cant for the life of me
understand what. I'm fairly new to v4l2, so I dont really know whats legit and
what isnt. particularly, the code appears to abuse one "code" to provide
several (incompatible?) formats.
H
This small patch series adds initial support for the adv7612 dual HDMI input
decoder chip and adds a device-tree option allowing the default input to be
selected.
Please review / apply,
-Ian
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to maj
This patch adds support to the adv7604 driver for reading the default
selected input from the Device tree. If none is provided, the driver will not
select an input without help from userspace.
Tested-by: William Towle
Signed-off-by: Ian Molton
---
Documentation/devicetree/bindings/media/i2c
This patch adds necessary support for the ADV7612 dual HDMI decoder / repeater
chip.
This was tested using a heavily modified rcar_vin/soc_camera capture driver.
Tested-by: William Towle
Signed-off-by: Ian Molton
---
.../devicetree/bindings/media/i2c/adv7604.txt | 17 +++
drivers
ped. The buffer we have been asked
> > * to release could be any of the current buffers in use, so
> > @@ -517,12 +527,15 @@ static void rcar_vin_stop_streaming(struct vb2_queue
> > *vq)
> >
> > spin_lock_irq(&priv->lock);
> >
> > +
On Tue, 08 Jul 2014 20:09:58 +0400
Sergei Shtylyov wrote:
> Hello.
Hi,
> > Signed-off-by: Ian Molton
> > Signed-off-by: William Towle
> > ---
> > drivers/media/platform/soc_camera/rcar_vin.c | 43
> > ++--
> > 1 file
select mutually acceptable data formats, but
the calls to get/set resolution seem to use fh's
I will persist with approach 2 then for now.
--
Ian Molton
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
M
e struggling to see a clear path through
this. Whatever we do, we would like to be acceptable upstream, so we'd like to
open a discussion.
Perhaps a soc_camera2 with pads support?
--
Ian Molton
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
t
rcar_vin_videobuf_release() is called once per buffer from the buf_cleanup hook.
There is no need to look up the queue and free all buffers at this point.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 +++-
1 file changed
finish prior to finalising these buffers.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 43 ++--
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b
This patch makes the rcar_vin IRQ handler a little more readable.
Removes an else clause, and simplifies the buffer handling.
Signed-off-by: Ian Molton
Reviewed-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 14 insertions
Resent to include the author and a couple of other interested parties :)
This patch series provides fixes that allow the rcar_vin driver to function
without triggering dozens of warnings from the videobuf2 and soc_camera layers.
Patches 2/3 should probably be merged into a single, atomic change,
at this point.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 7154500..06ce705
rcar_vin_videobuf_release() is called once per buffer from the buf_cleanup hook.
There is no need to look up the queue and free all buffers at this point.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 12 +++-
1 file changed
This patch series provides fixes that allow the rcar_vin driver to function
without triggering dozens of warnings from the videobuf2 and soc_camera layers.
Patches 2/3 should probably be merged into a single, atomic change, although
patch 2 does not make the existing situation /worse/ in and of it
This patch makes the rcar_vin IRQ handler a little more readable.
Removes an else clause, and simplifies the buffer handling.
Signed-off-by: Ian Molton
Reviewed-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 24 ++--
1 file changed, 14 insertions
at this point.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 7154500..06ce705
finish prior to finalising these buffers.
Signed-off-by: Ian Molton
Signed-off-by: William Towle
---
drivers/media/platform/soc_camera/rcar_vin.c | 43 ++--
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b
ocations quite
differently from other soc_camera drivers.
Does anyone have any guidance on how to proceed? Clearly the state machine is
being violated here, but I'm at a loss as to how its actually *supposed* to
operate. Is there any good documentation?
--
Ian Molton
--
To unsubscribe fro
oc_camera drivers.
Does anyone have any guidance on how to proceed? Clearly the state machine is
being violated here, but I'm at a loss as to how its actually *supposed* to
operate. Is there any good documentation?
--
Ian Molton
--
To unsubscribe from this list: send the line "unsubscri
;
> On Mon, 9 Nov 2009, Ian Molton wrote:
>
>> Well, I presume we want to know when the card gets removed :)
>
> Sure, that's why we shouldn't mask those interrupts:-) If they do get
> masked and missed, I do not know, if the interrupt remains pending in this
> ca
25 matches
Mail list logo