--- Hans Verkuil <[EMAIL PROTECTED]> wrote:
> On Wednesday 24 January 2007 00:13, Tim Harvey wrote:
> > --- Hans Verkuil <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 23 January 2007 22:35, Hans Verkuil wrote:
> > > > On Tuesday 23 January 2007 20:05, Tim Harvey wrote:
> > > > > Greetings,
> > > > >
> > > > > I'm running into a resource limit on my platform using ivtv and
> > > > > its because the cx23416 pci device is requesting 64MB of PCI
> > > > > memory space. Looking at
> > > > > Documentation/video4linux/cx2341x/fw-memory.txt I don't see how
> > > > > all this space is needed. Is there any problem with limiting
> > > > > this window and if not is there a way within the linux kernel
> > > > > to override the size resulting from the pci probe for a device?
> > > >
> > > > Urgh. I reduced the ioremap sizes, but completely forgot about
> > > > the request_mem_region calls. I'm working on it now, expect a
> > > > trunk commit soon.
> > >
> > > Committed. It now requests only a bit over 8MB for the cx23416 and
> > > a bit over 16 MB for the cx23415. Please test, it should now work.
> > >
> > > Hans
> >
> > I most likely need this fix, however before the ITVT driver even
> > loads I have an issue as the pci probe determines the device requests
> > 64MB which the kernel reserves and then any other PCI devices found
> > will fail to allocate resources appropriately - all before drivers
> > are loaded. This basically means that on my platform the 'only' PCI
> > device that I can have is the cx23416 based card unless I can figure
> > out how to resolve this.
> >
> > So obviously my current issue isn't an ivtv driver issue, but perhaps
> > someone here may be able to advise me how I can solve this.
> >
> > I couldn't figure out any way in the kernel to determine what the
> > space a PCI device 'requested' was, so I added a line of debugging to
> > my 2.6.19 kernel in drivers/pci/probe.c. Heres the applicable dmesg
> > portions from my armeb IXP4xx platform:
> >
> > Linux version 2.6.19 ([EMAIL PROTECTED]) (gcc version 3.4.4) #23 Tue Jan
> > 23 14:53:36 PST 2007
> > CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE),
> > cr=000039ff Machine: Intel IXDP425 Development Platform
> > Memory policy: ECC disabled, Data cache writeback
> > CPU0: D VIVT undefined 5 cache
> > CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> > CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
> > Built 1 zonelists. Total pages: 16256
> > Kernel command line: console=ttyS0,115200 root=/dev/ram0
> > initrd=0x00800000,6M PID hash table entries: 256 (order: 8, 1024
> > bytes)
> > Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> > Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> > Memory: 64MB = 64MB total
> > Memory: 56868KB available (1476K code, 303K data, 84K init)
> > Mount-cache hash table entries: 512
> > CPU: Testing write buffer coherency: ok
> > checking if image is initramfs...it isn't (no cpio magic); looks like
> > an initrd Freeing initrd memory: 6144K
> > NET: Registered protocol family 16
> > IXP4xx: Using 16MiB expansion bus window size
> > PCI: IXP4xx is host
> > PCI: IXP4xx Using direct access for memory space
> > pci_read_bases: MEM dev=0000:00:01.0 168C:0013 pos=0 start=0x00000000
> > end=0x0000ffff (size=65535)
> > pci_read_bases: MEM dev=0000:00:02.0 4444:0016 pos=0 start=0xfc000000
> > end=0xffffffff (size=67108863)
> > pci_read_bases: MEM dev=0000:00:05.0 1131:1561 pos=0 start=0xfffff000
> > end=0xffffffff (size=4095)
> > pci_read_bases: MEM dev=0000:00:05.1 1131:1561 pos=0 start=0xfffff000
> > end=0xffffffff (size=4095)
> > pci_read_bases: MEM dev=0000:00:05.2 1131:1562 pos=0 start=0xffffff00
> > end=0xffffffff (size=255)
> > PCI: bus0: Fast back to back transfers disabled
> > dmabounce: registered device 0000:00:01.0 on pci bus
> > dmabounce: registered device 0000:00:02.0 on pci bus
> > dmabounce: registered device 0000:00:05.0 on pci bus
> > dmabounce: registered device 0000:00:05.1 on pci bus
> > dmabounce: registered device 0000:00:05.2 on pci bus
> > PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:02.0
> > 4444:0016 PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for
> > 0000:00:01.0 168C:0013
> > PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for
> > 0000:00:05.0 1131:1561
> > PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for
> > 0000:00:05.1 1131:1561
> > PCI: Failed to allocate mem resource #0:[EMAIL PROTECTED] for 0000:00:05.2
> > 1131:1562 NET: Registered protocol family 2
> >
> > You can see above that the cx23416 is requesting a PCI mem region of
> > 64MB, which is the maximum region that the IXP4xx can provide,
> > therefore the devices detected following that can't allocate their
> > (meager) requirements. I'm assuming that the 'PCI: Failed to
> > allocate mem resource' messages are indicative as the problem to
> > follow where the device drivers fail to allocate their requested
> > regions ('request_mem_region' fails for any driver other than ivtv as
> > the cx23416 gobbled up all the space - even if the IVTV driver is
> > never loaded)
> >
> > I've tried hacking around in drivers/pci/probe to reduce the memory
> > size but I don't think I'm doing it correctly - is there some method
> > in the kernel to override what a PCI device is asking for when
> > probed?
>
> Perhaps drivers/pci/quirks.c is a good place to look. These fixups are
> called from pci_setup_device() in probe.c, so you might be able to do
> something with it.
>
> Hans
Yes, this was my thought as well. I added a quirk to reset the end resource to
start + 0x1ffffff for for a 32MB region and the rest of my devices get
allocations from the kernel correctly, yet then when ivtv tries to get its
requested 0x800000 it fails and I have reason to believe that the cx23416 is
still decoding addresses that are outside of this region (as my other cards
don't function properly even though they can allocate their regions):
PCI: IXP4xx is host
PCI: IXP4xx Using direct access for memory space
pci_read_bases: MEM dev=0000:00:01.0 168C:0013 pos=0 start=0x00000000
end=0x0000ffff (size=65535)
pci_read_bases: MEM dev=0000:00:02.0 4444:0016 pos=0 start=0xfc000000
end=0xffffffff (size=67108863)
quirk_cx23416: Adjusting cx23416 region size from 0xffffffff to 0x1fffffff
pci_read_bases: MEM dev=0000:00:05.0 1131:1561 pos=0 start=0xfffff000
end=0xffffffff (size=4095)
pci_read_bases: MEM dev=0000:00:05.1 1131:1561 pos=0 start=0xfffff000
end=0xffffffff (size=4095)
pci_read_bases: MEM dev=0000:00:05.2 1131:1562 pos=0 start=0xffffff00
end=0xffffffff (size=255)
PCI: bus0: Fast back to back transfers disabled
dmabounce: registered device 0000:00:01.0 on pci bus
dmabounce: registered device 0000:00:02.0 on pci bus
dmabounce: registered device 0000:00:05.0 on pci bus
dmabounce: registered device 0000:00:05.1 on pci bus
dmabounce: registered device 0000:00:05.2 on pci bus
PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:02.0 4444:0016
PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:01.0 168C:0013
PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:05.0 1131:1561
PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:05.1 1131:1561
PCI: allocated mem resource #0:[EMAIL PROTECTED] for 0000:00:05.2 1131:1562
NET: Registered protocol family 2
modprobe ivtv ivtv_debug=512:
Linux video capture interface: v2.00
ivtv: ==================== START INIT IVTV ====================
ivtv: version 0.10.0 (development revision 3742M) loading
ivtv: Linux version: 2.6.19 mod_unload ARMv5
ivtv: In case of problems please include the debug info between
ivtv: the START INIT IVTV and END INIT IVTV lines, along with
ivtv: any module options, when mailing the ivtv-users mailinglist.
ivtv0: Autodetected Yuan MPC622 card (cx23416 based)
ivtv0 info: base addr: 0x48000000
ivtv0 info: Enabling pci device
PCI: enabling device 0000:00:02.0 (0140 -> 0142)
ivtv_setup_pci: requesting 0x800000 byte mem region
ivtv0: Cannot request register memory region on card 0.
ivtv0: Error -5 on initialization
ivtv: probe of 0000:00:02.0 failed with error -5
ivtv: ==================== END INIT IVTV ====================
I don't quite understand why ivtv's call to request_mem_region(itv->base_addr,
0x800000, "ivtv_encoder") fails when I make the kernel allocate a 32MB window
vs a 64MB window?
I'm also not sure I understand why it appears that the cx23416 is still
decoding addresses that are not in its region but I suspect this is because in
quirks.c I'm re-setting the 'end' of the resource to modify what the kernel
allocates but this doesn't do anything to the chip to re-configure its address
decode. I wonder if there is anything I _can_ do to modify the chips address
decode?
Tim
>
> _______________________________________________
> ivtv-devel mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-devel
>
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
