We only had nits before and all sorted now, so..
Reviewed-by: Alan Previn
On Tue, 2023-05-02 at 09:38 -0700, Ceraolo Spurio, Daniele wrote:
> From: Alexander Usyskin
>
> Add GSC proxy driver. It to allows messaging between GSC component
> on Intel graphics card and CSE device.
>
> Cc: Alan
On 2023-04-03 20:22, Matthew Brost wrote:
> Add generic schedule message interface which sends messages to backend
> from the drm_gpu_scheduler main submission thread. The idea is some of
> these messages modify some state in drm_sched_entity which is also
> modified during submission. By
On 2023-04-03 20:22, Matthew Brost wrote:
> Add helper to set TDR timeout and restart the TDR with new timeout
> value. This will be used in XE, new Intel GPU driver, to trigger the TDR
> to cleanup drm_sched_entity that encounter errors.
>
> Signed-off-by: Matthew Brost
> ---
>
LGTM
Reviewed-by: Alan Previn
On Tue, 2023-05-02 at 09:38 -0700, Ceraolo Spurio, Daniele wrote:
> From: Alexander Usyskin
>
> GSC Proxy component is used for communication between the
> Intel graphics driver and MEI driver.
>
> Cc: Alan Previn
> Signed-off-by: Alexander Usyskin
>
On 2023-04-03 20:22, Matthew Brost wrote:
> If the TDR is set to a value, it can fire before a job is submitted in
> drm_sched_main. The job should be always be submitted before the TDR
> fires, fix this ordering.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/scheduler/sched_main.c |
On Wed, May 03, 2023 at 10:47:43AM +0200, Christian König wrote:
> Adding Luben as well.
>
> Am 03.05.23 um 10:16 schrieb Boris Brezillon:
> > [SNIP]
> > > To sum-up, we shouldn't call drm_sched_{start,stop,resubmit_jobs}().
> > After the discussion I had with Matthew yesterday on IRC, I
> >
On Fri, Mar 17, 2023 at 3:36 PM Saravana Kannan wrote:
>
> On Sun, Mar 12, 2023 at 7:45 AM Martin Kepplinger
> wrote:
> >
> > Am Donnerstag, dem 09.03.2023 um 22:39 -0800 schrieb Saravana Kannan:
> > > After commit 3fb16866b51d ("driver core: fw_devlink: Make cycle
> > > detection more robust"),
Hi Dave, Daniel,
Fixes for 6.4.
The following changes since commit d893f39320e1248d1c97fde0d6e51e5ea008a76b:
drm/amd/display: Lowering min Z8 residency time (2023-04-26 22:53:58 -0400)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
On 30 4月 23 09:36:29, Oded Gabbay wrote:
> On Fri, Apr 28, 2023 at 5:49 PM Cai Huoqing wrote:
> >
> > Using rhashtable to accelerate the search for userptr by address,
> > instead of using a list.
> >
> > Preferably, the lookup complexity of a hash table is O(1).
> >
> > This patch will speedup
On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote:
> Zack Rusin writes:
>
> > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote:
> > > !! External Email
> > >
> > > Daniel Vetter writes:
> > >
> > > > On Mon, Jul 11, 2022 at 11:32:39PM -0400, Zack Rusin wrote:
On Wed, 2023-05-03 at 10:54 +0300, Pekka Paalanen wrote:
> On Wed, 3 May 2023 03:35:29 +
> Zack Rusin wrote:
>
> > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote:
> > > !! External Email
> > >
> > > Daniel Vetter writes:
> > >
> > > > On Mon, Jul 11, 2022 at
On Wed, May 3, 2023, 14:53 André Almeida wrote:
> Em 03/05/2023 14:08, Marek Olšák escreveu:
> > GPU hangs are pretty common post-bringup. They are not common per user,
> > but if we gather all hangs from all users, we can have lots and lots of
> > them.
> >
> > GPU hangs are indeed not very
On 5/3/2023 4:00 PM, Marijn Suijten wrote:
Hi Jessica,
On 2023-05-03 12:04:59, Jessica Zhang wrote:
On 5/3/2023 12:28 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:15, Jessica Zhang wrote:
Add a dpu_hw_intf op to enable data compression.
Signed-off-by: Jessica Zhang
---
On 2023-05-03 13:10:36, Kuogee Hsieh wrote:
> During DSC setup, the crossbar mux need to be programmed to engage
> DSC to specified PINGPONG. Hence during tear down, the crossbar mux
> need to be reset to disengage DSC from PINGPONG. 0X0F is written to
> reset crossbar mux. It is not relevant to
On 5/3/2023 4:03 PM, Marijn Suijten wrote:
Hi Jessica,
On 2023-05-03 12:03:40, Jessica Zhang wrote:
On 5/3/2023 12:07 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:14, Jessica Zhang wrote:
Add data_compress feature to DPU HW catalog.
In DPU 7.x and later, there is a DATA_COMPRESS
Hi Kuogee,
On 2023-05-03 13:10:34, Kuogee Hsieh wrote:
> Legacy DPU (DPU < 7.0.0) requires PP block to be involved during
Nit: I wouldn't call it "legacy" (that's not really relevant here), just
DPU < 7.0.0 requires the PINGPONG block ...
> DSC setting up. Since then, enable and start the
On 5/3/2023 12:51 PM, Dmitry Baryshkov wrote:
On 03/05/2023 22:04, Jessica Zhang wrote:
On 5/3/2023 12:28 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:15, Jessica Zhang wrote:
Add a dpu_hw_intf op to enable data compression.
Signed-off-by: Jessica Zhang
---
This patch add myself as maintainer to drm loongson driver
Signed-off-by: Sui Jingfeng
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e9a3bf32fe28..4aa2e587f061 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6920,6 +6920,13 @@ T:
On 2023-05-03 13:10:32, Kuogee Hsieh wrote:
> This series adds the DPU side changes to support DSC 1.2 encoder. This
> was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
> The DSI and DP parts will be pushed later on top of this change.
> This seriel is rebase on [1], [2] and
Hi Jessica,
On 2023-05-03 12:03:40, Jessica Zhang wrote:
>
>
> On 5/3/2023 12:07 AM, Marijn Suijten wrote:
> > On 2023-05-02 18:19:14, Jessica Zhang wrote:
> >> Add data_compress feature to DPU HW catalog.
> >>
> >> In DPU 7.x and later, there is a DATA_COMPRESS register that must be set
> >>
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Fei Yang
The first three patches in this series are taken from
https://patchwork.freedesktop.org/series/116868/
These patches are included here because the last patch
has dependency on the pat_index refactor.
This series is focusing on uAPI changes,
1. end support for set caching ioctl
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
Hi Jessica,
On 2023-05-03 12:04:59, Jessica Zhang wrote:
>
>
> On 5/3/2023 12:28 AM, Marijn Suijten wrote:
> > On 2023-05-02 18:19:15, Jessica Zhang wrote:
> >> Add a dpu_hw_intf op to enable data compression.
> >>
> >> Signed-off-by: Jessica Zhang
> >> ---
> >>
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
This patch set was posted at
https://patchwork.freedesktop.org/series/116868/
Change title since the PTE patch was merged separately.
These patches are extracted from series
https://patchwork.freedesktop.org/series/115980/
This series refactor the cache policy programming so
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
From: Fei Yang
PTE encode is platform dependent. After replacing cache_level with
pat_index, the newly introduced mtl_pte_encode is actually generic
for all gen12 platforms, thus rename it to gen12_pte_encode and
apply it to all gen12 platforms.
Cc: Chris Wilson
Cc: Matt Roper
Signed-off-by:
On 4/30/2023 4:57 PM, Dmitry Baryshkov wrote:
Rework dpu_encoder initialization code, simplifying calling sequences
and separating common init parts.
Please mention that your series was made on top of
https://patchwork.freedesktop.org/series/116530/.
Figured it out when I tried to apply
Add writeback support for sc7280. This was validated with kms_writeback
test case in IGT.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h
[...]
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> index 8c70a0ec7d2f..27c948350b5b 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
>> @@ -54,6 +54,25 @@ unsigned int
Reviewed-by: Lyude Paul
Thanks!
On Tue, 2023-05-02 at 17:38 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code does '(bpp << 4) / 16' in the MST PBN
> calculation, but that is just the same as 'bpp' so the
> DSC codepath achieves absolutely nothing. Fix it up so that
> the
On Tue, May 02, 2023 at 11:40:26AM +0200, Konrad Dybcio wrote:
>
>
> On 2.05.2023 09:49, Akhil P Oommen wrote:
> > On Sat, Apr 01, 2023 at 01:54:43PM +0200, Konrad Dybcio wrote:
> >> Some (particularly SMD_RPM, a.k.a non-RPMh) SoCs implement A6XX GPUs
> >> but don't implement the associated
Add support for DSC 1.2 by providing the necessary hooks to program
the DPU DSC 1.2 encoder.
Changes in v3:
-- fixed kernel test rebot report that "__iomem *off" is declared but not
used at dpu_hw_dsc_config_1_2()
-- unrolling thresh loops
Changes in v4:
-- delete DPU_DSC_HW_REV_1_1
-- delete
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both share same base address but with
its own different sub block address.
changes in v4:
--
During DSC setup, the crossbar mux need to be programmed to engage
DSC to specified PINGPONG. Hence during tear down, the crossbar mux
need to be reset to disengage DSC from PINGPONG. 0X0F is written to
reset crossbar mux. It is not relevant to hw_pp->idx. This patch add
PINGPONG_NONE to serve as
Current DSC flush update is piggyback inside dpu_hw_ctl_intf_cfg_v1().
This patch separates DSC flush away from dpu_hw_ctl_intf_cfg_v1() by
adding dpu_hw_ctl_update_pending_flush_dsc_v1() to handle both per
DSC engine and DSC flush bits at same time to make it consistent with
the location of flush
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
pingpong ops functions are required to complete DSC data path setup if
this chipset has DSC hardware block presented. This patch add
DPU_PINGPONG_DSC bit to both PP_BLK and PP_BLK_TE marcos if it has DSC
hardware block
Legacy DPU (DPU < 7.0.0) requires PP block to be involved during
DSC setting up. Since then, enable and start the DSC encoder engine
had moved to INTF with helps of flush mechanism. This patch adds
DPU_PINGPONG_DSC feature bit to indicate that both
dpu_hw_pp_setup_dsc() and dpu_hw_pp_dsc_enable()
From: Abhinav Kumar
There are some platforms has DSC blocks but it is not declared at catalog.
For completeness, this patch adds DSC blocks for platforms which missed
them.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
This series adds the DPU side changes to support DSC 1.2 encoder. This
was validated with both DSI DSC 1.2 panel and DP DSC 1.2 monitor.
The DSI and DP parts will be pushed later on top of this change.
This seriel is rebase on [1], [2] and catalog fixes from [3].
Abhinav Kumar (2):
drm/msm/dpu:
On 5/3/2023 11:55 AM, Dmitry Baryshkov wrote:
On 03/05/2023 20:45, Kuogee Hsieh wrote:
On 5/2/2023 3:42 PM, Dmitry Baryshkov wrote:
On 03/05/2023 00:02, Kuogee Hsieh wrote:
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to
indicate
pingpong ops functions are required to
On 03/05/2023 22:04, Jessica Zhang wrote:
On 5/3/2023 12:28 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:15, Jessica Zhang wrote:
Add a dpu_hw_intf op to enable data compression.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4
Em 03/05/2023 14:43, Timur Kristóf escreveu:
Hi Felix,
On Wed, 2023-05-03 at 11:08 -0400, Felix Kuehling wrote:
That's the worst-case scenario where you're debugging HW or FW
issues.
Those should be pretty rare post-bringup. But are there hangs caused
by
user mode driver or application bugs
Hi Thomas,
On Wed, May 03, 2023 at 10:15:46AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 02.05.23 um 22:08 schrieb Sam Ravnborg:
> > Hi Thomas.
> >
> > On Tue, May 02, 2023 at 03:02:23PM +0200, Thomas Zimmermann wrote:
> > > Update the names of the fb_mem*() helpers to be consistent with their
On 5/3/2023 12:28 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:15, Jessica Zhang wrote:
Add a dpu_hw_intf op to enable data compression.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
On 5/3/2023 12:07 AM, Marijn Suijten wrote:
On 2023-05-02 18:19:14, Jessica Zhang wrote:
Add data_compress feature to DPU HW catalog.
In DPU 7.x and later, there is a DATA_COMPRESS register that must be set
within the DPU INTF block for DSC to work.
As core_rev (and related macros) was
Hi Thomas,
> > But I am missing something somewhere as I cannot see how this builds.
> > asm-generic now provide the fb_read/fb_write helpers.
> > But for example sparc has an architecture specifc fb.h so it will not
> > use the asm-generic variant. So I wonder how sparc get hold of the
> >
On 03/05/2023 20:45, Kuogee Hsieh wrote:
On 5/2/2023 3:42 PM, Dmitry Baryshkov wrote:
On 03/05/2023 00:02, Kuogee Hsieh wrote:
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
pingpong ops functions are required to complete DSC data path setup if
this chipset has DSC
On 5/2/2023 2:42 PM, Dmitry Baryshkov wrote:
On 03/05/2023 00:03, Kuogee Hsieh wrote:
From: Abhinav Kumar
Add DSC 1.2 hardware blocks to the catalog with necessary sub-block and
feature flag information. Each display compression engine (DCE) contains
dual hard slice DSC encoders so both
Em 03/05/2023 14:08, Marek Olšák escreveu:
GPU hangs are pretty common post-bringup. They are not common per user,
but if we gather all hangs from all users, we can have lots and lots of
them.
GPU hangs are indeed not very debuggable. There are however some things
we can do:
- Identify the
On Sun, Apr 30, 2023 at 11:22:16AM +0200, Linus Walleij wrote:
> The ADS7846 has some limited support for using GPIO descriptors,
> let's convert it over completely and fix all users to provide
> GPIOs in descriptor tables.
>
> The Nokia 770 now has dynamic allocation of IRQ numbers, so this
>
On 5/2/2023 11:51 AM, Hamza Mahfooz wrote:
As made mention of, in commit 9128e6babf10 ("drm/amdgpu: fix
amdgpu_irq_put call trace in gmc_v10_0_hw_fini") and commit c094b8923bdd
("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini"). It
is meaningless to call amdgpu_irq_put() for
Hi
Am 03.05.23 um 17:02 schrieb Geert Uytterhoeven:
Hi Thomas,
On Wed, May 3, 2023 at 4:30 PM Thomas Zimmermann wrote:
Am 03.05.23 um 11:51 schrieb Geert Uytterhoeven:
On Fri, Apr 28, 2023 at 2:26 PM Thomas Zimmermann wrote:
Push the test for info->screen_base from fb_read() and
LGTM:
Reviewed-by: Alan Previn
On Fri, 2023-04-28 at 11:56 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Don't use 'xe_lp*' prefixes for register lists that are common with
> Gen8.
>
> Don't add Xe only GSC registers to pre-Xe devices that don't
> even have a GSC engine.
>
On 5/3/2023 1:03 AM, Marijn Suijten wrote:
On 2023-05-02 14:02:59, Kuogee Hsieh wrote:
During DSC setup, the crossbar mux need to be programmed to engage
DSC to specified PINGPONG. Hence during tear down, the crossbar mux
need to be reset to disengage DSC from PINGPONG. This patch add
On 5/2/2023 3:42 PM, Dmitry Baryshkov wrote:
On 03/05/2023 00:02, Kuogee Hsieh wrote:
At legacy chipsets, it required DPU_PINGPONG_DSC bit be set to indicate
pingpong ops functions are required to complete DSC data path setup if
this chipset has DSC hardware block presented. This patch add
On 5/3/2023 1:26 AM, Dmitry Baryshkov wrote:
On 03/05/2023 04:19, Jessica Zhang wrote:
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
WRITE_DATA with ENGINE=PFP will execute the packet on the frontend engine,
while ENGINE=ME will execute the packet on the backend engine.
Marek
On Wed, May 3, 2023 at 1:08 PM Marek Olšák wrote:
> GPU hangs are pretty common post-bringup. They are not common per user,
> but if we gather all
On 5/3/2023 1:33 AM, Dmitry Baryshkov wrote:
On 03/05/2023 04:19, Jessica Zhang wrote:
Divide the pclk rate by the compression ratio when DSC is enabled
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 14 ++
1 file changed, 10 insertions(+), 4
GPU hangs are pretty common post-bringup. They are not common per user, but
if we gather all hangs from all users, we can have lots and lots of them.
GPU hangs are indeed not very debuggable. There are however some things we
can do:
- Identify the hanging IB by its VA (the kernel should know it)
On Mon, May 1, 2023 at 8:38 AM Dmitry Osipenko <
dmitry.osipe...@collabora.com> wrote:
> On 4/16/23 14:52, Dmitry Osipenko wrote:
> > We have multiple Vulkan context types that are awaiting for the addition
> > of the sync object DRM UAPI support to the VirtIO-GPU kernel driver:
> >
> > 1. Venus
On Mon, Apr 24, 2023 at 3:17 PM Adam Ford wrote:
>
> On Mon, Apr 24, 2023 at 4:03 AM Jagan Teki wrote:
> >
> > On Sun, Apr 23, 2023 at 5:42 PM Adam Ford wrote:
> > >
> > > From: Lucas Stach
> > >
> > > Scale the blanking packet sizes to match the ratio between HS clock
> > > and DPI interface
From: Frieder Schrempf
The datasheet describes the following initialization flow including
minimum delay times between each step:
1. DSI data lanes need to be in LP-11 and the clock lane in HS mode
2. toggle EN signal
3. initialize registers
4. enable PLL
5. soft reset
6. enable DSI stream
7.
From: Frieder Schrempf
According to the documentation [1] the proper enable flow is:
1. Enable DSI link and keep data lanes in LP-11 (stop state)
2. Disable stop state to bring data lanes into HS mode
Currently we do this all at once within enable(), which doesn't
allow to meet the
From: Frieder Schrempf
This patchset contains a proposal to fix the initialization flow for
the display pipeline used on our i.MX8MM Kontron boards:
i.MX8MM LCDIF -> i.MX8MM DSIM -> TI SN65DSI84 -> 7" LVDS Panel
Without these changes the display works most of the time, but fails
to come up
On Wed, May 3, 2023 at 10:52 AM Frieder Schrempf
wrote:
>
> On 02.05.23 03:07, Adam Ford wrote:
> > The blanking calculation currently uses burst_clk_rate for calculating
> > the settings. Since it's possible to use this in non-burst mode, it's
> > possible that where won't be burst_clk_rate.
On 02.05.23 03:07, Adam Ford wrote:
> The blanking calculation currently uses burst_clk_rate for calculating
> the settings. Since it's possible to use this in non-burst mode, it's
> possible that where won't be burst_clk_rate. Instead, cache the
"possible that burst_clk_rate is 0"
> clock rate
On 02.05.23 03:07, Adam Ford wrote:
> 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
On 02.05.23 03:07, Adam Ford wrote:
> 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
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 drmcgroup_device->regions[..] name and size for each
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 drmcgroup_device->regions[..] name and size for each active
region.
- Call
Am 03.05.23 um 17:08 schrieb Felix Kuehling:
Am 2023-05-03 um 03:59 schrieb Christian König:
Am 02.05.23 um 20:41 schrieb Alex Deucher:
On Tue, May 2, 2023 at 11:22 AM Timur Kristóf
wrote:
[SNIP]
In my opinion, the correct solution to those problems would be
if
the kernel could give
On 02.05.23 03:07, Adam Ford wrote:
> 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
This fixes
On 02.05.23 03:07, Adam Ford wrote:
> 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
On 02.05.23 03:07, Adam Ford wrote:
> 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
On 02.05.23 03:07, Adam Ford wrote:
> 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
Am 2023-05-03 um 03:59 schrieb Christian König:
Am 02.05.23 um 20:41 schrieb Alex Deucher:
On Tue, May 2, 2023 at 11:22 AM Timur Kristóf
wrote:
[SNIP]
In my opinion, the correct solution to those problems would be
if
the kernel could give userspace the necessary information about
a
GPU hang
On Wed, May 3, 2023, at 16:55, Thomas Zimmermann wrote:
> Am 02.05.23 um 22:06 schrieb Arnd Bergmann:
>> It's probably safe to deal with all the above by either adding
>> architecture specific overrides to the current version, or
>> by doing the semantic changes before the move to asm/fb.h, but
Hi Thomas,
On Wed, May 3, 2023 at 4:30 PM Thomas Zimmermann wrote:
> Am 03.05.23 um 11:51 schrieb Geert Uytterhoeven:
> > On Fri, Apr 28, 2023 at 2:26 PM Thomas Zimmermann
> > wrote:
> >> Push the test for info->screen_base from fb_read() and fb_write() into
> >> the implementations of struct
Am 03.05.23 um 15:10 schrieb Lucas Stach:
Am Mittwoch, dem 03.05.2023 um 13:40 +0200 schrieb Christian König:
Hi Lucas,
Am 03.05.23 um 12:28 schrieb Lucas Stach:
Hi Christian,
Am Mittwoch, dem 03.05.2023 um 10:47 +0200 schrieb Christian König:
Adding Luben as well.
Am 03.05.23 um 10:16
Hi
Am 02.05.23 um 22:06 schrieb Arnd Bergmann:
On Tue, May 2, 2023, at 15:02, Thomas Zimmermann wrote:
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(),
in the architecture's header file or the generic one.
The common case has been the use of regular I/O functions, such
Merged, thanks!
Am 02.05.23 um 14:59 schrieb Dan Carpenter:
The "unode" pointer cannot be NULL here and checking for it causes
Smatch warnings:
drivers/gpu/drm/udl/udl_main.c:259 udl_get_urb_locked()
warn: can 'unode' even be NULL?
Fortunately, it's just harmless dead code which can
Hi
Am 03.05.23 um 11:51 schrieb Geert Uytterhoeven:
On Fri, Apr 28, 2023 at 2:26 PM Thomas Zimmermann wrote:
Push the test for info->screen_base from fb_read() and fb_write() into
the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
the driver operates on
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
i915 became the last flush_scheduled_work() user, but developers cannot
find time for auditing which work items does this flush_scheduled_work()
need
On 02/05/2023 05:11, fei.y...@intel.com wrote:
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum.
Am Mittwoch, dem 03.05.2023 um 13:40 +0200 schrieb Christian König:
> Hi Lucas,
>
> Am 03.05.23 um 12:28 schrieb Lucas Stach:
> > Hi Christian,
> >
> > Am Mittwoch, dem 03.05.2023 um 10:47 +0200 schrieb Christian König:
> > > Adding Luben as well.
> > >
> > > Am 03.05.23 um 10:16 schrieb Boris
On Tue, May 2, 2023 at 4:26 PM Ulf Hansson wrote:
> On Sun, 30 Apr 2023 at 11:22, Linus Walleij wrote:
> > Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
> > Signed-off-by: Linus Walleij
>
> This looks like it's best funneled through the soc maintainer's tree(s),
> right?
On Wed, May 03, 2023 at 02:07:04PM +0300, Ville Syrjälä wrote:
> On Wed, May 03, 2023 at 10:36:42AM +0300, Lisovskiy, Stanislav wrote:
> > On Tue, May 02, 2023 at 05:38:57PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The MST DSC code has a myriad of issues:
> > > -
Add support for 12-bit gamma lookup tables and introduce the first
user for it: MT8195.
While at it, also reorder the variables in mtk_gamma_set_common()
and rename `lut_base` to `lut0_base` to improve readability.
Signed-off-by: AngeloGioacchino Del Regno
---
All of the SoCs that don't have dithering control in the gamma IP
have got a GAMMA_LUT_TYPE bit that tells to the IP if the LUT is
"descending" (bit set) or "rising" (bit cleared): make sure to set
it correctly after programming the LUT.
Signed-off-by: AngeloGioacchino Del Regno
---
Newer Gamma IP have got multiple LUT banks: support specifying the
size of the LUT banks and handle bank-switching before programming
the LUT in mtk_gamma_set_common() in preparation for adding support
for MT8195 and newer SoCs.
Suggested-by: Jason-JH.Lin
[Angelo: Refactored original commit]
Disable relay mode at the end of LUT programming to make sure that the
processed image goes through.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_gamma.c
New SoCs, like MT8195, not only may support bigger lookup tables, but
have got a different register layout to support bigger precision:
support specifying the number of `lut_bits` for each SoC and use it
in mtk_gamma_set_common() to perform the right calculation.
Signed-off-by: AngeloGioacchino
Make the code more robust and improve readability by using bitfield
macros instead of open coding bit operations.
While at it, also add a definition for LUT_BITS_DEFAULT.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 41 ++-
1
Use drm_color_lut_extract() to avoid open-coding the bits reduction
calculations for each color channel and use a struct drm_color_lut
to temporarily store the information instead of an array of u32.
Also, slightly improve the precision of the HW LUT calculation in the
LUT DIFF case by performing
Move the write to DISP_GAMMA_CFG to enable the Gamma LUT to after
programming the actual table to avoid potential visual glitches during
table modification.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/mediatek/mtk_disp_gamma.c | 13 -
1 file changed, 8
1 - 100 of 153 matches
Mail list logo
