IMHO, the best is to get the latest firmware licensed is the best
thing to do.
Does that "new" xc5000c come with a firmware pre-loaded already?
I've got firmware here that is indicated as being for the xc5300 (i.e.
0x14b4). That said, I am not sure if it's the same as the original
5000c firmware. Definitely makes sense to do an I2C dump and compare
the firmware images since using the wrong firmware can damage the
part.
I'm not against an additional #define for the 0x14b4 part ID, but it
shouldn't be accepted upstream until we have corresponding firmware
and have seen the tuner working. Do you have digital signal lock
working with this device under Linux and the issue is strictly with
part identification?
Hello.
There are new details.
My assumption, that such behaviour of IC can be because of an old or incorrect
(for that HW) firmware, was wrong. It does not matter which FW version we use.
With a fresh (beginning of 2015) media_build, even with an "old" firmware, RF
tuner always and stably returns status 0x14b4. Also it's stably detects an
already
loaded firmware from another instance of the driver (analog part
initialisation).
And there is no i2c errors.
With an old media_build from beginning of 2014, there is some problem with
detection of already loaded firmware, there is i2c errors, and it gives the
50/50 status
either 0x1388 or 0x14b4.
My mistake I didn't checked a fresh media_build before.
So, the only thing we need is to add an additional #define for the 0x14b4 part
ID to a
driver's code, as I wrote before.
If you have any more questions, please ask.
Best regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
