Helen Koike
Jacopo Mondi
Laurent Pinchart
Niklas Söderlund
Hans Verkuil
If I missed someone, or you are on the list but won't attend after all, then
please let me know.
Could I be added to the list please?
Dave Stevenson
Attendees: it is probably useful if you let us know whether you ha
Hi Nicolas
On Fri, 28 Jun 2019 at 16:48, Nicolas Dufresne wrote:
>
> Le vendredi 28 juin 2019 à 16:21 +0100, Dave Stevenson a écrit :
> > Hi Hans
> >
> > On Fri, 28 Jun 2019 at 15:34, Hans Verkuil wrote:
> > > Hi all,
> > >
> > >
Hi Stefan
On Fri, 28 Jun 2019 at 17:57, Stefan Wahren wrote:
>
> Hi Hans,
>
> Am 28.06.19 um 10:06 schrieb Hans Verkuil:
> > Hi Stefan,
> >
> > On 6/27/19 8:55 PM, Stefan Wahren wrote:
> >> This is an attempt to help Dave Stevenson to get all the fixes and
dware produces the equivalent to V4L2_FIELD_INTERLACED_[TB|BT].
The encoder currently spits out the H264 SPS/PPS headers as a separate
V4L2 buffer, and then one compressed frame per V4L2 buffer (provided
the buffer is big enough). Should
V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER be set, then it will repeat the
headers in an independent V4L2 buffer before each I frame.
I'm quite happy to amend this should we have a decent spec of what is
required. As I've never found a spec it's been trial and error until
now.
There is no interlaced support available.
Dave
Hi Stefan
Firstly a huge thank you for picking this up - it's been on my to-do
list for ages, and just hasn't made it to the top.
On Fri, 28 Jun 2019 at 09:06, Hans Verkuil wrote:
>
> Hi Stefan,
>
> On 6/27/19 8:55 PM, Stefan Wahren wrote:
> > This is an attempt t
Hi Nicolas
On Thu, 27 Jun 2019 at 20:55, Nicolas Dufresne wrote:
>
> Hi Dave,
>
> Le jeudi 27 juin 2019 à 20:55 +0200, Stefan Wahren a écrit :
> > From: Dave Stevenson
> >
> > H264 header come from VC with 0 timestamps, which means they get a
> > strange tim
608fbcf166 ("media: v4l: event: Prevent freeing event subscriptions
> while accessed")
>
> Reported-by: Dave Stevenson
> Signed-off-by: Sakari Ailus
Tested-By: Dave Stevenson
Tested with 3 bcm2835 drivers (camera driver in staging, CSI2
receiver, and codec M2M driver) via
uot;media: v4l: event: Prevent freeing event subscriptions
> while accessed")
>
> Reported-by: Dave Stevenson
> Signed-off-by: Sakari Ailus
> ---
> Hi Dave, Hans,
>
> This should address the issue.
>
> The functions can (and probably should) be re-arranged later but l
Hi Hans
On Mon, 5 Nov 2018 at 13:18, Hans Verkuil wrote:
>
> On 11/05/2018 01:21 PM, Dave Stevenson wrote:
> > Hi All
> >
> > I'm testing with 4.19 and finding that testEvents in v4l2-compliance
> > is failing with ""failed to find event for control
warn for <2.0"
Could someone test on other hardware to confirm that it's not the
drivers I'm using? I'm fairly certain it isn't as that patch does call
sev->ops->add(sev, elems); before list_add(&sev->list,
&fh->subscribed), and that is guaranteed to fail if sev->ops->add
immediately queues an event.
Thanks
Dave
ting to shift to using V4L2 M2M for codecs on as many platforms
as possible. They'll use it wrapped by FFmpeg, and they're working on
patches to get FFmpeg exporting dmabufs to be consumed by DRM.
Hans had pointed me at your patch, and I've been using it to get
around the issue.
I d
defines the MJPEG-A and MJPEG-B variants [1].
MJPEG-B is not a concatenation of JPEG frames as the framing is
different, so can't really be combined into V4L2_PIX_FMT_JPEG.
Have people encountered devices that produce MJPEG-A or MJPEG-B via
V4L2? I haven't, but I have been forced to sup
Hi Laurent
On 19 May 2018 at 08:04, Laurent Pinchart
wrote:
> Hi Dave,
>
> On Friday, 18 May 2018 18:37:01 EEST Dave Stevenson wrote:
>> On 18 May 2018 at 16:05, Mauro Carvalho Chehab wrote:
>> > Em Fri, 18 May 2018 15:27:24 +0300
>>
>>
>>
>> >
on't do it.
To avoid ambiguity, the Pi has a hardware ISP block. There are other
SoCs that use either GPU code or a DSP to implement their ISP.
Dave
On 26 April 2018 at 17:25, Dave Stevenson
wrote:
> Hi All.
>
> I'm trying to get a V4L2 M2M driver sorted for the Raspberry Pi to
> allow access to the video codecs. Much of it is working fine.
>
> One thing that isn't clear relates to video decode. Do
On 3 May 2018 at 23:45, Daniel Vetter wrote:
> On Thu, May 3, 2018 at 2:06 PM, Laurent Pinchart
> wrote:
>> Hi Dave,
>>
>> Ping ?
>
> Not aware of any crc core work going on in drm, so has my ack. Worst
> case we do a topic branch or something like that (since I
?
I could handle it either way, but there are some performance tweaks I
can do if I know the data must be framed.
Thanks in advance.
Dave
ork
> properly for these modified functions.
>
> Miscellanea:
>
> o Remove extra trailing ; and blank line from xfs_agf_verify
>
> Signed-off-by: Joe Perches
> ---
XFS bits look fine.
Acked-by: Dave Chinner
--
Dave Chinner
da...@fromorbit.com
On 21 November 2017 at 20:54, Eric Anholt wrote:
> Rob Herring writes:
>
>> On Tue, Nov 21, 2017 at 1:26 PM, Eric Anholt wrote:
>>> Dave Stevenson writes:
>>>
>>>> Hi Rob
>>>>
>>>> On 27 September 2017 at 22:51, Rob Herring wro
Hi Sakari.
On 13 October 2017 at 22:09, Sakari Ailus wrote:
> Hi Dave,
>
> On Wed, Sep 20, 2017 at 05:07:54PM +0100, Dave Stevenson wrote:
>> New helper function char *v4l2_fourcc2s(u32 fourcc, char *buf)
>> that converts a fourcc into a nice printable version.
>
Hi Rob
On 27 September 2017 at 22:51, Rob Herring wrote:
> On Fri, Sep 22, 2017 at 05:07:22PM +0100, Dave Stevenson wrote:
>> Hi Stefan
>>
>> On 22 September 2017 at 07:45, Stefan Wahren wrote:
>> > Hi Dave,
>> >
>> >> Dave Stevenson ha
tly active lanes, add a new
> bitfield to the v4l2_mbus_config flags. This is a temporary fix, to be
> used only until a better solution is found.
>
> Signed-off-by: Philipp Zabel
Tested-by: Dave Stevenson
> ---
> Changes since v1:
> - Check csi_lanes_in_use <= num_data_lane
On 22 September 2017 at 18:17, Hans Verkuil wrote:
> On 22/09/17 18:31, Dave Stevenson wrote:
>> On 22 September 2017 at 12:00, Hans Verkuil wrote:
>>> On 13/09/17 17:49, Dave Stevenson wrote:
>>>> OV5647
>>>>
>>>> v4l2-compliance SHA : f6e
On 22 September 2017 at 12:00, Hans Verkuil wrote:
> On 13/09/17 17:49, Dave Stevenson wrote:
>> OV5647
>>
>> v4l2-compliance SHA : f6ecbc90656815d91dc6ba90aac0ad8193a14b38
>>
>> Driver Info:
>> Driver name : unicam
>> Card type :
Hi Stefan
On 22 September 2017 at 07:45, Stefan Wahren wrote:
> Hi Dave,
>
>> Dave Stevenson hat am 20. September 2017 um
>> 18:07 geschrieben:
>>
>>
>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> (known as Unicam) on BCM283x
(although
V4L2_FWNODE_CSI2_MAX_DATA_LANES limits you to 4 at the moment).
- Or you could have 2 lanes configured in DT and ask TC358743 for (eg)
1080P60 UYVY at 594Mbps (needs 4 lanes) which passes the current logic
in the TC358743 driver and would return 0, when it is actually going
to use 4 lane
Add driver for the Unicam camera receiver block on
BCM283x processors.
Signed-off-by: Dave Stevenson
---
Changes from v2.
- Don't store the irq value as it isn't used outside the probe.
- Change PIX_FMT_ALL_ defines to avoid potential clashes with 4CCs.
- Clock now called "lp&quo
Signed-off-by: Dave Stevenson
---
No changes from v2 to v3
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eb930eb..b47ddaa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2713,6 +2713,13 @@ S: Maintained
N: bcm2835
F
Document the DT bindings for the CSI2/CCP2 receiver peripheral
(known as Unicam) on BCM283x SoCs.
Signed-off-by: Dave Stevenson
---
Changes since v2
- Removed all references to Linux drivers.
- Reworded section about disabling the firmware driver.
- Renamed clock from "lp_clock"
Hi All.
v3 of this patch set.
This addresses the DT issues raised by Rob, and the things raised by
Eric on the driver. More complete change details between v2 and v3
are in the individual patches.
Thanks
Dave
Dave Stevenson (4):
[media] v4l2-common: Add helper function for fourcc to string
New helper function char *v4l2_fourcc2s(u32 fourcc, char *buf)
that converts a fourcc into a nice printable version.
Signed-off-by: Dave Stevenson
---
No changes from v2 to v3
drivers/media/v4l2-core/v4l2-common.c | 18 ++
include/media/v4l2-common.h | 3 +++
2
On 20 September 2017 at 12:24, Hans Verkuil wrote:
> On 09/20/17 13:00, Dave Stevenson wrote:
>> On 20 September 2017 at 11:23, Philipp Zabel wrote:
>>> Hi,
>>>
>>> On Wed, 2017-09-20 at 10:14 +0100, Dave Stevenson wrote:
>>>> Hi Mauro & Ph
On 20 September 2017 at 11:23, Philipp Zabel wrote:
> Hi,
>
> On Wed, 2017-09-20 at 10:14 +0100, Dave Stevenson wrote:
>> Hi Mauro & Philipp
>>
>> On 19 September 2017 at 17:49, Mauro Carvalho Chehab
>> wrote:
>> > Em Tue, 19 Sep 2017 17:24:45 +020
Hi Mauro & Philipp
On 19 September 2017 at 17:49, Mauro Carvalho Chehab
wrote:
> Em Tue, 19 Sep 2017 17:24:45 +0200
> Philipp Zabel escreveu:
>
>> Hi Dave,
>>
>> On Tue, 2017-09-19 at 14:08 +0100, Dave Stevenson wrote:
>> > The existing fixed value of 16
Hi Rob.
Thanks for the review.
On 19 September 2017 at 15:32, Rob Herring wrote:
> On Wed, Sep 13, 2017 at 04:07:47PM +0100, Dave Stevenson wrote:
>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> (known as Unicam) on BCM283x SoCs.
>>
>> Si
work on two lanes (useful on the Raspberry Pi which
only brings out two CSI2 lanes to the camera connector).
I'd like to extend the last one to dynamically calculate all the values
for an arbitrary link speed, but time hasn't allowed as yet.
Dave Stevenson (3):
[media] tc358743: Cor
Adds register setups for running the CSI lanes at 972Mbit/s,
which allows 1080P50 UYVY down 2 lanes.
Signed-off-by: Dave Stevenson
---
drivers/media/i2c/tc358743.c | 47 +++-
1 file changed, 33 insertions(+), 14 deletions(-)
diff --git a/drivers/media
Support for non-continuous clock had previously been added via
device tree, but a comment and the value reported by g_mbus_config
still stated that it wasn't supported.
Remove the comment, and return the correct value in g_mbus_config.
Signed-off-by: Dave Stevenson
---
drivers/medi
d the increase in frame delay is <4usecs for 1080P60 UYVY
(2.55usecs for RGB888).
Signed-off-by: Dave Stevenson
---
drivers/media/i2c/tc358743.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 6b0fd07.
Hi Hans.
Thanks for the response.
On 19 September 2017 at 11:20, Hans Verkuil wrote:
> On 09/19/17 11:50, Dave Stevenson wrote:
>> Hi Eric.
>>
>> Thanks for the review.
>>
>> On 18 September 2017 at 19:18, Eric Anholt wrote:
>>> Dave Stevenson writes
Hi Eric.
Thanks for the review.
On 18 September 2017 at 19:18, Eric Anholt wrote:
> Dave Stevenson writes:
>> diff --git a/drivers/media/platform/bcm2835/bcm2835-unicam.c
>> b/drivers/media/platform/bcm2835/bcm2835-unicam.c
>> new file mode 100644
>> index 00
ircumstances, but it isn't really a failure of this driver.
Dave
On 13 September 2017 at 16:07, Dave Stevenson
wrote:
> Hi All.
>
> This is v2 for adding a V4L2 subdevice driver for the CSI2/CCP2 camera
> receiver peripheral on BCM283x, as used on Raspberry Pi.
> Sorry for t
Add driver for the Unicam camera receiver block on
BCM283x processors.
Signed-off-by: Dave Stevenson
---
drivers/media/platform/Kconfig |1 +
drivers/media/platform/Makefile |1 +
drivers/media/platform/bcm2835/Kconfig | 14 +
drivers/media
Signed-off-by: Dave Stevenson
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eb930eb..b47ddaa 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2713,6 +2713,13 @@ S: Maintained
N: bcm2835
F: drivers/staging/vc04_services
/upstream-linux/tree/unicam is the linux-media
tree with my mods on top. It also includes a couple of TC358743 and
OV5647 driver updates that I'll send to the list in the next few days.
Thanks in advance.
Dave
Changes from v1 to v2:
- Broken out a new helper function v4l2_fourcc2s as reques
Document the DT bindings for the CSI2/CCP2 receiver peripheral
(known as Unicam) on BCM283x SoCs.
Signed-off-by: Dave Stevenson
---
.../devicetree/bindings/media/bcm2835-unicam.txt | 107 +
1 file changed, 107 insertions(+)
create mode 100644 Documentation/devicetree
New helper function char *v4l2_fourcc2s(u32 fourcc, char *buf)
that converts a fourcc into a nice printable version.
Signed-off-by: Dave Stevenson
---
drivers/media/v4l2-core/v4l2-common.c | 18 ++
include/media/v4l2-common.h | 3 +++
2 files changed, 21 insertions
On 30 August 2017 at 11:45, Hans Verkuil wrote:
> On 30/08/17 11:40, Dave Stevenson wrote:
>> Hi Hans.
>>
>> On 28 August 2017 at 15:15, Hans Verkuil wrote:
>>> Hi Dave,
>>>
>>> What is the status of this work? I ask because I tried to use this
Hi Hans.
On 28 August 2017 at 15:15, Hans Verkuil wrote:
> Hi Dave,
>
> What is the status of this work? I ask because I tried to use this driver
> plus my tc358743 on my rpi-2b without any luck. Specifically the tc358843
> isn't able to read from the i2c bus.
I was on oth
On 31/07/17 13:55, Steven Toth wrote:
On Sun, Jul 30, 2017 at 8:55 AM, Dave Newman
wrote:
I can confirm the problems with the cx23885 driver reported by Steven
Toth on 6 June 2017. He found that:
I tried the card in a different older Intel i7 board and it worked
flawlessly. I then started to
I can confirm the problems with the cx23885 driver reported by Steven
Toth on 6 June 2017. He found that:
> I tried the card in a different older Intel i7 board and it worked
> flawlessly. I then started to wonder if it was some new
> incompatibility introduced with Kaby Lake. I had tweaked the U
On 16 June 2017 at 17:08, Hans Verkuil wrote:
> On 06/16/2017 05:55 PM, Dave Stevenson wrote:
>>
>> On 16 June 2017 at 15:05, Hans Verkuil wrote:
>>>
>>> On 06/15/17 17:11, Dave Stevenson wrote:
>>>>
>>>> On 15 June 2017 at 15:14,
On 16 June 2017 at 15:05, Hans Verkuil wrote:
> On 06/15/17 17:11, Dave Stevenson wrote:
>> On 15 June 2017 at 15:14, Hans Verkuil wrote:
>>> On 06/15/17 15:38, Dave Stevenson wrote:
>>>> Hi Hans.
>>>>
>>>> "On 15 June 2017 at 08:12
Hi Sakari
On 16 June 2017 at 10:57, Sakari Ailus wrote:
> Hi Dave,
>
> On Thu, Jun 15, 2017 at 05:15:04PM +0100, Dave Stevenson wrote:
>> Hi Sakari.
>>
>> Thanks for the review.
>>
>> On 15 June 2017 at 13:59, Sakari Ailus wrote:
>> > Hi Dave,
>
Hi Sakari.
Thanks for the review.
On 15 June 2017 at 13:59, Sakari Ailus wrote:
> Hi Dave,
>
> Thanks for the set!
>
> On Wed, Jun 14, 2017 at 04:15:46PM +0100, Dave Stevenson wrote:
>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> (known
Hi Stefan.
On 15 June 2017 at 15:49, Stefan Wahren wrote:
> Hi Dave,
>
> Am 15.06.2017 um 15:38 schrieb Dave Stevenson:
>> Hi Hans.
>>
>> "On 15 June 2017 at 08:12, Hans Verkuil wrote:
>>> Hi Dave,
>>>
>>> Here is a quick review of t
On 15 June 2017 at 15:14, Hans Verkuil wrote:
> On 06/15/17 15:38, Dave Stevenson wrote:
>> Hi Hans.
>>
>> "On 15 June 2017 at 08:12, Hans Verkuil wrote:
>>> Hi Dave,
>>>
>>> Here is a quick review of this driver. Once a v2 is posted I&#x
Hi Hans.
"On 15 June 2017 at 08:12, Hans Verkuil wrote:
> Hi Dave,
>
> Here is a quick review of this driver. Once a v2 is posted I'll do a more
> thorough
> check.
Thank you. I wasn't expecting such a quick response.
> On 06/14/2017 05:15 PM, Dave Stevenso
Hi Stefan.
Thanks for taking the time to review this.
On 15 June 2017 at 07:34, Stefan Wahren wrote:
> Hi Dave,
>
> Am 14.06.2017 um 17:15 schrieb Dave Stevenson:
>> Document the DT bindings for the CSI2/CCP2 receiver peripheral
>> (known as Unicam) on BCM283x SoCs.
>
On 15 June 2017 at 08:17, Hans Verkuil wrote:
> On 06/14/2017 11:03 PM, Dave Stevenson wrote:
>>
>> On 14 June 2017 at 18:38, Hans Verkuil wrote:
>>>
>>> On 06/14/2017 06:29 PM, Dave Stevenson wrote:
>>>>
>>>>
>>>
On 14 June 2017 at 18:38, Hans Verkuil wrote:
> On 06/14/2017 06:29 PM, Dave Stevenson wrote:
>>
>> Hi Hans.
>>
>> On 14 June 2017 at 16:42, Hans Verkuil wrote:
>>>
>>> Hi Dave,
>>>
>>> How does this driver relate to this stagi
Hi Hans.
On 14 June 2017 at 16:42, Hans Verkuil wrote:
> Hi Dave,
>
> How does this driver relate to this staging driver:
>
> drivers/staging/vc04_services/bcm2835-camera/
>
> It's not obvious to me.
drivers/staging/vc04_services/bcm2835-camera/ is using the VideoCore
Add driver for the Unicam camera receiver block on
BCM283x processors.
Signed-off-by: Dave Stevenson
---
drivers/media/platform/Kconfig |1 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/bcm2835/Kconfig | 14 +
drivers/media
essed up in sending these patches - so many ways
to do something.
Thanks in advance.
Dave
Dave Stevenson (2):
[media] dt-bindings: Document BCM283x CSI2/CCP2 receiver
[media] bcm2835-unicam: Driver for CCP2/CSI2 camera interface
.../devicetree/bindings/media/bcm2835-unicam.txt | 76
Document the DT bindings for the CSI2/CCP2 receiver peripheral
(known as Unicam) on BCM283x SoCs.
Signed-off-by: Dave Stevenson
---
.../devicetree/bindings/media/bcm2835-unicam.txt | 76 ++
1 file changed, 76 insertions(+)
create mode 100644 Documentation/devicetree
On 2 June 2017 at 15:13, Philipp Zabel wrote:
> On Fri, 2017-06-02 at 15:27 +0200, Hans Verkuil wrote:
>> On 06/02/17 15:03, Dave Stevenson wrote:
>> > Hi Hans.
>> >
>> > On 2 June 2017 at 13:35, Hans Verkuil wrote:
>> >> On 06/02/17 14:18,
Hi Hans.
On 2 June 2017 at 13:35, Hans Verkuil wrote:
> On 06/02/17 14:18, Dave Stevenson wrote:
>> These 3 patches for TC358743 came out of trying to use the
>> existing driver with a new Raspberry Pi CSI-2 receiver driver.
>
> Nice! Doing that has been on my todo list for
Previously the mbus_fmt_code was set after the device was
registered. If a connected sub-device called tc358743_get_fmt
prior to that point it would get an invalid code back.
Signed-off-by: Dave Stevenson
---
drivers/media/i2c/tc358743.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
There was no way to query the supported mbus formats from this
driver. enum_mbus_code is the function to expose that, so
implement it.
Signed-off-by: Dave Stevenson
---
drivers/media/i2c/tc358743.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/media/i2c
if no interrupt source is defined.
Signed-off-by: Dave Stevenson
---
drivers/media/i2c/tc358743.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
index 2f5763d..654aac2 100644
--- a/drivers/
line wired up to the SoC. "interrupts" is listed as being
optional in the DT binding, but the driver didn't actually
function if it wasn't provided.
Dave Stevenson (3):
[media] tc358743: Add enum_mbus_code
[media] tc358743: Setup default mbus_fmt before registering
[media]
ecified.
>> >
>> > v2: move early return after enable_signaling
>> >
>> > Signed-off-by: Andres Rodriguez
>>
>> Reviewed-by: Christian König
>
> pushed to drm-misc-next. Thanks all.
I don't see this patch in -rc2, where did it end up going?
Dave.
Hi Sakari .
Thanks for taking the time to respond.
On 17 May 2017 at 00:04, Sakari Ailus wrote:
> Hi Dave,
>
> On Thu, May 11, 2017 at 04:51:27PM +0100, Dave Stevenson wrote:
>> Hi All.
>>
>> As previously discussed, I'm working on a V4L2 driver for the
>> C
be
needed for enum_input.
vidioc_g_input can be done by the CSI-2 receiver driver
assuming/setting to input 0 during probe, and then caching the last
set value, but that feels a little nasty. Have I missed something
there?
Thanks in advance.
Dave
[1]
https://linuxtv.org/downloads/v4l-dvb-apis-new/kapi/csi2.html#receiver-drivers
olls on them.
>
> If a caller is only interested in the fence status without enabling the
> signaling it should call dma_fence_is_signaled() instead.
Can we not move the return 0 (with spin unlock) down after we enabling
signalling, but before
we enter the schedule_timeout(1)?
Dave.
Hi Hans.
On 06/02/17 12:58, Hans Verkuil wrote:
On 02/06/2017 12:37 PM, Dave Stevenson wrote:
Hi Hans.
On 06/02/17 09:08, Hans Verkuil wrote:
Hi Eric,
Great to see this driver appearing for upstream merging!
See below for my review comments, focusing mostly on V4L2 specifics
Hi Mauro.
Can I just say that I'm not attempting to upstream this, others are.
I've just answered questions raised.
On 06/02/17 12:37, Mauro Carvalho Chehab wrote:
Em Sun, 5 Feb 2017 22:15:21 +
Dave Stevenson escreveu:
If the goal was to protect some IP related to the sensor
Hi Hans.
On 06/02/17 09:08, Hans Verkuil wrote:
Hi Eric,
Great to see this driver appearing for upstream merging!
See below for my review comments, focusing mostly on V4L2 specifics.
On 01/27/2017 10:54 PM, Eric Anholt wrote:
- Supports raw YUV capture, preview, JPEG and H264.
- Uses videobu
e public).
That doesn't seem to fit very well into V4L2 which expects that it can
see all the detail, so there are a few nasty spots to shoe-horn it in.
If there are better ways to solve the problems, then I'm open to them.
Thanks
Dave
On 03/02/17 18:59, Mauro Carvalho Chehab wrot
, 2016 at 01:09:21AM +0200, Laurent Pinchart wrote:
On Thursday 08 Dec 2016 12:31:55 Dave Stevenson wrote:
Hi All.
I'm working with a USB webcam which has been seen to spontaneously
disconnect when in use. That's a separate issue, but when it does it
throws a load of warnings into the
Hi Ramiro
On 13/12/16 13:47, Ramiro Oliveira wrote:
Hi Dave
On 07/21/2016 08:19 PM, Dave Stevenson wrote:
Just a quick query to avoid duplicating effort. Has anyone worked on a
Sony IMX219 (or other Sony sensor) subdevice driver as yet?
With the new Raspberry Pi camera being IMX219, and as
.04 machine are below).
I can fully appreciate that the open file descriptor is holding
references to a now invalid device, but is there a way to avoid them? Or
do we really not care and have to put up with the log noise when doing
such silly things?
Thanks in advance.
Dave
[157877.29761
On 11/22/2016 11:49 PM, Daniel Vetter wrote:
> Yes, agreed. My idea with exposing vram sections using numa nodes wasn't
> to reuse all the existing allocation policies directly, those won't work.
> So at boot-up your default numa policy would exclude any vram nodes.
>
> But I think (as an -mm laym
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On 10/11/2016 04:50 PM, Ruchi Kandoi wrote:
> Any process holding a reference to these buffers will keep the kernel from
> reclaiming its backing pages. mm counters don't provide a complete picture of
> these allocations, since they only account for pages that are mapped into a
> process's address
Hi Hans.
On 22/07/16 10:46, Hans Verkuil wrote:
On 07/21/2016 08:19 PM, Dave Stevenson wrote:
Hi All.
Just a quick query to avoid duplicating effort. Has anyone worked on a
Sony IMX219 (or other Sony sensor) subdevice driver as yet?
Not that I am aware of.
OK, glad to hear I won'
10bpp Bayer, and the odd
packing is ignored. Or do we need new enums?
Thanks.
Dave
--
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
t; 2) | ((buf[4] >> 4) & 3);
break;
default: val = (buf[3] << 2) | ((buf[4] >> 6) & 3);
All of those agree with Sakari's update that the first pixel's LSBits
are in bits 1..0 of byte 5, 2nd pixel in bits 3..2, etc.
Regards,
Dave
(working
been merged in the Linux
> media git tree for v4.7. Dave, instead of merging the media tree in your tree
> to pull the dependency in, it would be easier to get those two patches
> upstream through the media tree. I don't expect any conflict related to the
> DU driver for v4.7
ld compare with the things Solaris uses to describe the
restrictions on a DMA binding ...
http://docs.oracle.com/cd/E23824_01/html/821-1478/ddi-dma-attr-9s.html#REFMAN9Sddi-dma-attr-9s
.Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bo
The decoder box is UEC DSD4121 using VAST (DVB-S2) with AV and HDMI outputs.
There's a UEC upgrade kit to use the USB port with an external HDD to
record for $65.
Might try that next.
Other options?
Dave
On 18/10/14 08:34, Steven Toth wrote:
So I think this is going to be a very poor toy.
assistance would be welcome - as you can probably tell, I really
don't know what I'm doing.
Dave
On 17/10/14 07:40, Steven Toth wrote:
Ok, no nobody jumped in the first time around. my turn I guess... :)
Comments below.
On Thu, Oct 16, 2014 at 5:18 PM, Dave Kimble wrote:
I have jus
I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD".
http://www.greada.com/grabbeex-hd.html
Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg
Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E".
Note that it compresses the video with H.264 .
I k
I have just bought an HDMI to USB-2.0 grabber called "GrabBee-HD".
http://www.greada.com/grabbeex-hd.html
Motherboard photo: http://www.davekimble.org.au/computers/GrabBee-HD.jpg
Inside it has chips labelled "Sigma PL330B-CPE3" and "iTE IT6604E".
Note that it compresses the video with H.264 .
I k
>
> Dave,
> I understand your issues with my programming. I need to try and
> understand the kernel first before programming
> for it.
Why do you insist on sending more patches then, every day you try and
send another one or two, despite been
told multiple times to a) understa
ned-off-by: Nicholas Krause
>
> Dunno what's going on here after reading Dave Airlie's reply, but:
>
Nick has decided he wants to be a kernel developer, a laudable goal.
He however has decided not to take any advice given to me by a number of other
kernel developers on how to work on
read them again, go nuts read them again.
Still wondering where I'm going with this? read them again.
then understand that I mean this in the nicest way possible. "please fuck off."
you are wasting developers time.
Dave.
--
To unsubscribe from this list: send the line "unsubsc
Hello again
Philipp Zabel writes:
> +struct media_device *ipu_find_media_device(void)
> +{
> + return &ipu_media->mdev;
> +}
> +EXPORT_SYMBOL_GPL(ipu_find_media_device);
Where is ipu_find_media_device() being called?
> +int ipu_media_device_register(struct device *dev)
> +{
[snip]
> +
>
1 - 100 of 207 matches
Mail list logo
