Here are the files that are added:
./module/eeprom ./module/eeprom/sections ./module/eeprom/sections/.strtab ./module/eeprom/sections/.symtab ./module/eeprom/sections/.bss ./module/eeprom/sections/.gnu.linkonce.this_module ./module/eeprom/sections/.data ./module/eeprom/sections/.eh_frame ./module/eeprom/sections/__versions ./module/eeprom/sections/__param ./module/eeprom/sections/.rodata.str1.4 ./module/eeprom/sections/.rodata.str1.1 ./module/eeprom/sections/.init.text ./module/eeprom/sections/.exit.text ./module/eeprom/sections/.text ./module/eeprom/refcnt ./module/eeprom/srcversion
5168a5186,5189
./bus/i2c/drivers/eeprom ./bus/i2c/drivers/eeprom/bind ./bus/i2c/drivers/eeprom/unbind ./bus/i2c/drivers/eeprom/module
I don't see a exact eeprom file. I did notice when I tried to unload tveeprom that cx88xx was requiring it. The only 0-0050 I found was under the tveeprom device, and that doesn't have a eeprom file underneath it. Thanks again for your help, I really appreciate it. On 10/16/06, Steven Toth <stoth@xxxxxxxxxxxxx> wrote:
The file is called eeprom but the exact location escapes me. Try modprobing eeprom.ko and see which files appear under /sys/bus/i2c. Diff a recursive find of /sys before and after the modprobe. Of course, if the hardware eeprom is actually faulty, it may not appear and this could be the problem. Steve > Under /sys/bus/i2c/drivers I have eeprom and tv-eeprom. > > eeprom: > > mediacore:/sys/bus/i2c/drivers/eeprom> ls > bind module unbind > > mediacore:/sys/bus/i2c/drivers/eeprom> cd module/ > mediacore:/sys/bus/i2c/drivers/eeprom/module> ls > refcnt sections srcversion > mediacore:/sys/bus/i2c/drivers/eeprom/module> ls -lA > total 0 > -r--r--r-- 1 root root 4096 2006-10-16 22:01 refcnt > drwxr-xr-x 2 root root 0 2006-10-16 21:59 sections > -r--r--r-- 1 root root 4096 2006-10-16 22:01 srcversion > mediacore:/sys/bus/i2c/drivers/eeprom/module> > > Under tveeprom I have: > mediacore:/sys/bus/i2c/drivers/tveeprom/0-0050> ls > bus driver name power subsystem uevent > > mediacore:/sys/bus/i2c/drivers/tveeprom/0-0050> ls -lA > total 0 > lrwxrwxrwx 1 root root 0 2006-10-16 17:51 bus -> ../../../../../../bus/i2c > lrwxrwxrwx 1 root root 0 2006-10-16 17:51 driver -> > ../../../../../../bus/i2c/drivers/tveeprom > -r--r--r-- 1 root root 4096 2006-10-16 17:51 name > drwxr-xr-x 2 root root 0 2006-10-16 17:51 power > lrwxrwxrwx 1 root root 0 2006-10-16 17:51 subsystem -> > ../../../../../../bus/i2c > --w------- 1 root root 4096 2006-10-16 17:51 uevent > mediacore:/sys/bus/i2c/drivers/tveeprom/0-0050> more name > tveeprom > > I don't see a location to hexdump? > > Thanks for all of your help here. > > On 10/16/06, Steven Toth <stoth@xxxxxxxxxxxxx> wrote: > >> See below. >> >> Joshua Prismon wrote: >> >>> It worked on a different motherboard (an ASUS A8N-SLI deluxe with a >>> socket 939 AMD64). I replaced the motherboard with a Intel 965P, and >>> it stopped working. It does not work with a vanilla kernel. >>> >>> I also noted that the device went away with this motherboard. The 965P >>> motherboards are fairly new, and this may be a larger linux problem. >>> >>> Right now I am playing around with PCI addressing modes to see if >>> there is a problem in the ACPI layer. >>> >>> On 10/16/06, Steven Toth <stoth@xxxxxxxxxxxxx> wrote: >>> >>> >>>> Joshua Prismon wrote: >>>> >>>> >>>>> I am still getting the hang of this code, so it's very very possible >>>>> that I am missing something basic here. >>>>> >>>>> I don't think the problem is in the request_aquire function. In fact >>>>> that doesn't even appear to be every called. The DVB driver registered >>>>> correctly with the cx88-mpeg driver ( cx8802_register_driver). That >>>>> driver registers with the pci_driver. >>>>> >>>>> That PCI probe doesn't appear to be actually called. When >>>>> cx8802_register_driver starts looping through devices (after the dvb >>>>> driver is registered), it doesn't find any devices at all. The >>>>> devlist should be (if I read the code correctly) populated by the >>>>> cx8802_probe function. >>>>> >>>>> As a quick test, I added the following lines to the >>>>> pci_register_driver to see what the system actually sees in the PCI >>>>> tables: >>>>> >>>>> /* >>>>> .vendor = 0x14f1, >>>>> .device = 0x8802, >>>>> */ >>>>> >>>>> dev = pci_find_device(0x14f1, 0x8802, dev); >>>>> >>>>> >>>>> >>>>> >>>> <cut> >>>> >>>> >>>> >>>>> 05:00.0 0400: 14f1:8800 (rev 05) >>>>> Subsystem: 7063:3000 >>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>>>> ParErr- Stepping- SERR- FastB2B- >>>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>>>> >>>>> >>>>> >>>>>> TAbort- <TAbort- <MAbort- >SERR- <PERR- >>>>>> >>>>>> >>>>>> >>>>> Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 32 bytes >>>>> Interrupt: pin A routed to IRQ 21 >>>>> Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M] >>>>> Capabilities: [44] Vital Product Data >>>>> Capabilities: [4c] Power Management version 2 >>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA >>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>> Status: D0 PME-Enable- DSel=0 DScale=0 PME- >>>>> >>>>> 05:00.4 0480: 14f1:8804 (rev 05) >>>>> Subsystem: 7063:3000 >>>>> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- >>>>> ParErr- Stepping- SERR- FastB2B- >>>>> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >>>>> >>>>> >>>>> >>>> I don't see the mpeg PCI function enabled. In other words I don't see >>>> the 14f1:8802 device. Why is this missing? I expected to see an entire >>>> entry for this. >>>> >>>> The cx8802.ko (cx88-mpeg.c) driver registers against 14f1:8802 and so if >>>> that isn't registered then DVB is never going to work, because the >>>> kernel will never probe it. >>>> >>>> Are you completely sure the DVB device works under other kernels? >>>> >>>> Can you tell me which vanilla kernel from www.kernel.org this DVB >>>> product is working correctly with? >>>> >>>> >>>> >> cc'ing the linux-dvb list back _IN_ to the thread. >> >> modprobe eeprom.ko >> >> ^^^ This should create a /sys/bus/i2c/drive/eeprom/?-0050/eeprom or >> something like this. >> >> hexdump the eeprom file, it's 256 bytes long. The first byte of the file >> indicates which PCI devices are enabled by the 88x bridge chip. If the >> eeprom has become corrupt this will effect which PCI devices are enabled >> when the board is powered up. >> >> What does the entire eeprom content look like? (make sure you get the >> byte ordering the right way around in hexdump else it assumes word >> format and all the bytes get switched). >> >> Steve >> >> >> >> >> > >
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
