Oliver Endriss wrote:
> Robert Schedel wrote:
>> Hello,
>>
>> on 2.6.24 I run into a small issue with the budget_av driver:
>>
>> Hardware: Athlon 64X2 3800+, Satelco Easywatch DVB-C (1894:002c), no CI/CAM
>> Software: Linux kernel 2.6.24 (gentoo-r4) SMP x86_64, budget_av module
>>
>> Error description:
>> After the budget_av driver module is loaded (even without any DVB 
>> application), the CPU load average in 'top' rises to ~1, but in top no 
>> active tasks are found. After unloading the driver, the load decreases 
>> again to ~0.
>>
>> Displaying the blocked tasks during high load with Alt-SysRq-W shows 
>> that the kdvb-ca kernel thread seems to be accounted as blocked when it 
>> polls for the CI slot status:
>> ---------------------------------------------------
>> [...]
>> ---------------------------------------------------
>>
>> Enabling debug traces shows that polling for the PSR in function 
>> 'saa7146_wait_for_debi_done_sleep' constantly times out after 250x1ms 
>> sleeps:
>>
>>  > saa7146: saa7146_wait_for_debi_done_sleep(): saa7146 (0): 
>> saa7146_wait_for_debi_done_sleep timed out while waiting for transfer 
>> completion
>>
>> Increasing the 250ms did not avoid the timeout. And as I understood from 
>> previous list mails, this timeout is normal when no CI/CAM is connected 
>> to the DEBI. However, for me the high frequency polling does not make 
>> sense if someone does not plan to plug in a CI/CAM.
>>
>> When commenting out two lines in 'dvb_ca_en50221_thread_update_delay' to 
>> increase the polling timer for slotstate NONE from 100ms (!) to 60s, the 
>> CPU load went down to 0. So this is some kind of workaround for me.
> 
> Afaics the polling interval could be increased to something like 5s or
> 10s if (and only if) the slot is empty. Could you provide a patch?

Attached a patch for 2.6.24.4. Opinions?

Unfortunately, a 5s poll interval for empty slots still results in a
load average of about 0,06 (~ 250ms/5s).

Increasing to 10s would decrease the load and be fine for people without
CAM, but increase the delay for those users inserting CAMs during
runtime. 5s sounds like a reasonable tradeoff.

Is the 250ms timeout an approved limit? Decreasing it would push the
load further down. Probably it still has to cover slow CAMs as well as a
stressed PCI bus. Unfortunately, without CAM/CI I cannot make any
statements myself.

>> Finally, my questions:
>> 1. Did I understand this right, that the behaviour above is expected 
>> when no CI is connected?
> 
> Yes, but afaics the polling interval is way too short.
> 
>> 2. Are all budget_av cards unable to check CAM slot state via interrupt 
>>   for HW reasons (as budget_ci does)?
> 
> I don't have any budget-av hardware, so I don't know.
> But I think that Andrew(?) had a good reason to implement it this way.
> (In contrast the budget-ci driver was always interrupt-driven.)
> 
> If someone finds out that a given card can operate in interrupt mode,
> it should be changed for this card. Patches are welcome. ;-)

My impression is, due to the different GPIO layout there is no way to
get a CAM change IRQ. But it seems difficult to get information about
the HW architecture of cards at all.

Regarding DEBI_E: Just found a av7110 code comment which also reflects
what my recent tests showed:
          /* Note: Don't try to handle the DEBI error irq (MASK_18), in
           * intel mode the timeout is asserted all the time...
           */

So really only DEBI_S would be left, see below.

>> 3. Would it be possible to substitute the current PSR DEBI_S polling 
>> with an interrupt based solution via IER/ISR? (driver av7110 alreadys 
>> seems to do this for its DEBI DMA)? Or was this not considered worthy, 
>> due to the expected short waiting period and the tricky IER handling? 
>> The code does not state further thoughts about this.
> 
> The av7110 driver uses interrupt mode for buffer transfers in dma mode.
> It does not make much sense to use interrupt mode for single-word
> transfers, because the single-word transfers are very fast.
> But I understand that the timeout causes a problem in this case.

OK, interrupts of course decrease performance in the "sunny day" cases
(=communication with inserted card in slot state READY). Having both
approaches (interrupt when slotstate empty, later polling) would combine
all benefits but also be somewhat crazy.

>> 4. Are the high timeout periods in debi_done (50ms/250ms) in relation to 
>> the 100ms poll timer intended? (I found the recent patch to this code in 
>> the mailing list end of last year)
> 
> That patch was applied to reduce the load on the pci bus in busy-wait
> mode. Basically it did not change anything for cam polling. (In fact I
> was not aware that the CAM was polled every 100ms. Imho this should be
> fixed.)

Only wondered whether the 250ms might have been smaller in former driver
versions.

> 
>> 5. If we would be restricted to poll with high frequency: Why not at 
>> least allow users without CI to disable polling for slots or change the 
>> interval, e.g. via module options?
> 
> Module options are evil. ;-)
> We should do this only if everything else fails.

Correct.

P.S. Had already created bugzilla #10459 for tracking.
Sorry for late response, previous mail was stuck in spam filter.

Regards,
Robert