From: Thomas Zimmermann <tzimmermann@suse.de>
To: Binbin Zhou <zhoubb.aaron@gmail.com>
Cc: Binbin Zhou <zhoubinbin@loongson.cn>,
Huacai Chen <chenhuacai@loongson.cn>, Lee Jones <lee@kernel.org>,
Corey Minyard <minyard@acm.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Huacai Chen <chenhuacai@kernel.org>,
linux-kernel@vger.kernel.org,
openipmi-developer@lists.sourceforge.net,
dri-devel@lists.freedesktop.org, Xuerui Wang <kernel@xen0n.name>,
loongarch@lists.linux.dev, Chong Qiao <qiaochong@loongson.cn>
Subject: Re: [PATCH v1 3/4] drm/ls2kbmc: Add support for Loongson-2K BMC display
Date: Mon, 6 Jan 2025 15:10:24 +0100 [thread overview]
Message-ID: <392f855c-4474-4e12-8bdc-3baf43d34e13@suse.de> (raw)
In-Reply-To: <CAMpQs4L38rDEDYM64jJ6pO+g=M4+etKN9v9+ygzkLY6RQgu94A@mail.gmail.com>
Hi,
Thanks for the info.
Am 06.01.25 um 08:03 schrieb Binbin Zhou:
[...]
>> Could you point to the exact call that fails within simpledrm?
> If we use simpledrm directly, the following error occurs:
>
> [ 8.289823] simple-framebuffer simple-framebuffer.0: [drm] *ERROR*
> could not acquire memory range [mem 0xe0031200000-0xe00315fffff flags
> 0x200]: -16
> [ 8.312681] simple-framebuffer simple-framebuffer.0: probe with
> driver simple-framebuffer failed with error -16
>
> The reason for the failure: overlapping resources.
>
> https://elixir.bootlin.com/linux/v6.12.6/source/drivers/video/aperture.c#L175
This error means that there's already an instance of simpledrm bound to
the BMC framebuffer. So you already have a working display and some
graphics under Linux without the new driver, right?
If so, why do you need a new driver that does exactly the same as simpledrm?
Best regards
Thomas
>>> Because although we register the driver in platform form, its memory
>>> belongs to pci space and we can see the corresponding pci probe and
>>> resource allocation in Patch-1.
>> I don't understand. Graphics memory is often located on the PCI bus.
>> What is so special about this one?
>>
>>> Therefore, we need to use aperture_remove_conflicting_pci_devices().
>> So there is already a device that represents the graphics card? That's
>> what you'd remove here? If you only add that MFD device, who owns the
>> framebuffer? If it's the PCI device from patch 1 ("ls2k-bmc"), why does
>> aperture_remove_conflicting_pci_devices() not remove that device? I'm
>> somewhat confused, because the logic in your driver mostly looks like it
>> binds to a pre-configured framebuffer, but some of the code doesn't.
> Perhaps the use of aperture_remove_conflicting_pci_devices() is wrong,
> as there is only one display device for the LS2K BMC and there will be
> no phase conflict.
>
> When I tried to use that API before, it was partly due to the error
> above, and partly because I referenced that other display drivers via
> pci_driver.probe() would have it, just in case I used it, which was
> probably the wrong choice.
>
> The resources for pci bar0 are as follows:
> BAR0: e0030000000/SZ_32M
>
> 0x0 0x600000 0xf00001c 16M 32M
> +----+--------------+--------+-----------+---+-----------------+
> | 2M | simpldrm | | IPMI | | video env |
> +-----------------------------------------------------------------+
>
> The mfd driver registers the ls2kbmc-framebuffer and ls2k-ipmi-si
> devices according to the resource allocation shown above. At the same
> time, the ls2kbmc drm is bound to the pre-configured “simpldrm”
> resource in the above figure, which is passed through the
> ls2kbmc-framebuffer driver. In addition, the resolution is read from
> “video env” for the time being, and the resolution adaption is planned
> to be added later.
>
>> Best regards Thomas
>>
>>> Also, since we are using BMC display, the display will be disconnected
>>> when BMC reset, at this time we need to push the display data (crtc,
>>> connector, etc.) manually as shown in Patch-4.
>>>
>>> Probably it's not the most suitable way to implement it.
>>>
>>>> Best regards
>>>> Thomas
>>>>
>>>>> + },
>>>>> + .probe = ls2kbmc_probe,
>>>>> + .remove = ls2kbmc_remove,
>>>>> +};
>>>>> +
>>>>> +module_platform_driver(ls2kbmc_platform_driver);
>>>>> +
>>>>> +MODULE_DESCRIPTION("DRM driver for Loongson-2K BMC");
>>>>> +MODULE_LICENSE("GPL");
>>>> --
>>>> --
>>>> Thomas Zimmermann
>>>> Graphics Driver Developer
>>>> SUSE Software Solutions Germany GmbH
>>>> Frankenstrasse 146, 90461 Nuernberg, Germany
>>>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>>>> HRB 36809 (AG Nuernberg)
>>>>
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>
>
> --
> Thanks.
> Binbin
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
next prev parent reply other threads:[~2025-01-06 14:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-30 9:31 [PATCH v1 0/4] LoongArch: Add Loongson-2K0500 BMC support Binbin Zhou
2024-12-30 9:31 ` [PATCH v1 1/4] mfd: ls2kbmc: Introduce Loongson-2K BMC MFD Core driver Binbin Zhou
2024-12-30 9:31 ` [PATCH v1 2/4] ipmi: Add Loongson-2K BMC support Binbin Zhou
2024-12-31 12:37 ` kernel test robot
2025-01-03 4:29 ` kernel test robot
2024-12-30 9:31 ` [PATCH v1 3/4] drm/ls2kbmc: Add support for Loongson-2K BMC display Binbin Zhou
2025-01-02 9:07 ` Thomas Zimmermann
2025-01-02 12:55 ` Binbin Zhou
2025-01-02 13:32 ` Thomas Zimmermann
2025-01-06 1:56 ` Binbin Zhou
2025-01-06 7:03 ` Binbin Zhou
2025-01-06 14:10 ` Thomas Zimmermann [this message]
2025-01-09 12:56 ` Binbin Zhou
2025-01-15 8:48 ` Thomas Zimmermann
2024-12-30 9:31 ` [PATCH v1 4/4] drm/ls2kbmc: Add Loongson-2K BMC reset function support Binbin Zhou
2025-01-15 8:57 ` Thomas Zimmermann
2025-02-11 11:27 ` Binbin Zhou
2025-03-25 12:39 ` Binbin Zhou
2025-03-31 7:53 ` Thomas Zimmermann
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=392f855c-4474-4e12-8bdc-3baf43d34e13@suse.de \
--to=tzimmermann@suse.de \
--cc=airlied@gmail.com \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=dri-devel@lists.freedesktop.org \
--cc=kernel@xen0n.name \
--cc=lee@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=loongarch@lists.linux.dev \
--cc=maarten.lankhorst@linux.intel.com \
--cc=minyard@acm.org \
--cc=mripard@kernel.org \
--cc=openipmi-developer@lists.sourceforge.net \
--cc=qiaochong@loongson.cn \
--cc=simona@ffwll.ch \
--cc=zhoubb.aaron@gmail.com \
--cc=zhoubinbin@loongson.cn \
/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
all inboxes | Powered by JetHome®