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=-5.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,INCLUDES_CR_TRAILER, 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 B7A92C4361B for ; Mon, 14 Dec 2020 23:40:28 +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 2EAC622507 for ; Mon, 14 Dec 2020 23:40:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2EAC622507 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 5B1356E054; Mon, 14 Dec 2020 23:40:27 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 93CF56E054 for ; Mon, 14 Dec 2020 23:40:26 +0000 (UTC) IronPort-SDR: G5e0IA/u9krQVzsHxJ5Y7BU4n/WaT1dSq6xKlZklb2C/tLugfTP5pDxQzI1HiwlHaJwjCuLjEW y0MrZN2+9sqg== X-IronPort-AV: E=McAfee;i="6000,8403,9835"; a="174942490" X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208,217";a="174942490" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Dec 2020 15:40:25 -0800 IronPort-SDR: K6vcsvdZtglGebfpFYGa9I5/OkEqaPRONtEgDEqxqXKprcVxhJrrxXVG1syUqjFYUBVxB+oC2T 8jtS+l7Nn9iQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.78,420,1599548400"; d="scan'208,217";a="351638098" Received: from orsmsx604.amr.corp.intel.com ([10.22.229.17]) by orsmga002.jf.intel.com with ESMTP; 14 Dec 2020 15:40:25 -0800 Received: from orsmsx612.amr.corp.intel.com (10.22.229.25) by ORSMSX604.amr.corp.intel.com (10.22.229.17) 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 15:40:25 -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 15:40:24 -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 15:40:24 -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//4hAlIAAj98A//+Qpl0= Date: Mon, 14 Dec 2020 23:40:24 +0000 Message-ID: <10feb0b0fd924e48a149b0fa2a8d5d29@intel.com> References: <20201212094354.3023502-1-chris@chris-wilson.co.uk> <7021dc5149a24438878f6540a0c4aed8@intel.com>, <160797892093.13039.18269573801947438332@build.alporthouse.com> , <160798410071.13039.10818205990449584130@build.alporthouse.com> In-Reply-To: <160798410071.13039.10818205990449584130@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="===============0038654789==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============0038654789== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_10feb0b0fd924e48a149b0fa2a8d5d29intelcom_" --_000_10feb0b0fd924e48a149b0fa2a8d5d29intelcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >From: Chris Wilson > >Sent: Monday, December 14, 2020 2:15 PM >To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org >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 21:52:10) >> >> > >> >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_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 apert= ure >> 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 >> > >> >> That makes sense. >> >> Then we need to make sure not start from a fix slot to look for GPU devi= ce 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_device_next to search. > >It's held true for ~20 years :) > >I hear you; for the remaining users, they should probably use the lsgpu >interface to pick the right device to work on (and remove >intel_get_pci_device). > >tools/intel_audio_dump.c >tools/intel_backlight.c >tools/intel_display_poller.c >tools/intel_forcewaked.c >tools/intel_gpu_time.c >tools/intel_gtt.c >tools/intel_infoframes.c >tools/intel_lid.c >tools/intel_panel_fitter.c >tools/intel_reg.c >tools/intel_reg_checker.c >tools/intel_watermark.c > >A few of those could even be retired. >-Chris > > Sounds reasonably to me. the rest of your changes look good to me, and also= fix my issue. Thanks, Bruce Reviewed-by: Bruce Chang --_000_10feb0b0fd924e48a149b0fa2a8d5d29intelcom_ 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 2:15 PM
>To: Chang, Yu bruce; intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH i-g-t] lib: Pass device fd to gem_= mmappable_aperture_size()
> 
>Quoting Chang, Yu bruce (2020-12-14 21:52:10)
>> 
>> >
>> >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 f= d 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 t= he mappable gpu aperture
>> size.
>> >> + * This is the area available for GTT memory ma= ppings.
>> >> + *
>> > + * Returns: The mappable gtt address space size.
>> > + */
>> > +uint64_t gem_mappable_aperture_size(int fd)
>> > +{
>> > +       struct pci_device *pci_d= ev =3D igt_device_get_pci_device(fd);
>> > 
>> > Does it make sense to eliminate the function intel_get_p= ci_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.&nb= sp;
>> >-Chris
>> >
>> 
>> That makes sense.
>> 
>> Then we need to make sure not start from a fix slot to look f= or 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 || p= ci_dev->vendor_id !=3D 0x8086) {
>> 
>> So, either add extra check to make sure it is VGA class or al= ways use 
>> pci_device_next to search.
>
>It's held true for ~20 years :)
>
>I hear you; for the remaining users, they should probably use the = lsgpu
>interface to pick the right device to work on (and remove
>intel_get_pci_device).
>
>tools/intel_audio_dump.c
>tools/intel_backlight.c
>tools/intel_display_poller.c
>tools/intel_forcewaked.c
>tools/intel_gpu_time.c
>tools/intel_gtt.c
>tools/intel_infoframes.c
>tools/intel_lid.c
>tools/intel_panel_fitter.c
>tools/intel_reg.c
>tools/intel_reg_checker.c
>tools/intel_watermark.c
>
>A few of those could even be retired.
>-Chris
>
>

Sounds reasonably to me. the rest of your changes look good to me= , and also fix my issue.

Thanks,
Bruce

Reviewed-by: Bruce Chang <yu.bruce.chang@intel.com>

--_000_10feb0b0fd924e48a149b0fa2a8d5d29intelcom_-- --===============0038654789== 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 --===============0038654789==--