Hi Noralf.
On Wed, Apr 29, 2020 at 02:48:21PM +0200, Noralf Trønnes wrote:
> Add a way to lookup a backlight device based on its name.
> Will be used by a USB display gadget getting the name from configfs.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Signed-off-by: Noralf Trønnes
Hi Noralf.
On Wed, Apr 29, 2020 at 02:48:24PM +0200, Noralf Trønnes wrote:
> Some drivers need explicit flushing of buffer changes, add a function
> that does that.
I trust you on this.
>
> Signed-off-by: Noralf Trønnes
Some bikeshedding below. Either way:
Reviewed-by: Sam Ravnborg
> ---
> d
Hi Noralf.
On Wed, Apr 29, 2020 at 02:48:25PM +0200, Noralf Trønnes wrote:
> Add a way for client to check the configuration before comitting.
>
> Signed-off-by: Noralf Trønnes
Two small ntis. With these addressed:
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/drm_client_modeset.c | 35 +++
Hi Noralf.
Some comments in the following - partly because I still do not fully
grasp modeset etc.
Sam
On Wed, Apr 29, 2020 at 02:48:26PM +0200, Noralf Trønnes wrote:
> This adds functions for clients that need more control over the
> configuration than what's setup by drm_client_modeset
Den 03.05.2020 09.48, skrev Sam Ravnborg:
> Hi Noralf.
>
> On Wed, Apr 29, 2020 at 02:48:24PM +0200, Noralf Trønnes wrote:
>> Some drivers need explicit flushing of buffer changes, add a function
>> that does that.
> I trust you on this.
All drivers in tiny/ and at least udl need to be told to
Den 03.05.2020 10.03, skrev Sam Ravnborg:
> Hi Noralf.
>
> On Wed, Apr 29, 2020 at 02:48:25PM +0200, Noralf Trønnes wrote:
>> Add a way for client to check the configuration before comitting.
>>
>> Signed-off-by: Noralf Trønnes
> Two small ntis. With these addressed:
> Reviewed-by: Sam Ravnborg
Hi Noralf
On Wed, Apr 29, 2020 at 02:48:27PM +0200, Noralf Trønnes wrote:
> This replaces drm_fb_swab16() with drm_fb_swab() supporting 16 and 32-bit.
> Also make pixel line caching optional.
>
> Signed-off-by: Noralf Trønnes
A couple of nits, with these considered:
Reviewed-by: Sam Ravnborg
>
Den 03.05.2020 10.47, skrev Sam Ravnborg:
> Hi Noralf.
>
> Some comments in the following - partly because I still do not fully
> grasp modeset etc.
I still don't fully understand it either. I have wandered inside the
atomic machinery countless times to track what happens to this or that
state/
On some qualcomm platforms DPU needs to express a performance state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Reviewed-by: Rob Clark
Revie
On SDM845 DSI needs to express a perforamnce state
requirement on a power domain depending on the clock rates.
Use OPP table from DT to register with OPP framework and use
dev_pm_opp_set_rate() to set the clk/perf state.
Signed-off-by: Rajendra Nayak
Cc: Rob Clark
Cc: Sean Paul
Cc: dri-devel@li
Hi Neil,
On Tue, Apr 28, 2020 at 10:38 AM Neil Armstrong wrote:
[...]
> > @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
> > VIU_OSD_FIFO_LIMITS(2); /* fifo_lim: 2*16=32 */
> >
> > if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> > -
Hi Nikolaus,
Le sam. 2 mai 2020 à 22:26, H. Nikolaus Schaller a
écrit :
Hi Paul,
Am 26.04.2020 um 15:11 schrieb Paul Cercueil :
Hi Nikolaus,
Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller
a écrit :
The Imagination PVR/SGX GPU is part of several SoC from
multiple vendors, e.g.
Hi Paul,
> Am 26.04.2020 um 15:11 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le ven. 24 avril 2020 à 22:34, H. Nikolaus Schaller a
> écrit :
>> The Imagination PVR/SGX GPU is part of several SoC from
>> multiple vendors, e.g. TI OMAP, Ingenic JZ4780, Intel Poulsbo,
>> Allwinner A83 and other
Hi Steven,
On Tue, 14 Apr 2020 at 15:10, Steven Price wrote:
>
> Hi Clément,
>
> On 13/04/2020 18:28, Clément Péron wrote:
> > Hi Steven,
> >
> Getting a backtrace from the two occurrences, I see one added from:
>
>(debugfs_create_dir) from [] (create_regulator+0xe0/0x220)
>(create_reg
Hi,
Thanks for your review. I'll send a v2 soon, however we need to solve the
compat string issue first.
How should I document tm5p5? I think it's rather some kind of a model no.
along with the nt35596 IC than a vendor name.. Or should we call it
something like "unknown,tm5p5-nt35596", perhaps "a
Disclaimer: sorry if you see it twice, I got a response saying something
was wrong when I first tried to send this.
Hi,
Thanks for your review. I'll send a v2 soon, however we need to solve the
compat string issue first.
How should I document tm5p5? I think it's rather some kind of a model no.
a
Den 03.05.2020 12.29, skrev Sam Ravnborg:
> Hi Noralf
>
> On Wed, Apr 29, 2020 at 02:48:27PM +0200, Noralf Trønnes wrote:
>> This replaces drm_fb_swab16() with drm_fb_swab() supporting 16 and 32-bit.
>> Also make pixel line caching optional.
>>
>> Signed-off-by: Noralf Trønnes
> A couple of nit
On Thu, Apr 30, 2020 at 7:46 AM Schrempf Frieder
wrote:
>
> From: Frieder Schrempf
>
> According to the documents, the i.MX8M-Mini features a GC320 and a
> GCNanoUltra GPU core. Etnaviv detects them as:
>
> etnaviv-gpu 3800.gpu: model: GC600, revision: 4653
> etnaviv-gpu 38008
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #10 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #9)
> I'm not there yet but it's starting to look like a possibly dud bisect:
> everything showing good so far
Good but not ideal news!
I did get an apparent
Hi Thomas.
On Wed, Apr 29, 2020 at 04:32:29PM +0200, Thomas Zimmermann wrote:
> Set different fields in MISC in their rsp location in the code. This
> patch also fixes a bug in the original code where the mode's SYNC flags
> were never written into the MISC register.
>
> Signed-off-by: Thomas Zim
On Wed, Apr 29, 2020 at 04:32:30PM +0200, Thomas Zimmermann wrote:
> Setting the plane registers first and the mode registers afterwards
> reproduces the sequence used by atomic helpers. Done in preparation
> of switching to simple KMS helpers.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam R
Hi Thomas.
On Wed, Apr 29, 2020 at 04:32:31PM +0200, Thomas Zimmermann wrote:
> The framebuffer's pitch is now set in mgag200_set_offset().
>
> Signed-off-by: Thomas Zimmermann
I failed to follow this code.
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 41 +-
> 1 fi
Hi Thomas.
One nit about a bit name below.
Acked-by: Sam Ravnborg
On Wed, Apr 29, 2020 at 04:32:33PM +0200, Thomas Zimmermann wrote:
> 5
>
> The TAGFIFO state is now reset in mgag200_g200er_reset_tagfifo().
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.h |
On Wed, Apr 29, 2020 at 04:32:34PM +0200, Thomas Zimmermann wrote:
> The hiprivlvl settings are now updated in mgag200_g200se_set_hiprilvl()
> and mgag200_g200ev_set_hiprilvl().
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/mgag200/mgag200_mode.c | 98 +
On Wed, Apr 29, 2020 at 04:32:35PM +0200, Thomas Zimmermann wrote:
> Registers are initialized with constants. This is now done in
> mgag200_init_regs(), mgag200_set_dac_regs() and mgag200_set_pci_regs().
> Later patches should move these calls from mode setting to device
> initialization.
>
> Sig
Hi Thomas.
Introducing drm_simple_display_pipe to hold some of the data,
and then a later patch to change over would have helped the readability
I think.
Anyway - deleted unused code belongs to another patch.
Other than tthose details I did not spot anything, but then I did not
read this patch as
Hi Souptick
On Sat, May 02, 2020 at 03:28:11AM +0530, Souptick Joarder wrote:
> These are dead code since 3.15. If there is no plan to use it further
> it can be removed forever.
Could you explain why you conclude this is dead code sine 3.15 -
and maybe point to the commit that made it dead.
I fai
Quoting Christoph Hellwig (2020-05-01 19:07:31)
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to check for ma
Quoting Jason A. Donenfeld (2020-04-30 23:10:16)
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something slower in the unlikely
Hi all,
On Thu, 30 Apr 2020 12:24:27 -0700 Bjorn Andersson
wrote:
>
> rd_full should be defined outside the CONFIG_DEBUG_FS region, in order
> to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled.
>
> Fixes: e515af8d4a6f ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP
From: Ira Weiny
Move the kmap() build bug to kmap_init() to facilitate patches to lift
kmap() to the core.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
Changes from V1:
combine code onto 1 line.
---
arch/xtensa/include/asm/highmem.h | 5 -
arch/xtensa/mm/highmem.c
From: Ira Weiny
We want to support kmap_atomic_prot() on all architectures and it makes
sense to define kmap_atomic() to use the default kmap_prot.
So we ensure all arch's have a globally available kmap_prot either as a
define or exported symbol.
Signed-off-by: Ira Weiny
---
arch/microblaze/i
From: Ira Weiny
kmap_atomic_prot() is now exported by all architectures. Use this
function rather than open coding a driver specific kmap_atomic.
Reviewed-by: Christian König
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira Weiny
---
drivers/gpu/drm/ttm/ttm_bo_util.c| 56 ++
From: Ira Weiny
Every single architecture (including !CONFIG_HIGHMEM) calls...
pagefault_enable();
preempt_enable();
... before returning from __kunmap_atomic(). Lift this code into the
kunmap_atomic() macro.
While we are at it rename __kunmap_atomic() to kunmap_atomic_high()
From: Ira Weiny
All architectures do exactly the same thing for kunmap(); remove all the
duplicate definitions and lift the call to the core.
This also has the benefit of changing kmap_unmap() on a number of
architectures to be an inline call rather than an actual function.
Reviewed-by: Christo
From: Ira Weiny
To support kmap_atomic_prot(), all architectures need to support
protections passed to their kmap_atomic_high() function. Pass
protections into kmap_atomic_high() and change the name to
kmap_atomic_high_prot() to match.
Then define kmap_atomic_prot() as a core function which cal
From: Ira Weiny
The kmap code for all the architectures is almost 100% identical.
Lift the common code to the core. Use ARCH_HAS_KMAP_FLUSH_TLB to
indicate if an arch defines kmap_flush_tlb() and call if if needed.
This also has the benefit of changing kmap() on a number of
architectures to be
From: Ira Weiny
To support kmap_atomic_prot() on all architectures each arch must
support protections passed in to them.
Change csky, mips, nds32 and xtensa to use their global constant
kmap_prot rather than a hard coded value which was equal.
Reviewed-by: Christoph Hellwig
Signed-off-by: Ira
From: Ira Weiny
Every arch has the same code to ensure atomic operations and a check for
!HIGHMEM page.
Remove the duplicate code by defining a core kmap_atomic() which only
calls the arch specific kmap_atomic_high() when the page is high memory.
Signed-off-by: Ira Weiny
---
Changes from V1:
From: Ira Weiny
Replace the use of BUG_ON(in_interrupt()) in the kmap() and kunmap()
in favor of might_sleep().
Besides the benefits of might_sleep(), this normalizes the
implementations such that they can be made generic in subsequent
patches.
Reviewed-by: Dan Williams
Reviewed-by: Christoph
From: Ira Weiny
During this kmap() conversion series we must maintain bisect-ability.
To do this, kmap_atomic_prot() in x86, powerpc, and microblaze need to
remain functional.
Create a temporary inline version of kmap_atomic_prot within these
architectures so we can rework their kmap_atomic() ca
From: Ira Weiny
The kmap infrastructure has been copied almost verbatim to every architecture.
This series consolidates obvious duplicated code by defining core functions
which call into the architectures only when needed.
Some of the k[un]map_atomic() implementations have some similarities but
Hi all,
Today's linux-next merge of the devicetree tree got a conflict in:
Documentation/devicetree/bindings/display/panel/panel-common.yaml
between commit:
92e513fb0798 ("dt-bindings: display: grammar fixes in panel/")
from the drm tree and commit:
3d21a4609335 ("dt-bindings: Remove ca
On Mon, May 04, 2020 at 02:35:09AM +0100, Al Viro wrote:
> On Sun, May 03, 2020 at 06:09:01PM -0700, ira.we...@intel.com wrote:
> > From: Ira Weiny
> >
> > The kmap infrastructure has been copied almost verbatim to every
> > architecture.
> > This series consolidates obvious duplicated code by d
44 matches
Mail list logo
