From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: linux1394-user@lists.sourceforge.net,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: VIA VT6307 OHCI version?
Date: Mon, 29 Oct 2007 00:12:04 +0100 [thread overview]
Message-ID: <47251744.6090206@s5r6.in-berlin.de> (raw)
In-Reply-To: <m33avvdlbq.fsf@maximus.localdomain>
Krzysztof Halasa wrote:
> Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
>> # ./a.out 00:0a.3
>> I/O region #1 is at C800
>> It seems your VT6307 chip is connected to 93c46 EEPROM
>
> Interesting, really. Perhaps they aimed at I2C too with 9306 but
> screwed up the silicon? Would have to look at the pinout but for
> now I'm sick and high fever makes it hard.
>
> It's all consistent, amazingly.
>
> 6306#1
>> 00: 00 11 06 00 00 00 E3 32 00 88 00 08 44 00 00 00
>> 10: A1 E4 2F 00 06 11 44 30 03 DF 40 00 00 20 00 73
>> 20: 3C 10 00 00 00 00 FF FF FF FF FF FF D7 57 55 75
>
> Obviously some values are different than these for my 3 vt6307
> (not counting GUID + PCI sub IDs). Though data at 0x20+ is equal.
>
> The last 4 bytes are almost certainly rubbish, that asks the question
> if the contents hasn't been changed through some tests, works on
> the drivers etc, or if the manufacturer did it right (for example
> I somehow managed to clear the GUID on I^2C version before I had the
> code to write to it, quite a mystery (writing correct I^2C sequence
> for it isn't trivial due to the need of non-all-zeros DEVSEL byte
> preceded by the start sequence).
>
> I wonder if the EEPROM has more non-FF data? IIRC the chips addresses
> 0x80 bytes, or maybe 0x100? I limited it to 0x40 in the code because
> the rest is never read by the chip, except if requested by the user.
> (For 93c46 the program could read any location directly but I didn't
> implement that).
This device is a somewhat buggy PCI card which somebody sent me after
unsuccessful attempts to get it properly working under Linux. Among
more serious trouble, ohci1394 reads a bogus maximum async payload (a
zero value) from the BusOptions register during startup. This has
occasionally been reported for some VT6306 in the past. I haven't
really tested this card myself yet, it's currently stuck in a PC which I
don't use anymore.
Bad VT6306 card:
PCI: Found IRQ 11 for device 0000:00:0a.3
PCI: Sharing IRQ 11 with 0000:00:0a.0
PCI: Sharing IRQ 11 with 0000:00:10.1
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11]
MMIO=[ec101000-ec1017ff] Max Packet=[2] IR/IT contexts=[4/8]
ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to
set max_packet_size to 512 bytes
ieee1394: Host added: ID:BUS[0-00:1023] GUID[001106000000e332]
VT6306 onboard controller:
PCI: setting IRQ 5 as level-triggered
PCI: Found IRQ 5 for device 0000:00:0c.0
PCI: Sharing IRQ 5 with 0000:00:0a.2
ohci1394: fw-host1: OHCI-1394 1.0 (PCI): IRQ=[5]
MMIO=[ec103000-ec1037ff] Max Packet=[2048] IR/IT contexts=[8/8]
ieee1394: Host added: ID:BUS[1-00:1023] GUID[00301bac00002ba4]
VT6306 CardBus card in my main PC:
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 17 (level, low) -> IRQ 18
ohci1394: fw-host2: OHCI-1394 1.0 (PCI): IRQ=[18]
MMIO=[80000000-800007ff] Max Packet=[1024] IR/IT contexts=[4/8]
ieee1394: Host added: ID:BUS[2-00:1023] GUID[00110600000041cc]
The Max Packet value of the CardBus card is OK; all CardBus cards seem
to have this limitation regardless of their link layer chip.
I wonder what's up with the varying number of IR contexts. The
datasheet talks about 8 IR contexts and 8 IR context registers, but also
has a sentence "These registers are Context Control registers for
isochronous Receive Contexts 0-3" which may be an editorial error.
--
Stefan Richter
-=====-=-=== =-=- ===--
http://arcgraph.de/sr/
next prev parent reply other threads:[~2007-10-28 23:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <m3sl4ciz1h.fsf@maximus.localdomain>
[not found] ` <4714EF01.2060609@s5r6.in-berlin.de>
2007-10-16 20:20 ` Krzysztof Halasa
2007-10-16 20:33 ` Krzysztof Halasa
2007-10-16 21:06 ` Stefan Richter
2007-10-17 19:38 ` Krzysztof Halasa
2007-10-17 20:11 ` Stefan Richter
2007-10-17 20:54 ` Krzysztof Halasa
2007-10-17 21:06 ` Stefan Richter
2007-10-18 0:07 ` Krzysztof Halasa
2007-10-19 22:42 ` Krzysztof Halasa
2007-10-20 6:31 ` Stefan Richter
2007-10-20 13:03 ` Krzysztof Halasa
2007-10-20 13:13 ` Stefan Richter
2007-10-20 23:23 ` Krzysztof Halasa
2007-10-28 17:41 ` Stefan Richter
2007-10-28 20:40 ` Krzysztof Halasa
2007-10-28 23:12 ` Stefan Richter [this message]
2007-10-29 12:53 ` Krzysztof Halasa
2007-11-03 19:15 ` Stefan Richter
2007-11-04 16:54 ` Krzysztof Halasa
2007-11-04 19:31 ` Andreas Mohr
2007-11-04 23:00 ` Krzysztof Halasa
2007-11-05 18:25 ` Andreas Mohr
2007-11-05 19:14 ` Stefan Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47251744.6090206@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-user@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®