[linux-dvb] dvb_ca_en50221.c,h - a hook needed

Manu Abraham abraham.manu at gmail.com
Thu Aug 2 11:40:22 CEST 2007

On 8/2/07, Akiva Sadovski <akivas at scopus.net> wrote:
> Manu,
>   1) thanks for prompt reply,
>   2) see inline:
>  Not exactly. Let's put it this way:
> 1. before starting to work with cimax I have to:
>      1.1 reset the chip (it controls 2 CAM slots)

Just need some clarification, since there are 2 Reset's on the cimax.
CIMax Control @0x1fh :7 RESET :1 LOCK

LOCK validates and locks the chip setup
0 chip is not configured. Microprocessor inputs and outputs are inactive
1 chip is configured. Configuration bits are locked and CIMaX™ IOs are active
RST reset chip
equivalent to asserting the RESET pin. CIMaX™ is reset to its initial
state this bit is automatically
reset; no need to write 0 in italways reads as 0
1 reset

Here it is just "Resetting the chip" as a whole. In the driver
initialization you can handle this, No ? (Driver LOAD --> Reset module
--> LOAD default values)

>      1.2 configure some  cimax registers  - these registers will remain unchanged until next power down / power up


> 2. I prefer not to do these tasks in
>         int (*slot_reset)(struct dvb_ca_en50221* ca, int slot);
>    hook, since it's activated per CAM slot and I'd prefer something device-wide [my 'device' is the cimax controlling two CAM slots]

With regards to the CIMax, you have this "slot reset" as Module A
@0x00h, Module B @0x09h Reset :7 ie., Module Reset (according to CIMax
specs) the same as Slot Reset (according to EN50221 as well as
dvb_ca_en50221::slot_reset() ) is it not ?

RST module RST pin control
automatically forced to 0 when DET = 0
setting this bit is only allowed when DET = 1
The state of this bit is reproduced on the RST (A or B) pin of the module.

Are you meaning this RESET (Module Reset) or the first one (Chip Reset) ?

> 3. IMHO the ideal place for such a hook will be somewhere in dvb_ca_en50221_io_open() function...

This would have the effect of resetting the module on each open().
AFAICT, currently what we do from a userspace program POV, call RESET,
then open()

rather than calling an open(), where the open() call internally does
RESET. Just 2 ways it does, but eventually from a hardware POV, both
are the same isn't it ? But in the case when you have an external
RESET (whereby it is visible to the application: implying more
specific control over the hardware), it is more flexible than having
the RESET hidden in the open(), IMHO

By this, my assumption was that you meant module reset (A, B), rather
than chip reset, to be handled in dvb_ca_en50221_io_open()

More information about the linux-dvb mailing list