Hi Steve,
On Tue, 2017-02-14 at 18:27 -0800, Steve Longerbeam wrote:
[...]
> >
> > # Provide an EDID to the HDMI source
> > v4l2-ctl -d /dev/v4l-subdev2 --set-edid=file=edid-1080p.hex
>
> I can probably generate this Intel hex file myself from sysfs
> edid outputs, but for convenience do you mind
Hi Philipp,
I've created a test branch off my imx-media-staging-md-wip called tc358743,
which cherry-picks a couple of your commits from your
imx-media-staging-md-wip
branch:
[media] tc358743: set entity function to video interface bridge
[media] tc358743: put lanes in STOP state before starti
On 02/02/2017 02:29 PM, Russell King - ARM Linux wrote:
On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote:
Here is the current .queue_setup() op in imx-media-capture.c:
static int capture_queue_setup(struct vb2_queue *vq,
unsigned int *nbuffers,
On 02/03/2017 06:41 AM, Laurent Pinchart wrote:
Hello,
On Wednesday 01 Feb 2017 16:19:27 Steve Longerbeam wrote:
On 02/01/2017 01:30 AM, Philipp Zabel wrote:
media-ctl propagates the output pad format to all remote subdevices'
input pads for all enabled links:
https://git.linuxtv.org/v4l-u
Hello,
On Wednesday 01 Feb 2017 16:19:27 Steve Longerbeam wrote:
> On 02/01/2017 01:30 AM, Philipp Zabel wrote:
> > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> > [...]
> >
> >>> # Set pad formats
> >>> media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
> >>> media-ctl
On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote:
> Here is the current .queue_setup() op in imx-media-capture.c:
>
> static int capture_queue_setup(struct vb2_queue *vq,
>unsigned int *nbuffers,
>unsigned int *nplanes
On 02/02/2017 10:58 AM, Russell King - ARM Linux wrote:
On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote:
On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:
and for whatever reason we end up falling out through free_ring. This
is VERY bad news, because it means that the
On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote:
> On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:
> >and for whatever reason we end up falling out through free_ring. This
> >is VERY bad news, because it means that the ring which SMFC took a copy
> >of is now freed beneath
On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote:
On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote:
I thought, maybe, it's the IPU overwriting past the end of the buffer,
but I've added checks and that doesn't seem to have fired. I also
wondered if it was some ki
On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote:
> I thought, maybe, it's the IPU overwriting past the end of the buffer,
> but I've added checks and that doesn't seem to have fired. I also
> wondered if it was some kind of use-after-free of the ring, so I made
> imx_media
Hi Russell,
I don't recommend spending too much time debugging this
OOPS. The dma buffer ring has been removed completely
in version 4 (which I'm trying to get ready to post hopefully
by end of this week).
Steve
On 02/02/2017 09:22 AM, Russell King - ARM Linux wrote:
I seem to be getting some
I seem to be getting some sort of memory corruption with this driver.
I've had two instances now of uninitialised spinlocks in
imx_media_dma_buf_get_active() which show that the spinlock being
taken in this function is all-zeros.
That very quickly leads to an oops, where I've seen buf->ring is
NU
On 02/01/2017 01:30 AM, Philipp Zabel wrote:
On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
[...]
# Set pad formats
media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
media-ctl --set-v4l2 "'ipu1_csi0_mux':
On Wed, Feb 01, 2017 at 11:42:31AM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote:
> Right, it's just that in the latest version there is no v4l2_subdev for
> fifos and idmac. There is the capture interface entity that represents
> one of the IDMAC w
On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote:
> On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> > [...]
> > > right, need to fix that. Probably by poking the attached
> > > source subdev (csi or prp
On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
> [...]
> > right, need to fix that. Probably by poking the attached
> > source subdev (csi or prpenc/vf) for its supported formats.
>
> You are right, in bayer/raw mode only
On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote:
[...]
> > # Set pad formats
> > media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]"
> > media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]"
> > media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]"
> > medi
On Tue, Jan 31, 2017 at 05:54:52PM -0800, Steve Longerbeam wrote:
> On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote:
> First, thank you for the explanation, it clears up a lot.
>
> But of_parse_subdev() is used to parse the OF graph starting
> from the CSI ports, to discover all the nodes t
On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote:
On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote:
On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote:
Just like smiapp, the camera sensor block (which is the very far end
of the pipeline) is marked with MEDIA_ENT_F_CA
On 01/31/2017 05:54 AM, Philipp Zabel wrote:
Hi Steve,
I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
observations:
# Link pipeline
media-ctl -l "'tc358743 1-000f':0->'imx6-mipi-csi2':0[1]"
media-ct
On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote:
>
>
> On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote:
> >Just like smiapp, the camera sensor block (which is the very far end
> >of the pipeline) is marked with MEDIA_ENT_F_CAM_SENSOR. However, in
> >front of that is the b
On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote:
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
I'm also having trouble finding a datasheet for it, but from what
I've read, it has a MIPI CSI-2 interface. It should work fine as long
as it presents a single source pad,
On Tue, Jan 31, 2017 at 03:25:10PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote:
> > Hi Steve,
> >
> > I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
> > with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
> > obser
On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote:
> Hi Steve,
>
> I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
> with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
> observations:
>
> # Link pipeline
> media-ctl -l "'tc358743 1-000f':0->'imx6-mi
On Tue, Jan 31, 2017 at 02:35:00PM +0100, Philipp Zabel wrote:
> On Tue, 2017-01-31 at 13:14 +, Russell King - ARM Linux wrote:
> > This isn't limited to the serial side - the parallel bus side between
> > the CSI2 interface and CSI2IPU wrapper, and the CSI2IPU wrapper and
> > the CS0/1 interfa
Hi Steve,
I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X
with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some
observations:
# Link pipeline
media-ctl -l "'tc358743 1-000f':0->'imx6-mipi-csi2':0[1]"
media-ctl -l "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
m
On Tue, 2017-01-31 at 13:14 +, Russell King - ARM Linux wrote:
> On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote:
> > On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote:
> > > To help illustrate my point, consider the difference between
> > > MEDIA_BUS_FMT_RGB565_1X
On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote:
> On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote:
> > To help illustrate my point, consider the difference between
> > MEDIA_BUS_FMT_RGB565_1X16 and MEDIA_BUS_FMT_RGB565_2X8_BE or
> > MEDIA_BUS_FMT_RGB565_2X8_LE. RGB
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> I'm also having trouble finding a datasheet for it, but from what
> I've read, it has a MIPI CSI-2 interface. It should work fine as long
> as it presents a single source pad, registers asynchronously, and
> sets its entity functio
On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote:
> Edit: I see a subdev that is missing: the video mux. Did you enable
> CONFIG_VIDEO_MULTIPLEXER?
Yes, and that's where the problem is - the video-multiplexer is
missing the module aliases to allow it to be automatically loaded.
-
On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote:
> > The central issue seems to be that I think media pad links / media bus
> > formats should describe physical links, such as parallel or serial
> > buses, and the formats of pixels flowing through them, whereas Steve
> > would lik
On Mon, 2017-01-30 at 17:22 -0800, Steve Longerbeam wrote:
>
> On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote:
> >
> > Hi,
> >
> > Trying this driver with an imx219 camera (which works with Philipp's
> > driver) results in not much happening... no /dev/media* node for it,
> > no subdevs, n
On 01/30/2017 05:06 PM, Russell King - ARM Linux wrote:
On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:
Trying this driver with an imx219 camera (which works with Philipp's
driver) results in not much happening... no /dev/media* node for it,
no subdevs, no nothing. N
On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote:
Hi,
Trying this driver with an imx219 camera (which works with Philipp's
driver) results in not much happening... no /dev/media* node for it,
no subdevs, no nothing. No clues as to what's missing either. Only
messages from imx-media ar
On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote:
> Trying this driver with an imx219 camera (which works with Philipp's
> driver) results in not much happening... no /dev/media* node for it,
> no subdevs, no nothing. No clues as to what's missing either. Only
> messages f
On Fri, Jan 06, 2017 at 06:11:18PM -0800, Steve Longerbeam wrote:
> Philipp Zabel (3):
> ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
> connections
> add mux and video interface bridge entity functions
> platform: add video-multiplexer subdevice driver
>
> Steve L
> The central issue seems to be that I think media pad links / media bus
> formats should describe physical links, such as parallel or serial
> buses, and the formats of pixels flowing through them, whereas Steve
> would like to extend them to describe software transports and in-memory
> formats.
On 01/24/2017 03:27 AM, Philipp Zabel wrote:
Hi Steve, Hans,
[added Laurent to Cc: who I believe might have an opinion on the media
bus formats, too. Sorry for the wall of text, I have put a marker where
the MEDIA_BUS argument starts]
The central issue seems to be that I think media pad links
On Mon, 2017-01-23 at 12:08 +0100, Hans Verkuil wrote:
> On 01/23/2017 12:00 PM, Philipp Zabel wrote:
> > On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
[...]
> As long as it is mentioned in the TODO, and ideally in the Kconfig as well,
> then I'm fine with it.
>
> The big advantage of bein
Hi Steve, Hans,
[added Laurent to Cc: who I believe might have an opinion on the media
bus formats, too. Sorry for the wall of text, I have put a marker where
the MEDIA_BUS argument starts]
The central issue seems to be that I think media pad links / media bus
formats should describe physical lin
On 01/23/2017 03:00 AM, Philipp Zabel wrote:
On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
[...]
There is a VDIC entity in the i.MX IPU that performs de-interlacing with
hardware filters for motion compensation. Some of the motion compensation
modes ("low" and "medium" motion) require
On 01/23/2017 12:00 PM, Philipp Zabel wrote:
> On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
> [...]
>>> There is a VDIC entity in the i.MX IPU that performs de-interlacing with
>>> hardware filters for motion compensation. Some of the motion compensation
>>> modes ("low" and "medium" moti
On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
[...]
> > There is a VDIC entity in the i.MX IPU that performs de-interlacing with
> > hardware filters for motion compensation. Some of the motion compensation
> > modes ("low" and "medium" motion) require that the VDIC receive video
> > frame
On 01/20/2017 07:40 PM, Steve Longerbeam wrote:
> Hi Hans, Philipp,
>
>
> On 01/20/2017 08:31 AM, Philipp Zabel wrote:
>> Hi Hans,
>>
>> On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote:
>>> Hi Steve, Philipp,
>>>
>>> On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
In version 3:
>>
Hi Hans, Philipp,
On 01/20/2017 08:31 AM, Philipp Zabel wrote:
Hi Hans,
On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote:
Hi Steve, Philipp,
On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
In version 3:
Changes suggested by Rob Herring :
- prepended FIM node properties with vendor
Hi Hans,
On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote:
> Hi Steve, Philipp,
>
> On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
> > In version 3:
> >
> > Changes suggested by Rob Herring :
> >
> > - prepended FIM node properties with vendor prefix "fsl,".
> >
> > - make mipi csi-2
Hi Steve, Philipp,
On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
> In version 3:
>
> Changes suggested by Rob Herring :
>
> - prepended FIM node properties with vendor prefix "fsl,".
>
> - make mipi csi-2 receiver compatible string SoC specific:
> "fsl,imx6-mipi-csi2" instead of "fsl,
Hi Tim,
On 01/11/2017 03:14 PM, Tim Harvey wrote:
Hi Steve,
I took a stab at testing this today on a gw51xx which has an adv7180
hooked up as follows:
- i2c3@0x20
- 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads
(CSI0_IPU1)
- PWRDWN# on MX6QDL_PAD_CSI0_DATA_EN__GPIO5_I
On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam wrote:
> In version 3:
>
> Changes suggested by Rob Herring :
>
> - prepended FIM node properties with vendor prefix "fsl,".
>
> - make mipi csi-2 receiver compatible string SoC specific:
> "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2"
In version 3:
Changes suggested by Rob Herring :
- prepended FIM node properties with vendor prefix "fsl,".
- make mipi csi-2 receiver compatible string SoC specific:
"fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2".
- redundant "_clk" removed from mipi csi-2 receiver clock-names p
50 matches
Mail list logo
