On Fri, 2008-05-16 at 22:04 +0200, Hans Verkuil wrote:
> On Friday 16 May 2008 18:50, Andy Walls wrote:
> > Hans,
> >
> > This seems like wiki material. I think it needs a forward section
> > about building a starting card entry ivtv-cards.c and some tweaks to
> > make it more generic, but it is a methodical process well worth
> > documenting.
>
> I was thinking the same thing. Either a wiki entry or a new
> documentation file that's part of the v4l-dvb tree or put the
> documentation in the ivtv-cards.c source itself as a big comment.
>
> What's your opinion? I'm leaning towards putting it in the source itself
> as that makes it easier to keep the documentation and the
> implementation in sync.
Source comments is the best choice:
- easy to have a commented template
- easy to handle "add line to this array and that array"
- easy to keep in sync with the code
Wiki is the second best choice:
- community can easily contribute lessons learned
v4l-dvb documentation is the worst choice:
- no benefits of the other two options
- not an obvious place: someone must be looking to RTFM
> > If you ever have time to write up an e-mail with a draft or sketch of
> > the total process, making note of all the "oh by the way"s (which I
> > suspect maybe only you know), I'll try to find time to clean it up
> > and get it on the wiki.
>
> I'll certainly ask you to review it.
OK.
>
> > Since cx18 is "bone of ivtv's bone and flesh of ivtv's flesh",
>
> How poetic! Much better than 'copy and paste'. :-)
I can't take credit really, so I'll cite my reference properly: metaphor
based on Genesis 2:23. [I can copy and paste too. :) ]
> > this
> > process can be adapted to apply to getting new cards working for cx18
> > as well.
>
> Yes, it is very similar. Except for the very annoying memory chip ddr
> settings, which is unique to the cx23418.
And that is a problem, AFAICT. I dug up the data sheet for the Samsung
chips, and it appears to require pretty good knowledge of how the host
(i.e. the cx23418) intends to drive the chip to set it up properly.
Looking at some PC memory modules, I noticed a small chip off in the
corner that looked like a serial EEPROM - it was. I did some digging
and found out about something called Serial Presence Detect (SPD) which
holds memory device parameters. Slide 28 of this brief shows a picture
of such an EEPROM on a memory module:
http://www.ece.umd.edu/courses/enee759h.S2003/references/config_DDR_Modules.pdf
And this technical note, although not a JEDEC specification or standard,
gives example layouts of SPD tables for several types of memory module:
http://download.micron.com/pdf/technotes/TN_04_42_C.pdf
If only the EEPROMs on these TV boards held similar information.
The windows *.inf file for on of the Toshiba MiniPCI cards actually has
all the DDR parameters in the *inf file. But given the draconian EULA
terms and copyright notices that come with Windows driver packages, I'm
not sure I could give a S-O-B in good conscience pulling the parameters
from the file.
I've seen Mauro often suggest running regspy. I guess that's acceptable
in most cases? I don't know.
I guess knowing the particular DDR chip and having it's datasheet is the
best way to go. In the absence of the proper datasheet, I have no idea
if an iterative or formulaic way to determine DDR parameters is
feasible.
-Andy
> Regards,
>
> Hans
>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
