Re: [PATCH 08/11] drm/i915: Use drm_fbdev_helper_client_unregister()
On Tue, May 07, 2024 at 01:58:29PM +0200, Thomas Zimmermann wrote:
> Implement struct drm_client_funcs.unregister with the helpers
> drm_fbdev_helper_client_unregister() and remove the custom code
> from the driver. The generic helper is equivalent in functionality.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c | 21 ++---
> 1 file changed, 2 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index bda702c2cab8e..f1b4543bffc02 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -38,7 +38,6 @@
> #include
>
> #include
> -#include
> #include
> #include
> #include
> @@ -580,25 +579,9 @@ static int intel_fbdev_restore_mode(struct
> drm_i915_private *dev_priv)
> }
>
> /*
> - * Fbdev client and struct drm_client_funcs
> + * struct drm_client_funcs
> */
>
> -static void intel_fbdev_client_unregister(struct drm_client_dev *client)
> -{
> - struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
> - struct drm_device *dev = fb_helper->dev;
> - struct pci_dev *pdev = to_pci_dev(dev->dev);
> -
> - if (fb_helper->info) {
> - vga_switcheroo_client_fb_set(pdev, NULL);
> - drm_fb_helper_unregister_info(fb_helper);
> - } else {
> - drm_fb_helper_unprepare(fb_helper);
> - drm_client_release(_helper->client);
The only real difference is that these 2 calls are inverted in the new
drm_fbdev_helper_client_unregister.
I feel that the releasing after the unprepare sounds more logical,
but if there's no actual issue with that and it is working for
everybody, let's do that.
Reviewed-by: Rodrigo Vivi
Acked-by: Rodrigo Vivi
(to get through drm-misc with everything else if you prefer)
> - kfree(fb_helper);
> - }
> -}
> -
> static int intel_fbdev_client_restore(struct drm_client_dev *client)
> {
> struct drm_i915_private *dev_priv = to_i915(client->dev);
> @@ -644,7 +627,7 @@ static int intel_fbdev_client_hotplug(struct
> drm_client_dev *client)
>
> static const struct drm_client_funcs intel_fbdev_client_funcs = {
> .owner = THIS_MODULE,
> - .unregister = intel_fbdev_client_unregister,
> + .unregister = drm_fbdev_helper_client_unregister,
> .restore= intel_fbdev_client_restore,
> .hotplug= intel_fbdev_client_hotplug,
> };
> --
> 2.44.0
>
Re: [PATCH v2 03/12] drm/i915: Make I2C terminology more inclusive
On Fri, May 03, 2024 at 02:04:15PM -0700, Easwar Hariharan wrote: > On 5/3/2024 12:34 PM, Rodrigo Vivi wrote: > > On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote: > >> I2C v7, SMBus 3.2, and I3C 1.1.1 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. > >> > >> Compile tested, no functionality changes intended > >> > >> [1]: > >> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/ > >> > >> Reviewed-by: Rodrigo Vivi > >> Acked-by: Rodrigo Vivi > > > > It looks like the ack is not needed since we are merging this through > > drm-intel-next. But I'm planing to merge this only after seeing the > > main drivers/i2c accepting the new terminology. So we don't have a > > risk of that getting push back and new names there and we having > > to rename it once again. > > Just to be explicit, did you want me to remove the Acked-by in v3, or will > you when you pull > the patch into drm-intel-next? > > > > > (more below) > > > >> Acked-by: Zhi Wang > >> Signed-off-by: Easwar Hariharan > > > > Cc: Jani Nikula > > > > Jani, what bits were you concerned that were not necessarily i2c? > > I believe although not necessarily/directly i2c, I believe they > > are related and could benefit from the massive single shot renable. > > or do you have any better split to suggest here? > > > > (more below) > > > >> --- > >> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 - > >> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +- > >> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +-- > >> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +-- > >> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++--- > >> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > >> .../gpu/drm/i915/display/intel_display_core.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++--- > >> drivers/gpu/drm/i915/display/intel_dvo.c | 14 - > >> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +- > >> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +-- > >> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +-- > >> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +-- > >> drivers/gpu/drm/i915/gvt/edid.c | 28 - > >> drivers/gpu/drm/i915/gvt/edid.h | 4 +-- > >> drivers/gpu/drm/i915/gvt/opregion.c | 2 +- > >> 19 files changed, 119 insertions(+), 119 deletions(-) > >> > > > > >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c > >> b/drivers/gpu/drm/i915/display/intel_ddi.c > >> index c17462b4c2ac..64db211148a8 100644 > >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c > >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c > >> @@ -4332,7 +4332,7 @@ static int intel_ddi_compute_config_late(struct > >> intel_encoder *encoder, > >> > >> connector->tile_group->id); > >> > >>/* > >> - * EDP Transcoders cannot be ensalved > >> + * EDP Transcoders cannot be slaves > > > > ^ here > > perhaps you meant 'targeted' ? > > > >> * make them a master always when present > > > > This is not actually I2C related as far as I could tell when I was making the > change, so this was more of a typo fix. > > If we want to improve this, a quick check with the eDP v1.5a spec suggests > using primary/secondary instead, > though in a global fashion rather than specifically for eDP transcoders. > There is also source/sink terminology > in the spec related to DP encoders. > > Which would be a more acceptable change here? hmmm probably better to split the patches and align with the spec naming where it applies. and with i2c name where it applies. > > Thanks, > Easwar
Re: [PATCH v2 03/12] drm/i915: Make I2C terminology more inclusive
On Fri, May 03, 2024 at 06:13:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 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.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Reviewed-by: Rodrigo Vivi
> Acked-by: Rodrigo Vivi
It looks like the ack is not needed since we are merging this through
drm-intel-next. But I'm planing to merge this only after seeing the
main drivers/i2c accepting the new terminology. So we don't have a
risk of that getting push back and new names there and we having
to rename it once again.
(more below)
> Acked-by: Zhi Wang
> Signed-off-by: Easwar Hariharan
Cc: Jani Nikula
Jani, what bits were you concerned that were not necessarily i2c?
I believe although not necessarily/directly i2c, I believe they
are related and could benefit from the massive single shot renable.
or do you have any better split to suggest here?
(more below)
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
> drivers/gpu/drm/i915/gvt/edid.c | 28 -
> drivers/gpu/drm/i915/gvt/edid.h | 4 +--
> drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> 19 files changed, 119 insertions(+), 119 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index d0c3880d7f80..493e730c685b 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo,
> u8 addr, u8 *val)
> {
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = ,
> },
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = val,
> @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> {
> u8 buf[2] = { addr, val };
> struct i2c_msg msg = {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 2,
> .buf = buf,
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> return i2c_transfer(dvo->i2c_bus, , 1) == 1;
> }
>
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/** Probes for a CH7017 on the given bus and target address. */
> static bool ch7017_init(struct intel_dvo_device *dvo,
> struct i2c_adapter *adapter)
> {
> @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
> break;
> default:
> DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
> - "slave %d.\n",
> - val, adapter->name, dvo->slave_addr);
> + "target %d.\n",
> + val, adapter->name, dvo->target_addr);
> goto fail;
> }
>
> DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
> - str, a
Re: [PATCH v1 03/12] drm/i915: Make I2C terminology more inclusive
On Tue, Apr 30, 2024 at 05:38:02PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C 1.1.1 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.
>
> Compile tested, no functionality changes intended
>
> [1]:
> https://lore.kernel.org/all/20240322132619.6389-1-wsa+rene...@sang-engineering.com/
>
> Signed-off-by: Easwar Hariharan
I'm glad to see this change!
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/dvo_ch7017.c | 14 -
> drivers/gpu/drm/i915/display/dvo_ch7xxx.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_ivch.c | 16 +-
> drivers/gpu/drm/i915/display/dvo_ns2501.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_sil164.c | 18 +--
> drivers/gpu/drm/i915/display/dvo_tfp410.c | 18 +--
> drivers/gpu/drm/i915/display/intel_bios.c | 22 +++---
> drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> .../gpu/drm/i915/display/intel_display_core.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 20 ++---
> drivers/gpu/drm/i915/display/intel_dvo.c | 14 -
> drivers/gpu/drm/i915/display/intel_dvo_dev.h | 2 +-
> drivers/gpu/drm/i915/display/intel_gmbus.c| 4 +--
> drivers/gpu/drm/i915/display/intel_sdvo.c | 30 +--
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 4 +--
> drivers/gpu/drm/i915/gvt/edid.c | 28 -
> drivers/gpu/drm/i915/gvt/edid.h | 4 +--
> drivers/gpu/drm/i915/gvt/opregion.c | 2 +-
> 19 files changed, 119 insertions(+), 119 deletions(-)
The chances of conflicts are high with this many changes,
but should be easy enough to deal with later, so feel free
to move with this i915 patch on any other tree and we catch-up
later.
Acked-by: Rodrigo Vivi
>
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> index d0c3880d7f80..493e730c685b 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/display/dvo_ch7017.c
> @@ -170,13 +170,13 @@ static bool ch7017_read(struct intel_dvo_device *dvo,
> u8 addr, u8 *val)
> {
> struct i2c_msg msgs[] = {
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 1,
> .buf = ,
> },
> {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = I2C_M_RD,
> .len = 1,
> .buf = val,
> @@ -189,7 +189,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> {
> u8 buf[2] = { addr, val };
> struct i2c_msg msg = {
> - .addr = dvo->slave_addr,
> + .addr = dvo->target_addr,
> .flags = 0,
> .len = 2,
> .buf = buf,
> @@ -197,7 +197,7 @@ static bool ch7017_write(struct intel_dvo_device *dvo, u8
> addr, u8 val)
> return i2c_transfer(dvo->i2c_bus, , 1) == 1;
> }
>
> -/** Probes for a CH7017 on the given bus and slave address. */
> +/** Probes for a CH7017 on the given bus and target address. */
> static bool ch7017_init(struct intel_dvo_device *dvo,
> struct i2c_adapter *adapter)
> {
> @@ -227,13 +227,13 @@ static bool ch7017_init(struct intel_dvo_device *dvo,
> break;
> default:
> DRM_DEBUG_KMS("ch701x not detected, got %d: from %s "
> - "slave %d.\n",
> - val, adapter->name, dvo->slave_addr);
> + "target %d.\n",
> + val, adapter->name, dvo->target_addr);
> goto fail;
> }
>
> DRM_DEBUG_KMS("%s detected on %s, addr %d\n",
> - str, adapter->name, dvo->slave_addr);
> + str, adapter->name, dvo->target_addr);
> return true;
>
> fail:
> diff --git a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> b/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> index 2e8e85da5a40..534b8544e0a4 100644
> --- a/drivers/gpu/drm/i915/display/dvo_ch7xxx.c
> +++ b/drivers/gpu/drm/
Re: [PATCH v2 3/6] drm_dbg: add trailing newlines to msgs
On Mon, Sep 04, 2023 at 08:32:40AM +0200, Andi Shyti wrote:
> Hi Jim,
>
> On Sun, Sep 03, 2023 at 12:46:00PM -0600, Jim Cromie wrote:
> > By at least strong convention, a print-buffer's trailing newline says
> > "message complete, send it". The exception (no TNL, followed by a call
> > to pr_cont) proves the general rule.
> >
> > Most DRM.debug calls already comport with this: 207 DRM_DEV_DEBUG,
> > 1288 drm_dbg. Clean up the remainders, in maintainer sized chunks.
> >
> > No functional changes.
> >
> > Signed-off-by: Jim Cromie
>
> Reviewed-by: Andi Shyti
I pushed this i915 one to our drm-intel-next.
While doing it I have changed the subject to make it clear
this is 'drm/i915:'.
I believe you should do similar change to all the other patches
to make it clear in the subject about which domain that commit
is touching... instead of only 'drm_dbg'.
i.e.: 183670347b06 ("drm/i915: add trailing newlines to msgs")
https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next=183670347b060521920a81f84ff7f10e227ebe05
Thanks for the patch,
Rodrigo.
>
> Andi
Re: [PATCH v7] drm/doc: Document DRM device reset expectations
On Fri, Aug 18, 2023 at 05:06:42PM -0300, André Almeida wrote: > Create a section that specifies how to deal with DRM device resets for > kernel and userspace drivers. > > Signed-off-by: André Almeida > > --- > > v7 changes: > - s/application/graphical API contex/ in the robustness part (Michel) > - Grammar fixes (Randy) > > v6: > https://lore.kernel.org/lkml/20230815185710.159779-1-andrealm...@igalia.com/ > > v6 changes: > - Due to substantial changes in the content, dropped Pekka's Acked-by > - Grammar fixes (Randy) > - Add paragraph about disabling device resets > - Add note about integrating reset tracking in drm/sched > - Add note that KMD should return failure for contexts affected by >resets and UMD should check for this > - Add note about lack of consensus around what to do about non-robust >apps > > v5: > https://lore.kernel.org/dri-devel/20230627132323.115440-1-andrealm...@igalia.com/ > --- > Documentation/gpu/drm-uapi.rst | 77 ++ > 1 file changed, 77 insertions(+) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 65fb3036a580..3694bdb977f5 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -285,6 +285,83 @@ for GPU1 and GPU2 from different vendors, and a third > handler for > mmapped regular files. Threads cause additional pain with signal > handling as well. > > +Device reset > + > + > +The GPU stack is really complex and is prone to errors, from hardware bugs, > +faulty applications and everything in between the many layers. Some errors > +require resetting the device in order to make the device usable again. This > +section describes the expectations for DRM and usermode drivers when a > +device resets and how to propagate the reset status. > + > +Device resets can not be disabled without tainting the kernel, which can > lead to > +hanging the entire kernel through shrinkers/mmu_notifiers. Userspace role in > +device resets is to propagate the message to the application and apply any > +special policy for blocking guilty applications, if any. Corollary is that > +debugging a hung GPU context require hardware support to be able to preempt > such > +a GPU context while it's stopped. > + > +Kernel Mode Driver > +-- > + > +The KMD is responsible for checking if the device needs a reset, and to > perform > +it as needed. Usually a hang is detected when a job gets stuck executing. KMD > +should keep track of resets, because userspace can query any time about the > +reset status for a specific context. This is needed to propagate to the rest > of > +the stack that a reset has happened. Currently, this is implemented by each > +driver separately, with no common DRM interface. Ideally this should be > properly > +integrated at DRM scheduler to provide a common ground for all drivers. > After a > +reset, KMD should reject new command submissions for affected contexts. is there any consensus around what exactly 'affected contexts' might mean? I see i915 pin-point only the context that was at execution with head pointing at it and doesn't blame the queued ones, while on Xe it looks like we are blaming all the queued context. Not sure what other drivers are doing for the 'affected contexts'. > + > +User Mode Driver > + > + > +After command submission, UMD should check if the submission was accepted or > +rejected. After a reset, KMD should reject submissions, and UMD can issue an > +ioctl to the KMD to check the reset status, and this can be checked more > often > +if the UMD requires it. After detecting a reset, UMD will then proceed to > report > +it to the application using the appropriate API error code, as explained in > the > +section below about robustness. > + > +Robustness > +-- > + > +The only way to try to keep a graphical API context working after a reset is > if > +it complies with the robustness aspects of the graphical API that it is > using. > + > +Graphical APIs provide ways to applications to deal with device resets. > However, > +there is no guarantee that the app will use such features correctly, and a > +userspace that doesn't support robust interfaces (like a non-robust > +OpenGL context or API without any robustness support like libva) leave the > +robustness handling entirely to the userspace driver. There is no strong > +community consensus on what the userspace driver should do in that case, > +since all reasonable approaches have some clear downsides. > + > +OpenGL > +~~ > + > +Apps using OpenGL should use the available robust interfaces, like the > +extension ``GL_ARB_robustness`` (or ``GL_EXT_robustness`` for OpenGL ES). > This > +interface tells if a reset has happened, and if so, all the context state is > +considered lost and the app proceeds by creating new ones. There's no > consensus > +on what to do to if robustness is not in use. > + > +Vulkan > +~~ > +
Re: [PATCH v2] drm: Spelling s/sempahore/semaphore/
On Mon, Jul 17, 2023 at 03:23:20PM +0200, Geert Uytterhoeven wrote: > Fix misspellings of "semaphore". > > Signed-off-by: Geert Uytterhoeven > Reviewed-by: Hamza Mahfooz > --- > v2: > - Add Reviewed-by. > --- > drivers/gpu/drm/i915/i915_request.c | 2 +- > drivers/gpu/drm/radeon/cik.c| 2 +- > drivers/gpu/drm/radeon/r600.c | 2 +- > include/drm/task_barrier.h | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_request.c > b/drivers/gpu/drm/i915/i915_request.c > index 894068bb37b6f1b6..32323bb801a139b7 100644 > --- a/drivers/gpu/drm/i915/i915_request.c > +++ b/drivers/gpu/drm/i915/i915_request.c > @@ -1220,7 +1220,7 @@ emit_semaphore_wait(struct i915_request *to, > /* >* If this or its dependents are waiting on an external fence >* that may fail catastrophically, then we want to avoid using > - * sempahores as they bypass the fence signaling metadata, and we > + * semaphores as they bypass the fence signaling metadata, and we >* lose the fence->error propagation. >*/ > if (from->sched.flags & I915_SCHED_HAS_EXTERNAL_CHAIN) Acked-by: Rodrigo Vivi to take this through drm-misc > diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c > index 5819737c21c678d3..5d6b81a6578ef2ba 100644 > --- a/drivers/gpu/drm/radeon/cik.c > +++ b/drivers/gpu/drm/radeon/cik.c > @@ -3603,7 +3603,7 @@ void cik_fence_compute_ring_emit(struct radeon_device > *rdev, > * @rdev: radeon_device pointer > * @ring: radeon ring buffer object > * @semaphore: radeon semaphore object > - * @emit_wait: Is this a sempahore wait? > + * @emit_wait: Is this a semaphore wait? > * > * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP > * from running ahead of semaphore waits. > diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c > index 382795a8b3c064ba..a17b95eec65fb810 100644 > --- a/drivers/gpu/drm/radeon/r600.c > +++ b/drivers/gpu/drm/radeon/r600.c > @@ -2918,7 +2918,7 @@ void r600_fence_ring_emit(struct radeon_device *rdev, > * @rdev: radeon_device pointer > * @ring: radeon ring buffer object > * @semaphore: radeon semaphore object > - * @emit_wait: Is this a sempahore wait? > + * @emit_wait: Is this a semaphore wait? > * > * Emits a semaphore signal/wait packet to the CP ring and prevents the PFP > * from running ahead of semaphore waits. > diff --git a/include/drm/task_barrier.h b/include/drm/task_barrier.h > index 087e3f649c52f02d..217c1cf21c1ab7d5 100644 > --- a/include/drm/task_barrier.h > +++ b/include/drm/task_barrier.h > @@ -25,7 +25,7 @@ > > /* > * Reusable 2 PHASE task barrier (randevouz point) implementation for N > tasks. > - * Based on the Little book of sempahores - > https://greenteapress.com/wp/semaphores/ > + * Based on the Little book of semaphores - > https://greenteapress.com/wp/semaphores/ > */ > > > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH v2 2/3] drm/fb-helper: Set framebuffer for vga-switcheroo clients
On Thu, Jan 19, 2023 at 09:06:54AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 18.01.23 um 20:21 schrieb Rodrigo Vivi:
> > On Thu, Jan 12, 2023 at 09:11:55PM +0100, Thomas Zimmermann wrote:
> > > Set the framebuffer info for drivers that support VGA switcheroo. Only
> > > affects the amdgpu and nouveau drivers, which use VGA switcheroo and
> > > generic fbdev emulation. For other drivers, this does nothing.
> > >
> > > This fixes a potential regression in the console code. Both, amdgpu and
> > > nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev
> > > code. But the call got lost when the drivers switched to the generic
> > > emulation.
> > >
> > > Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of
> > > setting up AMD own's.")
> > > Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> > > Signed-off-by: Thomas Zimmermann
> > > Reviewed-by: Daniel Vetter
> > > Reviewed-by: Alex Deucher
> > > Cc: Ben Skeggs
> > > Cc: Karol Herbst
> > > Cc: Lyude Paul
> > > Cc: Thomas Zimmermann
> > > Cc: Javier Martinez Canillas
> > > Cc: Laurent Pinchart
> > > Cc: Jani Nikula
> > > Cc: Dave Airlie
> > > Cc: Evan Quan
> > > Cc: Christian König
> > > Cc: Alex Deucher
> > > Cc: Hawking Zhang
> > > Cc: Likun Gao
> > > Cc: "Christian König"
> > > Cc: Stanley Yang
> > > Cc: "Tianci.Yin"
> > > Cc: Xiaojian Du
> > > Cc: Andrey Grodzovsky
> > > Cc: YiPeng Chai
> > > Cc: Somalapuram Amaranath
> > > Cc: Bokun Zhang
> > > Cc: Guchun Chen
> > > Cc: Hamza Mahfooz
> > > Cc: Aurabindo Pillai
> > > Cc: Mario Limonciello
> > > Cc: Solomon Chiu
> > > Cc: Kai-Heng Feng
> > > Cc: Felix Kuehling
> > > Cc: Daniel Vetter
> > > Cc: "Marek Olšák"
> > > Cc: Sam Ravnborg
> > > Cc: Hans de Goede
> > > Cc: "Ville Syrjälä"
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: nouv...@lists.freedesktop.org
> > > Cc: # v5.17+
> > > ---
> > > drivers/gpu/drm/drm_fb_helper.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > > b/drivers/gpu/drm/drm_fb_helper.c
> > > index 427631706128..5e445c61252d 100644
> > > --- a/drivers/gpu/drm/drm_fb_helper.c
> > > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > > @@ -30,7 +30,9 @@
> > > #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > #include
> > > +#include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > @@ -1940,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct
> > > drm_fb_helper *fb_helper,
> > >int preferred_bpp)
> > > {
> > > struct drm_client_dev *client = _helper->client;
> > > + struct drm_device *dev = fb_helper->dev;
> >
> > On drm-tip, this commit has a silent conflict with
> > cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
> > that's already in drm-next.
> >
> > I had created a fix-up patch in drm-tip re-introducing this line.
>
> Thank you. Is it fixed for now?
Fixed in drm-tip, yes. But broke linux-next as well. This
resolution will need to go up with any merge...
>
> >
> > We probably need a backmerge from drm-next into drm-misc-fixes with
> > the resolution applied there. And probably propagated that resolution
> > later...
>
> Backmerging from -next into -fixes branches is a problem, as -fixes should
> be close to the latest release.
doh! Indeed I should've known this by heart... -ENOTEHOUGHCOFFEE
>
> Can we solve this by merging -fixes into upstream and backmerging this into
> our -next branches?
hmmm... probably better just wait and let folks know the resolution
when the patches are moving up...
>
> Best regards
> Thomas
>
> >
> > > struct drm_fb_helper_surface_size sizes;
> > > int ret;
> > > @@ -1961,6 +1964,11 @@ static int drm_fb_helper_single_fb_probe(struct
> > > drm_fb_helper *fb_helper,
> > > return ret;
> > > strcpy(fb_helper->fb->comm, "[fbcon]");
> > > +
> > > + /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
> > > + if (dev_is_pci(dev->dev))
> > > + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev),
> > > fb_helper->info);
> > > +
> > > return 0;
> > > }
> > > --
> > > 2.39.0
> > >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
Re: [Intel-gfx] [PATCH v2 2/3] drm/fb-helper: Set framebuffer for vga-switcheroo clients
On Thu, Jan 12, 2023 at 09:11:55PM +0100, Thomas Zimmermann wrote:
> Set the framebuffer info for drivers that support VGA switcheroo. Only
> affects the amdgpu and nouveau drivers, which use VGA switcheroo and
> generic fbdev emulation. For other drivers, this does nothing.
>
> This fixes a potential regression in the console code. Both, amdgpu and
> nouveau, invoked vga_switcheroo_client_fb_set() from their internal fbdev
> code. But the call got lost when the drivers switched to the generic
> emulation.
>
> Fixes: 087451f372bf ("drm/amdgpu: use generic fb helpers instead of setting
> up AMD own's.")
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
> Reviewed-by: Alex Deucher
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Lyude Paul
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: Laurent Pinchart
> Cc: Jani Nikula
> Cc: Dave Airlie
> Cc: Evan Quan
> Cc: Christian König
> Cc: Alex Deucher
> Cc: Hawking Zhang
> Cc: Likun Gao
> Cc: "Christian König"
> Cc: Stanley Yang
> Cc: "Tianci.Yin"
> Cc: Xiaojian Du
> Cc: Andrey Grodzovsky
> Cc: YiPeng Chai
> Cc: Somalapuram Amaranath
> Cc: Bokun Zhang
> Cc: Guchun Chen
> Cc: Hamza Mahfooz
> Cc: Aurabindo Pillai
> Cc: Mario Limonciello
> Cc: Solomon Chiu
> Cc: Kai-Heng Feng
> Cc: Felix Kuehling
> Cc: Daniel Vetter
> Cc: "Marek Olšák"
> Cc: Sam Ravnborg
> Cc: Hans de Goede
> Cc: "Ville Syrjälä"
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: # v5.17+
> ---
> drivers/gpu/drm/drm_fb_helper.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 427631706128..5e445c61252d 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -30,7 +30,9 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> +#include
> #include
> +#include
>
> #include
> #include
> @@ -1940,6 +1942,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>int preferred_bpp)
> {
> struct drm_client_dev *client = _helper->client;
> + struct drm_device *dev = fb_helper->dev;
On drm-tip, this commit has a silent conflict with
cff84bac9922 ("drm/fh-helper: Split fbdev single-probe helper")
that's already in drm-next.
I had created a fix-up patch in drm-tip re-introducing this line.
We probably need a backmerge from drm-next into drm-misc-fixes with
the resolution applied there. And probably propagated that resolution
later...
> struct drm_fb_helper_surface_size sizes;
> int ret;
>
> @@ -1961,6 +1964,11 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> return ret;
>
> strcpy(fb_helper->fb->comm, "[fbcon]");
> +
> + /* Set the fb info for vgaswitcheroo clients. Does nothing otherwise. */
> + if (dev_is_pci(dev->dev))
> + vga_switcheroo_client_fb_set(to_pci_dev(dev->dev),
> fb_helper->info);
> +
> return 0;
> }
>
> --
> 2.39.0
>
Re: misc vgaarb cleanups
On Fri, Jul 16, 2021 at 08:16:27AM +0200, Christoph Hellwig wrote: > Hi all, > > this series cleans up a bunch of lose ends in the vgaarb code. > > Diffstat: > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +- > drivers/gpu/drm/drm_irq.c |4 > drivers/gpu/drm/i915/display/intel_vga.c |9 +- The parts touching i915 looks clean to me Acked-by: Rodrigo Vivi > drivers/gpu/drm/nouveau/nouveau_vga.c |8 - > drivers/gpu/drm/radeon/radeon_device.c | 11 +- > drivers/gpu/vga/vgaarb.c | 67 +--- > drivers/vfio/pci/vfio_pci.c| 11 +- > include/linux/vgaarb.h | 118 > ++--- > 8 files changed, 93 insertions(+), 146 deletions(-) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [Intel-gfx] [PATCH 19/30] drm/dp: Pass drm_dp_aux to drm_dp_link_train_clock_recovery_delay()
On Fri, Feb 19, 2021 at 04:53:15PM -0500, Lyude Paul wrote:
> So that we can start using drm_dbg_*() in
> drm_dp_link_train_clock_recovery_delay().
>
> Signed-off-by: Lyude Paul
I wonder if we could have a drm_dp so we encapsulate both aux and dpcd
related information...
But this one already solves the issue...
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/amd/amdgpu/atombios_dp.c | 2 +-
> drivers/gpu/drm/drm_dp_helper.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/msm/dp/dp_ctrl.c | 2 +-
> drivers/gpu/drm/msm/edp/edp_ctrl.c| 2 +-
> drivers/gpu/drm/radeon/atombios_dp.c | 2 +-
> drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> include/drm/drm_dp_helper.h | 4 +++-
> 8 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> index 6d35da65e09f..4468f9d6b4dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_dp.c
> @@ -611,7 +611,7 @@ amdgpu_atombios_dp_link_train_cr(struct
> amdgpu_atombios_dp_link_train_info *dp_i
> dp_info->tries = 0;
> voltage = 0xff;
> while (1) {
> - drm_dp_link_train_clock_recovery_delay(dp_info->dpcd);
> + drm_dp_link_train_clock_recovery_delay(dp_info->aux,
> dp_info->dpcd);
>
> if (drm_dp_dpcd_read_link_status(dp_info->aux,
>dp_info->link_status) <= 0) {
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 194e0c273809..ce08eb3bface 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -132,7 +132,8 @@ u8 drm_dp_get_adjust_request_post_cursor(const u8
> link_status[DP_LINK_STATUS_SIZ
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
>
> -void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> +void drm_dp_link_train_clock_recovery_delay(const struct drm_dp_aux *aux,
> + const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
>DP_TRAINING_AUX_RD_MASK;
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> index 892d7db7d94f..222073d46bdb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -441,7 +441,7 @@ static void
> intel_dp_link_training_clock_recovery_delay(struct intel_dp *intel_d
> enum drm_dp_phy dp_phy)
> {
> if (dp_phy == DP_PHY_DPRX)
> - drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> + drm_dp_link_train_clock_recovery_delay(_dp->aux,
> intel_dp->dpcd);
> else
> drm_dp_lttpr_link_train_clock_recovery_delay();
> }
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 36b39c381b3f..2501a6b326a3 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1103,7 +1103,7 @@ static int dp_ctrl_link_train_1(struct dp_ctrl_private
> *ctrl,
> tries = 0;
> old_v_level = ctrl->link->phy_params.v_level;
> for (tries = 0; tries < maximum_retries; tries++) {
> - drm_dp_link_train_clock_recovery_delay(ctrl->panel->dpcd);
> + drm_dp_link_train_clock_recovery_delay(ctrl->aux,
> ctrl->panel->dpcd);
>
> ret = dp_ctrl_read_link_status(ctrl, link_status);
> if (ret)
> diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> index 57af3d8b6699..6501598448b4 100644
> --- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> @@ -608,7 +608,7 @@ static int edp_start_link_train_1(struct edp_ctrl *ctrl)
> tries = 0;
> old_v_level = ctrl->v_level;
> while (1) {
> - drm_dp_link_train_clock_recovery_delay(ctrl->dpcd);
> + drm_dp_link_train_clock_recovery_delay(ctrl->drm_aux,
> ctrl->dpcd);
>
> rlen = drm_dp_dpcd_read_link_status(ctrl->drm_aux, link_status);
> if (rlen < DP_LINK_STATUS_SIZE) {
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index
Re: [Intel-gfx] [PATCH 0/4] managed drm_device, absolute final leftover bits
On Fri, Sep 18, 2020 at 11:03:12AM -0400, Alex Deucher wrote: > On Fri, Sep 18, 2020 at 9:25 AM Daniel Vetter wrote: > > > > Hi all, > > > > These are the leftovers of the leftovers of my initial drmm series to > > manage drm_device. > > > > Changes: > > - bugfixed i915 selftests > > - patch from Luben to finalize the admgpu conversion > > > > Alex & i915 maintainers, pls ack for merging this all through > > drm-misc-next since otherwise the final patch (and the resulting confusion > > with outdated docs) is held up another round. > > Acked-by: Alex Deucher Acked-by: Rodrigo Vivi > > > > > Cheers, Daniel > > > > Daniel Vetter (3): > > drm/i915/selftest: Create mock_destroy_device > > drm/i915/selftests: align more to real device lifetimes > > drm/dev: Remove drm_dev_init > > > > Luben Tuikov (1): > > drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2) > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16 ++ > > drivers/gpu/drm/drm_drv.c | 41 ++-- > > drivers/gpu/drm/drm_internal.h| 1 + > > drivers/gpu/drm/drm_managed.c | 13 - > > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > > .../drm/i915/gem/selftests/i915_gem_context.c | 2 +- > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- > > .../drm/i915/gem/selftests/i915_gem_object.c | 2 +- > > .../drm/i915/gem/selftests/i915_gem_phys.c| 2 +- > > drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- > > .../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +- > > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > > .../drm/i915/selftests/intel_memory_region.c | 2 +- > > .../gpu/drm/i915/selftests/mock_gem_device.c | 49 --- > > .../gpu/drm/i915/selftests/mock_gem_device.h | 2 + > > include/drm/drm_drv.h | 4 -- > > 18 files changed, 51 insertions(+), 97 deletions(-) > > > > -- > > 2.28.0 > > > > ___ > > amd-gfx mailing list > > amd-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH v2 06/34] drm/i915: convert put_page() to put_user_page*()
On Sun, Aug 04, 2019 at 03:48:47PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> This is a merge-able version of the fix, because it restricts
> itself to put_user_page() and put_user_pages(), both of which
> have not changed their APIs. Later, i915_gem_userptr_put_pages()
> can be simplified to use put_user_pages_dirty_lock().
Thanks for that.
with this version we won't have any conflict.
Ack for going through mm tree.
>
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: John Hubbard
> ---
> drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> index 2caa594322bc..76dda2923cf1 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
> @@ -527,7 +527,7 @@ __i915_gem_userptr_get_pages_worker(struct work_struct
> *_work)
> }
> mutex_unlock(>mm.lock);
>
> - release_pages(pvec, pinned);
> + put_user_pages(pvec, pinned);
> kvfree(pvec);
>
> i915_gem_object_put(obj);
> @@ -640,7 +640,7 @@ static int i915_gem_userptr_get_pages(struct
> drm_i915_gem_object *obj)
> __i915_gem_userptr_set_active(obj, true);
>
> if (IS_ERR(pages))
> - release_pages(pvec, pinned);
> + put_user_pages(pvec, pinned);
> kvfree(pvec);
>
> return PTR_ERR_OR_ZERO(pages);
> @@ -675,7 +675,7 @@ i915_gem_userptr_put_pages(struct drm_i915_gem_object
> *obj,
> set_page_dirty_lock(page);
>
> mark_page_accessed(page);
> - put_page(page);
> + put_user_page(page);
> }
> obj->mm.dirty = false;
>
> --
> 2.22.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 05:37:22PM +0100, Daniel Stone wrote: > Hi Rodrigo, > > On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote: > > On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > > > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > > > drm-intel for the time being. Doing that migration in the same go is a > > > > bit much I think. Reassignment across bugzilla and gitlab will be an > > > > issue. > > > > > > Can you elaborate a bit on the issues here? The actual move-the-bugs > > > process has been pretty painless for the parts of xorg we've done so > > > far. > > > > I guess there is nothing against moving the bugs there. The concern is only > > on > > doing everything at once. > > > > I'm in favor of moving gits for now and after we are confident that > > everything is there and working we move the bugs. > > As Daniel alluded to, the only issue I really have is moving _all_ the > kernel repos at once. At the end of the year we'll have easy automatic > scaling thanks to the independent services being separated. As it is, > all the GitLab services (apart from CI runners) run on a single > machine, so we have limited options if it becomes overwhelmed with > load. > > Do you have a particular concern about the repos? no concerns from my side about the repos itself. From my committer perspective on libdrm, mesa the migration was really smooth. > e.g. what would you > check for to make sure things are 'there and working'? more in terms of other committers getting used to it, dim working for most of committers, links in documentations and wikis updated... but no concerns with the infra itself. > > > One question about the bugzilla: > > > > Will all the referrences on all commit messages get outdated after > > bugzilla is dead? > > Or bugzilla will stay up for referrence but closed for interaction? > > or all old closed stuff are always moved and bugzilla.fd.o as well and > > bugzilla.fd.o will be mirroring gitlab? > > When bugs are migrated from Bugzilla to GitLab, only open bugs are > migrated. Closed ones are left in place, as is; open ones have a > comment at the end saying that the bug has moved to GitLab, a URL > linking to the new GitLab issue, and telling them to please chase it > up there. > > Even when we move everyone completely off Bugzilla, we will keep it as > a read-only mirror forever. Even with Phabricator, which very few > people ever used, has had all its bugs and code review captured and > archived, so we can continue to preserve all the old content and > links, without having to run the actual service. Great! Thanks for all clarification, Rodrigo. > > Cheers, > Daniel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [igt-dev] RFC: Migration to Gitlab
On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote: > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote: > > > - Sticking to fdo bugzilla and disabling gitlab issues for at least > > drm-intel for the time being. Doing that migration in the same go is a > > bit much I think. Reassignment across bugzilla and gitlab will be an > > issue. > > Can you elaborate a bit on the issues here? The actual move-the-bugs > process has been pretty painless for the parts of xorg we've done so > far. I guess there is nothing against moving the bugs there. The concern is only on doing everything at once. I'm in favor of moving gits for now and after we are confident that everything is there and working we move the bugs. One question about the bugzilla: Will all the referrences on all commit messages get outdated after bugzilla is dead? Or bugzilla will stay up for referrence but closed for interaction? or all old closed stuff are always moved and bugzilla.fd.o as well and bugzilla.fd.o will be mirroring gitlab? Thanks, Rodrigo. > > - ajax > ___ > dim-tools mailing list > dim-to...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dim-tools ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
