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: Mon May 15 05:00:24 CEST 2017 media-tree git hash:3622d3e77ecef090b5111e3c5423313f11711dfa media_build git hash: ab988a3d089232ce9e1aec2f259e947c06983dbc v4l-utils git hash: 6acac5cec698de39b9398b66c4f5f4db6b2730d8 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0-3553-g78b2ea6 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.9.0-164 linux-git-arm-at91: WARNINGS linux-git-arm-davinci: WARNINGS linux-git-arm-multi: WARNINGS linux-git-arm-pxa: OK linux-git-blackfin-bf561: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS 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: WARNINGS linux-3.12.67-i686: WARNINGS 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: WARNINGS linux-4.9.26-i686: WARNINGS linux-4.10.14-i686: WARNINGS linux-4.11-i686: WARNINGS 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: WARNINGS linux-3.12.67-x86_64: WARNINGS 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: WARNINGS linux-4.9.26-x86_64: WARNINGS linux-4.10.14-x86_64: WARNINGS linux-4.11-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree
On Fri, 2017-05-12 at 17:05 +0200, Matthias Brugger wrote:
>
> On 12/05/17 05:22, Minghsiu Tsai wrote:
> > From: Daniel Kurtz
> >
> > If the mdp_* nodes are under an mdp sub-node, their corresponding
> > platform device does not automatically get its iommu assigned properly.
> >
> > Fix this by moving the mdp component nodes up a level such that they are
> > siblings of mdp and all other SoC subsystems. This also simplifies the
> > device tree.
> >
> > Although it fixes iommu assignment issue, it also break compatibility
> > with old device tree. So, the patch in driver is needed to iterate over
> > sibling mdp device nodes, not child ones, to keep driver work properly.
> >
>
> Couldn't we preserve backwards compatibility by doing something like this:
> diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> index 9e4eb7dcc424..277d8fe6eb76 100644
> --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> @@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> {
> struct mtk_mdp_dev *mdp;
> struct device *dev = &pdev->dev;
> - struct device_node *node;
> + struct device_node *node, *parent;
> int i, ret = 0;
>
> mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
> @@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> mutex_init(&mdp->lock);
> mutex_init(&mdp->vpulock);
>
> + /* Old dts had the components as child nodes */
> + if (of_get_next_child(dev->of_node, NULL))
> + parent = dev->of_node;
> + else
> + parent = dev->of_node->parent;
> +
> /* Iterate over sibling MDP function blocks */
> - for_each_child_of_node(dev->of_node, node) {
> + for_each_child_of_node(parent, node) {
> const struct of_device_id *of_id;
> enum mtk_mdp_comp_type comp_type;
> int comp_id;
>
> Maybe even by putting a warning in the if branch to make sure, people
> are aware of their out-of-date device tree blobs.
>
> Regards,
> Matthias
>
Hi Matthias,
It is a good idea to do compatible in such a way and put a warning the
device tree is out of date. People can find out cause soon if device
tree is old.
I modify the code as below:
+ /* Old dts had the components as child nodes */
+ if (of_get_next_child(dev->of_node, NULL)) {
+ parent = dev->of_node;
+ dev_warn(dev, "device tree is out of date\n");
+ } else {
+ parent = dev->of_node->parent;
+ }
Will you upload it in a separate patch?
If not, I can merge it in my patch series and upload v4.
Best Regards,
Ming Hsiu
> > Signed-off-by: Daniel Kurtz
> > Signed-off-by: Minghsiu Tsai
> >
> > ---
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > index 9e4eb7d..a5ad586 100644
> > --- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > +++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > @@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
> > mutex_init(&mdp->vpulock);
> >
> > /* Iterate over sibling MDP function blocks */
> > - for_each_child_of_node(dev->of_node, node) {
> > + for_each_child_of_node(dev->of_node->parent, node) {
> > const struct of_device_id *of_id;
> > enum mtk_mdp_comp_type comp_type;
> > int comp_id;
> >
Re: [PATCH 0/6] R-Car DU: Fix IOMMU operation when connected to VSP
Hi Magnus, On Wednesday 07 Sep 2016 17:01:06 Magnus Damm wrote: > Hi Laurent, > > Thanks for your help with this. Good to see that the DU driver is > getting closer to work with the IPMMU hardware! Please see below for > some feedback from me. > > On Fri, Aug 19, 2016 at 5:39 PM, Laurent Pinchart wrote: > > Hello, > > > > This patch series fixes the rcar-du-drm driver to support VSP plane > > sources with an IOMMU. It is available for convenience at > > > > git://linuxtv.org/pinchartl/media.git iommu/devel/du > > > > On R-Car Gen3 the DU has no direct memory access but sources planes > > through VSP instances. When an IOMMU is inserted between the VSP and > > memory, the DU framebuffers need to be DMA mapped using the VSP device, > > not the DU device as currently done. The same situation can also be > > reproduced on Gen2 hardware by linking the VSP to the DU in DT [1], > > effectively disabling direct memory access by the DU. > > > > The situation is made quite complex by the fact that different planes can > > be connected to different DU instances, and thus served by different > > IOMMUs (or, in practice on existing hardware, by the same IOMMU but > > through different micro-TLBs). We thus can't allocate and map buffers to > > the right device in a single dma_alloc_wc() operation as done in the DRM > > CMA GEM helpers. > > > > However, on such setups, the DU DT node doesn't reference IOMMUs as the DU > > does not perform any direct memory access. We can thus keep the GEM object > > allocation unchanged, and the DMA addresses that we receive in the DU > > driver will be physical addresses. Those buffers then need to be mapped > > to the VSP device when they are associated with planes. Fortunately the > > atomic framework provides two plane helper operations, .prepare_fb() and > > .cleanup_fb() that we can use for this purpose. > > > > The reality is slightly more complex than this on Gen3, as an FCP device > > instance sits between VSP instances and memory. It is the FCP devices that > > are connected to the IOMMUs, and buffer mapping thus need to be performed > > using the FCP devices. This isn't required on Gen2 as the platforms don't > > have any FCPs. > > > > Patches 1/6 and 2/6 unconstify the state argument to the .prepare_fb() and > > .cleanup_fb() operations, to allow storing the mapped buffer addresses in > > the state. Patches 3/6 and 4/6 then extend the rcar-fcp driver API to > > expose the FCP struct device. Patch 5/6 extends the vsp1 driver API to > > allow mapping a scatter-gather list to the VSP, with the implementation > > using the FCP devices instead when available. Patch 6/6 then use the vsp1 > > mapping API in the rcar-du-drm driver to map and unmap buffers when > > needed. > > > > The series has been tested on Gen2 (Lager) only as the Gen3 IOMMU is known > > to be broken. > > Slight clarification, the R-Car Gen3 family as a whole does not have > broken IPMMU hardware. Early R-Car H3 revisions do require some errata > handling though, but M3-W and later ES versions and MP of H3 will be > fine. Given the early R-Car H3 errata I agree it makes sense to > develop and test this series on R-Car Gen2 though. > > > A possible improvement is to modify the GEM object allocation mechanism to > > use non-contiguous memory when the DU driver detects that all the VSP > > instances it is connected to use an IOMMU (possibly through FCP devices). > > > > An issue has been noticed with synchronization between page flip and VSP > > operation. Buffers get unmapped (and possibly freed) before the VSP is > > done reading them. The problem isn't new, but is much more noticeable with > > IOMMU support enabled as any hardware access to unmapped memory generates > > an IOMMU page fault immediately. > > > > The series unfortunately contain a dependency between DRM and V4L2 > > patches, complicating upstream merge. As there's no urgency to merge patch > > 6/6 due to the IOMMU being broken on Gen3 at the moment, I propose merging > > patches 1/6-2/6 and 3/6-5/6 independently for the next kernel release. > > > > I would particularly appreciate feedback on the APIs introduced by patches > > 4/6 and 5/6. > > The code in general looks fine to me. The APIs introduced by patches > 4/6 and 5/6 seem quite straightforward. Is there something I can do to > help with those? > > > [1] > > https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg06589.h > > tml > > Laurent Pinchart (6): > > drm: Don't implement empty prepare_fb()/cleanup_fb() > > drm: Unconstify state argument to prepare_fb()/cleanup_fb() > > v4l: rcar-fcp: Don't get/put module reference > > v4l: rcar-fcp: Add an API to retrieve the FCP device > > v4l: vsp1: Add API to map and unmap DRM buffers through the VSP > > drm: rcar-du: Map memory through the VSP device > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 2 - > > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 4 +- > > drivers/gpu/drm/fsl-dc
[PATCH] [media] s5p-mfc: fix spelling mistake: "destionation" -> "destination"
From: Colin Ian King
Trivial fix to spelling mistake in mfc_err error messages
Signed-off-by: Colin Ian King
---
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 2 +-
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index b41ee608c171..0913881219ff 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -1293,7 +1293,7 @@ static int s5p_mfc_run_init_dec_buffers(struct
s5p_mfc_ctx *ctx)
* First set the output frame buffers
*/
if (ctx->capture_state != QUEUE_BUFS_MMAPED) {
- mfc_err("It seems that not all destionation buffers were
mmaped\nMFC requires that all destination are mmaped before starting
processing\n");
+ mfc_err("It seems that not all destination buffers were
mmaped\nMFC requires that all destination are mmaped before starting
processing\n");
return -EAGAIN;
}
if (list_empty(&ctx->src_queue)) {
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 85880e9106be..88dbb9c341ec 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -1650,7 +1650,7 @@ static inline int s5p_mfc_run_init_dec_buffers(struct
s5p_mfc_ctx *ctx)
* s5p_mfc_alloc_dec_buffers(ctx); */
if (ctx->capture_state != QUEUE_BUFS_MMAPED) {
- mfc_err("It seems that not all destionation buffers were\n"
+ mfc_err("It seems that not all destination buffers were\n"
"mmaped.MFC requires that all destination are mmaped\n"
"before starting processing.\n");
return -EAGAIN;
--
2.11.0
Re: Is it possible to have a binary blob custom control?
On Sun, May 14, 2017 at 3:27 AM, Jean-Michel Hautbois wrote: > Maybe a debugfs would be easier than an ioctl? Do you have a good reason to > use the control framework for that matter? I implemented this once before, using a custom ioctl, which meant that I had to maintain a custom kernel header file. I am looking for a better way to do this. I wondered if I could do this through the V4L2 framework, but perhaps, as you suggest, the debugfs would be better. The underlying issue I am trying to address is this: I have an application that used the ov7740 imager from Omnivision. I have custom register settings that were provided to me under NDA. I have asked Omnivision if I can publish those register settings in GPL'd source code, but have received no response. So, my alternative approach was to modify the GPL driver to accept custom register settings (through a new IOCTL). That way I can bake the register settings in my custom application and still use the GPL'd driver. But that meant that I had to define a header file that gets included in the kernel, and I need some way to build my application with a reference to that header file. This is error prone. I like your suggestion of a debugfs API. That way I could open /proc/sys/debug/ov7740/custom_vga_settings and write my register settings there. The name is the documentation. The format is in the README. Are there other ways I could do this? Certainly? Are there better ways I could do this? I'm open to opinions. Thanks again. --wpd
