<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
vianpl: Hi, I'm working on a SDI capture driver and it seems that SDI timings have never been defined (v4l2-dv-timings.h). Does any of you have a reliable source that lists all the SDI formats? I've been looking around , mostly checking datasheets from random SDI devices yet they seem to contradict each other. Also the SMPTE standards are pretty expensive so that's not an option for me.
hverkuil: <u>vianpl</u>: we have one sdi driver: drivers/media/spi/gs1662.c
<br> it just reuses the existing timings.
<br> AFAIK there is no front/backporch or sync, but the total blanking time is the same.
vianpl: Thanks, I'll have a look at it.
hverkuil: <u>benjiG</u>: I was about to merge the stm32-cec driver, but then I saw that the first patch hasn't been acked yet by Rob Herring.
<br> Can you chase that?
<br> Sorry for missing this before, I thought it was already acked.
benjiG: <u>hverkuil</u>: sure I will to Rob to look at it
mchehab: <u>svarbanov</u>: I took a quick look on the venus driver today... patch looks ok, but I found some issues when building it, plus the lack of the capability of building it with COMPILE_TEST
<br> just sent you an email about it
svarbanov: <u>mchehab</u>: ok, thanks!
mchehab: I'll mark the pull request as "changes requested", as you'll likely need to respin it to solve some issues
svarbanov: <u>mchehab</u>: the venus driver depends on qcom/arm symbols which are related to trusted environment and firmware loading, so it couldn't use COMPILE_TEST until the driver which provides those symbols is fixed.
mchehab: any ETA for fixing it?
<br> (ETA: expected time)
svarbanov: <u>mchehab</u>: I will send a separate patch for this dependency driver, I hope it could merged as fix on next rc
mchehab: Ok
hverkuil: <u>mchehab</u>: I looked into this as well, and COMPILE_TEST really doesn't work yet for this driver.
mchehab: please be clearer about that at the patch description
<br> also, please look at the issues pointed by gcc
<br> at least some of them are valid (if not all)
svarbanov: <u>mchehab</u>: sure, will do
mchehab: ok, thanks!
<br> some of them are really scared, like this one:
<br> drivers/media/platform/qcom/venus/venc.c:1150 venc_close() error: dereferencing freed memory 'inst'
<br> and this:
<br> drivers/media/platform/qcom/venus/hfi_cmds.c:415 pkt_session_set_property_1x() warn: variable dereferenced before check 'pkt' (see line 412)
<br> (it might be some gcc noise - didn't really check the code)
svarbanov: <u>mchehab</u>: agreed, sounds bad
<br> <u>mchehab</u>: I'll take care of this, probably I need to find a way to upgrade to gcc 7
mchehab: what I did here was to put gcc 7 under /opt
<br> I had to compile it myself
<br> I picked it from its git tree and used this script: https://pastebin.com/qz62aJ0u
<br> it builds gcc for both x86 and arm
<br> it took me a while to figure out the steps to do, so I documented them at the script
svarbanov: <u>mchehab</u>: you said arm, what about arm64?
mchehab: not sure if I tried building it for arm64
<br> if you play with those:
<br> PREFIX_arm=/opt/gcc-${VER}/arm
<br> TARGET_arm="--target arm-none-eabi --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb"
<br> you may be able to build it for aarch64
<br> if you manage to do that, please send me the config :-)
<br> the way I did the script, it would be easy to add other architectures...
<br> it is just a matter of setting the location of the binary and the platform-specific parameters for gcc --configure
<br> I mean: gcc configure
<br> maybe just --target aarch64-none-eabi would be enough
<br> no, that's not enough:
<br> Makefile:897: recipe for target 'all' failed
<br> this seems to work
<br> --target=aarch64-linux
<br> no, it failed too
mort: <u>svarbanov</u>: hi, are you here? gentest_fill() uses NV12, right?
svarbanov: <u>mort</u>: yes
<br> <u>mchehab</u>: which branch do you use for gcc7 build?
mchehab: gcc-7_1_0-release
<br> it is actually a tag
<br> f9105a38249f (HEAD -> gcc-7_1_0, tag: gcc-7_1_0-release) Update ChangeLog and version files for release
<br> building for aarch64 is not trivial, due to some issues when building gdb stuff... not sure how to fix it
svarbanov: <u>mchehab</u>: ok, thanks! I will use i386 version to fix the warn/errors first, then will see
mchehab: yep, x86 is enough for warn/error checks
<br> fedora 26 is scheduled for 2017-07-11, and, afaikt, it should come with gcc 7... that sounds good enough for me to have it on other archs :-)
<br> if I need before, I may end installing the beta version, scheduled for Jun, 13
<br> but the x86 version is actually enough for my workflow
svarbanov: <u>mchehab</u>: one more thing, it seems that the license from qualcomm developer site has been corrected and is applicable for linux-firmware now, so I have to prepare a pull request these days, sigh
mchehab: that's good news
<br> once you send the pull request for linux-firmware (please c/c me) and fix the issues pointed, I'll apply your patch series, as it looked fine on my eyes
<br> you may address the gcc errors on separate patches after the existing ones...
<br> that makes easier for us, as we'll need to review only the newer patches
svarbanov: <u>mchehab</u>: OK, hope that the time will be enough :)
***: benjiG has left
<br> padovan has quit IRC (Read error: Connection reset by peer)