All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
To: Kamil Konieczny <kamil.konieczny@linux.intel.com>
Cc: "Janusz Krzysztofik" <janusz.krzysztofik@linux.intel.com>,
	igt-dev@lists.freedesktop.org,
	"Dominik Karol Piątkowski" <dominik.karol.piatkowski@intel.com>,
	"Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Subject: Re: [PATCH i-g-t v9 2/7] lib/drmtest: Introduced drm_open_driver_another
Date: Tue, 20 Feb 2024 10:32:58 +0100	[thread overview]
Message-ID: <10419859.qUNvkh4Gvn@jkrzyszt-mobl2.ger.corp.intel.com> (raw)
In-Reply-To: <20240219174232.63q3nuu4mc5o566q@kamilkon-desk.igk.intel.com>

Hi Kamil,

On Monday, 19 February 2024 18:42:32 CET Kamil Konieczny wrote:
> Hi Janusz,
> On 2024-02-16 at 11:23:58 +0100, Janusz Krzysztofik wrote:
> > Hi Kamil, Dominik,
> > 
> > On Thursday, 15 February 2024 17:10:09 CET Kamil Konieczny wrote:
> > > From: Dominik Karol Piątkowski <dominik.karol.piatkowski@intel.com>
> > > 
> > > For user convenience, introduce drm_open_driver_another as
> > > a wrapper for __drm_open_driver_another with successful open
> > > assert.
> > 
> > Out of several existing variants of *drm_open_driver* functions, those which 
> > names start with "drm_", wrapped around their counterparts which names start 
> > with double underscores, used to set up an exit handler that performs 
> > necessary cleanups before exit, freeing users from taking care of that.  Don't 
> > we want to keep that convention also for drm_open_driver_another() and set up 
> > the exit handler from inside that wrapper on success?
> > 
> > Thanks,
> > Janusz
> > 
> 
> How and what should we unwind here? There is only fd, I do not see
> any other var or state to unwind? Am I missing something?

Have you had a look at drm_open()?

        /* For i915, at least, we ensure that the driver is idle before
         * starting a test and we install an exit handler to wait until
         * idle before quitting.
         */
        if (is_i915_device(fd)) {
                if (__sync_fetch_and_add(&open_count, 1) == 0) {
                        __cancel_work_at_exit(fd);
                        at_exit_drm_fd = drm_reopen_driver(fd);
                        igt_install_exit_handler(cancel_work_at_exit);
                }
        }

From that point of view, how does multi-gpu testing differ from single-gpu?

And yes, that can be not trivial to extend the existing exit handlers solution 
over multiple device file descriptor handling.

Also ...

> 
> Regards,
> Kamil
> 
> > > 
> > > v2: rebased (Kamil)
> > > v6: reword description (Janusz)
> > > 
> > > Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> > > Signed-off-by: Dominik Karol Piątkowski <dominik.karol.piatkowski@intel.com>
> > > Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> > > Reviewed-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com>
> > > ---
> > >  lib/drmtest.c | 19 +++++++++++++++++++
> > >  lib/drmtest.h |  1 +
> > >  2 files changed, 20 insertions(+)
> > > 
> > > diff --git a/lib/drmtest.c b/lib/drmtest.c
> > > index 52b5a2020..73d9159af 100644
> > > --- a/lib/drmtest.c
> > > +++ b/lib/drmtest.c
> > > @@ -563,6 +563,25 @@ int __drm_open_driver_another(int idx, int chipset)
> > >  	return fd;
> > >  }
> > >  
> > > +/*
> > > + * drm_open_driver_another
> > > + * @idx: index of the device you are opening
> > > + * @chipset: OR'd flags for each chipset to search, eg. #DRIVER_INTEL
> > > + *
> > > + * A wrapper for __drm_open_driver with successful open assert.
> > > + *
> > > + * Returns:
> > > + * An open DRM fd
> > > + */
> > > +int drm_open_driver_another(int idx, int chipset)
> > > +{
> > > +	int fd = __drm_open_driver_another(idx, chipset);
> > > +
> > > +	igt_assert_fd(fd);

drm_open_driver() skips in that case.  Shouldn't drm_open_driver_another() 
also skip for consistency?

Thanks,
Janusz

> > > +
> > > +	return fd;
> > > +}
> > > +
> > >  /**
> > >   * __drm_open_driver:
> > >   * @chipset: OR'd flags for each chipset to search, eg. #DRIVER_INTEL
> > > diff --git a/lib/drmtest.h b/lib/drmtest.h
> > > index 6bc819734..856208c48 100644
> > > --- a/lib/drmtest.h
> > > +++ b/lib/drmtest.h
> > > @@ -101,6 +101,7 @@ void __set_forced_driver(const char *name);
> > >  
> > >  int __drm_open_device(const char *name, unsigned int chipset);
> > >  void drm_load_module(unsigned int chipset);
> > > +int drm_open_driver_another(int idx, int chipset);
> > >  int drm_open_driver(int chipset);
> > >  int drm_open_driver_master(int chipset);
> > >  int drm_open_driver_render(int chipset);
> > > 
> > 
> > 
> > 
> > 
> 





  reply	other threads:[~2024-02-20  9:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 16:10 [PATCH i-g-t v9 0/7] introduce Xe multigpu and other multi-GPU helpers Kamil Konieczny
2024-02-15 16:10 ` [PATCH i-g-t v9 1/7] lib/igt_device_scan: Introduce filtering out non-PCI devices Kamil Konieczny
2024-02-15 16:10 ` [PATCH i-g-t v9 2/7] lib/drmtest: Introduced drm_open_driver_another Kamil Konieczny
2024-02-16 10:23   ` Janusz Krzysztofik
2024-02-19 17:42     ` Kamil Konieczny
2024-02-20  9:32       ` Janusz Krzysztofik [this message]
2024-02-20 18:33         ` Kamil Konieczny
2024-02-21 10:04           ` Janusz Krzysztofik
2024-02-15 16:10 ` [PATCH i-g-t v9 3/7] lib/intel_multigpu: Introduce library for multi-GPU scenarios Kamil Konieczny
2024-02-19 11:11   ` Zbigniew Kempczyński
2024-02-19 17:37     ` Kamil Konieczny
2024-02-15 16:10 ` [PATCH i-g-t v9 4/7] lib/intel_multigpu: Introduced gem_multigpu_count_class and igt_multi_fork_foreach_gpu Kamil Konieczny
2024-02-19 11:20   ` Zbigniew Kempczyński
2024-02-19 17:40     ` Kamil Konieczny
2024-02-19 17:45     ` Kamil Konieczny
2024-02-15 16:10 ` [PATCH i-g-t v9 5/7] lib/intel_multigpu: Add xe_multi_fork_foreach_gpu Kamil Konieczny
2024-02-19 11:22   ` Zbigniew Kempczyński
2024-02-19 11:26   ` Zbigniew Kempczyński
2024-02-15 16:10 ` [PATCH i-g-t v9 6/7] tests/intel/xe_exec_basic: add multigpu subtests Kamil Konieczny
2024-02-15 16:10 ` [PATCH i-g-t v9 7/7] tests/intel/gem_exec_gttfill: simplify multiGPU subtest Kamil Konieczny
2024-02-19 11:29   ` Zbigniew Kempczyński
2024-02-15 18:03 ` ✓ CI.xeBAT: success for introduce Xe multigpu and other multi-GPU helpers (rev9) Patchwork
2024-02-15 18:20 ` ✓ Fi.CI.BAT: " Patchwork
2024-02-16 14:41 ` ✗ Fi.CI.IGT: failure " Patchwork

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=10419859.qUNvkh4Gvn@jkrzyszt-mobl2.ger.corp.intel.com \
    --to=janusz.krzysztofik@linux.intel.com \
    --cc=dominik.karol.piatkowski@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=kamil.konieczny@linux.intel.com \
    --cc=zbigniew.kempczynski@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.