From: Luben Tuikov <luben.tuikov@amd.com>
To: Alex Deucher <alexdeucher@gmail.com>
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>,
Nirmoy <nirmodas@amd.com>,
amd-gfx list <amd-gfx@lists.freedesktop.org>,
Nirmoy Das <nirmoy.das@amd.com>,
"Deucher, Alexander" <alexander.deucher@amd.com>,
Christian Koenig <christian.koenig@amd.com>
Subject: Re: [RFC PATCH 1/1] drm/amdgpu: add initial support for pci error handler
Date: Fri, 14 Aug 2020 16:20:17 -0400 [thread overview]
Message-ID: <87f76e32-eecb-ed6e-b117-e5402c944638@amd.com> (raw)
In-Reply-To: <CADnq5_NhPJ8+QsAfzHEha-1i_B0UcgwFA-X0P-NAskUhZzmZPg@mail.gmail.com>
On 2020-08-14 4:10 p.m., Alex Deucher wrote:
>> I see DRM as more of a unifying layer (perhaps long term), as opposed
>> to a *library* which LLDDs call into. Then LLDDs would provide an interface
>> to the hardware. This will help us avoid many of the deadlocks and
>> synchronization issues which were outlined in a recent memory presentation.
>> It will also help us avoid code redundancy in LLDDs.
>
> We are actually trying to move away from that model. drm started out
> as a midlayer and it caused all kinds of pain. E.g., some drm devices
> are usb devices, some are pci, some are platform devices, etc. A flow
> that worked for one didn't always work well for another. In general
> we should follow the driver model for the specific device model of
> your driver and then use drm helper functions to deal with the core
> drm functionality. E.g., drm shouldn't be in the business of dealing
> with pci power management. The driver should interact directly with
> the pci subsystem for that.
Ah, thanks Alex for the clarification. So a library of sorts--got it.
Regards,
Luben
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
prev parent reply other threads:[~2020-08-14 20:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 13:30 [RFC PATCH 1/1] drm/amdgpu: add initial support for pci error handler Nirmoy Das
2020-08-12 14:52 ` Andrey Grodzovsky
2020-08-13 11:09 ` Nirmoy
2020-08-13 13:36 ` Alex Deucher
2020-08-13 13:38 ` Andrey Grodzovsky
2020-08-13 15:06 ` Nirmoy
2020-08-13 18:18 ` Andrey Grodzovsky
2020-08-13 21:17 ` Luben Tuikov
2020-08-13 21:30 ` Luben Tuikov
2020-08-14 15:23 ` Nirmoy
2020-08-14 19:52 ` Luben Tuikov
2020-08-14 20:10 ` Alex Deucher
2020-08-14 20:20 ` Luben Tuikov [this message]
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=87f76e32-eecb-ed6e-b117-e5402c944638@amd.com \
--to=luben.tuikov@amd.com \
--cc=Andrey.Grodzovsky@amd.com \
--cc=alexander.deucher@amd.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=nirmodas@amd.com \
--cc=nirmoy.das@amd.com \
/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