From: Patrick Williams <patrick@stwcx.xyz>
To: Ed Tanous <edtanous@google.com>
Cc: openbmc@lists.ozlabs.org, Benjamin Fair <benjaminfair@google.com>,
Michael Shen <gpgpgp@google.com>
Subject: Re: Propose a new application for reading DIMM SPD directly
Date: Wed, 9 Feb 2022 15:14:52 -0600 [thread overview]
Message-ID: <YgQuzD9AkrqstygH@heinlein> (raw)
In-Reply-To: <CAH2-KxAyXn3YndZY_aWAMt4M6eTMrkPA91vCPeOj0tZOgPv-vA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]
On Wed, Feb 09, 2022 at 12:20:00PM -0800, Ed Tanous wrote:
> On Wed, Feb 9, 2022 at 11:56 AM Patrick Williams <patrick@stwcx.xyz> wrote:
> > On Tue, Feb 08, 2022 at 04:23:12PM +0800, Michael Shen wrote:
> > > On Tue, Feb 8, 2022 at 3:11 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > > > On Tue, Feb 08, 2022 at 01:10:37PM +0800, Michael Shen wrote:
> > > BIOS owns the MUX select pin and it can decide who owns the SPD(I2C/I3C) bus.
> > > From my understanding, BIOS only needs to read SPD during the POST stage.
> > > For the rest of time, BIOS will hand over the SPD bus to BMC.
> >
> > That seems like it might work. You'll have to deal with the time when the BIOS
> > has the mux in the BMC code somehow. Ideally I'd ask for the mux select to also
> > be fed to the BMC as an input GPIO so that you can differentiate between "we
> > don't own the mux" and "all the devices are NAKing us".
>
> This seems like a nitty gritty design detail that's best handled in
> code when we review it. I think the important bit here is that there
> are paths where this could work without a significant design issue.
Just one subtlety. I wouldn't expect this, necessarily, to be in _our_ design
and/or code, except that we'd want to document the GPIO line like we do all
others. I was trying to hint that "if I were involved in this hardware design,
I'd ask for...". If you leave it out, I'm sure it'll work _most_ of the time
just fine and it'll be your problem to debug it when it doesn't.
--
Patrick Williams
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-09 21:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 5:10 Propose a new application for reading DIMM SPD directly Michael Shen
2022-02-08 7:11 ` Patrick Williams
2022-02-08 8:23 ` Michael Shen
2022-02-09 19:56 ` Patrick Williams
2022-02-09 20:20 ` Ed Tanous
2022-02-09 21:14 ` Patrick Williams [this message]
2022-02-09 22:45 ` Ed Tanous
2022-02-11 0:40 ` Michael Shen
2022-02-11 21:21 ` Zbigniew, Lukwinski
2022-02-14 22:17 ` Benjamin Fair
2022-02-15 1:50 ` Michael Shen
2022-02-15 20:39 ` Zbigniew, Lukwinski
2022-02-17 3:59 ` Michael Shen
2022-02-21 12:07 ` Zbigniew, Lukwinski
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=YgQuzD9AkrqstygH@heinlein \
--to=patrick@stwcx.xyz \
--cc=benjaminfair@google.com \
--cc=edtanous@google.com \
--cc=gpgpgp@google.com \
--cc=openbmc@lists.ozlabs.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.