Simon Lodal wrote: > Hello > > That was an enlightening story! > > If I understand you right, it is possible to do some kind of power > management, > it is just not manageable? >
Well, techinically yes it is, but you have to rewrite the firmware to do that which is quite impossible unfortunately. You can turn off the hardware units in the firmware through assembly style java bytecode instructions, but as seeing that it was hard for even the 1-2 people at iCompression to be able to do much in the firmware besides what we see it doing today, that's very unlikely to be ever done by any humans :). > If so here is a naive question: Would it be possible to shut down the entire > card completely, totally ignore any dependencies between it's components, > maybe leave it in some partly unworkable state, and simply reset / power it > up when needed? > Well maybe running the firmware shutdown API command possibly will turn off all the hardware units, and unloading the firmware, if that doesn't do it then I guess it's just always going to be drawing power. Thanks, Chris > I could easily live with some reinitialization delay and other quirks if it > would just stop drawing 10-15W at all times. > > > Simon > > > On Wednesday 07 June 2006 16:15, Chris Kennedy wrote: > >> Wilhelm Eger wrote: >> >>> Hi there, >>> >>> is there any chance to shut down the decoder of a PVR 350 to save power? >>> >> The cx23415 (the main mpeg encoder/decoder chip) actually uses hardware >> units from both the encoder/decoder for both encoding and decoding, so >> basically no it's impossible (for the mpeg encoder/decoder chip that is) >> because the decoder is used for encoding somewhat (like audio, PCM >> processing, and even DMA xfers cross over for how they function). It's >> a bad design being tangled up like that and one of the big flaws of >> these chips is exactly that, power hungry and encoder/decoder were not >> ever engineered properly to be separate (the cx23416 on the >> pvr250/150/500 had the hardware units switched around some to chop out >> the decoder but leave the units needed for the encoder). It originally >> was designed under the concept of a full set top box core and so >> everything was just thrown in together, they even forgot to have the >> Java processors separated enough to safely encode/decode together :) (so >> obviously more than just bad design but also major flaws that weren't >> able to be fully realized till too late in the game, it took years it >> seems to fully test all hardware units enough to know they were flawed >> it seems, I'm not sure what they were doing from 99'-01', the chip was >> birthed back in the late 90's) hence it's lucky that works so well >> actually through mulitple firmware hacks and driver hacks (and the >> wonderful DMA errors are partly a still visible side effect of that >> problem, 3 non-atomic locking Java processors working side by side >> blindly and accessing the same global block of registers is a 'bad thing'). >> >> Thanks, >> Chris >> >> >>> Greetings, >>> >>> Wilhelm >>> >>> _______________________________________________ >>> ivtv-devel mailing list >>> [email protected] >>> http://ivtvdriver.org/mailman/listinfo/ivtv-devel >>> >> _______________________________________________ >> ivtv-devel mailing list >> [email protected] >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel >> > > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
