On Thu, Jul 23, 2009 at 4:05 PM, Devin Heitmueller<dheitmueller@xxxxxxxxxxxxxx> wrote: > On Thu, Jul 23, 2009 at 8:10 AM, Markus Rechberger<mrechberger@xxxxxxxxx> wrote: >> There's a pretty good disclosed detection from Empia available, the >> linux kernel driver >> just doesn't support it and very likely will never support it. Instead >> of doing it the >> wrong way it's better to turn it off or explicitly ask the user if he >> wants to do something >> undefined with his device. >> The nvidia setup tools also provide an option to force it instead of >> letting the software >> just do whatever some developers don't know what it will cause... >> You don't know what will happen to the device when doing that detection. >> The initial device in question had to be replugged after we removed >> the driver from the system. >> You shouldn't invite people to do undefined things with their hardware >> so they might break them >> I think I will submit a few photos what physically can happen to the >> device with wrong settings. > > Well, if there is a known heuristic, I would be very happy to get rid > of the autodetection logic. I haven't looked at the Empia code in > months so I should probably do that. > > Since I used to design hardware for a living, I am quite familiar with > what can happen with incorrect GPIOs so I do not believe you need to > attempt to convince me with photos, which is why I am in favor of > removing the logic in question. We just need to figure out how to do > it without causing a regression in current device support. > > Interesting... I took a quick look at the code, and it seems like the > USB errors occur before we change any GPIOs, and more interesting it > appears that the em2861 itself is wedged (which I believe is the first > time I've seen that). The code in the log above suggests that the > autodetection concluded that the profile was not known, so it did not > arbitrarily pick some incorrect device. I am a bit surprised that > just reading the eeprom once and doing a scan of the i2c bus would > wedge the chip. > > Is there any information you can give about the board in question in > terms of what product it is or what components it contains? > it was a simple TVP5150 based device... I do not mean my old code either it's also a failure as I got more information for the new driver after we dropped the old project. As you know the new driver is entirely in Userpace and supported by all involved chipcompanies, it comes with its own LinuxDVB and video4linux2 Stack. Also vendors have a very low interest in supporting those devices in Kernelspace as installing devices which should be sold now are not supported by any distributions. Devices which have been sold one year ago have a very low till no motivation anymore. Most people are simply not able to compile the drivers and/or prepare the kernel development environment just for installing and using a TV Card. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
