[BUG]pci layer may report wrong iomem resources data to drivers
lo, aic7xxx driver mmio / dma on x86_64 and some pre 2.6.19.5 ix86 linux kernels are broken here with the adaptec asc19160 PCI/32 scsi hba pci card. well, i've got several live cd systems < 2.6.19.5i386 like whax 3.0 and knoppix that oops and hang boot in aic7xxx init, only one booting here so far is knoppix 5.2, the latest unofficial debian stable 2.6.8-12-amd64-generic, which says ACPI: PCI interrupt :00:06.0[A] -> GSI 17 (level, low) -> IRQ 17 aic7xxx: PCI0:6:0 MEM region 0x0 unavailable. Cannot memory map device. but works in PIO mode, a debian etch 2.6.18-4-amd64 x86_64 which says: SCSI subsystem initialized GSI 16 sharing vector 0xA9 and IRQ 16 ACPI: PCI Interrupt :00:06.0[A] -> GSI 17 (level, low) -> IRQ 169 BUG: soft lockup detected on CPU#0! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] apic_timer_interrupt+0x66/0x6c [] pci_conf1_write+0x0/0xc9 [] :aic7xxx:ahc_pci_test_register_access+0xc2/0x391 [] :aic7xxx:ahc_pci_test_register_access+0x4f/0x391 [] :aic7xxx:ahc_pci_map_registers+0x1bb/0x239 [] :aic7xxx:ahc_pci_config+0x4c/0x12d0 [] pcibios_set_master+0x1e/0x84 [] :aic7xxx:ahc_linux_pci_dev_probe+0x13e/0x213 [] pci_device_probe+0xdf/0x147 [] driver_probe_device+0x52/0xa8 [] __driver_attach+0x0/0x9a [] __driver_attach+0x50/0x9a [] __driver_attach+0x0/0x9a [] bus_for_each_dev+0x43/0x6e [] bus_add_driver+0x7e/0x130 [] __pci_register_driver+0x57/0x7d [] :aic7xxx:ahc_linux_pci_init+0x17/0x21 [] :aic7xxx:ahc_linux_init+0x325/0x336 [] default_wake_function+0x0/0xe [] __down_read+0x12/0x9a [] __link_module+0x0/0x25 [] __up_read+0x13/0x8a [] sys_init_module+0x16cc/0x1882 [] system_call+0x7e/0x83 BUG: soft lockup detected on CPU#0! which is not surprising, since the aic driver has a thread 4E4 blocking test function: I can fix the mmio check not to hang, but the card won't actually work mmio until whatever's assigning the BAR above 32 bits is fixed (that could either be a kernel PCI bug or a BIOS bug). [EMAIL PROTECTED] a kernel.org 2.6.20 with K8 config set but built in a 32Bit debian sid environment, but works ok: tom1:~# uname -a Linux tom1.schorpp.dyndns.dk 2.6.20 #1 PREEMPT Mon Feb 5 11:21:13 CET 2007 i686 GNU/Linux tom1:~# lspci -vvv -s 00:06.0 00:06.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02) Subsystem: Adaptec 19160 Ultra160 SCSI Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- and finally the latest kernel.org 2.6.20.4 AMD K8 and .21-rc4 git built on debian amd64 etch userland that hangs boot on aic7xxx init without magic sysreq keys functionality and oops print triggering, (so the softlockup detection does not work without SMP config set, too): Loading iSCSI transport class v2.0-724. ACPI: PCI Interrupt :00:06.0[A] -> GSI 17 (level, low) -> IRQ 17 ... Kernel alive - Kernel direct mapping tables up to 1 @ 8000-d000 i've dangerously commented out the blocking while(!ahc_is_paused) and got the driver to work in PIO mode so far. tom1:~# lspci -vvv -s 00:06.0 00:06.0 SCSI storage controller: Adaptec AIC-7892B U160/m (rev 02) Subsystem: Adaptec 19160 Ultra160 SCSI Controller Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Status: D0 PME-Enable- DSel=0 DScale=0 PME- the driver asks the pci layer for the iomem resource correctly (checked 0x1000 len) with: request_mem_region(start, 0x1000, "aic7xxx") which returns a invalid >32Bit address and the 64Bit pci mem resources flag is set. the driver shortens the return value then: ahc->platform_data->mem_busaddr is u32. on later freeing [ 49.278810] Trying to free nonexistent resourcewarning occours respectively. i've tried to change containers to u64 but then the above allocation call fails with NULL return. theres no reason to agree about a mb bios issue since the mb bios does not care about OS kernels and since some 32bit linux versions/kernel configs work and winxp_x64 kernel works fine with mmio. we're not sure how to fix that: The problem you seem to have is that your system is reporting a BAR beyond 32 bits (4GB) which the card physically can't use. This could be because of a BIOS misconfiguration or because there's a bug in the PCI subsystem somewhere. James on what circumstances can a >= 2.6.19.5 32bit kernel pci layer decode/report a correct iomem address and a < or 64bit x86_64 configured/built not? working in to linux pci hal next, some change there must have caused the issue. it seems fixed for 32bit kernels but not for 64bit. y tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
(resend, mozilla misconfig )
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip,
since pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int
ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr,
uint8_t __iomem **maddr)
{
// u_long start;
u_long len;
int error;
uint64_t start;
...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64 0x%lx\n", start,
pci_resource_flags(ahc->dev_softc, 1) & PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp
return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1);
len = pci_resource_len(ahc->dev_softc, 1);
if (start != 0) {
*bus_addr = start;
// if (request_mem_region(start, 0x1000, "aic7xxx") == 0)
if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM;
printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x memlen 0x%lx \n",
error, len ); //schorpp
tom1:~# dmesg |grep aic
aic7xxx: DMA_32BIT_MASK
aic7xxx: req_mem_region 0x0 memlen 0x1000
aic7xxx: pci_resource_start 0xff000 *maddr 0x2 mem64 0x4
aic7xxx: PCI Device 0:6:0 failed memory mapped test. Using PIO.
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the hardware worked
fine in a winxp_x64 test setup a few months ago.
will ask LKML.
y
tom
sorry, wrong according to http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that
supports zero wait-state memory;
also operates on 33 MHz, 32-bit
PCI busses"
this chip is capable of 64bit addressing, as pci_resource_ (checking this)
on x86_64 platform and lspci on x86_64 *and* AMDK7 configured kernels reports,
even on PCI/32, right?
or is it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the full 64
bits, so I suspect it should never get a 64 bit BAR, since it wouldn't
be able to decode the full 32 bits. I can fix the mmio check not to
hang, but the card won't actually work mmio until whatever's assigning
the BAR above 32 bits is fixed (that could either be a kernel PCI bug or
a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out, winxp_x64
driver handled all.
so agree on kernel pci hal issue.
but what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still in production
state, i assume they want to have a linux x86_64 dma capable driver. so far it
is not, or can other users having this card pls confirm my pci system broken?
James
y
tom
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[BUG][x86_64]pci layer may report wrong iomem resources data to drivers
lo,
aic7xxx driver mmio / dma on x86_64 linux broken here.
i need some comments and further investigation advice on this:
thomas schorpp wrote:
James Bottomley wrote:
On Fri, 2007-03-23 at 17:28 +0100, thomas schorpp wrote:
i agree for this to be a 32bit dma busmaster chip, since
pci_resource_flags and lspci say 64bit mem resource type
aic7xxx: pci_resource_start f000 *maddr 2 mem64 4
static int ahc_linux_pci_reserve_mem_region(struct ahc_softc *ahc,
u_long *bus_addr, uint8_t __iomem **maddr) { // u_long start;
u_long len; int error; uint64_t start; ...
printk(KERN_WARNING "aic7xxx: pci_resource_start 0x%llx mem64
0x%lx\n", start, pci_resource_flags(ahc->dev_softc, 1) &
PCI_BASE_ADDRESS_MEM_TYPE_64 ); //schorpp return (error);
aic7xxx: pci_resource_start 0xff000 mem64 0x4
---^
just to doublecheck the situation, posted lspci already.
will check next, if len = pci_resource_len(ahc->dev_softc, 1); if
(start != 0) { *bus_addr = start; // if
(request_mem_region(start, 0x1000, "aic7xxx") == 0) if
(request_mem_region(start, len, "aic7xxx") == 0)
succeeds.
no. so the pci layer reports wrong start:
start = pci_resource_start(ahc->dev_softc, 1); len =
pci_resource_len(ahc->dev_softc, 1); if (start != 0) { *bus_addr =
start; // if (request_mem_region(start, 0x1000,
"aic7xxx") == 0) if (request_mem_region(start, len, "aic7xxx") == 0)
error = ENOMEM; printk(KERN_WARNING "aic7xxx: req_mem_region 0x%x
memlen 0x%lx \n", error, len ); //schorpp
tom1:~# dmesg |grep aic aic7xxx: DMA_32BIT_MASK aic7xxx:
req_mem_region 0x0 memlen 0x1000 aic7xxx: pci_resource_start
0xff000 *maddr 0x2 mem64 0x4 aic7xxx: PCI Device 0:6:0 failed
memory mapped test. Using PIO. aic7892: Ultra160 Wide Channel A,
SCSI Id=7, 32/253 SCBs
we've a bug in the x86_64 linux pci config, BIOS is ok, the
hardware worked fine in a winxp_x64 test setup a few months
ago.
will ask LKML.
y tom
sorry, wrong according to
http://download.adaptec.com/pdfs/aic7892.pdf.
"66 MHz, 64-bit, PCI interface that supports zero wait-state
memory; also operates on 33 MHz, 32-bit PCI busses"
this chip is capable of 64bit addressing, as pci_resource_
(checking this) on x86_64 platform and lspci on x86_64 *and*
AMDK7 configured kernels reports, even on PCI/32, right? or is
it impossible to do multiplexed 64bit mem addressing on PCI/32?
It can only do 37 bit addressing ... only the aic79xx can do the
full 64 bits, so I suspect it should never get a 64 bit BAR,
since it wouldn't be able to decode the full 32 bits. I can fix
the mmio check not to hang, but the card won't actually work mmio
until whatever's assigning the BAR above 32 bits is fixed (that
could either be a kernel PCI bug or a BIOS bug).
ok, i trust in that. adaptor bios and mainboard bios *are* out,
winxp_x64 driver handled all. so agree on kernel pci hal issue. but
what for const uint64_t mask_39bit = 0x7FULL;
then?
can adaptec.inc pls comment? since the aha19160 card is still
in production state, i assume they want to have a linux x86_64
dma capable driver. so far it is not, or can other users having
this card pls confirm my pci system broken?
James
y tom
- To unsubscribe from this list: send the line "unsubscribe
linux-scsi" in the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH][DVB][2.6.12]Siemens DVB-C PCI: SAA7113 Analog Module Extension: Fix missing Video (CVBS+Y/C) Inputs in AV711X V4L driver
hello,
this patch enables the before not implemented video inputs of the
SAA7113 Analog Cable Extension Module of that "classic" dvb-c card
listed:
http://www.vdr-wiki.de/wiki/index.php/DVB-C_full-featured-Karten#Fujitsu-Siemens_DVB-C
- tested O.K. with original Siemens PCI Card + CI + Analog Module
- tested O.K. with xawtv (latest 3.xx release at this time)
- tested O.K. with gnomemeeting (v4l1 only)
- tested O.K. with tvtime 0.9x (NOT OK if tuner is accessed! be careful)
- not tested the Y/C input configuration, is guessed from datasheet.
signed-off-by: [EMAIL PROTECTED]
y
tom
--- linux-2.6.12/drivers/media/dvb/ttpci/av7110_v4l.c 2005-06-17
21:48:29.0 +0200
+++ linux-2.6.12/drivers/media/dvb/ttpci/av7110_v4l.c 2005-07-11
01:43:18.0 +0200
@@ -70,7 +70,7 @@
return 0;
}
-static struct v4l2_input inputs[2] = {
+static struct v4l2_input inputs[4] = {
{
.index = 0,
.name = "DVB",
@@ -87,6 +87,22 @@
.tuner = 0,
.std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
.status = 0,
+ }, {
+ .index = 2,
+ .name = "Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
+ }, {
+ .index = 3,
+ .name = "Y/C",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
}
};
@@ -212,11 +228,17 @@
}
if (0 != av7110->current_input) {
+
+ dprintk(1, "switching to analog TV: \n");
adswitch = 1;
source = SAA7146_HPS_SOURCE_PORT_B;
sync = SAA7146_HPS_SYNC_PORT_B;
memcpy(standard, analog_standard, sizeof(struct
saa7146_standard) * 2);
- dprintk(1, "switching to analog TV\n");
+
+ switch (av7110->current_input) {
+ case 1:
+ {
+ dprintk(1, "switching SAA7113 to Analog Tuner Input.\n");
msp_writereg(av7110, MSP_WR_DSP, 0x0008, 0x); //
loudspeaker source
msp_writereg(av7110, MSP_WR_DSP, 0x0009, 0x); // headphone
source
msp_writereg(av7110, MSP_WR_DSP, 0x000a, 0x); // SCART 1
source
@@ -231,6 +253,37 @@
saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); // TDA9198
pin9(STD)
saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI); // TDA9198
pin30(VIF)
}
+
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd0) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ break;
+ }
+
+ case 2:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd2) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV CVBS Input.\n");
+ break;
+ }
+
+ case 3:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd9) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV Y/C Input.\n");
+ break;
+ }
+
+ default:
+ {
+ dprintk(1, "switching SAA7113 to Input: AV7110: SAA7113: invalid
input.\n");
+ }
+ }
+
} else {
adswitch = 0;
source = SAA7146_HPS_SOURCE_PORT_A;
@@ -406,7 +459,7 @@
dprintk(2, "VIDIOC_ENUMINPUT: %d\n", i->index);
if (av7110->analog_tuner_flags) {
- if (i->index < 0 || i->index >= 2)
+ if (i->index < 0 || i->index >= 4)
return -EINVAL;
} else {
if (i->index != 0)
@@ -433,7 +486,7 @@
if (!av7110->analog_tuner_flags)
return 0;
- if (input < 0 || input >= 2)
+ if (input < 0 || input >= 4)
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
[PATCH][DVB][2.6.12]Siemens DVB-C PCI: SAA7113 Analog Module Extension: Fix missing Video (CVBS+Y/C) Inputs in AV711X V4L driver
hello,
this patch enables the before not implemented video inputs of the
SAA7113 Analog Cable Extension Module of that "classic" dvb-c card
listed:
http://www.vdr-wiki.de/wiki/index.php/DVB-C_full-featured-Karten#Fujitsu-Siemens_DVB-C
- tested O.K. with original Siemens PCI Card + CI + Analog Module
- tested O.K. with xawtv (latest 3.xx release at this time)
- tested O.K. with gnomemeeting (v4l1 only)
- tested O.K. with tvtime 0.9x (NOT OK if tuner is accessed! be careful)
- not tested the Y/C input configuration, is guessed from datasheet.
signed-off-by: [EMAIL PROTECTED]
y
tom
--- av7110_v4l.c2005-06-17 21:48:29.0 +0200
+++ av7110_v4l.c2005-07-11 01:43:18.0 +0200
@@ -70,7 +70,7 @@
return 0;
}
-static struct v4l2_input inputs[2] = {
+static struct v4l2_input inputs[4] = {
{
.index = 0,
.name = "DVB",
@@ -87,6 +87,22 @@
.tuner = 0,
.std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
.status = 0,
+ }, {
+ .index = 2,
+ .name = "Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
+ }, {
+ .index = 3,
+ .name = "Y/C",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
}
};
@@ -212,11 +228,17 @@
}
if (0 != av7110->current_input) {
+
+ dprintk(1, "switching to analog TV: \n");
adswitch = 1;
source = SAA7146_HPS_SOURCE_PORT_B;
sync = SAA7146_HPS_SYNC_PORT_B;
memcpy(standard, analog_standard, sizeof(struct
saa7146_standard) * 2);
- dprintk(1, "switching to analog TV\n");
+
+ switch (av7110->current_input) {
+ case 1:
+ {
+ dprintk(1, "switching SAA7113 to Analog Tuner Input.\n");
msp_writereg(av7110, MSP_WR_DSP, 0x0008, 0x); //
loudspeaker source
msp_writereg(av7110, MSP_WR_DSP, 0x0009, 0x); // headphone
source
msp_writereg(av7110, MSP_WR_DSP, 0x000a, 0x); // SCART 1
source
@@ -231,6 +253,37 @@
saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); // TDA9198
pin9(STD)
saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI); // TDA9198
pin30(VIF)
}
+
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd0) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ break;
+ }
+
+ case 2:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd2) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV CVBS Input.\n");
+ break;
+ }
+
+ case 3:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd9) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV Y/C Input.\n");
+ break;
+ }
+
+ default:
+ {
+ dprintk(1, "switching SAA7113 to Input: AV7110: SAA7113: invalid
input.\n");
+ }
+ }
+
} else {
adswitch = 0;
source = SAA7146_HPS_SOURCE_PORT_A;
@@ -406,7 +459,7 @@
dprintk(2, "VIDIOC_ENUMINPUT: %d\n", i->index);
if (av7110->analog_tuner_flags) {
- if (i->index < 0 || i->index >= 2)
+ if (i->index < 0 || i->index >= 4)
return -EINVAL;
} else {
if (i->index != 0)
@@ -433,7 +486,7 @@
if (!av7110->analog_tuner_flags)
return 0;
- if (input < 0 || input >= 2)
+ if (input < 0 || input >= 4)
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://ww
[PATCH] [DVB]Siemens DVB-C PCI: SAA7113 Analog Module Extension: Fix missing Video (CVBS+Y/C) Inputs in AV7111X V4L driver
hello,
this patch enables the before not implemented video inputs of the
SAA7113 Analog Cable Extension Module of that "classic" dvb-c card
listed:
http://www.vdr-wiki.de/wiki/index.php/DVB-C_full-featured-Karten#Fujitsu-Siemens_DVB-C
- tested O.K. with original Siemens PCI Card + CI + Analog Module
- tested O.K. with xawtv (latest 3.xx release at this time)
- tested O.K. with gnomemeeting (v4l1 only)
- tested O.K. with tvtime 0.9x (NOT OK if tuner is accessed! be careful)
- not tested the Y/C input configuration, is guessed from datasheet.
signed-off-by: [EMAIL PROTECTED]
y
tom
--- av7110_v4l.c2005-06-17 21:48:29.0 +0200
+++ av7110_v4l.c-7113 2005-07-11 01:43:18.0 +0200
@@ -70,7 +70,7 @@
return 0;
}
-static struct v4l2_input inputs[2] = {
+static struct v4l2_input inputs[4] = {
{
.index = 0,
.name = "DVB",
@@ -87,6 +87,22 @@
.tuner = 0,
.std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
.status = 0,
+ }, {
+ .index = 2,
+ .name = "Video",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
+ }, {
+ .index = 3,
+ .name = "Y/C",
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .audioset = 0,
+ .tuner = 0,
+ .std= V4L2_STD_PAL_BG|V4L2_STD_NTSC_M,
+ .status = 0,
}
};
@@ -212,11 +228,17 @@
}
if (0 != av7110->current_input) {
+
+ dprintk(1, "switching to analog TV: \n");
adswitch = 1;
source = SAA7146_HPS_SOURCE_PORT_B;
sync = SAA7146_HPS_SYNC_PORT_B;
memcpy(standard, analog_standard, sizeof(struct
saa7146_standard) * 2);
- dprintk(1, "switching to analog TV\n");
+
+ switch (av7110->current_input) {
+ case 1:
+ {
+ dprintk(1, "switching SAA7113 to Analog Tuner Input.\n");
msp_writereg(av7110, MSP_WR_DSP, 0x0008, 0x); //
loudspeaker source
msp_writereg(av7110, MSP_WR_DSP, 0x0009, 0x); // headphone
source
msp_writereg(av7110, MSP_WR_DSP, 0x000a, 0x); // SCART 1
source
@@ -231,6 +253,37 @@
saa7146_setgpio(dev, 1, SAA7146_GPIO_OUTHI); // TDA9198
pin9(STD)
saa7146_setgpio(dev, 3, SAA7146_GPIO_OUTHI); // TDA9198
pin30(VIF)
}
+
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd0) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ break;
+ }
+
+ case 2:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd2) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV CVBS Input.\n");
+ break;
+ }
+
+ case 3:
+ {
+ if (i2c_writereg(av7110, 0x48, 0x02, 0xd9) != 1) {
+ dprintk(1, "saa7113 write failed @ card %d",
av7110->dvb_adapter.num);
+ }
+ dprintk(1, "switching SAA7113 to Video AV Y/C Input.\n");
+ break;
+ }
+
+ default:
+ {
+ dprintk(1, "switching SAA7113 to Input: AV7110: SAA7113: invalid
input.\n");
+ }
+ }
+
} else {
adswitch = 0;
source = SAA7146_HPS_SOURCE_PORT_A;
@@ -406,7 +459,7 @@
dprintk(2, "VIDIOC_ENUMINPUT: %d\n", i->index);
if (av7110->analog_tuner_flags) {
- if (i->index < 0 || i->index >= 2)
+ if (i->index < 0 || i->index >= 4)
return -EINVAL;
} else {
if (i->index != 0)
@@ -433,7 +486,7 @@
if (!av7110->analog_tuner_flags)
return 0;
- if (input < 0 || input >= 2)
+ if (input < 0 || input >= 4)
return -EINVAL;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.
