> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
>
>
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 8/8] drm/i915: Convert PALETTE() to
> _PICK_
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 7/8] drm/i915: Convert MBUS_ABOX_CTL() to
>
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 6/8] drm/i915: Convert _FIA() to
> _PICK_EVE
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH v2 5/8] drm/i915: Convert PIPE3/PORT3 to
> _PIC
Verified that the new macro evaluates to the right register offsets.
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@
Boqun wrote:
> On Sat, Jan 21, 2023 at 12:28:14PM +0900, Byungchul Park wrote:
> > On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> > > On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > > > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
> >
> > [...]
> >
Hi Javier,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.2-rc4 next-20230120]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
On Sat, Jan 21, 2023 at 12:28:14PM +0900, Byungchul Park wrote:
> On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> > On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
>
> [...]
>
> > > > T0 T
On Thu, Jan 19, 2023 at 07:07:59PM -0800, Boqun Feng wrote:
> On Thu, Jan 19, 2023 at 06:23:49PM -0800, Boqun Feng wrote:
> > On Fri, Jan 20, 2023 at 10:51:45AM +0900, Byungchul Park wrote:
[...]
> > > T0T1 T2
> > > ---- --
> > > unfair_re
Byungchul wrote:
> Torvalds wrote:
> > On Sun, Jan 8, 2023 at 7:33 PM Byungchul Park
> > wrote:
> > >
> > > 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
On Fri, 2023-01-20 at 23:46 +, Teres Alexis, Alan Previn wrote:
> Thanks for the review comment...
>
Replying here with the summary of our offline chat:
So we concluded that for the next rev, lets move the
buffer/vma allocations from patch #2 into this patch
#5-send-message. But for now we
Thanks for the review comment...
On Wed, 2023-01-18 at 17:40 -0800, Ceraolo Spurio, Daniele wrote:
>
>
> On 1/11/2023 1:42 PM, Alan Previn wrote:
> > Add GSC engine based method for sending PXP firmware packets
> > to the GSC firmware for MTL (and future) products. Use the newly
> > added helpe
Hi Dave, Daniel,
More updates for 6.3.
The following changes since commit 0c2dece8fb541ab07b68c3312a1065fa9c927a81:
drm/amdkfd: Page aligned memory reserve size (2023-01-11 16:41:03 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-
On 1/20/2023 15:28, john.c.harri...@intel.com wrote:
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung reques
Hi Tomi,
On Fri, Jan 20, 2023 at 10:50:02AM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen
>
> Hi,
>
> v2 of the series. Diff to v1 can be found below.
>
> The main changes are:
> - Runtime PM support for LVDS
> - Skip rcar_du_group_setup() for gen4+
>
> Tomi
>
> Koji Matsuoka (1):
>
From: John Harrison
The GuC specific register state entry in the error capture object was
just called 'capture'. Although the companion 'node' entry was called
'guc_capture_node'. Rename the base entry to be 'guc_capture' instead
so that it is a) more consistent and b) more obvious what it is.
S
From: John Harrison
Engine resets are supposed to never fail. But in the case when one
does (due to unknown reasons that normally come down to a missing
w/a), it is useful to get as much information out of the system as
possible. Given that the GuC intentionally dies on such a situation,
it is no
From: John Harrison
For understanding bug reports, it can be useful to have an explicit
dmesg print when a reset notification is received from GuC. As opposed
to simply inferring that this happened from other messages.
Signed-off-by: John Harrison
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/d
From: John Harrison
A hang situation has been observed where the only requests on the
context were either completed or not yet started according to the
breaadcrumbs. However, the register state claimed a batch was (maybe)
in progress. So, allow capture of the pending request on the grounds
that t
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC. The problem was not reproducible.
However, it is possible to happen if the context in question has no
active r
From: John Harrison
The debugfs dump of requests was confused about what state requires
the execlist lock versus the GuC lock. There was also a bunch of
duplicated messy code between it and the error capture code.
So refactor the hung request search into a re-usable function. And
reduce the span
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking around the search
internally. So it needs to grab the reference count internally as
well. The execlist only request based
From: John Harrison
It is technically possible to get a hung context without a valid
request. In such a situation, try to provide as much information in
the error capture as possible rather than just aborting and capturing
nothing.
Similarly, in the case of an engine reset failure the GuC is not
For the whole series:
Reviewed-by: Lyude Paul
So glad to have this fixed finally ♥
On Thu, 2023-01-19 at 18:51 -0500, Harry Wentland wrote:
> MST has been broken on amdgpu after a refactor in drm_dp_mst
> code that was aligning drm_dp_mst more closely with the atomic
> model.
>
> The gitlab is
On 1/19/2023 07:16, Andy Shevchenko wrote:
On Wed, Jan 18, 2023 at 10:49:55PM -0800, john.c.harri...@intel.com wrote:
From: John Harrison
When GuC support was added to error capture, the locking around the
request object was broken. Fix it up.
The context based search manages the spinlocking
On Fri, Jan 20, 2023 at 1:25 PM Carlos Llamas wrote:
>
> On Mon, Jan 09, 2023 at 09:38:06PM +, T.J. Mercier wrote:
> > From: Hridya Valsaraju
> >
> > This patch introduces flags BINDER_FD_FLAG_XFER_CHARGE, and
> > BINDER_FD_FLAG_XFER_CHARGE that a process sending an individual fd or
>
> I bel
Hi,
On Fri, Jan 20, 2023 at 3:43 AM John Keeping wrote:
>
> Commit 15b9ca1641f0 ("drm: Config orientation property if panel provides
> it") added a helper to set the panel panel orientation early but only
> connected this for drm_bridge_connector, which constructs a panel bridge
> with DRM_BRIDGE
On Mon, Jan 09, 2023 at 09:38:06PM +, T.J. Mercier wrote:
> From: Hridya Valsaraju
>
> This patch introduces flags BINDER_FD_FLAG_XFER_CHARGE, and
> BINDER_FD_FLAG_XFER_CHARGE that a process sending an individual fd or
I believe the second one was meant to be BINDER_FDA_FLAG_XFER_CHARGE.
How
On Mon, Jan 16, 2023 at 5:07 AM Sakari Ailus
wrote:
>
> Hi Prashant,
>
> On Thu, Jan 12, 2023 at 02:31:45PM -0800, Prashant Malani wrote:
> > HI Sakari,
> >
> > On Thu, Jan 12, 2023 at 5:32 AM Sakari Ailus
> > wrote:
> > >
> > > Hi Pin-yen,
> > >
> > > On Thu, Jan 12, 2023 at 12:20:56PM +0800, Pi
As downstream indicates, DSI PLL is actually 0x27c and not 0x260-
wide. Fix that to reserve the correct registers.
Fixes: d4a4410583ed ("arm64: dts: qcom: sm8350: Add display system nodes")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++--
1 file changed, 2 insertio
Add the mdss_ prefix to DSIn labels, so that the hardware blocks can
be organized near each other while retaining the alphabetical order
in device DTs when referencing by label.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 2 +-
arch/arm64/boot/dts/qcom/sm8350.dtsi
Somehow DSI1 was not hooked up to MDP resulting in it not working.
Fix it.
Fixes: d4a4410583ed ("arm64: dts: qcom: sm8350: Add display system nodes")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/
The compatibles were wrong, resulting in the driver not probing. Fix
that.
Fixes: d4a4410583ed ("arm64: dts: qcom: sm8350: Add display system nodes")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch
This was omitted but is necessary for DSI1 to function. Fix it.
Fixes: d4a4410583ed ("arm64: dts: qcom: sm8350: Add display system nodes")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts
The interrupt was wrong, likely copypasted from DSI0. Fix it.
Fixes: d4a4410583ed ("arm64: dts: qcom: sm8350: Add display system nodes")
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/q
Panels/DRM bridges definitely don't need 64bits of address space and
are usually not 32-bit wide. Set address-cells to 1 and size-cells to
0.
Signed-off-by: Konrad Dybcio
---
arch/arm64/boot/dts/qcom/sm8350.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/s
v2.5.0 support was originally added for SC7280, but this hw is also
present on SM8350, which has one more DSI host. Bump up the dsi count
and fill in the register of the secondary host to allow it to probe.
This should not have any adverse effects on SC7280, as the secondary
CTRL will only be touc
On 1/20/23 10:39, Limonciello, Mario wrote:
[ ... ]
Wayne is OOO for CNY, but let me update you.
Harry has sent out this series which is a collection of proper fixes.
https://patchwork.freedesktop.org/series/113125/
Once that's reviewed and accepted, 4 of them are applicable for 6.1.
Thanks
On Wed, 2023-01-18 at 17:28 -0800, Ceraolo Spurio, Daniele wrote:
> >
> >
> > On 1/11/2023 1:42 PM, Alan Previn wrote:
> > > > Add helper functions into (new) common heci-packet-submission files
> > > > to handle generating the MTL GSC-CS Memory-Header and emitting of
> > > > the Heci-Cmd-Packet
Thanks for reviewing.
On Wed, 2023-01-18 at 16:09 -0800, Ceraolo Spurio, Daniele wrote:
> >
> >
Alan: [snip]
> > > > -/* KCR register definitions */
> > > > -#define KCR_INIT _MMIO(0x320f0)
> > > > -/* Setting KCR Init bit is required after system boot */
> > > > -#define KCR_INIT_ALLOW_DISPLAY_
Thanks for reviewing, Daniele. Responses are inline below.
On Wed, 2023-01-18 at 15:55 -0800, Ceraolo Spurio, Daniele wrote:
> >
> >
> > On 1/11/2023 1:42 PM, Alan Previn wrote:
> > > > For MTL, PXP transport back-end uses the GSC engine to submit
> > > > HECI packets for PXP arb session managem
On Fri, Jan 20, 2023 at 07:28:19PM +, Robin Murphy wrote:
> On 2023-01-18 18:00, Jason Gunthorpe wrote:
> > Change the sg_alloc_table_from_pages() allocation that was hardwired to
> > GFP_KERNEL to use the gfp parameter like the other allocations in this
> > function.
> >
> > Auditing says thi
On 20 January 2023 18:32:47 GMT+03:00, Sean Paul wrote:
>On Thu, Jan 19, 2023 at 11:37:52AM +0100, Krzysztof Kozlowski wrote:
>> On 18/01/2023 20:30, Mark Yacoub wrote:
>> > From: Sean Paul
>> >
>> > This patch moves the hdcp atomic check from i915 to drm_hdcp so other
>> > drivers can use it
Changes look good.
Reviewed-by: Anusha Srivatsa
> -Original Message-
> From: Intel-gfx On Behalf Of Lucas
> De Marchi
> Sent: Friday, January 20, 2023 11:35 AM
> To: intel-...@lists.freedesktop.org
> Cc: De Marchi, Lucas ; dri-
> de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATC
Hi Michal,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Michal-Wajdeczko/drm-i915-guc-Add-GuC-oriented-print-macros/20230121-004232
base: git://anongit.freedesktop.org/drm/drm-tip drm
Hi Jagan
On Fri, 20 Jan 2023 at 19:10, Jagan Teki wrote:
>
> Hi Dave,
>
> On Sat, Jan 21, 2023 at 12:26 AM Dave Stevenson
> wrote:
> >
> > Hi Jagan
> >
> > Responding due to Marek's comment on the "Add Samsung MIPI DSIM
> > bridge" series, although I know very little about the Exynos
> > specifi
MBUS_ABOX_CTL() can use _PICK_EVEN_2RANGES instead of _PICK, which
reduces the size and is safer.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/
PALETTE() can use _PICK_EVEN_2RANGES instead of _PICK, which
reduces the size and is safer.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_
_FIA() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the
size and is safer.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_mg_phy_regs.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_mg_phy_regs.h
b/
As done previously for pll, also convert users of _PHY3() to
_PICK_EVEN_2RANGES(). Size comparison of i915.o:
$ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
textdata bss dec hex filename
4026997 1857036984 4219684 406324
build64/drivers/gpu/
Like done for when __var_args__ were used, but size-wise it's also
benefitial to avoid _PICK() used for 3 ports/pipes:
$ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
textdata bss dec hex filename
4026288 1857036984 4218975 40605f
build64/dri
Avoid the array lookup, converting the PLL macros after ICL to
_PICK_EVEN_RANGES. This provides the following reduction in code size:
$ size build64/drivers/gpu/drm/i915/i915.o{.old,.new}
textdata bss dec hex filename
4027456 1857036984 4220143 4064
It's a constant pattern in the driver to need to use 2 ranges of MMIOs
based on port, phy, pll, etc. When that happens, instead of using
_PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged
due to some reasons like:
1) It increases the code size since the array is declared
in e
Abide by the rules in the top of the header: 2 spaces for bitfield,
prefix offsets with underscore and prefer the use of REG_BIT().
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/driver
Add a new macro, _PICK_EVEN_2RANGES, that supports using 2 address
ranges. This can be considered a v2 of
https://patchwork.freedesktop.org/series/109606/
I think I converted all the _PICK() uses that could be easily done
without making it much harder to read. We do have some cases of 3
ranges: I
On 2023-01-18 18:00, Jason Gunthorpe wrote:
Change the sg_alloc_table_from_pages() allocation that was hardwired to
GFP_KERNEL to use the gfp parameter like the other allocations in this
function.
Auditing says this is never called from an atomic context, so it is safe
as is, but reads wrong.
Hi Hans,
On Thu, Jan 19, 2023 at 10:02:19AM +0100, Hans Verkuil wrote:
> The bcm2711 has two HDMI outputs, each with their own CEC adapter.
> The CEC adapter name has to be unique, but it is currently
> hardcoded to "vc4" for both outputs. Change this to use the card_name
> from the variant inform
On Wed, Jan 04, 2023 at 04:08:47PM +0100, Marek Vasut wrote:
> On 1/3/23 11:59, Alexander Stein wrote:
> > Hi,
> >
> > Am Sonntag, 18. Dezember 2022, 23:28:20 CET schrieb Marek Vasut:
> > > On 12/18/22 23:24, Adam Ford wrote:
> > > > On Sat, Dec 17, 2022 at 10:33 PM Marek Vasut wrote:
> > > > > O
> Among the people present in this discussion, the consensus was that we
> should delete them.
I wasn't present but +1 from me.
Hi Dave,
On Sat, Jan 21, 2023 at 12:26 AM Dave Stevenson
wrote:
>
> Hi Jagan
>
> Responding due to Marek's comment on the "Add Samsung MIPI DSIM
> bridge" series, although I know very little about the Exynos
> specifics, and may well be missing context of what you're trying to
> achieve.
>
> On M
On 1/20/23 19:54, Jagan Teki wrote:
On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut wrote:
On 1/20/23 15:41, Jagan Teki wrote:
Hi Fabio,
Hello all,
On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam wrote:
Hi Jagan,
On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki wrote:
There are two patch serie
Hi Marek & Jagan
On Fri, 20 Jan 2023 at 15:06, Marek Vasut wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki
> >> wrote:
> >>
> >>> Ther
Hi Jagan
Responding due to Marek's comment on the "Add Samsung MIPI DSIM
bridge" series, although I know very little about the Exynos
specifics, and may well be missing context of what you're trying to
achieve.
On Mon, 12 Dec 2022 at 18:29, Jagan Teki wrote:
>
> Restore the proper bridge chain b
On Fri, Jan 20, 2023 at 8:36 PM Marek Vasut wrote:
>
> On 1/20/23 15:41, Jagan Teki wrote:
> > Hi Fabio,
>
> Hello all,
>
> > On Fri, Jan 20, 2023 at 5:36 PM Fabio Estevam wrote:
> >>
> >> Hi Jagan,
> >>
> >> On Thu, Jan 19, 2023 at 2:59 PM Jagan Teki
> >> wrote:
> >>
> >>> There are two patch
On Thu, Jan 19, 2023 at 06:19:01PM +0200, Jani Nikula wrote:
> It's a bit confusing to have two cached EDIDs in struct intel_connector
> with slightly different purposes. Make the distinction a bit clearer by
> moving the EDID cached for eDP and LVDS panels at connector init time to
> struct intel_
On Thu, Jan 19, 2023 at 06:19:00PM +0200, Jani Nikula wrote:
> Simplify validation and use by converting to drm_edid.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 10 ++-
> drivers/gpu/drm/i915/displ
On Thu, Jan 19, 2023 at 06:18:59PM +0200, Jani Nikula wrote:
> Try to use struct drm_edid where possible, even if having to fall back
> to looking into struct edid down low via drm_edid_raw().
>
> v2: Rebase
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
On Thu, Jan 19, 2023 at 06:18:58PM +0200, Jani Nikula wrote:
> Convert all the connectors that use cached connector edid and
> detect_edid to drm_edid.
>
> Since drm_get_edid() calls drm_connector_update_edid_property() while
> drm_edid_read*() do not, we need to call drm_edid_connector_update()
>
The pull request you sent on Fri, 20 Jan 2023 12:52:59 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-01-20
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ff83fec8179e392be2f472f0a9ec3da8f6d529c6
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
[Public]
> -Original Message-
> From: Guenter Roeck On Behalf Of Guenter Roeck
> Sent: Friday, January 20, 2023 12:18
> To: Limonciello, Mario
> Cc: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org; sta...@vger.kernel.org;
> stanislav.lisovs...@intel.com; Z
Hello everyone,
For many years now, we have maintained mirrors of numerous FDo projects
on GitHub, under the following organisations:
https://github.com/freedesktop
https://github.com/mesa3d
https://github.com/wayland-project
A bit over a month ago, a new security feature in git started preventin
On 1/19/23 05:14, Bagas Sanjaya wrote:
On Wed, Jan 18, 2023 at 07:12:45AM +0100, Danilo Krummrich wrote:
This adds the infrastructure for a manager implementation to keep track
of GPU virtual address (VA) mappings.
"Add infrastructure for ..."
+ * Analogue to drm_gpuva_sm_map_ops_create() dr
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
Changes
Hello Sascha,
On Fri, 2023-01-20 at 10:16 +0100, Sascha Hauer wrote:
> > + /* Enable LVDS mode */
> > + return regmap_update_bits(lvds->grf, RK3568_GRF_VO_CON2,
> > + RK3568_LVDS0_MODE_EN(1),
> > + RK3568_LVDS0_MODE_EN(1))
On Fri, Jan 20, 2023 at 03:22:09PM +, Daniel Thompson wrote:
> On Fri, Jan 20, 2023 at 05:47:27PM +0800, Jianhua Lu wrote:
> > Add Kinetic KTZ8866 backlight binding documentation.
> >
> > Signed-off-by: Jianhua Lu
> > [...]
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backl
The following registers do not exist on gen4, so we should not write
them: DEF6Rm, DEF7Rm, DEF8Rm, ESCRn, OTARn.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 8 +---
drivers/gpu/drm/rcar-du/rcar_du_group.c | 11 ---
2 fil
On 20/01/2023 18:21, Laurent Pinchart wrote:
On Fri, Jan 20, 2023 at 10:50:09AM +0200, Tomi Valkeinen wrote:
The following registers do not exist on gen4, so we should not write
them: DEF6Rm, DEF7Rm, DEF8Rm, ESCRn, OTARn.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drive
On Fri, Jan 20, 2023 at 11:18:56AM +0100, Krzysztof Kozlowski wrote:
> On 20/01/2023 10:47, Jianhua Lu wrote:
> > Add Kinetic KTZ8866 backlight binding documentation.
> >
> > Signed-off-by: Jianhua Lu
> > ---
> > Changes in v2:
> > - Remove "items" between "compatible" and "const: kinetic,ktz88
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
Changes
Add simple runtime PM suspend and resume functionality.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 43 +
1 file changed, 37 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
b/drivers/gpu/drm/rcar-du/rcar_lvd
On H3 ES1.x two bits in DPLLCR are used to select the DU input dot clock
source. These are bits 20 and 21 for DU2, and bits 22 and 23 for DU1. On
non-ES1.x, only the higher bits are used (bits 21 and 23), and the lower
bits are reserved and should be set to 0.
The current code always sets the lowe
Add support for Kinetic KTZ8866 backlight, which is used in
Xiaomi tablet, Mi Pad 5 series. This driver lightly based on
downstream implementation [1].
[1]
https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/elish-r-oss/drivers/video/backlight/ktz8866.c
Signed-off-by: Jianhua Lu
---
Changes
On Fri, Jan 20, 2023 at 03:22:09PM +, Daniel Thompson wrote:
> On Fri, Jan 20, 2023 at 05:47:27PM +0800, Jianhua Lu wrote:
> > Add Kinetic KTZ8866 backlight binding documentation.
> >
> > Signed-off-by: Jianhua Lu
> > [...]
> >
> > diff --git
> > a/Documentation/devicetree/bindings/leds/backl
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
---
Changes in v2:
- Remove "items" between "compatible" and "const: kinetic,ktz8866".
- Change "additionalProperties" to "unevaluatedProperties".
Changes in v3:
- Add Krzysztof's R-b.
Changes in v4:
- Drop K
Reset LVDS using the reset control as CPG reset/release is required in
the hardware manual sequence.
Based on a BSP patch from Koji Matsuoka .
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 ++-
2 files chan
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
Reviewed-by: Krzysztof Kozlowski
---
Changes in v2:
- Remove "items" between "compatible" and "const: kinetic,ktz8866".
- Change "additionalProperties" to "unevaluatedProperties".
Changes in v3:
- Add Krzysztof
Add Kinetic KTZ8866 backlight binding documentation.
Signed-off-by: Jianhua Lu
---
Changes in v2:
- Remove "items" between "compatible" and "const: kinetic,ktz8866".
- Change "additionalProperties" to "unevaluatedProperties".
Changes in v3:
- Add Krzysztof's R-b.
Changes in v4:
- Drop K
The RCAR DSI driver uses reset controller, so we should select it in the
Kconfig.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
From: Koji Matsuoka
According to hardware manual, LVDCR0 register must be cleared bit by bit
when disabling LVDS.
Signed-off-by: Koji Matsuoka
Signed-off-by: LUU HOAI
[tomi.valkeinen: simplified the code a bit]
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 26 ++
From: Tomi Valkeinen
Hi,
v2 of the series. Diff to v1 can be found below.
The main changes are:
- Runtime PM support for LVDS
- Skip rcar_du_group_setup() for gen4+
Tomi
Koji Matsuoka (1):
drm: rcar-du: lvds: Fix stop sequence
Tomi Valkeinen (6):
drm: rcar-du: dsi: add 'select RESET_CON
rcar_du_crtc.c does a soc_device_match() in
rcar_du_crtc_set_display_timing() to find out if the SoC is H3 ES1.x, and
if so, apply a workaround.
We will need another H3 ES1.x check in the following patch, so rather than
adding more soc_device_match() calls, let's add a rcar_du_device_info
entry fo
Hi Mario,
On Fri, Jan 20, 2023 at 11:51:04AM -0600, Limonciello, Mario wrote:
> On 1/20/2023 11:46, Guenter Roeck wrote:
> > On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
> > > This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
> > >
> > > [Why]
> > > Changes cause regress
On Fri, Jan 20, 2023, Bagas Sanjaya wrote:
> Stephen Rothwell reported htmldocs warning when merging kvm-x86 tree:
>
> Documentation/virt/kvm/api.rst:5070: ERROR: Unexpected indentation.
>
> Fix the warning by adding a blank line separator before
> KVM_CAP_PMU_EVENT_MASKED_EVENTS code path list t
On 1/20/2023 09:36, John Harrison wrote:
On 1/19/2023 17:54, Ceraolo Spurio, Daniele wrote:
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated b
On Fri, Jan 20, 2023 at 10:24:55AM +0100, Joerg Roedel wrote:
> On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> > I think it is just better to follow kernel convention and have
> > allocation functions include the GFP because it is a clear signal to
> > the user that there is an
On 1/20/2023 11:46, Guenter Roeck wrote:
On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
[Why]
Changes cause regression on amdgpu mst.
E.g.
In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
one
On Thu, Jan 12, 2023 at 04:50:44PM +0800, Wayne Lin wrote:
> This reverts commit 4d07b0bc403403438d9cf88450506240c5faf92f.
>
> [Why]
> Changes cause regression on amdgpu mst.
> E.g.
> In fill_dc_mst_payload_table_from_drm(), amdgpu expects to add/remove payload
> one by one and call fill_dc_mst_pa
On 1/19/2023 17:54, Ceraolo Spurio, Daniele wrote:
On 1/18/2023 10:49 PM, john.c.harri...@intel.com wrote:
From: John Harrison
There was a report of error captures occurring without any hung
context being indicated despite the capture being initiated by a 'hung
context notification' from GuC.
Acked-by: Alex Deucher
On Fri, Jan 20, 2023 at 12:31 PM Hamza Mahfooz wrote:
>
> Not all ASICs support LTTPR, however if they don't it doesn't mean that
> we have encountered unexpected behaviour. So, use DC_NOT_SUPPORTED
> instead of DC_ERROR_UNEXPECTED.
>
> Reviewed-by: Wenjing Liu
> Signed-o
1 - 100 of 215 matches
Mail list logo
