From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4DD31C4361B for ; Mon, 14 Dec 2020 21:52:14 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E81C522210 for ; Mon, 14 Dec 2020 21:52:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E81C522210 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5140989D43; Mon, 14 Dec 2020 21:52:13 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id 546D089D43 for ; Mon, 14 Dec 2020 21:52:12 +0000 (UTC) IronPort-SDR: 3KKMotmQTKNO0elBqz73fSrmyPYSSZPFX22ROAupDc6rb3kclTNmqIDdY1WFHqou67yzUw7lC6 felL137IAi9w== X-IronPort-AV: E=McAfee;i="6000,8403,9835"; a="154017742" X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208,217";a="154017742" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2020 13:52:11 -0800 IronPort-SDR: 7jGx8VLymrfuMfPkKwac+NQkNQthgXy31Su4Yi8sxSPAsUpQxZtAC6P83Ap1GgzRJAU1eLwsfL OMtFa1fTVkkA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208,217";a="556263808" Received: from orsmsx605.amr.corp.intel.com ([10.22.229.18]) by orsmga005.jf.intel.com with ESMTP; 14 Dec 2020 13:52:11 -0800 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX605.amr.corp.intel.com (10.22.229.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 14 Dec 2020 13:52:11 -0800 Received: from orsmsx610.amr.corp.intel.com (10.22.229.23) by ORSMSX612.amr.corp.intel.com (10.22.229.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Mon, 14 Dec 2020 13:52:10 -0800 Received: from orsmsx610.amr.corp.intel.com ([10.22.229.23]) by ORSMSX610.amr.corp.intel.com ([10.22.229.23]) with mapi id 15.01.1713.004; Mon, 14 Dec 2020 13:52:10 -0800 From: "Chang, Yu bruce" To: Chris Wilson , "intel-gfx@lists.freedesktop.org" Thread-Topic: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mmappable_aperture_size() Thread-Index: AQHW0Gtb2Usp9qHUFUmsvUL74KoMQan27y7/gACrGAD//4hAlA== Date: Mon, 14 Dec 2020 21:52:10 +0000 Message-ID: References: <20201212094354.3023502-1-chris@chris-wilson.co.uk> <7021dc5149a24438878f6540a0c4aed8@intel.com>, <160797892093.13039.18269573801947438332@build.alporthouse.com> In-Reply-To: <160797892093.13039.18269573801947438332@build.alporthouse.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.132] MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mmappable_aperture_size() X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0346881528==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============0346881528== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_b9269e1c98b34fb6a06fb14a277be599intelcom_" --_000_b9269e1c98b34fb6a06fb14a277be599intelcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > >From: Chris Wilson >Sent: Monday, December 14, 2020 12:48 PM >To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org >Cc: igt-dev@ >Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mmappabl= e_aperture_size() > >Quoting Chang, Yu bruce (2020-12-14 18:45:04) >> +/** >> + * gem_mappable_aperture_size: >> + * >> + * Feature test macro to query the kernel for the mappable gpu aperture= size. >> + * This is the area available for GTT memory mappings. >> + * > + * Returns: The mappable gtt address space size. > + */ > +uint64_t gem_mappable_aperture_size(int fd) > +{ > + struct pci_device *pci_dev =3D igt_device_get_pci_device(fd); > > Does it make sense to eliminate the function intel_get_pci_device() if no= t > being used anymore? But it can be a separate patch. > >It's still used by tools. The complication there is that we mostly >need to lookup the pci device without loading i915.ko. >-Chris > That makes sense. Then we need to make sure not start from a fix slot to look for GPU device = in the intel_get_pci_device() below as it may not work for a discrete GPU as that slot can be a non-vga device but= with vendor_id 0x8086. pci_dev =3D pci_device_find_by_slot(0, 0, 2, 0); if (pci_dev =3D=3D NULL || pci_dev->vendor_id !=3D 0x8086) { So, either add extra check to make sure it is VGA class or always use pci_d= evice_next to search. Thanks, -Bruce ________________________________ From: Chris Wilson Sent: Monday, December 14, 2020 12:48:40 PM To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org Cc: igt-dev@ Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mmappable= _aperture_size() Quoting Chang, Yu bruce (2020-12-14 18:45:04) > +/** > + * gem_mappable_aperture_size: > + * > + * Feature test macro to query the kernel for the mappable gpu aperture = size. > + * This is the area available for GTT memory mappings. > + * > + * Returns: The mappable gtt address space size. > + */ > +uint64_t gem_mappable_aperture_size(int fd) > +{ > + struct pci_device *pci_dev =3D igt_device_get_pci_device(fd); > > Does it make sense to eliminate the function intel_get_pci_device() if no= t > being used anymore? But it can be a separate patch. It's still used by tools. The complication there is that we mostly need to lookup the pci device without loading i915.ko. -Chris --_000_b9269e1c98b34fb6a06fb14a277be599intelcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


>
>From: Chris Wilson <chris@chris-wilson.co.uk>
>Sent: Monday, December 14, 2020 12:48 PM
>To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org
>Cc: igt-dev@
>Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mmapp= able_aperture_size()
> 
>Quoting Chang, Yu bruce (2020-12-14 18:45:04)
>> +/**
>> + * gem_mappable_aperture_size:
>> + *
>> + * Feature test macro to query the kernel for the mappable gp= u aperture size.
>> + * This is the area available for GTT memory mappings.
>> + *
> + * Returns: The mappable gtt address space size.
> + */
> +uint64_t gem_mappable_aperture_size(int fd)
> +{
> +       struct pci_device *pci_dev =3D igt_dev= ice_get_pci_device(fd);
> 
> Does it make sense to eliminate the function intel_get_pci_device() if= not
> being used anymore? But it can be a separate patch.
>
>It's still used by tools. The complication there is that we mostly
>need to lookup the pci device without loading i915.ko. 
>-Chris
>

That makes sense.

Then we need t= o make sure not start from a fix slot to look for GPU device in the intel_get_pci_device() below as
it may no= t work for a discrete GPU as that slot can be a non-vga device but with vendor_id 0x8086.

        pci_dev =3D pci_device_find_by_slot(0, = 0, 2, 0);
        = if (pci_dev =3D=3D NULL || pci_dev->vendor_id !=3D 0x8086) {

So, either add extr= a check to make sure it is VGA class or always use pci_device_next to search.

Thanks,
-Bruce

From: Chris Wilson <ch= ris@chris-wilson.co.uk>
Sent: Monday, December 14, 2020 12:48:40 PM
To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org
Cc: igt-dev@
Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_mm= appable_aperture_size()
 
Quoting Chang, Yu bruce (2020-12-14 18:45:04)
> +/**
> + * gem_mappable_aperture_size:
> + *
> + * Feature test macro to query the kernel for the mappable gpu ap= erture size.
> + * This is the area available for GTT memory mappings.
> + *
> + * Returns: The mappable gtt address space size.
> + */
> +uint64_t gem_mappable_aperture_size(int fd)
> +{
> +       struct pci_device *pci_dev = =3D igt_device_get_pci_device(fd);
>
> Does it make sense to eliminate the function intel_get_pci_device() if= not
> being used anymore? But it can be a separate patch.

It's still used by tools. The complication there is that we mostly
need to lookup the pci device without loading i915.ko.
-Chris
--_000_b9269e1c98b34fb6a06fb14a277be599intelcom_-- --===============0346881528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0346881528==--