Hi
Am 26.08.20 um 03:44 schrieb Dave Airlie:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
>
From: Dave Airlie
These tooks the same args in a different order to the dma
ones, just make things look nicer.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
This is based on top of misc-next with Christians io rework for nouveau.
https://github.com/airlied/linux/tree/ttm-tt-cleanup (is a complete tree)
The idea is to move towards ttm_tt being just a backing store for system
allocated pages + dma info, and not be anything to do with a global TT.
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_ttm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index c3530c6e46bd..4970c3450e88 100644
---
From: Dave Airlie
Signed-off-by: Dave Airlie
---
include/drm/ttm/ttm_tt.h | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/drm/ttm/ttm_tt.h b/include/drm/ttm/ttm_tt.h
index 2aa4cd7d6451..3b87ce43864a 100644
--- a/include/drm/ttm/ttm_tt.h
+++
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
drivers/gpu/drm/ttm/ttm_agp_backend.c | 17 -
include/drm/ttm/ttm_tt.h | 2 --
4 files changed, 4 insertions(+), 23
From: Dave Airlie
Get bound out is the next step.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_mn.c | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
From: Dave Airlie
next step move populated into upper page flag bits
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
From: Dave Airlie
These are now driver side.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c | 15 +++---
include/drm/ttm/ttm_tt.h | 39
2 files changed, 3 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c
From: Dave Airlie
This can be gotten back from bdev.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
From: Dave Airlie
If we move the bound flag out then the tt destroy is much
cleaner in a bo level wrapper, the code is in a few places,
leave the ttm_tt_destroy just about destroying the backing store.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 +
From: Dave Airlie
Make populating the backing store an explicit separate step
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
drivers/gpu/drm/nouveau/nouveau_bo.c| 6 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 7 ++-
From: Dave Airlie
These are just minor changes that fill some obvious holes.
Signed-off-by: Dave Airlie
---
include/drm/ttm/ttm_placement.h | 2 +-
include/drm/ttm/ttm_tt.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/drm/ttm/ttm_placement.h
From: Dave Airlie
Since the agp bind/unbind/destroy are now getting called from drivers
rather than via the func table, drop the bdev parameter.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 +++---
drivers/gpu/drm/radeon/radeon_ttm.c | 6 +++---
From: Dave Airlie
This is only used by drivers that have a dma tt backing store.
Signed-off-by: Dave Airlie
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 +--
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 9592505563bf..f07e7121bcc5 100644
---
From: Dave Airlie
These aren't used anymore.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
b/drivers/gpu/drm/ttm/ttm_agp_backend.c
index fbf98cd1a3e5..8072fb7c5bc8 100644
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
index a76a7f542dd8..6757be98be14
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_gem_vram_helper.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 788557bc5c01..93586a310971 100644
---
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d7f668dbc9e0..00b2c0359735 100644
---
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 45 +
drivers/gpu/drm/nouveau/nouveau_sgdma.c | 54 ++---
drivers/gpu/drm/nouveau/nouveau_ttm.h | 3 ++
3 files changed, 60 insertions(+), 42 deletions(-)
diff
From: Dave Airlie
Do agp decision in the driver, instead of special binding funcs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon.h| 7 +-
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_gem.c| 6 +-
From: Dave Airlie
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 15 +--
include/drm/ttm/ttm_tt.h | 6 ++
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_agp_backend.c
From: Dave Airlie
I want to remove the backend funcs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c| 15 +++---
include/drm/ttm/ttm_bo_driver.h | 36 +
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git
From: Dave Airlie
I want to split this structure up and use it differently,
step one remove bdev pointer from it and pass it explicitly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++
drivers/gpu/drm/drm_gem_vram_helper.c | 2 +-
On Sat, 22 Aug 2020 at 02:01, Christian König
wrote:
>
> While working on TTM cleanups I've found that the io_reserve_lru used by
> Nouveau is actually not working at all.
>
> In general we should remove driver specific handling from the memory
> management, so this patch moves the io_reserve_lru
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/qxl/qxl_display.c: In function
'qxl_display_read_client_monitors_config':
include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commits:
cacbbe7c0065 ("drm/amdgpu:
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/video/fbdev/arcfb.c
drivers/video/fbdev/atmel_lcdfb.c
drivers/video/fbdev/savage/savagefb_driver.c
between commit:
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
from Linus' tree and commit:
From: Tom Rix
clang static analysis flags this error
intel_combo_phy.c:268:7: warning: The left expression of the
compound assignment is an uninitialized value.
The computed value will also be garbage
ret &= check_phy_reg(...
~~~ ^
ret has no initial values,
On Wed, 19 Aug 2020 12:22:45 +0200, Lubomir Rintel wrote:
> Himax HX8837 is a secondary display controller used to drive the panel
> on OLPC platforms.
>
> Signed-off-by: Lubomir Rintel
>
> ---
> Changes since v3:
> - Moved to bindings/display/
> - Added the ports
> - Converted to YAML
> -
On Wed, 19 Aug 2020 12:12:05 +0200, Lubomir Rintel wrote:
> Add the Innolux LS075AT011 7.5" (1200x900) color/reflective LCD panel to
> the panel-simple compatible list. This panel is used in the OLPC laptops.
>
> Signed-off-by: Lubomir Rintel
> ---
>
Hi Maxime,
Am 25.08.20 um 17:06 schrieb Maxime Ripard:
> Hi Stefan,
>
> On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote:
>> Am 29.07.20 um 16:42 schrieb Maxime Ripard:
>>> Hi,
>>>
>>> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote:
On Wed, 8 Jul 2020 at 18:43,
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instance will allow distros to enable drm
Hi Mauro.
Laurent and I discussed this driver a little on irc.
Some highlights:
This parts could use register names:
+ writel(0x2, noc_dss_base + 0xc);
+ writel(0x2, noc_dss_base + 0x8c);
+ writel(0x2, noc_dss_base + 0x10c);
+ writel(0x2, noc_dss_base + 0x18c);
The two
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD,
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h |
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector")
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..201c0b4335563 100644
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
---
Hi Mauro
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
>
> If you'd like to see the entire thing, I'm placing it here:
>
>
> https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/hikey970_v2/
Review 3/3
For next
Hi Laurent,
On 23/08/2020 19:26, Aaro Koskinen wrote:
> Hi,
>
> On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
>> On 04/08/2020 15:13, Tomi Valkeinen wrote:
>
>>> Can you try to pinpoint a bit where the hang happens? Maybe add
>>> DRM/omapdrm debug prints, or perhaps sysrq
On Sat, Jul 4, 2020 at 9:38 PM Maxime Ripard wrote:
>
> The LVDS controller can invert the polarity / lanes of the LVDS output.
> The default polarity causes some issues on some panels.
>
> However, U-Boot has always used the opposite polarity without any reported
> issue, and the only currently
On 2020-08-22 5:59 a.m., Michel Dänzer wrote:
On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
On 2020-08-21 12:57 p.m., Michel Dänzer wrote:
From: Michel Dänzer
Don't check drm_crtc_state::active for this either, per its
documentation in include/drm/drm_crtc.h:
* Hence drivers must
On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote:
> On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote:
> > Not entirely sure why this never came up when I originally tested this
> > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc
> > appears to cause the display engine to
On Mon, Aug 24, 2020 at 11:31 PM Rodrigo Siqueira
wrote:
>
> In the vkms_composer.c, some of the functions related to CRC and compose
> have interdependence between each other. This patch reworks some
> functions inside vkms_composer to make crc and composer computation
> decoupled.
>
> This
On Tue, Aug 25, 2020 at 12:45 PM Melissa Wen wrote:
>
> On 08/24, Rodrigo Siqueira wrote:
> > This patch implements the necessary functions to add writeback support
> > for vkms. This feature is useful for testing compositors if you don't
> > have hardware with writeback support.
> >
> > Change
Hi Rodrigo,
Nice work!
I tested this on the kms_writeback set of subtests and works fine.
I have also checked it on the other IGT tests that I usually uses:
- kms_cursor_crc/cursor-alpha-transparent was affected by a small
problem in the bitmap_clear of the get_pixel_from_buffer function,
On 08/24, Rodrigo Siqueira wrote:
> This patch implements the necessary functions to add writeback support
> for vkms. This feature is useful for testing compositors if you don't
> have hardware with writeback support.
>
> Change in V4 (Emil and Melissa):
> - Move signal completion above
On 08/24, Rodrigo Siqueira wrote:
> The compute_crc() function is responsible for calculating the
> framebuffer CRC value; due to the XRGB format, this function has to
> ignore the alpha channel during the CRC computation. Therefore,
> compute_crc() set zero to the alpha channel directly in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-08-24 9:43 a.m., Pekka Paalanen wrote:
> On Sat, 22 Aug 2020 11:59:26 +0200 Michel Dänzer
> wrote:
>> On 2020-08-21 8:07 p.m., Kazlauskas, Nicholas wrote:
>>> On 2020-08-21 12:57 p.m., Michel Dänzer wrote:
From: Michel Dänzer
From: Sidong Yang , Haneen Mohammed
When vkms_get_vblank_timestamp() is called very first time without
enabling vblank before, vblank time has just intial value and it makes
warning message. this patch prevents warning message by setting vblank
time to current time.
Cc: Daniel Vetter
Cc:
On Mon, Aug 24, 2020 at 11:52 PM Christoph Hellwig wrote:
>
> On Sat, Aug 22, 2020 at 10:52:54AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Now that it isn't causing problems to use dma_map/unmap, we can drop the
> > hack of using dma_sync in certain cases.
>
> Great to see! What did
Am 10.07.20 um 11:47 schrieb Stefan Wahren:
> Hi Marek,
>
> Am 02.07.20 um 08:58 schrieb Marek Szyprowski:
>> On 01.07.2020 20:49, Stefan Wahren wrote:
>>> Am 01.07.20 um 09:39 schrieb Marek Szyprowski:
card->owner is a required property and since commit 81033c6b584b ("ALSA:
core: Warn
On Mon, Aug 24, 2020 at 11:15:01PM -0400, Rodrigo Siqueira wrote:
> Hi Sidong,
>
> Thanks a lot for your patch and effort to improve VKMS.
>
> On 08/18, Sidong Yang wrote:
> > I wrote this patch for TODO list in vkms documentation.
> >
> > Use alpha value to blend source value and destination
Hi Mauro,
On Tue, 25 Aug 2020 at 12:30, Mauro Carvalho Chehab
wrote:
> Sorry, but I can't agree that review is more important than to be able
> to properly indicate copyrights in a valid way at the legal systems that
> it would apply ;-)
The way to properly indicate copyright coverage is to
Hi Rodrigo,
Thanks for the review!
I just sent a v2 applying your suggestions.
Best Regards,
Melissa Wen
Melissa Wen
On Tue, Aug 25, 2020 at 12:04 AM Rodrigo Siqueira
wrote:
>
> Hi Melissa,
>
> First of all, thanks a lot for your patch!
>
> Follows my inline comments.
>
> On 08/19, Melissa
The VKMS blend function was ignoring the alpha channel and just
overwriting vaddr_src with vaddr_dst. This XRGB approach triggers a
warning when running the kms_cursor_crc/cursor-alpha-transparent test
case. In IGT, cairo_format_argb32 uses premultiplied alpha (according to
documentation). Also
Hi Mauro,
On Tue, Aug 25, 2020 at 01:30:25PM +0200, Mauro Carvalho Chehab wrote:
> Em Tue, 25 Aug 2020 05:29:29 +1000
> Dave Airlie escreveu:
>
> > On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> > wrote:
> > >
> > > Hi Mauro,
> > >
> > > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro
Em Tue, 25 Aug 2020 05:29:29 +1000
Dave Airlie escreveu:
> On Thu, 20 Aug 2020 at 20:02, Laurent Pinchart
> wrote:
> >
> > Hi Mauro,
> >
> > On Thu, Aug 20, 2020 at 09:03:26AM +0200, Mauro Carvalho Chehab wrote:
> > > Em Wed, 19 Aug 2020 12:52:06 -0700 John Stultz escreveu:
> > > > On Wed,
Hello Mathieu Malaterre,
The patch e9c0c874711b: "drm/dp: annotate implicit fall throughs"
from Jan 14, 2019, leads to the following static checker warning:
drivers/gpu/drm/drm_dp_helper.c:495 drm_dp_downstream_max_bpc()
warn: ignoring unreachable code.
Patchset Summary:
Enhance a PCIe host controller driver. Because of its unusual design
we are foced to change dev->dma_pfn_offset into a more general role
allowing multiple offsets. See the 'v1' notes below for more info.
v11:
Commit: "device-mapping: Introduce DMA range map,
The new field 'dma_range_map' in struct device is used to facilitate the
use of single or multiple offsets between mapping regions of cpu addrs and
dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
capable of holding a single uniform offset and had no region bounds
checking.
On 8/20/20 6:01 PM, Robin Murphy wrote:
> On 2020-08-20 20:55, Sakari Ailus wrote:
>> On Thu, Aug 20, 2020 at 06:25:19PM +0100, Robin Murphy wrote:
>>> On 2020-08-20 17:53, Sakari Ailus wrote:
Hi Robin,
On Thu, Aug 20, 2020 at 04:08:36PM +0100, Robin Murphy wrote:
> Now that
Hi Robin,
On 8/20/20 10:08 AM, Robin Murphy wrote:
> Now that arch/arm is wired up for default domains and iommu-dma,
> implement the corresponding driver-side support for DMA domains.
>
> Signed-off-by: Robin Murphy
> ---
> drivers/iommu/omap-iommu.c | 22 +-
> 1 file
The values for "se_num" and "sh_num" come from the user in the ioctl.
They can be in the 0-255 range but if they're more than
AMDGPU_GFX_MAX_SE (4) or AMDGPU_GFX_MAX_SH_PER_SE (2) then it results in
an out of bounds read.
I split this function into to two to make the error handling simpler.
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Changes in v5:
- Fix an
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cycle
are now u64
Changes
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the
Hi All,
I missed on 64-bit divide caused by pwm_state.period and pwm_state.duty_cycle
being changed
to u64-s in 5.9. This new version fixes this, otherwise this is identical to v6:
Here is v6 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 =
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /*
On 8/25/20 1:32 AM, Jens Wiklander wrote:
On Mon, Aug 24, 2020 at 02:11:25PM -0700, John Hubbard wrote:
...
OK, one more try, this time actually handling the _USER_MAPPED vs.
_KERNEL_MAPPED pages!
thanks,
John Hubbard
NVIDIA
Looks good and it works too! :-) I've tested it on my Hikey board
1 - 100 of 119 matches
Mail list logo
