On Fri, 4 Mar 2022 at 07:31, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-03-03 20:23:06)
> > On Fri, 4 Mar 2022 at 01:32, Stephen Boyd wrote:
> > >
> > > Quoting Dmitry Baryshkov (2022-02-16 21:55:27)
> > > > The only clock for which we set the rate is the "stream_pixel". Rather
> > >
correct for typo:
-for (struct list_head *list = head->next, cond = (struct list_head *)-1; cond
== (struct list_head *)-1; cond = NULL) \
+for (struct list_head *list = head->next, *cond = (struct list_head *)-1; cond
== (struct list_head *)-1; cond = NULL) \
--
Xiaomeng Tong
> WARNING: This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> On 18/02/2022 14:30, Vinod Polimera wrote:
> > - Some DPU versions support inline rot90. It is supported only for
> > limited amount of UBWC formats.
> > - There
> From: Xiaomeng Tong
> > Sent: 03 March 2022 07:27
> >
> > On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > > The problem is the mis-use of iterator outside the loop on exit, and
> > > > the iterator will be the HEAD's
On Thu, Mar 03, 2022 at 06:48:24PM +0900, Byungchul Park wrote:
> On Thu, Mar 03, 2022 at 08:03:21AM +, Hyeonggon Yoo wrote:
> > On Thu, Mar 03, 2022 at 09:18:13AM +0900, Byungchul Park wrote:
> > > Hi Hyeonggon,
> > >
> > > Dept also allows the following scenario when an user guarantees that
On Thu, 3 Mar 2022 12:18:24 +, Daniel Thompson wrote:
> On Thu, Mar 03, 2022 at 03:26:57PM +0800, Xiaomeng Tong wrote:
> > On Thu, 3 Mar 2022 04:58:23 +, David Laight wrote:
> > > on 3 Mar 2022 10:27:29 +0800, Xiaomeng Tong wrote:
> > > > The problem is the mis-use of iterator outside the
Am 03.03.22 um 17:17 schrieb Michael Walle:
The supplied buffer might be on the stack and we get the following error
message:
[3.312058] at91_i2c e0070600.i2c: rejecting DMA map of vmalloc memory
Use i2c_{get,put}_dma_safe_msg_buf() to get a DMA-able memory region if
necessary.
Cc:
On Thu, Mar 03, 2022 at 02:34:34PM -0800, Matt Roper wrote:
In the past we've always assumed that an RCS engine is present on every
platform. However now that we have compute engines there may be
platforms that have CCS engines but no RCS, or platforms that are
designed to have both, but have
Dept works with waits preceeding an event, that might lead a deadlock.
Once the event has been handled, it's hard to ensure further waits
actually contibute to deadlock until next turn, which will start when
a sleep associated with that map happens.
So let Dept start tracking dependency when a
Makes Dept able to track dependencies by
wait_for_completion()/complete().
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 42 --
kernel/sched/completion.c | 12 ++--
2 files changed, 50 insertions(+), 4 deletions(-)
diff --git
For completions who don't want to get tracked by Dept, added
init_completion_nocheck() to disable Dept on it.
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/linux/completion.h
Dept already prevents creating dependencies between different depths of
the class indicated by *_lock_nested() when the lock acquisitions happen
consecutively.
lock A0 with depth
lock_nested A1 with depth + 1
...
unlock A1
unlock A0
Dept does not create A0 -> A1 dependency in this
struct crypto_larval's completion is used for multiple purposes e.g.
waiting for test to complete or waiting for probe to complete.
The completion variable needs to be split according to what it's used
for. Otherwise, Dept cannot distinguish one from another and doesn't
work properly. Now that it
Makes Dept able to track dependencies by mutex families.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h | 18 +++---
include/linux/mutex.h | 33 +
include/linux/rtmutex.h | 7 +++
3 files changed, 55 insertions(+), 3 deletions(-)
Workqueue already provides concurrency control. By that, any wait in a
work doesn't prevents events in other works with the control enabled.
Thus, each work would better be considered a different context.
So let Dept assign a different context id to each work.
Signed-off-by: Byungchul Park
---
Dept commits the staged wait in __schedule() even if the corresponding
wake_up() has already woken up the task. Which means Dept considers the
case as a sleep. This would help Dept work for stronger detection but
also leads false positives.
It'd be better to let Dept work only with real sleeps
The struct wait_queue_head array, bit_wait_table[] in sched/wait_bit.c
are shared by all its users, which unfortunately vary in terms of class.
So each should've been assigned its own class to avoid false positives.
It'd better let Dept work at a higher layer than wait_bit. So disabled
Dept
Makes SDT able to track dependencies by swait.
Signed-off-by: Byungchul Park
---
include/linux/swait.h | 4
kernel/sched/swait.c | 10 ++
2 files changed, 14 insertions(+)
diff --git a/include/linux/swait.h b/include/linux/swait.h
index 6a8c22b..dbdf2ce 100644
---
cb92173d1f0 (locking/lockdep, cpu/hotplug: Annotate AP thread) was
introduced to make lockdep_assert_cpus_held() work in AP thread.
However, the annotation is too strong for that purpose. We don't have to
use more than try lock annotation for that.
Furthermore, now that Dept was introduced,
CURRENT STATUS
--
Lockdep tracks acquisition order of locks in order to detect deadlock,
and IRQ and IRQ enable/disable state as well to take accident
acquisitions into account.
Lockdep should be turned off once it detects and reports a deadlock
since the data structure and algorithm
There is a case where all maps used for a type of wait/event is so large
in size. For instance, struct page can be a type for (un)lock_page().
The additional memory size for the maps would be 'the # of pages *
sizeof(struct dept_map)' if each struct page keeps its map all the way,
which might be
It'd be useful to show Dept internal stats and dependency graph on
runtime via proc for better information. Introduced the knobs.
Signed-off-by: Byungchul Park
---
kernel/dependency/Makefile| 1 +
kernel/dependency/dept.c | 24 --
kernel/dependency/dept_internal.h | 26
Makes Dept able to track dependencies by rwsem.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h | 24
include/linux/percpu-rwsem.h | 10 +-
include/linux/rwsem.h| 33 +
3 files changed, 62 insertions(+), 5
Dept should work independently from Lockdep. However, there's no choise
but to rely on Lockdep code and its instances for now.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h | 71 ---
include/linux/lockdep_types.h | 3 ++
It enters kernel mode on each syscall and each syscall handling should
be considered independently from the point of view of Dept. Otherwise,
Dept may wrongly track dependencies across different syscalls.
That might be a real dependency from user mode. However, now that Dept
just started to work,
Makes Dept able to track dependencies by seqlock with adding wait
annotation on read side of seqlock.
Signed-off-by: Byungchul Park
---
include/linux/seqlock.h | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git
Makes Dept able to track dependencies by PG_{locked,writeback}. For
instance, (un)lock_page() generates that type of dependency.
Signed-off-by: Byungchul Park
---
include/linux/dept_page.h | 78 +
include/linux/page-flags.h | 45
Makes SDT able to track dependencies by wait(waitqueue).
Signed-off-by: Byungchul Park
---
include/linux/wait.h | 6 +-
kernel/sched/wait.c | 16
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index
Dept would skip check for dmaps marked by dept_map_nocheck() permanently.
However, sometimes it needs to skip check for some dmaps temporarily and
back to normal, for instance, lock acquisition with a nest lock.
Lock usage check with regard to nest lock could be performed by Lockdep,
however,
llist_head and llist_node can be used by very primitives. For example,
Dept for tracking dependency uses llist things in its header. To avoid
header dependency, move those to types.h.
Signed-off-by: Byungchul Park
---
include/linux/llist.h | 8
include/linux/types.h | 8
2
Hi Linus and folks,
I've been developing a tool for detecting deadlock possibilities by
tracking wait/event rather than lock(?) acquisition order to try to
cover all synchonization machanisms. It's done on v5.17-rc1 tag.
Makes Dept able to track dependencies by rwlock.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h| 25
include/linux/rwlock.h | 52 ++
include/linux/rwlock_api_smp.h | 8 +++
include/linux/rwlock_types.h
Makes Dept able to track dependencies by spinlock.
Signed-off-by: Byungchul Park
---
include/linux/lockdep.h| 18 +++---
include/linux/spinlock.h | 26 ++
include/linux/spinlock_types_raw.h | 13 +
3 files changed, 54
Add clock selection code for AST2600. At AST2600 user could
select more than one dispaly timing. Add gfx flags for future
usage.
Signed-off-by: Tommy Haung
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 11 +++
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 14 ++
v1:
Add 1024x768@70Hz for AST2600 soc display timing selection.
Add gfx flag for future usage.
Testing steps:
1. Add below config to turn VT and LOGO on.
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
Update the aspeed_gfx_set_clk with display width.
At AST2600, the display clock could be coming from
HPLL clock / 16 = 75MHz. It would fit 1024x768@70Hz.
Another chip will still keep 800x600.
Signed-off-by: Tommy Haung
---
drivers/gpu/drm/aspeed/aspeed_gfx.h | 12 ++
On 3/3/22 09:21, Lucas Stach wrote:
Am Donnerstag, dem 03.03.2022 um 04:14 +0100 schrieb Marek Vasut:
On 3/2/22 10:23, Lucas Stach wrote:
[...]
I tend to agree with Marek on this one. We have an instance where the
blk-ctrl and the GPC driver between 8m, mini, nano, plus are close,
but
Quoting Dmitry Baryshkov (2022-03-03 20:23:06)
> On Fri, 4 Mar 2022 at 01:32, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-02-16 21:55:27)
> > > The only clock for which we set the rate is the "stream_pixel". Rather
> > > than storing the rate and then setting it by looping over all
On Fri, 4 Mar 2022 at 01:32, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-02-16 21:55:27)
> > The only clock for which we set the rate is the "stream_pixel". Rather
> > than storing the rate and then setting it by looping over all the
> > clocks, set the clock rate directly.
> >
> >
Hi Linus,
Things are quieting down as expected, just a small set of fixes, i915,
exynos, amdgpu, vrr, bridge and hdlcd. Nothing scary at all.
Dave.
drm-fixes-2022-03-04:
drm fixes for 5.17-rc7
i915:
- Fix GuC SLPC unset command
- Fix misidentification of some Apple MacBook Pro laptops as
MSM DRM driver already allows one to compile out the DP or DSI support.
Add support for disabling other features like MDP4/MDP5/DPU drivers or
direct HDMI output support.
Suggested-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 50
Let's make the match's data pointer a (sub-)driver's private data. The
only user currently is the msm_drm_init() function, using this data to
select kms_init callback. Pass this callback through the driver's
private data instead.
Signed-off-by: Dmitry Baryshkov
---
Currently the msm platform driver is a multiplex handling several cases:
- headless GPU-only driver,
- MDP4 with flat device nodes,
- MDP5/DPU MDSS with all the nodes being children of MDSS node.
This results in not-so-perfect code, checking the hardware version
(MDP4/MDP5/DPU) in several places,
Since now there is just one mdss subdriver, drop all the indirection,
make msm_mdss struct completely opaque (and defined inside msm_mdss.c)
and call mdss functions directly.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/msm_drv.c | 29 +++
drivers/gpu/drm/msm/msm_kms.h | 16
MDP5 and DPU1 both provide the driver handling the MDSS region, which
handles the irq domain and (incase of DPU1) adds some init for the UBWC
controller. Unify those two pieces of code into a common driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Makefile | 3
These patches coninue work started by AngeloGioacchino Del Regno in the
previous cycle by further decoupling and dissecting MDSS and MDP drivers
probe/binding paths.
This removes code duplication between MDP5 and DPU1 MDSS drivers, by
merging them and moving to the top level.
This patchset
On Thu, Mar 03, 2022 at 09:36:25AM -0500, Theodore Ts'o wrote:
> On Thu, Mar 03, 2022 at 02:23:33PM +0900, Byungchul Park wrote:
> > I totally agree with you. *They aren't really locks but it's just waits
> > and wakeups.* That's exactly why I decided to develop Dept. Dept is not
> > interested in
On Thu, Mar 03, 2022 at 10:54:56AM +0100, Jan Kara wrote:
> On Thu 03-03-22 10:00:33, Byungchul Park wrote:
> > Unfortunately, it's neither perfect nor safe without another wakeup
> > source - rescue wakeup source.
> >
> >consumer producer
> >
> >
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.
Overall the
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
From: Rob Clark
Any app controlled perfcntr collection (GL_AMD_performance_monitor, etc)
does not require counters to maintain state across context switches. So
clear them if systemwide profiling is not active.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 29
From: Rob Clark
Add a SYSPROF param for system profiling tools like Mesa's pps-producer
(perfetto) to control behavior related to system-wide performance
counter collection. In particular, for profiling, one wants to ensure
that GPU context switches do not effect perfcounter state, and might
From: Rob Clark
It was always expected to have a use for this some day, so we left a
placeholder. Now we do. (And I expect another use in the not too
distant future when we start allowing userspace to allocate GPU iova.)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c |
From: Rob Clark
Some clever folks figured out a way to use performance counters as a
side-channel[1]. But, other than the special case of using the perf
counters for system profiling, we can reset the counters across context
switches to protect against this.
This series introduces a SYSPROF
On Thu, Mar 03, 2022 at 09:36:25AM -0500, Theodore Ts'o wrote:
> On Thu, Mar 03, 2022 at 02:23:33PM +0900, Byungchul Park wrote:
> > I totally agree with you. *They aren't really locks but it's just waits
> > and wakeups.* That's exactly why I decided to develop Dept. Dept is not
> > interested in
On Thu, Mar 03, 2022 at 12:38:39PM +, Hyeonggon Yoo wrote:
> On Thu, Mar 03, 2022 at 06:48:24PM +0900, Byungchul Park wrote:
> > On Thu, Mar 03, 2022 at 08:03:21AM +, Hyeonggon Yoo wrote:
> > > On Thu, Mar 03, 2022 at 09:18:13AM +0900, Byungchul Park wrote:
> > > > Hi Hyeonggon,
> > > >
>
On 3/3/22 13:54, Maxime Ripard wrote:
[...]
Regarding the default value -- there are no in-tree users of this driver yet
(per git grep in current linux-next), do we really care about backward
compatibility in this case?
If it hasn't been in a stable release yet, no. If it did, yes
It was
Rename and inline macro ICN6211_DSI() into function chipone_writeb()
to keep all function names lower-case. No functional change.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
Cc: Thomas Zimmermann
To:
The chip contains fractional PLL, however the driver currently hard-codes
one specific PLL setting. Implement generic PLL parameter calculation code,
so any DPI panel with arbitrary pixel clock can be attached to this bridge.
The datasheet for this bridge is not available, the PLL behavior has
The chip is capable of swapping DPI RGB channels. The driver currently
does not implement support for this functionality. Write the MIPI_PN_SWAP
register to 0 to assure the color swap is disabled.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert
Both example code [1], [2] as well as one provided by custom panel vendor
set register SYS_CTRL_1 to 0x88. What exactly does the value mean is unknown
due to unavailable datasheet. Align this register value with example code.
[1]
The ICN6211 chip starts in I2C configuration mode after cold boot.
Implement support for configuring the chip via I2C in addition to
the current DSI LP command mode configuration support. The later
seems to be available only on chips which have additional MCU on
the panel/bridge board which
The chip register layout has nothing to do with MIPI DCS, the registers
incorrectly marked as MIPI DCS in the driver are regular chip registers
often with completely different function.
Fill in the actual register names and bits from [1] and [2] and add the
entire register layout, since the
Read out the Vendor/Chip/Version ID registers from the chip before
performing any configuration, and validate that the registers have
correct values. This is mostly a simple test whether DSI register
access does work, since that tends to be broken on various bridges.
Acked-by: Maxime Ripard
The DSI burst mode is more energy efficient than the DSI sync pulse mode,
make use of the burst mode since the chip supports it as well. Disable the
generation of EoT packet, the chip ignores it, so no point in emitting it.
Enable transmission of data in LP mode, otherwise register read via DSI
The driver currently hard-codes HS/VS polarity to active-low and DE to
active-high, which is not correct for a lot of supported DPI panels.
Add the missing mode flag handling for HS/VS/DE polarity.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
This series fixes multiple problems with the ICN6211 driver and adds
support for configuration of the chip via I2C bus.
First, in the current state, the ICN6211 driver hard-codes DPI timing
and clock settings specific to some unknown panel. The settings provided
by panel driver are ignored. Using
Implement .atomic_get_input_bus_fmts callback, which sets up the
input (DSI-end) format, and that format can then be used in pipeline
format negotiation between the DSI-end of this bridge and the other
component closer to the scanout engine.
Acked-by: Maxime Ripard
Signed-off-by: Marek Vasut
The HFP_HSW_HBP_HI register must be programmed with 2 LSbits of each
Horizontal Front Porch/Sync/Back Porch. Currently the driver programs
this register to 0, which breaks displays with either value above 255.
The HFP_MIN register must be set to the same value as HFP_LI, otherwise
there is
The driver currently hard-codes DSI lane count to two, however the chip
is capable of operating in 1..4 DSI lanes mode. Parse 'data-lanes' DT
property and program the result into DSI_CTRL register.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Robert Foss
Cc: Sam Ravnborg
It is necessary to specify the number of connected/used DSI data lanes when
using the DSI input port of this bridge. Document the 'data-lanes' property
of the DSI input port.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Maxime Ripard
Cc: Rob Herring
Cc: Robert Foss
Cc: Sam Ravnborg
Cc:
On Fri, 4 Mar 2022 at 02:56, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-03-03 15:50:50)
> > On Thu, 3 Mar 2022 at 12:40, Vinod Polimera
> > wrote:
> > >
> > > Kernel clock driver assumes that initial rate is the
> > > max rate for that clock and was not allowing it to scale
> > >
On Thu, 3 Mar 2022 at 14:43, Vinod Polimera wrote:
>
> - Some DPU versions support inline rot90. It is supported only for
> limited amount of UBWC formats.
> - There are two versions of inline rotators, v1 (present on sm8250 and
> sm7250) and v2 (sc7280). These versions differ in the list of
Convert the bindings to yaml and add the ast2600 compatible string.
The legacy mfd description was put in place before the gfx bindings
existed, to document the compatible that is used in the pinctrl
bindings.
Signed-off-by: Joel Stanley
---
.../devicetree/bindings/gpu/aspeed,gfx.yaml | 69
The example needs updating to match the to be added yaml bindings for
the gfx node.
Signed-off-by: Joel Stanley
---
.../bindings/pinctrl/aspeed,ast2500-pinctrl.yaml | 16
1 file changed, 16 insertions(+)
diff --git
v1: https://lore.kernel.org/all/20220302051056.678367-1-j...@jms.id.au/
This series cleans up the bindings for the ASPEED GFX unit.
The old text files are deleted for both the description under gpu, and the
placeholder one under mfd.
The mfd one existed because pinctrl for the 2500 depends on
Quoting Dmitry Baryshkov (2022-03-03 15:50:50)
> On Thu, 3 Mar 2022 at 12:40, Vinod Polimera wrote:
> >
> > Kernel clock driver assumes that initial rate is the
> > max rate for that clock and was not allowing it to scale
> > beyond the assigned clock value.
> >
> > Drop the assigned clock rate
On Thu, 3 Mar 2022 at 12:40, Vinod Polimera wrote:
>
> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.
>
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated value
On Fri, 4 Mar 2022 at 02:00, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-01-19 14:40:04)
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index 06d26c5fb274..6895c056be19 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++
On Fri, 4 Mar 2022 at 01:54, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2022-01-19 14:40:03)
> > diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> > index be06a62d7ccb..f18dfbb614f0 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.c
> > +++
Hi Stephen
There is some discussion going on about the base dependency of the change:
https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/
I will resend this with comments addressed once the dependency is sorted
out among intel, QC and laurent.
On Fri, 4 Mar 2022, at 08:05, Joel Stanley wrote:
> On Thu, 3 Mar 2022 at 19:34, Rob Herring wrote:
>>
>> On Wed, Mar 2, 2022 at 12:01 PM Rob Herring wrote:
>> >
>> > On Wed, Mar 02, 2022 at 03:40:56PM +1030, Joel Stanley wrote:
>> > > Convert the bindings to yaml and add the ast2600
On Thu, Mar 03, 2022 at 02:37:35PM -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> An earlier patch added support for compute engines. However, it missed
> enabling the anti-pre-emption w/a for the new engine class. So move
> the 'compute capable' flag earlier and use it for
Quoting Dmitry Baryshkov (2022-01-19 14:40:05)
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 759076357e0e..f83dca99f03d 100644
> --- a/drivers/gpu/drm/msm/msm_mdss.c
> +++ b/drivers/gpu/drm/msm/msm_mdss.c
> @@ -314,11 +314,11 @@ static const struct
Hi,
On Tue, Mar 1, 2022 at 6:11 PM Brian Norris wrote:
>
> DP AUX transactions can consist of many short operations. There's no
> need to power things up/down in short intervals.
>
> I pick an arbitrary 100ms; for the systems I'm testing (Rockchip
> RK3399), runtime-PM transitions only take a
Quoting Dmitry Baryshkov (2022-01-19 14:40:04)
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index 06d26c5fb274..6895c056be19 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -451,10 +451,18 @@ static inline void
Quoting Dmitry Baryshkov (2022-01-19 14:40:03)
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index be06a62d7ccb..f18dfbb614f0 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -1211,19 +1212,32 @@ static int
Quoting Dmitry Baryshkov (2022-01-19 14:40:02)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> b/drivers/gpu/drm/msm/msm_mdss.c
> similarity index 58%
> rename from drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c
> rename to drivers/gpu/drm/msm/msm_mdss.c
> index 9f5cc7f9e9a9..f5429eb0ae52
On 3/3/2022 14:34, Matt Roper wrote:
From: Stuart Summers
If RCS is not enumerated, GuC will return invalid parameters.
Make sure we do not send RCS supported when we have not enumerated
it.
Cc: Vinay Belgaumkar
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
Reviewed-by: John
Quoting Abhinav Kumar (2022-02-04 13:17:13)
> This series adds support for writeback block on DPU. Writeback
> block is extremely useful to validate boards having no physical displays
> in addition to many other use-cases where we want to get the output
> of the display pipeline to examine whether
From: Akeem G Abodunrin
Starting with DG2, preemption can no longer be controlled using userspace
on a per-context basis. Instead, the hardware only allows us to enable or
disable preemption in a global, system-wide basis. Also, we lose the
ability to specify the preemption granularity (such as
Hi,
On Thu, Mar 3, 2022 at 1:40 AM Vinod Polimera wrote:
>
> Kernel clock driver assumes that initial rate is the
> max rate for that clock and was not allowing it to scale
> beyond the assigned clock value.
>
> Drop the assigned clock rate property and vote on the mdp clock as per
> calculated
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was disabled. This is undesirable with GuC
submission as it prevents per engine reset of hung contexts. Hence
From: John Harrison
A workaround was added to the driver to allow OpenCL workloads to run
'forever' by disabling pre-emption on the RCS engine for Gen12.
It is not totally unbound as the heartbeat will kick in eventually
and cause a reset of the hung engine.
However, this does not work well in
From: John Harrison
GuC converts the pre-emption timeout and timeslice quantum values into
clock ticks internally. That significantly reduces the point of 32bit
overflow. On current platforms, worst case scenario is approximately
110 seconds. Rather than allowing the user to set higher values
From: John Harrison
Compute workloads are inherently not pre-emptible on current hardware.
Thus the pre-emption timeout was disabled as a workaround to prevent
unwanted resets. Instead, the hang detection was left to the heartbeat
and its (longer) timeout. This is undesirable with GuC submission
From: John Harrison
An earlier patch added support for compute engines. However, it missed
enabling the anti-pre-emption w/a for the new engine class. So move
the 'compute capable' flag earlier and use it for the pre-emption w/a
test.
Fixes: c674c5b9342e ("drm/i915/xehp: CCS should use RCS
Quoting Rob Clark (2022-03-03 13:47:14)
> On Thu, Mar 3, 2022 at 1:17 PM Rob Clark wrote:
> >
> > On Thu, Mar 3, 2022 at 12:47 PM Stephen Boyd wrote:
> > >
> > > Quoting Rob Clark (2022-03-03 11:46:47)
> > > > +
> > > > + /* then apply new value: */
> > >
> > > It would be safer to swap
From: Stuart Summers
If RCS is not enumerated, GuC will return invalid parameters.
Make sure we do not send RCS supported when we have not enumerated
it.
Cc: Vinay Belgaumkar
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 2 +-
1
In the past we've always assumed that an RCS engine is present on every
platform. However now that we have compute engines there may be
platforms that have CCS engines but no RCS, or platforms that are
designed to have both, but have the RCS engine fused off.
Various engine-centric
1 - 100 of 265 matches
Mail list logo
