cron job: media_tree daily build: ERRORS
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: Fri Jul 29 04:00:25 CEST 2016 git branch: test git hash: 292eaf50c7df4ae2ae8aaa9e1ce3f1240a353ee8 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: ERRORS linux-git-arm-davinci: ERRORS linux-git-arm-multi: ERRORS linux-git-blackfin-bf561: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS 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: WARNINGS linux-3.12.23-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-i686: WARNINGS linux-4.1.1-i686: WARNINGS linux-4.2-i686: WARNINGS linux-4.3-i686: WARNINGS linux-4.4-i686: WARNINGS linux-4.5-i686: WARNINGS linux-4.6-i686: WARNINGS linux-4.7-rc1-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.23-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-x86_64: WARNINGS linux-4.1.1-x86_64: WARNINGS linux-4.2-x86_64: WARNINGS linux-4.3-x86_64: WARNINGS linux-4.4-x86_64: WARNINGS linux-4.5-x86_64: WARNINGS linux-4.6-x86_64: WARNINGS linux-4.7-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: ERRORS sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
Sony tuner chip driver questions
Hello Linux-media people... :-) A group at Sony would like to develop a proper kernel driver for a TV/tuner chip that Sony produces, and we'd like to ask some questions before we get started. FYI - I'm kicking off the conversation thread, but I'm not a TV or media-driver person, so please excuse anything that sounds strangely worded or is just a really dumb question. I have experts CC:ed who can clarify anything I misstate. :-) First some background: The chip is in the same family as other chips for which there are currently some kernel drivers in mainline, produced by 3rd parties (not Sony). The drivers already in the tree are linux/media/dvb-frontend/cxd2820.c, cxd2841er.c, and ascot2e.c. Currently Sony provides a user-space driver to its customers, but we'd like to switch to an in-kernel driver. The chip has a tuner and demodulator included. First, we will be delivering the actual video data over SPI. Currently, we only see examples of doing this over PCI and USB busses. Are there any examples of the appropriate method to transfer video data (or other high-volume data) over SPI? If not, are there any recommendations or tips for going about this? Second, the current drivers for the cxd2820 and cxd2841 seem to use a lot of hard-coded register values (and don't appear to use device tree). We're not sure if these drivers are the best examples to follow in creating a new dvb driver for Linux. Is there a recommended driver or example that shows the most recent or preferred good structure for such drivers, that we should use in starting ours? Is DVB is the correct kernel subsystem to use for this driver, or is V4L more appropriate? If we have multiple files in our driver, should we put them all in the dvb-frontend directory, or should they be sprinkled around in different directories based on function? Or should we create a 'sony' directory somewhere to hold them? What debugging tools, if any, are available for testing dvb drivers in the kernel? Do any current tuner drivers support dual-tuner configurations? Thanks for any assistance or information you can provide to help us get started. -- Tim Bird Senior Staff Software Engineer, Sony North America P.S. We are ramping up the project now, but will likely get to major development effort in a month or two. -- 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 1/1] media: platform: ti-vpe: call of_node_put on non-null pointer
Peter Chen wrote on Fri [2016-Jul-15 17:33:06 +0800]: > It should call of_node_put on non-null poiner. Good catch, thanks. Acked-by: Benoit Parrot > > Cc: linux-media@vger.kernel.org > Cc: Mauro Carvalho Chehab > Cc: Benoit Parrot > Signed-off-by: Peter Chen > --- > drivers/media/platform/ti-vpe/cal.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/media/platform/ti-vpe/cal.c > b/drivers/media/platform/ti-vpe/cal.c > index 82001e6..00c3e97 100644 > --- a/drivers/media/platform/ti-vpe/cal.c > +++ b/drivers/media/platform/ti-vpe/cal.c > @@ -1761,13 +1761,13 @@ static int of_cal_create_instance(struct cal_ctx > *ctx, int inst) > } > > cleanup_exit: > - if (!remote_ep) > + if (remote_ep) > of_node_put(remote_ep); > - if (!sensor_node) > + if (sensor_node) > of_node_put(sensor_node); > - if (!ep_node) > + if (ep_node) > of_node_put(ep_node); > - if (!port) > + if (port) > of_node_put(port); > > return ret; > -- > 1.9.1 > -- 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: pwc over musb: 100% frame drop (lost) on high resolution stream
Hello,
I've just bisected commit, which fixed the issue in v4.7
commit 9fa64d6424adabf0e3a546ae24d01a62a927b342
Merge: f55532a febce40
Author: Rafael J. Wysocki
Date: Sat Apr 2 01:07:17 2016 +0200
Merge back intel_pstate fixes for v4.6.
* pm-cpufreq:
intel_pstate: Avoid extra invocation of intel_pstate_sample()
intel_pstate: Do not set utilization update hook too early
Unfortunately, intel_pstate branch doesn't have
f551e13529833e052f75ec628a8af7b034af20f9 applied.
I'll try to bisect this branch with the patch manually applied.
2016-07-27 20:34 GMT+03:00 Matwey V. Kornilov :
> Hello,
>
> I've just biseced commit, which introduced this issue
>
> commit f551e13529833e052f75ec628a8af7b034af20f9
> Author: Bin Liu
> Date: Mon Apr 25 15:53:30 2016 -0500
>
> Revert "usb: musb: musb_host: Enable HCD_BH flag to handle urb
> return in bottom half"
>
> I have not checked yet, if it was intentionnaly fixed.
>
> 2016-07-23 22:24 GMT+03:00 Matwey V. Kornilov :
>> 2016-07-20 21:56 GMT+03:00 Matwey V. Kornilov :
>>> 2016-07-20 18:06 GMT+03:00 Bin Liu :
Hi,
On Wed, Jul 20, 2016 at 05:44:56PM +0300, Matwey V. Kornilov wrote:
> 2016-07-20 17:13 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Wed, Jul 20, 2016 at 09:09:42AM +0300, Matwey V. Kornilov wrote:
> >> 2016-07-20 0:34 GMT+03:00 Bin Liu :
> >> > Hi,
> >> >
> >> > On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> >> >> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> >> >> > Hi,
> >> >> >
> >> >> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> >> >> Hello,
> >> >> >>
> >> >> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x
> >> >> >> based BeagleBoneBlack SBC.
> >> >> >> I am sure that both of them are fine and work properly.
> >> >> >> I am running Linux 4.6.4 (my kernel config is available at
> >> >> >> https://clck.ru/A2kQs ) and I've just discovered, that there is
> >> >> >> an issue with frame transfer when high resolution formats are
> >> >> >> used.
> >> >> >>
> >> >> >> The issue is the following. I use simple v4l2 example tool
> >> >> >> (taken from API docs), which source code is available at
> >> >> >> http://pastebin.com/grcNXxfe
> >> >> >>
> >> >> >> When I use (see line 488) 640x480 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 640;
> >> >> >> fmt.fmt.pix.height = 480;
> >> >> >>
> >> >> >> then I get "select timeout" and don't get any frames.
> >> >> >>
> >> >> >> When I use 320x240 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 320;
> >> >> >> fmt.fmt.pix.height = 240;
> >> >> >>
> >> >> >> then about 60% frames are missed. An example outpout of ./a.out
> >> >> >> -f is available at https://yadi.sk/d/aRka8xWPtSc4y
> >> >> >> It looks like there are pauses between bulks of frames (frame
> >> >> >> counter and timestamp as returned from v4l2 API):
> >> >> >>
> >> >> >> 3 3705.142553
> >> >> >> 8 3705.342533
> >> >> >> 13 3705.542517
> >> >> >> 110 3708.776208
> >> >> >> 115 3708.976190
> >> >> >> 120 3709.176169
> >> >> >> 125 3709.376152
> >> >> >> 130 3709.576144
> >> >> >> 226 3712.807848
> >> >> >>
> >> >> >> When I use tiny 160x120 frames
> >> >> >>
> >> >> >> fmt.fmt.pix.width = 160;
> >> >> >> fmt.fmt.pix.height = 120;
> >> >> >>
> >> >> >> then more frames are received. See output example at
> >> >> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> >> >> That is why I thought that everything was fine in May when used
> >> >> >> tiny xawtv window to check kernel OOPS presence (see
> >> >> >> http://www.spinics.net/lists/linux-usb/msg141188.html for
> >> >> >> reference)
> >> >> >>
> >> >> >> Even more. When I introduce USB hub between the host and the
> >> >> >> webcam, I can not receive even any 320x240 frames.
> >> >> >>
> >> >> >> I've managed to use ftrace to see what is going on when no
> >> >> >> frames are received.
> >> >> >> I've found that pwc_isoc_handler is called frequently as the
> >> >> >> following:
> >> >> >>
> >> >> >> 0) | pwc_isoc_handler [pwc]() {
> >> >> >> 0) |usb_submit_urb [usbcore]() {
> >> >> >> 0) | usb_submit_urb.part.3 [usbcore]() {
> >> >> >> 0) |usb_hcd_submit_urb [usbcore]() {
> >> >> >> 0) 0.834 us| usb_get_urb [usbcore]();
> >> >> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
> >> >> >> 0) 0.792 us|usb_hcd_map_urb_for_dma
> >> >> >> [usbcore]();
> >> >> >> 0) 5.750 us| }
> >> >> >> 0) |
Re: [PATCH v2 2/4] dt-bindings: Add a binding for Mediatek MDP
On Tue, Jul 26, 2016 at 8:44 PM, Minghsiu Tsai
wrote:
> On Tue, 2016-07-26 at 13:54 -0500, Rob Herring wrote:
>> On Fri, Jul 22, 2016 at 04:33:01PM +0800, Minghsiu Tsai wrote:
>> > Add a DT binding documentation of MDP for the MT8173 SoC
>> > from Mediatek
>> >
>> > Signed-off-by: Minghsiu Tsai
>> > ---
>> > .../devicetree/bindings/media/mediatek-mdp.txt | 96
>> >
>> > 1 file changed, 96 insertions(+)
>> > create mode 100644
>> > Documentation/devicetree/bindings/media/mediatek-mdp.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt
>> > b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
>> > new file mode 100644
>> > index 000..2dad031
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt
>> > @@ -0,0 +1,96 @@
>> > +* Mediatek Media Data Path
>> > +
>> > +Media Data Path is used for scaling and color space conversion.
>> > +
>> > +Required properties (all function blocks):
>> > +- compatible: "mediatek,-mdp"
>>
>> What is this, ...
>>
>
> It is used to match platform driver.
Would structuring things like this work instead:
{
compatible = "mediatek,-mdp";
ranges = ...;
{
compatible = "mediatek,-mdp-rdma";
...
};
{
compatible = "mediatek,-mdp-wdma";
...
};
...
};
>
>
>> > +"mediatek,-mdp-", one of
>>
>> and this?
>>
>
> It is string format of HW block. could be "mt8173", and
> are "rdma", "rsz", "wdma", and "wrot".
>
>
>> > +"mediatek,-mdp-rdma" - read DMA
>> > +"mediatek,-mdp-rsz" - resizer
>> > +"mediatek,-mdp-wdma" - write DMA
>> > +"mediatek,-mdp-wrot" - write DMA with rotation
>>
>> List what are valid values of .
>>
>
> - mt8173. There should be other chip added in future.
> I will change the property as blow:
>
> - compatible: "mediatek,-mdp"
> Should be one of
> "mediatek,-mdp-rdma" - read DMA
> "mediatek,-mdp-rsz" - resizer
> "mediatek,-mdp-wdma" - write DMA
> "mediatek,-mdp-wrot" - write DMA with rotation
> - could be 8173
>
>
> If don't need , I also can change it as below. It is more clear.
Up to you. Depends on how many different chips you will have.
> - compatible: "mediatek,mt8173-mdp"
> Should be one of
> "mediatek,mt8173-mdp-rdma" - read DMA
> "mediatek,mt8173-mdp-rsz" - resizer
> "mediatek,mt8173-mdp-wdma" - write DMA
> "mediatek,mt8173-mdp-wrot" - write DMA with rotation
>
>
>> > +- reg: Physical base address and length of the function block register
>> > space
>> > +- clocks: device clocks
>> > +- power-domains: a phandle to the power domain.
>> > +- mediatek,vpu: the node of video processor unit
>> > +
>> > +Required properties (DMA function blocks):
>> > +- compatible: Should be one of
>> > +"mediatek,-mdp-rdma"
>> > +"mediatek,-mdp-wdma"
>> > +"mediatek,-mdp-wrot"
>> > +- iommus: should point to the respective IOMMU block with master port as
>> > + argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
>> > + for details.
>> > +- mediatek,larb: must contain the local arbiters in the current Socs.
>>
>> It is still not clear which properties apply to which compatible
>> strings.
>>
>
> I found out the document for larb.
> I will change the property as below:
>
> - mediatek,larb: must contain the local arbiters in the current Socs,
> see
> Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt
> for details.
That's good, but not what I meant. You still have properties which
only apply to certain blocks, but are listed for all blocks like
mediatek,vpu for example.
Rob
--
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: [GIT PULL for v4.8-rc1] media updates part II: documentation
Hi Stephen, Em Thu, 28 Jul 2016 12:10:08 +1000 Stephen Backway escreveu: > Mauro, > > Are these doc-rst changes planned to be applied to the linux-media tree? > (https://git.linuxtv.org/media_tree.git/tree/Documentation) They are there already, but on a separate topic branch: https://git.linuxtv.org/media_tree.git/tree/Documentation/media?h=docs-next They'll be merged back on the master branch soon. Usually, I wait for the release of the -rc1 to merge back from Linus tree, with is scheduled to happen by the end of the next week. > > As at the moment if you follow the linux-media build instructions to > develop and send patches, you do not see the new doc-rst files and > therefore cannot include them in the patch. > (https://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers) The wiki pages may need some updates, as I suspect some of them may be mentioning the old DocBook. With regards to use media_build, you could use this option of the build script to get some other branch: --git [URL] [BRANCH] Allows specifying a URL and a git branch, instead of the default ones. Currently, only linuxtv.org git URL's are supported, as the build needs to warrant an unique namespace for git remotes. Yet, the main goal of media_build is to provide a way for users to test drivers with legacy Kernels. For developers, although using media_build may work (with either --git or --main-git option, in order to make easier to submit the patches later), the best is to just use a clone of the media_tree and use it do develop drivers. Regards, Mauro > > Thanks > Stephen. > > On 28 July 2016 at 00:01, Mauro Carvalho Chehab > wrote: > > Hi Linus, > > > > Please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > > tags/media/v4.8-4 > > > > For media documentation updates. > > > > This patch series does the conversion of all media documentation stuff > > to Restrutured Text markup format and add them to the > > Documentation/index.rst > > file. The media documentation was grouped into 4 books: > > - media uAPI; > > - media kAPI; > > - V4L driver-specific documentation; > > - DVB driver-specific documentation. > > > > It also contains several documentation improvements. > > > > Thanks! > > Mauro > > > > --- > > > > PS.: this is nearly identical to the previous pull request. > > The only difference is that I removed an already applied patch > > from the patch series. > > > > A trivial conflict is expected when merging Documentation/index.rst, > > as both my tree and Daniel Vetter's tree will be adding files there. > > > > > > The following changes since commit 9c1958fc326a0a0a533ec8e86ea6fa30977207de: > > > > Merge tag 'media/v4.8-1' of > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > > (2016-07-26 18:59:59 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media > > tags/media/v4.8-4 > > > > for you to fetch changes up to 85538b1ad145c67198cb55d02de14ba269cc323d: > > > > Merge branch 'topic/docs-next' into v4l_for_linus (2016-07-27 10:45:04 > > -0300) > > > > > > media updates for v4.8-rc1 > > > > > > Hans Verkuil (5): > > [media] pixfmt-006.rst: add missing V4L2_YCBCR_ENC_SMPTE240M > > [media] vidioc-g-dv-timings.rst: document interlaced defines > > [media] doc-rst: update CEC_RECEIVE > > [media] doc-rst: improve CEC documentation > > [media] doc-rst: cec: update documentation > > > > Markus Heiser (10): > > doc-rst: linux_tv DocBook to reST migration (docs-next) > > doc-rst: boilerplate HTML theme customization > > doc-rst: customize RTD theme, table & full width > > doc-rst: customize RTD theme, captions & inline literal > > doc-rst: auto-generate: fixed include "output/*.h.rst" content > > doc-rst: add kernel-include directive > > doc-rst: linux_tv/Makefile: Honor quiet make O=dir > > [media] doc-rst: linux_tv CEC part, DocBook to reST migration > > [media] doc-rst: linux_tc CEC enhanced markup > > [media] doc-rst: media: reordered top sectioning > > > > Mauro Carvalho Chehab (313): > > Merge branch 'docs-next' of git://git.lwn.net/linux into > > devel/docs-next > > doc-rst: linuxt_tv: update the documentation year > > doc-rst: some fixups at linux_tv/index > > doc-rst: v4l2: Fix authors and revisions lists > > doc-rst: querycap: fix troubles on some references > > doc-rst: linux_tv/index: add xrefs for document divisions > > doc-rst: app-pri: Fix a bad reference > > doc-rst: video: use reference for VIDIOC_ENUMINPUT > > doc-rst: v4l2: numerate the V4L2 chapters > > doc-rst: video: Restore
omap3-isp bt656 10bit
Hello, I'm trying to read 10 bit BT656 using an omap3 DM3730 (omap3-isp). The bt565 data comes from ADV7842 configured manually from i2c, I have checked the ADV configuration using an evaluation board (EVAL-ADV7842-7511P) in BT656 10 bits mode. Then I assume that the 10bit BT656 arrives to the omap isp. In the kernel side, I use a tvp5150 driver like a dummy driver in order to configure the MC and V4L2, this dummy driver only have patched the i2c read/write and is well registered. My question is about 10bit instead of 8 bits of tvp5150, in the omap3-isp driver the 10 bits for BT656 is not configured (the ISPCCDC_CFG_BW656 is not set in ispccdc.c file) I just added isp_reg_set(isp, OMAP3_ISP_IOMEM_CCDC, ISPCCDC_CFG, ISPCCDC_CFG_BW656); inside of ccdc_set_stream function, and I have checked that the bit 5 in 0x480B_C654 CCDC_CFG omap register and comes to "1" But with yavta I can't capture the image sent from ADV7842, after convert with raw2rgbpnm appear the "image", attached link. http://picpaste.com/test-0HlXySLu.png Any clue about how to use BT656 10 bits in omap3 (DM3730)? I have tested with kernel v4.5 mainline and v4.3 that was used for validate the tvp5150(bt656 8bit) video captures to omap3-isp. Best Regards Eduard Gavin -- 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
