ADV7170 driver roadblock

Helmut Forren

Other Parts Discussed in Thread: THS7303, THS8200, THS7353, TVP7002, THS7373, TVP5147

Please help me get past this roadblock. I'm trying to build a kernel that includes the ADV7170 driver for the ADV7171 video chip on my custom DM6467T board (with DM6467 soldered to it and other adaptations due to DM6467T long lead time).

I'm tentatively modifying davinci_mhb_1ghz_defconfig to exclude the THS7303 and include the ADV7170 driver. When I make, the THS7303 "comes back", which I don't want but can live with. The ADV7170 driver seems to come, fortunately. After building the kernel, I look at the file .config and see both "CONFIG_VIDEO_ADV7170=y" and "CONFIG_VIDEO_THS7303=y". This makes me think I've built the kernel correctly.

However, when I boot up the kernel, I get

Linux video capture interface: v2.00
ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter)
ths7303 1-002c: ths7303 write failed
ths7303: probe of 1-002c failed with error -121
vpif_display vpif_display: Error registering v4l2 subdevice
vpif_display vpif_display: VPIF IRQ request failed
tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!
vpif_capture vpif_capture: registered sub device tvp514x-0
tvp514x 1-005c: tvp514x 1-005c decoder driver registered !!
vpif_capture vpif_capture: registered sub device tvp514x-1
vpif_capture vpif_capture: DM646x VPIF Capture driver initialized

I realize I'm getting the THS7303-related errors because I don't have that chip. I realize I get the TVP5147-related messages because I do have ONE of those chips.

I don't understand why I see no message regarding the ADV7170 driver or ADV7171 chip. I thought I built the kernel correctly.

I later came to understand I should modify board-dm646x-evm.c. I did this, adding analogous code for the ADV7170 as I see for the THS7303. Specifically:

static struct vpif_subdev_info dm646x_vpif_subdev[] = {

...[SNIP]...

{

.name = "adv7170",

.board_info = {

I2C_BOARD_INFO("adv7170", 0x5a),

}

...[SNIP]...

};

I rebuild the kernel, noting that board-dm646x-evm.o got a new date. I install the kernel on my board and boot it. NO CHANGE in the boot log. It still seems I'm not getting the adv7170 driver in there, or at least not trying to invoke it somehow. Please help!

Note I'm giving my ADV7170 as much consideration in the code as the THS8200 had, where the EVM uses the THS8200 for video output and I'm using the ADV7171.

-Helmut

over 13 years ago

0 Helmut Forren over 13 years ago

Mastermind 6805 points

I've searched all of the git folder for germane references to "8200" or "THS8200", to make sure that I'm doing as much on behalf of the ADV7170 driver as was previously done on behalf of the THS8200 driver. Here's what I find:

drivers/media/video/Makefile : has lines like "obj -$(CONFIG_VIDEO_THS8200) += ths8200.o". Similar already exists for ADV7170.

include/media/v4l2-chip-ident.h : has line like "V4L2_IDENT_THS8200". Similar already exists for ADV7170.

Has ths8200.c and ths8200.h files. Similar already exist for ADV7170.

drivers/media/video/Kconfig : has "config VIDEO_THS8200" and followup lines. Similar already exist for ADV7170.

And that's all folks. Why oh why am I getting nowhere?

0 Helmut Forren over 13 years ago in reply to Helmut Forren

Mastermind 6805 points

Note I finally got ncurses running, so that I could config "properly" from the top (ref http://e2e.ti.com/support/embedded/f/354/p/96970/338575.aspx#338575). However, I quickly discovered that "make menuconfig ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-" is a co-conspirator in forcing inclusion of the THS7303. Instead of "<*>" that responds to "y" or "no" to include or exclude, it has "-*-" and does not respond to "y" or "no". Why oh why???

Also, note that with ncurses running, I saw my ADV7170 enabled. I deduce it read the current .config to see what I had done before. And looking at file dates afterward, it writes .config. So I deduce that this menuconfig step is the true top level entry point. HOWEVER, it does not accomplish anything more than I was already getting into .config. Thereefore, it's not going to cause me to get a boot log from my kernel referring to the ADV7170.

Should I get anything in the boot log about it? Are things perhaps not going far enough because it fails on the THS7303? What's going on. I'm getting desperate...

Thanks,

Helmut

0 Helmut Forren over 13 years ago in reply to Helmut Forren

Mastermind 6805 points

Upon further investigation, I find the EVM itself includes the following in the log:

Linux video capture interface: v2.00
ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter)
ths8200 1-0020: chip found @ 0x40 (DaVinci I2C adapter)
ths7353 1-002e: chip found @ 0x5c (DaVinci I2C adapter)
vpif_capture vpif_capture: registered sub device ths7353
tvp7002 1-005d: tvp7002 1-005d decoder driver registered !!
vpif_capture vpif_capture: registered sub device tvp7002
vpif_capture vpif_capture: DM646x VPIF Capture driver initialized

Note that it mentions these: HD-output(THS7303, THS8200), HD-input(THS7373, TVP7002)

Note that it does NOT mention the TVP5147's that are used by the EVM for composite and S-video in, but then that's because the default kernel does not include these drivers.

Therefore, the above tells me that the kernel log SHOULD be verbose about my ADV7170 driver.

NEXT, when I throw in the kitchen sink and run it on my board, I get the log below. Kitchen sink means I've configured THS514X, TVP7002, ADV7170, ADV7175, THS7303, THS7353, and THS7353_LUMA_CHANNEL=3, THS8200. The log:

Linux video capture interface: v2.00

ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter)

ths7303 1-002c: ths7303 write failed

ths7303: probe of 1-002c failed with error -121

vpif_display vpif_display: Error registering v4l2 subdevice

vpif_display vpif_display: VPIF IRQ request failed

ths7353 1-002e: chip found @ 0x5c (DaVinci I2C adapter)

ths7353 1-002e: ths7353 write failed

ths7353: probe of 1-002e failed with error -121

vpif_capture vpif_capture: Error registering v4l2 subdevice

Note that THS7353 is mentioned, but gets an error. THS7303 is mentioned as always, and also gets an error. Note that the rest of the kitchen sink isn't mentioned. Specifically, THS514X that is mentioned with my regular custom kernel isn't mentioned. TVP7002 and THS8200 that I know get mentioned on the EVM aren't mentioned here.

DEDUCTION: The THS7303 is involved with video output and the error causes the kernel to quit trying on video output. For this reason, it never mentions any of the other video output drivers. This includes my desired ADV7170, as well as kitchen sink items ADV7175 and THS8200. Similarly, the THS7353 is involved with video input and the error causes the kernel to quit trying on video input. For this reason, it never mentions any of the other video input drivers. This includes my desired THS514X, as well as kitchen sink item TVP7002.

So, repeating the log I get with my desired kernel (color added):

Linux video capture interface: v2.00

ths7303 1-002c: chip found @ 0x58 (DaVinci I2C adapter)

ths7303 1-002c: ths7303 write failed

ths7303: probe of 1-002c failed with error -121

vpif_display vpif_display: Error registering v4l2 subdevice

vpif_display vpif_display: VPIF IRQ request failed

tvp514x 1-005d: tvp514x 1-005d decoder driver registered !!

vpif_capture vpif_capture: registered sub device tvp514x-0

tvp514x 1-005c: tvp514x 1-005c decoder driver registered !!

vpif_capture vpif_capture: registered sub device tvp514x-1

vpif_capture vpif_capture: DM646x VPIF Capture driver initialized

It appears that my video input driver, TVP514X, is being [initialized] just fine. However, the THS7303 failure is preventing the kernel from continuing and trying my ADV7170 driver.

Therefore INDEED, I need to get rid of this darned THS7303 that everybody and his brother keeps insisting to keep in the config!

I may also need to modify some code somewhere that may be the reason behind the conspiracy to keep THS7303. With that in mind, I need to find, at a minimum, the exact source code file responsible for the boot log lines I colored red above. That might be some generic loading code, however. What I really need to know is WHY someone somewhere, some code somewhere, thinks the THS7303 is a required chip. I need to figure out if this is true and I'm hosed, or if this is only erroneously true and I need to modify code to eliminate the dependency, or if this is not true at all and I just need to break up the conspiracy. HELP!

Thanks,

Helmut

0 Helmut Forren over 13 years ago in reply to Helmut Forren

Mastermind 6805 points

I did tentatively edit drivers/media/video/Makefile and commented out the line "obj -$(CONFIG_VIDEO_THS7303) += ths7303.0". This kernel compiled and no longer mentions THS7303. However, it doesn't mention my ADV7170 substitute, either. And the boot log still includes the "Error registering v4l2 subdevice" and "VPIF IRQ request failed" that were occurring after attempting to access THS7303 that wasn't present.

I also tentatively edited the same makefile FURTHER, by not only commenting that line out, but also trying to insure ADV7170 got included. I don't know how to write the syntax directly to force the inclusion, so I cloned a line to make "obj -$(CONFIG_VIDEO_TVP514X) += adv7170.o", since I knew TVP5147 was being handled. So the hope was that the adv7170.o was REALLY being included, and just has forcing the ths7303.o to NOT be included silenced it in the boot log, this forced inclusion should cause the ADV7170 to show up in the boot log finally. NO SUCH LUCK. The boot log didn't change from above. There must also be something in the running code that wants the THS7303, and won't go any further forward without it, or else I'm still failing to get the ADV7170 included.

0 Helmut Forren over 13 years ago in reply to Helmut Forren

Mastermind 6805 points

Please note that this morning, I tentatively edited git/drivers/media/video/davinci/vpif_display.c to continue in it's loop rather than exit, upon encountering the "Error registering v4l2 subdevice". Indeed, after the TH7303 related error, a boot log output occurred mentioning the ADV7170.

So, the ADV7170 driver is there, but the kernel wasn't trying to access it because of the prior error accessing the TH7303. This tells me that I can reduce my problem to getting rid of the pesky TH7303, for which there's some kind of conspiracy to keep it around. Please see "Why the THS7303 Conspiracy?" http://e2e.ti.com/support/embedded/f/354/p/97004/338846.aspx#338846

Processors

Processors forum

ADV7170 driver roadblock