Re: [PATCH] gpu: ipu-v3: Allow negative offsets for interlaced scanning

Steve Longerbeam writes: > Right, the selection of interweave is moved to the capture devices, > so the following will enable interweave: > > v4l2-ctl -dN --set-fmt-video=field=interlaced_tb and > So the patch to adv7180 needs to be modified to report # field lines. > > Try the following: > >

Re: [PATCH] gpu: ipu-v3: Allow negative offsets for interlaced scanning

Reporting from the field :-) The fix-csi-interlaced.3 branch is still a bit off the track I guess: media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/576 field:seq-tb]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576

Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

Steve Longerbeam writes: > One final note, it is incorrect to assign 'seq-tb' to a PAL signal according > to this new understanding. Because according to various sites (for example > [1]), both standard definition NTSC and PAL are bottom field dominant, > so 'seq-tb' is not correct for PAL.

Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

Steve Longerbeam writes: > Yes, I had already implemented this idea yesterday, I've added it > to branch fix-csi-interlaced.3. The CSI will swap field capture > (field 1 first, then field 2, by inverting F bit in CCIR registers) if > the field order input to the CSI is different from the

Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

Steve Longerbeam writes: > I don't follow you, yes the interweaving step only has access to > a single frame, but why would interweave need access to another > frame to carry out seq-bt -> interlaced-tb ? See below... You can't to that. You can delay the input stream (skip one field) so the

Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

Philipp Zabel writes: > I'm probably misunderstanding you, so at the risk of overexplaining: > There is no way we can ever produce a correct interlaced-tb frame in > memory from a seq-bt frame output by the CSI, as the interweaving step > only has access to a single frame. Anyway we can use

Re: [PATCH v2 01/10] media: imx-csi: Pass sink pad field to ipu_csi_init_interface

Steve Longerbeam writes: > I think you misunderstood me. Of course there is a first and second > field. By first I am referring to the first field transmitted, which could > be top or bottom. Right. I was thinking the fields are even and odd, but that's not actually the case (I mean, the

Re: i.MX6 IPU CSI analog video input on Ventana

I've just tested the PAL setup: in currect situation (v4.17 + Steve's fix-csi-interlaced.2 + "media: adv7180: fix field type" + a small cheap PAL camera) the following produces bottom-first interlaced frames: media-ctl -r -l '"adv7180 2-0020":0->"ipu2_csi1_mux":1[1],

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > I think this must be legacy code from a Freescale BSP requirement > that the CSI must always capture in T-B order. We should remove this > code, so that the CSI always captures field 0 followed by field 1, > irrespective > of field affinity, Well it now seems we could

Re: i.MX6 IPU CSI analog video input on Ventana

Hi Philipp, Philipp Zabel writes: > My understanding is that the CCIR codes for height == 480 (NTSC) > currently capture the second field (top) first, assuming that for NTSC > the EAV/SAV codes are bottom-field-first. 2a38014: 010D07DF 00040596 SA EA SB EB SB EB D07DF: 001

Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture

Steve Longerbeam writes: > Hmm, if the sink is 'alternate', and the requested source is > 'interlaced*', perhaps we should allow the source to be > 'interlaced*' and not override it. For example, if requested > is 'interlaced-tb', let it be that. IOW assume user knows something > we don't about

Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields

Philipp Zabel writes: > This is ok in this patch, but we can't use this check in the following > TRY_FMT patch as there is no way to interweave > SEQ_TB -> INTERLACED_BT (because in SEQ_TB the B field is newer than T, > but in INTERLACED_BT it has to be older) or SEQ_BT -> INTERLACED_TB (the >

Re: [PATCH v2 01/10] media: imx-csi: Pass sink pad field to ipu_csi_init_interface

Steve Longerbeam writes: > I think we should return to enforcing field order to userspace that > matches field order from the source, which is what I had implemented > previously. I agree with you that we should put off allowing inverting > field order. There is no any particular field order at

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > I tend to agree, I've found conflicting info out there regarding > PAL vs. NTSC field order. And I've never liked having to guess > at input analog standard based on input # lines. I will go ahead > and remove the field order override code. I've merged your current

Re: i.MX6 IPU CSI analog video input on Ventana

Philipp Zabel writes: > Note that the code in ipu_csi_init_interface currently hard-codes field > order depending on frame size. It could be that selecting opposite field > order is as easy as switching the relevant parts of writes to registers > CCIR_CODE_2 and _3, but we'd have to pass the

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: >> but it should be possible for the user to explicitly request the field >> order on CSI output (I can make a patch I guess). > > If you think that is the correct behavior, I will remove the override > code. I suppose it makes sense to allow user to select field order

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > Yes, you'll need to patch adv7180.c to select either > 'seq-bt/tb' or 'alternate'. The current version will override > any attempt to set field to anything other than 'interlaced'. > This is in anticipation of getting a patch merged for adv7180 > that fixes this.

Re: i.MX6 IPU CSI analog video input on Ventana

Hi Steve, Steve Longerbeam writes: > Krzysztof, in the meantime the patches are available in my > media-tree fork, for testing on the Ventana GW5300: > > g...@github.com:slongerbeam/mediatree.git, branch 'fix-csi-interlaced' I assume fix-csi-interlaced.2 is a newer version, isn't it? I merged

Re: i.MX6 IPU CSI analog video input on Ventana

Philipp Zabel writes: > Maybe scanline interlave and double write reduction can't be used at the > same time? Well, if it works in non-interlaced modes - it may be the case. Perhaps the data reduction is done before the field merge step. This would make it incompatible:

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: >> The manual says: Reduce Double Read or Writes (RDRW): >> This bit is relevant for YUV4:2:0 formats. For write channels: >> U and V components are not written to odd rows. >> >> How could it be so? With YUV420, are they normally written? > >

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > Sorry I did find a bug. Please try this patch: Ok, your patch fixes the first problem (sets the CSI interlaced mode on input when field = NOE is requested on output). Posting in full since your mail came somehow mangled with UTF-8. ---

Re: i.MX6 IPU CSI analog video input on Ventana

Hi, I've experimented with the ADV7180 a bit and this is what I found. First, I'm using (with a NTSC camera but I guess PAL won't be much different): media-ctl -V '"adv7180 2-0020":0[fmt:UYVY2X8 720x480 field:interlaced]' media-ctl -V '"ipu2_csi1_mux":1[fmt:UYVY2X8 720x480 field:interlaced]'

Re: i.MX6 IPU CSI analog video input on Ventana

Hi, Steve Longerbeam writes: > Hi Krzysztof, I've been on vacation, just returned today. I will > find the time this week to attempt to reproduce your results on > a SabreAuto quad with the adv7180. Great. Please let me know if I can assist you somehow. > Btw, if you

Re: i.MX6 IPU CSI analog video input on Ventana

Tested with NTSC camera, it's the same as with PAL. The only case when IPU2_CSI1_SENS_CONF register is set to interlaced mode (PRCTL=3, CCIR interlaced mode (BT.656)) is when all parts of the pipeline are set to interlaced: "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:interlaced]

Re: i.MX6 IPU CSI analog video input on Ventana

Tim, Tim Harvey writes: > What version of kernel are you using and what specific board model do > you have (full board model and/or serial number so I know if you've > got an IMX6DL or an IMX6Q) and have you modified the device-tree? I > tested the adv7180 a couple of

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > Yes, the CSI on i.MX6 does not deal well with unstable bt.656 sync codes, > which results in vertical sync issues (scrolling or split images). The > ADV7180 > will often shift the sync codes around in various situations (initial > power on, > see

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: >> Second, the image format information I'm getting out of "ipu2_csi1 >> capture" device is: >> >> open("/dev/video6") >> ioctl(VIDIOC_S_FMT, {V4L2_BUF_TYPE_VIDEO_CAPTURE, >> fmt.pix={704x576, pixelformat=NV12, V4L2_FIELD_INTERLACED} => >>

i.MX6 IPU CSI analog video input on Ventana

Hi, I'm using analog PAL video in on GW53xx/54xx boards (through ADV7180 chip and 8-bit parallel CSI input, with (presumably) BT.656). I'm trying to upgrade from e.g. Linux 4.2 + Steve's older MX6 camera driver (which works fine) to v.4.16 with the recently merged driver. media-ctl -r -l

i.MX6: 16-bit parallel CSI

Another thing. I'm using a 16-bit parallel CSI camera (with the so called BT.1120, the 16-bit version of BT.656). Both BT.1120 and BT.656 send sync info embedded in the pixel data stream. The current code calls for "passthrough" in 16-bit YCbCr (YUV) mode, though this isn't actually required in

Re: [PATCH][MEDIA]i.MX6 CSI: Fix MIPI camera operation in RAW/Bayer mode

Fabio Estevam writes: >> --- a/drivers/staging/media/imx/imx-media-csi.c >> +++ b/drivers/staging/media/imx/imx-media-csi.c >> @@ -340,7 +340,7 @@ static int csi_idmac_setup_channel(struct csi_priv *priv) >> case V4L2_PIX_FMT_SGBRG8: >> case

[PATCH][MEDIA]i.MX6 CSI: Fix MIPI camera operation in RAW/Bayer mode

Without this fix, in 8-bit Y/Bayer mode, every other 8-byte group of pixels is lost. Not sure about possible side effects, though. Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> --- a/drivers/staging/media/imx/imx-media-csi.c +++ b/drivers/staging/media/imx/imx-media-csi.c @@ -340,7

[PATCH][MEDIA] i.MX6: Fix MIPI CSI-2 LP-11 check

Bitmask for the MIPI CSI-2 data PHY status doesn't seem to be correct. Fix it. Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> --- a/drivers/staging/media/imx/imx6-mipi-csi2.c +++ b/drivers/staging/media/imx/imx6-mipi-csi2.c @@ -252,8 +252,8 @@ static int csi2_dphy_wait_stopstate(

i.MX6 CODA warning: vb2: counters for queue xxx, buffer y: UNBALANCED!

Hi, I'm using i.MX6 CODA H.264 encoder and found a minor bug somewhere. Not sure how it should be fixed, though. The problem manifests itself when I configure (open, qbuf etc) the encoder device and then close it without any start/stop streaming calls. I'm using 2 buffers in this example: vb2:

Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure

Hans Verkuil writes: > Any progress on this? I gather I can expect a new patch from someone? Well, the issue is trivial and very easy to test, though not present on common x86 hw. That patch I've sent fixes it, but I'm not the one who decides. -- Krzysztof Halasa

Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure

Ezequiel Garcia writes: > How about this one (untested) ? > > diff --git a/drivers/media/pci/tw686x/tw686x-video.c > b/drivers/media/pci/tw686x/tw686x-video.c > index c3fafa97b2d0..77b8d2dbd995 100644 > --- a/drivers/media/pci/tw686x/tw686x-video.c > +++

Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure

"zhaoxuegang" writes: > In my opinion, the oops occur to tw686x_free_dma(struct tw686x_video_channel > *vc, unsigned int pb). > In function tw686x_video_init, if coherent-DMA is not enough, > tw686x_alloc_dma will failed. > Then tw686x_video_free will be called. but

Re: [PATCH] TW686x: Fix OOPS on buffer alloc failure

Ezequiel Garcia writes: >> + /* Initialize vc->dev and vc->ch for the error path first */ >> + for (ch = 0; ch < max_channels(dev); ch++) { >> + struct tw686x_video_channel *vc = >video_channels[ch]; >> + vc->dev = dev; >> +

[PATCH] TW686x: Fix OOPS on buffer alloc failure

Signed-off-by: Krzysztof Hałasa <khal...@piap.pl> diff --git a/drivers/media/pci/tw686x/tw686x-video.c b/drivers/media/pci/tw686x/tw686x-video.c index c3fafa9..d637f47 100644 --- a/drivers/media/pci/tw686x/tw686x-video.c +++ b/drivers/media/pci/tw686x/tw686x-video.c @@ -1190,6 +1190,13

Re: [PCIE device driver: tw686x] I have some problems with tw686x and I need help.

Hello Singh, I've added linux-media as well as the current TW686x driver maintainer to Cc: list. Perhaps they will be better prepared to help you, the driver differs much from what it was when I originally wrote it. writes: > First, I download source code from website >

Re: [PATCH v2] media: solo6x10: fix lockup by avoiding delayed register write

Andrey Utkin writes: > --- a/drivers/media/pci/solo6x10/solo6x10.h > +++ b/drivers/media/pci/solo6x10/solo6x10.h > @@ -284,7 +284,10 @@ static inline u32 solo_reg_read(struct solo_dev > *solo_dev, int reg) > static inline void solo_reg_write(struct solo_dev

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > Lockup happens only on 6010. In provided log you can see that 6110 > passes just fine right before 6010. Also if 6010 PCI ID is removed from > solo6x10 driver's devices list, the freeze doesn't happen. Probably explains why I don't see lockups

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Can you share some details about the machine you are experiencing the >> problems on? CPU, chipset? I'd try to see if I can recreate the problem. > > See solo.txt.gz attached. Thanks. I can see you have quite a set of video devices there. I

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: >> Does (only) adding the >> >> pci_read_config_word(solo_dev->pdev, PCI_STATUS, ); >> >> in solo_reg_write() help? > > Yes. > I have posted a patch with this change few days ago, I thought you have > noticed it. Well, I think you haven't

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin <andrey_ut...@fastmail.com> writes: > On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote: >> I wonder if the following fixes the problem (completely untested). > > I have given this a run, and it still hangs. Does (only) adding the

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Andrey Utkin writes: > It happens in solo_disp_init at uploading default motion thresholds > array. > > I've got a prints trace with solo6010-fix-lockup branch > https://github.com/bluecherrydvr/linux/tree/solo6010-fix-lockup/drivers/media/pci/solo6x10 > the trace

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

Hans Verkuil writes: > That was probably the reason for the pci_read_config_word in the reg_write > code. Try putting that back (and just that). Yes. I guess a single pci_read_config_word() would suffice. Though it would obviously be much better to identify the place in the

Re: [PATCH] [media] tw686x-kh: Delete an unnecessary check before the function call "video_unregister_device"

SF Markus Elfring writes: > The video_unregister_device() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by:

Re: Non-coherent (streaming) contig-dma?

Sakari Ailus writes: > I sent the set here under the subject "[RFC RESEND 00/11] vb2: Handle user > cache hints, allow drivers to choose cache coherency" last September. Thanks, I will look at this. Unfortunately, I need CPU access to the buffers, it's just that coherent

Non-coherent (streaming) contig-dma?

Hi, I know certain approaches had been tried to allow use of streaming DMA (dma_map_single() etc. - i.e., not coherent) in the media drivers, is there something which can be used at this point (for MMAP method)? Coherent buffers on many systems are very slow (uncacheable), should i simply

[PATCH] Driver for Intersil/Techwell TW686x-based PCIe frame grabbers again

--git a/drivers/staging/media/tw686x/tw686x-core.c b/drivers/staging/media/tw686x/tw686x-core.c new file mode 100644 index 000..5891ea7 --- /dev/null +++ b/drivers/staging/media/tw686x/tw686x-core.c @@ -0,0 +1,140 @@ +/* + * Copyright (C) 2015 Industrial Research Institute for Automation + *

Re: tw686x driver

Hans Verkuil writes: > Heck, if you prefer your driver can be added to staging first, then Ezequiel's > driver commit can directly refer to the staging driver as being derived from > it. Ok, I guess it's fair enough for me. Would you like me to send a patch with paths

Re: tw686x driver

Hans Verkuil writes: > Sorry, I meant V4L2_FIELD_INTERLACED support. Very few applications support > FIELD_TOP/BOTTOM, let alone SEQ_BT. Well, that's doable, though not in SG mode. It still doesn't require memcpy() of uncompressed video. > I don't get it. Getting your

Re: tw686x driver

Hans Verkuil writes: > I have two drivers with different feature sets. Only one can be active > at a time. I have to make a choice which one I'll take and Ezequiel's > version has functionality (audio, interlaced support) which matches best > with existing v4l applications

Re: tw686x driver

Hans Verkuil writes: >> Staging is meant for completely different situation - for immature, >> incomplete code. It has nothing to do with the case. > > It can be for anything that prevents it from being mainlined. It was (still > is?) > used for mature android drivers, for

Re: tw686x driver

Hans Verkuil writes: > There is no point whatsoever in committing a driver and then replacing it > with another which has a different feature set. I'm not going to do > that. Sure, that's why I haven't asked you to do it. Now there is no another driver, as Ezequiel stated -

Re: tw686x driver

Hans Verkuil writes: > When a driver is merged for the first time in the kernel it is always as > a single change, i.e. you don't include the development history as that > would pollute the kernel's history. We don't generally add new drivers with long patch series, that's

Re: tw686x driver

Hi Hans, Hans Verkuil writes: > So lessons learned: > > Krzysztof, next time don't wait many months before posting a new version > fixing > requested changes. Actually, this is not how it happened. On July 3, 2015 I posted the original driver:

Re: H264 headers generation for driver

Andrey Utkin writes: [H.264 headers] > I guess that one acceptable way is to pre-generate all headers for all > needed cases and ship them inlined; for correctness checking purpose, > it is possible to ship also a script or additional source code file > which is

Re: TW686x

Hi Ezequiel, OTOH I don't see any reason preventing you from sending a pull request for the inclusion of the TW686x driver, Mauro could merge this stuff then (assuming it's ready). You don't have to wait for me and a driver doesn't need to be a single patch from a single person. -- Krzysztof

Re: Subjective maturity of tw6869, cx25821, bluecherry/softlogic drivers

Andrey Utkin andrey.ut...@corp.bluecherry.net writes: Also, TW686x are (mini) PCIe while SOLO6110 (and earlier SOLO6010 which produces MPEG4 part 2 instead of H.264) are (mini) PCI. solo6110 is PCI-E, not PCI. No, it's not, both SOLO6010 and SOLO6110 are 32-bit PCI. SOLO6110 Data Sheet

[PATCH] [MEDIA] Add support for TW686[4589]-based frame grabbers.

Audio will be supported with a further patch. Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig index 218144a..32902f2 100644 --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -21,6 +21,7 @@ source drivers/media

Re: Subjective maturity of tw6869, cx25821, bluecherry/softlogic drivers

Nathaniel Bezanson mys...@telcodata.us writes: I found the intersil/techwell TW6869 chip on a very affordable card, and there's a nice looking driver here: https://github.com/igorizyumin/tw6869/ It didn't work for me. Probably because it uses large coherent allocations (which aren't possible

Video driver for Techwell TW686[4589]-based cards.

I'll be attaching a driver for Techwell/Intersil TW686[4589]-based video frame grabbers. It's currently tested only with v4.0 (the system I'm using this on has problems with v4.1) but it should apply and work with current kernels (there might be a trivial conflict in Kconfig and/or Makefile).

[PATCH] MEDIA PCI Kconfig ANALOG_TV - CAMERA

) but it at least doesn't select the TUNERs. Perhaps the following patch would make sense. Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -11,16 +11,16 @@ if MEDIA_PCI_SUPPORT if MEDIA_CAMERA_SUPPORT comment Media

[PATCH] SOLO6x10: Fix G.723 minimum audio period count.

The period count is fixed, don't confuse ALSA. Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/solo6x10/solo6x10-g723.c +++ b/drivers/media/pci/solo6x10/solo6x10-g723.c @@ -48,10 +48,8 @@ /* The solo writes to 1k byte pages, 32 pages, in the dma. Each 1k page

[PATCH] SOLO6x10: remove unneeded register locking and barriers.

readl() and writel() are atomic, we don't need the spin lock. Also, flushing posted write buffer isn't required. Especially on read :-) Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -483,7

[PATCH] SOLO6x10: Remove dead code.

solo_dev and pdev cannot be NULL here. It doesn't matter if we initialized the PCI device or not. Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -134,23 +134,11 @@ static irqreturn_t solo_isr

[PATCH] SOLO6x10: unmap registers only after free_irq().

Fixes a panic on ARM. Diagnosis by Russell King. Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -164,9 +164,9 @@ static void free_solo_dev(struct solo_dev *solo_dev) /* Now

A few SOLO6x10 patches.

Hi, I'm attaching a few patches to SOLO6x10 video frame grabber driver. Nothing out of ordinary, an audio bug fix (nobody using SOLO with audio?), an rmmod-related panic and the register access optimization. Feel free to pick up what you want. The remaining issue is incorrect SDRAM size reported

Re: On register r/w macros/procedures of drivers/media/pci

Andrey Utkin andrey.ut...@corp.bluecherry.net writes: Please check first digit. I mean _5_864, in your post there's 6869. Ok, I just thought it may be a typo. I can now see 5864 is a H.264 encoder, while 686x are simpler frame-grabbers only. Sorry for the noise. -- Krzysztof Halasa Research

Re: On register r/w macros/procedures of drivers/media/pci

Andrey Utkin andrey.ut...@corp.bluecherry.net writes: I am starting a work on driver for techwell tw5864 media grabberencoder. If this is tw6864 then I have a driver mostly completed. Actually I'm using tw6869 but I think this is very similar (4 channels instead of 8 and PCI instead of PCIe). I

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

Andrey Utkin andrey.ut...@corp.bluecherry.net writes: In upstream there's no more module parameter for video standard (NTSC/PAL). But there's VIDIOC_S_STD handling procedure. But it turns out not to work correctly: the frame is offset, so that in the bottom there's black horizontal bar. The

Re: [RFC] solo6x10 freeze, even with Oct 31's linux-next... any ideas or help?

Andrey Utkin andrey.ut...@corp.bluecherry.net writes: The problem is the following: after ~1 hour of uptime with working application reading the streams, one card (the same one every time) stops producing interrupts (counter in /proc/interrupts freezes), and all threads reading from that card

SOLO6x10: fix a race in IRQ handler.

the IRQ rate on ARMv6 dual core CPU. Signed-off-by: Krzysztof Hałasa khal...@piap.pl --- a/drivers/media/pci/solo6x10/solo6x10-core.c +++ b/drivers/media/pci/solo6x10/solo6x10-core.c @@ -105,11 +105,8 @@ static irqreturn_t solo_isr(int irq, void *data) if (!status) return

Re: SOLO6x10: fix a race in IRQ handler.

Andrey Utkin andrey.krieger.ut...@gmail.com writes: could you please point to some reading which explains this moment? Or you just know this from experience? The solo device specs are very terse about this, so I considered that it should work fine without regard to how fast we write back to

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

Ralf Baechle r...@linux-mips.org writes: 16K is a silver bullet solution to all cache aliasing problems. So if your issue persists with 16K page size, it's not a cache aliasing issue. Aside there are generally performance gains from the bigger page size. I wonder why isn't the issue present

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

Ralf Baechle r...@linux-mips.org writes: The kernel is supposed to perform the necessary cache flushing, so any remaining aliasing issue would be considered a bug. But the code is performance sensitive, some of the problem cases are twisted and complex so bugs and unsolved corner cases show

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

Ralf Baechle r...@linux-mips.org writes: That's fine. You just need to ensure that there are no virtual aliases. Does this include virtual aliasing between a 4 KB TLB-mapped page and a kseg0 address? I don't really have two TLBs pointing to the same page. One way to do so is to increase the

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

Ralf Baechle r...@linux-mips.org writes: That's fine. You just need to ensure that there are no virtual aliases. One way to do so is to increase the page size to 16kB. Checked, this thing works fine with 16 KB pages. -- Krzysztof Halasa Research Institute for Automation and Measurements

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

Please forgive me my MIPS TLB ignorance. It seems there is a TLB entry pointing to the userspace buffer at the time the kernel pointer (kseg0) is used. Is is an allowed situation on MIPS 24K? buffer: len 0x1000 (first page), userspace pointer 0x77327000, kernel pointer 0x867ac000

V4L2_BUF_FLAG_NO_CACHE_*

Hi, found them looking for my V4L2 + mmap + MIPS solution... Is the following intentional? Some out-of-tree code maybe? $ grep V4L2_BUF_FLAG_NO_CACHE_ * -r Documentation/DocBook/media/v4l/io.xml: entryconstantV4L2_BUF_FLAG_NO_CACHE_INVALIDATE/constant/entry

[PATCH] SOLO6x10: Fix video frame type (I/P/B).

Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c index 7a2fd98..27e9a0a 100644 --- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c +++ b/drivers/staging/media/solo6x10

Re: Suspected cache coherency problem on V4L2 and AR7100 CPU

I'm debugging a problem with a SOLO6110-based H.264 PCI video encoder on Atheros AR7100-based (MIPS, big-endian) platform. BTW this CPU obviously has VIPT data cache, this means a physical page with multiple virtual addresses (e.g. mapped multiple times) may and will be cached multiple times.

Suspected cache coherency problem on V4L2 and AR7100 CPU

Hi, I'm debugging a problem with a SOLO6110-based H.264 PCI video encoder on Atheros AR7100-based (MIPS, big-endian) platform. The problem manifests itself with stale data being returned by the driver (using ioctl VIDIOC_DQBUF). The stale date always starts and ends on 32-byte cache line

[PATCH] SOLO6x10: Remove unused #define SOLO_DEFAULT_GOP

Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/staging/media/solo6x10/solo6x10.h b/drivers/staging/media/solo6x10/solo6x10.h index 6f91d2e..f1bbb8c 100644 --- a/drivers/staging/media/solo6x10/solo6x10.h +++ b/drivers/staging/media/solo6x10/solo6x10.h @@ -94,7 +94,6

[PATCH] SOLO6x10: don't do DMA from stack in solo_dma_vin_region().

Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/staging/media/solo6x10/solo6x10-disp.c b/drivers/staging/media/solo6x10/solo6x10-disp.c index 32d9953..884512e 100644 --- a/drivers/staging/media/solo6x10/solo6x10-disp.c +++ b/drivers/staging/media/solo6x10/solo6x10-disp.c

[PATCH] SOLO6x10: Fix video encoding on big-endian systems.

Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c index a4c5896..e501287 100644 --- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c +++ b/drivers/staging/media/solo6x10

[PATCH] SOLO6x10: Fix video headers on certain hardware.

On certain platforms a sequence of dma_map_sg() and dma_unmap_sg() discards data previously stored in the buffers. Build video headers only after the DMA is completed. Signed-off-by: Krzysztof Hałasa khal...@piap.pl diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c b/drivers

SOLO6x10 MPEG4/H.264 encoder driver

Hi Hans, I'm trying to move to Linux 3.11 and I noticed you've made some significant changes to the SOLO6x10 driver. While I don't yet have the big picture, I can see some regressions here: - the driver doesn't even try to work on big endian systems (I'm using IXP4xx-based system which is BE).

Re: SOLO6x10 MPEG4/H.264 encoder driver

Hans Verkuil hverk...@xs4all.nl writes: I took the latest bluecherry code as the basis for the changes, merging what I could from the kernel code. Unfortunately this was very hard to do backport, so I decided to take bluecherry's code. I see, thanks for speedy explanation. If I may suggest