search for: jingfeng

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the nee...

Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and buffer size. Align the pitch according to hardware requirements. Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Cc: Sui Jingfeng <suijingfeng at loongson.cn> Cc: Sui Jingfeng <sui.jingfeng at linux.dev> --- drivers/gpu/drm/loongson/lsdc_gem.c | 29 ++++++++--------------------- 1 file changed, 8 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/loongson/lsdc_gem.c b/drivers/gpu/drm/loongson/lsdc_gem.c...

From: Sui Jingfeng <suijingfeng at loongson.cn> On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to...

From: Sui Jingfeng <suijingfeng at loongson.cn> Should be no functional change Cc: Jaroslav Kysela <perex at perex.cz> Cc: Takashi Iwai <tiwai at suse.com> Cc: Fred Oh <fred.oh at linux.intel.com> Cc: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com> Cc: Kai Vehmanen <k...

Hi, On 2023/9/5 22:52, Alex Williamson wrote: > On Tue, 5 Sep 2023 03:57:15 +0800 > Sui Jingfeng <sui.jingfeng at linux.dev> wrote: > >> From: Sui Jingfeng <suijingfeng at loongson.cn> >> >> On a machine with multiple GPUs, a Linux user has no control over which >> one is primary at boot time. This series tries to solve above mentioned >> problem by...

From: Sui Jingfeng <suijingfeng at loongson.cn> Patch 1,2 and 3 do basic clean up to the vgaarb module. Patch 4 introduce is_boot_device function callback to vga_client_register Sui Jingfeng (4): PCI/VGA: tidy up the code and comment format PCI/VGA: Use unsigned type for the io_state variable PCI/VGA: o...

From: Sui Jingfeng <suijingfeng at loongson.cn> To keep consistent with vga_iostate_to_str() function, the third argument of vga_str_to_iostate() function should be 'unsigned int *'. Signed-off-by: Sui Jingfeng <suijingfeng at loongson.cn> --- drivers/pci/vgaarb.c | 29 +++++++++++++++--------...

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a de...

...ssages when adding devices dc593fd48abb PCI/VGA: Remove empty vga_arb_device_card_gone() ... Subject line should be a summary of the commit log, not just "various style fixes". This one needs to say something about vga_str_to_iostate(). On Mon, Jun 05, 2023 at 04:58:30AM +0800, Sui Jingfeng wrote: > From: Sui Jingfeng <suijingfeng at loongson.cn> > > To keep consistent with vga_iostate_to_str() function, the third argument > of vga_str_to_iostate() function should be 'unsigned int *'. > > Signed-off-by: Sui Jingfeng <suijingfeng at loongson.cn>...

On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote: > On 2023/6/9 03:19, Bjorn Helgaas wrote: > > On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote: > > > From: Sui Jingfeng <suijingfeng at loongson.cn> > > > > > > The vga_is_firmware_default() function is arch-dependent, which doesn't...

From: Sui Jingfeng <suijingfeng at loongson.cn> [why] The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is arch-dependent, it's a dummy on non-x86 architectures currently. This made VGAARB lost an important condition for the arbitration. It could still be wrong even if we remove the #ifdef and...

From: Sui Jingfeng <suijingfeng at loongson.cn> [why] The vga_is_firmware_default() defined in drivers/pci/vgaarb.c is arch-dependent, it's a dummy on non-x86 architectures currently. This made VGAARB lost an important condition for the arbitration. It could still be wrong even if we remove the #ifdef and...

From: Sui Jingfeng <suijingfeng at loongson.cn> Should be no functional change. Cc: Alex Deucher <alexander.deucher at amd.com> Signed-off-by: Sui Jingfeng <suijingfeng at loongson.cn> --- drivers/gpu/drm/radeon/radeon_bios.c | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletion...

From: Sui Jingfeng <suijingfeng at loongson.cn> There is no function that can be used to get all PCI(e) devices in a system by matching against its the PCI base class code only, while keep the sub-class code and the programming interface ignored. Therefore, add the pci_get_base_class() function to suit the nee...

On Mon, Jan 20, 2025 at 12:26:30AM +0800, Sui Jingfeng wrote: > On 2025/1/19 23:22, Tomi Valkeinen wrote: > > On 19/01/2025 16:59, Sui Jingfeng wrote: > > > >>>>> But userspace must be able to continue allocating YUV buffers through > >>>>> CREATE_DUMB. > >>>> > >>>> I thi...

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call apertu...

Hi, On 2025/1/19 23:22, Tomi Valkeinen wrote: > On 19/01/2025 16:59, Sui Jingfeng wrote: > >>>>> But userspace must be able to continue allocating YUV buffers through >>>>> CREATE_DUMB. >>>> >>>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>>> an *abuse* and *misuse* of this API for n...

On 19/01/2025 16:59, Sui Jingfeng wrote: >>>> But userspace must be able to continue allocating YUV buffers through >>>> CREATE_DUMB. >>> >>> I think, allocating YUV buffers through CREATE_DUMB interface is just >>> an *abuse* and *misuse* of this API for now. >>> >&gt...

Hi, On 2025/1/19 20:18, Tomi Valkeinen wrote: > Hi, > > On 19/01/2025 13:29, Sui Jingfeng wrote: >> Hi, >> >> On 2025/1/16 18:35, Dmitry Baryshkov wrote: >>> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote: >>>> On Thu, Jan 16, 2025 at 11:03?AM Tomi Valkeinen >>>> <tomi.valkeinen at ideasonboard.com> wrote: >...

Hi, On 19/01/2025 13:29, Sui Jingfeng wrote: > Hi, > > On 2025/1/16 18:35, Dmitry Baryshkov wrote: >> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote: >>> On Thu, Jan 16, 2025 at 11:03?AM Tomi Valkeinen >>> <tomi.valkeinen at ideasonboard.com> wrote: >>>> On 16/01/2...