Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 13 Apr 2022 16:55:10 +0100 (BST)
From:   "Maciej W. Rozycki" <macro@orcam.me.uk>
To:     Thomas Gleixner <tglx@linutronix.de>
cc:     Daniel Vacek <neelx@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86/apic: Clarify i82489DX bit overlap in APIC_LVT0
In-Reply-To: <875yndf760.ffs@tglx>
Message-ID: <alpine.DEB.2.21.2204131450220.9383@angie.orcam.me.uk>
References: <20220202140244.1681140-1-neelx@redhat.com> <874k361liu.ffs@tglx> <CACjP9X_A7aLmvypyOz1UrXM571gx_X5q7=w-1j+G+MSbCteiEw@mail.gmail.com> <87ee22f3ci.ffs@tglx> <alpine.DEB.2.21.2204122235140.9383@angie.orcam.me.uk> <875yndf760.ffs@tglx>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

Thomas,

> >  For the record, it's documented in the i82498DX datasheet[1] and user 
> > manual[2]:
> >
> > 'Bits [19:18] Timer Base: This field selects the time base input to be 
> > used by the timer.
> 
> That's true, but how many people aside of you and me still have access
> to the i82498DX related documentation? The interwebs has no trace of
> them.

 Hmm, actually now that you mention it I recall that archive.org does have 
scanned copies of the 1995 Intel486 Microprocessors and Pentium Processors 
databooks, and they include the i82489DX datasheet and manual respectively 
starting from pages 4-220 (857) and 2-579 (600).  See:

<https://archive.org/details/bitsavers_intel80486croprocessorsandRelatedProductsJan95_58561506>

<https://archive.org/details/bitsavers_intelpentirocessorsandRelatedComponents_64170750>

I have uploaded clean copies of the discrete documents to my site now too, 
made via a PostScript printer driver with the "print" function of software 
included with Intel Data on Demand CDs to handle the proprietary document 
format used there.  Sadly these are bitmaps rather than searchable PDFs, 
but they might be easier to refer to.  No better format has been tracked 
down.  See:

<ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/APIC/>

Because why not?

> With the above I explicitely meant the undocumented bit overlap both in
> the current SDMs and the kernel source.

 Fair enough.  The lore has probably been already forgotten within Intel.

  Maciej