On Sun, Dec 02, 2018 at 07:28:55PM -0800, Randy Dunlap wrote:
> Hi,
> I have more editing comments below.
>
>
> On 11/15/18 5:01 PM, Jarkko Sakkinen wrote:
> > Documentation of the features of the Software Guard eXtensions used
> > by the Linux kernel and basic design choices for the core and dri
Hi Peter,
On 27.11.2018 22:13, Alexey Budankov wrote:
> On 27.11.2018 21:11, Jonathan Corbet wrote:
>> On Tue, 27 Nov 2018 11:15:37 +0300
>> Alexey Budankov wrote:
>>
>>> +To perform security checks, the Linux implementation splits processes into
>>> two
>>> +categories [6]_ : a) privileged proc
On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> Providing an explicit list of discrimination factors may give the false
> impression that discrimination based on other unlisted factors would be
> allowed.
>
> Furthermore, this list is already overly long, polarizing,
> politi
On 12.10.18 19:21, Jonathan Corbet wrote:
> On Thu, 11 Oct 2018 07:58:15 +0300
> Mike Rapoport wrote:
>
>> As discussed at [1], the latest updates to memory hotplug documentation are
>> causing a conflict between docs and mmotm trees.
>> These patches resolve the conflict.
>>
>> [1] https://lkml.
From: Brian Starkey
As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).
AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes",
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffe
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:
We need to define a common list of format modifiers supported by each of the
Mali
display processors. The difference between DP500 from DP550/650 is that DP500
does not support block split mode (ie AFBC_FORMAT_MOD_SPLIT) and DP550 supports
YUV420 with split mode. We noted these special cases by de
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modi
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Signed
We have added some new formats to be supported on DP500/DP550/DP650.
Signed-off-by: Ayan Kumar Halder
Depends on :- https://patchwork.kernel.org/patch/10460063/
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers
We have added a new format ie DRM_FORMAT_XVYU2101010 which is supported
by mali display driver.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC buffers
(in num
This patchset aims to add support for AFBC in mali display driver with
the help of format modifiers. AFBC modifiers adds some constraints to
framebuffer size, alignment, pitch, formats, etc
In the previous patchset ie
https://lists.freedesktop.org/archives/dri-devel/2018-June/180124.html
I had il
From: Brian Starkey
AFBC is a flexible, proprietary, lossless compression protocol and
format, with a number of defined DRM format modifiers. To facilitate
consistency and compatibility between different AFBC producers and
consumers, document the expectations for usage of the AFBC DRM format
modi
The constraints are as follows (for Mali-DP 500, 550, 650) :-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifi
Hi Greg,
On Mon, Dec 3, 2018 at 12:05 PM Greg Kroah-Hartman
wrote:
> On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allo
On Thu, Nov 22, 2018 at 03:04:31AM +, Kulkarni, Ganapatrao wrote:
> The SoC has PMU support in its L3 cache controller (L3C) and in the
> DDR4 Memory Controller (DMC).
>
> Signed-off-by: Ganapatrao Kulkarni
> ---
> Documentation/perf/thunderx2-pmu.txt | 106 +++
> 1 f
On Thu, Nov 22, 2018 at 03:04:35AM +, Kulkarni, Ganapatrao wrote:
> This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory
> Controller(DMC) and Level 3 Cache(L3C). Each PMU supports up to 4
> counters. All counters lack overflow interrupt and are
> sampled periodically.
>
> Sign
On Mon 2018-12-03 12:05:06, Greg Kroah-Hartman wrote:
> On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > Providing an explicit list of discrimination factors may give the false
> > impression that discrimination based on other unlisted factors would be
> > allowed.
> >
> > F
Hello Stephen & All,
I created v5 where I fixed obvious issues. I'll send it in few minutes.
Please note following topics:
On Fri, Nov 30, 2018 at 12:50:22PM +0200, Matti Vaittinen wrote:
>
> On Fri, Nov 30, 2018 at 12:54:10AM -0800, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2018-11-13 03
Series add bd71837/bd71837 PMIC clock support + managed interfaces
Few clk drivers appear to be leaking clkdev lookup registrations at
driver remove. The patch series adds devm versions of lookup
registrations and cleans up few drivers. Driver clean-up patches have
not been tested as I lack the HW
With MFD devices the clk properties may be contained in MFD (parent) DT
node. Current devm_of_clk_add_hw_provider assumes the clk is bound to MFD
subdevice not to MFD device (parent). Add
devm_of_clk_add_hw_provider_parent to tackle this issue.
Signed-off-by: Matti Vaittinen
---
Documentation/dr
Clkdev registration lacks of managed registration functions and it
seems few drivers do not drop clkdev lookups at exit. Add
devm_clk_hw_register_clkdev and devm_clk_release_clkdev to ease lookup
releasing at exit.
Signed-off-by: Matti Vaittinen
---
Documentation/driver-model/devres.txt | 1 +
clk-max77686 never clean clkdev lookup at remove. This can cause
oops if clk-max77686 is removed and inserted again. Fix leak by
using new devm clkdev lookup registration. Simplify also error
path by using new devm_of_clk_add_parent_hw_provider.
Signed-off-by: Matti Vaittinen
Reviewed-by: Krzyszt
> Series add bd71837/bd71837 PMIC clock support + managed interfaces
[...]
> Matti Vaittinen (9):
> clkdev: add managed clkdev lookup registration
> clk: of_clk - add managed provider registrations
> clk: clk-max77686: Clean clkdev lookup leak and use devm
> clk: clk-st: avoid clkdev look
Use devm based clkdev lookup registration to avoid leaking lookup
structures.
Signed-off-by: Matti Vaittinen
---
drivers/clk/x86/clk-st.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c
index 3a0996f2d556..25d4b97aff9b 100
Simplify clean-up for rk808 by using managed version of of_provider
registration.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-rk808.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
index 6461f2820a5b..
use devm variant for of_provider registration so provider is freed
at exit.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-hi655x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-hi655x.c b/drivers/clk/clk-hi655x.c
index 403a0188634a..394d0109104d 100
use devm variant for of_provider registration so provider is freed
at exit.
Signed-off-by: Matti Vaittinen
Acked-by: Peter Ujfalusi
---
drivers/clk/clk-twl6040.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index
use devm variant for of_provider registration.
Signed-off-by: Matti Vaittinen
---
drivers/clk/qcom/apcs-msm8916.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/qcom/apcs-msm8916.c b/drivers/clk/qcom/apcs-msm8916.c
index b1cc8dbcd327..f4e0c136ab1a 100644
---
ROHM bd71837 and bd71847 contain 32768Hz clock gate. Support the clock
using generic clock framework. Note, only bd71837 is tested but bd71847
should be identical what comes to clk parts.
Signed-off-by: Matti Vaittinen
---
drivers/clk/Kconfig | 7 +++
drivers/clk/Makefile | 1 +
d
From: Rafael J. Wysocki
Add two new metrics for CPU idle states, "high" and "low", to count
the number of times the given state had been asked for (or entered
from the kernel's perspective), but the observed idle duration turned
out to be too high or too low for it (respectively).
These mertics
From: Rafael J. Wysocki
When computing the limit of time to spend in the loop in poll_idle(),
use the target residency of the first enabled idle state deeper than
state 0 instead of always using the target residency of state 1.
This helps when state 1 is disabled for diagnostics, for instance.
Hi de Ho Lee,
On Mon, Dec 03, 2018 at 12:19:51PM +, Lee Jones wrote:
> > Series add bd71837/bd71837 PMIC clock support + managed interfaces
>
> You've send me a cover letter and no patches.
I am afraid the patches may be still on their way... I added recipients
to git format-patch via comma
On Mon, 03 Dec 2018, Matti Vaittinen wrote:
>
> Hi de Ho Lee,
>
> On Mon, Dec 03, 2018 at 12:19:51PM +, Lee Jones wrote:
> > > Series add bd71837/bd71837 PMIC clock support + managed interfaces
> >
> > You've send me a cover letter and no patches.
> >
> I am afraid the patches may be still
On Mon, Dec 03, 2018 at 12:53:00PM +0100, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Mon, Dec 3, 2018 at 12:05 PM Greg Kroah-Hartman
> wrote:
> > On Sun, Dec 02, 2018 at 10:32:57AM +0100, Geert Uytterhoeven wrote:
> > > Providing an explicit list of discrimination factors may give the false
> >
To be honest, I fail to understand this patch. At least after a quick glance,
I will try to read it again tomorrow but so far I do not even understand the
desired semantics wrt signals/ptrace.
On 11/30, Roman Gushchin wrote:
>
> @@ -368,6 +369,8 @@ static inline int signal_pending_state(long state
On 11/30, Roman Gushchin wrote:
>
> +void cgroup_enter_frozen(void)
> +{
> + if (!current->frozen) {
> + struct cgroup *cgrp;
> +
> + spin_lock_irq(&css_set_lock);
> + current->frozen = true;
> + cgrp = task_dfl_cgroup(current);
> + cg
Add some more Ccs.
On Sun, Dec 02, 2018 at 11:08:38AM +0800, Lianbo Jiang wrote:
> This document lists some variables that export to vmcoreinfo, and briefly
> describles what these variables indicate. It should be instructive for
> many people who do not know the vmcoreinfo, and it also normalizes
On 11/30, Roman Gushchin wrote:
>
> void recalc_sigpending(void)
> {
> if (!recalc_sigpending_tsk(current) && !freezing(current) &&
> - !klp_patch_pending(current))
> + !klp_patch_pending(current) && !cgroup_task_frozen(current))
I must have missed something... but shouldn'
On Fri, Nov 30, 2018 at 03:47:41PM -0800, Roman Gushchin wrote:
> + * nr_descendants and nr_dying_descendants are protected
> + * by cgroup_mutex and css_set_lock.
Can you be a bit more specific - hold both for writes, either for
reads.
Thanks.
--
tejun
On Mon, Dec 3, 2018 at 4:15 AM Pavel Machek wrote:
>
> Linus, I don't think Greg is doing good job maintaining this. Can you
> take the patch? (Or explain what is going on here, because I don't
> think public has full story).
I think Greg is doing a fine job, and I personally will not take
patche
On Mon, Dec 03, 2018 at 08:17:06AM -0800, Tejun Heo wrote:
> On Fri, Nov 30, 2018 at 03:47:41PM -0800, Roman Gushchin wrote:
> > +* nr_descendants and nr_dying_descendants are protected
> > +* by cgroup_mutex and css_set_lock.
>
> Can you be a bit more specific - hold both for writes, eith
Hi,
On Mon, Dec 03, 2018 at 02:17:56PM +0200, Matti Vaittinen wrote:
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 9ab3db8b3988..68a1e55a60d2 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -401,6 +401,25 @@ static struct clk_lookup *__clk_register_clkdev
This adds the build infrastructure for checking DT binding schema
documents and validating dts files using the binding schema.
Check DT binding schema documents:
make dt_binding_check
Build dts files and check using DT binding schema:
make dtbs_check
Optionally, DT_SCHEMA_FILES can passed in wit
Quoting Matti Vaittinen (2018-11-30 02:50:22)
> Hello Stephen,
>
> Thanks a bunch for taking the time and reviewing this!
>
> On Fri, Nov 30, 2018 at 12:54:10AM -0800, Stephen Boyd wrote:
> > Quoting Matti Vaittinen (2018-11-13 03:55:58)
> > > With MFD devices the clk properties may be contained
On Mon, Dec 03, 2018 at 03:47:18PM +0100, Oleg Nesterov wrote:
> To be honest, I fail to understand this patch. At least after a quick glance,
> I will try to read it again tomorrow but so far I do not even understand the
> desired semantics wrt signals/ptrace.
>
> On 11/30, Roman Gushchin wrote:
Hi Boris,
Sorry for the delayed response.
On 27/11/18 12:33, Boris Brezillon wrote:
Hi Vitor,
On Tue, 27 Nov 2018 11:50:53 +
vitor wrote:
Sorry for that and don't take me wrong... maybe I should rise this
question early but this only came up now when I started splitting and
thinking
Documentation/networking/ is full of cryptically named files with
driver documentation. This makes finding interesting information
at a glance really hard. Move all those files into a directory
called device_drivers (since not all drivers are for device) and
fix up references.
RFC v0.1 -> RFC v1
On 12/3/18 6:43 PM, Jakub Kicinski wrote:
> Documentation/networking/ is full of cryptically named files with
> driver documentation. This makes finding interesting information
> at a glance really hard. Move all those files into a directory
> called device_drivers (since not all drivers are for
Hi Will,
On Mon, Dec 3, 2018 at 5:39 PM Will Deacon wrote:
>
> On Thu, Nov 22, 2018 at 03:04:31AM +, Kulkarni, Ganapatrao wrote:
> > The SoC has PMU support in its L3 cache controller (L3C) and in the
> > DDR4 Memory Controller (DMC).
> >
> > Signed-off-by: Ganapatrao Kulkarni
> > ---
> > D
On Mon, Dec 3, 2018 at 5:41 PM Will Deacon wrote:
>
> On Thu, Nov 22, 2018 at 03:04:35AM +, Kulkarni, Ganapatrao wrote:
> > This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory
> > Controller(DMC) and Level 3 Cache(L3C). Each PMU supports up to 4
> > counters. All counters lack
Hello Again Stephen,
I did already send v5 prior to your reply but I will create v6 today
based on this discussion.
On Mon, Dec 03, 2018 at 03:35:10PM -0800, Stephen Boyd wrote:
> Quoting Matti Vaittinen (2018-11-30 02:50:22)
> > Hello Stephen,
> >
> > Thanks a bunch for taking the time and revi
--
Brauchen Sie einen Kredit?
--
Hello,
First of all i will like to apologies for my manner of communication
because you do not know me personally, its due to the fact that i have a
very important proposal for you.
57 matches
Mail list logo
