Hi, Jingfeng,
I think you should exchange the order of these two patches.
Huacai
On Thu, May 4, 2023 at 4:04 PM Sui Jingfeng wrote:
>
> This patch add myself as maintainer to drm loongson driver
>
> Signed-off-by: Sui Jingfeng
> ---
> MAINTAINERS | 7 +++
> 1 file changed, 7 insertions(
The DPHY timings are currently hard coded. Since the input
clock can be variable, the phy timings need to be variable
too. Add an additional variable to the driver data to enable
this feature to prevent breaking boards that don't support it.
The phy_mipi_dphy_get_default_config function configure
The high-speed clock is hard-coded to the burst-clock
frequency specified in the device tree. However, when
using devices like certain bridge chips without burst mode
and varying resolutions and refresh rates, it may be
necessary to set the high-speed clock dynamically based
on the desired pixel c
In order to support variable DPHY timings, it's necessary
to enable GENERIC_PHY_MIPI_DPHY so phy_mipi_dphy_get_default_config
can be used to determine the nominal values for a given resolution
and refresh rate.
Signed-off-by: Adam Ford
Tested-by: Frieder Schrempf
Reviewed-by: Frieder Schrempf
-
Make the pll-clock-frequency optional. If it's present, use it
to maintain backwards compatibility with existing hardware. If it
is absent, read clock rate of "sclk_mipi" to determine the rate.
Signed-off-by: Adam Ford
Tested-by: Chen-Yu Tsai
Tested-by: Frieder Schrempf
Reviewed-by: Frieder S
According to Table 13-45 of the i.MX8M Mini Reference Manual, the min
and max values for M and the frequency range for the VCO_out
calculator were incorrect. This information was contradicted in other
parts of the mini, nano and plus manuals. After reaching out to my
NXP Rep, when confronting him
From: Lucas Stach
Scale the blanking packet sizes to match the ratio between HS clock
and DPI interface clock. The controller seems to do internal scaling
to the number of active lanes, so we don't take those into account.
Signed-off-by: Lucas Stach
Signed-off-by: Adam Ford
Tested-by: Chen-Yu
This series fixes the blanking pack size and the PMS calculation. It then
adds support to allows the DSIM to dynamically DPHY clocks, and support
non-burst mode while allowing the removal of the hard-coded clock values
for the PLL for imx8m mini/nano/plus, and it allows the removal of the
burst-cl
On Fri, 05 May 2023 23:40:31 +0200, Konrad Dybcio wrote:
> Document the SM6375 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6375-mdss.yaml | 216
> +
> 1 file changed, 216 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
On Fri, 05 May 2023 23:40:30 +0200, Konrad Dybcio wrote:
> Document the SM6350 MDSS.
>
> Signed-off-by: Konrad Dybcio
> ---
> .../bindings/display/msm/qcom,sm6350-mdss.yaml | 214
> +
> 1 file changed, 214 insertions(+)
>
My bot found errors running 'make DT_CHECKER_
On Fri, May 5, 2023 at 10:40 PM Dave Airlie wrote:
>
> On Fri, 5 May 2023 at 01:23, Simon Ser wrote:
> >
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffer and bef
On 5/5/2023 2:23 PM, Jessica Zhang wrote:
Adjust the pclk rate to divide hdisplay by the compression ratio when DSC
is enabled.
Changes in v2:
- Adjusted pclk_rate math to divide only the hdisplay value by
compression ratio
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_h
On Tue, May 02, 2023 at 02:00:35PM +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition to enforce the type. Panels can be single- or
> dual-link, thus require only one port@0.
>
> Signed-off-by: Krzysztof Kozlowski
>
>
On Tue, May 02, 2023 at 02:00:36PM +0200, Krzysztof Kozlowski wrote:
> The panel-common schema does not define what "ports" property is, so
> bring the definition to enforce the type. All panels described by
> binding are dual-link, thus require both ports.
>
> Signed-off-by: Krzysztof Kozlowski
From: Konrad Dybcio
Add the SM6350 DPU compatible to clients compatible list, as it also
needs the workarounds.
Signed-off-by: Konrad Dybcio
Acked-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --gi
Add the SM6375 DPU compatible to clients compatible list, as it also
needs the workarounds.
Acked-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/dr
It got broken at some point, fix it up.
Signed-off-by: Konrad Dybcio
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index ae09c627bc84.
Add support for MDSS on SM6375.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 4e3a5f0c303c..0564
Document the SM6375 MDSS.
Signed-off-by: Konrad Dybcio
---
.../bindings/display/msm/qcom,sm6375-mdss.yaml | 216 +
1 file changed, 216 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6375-mdss.yaml
b/Documentation/devicetree/bindings/dis
Add basic SM6375 support to the DPU1 driver to enable display output.
Signed-off-by: Konrad Dybcio
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h | 152 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |
Add SM6350 support to the DPU1 driver to enable display output.
It's worth noting that one entry dpu_qos_lut_entry was trimmed off:
{.fl = 0, .lut = 0x0011223344556677 },
due to the fact that newer SoCs dropped the .fl (fill level)-based
logic and don't provide real values, resulting in all entr
Add support for MDSS on SM6350.
Reviewed-by: Dmitry Baryshkov
Reviewed-by: Marijn Suijten
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index e8c93731a
SC7180, SM6350 and SM6375 use a rather similar hw setup for DPU, with
the main exception being that the last one requires an additional
throttle clock.
It is not well understood yet, but failing to toggle it on makes the
display hardware stall and not output any frames.
Document SM6350 and SM6375
Document the SM6350 MDSS.
Signed-off-by: Konrad Dybcio
---
.../bindings/display/msm/qcom,sm6350-mdss.yaml | 214 +
1 file changed, 214 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
b/Documentation/devicetree/bindings/dis
Add the DSI host found on SM6350.
Acked-by: Rob Herring
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Docume
v2 -> v3:
- Don't duplicate qcm2290_lm_sblk
- Use DEFAULT_DPU_LINE_WIDTH defines
- Fix up sspp clk assignments for sm6350
- Add 6350-6375-common QoS data straight to the common file
instead of moving it around after adding it
- Fix up iommu compatible order before adding new entries
- Reuse sm635
Add the DSI host found on SM6375.
Acked-by: Rob Herring
Signed-off-by: Konrad Dybcio
---
Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
b/Docume
Adjust the pclk rate to divide hdisplay by the compression ratio when DSC
is enabled.
Changes in v2:
- Adjusted pclk_rate math to divide only the hdisplay value by
compression ratio
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 17 +
1 file changed, 13
Add a DPU INTF op to set DATA_COMPRESS register for command mode panels if
the DPU_INTF_DATA_COMPRESS feature flag is set. This flag needs to be
enabled in order for DSC v1.2 to work.
Note: These changes are for command mode only. Video mode changes will
be posted along with the DSC v1.2 support f
Currently, word count is calculated using slice_count. This is incorrect
as downstream uses slice per packet, which is different from
slice_count.
Slice count represents the number of soft slices per interface, and its
value will not always match that of slice per packet. For example, it is
possib
This is a series of changes for DSI to enable command mode support
for DSC v1.2.
This includes:
1) Adjusting pclk_rate to account for compression
2) Fixing the word count calculation for DSC
3) Setting the DATA_COMPRESS bit when DSC is enabled
With these changes (and the dependency below), DSC v
Add DATA_COMPRESS feature flag to DPU INTF block.
In DPU 7.x and later, DSC/DCE enablement registers have been moved from
PINGPONG to INTF.
As core_rev (and related macros) was removed from the dpu_kms struct, the
most straightforward way to indicate the presence of this register would be
to have
On Mon, May 01, 2023 at 08:51:01PM +0200, Artur Weber wrote:
> Add bindings for the S6D7AA0 LCD panel controller, including the
> S6D7AA0-LSL080AL02 panel used in the Samsung Galaxy Tab 3 8.0 family
> of tablets, and the S6D7AA0-LSL080AL03 and S6D7AA0-LTL101AT01 panels
> used in the Samsung Galaxy
On Fri, 5 May 2023 at 01:23, Simon Ser wrote:
>
> Hi all,
>
> The goal of this RFC is to expose a generic KMS uAPI to configure the color
> pipeline before blending, ie. after a pixel is tapped from a plane's
> framebuffer and before it's blended with other planes. With this new uAPI we
> aim to r
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_fb_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 6bb1b8b27d7a..3f34bcd8145c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm
On Sat, Apr 29, 2023 at 12:45:31PM +0200, Artur Weber wrote:
> Notable changes:
> - ROM child nodes use dashes instead of underscores; the driver
> reads all child nodes regardless of their names, so this doesn't
> break ABI.
> - pwm-period argument is deprecated, as it effectively duplicates
>
On Thu, May 04, 2023 at 06:27:53PM +0200, Andrzej Hajda wrote:
> Hi maintainers of net and i915,
>
> On 25.04.2023 00:05, Andrzej Hajda wrote:
> > This is revived patchset improving ref_tracker library and converting
> > i915 internal tracker to ref_tracker.
> > The old thread ended without consen
On Fri, May 05, 2023 at 04:06:26PM +, Simon Ser wrote:
> On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
>
> > Ok no comments from me on the actual color operations and semantics of all
> > that, because I have simply nothing to bring to that except confusion :-)
> >
> > Some higher
On Fri, May 05, 2023 at 05:57:37PM +0200, Sebastian Wick wrote:
> On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
> >
> > On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > > Hi all,
> > >
> > > The goal of this RFC is to expose a generic KMS uAPI to configure the
> > > color
> >
Hello,
On Wed, May 03, 2023 at 10:34:56AM +0200, Maarten Lankhorst wrote:
> RFC as I'm looking for comments.
>
> For long running compute, it can be beneficial to partition the GPU memory
> between cgroups, so each cgroup can use its maximum amount of memory without
> interfering with other sched
On Fri, May 05, 2023 at 03:53:54PM +0100, Robin Murphy wrote:
> > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > index 5c5cb5bee8b6..1d99c2d984fb 100644
> > > --- a/drivers/iommu/Kconfig
> > > +++ b/drivers/iommu/Kconfig
> > > @@ -137,7 +137,7 @@ config OF_IOMMU
> > > # IOMMU-
The pull request you sent on Fri, 5 May 2023 13:10:28 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-05-05
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/084f51d473cd566eab310d5da56fe7b68d0b10be
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
On Fri, 5 May 2023 at 20:24, Jeykumar Sankaran
wrote:
>
>
>
> On 5/2/2023 8:05 AM, Dmitry Baryshkov wrote:
> > Reorder SSPP register definitions to sort them in the ascending order.
> > Move register bitfields after the register definitions.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > d
On 5/4/2023 2:17 PM, Marijn Suijten wrote:
On 2023-05-04 22:33:17, Marijn Suijten wrote:
Title suggestion: use the wording "reduce pclk rate" :)
(Eventually "when DSC is enabled", instead of "for compression")
On 2023-05-02 18:19:12, Jessica Zhang wrote:
Divide the pclk rate by the compres
Applied. Thanks!
Alex
On Fri, May 5, 2023 at 3:43 AM Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> ./drivers/gpu/drm/amd/amdgpu/nbio_v7_9.c:146:2-3: Unneeded semicolon.
>
> Reported-by: Abaci Robot
> Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=4871
> Signed-off-by:
On Mon, Jan 09, 2023 at 05:18:16PM -0800, Brian Norris wrote:
> The self-refresh helper framework overloads "disable" to sometimes mean
> "go into self-refresh mode," and this mode activates automatically
> (e.g., after some period of unchanging display output). In such cases,
> the display pipe is
On Fri, May 5, 2023 at 2:39 PM WANG Xuerui wrote:
>
> On 5/6/23 02:00, Alex Deucher wrote:
> > On Fri, May 5, 2023 at 1:57 PM WANG Xuerui wrote:
> >>
> >> On a side note, I had to modprobe amdgpu with runpm=0, otherwise my
> >> dmesg gets flooded with PSP getting resumed every 8~10 seconds or so
From: Robert Foss
On Thu, 27 Apr 2023 16:29:25 +0200, Francesco Dolcini wrote:
> From: Francesco Dolcini
>
> This series includes multiple fixes on the tc358768 parallel RGB to DSI
> driver.
>
> With the following changes I am able to have a stable display output using a
> TI
> SN65DSI83 (DS
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Remove the unused phy_delay_nsk variable, before it was wrongly used
> to compute some register value, the fixed computation is no longer using
> it and therefore can be removed.
>
> Signed-off-by: Francesco
On Thu, May 04, 2023 at 01:45:24PM -0700, John Harrison wrote:
On 5/4/2023 13:29, Lucas De Marchi wrote:
On Thu, May 04, 2023 at 01:22:52PM -0700, john.c.harri...@intel.com
wrote:
From: John Harrison
Also switch to using reduced version file naming as it is no longer
such a work-in-progress a
Hi Linus,
On Fri, May 05, 2023 at 01:16:55PM +0200, Linus Walleij wrote:
>
> Populate the devices on the Nokia 770 CBUS I2C using software
> nodes instead of platform data quirks. This includes the LCD
> and the ADS7846 touchscreen so the conversion just brings the LCD
> along with it as software
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of THS_TRAILCNT register.
>
> This register must be set to a value that ensure that
> THS_TRAIL > 60 ns + 4 x UI
> and
> THS_TRAIL > 8 x UI
> and
> THS_TRAIL < TEOT
> with
> TEOT = 105
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TXTAGOCNT register.
>
> This register must be set to a value that ensure that the
> TTA-GO period = (4 x TLPX)
>
> with the actual value of TTA-GO being
>
> 4 x (TXTAGOCNT + 1) x (HSByt
dm/dc_fpu.c
> >> index 1743ca0a3641..86f4c0e04654 100644
> >> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> >> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c
> >> @@ -33,6 +33,8 @@
> >> #include
> >> #elif defined(CONFIG_ARM64)
On Thu, Apr 27, 2023 at 4:33 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of THS_ZEROCNT register.
>
> This register must be set to a value that ensure that
> THS_PREPARE + THS_ZERO > 145ns + 10*UI
>
> with the actual value of (THS_PREPARE + THS_ZERO) being
>
>
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TCLK_TRAILCNT register.
>
> The driver does not implement non-continuous clock mode, so the actual
> value doesn't make a practical difference yet. However this change also
> ensures th
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correct computation of TCLK_ZEROCNT register.
>
> This register must be set to a value that ensure that
> (TCLK-PREPARECNT + TCLK-ZERO) > 300ns
>
> with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being
On Thu, Apr 27, 2023 at 4:32 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Correctly compute the PLL target frequency, the current formula works
> correctly only when the input bus width is 24bit, actually to properly
> compute the PLL target frequency what is relevant is the bits-p
On Thu, Apr 27, 2023 at 4:35 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> According to Toshiba documentation the PLL input clock after the divider
> should be not less than 4MHz, fix the PLL parameters computation
> accordingly.
>
> Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 dr
On Thu, Apr 27, 2023 at 4:34 PM Francesco Dolcini wrote:
>
> From: Francesco Dolcini
>
> Always enable HS video mode setting the TXMD bit, without this change no
> video output is present with DSI sinks that are setting
> MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge).
>
> Previousl
Hi Maxime,
kernel test robot noticed the following build errors:
[auto build test ERROR on 145e5cddfe8b4bf607510b2dcf630d95f4db420f]
url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/clk-Export-clk_hw_forward_rate_request/20230505-193724
base
On 5/5/23 15:16, Pekka Paalanen wrote:
On Fri, 5 May 2023 14:30:11 +0100
Joshua Ashton wrote:
Some corrections and replies inline.
On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
On Thu, 04 May 2023 15:22:59 +
Simon Ser wrote:
...
To wrap things up, let's take a real-world e
On 5/3/2023 1:40 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. So pull it out into a separate function that is only
called once pe
This is a of the HuC support for MTL series [1]. It's been included
because one of the new patches in this series depend on it, but it
should be reviewd separately in its own thread.
[1] https://patchwork.freedesktop.org/series/117080/
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i9
A few fixes/updates are required around the GSC memory allocation and it
is easier to do them all at the same time. The changes are as follows:
1 - Switch the memory allocation to stolen memory. We need to avoid
accesses from GSC FW to normal memory after the suspend function has
completed and to
Add a new debugfs to dump information about the GSC. This includes:
- the FW path and SW tracking status;
- the release, security and compatibility versions;
- the HECI1 status registers.
Note that those are the same registers that the mei driver dumps in
their own status sysfs on DG2 (where mei
The compatibility version is queried via an MKHI command. Right now, the
only existing interface is 1.0
This is basically the interface version for the GSC FW, so the plan is
to use it as the main tracked version, including for the binary naming
in the fetch code.
Signed-off-by: Daniele Ceraolo Sp
Add FW definition and the matching override modparam.
The GSC FW has both a release version, based on platform and a rolling
counter, and a compatibility version, which is the one tracking
interface changes. Since what we care about is the interface, we use
the compatibility version in the buinary
The release and security versions of the GSC binary are not used at
runtime to decide interface compatibility (there is a separate version
for that), but they're still useful for debug, so it is still worth
extracting them and printing them out in dmesg.
To get to these version, we need to navigat
Last chunk of the required support for the GSC FW. This includes some
fixes to the GSC memory allocation, FW idefinition and version
management, plus a new debugfs for debug information.
Adding the FW definition will enable all the features that are dependent
on the GSC being loaded (Media C6, HuC
On Friday, May 5th, 2023 at 17:28, Daniel Vetter wrote:
> Ok no comments from me on the actual color operations and semantics of all
> that, because I have simply nothing to bring to that except confusion :-)
>
> Some higher level thoughts instead:
>
> - I really like that we just go with graph
On Fri, May 5, 2023 at 5:28 PM Daniel Vetter wrote:
>
> On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is tapped from a plane's
> > framebuffe
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base
On 05/05/2023 11:28, Vinod Koul wrote:
On 14-04-23, 08:22, Tom Rix wrote:
clang reports
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: error: variable
'ret' is uninitialized when used here [-Werror,-Wuninitialized]
if (ret)
^~~
ret should have been set by the prece
On Thu, May 04, 2023 at 03:22:59PM +, Simon Ser wrote:
> Hi all,
>
> The goal of this RFC is to expose a generic KMS uAPI to configure the color
> pipeline before blending, ie. after a pixel is tapped from a plane's
> framebuffer and before it's blended with other planes. With this new uAPI we
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base
On 2023-05-05 15:50, Jason Gunthorpe wrote:
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote:
Although iommu-dma is a per-architecture chonce, that is currently
implemented in a rather haphazard way. Selecting from the arch Kconfig
was the original logical approach, but is complicate
On Tue, Aug 16, 2022 at 06:28:03PM +0100, Robin Murphy wrote:
> Although iommu-dma is a per-architecture chonce, that is currently
> implemented in a rather haphazard way. Selecting from the arch Kconfig
> was the original logical approach, but is complicated by having to
> manage dependencies; con
Hi Jocelyn,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]
url:
https://github.com/intel-lab-lkp/linux/commits/Jocelyn-Falempe/drm-mgag200-Rename-constant-MGAREG_Status-to-MGAREG_STATUS/20230505-204705
base
On Tue, Apr 18, 2023 at 07:04:30AM -0700, Nikita Zhandarovich wrote:
> drm_dp_dsc_sink_max_slice_count() may return 0 if something goes
> wrong on the part of the DSC sink and its DPCD register. This null
> value may be later used as a divisor in intel_dsc_compute_params(),
> which will lead to an
I just now noticed the other comments. Wiill address them.
On 2023-05-03 17:31, Tvrtko Ursulin wrote:
On 03/05/2023 09:34, Maarten Lankhorst wrote:
Based roughly on the rdma and misc cgroup controllers, with a lot of
the accounting code borrowed from rdma.
The interface is simple:
- populate
Allow drivers to resolve a WW transaction rollback. This allows for
1) Putting a lower-priority transaction to sleep allowing another to
succeed instead both fighting using trylocks.
2) Letting the driver know whether a received -ENOMEM is the result of
competition with another WW transaction, whic
On Fri, 5 May 2023 14:30:11 +0100
Joshua Ashton wrote:
> Some corrections and replies inline.
>
> On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
> >
> > On Thu, 04 May 2023 15:22:59 +
> > Simon Ser wrote:
...
> > > To wrap things up, let's take a real-world example: how would gamesco
On 5/5/23 09:35, Daniel Vetter wrote:
> On Fri, May 05, 2023 at 09:20:26AM -0400, Harry Wentland wrote:
>>
>>
>> On 5/5/23 06:16, Daniel Vetter wrote:
>>> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
On Thu, 4 May 2023 17:25:57 -0400
Harry Wentland wrote:
>
Hey Huacai,
On 5/5/23 07:32, Huacai Chen wrote:
Now LoongArch provides kernel_fpu_begin() and kernel_fpu_end() in commit
2b3bd32ea3a22ea2d ("LoongArch: Provide kernel fpu functions"), so we can
enable DC_FP for DCN devices.
Have you had the chance to test how well this is working on actual
h
On Fri, May 05, 2023 at 09:20:26AM -0400, Harry Wentland wrote:
>
>
> On 5/5/23 06:16, Daniel Vetter wrote:
> > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
> >> On Thu, 4 May 2023 17:25:57 -0400
> >> Harry Wentland wrote:
> >>
> >>> We have steered away for a long time now fr
On 05/05, Pekka Paalanen wrote:
On Fri, 5 May 2023 12:16:55 +0200
Daniel Vetter wrote:
> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
> > On Thu, 4 May 2023 17:25:57 -0400
> > Harry Wentland wrote:
> >
> > > We have steered away for a long time now from driver-specific KM
Some corrections and replies inline.
On Fri, 5 May 2023 at 12:42, Pekka Paalanen wrote:
>
> On Thu, 04 May 2023 15:22:59 +
> Simon Ser wrote:
>
> > Hi all,
> >
> > The goal of this RFC is to expose a generic KMS uAPI to configure the color
> > pipeline before blending, ie. after a pixel is t
On 5/5/23 06:16, Daniel Vetter wrote:
> On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
>> On Thu, 4 May 2023 17:25:57 -0400
>> Harry Wentland wrote:
>>
>>> We have steered away for a long time now from driver-specific KMS APIs
>>> for good reasons but never codified our stance.
On Fri, May 05, 2023 at 02:20:39PM +0300, Pekka Paalanen wrote:
> On Fri, 5 May 2023 12:16:55 +0200
> Daniel Vetter wrote:
>
> > On Fri, May 05, 2023 at 11:43:20AM +0300, Pekka Paalanen wrote:
> > > On Thu, 4 May 2023 17:25:57 -0400
> > > Harry Wentland wrote:
> > >
> > > > We have steered aw
Register irq, and enable the softrap irq.
This patch has no functional impact since softrap
irq can't be triggered without DMA.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 41 +++
drivers/gpu/drm/mgag200/mgag200_drv.h | 3 ++
drivers/gpu/dr
Even if the transfer is not faster, it brings significant
improvement in latencies and CPU usage.
CPU usage drops from 100% of one core to 3% when continuously
refreshing the screen.
The primary DMA is used to send commands (register write), and
the secondary DMA to send the pixel data.
It uses t
This series adds DMA and IRQ for the mgag200 driver.
Unfortunately the DMA doesn't make the driver faster.
But it's still a big improvement regarding CPU usage and latency.
CPU usage goes from 100% of 1 CPU to 3% (using top and refreshing the screen
continuously).
top without DMA, and a bash s
From: Thomas Zimmermann
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Gerd Hoffmann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4 delet
Now that the driver handles only 16, 24 and 32-bit framebuffer,
it can be simplified.
No functional changes.
offset:
16bit: (bppshift = 1)
offset = width >> (4 - bppshift) => width / 8 => pitch / 16
24bit: (bppshift = 0)
offset = (width * 3) >> (4 - bppshift) => width * 3 / 16 => pitch / 16
3
On 25.04.2023 19:03, Rob Herring wrote:
> On Fri, Apr 21, 2023 at 12:31:12AM +0200, Konrad Dybcio wrote:
>> Document the SM6350 DPU.
>>
>> Signed-off-by: Konrad Dybcio
>> ---
>> .../bindings/display/msm/qcom,sm6350-dpu.yaml | 94
>> ++
>> 1 file changed, 94 insertions
Hi Sebastian,
Thanks for the v2 of your series. Looks great!
One nitpick though: you seem to wrap the patch message lines at ~50
characters sometimes, which is awfully short.
Another comment below:
On 4/22/23 22:50, Sebastian Reichel wrote:
> Avoid hard-coding the default_mode and supply it fro
On 27/04/2023 18:37, Marijn Suijten wrote:
On 2023-04-21 00:31:16, Konrad Dybcio wrote:
Add SM6350 support to the DPU1 driver to enable display output.
Signed-off-by: Konrad Dybcio
Signed-off-by: Konrad Dybcio
After addressing the comments from Dmitry (CURSOR0->DMA1 and
CURSOR1->DMA2), this
On Thu, 04 May 2023 15:22:59 +
Simon Ser wrote:
> Hi all,
>
> The goal of this RFC is to expose a generic KMS uAPI to configure the color
> pipeline before blending, ie. after a pixel is tapped from a plane's
> framebuffer and before it's blended with other planes. With this new uAPI we
> ai
1 - 100 of 134 matches
Mail list logo