Hi Joe.
> My preference would also convert all the
> DRM_DEV_ uses to drm_dev_ eventually.
>
> Also, the macros themselves could change to use a
> more consistent mechanism.
>
> This would make the drm logging mechanisms more like
> other logging mechanisms used in the kernel.
>
> Something lik
On Fri, 2019-02-01 at 14:37 +0100, Sam Ravnborg wrote:
> Hi Thierry.
>
> > I'm slightly on the fence about this patch.
>
> Please ignore patch 3-19, there is no consensus on the logging changes.
> We do not want to apply these and then have to redo parts/all of
> it later.
>
> But the first two
Hi Thierry.
> I'm slightly on the fence about this patch.
Please ignore patch 3-19, there is no consensus on the logging changes.
We do not want to apply these and then have to redo parts/all of
it later.
But the first two patches has not seen any feedback yet:
[PATCH v1 01/19] drm/panel: d
On Fri, 01 Feb 2019, Andrzej Hajda wrote:
> On 01.02.2019 11:30, Jani Nikula wrote:
>> On Fri, 01 Feb 2019, Sam Ravnborg wrote:
>>> Hi Thierry.
>>>
I personally like the DRM_DEV_* variants better because of the
additional information that they provide. That can be useful when
grepp
On 01.02.2019 11:30, Jani Nikula wrote:
> On Fri, 01 Feb 2019, Sam Ravnborg wrote:
>> Hi Thierry.
>>
>>> I personally like the DRM_DEV_* variants better because of the
>>> additional information that they provide. That can be useful when
>>> grepping logs etc.
>>>
>>> I'm slightly on the fence abo
On Fri, 01 Feb 2019, Sam Ravnborg wrote:
> Hi Thierry.
>
>>
>> I personally like the DRM_DEV_* variants better because of the
>> additional information that they provide. That can be useful when
>> grepping logs etc.
>>
>> I'm slightly on the fence about this patch. The unwritten, and
>> admitte
Hi Thierry.
>
> I personally like the DRM_DEV_* variants better because of the
> additional information that they provide. That can be useful when
> grepping logs etc.
>
> I'm slightly on the fence about this patch. The unwritten, and
> admittedly fuzzy, rules that I've been using so far are tha
On Thu, Jan 31, 2019 at 10:03:12PM +0100, Sam Ravnborg wrote:
> Hi Sean.
>
> > Hey Sam,
> > Thanks for the patchset, this will make dmesg grepping easier! One comment,
> > and
> > you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
> >
> > When I introduced DRM_DEV, it was to cove
Hi Sean.
> Hey Sam,
> Thanks for the patchset, this will make dmesg grepping easier! One comment,
> and
> you're going to hate me for it: Why use DRM_DEV* instead of DRM_*?
>
> When I introduced DRM_DEV, it was to cover the case where there are multiple
> instances of the same driver (ie: dual-c
On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address the above it
Hi all.
On Thu, Jan 31, 2019 at 08:26:00PM +0100, Sam Ravnborg wrote:
> Hi Thierry et al.
>
> While reviewing a number of new panel drivers there was a
> certain pattern in the feedback:
> - the now deprecated drmP.h file was used
> - dev_err() and friends was used
>
> This patch-set address the
Hi Thierry et al.
While reviewing a number of new panel drivers there was a
certain pattern in the feedback:
- the now deprecated drmP.h file was used
- dev_err() and friends was used
This patch-set address the above items in the panel
drivers in drm/panel/
The hope is that new panel drivers will
12 matches
Mail list logo
