Hi Luis,
2016-04-11 Luis de Bethencourt <luisbg(a)osg.samsung.com>:
> The members child_list and active_list were added to the fence struct
> without descriptions for the Documentation. Adding these.
>
> Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
> Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
> ---
> Hi,
>
> Just resending this patch since it hasn't had any reviews in since
> March 21st.
>
> Thanks,
> Luis
>
> include/linux/fence.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk>
Gustavo
The original patches have been done by Marek:
https://lists.freedesktop.org/archives/dri-devel/2016-January/099572.html
I have just adapt them to make zpos depend on plane and no more on drm core.
Since zpos range can be define per plane normalize function takes care of
the min and max before compute normalized zpos value.
Benjamin Gaignard (2):
drm: add generic zpos property
drm: sti: use generic zpos for plane
Documentation/DocBook/gpu.tmpl | 10 ++
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_atomic.c | 4 +
drivers/gpu/drm/drm_atomic_helper.c | 6 +
drivers/gpu/drm/drm_blend.c | 242 ++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/drm_crtc_internal.h | 3 +
drivers/gpu/drm/sti/sti_mixer.c | 2 +-
drivers/gpu/drm/sti/sti_plane.c | 82 +++++-------
drivers/gpu/drm/sti/sti_plane.h | 2 -
include/drm/drm_crtc.h | 17 +++
10 files changed, 314 insertions(+), 56 deletions(-)
create mode 100644 drivers/gpu/drm/drm_blend.c
--
1.9.1
Hi
On Mon, Mar 28, 2016 at 9:42 PM, Tiago Vignatti
<tiago.vignatti(a)intel.com> wrote:
> Do we have an agreement here after all? David? I need to know whether this
> fixup is okay to go cause I'll need to submit to Chrome OS then.
Sure it is fine. The code is already there, we cannot change it.
Thanks
David
Hello Luis,
On Sat, Mar 19, 2016 at 4:50 PM, Luis de Bethencourt
<luisbg(a)osg.samsung.com> wrote:
> Commit b55b54b5db33 ("staging/android: remove struct sync_pt")
> added the members child_list and active_list to the fence struct, but
> didn't add descriptions for these. Adding the descriptions.
>
Patches whose commit message mentions a specific commit that
introduced and issue, usually also have a "Fixes:" tag before the
S-o-B. For example this patch should have:
Fixes: b55b54b5db33 ("staging/android: remove struct sync_pt")
> Signed-off-by: Luis de Bethencourt <luisbg(a)osg.samsung.com>
> ---
> Hi,
>
> Noticed this missing descriptions when running make htmldocs.
>
> Got the following warnings:
> .//include/linux/fence.h:84: warning: No description found for parameter 'child_list'
> .//include/linux/fence.h:84: warning: No description found for parameter 'active_list'
>
> Thanks :)
> Luis
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier(a)osg.samsung.com>
Best regards,
Javier
Hello,
This patchset fixes attaching and detaching devices to a group, which
has default domain configured. With both patches applied all calls to
iommu's attach/detach functions will be balanced, whenever caller
attaches device to the default domain or the custom one.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summary:
Marek Szyprowski (2):
iommu: call detach also for default_domain before attaching to new one
iommu: fix default domain handling in __iommu_detach_group()
drivers/iommu/iommu.c | 48 +++++++++++++++++++++++++++---------------------
1 file changed, 27 insertions(+), 21 deletions(-)
--
1.9.2
2015-10-21 16:34 GMT+02:00 James Morris <jmorris(a)namei.org>:
> On Wed, 21 Oct 2015, Benjamin Gaignard wrote:
>
>>
>> The outcome of the previous RFC about how do secure data path was the need
>> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>>
>
> Have you addressed all the questions raised by Alan here:
>
> https://lkml.org/lkml/2015/5/8/629
SMAF create /dev/smaf where all allocations could be done and is the
owner of the dmabuf.
Secure module is called to check permissions before that the CPU could
access to the memory.
I hope this cover what Alan expected but I can't speak form him.
>
> Also, is there any application of this beyond DRM?
>
If you don't use the secure part you can consider that SMAF is a
central allocator with helpers to select
the best allocator for your hardware devices.
While SMAF doesn't rely on DRM concepts (crypto, CENC, keys etc...) we
can use it outside this context but obviously it that been first
designed for DRM uses cases.
>
> - James
> --
> James Morris
> <jmorris(a)namei.org>
>
--
Benjamin Gaignard
Graphic Working Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog