I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I re
If we store the fb funcs pointer, we can remove a bit of boilerplate.
Also remove the _fbdev_ in the example code, since the fb_funcs->dirty
callback has nothing to do with fbdev. It's a KMS feature, only
used by the fbdev deferred_io support to implement flushing/upload.
Cc: Noralf Trønnes
Cc:
We forgot to clean this up when adding connector refcounting.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 8eab8944c736..5e5224460042 1
Drive-by polish.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_rect.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index e6057d8cdcd5..bc5575960ebc 100644
--- a/drivers/gpu/drm/drm_re
The new cool is &struct foo (kernel-doc now copes with linebreaks),
and structure members should be referenced using &foo.bar.
Cc: Jani Nikula
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
Documentation/gpu/introduction.rst | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-
I've forgotten to remove this when revamping the
connector_list locking.
Cc: seanpaul at chromium.org
Signed-off-by: Daniel Vetter
---
include/drm/drm_connector.h | 6 +-
include/drm/drm_crtc.h | 14 --
2 files changed, 1 insertion(+), 19 deletions(-)
diff --git a/include/
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i
Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Cc: Sumit Semwal
Cc: Jani Nikula
Cc: Chris Wilson
Signe
sed -e 's/\( \* .*\)struct &\([_a-z]*\)/\1\&struct \2/' -i
Originally I wasnt a friend of this style because I thought a
line-break between the "&struct" and "foo" part would break it. But a
quick test shows that " * &struct \n * foo\n" works pefectly well with
current kernel-doc. So time to mass-
Added some boilerplate for the structs, documented members where they
are relevant and plenty of markup for hyperlinks all over. And a few
small wording polish.
Note that the intro needs some more love after the DRM_MM_INSERT_*
patch from Chris has landed.
v2: Spelling fixes (Chris).
v3: Use &st
Our style guide should only be the delta compared to the overall one.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
Documentation/gpu/introduction.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/gpu/introduction.rst
b/Documentation/gpu/introduction.rst
index 1903595
- Remove the outdated hunk about driver documentation which somehow
got misplaced here in the split-up.
- Collect all the testing&validation stuff together and give the CRC
section a heading for prettier output.
Cc: Tomeu Vizoso
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
Documentati
From: Shawn Guo
Function rockchip_crtc_from_pipe() does the exactly same thing as what
crtc helper drm_crtc_from_index() provides. Use the helper to save
some code.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 17 ++---
1 file changed, 2 insertions(+)
From: Shawn Guo
Function zx_find_crtc() does the exactly same thing as what crtc helper
drm_crtc_from_index() provides. Use the helper to save some code.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_vou.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --gi
From: Shawn Guo
It adds a crtc helper drm_crtc_from_index() to find the registered CRTC
with a given index, just like drm_plane_from_index().
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/drm_crtc.c | 20
include/drm/drm_crtc.h | 1 +
2 files changed, 21 insertions(+)
From: Shawn Guo
This is a suggestion from Sean Paul. ZTE and Rockchip DRM drivers have
the similar code to find registered CRTC by given index. The series
create a CRTC helper drm_crtc_from_index() to do the job, just like
drm_plane_from_index() to search plane, and change ZTE, Rockchip driver
ng this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161229/46765e60/attachment-0001.html>
From: Shawn Guo
It enables HDMI audio support through SPDIF interface based on generic
hdmi-audio-codec driver. The HDMI hardware supports more audio
interfaces than SPDIF, like I2S, which may be added later.
Signed-off-by: Shawn Guo
---
Changes for v2:
- Distll the function zx_hdmi_audio_get
On Thu, Dec 22, 2016 at 10:18:00AM -0500, Sean Paul wrote:
> On Thu, Dec 22, 2016 at 8:11 AM, Shawn Guo wrote:
> > +static int zx_hdmi_audio_get_n(unsigned int fs)
> > +{
> > + unsigned int n;
> > +
> > + switch (fs) {
> > + case 32000:
> > + n = 4096;
> > +
This patch adds a small helper function, which clears the cached
information about a hot-pluggable display, from connector. On event
This will run on event of a hot-unplug, keeping the connector's display
info up-to-date, avoiding any errors due to invalid cached data.
Forking this patch out from
Thanks for the review, Jose.
Regards
Shashank
-Original Message-
From: Jose Abreu [mailto:jose.ab...@synopsys.com]
Sent: Thursday, December 29, 2016 11:05 PM
To: Sharma, Shashank ; dri-devel at
lists.freedesktop.org; intel-gfx at lists.freedesktop.org
Cc: Jose Abreu ; Daniel Vetter
Subj
On Thu, Dec 29, 2016 at 3:48 PM, Daniel Vetter
wrote:
> I've forgotten to remove this when revamping the
> connector_list locking.
>
> Cc: seanpaul at chromium.org
Reviewed-by: Sean Paul
> Signed-off-by: Daniel Vetter
> ---
> include/drm/drm_connector.h | 6 +-
> include/drm/drm_crtc.h
Hi Shashank,
On 29-12-2016 12:28, Shashank Sharma wrote:
> This patch adds a small helper function, which clears the cached
> information about a hot-pluggable display, from connector. On event
> This will run on event of a hot-unplug, keeping the connector's display
> info up-to-date, avoiding a
Regards
Shashank
On 12/29/2016 3:35 PM, Jose Abreu wrote:
> Hi Shashank,
>
>
> On 29-12-2016 05:53, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 12/27/2016 3:07 PM, Daniel Vetter wrote:
>>> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
Hi Shashank,
>
From: Colin Ian King
trivial fix to spelling mistake in warn message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/
From: Colin Ian King
trivial fix to spelling mistake in WARN message
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amd
Hi Hans,
On 2016-12-13 16:08, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds the HDMI notifier code, based on Russell's code:
>
> https://patchwork.kernel.org/patch/9277043/
>
> It adds support for it to the exynos_hdmi drm driver, adds support for
> it to the CEC framework
Thanks, applied.
Reviewed-by: Sinclair Yeh
On Sat, Dec 24, 2016 at 01:21:10AM +0530, Shyam Saini wrote:
> When some other buffer is immediately copied into allocated region.
> Replace calls to kmalloc followed by a memcpy with a direct
> call to kmemdup.
>
> Signed-off-by: Shyam Saini
> ---
>
ktop.org/archives/dri-devel/attachments/20161229/1a3593d8/attachment.html>
On Thu, Dec 29, 2016 at 11:31:45AM +, Chris Wilson wrote:
> On Thu, Dec 29, 2016 at 12:09:24PM +0100, Daniel Vetter wrote:
> > Including all drivers. I thought about keeping small compat functions
> > to avoid having to change all drivers. But I really like the
> > drm_printer idea, so figured
Currently at the end of drm_core_init() we print
[0.735185] [drm] Initialized
which does not provide any user information and is only a breadcrumb for
developers, so reduce it from info to debug.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_drv.c | 2 +-
1 file changed, 1 insertion(
On Thu, 29 Dec 2016, Chris Wilson wrote:
> On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote:
>> On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote:
>> > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote:
>> > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_
On Wed, Dec 28, 2016 at 05:42:09PM +0100, Daniel Vetter wrote:
> Useful for dumping lots of data into dmesg, e.g. drm_mm.
>
> Cc: Rob Clark
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_print.c | 6 ++
> include/drm/drm_print.h | 20 ++--
> 2 files changed,
On Thu, Dec 29, 2016 at 11:44:35AM +0100, Daniel Vetter wrote:
> Our style guide should only be the delta compared to the overall one.
The link looks correct, but I still haven't found a good guide on the
style of prose to use; certainly one doesn't stand out from the
instructions on how to write
Including all drivers. I thought about keeping small compat functions
to avoid having to change all drivers. But I really like the
drm_printer idea, so figured spreading it more widely is a good thing.
v2: Review from Chris:
- Natural argument order and better name for drm_mm_print.
- show_mm() ma
On Thu, Dec 29, 2016 at 10:54:29AM +, Chris Wilson wrote:
> On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote:
> > On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote:
> > > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote:
> > > > @@ -230,23 +272,23 @@ static
Hi Sergei,
On Thursday 29 Dec 2016 00:18:40 Sergei Shtylyov wrote:
> Hello.
>
>Here's the set of 2 patches against the 'drm-next' branch of David
> Airlie's 'linux.git' repo. We're switching to the DU compositor for the DU
> driver on the Renesas R8A7794 SoC.
>
> [1/2] drm: rcar-du: support
Our style guide should only be the delta compared to the overall one.
Cc: Chris Wilson
Signed-off-by: Daniel Vetter
---
Documentation/gpu/introduction.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/gpu/introduction.rst
b/Documentation/gpu/introduction.rst
index 1903595
On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote:
> On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote:
> > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const struct
> > drm_mm_node *hole_node)
> >
> > /**
> > * drm_mm_for_each_node - iterator to walk ov
On Thu, Dec 29, 2016 at 12:09:24PM +0100, Daniel Vetter wrote:
> Including all drivers. I thought about keeping small compat functions
> to avoid having to change all drivers. But I really like the
> drm_printer idea, so figured spreading it more widely is a good thing.
>
> v2: Review from Chris:
anything for me but that
might be due to using Wayland.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161229/7fccf
Regards
Shashank
On 12/27/2016 3:07 PM, Daniel Vetter wrote:
> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
>> Hi Shashank,
>>
>>
>> On 21-12-2016 15:29, Shashank Sharma wrote:
>>> This patch adds a small helper function, which clears the cached
>>> information about a hot-pluggab
ML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161229/b8683109/attachment-0001.html>
On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote:
> On Wed, Dec 28, 2016 at 05:37:26PM +, Chris Wilson wrote:
> > On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote:
> > > @@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const struct
> > > drm_mm_node *hole_
From: Shawn Guo
It enables VOU VL (Video Layer) to support overlay plane with scaling
function. VL0 has some quirks on scaling support. We choose to skip it
and only adds VL1 and VL2 into DRM core for now.
Function zx_plane_atomic_disable() gets moved around with no changes to
save a forward d
From: Shawn Guo
There are a few hardware bits for each graphic layer to control main/aux
channel and clock selection, as well as the layer enabling. These bits
sit outside the layer block itself, but in VOU control glue block. We
currently set these bits up at CRTC initialization for once, and
From: Shawn Guo
Move struct zx_plane from zx_plane.c to zx_plane.h, so that it can be
accessed from zx_vou driver, and we can save the use of struct
zx_layer_data completely. More importantly, those additional data used
by VOU controller to enable/disable graphic and video layers can later
be ad
From: Shawn Guo
Changes for v3:
- Let zx_plane be accessible from zx_vou driver, and so we can easily
access all the data encoded in zx_plane with a drm_plane pointer.
Thus, function zx_overlay_find_vl_idx() can be saved completely.
- Refine the existing zx_plane driver a bit to support d
Hi Sean,
On Thu, Dec 22, 2016 at 09:56:01AM -0500, Sean Paul wrote:
> On Tue, Dec 20, 2016 at 7:09 AM, Shawn Guo wrote:
> > diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c
> > index 73fe15c17c32..8ca9c4bdeeaf 100644
> > --- a/drivers/gpu/drm/zte/zx_vou.c
> > +++ b/drivers
nts/20161229/6021e116/attachment.html>
Hi Shashank,
On 29-12-2016 05:53, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 12/27/2016 3:07 PM, Daniel Vetter wrote:
>> On Thu, Dec 22, 2016 at 10:21:25AM +, Jose Abreu wrote:
>>> Hi Shashank,
>>>
>>>
>>> On 21-12-2016 15:29, Shashank Sharma wrote:
This patch adds a small h
Resending because it got caught in moderation last time.
What I'm using:
- R9 290
- Kernel 4.9.0
- ASUS PB278Q monitor, connected with DisplayPort
- OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel
(git-d9fef84)
- radeon DDX 7.8.99 (Git)
For as long as I remember I've h
On 2016-12-28 19:53, Gabriel Krisman Bertazi wrote:
> Fabio Estevam writes:
>
>> On Wed, Dec 28, 2016 at 4:38 PM, Gabriel Krisman Bertazi
>> wrote:
>>
>>> This leaks tcon if clk_prepare_enable fails.
>>
>> No, it does not as tcon is allocated via devm_kzalloc().
>
> Agreed. But I think devm_kz
tps://lists.freedesktop.org/archives/dri-devel/attachments/20161229/d4d268f8/attachment.html>
We're going to use R8A7794 VSPD to control DU, so set the corresponding flag
and the newly added field, 'num_vspds'...
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar
Renesas R-Car E2 (R8A7791) SoC only has 1 VSPD but still 2 DU ports.
Since we are going to use the R-Car gen2 VSPDs as the DU compositors,
we'll have to also support this case. Now that the number of VSPDs can be
less than the number of the DU ports, 'struct rcar_du_device_info' needs
a new f
Hello.
Here's the set of 2 patches against the 'drm-next' branch of David Airlie's
'linux.git' repo. We're switching to the DU compositor for the DU driver on the
Renesas R8A7794 SoC.
[1/2] drm: rcar-du: support less VSPs than CRTCs
[2/2] drm: rcar-du: enable VSPD on R8A7794
MBR, Sergei
62 matches
Mail list logo
