[linux-dvb] saa7134 ioremap() problem

[linux-dvb] saa7134 ioremap() problem

[Nick Fisk]

Hi,

I also have a card based on the saa7134 chip and I am encountering the
same problem as described in this thread.

My card:-

00:01.0 Multimedia controller: Philips Semiconductors SAA7133/SAA7135
Video Broadcast Decoder (rev d1)
	Subsystem: Avermedia Technologies Inc Unknown device 2c00
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 64
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at febef800 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [40] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-




I was wondering if this fix would be included in 2.6.27?

If there is any testing or other information that I can provide that
would help please let me know.

Nick


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] saa7134 ioremap() problem

[Andy Burns]

I have been using the saa7134.ko and saa7134_dvb.ko drivers for years as 
part of my mythtv system, working very nicely.

Now I am trying to use xen to virtualise my mythtv-backend, with PCI 
passthrough of the tuner to the virtual machine, everything hasn't gone 
smoothly, but I believe I have found an issue within the driver which 
would have gone un-noticed on a bare-metal machine, yet which causes a 
problem under xen.

Here is what lspci -vvv shows for my card

08:01.0 Multimedia controller: Philips Semiconductors SAA7130 Video 
Broadcast Decoder (rev 01)
         Subsystem: Compro Technology, Inc. Videomate DVB-T200
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
         Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium 
 >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
         Latency: 64 (21000ns min, 8000ns max)
         Interrupt: pin A routed to IRQ 17
         Region 0: Memory at febffc00 (32-bit, non-prefetchable) [size=1K]
         Capabilities: [40] Power Management version 1
                 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=1 PME-
         Kernel modules: saa7134

Notice the MMIO area is 1K in size, but within the driver, it requests 
mapping of a 4K area, rather than 1K.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.25.y.git;a=blob;f=drivers/media/video/saa7134/saa7134-core.c;h=58ab163fdbd74e628e60655ea05c5d3bea611599;hb=HEAD#l998

Obviously the kernel will have to round the start/end addresses to the 
nearest 4K boundaries as this is the granularity of page mapping, but if 
the request is too large to begin with it attempts to map two pages, 
straddling the card's physical address range, this works on a physical 
machine, but fails under xen due to more rigourous checking/enforcement 
of permissions.

I have rebuilt the driver module using 0x400 instead of 0x1000 for the 
ioremap() size and the driver then loads, instead of failing (I still 
have an interrupt problem but will follow that up separately).

If you'd like to follow the discussion I've been having on the xen-devel 
list, Keir Fraser should be able to answer questions on why this fails 
under xen far better than I can.

http://lists.xensource.com/archives/html/xen-devel/2008-07/msg00004.html

Could you comment on whether you'd accept a patch for this?


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb