Mailing List Archive: Delay loading v4l-cx25840.fw

Delay loading v4l-cx25840.fw

Apr 28, 2009, 6:34 AM

Post #1 of 10 (4517 views)

Hi,

I'm using ivtv in combination with a Hauppauge PVR 150, but every boot
I experience a 4 second delay every loading the firmware. During that,
one core of my processor spikes to 100% usage. I'm running kernel
2.6.28 (ubuntu jaunty), and have experienced this issue on another
computer too (running kernel 2.6.27, ubuntu intrepid).

Is this normal behaviour? I'd think my processor (a Q9500) would have
enough computational power to load a 16kB firmware file in less then 4
seconds.

I've added some details at the end of my mail, thanks in advance for
any comment.
maleadt

Hardware (lspci -v):
05:06.0 Multimedia video controller: Internext Compression Inc iTVC16
(CX23416) MPEG-2 Encoder (rev 01)
Subsystem: Hauppauge computer works Inc. Device 8003
Flags: bus master, medium devsel, latency 64, IRQ 22
Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [44] Power Management version 2
Kernel driver in use: ivtv
Kernel modules: ivtv

Kernel (relevant part of /var/log/messages):
[ 10.398809] ivtv: Start initialization, version 1.4.0
[ 10.398854] ivtv0: Initializing card #0
[ 10.398856] ivtv0: Autodetected Hauppauge card (cx23416 based)
[ 10.398939] ivtv 0000:05:06.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
[ 10.452053] tveeprom 0-0050: The eeprom says no radio is present,
but the tuner type
[ 10.452055] tveeprom 0-0050: indicates otherwise. I will assume
that radio is present.
[ 10.452057] tveeprom 0-0050: Hauppauge model 26039, rev C1A5, serial# 7930745
[ 10.452058] tveeprom 0-0050: tuner model is TCL MPE05-2 (idx 105, type 38)
[ 10.452060] tveeprom 0-0050: TV standards PAL(B/G) PAL(I)
SECAM(L/L') PAL(D/D1/K) (eeprom 0x74)
[ 10.452061] tveeprom 0-0050: audio processor is CX25842 (idx 36)
[ 10.452063] tveeprom 0-0050: decoder processor is CX25842 (idx 29)
[ 10.452064] tveeprom 0-0050: has radio, has IR receiver, has IR transmitter
[ 10.452065] ivtv0: Autodetected Hauppauge WinTV PVR-150
[ 10.452066] ivtv0: Reopen i2c bus for IR-blaster support
[ 10.494662] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level,
low) -> IRQ 22
[ 10.494709] HDA Intel 0000:00:1b.0: setting latency timer to 64
[ 10.513721] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0)
[ 10.526432] hda_codec: Unknown model for ALC883, trying auto-probe
from BIOS...
[ 10.551060] tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0)
[ 10.555344] tda9887 0-0043: creating new instance
[ 10.555345] tda9887 0-0043: tda988[5/6/7] found
[ 10.556731] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
[ 10.556774] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
[ 10.563959] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level,
low) -> IRQ 17
[ 10.564010] HDA Intel 0000:01:00.1: setting latency timer to 64
[ 10.572902] tuner-simple 0-0061: creating new instance
[ 10.572904] tuner-simple 0-0061: type set to 38 (Philips PAL/SECAM
multi (FM1216ME MK3))
[ 10.590693] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
[ 14.290279] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
[ 14.367933] ivtv0: Registered device video0 for encoder MPG (4096 kB)
[ 14.367971] ivtv0: Registered device video32 for encoder YUV (2048 kB)
[ 14.368016] ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
[ 14.368050] ivtv0: Registered device video24 for encoder PCM (320 kB)
[ 14.368079] ivtv0: Registered device radio0 for encoder radio
[ 14.368081] ivtv0: Initialized card #0: Hauppauge WinTV PVR-150
[ 14.368122] ivtv: End initialization

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

awalls at radix

Apr 28, 2009, 7:56 PM

Post #2 of 10 (4400 views)

Permalink

On Tue, 2009-04-28 at 15:34 +0200, maleadt wrote:
> Hi,
>
> I'm using ivtv in combination with a Hauppauge PVR 150, but every boot
> I experience a 4 second delay every loading the firmware. During that,
> one core of my processor spikes to 100% usage. I'm running kernel
> 2.6.28 (ubuntu jaunty), and have experienced this issue on another
> computer too (running kernel 2.6.27, ubuntu intrepid).
>
> Is this normal behaviour? I'd think my processor (a Q9500) would have
> enough computational power to load a 16kB firmware file in less then 4
> seconds.

Well, a busy CPU and a delay will be normal. I'd have to do some
spreadsheet calculations to make an estimate to verify if 4 seconds was
about right.

Here the circumstances which may help you understand your observations:

1. The CX25842 on your PVR-150 card is loaded and controlled via an I2C
(3 wire serial) bus to the CX23416 chip which acts as the I2C bus master
on that PVR-150 card.

2. The CX23416 does not (AFAIK) have any intelligence to manipulate the
I2C bus clock and data line automatically. There are a few registers
with bits to set and clear to set the clock or data line to a high or
low state. The CPU has control over this by PCI bus read and write
accesses to the CX23416 registers for the I2C lines. Manipulating bits
on a wire this way with the CPU is called "bit-banging".

3. Because of the nominal I2C clock rate of 100 kHz (IIRC) and that any
given kernel can have a low timer tick rate (i.e. with HZ = 100
ticks/sec is 1000 times slower than 100 kHz) the CPU does busy waits
during the high and low times of bits on the I2C bus while bit banging.
It can't rely on sleeping and kernel timers to get the bit times right.

4. The CX25842 firmware is about 16 KBytes long.

5. Apparently there are some PVR board (and/or motherboard combinations)
which will sometimes causes PCI bus reads or writes to fail. The ivtv
driver works around this by having it's own i2c bit banging
implmentation that does extra reads of the CX23416 registers on the PCI
bus. (Hans can correct me on this if I'm too far off). These extra
read result in some additional delays - like if the CPU or PCI-PCI
bridge is forced to yield the PCI bus due to PCI latency timers and bus
arbitration rules.

In short the 100 % CPU usage is expected due to busy waits, and a
noticable delay in loading the firmware doesn't surpirse me.

Is there room for improvement? Assuming a 100 kHz I2C clock rate and
neglecting *all* overhead bits (start,stop) and bytes (chip addresses)
and turn-around delays and the fact that the PCI bus is shared: 16384
bytes * 8 bits/byte / 100000 bits/sec = 1.31072 seconds is an
optimistic, unrealistic lower bound on the time to load the firmware.
Maybe things can be improved to get closer to that lower bound than 4
seconds, but I suspect not much improvement can be had. Also the time
investment on ensuring continued reliability of I2C bus transactions for
all ivtv users may not make it worth the effort.

The ivtv and cx25840 module should be deferring the cx2584x firmware
load until the chip is actually needed. Then the actual loading is spun
off to some transient kernel thread to get the job done in parallel with
other processes.

Regards,
Andy

> I've added some details at the end of my mail, thanks in advance for
> any comment.
> maleadt
>
> Hardware (lspci -v):
> 05:06.0 Multimedia video controller: Internext Compression Inc iTVC16
> (CX23416) MPEG-2 Encoder (rev 01)
> Subsystem: Hauppauge computer works Inc. Device 8003
> Flags: bus master, medium devsel, latency 64, IRQ 22
> Memory at f8000000 (32-bit, prefetchable) [size=64M]
> Capabilities: [44] Power Management version 2
> Kernel driver in use: ivtv
> Kernel modules: ivtv
>
> Kernel (relevant part of /var/log/messages):
> [ 10.398809] ivtv: Start initialization, version 1.4.0
> [ 10.398854] ivtv0: Initializing card #0
> [ 10.398856] ivtv0: Autodetected Hauppauge card (cx23416 based)
> [ 10.398939] ivtv 0000:05:06.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> [ 10.452053] tveeprom 0-0050: The eeprom says no radio is present,
> but the tuner type
> [ 10.452055] tveeprom 0-0050: indicates otherwise. I will assume
> that radio is present.
> [ 10.452057] tveeprom 0-0050: Hauppauge model 26039, rev C1A5, serial# 7930745
> [ 10.452058] tveeprom 0-0050: tuner model is TCL MPE05-2 (idx 105, type 38)
> [ 10.452060] tveeprom 0-0050: TV standards PAL(B/G) PAL(I)
> SECAM(L/L') PAL(D/D1/K) (eeprom 0x74)
> [ 10.452061] tveeprom 0-0050: audio processor is CX25842 (idx 36)
> [ 10.452063] tveeprom 0-0050: decoder processor is CX25842 (idx 29)
> [ 10.452064] tveeprom 0-0050: has radio, has IR receiver, has IR transmitter
> [ 10.452065] ivtv0: Autodetected Hauppauge WinTV PVR-150
> [ 10.452066] ivtv0: Reopen i2c bus for IR-blaster support
> [ 10.494662] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level,
> low) -> IRQ 22
> [ 10.494709] HDA Intel 0000:00:1b.0: setting latency timer to 64
> [ 10.513721] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver #0)
> [ 10.526432] hda_codec: Unknown model for ALC883, trying auto-probe
> from BIOS...
> [ 10.551060] tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0)
> [ 10.555344] tda9887 0-0043: creating new instance
> [ 10.555345] tda9887 0-0043: tda988[5/6/7] found
> [ 10.556731] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> [ 10.556774] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
> [ 10.563959] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level,
> low) -> IRQ 17
> [ 10.564010] HDA Intel 0000:01:00.1: setting latency timer to 64
> [ 10.572902] tuner-simple 0-0061: creating new instance
> [ 10.572904] tuner-simple 0-0061: type set to 38 (Philips PAL/SECAM
> multi (FM1216ME MK3))
> [ 10.590693] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
> [ 14.290279] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
> [ 14.367933] ivtv0: Registered device video0 for encoder MPG (4096 kB)
> [ 14.367971] ivtv0: Registered device video32 for encoder YUV (2048 kB)
> [ 14.368016] ivtv0: Registered device vbi0 for encoder VBI (1024 kB)
> [ 14.368050] ivtv0: Registered device video24 for encoder PCM (320 kB)
> [ 14.368079] ivtv0: Registered device radio0 for encoder radio
> [ 14.368081] ivtv0: Initialized card #0: Hauppauge WinTV PVR-150
> [ 14.368122] ivtv: End initialization

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

hverkuil at xs4all

Apr 28, 2009, 11:19 PM

Post #3 of 10 (4391 views)

Permalink

On Wednesday 29 April 2009 04:56:53 Andy Walls wrote:
> On Tue, 2009-04-28 at 15:34 +0200, maleadt wrote:
> > Hi,
> >
> > I'm using ivtv in combination with a Hauppauge PVR 150, but every boot
> > I experience a 4 second delay every loading the firmware. During that,
> > one core of my processor spikes to 100% usage. I'm running kernel
> > 2.6.28 (ubuntu jaunty), and have experienced this issue on another
> > computer too (running kernel 2.6.27, ubuntu intrepid).
> >
> > Is this normal behaviour? I'd think my processor (a Q9500) would have
> > enough computational power to load a 16kB firmware file in less then 4
> > seconds.
>
> Well, a busy CPU and a delay will be normal. I'd have to do some
> spreadsheet calculations to make an estimate to verify if 4 seconds was
> about right.
>
> Here the circumstances which may help you understand your observations:
>
> 1. The CX25842 on your PVR-150 card is loaded and controlled via an I2C
> (3 wire serial) bus to the CX23416 chip which acts as the I2C bus master
> on that PVR-150 card.
>
> 2. The CX23416 does not (AFAIK) have any intelligence to manipulate the
> I2C bus clock and data line automatically. There are a few registers
> with bits to set and clear to set the clock or data line to a high or
> low state. The CPU has control over this by PCI bus read and write
> accesses to the CX23416 registers for the I2C lines. Manipulating bits
> on a wire this way with the CPU is called "bit-banging".
>
> 3. Because of the nominal I2C clock rate of 100 kHz (IIRC) and that any
> given kernel can have a low timer tick rate (i.e. with HZ = 100
> ticks/sec is 1000 times slower than 100 kHz) the CPU does busy waits
> during the high and low times of bits on the I2C bus while bit banging.
> It can't rely on sleeping and kernel timers to get the bit times right.
>
> 4. The CX25842 firmware is about 16 KBytes long.
>
> 5. Apparently there are some PVR board (and/or motherboard combinations)
> which will sometimes causes PCI bus reads or writes to fail. The ivtv
> driver works around this by having it's own i2c bit banging
> implmentation that does extra reads of the CX23416 registers on the PCI
> bus. (Hans can correct me on this if I'm too far off).

This is only enabled if the device has an IR-blaster. Otherwise the normal
i2c kernel code is used. In this case the device does have an IR-blaster.

> These extra
> read result in some additional delays - like if the CPU or PCI-PCI
> bridge is forced to yield the PCI bus due to PCI latency timers and bus
> arbitration rules.
>
>
>
> In short the 100 % CPU usage is expected due to busy waits, and a
> noticable delay in loading the firmware doesn't surpirse me.
>
> Is there room for improvement? Assuming a 100 kHz I2C clock rate and
> neglecting *all* overhead bits (start,stop) and bytes (chip addresses)
> and turn-around delays and the fact that the PCI bus is shared: 16384
> bytes * 8 bits/byte / 100000 bits/sec = 1.31072 seconds is an
> optimistic, unrealistic lower bound on the time to load the firmware.
> Maybe things can be improved to get closer to that lower bound than 4
> seconds, but I suspect not much improvement can be had. Also the time
> investment on ensuring continued reliability of I2C bus transactions for
> all ivtv users may not make it worth the effort.
>
> The ivtv and cx25840 module should be deferring the cx2584x firmware
> load until the chip is actually needed. Then the actual loading is spun
> off to some transient kernel thread to get the job done in parallel with
> other processes.

What does surprise me here is that the fw is loaded right after the driver
was loaded, which does suggest that some process is opening one of the
device nodes since the fw load is only done on the first open.

Regards,

Hans

>
> Regards,
> Andy
>
> > I've added some details at the end of my mail, thanks in advance for
> > any comment.
> > maleadt
> >
> > Hardware (lspci -v):
> > 05:06.0 Multimedia video controller: Internext Compression Inc iTVC16
> > (CX23416) MPEG-2 Encoder (rev 01)
> > Subsystem: Hauppauge computer works Inc. Device 8003
> > Flags: bus master, medium devsel, latency 64, IRQ 22
> > Memory at f8000000 (32-bit, prefetchable) [size=64M]
> > Capabilities: [44] Power Management version 2
> > Kernel driver in use: ivtv
> > Kernel modules: ivtv
> >
> > Kernel (relevant part of /var/log/messages):
> > [ 10.398809] ivtv: Start initialization, version 1.4.0
> > [ 10.398854] ivtv0: Initializing card #0
> > [ 10.398856] ivtv0: Autodetected Hauppauge card (cx23416 based)
> > [ 10.398939] ivtv 0000:05:06.0: PCI INT A -> GSI 22 (level, low) ->
> > IRQ 22 [ 10.452053] tveeprom 0-0050: The eeprom says no radio is
> > present, but the tuner type
> > [ 10.452055] tveeprom 0-0050: indicates otherwise. I will assume
> > that radio is present.
> > [ 10.452057] tveeprom 0-0050: Hauppauge model 26039, rev C1A5,
> > serial# 7930745 [ 10.452058] tveeprom 0-0050: tuner model is TCL
> > MPE05-2 (idx 105, type 38) [ 10.452060] tveeprom 0-0050: TV standards
> > PAL(B/G) PAL(I)
> > SECAM(L/L') PAL(D/D1/K) (eeprom 0x74)
> > [ 10.452061] tveeprom 0-0050: audio processor is CX25842 (idx 36)
> > [ 10.452063] tveeprom 0-0050: decoder processor is CX25842 (idx 29)
> > [ 10.452064] tveeprom 0-0050: has radio, has IR receiver, has IR
> > transmitter [ 10.452065] ivtv0: Autodetected Hauppauge WinTV PVR-150
> > [ 10.452066] ivtv0: Reopen i2c bus for IR-blaster support
> > [ 10.494662] HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level,
> > low) -> IRQ 22
> > [ 10.494709] HDA Intel 0000:00:1b.0: setting latency timer to 64
> > [ 10.513721] cx25840 0-0044: cx25842-23 found @ 0x88 (ivtv i2c driver
> > #0) [ 10.526432] hda_codec: Unknown model for ALC883, trying
> > auto-probe from BIOS...
> > [ 10.551060] tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0)
> > [ 10.555344] tda9887 0-0043: creating new instance
> > [ 10.555345] tda9887 0-0043: tda988[5/6/7] found
> > [ 10.556731] tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
> > [ 10.556774] wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
> > [ 10.563959] HDA Intel 0000:01:00.1: PCI INT B -> GSI 17 (level,
> > low) -> IRQ 17
> > [ 10.564010] HDA Intel 0000:01:00.1: setting latency timer to 64
> > [ 10.572902] tuner-simple 0-0061: creating new instance
> > [ 10.572904] tuner-simple 0-0061: type set to 38 (Philips PAL/SECAM
> > multi (FM1216ME MK3))
> > [ 10.590693] cx25840 0-0044: firmware: requesting v4l-cx25840.fw
> > [ 14.290279] cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382
> > bytes) [ 14.367933] ivtv0: Registered device video0 for encoder MPG
> > (4096 kB) [ 14.367971] ivtv0: Registered device video32 for encoder
> > YUV (2048 kB) [ 14.368016] ivtv0: Registered device vbi0 for encoder
> > VBI (1024 kB) [ 14.368050] ivtv0: Registered device video24 for
> > encoder PCM (320 kB) [ 14.368079] ivtv0: Registered device radio0 for
> > encoder radio [ 14.368081] ivtv0: Initialized card #0: Hauppauge
> > WinTV PVR-150 [ 14.368122] ivtv: End initialization
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

mcree at orcon

Apr 29, 2009, 2:50 AM

Post #4 of 10 (4396 views)

Permalink

On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
> On Wednesday 29 April 2009 04:56:53 Andy Walls wrote:
>> The ivtv and cx25840 module should be deferring the cx2584x firmware
>> load until the chip is actually needed. Then the actual loading is
>> spun
>> off to some transient kernel thread to get the job done in parallel
>> with
>> other processes.
>
> What does surprise me here is that the fw is loaded right after the
> driver
> was loaded, which does suggest that some process is opening one of the
> device nodes since the fw load is only done on the first open.

Loading lirc drivers maybe?

Michael.

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

awalls at radix

Apr 29, 2009, 4:06 AM

Post #5 of 10 (4388 views)

Permalink

On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
> > On Wednesday 29 April 2009 04:56:53 Andy Walls wrote:
> >> The ivtv and cx25840 module should be deferring the cx2584x firmware
> >> load until the chip is actually needed. Then the actual loading is
> >> spun
> >> off to some transient kernel thread to get the job done in parallel
> >> with
> >> other processes.
> >
> > What does surprise me here is that the fw is loaded right after the
> > driver
> > was loaded, which does suggest that some process is opening one of the
> > device nodes since the fw load is only done on the first open.
>
> Loading lirc drivers maybe?

It has to be something from userspace on the /dev/video* or /dev/radio*
nodes. I'm not sure lirc would cause this.

On my systems (Fedora 9 & 10) IIRC it happens early too. I've always
assumed it was either udev or hal or some some other automatic process
that mucks with device nodes.

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

hverkuil at xs4all

Apr 29, 2009, 4:33 AM

Post #6 of 10 (4395 views)

Permalink

> On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
>> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
>> > On Wednesday 29 April 2009 04:56:53 Andy Walls wrote:
>> >> The ivtv and cx25840 module should be deferring the cx2584x firmware
>> >> load until the chip is actually needed. Then the actual loading is
>> >> spun
>> >> off to some transient kernel thread to get the job done in parallel
>> >> with
>> >> other processes.
>> >
>> > What does surprise me here is that the fw is loaded right after the
>> > driver
>> > was loaded, which does suggest that some process is opening one of the
>> > device nodes since the fw load is only done on the first open.
>>
>> Loading lirc drivers maybe?
>
> It has to be something from userspace on the /dev/video* or /dev/radio*
> nodes. I'm not sure lirc would cause this.
>
> On my systems (Fedora 9 & 10) IIRC it happens early too. I've always
> assumed it was either udev or hal or some some other automatic process
> that mucks with device nodes.

It would be nice if you could track down who is messing around with those
device nodes. If you modprobe ivtv with file and ioctl debugging on, does
that give an indication of what is done with the device nodes?

I'm running a non-standard linuxfromscratch system which doesn't use hal.
On that system the fw is really loaded only when it is opened for use for
the first time.

Depending on what process is doing what with the device nodes I may be
able to optimize the driver for that. It's really annoying to have this fw
loaded at boot time, esp. if you have one or more PVR-500 cards.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

awalls at radix

Apr 29, 2009, 6:18 PM

Post #7 of 10 (4382 views)

Permalink

On Wed, 2009-04-29 at 13:33 +0200, Hans Verkuil wrote:
> > On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
> >> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:

> >> > What does surprise me here is that the fw is loaded right after the
> >> > driver
> >> > was loaded, which does suggest that some process is opening one of the
> >> > device nodes since the fw load is only done on the first open.
> >>

> > On my systems (Fedora 9 & 10) IIRC it happens early too. I've always
> > assumed it was either udev or hal or some some other automatic process
> > that mucks with device nodes.

> It would be nice if you could track down who is messing around with those
> device nodes.

I'll work on it. It looks like something that is aware of v4l device
nodes (see below) - I'm wagering hald.

> If you modprobe ivtv with file and ioctl debugging on, does
> that give an indication of what is done with the device nodes?

For the cx18 driver on a Fedora 10 system something runs through
the /dev/video* nodes and /dev/radio* doing VIDIOC_QUERYCAP. I suspect
the behavior will be the same for ivtv. I'll test on my other system
when I get a chance.

I have attached the startup from dmesg and /var/log/messages. I had the
mythbackend disabled at boot. With the mythbackend enabled at startup,
the results are the same except at 135 seconds after boot, the
mythbackend opens up a TS stream looking for EIT/EPG data.

> I'm running a non-standard linuxfromscratch system which doesn't use hal.
> On that system the fw is really loaded only when it is opened for use for
> the first time.
>
> Depending on what process is doing what with the device nodes I may be
> able to optimize the driver for that. It's really annoying to have this fw
> loaded at boot time, esp. if you have one or more PVR-500 cards.

More info to come...

Regards,
Andy

Re: Delay loading v4l-cx25840.fw [ In reply to ]

mcree at orcon

Apr 30, 2009, 5:30 PM

Post #8 of 10 (4353 views)

Permalink

On 29/04/2009, at 11:06 PM, Andy Walls wrote:
> On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
>> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
>>> On Wednesday 29 April 2009 04:56:53 Andy Walls wrote:
>>>> The ivtv and cx25840 module should be deferring the cx2584x
>>>> firmware
>>>> load until the chip is actually needed. Then the actual loading is
>>>> spun
>>>> off to some transient kernel thread to get the job done in parallel
>>>> with
>>>> other processes.
>>>
>>> What does surprise me here is that the fw is loaded right after the
>>> driver
>>> was loaded, which does suggest that some process is opening one of
>>> the
>>> device nodes since the fw load is only done on the first open.
>>
>> Loading lirc drivers maybe?
>
> It has to be something from userspace on the /dev/video* or /dev/
> radio*
> nodes. I'm not sure lirc would cause this.

Okay. I mentioned it because I know that on my system the firmware
gets loaded about the time the lircd script is run. But on closer
examination of the startup messages I see that Hal gets loaded then
the ivtv firmware load messages come, then lircd is loaded so your
suggestion that:

> I've always
> assumed it was either udev or hal or some some other automatic process
> that mucks with device nodes.

looks likely.

Unfortunately the evidence I mention above of Hal loading then ivtv
firmware is not recorded in my system logs - I just saw it pass by on
the console screen. I think there is a flag I can change in the
startup procedure that will cause a lot more information to be
recorded. I'll explore trying to get a useful start up log over the
weekend.

Cheers
Michael.

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

awalls at radix

Apr 30, 2009, 7:21 PM

Post #9 of 10 (4347 views)

Permalink

On Wed, 2009-04-29 at 21:18 -0400, Andy Walls wrote:
> On Wed, 2009-04-29 at 13:33 +0200, Hans Verkuil wrote:
> > > On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
> > >> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
>
> > >> > What does surprise me here is that the fw is loaded right after the
> > >> > driver
> > >> > was loaded, which does suggest that some process is opening one of the
> > >> > device nodes since the fw load is only done on the first open.
> > >>
>
> > > On my systems (Fedora 9 & 10) IIRC it happens early too. I've always
> > > assumed it was either udev or hal or some some other automatic process
> > > that mucks with device nodes.
>
> > It would be nice if you could track down who is messing around with those
> > device nodes.
>
> I'll work on it. It looks like something that is aware of v4l device
> nodes (see below) - I'm wagering hald.

I've found it. It's hald-probe-video4linux:

[11539.917539] cx18-0: info: cx18_v4l2_open: called for stream encoder MPEG by pid 22870 (hald-probe-vide) ppid 1981 (hald-runner)
[11540.333557] cx18-0: info: cx18_v4l2_open: called for stream encoder PCM audio by pid 22907 (hald-probe-vide) ppid 1981 (hald-runner)
[11540.337019] cx18-0: info: cx18_v4l2_open: called for stream encoder VBI by pid 22923 (hald-probe-vide) ppid 1981 (hald-runner)
[11540.386051] cx18-0: info: cx18_v4l2_open: called for stream encoder YUV by pid 22929 (hald-probe-vide) ppid 1981 (hald-runner)
[11540.401658] cx18-0: info: cx18_v4l2_open: called for stream encoder radio by pid 22930 (hald-probe-vide) ppid 1981 (hald-runner)

# locate hald-probe-vide
/usr/libexec/hald-probe-video4linux

It's not restricted to boot. It happens on modprobe, probably cued by
udev or some other hotplug mechanism.

> > If you modprobe ivtv with file and ioctl debugging on, does
> > that give an indication of what is done with the device nodes?
>
> For the cx18 driver on a Fedora 10 system something runs through
> the /dev/video* nodes and /dev/radio* doing VIDIOC_QUERYCAP. I suspect
> the behavior will be the same for ivtv. I'll test on my other system
> when I get a chance.

> > Depending on what process is doing what with the device nodes I may be
> > able to optimize the driver for that. It's really annoying to have this fw
> > loaded at boot time, esp. if you have one or more PVR-500 cards.

Well thinking about this, this is a system level issue:

1. People want to avoid unnecessary waits at boot (or module insertion
time)

2. Hardware detection mechanisms want to query what new hardware is as
soon as it appears.

3. Hardware queries from userspace should (or need to) avoid IO bound
operations that consume CPU.

4. Kernel drivers should be able to satsify hardware queries without
starting up an IO bound operation that consumes CPU.

Hans, it sounds like your media_controller device node idea is really
what we need to get implemented here for user space to do queires on
hardware. This problem obviously affects more than the ivtv driver so
I'd recommend against an ivtv band-aid.

We'd also want to coordinate with the hald folks and other user space
app/plumbing developers, as this likely affects a few v4l2 drivers. It
sounds like an LPC agenda item to me...

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Re: Delay loading v4l-cx25840.fw [ In reply to ]

hverkuil at xs4all

May 2, 2009, 8:49 AM

Post #10 of 10 (4323 views)

Permalink

On Friday 01 May 2009 04:21:36 Andy Walls wrote:
> On Wed, 2009-04-29 at 21:18 -0400, Andy Walls wrote:
> > On Wed, 2009-04-29 at 13:33 +0200, Hans Verkuil wrote:
> > > > On Wed, 2009-04-29 at 21:50 +1200, Michael Cree wrote:
> > > >> On 29/04/2009, at 6:19 PM, Hans Verkuil wrote:
> > > >> > What does surprise me here is that the fw is loaded right after
> > > >> > the driver
> > > >> > was loaded, which does suggest that some process is opening one
> > > >> > of the device nodes since the fw load is only done on the first
> > > >> > open.
> > > >
> > > > On my systems (Fedora 9 & 10) IIRC it happens early too. I've
> > > > always assumed it was either udev or hal or some some other
> > > > automatic process that mucks with device nodes.
> > >
> > > It would be nice if you could track down who is messing around with
> > > those device nodes.
> >
> > I'll work on it. It looks like something that is aware of v4l device
> > nodes (see below) - I'm wagering hald.
>
> I've found it. It's hald-probe-video4linux:
>
> [11539.917539] cx18-0: info: cx18_v4l2_open: called for stream encoder
> MPEG by pid 22870 (hald-probe-vide) ppid 1981 (hald-runner)
> [11540.333557] cx18-0: info: cx18_v4l2_open: called for stream encoder
> PCM audio by pid 22907 (hald-probe-vide) ppid 1981 (hald-runner)
> [11540.337019] cx18-0: info: cx18_v4l2_open: called for stream encoder
> VBI by pid 22923 (hald-probe-vide) ppid 1981 (hald-runner) [11540.386051]
> cx18-0: info: cx18_v4l2_open: called for stream encoder YUV by pid 22929
> (hald-probe-vide) ppid 1981 (hald-runner) [11540.401658] cx18-0: info:
> cx18_v4l2_open: called for stream encoder radio by pid 22930
> (hald-probe-vide) ppid 1981 (hald-runner)
>
> # locate hald-probe-vide
> /usr/libexec/hald-probe-video4linux
>
>
> It's not restricted to boot. It happens on modprobe, probably cued by
> udev or some other hotplug mechanism.
>
> > > If you modprobe ivtv with file and ioctl debugging on, does
> > > that give an indication of what is done with the device nodes?
> >
> > For the cx18 driver on a Fedora 10 system something runs through
> > the /dev/video* nodes and /dev/radio* doing VIDIOC_QUERYCAP. I suspect
> > the behavior will be the same for ivtv. I'll test on my other system
> > when I get a chance.
> >
> > > Depending on what process is doing what with the device nodes I may
> > > be able to optimize the driver for that. It's really annoying to have
> > > this fw loaded at boot time, esp. if you have one or more PVR-500
> > > cards.
>
> Well thinking about this, this is a system level issue:
>
> 1. People want to avoid unnecessary waits at boot (or module insertion
> time)
>
> 2. Hardware detection mechanisms want to query what new hardware is as
> soon as it appears.
>
> 3. Hardware queries from userspace should (or need to) avoid IO bound
> operations that consume CPU.
>
> 4. Kernel drivers should be able to satsify hardware queries without
> starting up an IO bound operation that consumes CPU.
>
> Hans, it sounds like your media_controller device node idea is really
> what we need to get implemented here for user space to do queires on
> hardware. This problem obviously affects more than the ivtv driver so
> I'd recommend against an ivtv band-aid.
>
> We'd also want to coordinate with the hald folks and other user space
> app/plumbing developers, as this likely affects a few v4l2 drivers. It
> sounds like an LPC agenda item to me...
>
> Regards,
> Andy

I agree. A media controller device is exactly what we need. It's ideal for
applications and daemons like hald.

Now all I need is the time to work on it and I don't see that happening
anytime soon. :-(

Any volunteers? I have a general idea of how it should be implemented, but
it needs a fair amount of research as well.

Regards,

Hans

--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Mailing List Archive

Mailing List Archive

Attached Files: