From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCWCZ-0002L3-Mz for qemu-devel@nongnu.org; Sun, 09 Feb 2014 10:21:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WCWCT-0002q6-Fp for qemu-devel@nongnu.org; Sun, 09 Feb 2014 10:21:47 -0500 Received: from s16892447.onlinehome-server.info ([82.165.15.123]:44729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WCWCT-0002pz-8Y for qemu-devel@nongnu.org; Sun, 09 Feb 2014 10:21:41 -0500 Message-ID: <52F79C89.2010204@ilande.co.uk> Date: Sun, 09 Feb 2014 15:19:37 +0000 From: Mark Cave-Ayland MIME-Version: 1.0 References: <1391877522-17254-1-git-send-email-mark.cave-ayland@ilande.co.uk> <1391877522-17254-2-git-send-email-mark.cave-ayland@ilande.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv2 1/2] sun4m: Add Sun CG3 framebuffer and corresponding OpenBIOS FCode ROM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Blue Swirl , Bob Breuer , QEMU Developers , Anthony Liguori , Artyom Tarasenko On 09/02/14 14:41, Peter Maydell wrote: > On 8 February 2014 16:38, Mark Cave-Ayland > wrote: >> The CG3 framebuffer is a simple 8-bit framebuffer for use with operating >> systems such as early Solaris that do not have drivers for TCX. >> >> +static void cg3_reg_write(void *opaque, hwaddr addr, uint64_t val, >> + unsigned size) >> +{ >> + CG3State *s = opaque; >> + uint8_t regval; >> + int i; >> + >> + DPRINTF("write %02lx to reg %x size %d\n", val, (int)addr, size); >> + >> + switch (addr) { >> + case 0: >> + s->dac_index = val; >> + s->dac_state = 0; >> + break; >> + case 4: >> + /* This register can be written to as either a long word or a byte. >> + * According to the SBus specification, byte transfers are placed >> + * in bits 31-28 */ >> + if (size == 1) { >> + val<<= 24; >> + } > > I'm a little reluctant to start talking about endianness again :-) > but that "if (size == 1)" comment looks a little odd to me. The SBus > spec says that SBus is a big-endian bus (which probably means > that the .endianness in the memops struct should be > DEVICE_BIG_ENDIAN though for SPARC targets it won't make > any actual difference)". So while it's true that for SBus you get > byte transfers in data lines 31..28 (and also possibly on some of > the other data lines if the address is not 4-aligned or if the master > just feels like sending the byte on all four lanes at once), I don't > think that's why you're doing this shift. The shift is presumably > because the behaviour of this specific device is "I treat a byte > write like a write to the most significant byte of this register", > not because of the specifics of how SBus defines a byte transfer > to occur. It's been a little while since I looked, however this was my interpretation of the table 3-12 on p.66 of the SBus specification. While that particular table refers to the acknowledgment cycle from the slave back to the master, it seems to work here in the same way when transferring between the master and the slave. One of things we do know about that card is that the DAC is a BT408, where the 256 * 3 shift register for the RGB values is seemingly controller by register 4. And I'm fairly sure that I've seen a mixture of byte and 4-byte accesses to the card coming from the Solaris driver which is why it's necessary to support both accesses in this way :/ There is also a related comment on page 80 explaining how bus sizing can be used to allow 8-bit framebuffer to be driven in exactly the same way as a 32-bit framebuffer. FWIW I copied the .endianness part over from the TCX driver, so if you feel for correctness that .endianness needs to be DEVICE_BIG_ENDIAN for TCX too then I'm happy to submit a patch for that too. ATB, Mark.