eMPIA EM2710 Webcam (em28xx) and LIRC

eMPIA EM2710 Webcam (em28xx) and LIRC

[Rui Salvaterra]

Hi, everyone.

I apologise in advance for the noise if this is the wrong place to ask
such questions. I have a couple of eMPIA EM2710 (Silvercrest) USB
webcams which work quite well, except for the fact that most of LIRC
is unnecessarily loaded when the em28xx module loads. I suppose it
shouldn't be necessary, since these are webcams and don't have any
kind of IR remote control. I tried blacklisting the relevant modules,
but they keep loading. If relevant, I'm running Linux 3.3.0-rc7 on
Ubuntu 11.10.
(I'm not subscribed to the list, but I occasionally lurk in the archives.)

Thanks!

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Ezequiel García]

Hi Rui,

On Wed, Mar 14, 2012 at 8:28 AM, Rui Salvaterra <rsalvaterra@gmail.com> wrote:
> Hi, everyone.
>
> I apologise in advance for the noise if this is the wrong place to ask
> such questions. I have a couple of eMPIA EM2710 (Silvercrest) USB
> webcams which work quite well, except for the fact that most of LIRC

Exactly what module do you refer to? Could you just send a snippet
of dmesg when module is loaded?

> is unnecessarily loaded when the em28xx module loads. I suppose it
> shouldn't be necessary, since these are webcams and don't have any

Looking at source code, I noticed two things:
1. You have a module param named "disable-ir", perhaps you could
try to use this (do you know how?).
2. EM2710 board is defined like this:

                .name          = "EM2710/EM2750/EM2751 webcam grabber",
                .xclk          = EM28XX_XCLK_FREQUENCY_20MHZ,
                .tuner_type    = TUNER_ABSENT,
                .is_webcam     = 1,
                .input         = { {
                        .type     = EM28XX_VMUX_COMPOSITE1,
                        .vmux     = 0,
                        .amux     = EM28XX_AMUX_VIDEO,
                        .gpio     = silvercrest_reg_seq,
                } },

As opposed to:

                .name         = "Terratec Cinergy 250 USB",
                .tuner_type   = TUNER_LG_PAL_NEW_TAPC,
                .has_ir_i2c   = 1,
                .tda9887_conf = TDA9887_PRESENT,
                .decoder      = EM28XX_SAA711X,
                .input        = { {
                        .type     = EM28XX_VMUX_TELEVISION,
                        .vmux     = SAA7115_COMPOSITE2,
                        .amux     = EM28XX_AMUX_LINE_IN,
                }, {
                        .type     = EM28XX_VMUX_COMPOSITE1,
                        .vmux     = SAA7115_COMPOSITE0,
                        .amux     = EM28XX_AMUX_LINE_IN,
                }, {
                        .type     = EM28XX_VMUX_SVIDEO,
                        .vmux     = SAA7115_SVIDEO3,
                        .amux     = EM28XX_AMUX_LINE_IN,
                } },
        },

Noticed the lack of "has_ir_i2c" definition in the EM2710.

So I don't know how that module is being loaded. Probably I'm missing something.

Hope it helps,
Ezequiel.

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Rui Salvaterra]

[-- Attachment #1: Type: text/plain, Size: 3713 bytes --]

2012/3/14 Ezequiel García <elezegarcia@gmail.com>:
> Hi Rui,
>
> On Wed, Mar 14, 2012 at 8:28 AM, Rui Salvaterra <rsalvaterra@gmail.com> wrote:
>> Hi, everyone.
>>
>> I apologise in advance for the noise if this is the wrong place to ask
>> such questions. I have a couple of eMPIA EM2710 (Silvercrest) USB
>> webcams which work quite well, except for the fact that most of LIRC
>
> Exactly what module do you refer to? Could you just send a snippet
> of dmesg when module is loaded?

Hi, Ezequiel. Thanks a lot for your reply.
I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
where all modules are loaded (since the boot sequence became
asynchronous).

>
>> is unnecessarily loaded when the em28xx module loads. I suppose it
>> shouldn't be necessary, since these are webcams and don't have any
>
> Looking at source code, I noticed two things:
> 1. You have a module param named "disable-ir", perhaps you could
> try to use this (do you know how?).

Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
same result. Additionally:

rui@wilykat:~$ lsmod | grep ir
ir_lirc_codec          12901  0
lirc_dev               19204  1 ir_lirc_codec
ir_mce_kbd_decoder     12724  0
ir_sanyo_decoder       12513  0
ir_sony_decoder        12510  0
ir_jvc_decoder         12507  0
ir_rc6_decoder         12507  0
ir_rc5_decoder         12507  0
ir_nec_decoder         12507  0
rc_core                26373  9
ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
rui@wilykat:~$

> 2. EM2710 board is defined like this:
>
>                .name          = "EM2710/EM2750/EM2751 webcam grabber",
>                .xclk          = EM28XX_XCLK_FREQUENCY_20MHZ,
>                .tuner_type    = TUNER_ABSENT,
>                .is_webcam     = 1,
>                .input         = { {
>                        .type     = EM28XX_VMUX_COMPOSITE1,
>                        .vmux     = 0,
>                        .amux     = EM28XX_AMUX_VIDEO,
>                        .gpio     = silvercrest_reg_seq,
>                } },
>
> As opposed to:
>
>                .name         = "Terratec Cinergy 250 USB",
>                .tuner_type   = TUNER_LG_PAL_NEW_TAPC,
>                .has_ir_i2c   = 1,
>                .tda9887_conf = TDA9887_PRESENT,
>                .decoder      = EM28XX_SAA711X,
>                .input        = { {
>                        .type     = EM28XX_VMUX_TELEVISION,
>                        .vmux     = SAA7115_COMPOSITE2,
>                        .amux     = EM28XX_AMUX_LINE_IN,
>                }, {
>                        .type     = EM28XX_VMUX_COMPOSITE1,
>                        .vmux     = SAA7115_COMPOSITE0,
>                        .amux     = EM28XX_AMUX_LINE_IN,
>                }, {
>                        .type     = EM28XX_VMUX_SVIDEO,
>                        .vmux     = SAA7115_SVIDEO3,
>                        .amux     = EM28XX_AMUX_LINE_IN,
>                } },
>        },
>
> Noticed the lack of "has_ir_i2c" definition in the EM2710.
>
> So I don't know how that module is being loaded. Probably I'm missing something.

I also took a look at the module source but couldn't find any "smoking
gun". That said, I'm not a (kernel) programmer... :)

>
> Hope it helps,
> Ezequiel.

Thanks, once again,

Rui Salvaterra

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 58537 bytes --]

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 3.3.0-999-generic (apw@gomeisa) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #201203140409 SMP Wed Mar 14 08:10:51 UTC 2012
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.3.0-999-generic root=UUID=5110142e-fe8a-437a-ba04-3824ed69fb8e ro enable_mtrr_cleanup cgroup_disable=memory nmi_watchdog=0 apparmor=0 transparent_hugepage=always quiet splash vt.handoff=7
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000]   AMD AuthenticAMD
[    0.000000]   Centaur CentaurHauls
[    0.000000] Disabled fast string operations
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009e800 (usable)
[    0.000000]  BIOS-e820: 000000000009e800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cffa0000 (usable)
[    0.000000]  BIOS-e820: 00000000cffa0000 - 00000000cffae000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000cffae000 - 00000000cfff0000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cfff0000 - 00000000e0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[    0.000000]  BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI present.
[    0.000000] DMI: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015  08/13/2009
[    0.000000] e820 update range: 0000000000000000 - 0000000000010000 (usable) ==> (reserved)
[    0.000000] e820 remove range: 00000000000a0000 - 0000000000100000 (usable)
[    0.000000] No AGP bridge found
[    0.000000] last_pfn = 0xcffa0 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-CFFFF write-protect
[    0.000000]   D0000-DFFFF uncachable
[    0.000000]   E0000-EFFFF write-through
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 0E0000000 mask 0E0000000 uncachable
[    0.000000]   1 base 000000000 mask 000000000 write-back
[    0.000000]   2 disabled
[    0.000000]   3 disabled
[    0.000000]   4 disabled
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] original variable MTRRs
[    0.000000] reg 0, base: 3584MB, range: 512MB, type UC
[    0.000000] reg 1, base: 0GB, range: 4GB, type WB
[    0.000000] total RAM covered: 3584M
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000]  gran_size: 64K 	chunk_size: 1G 	num_reg: 2  	lose cover RAM: 0G
[    0.000000] New variable MTRRs
[    0.000000] reg 0, base: 0GB, range: 4GB, type WB
[    0.000000] reg 1, base: 3584MB, range: 512MB, type UC
[    0.000000] found SMP MP-table at [ffff8800000ff780] ff780
[    0.000000] initial memory mapped : 0 - 20000000
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 20480
[    0.000000] init_memory_mapping: 0000000000000000-00000000cffa0000
[    0.000000]  0000000000 - 00cfe00000 page 2M
[    0.000000]  00cfe00000 - 00cffa0000 page 4k
[    0.000000] kernel direct mapping tables up to cffa0000 @ 1fffa000-20000000
[    0.000000] RAMDISK: 37ce0000 - 37e68000
[    0.000000] ACPI: RSDP 00000000000faab0 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 00000000cffa0100 0005C (v01 081309 XSDT0925 20090813 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000cffa0290 000F4 (v04 081309 FACP0925 20090813 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000cffa04a0 070E9 (v02   NVDA NVDAACPI 00001000 INTL 20051117)
[    0.000000] ACPI: FACS 00000000cffae000 00040
[    0.000000] ACPI: APIC 00000000cffa0390 00080 (v02 081309 APIC0925 20090813 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000cffa0410 0003C (v01 081309 OEMMCFG  20090813 MSFT 00000097)
[    0.000000] ACPI: WDRT 00000000cffa0450 00047 (v01 081309 NV-WDRT  20090813 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000cffae040 00079 (v01 081309 OEMB0925 20090813 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cffaa4a0 00038 (v01 081309 OEMHPET0 20090813 MSFT 00000097)
[    0.000000] ACPI: NVHD 00000000cffae0c0 00284 (v01 081309  NVHDCP  20090813 MSFT 00000097)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] No NUMA configuration found
[    0.000000] Faking a node at 0000000000000000-00000000cffa0000
[    0.000000] Initmem setup node 0 0000000000000000-00000000cffa0000
[    0.000000]   NODE_DATA [00000000cff9b000 - 00000000cff9ffff]
[    0.000000]  [ffffea0000000000-ffffea00033fffff] PMD -> [ffff8800cc200000-ffff8800cf5fffff] on node 0
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA      0x00000010 -> 0x00001000
[    0.000000]   DMA32    0x00001000 -> 0x00100000
[    0.000000]   Normal   empty
[    0.000000] Movable zone start PFN for each node
[    0.000000] Early memory PFN ranges
[    0.000000]     0: 0x00000010 -> 0x0000009e
[    0.000000]     0: 0x00000100 -> 0x000cffa0
[    0.000000] On node 0 totalpages: 851758
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 5 pages reserved
[    0.000000]   DMA zone: 3913 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 13247 pages used for memmap
[    0.000000]   DMA32 zone: 834529 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x4008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 17, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] ACPI: IRQ14 used by override.
[    0.000000] ACPI: IRQ15 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000
[    0.000000] SMP: Allowing 4 CPUs, 0 hotplug CPUs
[    0.000000] nr_irqs_gsi: 40
[    0.000000] PM: Registered nosave memory: 000000000009e000 - 000000000009f000
[    0.000000] PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
[    0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
[    0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
[    0.000000] Allocating PCI resources starting at e0000000 (gap: e0000000:1ec00000)
[    0.000000] Booting paravirtualized kernel on bare hardware
[    0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:4 nr_node_ids:1
[    0.000000] PERCPU: Embedded 28 pages/cpu @ffff8800cfc00000 s82624 r8192 d23872 u524288
[    0.000000] pcpu-alloc: s82624 r8192 d23872 u524288 alloc=1*2097152
[    0.000000] pcpu-alloc: [0] 0 1 2 3 
[    0.000000] Built 1 zonelists in Node order, mobility grouping on.  Total pages: 838442
[    0.000000] Policy zone: DMA32
[    0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.3.0-999-generic root=UUID=5110142e-fe8a-437a-ba04-3824ed69fb8e ro enable_mtrr_cleanup cgroup_disable=memory nmi_watchdog=0 apparmor=0 transparent_hugepage=always quiet splash vt.handoff=7
[    0.000000] Disabling memory control group subsystem
[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
[    0.000000] Checking aperture...
[    0.000000] No AGP bridge found
[    0.000000] Calgary: detecting Calgary via BIOS EBDA area
[    0.000000] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[    0.000000] Memory: 3335968k/3407488k available (6578k kernel code, 456k absent, 71064k reserved, 6550k data, 912k init)
[    0.000000] SLUB: Genslabs=15, HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] 	RCU dyntick-idle grace-period acceleration is enabled.
[    0.000000] NR_IRQS:16640 nr_irqs:712 16
[    0.000000] Extended CMOS year: 2000
[    0.000000] spurious 8259A interrupt: IRQ7.
[    0.000000] Console: colour dummy device 80x25
[    0.000000] console [tty0] enabled
[    0.000000] hpet clockevent registered
[    0.000000] Fast TSC calibration using PIT
[    0.000000] Detected 1999.919 MHz processor.
[    0.004007] Calibrating delay loop (skipped), value calculated using timer frequency.. 3999.83 BogoMIPS (lpj=7999676)
[    0.004018] pid_max: default: 32768 minimum: 301
[    0.004074] Security Framework initialized
[    0.004083] AppArmor: AppArmor disabled by boot time parameter
[    0.008701] Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
[    0.011837] Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
[    0.013261] Mount-cache hash table entries: 256
[    0.013601] Initializing cgroup subsys cpuacct
[    0.013608] Initializing cgroup subsys memory
[    0.013629] Initializing cgroup subsys devices
[    0.013634] Initializing cgroup subsys freezer
[    0.013639] Initializing cgroup subsys blkio
[    0.013657] Initializing cgroup subsys perf_event
[    0.013722] Disabled fast string operations
[    0.013731] CPU: Physical Processor ID: 0
[    0.013735] CPU: Processor Core ID: 0
[    0.013740] mce: CPU supports 5 MCE banks
[    0.013755] CPU0: Thermal monitoring enabled (TM1)
[    0.013763] using mwait in idle threads.
[    0.016856] ACPI: Core revision 20120111
[    0.027264] ftrace: allocating 25264 entries in 99 pages
[    0.044636] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.084895] CPU0: Intel(R) Atom(TM) CPU  330   @ 1.60GHz stepping 02
[    0.088004] Performance Events: PEBS fmt0+, Atom events, Intel PMU driver.
[    0.088004] ... version:                3
[    0.088004] ... bit width:              40
[    0.088004] ... generic registers:      2
[    0.088004] ... value mask:             000000ffffffffff
[    0.088004] ... max period:             000000007fffffff
[    0.088004] ... fixed-purpose events:   3
[    0.088004] ... event mask:             0000000700000003
[    0.088004] Booting Node   0, Processors  #1
[    0.088004] smpboot cpu 1: start_ip = 99000
[    0.008000] Disabled fast string operations
[    0.096226]  #2
[    0.096231] smpboot cpu 2: start_ip = 99000
[    0.008000] Disabled fast string operations
[    0.112297]  #3 Ok.
[    0.112302] smpboot cpu 3: start_ip = 99000
[    0.008000] Disabled fast string operations
[    0.128035] Brought up 4 CPUs
[    0.128042] Total of 4 processors activated (15999.35 BogoMIPS).
[    0.132373] devtmpfs: initialized
[    0.139556] EVM: security.selinux
[    0.139561] EVM: security.SMACK64
[    0.139565] EVM: security.capability
[    0.139666] PM: Registering ACPI NVS region at cffae000 (270336 bytes)
[    0.141942] print_constraints: dummy: 
[    0.142024] RTC time: 18:31:01, date: 03/14/12
[    0.142125] NET: Registered protocol family 16
[    0.142437] ACPI: bus type pci registered
[    0.142576] PCI: MMCONFIG for domain 0000 [bus 00-1f] at [mem 0xfc000000-0xfdffffff] (base 0xfc000000)
[    0.142583] PCI: not using MMCONFIG
[    0.142588] PCI: Using configuration type 1 for base access
[    0.144842] bio: create slab <bio-0> at 0
[    0.144842] ACPI: Added _OSI(Module Device)
[    0.144842] ACPI: Added _OSI(Processor Device)
[    0.144842] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.144842] ACPI: Added _OSI(Processor Aggregator Device)
[    0.148921] ACPI: EC: Look up EC in DSDT
[    0.152929] ACPI: Executed 1 blocks of module-level executable AML code
[    0.159189] ACPI: Interpreter enabled
[    0.159202] ACPI: (supports S0 S1 S4 S5)
[    0.159245] ACPI: Using IOAPIC for interrupt routing
[    0.159308] PCI: MMCONFIG for domain 0000 [bus 00-1f] at [mem 0xfc000000-0xfdffffff] (base 0xfc000000)
[    0.162135] PCI: MMCONFIG at [mem 0xfc000000-0xfdffffff] reserved in ACPI motherboard resources
[    0.185798] ACPI: No dock devices found.
[    0.185812] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.186399] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.186854] pci_root PNP0A03:00: host bridge window [io  0x0000-0x0cf7]
[    0.186861] pci_root PNP0A03:00: host bridge window [io  0x0d00-0xffff]
[    0.186867] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[    0.186873] pci_root PNP0A03:00: host bridge window [mem 0x000d0000-0x000dffff]
[    0.186879] pci_root PNP0A03:00: host bridge window [mem 0xe0000000-0xfbffffff]
[    0.186885] pci_root PNP0A03:00: host bridge window [mem 0xfe000000-0xfebfffff]
[    0.186994] PCI host bridge to bus 0000:00
[    0.187000] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7]
[    0.187006] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff]
[    0.187012] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff]
[    0.187017] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000dffff]
[    0.187023] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xfbffffff]
[    0.187029] pci_bus 0000:00: root bus resource [mem 0xfe000000-0xfebfffff]
[    0.187054] pci 0000:00:00.0: [10de:0a82] type 0 class 0x000600
[    0.187176] pci 0000:00:00.1: [10de:0a88] type 0 class 0x000500
[    0.187345] pci 0000:00:03.0: [10de:0aad] type 0 class 0x000601
[    0.187359] pci 0000:00:03.0: reg 10: [io  0x4f00-0x4fff]
[    0.187422] pci 0000:00:03.1: [10de:0aa4] type 0 class 0x000500
[    0.187524] pci 0000:00:03.2: [10de:0aa2] type 0 class 0x000c05
[    0.187544] pci 0000:00:03.2: reg 10: [io  0x4900-0x493f]
[    0.187574] pci 0000:00:03.2: reg 20: [io  0x4d00-0x4d3f]
[    0.187585] pci 0000:00:03.2: reg 24: [io  0x4e00-0x4e3f]
[    0.187630] pci 0000:00:03.2: PME# supported from D3hot D3cold
[    0.187663] pci 0000:00:03.3: [10de:0a89] type 0 class 0x000500
[    0.187842] pci 0000:00:03.5: [10de:0aa3] type 0 class 0x000b40
[    0.187866] pci 0000:00:03.5: reg 10: [mem 0xfae80000-0xfaefffff]
[    0.188025] pci 0000:00:04.0: [10de:0aa5] type 0 class 0x000c03
[    0.188043] pci 0000:00:04.0: reg 10: [mem 0xfae7f000-0xfae7ffff]
[    0.188107] pci 0000:00:04.0: supports D1 D2
[    0.188112] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.188146] pci 0000:00:04.1: [10de:0aa6] type 0 class 0x000c03
[    0.188166] pci 0000:00:04.1: reg 10: [mem 0xfae7ec00-0xfae7ecff]
[    0.188240] pci 0000:00:04.1: supports D1 D2
[    0.188245] pci 0000:00:04.1: PME# supported from D0 D1 D2 D3hot D3cold
[    0.188282] pci 0000:00:06.0: [10de:0aa7] type 0 class 0x000c03
[    0.188299] pci 0000:00:06.0: reg 10: [mem 0xfae7d000-0xfae7dfff]
[    0.188362] pci 0000:00:06.0: supports D1 D2
[    0.188367] pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.188393] pci 0000:00:06.1: [10de:0aa9] type 0 class 0x000c03
[    0.188413] pci 0000:00:06.1: reg 10: [mem 0xfae7e800-0xfae7e8ff]
[    0.188487] pci 0000:00:06.1: supports D1 D2
[    0.188492] pci 0000:00:06.1: PME# supported from D0 D1 D2 D3hot D3cold
[    0.188529] pci 0000:00:08.0: [10de:0ac0] type 0 class 0x000403
[    0.188546] pci 0000:00:08.0: reg 10: [mem 0xfae78000-0xfae7bfff]
[    0.188610] pci 0000:00:08.0: PME# supported from D3hot D3cold
[    0.188633] pci 0000:00:09.0: [10de:0aab] type 1 class 0x000604
[    0.188698] pci 0000:00:0a.0: [10de:0ab0] type 0 class 0x000200
[    0.188716] pci 0000:00:0a.0: reg 10: [mem 0xfae7c000-0xfae7cfff]
[    0.188726] pci 0000:00:0a.0: reg 14: [io  0xd080-0xd087]
[    0.188737] pci 0000:00:0a.0: reg 18: [mem 0xfae7e400-0xfae7e4ff]
[    0.188748] pci 0000:00:0a.0: reg 1c: [mem 0xfae7e000-0xfae7e00f]
[    0.188794] pci 0000:00:0a.0: supports D1 D2
[    0.188799] pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.188827] pci 0000:00:0b.0: [10de:0ab8] type 0 class 0x000106
[    0.188845] pci 0000:00:0b.0: reg 10: [io  0xd000-0xd007]
[    0.188855] pci 0000:00:0b.0: reg 14: [io  0xcc00-0xcc03]
[    0.188866] pci 0000:00:0b.0: reg 18: [io  0xc880-0xc887]
[    0.188876] pci 0000:00:0b.0: reg 1c: [io  0xc800-0xc803]
[    0.188887] pci 0000:00:0b.0: reg 20: [io  0xc480-0xc48f]
[    0.188897] pci 0000:00:0b.0: reg 24: [mem 0xfae76000-0xfae77fff]
[    0.188995] pci 0000:00:0c.0: [10de:0ac4] type 1 class 0x000604
[    0.189247] pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.189318] pci 0000:00:10.0: [10de:0aa0] type 1 class 0x000604
[    0.189375] pci 0000:00:10.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.189445] pci 0000:00:15.0: [10de:0ac6] type 1 class 0x000604
[    0.189687] pci 0000:00:15.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.189784] pci 0000:00:16.0: [10de:0ac7] type 1 class 0x000604
[    0.190033] pci 0000:00:16.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.190130] pci 0000:00:17.0: [10de:0ac7] type 1 class 0x000604
[    0.190372] pci 0000:00:17.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.190469] pci 0000:00:18.0: [10de:0ac7] type 1 class 0x000604
[    0.190721] pci 0000:00:18.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.190845] pci 0000:00:09.0: PCI bridge to [bus 01-01] (subtractive decode)
[    0.190857] pci 0000:00:09.0:   bridge window [io  0x0000-0x0cf7] (subtractive decode)
[    0.190864] pci 0000:00:09.0:   bridge window [io  0x0d00-0xffff] (subtractive decode)
[    0.190870] pci 0000:00:09.0:   bridge window [mem 0x000a0000-0x000bffff] (subtractive decode)
[    0.190877] pci 0000:00:09.0:   bridge window [mem 0x000d0000-0x000dffff] (subtractive decode)
[    0.190883] pci 0000:00:09.0:   bridge window [mem 0xe0000000-0xfbffffff] (subtractive decode)
[    0.190890] pci 0000:00:09.0:   bridge window [mem 0xfe000000-0xfebfffff] (subtractive decode)
[    0.191043] pci 0000:00:0c.0: PCI bridge to [bus 02-02]
[    0.191123] pci 0000:03:00.0: [10de:087d] type 0 class 0x000300
[    0.191145] pci 0000:03:00.0: reg 10: [mem 0xfb000000-0xfbffffff]
[    0.191161] pci 0000:03:00.0: reg 14: [mem 0xe0000000-0xefffffff 64bit pref]
[    0.191178] pci 0000:03:00.0: reg 1c: [mem 0xf8000000-0xf9ffffff 64bit pref]
[    0.191191] pci 0000:03:00.0: reg 24: [io  0xec00-0xec7f]
[    0.191204] pci 0000:03:00.0: reg 30: [mem 0xfafe0000-0xfaffffff pref]
[    0.191283] pci 0000:00:10.0: PCI bridge to [bus 03-03]
[    0.191292] pci 0000:00:10.0:   bridge window [io  0xe000-0xefff]
[    0.191298] pci 0000:00:10.0:   bridge window [mem 0xfaf00000-0xfbffffff]
[    0.191307] pci 0000:00:10.0:   bridge window [mem 0xe0000000-0xf9ffffff 64bit pref]
[    0.191485] pci 0000:04:00.0: [1814:0781] type 0 class 0x000280
[    0.191505] pci 0000:04:00.0: reg 10: [mem 0xfebf0000-0xfebfffff]
[    0.191616] pci 0000:04:00.0: PME# supported from D0 D3hot
[    0.196051] pci 0000:00:15.0: PCI bridge to [bus 04-04]
[    0.196076] pci 0000:00:15.0:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.196243] pci 0000:00:16.0: PCI bridge to [bus 05-05]
[    0.196437] pci 0000:00:17.0: PCI bridge to [bus 06-06]
[    0.196620] pci 0000:00:18.0: PCI bridge to [bus 07-07]
[    0.196734] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.197059] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PBB0._PRT]
[    0.197163] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IXVE._PRT]
[    0.197243] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR0._PRT]
[    0.197371] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P6._PRT]
[    0.197463] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P7._PRT]
[    0.197553] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P8._PRT]
[    0.197643] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P9._PRT]
[    0.197991]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.198484]  pci0000:00: ACPI _OSC request failed (AE_SUPPORT), returned control mask: 0x0c
[    0.198490] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.219261] ACPI: PCI Interrupt Link [LNKA] (IRQs 16 17 18 19) *0, disabled.
[    0.219543] ACPI: PCI Interrupt Link [LNKB] (IRQs 16 17 18 19) *0, disabled.
[    0.219828] ACPI: PCI Interrupt Link [LNKC] (IRQs 16 17 18 19) *0, disabled.
[    0.220116] ACPI: PCI Interrupt Link [LNKD] (IRQs 16 17 18 19) *0, disabled.
[    0.220390] ACPI: PCI Interrupt Link [LN0A] (IRQs 16 17 18 19) *0, disabled.
[    0.220662] ACPI: PCI Interrupt Link [LN0B] (IRQs 16 17 18 19) *0, disabled.
[    0.220941] ACPI: PCI Interrupt Link [LN0C] (IRQs 16 17 18 19) *0, disabled.
[    0.221214] ACPI: PCI Interrupt Link [LN0D] (IRQs 16 17 18 19) *0, disabled.
[    0.221487] ACPI: PCI Interrupt Link [LN1A] (IRQs 16 17 18 19) *0, disabled.
[    0.221759] ACPI: PCI Interrupt Link [LN1B] (IRQs 16 17 18 19) *0, disabled.
[    0.222033] ACPI: PCI Interrupt Link [LN1C] (IRQs 16 17 18 19) *0, disabled.
[    0.222305] ACPI: PCI Interrupt Link [LN1D] (IRQs 16 17 18 19) *0, disabled.
[    0.222577] ACPI: PCI Interrupt Link [LN2A] (IRQs 16 17 18 19) *0, disabled.
[    0.222849] ACPI: PCI Interrupt Link [LN2B] (IRQs 16 17 18 19) *0, disabled.
[    0.223131] ACPI: PCI Interrupt Link [LN2C] (IRQs 16 17 18 19) *0, disabled.
[    0.223405] ACPI: PCI Interrupt Link [LN2D] (IRQs 16 17 18 19) *0, disabled.
[    0.223684] ACPI: PCI Interrupt Link [LN3A] (IRQs 16 17 18 19) *11
[    0.223958] ACPI: PCI Interrupt Link [LN3B] (IRQs 16 17 18 19) *0, disabled.
[    0.224247] ACPI: PCI Interrupt Link [LN3C] (IRQs 16 17 18 19) *0, disabled.
[    0.224520] ACPI: PCI Interrupt Link [LN3D] (IRQs 16 17 18 19) *0, disabled.
[    0.224809] ACPI: PCI Interrupt Link [LN4A] (IRQs 16 17 18 19) *0, disabled.
[    0.225083] ACPI: PCI Interrupt Link [LN4B] (IRQs 16 17 18 19) *0, disabled.
[    0.225357] ACPI: PCI Interrupt Link [LN4C] (IRQs 16 17 18 19) *0, disabled.
[    0.225630] ACPI: PCI Interrupt Link [LN4D] (IRQs 16 17 18 19) *0, disabled.
[    0.225904] ACPI: PCI Interrupt Link [LN5A] (IRQs 16 17 18 19) *0, disabled.
[    0.226178] ACPI: PCI Interrupt Link [LN5B] (IRQs 16 17 18 19) *0, disabled.
[    0.226452] ACPI: PCI Interrupt Link [LN5C] (IRQs 16 17 18 19) *0, disabled.
[    0.226725] ACPI: PCI Interrupt Link [LN5D] (IRQs 16 17 18 19) *0, disabled.
[    0.227008] ACPI: PCI Interrupt Link [LN6A] (IRQs 16 17 18 19) *0, disabled.
[    0.227284] ACPI: PCI Interrupt Link [LN6B] (IRQs 16 17 18 19) *0, disabled.
[    0.227559] ACPI: PCI Interrupt Link [LN6C] (IRQs 16 17 18 19) *0, disabled.
[    0.227832] ACPI: PCI Interrupt Link [LN6D] (IRQs 16 17 18 19) *0, disabled.
[    0.228128] ACPI: PCI Interrupt Link [LUB0] (IRQs 20 21 22 23) *15
[    0.228409] ACPI: PCI Interrupt Link [LUB2] (IRQs 20 21 22 23) *10
[    0.228696] ACPI: PCI Interrupt Link [LMAC] (IRQs 20 21 22 23) *10
[    0.228974] ACPI: PCI Interrupt Link [LAZA] (IRQs 20 21 22 23) *15
[    0.229252] ACPI: PCI Interrupt Link [SGRU] (IRQs 20 21 22 23) *10
[    0.229530] ACPI: PCI Interrupt Link [LSMB] (IRQs 20 21 22 23) *11
[    0.229809] ACPI: PCI Interrupt Link [LPMU] (IRQs 20 21 22 23) *9
[    0.230087] ACPI: PCI Interrupt Link [LSA0] (IRQs 20 21 22 23) *5
[    0.230402] ACPI: PCI Interrupt Link [LATA] (IRQs 20 21 22 23) *0, disabled.
[    0.230683] ACPI: PCI Interrupt Link [UB11] (IRQs 20 21 22 23) *11
[    0.230961] ACPI: PCI Interrupt Link [UB12] (IRQs 20 21 22 23) *9
[    0.231249] ACPI: PCI Interrupt Link [LRP0] (IRQs 20 21 22 23) *10
[    0.231530] ACPI: PCI Interrupt Link [LRP1] (IRQs 20 21 22 23) *0, disabled.
[    0.231804] ACPI: PCI Interrupt Link [LRP2] (IRQs 20 21 22 23) *0, disabled.
[    0.232101] ACPI: PCI Interrupt Link [LRP3] (IRQs 20 21 22 23) *11
[    0.232390] ACPI: PCI Interrupt Link [LRP4] (IRQs 20 21 22 23) *9
[    0.232678] ACPI: PCI Interrupt Link [LRP5] (IRQs 20 21 22 23) *15
[    0.232967] ACPI: PCI Interrupt Link [LRP6] (IRQs 20 21 22 23) *14
[    0.233217] vgaarb: device added: PCI:0000:03:00.0,decodes=io+mem,owns=io+mem,locks=none
[    0.233217] vgaarb: loaded
[    0.233217] vgaarb: bridge control possible 0000:03:00.0
[    0.233217] SCSI subsystem initialized
[    0.233217] libata version 3.00 loaded.
[    0.233217] usbcore: registered new interface driver usbfs
[    0.233217] usbcore: registered new interface driver hub
[    0.233217] usbcore: registered new device driver usb
[    0.233217] PCI: Using ACPI for IRQ routing
[    0.233217] PCI: pci_cache_line_size set to 64 bytes
[    0.233217] reserve RAM buffer: 000000000009e800 - 000000000009ffff 
[    0.233217] reserve RAM buffer: 00000000cffa0000 - 00000000cfffffff 
[    0.233358] NetLabel: Initializing
[    0.233364] NetLabel:  domain hash size = 128
[    0.233368] NetLabel:  protocols = UNLABELED CIPSOv4
[    0.233392] NetLabel:  unlabeled traffic allowed by default
[    0.233458] HPET: 4 timers in total, 0 timers will be used for per-cpu timer
[    0.233458] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31, 31
[    0.233458] hpet0: 4 comparators, 64-bit 25.000000 MHz counter
[    0.250324] Switching to clocksource hpet
[    0.268726] pnp: PnP ACPI init
[    0.268768] ACPI: bus type pnp registered
[    0.269083] pnp 00:00: [bus 00-ff]
[    0.269090] pnp 00:00: [io  0x0cf8-0x0cff]
[    0.269096] pnp 00:00: [io  0x0000-0x0cf7 window]
[    0.269101] pnp 00:00: [io  0x0d00-0xffff window]
[    0.269107] pnp 00:00: [mem 0x000a0000-0x000bffff window]
[    0.269112] pnp 00:00: [mem 0x000d0000-0x000dffff window]
[    0.269118] pnp 00:00: [mem 0xe0000000-0xfbffffff window]
[    0.269124] pnp 00:00: [mem 0xfe000000-0xfebfffff window]
[    0.269284] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.269399] pnp 00:01: [dma 4]
[    0.269405] pnp 00:01: [io  0x0000-0x000f]
[    0.269410] pnp 00:01: [io  0x0081-0x0083]
[    0.269415] pnp 00:01: [io  0x0087]
[    0.269419] pnp 00:01: [io  0x0089-0x008b]
[    0.269424] pnp 00:01: [io  0x008f]
[    0.269429] pnp 00:01: [io  0x00c0-0x00df]
[    0.269497] pnp 00:01: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.269523] pnp 00:02: [io  0x0061]
[    0.269584] pnp 00:02: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.269611] pnp 00:03: [io  0x00f0-0x00ff]
[    0.269634] pnp 00:03: [irq 13]
[    0.269696] pnp 00:03: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.271057] pnp 00:04: [mem 0x000d0000-0x000d3fff window]
[    0.271065] pnp 00:04: [mem 0x000d4000-0x000d7fff window]
[    0.271070] pnp 00:04: [mem 0x000de000-0x000dffff window]
[    0.271076] pnp 00:04: [io  0x0010-0x001f]
[    0.271081] pnp 00:04: [io  0x0022-0x003f]
[    0.271086] pnp 00:04: [io  0x0044-0x004d]
[    0.271090] pnp 00:04: [io  0x0050-0x005f]
[    0.271101] pnp 00:04: [io  0x0062-0x0063]
[    0.271106] pnp 00:04: [io  0x0065-0x006f]
[    0.271111] pnp 00:04: [io  0x0072-0x007f]
[    0.271115] pnp 00:04: [io  0x0080]
[    0.271120] pnp 00:04: [io  0x0084-0x0086]
[    0.271125] pnp 00:04: [io  0x0088]
[    0.271129] pnp 00:04: [io  0x008c-0x008e]
[    0.271134] pnp 00:04: [io  0x0090-0x009f]
[    0.271138] pnp 00:04: [io  0x00a2-0x00bf]
[    0.271143] pnp 00:04: [io  0x00e0-0x00ef]
[    0.271148] pnp 00:04: [io  0x04d0-0x04d1]
[    0.271153] pnp 00:04: [io  0x0800-0x080f]
[    0.271158] pnp 00:04: [io  0x4000-0x407f]
[    0.271163] pnp 00:04: [io  0x4080-0x40ff]
[    0.271167] pnp 00:04: [io  0x4400-0x447f]
[    0.271172] pnp 00:04: [io  0x4480-0x44ff]
[    0.271177] pnp 00:04: [io  0x4800-0x487f]
[    0.271182] pnp 00:04: [io  0x4880-0x48ff]
[    0.271187] pnp 00:04: [mem 0x00000000-0xffffffffffffffff disabled]
[    0.271193] pnp 00:04: [mem 0xfefe2000-0xfefe3fff]
[    0.271198] pnp 00:04: [mem 0xfefe1000-0xfefe1fff]
[    0.271203] pnp 00:04: [mem 0xfee01000-0xfeefffff]
[    0.271368] system 00:04: [io  0x04d0-0x04d1] has been reserved
[    0.271376] system 00:04: [io  0x0800-0x080f] has been reserved
[    0.271382] system 00:04: [io  0x4000-0x407f] has been reserved
[    0.271388] system 00:04: [io  0x4080-0x40ff] has been reserved
[    0.271395] system 00:04: [io  0x4400-0x447f] has been reserved
[    0.271401] system 00:04: [io  0x4480-0x44ff] has been reserved
[    0.271407] system 00:04: [io  0x4800-0x487f] has been reserved
[    0.271413] system 00:04: [io  0x4880-0x48ff] has been reserved
[    0.271421] system 00:04: [mem 0x000d0000-0x000d3fff window] has been reserved
[    0.271428] system 00:04: [mem 0x000d4000-0x000d7fff window] has been reserved
[    0.271434] system 00:04: [mem 0x000de000-0x000dffff window] has been reserved
[    0.271442] system 00:04: [mem 0xfefe2000-0xfefe3fff] has been reserved
[    0.271448] system 00:04: [mem 0xfefe1000-0xfefe1fff] has been reserved
[    0.271454] system 00:04: [mem 0xfee01000-0xfeefffff] has been reserved
[    0.271463] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.271742] pnp 00:05: [mem 0xfed00000-0xfed00fff]
[    0.271749] pnp 00:05: [irq 2 disabled]
[    0.271765] pnp 00:05: [irq 8]
[    0.271828] pnp 00:05: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.271893] pnp 00:06: [io  0x0070-0x0071]
[    0.271960] pnp 00:06: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.272228] pnp 00:07: [mem 0xfec00000-0xfec00fff]
[    0.272235] pnp 00:07: [mem 0xfee00000-0xfee00fff]
[    0.272349] system 00:07: [mem 0xfec00000-0xfec00fff] could not be reserved
[    0.272357] system 00:07: [mem 0xfee00000-0xfee00fff] has been reserved
[    0.272366] system 00:07: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.272450] pnp 00:08: [io  0x0060]
[    0.272455] pnp 00:08: [io  0x0064]
[    0.272472] pnp 00:08: [irq 1]
[    0.272555] pnp 00:08: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.272884] pnp 00:09: [io  0x0000-0xffffffffffffffff disabled]
[    0.272891] pnp 00:09: [io  0x0a00-0x0a0f]
[    0.272896] pnp 00:09: [io  0x0a10-0x0a1f]
[    0.273003] system 00:09: [io  0x0a00-0x0a0f] has been reserved
[    0.273010] system 00:09: [io  0x0a10-0x0a1f] has been reserved
[    0.273019] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.273168] pnp 00:0a: [mem 0xfc000000-0xfdffffff]
[    0.273277] system 00:0a: [mem 0xfc000000-0xfdffffff] has been reserved
[    0.273286] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.273717] pnp 00:0b: [mem 0x00000000-0x0009ffff]
[    0.273723] pnp 00:0b: [mem 0x000c0000-0x000cffff]
[    0.273729] pnp 00:0b: [mem 0x000e0000-0x000fffff]
[    0.273734] pnp 00:0b: [mem 0x00100000-0xdfffffff]
[    0.273739] pnp 00:0b: [mem 0xfec00000-0xffffffff]
[    0.273868] system 00:0b: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.273876] system 00:0b: [mem 0x000c0000-0x000cffff] could not be reserved
[    0.273883] system 00:0b: [mem 0x000e0000-0x000fffff] could not be reserved
[    0.273890] system 00:0b: [mem 0x00100000-0xdfffffff] could not be reserved
[    0.273897] system 00:0b: [mem 0xfec00000-0xffffffff] could not be reserved
[    0.273905] system 00:0b: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.275867] pnp: PnP ACPI: found 12 devices
[    0.275873] ACPI: ACPI bus type pnp unregistered
[    0.287562] PCI: max bus depth: 1 pci_try_num: 2
[    0.287698] pci 0000:00:09.0: PCI bridge to [bus 01-01]
[    0.287712] pci 0000:00:0c.0: PCI bridge to [bus 02-02]
[    0.287744] pci 0000:00:10.0: PCI bridge to [bus 03-03]
[    0.287750] pci 0000:00:10.0:   bridge window [io  0xe000-0xefff]
[    0.287758] pci 0000:00:10.0:   bridge window [mem 0xfaf00000-0xfbffffff]
[    0.287766] pci 0000:00:10.0:   bridge window [mem 0xe0000000-0xf9ffffff 64bit pref]
[    0.287775] pci 0000:00:15.0: PCI bridge to [bus 04-04]
[    0.287789] pci 0000:00:15.0:   bridge window [mem 0xfeb00000-0xfebfffff]
[    0.287811] pci 0000:00:16.0: PCI bridge to [bus 05-05]
[    0.287842] pci 0000:00:17.0: PCI bridge to [bus 06-06]
[    0.287874] pci 0000:00:18.0: PCI bridge to [bus 07-07]
[    0.287924] pci 0000:00:09.0: setting latency timer to 64
[    0.288437] ACPI: PCI Interrupt Link [LRP0] enabled at IRQ 23
[    0.288480] pci 0000:00:10.0: setting latency timer to 64
[    0.288909] ACPI: PCI Interrupt Link [LRP3] enabled at IRQ 22
[    0.289363] ACPI: PCI Interrupt Link [LRP4] enabled at IRQ 21
[    0.289803] ACPI: PCI Interrupt Link [LRP5] enabled at IRQ 20
[    0.290245] ACPI: PCI Interrupt Link [LRP6] enabled at IRQ 23
[    0.290260] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7]
[    0.290266] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff]
[    0.290272] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff]
[    0.290278] pci_bus 0000:00: resource 7 [mem 0x000d0000-0x000dffff]
[    0.290284] pci_bus 0000:00: resource 8 [mem 0xe0000000-0xfbffffff]
[    0.290290] pci_bus 0000:00: resource 9 [mem 0xfe000000-0xfebfffff]
[    0.290297] pci_bus 0000:01: resource 4 [io  0x0000-0x0cf7]
[    0.290303] pci_bus 0000:01: resource 5 [io  0x0d00-0xffff]
[    0.290308] pci_bus 0000:01: resource 6 [mem 0x000a0000-0x000bffff]
[    0.290314] pci_bus 0000:01: resource 7 [mem 0x000d0000-0x000dffff]
[    0.290320] pci_bus 0000:01: resource 8 [mem 0xe0000000-0xfbffffff]
[    0.290326] pci_bus 0000:01: resource 9 [mem 0xfe000000-0xfebfffff]
[    0.290332] pci_bus 0000:03: resource 0 [io  0xe000-0xefff]
[    0.290337] pci_bus 0000:03: resource 1 [mem 0xfaf00000-0xfbffffff]
[    0.290344] pci_bus 0000:03: resource 2 [mem 0xe0000000-0xf9ffffff 64bit pref]
[    0.290350] pci_bus 0000:04: resource 1 [mem 0xfeb00000-0xfebfffff]
[    0.290440] NET: Registered protocol family 2
[    0.290731] IP route cache hash table entries: 131072 (order: 8, 1048576 bytes)
[    0.293387] TCP established hash table entries: 524288 (order: 11, 8388608 bytes)
[    0.298977] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
[    0.299652] TCP: Hash tables configured (established 524288 bind 65536)
[    0.299658] TCP reno registered
[    0.299690] UDP hash table entries: 2048 (order: 4, 65536 bytes)
[    0.299754] UDP-Lite hash table entries: 2048 (order: 4, 65536 bytes)
[    0.300000] NET: Registered protocol family 1
[    0.300619] ACPI: PCI Interrupt Link [LUB0] enabled at IRQ 22
[    0.408492] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 21
[    0.408952] ACPI: PCI Interrupt Link [UB11] enabled at IRQ 20
[    0.480470] ACPI: PCI Interrupt Link [UB12] enabled at IRQ 23
[    0.480734] pci 0000:03:00.0: Boot video device
[    0.480745] PCI: CLS 64 bytes, default 64
[    0.480864] Trying to unpack rootfs image as initramfs...
[    0.888361] Freeing initrd memory: 1568k freed
[    0.890781] audit: initializing netlink socket (disabled)
[    0.890810] type=2000 audit(1331749860.884:1): initialized
[    0.929279] HugeTLB registered 2 MB page size, pre-allocated 0 pages
[    0.934465] VFS: Disk quotas dquot_6.5.2
[    0.934606] Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.935942] fuse init (API version 7.18)
[    0.936248] msgmni has been set to 6518
[    0.937575] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
[    0.937678] io scheduler noop registered
[    0.937684] io scheduler deadline registered
[    0.937823] io scheduler cfq registered (default)
[    0.938777] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[    0.938826] pciehp: PCI Express Hot Plug Controller Driver version: 0.4
[    0.938962] intel_idle: MWAIT substates: 0x10
[    0.938990] intel_idle: v0.4 model 0x1C
[    0.938995] intel_idle: lapic_timer_reliable_states 0x2
[    0.939226] input: Power Button as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
[    0.939241] ACPI: Power Button [PWRB]
[    0.939365] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    0.939374] ACPI: Power Button [PWRF]
[    0.945624] GHES: HEST is not enabled!
[    0.945896] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[    0.950215] Linux agpgart interface v0.103
[    0.954251] brd: module loaded
[    0.956359] loop: module loaded
[    0.956686] ahci 0000:00:0b.0: version 3.0
[    0.957185] ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 22
[    0.957281] ahci 0000:00:0b.0: irq 40 for MSI/MSI-X
[    0.957308] ahci 0000:00:0b.0: controller can't do PMP, turning off CAP_PMP
[    0.957406] ahci 0000:00:0b.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f impl SATA mode
[    0.957415] ahci 0000:00:0b.0: flags: 64bit ncq sntf led pio slum part sxs 
[    0.957422] ahci 0000:00:0b.0: setting latency timer to 64
[    0.959428] scsi0 : ahci
[    0.959707] scsi1 : ahci
[    0.959917] scsi2 : ahci
[    0.960173] scsi3 : ahci
[    0.960369] scsi4 : ahci
[    0.960565] scsi5 : ahci
[    0.960937] ata1: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76100 irq 40
[    0.960944] ata2: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76180 irq 40
[    0.960951] ata3: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76200 irq 40
[    0.960957] ata4: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76280 irq 40
[    0.960964] ata5: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76300 irq 40
[    0.960970] ata6: SATA max UDMA/133 abar m8192@0xfae76000 port 0xfae76380 irq 40
[    0.961988] Fixed MDIO Bus: probed
[    0.962038] tun: Universal TUN/TAP device driver, 1.6
[    0.962042] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    0.962211] PPP generic driver version 2.4.2
[    0.962527] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    0.962608] ehci_hcd 0000:00:04.1: setting latency timer to 64
[    0.962615] ehci_hcd 0000:00:04.1: EHCI Host Controller
[    0.962761] ehci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 1
[    0.962798] ehci_hcd 0000:00:04.1: debug port 1
[    0.962811] ehci_hcd 0000:00:04.1: cache line size of 64 is not supported
[    0.962851] ehci_hcd 0000:00:04.1: irq 21, io mem 0xfae7ec00
[    0.972047] ehci_hcd 0000:00:04.1: USB 2.0 started, EHCI 1.00
[    0.972380] hub 1-0:1.0: USB hub found
[    0.972392] hub 1-0:1.0: 6 ports detected
[    0.972589] ehci_hcd 0000:00:06.1: setting latency timer to 64
[    0.972596] ehci_hcd 0000:00:06.1: EHCI Host Controller
[    0.972741] ehci_hcd 0000:00:06.1: new USB bus registered, assigned bus number 2
[    0.972782] ehci_hcd 0000:00:06.1: debug port 1
[    0.972795] ehci_hcd 0000:00:06.1: cache line size of 64 is not supported
[    0.972837] ehci_hcd 0000:00:06.1: irq 23, io mem 0xfae7e800
[    0.984042] ehci_hcd 0000:00:06.1: USB 2.0 started, EHCI 1.00
[    0.984349] hub 2-0:1.0: USB hub found
[    0.984360] hub 2-0:1.0: 6 ports detected
[    0.984540] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[    0.984603] ohci_hcd 0000:00:04.0: setting latency timer to 64
[    0.984610] ohci_hcd 0000:00:04.0: OHCI Host Controller
[    0.984756] ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 3
[    0.984806] ohci_hcd 0000:00:04.0: irq 22, io mem 0xfae7f000
[    1.042326] hub 3-0:1.0: USB hub found
[    1.042339] hub 3-0:1.0: 6 ports detected
[    1.042515] ohci_hcd 0000:00:06.0: setting latency timer to 64
[    1.042522] ohci_hcd 0000:00:06.0: OHCI Host Controller
[    1.042676] ohci_hcd 0000:00:06.0: new USB bus registered, assigned bus number 4
[    1.042725] ohci_hcd 0000:00:06.0: irq 20, io mem 0xfae7d000
[    1.098299] hub 4-0:1.0: USB hub found
[    1.098312] hub 4-0:1.0: 6 ports detected
[    1.098469] uhci_hcd: USB Universal Host Controller Interface driver
[    1.098616] usbcore: registered new interface driver libusual
[    1.098701] i8042: PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[    1.098706] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[    1.099126] serio: i8042 KBD port at 0x60,0x64 irq 1
[    1.099505] mousedev: PS/2 mouse device common for all mice
[    1.099904] rtc_cmos 00:06: RTC can wake from S4
[    1.100248] rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
[    1.100316] rtc0: alarms up to one year, y3k, 114 bytes nvram, hpet irqs
[    1.100526] device-mapper: uevent: version 1.0.3
[    1.100742] device-mapper: ioctl: 4.22.0-ioctl (2011-10-19) initialised: dm-devel@redhat.com
[    1.100859] cpuidle: using governor ladder
[    1.101020] cpuidle: using governor menu
[    1.101026] EFI Variables Facility v0.08 2004-May-17
[    1.101545] TCP cubic registered
[    1.101824] NET: Registered protocol family 10
[    1.103038] NET: Registered protocol family 17
[    1.103085] Registering the dns_resolver key type
[    1.103531] PM: Hibernation image not present or could not be loaded.
[    1.103563] registered taskstats version 1
[    1.118436] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[    1.122491]   Magic number: 4:420:544
[    1.122560] tty ttyS20: hash matches
[    1.122775] rtc_cmos 00:06: setting system clock to 2012-03-14 18:31:02 UTC (1331749862)
[    1.122864] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[    1.122869] EDD information not available.
[    1.280064] ata5: SATA link down (SStatus 0 SControl 300)
[    1.280104] ata6: SATA link down (SStatus 0 SControl 300)
[    1.280138] ata3: SATA link down (SStatus 0 SControl 300)
[    1.280168] ata2: SATA link down (SStatus 0 SControl 300)
[    1.280199] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.280229] ata4: SATA link down (SStatus 0 SControl 300)
[    1.281926] ata1.00: ATA-8: WDC WD10EACS-00D6B1, 01.01A01, max UDMA/133
[    1.281933] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    1.282754] ata1.00: configured for UDMA/133
[    1.283073] scsi 0:0:0:0: Direct-Access     ATA      WDC WD10EACS-00D 01.0 PQ: 0 ANSI: 5
[    1.283487] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    1.283497] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[    1.283799] sd 0:0:0:0: [sda] Write Protect is off
[    1.283808] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.283916] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.284071] usb 1-2: new high-speed USB device number 2 using ehci_hcd
[    1.299946]  sda: sda1 sda2 sda3 sda4
[    1.301145] sd 0:0:0:0: [sda] Attached SCSI disk
[    1.305093] Freeing unused kernel memory: 912k freed
[    1.305628] Write protecting the kernel read-only data: 12288k
[    1.318642] Freeing unused kernel memory: 1596k freed
[    1.329616] Freeing unused kernel memory: 1220k freed
[    1.375725] udevd[101]: starting version 173
[    1.528177] usb 1-3: new high-speed USB device number 3 using ehci_hcd
[    1.844048] EXT4-fs (sda3): mounted filesystem with writeback data mode. Opts: (null)
[    1.888055] Refined TSC clocksource calibration: 1999.968 MHz.
[    1.888068] Switching to clocksource tsc
[    2.168058] usb 4-1: new low-speed USB device number 2 using ohci_hcd
[    3.403006] Adding 1951740k swap on /dev/sda1.  Priority:-1 extents:1 across:1951740k 
[    3.474251] udevd[335]: starting version 173
[    3.886001] lp: driver loaded but no devices found
[    4.077591] i2c i2c-0: nForce2 SMBus adapter at 0x4d00
[    4.077608] ACPI Warning: 0x0000000000004e00-0x0000000000004e3f SystemIO conflicts with Region \_SB_.PCI0.SM00 1 (20120111/utaddress-251)
[    4.077630] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[    4.123510] wmi: Mapper loaded
[    4.197707] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    4.437673] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.64.
[    4.438475] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 21
[    4.438499] forcedeth 0000:00:0a.0: setting latency timer to 64
[    4.501964] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x732 @ 3, addr 00:01:2e:23:24:67
[    4.501974] forcedeth 0000:00:0a.0: highdma csum pwrctl gbit lnktim msi desc-v3
[    4.504964] usbcore: registered new interface driver uas
[    4.542603] cfg80211: Calling CRDA to update world regulatory domain
[    4.731491] input: USB Optical Wheel Mouse as /devices/pci0000:00/0000:00:06.0/usb4/4-1/4-1:1.0/input/input3
[    4.732343] generic-usb 0003:04FC:0003.0001: input,hidraw0: USB HID v1.10 Mouse [USB Optical Wheel Mouse] on usb-0000:00:06.0-1/input0
[    4.732435] usbcore: registered new interface driver usbhid
[    4.732442] usbhid: USB HID core driver
[    4.913476] IR NEC protocol handler initialized
[    4.955707] [drm] Initialized drm 1.1.0 20060810
[    5.002250] IR RC5(x) protocol handler initialized
[    5.021540] Linux video capture interface: v2.00
[    5.080067] em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0)
[    5.080076] em28xx: Video interface 0 found
[    5.080761] em28xx #0: chip ID is em2710
[    5.114076] init: network-interface (lo) pre-start process (499) terminated with status 1
[    5.173585] em28xx #0: board has no eeprom
[    5.216700] IR RC6 protocol handler initialized
[    5.356037] em28xx #0: Sensor is mt9v011, using model Silvercrest Webcam 1.3mpix entry.
[    5.356056] em28xx #0: Identified as Silvercrest Webcam 1.3mpix (card=71)
[    5.417395] mt9v011 1-005d: chip found @ 0xba (em28xx #0 - chip version 0x8243)
[    5.417509] em28xx #0: Config register raw data: 0x00
[    5.611137] ACPI: PCI Interrupt Link [LN3A] enabled at IRQ 19
[    5.619464] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
[    5.619479] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619488] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
[    5.619500] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619508] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
[    5.619519] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619528] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
[    5.619538] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619546] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
[    5.619553] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619558] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
[    5.619565] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619570] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
[    5.619577] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619582] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
[    5.619589] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619594] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
[    5.619601] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619606] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
[    5.619612] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619618] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
[    5.619625] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2000 mBm)
[    5.619630] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule:
[    5.619637] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
[    5.619642] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule:
[    5.619649] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
[    5.619654] cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width channel with regulatory rule:
[    5.619661] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (600 mBi, 2000 mBm)
[    5.651738] VGA switcheroo: detected Optimus DSM method \ handle
[    5.652422] ACPI: PCI Interrupt Link [SGRU] enabled at IRQ 20
[    5.652439] nouveau 0000:03:00.0: setting latency timer to 64
[    5.655539] [drm] nouveau 0000:03:00.0: Detected an NV50 generation card (0x0ace80b1)
[    5.661630] [drm] nouveau 0000:03:00.0: Attempting to load BIOS image from PRAMIN
[    5.706205] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    5.708001] Registered led device: rt2800pci-phy0::radio
[    5.708115] Registered led device: rt2800pci-phy0::assoc
[    5.708205] Registered led device: rt2800pci-phy0::quality
[    5.727237] [drm] nouveau 0000:03:00.0: ... appears to be valid
[    5.727254] [drm] nouveau 0000:03:00.0: BIT BIOS found
[    5.727265] [drm] nouveau 0000:03:00.0: Bios version 62.79.65.00
[    5.727275] [drm] nouveau 0000:03:00.0: TMDS table version 2.0
[    5.728749] [drm] nouveau 0000:03:00.0: MXM: no VBIOS data, nothing to do
[    5.728761] [drm] nouveau 0000:03:00.0: DCB version 4.0
[    5.728772] [drm] nouveau 0000:03:00.0: DCB outp 00: 02000300 0000001e
[    5.728782] [drm] nouveau 0000:03:00.0: DCB outp 01: 01011322 00020030
[    5.728791] [drm] nouveau 0000:03:00.0: DCB outp 02: 02022332 00020010
[    5.728799] [drm] nouveau 0000:03:00.0: DCB conn 00: 00000000
[    5.728808] [drm] nouveau 0000:03:00.0: DCB conn 01: 00001131
[    5.728816] [drm] nouveau 0000:03:00.0: DCB conn 02: 00002261
[    5.728830] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table 0 at offset 0xDEEA
[    5.768397] IR JVC protocol handler initialized
[    5.772503] IR Sony protocol handler initialized
[    5.785027] em28xx #0: v4l2 driver version 0.1.3
[    5.813397] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table 1 at offset 0xE1C2
[    5.813405] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table 2 at offset 0xE1C4
[    5.813418] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table 3 at offset 0xE285
[    5.813432] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table 4 at offset 0xE34A
[    5.813439] [drm] nouveau 0000:03:00.0: Parsing VBIOS init table at offset 0xE3AF
[    5.824569] IR SANYO protocol handler initialized
[    5.833306] [drm] nouveau 0000:03:00.0: 0xE3AF: Condition still not met after 20ms, skipping following opcodes
[    5.846512] [drm] nouveau 0000:03:00.0: 4 available performance level(s)
[    5.846525] [drm] nouveau 0000:03:00.0: 0: core 200MHz shader 400MHz voltage 1010mV fanspeed 60%
[    5.846535] [drm] nouveau 0000:03:00.0: 1: core 300MHz shader 600MHz voltage 1010mV fanspeed 100%
[    5.846543] [drm] nouveau 0000:03:00.0: 2: core 350MHz shader 800MHz voltage 1010mV fanspeed 100%
[    5.846554] [drm] nouveau 0000:03:00.0: 3: core 450MHz shader 1100MHz voltage 1010mV fanspeed 100%
[    5.846569] [drm] nouveau 0000:03:00.0: c:
[    5.847732] IR MCE Keyboard/mouse protocol handler initialized
[    5.851726] [TTM] Zone  kernel: Available graphics memory: 1670632 kiB.
[    5.851733] [TTM] Initializing pool allocator.
[    5.851746] [TTM] Initializing DMA pool allocator.
[    5.851779] [drm] nouveau 0000:03:00.0: Detected 256MiB VRAM
[    5.851785] [drm] nouveau 0000:03:00.0: Stolen system memory at: 0x00d0000000
[    5.851800] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
[    5.851819] [drm] nouveau 0000:03:00.0: 64 MiB GART (aperture)
[    5.870869] nouveau 0000:03:00.0: irq 41 for MSI/MSI-X
[    5.870900] [drm] nouveau 0000:03:00.0: enabled MSI
[    5.885546] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[    5.885557] [drm] No driver support for vblank timestamp query.
[    5.886929] cfg80211: Updating information on frequency 2412 MHz for a 20 MHz width channel with regulatory rule:
[    5.886941] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.886949] cfg80211: Updating information on frequency 2417 MHz for a 20 MHz width channel with regulatory rule:
[    5.886958] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.886965] cfg80211: Updating information on frequency 2422 MHz for a 20 MHz width channel with regulatory rule:
[    5.886974] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.886982] cfg80211: Updating information on frequency 2427 MHz for a 20 MHz width channel with regulatory rule:
[    5.886990] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.886998] cfg80211: Updating information on frequency 2432 MHz for a 20 MHz width channel with regulatory rule:
[    5.887006] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887014] cfg80211: Updating information on frequency 2437 MHz for a 20 MHz width channel with regulatory rule:
[    5.887022] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887030] cfg80211: Updating information on frequency 2442 MHz for a 20 MHz width channel with regulatory rule:
[    5.887038] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887046] cfg80211: Updating information on frequency 2447 MHz for a 20 MHz width channel with regulatory rule:
[    5.887054] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887062] cfg80211: Updating information on frequency 2452 MHz for a 20 MHz width channel with regulatory rule:
[    5.887070] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887078] cfg80211: Updating information on frequency 2457 MHz for a 20 MHz width channel with regulatory rule:
[    5.887086] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887094] cfg80211: Updating information on frequency 2462 MHz for a 20 MHz width channel with regulatory rule:
[    5.887102] cfg80211: 2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887110] cfg80211: Updating information on frequency 2467 MHz for a 20 MHz width channel with regulatory rule:
[    5.887119] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    5.887126] cfg80211: Updating information on frequency 2472 MHz for a 20 MHz width channel with regulatory rule:
[    5.887135] cfg80211: 2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    5.887142] cfg80211: Updating information on frequency 2484 MHz for a 20 MHz width channel with regulatory rule:
[    5.887151] cfg80211: 2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    5.887159] cfg80211: World regulatory domain updated:
[    5.887164] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[    5.887173] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887180] cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    5.887188] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[    5.887196] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.887204] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[    5.916086] lirc_dev: IR Remote Control driver registered, major 250 
[    5.917186] IR LIRC bridge handler initialized
[    6.018900] [drm] nouveau 0000:03:00.0: allocated 1920x1080 fb: 0x2f0000, bo ffff8800c963d800
[    6.019167] fbcon: nouveaufb (fb0) is primary device
[    6.038143] Console: switching to colour frame buffer device 240x67
[    6.040637] fb0: nouveaufb frame buffer device
[    6.040642] drm: registered panic notifier
[    6.040654] [drm] Initialized nouveau 0.0.16 20090420 for 0000:03:00.0 on minor 0
[    6.196283] em28xx #0: V4L2 video device registered as video0
[    6.196430] usbcore: registered new interface driver em28xx
[    6.212947] snd_hda_intel 0000:00:08.0: power state changed by ACPI to D0
[    6.212967] snd_hda_intel 0000:00:08.0: power state changed by ACPI to D0
[    6.213684] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 23
[    6.213703] hda_intel: Disabling MSI
[    6.213781] snd_hda_intel 0000:00:08.0: setting latency timer to 64
[    8.232377] input: HDA NVidia Line as /devices/pci0000:00/0000:00:08.0/sound/card0/input4
[    8.232804] input: HDA NVidia Front Mic as /devices/pci0000:00/0000:00:08.0/sound/card0/input5
[    8.233143] input: HDA NVidia Rear Mic as /devices/pci0000:00/0000:00:08.0/sound/card0/input6
[    8.233466] input: HDA NVidia Front Headphone as /devices/pci0000:00/0000:00:08.0/sound/card0/input7
[    8.233785] input: HDA NVidia Line Out as /devices/pci0000:00/0000:00:08.0/sound/card0/input8
[    8.255861] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro
[    9.029899] EXT4-fs (sda4): barriers disabled
[    9.103389] EXT4-fs (sda4): mounted filesystem with writeback data mode. Opts: (null)
[    9.548223] RPC: Registered named UNIX socket transport module.
[    9.548233] RPC: Registered udp transport module.
[    9.548239] RPC: Registered tcp transport module.
[    9.548245] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    9.619063] FS-Cache: Loaded
[    9.651149] FS-Cache: Netfs 'nfs' registered for caching
[    9.669637] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    9.976567] init: failsafe main process (738) killed by TERM signal
[   12.064554] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[   12.064825] NFSD: starting 90-second grace period
[   15.548295] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,commit=0
[   15.719026] EXT4-fs (sda4): re-mounted. Opts: commit=0
[   16.314035] zram: module is from the staging directory, the quality is unknown, you have been warned.
[   16.314653] zram: Creating 4 devices ...
[   16.357858] Adding 208836k swap on /dev/zram0.  Priority:5 extents:1 across:208836k SS
[   16.361674] Adding 208836k swap on /dev/zram1.  Priority:5 extents:1 across:208836k SS
[   16.364972] Adding 208836k swap on /dev/zram2.  Priority:5 extents:1 across:208836k SS
[   16.367920] Adding 208836k swap on /dev/zram3.  Priority:5 extents:1 across:208836k SS
[   16.394213] init: plymouth-stop pre-start process (1178) terminated with status 1
[   20.121515] EXT4-fs (sda3): re-mounted. Opts: errors=remount-ro,commit=0
[   20.134470] EXT4-fs (sda4): re-mounted. Opts: commit=0
[   22.928056] eth0: no IPv6 routers present

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Ezequiel García]

Hi,

2012/3/14 Rui Salvaterra <rsalvaterra@gmail.com>:
>
> Hi, Ezequiel. Thanks a lot for your reply.
> I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
> where all modules are loaded (since the boot sequence became
> asynchronous).

Indeed.

>
>
> Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
> same result. Additionally:
>
> rui@wilykat:~$ lsmod | grep ir
> ir_lirc_codec          12901  0
> lirc_dev               19204  1 ir_lirc_codec
> ir_mce_kbd_decoder     12724  0
> ir_sanyo_decoder       12513  0
> ir_sony_decoder        12510  0
> ir_jvc_decoder         12507  0
> ir_rc6_decoder         12507  0
> ir_rc5_decoder         12507  0
> ir_nec_decoder         12507  0
> rc_core                26373  9
> ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
> rui@wilykat:~$

Mmmm...
Are you completely sure that em28xx driver is triggering the load of
the ir related modules?
Perhaps you could disable the module (blacklist, or compile out the
module, or erase em28xx.ko to make sure)
so you can see that effectively em28xx doesn't load and the rest of
the modules doesn't load either,
do you follow my line of reasoning?

I'm also no kernel expert, just trying to be helpful.

Hope it helps,
Ezequiel.

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Rui Salvaterra]

2012/3/14 Ezequiel García <elezegarcia@gmail.com>:
> Hi,
>
> 2012/3/14 Rui Salvaterra <rsalvaterra@gmail.com>:
>>
>> Hi, Ezequiel. Thanks a lot for your reply.
>> I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
>> where all modules are loaded (since the boot sequence became
>> asynchronous).
>
> Indeed.
>
>>
>>
>> Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
>> same result. Additionally:
>>
>> rui@wilykat:~$ lsmod | grep ir
>> ir_lirc_codec          12901  0
>> lirc_dev               19204  1 ir_lirc_codec
>> ir_mce_kbd_decoder     12724  0
>> ir_sanyo_decoder       12513  0
>> ir_sony_decoder        12510  0
>> ir_jvc_decoder         12507  0
>> ir_rc6_decoder         12507  0
>> ir_rc5_decoder         12507  0
>> ir_nec_decoder         12507  0
>> rc_core                26373  9
>> ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
>> rui@wilykat:~$
>
> Mmmm...
> Are you completely sure that em28xx driver is triggering the load of
> the ir related modules?

I'm positive, the LIRC modules aren't loaded at all if I boot with the
webcam disconnected. As soon as I plug it into an USB port, em28xx and
LIRC are loaded.

> Perhaps you could disable the module (blacklist, or compile out the
> module, or erase em28xx.ko to make sure)
> so you can see that effectively em28xx doesn't load and the rest of
> the modules doesn't load either,
> do you follow my line of reasoning?

Ok, I did some more testing, here's what I found out. If I blacklist
em28xx, no modules are loaded. Afterwards, I allowed em28xx to load
and appended

blacklist rc_core
blacklist ir_lirc_codec
blacklist lirc_dev
blacklist ir_mce_kbd_decoder
blacklist ir_sanyo_decoder
blacklist ir_sony_decoder
blacklist ir_jvc_decoder
blacklist ir_rc6_decoder
blacklist ir_rc5_decoder
blacklist ir_nec_decoder

to /etc/modprobe.d/blacklist.conf (basically blacklisted all LIRC
stuff), but it also didn't work. And I still have em28xx disable_ir=1.

>
> I'm also no kernel expert, just trying to be helpful.
>
> Hope it helps,
> Ezequiel.

Every bit of help is appreciated, thanks a lot! :)

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Ezequiel García]

Hi,

>
> I'm positive, the LIRC modules aren't loaded at all if I boot with the
> webcam disconnected. As soon as I plug it into an USB port, em28xx and
> LIRC are loaded.
>

So... why don't you post *this* dmesg:
First boot the computer.
Then change the kernel debug level so to get every output possible.
Then insert the module.

This dmesg is of some interest, not the previous one.

A couple of things you can test:

1. If your module is getting loaded when
the device is plugged, then udev
must be running. I suggest you to
turn it off, just to remove it from the equation.
Once you do this, you'll have to load module
manually.

2. Also modprobe maybe handling dependencies.
To check this you can do:

$ modprobe -v em28xx

3. You can try *not* to use modprobe. So
start fresh (from boot) and load with insmod
providing full path, like this:

$ insmod /lib/modules/3.3.0-rc3-athlon-full-preempt-gentoo+/kernel/drivers/media/video/em28xx/em28xx.ko

Probably you'll bump into unknown symbol errors.
You can see them with dmesg.

Hope it helps,
Ezequiel.

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Mauro Carvalho Chehab]

Em 14-03-2012 21:28, Rui Salvaterra escreveu:
> 2012/3/14 Ezequiel García <elezegarcia@gmail.com>:
>> Hi,
>>
>> 2012/3/14 Rui Salvaterra <rsalvaterra@gmail.com>:
>>>
>>> Hi, Ezequiel. Thanks a lot for your reply.
>>> I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
>>> where all modules are loaded (since the boot sequence became
>>> asynchronous).
>>
>> Indeed.
>>
>>>
>>>
>>> Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
>>> same result. Additionally:
>>>
>>> rui@wilykat:~$ lsmod | grep ir
>>> ir_lirc_codec          12901  0
>>> lirc_dev               19204  1 ir_lirc_codec
>>> ir_mce_kbd_decoder     12724  0
>>> ir_sanyo_decoder       12513  0
>>> ir_sony_decoder        12510  0
>>> ir_jvc_decoder         12507  0
>>> ir_rc6_decoder         12507  0
>>> ir_rc5_decoder         12507  0
>>> ir_nec_decoder         12507  0
>>> rc_core                26373  9
>>> ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
>>> rui@wilykat:~$
>>
>> Mmmm...
>> Are you completely sure that em28xx driver is triggering the load of
>> the ir related modules?
> 
> I'm positive, the LIRC modules aren't loaded at all if I boot with the
> webcam disconnected. As soon as I plug it into an USB port, em28xx and
> LIRC are loaded.
> 
>> Perhaps you could disable the module (blacklist, or compile out the
>> module, or erase em28xx.ko to make sure)
>> so you can see that effectively em28xx doesn't load and the rest of
>> the modules doesn't load either,
>> do you follow my line of reasoning?
> 
> Ok, I did some more testing, here's what I found out. If I blacklist
> em28xx, no modules are loaded. Afterwards, I allowed em28xx to load
> and appended
> 
> blacklist rc_core
> blacklist ir_lirc_codec
> blacklist lirc_dev
> blacklist ir_mce_kbd_decoder
> blacklist ir_sanyo_decoder
> blacklist ir_sony_decoder
> blacklist ir_jvc_decoder
> blacklist ir_rc6_decoder
> blacklist ir_rc5_decoder
> blacklist ir_nec_decoder
> 
> to /etc/modprobe.d/blacklist.conf (basically blacklisted all LIRC
> stuff), but it also didn't work. And I still have em28xx disable_ir=1.

The em28xx module requires IR support from rc_core, as most em28xx devices
support it. It can be compiled without IR support, but, as the em28xx-input
is not on a separate module, and it contains some calls to rc_core functions
like rc_register_device, modprobe will load rc_core, and rc_core will load
the decoders, including lirc_dev.

Those modules are small and won't be running if all you have are the webcams.
The optimization to not load those modules is not big, so nobody had time
yet to do it.

Anyway, if you want to fix it, there are two possible approaches:

1) change rc_core to not load the IR decoders at load time, postponing it
   to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device.
  
A patch for it shouldn't be hard. All you need to do is to move ir_raw_init()
to rc_register_device() and add a logic there to call it for the first
raw device.

With such patch, rc_core module will still be loaded.

2) change em28xx-input.c to be a separate module, called only when a device
has IR. It will need to have a logic similar to em28xx-dvb and em28xx-alsa
modules.

It is not hard to write such patch, as most of the logic is already there,
but it is not as trivial as approach (1).

It probably makes sense for both approaches (1) and (2), as not all boards
support "raw" devices. In the case of em28xx, there's no device using "raw"
mode, as the em28xx chips provide a hardware IR decoder. So, up to now, we
didn't find any em28xx device requiring a software decoder for IR.

If you want to write patches for the above, they'll be welcome.

I hope that helps.

Regards,
Mauro

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Frank Schäfer]

Am 15.03.2012 11:42, schrieb Mauro Carvalho Chehab:
> Em 14-03-2012 21:28, Rui Salvaterra escreveu:
>> 2012/3/14 Ezequiel García <elezegarcia@gmail.com>:
>>> Hi,
>>>
>>> 2012/3/14 Rui Salvaterra <rsalvaterra@gmail.com>:
>>>> Hi, Ezequiel. Thanks a lot for your reply.
>>>> I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
>>>> where all modules are loaded (since the boot sequence became
>>>> asynchronous).
>>> Indeed.
>>>
>>>>
>>>> Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
>>>> same result. Additionally:
>>>>
>>>> rui@wilykat:~$ lsmod | grep ir
>>>> ir_lirc_codec          12901  0
>>>> lirc_dev               19204  1 ir_lirc_codec
>>>> ir_mce_kbd_decoder     12724  0
>>>> ir_sanyo_decoder       12513  0
>>>> ir_sony_decoder        12510  0
>>>> ir_jvc_decoder         12507  0
>>>> ir_rc6_decoder         12507  0
>>>> ir_rc5_decoder         12507  0
>>>> ir_nec_decoder         12507  0
>>>> rc_core                26373  9
>>>> ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
>>>> rui@wilykat:~$
>>> Mmmm...
>>> Are you completely sure that em28xx driver is triggering the load of
>>> the ir related modules?
>> I'm positive, the LIRC modules aren't loaded at all if I boot with the
>> webcam disconnected. As soon as I plug it into an USB port, em28xx and
>> LIRC are loaded.
>>
>>> Perhaps you could disable the module (blacklist, or compile out the
>>> module, or erase em28xx.ko to make sure)
>>> so you can see that effectively em28xx doesn't load and the rest of
>>> the modules doesn't load either,
>>> do you follow my line of reasoning?
>> Ok, I did some more testing, here's what I found out. If I blacklist
>> em28xx, no modules are loaded. Afterwards, I allowed em28xx to load
>> and appended
>>
>> blacklist rc_core
>> blacklist ir_lirc_codec
>> blacklist lirc_dev
>> blacklist ir_mce_kbd_decoder
>> blacklist ir_sanyo_decoder
>> blacklist ir_sony_decoder
>> blacklist ir_jvc_decoder
>> blacklist ir_rc6_decoder
>> blacklist ir_rc5_decoder
>> blacklist ir_nec_decoder
>>
>> to /etc/modprobe.d/blacklist.conf (basically blacklisted all LIRC
>> stuff), but it also didn't work. And I still have em28xx disable_ir=1.
> The em28xx module requires IR support from rc_core, as most em28xx devices
> support it. It can be compiled without IR support, but, as the em28xx-input
> is not on a separate module, and it contains some calls to rc_core functions
> like rc_register_device, modprobe will load rc_core, and rc_core will load
> the decoders, including lirc_dev.
>
> Those modules are small and won't be running if all you have are the webcams.
> The optimization to not load those modules is not big, so nobody had time
> yet to do it.
>
> Anyway, if you want to fix it, there are two possible approaches:
>
> 1) change rc_core to not load the IR decoders at load time, postponing it
>    to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device.
>   
> A patch for it shouldn't be hard. All you need to do is to move ir_raw_init()
> to rc_register_device() and add a logic there to call it for the first
> raw device.
>
> With such patch, rc_core module will still be loaded.
>
> 2) change em28xx-input.c to be a separate module, called only when a device
> has IR. It will need to have a logic similar to em28xx-dvb and em28xx-alsa
> modules.
>
> It is not hard to write such patch, as most of the logic is already there,
> but it is not as trivial as approach (1).
>
> It probably makes sense for both approaches (1) and (2), as not all boards
> support "raw" devices. In the case of em28xx, there's no device using "raw"
> mode, as the em28xx chips provide a hardware IR decoder. So, up to now, we
> didn't find any em28xx device requiring a software decoder for IR.
>
> If you want to write patches for the above, they'll be welcome.
>
> I hope that helps.
>
> Regards,
> Mauro
>

I would like to bring up the question, if it wouldn't make sense to move
support for the em27xx/28xx webcams to a separate gspca-subdriver.

I'm currently working on adding support for the VAD Laplace webcam
(em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
Lots of modifications to the em28xx driver would be necessary to support
this device because of some significant differences:
- supports only bulk transfers
- uses proprietary I2C-writes
- em25xx-eeprom
- ov2640 sensor

Lots of changes concerning the USB-interface probing, button handling,
video controls, frame processing and more would be necessary, too.

For reverse engineering purposes, I decided to write a gspca subdriver
for this device (will send a patch for testing/discussion soon).

I have no strong opinion about this, but I somehow feel that the em28xx
driver gets bloated more and more...

Regards,
Frank Schäfer

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Mauro Carvalho Chehab]

Em 15-03-2012 09:34, Frank Schäfer escreveu:
> Am 15.03.2012 11:42, schrieb Mauro Carvalho Chehab:
>> Em 14-03-2012 21:28, Rui Salvaterra escreveu:
>>> 2012/3/14 Ezequiel García <elezegarcia@gmail.com>:
>>>> Hi,
>>>>
>>>> 2012/3/14 Rui Salvaterra <rsalvaterra@gmail.com>:
>>>>> Hi, Ezequiel. Thanks a lot for your reply.
>>>>> I'm attaching a copy of my full dmesg, its a bit hard to spot exactly
>>>>> where all modules are loaded (since the boot sequence became
>>>>> asynchronous).
>>>> Indeed.
>>>>
>>>>>
>>>>> Sure, no problem at all. I booted with em28xx disable_ir=1 and got the
>>>>> same result. Additionally:
>>>>>
>>>>> rui@wilykat:~$ lsmod | grep ir
>>>>> ir_lirc_codec          12901  0
>>>>> lirc_dev               19204  1 ir_lirc_codec
>>>>> ir_mce_kbd_decoder     12724  0
>>>>> ir_sanyo_decoder       12513  0
>>>>> ir_sony_decoder        12510  0
>>>>> ir_jvc_decoder         12507  0
>>>>> ir_rc6_decoder         12507  0
>>>>> ir_rc5_decoder         12507  0
>>>>> ir_nec_decoder         12507  0
>>>>> rc_core                26373  9
>>>>> ir_lirc_codec,ir_mce_kbd_decoder,ir_sanyo_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,em28xx,ir_rc5_decoder,ir_nec_decoder
>>>>> rui@wilykat:~$
>>>> Mmmm...
>>>> Are you completely sure that em28xx driver is triggering the load of
>>>> the ir related modules?
>>> I'm positive, the LIRC modules aren't loaded at all if I boot with the
>>> webcam disconnected. As soon as I plug it into an USB port, em28xx and
>>> LIRC are loaded.
>>>
>>>> Perhaps you could disable the module (blacklist, or compile out the
>>>> module, or erase em28xx.ko to make sure)
>>>> so you can see that effectively em28xx doesn't load and the rest of
>>>> the modules doesn't load either,
>>>> do you follow my line of reasoning?
>>> Ok, I did some more testing, here's what I found out. If I blacklist
>>> em28xx, no modules are loaded. Afterwards, I allowed em28xx to load
>>> and appended
>>>
>>> blacklist rc_core
>>> blacklist ir_lirc_codec
>>> blacklist lirc_dev
>>> blacklist ir_mce_kbd_decoder
>>> blacklist ir_sanyo_decoder
>>> blacklist ir_sony_decoder
>>> blacklist ir_jvc_decoder
>>> blacklist ir_rc6_decoder
>>> blacklist ir_rc5_decoder
>>> blacklist ir_nec_decoder
>>>
>>> to /etc/modprobe.d/blacklist.conf (basically blacklisted all LIRC
>>> stuff), but it also didn't work. And I still have em28xx disable_ir=1.
>> The em28xx module requires IR support from rc_core, as most em28xx devices
>> support it. It can be compiled without IR support, but, as the em28xx-input
>> is not on a separate module, and it contains some calls to rc_core functions
>> like rc_register_device, modprobe will load rc_core, and rc_core will load
>> the decoders, including lirc_dev.
>>
>> Those modules are small and won't be running if all you have are the webcams.
>> The optimization to not load those modules is not big, so nobody had time
>> yet to do it.
>>
>> Anyway, if you want to fix it, there are two possible approaches:
>>
>> 1) change rc_core to not load the IR decoders at load time, postponing it
>>    to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device.
>>   
>> A patch for it shouldn't be hard. All you need to do is to move ir_raw_init()
>> to rc_register_device() and add a logic there to call it for the first
>> raw device.
>>
>> With such patch, rc_core module will still be loaded.
>>
>> 2) change em28xx-input.c to be a separate module, called only when a device
>> has IR. It will need to have a logic similar to em28xx-dvb and em28xx-alsa
>> modules.
>>
>> It is not hard to write such patch, as most of the logic is already there,
>> but it is not as trivial as approach (1).
>>
>> It probably makes sense for both approaches (1) and (2), as not all boards
>> support "raw" devices. In the case of em28xx, there's no device using "raw"
>> mode, as the em28xx chips provide a hardware IR decoder. So, up to now, we
>> didn't find any em28xx device requiring a software decoder for IR.
>>
>> If you want to write patches for the above, they'll be welcome.
>>
>> I hope that helps.
>>
>> Regards,
>> Mauro
>>
> 
> I would like to bring up the question, if it wouldn't make sense to move
> support for the em27xx/28xx webcams to a separate gspca-subdriver.

The em2710/2750 chips are very similar to em2820. There's not much sense
on moving it elsewhere, as it would duplicate a lot of the existing code,
for no good reason.

> 
> I'm currently working on adding support for the VAD Laplace webcam
> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
> Lots of modifications to the em28xx driver would be necessary to support
> this device because of some significant differences:
> - supports only bulk transfers

em28xx supports it as well, but it is used only for dvb, currently.

> - uses proprietary I2C-writes

huh? I2C writes are proprietary. What do you mean?

> - em25xx-eeprom

Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
not only the webcam ones. Currently, the code detects it but nobody wrote
an implementation for it yet. It would likely make sense to implement it
at em28xx anyway.

> - ov2640 sensor

The better is to use a separate I2C driver for the sensor. This is not
a common practice at gspca, but doing that would help to re-use the sensor
driver elsewhere.

> Lots of changes concerning the USB-interface probing, button handling,
> video controls, frame processing and more would be necessary, too.

Video controls are implemented at the sensor sub-driver, so this is not
an issue.

Anyway, if em2765 is different enough from em2874 and em2750, then it makes
sense to write it as a separate driver. Otherwise, it is better to add support
for it there.

> For reverse engineering purposes, I decided to write a gspca subdriver
> for this device (will send a patch for testing/discussion soon).

Ok.

> I have no strong opinion about this, but I somehow feel that the em28xx
> driver gets bloated more and more...

The advantage of adding it there is that it generally reduces maintenance 
efforts, as the same code and fixes don't need to be added on two separate
places.

For example, if the em2765 eeprom access is similar to em2874, the same
code chunk would be required on both drivers.

Regards,
Mauro

Re: Move em27xx/em28xx webcams to a gspca subdriver ?

[Frank Schäfer]

[Was: eMPIA EM2710 Webcam (em28xx) and LIRC]

Continue this part of the discussion in a new thread...

Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
> Em 15-03-2012 09:34, Frank Schäfer escreveu:
>> ...
>>
>> I would like to bring up the question, if it wouldn't make sense to move
>> support for the em27xx/28xx webcams to a separate gspca-subdriver.
> The em2710/2750 chips are very similar to em2820. There's not much sense
> on moving it elsewhere, as it would duplicate a lot of the existing code,
> for no good reason.
Yes, that was my first thought, too.
But looking at the resulting gspca subdriver, you will see that there is
not much code duplication.
I would say that adding support for this device as a gspca subdriver
requires less new lines of code than extending/modifying the em28xx driver.

>> I'm currently working on adding support for the VAD Laplace webcam
>> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
>> Lots of modifications to the em28xx driver would be necessary to support
>> this device because of some significant differences:
>> - supports only bulk transfers
> em28xx supports it as well, but it is used only for dvb, currently.
You are talking about the em28xx device capabilities, right ?
AFAIK, the em28xx driver still has no bulk transfer support.

>> - uses proprietary I2C-writes
> huh? I2C writes are proprietary. What do you mean?
Maybe proprietary is not the best name...
Requests 0x06 an 0x08 are used for the usb control messages.
I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
Could be the "vendor specific" usb requests the datasheet talks about.

>> - em25xx-eeprom
> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
> not only the webcam ones. Currently, the code detects it but nobody wrote
> an implementation for it yet. It would likely make sense to implement it
> at em28xx anyway.
Yes, the device has an eeprom with 16bit addresses.
Anyway, I'm talking about a different format of the eeprom data:
http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html

You can find the eeprom content of my device at
http://linuxtv.org/wiki/index.php/VAD_Laplace

>> - ov2640 sensor
> The better is to use a separate I2C driver for the sensor. This is not
> a common practice at gspca, but doing that would help to re-use the sensor
> driver elsewhere.
I agree. But let's do things step by step...

>> Lots of changes concerning the USB-interface probing, button handling,
>> video controls, frame processing and more would be necessary, too.
> Video controls are implemented at the sensor sub-driver, so this is not
> an issue.
>
> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
> sense to write it as a separate driver. Otherwise, it is better to add support
> for it there.

No, the em2765 itself seems to be very similar to the other
em27xx/em28xx chips.
But the device as a whole is different enough to consider a separate driver.

>> For reverse engineering purposes, I decided to write a gspca subdriver
>> for this device (will send a patch for testing/discussion soon).
> Ok.
See the patch posted a minute ago.

>
>> I have no strong opinion about this, but I somehow feel that the em28xx
>> driver gets bloated more and more...
> The advantage of adding it there is that it generally reduces maintenance 
> efforts, as the same code and fixes don't need to be added on two separate
> places.
Yes, that's right. But on the other hand, the benefit of separate
drivers is simpler code, which is easier to maintain/understand.
For example, there would be no LIRC modules issue ;-)

> For example, if the em2765 eeprom access is similar to em2874, the same
> code chunk would be required on both drivers.
Sure, code duplication is one of the disadvantages. The question is how
much duplicate code there would be.

Regards,
Frank

> Regards,
> Mauro

Re: Move em27xx/em28xx webcams to a gspca subdriver ?

[Frank Schäfer]

Am 16.03.2012 23:18, schrieb Frank Schäfer:
> [Was: eMPIA EM2710 Webcam (em28xx) and LIRC]
>
> Continue this part of the discussion in a new thread...
>
> Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
>> Em 15-03-2012 09:34, Frank Schäfer escreveu:
>>> ...
>>>
>>> I would like to bring up the question, if it wouldn't make sense to move
>>> support for the em27xx/28xx webcams to a separate gspca-subdriver.
>> The em2710/2750 chips are very similar to em2820. There's not much sense
>> on moving it elsewhere, as it would duplicate a lot of the existing code,
>> for no good reason.
> Yes, that was my first thought, too.
> But looking at the resulting gspca subdriver, you will see that there is
> not much code duplication.
> I would say that adding support for this device as a gspca subdriver
> requires less new lines of code than extending/modifying the em28xx driver.
>
>>> I'm currently working on adding support for the VAD Laplace webcam
>>> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
>>> Lots of modifications to the em28xx driver would be necessary to support
>>> this device because of some significant differences:
>>> - supports only bulk transfers
>> em28xx supports it as well, but it is used only for dvb, currently.
> You are talking about the em28xx device capabilities, right ?
> AFAIK, the em28xx driver still has no bulk transfer support.
>
>>> - uses proprietary I2C-writes
>> huh? I2C writes are proprietary. What do you mean?
> Maybe proprietary is not the best name...
> Requests 0x06 an 0x08 are used for the usb control messages.
> I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
> Could be the "vendor specific" usb requests the datasheet talks about.
>
>>> - em25xx-eeprom
>> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
>> not only the webcam ones. Currently, the code detects it but nobody wrote
>> an implementation for it yet. It would likely make sense to implement it
>> at em28xx anyway.
> Yes, the device has an eeprom with 16bit addresses.
> Anyway, I'm talking about a different format of the eeprom data:
> http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html
>
> You can find the eeprom content of my device at
> http://linuxtv.org/wiki/index.php/VAD_Laplace
>
>>> - ov2640 sensor
>> The better is to use a separate I2C driver for the sensor. This is not
>> a common practice at gspca, but doing that would help to re-use the sensor
>> driver elsewhere.
> I agree. But let's do things step by step...
>
>>> Lots of changes concerning the USB-interface probing, button handling,
>>> video controls, frame processing and more would be necessary, too.
>> Video controls are implemented at the sensor sub-driver, so this is not
>> an issue.
>>
>> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
>> sense to write it as a separate driver. Otherwise, it is better to add support
>> for it there.
> No, the em2765 itself seems to be very similar to the other
> em27xx/em28xx chips.
> But the device as a whole is different enough to consider a separate driver.
>
>>> For reverse engineering purposes, I decided to write a gspca subdriver
>>> for this device (will send a patch for testing/discussion soon).
>> Ok.
> See the patch posted a minute ago.
>
>>> I have no strong opinion about this, but I somehow feel that the em28xx
>>> driver gets bloated more and more...
>> The advantage of adding it there is that it generally reduces maintenance 
>> efforts, as the same code and fixes don't need to be added on two separate
>> places.
> Yes, that's right. But on the other hand, the benefit of separate
> drivers is simpler code, which is easier to maintain/understand.
> For example, there would be no LIRC modules issue ;-)
>
>> For example, if the em2765 eeprom access is similar to em2874, the same
>> code chunk would be required on both drivers.
> Sure, code duplication is one of the disadvantages. The question is how
> much duplicate code there would be.
>
> Regards,
> Frank
>
>> Regards,
>> Mauro
Ping !
No comments, opinions ? ;-)

Regards,
Frank

Re: Move em27xx/em28xx webcams to a gspca subdriver ?

[Mauro Carvalho Chehab]

Em 21-03-2012 15:01, Frank Schäfer escreveu:
> Am 16.03.2012 23:18, schrieb Frank Schäfer:
>> [Was: eMPIA EM2710 Webcam (em28xx) and LIRC]
>>
>> Continue this part of the discussion in a new thread...
>>
>> Am 15.03.2012 14:05, schrieb Mauro Carvalho Chehab:
>>> Em 15-03-2012 09:34, Frank Schäfer escreveu:
>>>> ...
>>>>
>>>> I would like to bring up the question, if it wouldn't make sense to move
>>>> support for the em27xx/28xx webcams to a separate gspca-subdriver.
>>> The em2710/2750 chips are very similar to em2820. There's not much sense
>>> on moving it elsewhere, as it would duplicate a lot of the existing code,
>>> for no good reason.
>> Yes, that was my first thought, too.
>> But looking at the resulting gspca subdriver, you will see that there is
>> not much code duplication.
>> I would say that adding support for this device as a gspca subdriver
>> requires less new lines of code than extending/modifying the em28xx driver.
>>
>>>> I'm currently working on adding support for the VAD Laplace webcam
>>>> (em2765 + OV2640) (http://linuxtv.org/wiki/index.php/VAD_Laplace).
>>>> Lots of modifications to the em28xx driver would be necessary to support
>>>> this device because of some significant differences:
>>>> - supports only bulk transfers
>>> em28xx supports it as well, but it is used only for dvb, currently.
>> You are talking about the em28xx device capabilities, right ?
>> AFAIK, the em28xx driver still has no bulk transfer support.
>>
>>>> - uses proprietary I2C-writes
>>> huh? I2C writes are proprietary. What do you mean?
>> Maybe proprietary is not the best name...
>> Requests 0x06 an 0x08 are used for the usb control messages.
>> I have documented that at http://linuxtv.org/wiki/index.php/VAD_Laplace.
>> Could be the "vendor specific" usb requests the datasheet talks about.
>>
>>>> - em25xx-eeprom
>>> Are you meaning more than 256 addresses eeprom? Newer Empia chips use it,
>>> not only the webcam ones. Currently, the code detects it but nobody wrote
>>> an implementation for it yet. It would likely make sense to implement it
>>> at em28xx anyway.
>> Yes, the device has an eeprom with 16bit addresses.
>> Anyway, I'm talking about a different format of the eeprom data:
>> http://wenku.baidu.com/view/a21a28eab8f67c1cfad6b8f6.html
>>
>> You can find the eeprom content of my device at
>> http://linuxtv.org/wiki/index.php/VAD_Laplace
>>
>>>> - ov2640 sensor
>>> The better is to use a separate I2C driver for the sensor. This is not
>>> a common practice at gspca, but doing that would help to re-use the sensor
>>> driver elsewhere.
>> I agree. But let's do things step by step...
>>
>>>> Lots of changes concerning the USB-interface probing, button handling,
>>>> video controls, frame processing and more would be necessary, too.
>>> Video controls are implemented at the sensor sub-driver, so this is not
>>> an issue.
>>>
>>> Anyway, if em2765 is different enough from em2874 and em2750, then it makes
>>> sense to write it as a separate driver. Otherwise, it is better to add support
>>> for it there.
>> No, the em2765 itself seems to be very similar to the other
>> em27xx/em28xx chips.
>> But the device as a whole is different enough to consider a separate driver.
>>
>>>> For reverse engineering purposes, I decided to write a gspca subdriver
>>>> for this device (will send a patch for testing/discussion soon).
>>> Ok.
>> See the patch posted a minute ago.
>>
>>>> I have no strong opinion about this, but I somehow feel that the em28xx
>>>> driver gets bloated more and more...
>>> The advantage of adding it there is that it generally reduces maintenance 
>>> efforts, as the same code and fixes don't need to be added on two separate
>>> places.
>> Yes, that's right. But on the other hand, the benefit of separate
>> drivers is simpler code, which is easier to maintain/understand.
>> For example, there would be no LIRC modules issue ;-)
>>
>>> For example, if the em2765 eeprom access is similar to em2874, the same
>>> code chunk would be required on both drivers.
>> Sure, code duplication is one of the disadvantages. The question is how
>> much duplicate code there would be.
>>
>> Regards,
>> Frank
>>
>>> Regards,
>>> Mauro
> Ping !
> No comments, opinions ? ;-)

-ETOOBUSY ;)

We're in the middle of a merge window. I don't have any time
during this and the next week for discussing it due to that,
as there are some maintainer's task that I need to handle.

Please ping me by the beginning of April, after the end of the
merge window.

Sorry,
Mauro

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Rui Salvaterra]

On 15 March 2012 10:42, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>
> The em28xx module requires IR support from rc_core, as most em28xx devices
> support it. It can be compiled without IR support, but, as the em28xx-input
> is not on a separate module, and it contains some calls to rc_core functions
> like rc_register_device, modprobe will load rc_core, and rc_core will load
> the decoders, including lirc_dev.
>
> Those modules are small and won't be running if all you have are the webcams.
> The optimization to not load those modules is not big, so nobody had time
> yet to do it.
>
> Anyway, if you want to fix it, there are two possible approaches:
>
> 1) change rc_core to not load the IR decoders at load time, postponing it
>   to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device.
>
> A patch for it shouldn't be hard. All you need to do is to move ir_raw_init()
> to rc_register_device() and add a logic there to call it for the first
> raw device.
>
> With such patch, rc_core module will still be loaded.
>
> 2) change em28xx-input.c to be a separate module, called only when a device
> has IR. It will need to have a logic similar to em28xx-dvb and em28xx-alsa
> modules.
>
> It is not hard to write such patch, as most of the logic is already there,
> but it is not as trivial as approach (1).
>
> It probably makes sense for both approaches (1) and (2), as not all boards
> support "raw" devices. In the case of em28xx, there's no device using "raw"
> mode, as the em28xx chips provide a hardware IR decoder. So, up to now, we
> didn't find any em28xx device requiring a software decoder for IR.
>
> If you want to write patches for the above, they'll be welcome.
>
> I hope that helps.
>
> Regards,
> Mauro


Hi, Mauro

I'm sorry for the late reply, I'm at work.
Thanks a lot for the explanation. Such refactoring seems a bit out of
my reach, for the time being (though apparently a nice opportunity to
learn Git-fu, I'm intoxicated by CVS), but at least now I understand
what is really happening.
I may try and hack the code a bit and see what comes out, but don't
wait for me, by all means. I only have a general idea of how the
kernel works (I understand C, but stopped writing it about ten years
ago, as I do Java for a living).


Thanks, once again,

Rui Salvaterra

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Mauro Carvalho Chehab]

Em 15-03-2012 10:10, Rui Salvaterra escreveu:
> On 15 March 2012 10:42, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>
>> The em28xx module requires IR support from rc_core, as most em28xx devices
>> support it. It can be compiled without IR support, but, as the em28xx-input
>> is not on a separate module, and it contains some calls to rc_core functions
>> like rc_register_device, modprobe will load rc_core, and rc_core will load
>> the decoders, including lirc_dev.
>>
>> Those modules are small and won't be running if all you have are the webcams.
>> The optimization to not load those modules is not big, so nobody had time
>> yet to do it.
>>
>> Anyway, if you want to fix it, there are two possible approaches:
>>
>> 1) change rc_core to not load the IR decoders at load time, postponing it
>>   to load only if a RC_DRIVER_IR_RAW device is registered via rc_register_device.
>>
>> A patch for it shouldn't be hard. All you need to do is to move ir_raw_init()
>> to rc_register_device() and add a logic there to call it for the first
>> raw device.
>>
>> With such patch, rc_core module will still be loaded.
>>
>> 2) change em28xx-input.c to be a separate module, called only when a device
>> has IR. It will need to have a logic similar to em28xx-dvb and em28xx-alsa
>> modules.
>>
>> It is not hard to write such patch, as most of the logic is already there,
>> but it is not as trivial as approach (1).
>>
>> It probably makes sense for both approaches (1) and (2), as not all boards
>> support "raw" devices. In the case of em28xx, there's no device using "raw"
>> mode, as the em28xx chips provide a hardware IR decoder. So, up to now, we
>> didn't find any em28xx device requiring a software decoder for IR.
>>
>> If you want to write patches for the above, they'll be welcome.
>>
>> I hope that helps.
>>
>> Regards,
>> Mauro
> 
> 
> Hi, Mauro
> 
> I'm sorry for the late reply, I'm at work.
> Thanks a lot for the explanation. Such refactoring seems a bit out of
> my reach, for the time being (though apparently a nice opportunity to
> learn Git-fu, I'm intoxicated by CVS), but at least now I understand
> what is really happening.
> I may try and hack the code a bit and see what comes out, but don't
> wait for me, by all means. I only have a general idea of how the
> kernel works (I understand C, but stopped writing it about ten years
> ago, as I do Java for a living).

Take your time. As I said, a patch for (1) should be easy. So, if you're
interested on trying to do it, it is probably the best thing to start.

If you won't take it, it is likely that some day someone will do it,
but, as this is just a cleanup, the main developers won't likely
have time for doing it, as they're generally busy adding support for 
new hardware.

Regards,
Mauro
> 
> 
> Thanks, once again,
> 
> Rui Salvaterra

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Ezequiel García]

Hi Mauro,

On 3/15/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
> If you won't take it, it is likely that some day someone will do it,
> but, as this is just a cleanup, the main developers won't likely
> have time for doing it, as they're generally busy adding support for
> new hardware.
>

I have no problem submitting the two patches in discussion.
(Actually, I've already wroten the first one).

If Rui wants to help me, it would be nice to get this tested,
since I don't have the necessary hardware.

One thing I haven't got clear is this: I've seen that ir_raw_init()
does not call request_module() directly but rather defers it
through a work queue.

I don't understand fully the rc code, but still I don't get what
happens if I need the raw decoders *now* (so to speak)
but the work queue hasn't been run yet?

Thanks,
Ezequiel.

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Mauro Carvalho Chehab]

Em 15-03-2012 14:15, Ezequiel García escreveu:
> Hi Mauro,
> 
> On 3/15/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>> If you won't take it, it is likely that some day someone will do it,
>> but, as this is just a cleanup, the main developers won't likely
>> have time for doing it, as they're generally busy adding support for
>> new hardware.
>>
> 
> I have no problem submitting the two patches in discussion.
> (Actually, I've already wroten the first one).

Good!

> If Rui wants to help me, it would be nice to get this tested,
> since I don't have the necessary hardware.

I might test, but I'm currently very busy with some other stuff,
so I won't likely have time for it anytime soon.

> One thing I haven't got clear is this: I've seen that ir_raw_init()
> does not call request_module() directly but rather defers it
> through a work queue.

Deferring request_module to a work_queue is a common procedure we
do at v4l drivers. It helps to initialize faster, and prevents some
dependency issues, as the decoders depend on rc_core to be initialized,
in order to load.

> I don't understand fully the rc code, but still I don't get what
> happens if I need the raw decoders *now* (so to speak)
> but the work queue hasn't been run yet?

Well, if you press an RC key while the needed decoded is not loaded,
that key will be lost. No other problems should happen.

Regards,
Mauro.

Re: eMPIA EM2710 Webcam (em28xx) and LIRC

[Rui Salvaterra]

Hi again, I'm terribly sorry for the delay


2012/3/15 Mauro Carvalho Chehab <mchehab@redhat.com>:
> Em 15-03-2012 14:15, Ezequiel García escreveu:
>> Hi Mauro,
>>
>> On 3/15/12, Mauro Carvalho Chehab <mchehab@redhat.com> wrote:
>>> If you won't take it, it is likely that some day someone will do it,
>>> but, as this is just a cleanup, the main developers won't likely
>>> have time for doing it, as they're generally busy adding support for
>>> new hardware.
>>>
>>
>> I have no problem submitting the two patches in discussion.
>> (Actually, I've already wroten the first one).
>
> Good!
>
>> If Rui wants to help me, it would be nice to get this tested,
>> since I don't have the necessary hardware.
>
> I might test, but I'm currently very busy with some other stuff,
> so I won't likely have time for it anytime soon.


I'd love to give it at spin, of course. I'm just not familiar with the
procedure on Debian/Ubuntu (last time I compiled a kernel I was
running Gentoo, about six years ago).


>
>> One thing I haven't got clear is this: I've seen that ir_raw_init()
>> does not call request_module() directly but rather defers it
>> through a work queue.
>
> Deferring request_module to a work_queue is a common procedure we
> do at v4l drivers. It helps to initialize faster, and prevents some
> dependency issues, as the decoders depend on rc_core to be initialized,
> in order to load.
>
>> I don't understand fully the rc code, but still I don't get what
>> happens if I need the raw decoders *now* (so to speak)
>> but the work queue hasn't been run yet?
>
> Well, if you press an RC key while the needed decoded is not loaded,
> that key will be lost. No other problems should happen.
>
> Regards,
> Mauro.


Thanks,

Rui Salvaterra