All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Daniel Dadap <ddadap@nvidia.com>
Cc: dri-devel@lists.freedesktop.org,
	platform-driver-x86@vger.kernel.org, pobrn@protonmail.com,
	peter@lekensteyn.nl, dvhart@infradead.org, andy@infradead.org
Subject: Re: [PATCH v3] platform/x86: Add new vga-switcheroo gmux driver for ACPI-driven muxes
Date: Tue, 11 Aug 2020 05:43:01 +0200	[thread overview]
Message-ID: <20200811034301.nlhue4xgfv4p3utr@wunner.de> (raw)
In-Reply-To: <c7b1b098-a0ef-6e78-92c1-32da9b4ea3f3@nvidia.com>

On Mon, Aug 10, 2020 at 01:44:58PM -0500, Daniel Dadap wrote:
> On 8/10/20 3:37 AM, Lukas Wunner wrote:
> > On Wed, Jul 29, 2020 at 04:05:57PM -0500, Daniel Dadap wrote:
> > > + * Call MXDS with bit 0 set to change the current state.
> > > + * When changing state, clear bit 4 for iGPU and set bit 4 for dGPU.
> > [...]
> > > +enum mux_state_command {
> > > +     MUX_STATE_GET = 0,
> > > +     MUX_STATE_SET_IGPU = 0x01,
> > > +     MUX_STATE_SET_DGPU = 0x11,
> > > +};
> > It looks like the code comment is wrong and bit 1 (instead of bit 4) is
> > used to select the GPU.
> 
> The code comment is correct. The enum values are hexadecimal, not binary.

Ugh, missed that, sorry for the noise.

> Would it be clearer to write it out as something like 0 << 4 & 1 << 0 for
> MUX_STATE_SET_IGPU and 1 << 4 & 1 << 0 for MUX_STATE_SET_DGPU?

BIT(4) | BIT(0) might be clearer, but that gives you an unsigned long
and I'm not sure if gcc accepts that as an enum (=int) initializer.

> > > +static enum vga_switcheroo_client_id mxds_gmux_get_client_id(
> > > +     struct pci_dev *dev)
> > > +{
> > > +     if (dev) {
> > > +             if (ig_dev && dev->vendor == ig_dev->vendor)
> > > +                     return VGA_SWITCHEROO_IGD;
> > > +             if (dg_dev && dev->vendor == dg_dev->vendor)
> > > +                     return VGA_SWITCHEROO_DIS;
> > > +     }
> > That's a little odd.  Why not use "ig_dev == dev" and "dg_dev == dev"?
> 
> No reason; that is indeed better. I think originally these comparisons got a
> vendor ID from some other means.

Perhaps it was necessary in case an eGPU is attached, but that shouldn't
be an issue if you filter out Thunderbolt devices with
pci_is_thunderbolt_attached().

> Yes, MXMX and MXDS go back a ways, it seems. I'm not familiar enough with
> the MXMX+MXDS designs to know if MXDS uses the same API in those designs as
> it doesn in the MXDM+MXDS designs. I'm not aware of any already available
> designs with MXDM. MXMX was used for switching DDC lines independently back
> when LVDS panels were the norm. The upcoming MXDM+MXDS designs are eDP-based
> and do not support independent DDC muxing.

Interesting, thank you for the explanation.

Lukas
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-08-11  3:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0850ac9a-3d60-053d-1d70-5f20ce621b24@nvidia.com>
2020-07-29 21:05 ` [PATCH v3] platform/x86: Add new vga-switcheroo gmux driver for ACPI-driven muxes Daniel Dadap
2020-08-10  8:37   ` Lukas Wunner
2020-08-10 18:44     ` Daniel Dadap
2020-08-11  3:43       ` Lukas Wunner [this message]
2020-08-11 21:22         ` Daniel Dadap
2020-09-02 17:38           ` [PATCH v4] " Daniel Dadap
2020-09-02 18:37             ` Andy Shevchenko
2020-09-08 19:33               ` Daniel Dadap
2020-11-10  9:29             ` Hans de Goede
2020-11-10  9:29               ` Hans de Goede
2020-11-12 18:53               ` Daniel Dadap
2020-11-12 18:53                 ` Daniel Dadap

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=20200811034301.nlhue4xgfv4p3utr@wunner.de \
    --to=lukas@wunner.de \
    --cc=andy@infradead.org \
    --cc=ddadap@nvidia.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dvhart@infradead.org \
    --cc=peter@lekensteyn.nl \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=pobrn@protonmail.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.