Please ignore this series, it has issues. I'll update it and resubmit.
Thanks,
Janusz
On Thursday, 15 September 2022 18:52:08 CEST Janusz Krzysztofik wrote:
> i915_perf assumes that it can use the i915_gem_context reference to
> protect its i915->gem.contexts.list iteration. However, this requi
On Friday, 16 September 2022 01:26:51 CEST Matt Roper wrote:
> From: Chris Wilson
>
> If we abort driver initialisation in the middle of gt/engine discovery,
> some engines will be fully setup and some not. Those incompletely setup
> engines only have 'engine->release == NULL' and so will leak an
Hi Philipp,
Am Donnerstag, dem 15.09.2022 um 16:40 +0200 schrieb Philipp Zabel:
> Hi Lucas,
>
> On Do, 2022-09-15 at 16:19 +0200, Lucas Stach wrote:
> > While the interface for the MMU mapping takes phys_addr_t to hold a
> > full 64bit address when necessary and MMUv2 is able to map physical
> >
Add 1152x864 into support list.
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_mode.c | 3 +++
drivers/gpu/drm/ast/ast_tables.h | 7 +++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 214b10178454..0b2c5fe8dc2c
Hi Matt,
On Thu, Sep 15, 2022 at 04:26:54PM -0700, Matt Roper wrote:
> From: Tvrtko Ursulin
>
> This, along with the changes already landed in commit 1c66a12ab431
> ("drm/i915: Handle each GT on init/release and suspend/resume") makes
> engines from all GTs actually known to the driver.
>
> To
dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large
struct in its frame, which can result in:
drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes
is larger than 1024 bytes [-Wframe-larger-than=]
As the performance of the function is of no concern, let
Fix doc related warnings seen with W=1: the function names have changed
but the docs have not been changed accordingly.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 2 +-
drivers/gpu/drm/omapdrm/omap_irq.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff
On Fri, Sep 16, 2022, at 10:22 AM, Tomi Valkeinen wrote:
> dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large
> struct in its frame, which can result in:
>
> drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of
> 1060 bytes is larger than 1024 bytes [-Wframe-large
On 15/09/2022 21:49, Arnd Bergmann wrote:
On Thu, Sep 15, 2022, at 8:17 PM, kernel test robot wrote:
Hi Arnd,
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 3245cb65fd91cd514801bf91f5a3066d562f0ac4
commit: 3d427228f7370894680580fcd0381c0349624fa1 ARM: ixp
On Fri, Sep 16, 2022 at 02:39:21PM +0800, Zheng Hacker wrote:
> >From 8d95c1399e3ff345500a575e21254a73b0c89144 Mon Sep 17 00:00:00 2001
> From: xmzyshypnc <1002992...@qq.com>
> Date: Fri, 16 Sep 2022 14:37:48 +0800
> Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry
>
> The
Hi Jagan,
On 14.09.2022 11:39, Jagan Teki wrote:
> On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
> wrote:
>> On 13.09.2022 19:29, Jagan Teki wrote:
>>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
>>> wrote:
On 06.09.2022 21:07, Jagan Teki wrote:
> On Mon, Sep 5, 2022 at 4:54 PM M
Hi Linus,
This is the regular drm fixes pull, the i915 and misc fixes are fairly
regular, but the amdgpu contains fixes for new hw blocks, the dcn314
specific path hookups and also has a bunch of fixes for clang stack
size warnings which are a bit churny but fairly straightforward. This
means it l
Hi Dave & Daniel,
Here goes the final drm-intel-gt-next towards 6.1.
For stable platforms we have fixes for throttle reasons decoding to sysfs, GuC
version update to 7.5, XeHP SDV GSC support and the usual pile of smaller fixes.
DG2 and DG1 runtime PM is now mostly fixed for LMEM access via mmap
This patch series aims to support the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI video mode only.
This unit supports MIPI Alliance Specification for Display Serial Interface
(DSI)
Specification. This unit provides a solution for transmitting MIPI DSI compliant
digital vid
The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
can operate in DSI mode, with up to four data lanes.
Signed-off-by: Biju Das
Reviewed-by: Rob Herring
Reviewed-by: Laurent Pinchart
Reviewed-by: Geert Uytterhoeven
---
v6->v7:
* No change.
v5->v6:
* No change.
v4->v5:
This driver supports the MIPI DSI encoder found in the RZ/G2L
SoC. It currently supports DSI video mode only.
Signed-off-by: Biju Das
Acked-by: Sam Ravnborg
---
v6->v7:
* Added rzg2l_mipi_dsi_stop_video() counterpart of
rzg2l_mipi_dsi_start_video().
* Error labels are named according to the c
Add 1152x864 into support list.
Signed-off-by: Jammy Huang
---
v2 changes:
- add check in mode_valid
---
drivers/gpu/drm/ast/ast_mode.c | 9 +
drivers/gpu/drm/ast/ast_tables.h | 7 +++
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm
On Fri, Sep 16, 2022, at 10:24 AM, Tomi Valkeinen wrote:
> On 15/09/2022 21:49, Arnd Bergmann wrote:
>> On Thu, Sep 15, 2022, at 8:17 PM, kernel test robot wrote:
>> I think hte problem is that struct dsi_irq_stats is just too
>> large, at 776 bytes. The interrupts are disabled during a copy
>> fro
On 16/09/2022 02:43, Matt Roper wrote:
Although the bspec lists several MMIO ranges as "MSLICE," it turns out
that a subset of these are of a "GAM" subclass that has unique rules and
doesn't followed regular mslice steering behavior.
* Xe_HP SDV: GAM ranges must always be steered to 0,0. T
On 15/09/2022 21:03, John Harrison wrote:
On 9/15/2022 01:59, Tvrtko Ursulin wrote:
Hi,
On 15/09/2022 00:46, john.c.harri...@intel.com wrote:
From: John Harrison
Going forwards, the intention is for GuC firmware files to be named
for their major version only and HuC firmware files to have
Am Donnerstag, dem 08.09.2022 um 14:33 -0400 schrieb Andrey Grodzovsky:
> On 2022-09-08 14:10, Lucas Stach wrote:
> > Track the accumulated time that jobs from this entity were active
> > on the GPU. This allows drivers using the scheduler to trivially
> > implement the DRM fdinfo when the hardware
On 2022-09-15 22:44, Rodrigo Siqueira Jordao wrote:
>
> First of all, thanks a lot for your review. I want to take this opportunity
> to discuss this topic in more depth and learn more from you and others.
That really should have happened before submitting this patch. It was luck that
I happene
Some cases are not handled well for ast2600.
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast_mode.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index d327dcbaf032..be9bbc888ac3 100644
--- a/
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove the
context from the
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after we drop the
final reference and release the struct. If, as currently, we remove
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put.
However, there is a risk of triggering kernel warning on contexts list not
emp
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 38 ++-
1 file changed, 37 insertions(+), 1 deletion(-)
di
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
> Hi Lucas,
>
> On 08/09/2022 19:10, Lucas Stach wrote:
> > This exposes a accumulated GPU active time per client via the
> > fdinfo infrastructure.
> >
> > Signed-off-by: Lucas Stach
> > ---
> > drivers/gpu/drm/etna
Fix issues in HFVSDB parsing for DSC support.
Also minor refactoring in Logging.
Split from original patch into a new series.
https://patchwork.freedesktop.org/patch/495193/
v2: Minor styling fixes.
Ankit Nautiyal (4):
drm/edid: Fix minimum bpc supported with DSC1.2 for HDMI sink
drm/edid: S
Replace multiple log lines with a single log line at the end of
parsing HF-VSDB. Also use drm_dbg_kms instead of DRM_DBG_KMS, and
add log for DSC1.2 support.
v2: Fixed the formatting issues in the logging (Jani).
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 21 +---
DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
SCDS). Since minimum length of Data block is 7, all bytes greater than 7
must be read only after checking the length of the data block.
This patch adds check for data block length before reading relavant DSC
bytes.
Signed-off-b
HF-VSDB/SCDB has bits to advertise support for 16, 12 and 10 bpc.
If none of the bits are set, the minimum bpc supported with DSC is 8.
This patch corrects the min bpc supported to be 8, instead of 0.
Fixes: 76ee7b905678 ("drm/edid: Parse DSC1.2 cap fields from HFVSDB block")
Cc: Ankit Nautiyal
Move the DSC parsing logic into separate function.
v2: Rebase.
Signed-off-by: Ankit Nautiyal
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 128 -
1 file changed, 69 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers
On Fri, Sep 16, 2022 at 1:58 PM Marek Szyprowski
wrote:
>
> Hi Jagan,
>
> On 14.09.2022 11:39, Jagan Teki wrote:
> > On Wed, Sep 14, 2022 at 2:51 PM Marek Szyprowski
> > wrote:
> >> On 13.09.2022 19:29, Jagan Teki wrote:
> >>> On Wed, Sep 7, 2022 at 3:34 PM Marek Szyprowski
> >>> wrote:
> O
While the interface for the MMU mapping takes phys_addr_t to hold a
full 64bit address when necessary and MMUv2 is able to map physical
addresses with up to 40bit, etnaviv_iommu_map() truncates the address
to 32bits. Fix this by using the correct type.
Fixes: 931e97f3afd8 ("drm/etnaviv: mmuv2: sup
Hello Thomas,
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), so drivers can just use that instead.
>
> Signed-off-by: Thomas Zimmer
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:44PM +0200, Thomas Zimmermann wrote:
> Open-code drm_plane_init() and remove the function from DRM. The
> implementation of drm_plane_init() is a simple wrapper around a call
> to drm_universal_plane_init(), so drivers can just use
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a qui
Gentle ping. I know it's conference time, but I'd appreciate if this
could be merged in time for v6.1.
I also forgot to mention explicitly in the pull request that patch
"media: vsp1: Add premultiplied alpha support" has Mauro's approval for
merge through the DRM tree (the patch has his ack, but b
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:46PM +0200, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas Zimmerm
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Provide drm_univeral_plane_alloc(), which allocated an initializes a
> plane. Code for non-atomic drivers uses this pattern. Convert it to
> the new function. The modeset helpers contain a quirk for handling their
> color formats differently. Set the flag
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:47PM +0200, Thomas Zimmermann wrote:
> Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions
> of non-atomic drivers to default values. The macro is not supposed to
> be used in new code, but helps with documenting
On Fr, 2022-09-16 at 12:40 +0200, Lucas Stach wrote:
> While the interface for the MMU mapping takes phys_addr_t to hold a
> full 64bit address when necessary and MMUv2 is able to map physical
> addresses with up to 40bit, etnaviv_iommu_map() truncates the address
> to 32bits. Fix this by using the
On 9/9/22 12:59, Thomas Zimmermann wrote:
> The plane update and disable helpers are only useful for non-atomic
> drivers. Print a warning if an atomic driver calls them.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best re
On 9/9/22 12:59, Thomas Zimmermann wrote:
> Provide DRM_PLANE_NON_ATOMIC_FUNCS, which initializes plane functions
> of non-atomic drivers to default values. The macro is not supposed to
> be used in new code, but helps with documenting and finding existing
> users.
>
> Signed-off-by: Thomas Zimmer
Hi
Am 16.09.22 um 13:06 schrieb Laurent Pinchart:
Hi Thomas,
Thank you for the patch.
On Fri, Sep 09, 2022 at 12:59:45PM +0200, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
the
Hi
Am 16.09.22 um 13:22 schrieb Javier Martinez Canillas:
On 9/9/22 12:59, Thomas Zimmermann wrote:
Provide drm_univeral_plane_alloc(), which allocated an initializes a
plane. Code for non-atomic drivers uses this pattern. Convert it to
the new function. The modeset helpers contain a quirk for
On 9/16/22 13:41, Thomas Zimmermann wrote:
[...]
>>
>>> + * @dev: DRM device
>>> + * @type: the type of the struct which contains struct &drm_plane
>>> + * @member: the name of the &drm_plane within @type
>>> + * @possible_crtcs: bitmask of possible CRTCs
>>> + * @funcs: callbacks for the new pla
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Reduce possible side effects of assigning the region and bailing out due
> to errors.
>
> Signed-off-by: Lucas De Marchi
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index acc561c0f0
On 16-09-2022 02:09, Lucas De Marchi wrote:
> DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
> of the base address of stolen. For the supported platforms bits 0-19 are
> zero but that may not be true in future. Add the missing mask.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
Due to i915_perf assuming that it can use the i915_gem_context reference
to protect its i915->gem.contexts.list iteration, we need to defer removal
of the context from the list until last reference to the context is put
Reviewed-by: Gwan-gyeong Mun
On 9/16/22 12:24 PM, Janusz Krzysztofik wrote:
From: Chris Wilson
i915_perf assumes that it can use the i915_gem_context reference to
protect its i915->gem.contexts.list iteration. However, this requires
that we do not remove the context from the list until after
Hi Dave & Daniel -
The final feature pull for v6.1.
drm-intel-next-2022-09-16-1:
drm/i915 feature pull #2 for v6.1:
Features and functionality:
- More Meteorlake platform enabling (Radhakrishna, Imre, Madhumitha)
- Allow seamless M/N changes on eDP panels that support it (Ville)
- Switch DSC d
On 16/09/2022 10:50, Lucas Stach wrote:
Hi Tvrtko,
Am Freitag, dem 16.09.2022 um 10:31 +0100 schrieb Tvrtko Ursulin:
Hi Lucas,
On 08/09/2022 19:10, Lucas Stach wrote:
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
dri
On 16-09-2022 02:09, Lucas De Marchi wrote:
> Add some helpers: adjust_stolen(), request_smem_stolen_() and
> init_reserved_stolen() that are now called by i915_gem_init_stolen() to
> initialize each part of the Data Stolen Memory region. Main goal is to
> split the reserved part, also known as
Looks good to me.
Reviewed-by: Gwan-gyeong Mun
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote:
There are a couple of issues at i915 display kernel-doc markups:
drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning:
Function parameter or member 'intel_connector' not desc
On 2022-09-16 05:12, Lucas Stach wrote:
Am Donnerstag, dem 08.09.2022 um 14:33 -0400 schrieb Andrey Grodzovsky:
On 2022-09-08 14:10, Lucas Stach wrote:
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement
On 9/9/22 10:34 AM, Mauro Carvalho Chehab wrote:
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- renamed functions;
- wrong parameter syntax.
Fix such warnings:
drivers/gpu/drm/i915/i915_active
The pull request you sent on Fri, 16 Sep 2022 18:28:58 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-09-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5763d7f29652f94bdfc9dab87888f79ba6bb6c34
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
If DEBUG_KERNEL is selected with a kernel build without DRM, Kconfig still
asks if DRM_DEBUG_MODESET_LOCK is to be selected or not, although this has
no influence on the kernel without DRM.
Make DRM_DEBUG_MODESET_LOCK depend on DRM to avoid needless questions
during kernel build configuration.
Si
On Fri, Sep 16, 2022 at 10:02:32AM +0100, Tvrtko Ursulin wrote:
>
> On 16/09/2022 02:43, Matt Roper wrote:
> > Although the bspec lists several MMIO ranges as "MSLICE," it turns out
> > that a subset of these are of a "GAM" subclass that has unique rules and
> > doesn't followed regular mslice ste
Am Samstag, dem 10.09.2022 um 13:29 -0700 schrieb Doug Brown:
> This series contains a few special cases for supporting the GC300
> properly. These were found in the drivers in the vivante_kernel_drivers
> repository. These changes were tested on a PXA168 with GC300 revision
> 0x2201 (date 0x200808
This series adds the HWMON support for DGFX
Test-with: 20220914140721.3500129-1-riana.ta...@intel.com
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
v3:
-
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jan
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use hwm
From: Ashutosh Dixit
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3:
- Use HWMON_CHANNEL_INFO to define power1_crit,
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2:
- Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
- Updated date, kernel version in document
From: Ashutosh Dixit
Expose power1_max_interval, that is the tau corresponding to PL1. Some bit
manipulation is needed because of the format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned up hwm
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fixed review comments (Ashutosh)
Signed-off-by: Ashutosh Dixit
Signed-off-by: Dale B Stimson
Signed-off-by: Badal Nilawar
Acked-by: Guenter Roeck
R
Track the accumulated time that jobs from this entity were active
on the GPU. This allows drivers using the scheduler to trivially
implement the DRM fdinfo when the hardware doesn't provide more
specific information than signalling job completion anyways.
Signed-off-by: Lucas Stach
Reviewed-by: A
Allows to easily track if several fd are pointing to the same
execution context due to being dup'ed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 +++
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/etnaviv/e
This exposes a accumulated GPU active time per client via the
fdinfo infrastructure.
Signed-off-by: Lucas Stach
---
v2:
- fix code style
- switch to raw seq_printf
- leave some breadcrumbs about the output format
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 40 ++-
1 file
This suppresses diagnosis for PWM_DEBUG routines and makes sure that
pwm->state isn't modified in pwm_device_request() if .get_state() fails.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c
Record and report an error code for the events. This allows to report
about failed calls without ambiguity and so gives a more complete
picture.
Signed-off-by: Uwe Kleine-König
---
drivers/pwm/core.c | 18 --
include/trace/events/pwm.h | 20 ++--
2 files c
Most drivers succeed to read out the programmed state unconditionally.
But some don't, allow them to signal a failure to the pwm core.
All drivers are adapted to return 0 on success and forward the error
code otherwise.
The core doesn't make use of this yet.
Signed-off-by: Uwe Kleine-König
---
Hi greg,
Thanks for pointing that out. Working on it now :)
Best wishes,
Zheng Wang
Greg KH 于2022年9月16日周五 16:25写道：
>
> On Fri, Sep 16, 2022 at 02:39:21PM +0800, Zheng Hacker wrote:
> > >From 8d95c1399e3ff345500a575e21254a73b0c89144 Mon Sep 17 00:00:00 2001
> > From: xmzyshypnc <1002992...@qq.co
Hi Dave, Daniel,
Updates for 6.1.
The following changes since commit 213cb76ddc8b875e772f9f4d173feefa122716af:
Merge tag 'drm-intel-gt-next-2022-09-09' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-09-12 21:12:23
+1000)
are available in the Git repository at:
https:/
>From afe79848cb74cc8e45ab426d13fa2394c87e0422 Mon Sep 17 00:00:00 2001
From: xmzyshypnc <1002992...@qq.com>
Date: Fri, 16 Sep 2022 23:48:23 +0800
Subject: [PATCH] drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry
There is a double-free security bug in split_2MB_gtt_entry.
Here is a callin
On Fri, Sep 16, 2022 at 05:50:33PM +0530, Iddamsetty, Aravind wrote:
On 16-09-2022 02:09, Lucas De Marchi wrote:
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory
From: Ville Syrjälä
I've talked about making blocking commits lockless a few
times in the past, so here's finally an attempt at it.
The main benefit I see from this is that TEST_ONLY commits
no longer getting blocked on the mutexes by parallel blocking
commits.
I have a small test here that spoo
From: Ville Syrjälä
The easiest way to execute blocking commits locklessly is to just
schedule them onto the workqueue excatly as we do for nonblocking
commits. And to preserve the blocking behaviour of the ioctl we
just flush the work before exiting the kernel.
We do need to reorder the state_p
From: Ville Syrjälä
Currently we reuse the commit_work for a later cleanup step.
Let's not do that so that atomic ioctl handler won't accidentally
wait for the cleanup work when it really wants to just wait on the
commit_tail() part. We'll just add another work struct for the
cleanup.
Cc: Daniel
From: Ville Syrjälä
Currently a nonblocking commit will actually block if it is
preceded by a blocking commit. It just happens block on the
mutex rather than on the completion. I shall call these as
not-actually-nonblocking commits.
I would like to make blocking commits execute locklessly,
just
From: Ville Syrjälä
Make blocking commits execute locklessly (just as nonblocking
commits do) by scheduling them onto the workqueues as well.
There will be a later flush_work() done by whoever called
the commit hook to make sure the blocking behaviour of the
ioctl/etc. is preserved.
I also wonde
Hi Johan,
On Wed, Sep 14, 2022 at 1:01 AM Johan Hovold wrote:
>
> On Tue, Sep 13, 2022 at 03:23:10PM -0500, Steev Klimaszewski wrote:
> > Hi Johan,
> >
> > On 9/13/22 3:53 AM, Johan Hovold wrote:
> > > The MSM DRM driver is currently broken in multiple ways with respect to
> > > probe deferral. N
Applied. Thanks!
On Wed, Sep 14, 2022 at 1:15 PM Colin Ian King wrote:
>
> There is a spelling mistake in a pr_debug message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/driv
Better split, document, and make the code paths for integrated and discrete
more similar.
v2:
- s/GENMASK/REG_GENMASK64/ where appropriate
- Fix comment
Signed-off-by: Lucas De Marchi
---
Lucas De Marchi (3):
drm/i915: Add missing mask when reading GEN12_DSMBASE
drm/i915: Split i
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes of
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the initia
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty
Reviewed-by: Caz Yokoyama
Signed-o
Applied the series.
Thanks,
Alex
On Wed, Sep 14, 2022 at 9:58 PM Yang Li wrote:
>
> clean up some inconsistent indentings
>
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2177
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
> ---
> .../gpu/drm/amd/display/dc/dml/dcn31/display_mod
This series supports common bridge support for Samsung MIPI DSIM
which is used in Exynos and i.MX8MM SoC's.
Previous v4 can be available here [1], repo on linux-next [2] and
Engicam i.Core MX8M Mini SoM boot log [3].
The final bridge supports both the Exynos and i.MX8MM DSI devices.
Changes for
From: Marek Szyprowski
Restore the proper bridge chain by finding the previous bridge
in the chain instead of passing NULL.
This establishes a proper bridge chain while attaching downstream
bridges.
v5:
* exclude the NULL replacement in exynos_dsi_host_attach
v4:
* none
v3:
* new patch
Signe
The child devices in MIPI DSI can be binding with OF-graph
and also via child nodes.
The OF-graph interface represents the child devices via
remote and associated endpoint numbers like
dsi {
compatible = "fsl,imx8mm-mipi-dsim";
ports {
port@0 {
reg = <0>;
Samsung MIPI DSIM controller is common DSI IP that can be used in various
SoCs like Exynos, i.MX8M Mini/Nano.
In order to access this DSI controller between various platform SoCs,
the ideal way to incorporate this in the drm stack is via the drm bridge
driver.
This patch is trying to differentiat
Look like an explicit fixing up of mode_flags is required for DSIM IP
present in i.MX8M Mini/Nano SoCs.
At least the LCDIF + DSIM needs active low sync polarities in order
to correlate the correct sync flags of the surrounding components in
the chain to make sure the whole pipeline can work proper
DSI host initialization handling in previous exynos dsi driver has
some pitfalls. It initializes the host during host transfer() hook
that is indeed not the desired call flow for I2C and any other DSI
configured downstream bridges.
Host transfer() is usually triggered for downstream DSI panels or
Finding the right input bus format throughout the pipeline is hard
so add atomic_get_input_bus_fmts callback and initialize with the
default RGB888_1X24 bus format on DSI-end.
This format can be used in pipeline for negotiating bus format between
the DSI-end of this bridge and the other component
Look like PLL PMS_P offset value varies between platforms that have
Samsung DSIM IP.
However, there is no clear evidence for it as both Exynos and i.MX
8M Mini Application Processor Reference Manual is still referring
the PMS_P offset as 13.
The offset 13 is not working for i.MX8M Mini SoCs but t
1 - 100 of 129 matches
Mail list logo
