On Fri, Feb 17, 2023 at 08:38:28PM +0100, Daniel Vetter wrote:
> > > > > I'm firmly in the camp that debugfs does not need to work under all
> > > > > conditions, but that it must fail gracefully instead of crashing.
> > > > Yeah I mean once we talk bring-up, you can just hand-roll the necessary
>
Am 17.02.23 um 20:38 schrieb Daniel Vetter:
On Fri, Feb 17, 2023 at 11:01:18AM +0100, Stanislaw Gruszka wrote:
On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
Am 16.02.23 um 20:54 schrieb Daniel Vetter:
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
On Thu, 16 F
Am 17.02.23 um 20:42 schrieb Daniel Vetter:
On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote:
Am 17.02.23 um 13:37 schrieb Jani Nikula:
On Fri, 17 Feb 2023, Christian König wrote:
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not ma
On Fri, Feb 17, 2023 at 04:55:27PM +0100, Christian König wrote:
> Am 17.02.23 um 13:37 schrieb Jani Nikula:
> > On Fri, 17 Feb 2023, Christian König
> > wrote:
> > > If i915 have such structural problems then I strongly suggest to solve
> > > them inside i915 and not make common code out of that
On Fri, Feb 17, 2023 at 11:01:18AM +0100, Stanislaw Gruszka wrote:
> On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
> > Am 16.02.23 um 20:54 schrieb Daniel Vetter:
> > > On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> > > > On Thu, 16 Feb 2023, Christian König wrot
Am 17.02.23 um 13:37 schrieb Jani Nikula:
On Fri, 17 Feb 2023, Christian König wrote:
If i915 have such structural problems then I strongly suggest to solve
them inside i915 and not make common code out of that.
All other things aside, that's just a completely unnecessary and
unhelpful remark.
On Fri, 17 Feb 2023, Christian König wrote:
> If i915 have such structural problems then I strongly suggest to solve
> them inside i915 and not make common code out of that.
All other things aside, that's just a completely unnecessary and
unhelpful remark.
BR,
Jani.
--
Jani Nikula, Intel Op
Am 17.02.23 um 12:36 schrieb Stanislaw Gruszka:
On Fri, Feb 17, 2023 at 12:49:41PM +0200, Jani Nikula wrote:
On Fri, 17 Feb 2023, Stanislaw Gruszka
wrote:
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
But should not this the driver responsibility, call drm_debugfs_add_file()
w
On Fri, Feb 17, 2023 at 12:49:41PM +0200, Jani Nikula wrote:
> On Fri, 17 Feb 2023, Stanislaw Gruszka
> wrote:
> > On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
> >> >
> >> > But should not this the driver responsibility, call
> >> > drm_debugfs_add_file()
> >> > whenever you are
On Fri, 17 Feb 2023, Stanislaw Gruszka
wrote:
> On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
>> >
>> > But should not this the driver responsibility, call drm_debugfs_add_file()
>> > whenever you are ready to handle operations on added file ?
>>
>> In theory, yes, but in practice
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
> >
> > But should not this the driver responsibility, call drm_debugfs_add_file()
> > whenever you are ready to handle operations on added file ?
>
> In theory, yes, but in practice it's pretty hard for a non-trivial
> driver to maintai
On Fri, Feb 17, 2023 at 10:22:25AM +0100, Christian König wrote:
> Am 16.02.23 um 20:54 schrieb Daniel Vetter:
> > On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> > > On Thu, 16 Feb 2023, Christian König wrote:
> > > > Am 16.02.23 um 17:46 schrieb Jani Nikula:
> > > > > On Thu, 16 F
Am 16.02.23 um 20:54 schrieb Daniel Vetter:
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
On Thu, 16 Feb 2023, Christian König wrote:
Am 16.02.23 um 17:46 schrieb Jani Nikula:
On Thu, 16 Feb 2023, Christian König wrote:
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb
On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Stanislaw Gruszka
> wrote:
> > On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> >> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> >> > The mutex was completely pointless in the
On Thu, Feb 16, 2023 at 07:08:49PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2023, Christian König wrote:
> > Am 16.02.23 um 17:46 schrieb Jani Nikula:
> >> On Thu, 16 Feb 2023, Christian König wrote:
> >>> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
> On Thu, Feb 09, 2023 at 09:18:38AM +01
On Thu, 16 Feb 2023, Stanislaw Gruszka
wrote:
> On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
>> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
>> > The mutex was completely pointless in the first place since any
>> > parallel adding of files to this list would
On Thu, 16 Feb 2023, Christian König wrote:
> Am 16.02.23 um 17:46 schrieb Jani Nikula:
>> On Thu, 16 Feb 2023, Christian König wrote:
>>> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> The mutex was completely pointless in
Am 16.02.23 um 17:46 schrieb Jani Nikula:
On Thu, 16 Feb 2023, Christian König wrote:
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
The mutex was completely pointless in the first place since any
parallel adding of files to this l
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > behavior since the list is fille
On Thu, 16 Feb 2023, Christian König wrote:
> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
>> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
>>> The mutex was completely pointless in the first place since any
>>> parallel adding of files to this list would result in random
>>> beh
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > behavior since the list is fille
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> The mutex was completely pointless in the first place since any
> parallel adding of files to this list would result in random
> behavior since the list is filled and consumed multiple times.
>
> Completely drop that approach and j
On Tue, Feb 14, 2023 at 01:19:51PM +0100, Stanislaw Gruszka wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > -void drm_debugfs_late_register(struct drm_device *dev)
> > -{
> > - struct drm_minor *minor = dev->primary;
> > - struct drm_debugfs_entry *entry, *tmp;
> >
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> -void drm_debugfs_late_register(struct drm_device *dev)
> -{
> - struct drm_minor *minor = dev->primary;
> - struct drm_debugfs_entry *entry, *tmp;
> -
> - if (!minor)
> - return;
> -
> - list_for_each_en
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
Completely drop that approach and just create the files directly.
This also re-adds the debugfs files to the
26 matches
Mail list logo
