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:
>
> -
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 field:interlaced-tb]"
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.
Actu
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 requeste
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 bott
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 CCIR
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 numberi
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],
"ipu2_csi1_mu
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
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
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 t
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
> ot
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
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 fix
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 desi
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 ev
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.
Right
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
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: in interlaced mode we ne
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?
>
> Well, given that this bit ex
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.
--- a/drivers/staging/media/imx/imx-
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]'
medi
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 just need to capture an in
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]
"ipu2_csi1_mux":
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 months ago but I don't know
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 below, also when there
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} =>
>> fmt.pix={720x576, pixe
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 '"adv718
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 suc
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 V4L2_PIX_FMT_SGRBG8:
>> case V4
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
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -340,7 +340,7 @@ static int
Bitmask for the MIPI CSI-2 data PHY status doesn't seem to be correct.
Fix it.
Signed-off-by: Krzysztof Hałasa
--- 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(struct csi2_dev
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:
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
Industrial Research Institute
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
> +++ b/drivers/media/pci/tw686x/tw686x-video.c
"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 some channel's dev is null(i
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 = &dev->video_channels[ch];
>> + vc->dev = dev;
>> + vc->ch = ch;
Signed-off-by: Krzysztof Hałasa
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 @@ int tw686x_video_init
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
> https://github.com/torva
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 *solo_dev, int reg,
>
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 :-)
I will have a look.
--
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 will see what I can do with thi
Andrey Utkin writes:
>> Does (only) adding the
>>
>> pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
>>
>> 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 sent me a copy. Anyway, i
Andrey Utkin 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
pci_read_config_word(solo_dev->pdev
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 itself in jpg:
> https://decent.
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
driver which needs t
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: Markus Elfring
> ---
> drivers/stag
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
RAM is way too slow on A
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 add/rep
4
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
+ * and Measurements PIAP
+ *
+ * Written by Krzysztof Hałasa.
+ *
+ * This program is free software; you can redistribu
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 changed to staging/?
How
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 driver in staging is much
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 and the typical use cas
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 example.
What is prev
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 - there is just one
dri
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 right.
That's because
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:
http://www.spinics.net/lists/linux-media/msg91474
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 able to generate same headers.
I
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 p
Andrey Utkin 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
1.2.5. PCI/HOST Interface
Audio will be supported with a further patch.
Signed-off-by: Krzysztof Hałasa
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/pci/
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).
Fi
Nathaniel Bezanson 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 on ARM, and shoul
eal camera in a laptop) but it at least doesn't select the
TUNERs.
Perhaps the following patch would make sense.
Signed-off-by: Krzysztof Hałasa
--- a/drivers/media/pci/Kconfig
+++ b/drivers/media/pci/Kconfig
@@ -11,16 +11,16 @@ if MEDIA_PCI_SUPPORT
if MEDIA_CAMERA_SUPPORT
comment &q
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
--- 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(int irq,
The period count is fixed, don't confuse ALSA.
Signed-off-by: Krzysztof Hałasa
--- 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
* is broken down
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
--- a/drivers/media/pci/solo6x10/solo6x10-core.c
+++ b/drivers/media/pci/solo6x10/solo6x10-core.c
@@ -483,7 +483,6
Fixes a panic on ARM. Diagnosis by Russell King.
Signed-off-by: Krzysztof Hałasa
--- 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 cleanup the PCI
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 reporte
Andrey Utkin 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 Institute for Automation and Mea
Andrey Utkin writes:
> I am starting a work on driver for techwell tw5864 media grabber&encoder.
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 have 6864s but haven't yet
tri
Andrey Utkin 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 S_STD ioctl call actually ma
Andrey Utkin 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 that register.
The SOLO IRQ
e the IRQ rate on ARMv6
dual core CPU.
Signed-off-by: Krzysztof Hałasa
--- 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 IRQ
Andrey Utkin 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 hang forever in
> ioctl(VIDI
Ralf Baechle 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 up every now and
Ralf Baechle 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 in other cases. P
Ralf Baechle 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 PIAP
Al. Jerozolimski
Ralf Baechle 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 page size to 16k
Signed-off-by: Krzysztof Hałasa
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/solo6x10-v4l2-enc.c
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:
V4L2_BUF_FLAG_NO_CACHE_INVALIDATE
Documentation/DocBook/media/v4l/io.xml:
V4L2_BUF_FLAG_NO
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
> 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.
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 boundary
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
diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
b/drivers/staging/media
Signed-off-by: Krzysztof Hałasa
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/solo6x10-v4l2-enc.c
Signed-off-by: Krzysztof Hałasa
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
@@ -176,18 +176,26
Signed-off-by: Krzysztof Hałasa
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 @@
#define
Hans Verkuil 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 something (especi
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).
90 matches
Mail list logo