For cx231xx users
Hello! Dear users of tv-tuners based cx231xx. Could you please connect tuner to PC and send to me output of "lsusb -v" command? I would like to clarify hardware revision, stored in bcdDevice usb descriptor. Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
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: Tue Jan 24 05:00:22 CET 2017 media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a media_build git hash: 3c6ce4ff75f19adf45869e34b376c5b9dee4d50a v4l-utils git hash: 9df320dd3d1a498fcd6cdeef7d783da609b526e0 gcc version:i686-linux-gcc (GCC) 6.2.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.8.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: OK linux-3.12.67-i686: OK linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0.9-i686: WARNINGS linux-4.1.33-i686: WARNINGS linux-4.2.8-i686: WARNINGS linux-4.3.6-i686: WARNINGS linux-4.4.22-i686: WARNINGS linux-4.5.7-i686: WARNINGS linux-4.6.7-i686: WARNINGS linux-4.7.5-i686: WARNINGS linux-4.8-i686: OK linux-4.9-i686: OK linux-4.10-rc3-i686: OK linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: OK linux-3.12.67-x86_64: OK linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0.9-x86_64: WARNINGS linux-4.1.33-x86_64: WARNINGS linux-4.2.8-x86_64: WARNINGS linux-4.3.6-x86_64: WARNINGS linux-4.4.22-x86_64: WARNINGS linux-4.5.7-x86_64: WARNINGS linux-4.6.7-x86_64: WARNINGS linux-4.7.5-x86_64: WARNINGS linux-4.8-x86_64: OK linux-4.9-x86_64: OK linux-4.10-rc3-x86_64: OK apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 20/24] media: imx: Add Camera Interface subdev driver
On 01/20/2017 06:38 AM, Hans Verkuil wrote:
On 01/07/2017 03:11 AM, Steve Longerbeam wrote:
+static int vidioc_querycap(struct file *file, void *fh,
+ struct v4l2_capability *cap)
+{
+ strncpy(cap->driver, "imx-media-camif", sizeof(cap->driver) - 1);
+ strncpy(cap->card, "imx-media-camif", sizeof(cap->card) - 1);
+ cap->bus_info[0] = 0;
Should be set to something like 'platform:imx-media-camif'. v4l2-compliance
should
complain about this.
Right, I've fixed this already as part of v4l2-compliance testing.
+ cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING;
+ cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
Set device_caps in struct video_device, then drop these two lines since
the core will set these up based on the device_caps field in struct
video_device.
done.
+
+static int camif_enum_input(struct file *file, void *fh,
+ struct v4l2_input *input)
+{
+ struct camif_priv *priv = video_drvdata(file);
+ struct imx_media_subdev *sensor;
+ int index = input->index;
+
+ sensor = imx_media_find_sensor(priv->md, &priv->sd.entity);
+ if (IS_ERR(sensor)) {
+ v4l2_err(&priv->sd, "no sensor attached\n");
+ return PTR_ERR(sensor);
+ }
+
+ if (index >= sensor->input.num)
+ return -EINVAL;
+
+ input->type = V4L2_INPUT_TYPE_CAMERA;
+ strncpy(input->name, sensor->input.name[index], sizeof(input->name));
+
+ if (index == priv->current_input) {
+ v4l2_subdev_call(sensor->sd, video, g_input_status,
+&input->status);
+ v4l2_subdev_call(sensor->sd, video, querystd, &input->std);
Wrong op, use g_tvnorms instead.
done.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/24] media: Add i.MX media core driver
On 01/23/2017 05:38 PM, Steve Longerbeam wrote: Second, ignoring the above locking issue for a moment, v4l2_pipeline_pm_use() will call s_power on the sensor _first_, then the mipi csi-2 s_power, when executing media-ctl -l '"ov5640 1-003c":0 -> "imx6-mipi-csi2":0[1]'. Which is the wrong order. In my version which enforces the correct power on order, the mipi csi-2 s_power is called first in that link setup, followed by the sensor. I don't understand why you want to power up subdevs as soon as the links are established. Because that is the precedence, all other media drivers do pipeline power on/off at link_notify. And v4l2_pipeline_link_notify() was written as a link_notify method. Shouldn't that rather be done for all subdevices in the pipeline when the corresponding capture device is opened? that won't work. There's no guarantee the links will be established at capture device open time. ugh, maybe v4l2_pipeline_pm_use() would work at open/release. If there are no links yet, it would basically be a no-op. And stream on requires opening the device, and the pipeline links should be established by then, so this might be fine, looking into this too. Steve It seems to me that powering up the pipeline should be the last step before userspace actually starts the capture. Well, I'm ok with moving pipeline power on/off to start/stop streaming. I would actually prefer to do it then, I only chose at link_notify because of precedence. I'll look into it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/24] media: Add i.MX media core driver
On 01/23/2017 03:13 AM, Philipp Zabel wrote: Hi Steve, On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote: On 01/16/2017 05:47 AM, Philipp Zabel wrote: On Sat, 2017-01-14 at 14:46 -0800, Steve Longerbeam wrote: [...] +Unprocessed Video Capture: +-- + +Send frames directly from sensor to camera interface, with no +conversions: + +-> ipu_smfc -> camif I'd call this capture interface, this is not just for cameras. Or maybe idmac if you want to mirror hardware names? Camif is so named because it is the V4L2 user interface for video capture. I suppose it could be named "capif", but that doesn't role off the tongue quite as well. Agreed, capif sounds weird. I find camif a bit confusing though, because Samsung S3C has a camera interface that is actually called "CAMIF". how about simply "capture" ? That sounds good to me. done. This should really be handled by v4l2_pipeline_pm_use. I thought about this earlier, but v4l2_pipeline_pm_use() seems to be doing some other stuff that bothered me, at least that's what I remember. I will revisit this. I have used it with a tc358743 -> mipi-csi2 pipeline, it didn't cause any problems. It would be better to reuse and, if necessary, fix the existing infrastructure where available. I tried this API, by switching to v4l2_pipeline_pm_use() in camif open/release, and switched to v4l2_pipeline_link_notify() instead of imx_media_link_notify() in the media driver's media_device_ops. This API assumes the video device has an open file handle while the media links are being established. This doesn't work for me, I want to be able to establish the links using 'media-ctl -l', and that won't work unless there is an open file handle on the video capture device node. Also, I looked into calling v4l2_pipeline_pm_use() during imx_media_link_notify(), instead of imx_media_pipeline_set_power(). Again there are problems with that. First, v4l2_pipeline_pm_use() acquires the graph mutex, so it can't be called inside link_notify which already acquires that lock. The header for this function also clearly states it should only be called in open/release. So why not call it in open/release then? er, see above (?) Second, ignoring the above locking issue for a moment, v4l2_pipeline_pm_use() will call s_power on the sensor _first_, then the mipi csi-2 s_power, when executing media-ctl -l '"ov5640 1-003c":0 -> "imx6-mipi-csi2":0[1]'. Which is the wrong order. In my version which enforces the correct power on order, the mipi csi-2 s_power is called first in that link setup, followed by the sensor. I don't understand why you want to power up subdevs as soon as the links are established. Because that is the precedence, all other media drivers do pipeline power on/off at link_notify. And v4l2_pipeline_link_notify() was written as a link_notify method. Shouldn't that rather be done for all subdevices in the pipeline when the corresponding capture device is opened? that won't work. There's no guarantee the links will be established at capture device open time. It seems to me that powering up the pipeline should be the last step before userspace actually starts the capture. Well, I'm ok with moving pipeline power on/off to start/stop streaming. I would actually prefer to do it then, I only chose at link_notify because of precedence. I'll look into it. Steve -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mysterious regression in dvb driver
Just use the driver from the media_build tree and do a git bisect on it. You can work out a bisect starting/good point from whatever kernel version you know to be working. It shouldn't take too long to find the offending commit. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/24] i.MX Media Driver
On 01/23/2017 03:00 AM, Philipp Zabel wrote:
On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
[...]
There is a VDIC entity in the i.MX IPU that performs de-interlacing with
hardware filters for motion compensation. Some of the motion compensation
modes ("low" and "medium" motion) require that the VDIC receive video
frame fields from memory buffers (dedicated dma channels in the
IPU are used to transfer those buffers into the VDIC).
So one option to support those modes would be to pass the raw buffers
from a camera sensor up to userspace to a capture device, and then pass
them back to the VDIC for de-interlacing using a mem2mem device.
Philipp and I are both in agreement that, since userland is not interested
in the intermediate interlaced buffers in this case, but only the final
result (motion compensated, de-interlaced frames), it is more efficient
to provide a media link that allows passing those intermediate frames
directly from a camera source pad to VDIC sink pad, without having
to route them through userspace.
So in order to support that, I've implemented a simple FIFO dma buffer
queue in the driver to allow passing video buffers directly from a source
to a sink. It is modeled loosely off the vb2 state machine and API, but
simpler (for instance it only allows contiguous, cache-coherent buffers).
This is where Philipp has an argument, that this should be done with a
new API in videobuf2.
That is one part of the argument. I'm glad to understand now that we
agree about this.
And I'm actually in total agreement with that. I definitely agree that there
should be a mechanism in the media framework that allows passing video
buffers from a source pad to a sink pad using a software queue, with no
involvement from userland.
That is the other part of the argument. I do not agree that these
software queue "links" should be presented to userspace as media pad
links between two entities of a media device.
First, that would limit the links to subdevices contained in the same
media graph, while this should work between any two capture and output
queues of different devices.
It sounds like we are talking about two different new proposed features.
My proposal is to implement a software buffer queue between pads.
Beyond enabling the link between pads using the existing media controller
API, userspace is not involved after that. The fact that this link is
accomplished
with a software buffer queue is not known, and doesn't need to be known,
by userspace.
Your proposal, if I have it right, is to allow linking two v4l2 device
vb2 queues
(i.e. /dev/videoX -> /dev/videoY), using a new user level API, in a free-run
mode such that v4l2 buffers get passed from one device's vb2 queue to the
other without requiring the v4l2 user program to actively forward those
buffers.
There isn't anything that would preclude one from the other, they can
both exist. But they are different ideas. One implements software queues
at the _pad level_ and is opaque to userspace, the other links queues
at the _device level_ using a new user API, but once the link is
established,
also does not require any involvement from userspace.
What I'm saying is we can do _both_.
Assume for example, we want to encode the captured, deinterlaced video
to h.264 with the coda VPU driver. A software queue link could be
established between the CSI capture and the VDIC deinterlacer input,
That's already available in the media graph. By linking CSI and
VDIC entities. The capture device will then already be providing
de-interlaced video, and ...
just as between the VDIC deinterlacer output and the coda VPU input.
Technically, there would be no difference between those two linked
capture/output queue pairs. But the coda driver is a completely separate
mem2mem device. And since it is not part of the i.MX media graph, there
is no entity pad to link to.
your free-run queue linking could then be used to link the (already)
de-interlaced stream to the coda device for h.264 encode.
The other idea would be to eventually make the coda device part of
the media graph as an entity. Then this link would instead be via pads.
Or assume there is an USB analog capture device that produces interlaced
frames. I think it should be possible to connect its capture queue to
the VDIC deinterlacer output queue just the same way as linking the CSI
to the VDIC (in software queue mode).
Right, for devices that are outside the i.MX media graph, such as a USB
capture device (or coda), access to the i.MX entities such as the VDIC would
require an i.MX mem2mem device with media links to the VDIC. The USB
capture device would forward its captured frames to mem2mem (maybe
using your free-run vb2 queue linking idea):
usb device -> i.mx mem2mem device -> VDIC entity -> i.mx mem2mem device
Second, the subdevice pad formats describe wire formats, not memory
formats. The user might want to choose between 4:2:2 and 4:2:0
subsampled YUV formats for the intermedia
Re: Mysterious regression in dvb driver
On Mon, Jan 23, 2017 at 12:21:35PM +, Dreamcat4 wrote: > Hi again, > > Installed Antergos (arch) linux today, and its still same issues. That > is with an even newer 4.8 kernel. No HD channels, I2C error in dmesg, > CRC error during w_scan tuning. (when its tuning the HD channels). > > So I'm hesitant to report it as a bug under ubuntu bug reporter. Since > its not just limited to debian-based distros. > > My main question is whats actually all the files on the disk / > filesystem that are involved? If not in the kernel. Then I could go > back and grab them all from ubuntu 14.04 (works), to try in 14.10 > (time of first breakage). Replacing one file at a time. > > Wheras... if it is in the kernel then what else was added later on > that broke this? And why is the newer 4.2 updated kernel in the old > 14.04 (+.3) still working then? Just doesn't add up / make sense to > me. > > I would be very grateful if anyone here could please shed some more > light on the matter. If it is a cross-distro breakage then probably the kernel bugzilla might be the right place to file an issue. However you should first spend a little time to clarify exactly where the issue is occurring. First, can you find the usb-id or pci-id for the device, as well as the marketing name. It's important for others to be able to identify the device unambiguously. dmesg from a working kernel should show this. Once you have that, run lspci -vvv or lsusb -v for that device and save the output. Next I suggest making a list of the kernels you have tried and whether the device is working or not with that kernel. You want the most detailed version number you can find, from the kernel package name or changelog. The release date for the packages would probably be helpful too. Then you should look for the latest working and earliest non-working version. Since you are using distro kernels, which will have many differences from the one published by kernel.org, it may be worth trying to find the git repository and the git tag that matches the kernels on either side of the break. This will allow easy diffing of the code. The changelog for the kernel package should have dates and perhaps even git commit ids that will help with that quest. If you get stuck on this just post your results so far, someone may be able to help. It might also be useful to capture dmesg logs for those two (working/ nonworking) versions so you can look for the place where things go awry. HTH Vince -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] exynos4-is: Add missing 'of_node_put'
It is likely that a "of_node_put(ep)" is missing here.
There is one in the previous error handling code, and one a few lines
below in the normal case as well.
Signed-off-by: Christophe JAILLET
---
drivers/media/platform/exynos4-is/media-dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index e3a8709138fa..da5b76c1df98 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -402,8 +402,10 @@ static int fimc_md_parse_port_node(struct fimc_md *fmd,
return ret;
}
- if (WARN_ON(endpoint.base.port == 0) || index >= FIMC_MAX_SENSORS)
+ if (WARN_ON(endpoint.base.port == 0) || index >= FIMC_MAX_SENSORS) {
+ of_node_put(ep);
return -EINVAL;
+ }
pd->mux_id = (endpoint.base.port - 1) & 0x1;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 4/5] exynos4.dtsi: add HDMI controller phandle
On Mon, Jan 23, 2017 at 11:23:36AM +0100, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Update the bindings documenting the new hdmi phandle and
> update exynos4.dtsi accordingly. This phandle is needed by the
> s5p-cec driver to initialize the HPD notifier framework.
>
> Tested with my Odroid U3.
>
> Signed-off-by: Hans Verkuil
> Tested-by: Marek Szyprowski
> CC: linux-samsung-...@vger.kernel.org
> ---
> Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
> arch/arm/boot/dts/exynos4.dtsi | 1 +
> 2 files changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
> b/Documentation/devicetree/bindings/media/s5p-cec.txt
> index 925ab4d72eaa..710fc005150c 100644
> --- a/Documentation/devicetree/bindings/media/s5p-cec.txt
> +++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
> @@ -15,6 +15,7 @@ Required properties:
>- clock-names : from common clock binding: must contain "hdmicec",
> corresponding to entry in the clocks property.
>- samsung,syscon-phandle - phandle to the PMU system controller
> + - samsung,hdmi-phandle - phandle to the HDMI controller
>
> Example:
>
> @@ -25,6 +26,7 @@ hdmicec: cec@100B {
> clocks = <&clock CLK_HDMI_CEC>;
> clock-names = "hdmicec";
> samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
> pinctrl-names = "default";
> pinctrl-0 = <&hdmi_cec>;
> status = "okay";
The bindings description can be a separate patch (often welcomed) but
does not have to. It may be squashed with driver changes. But not with
DTS changes because DTS should go through samsung-soc tree (alone). The
bindings description usually go through subsystem maintainer.
When sending the bindings description, please Cc at least
devicet...@vger.kernel.org as mentioned by get_maintainers. It is
welcomed to Cc also DT maintainers (Rob & Mark) although with simple
bindings extension I think it is not a necessity.
Anyway please split this and name the subject (git log --oneline
arch/arm/boot/dts/exynos*: "ARM: dts: exynos: Foo Bar").
Best regards,
Krzysztof
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index c64737baa45e..51dfcbb51b6b 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -762,6 +762,7 @@
> clocks = <&clock CLK_HDMI_CEC>;
> clock-names = "hdmicec";
> samsung,syscon-phandle = <&pmu_system_controller>;
> + samsung,hdmi-phandle = <&hdmi>;
> pinctrl-names = "default";
> pinctrl-0 = <&hdmi_cec>;
> status = "disabled";
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.11] Samsung SoC related updates
Hi Mauro, It's just a few clean up and one fix patch this time. The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a: [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v4.11/media/next for you to fetch changes up to d922b4028d8176cb8072a391a2f623a51ded52cd: exynos4-is: constify v4l2_subdev_* structures (2017-01-23 13:51:50 +0100) Arvind Yadav (1): exynos4-is: fimc-is: Unmap region obtained by of_iomap() Bhumika Goyal (1): exynos4-is: constify v4l2_subdev_* structures Javier Martinez Canillas (1): exynos-gsc: Fix unbalanced pm_runtime_enable() error Shailendra Verma (2): exynos4-is: Clean up file handle in open() error path exynos-gsc: Clean up file handle in open() error path drivers/media/platform/exynos-gsc/gsc-core.c | 1 + drivers/media/platform/exynos-gsc/gsc-m2m.c | 2 +- drivers/media/platform/exynos4-is/fimc-capture.c | 4 ++-- drivers/media/platform/exynos4-is/fimc-is.c | 8 ++-- drivers/media/platform/exynos4-is/fimc-m2m.c | 2 +- drivers/media/platform/exynos4-is/mipi-csis.c| 8 6 files changed, 15 insertions(+), 10 deletions(-) -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Urgent Please,,
Good Day Dear, My name is Ms. Joyes Dadi, I am glad you are reading this letter and I hope we will start our communication and I know that this message will look strange, surprising and probably unbelievable to you, but it is the reality. I want to make a donation of money to you. I contact you by the will of God. I am a firm German woman specialized in mining gold and diamonds in Africa. But now, I'm very sick of a cancer. My husband died in an accident two years ago with our two children and now I have cancer of the esophagus that damaged almost all the cells in my system/agencies and I'll die soon according to my doctor. My most concern now is, we grew up in the orphanage and were married in orphanage. If I die this deposited fund will soon be left alone in the hand of the bank, and I do want to it that way. Please, if you can be reliable and sincere to accept my humble proposal; I have (10.5Millions Euro) in a fixed deposit account; I will order the Bank to transfer the money into your account in your country immediately, and then you will take the fund to your country and invest it to the orphanage homes Please, answer as quickly as possible. God bless you. Ms. Joyes Dadi Email: joyesdadi...@citromail.hu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Mysterious regression in dvb driver
Hi again, Installed Antergos (arch) linux today, and its still same issues. That is with an even newer 4.8 kernel. No HD channels, I2C error in dmesg, CRC error during w_scan tuning. (when its tuning the HD channels). So I'm hesitant to report it as a bug under ubuntu bug reporter. Since its not just limited to debian-based distros. My main question is whats actually all the files on the disk / filesystem that are involved? If not in the kernel. Then I could go back and grab them all from ubuntu 14.04 (works), to try in 14.10 (time of first breakage). Replacing one file at a time. Wheras... if it is in the kernel then what else was added later on that broke this? And why is the newer 4.2 updated kernel in the old 14.04 (+.3) still working then? Just doesn't add up / make sense to me. I would be very grateful if anyone here could please shed some more light on the matter. Kind Regards On Fri, Jan 20, 2017 at 9:45 PM, Dreamcat4 wrote: > Hi there, > > Apologies if no-one wants to hear about this. But there was a patch > submitted in 3.17 for geniatech t220 / august dvb-t210 v1. And it > seems to have stopped working for some reason. (yet the patch code is > still there. I reached out to the birthplace / author of the patch, > but unfortunately its been a while, moved on to new hardware, and they > couldn't help. > > So whats the problem? > > Patch added support for scanning HD Channels (dvb-t2) for this > hardware. e.g. with w_scan program. This aspect: > > Works in ubuntu 14.04.3 (fully updated kernel etc). > > Not works anymore in any versions after that (e.g. 14.10, up to and > including latest 16.04). > > I also tried a recent version of debian too, didn't work on debian either. > > ... mostly confused because all of them have similar modern kernel > now, including 14.04.3 too (which still works properly). Don't know > where to head next. Any ideas? > > > Link to more details: > > https://tvheadend.org/boards/5/topics/10864?r=23758#message-23758 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 16/24] media: Add i.MX media core driver
Hi Steve,
On Sun, 2017-01-22 at 18:31 -0800, Steve Longerbeam wrote:
>
> On 01/16/2017 05:47 AM, Philipp Zabel wrote:
> > On Sat, 2017-01-14 at 14:46 -0800, Steve Longerbeam wrote:
> > [...]
> +Unprocessed Video Capture:
> +--
> +
> +Send frames directly from sensor to camera interface, with no
> +conversions:
> +
> +-> ipu_smfc -> camif
> >>> I'd call this capture interface, this is not just for cameras. Or maybe
> >>> idmac if you want to mirror hardware names?
> >> Camif is so named because it is the V4L2 user interface for video
> >> capture. I suppose it could be named "capif", but that doesn't role
> >> off the tongue quite as well.
> > Agreed, capif sounds weird. I find camif a bit confusing though, because
> > Samsung S3C has a camera interface that is actually called "CAMIF".
>
> how about simply "capture" ?
That sounds good to me.
[...]
> > Chapter 37.4.2.3 "FCW & FCR - Format converter write and read" in the
> > IDMAC chapter states that all internal submodules only work on 8-bit per
> > component formats with four components: YUVA or RGBA.
>
> Right, the "direct" IPU internal (that do not transfer buffers to/from
> memory via IDMAC channels) should only allow the IPU internal
> formats YUVA and RGBA. I get you now.
>
> The "direct" pads now only accept MEDIA_BUS_FMT_AYUV8_1X32 and
> MEDIA_BUS_FMT_ARGB_1X32.
>
> Those pads are:
>
> ipu_csi:1
> ipu_vdic:1
> ipu_ic_prp:0
> ipu_ic_prp:1
> ipu_ic_prpenc:0
> ipu_ic_prpenc:1
> ipu_ic_prpvf:0
> ipu_ic_prpvf:1
Yes, that is what I meant. The csi:1 can then be extended to support
additional expanded/packed/raw formats for the SMFC->memory path.
> >> There does not appear to be support in the FSU for linking a write channel
> >> to the VDIC read channels (8, 9, 10) according to VDI_SRC_SEL field. There
> >> is support for the direct link from CSI (which I am using), but that's
> >> not an
> >> IDMAC channel link.
> >>
> >> There is a PRP_SRC_SEL field, with linking from IDMAC (SMFC) channels
> >> 0..2 (and 3? it's not clear, and not clear whether this includes channel
> >> 1).
> > As I read it, that is 0 and 2 only, no idea why. But since there are
> > only 2 CSIs, that shouldn't be a problem.
>
> ipu_csi1 is now transferring on IDMAC/SMFC channel 2 (ipu_csi0 still
> at channel 0).
Ok.
> +static const u32 power_off_seq[] = {
> +IMX_MEDIA_GRP_ID_IC_PP,
> +IMX_MEDIA_GRP_ID_IC_PRPVF,
> +IMX_MEDIA_GRP_ID_IC_PRPENC,
> +IMX_MEDIA_GRP_ID_SMFC,
> +IMX_MEDIA_GRP_ID_CSI,
> +IMX_MEDIA_GRP_ID_VIDMUX,
> +IMX_MEDIA_GRP_ID_SENSOR,
> +IMX_MEDIA_GRP_ID_CSI2,
> +};
> >>> This seems somewhat arbitrary. Why is a power sequence needed?
> >> The CSI-2 receiver must be powered up before the sensor, that's the
> >> only requirement IIRC. The others have no s_power requirement. So I
> >> can probably change this to power up in the frontend -> backend order
> >> (IC_PP to sensor). And vice-versa for power off.
> > Yes, I think that should work (see below).
>
> Actually there are problems using this, see below.
[...]
> +EXPORT_SYMBOL_GPL(imx_media_pipeline_set_power);
> >>> This should really be handled by v4l2_pipeline_pm_use.
> >> I thought about this earlier, but v4l2_pipeline_pm_use() seems to be
> >> doing some other stuff that bothered me, at least that's what I remember.
> >> I will revisit this.
> > I have used it with a tc358743 -> mipi-csi2 pipeline, it didn't cause
> > any problems. It would be better to reuse and, if necessary, fix the
> > existing infrastructure where available.
>
> I tried this API, by switching to v4l2_pipeline_pm_use() in camif
> open/release,
> and switched to v4l2_pipeline_link_notify() instead of
> imx_media_link_notify()
> in the media driver's media_device_ops.
>
> This API assumes the video device has an open file handle while the media
> links are being established. This doesn't work for me, I want to be able to
> establish the links using 'media-ctl -l', and that won't work unless
> there is an
> open file handle on the video capture device node.
>
> Also, I looked into calling v4l2_pipeline_pm_use() during
> imx_media_link_notify(),
> instead of imx_media_pipeline_set_power(). Again there are problems with
> that.
>
> First, v4l2_pipeline_pm_use() acquires the graph mutex, so it can't be
> called inside
> link_notify which already acquires that lock. The header for this
> function also
> clearly states it should only be called in open/release.
So why not call it in open/release then?
> Second, ignoring the above locking issue for a moment,
> v4l2_pipeline_pm_use()
> will call s_power on the sensor _first_, then the mipi csi-2 s_power,
> when executing
> media-ctl -l '"ov5640 1-003c":0 -> "imx6-mipi-csi2":0[1]'. Which is the
> wrong order.
> In my version which enforces the correct power on order, the mipi csi-2
> s_power
> is call
Re: [PATCH v3 00/24] i.MX Media Driver
On 01/23/2017 12:00 PM, Philipp Zabel wrote:
> On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
> [...]
>>> There is a VDIC entity in the i.MX IPU that performs de-interlacing with
>>> hardware filters for motion compensation. Some of the motion compensation
>>> modes ("low" and "medium" motion) require that the VDIC receive video
>>> frame fields from memory buffers (dedicated dma channels in the
>>> IPU are used to transfer those buffers into the VDIC).
>>>
>>> So one option to support those modes would be to pass the raw buffers
>>> from a camera sensor up to userspace to a capture device, and then pass
>>> them back to the VDIC for de-interlacing using a mem2mem device.
>>>
>>> Philipp and I are both in agreement that, since userland is not interested
>>> in the intermediate interlaced buffers in this case, but only the final
>>> result (motion compensated, de-interlaced frames), it is more efficient
>>> to provide a media link that allows passing those intermediate frames
>>> directly from a camera source pad to VDIC sink pad, without having
>>> to route them through userspace.
>>>
>>> So in order to support that, I've implemented a simple FIFO dma buffer
>>> queue in the driver to allow passing video buffers directly from a source
>>> to a sink. It is modeled loosely off the vb2 state machine and API, but
>>> simpler (for instance it only allows contiguous, cache-coherent buffers).
>>>
>>> This is where Philipp has an argument, that this should be done with a
>>> new API in videobuf2.
>
> That is one part of the argument. I'm glad to understand now that we
> agree about this.
>
>>> And I'm actually in total agreement with that. I definitely agree that there
>>> should be a mechanism in the media framework that allows passing video
>>> buffers from a source pad to a sink pad using a software queue, with no
>>> involvement from userland.
>
> That is the other part of the argument. I do not agree that these
> software queue "links" should be presented to userspace as media pad
> links between two entities of a media device.
>
> First, that would limit the links to subdevices contained in the same
> media graph, while this should work between any two capture and output
> queues of different devices.
> Assume for example, we want to encode the captured, deinterlaced video
> to h.264 with the coda VPU driver. A software queue link could be
> established between the CSI capture and the VDIC deinterlacer input,
> just as between the VDIC deinterlacer output and the coda VPU input.
> Technically, there would be no difference between those two linked
> capture/output queue pairs. But the coda driver is a completely separate
> mem2mem device. And since it is not part of the i.MX media graph, there
> is no entity pad to link to.
> Or assume there is an USB analog capture device that produces interlaced
> frames. I think it should be possible to connect its capture queue to
> the VDIC deinterlacer output queue just the same way as linking the CSI
> to the VDIC (in software queue mode).
>
> Second, the subdevice pad formats describe wire formats, not memory
> formats. The user might want to choose between 4:2:2 and 4:2:0
> subsampled YUV formats for the intermediate buffer, for example,
> depending on memory bandwidth constraints and quality requirements. This
> is impossible with the media entity / subdevice pad links.
>
> I think an interface where userspace configures the capture and output
> queues via v4l2 API, passes dma buffers around from one to the other
> queue, and then puts both queues into a free running mode would be a
> much better fit for this mechanism.
>
>>> My only disagreement is when this should be implemented. I think it is
>>> fine to keep my custom implementation of this in the driver for now. Once
>>> an extension of vb2 is ready to support this feature, it would be fairly
>>> straightforward to strip out my custom implementation and go with the
>>> new API.
>>
>> For a staging driver this isn't necessary, as long as it is documented in
>> the TODO file that this needs to be fixed before it can be moved out of
>> staging. The whole point of staging is that there is still work to be
>> done in the driver, after all :-)
>
> Absolutely. The reason I am arguing against merging the mem2mem media
> control links so vehemently is that I am convinced the userspace
> interface is wrong, and I am afraid that even though in staging, it
> might become established.
As long as it is mentioned in the TODO, and ideally in the Kconfig as well,
then I'm fine with it.
The big advantage of being in the kernel is that it is much easier to start
providing fixes, improvements, etc. If you use a staging driver you know
that there is no guarantee whatsoever with respect to stable ABI/APIs.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-i
Re: [PATCH v3 00/24] i.MX Media Driver
On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote:
[...]
> > There is a VDIC entity in the i.MX IPU that performs de-interlacing with
> > hardware filters for motion compensation. Some of the motion compensation
> > modes ("low" and "medium" motion) require that the VDIC receive video
> > frame fields from memory buffers (dedicated dma channels in the
> > IPU are used to transfer those buffers into the VDIC).
> >
> > So one option to support those modes would be to pass the raw buffers
> > from a camera sensor up to userspace to a capture device, and then pass
> > them back to the VDIC for de-interlacing using a mem2mem device.
> >
> > Philipp and I are both in agreement that, since userland is not interested
> > in the intermediate interlaced buffers in this case, but only the final
> > result (motion compensated, de-interlaced frames), it is more efficient
> > to provide a media link that allows passing those intermediate frames
> > directly from a camera source pad to VDIC sink pad, without having
> > to route them through userspace.
> >
> > So in order to support that, I've implemented a simple FIFO dma buffer
> > queue in the driver to allow passing video buffers directly from a source
> > to a sink. It is modeled loosely off the vb2 state machine and API, but
> > simpler (for instance it only allows contiguous, cache-coherent buffers).
> >
> > This is where Philipp has an argument, that this should be done with a
> > new API in videobuf2.
That is one part of the argument. I'm glad to understand now that we
agree about this.
> > And I'm actually in total agreement with that. I definitely agree that there
> > should be a mechanism in the media framework that allows passing video
> > buffers from a source pad to a sink pad using a software queue, with no
> > involvement from userland.
That is the other part of the argument. I do not agree that these
software queue "links" should be presented to userspace as media pad
links between two entities of a media device.
First, that would limit the links to subdevices contained in the same
media graph, while this should work between any two capture and output
queues of different devices.
Assume for example, we want to encode the captured, deinterlaced video
to h.264 with the coda VPU driver. A software queue link could be
established between the CSI capture and the VDIC deinterlacer input,
just as between the VDIC deinterlacer output and the coda VPU input.
Technically, there would be no difference between those two linked
capture/output queue pairs. But the coda driver is a completely separate
mem2mem device. And since it is not part of the i.MX media graph, there
is no entity pad to link to.
Or assume there is an USB analog capture device that produces interlaced
frames. I think it should be possible to connect its capture queue to
the VDIC deinterlacer output queue just the same way as linking the CSI
to the VDIC (in software queue mode).
Second, the subdevice pad formats describe wire formats, not memory
formats. The user might want to choose between 4:2:2 and 4:2:0
subsampled YUV formats for the intermediate buffer, for example,
depending on memory bandwidth constraints and quality requirements. This
is impossible with the media entity / subdevice pad links.
I think an interface where userspace configures the capture and output
queues via v4l2 API, passes dma buffers around from one to the other
queue, and then puts both queues into a free running mode would be a
much better fit for this mechanism.
> > My only disagreement is when this should be implemented. I think it is
> > fine to keep my custom implementation of this in the driver for now. Once
> > an extension of vb2 is ready to support this feature, it would be fairly
> > straightforward to strip out my custom implementation and go with the
> > new API.
>
> For a staging driver this isn't necessary, as long as it is documented in
> the TODO file that this needs to be fixed before it can be moved out of
> staging. The whole point of staging is that there is still work to be
> done in the driver, after all :-)
Absolutely. The reason I am arguing against merging the mem2mem media
control links so vehemently is that I am convinced the userspace
interface is wrong, and I am afraid that even though in staging, it
might become established.
regards
Philipp
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 5/5] s5p-cec: add hpd-notifier support, move out of staging
From: Hans Verkuil
By using the HPD notifier framework there is no longer any reason
to manually set the physical address. This was the one blocking
issue that prevented this driver from going out of staging, so do
this move as well.
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
CC: linux-samsung-...@vger.kernel.org
---
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 ++
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 ++
drivers/staging/media/Kconfig | 2 --
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 -
12 files changed, 52 insertions(+), 24 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..0d7acf10b32a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -392,6 +392,24 @@ config VIDEO_TI_SC
config VIDEO_TI_CSC
tristate
+menuconfig V4L_CEC_DRIVERS
+ bool "Platform HDMI CEC drivers"
+ depends on MEDIA_CEC_SUPPORT
+
+if V4L_CEC_DRIVERS
+
+config VIDEO_SAMSUNG_S5P_CEC
+ tristate "Samsung S5P CEC driver"
+ depends on VIDEO_DEV && MEDIA_CEC_SUPPORT && (PLAT_S5P || ARCH_EXYNOS
|| COMPILE_TEST)
+ select HPD_NOTIFIER
+ ---help---
+ This is a driver for Samsung S5P HDMI CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
+endif #V4L_CEC_DRIVERS
+
menuconfig V4L_TEST_DRIVERS
bool "Media test drivers"
depends on MEDIA_CAMERA_SUPPORT
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 5b3cb271d2b8..ad3bf22bfeae 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -33,6 +33,7 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_JPEG) += s5p-jpeg/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC)+= s5p-mfc/
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D)+= s5p-g2d/
+obj-$(CONFIG_VIDEO_SAMSUNG_S5P_CEC)+= s5p-cec/
obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/
obj-$(CONFIG_VIDEO_STI_BDISP) += sti/bdisp/
diff --git a/drivers/staging/media/s5p-cec/Makefile
b/drivers/media/platform/s5p-cec/Makefile
similarity index 100%
rename from drivers/staging/media/s5p-cec/Makefile
rename to drivers/media/platform/s5p-cec/Makefile
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
b/drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cec.h
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cec.h
diff --git a/drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
b/drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
similarity index 100%
rename from drivers/staging/media/s5p-cec/exynos_hdmi_cecctrl.c
rename to drivers/media/platform/s5p-cec/exynos_hdmi_cecctrl.c
diff --git a/drivers/staging/media/s5p-cec/regs-cec.h
b/drivers/media/platform/s5p-cec/regs-cec.h
similarity index 100%
rename from drivers/staging/media/s5p-cec/regs-cec.h
rename to drivers/media/platform/s5p-cec/regs-cec.h
diff --git a/drivers/staging/media/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
similarity index 89%
rename from drivers/staging/media/s5p-cec/s5p_cec.c
rename to drivers/media/platform/s5p-cec/s5p_cec.c
index 2a07968b5ac6..2014f792eceb 100644
--- a/drivers/staging/media/s5p-cec/s5p_cec.c
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -14,15 +14,18 @@
*/
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
+#include
#include
#include "exynos_hdmi_cec.h"
@@ -167,10 +170,22 @@ static const struct cec_adap_ops s5p_cec_adap_ops = {
static int s5p_cec_probe(struct platform
[PATCHv3 3/5] cec: integrate HPD notifier support
From: Hans Verkuil
Support the HPD notifier framework, simplifying drivers that
depend on this.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/media/cec/cec-core.c | 50
include/media/cec.h | 15 +
2 files changed, 65 insertions(+)
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index aca3ab83a8a1..dd2c4a17aff5 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -195,6 +195,52 @@ static void cec_devnode_unregister(struct cec_devnode
*devnode)
put_device(&devnode->dev);
}
+#ifdef CONFIG_HPD_NOTIFIER
+static u16 parse_hdmi_addr(const struct edid *edid)
+{
+ if (!edid || edid->extensions == 0)
+ return CEC_PHYS_ADDR_INVALID;
+
+ return cec_get_edid_phys_addr((u8 *)edid,
+ EDID_LENGTH * (edid->extensions + 1), NULL);
+}
+
+static int cec_hpd_notify(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct cec_adapter *adap = container_of(nb, struct cec_adapter, nb);
+ struct hpd_notifier *n = data;
+ unsigned int phys;
+
+ dprintk(1, "event %lu\n", event);
+
+ switch (event) {
+ case HPD_DISCONNECTED:
+ cec_s_phys_addr(adap, CEC_PHYS_ADDR_INVALID, false);
+ break;
+
+ case HPD_NEW_EDID:
+ phys = parse_hdmi_addr(n->edid);
+ cec_s_phys_addr(adap, phys, false);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier)
+{
+ if (WARN_ON(!adap->devnode.registered))
+ return;
+
+ adap->nb.notifier_call = cec_hpd_notify;
+ adap->notifier = notifier;
+ hpd_notifier_register(adap->notifier, &adap->nb);
+}
+EXPORT_SYMBOL_GPL(cec_register_hpd_notifier);
+#endif
+
struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops,
void *priv, const char *name, u32 caps,
u8 available_las)
@@ -344,6 +390,10 @@ void cec_unregister_adapter(struct cec_adapter *adap)
adap->rc = NULL;
#endif
debugfs_remove_recursive(adap->cec_dir);
+#ifdef CONFIG_HPD_NOTIFIER
+ if (adap->notifier)
+ hpd_notifier_unregister(adap->notifier, &adap->nb);
+#endif
cec_devnode_unregister(&adap->devnode);
}
EXPORT_SYMBOL_GPL(cec_unregister_adapter);
diff --git a/include/media/cec.h b/include/media/cec.h
index 96a0aa770d61..f87a07ee36b3 100644
--- a/include/media/cec.h
+++ b/include/media/cec.h
@@ -28,6 +28,11 @@
#include
#include
#include
+#ifdef CONFIG_HPD_NOTIFIER
+#include
+#include
+#include
+#endif
#include
#include
@@ -173,6 +178,11 @@ struct cec_adapter {
bool passthrough;
struct cec_log_addrs log_addrs;
+#ifdef CONFIG_HPD_NOTIFIER
+ struct hpd_notifier *notifier;
+ struct notifier_block nb;
+#endif
+
struct dentry *cec_dir;
struct dentry *status_file;
@@ -213,6 +223,11 @@ void cec_transmit_done(struct cec_adapter *adap, u8
status, u8 arb_lost_cnt,
u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt);
void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg);
+#ifdef CONFIG_HPD_NOTIFIER
+void cec_register_hpd_notifier(struct cec_adapter *adap,
+ struct hpd_notifier *notifier);
+#endif
+
#else
static inline int cec_register_adapter(struct cec_adapter *adap,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 4/5] exynos4.dtsi: add HDMI controller phandle
From: Hans Verkuil
Update the bindings documenting the new hdmi phandle and
update exynos4.dtsi accordingly. This phandle is needed by the
s5p-cec driver to initialize the HPD notifier framework.
Tested with my Odroid U3.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
CC: linux-samsung-...@vger.kernel.org
---
Documentation/devicetree/bindings/media/s5p-cec.txt | 2 ++
arch/arm/boot/dts/exynos4.dtsi | 1 +
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/s5p-cec.txt
b/Documentation/devicetree/bindings/media/s5p-cec.txt
index 925ab4d72eaa..710fc005150c 100644
--- a/Documentation/devicetree/bindings/media/s5p-cec.txt
+++ b/Documentation/devicetree/bindings/media/s5p-cec.txt
@@ -15,6 +15,7 @@ Required properties:
- clock-names : from common clock binding: must contain "hdmicec",
corresponding to entry in the clocks property.
- samsung,syscon-phandle - phandle to the PMU system controller
+ - samsung,hdmi-phandle - phandle to the HDMI controller
Example:
@@ -25,6 +26,7 @@ hdmicec: cec@100B {
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "okay";
diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
index c64737baa45e..51dfcbb51b6b 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -762,6 +762,7 @@
clocks = <&clock CLK_HDMI_CEC>;
clock-names = "hdmicec";
samsung,syscon-phandle = <&pmu_system_controller>;
+ samsung,hdmi-phandle = <&hdmi>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_cec>;
status = "disabled";
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 2/5] exynos_hdmi: add HPD notifier support
From: Hans Verkuil
Implement the HPD notifier support to allow CEC drivers to
be informed when there is a new EDID and when a connect or
disconnect happens.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index d706ca4e2f02..50309409d450 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -77,6 +77,7 @@ config DRM_EXYNOS_DP
config DRM_EXYNOS_HDMI
bool "HDMI"
depends on DRM_EXYNOS_MIXER || DRM_EXYNOS5433_DECON
+ select HPD_NOTIFIER
help
Choose this option if you want to use Exynos HDMI for DRM.
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1effe71..8d48a0a21565 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -118,6 +119,7 @@ struct hdmi_context {
booldvi_mode;
struct delayed_work hotplug_work;
struct drm_display_mode current_mode;
+ struct hpd_notifier *notifier;
const struct hdmi_driver_data *drv_data;
void __iomem*regs;
@@ -807,9 +809,12 @@ static enum drm_connector_status hdmi_detect(struct
drm_connector *connector,
{
struct hdmi_context *hdata = connector_to_hdmi(connector);
- if (gpiod_get_value(hdata->hpd_gpio))
+ if (gpiod_get_value(hdata->hpd_gpio)) {
+ hpd_event_connect(hdata->notifier);
return connector_status_connected;
+ }
+ hpd_event_disconnect(hdata->notifier);
return connector_status_disconnected;
}
@@ -848,6 +853,8 @@ static int hdmi_get_modes(struct drm_connector *connector)
edid->width_cm, edid->height_cm);
drm_mode_connector_update_edid_property(connector, edid);
+ hpd_event_new_edid(hdata->notifier, edid,
+ EDID_LENGTH * (1 + edid->extensions));
ret = drm_add_edid_modes(connector, edid);
@@ -1483,6 +1490,7 @@ static void hdmi_disable(struct drm_encoder *encoder)
if (funcs && funcs->disable)
(*funcs->disable)(crtc);
+ hpd_event_disconnect(hdata->notifier);
cancel_delayed_work(&hdata->hotplug_work);
hdmiphy_disable(hdata);
@@ -1832,15 +1840,22 @@ static int hdmi_probe(struct platform_device *pdev)
}
}
+ hdata->notifier = hpd_notifier_get(&pdev->dev);
+ if (hdata->notifier == NULL) {
+ ret = -ENOMEM;
+ goto err_hdmiphy;
+ }
+
pm_runtime_enable(dev);
ret = component_add(&pdev->dev, &hdmi_component_ops);
if (ret)
- goto err_disable_pm_runtime;
+ goto err_notifier_put;
return ret;
-err_disable_pm_runtime:
+err_notifier_put:
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(dev);
err_hdmiphy:
@@ -1859,9 +1874,11 @@ static int hdmi_remove(struct platform_device *pdev)
struct hdmi_context *hdata = platform_get_drvdata(pdev);
cancel_delayed_work_sync(&hdata->hotplug_work);
+ hpd_event_disconnect(hdata->notifier);
component_del(&pdev->dev, &hdmi_component_ops);
+ hpd_notifier_put(hdata->notifier);
pm_runtime_disable(&pdev->dev);
if (!IS_ERR(hdata->reg_hdmi_en))
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/5] video/exynos/cec: add HPD state notifier & use in s5p-cec
From: Hans Verkuil
This patch series adds the hotplug detect notifier code, based on Russell's
code:
https://patchwork.kernel.org/patch/9277043/
It adds support for it to the exynos_hdmi drm driver, adds support for
it to the CEC framework and finally adds support to the s5p-cec driver,
which now can be moved out of staging.
Tested with my Odroid U3 exynos4 devboard.
Comments are welcome. I'd like to get this in for the 4.11 kernel as
this is a missing piece needed to integrate CEC drivers.
Changes since v2:
- Split off the dts changes of the s5p-cec patch into a separate patch
- Renamed HPD_NOTIFIERS to HPD_NOTIFIER to be consistent with the name
of the source.
Changes since v1:
Renamed HDMI notifier to HPD (hotplug detect) notifier since this code is
not HDMI specific, but is interesting for any video source that has to
deal with hotplug detect and EDID/ELD (HDMI, DVI, VGA, DP, ).
Only the use with CEC adapters is HDMI specific, but the HPD notifier
is more generic.
Regards,
Hans
Hans Verkuil (5):
video: add hotplug detect notifier support
exynos_hdmi: add HPD notifier support
cec: integrate HPD notifier support
exynos4.dtsi: add HDMI controller phandle
s5p-cec: add hpd-notifier support, move out of staging
.../devicetree/bindings/media/s5p-cec.txt | 2 +
arch/arm/boot/dts/exynos4.dtsi | 1 +
drivers/gpu/drm/exynos/Kconfig | 1 +
drivers/gpu/drm/exynos/exynos_hdmi.c | 23 +++-
drivers/media/cec/cec-core.c | 50
drivers/media/platform/Kconfig | 18 +++
drivers/media/platform/Makefile| 1 +
.../media => media/platform}/s5p-cec/Makefile | 0
.../platform}/s5p-cec/exynos_hdmi_cec.h| 0
.../platform}/s5p-cec/exynos_hdmi_cecctrl.c| 0
.../media => media/platform}/s5p-cec/regs-cec.h| 0
.../media => media/platform}/s5p-cec/s5p_cec.c | 35 +-
.../media => media/platform}/s5p-cec/s5p_cec.h | 3 +
drivers/staging/media/Kconfig | 2 -
drivers/staging/media/Makefile | 1 -
drivers/staging/media/s5p-cec/Kconfig | 9 --
drivers/staging/media/s5p-cec/TODO | 7 --
drivers/video/Kconfig | 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +
include/linux/hpd-notifier.h | 109 +
include/media/cec.h| 15 +++
22 files changed, 388 insertions(+), 27 deletions(-)
rename drivers/{staging/media => media/platform}/s5p-cec/Makefile (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cec.h
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/exynos_hdmi_cecctrl.c
(100%)
rename drivers/{staging/media => media/platform}/s5p-cec/regs-cec.h (100%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.c (89%)
rename drivers/{staging/media => media/platform}/s5p-cec/s5p_cec.h (97%)
delete mode 100644 drivers/staging/media/s5p-cec/Kconfig
delete mode 100644 drivers/staging/media/s5p-cec/TODO
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/5] video: add hotplug detect notifier support
From: Hans Verkuil
Add support for video hotplug detect and EDID/ELD notifiers, which is used
to convey information from video drivers to their CEC and audio counterparts.
Based on an earlier version from Russell King:
https://patchwork.kernel.org/patch/9277043/
The hpd_notifier is a reference counted object containing the HPD/EDID/ELD state
of a video device.
When a new notifier is registered the current state will be reported to
that notifier at registration time.
Signed-off-by: Hans Verkuil
Tested-by: Marek Szyprowski
---
drivers/video/Kconfig| 3 +
drivers/video/Makefile | 1 +
drivers/video/hpd-notifier.c | 134 +++
include/linux/hpd-notifier.h | 109 +++
4 files changed, 247 insertions(+)
create mode 100644 drivers/video/hpd-notifier.c
create mode 100644 include/linux/hpd-notifier.h
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af999893..a3a58d8481e9 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
config HDMI
bool
+config HPD_NOTIFIER
+ bool
+
if VT
source "drivers/video/console/Kconfig"
endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17d6456..2697ae5c4166 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_VGASTATE)+= vgastate.o
obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HPD_NOTIFIER)+= hpd-notifier.o
obj-$(CONFIG_VT) += console/
obj-$(CONFIG_LOGO) += logo/
diff --git a/drivers/video/hpd-notifier.c b/drivers/video/hpd-notifier.c
new file mode 100644
index ..971e823ead00
--- /dev/null
+++ b/drivers/video/hpd-notifier.c
@@ -0,0 +1,134 @@
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(hpd_notifiers);
+static DEFINE_MUTEX(hpd_notifiers_lock);
+
+struct hpd_notifier *hpd_notifier_get(struct device *dev)
+{
+ struct hpd_notifier *n;
+
+ mutex_lock(&hpd_notifiers_lock);
+ list_for_each_entry(n, &hpd_notifiers, head) {
+ if (n->dev == dev) {
+ mutex_unlock(&hpd_notifiers_lock);
+ kref_get(&n->kref);
+ return n;
+ }
+ }
+ n = kzalloc(sizeof(*n), GFP_KERNEL);
+ if (!n)
+ goto unlock;
+ n->dev = dev;
+ mutex_init(&n->lock);
+ BLOCKING_INIT_NOTIFIER_HEAD(&n->notifiers);
+ kref_init(&n->kref);
+ list_add_tail(&n->head, &hpd_notifiers);
+unlock:
+ mutex_unlock(&hpd_notifiers_lock);
+ return n;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_get);
+
+static void hpd_notifier_release(struct kref *kref)
+{
+ struct hpd_notifier *n =
+ container_of(kref, struct hpd_notifier, kref);
+
+ list_del(&n->head);
+ kfree(n->edid);
+ kfree(n);
+}
+
+void hpd_notifier_put(struct hpd_notifier *n)
+{
+ mutex_lock(&hpd_notifiers_lock);
+ kref_put(&n->kref, hpd_notifier_release);
+ mutex_unlock(&hpd_notifiers_lock);
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_put);
+
+int hpd_notifier_register(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_register(&n->notifiers, nb);
+
+ if (ret)
+ return ret;
+ kref_get(&n->kref);
+ mutex_lock(&n->lock);
+ if (n->connected) {
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ if (n->edid_size)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_EDID, n);
+ if (n->has_eld)
+ blocking_notifier_call_chain(&n->notifiers,
HPD_NEW_ELD, n);
+ }
+ mutex_unlock(&n->lock);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_register);
+
+int hpd_notifier_unregister(struct hpd_notifier *n, struct notifier_block *nb)
+{
+ int ret = blocking_notifier_chain_unregister(&n->notifiers, nb);
+
+ if (ret == 0)
+ hpd_notifier_put(n);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(hpd_notifier_unregister);
+
+void hpd_event_connect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = true;
+ blocking_notifier_call_chain(&n->notifiers, HPD_CONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_connect);
+
+void hpd_event_disconnect(struct hpd_notifier *n)
+{
+ mutex_lock(&n->lock);
+ n->connected = false;
+ n->has_eld = false;
+ n->edid_size = 0;
+ blocking_notifier_call_chain(&n->notifiers, HPD_DISCONNECTED, n);
+ mutex_unlock(&n->lock);
+}
+EXPORT_SYMBOL_GPL(hpd_event_disconnect);
+
+int hpd_event_new_edid(struct hpd_notifier *n, const void *edid, size_t size)
+{
+ mutex_lock(&n->lock);
+ if (n->edid_allocated_size < size) {
+ void *p = kmalloc(size, GFP_KERNEL);
+
+
Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging
On 01/04/2017 09:44 AM, Andrzej Hajda wrote: > On 03.01.2017 09:11, Hans Verkuil wrote: >> On 01/03/2017 09:00 AM, Andrzej Hajda wrote: >>> Is there a reason to split registration into two steps? >>> Wouldn't be better to integrate hpd_notifier_get into >>> cec_register_hpd_notifier. >> One problem is that hpd_notifier_get can fail, whereas >> cec_register_hpd_notifier can't. >> And I rather not have to register a CEC device only to unregister it again >> if the >> hpd_notifier_get would fail. > > hpd_notifier_get can fail only due to lack of memory for about 150 bytes > so if it happens whole system will probably fail anyway :) > > >> >> Another reason is that this keeps the responsibility of the hpd_notifier >> life-time >> handling in the driver instead of hiding it in the CEC framework, which is >> IMHO >> unexpected. > > Notifier is used only by CEC framework, so IMHO it would be desirable to > put CEC specific things into CEC framework. The CEC framework is just the first that needs it. But especially audio drivers also want to use it. It was designed to help out both subsystems since both need the EDID/ELD. Regards, Hans > Drivers duty is just to find notifier device. > Leaving it as is will just put little more burden on drivers, so this is > not big deal, do as you wish :) > > Regards > Andrzej > >> >> I think I want to keep this as-is, at least for now. >> >> Regards, >> >> Hans >> >> >> >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: radio-cadet, initialize timer with setup_timer
From: Matej Hulín
Stop accessing timer struct members directly and use the setup_timer
helper intended for that use. It makes the code cleaner and will allow
for easier change of the timer struct internals.
Signed-off-by: Matej Hulín
Signed-off-by: Jiri Slaby
Cc: Hans Verkuil
Cc: Mauro Carvalho Chehab
Cc:
---
drivers/media/radio/radio-cadet.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/radio-cadet.c
b/drivers/media/radio/radio-cadet.c
index 82affaedf067..cbaf850f4791 100644
--- a/drivers/media/radio/radio-cadet.c
+++ b/drivers/media/radio/radio-cadet.c
@@ -309,9 +309,7 @@ static void cadet_handler(unsigned long data)
/*
* Clean up and exit
*/
- init_timer(&dev->readtimer);
- dev->readtimer.function = cadet_handler;
- dev->readtimer.data = data;
+ setup_timer(&dev->readtimer, cadet_handler, data);
dev->readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(&dev->readtimer);
}
@@ -320,9 +318,7 @@ static void cadet_start_rds(struct cadet *dev)
{
dev->rdsstat = 1;
outb(0x80, dev->io);/* Select RDS fifo */
- init_timer(&dev->readtimer);
- dev->readtimer.function = cadet_handler;
- dev->readtimer.data = (unsigned long)dev;
+ setup_timer(&dev->readtimer, cadet_handler, (unsigned long)dev);
dev->readtimer.expires = jiffies + msecs_to_jiffies(50);
add_timer(&dev->readtimer);
}
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 4.10] fix cxd2820r 4.9 regression
The following changes since commit d183e4efcae8d88a2f252e546978658ca6d273cc: [media] v4l: tvp5150: Add missing break in set control handler (2016-12-12 07:49:58 -0200) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git cxd2820r for you to fetch changes up to 783d933cf02e970b49e0dcb586a76207aa6fa331: cxd2820r: fix gpio null pointer dereference (2017-01-23 10:40:17 +0200) Antti Palosaari (1): cxd2820r: fix gpio null pointer dereference drivers/media/dvb-frontends/cxd2820r_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v4.11] coda: add support for Video Data Order Adapter
The following changes since commit 40eca140c404505c09773d1c6685d818cb55ab1a: [media] mn88473: add DVB-T2 PLP support (2016-12-27 14:00:15 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.11c for you to fetch changes up to 7da44db4d65786332a797aa08b7932e2fb4d421f: coda: support YUYV output if VDOA is used (2017-01-23 09:43:46 +0100) Michael Tretter (3): coda: fix frame index to returned error coda: use VDOA for un-tiling custom macroblock format coda: support YUYV output if VDOA is used Philipp Zabel (4): dt-bindings: Add a binding for Video Data Order Adapter coda: add i.MX6 VDOA driver coda: correctly set capture compose rectangle coda: add debug output about tiling Documentation/devicetree/bindings/media/fsl-vdoa.txt | 21 +++ arch/arm/boot/dts/imx6qdl.dtsi | 2 + drivers/media/platform/Kconfig | 3 + drivers/media/platform/coda/Makefile | 1 + drivers/media/platform/coda/coda-bit.c | 93 + drivers/media/platform/coda/coda-common.c| 177 ++--- drivers/media/platform/coda/coda.h | 3 + drivers/media/platform/coda/imx-vdoa.c | 338 +++ drivers/media/platform/coda/imx-vdoa.h | 58 9 files changed, 654 insertions(+), 42 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt create mode 100644 drivers/media/platform/coda/imx-vdoa.c create mode 100644 drivers/media/platform/coda/imx-vdoa.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC simple allocator v1 0/2] Simple allocator
On Fri, Jan 20, 2017 at 04:32:29PM +0100, Benjamin Gaignard wrote:
> The goal of this RFC is to understand if a common ioctl for specific memory
> regions allocations is needed/welcome.
>
> Obviously it will not replace allocation done in linux kernel frameworks like
> v4l2, drm/kms or others, but offer an alternative when you don't want/need to
> use them for buffer allocation.
> To keep a compatibility with what already exist allocated buffers are exported
> in userland as dmabuf file descriptor (like ION is doing).
>
> "Unix Device Memory Allocator" project [1] wants to create a userland library
> which may allow to select, depending of the devices constraint, the best
> back-end for allocation. With this RFC I would to propose to have common ioctl
> for a maximum of allocators to avoid to duplicated back-ends for this library.
>
> One of the issues that lead me to propose this RFC it is that since the
> beginning
> it is a problem to allocate contiguous memory (CMA) without using v4l2 or
> drm/kms so the first allocator available in this RFC use CMA memory.
>
> An other question is: do we have others memory regions that could be
> interested
> by this new framework ? I have in mind that some title memory regions could
> use
> it or replace ION heaps (system, carveout, etc...).
> Maybe it only solve CMA allocation issue, in this case there is no need to
> create
> a new framework but only a dedicated ioctl.
>
> Maybe the first thing to do is to change the name and the location of this
> module, suggestions are welcome.
>
> I have testing this code with the following program:
I'm still maintaining that we should just destage ION (with the todo items
fixed), since that is already an uabi to do this (afaiui at least), and
it's used on a few devices ... Please chat with Laura Abott.
-Daniel
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include "simple-allocator.h"
>
> #define LENGTH 1024*16
>
> void main (void)
> {
> struct simple_allocate_data data;
> int fd = open("/dev/cma0", O_RDWR, 0);
> int ret;
> void *mem;
>
> if (fd < 0) {
> printf("Can't open /dev/cma0\n");
> return;
> }
>
> memset(&data, 0, sizeof(data));
>
> data.length = LENGTH;
> data.flags = O_RDWR | O_CLOEXEC;
>
> ret = ioctl(fd, SA_IOC_ALLOC, &data);
> if (ret) {
> printf("Buffer allocation failed\n");
> goto end;
> }
>
> mem = mmap(0, LENGTH, PROT_READ | PROT_WRITE, MAP_SHARED, data.fd, 0);
> if (mem == MAP_FAILED) {
> printf("mmap failed\n");
> }
>
> memset(mem, 0xFF, LENGTH);
> munmap(mem, LENGTH);
>
> printf("test simple allocator CMA OK\n");
> end:
> close(fd);
> }
>
> [1] https://github.com/cubanismo/allocator
>
> Benjamin Gaignard (2):
> Create Simple Allocator module
> add CMA simple allocator module
>
> Documentation/simple-allocator.txt | 81 ++
> drivers/Kconfig | 2 +
> drivers/Makefile| 1 +
> drivers/simpleallocator/Kconfig | 17 +++
> drivers/simpleallocator/Makefile| 2 +
> drivers/simpleallocator/simple-allocator-cma.c | 187
>
> drivers/simpleallocator/simple-allocator-priv.h | 33 +
> drivers/simpleallocator/simple-allocator.c | 180 +++
> include/uapi/linux/simple-allocator.h | 35 +
> 9 files changed, 538 insertions(+)
> create mode 100644 Documentation/simple-allocator.txt
> create mode 100644 drivers/simpleallocator/Kconfig
> create mode 100644 drivers/simpleallocator/Makefile
> create mode 100644 drivers/simpleallocator/simple-allocator-cma.c
> create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
> create mode 100644 drivers/simpleallocator/simple-allocator.c
> create mode 100644 include/uapi/linux/simple-allocator.h
>
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
