On 8/2/07, Akiva Sadovski <akivas@xxxxxxxxxx> 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 > Ok. > 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() _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
