All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Venture <venture@google.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
Cc: Corey Minyard <cminyard@mvista.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Hao Wu <wuhaotsh@google.com>
Subject: Re: [PATCH] hw/i2c: flatten pca954x mux device
Date: Wed, 2 Feb 2022 13:30:39 -0800	[thread overview]
Message-ID: <CAO=notzN4_Sid6AvwDa4UUCjrUQs+vCf8NA-PmiHULiyGwUQMQ@mail.gmail.com> (raw)
In-Reply-To: <f10cbf13-ac56-cbe0-02f8-1d96a687700e@amsat.org>

[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]

On Wed, Feb 2, 2022 at 9:31 AM Philippe Mathieu-Daudé <f4bug@amsat.org>
wrote:

> On 2/2/22 17:40, Patrick Venture wrote:
>
> >     Philippe,
> >
> >     I0202 08:29:45.380384  6641 stream.go:31] qemu: child buses at
> >     "pca9546": "channel[*]", "channel[*]", "channel[*]", "channel[*]"
> >
> >     Ok, so that's interesting.  In one system (using qom-list) it's
> >     correct, but then when using it to do path assignment
> >     (qdev-monitor), it fails...
> >
> >     I'm not as fond of the name i2c-bus.%d, since they're referred to as
> >     channels in the datasheet.  If I do the manual name creation, can I
> >     keep the name channel or should I pivot over?
> >
> >     Thanks
> >
> >
> >             -- >8 --
> >             diff --git a/hw/i2c/i2c_mux_pca954x.c
> b/hw/i2c/i2c_mux_pca954x.c
> >             index f9ce633b3a..a9517b612a 100644
> >             --- a/hw/i2c/i2c_mux_pca954x.c
> >             +++ b/hw/i2c/i2c_mux_pca954x.c
> >             @@ -189,9 +189,11 @@ static void pca954x_init(Object *obj)
> >
> >                    /* SMBus modules. Cannot fail. */
> >                    for (i = 0; i < c->nchans; i++) {
> >             +        g_autofree gchar *bus_name =
> >             g_strdup_printf("i2c.%d", i);
> >             +
> >                        /* start all channels as disabled. */
> >                        s->enabled[i] = false;
> >             -        s->bus[i] = i2c_init_bus(DEVICE(s), "channel[*]");
> >             +        s->bus[i] = i2c_init_bus(DEVICE(s), bus_name);
> >                    }
> >                }
> >
> >             ---
> >
> >             (look at HMP 'info qtree' output).
> >
> >              >       }
> >              >   }
> >
> >             With the change:
> >             Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org
> >             <mailto:f4bug@amsat.org>>
> >             Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org
> >             <mailto:f4bug@amsat.org>>
> >
> >
> > Just saw your reply, and found a bunch of other non-spam in my spam
> > folder.  I sent the message to the anti-spam team, hopefully that'll
> > resolve this for myself and presumably others.
>
> Thanks. I suppose the problem is the amsat.org domain.
>

Yours aren't the only ones I've missed, but who knows.


>
> > I definitely see the same result with the qdev-monitor, but was really
> > surprised that the qom-list worked.  I'll explicitly set the name, and
> > i2c.%d is fine.  The detail that they're channels is not really
> > important to the end user presumably.
>
> I agree it is better to follow datasheets, thus I am fine if you
> change and use channel. How would it look like? "channel.0"?
> FYI qdev busses are described in docs/qdev-device-use.txt.
>

Thanks.  I went with i2c.%d in v2, since I figured it wasn't super
important.


>
> We should be able to plug a device using some command line
> such "-device i2c_test_dev,bus=channel.0,addr=0x55".
> I wonder how to select the base PCA9548 ...
>

So I have been working on that, and I have been running into a different
issue, but related.

/smbus[1]/i2c-bus/pca9546/i2c.0 works to add a device via command line.

However, if there are two pca9546s on that main bus.  So if i do:

/smbus[1]/i2c-bus/child[0]/i2c.0 it'll respond that there is no child[0],
but rather includes "pca9546, pca9546"


>
> Maybe we need to pass the PCA ID to pca954x_init(), so we can
> name "channel.2.0" for the 1st channel on the 2nd PCA?
>

It sounds like you're thinking about the same problem overall.


>
> Regards,
>
> Phil.
>

[-- Attachment #2: Type: text/html, Size: 5548 bytes --]

  reply	other threads:[~2022-02-02 21:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 16:30 [PATCH] hw/i2c: flatten pca954x mux device Patrick Venture
2022-02-01 19:02 ` Philippe Mathieu-Daudé via
2022-02-01 20:54   ` Patrick Venture
2022-02-02 16:20     ` Philippe Mathieu-Daudé via
2022-02-02 16:34     ` Patrick Venture
2022-02-02 16:40       ` Patrick Venture
2022-02-02 17:30         ` Philippe Mathieu-Daudé via
2022-02-02 21:30           ` Patrick Venture [this message]
2022-02-02 19:01         ` Peter Maydell
2022-02-02 19:53           ` Patrick Venture

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='CAO=notzN4_Sid6AvwDa4UUCjrUQs+vCf8NA-PmiHULiyGwUQMQ@mail.gmail.com' \
    --to=venture@google.com \
    --cc=cminyard@mvista.com \
    --cc=f4bug@amsat.org \
    --cc=qemu-devel@nongnu.org \
    --cc=wuhaotsh@google.com \
    /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.