On Fri, Aug 05, 2005 David Johnson wrote: > On Thursday 04 August 2005 14:03, Johannes Stezenbach wrote: > > > > For the Nebula it may be that simple, but in the general case there > > might be more work to do (e.g. first make sure the demod is not > > in sleep state, need to probe PLL seperately etc.). Every time > > there's a new Nebula version the code needs updateing and gets more > > complex... > > Mainly as an exercise for myself, I've coded this up. > So instead of trying to attach each frontend in turn, we attempt to read a > register on the nxt6000. Basically if the i2c read succeeds, we know that > we've got the nxt6000 frontend, otherwise it's the mt352. This also isn't a > terribly clean way of doing it, but it's how Nebula do it. > > As I say, this was mainly an exercise for myself to see if I could implement > it successfully, so I won't be too upset if you decide it isn't worth doing. ... > I don't have an nxt6000-based card to test with, but the code compiles cleanly > and succeeds in reading a value from the mt352 if I change the I2C address. > > If you think doing this detection is worthwhile, I'll create a patch and get > somebody to test it with an nxt6000, otherwise I'll create a patch to remove > the comment from the code and stop bothering you :-) Similar probing code is already in nxt6000_attach() and mt352_attach(), so this is just a useless duplication of code. Seperate probing would make sense if we didn't have the static dependency on the frontend modules, but demand-load just the correct frontend module after probing. But frankly, I don't think it's worth it. Johannes
