From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7C18C432BE for ; Thu, 26 Aug 2021 05:22:53 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0B9C06108D for ; Thu, 26 Aug 2021 05:22:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0B9C06108D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=nongnu.org Received: from localhost ([::1]:46600 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mJ7ql-0007Dy-TZ for qemu-devel@archiver.kernel.org; Thu, 26 Aug 2021 01:22:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJ7pb-0006Mo-AL; Thu, 26 Aug 2021 01:21:39 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37435) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mJ7pZ-00089U-9L; Thu, 26 Aug 2021 01:21:39 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 35AE25C0151; Thu, 26 Aug 2021 01:21:33 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 26 Aug 2021 01:21:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=bskgcM C9y26v+u+6Y0yOgGgv5D1EuJiUvIx22z2XyJ0=; b=uyR+NHiZUXA3asaL+p59vj D7Ad4DQDa8F5YbCpTyW+LToJnbxqG+rjYqkWwpVrGwAe3IcsPYyKoaj5TV5ya6Jg f5y7XMda2udVefBznKYRdoNA9XZBfeeZFkaqKgF6WCqzm/AIne+r4g6VCPcCuD5Q n2vRuho350km5PRH/SOatqTOt2qW2YsYC7MzycXHXFU4huLmMqIvqMQnOlfzHTVv fRWcdqaYcS3oNYq9qzfCZ5tKNcay4paTzdQZnOaf7mZnaoOnQ2l9KKXq3UrRDoB6 n5ySMWRnXBMhBXUUdz/yoxHl6fUQqMRUgutNrw6bohSkbayWRp/TdWQEnai+apGg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddruddutddgleehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffujgfkfhggtgesthdtredttddtvdenucfhrhhomhephfhinhhnucfv hhgrihhnuceofhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgheqnecuggftrfgrth htvghrnhepiedvieetledvleevvdeiffetieekfffhleetjeeijeelffejudduteeihfff kedtnecuffhomhgrihhnpeeihedtvddrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehfthhhrghinheslhhinhhugidqmheikehkrdho rhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Aug 2021 01:21:28 -0400 (EDT) Date: Thu, 26 Aug 2021 15:21:22 +1000 (AEST) From: Finn Thain To: Mark Cave-Ayland Subject: Re: [RFC 05/10] hw/mos6522: Don't clear T1 interrupt flag on latch write In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Received-SPF: none client-ip=66.111.4.27; envelope-from=fthain@linux-m68k.org; helo=out3-smtp.messagingengine.com X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel@nongnu.org, Laurent Vivier , qemu-ppc@nongnu.org, Greg Kurz , David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Wed, 25 Aug 2021, Mark Cave-Ayland wrote: > On 24/08/2021 11:09, Finn Thain wrote: > > > The Synertek datasheet says, "A write to T1L-H loads an 8-bit count value > > into the latch. A read of T1L-H transfers the contents of the latch to > > the data bus. Neither operation has an affect [sic] on the interrupt > > flag." > > > > Signed-off-by: Finn Thain > > --- > > hw/misc/mos6522.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c > > index c0d6bee4cc..ffff8991f4 100644 > > --- a/hw/misc/mos6522.c > > +++ b/hw/misc/mos6522.c > > @@ -313,7 +313,6 @@ void mos6522_write(void *opaque, hwaddr addr, uint64_t > > val, unsigned size) > > break; > > case VIA_REG_T1LH: > > s->timers[0].latch = (s->timers[0].latch & 0xff) | (val << 8); > > - s->ifr &= ~T1_INT; > > break; > > case VIA_REG_T2CL: > > s->timers[1].latch = (s->timers[1].latch & 0xff00) | val; > > Hmmm. The reference document I used for QEMU's 6522 device is at > http://archive.6502.org/datasheets/mos_6522_preliminary_nov_1977.pdf and > according to page 6 and the section "Writing the Timer 1 Registers" writing to > the high byte of the latch does indeed clear the T1 interrupt flag. > > Side note: there is reference in Gary Davidian's excellent CHM video that > 6522s obtained from different manufacturers had different behaviours, and > there are also web pages mentioning that 6522s integrated as part of other > silicon e.g. IOSB/CUDA also had their own bugs... :/ > The MOS document you've cited is much older than the Synertek and Rockwell devices. The datasheets for the Synertek and Rockwell parts disagree with MOS about T1LH behaviour. Apple certainly used SY6522 devices in my Mac II and I'd assumed Apple would have used compatible logic cores in the custom ICs found in later models. But I don't really trust assumptions and datasheets so I wrote the Linux patch below and ran it on my Quadra 630. diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c index 3d11d6219cdd..ed41f6ae2bf2 100644 --- a/arch/m68k/mac/via.c +++ b/arch/m68k/mac/via.c @@ -634,3 +634,27 @@ static u64 mac_read_clk(struct clocksource *cs) return ticks; } + +static int baz(void) +{ + u8 a, b, c; + + local_irq_disable(); + + while (!(via1[vIFR] & VIA_TIMER_1_INT)) + continue; + a = via1[vIFR] & VIA_TIMER_1_INT; + via1[vT1LH] = via1[vT1LH]; + b = via1[vIFR] & VIA_TIMER_1_INT; + via1[vT1LL] = via1[vT1LL]; + c = via1[vIFR] & VIA_TIMER_1_INT; + + printk("a == %2x\n", a); + printk("b == %2x\n", b); + printk("c == %2x\n", c); + + local_irq_enable(); + + return 0; +} +late_initcall(baz); Based on the Synertek datasheet* one would expect to see b equal to a but I got this result instead: [ 10.450000] a == 40 [ 10.450000] b == 0 [ 10.450000] c == 0 This amounts to a MOS design flaw and I doubt that this result from my Quadra 630 would apply to other Mac models. So it would be great to see the output from a Quadra 800. But until then, let's disregard this patch. * http://archive.6502.org/datasheets/synertek_sy6522.pdf