linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christian König" <ckoenig.leichtzumerken@gmail.com>
To: Sui Jingfeng <sui.jingfeng@linux.dev>,
	suijingfeng <suijingfeng@loongson.cn>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"Koenig, Christian" <Christian.Koenig@amd.com>,
	Jani Nikula <jani.nikula@linux.intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	"Deucher, Alexander" <Alexander.Deucher@amd.com>
Cc: nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, linux-pci@vger.kernel.org
Subject: Re: [Nouveau] [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time
Date: Wed, 6 Sep 2023 12:50:31 +0200	[thread overview]
Message-ID: <4df435a0-dd9b-121a-8820-e331bb8a046f@gmail.com> (raw)
In-Reply-To: <873b331a-d0ce-658c-6daa-02bf816e92d1@linux.dev>

Am 06.09.23 um 12:31 schrieb Sui Jingfeng:
> Hi,
>
> On 2023/9/6 14:45, Christian König wrote:
>>> Firmware framebuffer device already get killed by the 
>>> drm_aperture_remove_conflicting_pci_framebuffers()
>>> function (or its siblings). So, this series is definitely not to 
>>> interact with the firmware framebuffer
>>> (or more intelligent framebuffer drivers).  It is for user space 
>>> program, such as X server and Wayland
>>> compositor. Its for Linux user or drm drivers testers, which allow 
>>> them to direct graphic display server
>>> using right hardware of interested as primary video card.
>>>
>>> Also, I believe that X server and Wayland compositor are the best 
>>> test examples.
>>> If a specific DRM driver can't work with X server as a primary,
>>> then there probably have something wrong.
>>>
>>>
>>>> But what's the use case for overriding this setting?
>>>>
>>>
>>> On a specific machine with multiple GPUs mounted,
>>> only the primary graphics get POST-ed (initialized) by the firmware.
>>> Therefore, the DRM drivers for the rest video cards, have to choose to
>>> work without the prerequisite setups done by firmware, This is 
>>> called as POST.
>>
>> Well, you don't seem to understand the background here. This is 
>> perfectly normal behavior.
>>
>> Secondary cards are posted after loading the appropriate DRM driver. 
>> At least for amdgpu this is done by calling the appropriate functions 
>> in the BIOS. 
>
>
> Well, thanks for you tell me this. You know more than me and 
> definitely have a better understanding.
>
> Are you telling me that the POST function for AMDGPU reside in the BIOS?
> The kernel call into the BIOS?

Yes, exactly that.

> Does the BIOS here refer to the UEFI runtime or ATOM BIOS or something 
> else?

On dGPUs it's the VBIOS on a flashrom on the board, for iGPUs (APUs as 
AMD calls them) it's part of the system BIOS.

UEFI is actually just a small subsystem in the system BIOS which 
replaced the old interface used between system BIOS, video BIOS and 
operating system.

>
> But the POST function for the drm ast, reside in the kernel space (in 
> other word, in ast.ko).
> Is this statement correct?

I don't know the ast driver well enough to answer that, but I assume 
they just read the BIOS and execute the appropriate functions.

>
> I means that for ASpeed BMC chip, if the firmware not POST the display 
> controller.
> Then we have to POST it at the kernel space before doing various 
> modeset option.
> We can only POST this chip by directly operate the various registers.
> Am I correct for the judgement about ast drm driver?

Well POST just means Power On Self Test, but what you mean is 
initializing the hardware.

Some drivers can of course initialize the hardware without the help of 
the BIOS, but I don't think AST can do that. As far as I know it's a 
relatively simple driver.

BTW firmware is not the same as the BIOS (which runs the POST), firmware 
usually refers to something run on microcontrollers inside the ASIC 
while the (system or video) BIOS runs on the host CPU.

Regards,
Christian.

>
> Thanks for your reviews.
>


  reply	other threads:[~2023-09-06 10:50 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-04 19:57 [RFC,drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 1/9] " Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 2/9] drm/nouveau: Implement .be_primary() callback Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 3/9] drm/radeon: " Sui Jingfeng
2023-09-05  5:50   ` Christian König
2023-09-05 17:24     ` suijingfeng
2023-09-06 16:00       ` Alex Deucher
2023-09-07  1:40         ` Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 4/9] drm/amdgpu: " Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 5/9] drm/i915: " Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 6/9] drm/loongson: " Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 7/9] drm/ast: Register as a VGA client by calling vga_client_register() Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 8/9] drm/hibmc: " Sui Jingfeng
2023-09-04 19:57 ` [RFC,drm-misc-next v4 9/9] drm/gma500: " Sui Jingfeng
2023-09-05 10:38 ` [RFC, drm-misc-next v4 0/9] PCI/VGA: Allowing the user to select the primary video adapter at boot time Jani Nikula
2023-09-05 13:28   ` Christian König
2023-09-05 14:28     ` Sui Jingfeng
2023-09-06  6:47       ` Christian König
2023-09-05 10:45 ` [Nouveau] " Thomas Zimmermann
2023-09-05 13:30   ` suijingfeng
2023-09-05 15:05     ` Thomas Zimmermann
2023-09-06  2:14       ` suijingfeng
2023-09-06  7:00         ` Thomas Zimmermann
2023-09-06  2:34       ` suijingfeng
2023-09-06  7:18         ` Thomas Zimmermann
2023-09-06  3:08       ` suijingfeng
2023-09-06  7:46         ` Thomas Zimmermann
2023-09-06  4:14       ` Sui Jingfeng
2023-09-06  6:45     ` Christian König
2023-09-06  9:08       ` suijingfeng
2023-09-06  9:40         ` Christian König
2023-09-07  2:30           ` Sui Jingfeng
2023-09-07  9:08             ` Christian König
2023-09-07 12:32               ` suijingfeng
2023-09-07 12:43                 ` Christian König
2023-09-07 15:26                   ` suijingfeng
2023-09-07 15:32                     ` Christian König
2023-09-07 16:33               ` suijingfeng
2023-09-08  6:59                 ` Christian König
2023-09-06 10:31       ` Sui Jingfeng
2023-09-06 10:50         ` Christian König [this message]
2023-09-05 10:49 ` Thomas Zimmermann
2023-09-05 15:59   ` suijingfeng
2023-09-06  8:05     ` Thomas Zimmermann
2023-09-06  9:48       ` suijingfeng
2023-09-06 11:06         ` Thomas Zimmermann
2023-09-07  9:43         ` Jani Nikula
2023-09-05 14:52 ` Alex Williamson
2023-09-05 16:21   ` suijingfeng
2023-09-05 16:39     ` Alex Williamson
2023-09-06  3:51   ` Sui Jingfeng
2023-09-06 19:29     ` Alex Williamson

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=4df435a0-dd9b-121a-8820-e331bb8a046f@gmail.com \
    --to=ckoenig.leichtzumerken@gmail.com \
    --cc=Alexander.Deucher@amd.com \
    --cc=Christian.Koenig@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=bhelgaas@google.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=sui.jingfeng@linux.dev \
    --cc=suijingfeng@loongson.cn \
    --cc=tzimmermann@suse.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).