What is the exact benefit we're after here by making things common
between all these cores? Code reuse is not a benefit, if it leads to
more expensive maintenance.
We'll, it diverged for the 23885 because the register addressed change for some
registers, it's not the same part. Certainly for the video decoder, not
necessarily for the audio encoder.
I know Andy knows this, I'm just pointing it out for the record.
This, coupled with the 'don't screw up other boards' approach leads to a unified
driver, not so much internally.
The 25840 driver does 'just enough' to get by, Andy has taken it to the next
level and done the stuff that I should have done for the cx23885 merge (although
I did 'just enough' to get by).
The notion of flexible clocks pays big dividends thanks to Andy, but is largely
a positive change that falls outside of this discussion topic (firmware filename).
I had considered moving the cx18-av code from the cx18 module into the
cx25840 module, but could never find a reason to undertake all the work.
Memory footprint isn't a good reason: desktop PC memory is cheap and
embedded systems would likely only use one type of card anyway. The
return on investment seems like it would be less than 0.
Hmm. You should check out the cx23102 driver, whole crap, massive cx25840
overlap, massive superset in terms of functionality.
OK. I'm done ranting...
A great pity, you were getting me fired up along the same train of thought :)
Andy, you have the support and full access to the resources of KernelLabs if you
need help (directly or indirectly) with regression testing. Your work is very
positive and a much needed overhaul.
Mauro, my pitch: Let's leave the firmwares unique for the time being, which
indeed they are. So, leave the firmware detection code as is, it's working for
everyone. Let's rethink this discussion after Andy's massive patch series. It
sounds like the cx25840 driver is 'getting a new owner' and we'll look at the
driver differently once the overhaul is complete.
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
--
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