Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d490f455-5228-b85a-656a-dce11586dee5@loongson.cn>
Date:   Thu, 20 Jul 2023 06:04:21 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: [Intel-gfx] [PATCH v3 3/9] PCI/VGA: Switch to
 aperture_contain_firmware_fb_nonreloc()
Content-Language: en-US
To:     Bjorn Helgaas <helgaas@kernel.org>,
        Sui Jingfeng <sui.jingfeng@linux.dev>
Cc:     David Airlie <airlied@gmail.com>, linux-fbdev@vger.kernel.org,
        kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        amd-gfx@lists.freedesktop.org, linux-pci@vger.kernel.org
References: <20230719204314.GA512532@bhelgaas>
From:   suijingfeng <suijingfeng@loongson.cn>
In-Reply-To: <20230719204314.GA512532@bhelgaas>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi,

On 2023/7/20 04:43, Bjorn Helgaas wrote:
> [+cc linux-pci; I don't apply or ack PCI patches unless they appear there]
>
> On Wed, Jul 12, 2023 at 12:43:04AM +0800, Sui Jingfeng wrote:
>> From: Sui Jingfeng <suijingfeng@loongson.cn>
>>
>> The observation behind this is that we should avoid accessing the global
>> screen_info directly. Call the aperture_contain_firmware_fb_nonreloc()
>> function to implement the detection of whether an aperture contains the
>> firmware FB.
> Because it's better to access the global screen_info from
> aperture_contain_firmware_fb_nonreloc()?  The reasoning here is not
> super clear to me.

Yes, honestly the benefits of this patch is not obvious.

But I do have some (may not practical) ideas in my mind when I create 
this patch.

See my explanation at the end.


>> This patch helps to decouple the determination from the implementation.
>> Or, in other words, we intend to make the determination opaque to the
>> caller. The determination may choose to be arch-dependent or
>> arch-independent. But vgaarb, as a consumer of the determination,
>> shouldn't care how the does determination is implemented.
> "how the determination ..."  (drop the "does")
Ok, will be fixed at the next version.
>
> Are you saying that aperture_contain_firmware_fb_nonreloc() might be
> arch-dependent?  Are there multiple callers?  Or does this just move
> code from one place to a more appropriate place?

1) To form a unify approach, and drop the screen_info.h header.

There are similar cleanup patch at patchwork.


screen_info.h is definitely arch-dependent, while vgaarb is just 
device-dependent.

I think, they do have subtle difference.


2) Convert the *device driven* to the "driver driven".

Move it from vgaarb.c to video/apperture allow code sharing.

While this function are not going to be shared in vgaarb.

Previous it is the device make the decision,

after applied this patch it allow driver make the decision.

They do have subtle difference.

Emm, I will try to give some examples at the next version.


3) I was imagine to drag platform display controllers in (get platform 
devices involved in the arbitration).

As Alex seem hint to implement something platform-independent.

The aperture_contain_firmware_fb_nonreloc() actually is possible be shared.

The aperture of platform device will be not moved.

So it seems that platform device driver could call this function to do 
something else.


>> Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
>> ---
>>   drivers/pci/vgaarb.c | 19 ++++---------------
>>   1 file changed, 4 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/pci/vgaarb.c b/drivers/pci/vgaarb.c
>> index bf96e085751d..953daf731b2c 100644
>> --- a/drivers/pci/vgaarb.c
>> +++ b/drivers/pci/vgaarb.c
>> @@ -14,6 +14,7 @@
>>   #define vgaarb_info(dev, fmt, arg...)	dev_info(dev, "vgaarb: " fmt, ##arg)
>>   #define vgaarb_err(dev, fmt, arg...)	dev_err(dev, "vgaarb: " fmt, ##arg)
>>   
>> +#include <linux/aperture.h>
>>   #include <linux/module.h>
>>   #include <linux/kernel.h>
>>   #include <linux/pci.h>
>> @@ -26,7 +27,6 @@
>>   #include <linux/poll.h>
>>   #include <linux/miscdevice.h>
>>   #include <linux/slab.h>
>> -#include <linux/screen_info.h>
>>   #include <linux/vt.h>
>>   #include <linux/console.h>
>>   #include <linux/acpi.h>
>> @@ -558,20 +558,11 @@ void vga_put(struct pci_dev *pdev, unsigned int rsrc)
>>   }
>>   EXPORT_SYMBOL(vga_put);
>>   
>> +/* Select the device owning the boot framebuffer if there is one */
>>   static bool vga_is_firmware_default(struct pci_dev *pdev)
>>   {
>>   #if defined(CONFIG_X86) || defined(CONFIG_IA64)
>> -	u64 base = screen_info.lfb_base;
>> -	u64 size = screen_info.lfb_size;
>>   	struct resource *r;
>> -	u64 limit;
>> -
>> -	/* Select the device owning the boot framebuffer if there is one */
>> -
>> -	if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
>> -		base |= (u64)screen_info.ext_lfb_base << 32;
>> -
>> -	limit = base + size;
>>   
>>   	/* Does firmware framebuffer belong to us? */
>>   	pci_dev_for_each_resource(pdev, r) {
>> @@ -581,10 +572,8 @@ static bool vga_is_firmware_default(struct pci_dev *pdev)
>>   		if (!r->start || !r->end)
>>   			continue;
>>   
>> -		if (base < r->start || limit >= r->end)
>> -			continue;
>> -
>> -		return true;
>> +		if (aperture_contain_firmware_fb_nonreloc(r->start, r->end))
>> +			return true;
>>   	}
>>   #endif
>>   	return false;
>> -- 
>> 2.25.1
>>