From: David Laight <David.Laight@ACULAB.COM>
To: 'Hans de Goede' <hdegoede@redhat.com>,
Orlando Chamberlain <orlandoch.dev@gmail.com>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com>,
"Lijo Lazar" <lijo.lazar@amd.com>,
"Rander Wang" <rander.wang@intel.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
"Evan Quan" <evan.quan@amd.com>,
"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
"Yong Zhi" <yong.zhi@intel.com>,
"Aun-Ali Zaidi" <admin@kodeit.net>,
"Andrey Grodzovsky" <andrey.grodzovsky@amd.com>,
"Bokun Zhang" <Bokun.Zhang@amd.com>,
"Mark Gross" <markgross@kernel.org>,
"Kerem Karabay" <kekrby@gmail.com>,
"Jaroslav Kysela" <perex@perex.cz>,
"Jack Xiao" <Jack.Xiao@amd.com>,
"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
"Somalapuram Amaranath" <Amaranath.Somalapuram@amd.com>,
"Takashi Iwai" <tiwai@suse.com>,
"Aditya Garg" <gargaditya08@live.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Hawking Zhang" <Hawking.Zhang@amd.com>
Subject: RE: [RFC PATCH 1/9] apple-gmux: use cpu_to_be32 instead of manual reorder
Date: Fri, 10 Feb 2023 22:52:41 +0000 [thread overview]
Message-ID: <6d733fa367e24462bf679b59e790ba4b@AcuMS.aculab.com> (raw)
In-Reply-To: <990b254c-b55f-539d-d6b5-fa4499078527@redhat.com>
From: Hans de Goede
> Sent: 10 February 2023 19:33
>
> Hi,
>
> On 2/10/23 20:09, Hans de Goede wrote:
> > Hi,
> >
> > On 2/10/23 05:48, Orlando Chamberlain wrote:
> >> Currently it manually flips the byte order, but we can instead use
> >> cpu_to_be32(val) for this.
> >>
> >> Signed-off-by: Orlando Chamberlain <orlandoch.dev@gmail.com>
> >> ---
> >> drivers/platform/x86/apple-gmux.c | 18 ++----------------
> >> 1 file changed, 2 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
> >> index 9333f82cfa8a..e8cb084cb81f 100644
> >> --- a/drivers/platform/x86/apple-gmux.c
> >> +++ b/drivers/platform/x86/apple-gmux.c
> >> @@ -94,13 +94,7 @@ static u32 gmux_pio_read32(struct apple_gmux_data *gmux_data, int port)
> >> static void gmux_pio_write32(struct apple_gmux_data *gmux_data, int port,
> >> u32 val)
> >> {
> >> - int i;
> >> - u8 tmpval;
> >> -
> >> - for (i = 0; i < 4; i++) {
> >> - tmpval = (val >> (i * 8)) & 0xff;
> >> - outb(tmpval, gmux_data->iostart + port + i);
> >> - }
> >> + outl(cpu_to_be32(val), gmux_data->iostart + port);
> >> }
> >>
> >> static int gmux_index_wait_ready(struct apple_gmux_data *gmux_data)
> >
> > The ioport / indexed-ioport accessed apple_gmux-es likely are (part of?)
> > LPC bus devices . Looking at the bus level you are now changing 4 io
> > accesses with a size of 1 byte, to 1 32 bit io-access.
>
> Correction to myself, re-reading the LPC specification, then
> if I'm right and this is a LPC device then all IO in/out accesses
> are always 1 byte accesses. Since the LPC bus only supports 16 / 32
> bit accesses for DMA cycles.
>
> So presumably the outl() would get split into 4 separate 8 bit
> (port) IO accesses.
I wonder if there is something obscure and the order of the
4 bytes writes matters?
In any case writing as:
xxxx iostart = gmux_data->iostart + port;
outb(val, iostart);
outb(val >> 8, iostart + 1);
outb(val >> 16, iostart + 2);
outb(val >> 24, ioctart + 3);
almost certainly generates better code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Hans de Goede' <hdegoede@redhat.com>,
Orlando Chamberlain <orlandoch.dev@gmail.com>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Mark Gross" <markgross@kernel.org>,
"Takashi Iwai" <tiwai@suse.com>,
"Hawking Zhang" <Hawking.Zhang@amd.com>,
"Andrey Grodzovsky" <andrey.grodzovsky@amd.com>,
"Lijo Lazar" <lijo.lazar@amd.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Somalapuram Amaranath" <Amaranath.Somalapuram@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Bokun Zhang" <Bokun.Zhang@amd.com>,
"Jack Xiao" <Jack.Xiao@amd.com>,
"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
"Rander Wang" <rander.wang@intel.com>,
"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"Yong Zhi" <yong.zhi@intel.com>, "Evan Quan" <evan.quan@amd.com>,
"Kerem Karabay" <kekrby@gmail.com>,
"Aditya Garg" <gargaditya08@live.com>,
"Aun-Ali Zaidi" <admin@kodeit.net>
Subject: RE: [RFC PATCH 1/9] apple-gmux: use cpu_to_be32 instead of manual reorder
Date: Fri, 10 Feb 2023 22:52:41 +0000 [thread overview]
Message-ID: <6d733fa367e24462bf679b59e790ba4b@AcuMS.aculab.com> (raw)
In-Reply-To: <990b254c-b55f-539d-d6b5-fa4499078527@redhat.com>
From: Hans de Goede
> Sent: 10 February 2023 19:33
>
> Hi,
>
> On 2/10/23 20:09, Hans de Goede wrote:
> > Hi,
> >
> > On 2/10/23 05:48, Orlando Chamberlain wrote:
> >> Currently it manually flips the byte order, but we can instead use
> >> cpu_to_be32(val) for this.
> >>
> >> Signed-off-by: Orlando Chamberlain <orlandoch.dev@gmail.com>
> >> ---
> >> drivers/platform/x86/apple-gmux.c | 18 ++----------------
> >> 1 file changed, 2 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
> >> index 9333f82cfa8a..e8cb084cb81f 100644
> >> --- a/drivers/platform/x86/apple-gmux.c
> >> +++ b/drivers/platform/x86/apple-gmux.c
> >> @@ -94,13 +94,7 @@ static u32 gmux_pio_read32(struct apple_gmux_data *gmux_data, int port)
> >> static void gmux_pio_write32(struct apple_gmux_data *gmux_data, int port,
> >> u32 val)
> >> {
> >> - int i;
> >> - u8 tmpval;
> >> -
> >> - for (i = 0; i < 4; i++) {
> >> - tmpval = (val >> (i * 8)) & 0xff;
> >> - outb(tmpval, gmux_data->iostart + port + i);
> >> - }
> >> + outl(cpu_to_be32(val), gmux_data->iostart + port);
> >> }
> >>
> >> static int gmux_index_wait_ready(struct apple_gmux_data *gmux_data)
> >
> > The ioport / indexed-ioport accessed apple_gmux-es likely are (part of?)
> > LPC bus devices . Looking at the bus level you are now changing 4 io
> > accesses with a size of 1 byte, to 1 32 bit io-access.
>
> Correction to myself, re-reading the LPC specification, then
> if I'm right and this is a LPC device then all IO in/out accesses
> are always 1 byte accesses. Since the LPC bus only supports 16 / 32
> bit accesses for DMA cycles.
>
> So presumably the outl() would get split into 4 separate 8 bit
> (port) IO accesses.
I wonder if there is something obscure and the order of the
4 bytes writes matters?
In any case writing as:
xxxx iostart = gmux_data->iostart + port;
outb(val, iostart);
outb(val >> 8, iostart + 1);
outb(val >> 16, iostart + 2);
outb(val >> 24, ioctart + 3);
almost certainly generates better code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Hans de Goede' <hdegoede@redhat.com>,
Orlando Chamberlain <orlandoch.dev@gmail.com>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Mark Gross" <markgross@kernel.org>,
"Jaroslav Kysela" <perex@perex.cz>,
"Takashi Iwai" <tiwai@suse.com>,
"Hawking Zhang" <Hawking.Zhang@amd.com>,
"Andrey Grodzovsky" <andrey.grodzovsky@amd.com>,
"Lijo Lazar" <lijo.lazar@amd.com>,
"YiPeng Chai" <YiPeng.Chai@amd.com>,
"Somalapuram Amaranath" <Amaranath.Somalapuram@amd.com>,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Bokun Zhang" <Bokun.Zhang@amd.com>,
"Jack Xiao" <Jack.Xiao@amd.com>,
"Kai Vehmanen" <kai.vehmanen@linux.intel.com>,
"Pierre-Louis Bossart" <pierre-louis.bossart@linux.intel.com>,
"Rander Wang" <rander.wang@intel.com>,
"Ranjani Sridharan" <ranjani.sridharan@linux.intel.com>,
"Amadeusz Sławiński" <amadeuszx.slawinski@linux.intel.com>,
"Yong Zhi" <yong.zhi@intel.com>, "Evan Quan" <evan.quan@amd.com>,
"Kerem Karabay" <kekrby@gmail.com>,
"Aditya Garg" <gargaditya08@live.com>,
"Aun-Ali Zaidi" <admin@kodeit.net>
Subject: RE: [RFC PATCH 1/9] apple-gmux: use cpu_to_be32 instead of manual reorder
Date: Fri, 10 Feb 2023 22:52:41 +0000 [thread overview]
Message-ID: <6d733fa367e24462bf679b59e790ba4b@AcuMS.aculab.com> (raw)
In-Reply-To: <990b254c-b55f-539d-d6b5-fa4499078527@redhat.com>
From: Hans de Goede
> Sent: 10 February 2023 19:33
>
> Hi,
>
> On 2/10/23 20:09, Hans de Goede wrote:
> > Hi,
> >
> > On 2/10/23 05:48, Orlando Chamberlain wrote:
> >> Currently it manually flips the byte order, but we can instead use
> >> cpu_to_be32(val) for this.
> >>
> >> Signed-off-by: Orlando Chamberlain <orlandoch.dev@gmail.com>
> >> ---
> >> drivers/platform/x86/apple-gmux.c | 18 ++----------------
> >> 1 file changed, 2 insertions(+), 16 deletions(-)
> >>
> >> diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
> >> index 9333f82cfa8a..e8cb084cb81f 100644
> >> --- a/drivers/platform/x86/apple-gmux.c
> >> +++ b/drivers/platform/x86/apple-gmux.c
> >> @@ -94,13 +94,7 @@ static u32 gmux_pio_read32(struct apple_gmux_data *gmux_data, int port)
> >> static void gmux_pio_write32(struct apple_gmux_data *gmux_data, int port,
> >> u32 val)
> >> {
> >> - int i;
> >> - u8 tmpval;
> >> -
> >> - for (i = 0; i < 4; i++) {
> >> - tmpval = (val >> (i * 8)) & 0xff;
> >> - outb(tmpval, gmux_data->iostart + port + i);
> >> - }
> >> + outl(cpu_to_be32(val), gmux_data->iostart + port);
> >> }
> >>
> >> static int gmux_index_wait_ready(struct apple_gmux_data *gmux_data)
> >
> > The ioport / indexed-ioport accessed apple_gmux-es likely are (part of?)
> > LPC bus devices . Looking at the bus level you are now changing 4 io
> > accesses with a size of 1 byte, to 1 32 bit io-access.
>
> Correction to myself, re-reading the LPC specification, then
> if I'm right and this is a LPC device then all IO in/out accesses
> are always 1 byte accesses. Since the LPC bus only supports 16 / 32
> bit accesses for DMA cycles.
>
> So presumably the outl() would get split into 4 separate 8 bit
> (port) IO accesses.
I wonder if there is something obscure and the order of the
4 bytes writes matters?
In any case writing as:
xxxx iostart = gmux_data->iostart + port;
outb(val, iostart);
outb(val >> 8, iostart + 1);
outb(val >> 16, iostart + 2);
outb(val >> 24, ioctart + 3);
almost certainly generates better code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2023-02-11 6:35 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-10 4:48 [RFC PATCH 0/9] apple-gmux: support MMIO gmux type on T2 Macs Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 1/9] apple-gmux: use cpu_to_be32 instead of manual reorder Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 19:09 ` Hans de Goede
2023-02-10 19:09 ` Hans de Goede
2023-02-10 19:09 ` Hans de Goede
2023-02-10 19:19 ` Hans de Goede
2023-02-10 19:19 ` Hans de Goede
2023-02-10 19:19 ` Hans de Goede
2023-02-10 23:30 ` Orlando Chamberlain
2023-02-10 23:30 ` Orlando Chamberlain
2023-02-10 23:30 ` Orlando Chamberlain
2023-02-11 11:27 ` Hans de Goede
2023-02-11 11:27 ` Hans de Goede
2023-02-11 11:27 ` Hans de Goede
2023-02-10 19:33 ` Hans de Goede
2023-02-10 19:33 ` Hans de Goede
2023-02-10 19:33 ` Hans de Goede
2023-02-10 22:52 ` David Laight [this message]
2023-02-10 22:52 ` David Laight
2023-02-10 22:52 ` David Laight
2023-02-10 4:48 ` [RFC PATCH 2/9] apple-gmux: consolidate version reading Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 19:41 ` Hans de Goede
2023-02-10 19:41 ` Hans de Goede
2023-02-10 19:41 ` Hans de Goede
2023-02-10 23:36 ` Orlando Chamberlain
2023-02-10 23:36 ` Orlando Chamberlain
2023-02-10 23:36 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 3/9] apple-gmux: use first bit to check switch state Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 4/9] apple-gmux: refactor gmux types Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 5/9] apple-gmux: Use GMSP acpi method for interrupt clear Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 19:43 ` Hans de Goede
2023-02-10 19:43 ` Hans de Goede
2023-02-10 19:43 ` Hans de Goede
2023-02-10 23:40 ` Orlando Chamberlain
2023-02-10 23:40 ` Orlando Chamberlain
2023-02-10 23:40 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 6/9] apple-gmux: support MMIO gmux on T2 Macs Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 7/9] apple-gmux: add sysfs interface Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 20:15 ` Hans de Goede
2023-02-10 20:15 ` Hans de Goede
2023-02-10 20:15 ` Hans de Goede
2023-02-10 20:23 ` Hans de Goede
2023-02-10 20:23 ` Hans de Goede
2023-02-10 20:23 ` Hans de Goede
2023-02-10 23:44 ` Orlando Chamberlain
2023-02-10 23:44 ` Orlando Chamberlain
2023-02-10 23:44 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 8/9] hda/hdmi: Register with vga_switcheroo on Dual GPU Macbooks Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` [RFC PATCH 9/9] drm/amdgpu: register a vga_switcheroo client for all GPUs that are not thunderbolt attached Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 4:48 ` Orlando Chamberlain
2023-02-10 15:53 ` Alex Deucher
2023-02-10 15:53 ` Alex Deucher
2023-02-10 15:53 ` Alex Deucher
2023-02-10 16:07 ` Hans de Goede
2023-02-10 16:07 ` Hans de Goede
2023-02-10 16:07 ` Hans de Goede
2023-02-10 16:37 ` Alex Deucher
2023-02-10 16:37 ` Alex Deucher
2023-02-10 16:37 ` Alex Deucher
2023-02-10 23:54 ` Orlando Chamberlain
2023-02-10 23:54 ` Orlando Chamberlain
2023-02-10 23:54 ` Orlando Chamberlain
2023-02-10 16:30 ` [RFC PATCH 0/9] apple-gmux: support MMIO gmux type on T2 Macs Alex Deucher
2023-02-10 16:30 ` Alex Deucher
2023-02-10 16:30 ` Alex Deucher
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=6d733fa367e24462bf679b59e790ba4b@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=Amaranath.Somalapuram@amd.com \
--cc=Bokun.Zhang@amd.com \
--cc=Hawking.Zhang@amd.com \
--cc=Jack.Xiao@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=YiPeng.Chai@amd.com \
--cc=admin@kodeit.net \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrey.grodzovsky@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=evan.quan@amd.com \
--cc=gargaditya08@live.com \
--cc=hdegoede@redhat.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=kekrby@gmail.com \
--cc=lijo.lazar@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=markgross@kernel.org \
--cc=orlandoch.dev@gmail.com \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=rander.wang@intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=tiwai@suse.com \
--cc=yong.zhi@intel.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.