Hi,
On 2023/9/19 21:12, Maxime Ripard wrote:
We've had a number of times when a patch slipped through and we couldn't
pick them up either because our MAINTAINERS entry only covers the
framework and thus we weren't Cc'd.
Let's take another approach where we match everything, and remove all
the
Hi,
On 2023/8/25 21:18, Deucher, Alexander wrote:
[Public]
-Original Message-
From: amd-gfx On Behalf Of Sui
Jingfeng
Sent: Friday, August 25, 2023 2:27 AM
To: Bjorn Helgaas
Cc: alsa-de...@alsa-project.org; Sui Jingfeng ;
nouv...@lists.freedesktop.org; linux-ker...@vger.kernel.org;
Hi,
On 2023/9/15 21:44, Doug Anderson wrote:
Hi,
On Fri, Sep 15, 2023 at 2:11 AM suijingfeng wrote:
Hi,
On 2023/9/2 07:39, Douglas Anderson wrote:
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time
Hi,
On 2023/9/2 07:39, Douglas Anderson wrote:
Based on grepping through the source code these drivers appear to be
missing a call to drm_atomic_helper_shutdown() at system shutdown
time. Among other things, this means that if a panel is in use that it
won't be cleanly powered off at system
Hi,
On 2023/9/7 17:08, Christian König wrote:
I strongly suggest that you just completely drop this here
Drop this is OK, no problem. Then I will go to develop something else.
This version is not intended to merge originally, as it's a RFC.
Also, the core mechanism already finished, it is
Hi,
On 2023/9/7 20:43, Christian König wrote:
Am 07.09.23 um 14:32 schrieb suijingfeng:
Hi,
On 2023/9/7 17:08, Christian König wrote:
Well, I have over 25 years of experience with display hardware and
what you describe here was never an issue.
I want to give you an example to let you
Hi,
On 2023/9/7 17:08, Christian König wrote:
Well, I have over 25 years of experience with display hardware and
what you describe here was never an issue.
I want to give you an example to let you know more.
I have a ASRock AD2550B-ITX board[1],
When another discrete video card is mounted
Hi,
On 2023/9/6 16:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 17:59 schrieb suijingfeng:
[...]
FYI: per-driver modeset parameters are deprecated and not to be
used. Please don't promote them.
Well, please wait, I want to explain.
drm/nouveau already promote it a little bit
Hi,
On 2023/9/6 14:45, Christian König wrote:
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which
one
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist. 'Primary' is the device that is available via VGA, VESA or EFI.
I may miss the point, what do you means by choose the word "modern"?
Are you trying to tell me that X
On 2023/9/5 23:05, Thomas Zimmermann wrote:
Hi
Am 05.09.23 um 15:30 schrieb suijingfeng:
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which
one
Hi,
On 2023/9/5 23:05, Thomas Zimmermann wrote:
However, on modern Linux systems the primary display does not really
exist.
No, it do exist. X server need to know which one is the primary GPU.
The '*' character at the of (4@0:0:0) PCI device is the Primary.
The '*' denote primary, see the
Hi,
On 2023/9/5 13:50, Christian König wrote:
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
On a machine with multiple GPUs, a Linux user has no control over
which one
is primary at boot time.
Question is why is that useful? Should we give users the ability to
control
Hi,
On 2023/9/5 22:52, Alex Williamson wrote:
On Tue, 5 Sep 2023 03:57:15 +0800
Sui Jingfeng wrote:
From: Sui Jingfeng
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
On 2023/9/5 18:49, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
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
Hi,
On 2023/9/5 18:45, Thomas Zimmermann wrote:
Hi
Am 04.09.23 um 21:57 schrieb Sui Jingfeng:
From: Sui Jingfeng
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
If anything, the primary
Hi,
On 2023/8/25 14:54, Patrik Jakobsson wrote:
On Fri, Jul 28, 2023 at 02:58:55AM +0800, Sui Jingfeng wrote:
Because the gma_irq_install() is call after psb_gem_mm_init() function,
when psb_gem_mm_init() fails, the interrupt line haven't been allocated.
Yet the gma_irq_uninstall() is called
Hi,
Nice cleanup, thanks a lot.
On 2023/8/24 06:29, Bjorn Helgaas wrote:
On Wed, Aug 09, 2023 at 06:34:01AM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
v1:
* Various improve.
v2:
* More fixes, optimizations and improvements.
Sui Jingfeng (11):
PCI/VGA: Use unsigned
Hi,
On 2023/8/22 01:38, Bjorn Helgaas wrote:
On Fri, Aug 18, 2023 at 12:09:29PM +0800, suijingfeng wrote:
On 2023/8/18 06:08, Bjorn Helgaas wrote:
On Wed, Aug 16, 2023 at 06:05:27AM +0800, Sui Jingfeng wrote:
Currently, the vga_is_firmware_default() function only works on x86 and
ia64
Hi,
On 2023/8/22 01:33, Bjorn Helgaas wrote:
On Fri, Aug 18, 2023 at 09:48:46AM +0800, suijingfeng wrote:
On 2023/8/18 06:08, Bjorn Helgaas wrote:
+ if (resource_type(res) != IORESOURCE_MEM)
+ continue;
+
+ if (!res->start || !res-&
Hi,
On 2023/8/18 18:20, suijingfeng wrote:
1) The "weird" logic completely overrides whatever decision VGAARB
ever made.
It seems to say that the decision ever made by VGAARB is useless.
Well, I think VGAARB shouldn't endure this; VGAARB has to be small.
VGAARB have t
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
I guess the point here is that:
- 03:00.0 BAR 0 is [mem 0xe005000-0xe005fff]
- screen_info says the framebuffer is
[mem 0xe005000-0xe005fff] (or part of it)
- Therefore, we want 03:00.0 to be the default VGA
-
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
+
+/*
+ * Identify the PCI VGA device that contains the firmware framebuffer
+ */
+static void pci_boot_vga_finder(struct pci_dev *pdev)
+{
+ resource_size_t fb_start;
+ resource_size_t fb_end;
+ unsigned int i;
+
+ /* Already
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
Please note that before apply this patch, vgaarb can not select the
right boot vga due to weird logic introduced with the commit
57fc7323a8e7c ("LoongArch: Add PCI controller support")
If we need this reference to 57fc7323a8e7c, we need more
Hi,
On 2023/8/3 23:47, Daniel Stone wrote:
Since there's a lot of confusion around this, document both the rules
and the best practice around negotiating, allocating, importing, and
Probably, best practices?
using buffers when crossing context/process/device/subsystem boundaries.
This
On 2023/8/18 22:04, suijingfeng wrote:
Hi,
Why this patch get dropped in the end?
Since the global screen_info is an arch-specific thing,
Whenever an arch-neutral module or subsystem references the global
screen_info,
There are some complaints from either compile testing robot
Hi,
Why this patch get dropped in the end?
Since the global screen_info is an arch-specific thing,
Whenever an arch-neutral module or subsystem references the global screen_info,
There are some complaints from either compile testing robot.
Well, a programmer may handle it by using the
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
Please note that before apply this patch, vgaarb can not select the
right boot vga due to weird logic introduced with the commit
57fc7323a8e7c ("LoongArch: Add PCI controller support")
If we need this reference to 57fc7323a8e7c, we need more
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
This patch makes the vga_is_firmware_default() function works on whatever
arch that has UEFI GOP support. But we make it available only on platforms
where PCI resource relocation happens. if the provided method proves to be
effective and reliable,
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
On Wed, Aug 16, 2023 at 06:05:27AM +0800, Sui Jingfeng wrote:
Currently, the vga_is_firmware_default() function only works on x86 and
ia64, it is a no-op on ARM, ARM64, PPC, RISC-V, etc. This patch completes
the implementation for the rest of the
Hi,
On 2023/8/18 06:08, Bjorn Helgaas wrote:
+ if (resource_type(res) != IORESOURCE_MEM)
+ continue;
+
+ if (!res->start || !res->end)
+ continue;
+
+ if (res->start <= fb_start && fb_end <= res->end) {
+
Hi,
On 2023/7/20 20:39, Harshit Mogalapalli wrote:
There are two problems in lsdc_pixel_pll_setup()
1. If kzalloc() fails then call iounmap() to release the resources.
2. Both kzalloc and ioremap doesnot return error pointers on failure, so
using IS_ERR_OR_NULL() checks is a bit confusing
Hi,
On 2023/8/9 22:01, Ilpo Järvinen wrote:
On Wed, 9 Aug 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
Because there is no good way to get the mask member used to searching for
devices that conform to a specific PCI class code, an application needs to
process all PCI display devices can
Hi,
On 2023/8/9 22:12, Ilpo Järvinen wrote:
On Wed, 9 Aug 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
1) s/intereted/interested
2) s/hotplugable/hot-pluggable
While at it, convert the comments to the conventional multi-line style,
and rewrap to fill 78 columns.
Fixes: deb2d2ecd43d
Hi,
On 2023/8/9 21:52, Ilpo Järvinen wrote:
On Wed, 9 Aug 2023, Sui Jingfeng wrote:
From: Sui Jingfeng
Changelog body is missing.
I thought that probably the Fixes tag could be taken as the body of this commit,
since there are no warnings when I check the whole series with
://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:
https://lore.kernel.org/r/20230803081758.968742-1-suijingfeng%40loongson.cn
patch subject: [PATCH] PCI/VGA: Make the vga_is_firmware_default()
arch-independent
config: arm64-randconfig-r026-20230731
(https://download.01.org
://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git next
patch link:
https://lore.kernel.org/r/20230801183706.702567-1-suijingfeng%40loongson.cn
patch subject: [PATCH] PCI/VGA: Fixup the firmware fb address om demanding time
config: parisc64-defconfig
(https://download.01.org/0day-ci/archive
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
+#define DRV_DATE "202305161"
The date is not correct here, generally it should have 8 numbers,
while you have 9 digits, why you are so special ?
I'm also interesting in RISCV arch, I got attracted by your patch.
I just wa
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
+if DRM_VERISILICON
+
+config STARFIVE_HDMI
+ bool "Starfive specific extensions HDMI"
+ help
+ This selects support for StarFive SoC specific extensions
+ for the Innosilicon HDMI driver. If you want to enable
+ HDMI
Hi,
On 2023/8/1 21:40, suijingfeng wrote:
So, you patch will be pass the compile test, I guess.
You patch will *NOT* pass the compile test, I guess.
Hi,
On 2023/8/1 18:10, Keith Zhao wrote:
Implement drm device registration interface
Signed-off-by: Keith Zhao
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/verisilicon/Kconfig | 25 ++
Hi,
Gentle ping for this series.
On 2023/6/26 22:33, Sui Jingfeng wrote:
Return -ENOMEM if tegra_bo_mmap() fails.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/tegra/gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
Hi,
On 2023/7/27 17:22, AngeloGioacchino Del Regno wrote:
Il 06/07/23 15:40, Sui Jingfeng ha scritto:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap
function")
Hi,
Thanks a lot!
On 2023/7/27 09:47, CK Hu (胡俊光) wrote:
Hi, Jingfeng:
On Thu, 2023-07-06 at 21:40 +0800, Sui Jingfeng wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
> Also return -ENOMEM if such a failure
Hi,
On 2023/7/25 02:34, Thomas Zimmermann wrote:
Hi
Am 18.07.23 um 07:40 schrieb suijingfeng:
Hi,
Actually, I'm only a little bit worry about the ast_pm_thaw() code
path.
|- ast_pm_thaw()
|-- ast_drm_thaw()
|--- ast_post_gpu()
I'm not quite sure what mean here, because the post
PING, please !
On 2023/7/11 21:43, Sui Jingfeng wrote:
From: Sui Jingfeng
The vga_update_device_decodes() function is NOT a trivial function, It is
not performance critical either. So, drop the inline.
This patch also make the parameter and argument consistent, use unsigned
int type instead
PING, please !
On 2023/7/11 21:43, Sui Jingfeng wrote:
From: Sui Jingfeng
In the vga_arbiter_notify_clients() function, the value of the 'new_state'
variable will be 'false' on systems that have more than one PCI VGA card.
Its value will be 'true' on systems that have one or no PCI VGA
Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote:
"drm/loongson: Add an implement for ..." also solves a problem, but it
lacks a commit log, so I don't know what the problem is.
I have already telling you one yeas ago.
I want remove the pci_fixup_vgadev() function in arch/loongarch/pci/pci.c
I
Hi,
Thanks for you noticed my change.
On 2023/7/20 03:32, Bjorn Helgaas wrote:
@@ -1509,13 +1543,24 @@ static int pci_notify(struct notifier_block *nb,
unsigned long action,
* cases of hotplugable vga cards.
*/
- if (action == BUS_NOTIFY_ADD_DEVICE)
+ switch
Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote:
2) It does not take the PCI Bar may get relocated into consideration.
3) It is not effective for the PCI device without a dedicated VRAM Bar.
4) It is device-agnostic, thus it has to waste the effort to iterate all
of the PCI Bar to find the VRAM
Hi,
I was too hurry reply to you. I'm may miss the point for part of your
reviews, Sorry.
On 2023/7/20 03:32, Bjorn Helgaas wrote:
CONFIG_DRM_AST is a tristate. We're talking about identifying the
boot-time console device.
Yes, my patch will only works *after* the module gets loaded
Hi,
On 2023/7/20 02:26, Bjorn Helgaas wrote:
Optimization is fine, but the most important thing here is to be clear
about what functional change this patch makes. As I mentioned at [1],
if this patch affects the class codes accepted, please make that clear
here.
Reviewed-by: Mario
Hi,
On 2023/7/20 18:07, Maxime Ripard wrote:
On Wed, Jul 19, 2023 at 09:12:14PM +0200, Javier Martinez Canillas wrote:
suijingfeng writes:
Hi,
On 2023/7/10 15:47, Maxime Ripard wrote:
[...]
+
+/**
+ * drm_kunit_helper_context_alloc - Allocates an acquire context
+ * @test: The test
On 2023/7/20 03:32, Bjorn Helgaas wrote:
but I think it's just confusing to
mention this in the commit log, so I would just remove it.
Ok, will be done at the next version.
Hi,
On 2023/7/20 03:32, Bjorn Helgaas wrote:
[+cc linux-pci (please cc in the future since the bulk of this patch
is in drivers/pci/)]
On Wed, Jul 12, 2023 at 12:43:05AM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, the strategy of selecting the default boot on a multiple video
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
The observation behind this is that we should avoid accessing the global
screen_info
Hi,
On 2023/7/20 05:13, Sui Jingfeng wrote:
Otherwise there 30+ noisy(useless) events got snooped. See below:
```
[ 0.246077] pci :01:00.0: vgaarb: setting as boot VGA device
[ 0.246077] pci :01:00.0: vgaarb: bridge control possible
[ 0.246077] pci :01:00.0: vgaarb: VGA
Hi,
On 2023/7/20 04:43, Bjorn Helgaas wrote:
On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
This patch adds the aperture_contain_firmware_fb() function to do the
determination. Unfortunately, due to the fact that the apertures list
will be freed
On 2023/7/20 03:58, Sui Jingfeng wrote:
On the other hand, even though the lest significant 8 but if
pdev->class is really matter.
If the low eight bits of pdev->class is really matters,
maybe we should wait the potential problems became severe.
Currently, it is not obvious.
On 2023/7/20 03:58, Sui Jingfeng wrote:
My explanation about the minor tweak being made before this version
and previous version
is that I want to keep my patch *less distraction*.
The minor tweak being made between this version and previous version is
to keep my patch *less
On 2023/7/20 03:58, Sui Jingfeng wrote:
What this version adds here is *same* before this patch set is applied.
The filter method is *same* , in the cases of before this patch is
applied and after this patch is applied.
Hi,
This version is ok, I'll apply this patch within a few days.
On 2023/7/19 16:45, Dan Carpenter wrote:
This code doesn't check for lsdc_bo_create() failure and it could lead
to a crash. It can fail for a variety of reasons, but the most common
cause would be low memory. Add a check.
Hi,
I still remember you are helps to review the drm/lsdc patch one years
ago, see [1].
drm/lsdc is the former version of drm/loongson, originally drm/lsdc
are embedded SoCs of Loongson.
[1] https://patchwork.freedesktop.org/patch/471997/?series=99512=5
I haven't forget about you.
On
Hi,
On 2023/7/18 16:12, Lucas Stach wrote:
Hi Jingfeng,
Am Dienstag, dem 18.07.2023 um 02:34 +0800 schrieb suijingfeng:
Hi, Lucas
Thanks for you guidance!
On 2023/7/17 17:51, Lucas Stach wrote:
Hi Jingfeng,
Am Freitag, dem 23.06.2023 um 18:08 +0800 schrieb Sui Jingfeng:
From: Sui
Hi,
On 2023/7/18 21:59, Dan Carpenter wrote:
People have suggested that I misread this and that "bare brain" means
through code review instead of testing. In context that seems to make
sense.
Sorry.
Sorry for my broken English, that's really a misunderstanding.
Anyway, the fixes tag is
across)
to multiple thread.
Sorry for my broken English. I will improve my written skill in the long
term.
Thanks for you contribution.
regards,
dan carpenter
On Tue, Jul 18, 2023 at 08:32:02PM +0800, suijingfeng wrote:
Hi,
Thanks for the patch.
The commit title generally should
"drm/loongson: Add a check for lsdc_bo_create() errors"
On 2023/7/18 15:01, Dan Carpenter wrote:
The lsdc_bo_create() function can fail so add a check for that.
Fixes: f39db26c5428 ("drm: Add kms driver for loongson display controller")
Signed-off-by: Dan Carpenter
---
Hi,
Thanks for the patch.
The commit title generally should be 'drm/looongson: Add a check for
lsdc_bo_create() errors'
not 'drm: loongson: '
On 2023/7/18 15:01, Dan Carpenter wrote:
The lsdc_bo_create() function can fail so add a check for that.
Fixes: f39db26c5428 ("drm: Add kms
Hi,
Actually, I'm only a little bit worry about the ast_pm_thaw() code path.
|- ast_pm_thaw()
|-- ast_drm_thaw()
|--- ast_post_gpu()
Except this, all other code path have pci_enable_device() or
pcim_enable_device() called.
So, this patch seems OK.
On 2023/7/12 21:08, Thomas
Hi,
I have tested this patch on my x86-64(i3-8100, H110 D4L board) + ast2400
discrete BMC card just now,
drm/ast still works on normal case.
But originally this function is called in ast_post_gpu() function.
ast_post_gpu() doesn't happen on my test case.
I know something about the POST
Hi, Lucas
Thanks for you guidance!
On 2023/7/17 17:51, Lucas Stach wrote:
Hi Jingfeng,
Am Freitag, dem 23.06.2023 um 18:08 +0800 schrieb Sui Jingfeng:
From: Sui Jingfeng
Because it is not used by the etnaviv_gem_new_impl() function,
no functional change.
I think it would make sense to
Hi,
On 2023/7/10 15:47, Maxime Ripard wrote:
The new helper to init the locking context allows to remove some
boilerplate.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_test_pv_muxing.c | 42 --
1 file changed, 19 insertions(+), 23 deletions(-)
Hi,
On 2023/7/10 15:47, Maxime Ripard wrote:
As we get more and more tests, the locking context initialisation
creates more and more boilerplate, both at creation and destruction.
Let's create a helper that will allocate, initialise a context, and
register kunit actions to clean up once the
Hi,
On 2023/7/10 15:47, Maxime Ripard wrote:
As we get more and more tests, the locking context initialisation
creates more and more boilerplate, both at creation and destruction.
Let's create a helper that will allocate, initialise a context, and
register kunit actions to clean up once the
Hi,
On 2023/7/10 15:47, Maxime Ripard wrote:
Hi,
Since v6.5-rc1, kunit gained a devm/drmm-like mechanism that makes tests
resources much easier to cleanup.
This series converts the existing tests to use those new actions were
relevant.
Is the word 'were' here means that 'where' relevant ?
Hi,
Fixes: f6b1772b2555 ('vgaarb: remove the unused irq_set_state argument
to vga_client_register')
Because after applied that patch, there have only one callback mechanism
we can use, not two anymore.
On 2023/7/12 00:43, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, the strategy
On 2023/7/17 21:17, Sui Jingfeng wrote:
So without we can craft something new easily without significant change.
Therefore, We can *NOT* craft something new easily without significant
change.
Especially userspace changes.
So my current patch choose to keep the original behavior.
At the
Hi,
On 2023/7/17 18:07, Lucas Stach wrote:
Am Freitag, dem 23.06.2023 um 18:08 +0800 schrieb Sui Jingfeng:
From: Sui Jingfeng
This make the code in etnaviv_pdev_probe() less twisted, drop the reference
to device node after finished. Also kill a double blank line.
I can't spot the double
Hi,
On 2023/7/11 21:43, Sui Jingfeng wrote:
From: Sui Jingfeng
Currently, vgaarb only cares about PCI VGA-compatible class devices.
While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
device is about to be removed. This happens even during the boot process.
Another
Hi, Dear etnaviv folks
Would you like to review this cleanup patch set ?
I am asking because I'm wondering that
if I should re-spin my other patch from the code base
which *with* this series applied or from the code base
*without* this series applied.
I think this series looks fine, is it
Hi,
On 2023/7/10 15:58, Thomas Zimmermann wrote:
Include to get the global screen_info state.
Fixes the following errors:
drivers/video/fbdev/hyperv_fb.c:1033:10: error: use of undeclared identifier
'screen_info'
1033 | base = screen_info.lfb_base;
|
Hi,
On 2023/7/10 18:26, Jani Nikula wrote:
On Mon, 10 Jul 2023, Sui Jingfeng wrote:
When accessing I/O memory, we should pass '__iomem *' type instead of
'void *' simply, otherwise sparse tests will complain. After applied
this patch, the following two sparse warnings got fixed.
Usually the
Hi,
On 2023/7/10 18:26, Jani Nikula wrote:
On Mon, 10 Jul 2023, Sui Jingfeng wrote:
When accessing I/O memory, we should pass '__iomem *' type instead of
'void *' simply, otherwise sparse tests will complain. After applied
this patch, the following two sparse warnings got fixed.
Usually the
Hi,
On 2023/7/10 18:39, Thomas Zimmermann wrote:
Am 10.07.23 um 12:24 schrieb Sui Jingfeng:
Because smatch warnings:
drivers/gpu/drm/loongson/lsdc_plane.c:199
lsdc_cursor_plane_atomic_async_check()
warn: variable dereferenced before check 'state' (see line 180)
vim +/state +199
Hi,
On 2023/7/10 15:19, Thomas Zimmermann wrote:
Hi
Am 10.07.23 um 09:02 schrieb suijingfeng:
Hi,
Thanks for testing,
What do you means about tell me this?
I means that would you like to help fixing this warning?
The code in drm_atomic_get_new_plane_state() dereferences the state
Hi,
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 8d1077cf2e43b15fefd76ebec2b71541eb27ef2c
commit: f39db26c54281da6a785259498ca74b5e470476f [2/3] drm: Add kms driver for
loongson display controller
config:
Hi,
Thanks for testing,
What do you means about tell me this?
I means that would you like to help fixing this warning?
Or otherwise, I will fix this someday.
On 2023/7/10 14:29, Dan Carpenter wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head:
OK, thanks a lot,
done!
On 2023/7/10 13:20, Michael Kelley (LINUX) wrote:
From: Sui Jingfeng Sent: Sunday, July 9, 2023 3:05 AM
drivers/video/fbdev/hyperv_fb.c: In function 'hvfb_getmem':
drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared (first
use
in this
Hi, Deepak and Michael
Would you like to review this trivial patch ?
Please help to push this to drm/hyperv, because kernel test robots are
crying.
On 2023/7/10 10:57, kernel test robot wrote:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head:
Hi,
On 2023/7/6 20:47, AngeloGioacchino Del Regno wrote:
Il 26/06/23 20:58, Sui Jingfeng ha scritto:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
This commit needs a Fixes tag. Please add the
Hi, thanks a lot!
On 2023/7/6 20:13, Alexandre Mergnat wrote:
On 26/06/2023 20:58, Sui Jingfeng wrote:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Reviewed-by: Alexandre Mergnat
Hi, Thanks a lot!
On 2023/7/6 19:39, Matthias Brugger wrote:
On 26/06/2023 20:58, Sui Jingfeng wrote:
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c |
Hi,
On 2023/7/5 18:29, Geert Uytterhoeven wrote:
Hi Sui,
On Tue, Jun 27, 2023 at 4:57 PM Sui Jingfeng wrote:
On 2023/6/22 17:21, Geert Uytterhoeven wrote:
When the device is unbound from the driver, the display may be active.
Make sure it gets shut down.
would you mind to give a short
Hi,
On 2023/6/30 01:44, Limonciello, Mario wrote:
[Public]
-Original Message-
From: 15330273...@189.cn <15330273...@189.cn>
Sent: Thursday, June 29, 2023 12:00 PM
To: Bjorn Helgaas ; Sui Jingfeng
Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
Cornelia Huck ; Karol Herbst ;
should replace '@' with '*'
Signed-off-by: suijingfeng
---
include/drm/ttm/ttm_device.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 4f3e81eac6f3..56e82ba2d046 100644
--- a/include/drm/ttm/ttm_device.h
Signed-off-by: suijingfeng <15330273...@189.cn>
---
drivers/dma-buf/dma-buf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 757c0fb77a6c..45d56aa4319c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drive
From: suijingfeng
This patch add myself as maintainer to fix following warning when run
./scripts/checkpatch.pl
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
Signed-off-by: suijingfeng
Signed-off-by: suijingfeng <15330273...@189.cn>
---
MAINTAINE
From: suijingfeng
Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.
This display controller is a PCI device, it has two display pipe
From: suijingfeng
Loongson display controller IP has been integrated in both Loongson
North Bridge chipset(ls7a1000 and ls7a2000) and Loongson SoCs(ls2k1000
and ls2k2000 etc), it even has been included in Loongson BMC products.
This display controller is a PCI device, it has two display pipe
From: suijingfeng
This patch add myself as maintainer to fix following warning
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
Signed-off-by: suijingfeng
Signed-off-by: suijingfeng <15330273...@189.cn>
---
MAINTAINERS | 7 +++
1 file changed, 7 inse
1 - 100 of 111 matches
Mail list logo
