Re: [PATCH] media: uvcvideo: Add boottime clock support
On Thu, Oct 18, 2018 at 5:50 AM Laurent Pinchart wrote: > > Hi Tomasz, > > On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote: > > On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote: > > > On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote: > > >> Android requires camera timestamps to be reported with > > >> CLOCK_BOOTTIME to sync timestamp with other sensor sources. > > > > > > What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If the > > > monotonic clock has shortcomings that make its use impossible for proper > > > synchronization, then we should consider switching to CLOCK_BOOTTIME > > > globally in V4L2, not in selected drivers only. > > > > CLOCK_BOOTTIME includes the time spent in suspend, while > > CLOCK_MONOTONIC doesn't. I can imagine the former being much more > > useful for anything that cares about the actual, long term, time > > tracking. Especially important since suspend is a very common event on > > Android and doesn't stop the time flow there, i.e. applications might > > wake up the device to perform various tasks at necessary times. > > Sure, but this patch mentions timestamp synchronization with other sensors, > and from that point of view, I'd like to know what is wrong with the monotonic > clock if all devices use it. AFAIK the sensors mentioned there are not camera sensors, but rather things we normally put under IIO, e.g. accelerometers, gyroscopes and so on. I'm not sure how IIO deals with timestamps, but Android seems to operate in the CLOCK_BOTTIME domain. Let me add some IIO folks. Gwendal, Alexandru, do you think you could shed some light on how we handle IIO sensors timestamps across the kernel, Chrome OS and Android? > > > Generally, I'd see a V4L2_BUF_FLAG_TIMESTAMP_BOOTTIME flag being added > > and user space being given choice to select the time stamp base it > > needs, perhaps by setting the flag in v4l2_buffer struct at QBUF time? > > I would indeed prefer a mechanism specified at the V4L2 API level, with an > implementation in the V4L2 core, over a module parameter. If the goal is to > use the boottime clock for synchronization purpose, we need to make sure that > all drivers will support it correctly. Patching drivers one by one doesn't > really scale. Agreed. Best regards, Tomasz
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Oct 18 05:00:10 CEST 2018 media-tree git hash:490d84f6d73c12f4204241cff8651eed60aae914 media_build git hash: 9f419c414672676f63e85a61ea99df0ddcd6e9a7 v4l-utils git hash: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.11-marune linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-rc6-i686: OK linux-4.19-rc6-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v7] media: add imx319 camera sensor driver
On Tue, Oct 16, 2018 at 8:50 PM Sakari Ailus wrote: > > Hi Tomasz, > > On Fri, Oct 12, 2018 at 05:06:56PM +0900, Tomasz Figa wrote: > > On Fri, Oct 12, 2018 at 4:58 PM Sakari Ailus > > wrote: > > > > > > Hi Tomasz, > > > > > > On Fri, Oct 12, 2018 at 01:51:10PM +0900, Tomasz Figa wrote: > > > > Hi Sakari, > > > > > > > > On Wed, Sep 26, 2018 at 11:38 AM wrote: > > > > > > > > > > From: Bingbu Cao > > > > > > > > > > Add a v4l2 sub-device driver for the Sony imx319 image sensor. > > > > > This is a camera sensor using the i2c bus for control and the > > > > > csi-2 bus for data. > > > > > > > > > > This driver supports following features: > > > > > - manual exposure and analog/digital gain control support > > > > > - vblank/hblank control support > > > > > - 4 test patterns control support > > > > > - vflip/hflip control support (will impact the output bayer order) > > > > > - support following resolutions: > > > > > - 3264x2448, 3280x2464 @ 30fps > > > > > - 1936x1096, 1920x1080 @ 60fps > > > > > - 1640x1232, 1640x922, 1296x736, 1280x720 @ 120fps > > > > > - support 4 bayer orders output (via change v/hflip) > > > > > - SRGGB10(default), SGRBG10, SGBRG10, SBGGR10 > > > > > > > > > > Cc: Tomasz Figa > > > > > Cc: Sakari Ailus > > > > > Signed-off-by: Bingbu Cao > > > > > Signed-off-by: Tianshu Qiu > > > > > > > > > > --- > > > > > > > > > > This patch is based on sakari's media-tree git: > > > > > https://git.linuxtv.org/sailus/media_tree.git/log/?h=for-4.20-1 > > > > > > > > > > Changes from v5: > > > > > - add some comments for gain calculation > > > > > - use lock to protect the format > > > > > - fix some style issues > > > > > > > > > > Changes from v4 to v5: > > > > > - use single PLL for all internal clocks > > > > > - change link frequency to 482.4MHz > > > > > - adjust frame timing for 2x2 binning modes > > > > >and enlarge frame readout time > > > > > - get CSI-2 link frequencies and external clock > > > > >from firmware > > > > > > > > If I remember correctly, that was suggested by you. Why do we need to > > > > specify link frequency in firmware if it's fully configured by the > > > > driver, with the only external dependency being the external clock? > > > > > > The driver that's now in upstream supports, for now, a very limited set of > > > configurations from what the sensor supports. These are more or less > > > tailored to the particular system where it is being used right now (output > > > image size, external clock frequency, frame rates, link frequencies etc.). > > > > As a side note, they're tailored to exactly the system I mentioned, > > with different link frequency hardcoded in the firmware, coming from > > earlier stage of development. > > > > > If the same sensor is needed elsewhere (quite likely), the configuration > > > needed elsewhere is very likely to be different from what you're using > > > now. > > > > > > The link frequency in particular is important as using a different link > > > frequency (which could be fine elsewhere) could cause EMI issues, e.g. > > > rendering your GPS receiver inoperable during the time the camera sensor > > > is > > > streaming images. > > > > > > Should new configurations be added to this driver to support a different > > > system, the link frequencies used by those configurations may be > > > problematic to your system, and after a software update the driver could > > > as > > > well use those new frequencies. That's a big no-no. > > > > > > > Okay, those are some valid points indeed, thanks for clarifying. > > > > > > > > > > We're having problems with firmware listing the link frequency from v4 > > > > and we can't easily change it anymore to report the new one. I feel > > > > like this dependency on the firmware here is unnecessary, as long as > > > > the external clock frequency matches. > > > > > > This is information you really need to know. > > > > > > A number of older drivers do not use the link frequency information from > > > the firmware but that comes with a risk. Really, it's better to change the > > > frequency now to something you can choose, rather than have it changed > > > later on to something someone else chose for you. > > > > I guess it means that we have to carry a local downstream patch that > > bypasses this check, since we cannot easily change the firmware > > anymore. > > Is there a possibility update the firmware, or carry an SSDT overlay as part > of the software? The options are laid out in > Documentation/acpi/ssdt-overlays.txt . Do remember to pay attention to the > revision field --- also in future Coreboot updates. > Generally we try to avoid updating the firmware in the field, but most of the time there is a reason to do it anyway, so that might eventually happen. Let me try to figure out. > > > > An alternative would be to make the driver try to select a frequency > > that matches what's in the firmware, but issue a warning and fall back > > to a default one if a m
Re: [PATCH v11 1/5] venus: firmware: add routine to reset ARM9
On Wed, 2018-10-17 at 11:49 +0300, Stanimir Varbanov wrote:
> On 10/08/2018 04:32 PM, Vikash Garodia wrote:
> > Add routine to reset the ARM9 and brings it out of reset. Also
> > abstract the Venus CPU state handling with a new function. This
> > is in preparation to add PIL functionality in venus driver.
[]
> > diff --git a/drivers/media/platform/qcom/venus/core.h
> > b/drivers/media/platform/qcom/venus/core.h
[]
> > @@ -129,6 +130,7 @@ struct venus_core {
> > struct device *dev;
> > struct device *dev_dec;
> > struct device *dev_enc;
> > + bool use_tz;
>
> could you make it unsigned? For more info please run checkpatch --strict.
>
> I know that we have structure members of type bool already - that should
> be fixed with follow-up patches, I guess.
That's probably not necessary.
I personally have no issue with bool struct members that
are only used on a transitory basis and not used by hardware
or shared between multiple cpus with different hardware
alignment requirements.
Nothing in this struct is saved or shared.
Perhaps the checkpatch message should be expanded to
enumerate when bool use in a struct is acceptable.
Re: [PATCH v3 00/16] i.MX media mem2mem scaler
Hi Philipp, On 10/12/18 5:29 PM, Steve Longerbeam wrote: But one last thing. Conversions to and from YV12 are producing images with wrong colors, it looks like the .uv_swapped boolean needs to be checked additionally somewhere. Any ideas? Sorry, this was my fault. I fixed this in "gpu: ipu-v3: Add chroma plane offset overrides to ipu_cpmem_set_image()" in my fork g...@github.com:slongerbeam/mediatree.git, branch imx-mem2mem.3. Steve
Re: [PATCH v3 10/16] gpu: ipu-v3: image-convert: select optimal seam positions
On 10/17/18 4:10 AM, Philipp Zabel wrote:
On Fri, 2018-10-12 at 17:33 -0700, Steve Longerbeam wrote:
On 09/18/2018 02:34 AM, Philipp Zabel wrote:
+/*
+ * Tile left edges are required to be aligned to multiples of 8 bytes
+ * by the IDMAC.
+ */
+static inline u32 tile_left_align(const struct ipu_image_pixfmt *fmt)
+{
+ return fmt->planar ? 8 * fmt->uv_width_dec : 64 / fmt->bpp;
+}
As I indicated, shouldn't this be
return fmt->planar ? 8 * fmt->uv_width_dec : 8;
?
Just from a unit analysis perspective, "64 / fmt->bp" has
units of pixels / 8-bytes, it should have units of bytes.
The tile alignment is in pixels, not in bytes.
Ah, yes of course you are right, I used to know this :) I am
loosing track of this code.
For 16-bit and 32-bit
packed formats, we only need to align to 4 or 2 pixels, respectively,
as the LCM of 8-byte alignment and 2-byte or 4-byte pixel size is
always 8 bytes.
Yes I agree, the LCM of 8-byte alignment and bytes-per-pixel should
be the tile left edge alignment in pixels.
But now that you pointed it out, it is quite obvious that this can't
work for 24-bit packed formats. Here the LCM of 8-byte alignment and 3-
byte pixels is 24 bytes, or 8 pixels.
How about:
if (fmt->planar)
return fmt->uv_packed ? 8 : 8 * fmt->uv_width_dec;
else
return fmt->bpp == 32 ? 2 : fmt->bpp == 16 ? 4 : 8;
Yep, that looks better. I tested this and it works fine.
Steve
Re: i.MX6 IPU CSI analog video input on Ventana
On 10/17/18 4:05 PM, Tim Harvey wrote: On Wed, Oct 17, 2018 at 2:33 PM Steve Longerbeam wrote: Hi Tim, On 10/17/18 1:38 PM, Tim Harvey wrote: On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: 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_mux":2->"ipu2_csi1":0[1], "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] I think it would be great if these changes make their way upstream. The details could be refined then. Krzysztof / Steve / Philipp, I jumped back onto IMX6 video capture from the adv7180 the other day trying to help out a customer that's using mainline and found things are still not working right. Where is all of this at these days? If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' v3 series (https://patchwork.kernel.org/cover/10626499/) I rolling/split (un-synchronized) video using: # Setup links media-ctl -r media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" # stream JPEG/RTP/UDP gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video3' does not support progressive interlacing I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png Are there other patches I need or different field formats above with 4.19? Do any of the other kernels work without patchsets that you know of between 4.16 and 4.19? First, the v3 series is out of date. Please apply the latest v5 posting of that series. See the imx.rst doc regarding field type negotiation, all pads starting at ipu2_csi1:1 should be 'seq-bt' or 'seq-tb' until the capture device, which should be set to 'interlaced' to enable IDMAC interweave. The ADV7180 now correctly sets its field type to alternate, which imx-media-csi.c translates to seq-tb or seq-bt at its output pad. See the SabreAuto examples in the doc. For the rolling/split image problem, try the attached somewhat hackish patch. There used to be code in imx-media-csi.c that searched for the backend sensor and queries via .g_skip_frames whether the sensor produces bad frames at first stream-on. But there was push-back on that, so the attached is another approach that doesn't require searching for a backend sensor. Steve, Thanks - I hadn't noticed the updated series. I've built it on top of linux-media/master and tested with: - Testing linux-media/master + your v5 now: # Use simple interweaving media-ctl -r # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":2 -> "ipu2_csi1 capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1':1 [fmt:AYUV32/720x480]" # Configure ipu_csi capture interface (/dev/video7) v4l2-ctl -d7 --set-fmt-video=field=interlaced_bt # Stream JPEG/RTP/UDP gst-launch-1.0 v4l2src device=/dev/video7 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000 ^^ gives me ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video7' does not support progressive interlacing I'm assuming this is because the format is still 'interlaced' - not sure how to stream this from GStreamer? I don't know what v4l2src plugin is trying to say by "progressive interlacing" - that's meaningless, the video is either progressive or interlaced, not both. But what is probably meant is v
Re: i.MX6 IPU CSI analog video input on Ventana
On Wed, Oct 17, 2018 at 2:33 PM Steve Longerbeam wrote: > > Hi Tim, > > On 10/17/18 1:38 PM, Tim Harvey wrote: > > On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: > > 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_mux":2->"ipu2_csi1":0[1], > "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" > media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > I think it would be great if these changes make their way upstream. > The details could be refined then. > > Krzysztof / Steve / Philipp, > > I jumped back onto IMX6 video capture from the adv7180 the other day > trying to help out a customer that's using mainline and found things > are still not working right. Where is all of this at these days? > > If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' > v3 series (https://patchwork.kernel.org/cover/10626499/) I > rolling/split (un-synchronized) video using: > > # Setup links > media-ctl -r > media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' > media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' > media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' > media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' > media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' > # Configure pads > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" > media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" > # stream JPEG/RTP/UDP > gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! > jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device > '/dev/video3' does not support progressive interlacing > > I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x > HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph > is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png > > Are there other patches I need or different field formats above with > 4.19? Do any of the other kernels work without patchsets that you know > of between 4.16 and 4.19? > > > First, the v3 series is out of date. Please apply the latest v5 posting > of that series. See the imx.rst doc regarding field type negotiation, > all pads starting at ipu2_csi1:1 should be 'seq-bt' or 'seq-tb' until the > capture device, which should be set to 'interlaced' to enable IDMAC > interweave. The ADV7180 now correctly sets its field type to alternate, > which imx-media-csi.c translates to seq-tb or seq-bt at its output pad. > > See the SabreAuto examples in the doc. > > For the rolling/split image problem, try the attached somewhat hackish patch. > There used to be code in imx-media-csi.c that searched for the backend sensor > and queries via .g_skip_frames whether the sensor produces bad frames at first > stream-on. But there was push-back on that, so the attached is another > approach that doesn't require searching for a backend sensor. Steve, Thanks - I hadn't noticed the updated series. I've built it on top of linux-media/master and tested with: - Testing linux-media/master + your v5 now: # Use simple interweaving media-ctl -r # Setup links media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":2 -> "ipu2_csi1 capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480 field:seq-bt]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1':1 [fmt:AYUV32/720x480]" # Configure ipu_csi capture interface (/dev/video7) v4l2-ctl -d7 --set-fmt-video=field=interlaced_bt # Stream JPEG/RTP/UDP gst-launch-1.0 v4l2src device=/dev/video7 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=5000 ^^ gives me ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video7' does not support progressive interlacing I'm assuming this is because the format is still 'interlaced' - not sure how to stream this from GStreamer? # Use VDIC motion compensated de-interlace # Setup links media-ctl -r media-ctl -l "'adv7180 2-00
[PATCH v3 2/2] seco-cec: add Consumer-IR support
From: Ettore Chimenti
Introduce support for Consumer-IR into seco-cec driver, as it shares the
same interrupt for receiving messages.
The device decodes RC5 signals only, defaults to hauppauge mapping.
It will spawn an input interface using the RC framework (like CEC
device).
Signed-off-by: Ettore Chimenti
Reviewed-by: Sean Young
---
drivers/media/platform/Kconfig | 10 ++
drivers/media/platform/seco-cec/seco-cec.c | 125 -
drivers/media/platform/seco-cec/seco-cec.h | 11 ++
3 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 51cd1fd005e3..e6b45da2af6d 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -625,6 +625,16 @@ config VIDEO_SECO_CEC
CEC bus is present in the HDMI connector and enables communication
between compatible devices.
+config VIDEO_SECO_RC
+ bool "SECO Boards IR RC5 support"
+ depends on VIDEO_SECO_CEC
+ select RC_CORE
+ help
+ If you say yes here you will get support for the
+ SECO Boards Consumer-IR in seco-cec driver.
+ The embedded controller supports RC5 protocol only, default mapping
+ is set to rc-hauppauge.
+
endif #CEC_PLATFORM_DRIVERS
menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/seco-cec/seco-cec.c
b/drivers/media/platform/seco-cec/seco-cec.c
index 9ac9a1f36bc0..c5af913d4715 100644
--- a/drivers/media/platform/seco-cec/seco-cec.c
+++ b/drivers/media/platform/seco-cec/seco-cec.c
@@ -26,6 +26,8 @@ struct secocec_data {
struct platform_device *pdev;
struct cec_adapter *cec_adap;
struct cec_notifier *notifier;
+ struct rc_dev *ir;
+ char ir_input_phys[32];
int irq;
};
@@ -364,6 +366,114 @@ struct cec_adap_ops secocec_cec_adap_ops = {
.adap_transmit = secocec_adap_transmit,
};
+#ifdef CONFIG_VIDEO_SECO_RC
+static int secocec_ir_probe(void *priv)
+{
+ struct secocec_data *cec = priv;
+ struct device *dev = cec->dev;
+ int status;
+ u16 val;
+
+ /* Prepare the RC input device */
+ cec->ir = devm_rc_allocate_device(dev, RC_DRIVER_SCANCODE);
+ if (!cec->ir)
+ return -ENOMEM;
+
+ snprintf(cec->ir_input_phys, sizeof(cec->ir_input_phys),
+"%s/input0", dev_name(dev));
+
+ cec->ir->device_name = dev_name(dev);
+ cec->ir->input_phys = cec->ir_input_phys;
+ cec->ir->input_id.bustype = BUS_HOST;
+ cec->ir->input_id.vendor = 0;
+ cec->ir->input_id.product = 0;
+ cec->ir->input_id.version = 1;
+ cec->ir->driver_name = SECOCEC_DEV_NAME;
+ cec->ir->allowed_protocols = RC_PROTO_BIT_RC5;
+ cec->ir->priv = cec;
+ cec->ir->map_name = RC_MAP_HAUPPAUGE;
+ cec->ir->timeout = MS_TO_NS(100);
+
+ /* Clear the status register */
+ status = smb_rd16(SECOCEC_STATUS_REG_1, &val);
+ if (status != 0)
+ goto err;
+
+ status = smb_wr16(SECOCEC_STATUS_REG_1, val);
+ if (status != 0)
+ goto err;
+
+ /* Enable the interrupts */
+ status = smb_rd16(SECOCEC_ENABLE_REG_1, &val);
+ if (status != 0)
+ goto err;
+
+ status = smb_wr16(SECOCEC_ENABLE_REG_1,
+ val | SECOCEC_ENABLE_REG_1_IR);
+ if (status != 0)
+ goto err;
+
+ dev_dbg(dev, "IR enabled");
+
+ status = devm_rc_register_device(dev, cec->ir);
+
+ if (status) {
+ dev_err(dev, "Failed to prepare input device");
+ cec->ir = NULL;
+ goto err;
+ }
+
+ return 0;
+
+err:
+ smb_rd16(SECOCEC_ENABLE_REG_1, &val);
+
+ smb_wr16(SECOCEC_ENABLE_REG_1,
+val & ~SECOCEC_ENABLE_REG_1_IR);
+
+ dev_dbg(dev, "IR disabled");
+ return status;
+}
+
+static int secocec_ir_rx(struct secocec_data *priv)
+{
+ struct secocec_data *cec = priv;
+ struct device *dev = cec->dev;
+ u16 val, status, key, addr, toggle;
+
+ if (!cec->ir)
+ return -ENODEV;
+
+ status = smb_rd16(SECOCEC_IR_READ_DATA, &val);
+ if (status != 0)
+ goto err;
+
+ key = val & SECOCEC_IR_COMMAND_MASK;
+ addr = (val & SECOCEC_IR_ADDRESS_MASK) >> SECOCEC_IR_ADDRESS_SHL;
+ toggle = (val & SECOCEC_IR_TOGGLE_MASK) >> SECOCEC_IR_TOGGLE_SHL;
+
+ rc_keydown(cec->ir, RC_PROTO_RC5, RC_SCANCODE_RC5(addr, key), toggle);
+
+ dev_dbg(dev, "IR key pressed: 0x%02x addr 0x%02x toggle 0x%02x", key,
+ addr, toggle);
+
+ return 0;
+
+err:
+ dev_err(dev, "IR Receive message failed (%d)", status);
+ return -EIO;
+}
+#else
+static void secocec_ir_rx(struct secocec_data *priv)
+{
+}
+
+static int secocec_ir_probe(void *priv)
+{
+ return 0;
+}
+#endif
+
static irqreturn_t secocec_irq_handler(int irq, void *priv)
{
[PATCH v3 1/2] media: add SECO cec driver
From: Ettore Chimenti
This patch adds support to the CEC device implemented with a STM32
microcontroller in X86 SECO Boards, including UDOO X86.
The communication is achieved via Braswell integrated SMBus
(i2c-i801). The driver use direct access to the PCI addresses, due to
the limitations of the specific driver in presence of ACPI calls.
The basic functionalities are tested with success with cec-ctl and
cec-compliance.
Inspired by cros-ec-cec implementation, attaches to i915 driver
cec-notifier.
Signed-off-by: Ettore Chimenti
---
MAINTAINERS| 6 +
drivers/media/platform/Kconfig | 12 +
drivers/media/platform/Makefile| 2 +
drivers/media/platform/seco-cec/Makefile | 1 +
drivers/media/platform/seco-cec/seco-cec.c | 699 +
drivers/media/platform/seco-cec/seco-cec.h | 130
6 files changed, 850 insertions(+)
create mode 100644 drivers/media/platform/seco-cec/Makefile
create mode 100644 drivers/media/platform/seco-cec/seco-cec.c
create mode 100644 drivers/media/platform/seco-cec/seco-cec.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ece30f15777..1062912a5ff4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12972,6 +12972,12 @@ L: sdricohcs-de...@lists.sourceforge.net
(subscribers-only)
S: Maintained
F: drivers/mmc/host/sdricoh_cs.c
+SECO BOARDS CEC DRIVER
+M: Ettore Chimenti
+S: Maintained
+F: drivers/media/platform/seco-cec/seco-cec.c
+F: drivers/media/platform/seco-cec/seco-cec.h
+
SECURE COMPUTING
M: Kees Cook
R: Andy Lutomirski
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 94c1fe0e9787..51cd1fd005e3 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -613,6 +613,18 @@ config VIDEO_TEGRA_HDMI_CEC
The CEC bus is present in the HDMI connector and enables communication
between compatible devices.
+config VIDEO_SECO_CEC
+ tristate "SECO Boards HDMI CEC driver"
+ depends on (X86 || IA64) || COMPILE_TEST
+ depends on PCI && DMI
+ select CEC_CORE
+ select CEC_NOTIFIER
+ help
+ This is a driver for SECO Boards integrated CEC interface.
+ Selecting it will enable support for this device.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
endif #CEC_PLATFORM_DRIVERS
menuconfig SDR_PLATFORM_DRIVERS
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 41322ab65802..5d2b06c4c68a 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -53,6 +53,8 @@ obj-$(CONFIG_VIDEO_TEGRA_HDMI_CEC)+= tegra-cec/
obj-y += stm32/
+obj-$(CONFIG_VIDEO_SECO_CEC) += seco-cec/
+
obj-y += davinci/
obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o
diff --git a/drivers/media/platform/seco-cec/Makefile
b/drivers/media/platform/seco-cec/Makefile
new file mode 100644
index ..09900b087d02
--- /dev/null
+++ b/drivers/media/platform/seco-cec/Makefile
@@ -0,0 +1 @@
+obj-y += seco-cec.o
diff --git a/drivers/media/platform/seco-cec/seco-cec.c
b/drivers/media/platform/seco-cec/seco-cec.c
new file mode 100644
index ..9ac9a1f36bc0
--- /dev/null
+++ b/drivers/media/platform/seco-cec/seco-cec.c
@@ -0,0 +1,699 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * CEC driver for SECO X86 Boards
+ *
+ * Author: Ettore Chimenti
+ * Copyright (C) 2018, SECO Srl.
+ * Copyright (C) 2018, Aidilab Srl.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* CEC Framework */
+#include
+
+#include "seco-cec.h"
+
+struct secocec_data {
+ struct device *dev;
+ struct platform_device *pdev;
+ struct cec_adapter *cec_adap;
+ struct cec_notifier *notifier;
+ int irq;
+};
+
+#define smb_wr16(cmd, data) smb_word_op(CMD_WORD_DATA, SECOCEC_MICRO_ADDRESS, \
+cmd, data, SMBUS_WRITE, NULL)
+#define smb_rd16(cmd, res) smb_word_op(CMD_WORD_DATA, SECOCEC_MICRO_ADDRESS, \
+ cmd, 0, SMBUS_READ, res)
+
+static int smb_word_op(short data_format, u16 slave_addr, u8 cmd, u16 data,
+ u8 operation, u16 *result)
+{
+ unsigned int count;
+ short _data_format;
+ int status = 0;
+
+ switch (data_format) {
+ case CMD_BYTE_DATA:
+ _data_format = BRA_SMB_CMD_BYTE_DATA;
+ break;
+ case CMD_WORD_DATA:
+ _data_format = BRA_SMB_CMD_WORD_DATA;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ /* Active wait until ready */
+ for (count = 0; count <= SMBTIMEOUT; ++count) {
+ if (!(inb(HSTS) & BRA_INUSE_STS))
+ break;
+ u
[PATCH v3 0/2] Add SECO Boards CEC device driver
This series of patches aims to add CEC functionalities to SECO devices, in particular UDOO X86. The communication is achieved via Braswell SMBus (i2c-i801) to the onboard STM32 microcontroller that handles the CEC signals. The driver use direct access to the PCI addresses, due to the limitations of the specific driver in presence of ACPI calls. The basic functionalities are tested with success with cec-ctl and cec-compliance. v3: - Refactored rx/tx for loops - Removed more debug prints - Sorted headers v2: - Removed useless debug prints - Added DMI && PCI to dependences - Removed useless ifdefs - Renamed all irda references to ir - Fixed SPDX clause - Several style fixes Ettore Chimenti (2): media: add SECO cec driver seco-cec: add Consumer-IR support MAINTAINERS| 6 + drivers/media/platform/Kconfig | 22 + drivers/media/platform/Makefile| 2 + drivers/media/platform/seco-cec/Makefile | 1 + drivers/media/platform/seco-cec/seco-cec.c | 822 + drivers/media/platform/seco-cec/seco-cec.h | 141 6 files changed, 994 insertions(+) create mode 100644 drivers/media/platform/seco-cec/Makefile create mode 100644 drivers/media/platform/seco-cec/seco-cec.c create mode 100644 drivers/media/platform/seco-cec/seco-cec.h -- 2.18.0
Re: [PATCH] media: uvcvideo: Add boottime clock support
Hi Tomasz, On Wednesday, 17 October 2018 11:28:52 EEST Tomasz Figa wrote: > On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart wrote: > > On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote: > >> Android requires camera timestamps to be reported with > >> CLOCK_BOOTTIME to sync timestamp with other sensor sources. > > > > What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If the > > monotonic clock has shortcomings that make its use impossible for proper > > synchronization, then we should consider switching to CLOCK_BOOTTIME > > globally in V4L2, not in selected drivers only. > > CLOCK_BOOTTIME includes the time spent in suspend, while > CLOCK_MONOTONIC doesn't. I can imagine the former being much more > useful for anything that cares about the actual, long term, time > tracking. Especially important since suspend is a very common event on > Android and doesn't stop the time flow there, i.e. applications might > wake up the device to perform various tasks at necessary times. Sure, but this patch mentions timestamp synchronization with other sensors, and from that point of view, I'd like to know what is wrong with the monotonic clock if all devices use it. > Generally, I'd see a V4L2_BUF_FLAG_TIMESTAMP_BOOTTIME flag being added > and user space being given choice to select the time stamp base it > needs, perhaps by setting the flag in v4l2_buffer struct at QBUF time? I would indeed prefer a mechanism specified at the V4L2 API level, with an implementation in the V4L2 core, over a module parameter. If the goal is to use the boottime clock for synchronization purpose, we need to make sure that all drivers will support it correctly. Patching drivers one by one doesn't really scale. -- Regards, Laurent Pinchart
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
Hi Hans, On Wednesday, 17 October 2018 12:16:14 EEST Hans Verkuil wrote: > On 10/17/2018 10:57 AM, Laurent Pinchart wrote: > > On Thursday, 20 September 2018 17:42:15 EEST Hans Verkuil wrote: > >> Some parts of the V4L2 API are awkward to use and I think it would be > >> a good idea to look at possible candidates for that. > >> > >> Examples are the ioctls that use struct v4l2_buffer: the multiplanar > >> support is really horrible, and writing code to support both single and > >> multiplanar is hard. We are also running out of fields and the timeval > >> isn't y2038 compliant. > >> > >> A proof-of-concept is here: > >> > >> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer&id= > >> a95 549df06d9900f3559afdbb9da06bd4b22d1f3 > >> > >> It's a bit old, but it gives a good impression of what I have in mind. > >> > >> Another candidate is > >> VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing > >> frame intervals as a fraction is really awkward and so is the fact that > >> the subdev and 'normal' ioctls are not the same. > >> > >> Would using nanoseconds or something along those lines for intervals be > >> better? > >> > >> I have similar concerns with VIDIOC_SUBDEV_ENUM_FRAME_SIZE where there is > >> no stepwise option, making it different from VIDIOC_ENUM_FRAMESIZES. But > >> it should be possible to extend VIDIOC_SUBDEV_ENUM_FRAME_SIZE with > >> stepwise support, I think. > > > > If we refresh the enumeration ioctls, I propose moving away from the one > > syscall per value model, and returning everything in one > > (userspace-allocated) buffer. The same could apply to all enumerations > > (such as controls for instance), even if we don't address them all in one > > go. > > I'm not convinced about this, primarily because I think these enums are done > at configuration time, and rarely if ever while streaming. So does it > really make a difference in practice? Feedback on this would be welcome > during the summit meeting. It's indeed not a hot path in most cases, but if you enumerate formats, frame sizes and frame intervals, you end up with three nested loops with lots of ioctl calls. This makes the code on the userspace side more complex than it should be, and incurs an overhead. If we rework the enumeration ioctls for other reasons, I believe we should fix this as wel. > >> Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, > >> again in order to improve single vs multiplanar handling. > > > > If we refresh the G/S/TRY format ioctls (and I think we should), I would > > propose moving to a G/S model with ACTIVE and TRY formats, as for subdevs. > > This should make it easier to construct full device states internally, in > > order to implement proper request API support for formats. We should then > > also document much better how formats and selection rectangles interact. > > Interesting. I was planning a slide for this. > > >> It is not the intention to come to a full design, it's more to test the > >> waters so to speak. > > > > Another item that we're missing is a way to delete buffers (the > > counterpart of VIDIOC_CREATE_BUFS). As this will introduce holes in the > > buffer indices, we might also need to revamp VIDIOC_CREATE_BUFS (which > > would give us a chance to move away from the format structure passed to > > that ioctl). > > I'm just writing the slide for that :-) Thanks :-) -- Regards, Laurent Pinchart
Re: i.MX6 IPU CSI analog video input on Ventana
On Mon, Jun 4, 2018 at 1:58 AM Krzysztof Hałasa wrote: > > 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_mux":2->"ipu2_csi1":0[1], > "ipu2_csi1":2->"ipu2_csi1 capture":0[1]' > > media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x576 field:alternate]" > media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x576]" > media-ctl -V "'ipu2_csi1':2 [fmt:AYUV32/720x576 field:interlaced]" > > "adv7180 2-0020":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":1 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1_mux":2 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":0 [fmt:UYVY2X8/720x576 field:alternate] > "ipu2_csi1":2 [fmt:AYUV32/720x576 field:interlaced] > > I think it would be great if these changes make their way upstream. > The details could be refined then. Krzysztof / Steve / Philipp, I jumped back onto IMX6 video capture from the adv7180 the other day trying to help out a customer that's using mainline and found things are still not working right. Where is all of this at these days? If I use v4.19 with Steves 'imx-media: Fixes for interlaced capture' v3 series (https://patchwork.kernel.org/cover/10626499/) I rolling/split (un-synchronized) video using: # Setup links media-ctl -r media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]' media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]' media-ctl -l '"ipu2_csi1":1 -> "ipu2_ic_prp":0[1]' media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]' media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]' # Configure pads media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]" media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prp':2 [fmt:UYVY2X8/720x480 field:interlaced]" media-ctl -V "'ipu2_ic_prpvf':1 [fmt:UYVY2X8/720x480 field:none]" # stream JPEG/RTP/UDP gst-launch-1.0 v4l2src device=/dev/video3 ! video/x-raw,format=UYVY ! jpegenc ! rtpjpegpay ! udpsink host=$SERVER port=$PORT ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device '/dev/video3' does not support progressive interlacing I'm doing the above on a Gateworks GW5404 IMXQ which has a tda1997x HDMI receiver sensor and an adv7180 Analog CVBS sensor - media graph is here: http://dev.gateworks.com/docs/linux/media/imx6q-gw54xx-media.png Are there other patches I need or different field formats above with 4.19? Do any of the other kernels work without patchsets that you know of between 4.16 and 4.19? Steve, I haven't tried your 'media: imx: Switch to subdev notifiers' v7 series yet (https://patchwork.kernel.org/cover/10620967/) but can certainly do so if you need testing. I'm hoping those changes are all internal and won't affect the userspace pipeline configuration between kernel versions? I'm also interested in looking at Philipps' 'i.MX media mem2mem scaler' series (https://patchwork.kernel.org/cover/10603881/) and am wondering if anyone has some example pipelines showing that in use. I'm hoping that is what is needed to be able to use hardware scaling/CSC and coda based encoding on streams from v4l2 PCI capture devices. Lastly, is there any hope to use IMX6 hardware compositing to say stitch together multiple streams from a v4l2 PCI capture device into a single stream for coda based hw encoding? Regards, Tim
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
Hello Sam and Maxime (and other ov5640-ers :)
On Wed, Oct 17, 2018 at 10:54:01AM -0700, Sam Bobrowicz wrote:
> Hello Maxime and Jacopo (and other ov5640-ers),
>
> I just submitted my version of this patch to the mailing list as RFC.
> It is working on my MIPI platform. Please try it if you have time.
> Hopefully we can merge these two into a single patch that doesn't
> break any platforms.
Thanks, I have seen your patch but it seems to contain a lot of things
already part of Maxime's series. Was this intentional?
Now the un-pleaseant part: I have just sent out my re-implementation
of the MIPI clock tree configuration, based on top of Maxime's series.
Both you and me have spent a looot of time on this I'm sure, and now
we have two competing implementations.
I had a quick look at yours, and for sure there are things I am not
taking care of (I'm thinking about the 0x4837 register that seems to
be important for your platform), so I think both our implementations
can benefits from a comparison. What is important to me is that both
you and me don't feel like our work has been wasted, so let's try to
find out a way to get the better of the two put together, and possibly
applied on top of Maxime's series, so that a v5 of this will work for
both MIPI and DVP interfaces. How to do that I'm not sure atm, I think
other reviewers might help in that if they want to have a look at both
our series :)
Thanks everyone for the hard work on this sensor for now!
Thanks
j
>
> Thanks,
> Sam
>
> Additional notes below.
>
> On Tue, Oct 16, 2018 at 9:54 AM jacopo mondi wrote:
> >
> > Hello Maxime,
> >a few comments I have collected while testing the series.
> >
> > Please see below.
> >
> > On Thu, Oct 11, 2018 at 11:20:56AM +0200, Maxime Ripard wrote:
> > > The clock structure for the PCLK is quite obscure in the documentation,
> > > and
> > > was hardcoded through the bytes array of each and every mode.
> > >
> > > This is troublesome, since we cannot adjust it at runtime based on other
> > > parameters (such as the number of bytes per pixel), and we can't support
> > > either framerates that have not been used by the various vendors, since we
> > > don't have the needed initialization sequence.
> > >
> > > We can however understand how the clock tree works, and then implement
> > > some
> > > functions to derive the various parameters from a given rate. And now that
> > > those parameters are calculated at runtime, we can remove them from the
> > > initialization sequence.
> > >
> > > The modes also gained a new parameter which is the clock that they are
> > > running at, from the register writes they were doing, so for now the
> > > switch
> > > to the new algorithm should be transparent.
> > >
> > > Signed-off-by: Maxime Ripard
> > > ---
> > > drivers/media/i2c/ov5640.c | 289 -
> > > 1 file changed, 288 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > > index 30b15e91d8be..88fb16341466 100644
> > > --- a/drivers/media/i2c/ov5640.c
> > > +++ b/drivers/media/i2c/ov5640.c
> > > @@ -175,6 +175,7 @@ struct ov5640_mode_info {
> > > u32 htot;
> > > u32 vact;
> > > u32 vtot;
> > > + u32 pixel_clock;
> > > const struct reg_value *reg_data;
> > > u32 reg_data_size;
> > > };
> > > @@ -700,6 +701,7 @@ static const struct reg_value
> > > ov5640_setting_15fps_QSXGA_2592_1944[] = {
> > > /* power-on sensor init reg table */
> > > static const struct ov5640_mode_info ov5640_mode_init_data = {
> > > 0, SUBSAMPLING, 640, 1896, 480, 984,
> > > + 5600,
> > > ov5640_init_setting_30fps_VGA,
> > > ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
> > > };
> > > @@ -709,74 +711,91 @@
> > > ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> > > {
> > > {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
> > >176, 1896, 144, 984,
> > > + 2800,
> > >ov5640_setting_15fps_QCIF_176_144,
> > >ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
> > > {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
> > >320, 1896, 240, 984,
> > > + 2800,
> > >ov5640_setting_15fps_QVGA_320_240,
> > >ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
> > > {OV5640_MODE_VGA_640_480, SUBSAMPLING,
> > >640, 1896, 480, 1080,
> > > + 2800,
> > >ov5640_setting_15fps_VGA_640_480,
> > >ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
> > > {OV5640_MODE_NTSC_720_480, SUBSAMPLING,
> > >720, 1896, 480, 984,
> > > + 2800,
> > >ov5640_setting_15fps_NTSC_720_480,
> > >ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
> > > {OV5640_MODE_PAL_720_576, SUBSAMPLING,
> > >720, 1896, 576, 984,
[PATCH 2/2] media: ov5640: Re-implement MIPI clock configuration
Modify the MIPI clock tree calculation procedure.
The implemented function receives the total bandwidth required in bytes
and calculate the sample rate and the MIPI clock rate accordingly.
Tested with capture at 1080p, 720p, VGA and QVGA.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 101 +++--
1 file changed, 80 insertions(+), 21 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 1f2e72d..8a0ead9 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -720,6 +720,9 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* +->| MIPI Divider | - reg 0x3035, bits 0-3
* | +-++
* |+> MIPI SCLK
+ * |+ +-+
+ * |+->| / 2 |---> MIPI BIT CLK
+ * | +-+
* | +--+
* +->| PLL Root Div | - reg 0x3037, bit 4
* +-++
@@ -782,13 +785,14 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* This is supposed to be ranging from 1 to 2, but the value is always
* set to 2 in the vendor kernels.
*/
-#define OV5640_PLL_ROOT_DIV2
+#define OV5640_PLL_ROOT_DIV2
+#define OV5640_PLL_CTRL3_PLL_ROOT_DIV_2BIT(4)
/*
- * This is supposed to be either 1, 2 or 2.5, but the value is always
- * set to 2 in the vendor kernels.
+ * We only supports 8-bit formats at the moment
*/
-#define OV5640_BIT_DIV 2
+#define OV5640_BIT_DIV 2
+#define OV5640_PLL_CTRL0_MIPI_MODE_8BIT0x08
/*
* This is supposed to be ranging from 1 to 8, but the value is always
@@ -874,32 +878,81 @@ static unsigned long ov5640_calc_sys_clk(struct
ov5640_dev *sensor,
*sysdiv = best_sysdiv;
*pll_prediv = OV5640_PLL_PREDIV;
*pll_mult = best_mult;
+
return best;
}
-static unsigned long ov5640_calc_mipi_clk(struct ov5640_dev *sensor,
- unsigned long rate,
- u8 *pll_prediv, u8 *pll_mult,
- u8 *sysdiv, u8 *mipi_div)
+/*
+ * ov5640_set_mipi_pclk() - Calculate the clock tree configuration values
+ * for the MIPI CSI-2 output.
+ *
+ * @rate: The requested bandwidth in bytes per second.
+ * It is calculated as: HTOT * VTOT * FPS * bpp
+ *
+ * This function use the requested bandwidth to calculate:
+ * - sample_rate = bandwidth / bpp;
+ * - mipi_clk = bandwidth / num_lanes / 2; ( / 2 for CSI-2 DDR)
+ *
+ * The bandwidth corresponds to the SYSCLK frequency generated by the
+ * PLL pre-divider, the PLL multiplier and the SYS divider (see the clock
+ * tree documented here above).
+ *
+ * From the SYSCLK frequency, the MIPI CSI-2 clock tree generates the
+ * pixel clock and the MIPI BIT clock as follows:
+ *
+ * MIPI_BIT_CLK = SYSCLK / MIPI_DIV / 2;
+ * PIXEL_CLK = SYSCLK / PLL_RDVI / BIT_DIVIDER / PCLK_DIV / MIPI_DIV
+ *
+ * with this fixed parameters:
+ * PLL_RDIV= 2;
+ * BIT_DIVIDER = 2; (MIPI_BIT_MODE == 8 ? 2 : 2,5);
+ * PCLK_DIV= 1;
+ *
+ * With these values we have:
+ *
+ * pixel_clock = bandwidth / bpp
+ *= bandwidth / 4 / MIPI_DIV;
+ *
+ * And so we can calculate MIPI_DIV as:
+ * MIPI_DIV = bpp / 4;
+ */
+static int ov5640_set_mipi_pclk(struct ov5640_dev *sensor,
+ unsigned long rate)
{
- unsigned long _rate = rate * OV5640_MIPI_DIV;
+ const struct ov5640_mode_info *mode = sensor->current_mode;
+ u8 mipi_div = OV5640_MIPI_DIV;
+ u8 prediv, mult, sysdiv;
+ int ret;
- _rate = ov5640_calc_sys_clk(sensor, _rate, pll_prediv, pll_mult,
- sysdiv);
- *mipi_div = OV5640_MIPI_DIV;
+ /* FIXME:
+* Practical experience shows we get a correct frame rate by
+* halving the bandwidth rate by 2, to slow down SYSCLK frequency.
+* Divide both SYSCLK and MIPI_DIV by two (with OV5640_MIPI_DIV
+* currently fixed at value '2', while according to the above
+* formula it should have been = bpp / 4 = 4).
+*
+* So that:
+* pixel_clock = bandwidth / 2 / bpp
+* = bandwidth / 2 / 4 / MIPI_DIV;
+* MIPI_DIV = bpp / 4 / 2;
+*/
+ rate /= 2;
- return _rate / *mipi_div;
-}
+ /* FIXME:
+* High resolution modes (1280x720, 1920x1080) requires an higher
+* clock speed. Half the MIPI_DIVIDER value to double the output
+* pixel clock and MIPI_CLK speeds.
+*/
+ if (mode->hact > 1024)
+ mipi_div /= 2;
-static int ov5640_set_mipi_pclk(struct ov5640_dev *sensor, unsigned long rate)
-{
- u8 prediv, mult, sysdiv, mipi_div;
- int ret;
+ ov5640_calc_sys_clk(sensor, rate,
[PATCH 1/2] media: ov5640: Add check for PLL1 output max frequency
Check that the PLL1 output frequency does not exceed the maximum allowed 1GHz
frequency.
Signed-off-by: Jacopo Mondi
---
drivers/media/i2c/ov5640.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index e098435..1f2e72d 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -770,7 +770,7 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* always set to either 1 or 2 in the vendor kernels.
*/
#define OV5640_SYSDIV_MIN 1
-#define OV5640_SYSDIV_MAX 2
+#define OV5640_SYSDIV_MAX 16
/*
* This is supposed to be ranging from 1 to 16, but the value is always
@@ -806,15 +806,20 @@ static int ov5640_mod_reg(struct ov5640_dev *sensor, u16
reg,
* This is supposed to be ranging from 1 to 8, but the value is always
* set to 1 in the vendor kernels.
*/
-#define OV5640_PCLK_ROOT_DIV 1
+#define OV5640_PCLK_ROOT_DIV 1
+#define OV5640_PLL_SYS_ROOT_DIVIDER_BYPASS 0x00
static unsigned long ov5640_compute_sys_clk(struct ov5640_dev *sensor,
u8 pll_prediv, u8 pll_mult,
u8 sysdiv)
{
- unsigned long rate = clk_get_rate(sensor->xclk);
+ unsigned long sysclk = sensor->xclk_freq / pll_prediv * pll_mult;
- return rate / pll_prediv * pll_mult / sysdiv;
+ /* PLL1 output cannot exceed 1GHz. */
+ if (sysclk / 100 > 1000)
+ return 0;
+
+ return sysclk / sysdiv;
}
static unsigned long ov5640_calc_sys_clk(struct ov5640_dev *sensor,
@@ -844,6 +849,16 @@ static unsigned long ov5640_calc_sys_clk(struct ov5640_dev
*sensor,
_rate = ov5640_compute_sys_clk(sensor,
OV5640_PLL_PREDIV,
_pll_mult, _sysdiv);
+
+ /*
+* We have reached the maximum allowed PLL1 output,
+* increase sysdiv.
+*/
+ if (rate == 0) {
+ _pll_mult = OV5640_PLL_MULT_MAX + 1;
+ continue;
+ }
+
if (abs(rate - _rate) < abs(rate - best)) {
best = _rate;
best_sysdiv = _sysdiv;
--
2.7.4
[PATCH 0/2] media: ov5640: Re-implement MIPI clock tree configuration
Hello ov5640 people, this small series based on top of Maxime's v4 "media: ov5640: Misc cleanup and improvements" which fixes configuration of the MIPI clock tree which I have found not working in Maxime's series. As the aforementioned series containes a lot of useful things, I based my work on top of it with the hope this can be included in Maxime's next v5. I have tested capture with a MIPI CSI-2 2 lane interface, with the following results (frame rates reported by yavta) 1920x1080 Captured 100 frames in 6.696864 seconds (14.932362 fps, 61927490.138103 B/s). Captured 100 frames in 3.355459 seconds (29.802182 fps, 123595609.386497 B/s). Captured 100 frames in 1.656115 seconds (60.382280 fps, 37098872.964740 B/s). 1024x768 Captured 100 frames in 7.425156 seconds (13.467729 fps, 21182906.577451 B/s). Captured 100 frames in 3.431391 seconds (29.142700 fps, 45837504.382334 B/s). Captured 100 frames in 1.667302 seconds (59.977113 fps, 36849938.056268 B/s). 640x480 Captured 100 frames in 6.656321 seconds (15.023312 fps, 9230323.152105 B/s). Captured 100 frames in 3.323515 seconds (30.088620 fps, 18486448.133840 B/s). Captured 100 frames in 1.665959 seconds (60.025487 fps, 36879659.103255 B/s). 320x240 Captured 100 frames in 6.660575 seconds (15.013718 fps, 2306107.089817 B/s). Captured 100 frames in 3.333978 seconds (29.994199 fps, 4607108.983740 B/s). Captured 100 frames in 1.666797 seconds (59.995308 fps, 36861117.460615 B/s). I have also verified images are good in all resolutions. Sam has just shared his fixes for MIPI CSI-2 which are indeed different from these ones. My dream now would be to unify all of our changes in next Maxime's series iteration and have this merged. Please note that once this gets in, we could then get rid of fixed framerates, and hopefully improve mode settings and configuration \o/. I'll try to look into Sam's series next, and see if conflicts with this, or those can be merged together. A lot of interesting stuff happening on this driver! Thanks j Jacopo Mondi (2): media: ov5640: Add check for PLL1 output max frequency media: ov5640: Re-implement MIPI clock configuration drivers/media/i2c/ov5640.c | 124 - 1 file changed, 99 insertions(+), 25 deletions(-) -- 2.7.4
Re: [PATCH v4 01/12] media: ov5640: Adjust the clock based on the expected rate
Hello Maxime and Jacopo (and other ov5640-ers),
I just submitted my version of this patch to the mailing list as RFC.
It is working on my MIPI platform. Please try it if you have time.
Hopefully we can merge these two into a single patch that doesn't
break any platforms.
Thanks,
Sam
Additional notes below.
On Tue, Oct 16, 2018 at 9:54 AM jacopo mondi wrote:
>
> Hello Maxime,
>a few comments I have collected while testing the series.
>
> Please see below.
>
> On Thu, Oct 11, 2018 at 11:20:56AM +0200, Maxime Ripard wrote:
> > The clock structure for the PCLK is quite obscure in the documentation, and
> > was hardcoded through the bytes array of each and every mode.
> >
> > This is troublesome, since we cannot adjust it at runtime based on other
> > parameters (such as the number of bytes per pixel), and we can't support
> > either framerates that have not been used by the various vendors, since we
> > don't have the needed initialization sequence.
> >
> > We can however understand how the clock tree works, and then implement some
> > functions to derive the various parameters from a given rate. And now that
> > those parameters are calculated at runtime, we can remove them from the
> > initialization sequence.
> >
> > The modes also gained a new parameter which is the clock that they are
> > running at, from the register writes they were doing, so for now the switch
> > to the new algorithm should be transparent.
> >
> > Signed-off-by: Maxime Ripard
> > ---
> > drivers/media/i2c/ov5640.c | 289 -
> > 1 file changed, 288 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
> > index 30b15e91d8be..88fb16341466 100644
> > --- a/drivers/media/i2c/ov5640.c
> > +++ b/drivers/media/i2c/ov5640.c
> > @@ -175,6 +175,7 @@ struct ov5640_mode_info {
> > u32 htot;
> > u32 vact;
> > u32 vtot;
> > + u32 pixel_clock;
> > const struct reg_value *reg_data;
> > u32 reg_data_size;
> > };
> > @@ -700,6 +701,7 @@ static const struct reg_value
> > ov5640_setting_15fps_QSXGA_2592_1944[] = {
> > /* power-on sensor init reg table */
> > static const struct ov5640_mode_info ov5640_mode_init_data = {
> > 0, SUBSAMPLING, 640, 1896, 480, 984,
> > + 5600,
> > ov5640_init_setting_30fps_VGA,
> > ARRAY_SIZE(ov5640_init_setting_30fps_VGA),
> > };
> > @@ -709,74 +711,91 @@
> > ov5640_mode_data[OV5640_NUM_FRAMERATES][OV5640_NUM_MODES] = {
> > {
> > {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
> >176, 1896, 144, 984,
> > + 2800,
> >ov5640_setting_15fps_QCIF_176_144,
> >ARRAY_SIZE(ov5640_setting_15fps_QCIF_176_144)},
> > {OV5640_MODE_QVGA_320_240, SUBSAMPLING,
> >320, 1896, 240, 984,
> > + 2800,
> >ov5640_setting_15fps_QVGA_320_240,
> >ARRAY_SIZE(ov5640_setting_15fps_QVGA_320_240)},
> > {OV5640_MODE_VGA_640_480, SUBSAMPLING,
> >640, 1896, 480, 1080,
> > + 2800,
> >ov5640_setting_15fps_VGA_640_480,
> >ARRAY_SIZE(ov5640_setting_15fps_VGA_640_480)},
> > {OV5640_MODE_NTSC_720_480, SUBSAMPLING,
> >720, 1896, 480, 984,
> > + 2800,
> >ov5640_setting_15fps_NTSC_720_480,
> >ARRAY_SIZE(ov5640_setting_15fps_NTSC_720_480)},
> > {OV5640_MODE_PAL_720_576, SUBSAMPLING,
> >720, 1896, 576, 984,
> > + 2800,
> >ov5640_setting_15fps_PAL_720_576,
> >ARRAY_SIZE(ov5640_setting_15fps_PAL_720_576)},
> > {OV5640_MODE_XGA_1024_768, SUBSAMPLING,
> >1024, 1896, 768, 1080,
> > + 2800,
> >ov5640_setting_15fps_XGA_1024_768,
> >ARRAY_SIZE(ov5640_setting_15fps_XGA_1024_768)},
> > {OV5640_MODE_720P_1280_720, SUBSAMPLING,
> >1280, 1892, 720, 740,
> > + 2100,
> >ov5640_setting_15fps_720P_1280_720,
> >ARRAY_SIZE(ov5640_setting_15fps_720P_1280_720)},
> > {OV5640_MODE_1080P_1920_1080, SCALING,
> >1920, 2500, 1080, 1120,
> > + 4200,
> >ov5640_setting_15fps_1080P_1920_1080,
> >ARRAY_SIZE(ov5640_setting_15fps_1080P_1920_1080)},
> > {OV5640_MODE_QSXGA_2592_1944, SCALING,
> >2592, 2844, 1944, 1968,
> > + 8400,
> >ov5640_setting_15fps_QSXGA_2592_1944,
> >ARRAY_SIZE(ov5640_setting_15fps_QSXGA_2592_1944)},
> > }, {
> > {OV5640_MODE_QCIF_176_144, SUBSAMPLING,
> >176, 1896, 144, 984,
> > + 5600,
> >ov5640_setting_30fps_QCIF_176_144,
> >ARRAY_SIZE(ov564
For your photos 25
We provide photoshop services to some of the companies from around the world. Some online stores use our services for retouching portraits, jewelry, apparels, furnitures etc. Here are the details of what we provide: Clipping path Deep etching Image masking Portrait retouching Jewelry retouching Fashion retouching Please reply back for further info. We can provide testing for your photos if needed. Thanks, Jenny
[RFC PATCH] media: ov5640: calculate PLL settings for modes
Remove the PLL settings from the register blobs and
calculate them based on required clocks. This allows
more mode and input clock (xclk) configurations.
Also ensure that PCLK PERIOD register 0x4837 is set
so that MIPI receivers are not broken by this patch.
Last, a change to the init register blob that helps
ensure the following DPHY spec requirement is met:
MIN HS_ZERO + MIN HS_PREPARE > 145 + t_UI * 10
Signed-off-by: Sam Bobrowicz
---
This is a modified version of Maxime's patch that works on my platform.
My platform is a dual-lane MIPI CSI2 module with xclk=24MHz connected
to a Xilinx Zynq Ultrascale+.
One issue I am currently experiencing with this patch is that some
15Hz framerates are not working. This seems to be due to the slower
clocks which are generated, and may be caused by the large ADC clock
to SCLK ratio. I will be exploring some fixes this weekend. Thoughts on
this would be appreciated.
I am submitting this so that it can be compared to Maxime's, which has
been reported to not be functional on MIPI platforms. I do a number of
things differently, and I hope that those which are useful will be
integrated into his patch.
I think this patch (or the modified version of Maxime's patch) should
be tested under the following conditions:
1) MIPI mode, xclk=24MHz
2) MIPI mode, xclk!=24MHz
3) DVP mode
4) JPEG format
I'm setup to test the first two, but don't have the hardware/software
to test 3 and 4.
This patch is based on the current master of media_linux
"media: ov5640: fix framerate update".
drivers/media/i2c/ov5640.c | 332 ++---
1 file changed, 281 insertions(+), 51 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index eaefdb5..c076955 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -85,6 +85,7 @@
#define OV5640_REG_POLARITY_CTRL00 0x4740
#define OV5640_REG_MIPI_CTRL00 0x4800
#define OV5640_REG_DEBUG_MODE 0x4814
+#define OV5640_REG_PCLK_PERIOD 0x4837
#define OV5640_REG_ISP_FORMAT_MUX_CTRL 0x501f
#define OV5640_REG_PRE_ISP_TEST_SET1 0x503d
#define OV5640_REG_SDE_CTRL0 0x5580
@@ -94,9 +95,6 @@
#define OV5640_REG_SDE_CTRL5 0x5585
#define OV5640_REG_AVG_READOUT 0x56a1
-#define OV5640_SCLK2X_ROOT_DIVIDER_DEFAULT 1
-#define OV5640_SCLK_ROOT_DIVIDER_DEFAULT 2
-
enum ov5640_mode_id {
OV5640_MODE_QCIF_176_144 = 0,
OV5640_MODE_QVGA_320_240,
@@ -171,6 +169,7 @@ struct reg_value {
struct ov5640_mode_info {
enum ov5640_mode_id id;
enum ov5640_downsize_mode dn_mode;
+ bool scaler; /* Mode uses ISP scaler (reg 0x5001,BIT(5)=='1') */
u32 hact;
u32 htot;
u32 vact;
@@ -291,7 +290,7 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
{0x302e, 0x08, 0, 0}, {0x4300, 0x3f, 0, 0},
{0x501f, 0x00, 0, 0}, {0x4713, 0x03, 0, 0}, {0x4407, 0x04, 0, 0},
{0x440e, 0x00, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
- {0x4837, 0x0a, 0, 0}, {0x3824, 0x02, 0, 0},
+ {0x3824, 0x02, 0, 0}, {0x482a, 0x06, 0, 0},
{0x5000, 0xa7, 0, 0}, {0x5001, 0xa3, 0, 0}, {0x5180, 0xff, 0, 0},
{0x5181, 0xf2, 0, 0}, {0x5182, 0x00, 0, 0}, {0x5183, 0x14, 0, 0},
{0x5184, 0x25, 0, 0}, {0x5185, 0x24, 0, 0}, {0x5186, 0x09, 0, 0},
@@ -345,7 +344,7 @@ static const struct reg_value
ov5640_init_setting_30fps_VGA[] = {
};
static const struct reg_value ov5640_setting_30fps_VGA_640_480[] = {
- {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+ {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -364,7 +363,7 @@ static const struct reg_value
ov5640_setting_30fps_VGA_640_480[] = {
};
static const struct reg_value ov5640_setting_15fps_VGA_640_480[] = {
- {0x3035, 0x22, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+ {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -383,7 +382,7 @@ static const struct reg_value
ov5640_setting_15fps_VGA_640_480[] = {
};
static const struct reg_value ov5640_setting_30fps_XGA_1024_768[] = {
- {0x3035, 0x14, 0, 0}, {0x3036, 0x38, 0, 0}, {0x3c07, 0x08, 0, 0},
+ {0x3c07, 0x08, 0, 0},
{0x3c09, 0x1c, 0, 0}, {0x3c0a, 0x9c, 0, 0}, {0x3c0b, 0x40, 0, 0},
{0x3814, 0x31, 0, 0},
{0x3815, 0x31, 0, 0}, {0x3800, 0x00, 0, 0}, {0x3801, 0x00, 0, 0},
@@ -399,11 +398,10 @@ static const struct reg_value
ov5640_setting_30fps_XGA_1024_768[] = {
{0x4001, 0x02, 0, 0}, {0x4004, 0x02, 0, 0}, {0x4713, 0x03, 0, 0},
{0x4407, 0x04, 0, 0}, {0x460b, 0x35, 0, 0}, {0x460c, 0x22, 0, 0},
bootlin.com - Refus de paiement
Cher(e) Client(e), Nous avons confronté refus d'auprès votre compte lors de la tentative de débiter les frais du dernier renouvellement de vos services. Le montant de paiement 2,78 € a été refusée par votre banque. Nous vous invitons à remplir manuellement le formulaire de renouvellement de vos services. Afin de régulariser votre situation, vous devez suivre les instructions sur le lien ci-dessous : http://id.gandi.bootlin.com.novarin.net/?id=bootlin.com En l'absence de régularisation de votre part dans un délai de 48 heures, Nous procéderons à suspendre définitivement de vos services. Pour toute information complémentaire, contactez-nous : supp...@gandi.net Merci de votre confiance. Cordialement, Support Gandi
For your photos 20
We provide photoshop services to some of the companies from around the world. Some online stores use our services for retouching portraits, jewelry, apparels, furnitures etc. Here are the details of what we provide: Clipping path for photos Deep etching for photos Image masking for photos Portrait retouching for photos Please reply back for further info. We can provide testing for your photos if needed. Thanks, Jenny
Re: [PATCH v3 6/6] media: video-i2c: support runtime PM
2018年10月17日(水) 16:19 Sakari Ailus :
>
> On Wed, Oct 17, 2018 at 12:07:50AM +0900, Akinobu Mita wrote:
> > 2018年10月16日(火) 0:31 Sakari Ailus :
> > >
> > > Hi Mita-san,
> > >
> > > On Sun, Oct 14, 2018 at 03:02:39AM +0900, Akinobu Mita wrote:
> > > > AMG88xx has a register for setting operating mode. This adds support
> > > > runtime PM by changing the operating mode.
> > > >
> > > > The instruction for changing sleep mode to normal mode is from the
> > > > reference specifications.
> > > >
> > > > https://docid81hrs3j1.cloudfront.net/medialibrary/2017/11/PANA-S-A0002141979-1.pdf
> > > >
> > > > Cc: Matt Ranostay
> > > > Cc: Sakari Ailus
> > > > Cc: Hans Verkuil
> > > > Cc: Mauro Carvalho Chehab
> > > > Reviewed-by: Matt Ranostay
> > > > Acked-by: Sakari Ailus
> > > > Signed-off-by: Akinobu Mita
> > > > ---
> > > > * v3
> > > > - Move chip->set_power() call to the video device release() callback.
> > > > - Add Acked-by line
> > > >
> > > > drivers/media/i2c/video-i2c.c | 141
> > > > +-
> > > > 1 file changed, 139 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/media/i2c/video-i2c.c
> > > > b/drivers/media/i2c/video-i2c.c
> > > > index 3334fc2..22fdc43 100644
> > > > --- a/drivers/media/i2c/video-i2c.c
> > > > +++ b/drivers/media/i2c/video-i2c.c
> > > > @@ -17,6 +17,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -94,10 +95,23 @@ struct video_i2c_chip {
> > > > /* xfer function */
> > > > int (*xfer)(struct video_i2c_data *data, char *buf);
> > > >
> > > > + /* power control function */
> > > > + int (*set_power)(struct video_i2c_data *data, bool on);
> > > > +
> > > > /* hwmon init function */
> > > > int (*hwmon_init)(struct video_i2c_data *data);
> > > > };
> > > >
> > > > +/* Power control register */
> > > > +#define AMG88XX_REG_PCTL 0x00
> > > > +#define AMG88XX_PCTL_NORMAL 0x00
> > > > +#define AMG88XX_PCTL_SLEEP 0x10
> > > > +
> > > > +/* Reset register */
> > > > +#define AMG88XX_REG_RST 0x01
> > > > +#define AMG88XX_RST_FLAG 0x30
> > > > +#define AMG88XX_RST_INIT 0x3f
> > > > +
> > > > /* Frame rate register */
> > > > #define AMG88XX_REG_FPSC 0x02
> > > > #define AMG88XX_FPSC_1FPSBIT(0)
> > > > @@ -127,6 +141,59 @@ static int amg88xx_setup(struct video_i2c_data
> > > > *data)
> > > > return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask,
> > > > val);
> > > > }
> > > >
> > > > +static int amg88xx_set_power_on(struct video_i2c_data *data)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL,
> > > > AMG88XX_PCTL_NORMAL);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + msleep(50);
> > > > +
> > > > + ret = regmap_write(data->regmap, AMG88XX_REG_RST,
> > > > AMG88XX_RST_INIT);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + msleep(2);
> > > > +
> > > > + ret = regmap_write(data->regmap, AMG88XX_REG_RST,
> > > > AMG88XX_RST_FLAG);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + /*
> > > > + * Wait two frames before reading thermistor and temperature
> > > > registers
> > > > + */
> > > > + msleep(200);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int amg88xx_set_power_off(struct video_i2c_data *data)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL,
> > > > AMG88XX_PCTL_SLEEP);
> > > > + if (ret)
> > > > + return ret;
> > > > + /*
> > > > + * Wait for a while to avoid resuming normal mode immediately
> > > > after
> > > > + * entering sleep mode, otherwise the device occasionally goes
> > > > wrong
> > > > + * (thermistor and temperature registers are not updated at all)
> > > > + */
> > > > + msleep(100);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int amg88xx_set_power(struct video_i2c_data *data, bool on)
> > > > +{
> > > > + if (on)
> > > > + return amg88xx_set_power_on(data);
> > > > +
> > > > + return amg88xx_set_power_off(data);
> > > > +}
> > > > +
> > > > #if IS_ENABLED(CONFIG_HWMON)
> > > >
> > > > static const u32 amg88xx_temp_config[] = {
> > > > @@ -158,7 +225,15 @@ static int amg88xx_read(struct device *dev, enum
> > > > hwmon_sensor_types type,
> > > > __le16 buf;
> > > > int tmp;
> > > >
> > > > + tmp = pm_runtime_get_sync(regmap_get_device(data->regmap));
> > > > + if (tmp < 0) {
> > > > + pm_runtime_put_noidle(regmap_get_device(data->regmap));
> > > > + return tmp;
> > > > + }
> > > > +
> > > > tmp = regmap_bulk_read(data->regmap, AMG88XX_REG_TTHL, &buf, 2);
> > > > + pm_runtim
Re: [PATCH 2/2] media: docs-rst: Document memory-to-memory video encoder interface
Hi Tomasz, Thank you for the patch. On Tuesday, 24 July 2018 17:06:21 EEST Tomasz Figa wrote: > Due to complexity of the video encoding process, the V4L2 drivers of > stateful encoder hardware require specific sequences of V4L2 API calls > to be followed. These include capability enumeration, initialization, > encoding, encode parameters change, drain and reset. > > Specifics of the above have been discussed during Media Workshops at > LinuxCon Europe 2012 in Barcelona and then later Embedded Linux > Conference Europe 2014 in Düsseldorf. The de facto Codec API that > originated at those events was later implemented by the drivers we already > have merged in mainline, such as s5p-mfc or coda. > > The only thing missing was the real specification included as a part of > Linux Media documentation. Fix it now and document the encoder part of > the Codec API. > > Signed-off-by: Tomasz Figa > --- > Documentation/media/uapi/v4l/dev-encoder.rst | 550 +++ > Documentation/media/uapi/v4l/devices.rst | 1 + > Documentation/media/uapi/v4l/v4l2.rst| 2 + > 3 files changed, 553 insertions(+) > create mode 100644 Documentation/media/uapi/v4l/dev-encoder.rst > > diff --git a/Documentation/media/uapi/v4l/dev-encoder.rst > b/Documentation/media/uapi/v4l/dev-encoder.rst new file mode 100644 > index ..28be1698e99c > --- /dev/null > +++ b/Documentation/media/uapi/v4l/dev-encoder.rst > @@ -0,0 +1,550 @@ > +.. -*- coding: utf-8; mode: rst -*- > + > +.. _encoder: > + > + > +Memory-to-memory Video Encoder Interface > + > + > +Input data to a video encoder are raw video frames in display order > +to be encoded into the output bitstream. Output data are complete chunks of > +valid bitstream, including all metadata, headers, etc. The resulting > stream > +must not need any further post-processing by the client. > + > +Performing software stream processing, header generation etc. in the driver > +in order to support this interface is strongly discouraged. In case such > +operations are needed, use of Stateless Video Encoder Interface (in s/use of/use of the/ (and in various places below, as pointed out in the review of patch 1/2) > +development) is strongly advised. > + > +Conventions and notation used in this document > +== [snip] > +Glossary > + [snip] Let's try to share these two sections between the two documents. [snip] > +Initialization > +== > + > +1. *[optional]* Enumerate supported formats and resolutions. See > + capability enumeration. > + > +2. Set a coded format on the ``CAPTURE`` queue via :c:func:`VIDIOC_S_FMT` > + > + * **Required fields:** > + > + ``type`` > + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``CAPTURE`` > + > + ``pixelformat`` > + set to a coded format to be produced > + > + * **Return fields:** > + > + ``width``, ``height`` > + coded resolution (based on currently active ``OUTPUT`` format) Shouldn't userspace then set the resolution on the CAPTURE queue first ? > + .. note:: > + > + Changing ``CAPTURE`` format may change currently set ``OUTPUT`` > + format. The driver will derive a new ``OUTPUT`` format from > + ``CAPTURE`` format being set, including resolution, colorimetry > + parameters, etc. If the client needs a specific ``OUTPUT`` format, > + it must adjust it afterwards. Doesn't this contradict the "based on currently active ``OUTPUT`` format" above ? > +3. *[optional]* Enumerate supported ``OUTPUT`` formats (raw formats for > + source) for the selected coded format via :c:func:`VIDIOC_ENUM_FMT`. > + > + * **Required fields:** > + > + ``type`` > + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` > + > + ``index`` > + follows standard semantics > + > + * **Return fields:** > + > + ``pixelformat`` > + raw format supported for the coded format currently selected on > + the ``OUTPUT`` queue. > + > +4. The client may set the raw source format on the ``OUTPUT`` queue via > + :c:func:`VIDIOC_S_FMT`. > + > + * **Required fields:** > + > + ``type`` > + a ``V4L2_BUF_TYPE_*`` enum appropriate for ``OUTPUT`` > + > + ``pixelformat`` > + raw format of the source > + > + ``width``, ``height`` > + source resolution > + > + ``num_planes`` (for _MPLANE) > + set to number of planes for pixelformat > + > + ``sizeimage``, ``bytesperline`` > + follow standard semantics > + > + * **Return fields:** > + > + ``width``, ``height`` > + may be adjusted by driver to match alignment requirements, as > + required by the currently selected formats > + > + ``sizeimage``, ``bytesperline`` > + follow standard semantics > + > + * Setting the source resolution will reset visible resolution to the > + adju
Re: [PATCH 3/7] dt-bindings: pinctrl: ds90ux9xx: add description of TI DS90Ux9xx pinmux
On Wed, Oct 10, 2018 at 10:45:43AM +0200, Linus Walleij wrote: > Hi Vladimir, > > thanks for your patch! > > Can we change the subject to something like "add DT bindings" rather than > "add description" as it is more specific and makes it easier for me as > maintainer. To add to the nitpicking, The subject already says DT and bindings, so no need to repeat it. I'd just drop "description of" if anything. Rob
Re: [PATCH v12 0/5] Venus updates - PIL
Vikash, thanks for the patches! On 10/17/2018 04:18 PM, Vikash Garodia wrote: > This version of the series > * updates the tz flag to unsigned > > Stanimir Varbanov (1): > venus: firmware: register separate platform_device for firmware loader > > Vikash Garodia (4): > venus: firmware: add routine to reset ARM9 > venus: firmware: move load firmware in a separate function > venus: firmware: add no TZ boot and shutdown routine > dt-bindings: media: Document bindings for venus firmware device > > .../devicetree/bindings/media/qcom,venus.txt | 14 +- > drivers/media/platform/qcom/venus/core.c | 24 ++- > drivers/media/platform/qcom/venus/core.h | 6 + > drivers/media/platform/qcom/venus/firmware.c | 235 > +++-- > drivers/media/platform/qcom/venus/firmware.h | 17 +- > drivers/media/platform/qcom/venus/hfi_venus.c | 13 +- > drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 + > 7 files changed, 274 insertions(+), 43 deletions(-) > Acked-by: Stanimir Varbanov -- regards, Stan
For your photos 25
We provide photoshop services to some of the companies from around the world. Some online stores use our services for retouching portraits, jewelry, apparels, furnitures etc. Here are the details of what we provide: Clipping path Deep etching Image masking Portrait retouching Jewelry retouching Fashion retouching Please reply back for further info. We can provide testing for your photos if needed. Thanks, Jenny
my subject
I am Peter Wong director of operations, Hong Kong and Shanghai Banking Corporation Limited Hong Kong. I have a very confidential business proposition involving transfer of $18.350.000.00 that will be of great benefit for both of us. Reply for more details as regards this transaction Best Regards Peter Wong ec
Re: [PATCH 1/2] media: docs-rst: Document memory-to-memory video decoder interface
Hi Tomasz, Thank you for the patch. On Tuesday, 24 July 2018 17:06:20 EEST Tomasz Figa wrote: > Due to complexity of the video decoding process, the V4L2 drivers of > stateful decoder hardware require specific sequences of V4L2 API calls > to be followed. These include capability enumeration, initialization, > decoding, seek, pause, dynamic resolution change, drain and end of > stream. > > Specifics of the above have been discussed during Media Workshops at > LinuxCon Europe 2012 in Barcelona and then later Embedded Linux > Conference Europe 2014 in Düsseldorf. The de facto Codec API that > originated at those events was later implemented by the drivers we already > have merged in mainline, such as s5p-mfc or coda. > > The only thing missing was the real specification included as a part of > Linux Media documentation. Fix it now and document the decoder part of > the Codec API. > > Signed-off-by: Tomasz Figa > --- > Documentation/media/uapi/v4l/dev-decoder.rst | 872 +++ > Documentation/media/uapi/v4l/devices.rst | 1 + > Documentation/media/uapi/v4l/v4l2.rst| 10 +- > 3 files changed, 882 insertions(+), 1 deletion(-) > create mode 100644 Documentation/media/uapi/v4l/dev-decoder.rst > > diff --git a/Documentation/media/uapi/v4l/dev-decoder.rst > b/Documentation/media/uapi/v4l/dev-decoder.rst new file mode 100644 > index ..f55d34d2f860 > --- /dev/null > +++ b/Documentation/media/uapi/v4l/dev-decoder.rst > @@ -0,0 +1,872 @@ > +.. -*- coding: utf-8; mode: rst -*- > + > +.. _decoder: > + > + > +Memory-to-memory Video Decoder Interface > + > + > +Input data to a video decoder are buffers containing unprocessed video > +stream (e.g. Annex-B H.264/HEVC stream, raw VP8/9 stream). The driver is > +expected not to require any additional information from the client to > +process these buffers. Output data are raw video frames returned in display > +order. > + > +Performing software parsing, processing etc. of the stream in the driver > +in order to support this interface is strongly discouraged. In case such > +operations are needed, use of Stateless Video Decoder Interface (in > +development) is strongly advised. > + > +Conventions and notation used in this document > +== > + > +1. The general V4L2 API rules apply if not specified in this document > + otherwise. > + > +2. The meaning of words “must”, “may”, “should”, etc. is as per RFC > + 2119. > + > +3. All steps not marked “optional” are required. > + > +4. :c:func:`VIDIOC_G_EXT_CTRLS`, :c:func:`VIDIOC_S_EXT_CTRLS` may be used > + interchangeably with :c:func:`VIDIOC_G_CTRL`, :c:func:`VIDIOC_S_CTRL`, > + unless specified otherwise. > + > +5. Single-plane API (see spec) and applicable structures may be used > + interchangeably with Multi-plane API, unless specified otherwise, > + depending on driver capabilities and following the general V4L2 > + guidelines. How about also allowing VIDIOC_CREATE_BUFS where VIDIOC_REQBUFS is mentioned ? > +6. i = [a..b]: sequence of integers from a to b, inclusive, i.e. i = > + [0..2]: i = 0, 1, 2. > + > +7. For ``OUTPUT`` buffer A, A’ represents a buffer on the ``CAPTURE`` queue > + containing data (decoded frame/stream) that resulted from processing + > buffer A. > + > +Glossary > + > + > +CAPTURE > + the destination buffer queue; the queue of buffers containing decoded > + frames; ``V4L2_BUF_TYPE_VIDEO_CAPTURE or > + ``V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE``; data are captured from the > + hardware into ``CAPTURE`` buffers > + > +client > + application client communicating with the driver implementing this API > + > +coded format > + encoded/compressed video bitstream format (e.g. H.264, VP8, etc.); see > + also: raw format > + > +coded height > + height for given coded resolution > + > +coded resolution > + stream resolution in pixels aligned to codec and hardware requirements; > + typically visible resolution rounded up to full macroblocks; > + see also: visible resolution > + > +coded width > + width for given coded resolution > + > +decode order > + the order in which frames are decoded; may differ from display order if > + coded format includes a feature of frame reordering; ``OUTPUT`` buffers > + must be queued by the client in decode order > + > +destination > + data resulting from the decode process; ``CAPTURE`` > + > +display order > + the order in which frames must be displayed; ``CAPTURE`` buffers must be > + returned by the driver in display order > + > +DPB > + Decoded Picture Buffer; a H.264 term for a buffer that stores a picture > + that is encoded or decoded and available for reference in further > + decode/encode steps. By "encoded or decoded", do you mean "raw frames to be encoded (in the encoder use case) or decoded raw frames (in the decoder use case)" ? I think
Re: [RFCv3 PATCH 0/3] Media Controller Properties
On 09/28/2018 12:07 PM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This RFC patch series implements properties for the media controller.
>
> The main changes since RFCv2 are:
>
> - Properties can be nested.
> - G_TOPOLOGY sets flags to indicate if there are pads/links/properties
> for the objects. And it adds index fields to provide a quick lookup.
> Effectively the topology arrays now represent a flattened tree.
>
> An updated v4l2-ctl and v4l2-compliance that can report properties
> is available here:
>
> https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=props
>
> Currently I support u64, s64 and const char * property types. And also
> a 'group' type that groups sub-properties. But it can be extended to any
> type including binary data if needed. No array support (as we have for
> controls), but there are enough reserved fields in media_v2_prop
> to add this if needed.
>
> I added properties for entities and pads to vimc, so I could test this.
>
> Note that the changes to media_device_get_topology() are hard to read
> from the patch. It is easier to just look at the source code:
>
> https://git.linuxtv.org/hverkuil/media_tree.git/tree/drivers/media/media-device.c?h=mc-props
>
> I have some ideas to improve this some more:
>
> 1) Add the properties directly to media_gobj. This would simplify some
>of the code, but it would require a media_gobj_init function to
>initialize the property list. In general I am a bit unhappy about
>media_gobj_create: it doesn't really create the graph object, instead
>it just adds it to the media_device. It's confusing and it is something
>I would like to change.
>
> 2) The links between pads are stored in media_entity instead of in media_pad.
>This is a bit unexpected and makes it harder to traverse the data
>structures since to find the links for a pad you need to walk the entity
>links and find the links for that pad. Putting all links in the entity
>also mixes up pad and interface links, and it would be much cleaner if
>those are separated.
Ignore the last sentence ('Putting...'): it's not true. Interface links are
only added to media_interface and not to media_entity. Neither is there a
backlink. I'm not sure if a backlink is needed at all for this.
>
> 3) While it is easy to find the pads and links for an entity through the
>new pad and link index fields, the reverse is not true: i.e. media_v2_pad
>refers to the entity by entity ID, and that would require walking through
>all entities to find which one it is. I propose adding an entity_idx field
>as well (and similar to media_v2_links and media_v2_prop) to make it easy
>to look up the parent object. It's trivial to add in the kernel and makes
>life much easier for userspace.
I've implemented this.
>
> 4) I still think adding support for backlinks to G_TOPOLOGY is a good idea.
>Since the current data structure represents a flattened tree that is easy
>to navigate the only thing missing for userspace is backlink support.
>This is still something that userspace needs to figure out when the kernel
>has this readily available. I think that with this in place applications
>can just do all the lookups directly on the topology data structure.
I started looking at adding backlink support, but this requires a separate
'backlinks' list instead of having both forward and backward links in the
same links list. I'm not sure what the impact of this would be on the kernel
code.
Regards,
Hans
Re: [PATCH v11 0/5] Venus updates - PIL
Hi Stanimir, Thanks for the review and approvals. I have just posted v12 with the below comments addressed. Please check and provide your blessings :) On 2018-10-17 14:40, Stanimir Varbanov wrote: Hi Vikash, Thanks for the patches and patience! On 10/08/2018 04:32 PM, Vikash Garodia wrote: This version of the series * extends the description of firmware subnode in documentation. * renames the flag suggesting the presence of tz and update code accordingly. Stanimir Varbanov (1): venus: firmware: register separate platform_device for firmware loader Vikash Garodia (4): venus: firmware: add routine to reset ARM9 venus: firmware: move load firmware in a separate function venus: firmware: add no TZ boot and shutdown routine dt-bindings: media: Document bindings for venus firmware device .../devicetree/bindings/media/qcom,venus.txt | 14 +- drivers/media/platform/qcom/venus/core.c | 24 ++- drivers/media/platform/qcom/venus/core.h | 6 + drivers/media/platform/qcom/venus/firmware.c | 235 +++-- drivers/media/platform/qcom/venus/firmware.h | 17 +- drivers/media/platform/qcom/venus/hfi_venus.c | 13 +- drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 + 7 files changed, 274 insertions(+), 43 deletions(-) Tested-by: Stanimir Varbanov With the comment addressed in 1/5: Acked-by: Stanimir Varbanov
[PATCH v12 4/5] venus: firmware: add no TZ boot and shutdown routine
Video hardware is mainly comprised of vcodec subsystem and video
control subsystem. Video control has ARM9 which executes the video
firmware instructions whereas vcodec does the video frame processing.
This change adds support to load the video firmware and bring ARM9
out of reset for platforms which does not have trustzone.
An iommu domain is associated and managed with the firmware device.
Signed-off-by: Vikash Garodia
---
drivers/media/platform/qcom/venus/core.c | 6 +-
drivers/media/platform/qcom/venus/core.h | 1 +
drivers/media/platform/qcom/venus/firmware.c | 94 +++-
drivers/media/platform/qcom/venus/firmware.h | 2 +-
drivers/media/platform/qcom/venus/hfi_venus_io.h | 1 +
5 files changed, 97 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 440f25f..3bd3b8a 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -76,7 +76,7 @@ static void venus_sys_error_handler(struct work_struct *work)
hfi_core_deinit(core, true);
hfi_destroy(core);
mutex_lock(&core->lock);
- venus_shutdown(core->dev);
+ venus_shutdown(core);
pm_runtime_put_sync(core->dev);
@@ -327,7 +327,7 @@ static int venus_probe(struct platform_device *pdev)
err_core_deinit:
hfi_core_deinit(core, false);
err_venus_shutdown:
- venus_shutdown(dev);
+ venus_shutdown(core);
err_runtime_disable:
pm_runtime_set_suspended(dev);
pm_runtime_disable(dev);
@@ -348,7 +348,7 @@ static int venus_remove(struct platform_device *pdev)
WARN_ON(ret);
hfi_destroy(core);
- venus_shutdown(dev);
+ venus_shutdown(core);
of_platform_depopulate(dev);
venus_firmware_deinit(core);
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index c629666..6382cea 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -133,6 +133,7 @@ struct venus_core {
unsigned int use_tz;
struct video_firmware {
struct device *dev;
+ struct iommu_domain *iommu_domain;
} fw;
struct mutex lock;
struct list_head instances;
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 98b3b16..c29acfd 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -122,6 +123,56 @@ static int venus_load_fw(struct venus_core *core, const
char *fwname,
return ret;
}
+static int venus_boot_no_tz(struct venus_core *core, phys_addr_t mem_phys,
+ size_t mem_size)
+{
+ struct iommu_domain *iommu;
+ struct device *dev;
+ int ret;
+
+ dev = core->fw.dev;
+ if (!dev)
+ return -EPROBE_DEFER;
+
+ iommu = core->fw.iommu_domain;
+
+ ret = iommu_map(iommu, VENUS_FW_START_ADDR, mem_phys, mem_size,
+ IOMMU_READ | IOMMU_WRITE | IOMMU_PRIV);
+ if (ret) {
+ dev_err(dev, "could not map video firmware region\n");
+ return ret;
+ }
+
+ venus_reset_cpu(core);
+
+ return 0;
+}
+
+static int venus_shutdown_no_tz(struct venus_core *core)
+{
+ struct iommu_domain *iommu;
+ size_t unmapped;
+ u32 reg;
+ struct device *dev = core->fw.dev;
+ void __iomem *base = core->base;
+
+ /* Assert the reset to ARM9 */
+ reg = readl_relaxed(base + WRAPPER_A9SS_SW_RESET);
+ reg |= WRAPPER_A9SS_SW_RESET_BIT;
+ writel_relaxed(reg, base + WRAPPER_A9SS_SW_RESET);
+
+ /* Make sure reset is asserted before the mapping is removed */
+ mb();
+
+ iommu = core->fw.iommu_domain;
+
+ unmapped = iommu_unmap(iommu, VENUS_FW_START_ADDR, VENUS_FW_MEM_SIZE);
+ if (unmapped != VENUS_FW_MEM_SIZE)
+ dev_err(dev, "failed to unmap firmware\n");
+
+ return 0;
+}
+
int venus_boot(struct venus_core *core)
{
struct device *dev = core->dev;
@@ -139,17 +190,30 @@ int venus_boot(struct venus_core *core)
return -EINVAL;
}
- return qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+ if (core->use_tz)
+ ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+ else
+ ret = venus_boot_no_tz(core, mem_phys, mem_size);
+
+ return ret;
}
-int venus_shutdown(struct device *dev)
+int venus_shutdown(struct venus_core *core)
{
- return qcom_scm_pas_shutdown(VENUS_PAS_ID);
+ int ret;
+
+ if (core->use_tz)
+ ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
+ else
+ ret = venus_shutdown_no_tz(core);
+
+ return ret;
}
[PATCH v12 5/5] dt-bindings: media: Document bindings for venus firmware device
Add devicetree binding documentation for firmware loader for video
hardware running on qualcomm chip.
Signed-off-by: Vikash Garodia
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/media/qcom,venus.txt | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt
b/Documentation/devicetree/bindings/media/qcom,venus.txt
index 00d0d1b..b602c4c 100644
--- a/Documentation/devicetree/bindings/media/qcom,venus.txt
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -53,7 +53,8 @@
* Subnodes
The Venus video-codec node must contain two subnodes representing
-video-decoder and video-encoder.
+video-decoder and video-encoder, and one optional firmware subnode.
+Firmware subnode is needed when the platform does not have TrustZone.
Every of video-encoder or video-decoder subnode should have:
@@ -79,6 +80,13 @@ Every of video-encoder or video-decoder subnode should have:
power domain which is responsible for collapsing
and restoring power to the subcore.
+The firmware subnode must have:
+
+- iommus:
+ Usage: required
+ Value type:
+ Definition: A list of phandle and IOMMU specifier pairs.
+
* An Example
video-codec@1d0 {
compatible = "qcom,msm8916-venus";
@@ -105,4 +113,8 @@ Every of video-encoder or video-decoder subnode should have:
clock-names = "core";
power-domains = <&mmcc VENUS_CORE1_GDSC>;
};
+
+ video-firmware {
+ iommus = <&apps_iommu 0x10b2 0x0>;
+ };
};
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v12 3/5] venus: firmware: register separate platform_device for firmware loader
From: Stanimir Varbanov
This registers a firmware platform_device and associate it with
video-firmware DT subnode. Then calls dma configure to initialize
dma and iommu.
Signed-off-by: Stanimir Varbanov
---
drivers/media/platform/qcom/venus/core.c | 14 +--
drivers/media/platform/qcom/venus/core.h | 3 ++
drivers/media/platform/qcom/venus/firmware.c | 55
drivers/media/platform/qcom/venus/firmware.h | 2 +
4 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index 75b9785..440f25f 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -284,6 +284,14 @@ static int venus_probe(struct platform_device *pdev)
if (ret < 0)
goto err_runtime_disable;
+ ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+ if (ret)
+ goto err_runtime_disable;
+
+ ret = venus_firmware_init(core);
+ if (ret)
+ goto err_runtime_disable;
+
ret = venus_boot(core);
if (ret)
goto err_runtime_disable;
@@ -308,10 +316,6 @@ static int venus_probe(struct platform_device *pdev)
if (ret)
goto err_core_deinit;
- ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
- if (ret)
- goto err_dev_unregister;
-
ret = pm_runtime_put_sync(dev);
if (ret)
goto err_dev_unregister;
@@ -347,6 +351,8 @@ static int venus_remove(struct platform_device *pdev)
venus_shutdown(dev);
of_platform_depopulate(dev);
+ venus_firmware_deinit(core);
+
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 8b85dc8..c629666 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -131,6 +131,9 @@ struct venus_core {
struct device *dev_dec;
struct device *dev_enc;
unsigned int use_tz;
+ struct video_firmware {
+ struct device *dev;
+ } fw;
struct mutex lock;
struct list_head instances;
atomic_t insts_count;
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 1d4f066..98b3b16 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -144,3 +146,56 @@ int venus_shutdown(struct device *dev)
{
return qcom_scm_pas_shutdown(VENUS_PAS_ID);
}
+
+int venus_firmware_init(struct venus_core *core)
+{
+ struct platform_device_info info;
+ struct platform_device *pdev;
+ struct device_node *np;
+ int ret;
+
+ np = of_get_child_by_name(core->dev->of_node, "video-firmware");
+ if (!np) {
+ core->use_tz = true;
+ return 0;
+ }
+
+ memset(&info, 0, sizeof(info));
+ info.fwnode = &np->fwnode;
+ info.parent = core->dev;
+ info.name = np->name;
+ info.dma_mask = DMA_BIT_MASK(32);
+
+ pdev = platform_device_register_full(&info);
+ if (IS_ERR(pdev)) {
+ of_node_put(np);
+ return PTR_ERR(pdev);
+ }
+
+ pdev->dev.of_node = np;
+
+ ret = of_dma_configure(&pdev->dev, np, true);
+ if (ret) {
+ dev_err(core->dev, "dma configure fail\n");
+ goto err_unregister;
+ }
+
+ core->fw.dev = &pdev->dev;
+
+ of_node_put(np);
+
+ return 0;
+
+err_unregister:
+ platform_device_unregister(pdev);
+ of_node_put(np);
+ return ret;
+}
+
+void venus_firmware_deinit(struct venus_core *core)
+{
+ if (!core->fw.dev)
+ return;
+
+ platform_device_unregister(to_platform_device(core->fw.dev));
+}
diff --git a/drivers/media/platform/qcom/venus/firmware.h
b/drivers/media/platform/qcom/venus/firmware.h
index 1343747..fd7edf0 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -16,6 +16,8 @@
struct device;
+int venus_firmware_init(struct venus_core *core);
+void venus_firmware_deinit(struct venus_core *core);
int venus_boot(struct venus_core *core);
int venus_shutdown(struct device *dev);
int venus_set_hw_state(struct venus_core *core, bool suspend);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v12 2/5] venus: firmware: move load firmware in a separate function
Separate firmware loading part into a new function.
Signed-off-by: Vikash Garodia
---
drivers/media/platform/qcom/venus/core.c | 4 +-
drivers/media/platform/qcom/venus/firmware.c | 55 ++--
drivers/media/platform/qcom/venus/firmware.h | 2 +-
3 files changed, 38 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.c
b/drivers/media/platform/qcom/venus/core.c
index bb6add9..75b9785 100644
--- a/drivers/media/platform/qcom/venus/core.c
+++ b/drivers/media/platform/qcom/venus/core.c
@@ -84,7 +84,7 @@ static void venus_sys_error_handler(struct work_struct *work)
pm_runtime_get_sync(core->dev);
- ret |= venus_boot(core->dev, core->res->fwname);
+ ret |= venus_boot(core);
ret |= hfi_core_resume(core, true);
@@ -284,7 +284,7 @@ static int venus_probe(struct platform_device *pdev)
if (ret < 0)
goto err_runtime_disable;
- ret = venus_boot(dev, core->res->fwname);
+ ret = venus_boot(core);
if (ret)
goto err_runtime_disable;
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index 0e21a90..1d4f066 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -60,20 +60,18 @@ int venus_set_hw_state(struct venus_core *core, bool resume)
return 0;
}
-int venus_boot(struct device *dev, const char *fwname)
+static int venus_load_fw(struct venus_core *core, const char *fwname,
+phys_addr_t *mem_phys, size_t *mem_size)
{
const struct firmware *mdt;
struct device_node *node;
- phys_addr_t mem_phys;
+ struct device *dev;
struct resource r;
ssize_t fw_size;
- size_t mem_size;
void *mem_va;
int ret;
- if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) || !qcom_scm_is_available())
- return -EPROBE_DEFER;
-
+ dev = core->dev;
node = of_parse_phandle(dev->of_node, "memory-region", 0);
if (!node) {
dev_err(dev, "no memory-region specified\n");
@@ -84,16 +82,16 @@ int venus_boot(struct device *dev, const char *fwname)
if (ret)
return ret;
- mem_phys = r.start;
- mem_size = resource_size(&r);
+ *mem_phys = r.start;
+ *mem_size = resource_size(&r);
- if (mem_size < VENUS_FW_MEM_SIZE)
+ if (*mem_size < VENUS_FW_MEM_SIZE)
return -EINVAL;
- mem_va = memremap(r.start, mem_size, MEMREMAP_WC);
+ mem_va = memremap(r.start, *mem_size, MEMREMAP_WC);
if (!mem_va) {
dev_err(dev, "unable to map memory region: %pa+%zx\n",
- &r.start, mem_size);
+ &r.start, *mem_size);
return -ENOMEM;
}
@@ -108,23 +106,40 @@ int venus_boot(struct device *dev, const char *fwname)
goto err_unmap;
}
- ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID, mem_va, mem_phys,
- mem_size, NULL);
+ if (core->use_tz)
+ ret = qcom_mdt_load(dev, mdt, fwname, VENUS_PAS_ID,
+ mem_va, *mem_phys, *mem_size, NULL);
+ else
+ ret = qcom_mdt_load_no_init(dev, mdt, fwname, VENUS_PAS_ID,
+ mem_va, *mem_phys, *mem_size, NULL);
release_firmware(mdt);
- if (ret)
- goto err_unmap;
-
- ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
- if (ret)
- goto err_unmap;
-
err_unmap:
memunmap(mem_va);
return ret;
}
+int venus_boot(struct venus_core *core)
+{
+ struct device *dev = core->dev;
+ phys_addr_t mem_phys;
+ size_t mem_size;
+ int ret;
+
+ if (!IS_ENABLED(CONFIG_QCOM_MDT_LOADER) ||
+ (core->use_tz && !qcom_scm_is_available()))
+ return -EPROBE_DEFER;
+
+ ret = venus_load_fw(core, core->res->fwname, &mem_phys, &mem_size);
+ if (ret) {
+ dev_err(dev, "fail to load video firmware\n");
+ return -EINVAL;
+ }
+
+ return qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+}
+
int venus_shutdown(struct device *dev)
{
return qcom_scm_pas_shutdown(VENUS_PAS_ID);
diff --git a/drivers/media/platform/qcom/venus/firmware.h
b/drivers/media/platform/qcom/venus/firmware.h
index 397570c..1343747 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -16,7 +16,7 @@
struct device;
-int venus_boot(struct device *dev, const char *fwname);
+int venus_boot(struct venus_core *core);
int venus_shutdown(struct device *dev);
int venus_set_hw_state(struct venus_core *core, bool suspend);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
[PATCH v12 1/5] venus: firmware: add routine to reset ARM9
Add routine to reset the ARM9 and brings it out of reset. Also
abstract the Venus CPU state handling with a new function. This
is in preparation to add PIL functionality in venus driver.
Signed-off-by: Vikash Garodia
---
drivers/media/platform/qcom/venus/core.h | 2 ++
drivers/media/platform/qcom/venus/firmware.c | 33
drivers/media/platform/qcom/venus/firmware.h | 11
drivers/media/platform/qcom/venus/hfi_venus.c| 13 +++---
drivers/media/platform/qcom/venus/hfi_venus_io.h | 7 +
5 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/qcom/venus/core.h
b/drivers/media/platform/qcom/venus/core.h
index 2f02365..8b85dc8 100644
--- a/drivers/media/platform/qcom/venus/core.h
+++ b/drivers/media/platform/qcom/venus/core.h
@@ -98,6 +98,7 @@ struct venus_caps {
* @dev: convenience struct device pointer
* @dev_dec: convenience struct device pointer for decoder device
* @dev_enc: convenience struct device pointer for encoder device
+ * @use_tz:a flag that suggests presence of trustzone
* @lock: a lock for this strucure
* @instances: a list_head of all instances
* @insts_count: num of instances
@@ -129,6 +130,7 @@ struct venus_core {
struct device *dev;
struct device *dev_dec;
struct device *dev_enc;
+ unsigned int use_tz;
struct mutex lock;
struct list_head instances;
atomic_t insts_count;
diff --git a/drivers/media/platform/qcom/venus/firmware.c
b/drivers/media/platform/qcom/venus/firmware.c
index c4a5778..0e21a90 100644
--- a/drivers/media/platform/qcom/venus/firmware.c
+++ b/drivers/media/platform/qcom/venus/firmware.c
@@ -22,10 +22,43 @@
#include
#include
+#include "core.h"
#include "firmware.h"
+#include "hfi_venus_io.h"
#define VENUS_PAS_ID 9
#define VENUS_FW_MEM_SIZE (6 * SZ_1M)
+#define VENUS_FW_START_ADDR0x0
+
+static void venus_reset_cpu(struct venus_core *core)
+{
+ void __iomem *base = core->base;
+
+ writel(0, base + WRAPPER_FW_START_ADDR);
+ writel(VENUS_FW_MEM_SIZE, base + WRAPPER_FW_END_ADDR);
+ writel(0, base + WRAPPER_CPA_START_ADDR);
+ writel(VENUS_FW_MEM_SIZE, base + WRAPPER_CPA_END_ADDR);
+ writel(VENUS_FW_MEM_SIZE, base + WRAPPER_NONPIX_START_ADDR);
+ writel(VENUS_FW_MEM_SIZE, base + WRAPPER_NONPIX_END_ADDR);
+ writel(0x0, base + WRAPPER_CPU_CGC_DIS);
+ writel(0x0, base + WRAPPER_CPU_CLOCK_CONFIG);
+
+ /* Bring ARM9 out of reset */
+ writel(0, base + WRAPPER_A9SS_SW_RESET);
+}
+
+int venus_set_hw_state(struct venus_core *core, bool resume)
+{
+ if (core->use_tz)
+ return qcom_scm_set_remote_state(resume, 0);
+
+ if (resume)
+ venus_reset_cpu(core);
+ else
+ writel(1, core->base + WRAPPER_A9SS_SW_RESET);
+
+ return 0;
+}
int venus_boot(struct device *dev, const char *fwname)
{
diff --git a/drivers/media/platform/qcom/venus/firmware.h
b/drivers/media/platform/qcom/venus/firmware.h
index 428efb5..397570c 100644
--- a/drivers/media/platform/qcom/venus/firmware.h
+++ b/drivers/media/platform/qcom/venus/firmware.h
@@ -18,5 +18,16 @@
int venus_boot(struct device *dev, const char *fwname);
int venus_shutdown(struct device *dev);
+int venus_set_hw_state(struct venus_core *core, bool suspend);
+
+static inline int venus_set_hw_state_suspend(struct venus_core *core)
+{
+ return venus_set_hw_state(core, false);
+}
+
+static inline int venus_set_hw_state_resume(struct venus_core *core)
+{
+ return venus_set_hw_state(core, true);
+}
#endif
diff --git a/drivers/media/platform/qcom/venus/hfi_venus.c
b/drivers/media/platform/qcom/venus/hfi_venus.c
index 1240855..074837e 100644
--- a/drivers/media/platform/qcom/venus/hfi_venus.c
+++ b/drivers/media/platform/qcom/venus/hfi_venus.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include "core.h"
@@ -27,6 +26,7 @@
#include "hfi_msgs.h"
#include "hfi_venus.h"
#include "hfi_venus_io.h"
+#include "firmware.h"
#define HFI_MASK_QHDR_TX_TYPE 0xff00
#define HFI_MASK_QHDR_RX_TYPE 0x00ff
@@ -55,11 +55,6 @@
#define IFACEQ_VAR_LARGE_PKT_SIZE 512
#define IFACEQ_VAR_HUGE_PKT_SIZE (1024 * 12)
-enum tzbsp_video_state {
- TZBSP_VIDEO_STATE_SUSPEND = 0,
- TZBSP_VIDEO_STATE_RESUME
-};
-
struct hfi_queue_table_header {
u32 version;
u32 size;
@@ -575,7 +570,7 @@ static int venus_power_off(struct venus_hfi_device *hdev)
if (!hdev->power_enabled)
return 0;
- ret = qcom_scm_set_remote_state(TZBSP_VIDEO_STATE_SUSPEND, 0);
+ ret = venus_set_hw_state_suspend(hdev->core);
if (ret)
return ret;
@@ -595,7 +590,7 @@ static int venus_power_on(struct venus_hfi_device *hdev)
if (hdev->power_enabled)
retur
[PATCH v12 0/5] Venus updates - PIL
This version of the series * updates the tz flag to unsigned Stanimir Varbanov (1): venus: firmware: register separate platform_device for firmware loader Vikash Garodia (4): venus: firmware: add routine to reset ARM9 venus: firmware: move load firmware in a separate function venus: firmware: add no TZ boot and shutdown routine dt-bindings: media: Document bindings for venus firmware device .../devicetree/bindings/media/qcom,venus.txt | 14 +- drivers/media/platform/qcom/venus/core.c | 24 ++- drivers/media/platform/qcom/venus/core.h | 6 + drivers/media/platform/qcom/venus/firmware.c | 235 +++-- drivers/media/platform/qcom/venus/firmware.h | 17 +- drivers/media/platform/qcom/venus/hfi_venus.c | 13 +- drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 + 7 files changed, 274 insertions(+), 43 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v7 2/6] ARM: dts: rockchip: add VPU device node for RK3288
Am Freitag, 5. Oktober 2018, 14:04:04 CEST schrieb Heiko Stuebner: > Am Freitag, 5. Oktober 2018, 02:12:22 CEST schrieb Ezequiel Garcia: > > Add the Video Processing Unit node for RK3288 SoC. > > > > Fix the VPU IOMMU node, which was disabled and lacking > > its power domain property. > > > > Signed-off-by: Ezequiel Garcia > > applied for 4.20 (may possibly move to 4.21 though) > after moving power-domain* below (#)iommu* to keep > alphabetical sorting. as Mauro did have additional comments and the pull request is still open, I've dropped the 2 dts patches from my tree again for now. We'll revisit once the code changes moved again. Heiko
Applied "spi: pic32-sqi: don't pass GFP_DMA32 to dma_alloc_coherent" to the spi tree
The patch
spi: pic32-sqi: don't pass GFP_DMA32 to dma_alloc_coherent
has been applied to the spi tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From ec506e9246bf42795f1fa8a5cd00740e5686ba73 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Sat, 13 Oct 2018 17:17:02 +0200
Subject: [PATCH] spi: pic32-sqi: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
Signed-off-by: Mark Brown
---
drivers/spi/spi-pic32-sqi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-pic32-sqi.c b/drivers/spi/spi-pic32-sqi.c
index 62e6bf1f50b1..d7e4e18ec3df 100644
--- a/drivers/spi/spi-pic32-sqi.c
+++ b/drivers/spi/spi-pic32-sqi.c
@@ -468,7 +468,7 @@ static int ring_desc_ring_alloc(struct pic32_sqi *sqi)
/* allocate coherent DMAable memory for hardware buffer descriptors. */
sqi->bd = dma_zalloc_coherent(&sqi->master->dev,
sizeof(*bd) * PESQI_BD_COUNT,
- &sqi->bd_dma, GFP_DMA32);
+ &sqi->bd_dma, GFP_KERNEL);
if (!sqi->bd) {
dev_err(&sqi->master->dev, "failed allocating dma buffer\n");
return -ENOMEM;
--
2.19.0.rc2
Applied "ASoC: intel: don't pass GFP_DMA32 to dma_alloc_coherent" to the asoc tree
The patch
ASoC: intel: don't pass GFP_DMA32 to dma_alloc_coherent
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 3b991038498bc5011b063d6a804503c577a79434 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Sat, 13 Oct 2018 17:17:04 +0200
Subject: [PATCH] ASoC: intel: don't pass GFP_DMA32 to dma_alloc_coherent
The DMA API does its own zone decisions based on the coherent_dma_mask.
Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
Signed-off-by: Mark Brown
---
sound/soc/intel/common/sst-firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/intel/common/sst-firmware.c
b/sound/soc/intel/common/sst-firmware.c
index 11041aedea31..1e067504b604 100644
--- a/sound/soc/intel/common/sst-firmware.c
+++ b/sound/soc/intel/common/sst-firmware.c
@@ -355,7 +355,7 @@ struct sst_fw *sst_fw_new(struct sst_dsp *dsp,
/* allocate DMA buffer to store FW data */
sst_fw->dma_buf = dma_alloc_coherent(dsp->dma_dev, sst_fw->size,
- &sst_fw->dmable_fw_paddr, GFP_DMA | GFP_KERNEL);
+ &sst_fw->dmable_fw_paddr, GFP_KERNEL);
if (!sst_fw->dma_buf) {
dev_err(dsp->dev, "error: DMA alloc failed\n");
kfree(sst_fw);
--
2.19.0.rc2
Re: [PATCH v3 10/16] gpu: ipu-v3: image-convert: select optimal seam positions
On Fri, 2018-10-12 at 17:33 -0700, Steve Longerbeam wrote:
>
> On 09/18/2018 02:34 AM, Philipp Zabel wrote:
>
>
> > +/*
> > + * Tile left edges are required to be aligned to multiples of 8 bytes
> > + * by the IDMAC.
> > + */
> > +static inline u32 tile_left_align(const struct ipu_image_pixfmt *fmt)
> > +{
> > + return fmt->planar ? 8 * fmt->uv_width_dec : 64 / fmt->bpp;
> > +}
>
>
>
> As I indicated, shouldn't this be
>
> return fmt->planar ? 8 * fmt->uv_width_dec : 8;
>
> ?
>
> Just from a unit analysis perspective, "64 / fmt->bp" has
> units of pixels / 8-bytes, it should have units of bytes.
The tile alignment is in pixels, not in bytes. For 16-bit and 32-bit
packed formats, we only need to align to 4 or 2 pixels, respectively,
as the LCM of 8-byte alignment and 2-byte or 4-byte pixel size is
always 8 bytes.
But now that you pointed it out, it is quite obvious that this can't
work for 24-bit packed formats. Here the LCM of 8-byte alignment and 3-
byte pixels is 24 bytes, or 8 pixels.
How about:
if (fmt->planar)
return fmt->uv_packed ? 8 : 8 * fmt->uv_width_dec;
else
return fmt->bpp == 32 ? 2 : fmt->bpp == 16 ? 4 : 8;
regards
Philipp
[PATCH] cec: add debug_phys_addr module option
If debug_phys_addr is set, then CEC_CAP_PHYS_ADDR is added to the CEC adapter capabilities. This allows for testing CEC even if the physical address isn't set. This makes it possible to connect two HDMI outputs together and still use CEC. Very useful for testing CEC if you don't have access to an HDMI receiver under linux. Signed-off-by: Hans Verkuil --- diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c index e4edc930d4ed..cc875dabd765 100644 --- a/drivers/media/cec/cec-core.c +++ b/drivers/media/cec/cec-core.c @@ -24,6 +24,10 @@ int cec_debug; module_param_named(debug, cec_debug, int, 0644); MODULE_PARM_DESC(debug, "debug level (0-2)"); +static bool debug_phys_addr; +module_param(debug_phys_addr, bool, 0644); +MODULE_PARM_DESC(debug_phys_addr, "add CEC_CAP_PHYS_ADDR if set"); + static dev_t cec_dev_t; /* Active devices */ @@ -270,6 +274,8 @@ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, adap->log_addrs.cec_version = CEC_OP_CEC_VERSION_2_0; adap->log_addrs.vendor_id = CEC_VENDOR_ID_NONE; adap->capabilities = caps; + if (debug_phys_addr) + adap->capabilities |= CEC_CAP_PHYS_ADDR; adap->needs_hpd = caps & CEC_CAP_NEEDS_HPD; adap->available_log_addrs = available_las; adap->sequence = 0;
Re: [PATCH v4 2/2] media: platform: Add Aspeed Video Engine driver
On 10/05/2018 09:57 PM, Eddie James wrote:
> The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs
> can capture and compress video data from digital or analog sources. With
> the Aspeed chip acting a service processor, the Video Engine can capture
> the host processor graphics output.
>
> Add a V4L2 driver to capture video data and compress it to JPEG images.
> Make the video frames available through the V4L2 streaming interface.
>
> Signed-off-by: Eddie James
> ---
> MAINTAINERS |8 +
> drivers/media/platform/Kconfig|8 +
> drivers/media/platform/Makefile |1 +
> drivers/media/platform/aspeed-video.c | 1674
> +
> 4 files changed, 1691 insertions(+)
> create mode 100644 drivers/media/platform/aspeed-video.c
>
> +static void aspeed_video_check_polarity(struct aspeed_video *video)
> +{
> + int i;
> + int hsync_counter = 0;
> + int vsync_counter = 0;
> + u32 sts;
> +
> + for (i = 0; i < NUM_POLARITY_CHECKS; ++i) {
> + sts = aspeed_video_read(video, VE_MODE_DETECT_STATUS);
> + if (sts & VE_MODE_DETECT_STATUS_VSYNC)
> + vsync_counter--;
> + else
> + vsync_counter++;
> +
> + if (sts & VE_MODE_DETECT_STATUS_HSYNC)
> + hsync_counter--;
> + else
> + hsync_counter++;
> + }
> +
> + if (hsync_counter < 0 || vsync_counter < 0) {
> + u32 ctrl;
> +
> + if (hsync_counter < 0)
> + ctrl = VE_CTRL_HSYNC_POL;
> + else
> + video->timings.polarities |= V4L2_DV_HSYNC_POS_POL;
> +
> + if (vsync_counter < 0)
> + ctrl = VE_CTRL_VSYNC_POL;
> + else
> + video->timings.polarities |= V4L2_DV_VSYNC_POS_POL;
> +
> + aspeed_video_update(video, VE_CTRL, 0, ctrl);
> + }
> +}
> +
> +static bool aspeed_video_alloc_buf(struct aspeed_video *video,
> +struct aspeed_video_addr *addr,
> +unsigned int size)
> +{
> + addr->virt = dma_alloc_coherent(video->dev, size, &addr->dma,
> + GFP_KERNEL);
> + if (!addr->virt)
> + return false;
> +
> + addr->size = size;
> + return true;
> +}
> +
> +static void aspeed_video_free_buf(struct aspeed_video *video,
> + struct aspeed_video_addr *addr)
> +{
> + dma_free_coherent(video->dev, addr->size, addr->virt, addr->dma);
> + addr->size = 0;
> + addr->dma = 0ULL;
> + addr->virt = NULL;
> +}
> +
> +/*
> + * Get the minimum HW-supported compression buffer size for the frame size.
> + * Assume worst-case JPEG compression size is 1/8 raw size. This should be
> + * plenty even for maximum quality; any worse and the engine will simply
> return
> + * incomplete JPEGs.
> + */
> +static void aspeed_video_calc_compressed_size(struct aspeed_video *video)
> +{
> + int i, j;
> + u32 compression_buffer_size_reg = 0;
> + unsigned int size;
> + const unsigned int num_compression_packets = 4;
> + const unsigned int compression_packet_size = 1024;
> + const unsigned int max_compressed_size =
> + video->width * video->height / 2; /* 4 Bpp / 8 */
> +
> + video->max_compressed_size = UINT_MAX;
> +
> + for (i = 0; i < 6; ++i) {
> + for (j = 0; j < 8; ++j) {
> + size = (num_compression_packets << i) *
> + (compression_packet_size << j);
> + if (size < max_compressed_size)
> + continue;
> +
> + if (size < video->max_compressed_size) {
> + compression_buffer_size_reg = (i << 3) | j;
> + video->max_compressed_size = size;
> + }
> + }
> + }
> +
> + aspeed_video_write(video, VE_STREAM_BUF_SIZE,
> +compression_buffer_size_reg);
> +
> + dev_dbg(video->dev, "max compressed size: %x\n",
> + video->max_compressed_size);
> +}
> +
> +#define res_check(v) test_and_clear_bit(VIDEO_MODE_DETECT_DONE, &(v)->flags)
> +
> +static int aspeed_video_get_resolution(struct aspeed_video *video)
> +{
> + bool invalid_resolution = true;
> + int rc;
> + int tries = 0;
> + unsigned int bottom;
> + unsigned int left;
> + unsigned int right;
> + unsigned int size;
> + unsigned int top;
> + u32 mds;
> + u32 src_lr_edge;
> + u32 src_tb_edge;
> + u32 sync;
> + struct aspeed_video_addr src;
> +
> + if (video->srcs[1].size)
> + aspeed_video_free_buf(video, &video->srcs[1]);
> +
> + if (video->srcs[0].size >= VE_MAX_SRC_BUFFER_SIZE) {
> + src = video->srcs[0];
> + } else {
> +
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
On 10/17/2018 10:57 AM, Laurent Pinchart wrote: > Hi Hans, > > On Thursday, 20 September 2018 17:42:15 EEST Hans Verkuil wrote: >> Some parts of the V4L2 API are awkward to use and I think it would be >> a good idea to look at possible candidates for that. >> >> Examples are the ioctls that use struct v4l2_buffer: the multiplanar support >> is really horrible, and writing code to support both single and multiplanar >> is hard. We are also running out of fields and the timeval isn't y2038 >> compliant. >> >> A proof-of-concept is here: >> >> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer&id=a95 >> 549df06d9900f3559afdbb9da06bd4b22d1f3 >> >> It's a bit old, but it gives a good impression of what I have in mind. >> >> Another candidate is >> VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing >> frame intervals as a fraction is really awkward and so is the fact that the >> subdev and 'normal' ioctls are not the same. >> >> Would using nanoseconds or something along those lines for intervals be >> better? >> >> I have similar concerns with VIDIOC_SUBDEV_ENUM_FRAME_SIZE where there is no >> stepwise option, making it different from VIDIOC_ENUM_FRAMESIZES. But it >> should be possible to extend VIDIOC_SUBDEV_ENUM_FRAME_SIZE with stepwise >> support, I think. > > If we refresh the enumeration ioctls, I propose moving away from the one > syscall per value model, and returning everything in one > (userspace-allocated) > buffer. The same could apply to all enumerations (such as controls for > instance), even if we don't address them all in one go. I'm not convinced about this, primarily because I think these enums are done at configuration time, and rarely if ever while streaming. So does it really make a difference in practice? Feedback on this would be welcome during the summit meeting. > >> Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, again >> in order to improve single vs multiplanar handling. > > If we refresh the G/S/TRY format ioctls (and I think we should), I would > propose moving to a G/S model with ACTIVE and TRY formats, as for subdevs. > This should make it easier to construct full device states internally, in > order to implement proper request API support for formats. We should then > also > document much better how formats and selection rectangles interact. Interesting. I was planning a slide for this. >> It is not the intention to come to a full design, it's more to test the >> waters so to speak. > > Another item that we're missing is a way to delete buffers (the counterpart > of > VIDIOC_CREATE_BUFS). As this will introduce holes in the buffer indices, we > might also need to revamp VIDIOC_CREATE_BUFS (which would give us a chance to > move away from the format structure passed to that ioctl). > I'm just writing the slide for that :-) Regards, Hans
Re: [PATCH v11 0/5] Venus updates - PIL
Hi Vikash, Thanks for the patches and patience! On 10/08/2018 04:32 PM, Vikash Garodia wrote: > This version of the series > * extends the description of firmware subnode in documentation. > * renames the flag suggesting the presence of tz and update code > accordingly. > > Stanimir Varbanov (1): > venus: firmware: register separate platform_device for firmware loader > > Vikash Garodia (4): > venus: firmware: add routine to reset ARM9 > venus: firmware: move load firmware in a separate function > venus: firmware: add no TZ boot and shutdown routine > dt-bindings: media: Document bindings for venus firmware device > > .../devicetree/bindings/media/qcom,venus.txt | 14 +- > drivers/media/platform/qcom/venus/core.c | 24 ++- > drivers/media/platform/qcom/venus/core.h | 6 + > drivers/media/platform/qcom/venus/firmware.c | 235 > +++-- > drivers/media/platform/qcom/venus/firmware.h | 17 +- > drivers/media/platform/qcom/venus/hfi_venus.c | 13 +- > drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 + > 7 files changed, 274 insertions(+), 43 deletions(-) > Tested-by: Stanimir Varbanov With the comment addressed in 1/5: Acked-by: Stanimir Varbanov -- regards, Stan
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
Hi Hans, On Thursday, 20 September 2018 17:42:15 EEST Hans Verkuil wrote: > Some parts of the V4L2 API are awkward to use and I think it would be > a good idea to look at possible candidates for that. > > Examples are the ioctls that use struct v4l2_buffer: the multiplanar support > is really horrible, and writing code to support both single and multiplanar > is hard. We are also running out of fields and the timeval isn't y2038 > compliant. > > A proof-of-concept is here: > > https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer&id=a95 > 549df06d9900f3559afdbb9da06bd4b22d1f3 > > It's a bit old, but it gives a good impression of what I have in mind. > > Another candidate is > VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing > frame intervals as a fraction is really awkward and so is the fact that the > subdev and 'normal' ioctls are not the same. > > Would using nanoseconds or something along those lines for intervals be > better? > > I have similar concerns with VIDIOC_SUBDEV_ENUM_FRAME_SIZE where there is no > stepwise option, making it different from VIDIOC_ENUM_FRAMESIZES. But it > should be possible to extend VIDIOC_SUBDEV_ENUM_FRAME_SIZE with stepwise > support, I think. If we refresh the enumeration ioctls, I propose moving away from the one syscall per value model, and returning everything in one (userspace-allocated) buffer. The same could apply to all enumerations (such as controls for instance), even if we don't address them all in one go. > Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, again > in order to improve single vs multiplanar handling. If we refresh the G/S/TRY format ioctls (and I think we should), I would propose moving to a G/S model with ACTIVE and TRY formats, as for subdevs. This should make it easier to construct full device states internally, in order to implement proper request API support for formats. We should then also document much better how formats and selection rectangles interact. > It is not the intention to come to a full design, it's more to test the > waters so to speak. Another item that we're missing is a way to delete buffers (the counterpart of VIDIOC_CREATE_BUFS). As this will introduce holes in the buffer indices, we might also need to revamp VIDIOC_CREATE_BUFS (which would give us a chance to move away from the format structure passed to that ioctl). -- Regards, Laurent Pinchart
Re: [PATCH v11 1/5] venus: firmware: add routine to reset ARM9
Hi Vikash,
On 10/08/2018 04:32 PM, Vikash Garodia wrote:
> Add routine to reset the ARM9 and brings it out of reset. Also
> abstract the Venus CPU state handling with a new function. This
> is in preparation to add PIL functionality in venus driver.
>
> Signed-off-by: Vikash Garodia
> ---
> drivers/media/platform/qcom/venus/core.h | 2 ++
> drivers/media/platform/qcom/venus/firmware.c | 33
>
> drivers/media/platform/qcom/venus/firmware.h | 11
> drivers/media/platform/qcom/venus/hfi_venus.c| 13 +++---
> drivers/media/platform/qcom/venus/hfi_venus_io.h | 7 +
> 5 files changed, 57 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index 2f02365..385e309 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -98,6 +98,7 @@ struct venus_caps {
> * @dev: convenience struct device pointer
> * @dev_dec: convenience struct device pointer for decoder device
> * @dev_enc: convenience struct device pointer for encoder device
> + * @use_tz: a flag that suggests presence of trustzone
> * @lock:a lock for this strucure
> * @instances: a list_head of all instances
> * @insts_count: num of instances
> @@ -129,6 +130,7 @@ struct venus_core {
> struct device *dev;
> struct device *dev_dec;
> struct device *dev_enc;
> + bool use_tz;
could you make it unsigned? For more info please run checkpatch --strict.
I know that we have structure members of type bool already - that should
be fixed with follow-up patches, I guess.
--
regards,
Stan
Re: [PATCH] media: uvcvideo: Add boottime clock support
Hi Laurent,
On Wed, Oct 17, 2018 at 5:02 PM Laurent Pinchart
wrote:
>
> Hi Heng-Ruey,
>
> Thank you for the patch.
>
> On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> > Android requires camera timestamps to be reported with
> > CLOCK_BOOTTIME to sync timestamp with other sensor sources.
>
> What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If the
> monotonic clock has shortcomings that make its use impossible for proper
> synchronization, then we should consider switching to CLOCK_BOOTTIME globally
> in V4L2, not in selected drivers only.
>
CLOCK_BOOTTIME includes the time spent in suspend, while
CLOCK_MONOTONIC doesn't. I can imagine the former being much more
useful for anything that cares about the actual, long term, time
tracking. Especially important since suspend is a very common event on
Android and doesn't stop the time flow there, i.e. applications might
wake up the device to perform various tasks at necessary times.
Generally, I'd see a V4L2_BUF_FLAG_TIMESTAMP_BOOTTIME flag being added
and user space being given choice to select the time stamp base it
needs, perhaps by setting the flag in v4l2_buffer struct at QBUF time?
Best regards,
Tomasz
> > Signed-off-by: Heng-Ruey Hsu
> > ---
> > drivers/media/usb/uvc/uvc_driver.c | 4
> > drivers/media/usb/uvc/uvc_video.c | 2 ++
> > 2 files changed, 6 insertions(+)
> >
> > diff --git a/drivers/media/usb/uvc/uvc_driver.c
> > b/drivers/media/usb/uvc/uvc_driver.c index d46dc432456c..a9658f38c586
> > 100644
> > --- a/drivers/media/usb/uvc/uvc_driver.c
> > +++ b/drivers/media/usb/uvc/uvc_driver.c
> > @@ -2287,6 +2287,8 @@ static int uvc_clock_param_get(char *buffer, const
> > struct kernel_param *kp) {
> > if (uvc_clock_param == CLOCK_MONOTONIC)
> > return sprintf(buffer, "CLOCK_MONOTONIC");
> > + else if (uvc_clock_param == CLOCK_BOOTTIME)
> > + return sprintf(buffer, "CLOCK_BOOTTIME");
> > else
> > return sprintf(buffer, "CLOCK_REALTIME");
> > }
> > @@ -2298,6 +2300,8 @@ static int uvc_clock_param_set(const char *val, const
> > struct kernel_param *kp)
> >
> > if (strcasecmp(val, "monotonic") == 0)
> > uvc_clock_param = CLOCK_MONOTONIC;
> > + else if (strcasecmp(val, "boottime") == 0)
> > + uvc_clock_param = CLOCK_BOOTTIME;
> > else if (strcasecmp(val, "realtime") == 0)
> > uvc_clock_param = CLOCK_REALTIME;
> > else
> > diff --git a/drivers/media/usb/uvc/uvc_video.c
> > b/drivers/media/usb/uvc/uvc_video.c index 86a99f461fd8..d4248d5cd9cd 100644
> > --- a/drivers/media/usb/uvc/uvc_video.c
> > +++ b/drivers/media/usb/uvc/uvc_video.c
> > @@ -425,6 +425,8 @@ static inline ktime_t uvc_video_get_time(void)
> > {
> > if (uvc_clock_param == CLOCK_MONOTONIC)
> > return ktime_get();
> > + else if (uvc_clock_param == CLOCK_BOOTTIME)
> > + return ktime_get_boottime();
> > else
> > return ktime_get_real();
> > }
>
> --
> Regards,
>
> Laurent Pinchart
>
>
>
Re: [PATCH] media: uvcvideo: Add boottime clock support
Hi Heng-Ruey,
Thank you for the patch.
On Wednesday, 17 October 2018 10:52:42 EEST Heng-Ruey Hsu wrote:
> Android requires camera timestamps to be reported with
> CLOCK_BOOTTIME to sync timestamp with other sensor sources.
What's the rationale behind this, why can't CLOCK_MONOTONIC work ? If the
monotonic clock has shortcomings that make its use impossible for proper
synchronization, then we should consider switching to CLOCK_BOOTTIME globally
in V4L2, not in selected drivers only.
> Signed-off-by: Heng-Ruey Hsu
> ---
> drivers/media/usb/uvc/uvc_driver.c | 4
> drivers/media/usb/uvc/uvc_video.c | 2 ++
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/media/usb/uvc/uvc_driver.c
> b/drivers/media/usb/uvc/uvc_driver.c index d46dc432456c..a9658f38c586
> 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -2287,6 +2287,8 @@ static int uvc_clock_param_get(char *buffer, const
> struct kernel_param *kp) {
> if (uvc_clock_param == CLOCK_MONOTONIC)
> return sprintf(buffer, "CLOCK_MONOTONIC");
> + else if (uvc_clock_param == CLOCK_BOOTTIME)
> + return sprintf(buffer, "CLOCK_BOOTTIME");
> else
> return sprintf(buffer, "CLOCK_REALTIME");
> }
> @@ -2298,6 +2300,8 @@ static int uvc_clock_param_set(const char *val, const
> struct kernel_param *kp)
>
> if (strcasecmp(val, "monotonic") == 0)
> uvc_clock_param = CLOCK_MONOTONIC;
> + else if (strcasecmp(val, "boottime") == 0)
> + uvc_clock_param = CLOCK_BOOTTIME;
> else if (strcasecmp(val, "realtime") == 0)
> uvc_clock_param = CLOCK_REALTIME;
> else
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index 86a99f461fd8..d4248d5cd9cd 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -425,6 +425,8 @@ static inline ktime_t uvc_video_get_time(void)
> {
> if (uvc_clock_param == CLOCK_MONOTONIC)
> return ktime_get();
> + else if (uvc_clock_param == CLOCK_BOOTTIME)
> + return ktime_get_boottime();
> else
> return ktime_get_real();
> }
--
Regards,
Laurent Pinchart
Re: i.MX6 MIPI-CSI2 OV5640 Camera testing on Mainline Linux
Hi Adam, Seve, On Tue, Oct 16, 2018 at 05:13:24PM -0700, Steve Longerbeam wrote: > Hi Adam, > > > On 10/16/18 12:46 PM, Adam Ford wrote: > >On Thu, Sep 20, 2018 at 9:58 AM jacopo mondi wrote: > >>Hi imx6 people, > >> > >>On Thu, May 31, 2018 at 08:39:20PM +0530, Jagan Teki wrote: > >>>Hi All, > >>> > >>>I'm trying to verify MIPI-CSI2 OV5640 camera on i.MX6 platform with > >>>Mainline Linux. > >>Sorry to resurect this, but before diving deep into details, do anyone > >>of you verified JPEG capture with ov5640 and i.MX6 platforms, and has > >>maybe a pipeline configuration to share :) ? > > > >I have a 4.14 kernel for my i.MX6D/Q using an ov5640 connected in a > >similar way as the sabresd and I'm getting similar timeouts. > >when executing > > > >media-ctl -l "'ov5640 2-0010':0 -> 'imx6-mipi-csi2':0[1]" > >media-ctl -l "'imx6-mipi-csi2':2 -> 'ipu1_csi1':0[1]" > > > You're routing through imx6-mipi-csi2 pad 2, which is CSI-2 virtual > channel 1, so make sure the ov5640 is transmitting on that channel, > see virtual_channel module parameter. > > > >media-ctl -l "'ipu1_csi1':1 -> 'ipu1_ic_prp':0[1]" > >media-ctl -l "'ipu1_ic_prp':1 -> 'ipu1_ic_prpenc':0[1]" > >media-ctl -l "'ipu1_ic_prpenc':1 -> 'ipu1_ic_prpenc capture':0[1]" > > > > > >media-ctl -V "'ov5640 2-0010':0 [fmt:UYVY2X8/640x480 field:none]" > >media-ctl -V "'imx6-mipi-csi2':2 [fmt:UYVY2X8/640x480 field:none]" > >media-ctl -V "'ipu1_csi1':1 [fmt:AYUV32/640x480 field:none]" > >media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/640x480 field:none]" > >media-ctl -V "'ipu1_ic_prpenc':1 [fmt:AYUV32/640x480 field:none]" > > > > > > gst-launch-1.0 -v v4l2src num-buffers=1 device=/dev/video0 ! jpegenc > >! filesink location=test.jpg Thanks, am I wrong or jpegenc is a software JPEG encoder? I was interested in options for capturing the JPEG frames as produced by the sensor. I'm not even sure it is possible at all. > > > >[ 72.799015] ipu1_ic_prpenc: EOF timeout > >[ 73.838985] ipu1_ic_prpenc: wait last EOF timeout > > > >When I try to jump directly to 4.19-RC8, I get errors regarding memory > >allocation, so I think there might be something else there I am > >missing. > > Please share the errors. I am using v4.19-rc7 without issues. > >Has anyone tried this camera module on a 4.14 kernel? I noticed there > >are a bunch of driver updates, and I was hoping there might be some > >patches that could be be backported to the 4.14.y stable branch. > > I would suggest backporting all the ov5640 commits. You can also > backport the imx-media commits, but that shouldn't be the cause > of the timeouts you are seeing. > Yes, try to backport the recent ov5640 developments on your kernel version. There are a lot of fixes there, and I don't think there is any dependency on new developments on the v4l2 framework you don't have in v4.14 (I might be wrong though). In case something breaks when cherry-picking patches or when building, please share and someone might help (I have recently backported those changes to a v3.14 kernel, so I might help too). Thanks j > > Steve > > > > > > >thanks for any suggestions to try. > > > >adam > > > >>Thanks > >>j > >> > >>>I've followed these[1] instructions to configure MC links and pads > >>>based on the probing details from dmesg and trying to capture > >>>ipu1_ic_prpenc capture (/dev/video1) but it's not working. > >>> > >>>Can anyone help me to verify whether I configured all the details > >>>properly if not please suggest. > >>> > >>>I'm pasting full log here, so-that anyone can comment in line and dt > >>>changes are at [2] > >>> > >>>Log: > >>>- > >>> > >>>[1.211866] etnaviv-gpu 2204000.gpu: Ignoring GPU with VG and FE2.0 > >>>[1.220211] [drm] Initialized etnaviv 1.2.0 20151214 for etnaviv on > >>>minor 0 > >>>[1.230344] imx-ipuv3 240.ipu: IPUv3H probed > >>>[1.237170] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > >>>[1.243920] [drm] No driver support for vblank timestamp query. > >>>[1.250831] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops > >>>ipu_crtc_ops) > >>>[1.258503] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops > >>>ipu_crtc_ops) > >>>[1.266293] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops > >>>ipu_crtc_ops) > >>>[1.274027] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops > >>>ipu_crtc_ops) > >>>[1.282304] dwhdmi-imx 12.hdmi: Detected HDMI TX controller > >>>v1.30a with HDCP (DWC HDMI 3D TX PHY) > >>>[1.295722] imx-drm display-subsystem: bound 12.hdmi (ops > >>>dw_hdmi_imx_ops) > >>>[1.373615] Console: switching to colour frame buffer device 128x48 > >>>[1.396495] imx-drm display-subsystem: fb0: frame buffer device > >>>[1.404620] [drm] Initialized imx-drm 1.0.0 20120507 for > >>>display-subsystem on minor 1 > >>>[1.412763] imx-ipuv3 280.ipu: IPUv3H probed > >>>[1.439673] brd: module loaded > >>>[1.469099] loop: module loaded > >>>[1.480324] nand: No NAND device found
[PATCH] media: uvcvideo: Add boottime clock support
Android requires camera timestamps to be reported with
CLOCK_BOOTTIME to sync timestamp with other sensor sources.
Signed-off-by: Heng-Ruey Hsu
---
drivers/media/usb/uvc/uvc_driver.c | 4
drivers/media/usb/uvc/uvc_video.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index d46dc432456c..a9658f38c586 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2287,6 +2287,8 @@ static int uvc_clock_param_get(char *buffer, const struct
kernel_param *kp)
{
if (uvc_clock_param == CLOCK_MONOTONIC)
return sprintf(buffer, "CLOCK_MONOTONIC");
+ else if (uvc_clock_param == CLOCK_BOOTTIME)
+ return sprintf(buffer, "CLOCK_BOOTTIME");
else
return sprintf(buffer, "CLOCK_REALTIME");
}
@@ -2298,6 +2300,8 @@ static int uvc_clock_param_set(const char *val, const
struct kernel_param *kp)
if (strcasecmp(val, "monotonic") == 0)
uvc_clock_param = CLOCK_MONOTONIC;
+ else if (strcasecmp(val, "boottime") == 0)
+ uvc_clock_param = CLOCK_BOOTTIME;
else if (strcasecmp(val, "realtime") == 0)
uvc_clock_param = CLOCK_REALTIME;
else
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index 86a99f461fd8..d4248d5cd9cd 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -425,6 +425,8 @@ static inline ktime_t uvc_video_get_time(void)
{
if (uvc_clock_param == CLOCK_MONOTONIC)
return ktime_get();
+ else if (uvc_clock_param == CLOCK_BOOTTIME)
+ return ktime_get_boottime();
else
return ktime_get_real();
}
--
2.19.1.331.ge82ca0e54c-goog
Re: [linux-sunxi] [PATCH v11 1/2] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
On Wed, Sep 26, 2018 at 2:11 PM Yong Deng wrote: > > Add binding documentation for Allwinner V3s CSI. > > Acked-by: Maxime Ripard > Acked-by: Sakari Ailus > Reviewed-by: Rob Herring > Signed-off-by: Yong Deng > --- > .../devicetree/bindings/media/sun6i-csi.txt| 59 > ++ > 1 file changed, 59 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt > > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt > b/Documentation/devicetree/bindings/media/sun6i-csi.txt > new file mode 100644 > index ..2ff47a9507a6 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt > @@ -0,0 +1,59 @@ > +Allwinner V3s Camera Sensor Interface > +- > + > +Allwinner V3s SoC features two CSI module. CSI0 is used for MIPI CSI-2 > +interface and CSI1 is used for parallel interface. > + > +Required properties: > + - compatible: value must be "allwinner,sun8i-v3s-csi" > + - reg: base address and size of the memory-mapped region. > + - interrupts: interrupt associated to this IP > + - clocks: phandles to the clocks feeding the CSI > +* bus: the CSI interface clock > +* mod: the CSI module clock > +* ram: the CSI DRAM clock > + - clock-names: the clock names mentioned above > + - resets: phandles to the reset line driving the CSI > + > +Each CSI node should contain one 'port' child node with one child 'endpoint' > +node, according to the bindings defined in > +Documentation/devicetree/bindings/media/video-interfaces.txt. As mentioned > +above, the endpoint's bus type should be MIPI CSI-2 for CSI0 and parallel or > +Bt656 for CSI1. But A64 manual claimed that CSI0 is parallel (ofcourse it has only one controller). On the other-side the register space seems similar. and also is Bt656 and CCIR656 are same types? -- Jagan Teki Senior Linux Kernel Engineer | Amarula Solutions U-Boot, Linux | Upstream Maintainer Hyderabad, India.
Re: [PATCH 1/8] cpufreq: tegra186: don't pass GFP_DMA32 to dma_alloc_coherent
On Wed, Oct 17, 2018 at 9:19 AM Christoph Hellwig wrote: > > On Mon, Oct 15, 2018 at 09:43:04AM +0200, Rafael J. Wysocki wrote: > > On Sat, Oct 13, 2018 at 5:17 PM Christoph Hellwig wrote: > > > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > > > Signed-off-by: Christoph Hellwig > > > > Acked-by: Rafael J. Wysocki > > Can you pick it up through the cpufreq tree? Sure, I'll do that, thanks!
Re: [PATCH 7/8] media: sti/bdisp: don't pass GFP_DMA32 to dma_alloc_attrs
On Mon, Oct 15, 2018 at 11:12:55AM +0200, Benjamin Gaignard wrote: > Le sam. 13 oct. 2018 à 17:18, Christoph Hellwig a écrit : > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > Signed-off-by: Christoph Hellwig > > Reviewed-by: Benjamin Gaignard Can you pick it up through the media tree?
Re: [PATCH 6/8] drm: sti: don't pass GFP_DMA32 to dma_alloc_wc
On Tue, Oct 16, 2018 at 02:41:23PM +0200, Benjamin Gaignard wrote: > Le lun. 15 oct. 2018 à 11:12, Benjamin Gaignard > a écrit : > > > > Le sam. 13 oct. 2018 à 17:17, Christoph Hellwig a écrit : > > > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > > > Signed-off-by: Christoph Hellwig > > > > Reviewed-by: Benjamin Gaignard > > Christoph do you plan to merge this patch on your own tree ? or would > like I put it directly in drm-misc-next branch ? Please pull it in through drm-misc-next, thanks!
Re: [PATCH 1/8] cpufreq: tegra186: don't pass GFP_DMA32 to dma_alloc_coherent
On Mon, Oct 15, 2018 at 09:43:04AM +0200, Rafael J. Wysocki wrote: > On Sat, Oct 13, 2018 at 5:17 PM Christoph Hellwig wrote: > > > > The DMA API does its own zone decisions based on the coherent_dma_mask. > > > > Signed-off-by: Christoph Hellwig > > Acked-by: Rafael J. Wysocki Can you pick it up through the cpufreq tree?
Re: [PATCH v3 6/6] media: video-i2c: support runtime PM
On Wed, Oct 17, 2018 at 12:07:50AM +0900, Akinobu Mita wrote:
> 2018年10月16日(火) 0:31 Sakari Ailus :
> >
> > Hi Mita-san,
> >
> > On Sun, Oct 14, 2018 at 03:02:39AM +0900, Akinobu Mita wrote:
> > > AMG88xx has a register for setting operating mode. This adds support
> > > runtime PM by changing the operating mode.
> > >
> > > The instruction for changing sleep mode to normal mode is from the
> > > reference specifications.
> > >
> > > https://docid81hrs3j1.cloudfront.net/medialibrary/2017/11/PANA-S-A0002141979-1.pdf
> > >
> > > Cc: Matt Ranostay
> > > Cc: Sakari Ailus
> > > Cc: Hans Verkuil
> > > Cc: Mauro Carvalho Chehab
> > > Reviewed-by: Matt Ranostay
> > > Acked-by: Sakari Ailus
> > > Signed-off-by: Akinobu Mita
> > > ---
> > > * v3
> > > - Move chip->set_power() call to the video device release() callback.
> > > - Add Acked-by line
> > >
> > > drivers/media/i2c/video-i2c.c | 141
> > > +-
> > > 1 file changed, 139 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/video-i2c.c b/drivers/media/i2c/video-i2c.c
> > > index 3334fc2..22fdc43 100644
> > > --- a/drivers/media/i2c/video-i2c.c
> > > +++ b/drivers/media/i2c/video-i2c.c
> > > @@ -17,6 +17,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -94,10 +95,23 @@ struct video_i2c_chip {
> > > /* xfer function */
> > > int (*xfer)(struct video_i2c_data *data, char *buf);
> > >
> > > + /* power control function */
> > > + int (*set_power)(struct video_i2c_data *data, bool on);
> > > +
> > > /* hwmon init function */
> > > int (*hwmon_init)(struct video_i2c_data *data);
> > > };
> > >
> > > +/* Power control register */
> > > +#define AMG88XX_REG_PCTL 0x00
> > > +#define AMG88XX_PCTL_NORMAL 0x00
> > > +#define AMG88XX_PCTL_SLEEP 0x10
> > > +
> > > +/* Reset register */
> > > +#define AMG88XX_REG_RST 0x01
> > > +#define AMG88XX_RST_FLAG 0x30
> > > +#define AMG88XX_RST_INIT 0x3f
> > > +
> > > /* Frame rate register */
> > > #define AMG88XX_REG_FPSC 0x02
> > > #define AMG88XX_FPSC_1FPSBIT(0)
> > > @@ -127,6 +141,59 @@ static int amg88xx_setup(struct video_i2c_data *data)
> > > return regmap_update_bits(data->regmap, AMG88XX_REG_FPSC, mask,
> > > val);
> > > }
> > >
> > > +static int amg88xx_set_power_on(struct video_i2c_data *data)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL,
> > > AMG88XX_PCTL_NORMAL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + msleep(50);
> > > +
> > > + ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_INIT);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + msleep(2);
> > > +
> > > + ret = regmap_write(data->regmap, AMG88XX_REG_RST, AMG88XX_RST_FLAG);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > + * Wait two frames before reading thermistor and temperature
> > > registers
> > > + */
> > > + msleep(200);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int amg88xx_set_power_off(struct video_i2c_data *data)
> > > +{
> > > + int ret;
> > > +
> > > + ret = regmap_write(data->regmap, AMG88XX_REG_PCTL,
> > > AMG88XX_PCTL_SLEEP);
> > > + if (ret)
> > > + return ret;
> > > + /*
> > > + * Wait for a while to avoid resuming normal mode immediately after
> > > + * entering sleep mode, otherwise the device occasionally goes wrong
> > > + * (thermistor and temperature registers are not updated at all)
> > > + */
> > > + msleep(100);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int amg88xx_set_power(struct video_i2c_data *data, bool on)
> > > +{
> > > + if (on)
> > > + return amg88xx_set_power_on(data);
> > > +
> > > + return amg88xx_set_power_off(data);
> > > +}
> > > +
> > > #if IS_ENABLED(CONFIG_HWMON)
> > >
> > > static const u32 amg88xx_temp_config[] = {
> > > @@ -158,7 +225,15 @@ static int amg88xx_read(struct device *dev, enum
> > > hwmon_sensor_types type,
> > > __le16 buf;
> > > int tmp;
> > >
> > > + tmp = pm_runtime_get_sync(regmap_get_device(data->regmap));
> > > + if (tmp < 0) {
> > > + pm_runtime_put_noidle(regmap_get_device(data->regmap));
> > > + return tmp;
> > > + }
> > > +
> > > tmp = regmap_bulk_read(data->regmap, AMG88XX_REG_TTHL, &buf, 2);
> > > + pm_runtime_mark_last_busy(regmap_get_device(data->regmap));
> > > + pm_runtime_put_autosuspend(regmap_get_device(data->regmap));
> > > if (tmp)
> > > return tmp;
> > >
> > > @@ -217,6 +292,7 @@ static const struct video_i2c_chip video_i2c_chip[] =
> > > {
> > > .regmap_config = &amg88xx_regmap_config,
> > > .setup = &amg88
Re: [PATCH v11 0/5] Venus updates - PIL
Hi Vikash, On 10/16/2018 06:55 PM, Vikash Garodia wrote: > I have no review comments. I'll need some time to test this version on v1 and v3. > > On 2018-10-08 19:02, Vikash Garodia wrote: >> This version of the series >> * extends the description of firmware subnode in documentation. >> * renames the flag suggesting the presence of tz and update code >> accordingly. >> >> Stanimir Varbanov (1): >> venus: firmware: register separate platform_device for firmware loader >> >> Vikash Garodia (4): >> venus: firmware: add routine to reset ARM9 >> venus: firmware: move load firmware in a separate function >> venus: firmware: add no TZ boot and shutdown routine >> dt-bindings: media: Document bindings for venus firmware device >> >> .../devicetree/bindings/media/qcom,venus.txt | 14 +- >> drivers/media/platform/qcom/venus/core.c | 24 ++- >> drivers/media/platform/qcom/venus/core.h | 6 + >> drivers/media/platform/qcom/venus/firmware.c | 235 >> +++-- >> drivers/media/platform/qcom/venus/firmware.h | 17 +- >> drivers/media/platform/qcom/venus/hfi_venus.c | 13 +- >> drivers/media/platform/qcom/venus/hfi_venus_io.h | 8 + >> 7 files changed, 274 insertions(+), 43 deletions(-) -- regards, Stan
