Hi Rohan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.7-rc7
next-20200529]
[if your patch is applied to the wrong
Hi Rohan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.7-rc7
next-20200529]
[if your patch is applied to the wrong
Hi Sylwester,
On Sat, May 30, 2020 at 1:34 AM Sylwester Nawrocki
wrote:
>
> This patch adds a generic interconnect driver for Exynos SoCs in order
> to provide interconnect functionality for each "samsung,exynos-bus"
> compatible device.
>
> The SoC topology is a graph (or more specifically, a tr
Hi Sylwester,
On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
wrote:
>
> From: Artur Świgoń
>
> This patch adds an 'interconnects' property to Exynos4412 DTS in order to
> declare the interconnect path used by the mixer. Please note that the
> 'interconnect-names' property is not needed when
Hi Sylwester,
On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
wrote:
>
> This patch adds the following properties for Exynos4412 interconnect
> bus nodes:
> - samsung,interconnect-parent: to declare connections between
>nodes in order to guarantee PM QoS requirements between nodes;
> - #
Hi Sylwester,
On Sat, May 30, 2020 at 1:32 AM Sylwester Nawrocki
wrote:
>
> Add documentation for new optional properties in the exynos bus nodes:
> samsung,interconnect-parent, #interconnect-cells.
> These properties allow to specify the SoC interconnect structure which
> then allows the interc
Hi Sylwester,
On Sat, May 30, 2020 at 1:33 AM Sylwester Nawrocki
wrote:
>
> This patch adds registration of a child platform device for the exynos
> interconnect driver. It is assumed that the interconnect provider will
> only be needed when #interconnect-cells property is present in the bus
> DT
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #42 from babgozd (babgoz...@outlook.com) ---
(In reply to Meric07 from comment #41)
> (In reply to Alex Deucher from comment #40)
> > (In reply to Meric07 from comment #39)
> > > I experience the same problem with a R9 380X. Still can'
Hi Rohan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.7-rc7
next-20200529]
[if your patch is applied to the wrong
On Sat, May 30, 2020 at 02:34:10PM +0100, Emil Velikov wrote:
> On Sat, 30 May 2020 at 14:18, Sam Ravnborg wrote:
> >
> > Hi Emil.
> > On Sat, May 30, 2020 at 01:46:40PM +0100, Emil Velikov wrote:
> > > Currently the ret handling is all over the place - with two redundant
> > > assignments and ano
On Sat, 30 May 2020 at 14:18, Sam Ravnborg wrote:
>
> Hi Emil.
> On Sat, May 30, 2020 at 01:46:40PM +0100, Emil Velikov wrote:
> > Currently the ret handling is all over the place - with two redundant
> > assignments and another one addressed earlier.
> >
> > Use the exact same flow in both functi
Hi Rob,
On Thu, May 28, 2020 at 01:48:04PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:12:10PM +0200, Guido Günther wrote:
> > The bridge allows to select the input source via a mux controller.
> >
> > Signed-off-by: Guido Günther
> > ---
> > .../display/bridge/mux-input-bridge.yaml
Hi Emil.
On Sat, May 30, 2020 at 01:46:40PM +0100, Emil Velikov wrote:
> Currently the ret handling is all over the place - with two redundant
> assignments and another one addressed earlier.
>
> Use the exact same flow in both functions.
>
> v2: straighten the code flow, instead of just removing
On 2020-05-29 5:01 p.m., Daniel Stone wrote:
> On Fri, 29 May 2020 at 15:36, Alex Deucher wrote:
>> On Fri, May 29, 2020 at 10:32 AM Daniel Stone wrote:
>>> On Fri, 29 May 2020 at 15:29, Alex Deucher wrote:
Maybe I'm over thinking this. I just don't want to get into a
situation where
Currently the ret handling is all over the place - with two redundant
assignments and another one addressed earlier.
Use the exact same flow in both functions.
v2: straighten the code flow, instead of just removing the assignments
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Colin
The function always returns zero (success). Ideally we'll remove it all
together - although that's requires a little more work.
For now, we can drop the return type and simplify the drm core code
surrounding it.
v2: remove redundant assignment (Sam)
Cc: David Airlie
Cc: Daniel Vetter
Cc: VMwar
On Sat, 30 May 2020 at 08:48, Sam Ravnborg wrote:
>
> Hi Emil.
>
> On Fri, May 29, 2020 at 10:48:07PM +0100, Emil Velikov wrote:
> > The variables are already the exact same value or will be overwritten
> > shortly afterwords. In either case there's no functional difference.
> s/afterwords/afterwa
Hi Steven
On Thu, 28 May 2020 at 15:22, Steven Price wrote:
>
> On 10/05/2020 17:55, Clément Péron wrote:
> > Later we will introduce devfreq probing regulator if they
> > are present. As regulator should be probe only one time we
> > need to get this logic in the device_init().
> >
> > panfrost_
On 2020-05-29 3:11 p.m., Marek Szyprowski wrote:
> Patches are pending:
> https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T/
Cool, nice! Though, I still don't think that fixes the issue in
i915_scatterlist.h given it still ignores sg_dma_len() and strictly
rel
On 27/05/2020 11:58, Lukasz Luba wrote:
> The Energy Model framework is going to support devices other that CPUs. In
> order to make this happen change the callback function and add pointer to
> a device as an argument.
>
> Update the related users to use new function and new callback from the
> E
Hi Steven,
On Thu, 28 May 2020 at 15:22, Steven Price wrote:
>
> On 10/05/2020 17:55, Clément Péron wrote:
> > Instead of expecting an error from dev_pm_opp_of_add_table()
> > do a simple device_property_present() check.
> >
> > Signed-off-by: Clément Péron
>
> I'm not sure I understand why this
This patch introduces fragmentation in the address range
and measures time taken by 10k and 20k insertions. ig_frag()
will fail if time taken by 20k insertions takes more than 4 times
of 10k insertions as we know that insertions scale quadratically.
Also tolerate 10% error because of kernel schedul
Hi Steven,
On Thu, 28 May 2020 at 15:23, Steven Price wrote:
>
> On 10/05/2020 17:55, Clément Péron wrote:
> > Some OPP tables specify voltage for each frequency. Devfreq can
> > handle these regulators but they should be get only 1 time to avoid
> > issue and know who is in charge.
> >
> > If OP
Hi Rafael,
On 5/27/20 10:58 AM, Lukasz Luba wrote:
Hi all,
Background of this version:
This is the v8 of the patch set and is has smaller scope. I had to split
the series into two: EM changes and thermal changes due to devfreq
dependencies. The patches from v7 9-14 which change devfreq cooling
Hi Steven,
On Thu, 28 May 2020 at 15:23, Steven Price wrote:
>
> On 10/05/2020 17:55, Clément Péron wrote:
> > Some SoCs have several clocks defined and the OPP core
> > needs to know the exact name of the clk to use.
> >
> > Set the clock name to "core".
> >
> > Signed-off-by: Clément Péron
>
acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 24
On Thu, May 28, 2020 at 12:37 AM John Hubbard wrote:
>
> On 2020-05-27 01:51, Daniel Vetter wrote:
> > On Wed, May 27, 2020 at 10:48:52AM +0200, Daniel Vetter wrote:
> >> On Tue, May 26, 2020 at 03:57:45PM -0700, John Hubbard wrote:
> >>> On 2020-05-26 14:00, Souptick Joarder wrote:
> This co
When gk20a_clk_ctor() returns an error code, pointer "clk"
should be released. It's the same when gm20b_clk_new()
returns from elsewhere following this call.
Signed-off-by: Dinghao Liu
---
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gm20b.c | 8
1 file changed, 4 insertions(+), 4 deletions(
On 5/29/20 5:18 PM, Rafael J. Wysocki wrote:
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba wrote:
Hi Rafael,
On 5/27/20 10:58 AM, Lukasz Luba wrote:
Hi all,
Background of this version:
This is the v8 of the patch set and is has smaller scope. I had to split
the series into two: EM changes
On 2020-05-29 6:45 a.m., Christoph Hellwig wrote:
> On Thu, May 28, 2020 at 06:00:44PM -0600, Logan Gunthorpe wrote:
>>> This issue is most likely in the i915 driver and is most likely caused by
>>> the driver not respecting the return value of the dma_map_ops::map_sg
>>> function. You can see
Fixes: 0cdea4455acd350a ("drm/mm: optimize rb_hole_addr rbtree search")
Signed-off-by: Nirmoy Das
Reported-by: Christian König
---
drivers/gpu/drm/drm_mm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index f4ca1ff80
Hi Robin,
On Fri, 29 May 2020 at 14:20, Robin Murphy wrote:
>
> On 2020-05-10 17:55, Clément Péron wrote:
> > Convert busy_count to a simple int protected by spinlock.
>
> A little more reasoning might be nice.
I have follow the modification requested for lima devfreq and clearly
don't have any
Hi Emil.
On Fri, May 29, 2020 at 10:48:07PM +0100, Emil Velikov wrote:
> The variables are already the exact same value or will be overwritten
> shortly afterwords. In either case there's no functional difference.
s/afterwords/afterwards/
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-b
Hi Emil.
On Fri, May 29, 2020 at 10:48:06PM +0100, Emil Velikov wrote:
> The function always returns zero (success). Ideally we'll remove it all
> together - although that's requires a little more work.
>
> For now, we can drop the return type and simplify the drm core code
> surrounding it.
>
>
34 matches
Mail list logo
