Hi Monk,
yeah, that's what I can certainly agree on.
My primary concern is that I'm not convinced that we don't get problems
at other places if we just add another band aid.
We already had this back and forth multiple times now and while we are
currently under time pressure we will be under
On Mon, 29 Mar 2021 15:36:27 +
Simon Ser wrote:
> On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
> wrote:
>
> > Making the second plane an overlay would break the ABI, which is never
> > something I'm happy to do; but I'd prefer to do it now than later.
>
> Yeah, I wonder if some
Hi Christian,
I don't think there is any constraint implemented to ensure `num_entries %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`:
/* validate the parameters */
if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK ||
size =
On 2021-03-29 20:04 +0200, Christian König wrote:
> Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
> > If the initial value of `num_entires` (calculated at line 1654) is not
> > an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
> > value greater than the initial value will be assigned
On 2021-03-29 20:10 +0200, Christian König wrote:
> You need to identify the root cause of this, most likely start or last
> are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
I printk'ed the value of start & last, they are all a multiple of 4
(AMDGPU_GPU_PAGES_IN_CPU_PAGE).
However... `num_ent
On 2021-03-29 21:36 +0200, Christian König wrote:
> Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
> > Hi Christian,
> >
> > I don't think there is any constraint implemented to ensure `num_entries %
> > AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`:
> >
> > /* valid
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the initial value will be assigned to it. That causes
`start > last + 1` after line 1708. Then in the next iteration an
underflow happen
On 2021-03-30 02:21 +0800, Xi Ruoyao wrote:
> On 2021-03-29 20:10 +0200, Christian König wrote:
> > You need to identify the root cause of this, most likely start or last
> > are not a multiple of AMDGPU_GPU_PAGES_IN_CPU_PAGE.
>
> I printk'ed the value of start & last, they are all a multiple of
On 2021.03.23 16:39:36 -0300, Jason Gunthorpe wrote:
> On Tue, Mar 23, 2021 at 08:26:30PM +0100, Christoph Hellwig wrote:
> > On Tue, Mar 23, 2021 at 02:55:32PM -0300, Jason Gunthorpe wrote:
> > > Ideally all of this would be moved to kvmgt.c, but it is entangled with
> > > the rest of the "generic
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fault), but it doesn't have s
On 2021-03-29 20:13, abhin...@codeaurora.org wrote:
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Drop the struct msm_dsi_pll abstraction, by including vco's clk_hw
directly into struct msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
Forgot to mention, please fix the typo "abstraction" in the subj
On 2021-03-27 04:03, Dmitry Baryshkov wrote:
The src_truthtable config is not used for some of phys, which use other
means of configuring the master/slave usecases. Inline this function
with the goal of removing src_pll_id argument in the next commit.
Signed-off-by: Dmitry Baryshkov
---
driver
On 2021-03-27 04:03, Dmitry Baryshkov wrote:
The 7nm, 10nm and 14nm drivers would store interim data used during
VCO/PLL rate setting in the global dsi_pll_Nnm structure. Move this
data
structures to the onstack storage. While we are at it, drop
unused/static 'config' data, unused config fields
On Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> This enables the adreno-specific SMMU path that sets HUPCF so
> (user-managed) page faults don't wedge the GPU.
>
> Signed-off-by: Eric Anholt
Acked-by: Bjorn Andersson
@Will, can you pick this together with the driver patch? (So that they
la
On 2021-03-27 04:03, Dmitry Baryshkov wrote:
Drop duplicate fields pdev and id from dsi_pll_Nnm instances. Reuse
those fields from the provided msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c| 72 +--
On Fri 26 Mar 18:13 CDT 2021, Eric Anholt wrote:
> db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> the GPU from wedging and then sometimes wedging the kernel after a
> page fault), but it doesn't have separate pagetables support yet in
> drm/msm so we can't go all the way to
Hi Doug,
On Mon, Mar 29, 2021 at 07:57:05PM -0700, Doug Anderson wrote:
> On Tue, Mar 16, 2021 at 5:44 PM Doug Anderson wrote:
> > On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart wrote:
> > > On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > > > On Sat, Mar 13, 2021 at 1:17 PM La
On Mon 29 Mar 07:00 CDT 2021, Dmitry Baryshkov wrote:
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Also inverse the non-mdp4 condition in add_display_components() to avoid
> having to check every new compatible in the c
On 2021-03-27 04:03, Dmitry Baryshkov wrote:
All PHY drivers would map dsi_pll area. Some PHY drivers would also
map dsi_phy area again (a leftover from old PHY/PLL separation). Move
all ioremaps to the common dsi_phy driver code and drop individual
ioremapped areas from PHY drivers.
Signed-off-
On 2021-03-27 04:03, Dmitry Baryshkov wrote:
Replace PLL accessor functions (pll_read/pll_write*) with the DSI PHY
accessors, reducing duplication.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 24 +--
drivers/gpu/drm/msm/dsi
On Mon 29 Mar 07:00 CDT 2021, Dmitry Baryshkov wrote:
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Also inverse the non-mdp4 condition in add_display_components() to avoid
> having to check every new compatible in the c
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Drop the struct msm_dsi_pll abstraction, by including vco's clk_hw
directly into struct msm_dsi_phy.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Kconfig | 8 --
drivers/gpu/drm/msm/Makefil
[AMD Official Use Only - Internal Distribution Only]
Hi Christian,
We don't need to debate on the design's topic, each of us have our own opinion,
it is hard to persuade others sometimes, again with more and more features and
requirements it is pretty normal that an old design need to
Refine an
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Make save_state/restore callbacks accept struct msm_dsi_phy rather than
struct msm_dsi_pll. This moves them to struct msm_dsi_phy_ops, allowing
us to drop struct msm_dsi_pll_ops.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/phy/dsi_ph
Hi,
On Tue, Mar 16, 2021 at 5:44 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Mar 16, 2021 at 2:46 PM Laurent Pinchart
> wrote:
> >
> > Hi Doug,
> >
> > On Mon, Mar 15, 2021 at 09:25:37AM -0700, Doug Anderson wrote:
> > > On Sat, Mar 13, 2021 at 1:17 PM Laurent Pinchart wrote:
> > > > On Thu, Mar
Though I don't have access to any hardware that uses ti-sn65dsi86 and
_doesn't_ provide a "refclk", I believe that we'll have trouble
reading the EDID at bootup in that case. Specifically I believe that
if there's no "refclk" we need the MIPI source clock to be active
before we can successfully rea
Now that we have the patch ("drm/edid: Use the cached EDID in
drm_get_edid() if eDP") we no longer need to maintain our own
cache. Drop this code.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +-
1 file changed, 9 inse
Unpreparing and re-preparing a panel can be a really heavy
operation. Panels datasheets often specify something on the order of
500ms as the delay you should insert after turning off the panel
before turning it on again. In addition, turning on a panel can have
delays on the order of 100ms - 200ms
Now that we can properly read the EDID for modes there should be no
reason to fallback to the fixed modes that our downstream panel driver
provides us. Let's make that clear by:
- Putting an error message in the logs if we fall back.
- Putting a comment in saying what's going on.
Signed-off-by: Do
eDP panels won't provide their EDID unless they're powered on. Let's
chain a power-on before we read the EDID. This roughly matches what
was done in 'parade-ps8640.c'.
NOTE: The old code attempted to call pm_runtime_get_sync() before
reading the EDID. While that was enough to power the bridge chip
Each time we call drm_get_edid() we:
1. Go out to the bus and ask for the EDID.
2. Cache the EDID.
We can improve this to actually use the cached EDID so that if
drm_get_edid() is called multiple times then we don't need to go out
to the bus over and over again.
In normal DP/HDMI cases reading th
As of commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") the drm_get_edid() function calls
drm_connector_update_edid_property() for us. There's no reason for us
to call it again.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c
We prepared the panel in pre_enable() so we should unprepare it in
post_disable() to match.
This becomes important once we start using pre_enable() and
post_disable() to make sure things are powered on (and then off again)
when reading the EDID.
Signed-off-by: Douglas Anderson
---
(no changes s
If we just leave the detect() function as NULL then the upper layers
assume we're always connected. There's no reason for a stub.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 12
1 file changed, 12 deletions(-)
diff --git a/dri
A random comment inside a function had "/**" in front of it. That
doesn't make sense. Remove.
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.
Let's make the remove() function strictly the reverse of the probe()
function so it's easier to reason about.
NOTES:
- The MIPI calls probably belong in detach() but will be moved in a
separate patch.
- The cached EDID freeing isn't actually part of probe but needs to be
in remove to avoid orp
The register() / attach() for MIPI happen in the bridge's
attach(). That means that the inverse belongs in the bridge's
detach().
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-
The clock framework makes it simple to deal with an optional clock.
You can call clk_get_optional() and if the clock isn't specified it'll
just return NULL without complaint. It's valid to pass NULL to
enable/disable/prepare/unprepare. Let's make use of this to simplify
things a tiny bit.
Signed-o
The drm_bridge_chain_pre_enable() is not the proper opposite of
drm_bridge_chain_post_disable(). It continues along the chain to
_before_ the starting bridge. Let's fix that.
Fixes: 05193dc38197 ("drm/bridge: Make the bridge chain a double-linked list")
Signed-off-by: Douglas Anderson
---
(no ch
The primary goal of this series is to try to properly fix EDID reading
for eDP panels using the ti-sn65dsi86 bridge.
Previously we had a patch that added EDID reading but it turned out
not to work at bootup. This caused some extra churn at bootup as we
tried (and failed) to read the EDID several t
Fix the following coccicheck warning:
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:217:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/panel//panel-tpo-td043mtea1.c:189:8-16: WARNING:
use scnprintf or sprintf
Signed-off-by: Tian Tao
---
drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 +
Trimming Cc list way down, sorry if that's too much.
Quoting Maxime Ripard (2021-02-19 04:00:30)
> Many drivers reference the plane->state pointer in order to get the
> current plane state in their atomic_update or atomic_disable hooks,
> which would be the new plane state in the global atomic sta
30.03.2021 00:36, Mikko Perttunen пишет:
> On 3/29/21 11:27 PM, Dmitry Osipenko wrote:
>> 29.03.2021 16:38, Mikko Perttunen пишет:
>>> Before this patch, cancelled waiters would only be cleaned up
>>> once their threshold value was reached. Make host1x_intr_put_ref
>>> process the cancellation imme
>On Sat, Mar 27, 2021 at 3:28 AM Wan Jiabing wrote:
>>
>> struct dc_state has been declared at 273rd line.
>> Remove the duplicate.
>> Delete duplicate blank lines.
>
>Can you split these into separate patches?
>
>Alex
OK. But in fact, what I did is simple.
The most important thing is removing
Quoting Dmitry Baryshkov (2021-03-27 04:02:40)
> Restructure MSM DSI PHY drivers. What started as an attempt to grok the
> overcomplicated PHY drivers, has lead up to the idea of merging PHY and
> PLL code, reducing abstractions, code duplication, dropping dead code,
> etc.
>
> The patches were ma
Fix the following coccicheck warning:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:65:8-16: WARNING:
use scnprintf
Would make it devm_of_clk_add_hw_provider() in the subject
Quoting Dmitry Baryshkov (2021-03-27 04:02:53)
> Use devm_of_clk_add_hw_provider() to register provided clocks. This
> allows dropping the remove function alltogether.
>
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
10nm and 7nm already do not use these helpers, as they handle setting
slave DSI clocks after enabling VCO. Modify the rest of PHY drivers to
remove unnecessary indirection and drop enable_seq/disable_seq PLL
callbacks.
Signed-off-by: Dmitry Baryshkov
Subject should say register instead of registe
Quoting Dmitry Baryshkov (2021-03-27 04:02:52)
> Use devres-enabled version of clock registration functions. This lets us
> remove dsi_pll destroy callbacks completely.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/dsi/dsi.h
Quoting Dmitry Baryshkov (2021-03-27 04:02:43)
> Add devm_clk_hw_register_divider() - devres version of
> clk_hw_register_divider().
>
> Signed-off-by: Dmitry Baryshkov
> Reviewed-by: Abhinav Kumar
> ---
Acked-by: Stephen Boyd
___
dri-devel mailing l
Quoting Dmitry Baryshkov (2021-03-27 04:02:42)
> Add devm_clk_hw_register_mux() - devres-managed version of
> clk_hw_register_mux().
>
> Signed-off-by: Dmitry Baryshkov
> Reviewed-by: Abhinav Kumar
> ---
Acked-by: Stephen Boyd
___
dri-devel mailing l
Hi Dafna,
Thank you for the patch.
On Mon, Mar 29, 2021 at 05:36:32PM +0200, Dafna Hirschfeld wrote:
> The mtk_hdmi does not support creating a bridge with a connector.
> Therefore the field 'conn' should be removed from the mtk_hdmi struct.
> It is replaced with a pointer curr_conn that points t
Hi Dafna,
Thank you for the patch.
On Mon, Mar 29, 2021 at 05:36:31PM +0200, Dafna Hirschfeld wrote:
> commit f01195148967 ("drm/mediatek: mtk_dpi: Create connector for bridges")
> broke the display support for elm device since mtk_dpi calls
> drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Instead of setting the variable and then using it just in the one
place,
determine vco_delay directly at the PLL configuration time.
Signed-off-by: Dmitry Baryshkov
The subject line should still be "drm/msm/dsi" and not "drm/msm/dpu".
Once thats fi
Hi Dafna,
Thank you for the patch.
On Mon, Mar 29, 2021 at 05:36:30PM +0200, Dafna Hirschfeld wrote:
> The bridge operation '.enable' and the audio cb '.get_eld'
> access hdmi->conn. In the future we will want to support
> the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will
> not have direct
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
These drivers do not use vco_delay variable, so drop it from all of
them.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 3 ---
drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 4
driv
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Morph msm_dsi_pll_save/restore_state() into
msm_dsi_phy_save/restore_state(),
thus removing last bits of knowledge about msm_dsi_pll from
dsi_manager.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi.h | 18 ++-
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Use devm_of_clk_add_hw_provider() to register provided clocks. This
allows dropping the remove function alltogether.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 22 +-
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
Use devres-enabled version of clock registration functions. This lets
us
remove dsi_pll destroy callbacks completely.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.h | 4 -
drivers/gp
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and friends.
From: Kalyan Thota
[ Upstream commit 627dc55c273dab308303a5217bd3e767d7083ddb ]
DPU runtime resume will request for a min vote on the AXI bus as
it is a necessary step before turning ON the AXI clock.
The change does below
1) Move the icc path set before requesting runtime get_sync.
2) remove t
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and friends.
From: Dmitry Baryshkov
[ Upstream commit 9daaf31307856defb1070685418ce5a484ecda3a ]
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b9f
From: Kalyan Thota
[ Upstream commit 627dc55c273dab308303a5217bd3e767d7083ddb ]
DPU runtime resume will request for a min vote on the AXI bus as
it is a necessary step before turning ON the AXI clock.
The change does below
1) Move the icc path set before requesting runtime get_sync.
2) remove t
From: Konrad Dybcio
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ]
While passing the A530-specific lm_setup func to A530 and A540
to !A530 was fine back when only these two were supported, it
certainly is not a good idea to send A540 specifics to smaller
GPUs like A508 and friends.
From: Rob Clark
[ Upstream commit 7ad48d27a2846bfda29214fb454d001c3e02b9e7 ]
We have seen a couple cases where low memory situations cause something
bad to happen, followed by a flood of these messages obscuring the root
cause. Lets ratelimit the dmesg spam so that next time it happens we
don't
From: Dmitry Baryshkov
[ Upstream commit 9daaf31307856defb1070685418ce5a484ecda3a ]
The PLL_LOCKDET_RATE_1 was being programmed with a hardcoded value
directly, but the same value was also being specified in the
dsi_pll_regs struct pll_lockdet_rate variable: let's use it!
Based on 362cadf34b9f
From: Jordan Crouse
[ Upstream commit 8490f02a3ca45fd1bbcadc243b4db9b69d0e3450 ]
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version of
the microcode for the target and print a message and error if not.
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
All MSM DSI PHYs provide two clocks: byte and pixel ones.
Register/unregister provided clocks from the generic place, removing
boilerplate code from all MSM DSI PHY drivers.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
drivers/g
On 2021-03-27 04:02, Dmitry Baryshkov wrote:
From: Daniel Palmer
Add a devm helper for clk_hw_register_fixed_factor() so that drivers
that internally
register fixed factor clocks for things like dividers don't need to
manually unregister
them on remove or if probe fails.
Signed-off-by: Daniel
On 3/29/21 11:27 PM, Dmitry Osipenko wrote:
29.03.2021 16:38, Mikko Perttunen пишет:
Before this patch, cancelled waiters would only be cleaned up
once their threshold value was reached. Make host1x_intr_put_ref
process the cancellation immediately to fix this.
Signed-off-by: Mikko Perttunen
-
29.03.2021 16:38, Mikko Perttunen пишет:
> Before this patch, cancelled waiters would only be cleaned up
> once their threshold value was reached. Make host1x_intr_put_ref
> process the cancellation immediately to fix this.
>
> Signed-off-by: Mikko Perttunen
> ---
> v6:
> * Call schedule instead
On Mon, Mar 29, 2021 at 04:37:22PM +0300, Jani Nikula wrote:
> Avoid any confusion with High Dynamic Range. No functional changes.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_displayid.c | 10 +-
> include/drm/drm_displayid.h | 2 +-
> 2
On Mon, Mar 29, 2021 at 04:37:21PM +0300, Jani Nikula wrote:
> The DisplayID specifications explicitly call out 0 as a valid payload
> length for data blocks. The mere presence of a data block, or the
> information coded in the block specific data (bits 7:3 in offset 1), may
> be enough to convey t
Am 29.03.21 um 21:27 schrieb Xi Ruoyao:
Hi Christian,
I don't think there is any constraint implemented to ensure `num_entries %
AMDGPU_GPU_PAGES_IN_CPU_PAGE == 0`. For example, in `amdgpu_vm_bo_map()`:
/* validate the parameters */
if (saddr & AMDGPU_GPU_PAGE_MASK || offset
Quoting Dmitry Baryshkov (2021-03-29 05:00:51)
> From: Jonathan Marek
>
> - Use sm8250 compatibles instead of sdm845 compatibles
>
Does it need the " - " prefix?
> Signed-off-by: Jonathan Marek
> Signed-off-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
_
Quoting Dmitry Baryshkov (2021-03-29 05:00:49)
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Signed-off-by: Jonathan Marek
> Acked-by: Rob Herring
> [DB: split dt-bindings into separate patch]
> Signed-off-by: Dmitry Ba
Quoting Dmitry Baryshkov (2021-03-29 05:00:50)
> From: Jonathan Marek
>
> The driver already has support for sm8150/sm8250, but the compatibles were
> never added.
>
> Also inverse the non-mdp4 condition in add_display_components() to avoid
> having to check every new compatible in the condition
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
v5 -> v6:
* More yaml file documentation fixes
v6 -> v7:
* Fix ordering of p
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
This is v3 of the series.
Changelog:
v2 -> v3:
* Turn Documentation into yaml format
v3 -> v4:
* Fix reference error in yaml file
v4 -> v5:
* More yaml file documentation fixes
v5 -> v6:
* More yaml file documentation fixes
Daniel Mack (2):
dt-bindings: displ
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
This patch adds support for Newhaven's NHD-1.8-128160EF display, featuring
an Ilitek ILI9163 controller.
Signed-off-by: Daniel Mack
Acked-by: Daniel Vetter
---
drivers/gpu/drm/tiny/Kconfig | 13 ++
drivers/gpu/drm/tiny/Makefile | 1 +
drivers/gpu/drm/tiny/ili9163.c | 224 +
This adds documentation for a new ILI9163 based, SPI connected display.
Signed-off-by: Daniel Mack
---
.../display/panel/ilitek,ili9163.yaml | 69 +++
1 file changed, 69 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/ilitek,ili9163.yaml
Hi Stephen,
thanks for the report.
On Mon, Mar 29, 2021 at 09:01:17AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 26 Mar 2021 19:58:38 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the drm-intel-fixes tree, today's linux-next build
> > (htmldocs) produced this warning:
> >
>
Am 29.03.21 um 20:08 schrieb Xi Ruoyao:
On 2021-03-29 20:04 +0200, Christian König wrote:
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the
Am 29.03.21 um 19:53 schrieb Xℹ Ruoyao:
If the initial value of `num_entires` (calculated at line 1654) is not
an integral multiple of `AMDGPU_GPU_PAGES_IN_CPU_PAGE`, in line 1681 a
value greater than the initial value will be assigned to it. That causes
`start > last + 1` after line 1708. Then
On Mon, Mar 29, 2021 at 6:27 AM Xin Ji wrote:
>
> On Thu, Mar 25, 2021 at 02:19:23PM -0400, Sean Paul wrote:
> > On Fri, Mar 19, 2021 at 2:35 AM Xin Ji wrote:
> > >
> > > Add HDCP feature, enable HDCP function through chip internal key
> > > and downstream's capability.
> > >
> > > Signed-off-by:
There'a limit to how big a kmalloc buffer can be, and as memory gets
fragmented it becomes more difficult to get big buffers. The downside of
smaller buffers is that the driver has to split the transfer up which
hampers performance. Compression might also take a hit because of the
splitting.
Solve
Free transfer and compression buffers on device removal instead of at
DRM device removal time. This ensures that the usual 2x8MB buffers are
released when the device is unplugged and not kept around should
userspace keep the DRM device fd open.
At least Ubuntu 20.04 doesn't release the DRM device
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fault), but it doesn't have s
Avoid requesting a full modeset if the sharpness property is not
modified, because then we don't actually need it.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 4 +++-
1 file changed, 3 insertion
It should have been an OVERLAY from the beginning. The documentation
stipulates that there should be an unique PRIMARY plane per CRTC.
Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +---
1 - 100 of 177 matches
Mail list logo
