On Thu, Jul 23, 2009 at 2:03 PM, Devin Heitmueller<dheitmueller@xxxxxxxxxxxxxx> wrote: > On Thu, Jul 23, 2009 at 7:46 AM, Markus Rechberger<mrechberger@xxxxxxxxx> wrote: >> one thing, you might remove that autodetecting part and taking a >> footprint of unknown devices >> this causes more problems than everything else with those devices. >> Maybe make this optional if someone wants to force autodetection over >> it it might be acceptable >> but doing that by default can also heat up devices. >> Also if it thinks it has detected something, after toggling some gpios >> the footprint might look different >> again after reloading it.. it's just a failed technique doing it that way... > > I agree that I'm not particularly happy with how the autodetection > logic works today. The current logic though is based on the > power-on-reset states of the GPIOs and GPOs though, so we are only > changing the GPIOs if the board matches a known profile. > > That said, unless the hardware design was laid out such that the > device would burn out if no driver were loaded at all, I think the > risk is pretty minimal for a device that does not match a known > profile. > > If Empia wants to describe a better heuristic for identifying their > various hardware designs with the same USB ID but different board > layouts and GPIO configs, that would be useful information and > eliminate the need for autodetection code. > > Anyway, I'll take a look at the code and see if I can determine > specifically where the errors are occurring in your case. > > The fun of dealing with hardware vendors that let their customers use > default USB IDs for different hardware designs.... :-) > 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. 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
