On 30/07/2022 12:17, Akhil P Oommen wrote:
Some clients like adreno gpu driver would like to ensure that its gdsc
is collapsed at hardware during a gpu reset sequence. This is because it
has a votable gdsc which could be ON due to a vote from another subsystem
like tz, hyp etc or due to an inter
On 30/07/2022 12:17, Akhil P Oommen wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/gpucc-sc7280.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/
On 30/07/2022 12:17, Akhil P Oommen wrote:
Add support to allow soc specific clk drivers to specify a custom reset
operation. A consumer-driver of the reset framework can call
"reset_control_reset()" api to trigger this.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/reset.c | 6 ++
On 30/07/2022 12:40, Akhil P Oommen wrote:
Because there could be transient votes from other drivers/tz/hyp which
may keep the cx gdsc enabled, we should poll until cx gdsc collapses.
We can use the reset framework to poll for cx gdsc collapse from gpucc
clk driver.
This feature requires support
On 30/07/2022 12:17, Akhil P Oommen wrote:
Allow a consumer driver to poll for cx gdsc collapse through Reset
framework.
Signed-off-by: Akhil P Oommen
---
drivers/clk/qcom/gpucc-sc7280.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/gpucc-sc7280.c b/drivers/clk/
On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
>
>
>
> Sent from my iPad
>
> > On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote:
> >
> > CAUTION: Email originated externally, do not click links or open
> > attachments unless you recognize the sender and know the content is safe.
> >
> >
> >> On Mon,
On Thu, 14 Jul 2022 16:06:28 +0200
Michal Wajdeczko wrote:
> On 14.07.2022 14:06, Mauro Carvalho Chehab wrote:
> > From: Prathap Kumar Valsan
> >
> > Add routines to interface with GuC firmware for TLB invalidation.
> >
> > Signed-off-by: Prathap Kumar Valsan
> > Cc: Bruce Chang
> > Cc: Mich
Hi Adam, Fabio,
On 22-08-01, Adam Ford wrote:
> On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote:
> >
> > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote:
> >
> > > I managed to get my HDMI output working. I had the lanes set to 2
> > > instead of 4. Once I switched to 4-lanes, the monitor ca
Hi Maxime
Am 29.07.22 um 18:34 schrieb Maxime Ripard:
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-b
Hi Danilo,
Thank you for the patch.
On Tue, Aug 02, 2022 at 02:04:01AM +0200, Danilo Krummrich wrote:
> Quite a lot of drivers include the drm_fb_cma_helper.h header file
> without actually making use of it's provided API, hence remove those
> includes.
>
> Suggested-by: Sam Ravnborg
> Signed-o
Hi Kevin,
>
> OpenChrome DDX carries lots of legacy code.
>
> https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/tree/src/via_drm.h?h=main&id=dc661c59257e855cd9b29c14b91a8ee2d9b86ccb
>
> There is a requirement to use the same via_drm.h with both DDX and DRM.
> Hence, I need to keep a
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
>
> On 7/21/22 16:24, Daniel Dadap wrote:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> ATM on x86 laptops where we want userspace to use the acpi_video backlight
>>> device we often register both the GPU's native backlight device and
>>> acpi_v
On 8/1/22 18:32, Rob Herring wrote:
On Mon, Aug 01, 2022 at 03:19:00PM +0200, Marek Vasut wrote:
The ICN6211 is capable of swapping the output DPI RGB/BGR color channels,
document a DT property to select this swap in DT. This can be useful on
hardware where such swap happens.
We should ensure
Hi
Am 02.08.22 um 05:45 schrieb Kevin Brace:
Hi Thomas,
I hope I am comprehending this right.
Yes, I am adding 3 new uAPI calls, not 6 of them.
Correspondingly, there are 3 new structs added.
That's understood.
While I may drop one (unmap uAPI), I personally do not wish to drop the other
t
Currently we are assuming a one to one mapping between dmabuf and handle
when releasing GEM handles.
But that is not always true, since we would create extra handles for the
GEM obj in cases like gem_open() and getfb{,2}().
A similar issue was reported at:
https://lore.kernel.org/all/202111050833
There are two identical CFLAGS entries for "display_mode_vba_20.o", so
remove one of them. Also, as there's already an entry for
"display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being
defined or not, remove the one entry between CONFIG_DRM_AMD_DC_DCN ifdef
guards.
Signed-off-by: Ma
On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote:
>
> Hi Adam, Fabio,
>
> On 22-08-01, Adam Ford wrote:
> > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote:
> > >
> > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote:
> > >
> > > > I managed to get my HDMI output working. I had the lanes set
Sent from my iPad
> On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote:
>
> On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
>>
>>
>>
>> Sent from my iPad
>>
On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote:
>>>
>>> CAUTION: Email originated externally, do not click links or open
>>> attachm
Sorry, the previous one contains html data.
> On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote:
>
> On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
>> Sent from my iPad
On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote:
>>> CAUTION: Email originated externally, do not click links or open
>>> atta
Hi Jani, Ville and Imre,
If there are no problems after reviewing this patch series, could you
please merge it?
Many thanks,
G.G.
On 7/22/22 3:51 PM, Andrzej Hajda wrote:
Hi Jani, Ville, Arun,
This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver
On 2022-08-02 08:04, Magali Lemes wrote:
> There are two identical CFLAGS entries for "display_mode_vba_20.o", so
> remove one of them. Also, as there's already an entry for
> "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being
> defined or not, remove the one entry between CONFI
Às 22:06 de 29/07/22, Magali Lemes escreveu:
> As "dcn3_1_soc", "dcn3_15_soc", and "dcn3_16_soc" are not used outside
> of their corresponding "dcn3*_fpu.c", make them static and remove their
> extern declaration.
>
> Fixes: 26f4712aedbd ("drm/amd/display: move FPU related code from dcn31 to
>
Às 09:04 de 02/08/22, Magali Lemes escreveu:
> There are two identical CFLAGS entries for "display_mode_vba_20.o", so
> remove one of them. Also, as there's already an entry for
> "display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being
> defined or not, remove the one entry between C
On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote:
>
> On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote:
> >
> > Hi Adam, Fabio,
> >
> > On 22-08-01, Adam Ford wrote:
> > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote:
> > > >
> > > > On Mon, Aug 1, 2022 at 10:39 PM Adam Ford wrote:
> > > >
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
accomodate this new parameter.
The idea is to pass the workload hints while context creation, so
that ker
On Fri, 29 Jul 2022, Maxime Ripard wrote:
> Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
> modes in the drivers.
>
> Since those modes are fairly standards, and that we'll need to use them in
> more places in the future, let's move the meson definition into the
> fram
On Wed, 27 Jul 2022, Bo-Chen Chen wrote:
> From: Guillaume Ranquet
>
> This patch adds two helper functions that extract the frequency and word
> length from a struct cea_sad.
>
> For these helper functions new defines are added that help translate the
> 'freq' and 'byte2' fields into real number
Hi
Am 02.08.22 um 15:58 schrieb Jani Nikula:
On Fri, 29 Jul 2022, Maxime Ripard wrote:
Multiple drivers (meson, vc4) define the analog TV 525-lines and 625-lines
modes in the drivers.
Since those modes are fairly standards, and that we'll need to use them in
more places in the future, let's m
On Wed, 27 Jul 2022, Matthieu CHARETTE wrote:
> Loading an EDID using drm.edid_firmware parameter makes resume to fail
> after firmware cache is being cleaned. This is because edid_load() use a
> temporary device to request the firmware. This cause the EDID firmware
> not to be cached from suspend
Hi Olivier,
Some comments below as I mentioned off-list.
One additional point: some devices need to know if a buffer is
protected, so that they can configure registers appropriately to make
use of that protected buffer. There was previously a discussion about
adding a flag to a dma_buf to indicat
On Fri, 22 Jul 2022, Ankit Nautiyal wrote:
> DSC capabilities are given in bytes 11-13 of VSDB (i.e. bytes 8-10 of
> SCDS). Since minimum length of Data block is 7, all bytes greater than 7
> must be read only after checking the length of the data block.
>
> This patch adds check for data block le
[AMD Official Use Only - General]
I found out that elsewhere in the drm code (e.g. in drm_atomic_helper.c)
expects drm_vblank_get() to fail as part of normal operation. So this patch
doesn't seem appropriate anymore and it seems more appropriate to hunt down all
the unchecked calls for drm_vbla
On Tue, Aug 02, 2022 at 02:04:02AM +0200, Danilo Krummrich wrote:
> Rename "FB CMA" helpers to "FB DMA" helpers - considering the hierarchy
> of APIs (mm/cma -> dma -> fb dma) calling them "FB DMA" seems to be
> more applicable.
>
> Besides that, commit e57924d4ae80 ("drm/doc: Task to rename CMA h
From: Rob Clark
Unchanged other than small update in 09/15
original description below:
This is mostly motivated by getting drm/msm to pass an i-g-t shrinker
test that I've been working on. In particular the test creates and
cycles between more GEM buffers than what will fit in RAM to force
evi
From: Rob Clark
This lets us drop the NORETRY.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index c9e
From: Rob Clark
Move more initialization into submit_create().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_submit.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.
From: Rob Clark
Really what this is doing is updating various LRU lists.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
inde
From: Rob Clark
Avoid having multiple spots where we increment/decrement pin_count (and
associated LRU updating)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/
From: Rob Clark
Otherwise if we hit reclaim pinning objects in the submit path, we'll be
blocking retire_worker trying to free a submit.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 4 ++--
drivers/gpu/drm/msm/msm_gem_submit.c | 10 --
drivers/gpu/drm/msm/msm_
From: Rob Clark
Currently in our shrinker path we shouldn't be encountering anything
that is active, but this will change in subsequent patches. So check
if there are unsignaled fences.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 10 ++
drivers/gpu/drm/msm/ms
From: Rob Clark
Since that is what these fxns actually do.. they are getting *pinned*
pages (as opposed to cases where we need pages, but don't need them
pinned, like CPU mappings).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 18 +-
drivers/gpu/drm/msm/ms
From: Rob Clark
At this point the pinned refcnt is sufficient, and the shrinker is
already prepared to encounter objects which are still active according
to fences attached to the resv.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c| 45 ++--
drivers
From: Rob Clark
This converts over to use the shared GEM LRU/shrinker helpers. Note
that it means we are no longer tracking purgeable or willneed buffers
that are active separately. But the most recently pinned buffers should
be at the tail of the various LRUs, and the shrinker is already prepa
From: Rob Clark
If we are under enough memory pressure, we should stall waiting for
active buffers to become idle in order to evict.
v2: Check for __GFP_ATOMIC before blocking
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c | 70 +-
drivers/gpu/drm/
From: Rob Clark
We've already attached the fences, so obj->resv (which shrinker checks)
tells us whether they are still active. So we can unpin sooner, before
we drop the queue lock.
This also avoids the need to grab the obj lock in the retire path,
avoiding potential for lock contention betwee
From: Rob Clark
Combine separate trace events for purge vs evict into one. When we add
support for purging/evicting active buffers we'll just add more info
into this one trace event, rather than adding a bunch more events.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem_shrinker.c |
From: Rob Clark
All use of msm_gem_is_locked() is just for WARN_ON()s, so extract out
into an msm_gem_assert_locked() patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 36 +--
drivers/gpu/drm/msm/msm_gem.h | 8 +++-
2 files changed, 25 ins
From: Rob Clark
Add a simple LRU helper to assist with driver's shrinker implementation.
It handles tracking the number of backing pages associated with a given
LRU, and provides a helper to implement shrinker_scan.
A driver can use multiple LRU instances to track objects in various
states, for
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.h | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index 3c6add51d13b..c4844cf3a585 100644
--- a/drivers/gpu/drm/msm/msm_gem.
On 2022-08-02 15:55, Shashank Sharma wrote:
> This patch adds:
> - A new input parameter "flags" in the amdgpu_ctx_create2 call.
> - Some new flags defining workload type hints.
> - Some change in the caller function of amdgpu_ctx_create2, to
> accomodate this new parameter.
>
> The idea is to p
On 8/2/2022 5:58 PM, Michel Dänzer wrote:
On 2022-08-02 15:55, Shashank Sharma wrote:
This patch adds:
- A new input parameter "flags" in the amdgpu_ctx_create2 call.
- Some new flags defining workload type hints.
- Some change in the caller function of amdgpu_ctx_create2, to
accomodate this
On 2022-08-02 09:05, Harry Wentland wrote:
On 2022-08-02 08:04, Magali Lemes wrote:
There are two identical CFLAGS entries for "display_mode_vba_20.o", so
remove one of them. Also, as there's already an entry for
"display_mode_lib.o" CFLAGS, regardless of CONFIG_DRM_AMD_DC_DCN being
defined o
On 2022-08-02 09:31, André Almeida wrote:
Às 22:06 de 29/07/22, Magali Lemes escreveu:
As "dcn3_1_soc", "dcn3_15_soc", and "dcn3_16_soc" are not used outside
of their corresponding "dcn3*_fpu.c", make them static and remove their
extern declaration.
Fixes: 26f4712aedbd ("drm/amd/display: m
On 8/2/22 06:31, Hans de Goede wrote:
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
On 7/21/22 16:24, Daniel Dadap wrote:
On 7/12/22 14:38, Hans de Goede wrote:
ATM on x86 laptops where we want userspace to use the acpi_video backlight
device we often register both the GPU's native backlig
On 2022-08-01 09:52, Imre Deak wrote:
Fix compiler warnings like the following triggered by
'-Wmissing-prototypes':
CC [M] drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.o
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:83:31:
warning: no previous proto
On 2022-08-01 09:52, Imre Deak wrote:
Fix the
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:951:13:
error: static declaration of ‘get_min_max_dc_plane_scaling’ follows non-static
declaration
951 | static void get_min_max_dc_plane_scaling(struct drm_device *dev,
Something minor in comments, so conditional R-B (please fix on the way in or
reply to correct me):
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
> From: Alan Previn
>
> Add a helper to get GuC log buffer size.
>
> Signed-off-by: Alan Previn
> Signed-off
Straight forward change - LGTM.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> There was a size check to warn if the GuC error state capture buffer
> allocation would be too small to fit a reasonable amount of capture
>
Hi Sam,
Regarding DRI1 era uAPI, I believe I am handling the matter similar to how
Radeon DRM header (include/uapi/drm/radeon_drm.h) handled the matter.
The header still contains old DRI1 uAPI calls, and it then adds new KMS
generation uAPI calls.
At this point, using drm_invalid_op() for OpenCh
Hi Danilo,
On Tue, Aug 02, 2022 at 02:04:01AM +0200, Danilo Krummrich wrote:
> Quite a lot of drivers include the drm_fb_cma_helper.h header file
> without actually making use of it's provided API, hence remove those
> includes.
>
> Suggested-by: Sam Ravnborg
> Signed-off-by: Danilo Krummrich
Hi Danilo,
On Tue, Aug 02, 2022 at 02:04:00AM +0200, Danilo Krummrich wrote:
> This patch series renames all CMA helpers to DMA helpers - considering the
> hierarchy of APIs (mm/cma -> dma -> gem/fb dma helpers) calling them DMA
> helpers seems to be more applicable.
>
> Additionally, commit e579
One minor NIT (though i hope it could be fixed otw in as it adds a bit of
ease-of-log-readibility).
That said, everything else looks good.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> When debugging GuC communication i
On Tue, Aug 2, 2022 at 12:02 AM Dmitry Baryshkov
wrote:
>
> On 30/07/2022 12:17, Akhil P Oommen wrote:
> >
> > Some clients like adreno gpu driver would like to ensure that its gdsc
> > is collapsed at hardware during a gpu reset sequence. This is because it
> > has a votable gdsc which could be O
One concern below. Else, nice, simple yet good optimization here. :)
In the interest of quicker progression, I will provide a conditional R-B if you
can either fix the issue raised below on
the way in or provide a reason why that's not an issue:
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 1
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Some debug code got left in when the GuC based register save for error
> capture was added. Remove that.
>
> Signed-off-by: John Harrison
> ---
> .../gpu/drm/i915/gt/uc/int
Ever since 68129f431faa ("dma-buf: warn about containers in dma_resv object"),
dma_resv_add_shared_fence will warn if you attempt to add a container fence.
While most drivers were fine, fences can also be added to a dma_resv via the
recently added DMA_BUF_IOCTL_IMPORT_SYNC_FILE. Use dma_fence_unwr
On Wed, 2022-06-15 at 04:28 +, Lin, Wayne wrote:
> [Public]
>
> Thank you Lyude for addressing this!
>
> VCPI is also a confusing naming to me at first glance since it stands for
> Virtual Channel Payload Identification which is just an ID number ( we can
> look up these payload IDs In DPC
On Tue, 2022-07-05 at 08:45 +, Lin, Wayne wrote:
> [Public]
>
>
>
> > -Original Message-
> > From: Lyude Paul
> > Sent: Wednesday, June 8, 2022 3:30 AM
> > To: dri-devel@lists.freedesktop.org; nouv...@lists.freedesktop.org; amd-
> > g...@lists.freedesktop.org
> > Cc: Lin, Wayne ; Vi
On Fri, Jul 29, 2022 at 09:03:54AM +0200, Mauro Carvalho Chehab wrote:
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
And looks like,
1. Rename intel_gt_invalidate_tlb() to intel_gt_invalidate_tlb_full()
2. Ad
On Fri, Jul 29, 2022 at 09:03:55AM +0200, Mauro Carvalho Chehab wrote:
Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the c
The main goal of this series is to make a small dent in cleaning up
the way we deal with regulator loads for DSI drivers.
As of v3 of this series, the regulator API improvements needed for the
later patches in the series are merged into mainline. Thus this series
only contains the DSI changes now.
3 regulators are specified listed but the number 2 is specified. Fix
it.
Fixes: 3a3ff88a0fc1 ("drm/msm/dsi: Add 8x96 info in dsi_cfg")
Signed-off-by: Douglas Anderson
---
(no changes since v2)
Changes in v2:
- ("Fix number of regulators for msm8996_dsi_cfg") new for v2.
drivers/gpu/drm/msm/ds
As of commit 5451781dadf8 ("regulator: core: Only count load for
enabled consumers"), a load isn't counted for a disabled
regulator. That means all the code in the DSI driver to specify and
set loads before disabling a regulator is not actually doing anything
useful. Let's remove it.
It should be
1 regulators is specified listed but the number 2 is specified. This
presumably means we try to get a regulator with no name. Fix it.
Fixes: 033f47f7f121 ("drm/msm/dsi: Add DSI configuration for SDM660")
Signed-off-by: Douglas Anderson
---
(no changes since v2)
Changes in v2:
- ("Fix number of
As of commit 6eabfc018e8d ("regulator: core: Allow specifying an
initial load w/ the bulk API") we can now specify the initial load in
the bulk data rather than having to manually call regulator_set_load()
on each regulator. Let's use it.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Upda
The dsi_phy_driver_probe() function has a "goto fail" for no
reason. Change it to just always return directly when it sees an
error. Make this simpler by leveraging dev_err_probe() which is
designed to make code like this shorter / simpler.
Signed-off-by: Douglas Anderson
---
Changes in v3:
- ("
As of the commit 1de452a0edda ("regulator: core: Allow drivers to
define their init data as const") we no longer need to do copying of
regulator bulk data from initdata to something dynamic. Let's take
advantage of that.
In addition to saving some code, this also moves us to using
ARRAY_SIZE() to
On 8/2/2022 11:48, Teres Alexis, Alan Previn wrote:
One concern below. Else, nice, simple yet good optimization here. :)
In the interest of quicker progression, I will provide a conditional R-B if you
can either fix the issue raised below on
the way in or provide a reason why that's not an issu
On 8/2/2022 11:27, Teres Alexis, Alan Previn wrote:
One minor NIT (though i hope it could be fixed otw in as it adds a bit of
ease-of-log-readibility).
That said, everything else looks good.
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote:
From:
On 8/2/2022 10:37, Teres Alexis, Alan Previn wrote:
Something minor in comments, so conditional R-B (please fix on the way in or
reply to correct me):
Reviewed-by: Alan Previn
On Wed, 2022-07-27 at 19:20 -0700, Harrison, John C wrote:
From: Alan Previn
Add a helper to get GuC log buffer si
Hi Thomas,
I am honestly surprised of the e-mail back and forth regarding the mainlining
of OpenChrome DRM, but let me state my position.
Considering the age of the hardware I am dealing with (i.e., pre-OpenGL 2.x
generation 3D engine), I do not anticipate being able to run OpenChrome on
Waylan
On Tue, Aug 2, 2022 at 8:51 AM Adam Ford wrote:
>
> On Tue, Aug 2, 2022 at 7:13 AM Adam Ford wrote:
> >
> > On Tue, Aug 2, 2022 at 3:08 AM Marco Felsch wrote:
> > >
> > > Hi Adam, Fabio,
> > >
> > > On 22-08-01, Adam Ford wrote:
> > > > On Mon, Aug 1, 2022 at 8:53 PM Fabio Estevam wrote:
> > >
Hi Adam,
sorry for the delay.
On 22-08-02, Adam Ford wrote:
...
> > > I think that the most important one is the blanking calc. Can you try to
> > > revert "drm/bridge: adv7511: Repair bus_flags and bus_format" and check
> > > if you can get a output still? Also something to try would be to dis
On 22-08-02, Adam Ford wrote:
...
> > I did some reading about the internal timing generator. It appears
> > that it's required when video formats use fractional bytes, and it's
> > preconfigured to run at 720p by default, but registers 28h through 37h
> > configure it for other video modes.
>
>
On 30/07/2022 11:17, Akhil P Oommen wrote:
> Add necessary definitions in gpucc bindings to ensure gpu cx gdsc collapse
> through 'reset' framework for SC7280.
>
> Signed-off-by: Akhil P Oommen
> ---
Assuming discussion in cover letter sorts out:
Acked-by: Krzysztof Kozlowski
Best regards,
K
85 matches
Mail list logo
