From: Easwar Hariharan <eahariha@linux.microsoft.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
Patrik Jakobsson <patrik.r.jakobsson@gmail.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Zhenyu Wang <zhenyuw@linux.intel.com>,
Zhi Wang <zhi.wang.linux@gmail.com>,
dri-devel@lists.freedesktop.org,
open list <linux-kernel@vger.kernel.org>,
"open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
<intel-gfx@lists.freedesktop.org>,
"open list:INTEL DRM DISPLAY FOR XE AND I915 DRIVERS"
<intel-xe@lists.freedesktop.org>,
"open list:INTEL GVT-g DRIVERS (Intel GPU Virtualization)"
<intel-gvt-dev@lists.freedesktop.org>
Cc: Wolfram Sang <wsa+renesas@sang-engineering.com>,
"open list:RADEON and AMDGPU DRM DRIVERS"
<amd-gfx@lists.freedesktop.org>,
"open list:DRM DRIVER FOR NVIDIA GEFORCE/QUADRO GPUS"
<nouveau@lists.freedesktop.org>,
"open list:I2C SUBSYSTEM HOST DRIVERS"
<linux-i2c@vger.kernel.org>,
"open list:BTTV VIDEO4LINUX DRIVER" <linux-media@vger.kernel.org>,
"open list:FRAMEBUFFER LAYER" <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH v0 03/14] drm/gma500,drm/i915: Make I2C terminology more inclusive
Date: Tue, 2 Apr 2024 11:19:03 -0700 [thread overview]
Message-ID: <75428d6c-c40a-43d8-84e3-f9ed161c37e2@linux.microsoft.com> (raw)
In-Reply-To: <87o7aremfz.fsf@intel.com>
On 4/2/2024 9:52 AM, Jani Nikula wrote:
> On Tue, 02 Apr 2024, Easwar Hariharan <eahariha@linux.microsoft.com> wrote:
>> On 4/2/2024 7:32 AM, Jani Nikula wrote:
>>> On Tue, 02 Apr 2024, Easwar Hariharan <eahariha@linux.microsoft.com> wrote:
>>>> On 4/2/2024 12:48 AM, Jani Nikula wrote:
>>>>> On Fri, 29 Mar 2024, Easwar Hariharan <eahariha@linux.microsoft.com> wrote:
>>>>>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>>>>>> with more appropriate terms. Inspired by and following on to Wolfram's
>>>>>> series to fix drivers/i2c/[1], fix the terminology for users of
>>>>>> I2C_ALGOBIT bitbanging interface, now that the approved verbiage exists
>>>>>> in the specification.
>>>>>
>>>>> gma500 and i915 changes should be split. See MAINTAINERS.
>>>>>
>>>>> Might also split the i915 changes to smaller pieces, it's kind of
>>>>> random. And the changes here are not strictly related to I2C AFAICT, so
>>>>> the commit message should be updated.
>>>>>
>>>>> BR,
>>>>> Jani.
>>>>>
>>>>>
>>>>
>>>> <snip>
>>>>
>>>> I will split gma500 and i915 into their respective patches if possible in v2.
>>>>
>>>> Can you say more about the changes being "not strictly related to I2C"? My
>>>> heuristic was to grep for master/slave, and look in the surrounding context for
>>>> i2c-related terminology (i2c_pin, 7-bit address, struct i2c_adapter, i2c_bus, etc)
>>>> to confirm that they are i2c-related, then following the references around to
>>>> make the compiler happy. For e.g., I did not change the many references to bigjoiner
>>>> master and slave because I understood from context they were not i2c references.
>>>>
>>>> A couple examples would help me restrict the changes to I2C, since as mentioned in the
>>>> discussion on Wolfram's thread, there are places where migrating away from master/slave
>>>> terms in the code would conflict with the original technical manuals and reduce correlation
>>>> and understanding of the code.
>>>
>>> I guess I was looking at the VBT changes in intel_bios.c. Granted, they
>>> do end up being used as i2c addresses. No big deal.
>>>
>>> I think I'd expect the treewide i2c adapter changes to land first, via
>>> i2c, and subsequent cleanups to happen next, via individual driver
>>> trees. There's quite a bit of conflict potential merging this outside of
>>> drm-intel-next, and there's really no need for that.
>>>
>>> BR,
>>> Jani.
>>>
>>
>> Great! Just so I'm clear, do you still want the i915 changes split up more, along with them being
>> split off from gma500?
>
> If we can merge the i915 changes via drm-intel-next, it's probably fine
> as a big i915 patch. Just the gma500 separated. (The struct
> i2c_algorithm change etc. necessarily has to go via I2C tree of course.)
>
> BR,
> Jani.
>
Got it. I'll send the split out in v1 (not v2 as mentioned earlier) since this is v0.
Thanks,
Easwar
next prev parent reply other threads:[~2024-04-02 18:19 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-29 17:00 [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 01/14] IB/hfi1, IB/qib: Make I2C terminology more inclusive Easwar Hariharan
2024-04-03 8:30 ` Leon Romanovsky
2024-04-03 15:54 ` Dennis Dalessandro
2024-04-03 16:44 ` Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 02/14] drm/amdgpu, drm/radeon: " Easwar Hariharan
2024-03-29 17:16 ` [PATCH v0 02/14] drm/amdgpu,drm/radeon: " Andi Shyti
2024-03-29 17:28 ` [PATCH v0 02/14] drm/amdgpu, drm/radeon: " Easwar Hariharan
2024-03-29 17:38 ` [PATCH v0 02/14] drm/amdgpu,drm/radeon: " Andi Shyti
2024-03-29 18:51 ` [PATCH v0 02/14] drm/amdgpu, drm/radeon: " Easwar Hariharan
2024-04-03 12:36 ` [PATCH v0 02/14] drm/amdgpu,drm/radeon: " Ville Syrjälä
2024-04-03 13:12 ` Jani Nikula
2024-04-03 14:26 ` [PATCH v0 02/14] drm/amdgpu, drm/radeon: " Christian König
2024-04-03 16:43 ` Easwar Hariharan
2024-04-03 16:42 ` Easwar Hariharan
2024-03-29 17:38 ` Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 03/14] drm/gma500, drm/i915: " Easwar Hariharan
2024-04-02 7:48 ` [PATCH v0 03/14] drm/gma500,drm/i915: " Jani Nikula
2024-04-02 11:59 ` Easwar Hariharan
2024-04-02 14:32 ` Jani Nikula
2024-04-02 16:20 ` Easwar Hariharan
2024-04-02 16:52 ` Jani Nikula
2024-04-02 18:19 ` Easwar Hariharan [this message]
2024-03-29 17:00 ` [PATCH v0 04/14] media: au0828: " Easwar Hariharan
2024-05-03 19:03 ` Mauro Carvalho Chehab
2024-03-29 17:00 ` [PATCH v0 05/14] media: cobalt: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 06/14] media: cx18: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 07/14] media: cx25821: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 08/14] media: ivtv: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 09/14] media: cx23885: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 10/14] sfc: falcon: " Easwar Hariharan
2024-04-02 8:29 ` Simon Horman
2024-04-04 19:17 ` Easwar Hariharan
2024-04-07 8:49 ` Simon Horman
2024-04-02 9:00 ` Martin Habets
2024-04-04 19:18 ` Easwar Hariharan
2024-04-08 8:35 ` Martin Habets
2024-03-29 17:00 ` [PATCH v0 11/14] fbdev/smscufx: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 12/14] fbdev/viafb: " Easwar Hariharan
2024-03-29 17:00 ` [PATCH v0 13/14] drm/nouveau: " Easwar Hariharan
2024-04-05 16:15 ` Danilo Krummrich
2024-04-05 16:30 ` Easwar Hariharan
2024-04-05 18:36 ` Lyude Paul
2024-03-29 17:00 ` [PATCH v0 14/14] i2c and treewide: " Easwar Hariharan
2024-04-05 10:18 ` [PATCH v0 00/14] Make I2C terminology more inclusive for I2C Algobit and consumers Wolfram Sang
2024-04-05 17:09 ` Easwar Hariharan
2024-04-07 17:50 ` Wolfram Sang
2024-04-08 7:48 ` Hans Verkuil
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=75428d6c-c40a-43d8-84e3-f9ed161c37e2@linux.microsoft.com \
--to=eahariha@linux.microsoft.com \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-gvt-dev@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=patrik.r.jakobsson@gmail.com \
--cc=rodrigo.vivi@intel.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--cc=wsa+renesas@sang-engineering.com \
--cc=zhenyuw@linux.intel.com \
--cc=zhi.wang.linux@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).