VPU on iMX51 babbage board
Subsystems (3)
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed v4l-coda7541-imx53.bin in /lib/firmware
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of writing in VPU address space in the function coda_write of file driver/media/platform/coda/coda-common.c
Is there anything preventing the coda driver to work with iMX51? Could anyone provide any suggestion on how investigate the problem?
Thanks
Regards
Pierluigi
arch/arm/boot/dts/imx51-babbage.dts +5 -1
@@ -44,6 +44,7 @@ interface-pix-fmt = "rgb24"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ipu_disp1>; + status = "disabled"; display-timings { native-mode = <&timing0>; timing0: dvi {
@@ -71,7 +72,6 @@ interface-pix-fmt = "rgb565"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ipu_disp2>; - status = "disabled"; display-timings { native-mode = <&timing1>; timing1: claawvga {
@@ -338,6 +338,10 @@ status = "okay"; }; +&vpu { + status = "okay"; +}; + &i2c1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c1>;
arch/arm/boot/dts/imx51.dtsi +36 -1
@@ -143,9 +143,17 @@ }; ipu_di1: port@3 { + #address-cells = <1>; + #size-cells = <0>; reg = <3>; - ipu_di1_disp1: endpoint { + ipu_di1_disp1: endpoint@0 { + reg = <0>; + }; + + ipu_di1_tve: endpoint@2 { + reg = <2>; + remote-endpoint = <&tve_in>; }; }; };
@@ -578,6 +586,33 @@ clock-names = "ipg", "ahb", "ptp"; status = "disabled"; }; + + tve: tve@83ff0000 { + compatible = "fsl,imx53-tve"; + reg = <0x83ff0000 0x1000>; + interrupts = <92>; + clocks = <&clks IMX5_CLK_TVE_GATE>, + <&clks IMX5_CLK_IPU_DI1_SEL>; + clock-names = "tve", "di1_sel"; + status = "disabled"; + + port { + tve_in: endpoint { + remote-endpoint = <&ipu_di1_tve>; + }; + }; + }; + + vpu: vpu@83ff4000 { + compatible = "fsl,imx53-vpu"; + reg = <0x83ff4000 0x1000>; + interrupts = <9>; + clocks = <&clks IMX5_CLK_VPU_REFERENCE_GATE>, + <&clks IMX5_CLK_VPU_GATE>; + clock-names = "per", "ahb"; + resets = <&src 1>; + iram = <&iram>; + }; }; }; };
CONFIG_KERNEL_LZO=yCONFIG_SYSVIPC=yCONFIG_FHANDLE=yCONFIG_NO_HZ=yCONFIG_HIGH_RES_TIMERS=yCONFIG_LOG_BUF_SHIFT=18CONFIG_CGROUPS=yCONFIG_RELAY=yCONFIG_BLK_DEV_INITRD=yCONFIG_EXPERT=yCONFIG_PERF_EVENTS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not setCONFIG_MODULES=yCONFIG_MODULE_UNLOAD=yCONFIG_MODVERSIONS=yCONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_BLK_DEV_BSG is not setCONFIG_ARCH_MULTI_V6=yCONFIG_ARCH_MXC=yCONFIG_MACH_MX31LILLY=yCONFIG_MACH_MX31LITE=yCONFIG_MACH_PCM037=yCONFIG_MACH_PCM037_EET=yCONFIG_MACH_MX31_3DS=yCONFIG_MACH_MX31MOBOARD=yCONFIG_MACH_QONG=yCONFIG_MACH_ARMADILLO5X0=yCONFIG_MACH_KZM_ARM11_01=yCONFIG_MACH_IMX31_DT=yCONFIG_MACH_IMX35_DT=yCONFIG_MACH_PCM043=yCONFIG_MACH_MX35_3DS=yCONFIG_MACH_VPR200=yCONFIG_SOC_IMX50=yCONFIG_SOC_IMX51=yCONFIG_SOC_IMX53=yCONFIG_SOC_IMX6Q=yCONFIG_SOC_IMX6SL=yCONFIG_SOC_IMX6SX=yCONFIG_SOC_VF610=yCONFIG_PCI=yCONFIG_PCI_IMX6=yCONFIG_SMP=yCONFIG_VMSPLIT_2G=yCONFIG_PREEMPT_VOLUNTARY=yCONFIG_AEABI=yCONFIG_HIGHMEM=yCONFIG_CMA=yCONFIG_CMDLINE="noinitrd console=ttymxc0,115200"CONFIG_CPU_FREQ=yCONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=yCONFIG_ARM_IMX6Q_CPUFREQ=yCONFIG_VFP=yCONFIG_NEON=yCONFIG_BINFMT_MISC=mCONFIG_PM_RUNTIME=yCONFIG_PM_DEBUG=yCONFIG_PM_TEST_SUSPEND=yCONFIG_NET=yCONFIG_PACKET=yCONFIG_UNIX=yCONFIG_INET=yCONFIG_IP_PNP=yCONFIG_IP_PNP_DHCP=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not setCONFIG_IPV6=yCONFIG_NETFILTER=yCONFIG_CAN=yCONFIG_CAN_FLEXCAN=yCONFIG_CFG80211=yCONFIG_MAC80211=yCONFIG_RFKILL=yCONFIG_RFKILL_INPUT=yCONFIG_DEVTMPFS=yCONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not setCONFIG_FW_LOADER_USER_HELPER_FALLBACK=yCONFIG_DMA_CMA=yCONFIG_IMX_WEIM=yCONFIG_CONNECTOR=yCONFIG_MTD=yCONFIG_MTD_CMDLINE_PARTS=yCONFIG_MTD_BLOCK=yCONFIG_MTD_CFI=yCONFIG_MTD_JEDECPROBE=yCONFIG_MTD_CFI_INTELEXT=yCONFIG_MTD_CFI_AMDSTD=yCONFIG_MTD_CFI_STAA=yCONFIG_MTD_PHYSMAP_OF=yCONFIG_MTD_DATAFLASH=yCONFIG_MTD_M25P80=yCONFIG_MTD_SST25L=yCONFIG_MTD_NAND=yCONFIG_MTD_NAND_GPMI_NAND=yCONFIG_MTD_NAND_MXC=yCONFIG_MTD_SPI_NOR=yCONFIG_MTD_UBI=yCONFIG_BLK_DEV_LOOP=yCONFIG_BLK_DEV_RAM=yCONFIG_BLK_DEV_RAM_SIZE=65536CONFIG_EEPROM_AT24=yCONFIG_EEPROM_AT25=y
# CONFIG_SCSI_PROC_FS is not setCONFIG_BLK_DEV_SD=yCONFIG_SCSI_CONSTANTS=yCONFIG_SCSI_LOGGING=yCONFIG_SCSI_SCAN_ASYNC=y
# CONFIG_SCSI_LOWLEVEL is not setCONFIG_ATA=yCONFIG_SATA_AHCI_PLATFORM=yCONFIG_AHCI_IMX=yCONFIG_PATA_IMX=yCONFIG_NETDEVICES=y
# CONFIG_NET_VENDOR_BROADCOM is not set
CONFIG_CS89x0=y
CONFIG_CS89x0_PLATFORM=y
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_NET_VENDOR_SEEQ is not setCONFIG_SMC91X=yCONFIG_SMC911X=yCONFIG_SMSC911X=y
# CONFIG_NET_VENDOR_STMICRO is not setCONFIG_AT803X_PHY=yCONFIG_BRCMFMAC=m
# CONFIG_INPUT_MOUSEDEV_PSAUX is not setCONFIG_INPUT_EVDEV=yCONFIG_INPUT_EVBUG=mCONFIG_KEYBOARD_GPIO=yCONFIG_KEYBOARD_IMX=yCONFIG_MOUSE_PS2=mCONFIG_MOUSE_PS2_ELANTECH=yCONFIG_INPUT_TOUCHSCREEN=yCONFIG_TOUCHSCREEN_EGALAX=yCONFIG_TOUCHSCREEN_MC13783=yCONFIG_TOUCHSCREEN_TSC2007=yCONFIG_TOUCHSCREEN_STMPE=yCONFIG_INPUT_MISC=yCONFIG_INPUT_MMA8450=yCONFIG_SERIO_SERPORT=m
# CONFIG_LEGACY_PTYS is not set
# CONFIG_DEVKMEM is not setCONFIG_SERIAL_IMX=yCONFIG_SERIAL_IMX_CONSOLE=yCONFIG_SERIAL_FSL_LPUART=yCONFIG_SERIAL_FSL_LPUART_CONSOLE=yCONFIG_HW_RANDOM=y
# CONFIG_I2C_COMPAT is not setCONFIG_I2C_CHARDEV=y
# CONFIG_I2C_HELPER_AUTO is not setCONFIG_I2C_ALGOPCF=mCONFIG_I2C_ALGOPCA=mCONFIG_I2C_IMX=yCONFIG_SPI=yCONFIG_SPI_IMX=yCONFIG_GPIO_SYSFS=yCONFIG_GPIO_MC9S08DZ60=yCONFIG_GPIO_STMPE=y
# CONFIG_HWMON is not setCONFIG_WATCHDOG=yCONFIG_IMX2_WDT=yCONFIG_MFD_DA9052_I2C=yCONFIG_MFD_MC13XXX_SPI=yCONFIG_MFD_MC13XXX_I2C=yCONFIG_MFD_STMPE=yCONFIG_REGULATOR=yCONFIG_REGULATOR_FIXED_VOLTAGE=yCONFIG_REGULATOR_ANATOP=yCONFIG_REGULATOR_DA9052=yCONFIG_REGULATOR_GPIO=yCONFIG_REGULATOR_MC13783=yCONFIG_REGULATOR_MC13892=yCONFIG_REGULATOR_PFUZE100=yCONFIG_MEDIA_SUPPORT=yCONFIG_MEDIA_CAMERA_SUPPORT=yCONFIG_MEDIA_RC_SUPPORT=yCONFIG_RC_DEVICES=yCONFIG_IR_GPIO_CIR=yCONFIG_V4L_PLATFORM_DRIVERS=yCONFIG_SOC_CAMERA=yCONFIG_VIDEO_MX3=yCONFIG_V4L_MEM2MEM_DRIVERS=yCONFIG_VIDEO_CODA=yCONFIG_SOC_CAMERA_OV2640=yCONFIG_IMX_IPUV3_CORE=yCONFIG_DRM=yCONFIG_DRM_PANEL_SIMPLE=yCONFIG_LCD_CLASS_DEVICE=yCONFIG_LCD_L4F00242T03=yCONFIG_LCD_PLATFORM=yCONFIG_BACKLIGHT_PWM=yCONFIG_BACKLIGHT_GPIO=yCONFIG_FRAMEBUFFER_CONSOLE=yCONFIG_LOGO=yCONFIG_SOUND=yCONFIG_SND=yCONFIG_SND_SOC=yCONFIG_SND_IMX_SOC=yCONFIG_SND_SOC_PHYCORE_AC97=yCONFIG_SND_SOC_EUKREA_TLV320=yCONFIG_SND_SOC_IMX_WM8962=yCONFIG_SND_SOC_IMX_SGTL5000=yCONFIG_SND_SOC_IMX_SPDIF=yCONFIG_SND_SOC_IMX_MC13783=yCONFIG_USB=yCONFIG_USB_EHCI_HCD=yCONFIG_USB_EHCI_MXC=yCONFIG_USB_STORAGE=yCONFIG_USB_CHIPIDEA=yCONFIG_USB_CHIPIDEA_UDC=yCONFIG_USB_CHIPIDEA_HOST=yCONFIG_NOP_USB_XCEIV=yCONFIG_USB_MXS_PHY=yCONFIG_USB_GADGET=yCONFIG_USB_ETH=mCONFIG_USB_MASS_STORAGE=mCONFIG_MMC=yCONFIG_MMC_SDHCI=yCONFIG_MMC_SDHCI_PLTFM=yCONFIG_MMC_SDHCI_ESDHC_IMX=yCONFIG_NEW_LEDS=yCONFIG_LEDS_CLASS=yCONFIG_LEDS_GPIO=yCONFIG_LEDS_TRIGGERS=yCONFIG_LEDS_TRIGGER_TIMER=yCONFIG_LEDS_TRIGGER_ONESHOT=yCONFIG_LEDS_TRIGGER_HEARTBEAT=yCONFIG_LEDS_TRIGGER_BACKLIGHT=yCONFIG_LEDS_TRIGGER_GPIO=yCONFIG_RTC_CLASS=yCONFIG_RTC_INTF_DEV_UIE_EMUL=yCONFIG_RTC_DRV_PCF8563=yCONFIG_RTC_DRV_MC13XXX=yCONFIG_RTC_DRV_MXC=yCONFIG_RTC_DRV_SNVS=yCONFIG_DMADEVICES=yCONFIG_IMX_SDMA=yCONFIG_MXS_DMA=yCONFIG_FSL_EDMA=yCONFIG_STAGING=yCONFIG_DRM_IMX=yCONFIG_DRM_IMX_FB_HELPER=yCONFIG_DRM_IMX_PARALLEL_DISPLAY=yCONFIG_DRM_IMX_TVE=yCONFIG_DRM_IMX_LDB=yCONFIG_DRM_IMX_IPUV3=yCONFIG_DRM_IMX_HDMI=y
# CONFIG_IOMMU_SUPPORT is not setCONFIG_PWM=yCONFIG_PWM_IMX=yCONFIG_EXT2_FS=yCONFIG_EXT2_FS_XATTR=yCONFIG_EXT2_FS_POSIX_ACL=yCONFIG_EXT2_FS_SECURITY=yCONFIG_EXT3_FS=yCONFIG_EXT3_FS_POSIX_ACL=yCONFIG_EXT3_FS_SECURITY=yCONFIG_EXT4_FS=yCONFIG_EXT4_FS_POSIX_ACL=yCONFIG_EXT4_FS_SECURITY=yCONFIG_QUOTA=yCONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not setCONFIG_AUTOFS4_FS=yCONFIG_FUSE_FS=yCONFIG_ISO9660_FS=mCONFIG_JOLIET=yCONFIG_ZISOFS=yCONFIG_UDF_FS=mCONFIG_MSDOS_FS=mCONFIG_VFAT_FS=yCONFIG_TMPFS=yCONFIG_JFFS2_FS=yCONFIG_UBIFS_FS=yCONFIG_NFS_FS=yCONFIG_NFS_V3_ACL=yCONFIG_NFS_V4=yCONFIG_ROOT_NFS=yCONFIG_NLS_DEFAULT="cp437"CONFIG_NLS_CODEPAGE_437=yCONFIG_NLS_ASCII=yCONFIG_NLS_ISO8859_1=yCONFIG_NLS_ISO8859_15=mCONFIG_NLS_UTF8=yCONFIG_PRINTK_TIME=yCONFIG_DEBUG_FS=yCONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHED_DEBUG is not setCONFIG_PROVE_LOCKING=y
# CONFIG_DEBUG_BUGVERBOSE is not set
# CONFIG_FTRACE is not set
# CONFIG_ARM_UNWIND is not setCONFIG_SECURITYFS=y
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_HW is not setCONFIG_CRC_CCITT=mCONFIG_CRC_T10DIF=yCONFIG_CRC7=mCONFIG_LIBCRC32C=mCONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
Fabio Estevam
reviewerQuoted 9 lines · Pierluigi Passaro
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed v4l-coda7541-imx53.bin in/lib/firmware
Quoted 8 lines
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of writing in VPU address space in the function
coda_writeof filedriver/media/platform/coda/coda-common.cIs there anything preventing the coda driver to work with iMX51? Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the mx51.dtsi you would need this:
arch/arm/boot/dts/imx51.dtsi +13 -0
@@ -121,6 +121,7 @@ iram: iram@1ffe0000 { compatible = "mmio-sram"; reg = <0x1ffe0000 0x20000>; + clocks = <&clks IMX5_CLK_OCRAM>; }; ipu: ipu@40000000 {
@@ -584,6 +585,18 @@ clock-names = "ipg", "ahb", "ptp"; status = "disabled"; }; + + vpu: vpu@83ff4000 { + compatible = "fsl,imx53-vpu"; + reg = <0x83ff4000 0x1000>; + interrupts = <9>; + clocks = <&clks IMX5_CLK_VPU_REFERENCE_GATE>, + <&clks IMX5_CLK_VPU_GATE>; + clock-names = "per", "ahb"; + resets = <&src 1>; + iram = <&iram>; + }; }; + }; };
Also, not sure if all the required coda patches are available in 3.18, so I tried it on linux-next 20141210 on a imx51-babbage (I had to disable USB, otherwise linux-next will hang on this board):
[ 1.368454] coda 83ff4000.vpu: Initialized CODA7541. [ 1.373572] coda 83ff4000.vpu: Firmware version: 1.4.50 [ 1.396695] coda 83ff4000.vpu: codec registered as /dev/video[0-3]
Also, no sure if we need to distinguish mx51 versus mx53 in the coda driver.
Adding Philipp in case he can comment.
Regards,
Fabio Estevam
Am Mittwoch, den 10.12.2014, 22:04 -0200 schrieb Fabio Estevam:
Quoted 34 lines
Quoted 9 lines · Pierluigi Passaro
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed v4l-coda7541-imx53.bin in/lib/firmwareQuoted 8 lines
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of writing in VPU address space in the function
coda_writeof filedriver/media/platform/coda/coda-common.cIs there anything preventing the coda driver to work with iMX51? Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsiyou would need this:arch/arm/boot/dts/imx51.dtsi +1
-0@@ -121,6 +121,7 @@ iram: iram@1ffe0000 { compatible = "mmio-sram"; reg = <0x1ffe0000 0x20000>; + clocks = <&clks IMX5_CLK_OCRAM>; }; ipu: ipu@40000000 {
arch/arm/boot/dts/imx51.dtsi line 590
Quoted 6 lines
arch/arm/boot/dts/imx51.dtsi +3
-0@@ -584,6 +585,18 @@ clock-names = "ipg", "ahb", "ptp"; status = "disabled"; }; + + vpu: vpu@83ff4000 { + compatible = "fsl,imx53-vpu";
This should be "fsl,imx51-vpu", and add a "cnm,codahx14".
According to the old imx-vpu-lib code and the vpu_fw_imx51.bin firmware file, the i.MX51 has a CodaHx14 (0xF00A) as opposed to the i.MX53's Coda7541 (0xF012).
Quoted 17 lines
arch/arm/boot/dts/imx51.dtsi +9
-0+ reg = <0x83ff4000 0x1000>; + interrupts = <9>; + clocks = <&clks IMX5_CLK_VPU_REFERENCE_GATE>, + <&clks IMX5_CLK_VPU_GATE>; + clock-names = "per", "ahb"; + resets = <&src 1>; + iram = <&iram>; + }; }; + }; };Also, not sure if all the required coda patches are available in 3.18, so I tried it on linux-next 20141210 on a imx51-babbage (I had to disable USB, otherwise linux-next will hang on this board):
Quoted 7 lines
[ 1.368454] coda 83ff4000.vpu: Initialized CODA7541. [ 1.373572] coda 83ff4000.vpu: Firmware version: 1.4.50 [ 1.396695] coda 83ff4000.vpu: codec registered as /dev/video[0-3]Also, no sure if we need to distinguish mx51 versus mx53 in the coda driver.
Adding Philipp in case he can comment.
Yes, the i.MX51 and i.MX53 firmware files are different. So at least an entry for i.MX51 with the correct firmware file name has to be added.
regards
Philipp
Quoted 42 lines · Philipp Zabel
Am Mittwoch, den 10.12.2014, 22:04 -0200 schrieb Fabio Estevam:
Quoted 33 lines
Quoted 9 lines · Pierluigi Passaro
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed v4l-coda7541-imx53.bin in/lib/firmwareQuoted 8 lines
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of writing in VPU address space in the function
coda_writeof filedriver/media/platform/coda/coda-common.cIs there anything preventing the coda driver to work with iMX51? Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsiyou would need this:arch/arm/boot/dts/imx51.dtsi +1
-0@@ -121,6 +121,7 @@ iram: iram@1ffe0000 { compatible = "mmio-sram"; reg = <0x1ffe0000 0x20000>; + clocks = <&clks IMX5_CLK_OCRAM>; }; ipu: ipu@40000000 {arch/arm/boot/dts/imx51.dtsi line 590
Quoted 6 lines
arch/arm/boot/dts/imx51.dtsi +3
-0@@ -584,6 +585,18 @@ clock-names = "ipg", "ahb", "ptp"; status = "disabled"; }; + + vpu: vpu@83ff4000 { + compatible = "fsl,imx53-vpu";This should be "fsl,imx51-vpu", and add a "cnm,codahx14".
Quoted 4 lines
According to the old imx-vpu-lib code and the vpu_fw_imx51.bin firmware file, the i.MX51 has a CodaHx14 (
0xF00A) as opposed to the i.MX53's Coda7541 (0xF012).
Thanks for the hint, I'm now going through the old imx-vpu-lib to understand the CodaHX14 behaviour.
In old imx-vpu-lib, file vpu_util.c, there is a comment that make me doubtful: "i.MX51 has no secondary AXI memory, but use on chip RAM". As far as I understood, the portion of coda driver affected from this comment should be around the function coda_setup_iram in coda-bit.c. How am I supposed to manage this information?
Have I to avoid to use iram for iMX51 (and return on !dev->iram.vaddr) or go through the function without managing any CodaHX14 specific behaviour?
Quoted 21 lines
Quoted 21 lines
arch/arm/boot/dts/imx51.dtsi +9
-0+ reg = <0x83ff4000 0x1000>; + interrupts = <9>; + clocks = <&clks IMX5_CLK_VPU_REFERENCE_GATE>, + <&clks IMX5_CLK_VPU_GATE>; + clock-names = "per", "ahb"; + resets = <&src 1>; + iram = <&iram>; + }; }; + }; };Also, not sure if all the required coda patches are available in 3.18, so I tried it on linux-next 20141210 on a imx51-babbage (I had to disable USB, otherwise linux-next will hang on this board):
[ 1.368454] coda 83ff4000.vpu: Initialized CODA7541. [ 1.373572] coda 83ff4000.vpu: Firmware version: 1.4.50 [ 1.396695] coda 83ff4000.vpu: codec registered as /dev/video[0-3]
Quoted 8 lines
Quoted 3 lines
Also, no sure if we need to distinguish mx51 versus mx53 in the coda driver.
Adding Philipp in case he can comment.
Yes, the i.MX51 and i.MX53 firmware files are different. So at least an entry for i.MX51 with the correct firmware file name has to be added.
regards
Philipp
Thanks
Regards
Pierluigi
Am Freitag, den 12.12.2014, 10:15 +0100 schrieb Pierluigi Passaro:
Quoted 47 lines · Philipp Zabel
Quoted 42 lines
Am Mittwoch, den 10.12.2014, 22:04 -0200 schrieb Fabio Estevam:
Quoted 33 lines
Quoted 9 lines · Pierluigi Passaro
Hi all,
I'm trying to use VPU code driver on iMX51 with kernel 3.18, following these steps:
- disabled DVI interface
- enabled LCD interface
- configured and enabled VPU
- copied iMX51 vpu firmware without header and renamed v4l-coda7541-imx53.bin in/lib/firmwareQuoted 8 lines
Attached you can find the patch and the defconfig I used.
The boot process hangs after loading the firmware at the first attempt of writing in VPU address space in the function
coda_writeof filedriver/media/platform/coda/coda-common.cIs there anything preventing the coda driver to work with iMX51? Could anyone provide any suggestion on how investigate the problem?
I have only tested the coda driver on mx6, but looking at the
mx51.dtsiyou would need this:arch/arm/boot/dts/imx51.dtsi +1
-0@@ -121,6 +121,7 @@ iram: iram@1ffe0000 { compatible = "mmio-sram"; reg = <0x1ffe0000 0x20000>; + clocks = <&clks IMX5_CLK_OCRAM>; }; ipu: ipu@40000000 {arch/arm/boot/dts/imx51.dtsi line 590
Quoted 6 lines
arch/arm/boot/dts/imx51.dtsi +3
-0@@ -584,6 +585,18 @@ clock-names = "ipg", "ahb", "ptp"; status = "disabled"; }; + + vpu: vpu@83ff4000 { + compatible = "fsl,imx53-vpu";This should be "fsl,imx51-vpu", and add a "cnm,codahx14".
Quoted 4 lines
According to the old imx-vpu-lib code and the vpu_fw_imx51.bin firmware file, the i.MX51 has a CodaHx14 (
0xF00A) as opposed to the i.MX53's Coda7541 (0xF012).
Quoted 9 lines
Thanks for the hint, I'm now going through the old imx-vpu-lib to understand the CodaHX14 behaviour.
In old imx-vpu-lib, filevpu_util.c, there is a comment that make me
doubtful: "i.MX51 has no secondary AXI memory, but use on chip RAM". As far as I understood, the portion of coda driver affected from this comment should be around the functioncoda_setup_iramincoda-bit.c. How am I supposed to manage this information?
Have I to avoid to use iram for iMX51 (and return on !dev->iram.vaddr) or go through the function without managing any CodaHX14 specific behaviour?
I think for CodaHx14 on i.MX51 the CODA7_USE_HOST_xyz_ENABLE bits should be set in coda_setup_iram, but the CODA7_USE_xyz_ENABLE should not.
regards
Philipp