Re: i.MX6 status for IPU/VPU/GPU
Sorry for the resend, I forget send in plain text. Hi all, I'm interested in this driver with MC support too. I join the conversation and if I have time can try to develop some functionality. Only one question: 2014-10-02 16:50 GMT+02:00 Jean-Michel Hautbois jean-michel.hautb...@vodalys.com: Hi Steve, 2014-09-09 18:28 GMT+02:00 Steve Longerbeam slongerb...@gmail.com: On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). Here is my first step toward MC support from your work : https://github.com/Vodalys/linux-2.6-imx/commit/8f0318f53c48a9638a1963b395bc79fbd7ba4c07 This is a WIP, so some parts of code are commented out awaiting a nicer solution. I also keep using your eplist array for the moment, and open will obviously fail when trying to power sensor. But what I wanted was a complete MC support with parsing links from DT and I used Laurent's work intensively :). You are forking the Freescale linux-2.6-imx repository if I understood well. Why not fork the linux-media repository? It's closer to mainline kernel I think it's better. Regards, Carlos 2014-10-02 16:50 GMT+02:00 Jean-Michel Hautbois jean-michel.hautb...@vodalys.com: Hi Steve, 2014-09-09 18:28 GMT+02:00 Steve Longerbeam slongerb...@gmail.com: On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). Here is my first step toward MC support from your work : https://github.com/Vodalys/linux-2.6-imx/commit/8f0318f53c48a9638a1963b395bc79fbd7ba4c07 This is a WIP, so some parts of code are commented out awaiting a nicer solution. I also keep using your eplist array for the moment, and open will obviously fail when trying to power sensor. But what I wanted was a complete MC support with parsing links from DT and I used Laurent's work intensively :). I've also worked out what I think is a workable video pipeline graph for i.MX, suitable for defining the entities, pads, and links. Unfortunately I haven't been able to spend as much time as I'd like on it. Did you find some time to write the pdf you mentioned ? Thanks for your work again, JM -- 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
Re: i.MX6 status for IPU/VPU/GPU
2014-10-03 12:16 GMT+02:00 Carlos Sanmartín Bustos carsa...@gmail.com: Hi all, I'm interested in this driver with MC support too. I join the conversation and if I have time can try to develop some functionality. Only one question: 2014-10-02 16:50 GMT+02:00 Jean-Michel Hautbois jean-michel.hautb...@vodalys.com: Hi Steve, 2014-09-09 18:28 GMT+02:00 Steve Longerbeam slongerb...@gmail.com: On 09/09/2014 12:49 AM, Jean-Michel Hautbois wrote: 2014-08-27 16:23 GMT+02:00 Steve Longerbeam steve_longerb...@mentor.com: The complete driver I posted to the list does have some minor issues mostly suggested by Hans Verkuil (switch to new selection API instead of cropping API for example). It is a full featured driver but it does not implement the media device framework, i.e. user does not have direct control of the video pipeline, rather the driver chooses the pipeline based on the traditional inputs from user (video format and controls). Here is my first step toward MC support from your work : https://github.com/Vodalys/linux-2.6-imx/commit/8f0318f53c48a9638a1963b395bc79fbd7ba4c07 This is a WIP, so some parts of code are commented out awaiting a nicer solution. I also keep using your eplist array for the moment, and open will obviously fail when trying to power sensor. But what I wanted was a complete MC support with parsing links from DT and I used Laurent's work intensively :). You are forking the Freescale linux-2.6-imx repository if I understood well. Why not fork the linux-media repository? It's closer to mainline kernel I think it's better. Well, this is kind of a mess in this github :). But the branch indicated is a clone of vanilla, not on linux-2.6-imx repository. I should have done a new repository, sorry for the confusion. JM -- 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] pt3 (pci, tc90522, mxl301rf, qm1d1c0042): pt3_unregister_subdev(), pt3_unregister_subdev(), cleanups...
Em Fri, 03 Oct 2014 14:45:19 +0900 AreMa Inc. i...@are.ma escreveu: Mauro Antti Please drop replace Tsukada's PT3 patches. It doesn't work like that. We don't simply drop a driver and replace by some other one. The way most open source project works with regards to patch reviewing process work is via lazy consensus. The maintainer could, of course, override it, but this is only done on exceptional cases and when there is a strong reason for doing that. The lazy consensus works like that: someone publish a patch at a public mailing list. During a reasonable amount of time, everybody that participates at the community can review the patch, and submit their review publicly. After that time, it is assumed that everybody was happy with the patch. The maintainers will then take it and merge. The PT3 patches are floating around for at least 2 merge windows, with is a more than reasonable time. There were requests to change some bad things there, to split the big patches into a series of patches, etc. All of them were satisfied. So, as everybody lazily agreed with the code, it got merged. In other words, if you had anything against the merge of the PT3 driver, you should have manifested before the merge during the ~2 months that this was discussed, and not after that. Yet, if the driver is not fully functional or if it have some issues, we do accept and we do want incremental patches fixing it. Of course, those changes should be properly described. The patch descriptions should answer three questions: - What each patch is doing; - Why that patch is needed; - How the change was done. As Antti stated, those incremental patches should be done with one logical change per patch. That will allow us to better understand what's happening. In other words, you could, for example, send us a patch inside a series that would be doing (from your previous patch): - lightweight yet precise CNR calculus Such patch should look like: Subject: pt3: improve and cleanup CNR calculus From: your real name your@email The current code uses a too complex logic to do CNR calculus. Simplify the logic by doing That keeps the CNR calculus precise, but makes the calculus (quicker|easier to read|...). Signed-off-by: your real name your@email Please read what's written on our Wiki for more details, at: http://linuxtv.org/wiki/index.php/Developer_Section Starting with: http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches There are too many weird violating codes in it. You need to provide us a way more detailed descriptions than just the above statement, as the above example E. g.: What is weird and where? What's being violated and where? What you're proposing to solve it? Regards, Mauro Thanks -Bud 2014-10-03 13:54 GMT+09:00 Antti Palosaari cr...@iki.fi: On 10/02/2014 09:49 PM, Буди Романто, AreMa Inc wrote: DVB driver for Earthsoft PT3 PCIE ISDB-S/T receiver ^^^ Status: stable Changes: - demod tuners converted to I2C binding model - i586 x86_64 clean compile - lightweight yet precise CNR calculus - raw CNR (DVBv3) - DVBv5 CNR @ 0.0001 dB (ref: include/uapi/linux/dvb/frontend.h, not 1/1000 dB!) - removed (unused?) tuner's *_release() - demod/tuner binding: pt3_unregister_subdev(), pt3_unregister_subdev() - some cleanups These drivers are already committed, like you have noticed. There is surely a lot of issues that could be improved, but it cannot be done by big patch which replaces everything. You need to just take one issue at the time, fix/improve it, send patch to mailing list for review. One patch per one logical change. regards Antti -- 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
Re: [coda6] Error while decoding second h.264 chunk
Hi, Do you have time to take a look at this (with the PC values) ? On 09/30/2014 09:54 AM, Gaëtan Carlier wrote: Hi, The problem can also come from register address or bit offset because depending source used (GStreamer for 2.6.22 or new coda kernel driver 3.6 or datasheet), registers do not have same addresses or do not even exists ! On 09/30/2014 08:00 AM, Gaëtan Carlier wrote: Hi Philipp and Fabio, First of all, thanks a lot for your reply. On 09/29/2014 03:53 PM, Philipp Zabel wrote: Hi Gaëtan, Am Mittwoch, den 24.09.2014, 11:18 +0200 schrieb Gaëtan Carlier: Hello Dears, I am back with my Coda6 (i.MX27). I have ported decoding from libvpu code to kernel 3.6 but I have a little problem. DEC_SEQ_INIT runs fine, the internal RdPtr increases by 512 bytes but when I run the DEC_PIC_RUN (PRESCAN disabled), the RdPTr has increased to 1024 (0x400), but macroblock error are reported and next DEC_PIC_RUN does not increase anymore the internal RdPtr. If I enable PRESCAN, the first DEC_PIC_RUN does not event finish (timeout). where is the PC pointer at when it times out? Maybe do a complete register dump before DEC_PIC_RUN and after the timeout to see if something stands out. I will do that and post reply today (I really don't know what to do with Program Counter of the FW. I hope you do :)). Here is the dump reg when PRESCAN is enable (and leads to timeout): Chunk 0[6269] : key frame 67 (0001674218D4) Chunk 1[1154] : frame 41 (0001419AFFBF) Chunk 2[1293] : frame 41 (0001419A8110) Chunk 3[1256] : frame 41 (0001419A7590) Chunk 4[1887] : frame 41 (0001419A0989) Chunk 5[2609] : frame 41 (0001419A6E54) Chunk 6[2463] : frame 41 (0001419A0865) Chunk 7[2087] : frame 41 (0001419AB42D) Chunk 8[2394] : frame 41 (0001419AB52F) Chunk 9[2210] : frame 41 (0001419A2CC2) coda_fill_decoder_bitstreambuf - c8c7f000 - 6269 bytes added - 6269 bytes bufferd WrPtr @ a73c187d - RdPtr @ a73c 0001674218D4 coda coda-imx27.0: Int occurs : 0002 CODA_REG_DEC_FUNC_CTRL (0x0114): CODA_RET_DEC_SEQ_SRC_SIZE (0x01C4): 000A01E0 CODA_RET_DEC_SEQ_SRC_F_RATE (0x01C8): CODA_RET_DEC_SEQ_FRAME_NEED (0x01CC): 0003 CODA_RET_DEC_SEQ_FRAME_DELAY (0x01D0): CODA_RET_DEC_SEQ_INFO (0x01D4): CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT (0x01D8): CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM (0x01DC): CODA_RET_DEC_SEQ_NEXT_FRAME_NUM (0x01E0): 0001 CODA_REG_BIT_RUN_INDEX (0x0168): CODA_REG_BIT_RD_PTR0 (0x0120): A73C0200 CODA_REG_BIT_WR_PTR0 (0x0124): A73C187D Framebuffers allocated 10 coda coda-imx27.0: Int occurs : 0010 coda_device_run_decoder coda_fill_decoder_bitstreambuf - c8d8 - 1154 bytes added - 7423 bytes bufferd WrPtr @ a73c1cff - RdPtr @ a73c0200 0001419AFFBF CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0069 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 coda coda-imx27.0: CODA PIC_RUN timeout, stopping all streams CODA_RET_DEC_PIC_FRAME_NUM (0x01C0): 0001 size 460800 CODA_RET_DEC_PIC_IDX (0x01C4): 000A01E0 CODA_RET_DEC_PIC_ERR_MB_NUM (0x01C8): CODA_RET_DEC_PIC_TYPE (0x01CC): 0003 CODA_RET_DEC_PIC_SUCCESS (0x01D4): 0003 CODA_RET_DEC_PIC_OPTION (0x01D0): CODA_RET_DEC_PIC_CUR_IDX (0x01DC): CODA_RET_DEC_PIC_NEXT_IDX (0x01E0): 0001 CODA_REG_BIT_INT_STATUS (0x0010): CODA_REG_BIT_CUR_PC (0x0018): 0DC6 CODA_REG_BIT_CODE_BUF_ADDR (0x0100): A713 CODA_REG_BIT_WORK_BUF_ADDR (0x0104): A720 CODA_REG_BIT_PARA_BUF_ADDR (0x0108): A730 CODA_REG_BIT_STREAM_CTRL (0x010C): 0006 CODA_REG_BIT_FRAME_MEM_CTRL (0x0110): CODA_REG_DEC_FUNC_CTRL (0x0114): CODADX6_REG_BIT_SEARCH_RAM_BASE_ADDR (0x0140): 4C00 I attach the kernel driver (+fw), the h264 raw file (encoded using this coda6 driver and played without error using ffplay), the userspace test program and the log file. Can you give me some advise to know where to search. I have tried to reset WrPtr and RdPtr before first DEC_PIC_RUN and reload h264 raw file from the beginning, let RdPtr and WrPtr unchanged and h264 raw file from the beginning but this is even worst... I don't think you are supposed to write RdPtr. That is what I think too but I have tried many things before asking help :) It is under firmware control, at least between SEQ_INIT and SEQ_END. There is a DEC_BUF_FLUSH command, maybe that does what you need. I supposed that DEC_BUF_FLUSH command is needed after DEC_PIC_RUN command in case of last chunk or one frame decoding. As my problem occurs while this first DEC_PIC_RUN, I don't even try to implement
[GIT PULL for v3.17] si2165 firmware changes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/topic/si2165-v3.17-rc8 For some changes at the si2165 firmware name and the removal of an extra unneeded header added artificially via the script that extracts it from the original driver provided by the manufacturer. The si2165 is a new driver that was added for v3.17. There are two issues with the current firmware format: - The firmware only covers one specific revision of the chipset (Rev. D). We'll be adding support for another revision for v3.18, so it would be better to rename the firmware file to reflect the revision on its name: -#define SI2165_FIRMWARE dvb-demod-si2165.fw +#define SI2165_FIRMWARE_REV_D dvb-demod-si2165-d.fw - Instead of containing a single blob with the firmware, the file also contains some meta-data that could be determined on some other way directly by the driver. The script that gets the firmware from the Internet was also updated accordingly to not add the extra header. Thanks! Mauro The following changes since commit 90a5dbef1a66e9f55b76ccb83c0ef27c0bd87c27: Revert [media] media: em28xx - remove reset_resume interface (2014-09-28 22:25:24 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/topic/si2165-v3.17-rc8 for you to fetch changes up to 3173fbdce9e41fc4fabe0b3dedd99c615f47dbdd: [media] [V2,2/2] si2165: do load firmware without extra header (2014-10-02 18:18:52 -0300) topic/si2165 fixes for v3.17-rc8 Matthias Schwarzott (2): [media] [V2, 1/2] get_dvb_firmware: si2165: drop the extra header from the firmware [media] [V2,2/2] si2165: do load firmware without extra header Documentation/dvb/get_dvb_firmware| 20 ++ drivers/media/dvb-frontends/Kconfig | 1 + drivers/media/dvb-frontends/si2165.c | 107 ++ drivers/media/dvb-frontends/si2165_priv.h | 2 +- 4 files changed, 71 insertions(+), 59 deletions(-) -- 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 v3.17] si2165 firmware changes
Yeah, this is pure crap. It doesn't even compile. drivers/media/dvb-frontends/si2165.c:1063:17: error: expected ‘,’ or ‘;’ before ‘SI2165_FIRMWARE’ MODULE_FIRMWARE(SI2165_FIRMWARE); because it should presumably say SI2165_FIRMWARE_REV_D now. Why the f*ck do you send me totally untested crap? Linus On Fri, Oct 3, 2014 at 11:05 AM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/topic/si2165-v3.17-rc8 For some changes at the si2165 firmware name and the removal of an extra unneeded header added artificially via the script that extracts it from the original driver provided by the manufacturer. The si2165 is a new driver that was added for v3.17. There are two issues with the current firmware format: - The firmware only covers one specific revision of the chipset (Rev. D). We'll be adding support for another revision for v3.18, so it would be better to rename the firmware file to reflect the revision on its name: -#define SI2165_FIRMWARE dvb-demod-si2165.fw +#define SI2165_FIRMWARE_REV_D dvb-demod-si2165-d.fw - Instead of containing a single blob with the firmware, the file also contains some meta-data that could be determined on some other way directly by the driver. The script that gets the firmware from the Internet was also updated accordingly to not add the extra header. Thanks! Mauro The following changes since commit 90a5dbef1a66e9f55b76ccb83c0ef27c0bd87c27: Revert [media] media: em28xx - remove reset_resume interface (2014-09-28 22:25:24 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/topic/si2165-v3.17-rc8 for you to fetch changes up to 3173fbdce9e41fc4fabe0b3dedd99c615f47dbdd: [media] [V2,2/2] si2165: do load firmware without extra header (2014-10-02 18:18:52 -0300) topic/si2165 fixes for v3.17-rc8 Matthias Schwarzott (2): [media] [V2, 1/2] get_dvb_firmware: si2165: drop the extra header from the firmware [media] [V2,2/2] si2165: do load firmware without extra header Documentation/dvb/get_dvb_firmware| 20 ++ drivers/media/dvb-frontends/Kconfig | 1 + drivers/media/dvb-frontends/si2165.c | 107 ++ drivers/media/dvb-frontends/si2165_priv.h | 2 +- 4 files changed, 71 insertions(+), 59 deletions(-) -- 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 1/1] media: Print information on failed link validation
From: Sakari Ailus sakari.ai...@linux.intel.com
The Media controller doesn't tell much to the user in cases such as pipeline
startup failure. The link validation is the most common media graph (or in
V4L2's case, format) related reason for the failure. In more complex
pipelines the reason may not always be obvious to the user, so point them to
look at the right direction.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/media-entity.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 37c334e..a6cb6b6 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -279,8 +279,14 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
continue;
ret = entity-ops-link_validate(link);
- if (ret 0 ret != -ENOIOCTLCMD)
+ if (ret 0 ret != -ENOIOCTLCMD) {
+ dev_dbg(entity-parent-dev,
+ link validation failed for \%s\:%u
- \%s\:%u, error %d\n,
+ entity-name, link-source-index,
+ link-sink-entity-name,
+ link-sink-index, ret);
goto error;
+ }
}
/* Either no links or validated links are fine. */
@@ -288,6 +294,11 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
if (!bitmap_full(active, entity-num_pads)) {
ret = -EPIPE;
+ dev_dbg(entity-parent-dev,
+ entity %s has pad %u must be connected by an
enabled link, error %d\n,
+ entity-name,
+ find_first_zero_bit(active, entity-num_pads),
+ ret);
goto error;
}
}
--
1.7.10.4
--
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
randconfig build error with next-20141003, in drivers/media/usb/gspca/gspca.c
Building with the attached random configuration file, drivers/built-in.o: In function `gspca_disconnect': /home/jim/linux/drivers/media/usb/gspca/gspca.c:2190: undefined reference to `input_unregister_device' drivers/built-in.o: In function `gspca_input_connect': /home/jim/linux/drivers/media/usb/gspca/gspca.c:162: undefined reference to `input_allocate_device' /home/jim/linux/drivers/media/usb/gspca/gspca.c:178: undefined reference to `input_register_device' /home/jim/linux/drivers/media/usb/gspca/gspca.c:183: undefined reference to `input_free_device' drivers/built-in.o: In function `gspca_dev_probe2': /home/jim/linux/drivers/media/usb/gspca/gspca.c:2130: undefined reference to `input_unregister_device' drivers/built-in.o: In function `input_report_key': /home/jim/linux/include/linux/input.h:392: undefined reference to `input_event' drivers/built-in.o: In function `input_sync': /home/jim/linux/include/linux/input.h:417: undefined reference to `input_event' drivers/built-in.o: In function `input_report_key': /home/jim/linux/include/linux/input.h:392: undefined reference to `input_event' drivers/built-in.o: In function `input_sync': /home/jim/linux/include/linux/input.h:417: undefined reference to `input_event' drivers/built-in.o: In function `input_report_key': /home/jim/linux/include/linux/input.h:392: undefined reference to `input_event' drivers/built-in.o:/home/jim/linux/include/linux/input.h:417: more undefined references to `input_event' follow make: *** [vmlinux] Error 1 # # Automatically generated file; DO NOT EDIT. # Linux/x86 3.17.0-rc7 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y # CONFIG_TASK_IO_ACCOUNTING is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TASKS_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_FREEZER is not set CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set CONFIG_CGROUP_HUGETLB=y # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED
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: Sat Oct 4 04:00:15 CEST 2014 git branch: test git hash: cf3167cf1e969b17671a4d3d956d22718a8ceb85 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-20-g7abd8a7 host hardware: x86_64 host os:3.16-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: 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.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: 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: OK 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: OK linux-3.16-i686: OK linux-3.17-rc1-i686: OK linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: 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: OK 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-x86_64: WARNINGS linux-3.17-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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
Re: [PATCH 1/2] af9033: fix DVBv3 signal strength value not correct issue
Hello
I did some review and testing. Before that patch, IT9133 DVBv3 signal
strength measurement was broken - it returned 0x all the time. After
that is returns some realistic values between 0-0x.
Anyhow, AF9033 chip version it worked earlier too, just like old comment
says hw returns 0-100, which was scaled to 0-0x.
AF9033 and IT9133 firmware differs on signal strength measurement. For
AF9033 it provides both percentage and dBm reports, for IT9133 I know
only dBm report.
AF9033:
0x800048 relative (0-100, percentage)
0x80004a decibel (-VAL dBm)
IT9133:
0x8000f7 decibel (VAL - 100 dBm)
Now you changed that AF9033 implementation from 0x800048 (percentage) to
0x80004a (dBm) and scale that to 0-0x, which results poorer result
than old implementation calculated by firmware.
What I tested that implementation, it gives maximum value 0x6e14, which
we could calc is 43dBm. I was using -18dBm RF level (which is very very
strong), so I suspect that 43dBm is maximum what firmware even could
report. Having maximum possible signal strength only 43% (out of 100%)
is not nice.
So I ask you change AF9035 as it has been (percentage reported by FW).
Change only non-working IT9135 what you like.
Also, add error checking just after register reads and jump out if fails.
regards
Antti
On 10/02/2014 08:32 AM, Bimow Chen wrote:
Register 0x800048 is not dB measure but relative scale. Fix it and conform to
NorDig specifications.
0001-af9033-fix-DVBv3-signal-strength-value-not-correct-i.patch
From 02ee7de4600a43a322f75cf04d273effa04d3a42 Mon Sep 17 00:00:00 2001
From: Bimow Chenbimow.c...@ite.com.tw
Date: Wed, 1 Oct 2014 18:28:54 +0800
Subject: [PATCH 1/2] af9033: fix DVBv3 signal strength value not correct issue
Register 0x800048 is not dB measure but relative scale. Fix it and conform to
NorDig specifications.
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
---
drivers/media/dvb-frontends/af9033.c | 43 +++-
drivers/media/dvb-frontends/af9033_priv.h |6
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 63a89c1..2b3d2f0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -862,16 +862,43 @@ static int af9033_read_snr(struct dvb_frontend *fe, u16
*snr)
static int af9033_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
{
struct af9033_dev *dev = fe-demodulator_priv;
- int ret;
- u8 strength2;
+ struct dtv_frontend_properties *c = dev-fe.dtv_property_cache;
+ int ret, tmp, power_real;
+ u8 u8tmp, gain_offset, buf[7];
- /* read signal strength of 0-100 scale */
- ret = af9033_rd_reg(dev, 0x800048, strength2);
- if (ret 0)
- goto err;
+ if (dev-is_af9035) {
+ ret = af9033_rd_reg(dev, 0x80004a, u8tmp);
+ /* scale value to 0x-0x */
+ *strength = u8tmp * 0x / 100;
+ } else {
+ ret = af9033_rd_reg(dev, 0x8000f7, u8tmp);
+ ret |= af9033_rd_regs(dev, 0x80f900, buf, 7);
+
+ if (c-frequency = 3)
+ gain_offset = 7; /* VHF */
+ else
+ gain_offset = 4; /* UHF */
+
+ power_real = (u8tmp - 100 - gain_offset) -
+ power_reference[((buf[3] 0) 3)][((buf[6] 0)
7)];
+
+ if (power_real -15)
+ tmp = 0;
+ else if ((power_real = -15) (power_real 0))
+ tmp = (2 * (power_real + 15)) / 3;
+ else if ((power_real = 0) (power_real 20))
+ tmp = 4 * power_real + 10;
+ else if ((power_real = 20) (power_real 35))
+ tmp = (2 * (power_real - 20)) / 3 + 90;
+ else
+ tmp = 100;
+
+ /* scale value to 0x-0x */
+ *strength = tmp * 0x / 100;
+ }
- /* scale value to 0x-0x */
- *strength = strength2 * 0x / 100;
+ if (ret)
+ goto err;
return 0;
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index c12c92c..c9c8798 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -2051,4 +2051,10 @@ static const struct reg_val tuner_init_it9135_62[] = {
{ 0x80fd8b, 0x00 },
};
+/* NorDig power reference table */
+static const int power_reference[][5] = {
+ {-93, -91, -90, -89, -88}, /* QPSK 1/2 ~ 7/8 */
+ {-87, -85, -84, -83, -82}, /* 16QAM 1/2 ~ 7/8 */
+ {-82, -80, -78, -77, -76}, /* 64QAM 1/2 ~ 7/8 */
+};
#endif /* AF9033_PRIV_H */
-- 1.7.0.4
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
Re: [PATCH 2/2] af9033: fix DVBv3 snr value not correct issue
Moikka
That changes DVBv3 SNR reporting from 0.1dB units to relative between
0-0x. For AF9033 it has been 0.1dB ages and I would like to keep it
as it is. So add logic here to return 0.1dB as it did for AF9033 and do
what you like for IT9133.
On switch-case default branch af9033_stat_work() jumps out. That will
stop statistics polling. It is not hard error case you want to stop
polling, so you need to jump case where it schedules new work. Hard
errors where you like to stop polling are those I/O errors (reg read,
reg write).
Otherwise it looks OK.
regards
Antti
On 10/02/2014 08:34 AM, Bimow Chen wrote:
Snr returns value not correct. Fix it.
0002-af9033-fix-DVBv3-snr-value-not-correct-issue.patch
From 7b7d83e669e1c7a041241c7412fd05a5ca73815c Mon Sep 17 00:00:00 2001
From: Bimow Chenbimow.c...@ite.com.tw
Date: Thu, 2 Oct 2014 10:37:13 +0800
Subject: [PATCH 2/2] af9033: fix DVBv3 snr value not correct issue
Snr returns value not correct. Fix it.
Signed-off-by: Bimow Chenbimow.c...@ite.com.tw
---
drivers/media/dvb-frontends/af9033.c | 61 +++-
drivers/media/dvb-frontends/af9033_priv.h |5 ++-
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 2b3d2f0..ad4ff78 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -849,14 +849,42 @@ static int af9033_read_snr(struct dvb_frontend *fe, u16
*snr)
{
struct af9033_dev *dev = fe-demodulator_priv;
struct dtv_frontend_properties *c = dev-fe.dtv_property_cache;
+ int ret;
+ u8 u8tmp;
/* use DVBv5 CNR */
- if (c-cnr.stat[0].scale == FE_SCALE_DECIBEL)
- *snr = div_s64(c-cnr.stat[0].svalue, 100); /* 1000x = 10x */
- else
+ if (c-cnr.stat[0].scale == FE_SCALE_DECIBEL) {
+ *snr = div_s64(c-cnr.stat[0].svalue, 1000);
+
+ /* read current modulation */
+ ret = af9033_rd_reg(dev, 0x80f903, u8tmp);
+ if (ret)
+ goto err;
+
+ /* scale value to 0x-0x */
+ switch ((u8tmp 0) 3) {
+ case 0:
+ *snr = *snr * 0x / 23;
+ break;
+ case 1:
+ *snr = *snr * 0x / 26;
+ break;
+ case 2:
+ *snr = *snr * 0x / 32;
+ break;
+ default:
+ goto err;
+ }
+ } else {
*snr = 0;
+ }
return 0;
+
+err:
+ dev_dbg(dev-client-dev, failed=%d\n, ret);
+
+ return ret;
}
static int af9033_read_signal_strength(struct dvb_frontend *fe, u16 *strength)
@@ -1038,6 +1066,33 @@ static void af9033_stat_work(struct work_struct *work)
snr_val = (buf[2] 16) | (buf[1] 8) | (buf[0] 0);
+ /* read superframe number */
+ ret = af9033_rd_reg(dev, 0x80f78b, u8tmp);
+ if (ret)
+ goto err;
+
+ if (u8tmp)
+ snr_val /= u8tmp;
+
+ /* read current transmission mode */
+ ret = af9033_rd_reg(dev, 0x80f900, u8tmp);
+ if (ret)
+ goto err;
+
+ switch ((u8tmp 0) 3) {
+ case 0:
+ snr_val *= 4;
+ break;
+ case 1:
+ snr_val *= 1;
+ break;
+ case 2:
+ snr_val *= 2;
+ break;
+ default:
+ goto err;
+ }
+
/* read current modulation */
ret = af9033_rd_reg(dev, 0x80f903, u8tmp);
if (ret)
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index c9c8798..8e23275 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -181,7 +181,10 @@ static const struct val_snr qam64_snr_lut[] = {
{ 0x05570d, 26 },
{ 0x059feb, 27 },
{ 0x05bf38, 28 },
- { 0xff, 29 },
+ { 0x05f78f, 29 },
+ { 0x0612c3, 30 },
+ { 0x0626be, 31 },
+ { 0xff, 32 },
};
static const struct reg_val ofsm_init[] = {
-- 1.7.0.4
--
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
