Quoting Chris Wilson (2018-04-24 02:08:39)
> printk unhelpfully inserts a '\n' between consecutive calls, and since
> our drm_printf wrapper may be emitting info a seq_file instead,
> KERN_CONT is not an option. To work with any drm_printf destination, we
> need to build up the output into a tempor
Quoting Tvrtko Ursulin (2018-04-24 12:57:41)
>
> On 24/04/2018 02:08, Chris Wilson wrote:
> > printk unhelpfully inserts a '\n' between consecutive calls, and since
> > our drm_printf wrapper may be emitting info a seq_file instead,
> > KERN_CONT is not an option. To work with any drm_printf desti
On 24/04/2018 02:08, Chris Wilson wrote:
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf
Quoting Chris Wilson (2018-04-24 02:08:39)
> printk unhelpfully inserts a '\n' between consecutive calls, and since
> our drm_printf wrapper may be emitting info a seq_file instead,
> KERN_CONT is not an option. To work with any drm_printf destination, we
> need to build up the output into a tempor
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete lin
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete lin
