Hi Laurent,
Thanks for the feedback.
> Subject: Re: [PATCH v5 3/3] drm/bridge/analogix/anx78xx: Drop conditionals
> around of_node pointers
>
> Hi Biju,
>
> Thank you for the patch.
>
> On Wed, Aug 30, 2023 at 06:08:19PM +0100, Biju Das wrote:
> > Having conditional around the of_node pointers
On Wed, Aug 30, 2023 at 09:10:26AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 29.08.23 um 22:02 schrieb Jonathan Neuschäfer:
> > The files fbmem.c, fb_defio.c, fbsysfs.c, fbmon.c, modedb.c, and
> > fbcmap.c were moved to drivers/video/fbdev, and subsequently to
> > drivers/video/fbdev/core, in th
On 8/30/23 13:19, Thomas Zimmermann wrote:
Hi
Am 25.08.23 um 15:22 schrieb Thierry Reding:
From: Thierry Reding
Tegra DRM doesn't support display on Tegra234 and later, so make sure
not to remove any existing framebuffers in that case.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/teg
Am 31.08.23 um 00:08 schrieb André Almeida:
Create a module option to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm
Am 31.08.23 um 00:08 schrieb André Almeida:
Merge all developer debug options available as separated module
parameters in one, making it obvious that are for developers.
Drop the obsolete module options in favor of the new ones.
Signed-off-by: André Almeida
---
v2:
- drop old module params
Fulfill the SMU13.0.7 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
--
v10->v11:
- downgrade the prompt level on message failure(Lijo)
---
.../drm/amd/pm/swsmu/smu13/smu_v13_0_7_ppt.c | 59 +++
1 file changed, 59 insertions(+
Fulfill the SMU13.0.0 support for Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
--
v10->v11:
- downgrade the prompt level on message failure(Lijo)
---
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 3 +
drivers/gpu/drm/amd/pm/swsmu/inc/smu_types.h |
With WBRF feature supported, as a driver responding to the frequencies,
amdgpu driver is able to do shadow pstate switching to mitigate possible
interference(between its (G-)DDR memory clocks and local radio module
frequency bands used by Wifi 6/6e/7).
Signed-off-by: Evan Quan
Reviewed-by: Mario
To protect PMFW from being overloaded.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 31 +++
drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | 7 +
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/dr
Add those data structures to support Wifi RFI mitigation feature.
Signed-off-by: Evan Quan
Reviewed-by: Mario Limonciello
---
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_0.h | 14 +-
.../pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_7.h | 14 +-
.../amd/pm/swsmu/inc/pmfw
To support the WBRF mechanism, Wifi adapters utilized in the system must
register the frequencies in use(or unregister those frequencies no longer
used) via the dedicated calls. So that, other drivers responding to the
frequencies can take proper actions to mitigate possible interference.
Co-devel
The newly added WBRF feature needs this interface for channel
width calculation.
Signed-off-by: Evan Quan
--
v8->v9:
- correct typo(Mhz -> MHz) (Johnson)
---
include/net/cfg80211.h | 8
net/wireless/chan.c| 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/incl
Due to electrical and mechanical constraints in certain platform designs
there may be likely interference of relatively high-powered harmonics of
the (G-)DDR memory clocks with local radio module frequency bands used
by Wifi 6/6e/7.
To mitigate this, AMD has introduced a mechanism that devices can
Due to electrical and mechanical constraints in certain platform designs there
may be likely interference of relatively high-powered harmonics of the (G-)DDR
memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To
mitigate possible RFI interference producers can advertise the
Hey Linus,
This is a PR to add drm-ci support files to the upstream tree.
This is a bunch of ci integration for the freedesktop gitlab instance
where we currently do upstream userspace testing on diverse sets of GPU
hardware. From my perspective I think it's an experiment worth going with
and seei
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Now that CDM block support has been added to DPU lets also add its
> entry to the DPU snapshot to help debugging.
>
> Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
> 1
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Since CDM block support has now been added for writeback blocks
> add NV12 in the list of supported WB formats.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> On chipsets where CDM block is not available OR where support has
> not been added yet do not allow YUV formats for writeback block.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 6 ++
> 1
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Reserve CDM blocks for writeback if the format of the output fb
> is YUV. At the moment, the reservation is done only for writeback
> but can easily be extended by relaxing the checks once other
> interfaces are ready to output YUV.
>
> Signed
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> To setup and enable CDM block for the writeback pipeline, lets
> add the pieces together to set the active bits and the flush
> bits for the CDM block.
>
> Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> In preparation of setting up CDM block, add the logic to disable it
> properly during encoder cleanup.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8
> drivers/gpu/drm/msm/disp/dpu1/dp
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> CDM block will need its own logic to program the flush and active
> bits in the dpu_hw_ctl layer.
>
> Make necessary changes in dpu_hw_ctl to support CDM programming.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
> the writeback encoder to setup the CDM block.
>
> Currently, this is defined and used within the writeback's physical
> encoder layer however, the function can be modified t
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Even though there is usually only one CDM block, it can be
> used by either HDMI, DisplayPort OR Writeback interfaces.
>
> Hence its allocation needs to be tracked properly by the
> resource manager to ensure appropriate availability of the
>
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> CDM block comes with its own set of registers and operations
> which can be done. In-line with other hardware sub-blocks, this
> change adds the dpu_hw_cdm abstraction for the CDM block.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/d
On Thu, 31 Aug 2023 at 01:50, Abhinav Kumar wrote:
>
> Add the RM APIs necessary to initialize and allocate CDM
> blocks by the rest of the DPU pipeline.
... to be used by the rest?
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +
> driver
On Thu, 31 Aug 2023 at 01:49, Abhinav Kumar wrote:
>
> dpu_encoder_phys_wb_setup_cdp() is not programming the chroma down
> prefetch block. Its setting up the display ctl path for writeback.
>
> Hence rename it to dpu_encoder_phys_wb_setup_ctl() to match what its
> actually doing.
>
> Fixes: d7d0e
On Thu, 31 Aug 2023 at 01:49, Abhinav Kumar wrote:
>
> In preparation of adding more formats to dpu writeback add
I think it is `preparation to'
Other than that:
Reviewed-by: Dmitry Baryshkov
> format validation to it to fail any unsupported formats.
>
> Fixes: d7d0e73f7de3 ("drm/msm/dpu: int
On Thu, 31 Aug 2023 at 01:49, Abhinav Kumar wrote:
>
> For YUV cases, setting the required format bits was missed
> out in the register programming. Lets fix it now in preparation
> of adding YUV formats support for writeback.
>
> Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for wr
Hi,
On Tue, Aug 29, 2023 at 1:38 AM Maxime Ripard wrote:
>
> On Mon, Aug 28, 2023 at 09:06:29AM -0700, Doug Anderson wrote:
> > > > Shutdown is called any time you reboot a device. That means that if a
> > > > DRM driver is _not_ calling drm_atomic_helper_shutdown() on the
> > > > panel's behalf
On Thu, 31 Aug 2023 at 01:49, Abhinav Kumar wrote:
>
> Add CDM blocks to the sc7280 dpu_hw_catalog to support
> YUV format output from writeback block.
>
> Signed-off-by: Abhinav Kumar
> ---
> .../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 9 +
> drivers/gpu/drm/msm/disp/dpu1/dpu
To setup and enable CDM block for the writeback pipeline, lets
add the pieces together to set the active bits and the flush
bits for the CDM block.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a
In preparation of setting up CDM block, add the logic to disable it
properly during encoder cleanup.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 2 ++
2 files changed, 10 insertions(+)
diff --
Now that CDM block support has been added to DPU lets also add its
entry to the DPU snapshot to help debugging.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/
Reserve CDM blocks for writeback if the format of the output fb
is YUV. At the moment, the reservation is done only for writeback
but can easily be extended by relaxing the checks once other
interfaces are ready to output YUV.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_en
Since CDM block support has now been added for writeback blocks
add NV12 in the list of supported WB formats.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/driv
CDM block will need its own logic to program the flush and active
bits in the dpu_hw_ctl layer.
Make necessary changes in dpu_hw_ctl to support CDM programming.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 34 ++
drivers/gpu/drm/msm/disp/dpu1
On chipsets where CDM block is not available OR where support has
not been added yet do not allow YUV formats for writeback block.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/di
Add the RM APIs necessary to initialize and allocate CDM
blocks by the rest of the DPU pipeline.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers
Add an API dpu_encoder_helper_phys_setup_cdm() which can be used by
the writeback encoder to setup the CDM block.
Currently, this is defined and used within the writeback's physical
encoder layer however, the function can be modified to be used to setup
the CDM block even for non-writeback interfa
Even though there is usually only one CDM block, it can be
used by either HDMI, DisplayPort OR Writeback interfaces.
Hence its allocation needs to be tracked properly by the
resource manager to ensure appropriate availability of the
block.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/di
dpu_encoder_phys_wb_setup_cdp() is not programming the chroma down
prefetch block. Its setting up the display ctl path for writeback.
Hence rename it to dpu_encoder_phys_wb_setup_ctl() to match what its
actually doing.
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
write
CDM block comes with its own set of registers and operations
which can be done. In-line with other hardware sub-blocks, this
change adds the dpu_hw_cdm abstraction for the CDM block.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile| 1 +
drivers/gpu/drm/msm/disp/dp
Add CDM blocks to the sm8250 dpu_hw_catalog to support
YUV format output from writeback block.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250
In preparation of adding more formats to dpu writeback add
format validation to it to fail any unsupported formats.
Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for
writeback")
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 7 ++
Add CDM blocks to the sc7280 dpu_hw_catalog to support
YUV format output from writeback block.
Signed-off-by: Abhinav Kumar
---
.../gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h | 9 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 13 +
drivers/gpu/drm/msm/disp/dpu
For YUV cases, setting the required format bits was missed
out in the register programming. Lets fix it now in preparation
of adding YUV formats support for writeback.
Fixes: 84a33d0fd921 ("drm/msm/dpu: add dpu_hw_wb abstraction for writeback
blocks")
Signed-off-by: Abhinav Kumar
---
drivers/gp
Chroma Down Sampling (CDM) block is a hardware block in the DPU pipeline
which among other things has a CSC block that can convert RGB input
from the DPU to YUV data.
This block can be used with either HDMI, DP or writeback interface.
In this series, lets first add the support for CDM block to be
Merge all developer debug options available as separated module
parameters in one, making it obvious that are for developers.
Drop the obsolete module options in favor of the new ones.
Signed-off-by: André Almeida
---
v2:
- drop old module params
- use BIT() macros
- replace global var with adev
Create a module option to disable soft recoveries on amdgpu, making
every recovery go through the device reset path. This option makes
easier to force device resets for testing and debugging purposes.
Signed-off-by: André Almeida
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/dr
As suggested by Christian at [0], this patchset merges all debug modules
parameters and creates a new one for disabling soft recovery:
> Maybe we can overload the amdgpu_gpu_recovery module option with this.
> Or even better merge all the developer module parameter into a
> amdgpu_debug option.
Other then the name typo (s/Pual/Paul):
Signed-off-by: Lyude Paul (just since I co-authored
things~)
Reviewed-by: Lyude Paul
I think we definitely want to make sure we get intel's opinions on this
though, especially regarding the usage of link-status. I think we're close
enough to link-status's
The pull request you sent on Wed, 30 Aug 2023 11:03:03 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-08-30
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/461f35f014466c4e26dca6be0f431f57297df3f2
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Thu, 2023-08-24 at 16:50 -0400, Gil Dekel wrote:
> Unlike SST, MST can support multiple displays connected to a single
> connector. However, this also means that if the DisplayPort link to the
> top-level MST branch device becomes unstable, then every single branch
> device has an unstable link.
Amazing! This work looks awesome Imre, sorry it took me a little bit to get
back to this :). For all of the DP MST helper patches:
Reviewed-by: Lyude Paul
On Thu, 2023-08-24 at 11:05 +0300, Imre Deak wrote:
> For fractional bpp values passed to the function in a .4 fixed point
> format, the frac
On Wed, Aug 30, 2023 at 08:47:37AM +, Shankar, Uma wrote:
>
>
> > -Original Message-
> > From: Harry Wentland
> > Sent: Wednesday, August 30, 2023 12:56 AM
> > To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> > dri-
> > de...@lists.freedesktop.org
> > Cc: wayland-de...@lists.fr
Hi Biju,
Thank you for the patch.
On Wed, Aug 30, 2023 at 06:08:19PM +0100, Biju Das wrote:
> Having conditional around the of_node pointers turns out to make driver
> code use ugly #ifdef and #if blocks. So drop the conditionals.
How about doing this for all bridge drivers in one go ?
> Sugges
Hi Tomi,
On 29.08.23 08:27, Tomi Valkeinen wrote:
> Hi Maxim,
>
> On 22/08/2023 19:19, Tomi Valkeinen wrote:
>> This series contains various fixes and cleanups for TC358768. The target
>> of this work is to get TC358768 working on Toradex's AM62 based board,
>> which has the following display pip
Hi Biju,
Thank you for the patch.
In the commit message, s/pointers/pointer/ as you're only touching a
single one.
On Wed, Aug 30, 2023 at 06:08:18PM +0100, Biju Das wrote:
> The commit c9e358dfc4a8 ("driver-core: remove conditionals around
> devicetree pointers") supposed to remove conditionals
Hi,
On Wed, Aug 30, 2023 at 10:08 AM Biju Das wrote:
>
> Having conditional around the of_node pointers turns out to make driver
> code use ugly #ifdef and #if blocks. So drop the conditionals.
>
> Suggested-by: Douglas Anderson
> Signed-off-by: Biju Das
> ---
> v5:
> * Split from patch#2
> --
Hi,
On Wed, Aug 30, 2023 at 10:08 AM Biju Das wrote:
>
> The commit c9e358dfc4a8 ("driver-core: remove conditionals around
> devicetree pointers") supposed to remove conditionals around of_node
> pointer, but it missed out drm/bridge.h. So drop #if conditionals by
> adding struct device_node forw
On Wed, 2023-08-30 at 17:29 +0300, Andy Shevchenko wrote:
> On Wed, Aug 30, 2023 at 5:19 PM wrote:
> > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > >
> > > wrote:
>
> > > > --- a/include/linux/string.h
> > > > +++ b/include/l
[Public]
> -Original Message-
> From: Samuel Holland
> Sent: Wednesday, August 30, 2023 2:58 PM
> To: Quan, Evan ; Deucher, Alexander
> ; Koenig, Christian
>
> Cc: Samuel Holland ; Daniel Vetter
> ; David Airlie ; Pan, Xinhui
> ; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesk
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin wrote:
>
> From: Lang Yu
>
> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
>
> When using cpu to update page tables, vm update fences are unused.
> Install stub fence into these fence pointers instead of NULL
> to avoid NULL dereference w
On Sun, Aug 27, 2023 at 07:05:59PM +, Kasireddy, Vivek wrote:
> Hi Jason, David,
>
> > > > Sure, we can simply always fail when we detect ZONE_MOVABLE or
> > > MIGRATE_CMA.
> > > > Maybe that keeps at least some use cases working.
> > >
> > > That seems fairly reasonable
> > AFAICS, failing ud
Having conditional around the of_node pointers turns out to make driver
code use ugly #ifdef and #if blocks. So drop the conditionals.
Suggested-by: Douglas Anderson
Signed-off-by: Biju Das
---
v5:
* Split from patch#2
---
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c | 2 --
1 file chang
The commit c9e358dfc4a8 ("driver-core: remove conditionals around
devicetree pointers") supposed to remove conditionals around of_node
pointer, but it missed out drm/bridge.h. So drop #if conditionals by
adding struct device_node forward declaration.
Suggested-by: Douglas Anderson
Signed-off-by:
The driver has an ID table, but it uses the wrong API for retrieving match
data and that will lead to a crash, if it is instantiated by user space or
using ID. From this, there is no user for the ID table and let's drop it
from the driver as it saves some memory.
Signed-off-by: Biju Das
Reviewed-
This patch series aims to drop ID table and conditionals around of_node
pointers for anx78xx driver.
While at it, drop conditionals from drm_bridge.h.
v4->v5:
* Added Rb tag from Andy and Helen for patch#1.
* Split patch#2 into two
* Added struct device_node forward declaration for patch#2.
PATCH 1 and 3 are
Tested-by:JamesZhu
Best Regards!
James Zhu
On 2023-07-24 17:14, Michał Winiarski wrote:
64 DRM device nodes is not enough for everyone.
Upgrade it to ~512K (which definitely is more than enough).
To allow testing userspace support for >64 devices, add additional DRM
modpara
On Mon, Aug 28, 2023 at 04:38:01AM +, Kasireddy, Vivek wrote:
> Turns out, calling hmm_range_fault() from the invalidate callback was indeed
> a problem and the reason why new pages were not faulted-in. In other words,
> it looks like the invalidate callback is not the right place to invoke
>
On 30/08/2023 15:53, Boris Brezillon wrote:
> On Wed, 30 Aug 2023 15:12:43 +0100
> Steven Price wrote:
>
>> On 29/08/2023 16:33, Boris Brezillon wrote:
>>> On Mon, 14 Aug 2023 16:53:09 +0100
>>> Steven Price wrote:
>>>
> +
> +/**
> + * struct panthor_vm_op_ctx - VM operation conte
>> The current implementation will try to pick the highest available
>> unit. This is rather unflexible, and allowing drivers to display BO size
>> statistics through fdinfo in units of their choice might be desirable.
>>
>> The new argument to drm_show_memory_stats is to be interpreted as the
>> i
When another discrete video card(SM750 or AST1400) is mounted into the mini
PCIe slot of my ASRock AD2550B-ITX board, the gma500 drivers fails to work.
It probably because the UEFI firmware of that board forget to initialize
the PSB_PGETBL_CTL reg, therefore the value of dev_priv->pge_ctl is 0, the
while at it, also replace the 'K' with 'KiB'.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/gma500/gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 4b7627a72637..6fe78f61e127 100644
--- a/drivers/gpu
The PGTBL_CTL register provides the starting physical memory address of
the Graphics Translation Table (GTT). We want to see what's the value in
it. This patch is useful for debug.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/gma500/gtt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/
When another discrete video card(SM750 or AST1400) is mounted into the mini
PCIe slot of my ASRock AD2550B-ITX board, the gma500 drivers fails to work.
It probably because the UEFI firmware of that board forget to initialize
the PSB_PGETBL_CTL reg, therefore the value of dev_priv->pge_ctl is 0, the
On Wed, Aug 30, 2023 at 06:50:32AM -0700, Christoph Hellwig wrote:
> I know I'm chiming in a bit late, but what ultimate user space is going
> to use this? We should not add anything to the kernel that can't
> be used without fully open user space.
qemu will get the matching VFIO userspace patche
On 29/08/2023 17:15, Boris Brezillon wrote:
> On Wed, 16 Aug 2023 17:01:56 +0100
> Steven Price wrote:
>
>> On 09/08/2023 17:53, Boris Brezillon wrote:
[...]
>>> +/**
>>> + * panthor_fw_mem_alloc() - Allocate a FW memory object and map it to the
>>> MCU VM.
>>> + * @ptdev: Device.
>>> + * @siz
On 8/28/23 17:02, Lazar, Lijo wrote:
> [AMD Official Use Only - General]
>
>
> As mentioned with an older version of this series, this is an 'abuse' of
> power profile interface.
>
> This series is oversimplifying what PMFW algorithms are supposed to be doing.
> Whatever this series is doing,
On 30/08/2023 11:57, Maxime Ripard wrote:
On Wed, Aug 30, 2023 at 10:24:49AM -0300, Helen Koike wrote:
Hi all,
Thanks for you comments.
On 30/08/2023 08:37, Maxime Ripard wrote:
On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
On Wed, 30 Aug 2023, Maxime Ripard wrote:
On Tue
On Wed, Aug 30, 2023 at 03:42:08PM +0200, Thomas Hellström (Intel) wrote:
>
> On 8/30/23 14:49, Danilo Krummrich wrote:
> > Hi Thomas,
> >
> > thanks for having a look!
> >
> > On Wed, Aug 30, 2023 at 09:27:45AM +0200, Thomas Hellström (Intel) wrote:
> > > Hi, Danilo.
> > >
> > > Some quick com
On Wed, Aug 30, 2023 at 10:24:49AM -0300, Helen Koike wrote:
> Hi all,
>
> Thanks for you comments.
>
> On 30/08/2023 08:37, Maxime Ripard wrote:
> > On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> > > On Wed, 30 Aug 2023, Maxime Ripard wrote:
> > > > On Tue, Aug 22, 2023 at 04:26
On Wed, 30 Aug 2023 15:12:43 +0100
Steven Price wrote:
> On 29/08/2023 16:33, Boris Brezillon wrote:
> > On Mon, 14 Aug 2023 16:53:09 +0100
> > Steven Price wrote:
> >
> >>> +
> >>> +/**
> >>> + * struct panthor_vm_op_ctx - VM operation context
> >>> + *
> >>> + * With VM operations potential
replying to a couple points on this thread
On Wed, Aug 30, 2023 at 6:25 AM Helen Koike wrote:
>
> Hi all,
>
> Thanks for you comments.
>
> On 30/08/2023 08:37, Maxime Ripard wrote:
> > On Wed, Aug 30, 2023 at 01:58:31PM +0300, Jani Nikula wrote:
> >> On Wed, 30 Aug 2023, Maxime Ripard wrote:
> >
On Wed, Aug 30, 2023 at 5:19 PM wrote:
> On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > wrote:
> > > --- a/include/linux/string.h
> > > +++ b/include/linux/string.h
> >
> > I'm wondering if this has no side-effects as string.h/st
As per spec, it is allowed to pulse the HPD signal to indicate that the
EDID information has changed. Some monitors do this when they wake up
from standby or are enabled. When the HPD goes low the adv7511 is
reset and the outputs are disabled which might cause the monitor to
go to standby again. To
The ADV7511 needs link configuration whereas ADV75{33,35} does not need
it. Add a variable link_config to struct adv7511_chip_info to handle
this difference.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2:
* Add Rb tag from Laurent.
* Replaced variable type from unsigned->boo
The ADV7533 and ADV7535 have DSI support. Add a variable has_dsi to
struct adv7511_chip_info for handling configuration related to DSI.
Signed-off-by: Biju Das
---
v1->v2:
* Replaced variable type from unsigned->bool.
* Restored check using type for low_refresh_rate and
regmap_register_patch
The ADV7533 and ADV7535 have an offset(0x70) for the CEC register map
compared to ADV7511. Add the reg_cec_offset variable to struct
adv7511_chip_info to handle this difference and drop the reg_cec_offset
variable from struct adv7511.
This will avoid assigning reg_cec_offset based on chip type and
The ADV7511 has 5 power supplies compared to 7 that of ADV75{33,35}. Add
supply_names and num_supplies variables to struct adv7511_chip_info to
handle this difference.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2:
* Added Rb tag from Laurent.
* Added trailing commas for num
The ADV7533 supports a maximum lane clock of 800MHz whereas it is 891MHz
for ADV7535. Add max_lane_freq_khz variable to struct adv7511_chip_info to
handle this difference.
While at it, drop the unused local variable max_lane_freq.
Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
---
v1->v2
The ADV7533 supports a maximum pixel clock of 80MHz whereas it is 148.5MHz
for ADV7535. Add max_mode_clock_khz variable to struct adv7511_chip_info to
handle this difference.
Signed-off-by: Biju Das
Reviewed-by: Adam Ford
Tested-by: Adam Ford #imx8mm-beacon
Reviewed-by: Laurent Pinchart
---
*
Add struct adv7511_chip_info to handle hw differences between various
chips rather checking against the 'type' variable in various places.
Replace 'adv->type'->'info->type' by moving variable 'type' from
struct adv7511 to struct adv7511_chip_info and add adv7511_chip_info as
device data for both OF
This patch series aims to improve ADV7511 driver by adding
feature bits and data instead of comparing enum adv7511_type for
various hardware differences between ADV7511, ADV7533 and ADV7535.
This patch series tested with[1] on RZ/G2L SMARC EVK which embeds
ADV7535.
[1] https://patchwork.kernel.or
On Wed, 2023-08-30 at 17:15 +0300, Andy Shevchenko wrote:
> On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> wrote:
>
> > + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> > + return ERR_PTR(-EINVAL);
>
> > + if (unlikely(check_mul_overflow(n, size, &nbytes)))
>
Am 30.08.23 um 10:19 schrieb Andi Shyti:
Hi Christian,
On Tue, Aug 29, 2023 at 01:01:11PM +0200, Christian König wrote:
We want to remove per minor debugfs directories. Start by stopping
drivers from adding anything inside of those in the mid layer callback.
v2: drop it for the accel node as w
On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> wrote:
> >
> > Currently, user array duplications are sometimes done without an
> > overflow check. Sometimes the checks are done manually; sometimes
> > the
> > array size is calculated
On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner wrote:
> + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> + return ERR_PTR(-EINVAL);
> + if (unlikely(check_mul_overflow(n, size, &nbytes)))
> + return ERR_PTR(-EINVAL);
Btw, why not -EOVERFLOW ?
--
On 29/08/2023 16:33, Boris Brezillon wrote:
> On Mon, 14 Aug 2023 16:53:09 +0100
> Steven Price wrote:
>
>>> +
>>> +/**
>>> + * struct panthor_vm_op_ctx - VM operation context
>>> + *
>>> + * With VM operations potentially taking place in a dma-signaling path, we
>>> + * need to make sure everyth
1 - 100 of 175 matches
Mail list logo
