On 7/4/23 11:36, Yangtao Li wrote:
Use devm_platform_ioremap_resource() to simplify code.
Signed-off-by: Yangtao Li
applied.
Thanks!
Helge
---
drivers/video/fbdev/imxfb.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/imxfb.c b/drivers/vid
On Thu, Jul 06, 2023 at 12:42:17PM +0200, Thomas Zimmermann wrote:
> The sm750fb driver does not need anything from .
> Remove the include statements.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Javier Martinez Canillas
> Cc: Sudip Mukherjee
> Cc: Teddy Wang
> ---
> drivers/staging/sm
Hi all,
On Thu, Jul 06, 2023 at 02:25:16PM -0700, Doug Anderson wrote:
> Hi,
>
> On Tue, Jul 4, 2023 at 12:47 AM Linus Walleij
> wrote:
> >
> > On Thu, Jun 1, 2023 at 5:55 PM Doug Anderson wrote:
> > > On Thu, May 25, 2023 at 2:32 AM Cong Yang
> > > wrote:
> > > >
> > > > The Starry-ili9882 is
The pull request you sent on Fri, 7 Jul 2023 11:14:46 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-07-07
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5133c9e51de41bfa902153888e11add3342ede18
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-o
On 07/07/2023 02:35, Konrad Dybcio wrote:
On 6.07.2023 23:10, Rob Clark wrote:
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
[...
On 7/7/23 05:53, Dmitry Osipenko wrote:
> On 7/7/23 05:49, Dmitry Osipenko wrote:
>> On 6/28/23 18:58, Gurchetan Singh wrote:
>>> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
>>> virtio_gpu_submit *submit,
>>>
>>> memset(submit, 0, sizeof(*submit));
>>>
>>> - out_fence =
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This simplifies the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 25 ++
On 7/7/23 05:49, Dmitry Osipenko wrote:
> On 6/28/23 18:58, Gurchetan Singh wrote:
>> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
>> virtio_gpu_submit *submit,
>>
>> memset(submit, 0, sizeof(*submit));
>>
>> -out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adre
On 6/28/23 18:58, Gurchetan Singh wrote:
> @@ -168,9 +168,13 @@ static int virtio_gpu_init_submit(struct
> virtio_gpu_submit *submit,
>
> memset(submit, 0, sizeof(*submit));
>
> - out_fence = virtio_gpu_fence_alloc(vgdev, fence_ctx, ring_idx);
> - if (!out_fence)
> -
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c |
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
I have the feeling that we are trying to circumvent the way DT works.
I'd suggest ad
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Would it be better to push this to DT? I mean, we already have a
'
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1
On 7/6/2023 7:19 PM, Dmitry Baryshkov wrote:
On 07/07/2023 03:16, Abhinav Kumar wrote:
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/dr
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm
On 07/07/2023 03:16, Abhinav Kumar wrote:
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change
Hi,
> -Original Message-
> From: Thomas Zimmermann
> Sent: Thursday, July 6, 2023 9:47 PM
> To: javi...@redhat.com; maarten.lankho...@linux.intel.com;
> mrip...@kernel.org
> Cc: dri-devel@lists.freedesktop.org; linux-arm-ker...@lists.infradead.org;
> linux-samsung-...@vger.kernel.org; lin
Hi,
On Fri, Jul 7, 2023 at 3:32 AM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 3, 2023 at 10:07 PM Cong Yang
> wrote:
> >
> > From power on/off sequence for panel data sheet[1], T2 timing VSP to VSN
> > needs 1ms delay when power on, and VSN to VSP also needs 1ms delay when
> > power off. Some
Hi Linus,
Lots of fixes, mostly i915 and amdgpu. It's 2 weeks of i915, and I
think 3 weeks of amdgpu.
Dave.
drm-next-2023-07-07:
drm fixes for 6.5-rc1
fbdev:
- Fix module infos on sparc
panel:
- Fix mode on Starry-ili9882t
i915:
- Allow DC states along with PW2 only for PWB functionality [adl
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> There are cases where there are differences due to SoC integration.
> Such as cache-coherency support, and (in the next patch) e-fuse to
> speedbin mappings.
>
> Signed-off-by: Rob Clark
> ---
of_machine_is_compatible is rather used in
> @@ -27,15 +28,8 @@ static bool gpu_write_needs_clflush(struct
> drm_i915_gem_object *obj)
> if (IS_DGFX(i915))
> return false;
> - /*
> -* For objects created by userspace through GEM_CREATE with
> pat_index
> -* set b
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Since the revision becomes an opaque identifier with future GPUs, move
> away from treating different ranges of bits as having a given meaning.
> This means that we need to explicitly list different patch revisions in
> the device table.
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/d
On 7/6/2023 5:07 PM, Dmitry Baryshkov wrote:
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the ca
On 06/07/2023 23:48, Ryan McCann wrote:
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: R
On 07/07/2023 00:10, Rob Clark wrote:
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +---
drivers/gpu/drm/msm/
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> This is used in a few places, including one that is parsed by userspace
> tools. So let's standardize it a bit better.
>
> Signed-off-by: Rob Clark
> ---
Userspace parsed this weird string instead of the hex-based chipid?
weird^2
Kon
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Sometimes it is useful to know the sub-generation (or "family"). And in
> any case, this helps us get away from infering the generation from the
> numerical chip-id.
>
> Signed-off-by: Rob Clark
> ---
[...]
> .rev = AD
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> All of these are derivatives of a630.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
> 2 files changed, 5
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> It is better to explicitly list it. With the move to opaque chip-id's
> for future devices, we should avoid trying to infer things like
> generation from the numerical value.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybci
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Rather than just open coding a list of gpu-id matches.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
Konrad
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
> drivers/gpu/drm/msm/adreno/adreno_device.c | 4
>
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> This just duplicates what is in adreno_info, and can cause confusion if
> used before it is set.
>
> Signed-off-by: Rob Clark
> ---
[...]
> - return gpu->revn == revn;
> + if (WARN_ON_ONCE(!gpu->info))
> + return fa
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> Even in the ocmem case, the allocated ocmem buffer size should match the
> requested size.
>
> Signed-off-by: Rob Clark
> ---
[...]
> +
> + WARN_ON(ocmem_hdl->len != adreno_gpu->info->gmem);
I believe this should be an error condit
On 6.07.2023 23:10, Rob Clark wrote:
> From: Rob Clark
>
> No real need to have marketing names in the kernel.
>
> Signed-off-by: Rob Clark
> ---
Reviewed-by: Konrad Dybcio
[...]
> - gpu_name = adreno_gpu->info->name;
> - if (!gpu_name) {
> - gpu_name = devm_kasprintf(dev
On Thu, Jul 6, 2023 at 11:58 PM Doug Anderson wrote:
> > So the Ilitek ILI9882t is an obvious break-out.
>
> I guess. To me it feels like the concept of breaking the driver into
> multiple sub-drivers and the idea of supporting ILI9882t more cleanly
> are orthogonal. You could still do your patch
Hi,
On Thu, Jul 6, 2023 at 2:36 PM Linus Walleij wrote:
>
> On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson wrote:
>
> > In my mind it's really a tradeoff and I'm happy to go with whatever
> > consensus that others agree with. What I'm never super happy with,
> > though, is changing the bikeshed c
On Thu, Jul 6, 2023 at 11:25 PM Doug Anderson wrote:
> In my mind it's really a tradeoff and I'm happy to go with whatever
> consensus that others agree with. What I'm never super happy with,
> though, is changing the bikeshed color too often, so I'd be really
> curious to hear Sam's thoughts on
On Thu, Jul 6, 2023 at 9:26 PM Doug Anderson wrote:
> Presumably if we wait a few days things will sort themselves out. If
> something needs to happen sooner then we'll have to get the drm-misc
> maintainers involved. Probably at this point it makes sense to wait?
Yeah there is certainly no hurr
Hi,
On Tue, Jul 4, 2023 at 12:47 AM Linus Walleij wrote:
>
> On Thu, Jun 1, 2023 at 5:55 PM Doug Anderson wrote:
> > On Thu, May 25, 2023 at 2:32 AM Cong Yang
> > wrote:
> > >
> > > The Starry-ili9882 is a 10.51" WUXGA TFT panel. which fits in nicely with
> > > the existing panel-boe-tv101wum-n
Hi,
On Mon, Jul 3, 2023 at 6:22 AM Linus Walleij wrote:
>
> The ILI9882t has similarities with other Ilitek panels, such
> as the characteristic internal page switching code that uses
> the model number (0x98, 0x82) as parameter.
>
> We can clearly abstract out the page switching sequence from
>
Hi,
On Mon, Jul 3, 2023 at 6:22 AM Linus Walleij wrote:
>
> The Starry ILI9882t-based panel should never have been part of the boe
> tv101wum driver, it is clearly based on the Ilitek ILI9882t display
> controller and if you look at the custom command sequences for the
> panel these clearly conta
Hi,
On Mon, Jul 3, 2023 at 6:22 AM Linus Walleij wrote:
>
> The DRM panel core already keeps track of if the panel is already
> prepared so do not reimplement this.
>
> Reviewed-by: Sam Ravnborg
> Signed-off-by: Linus Walleij
> ---
> drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 12
Hi,
On Mon, Jul 3, 2023 at 6:22 AM Linus Walleij wrote:
>
> The boe-tv101wum-nl6 is reinventing the mechanism to send command
> sequences that we usually nix during review, but I missed this one
> so fixing it up myself.
Sorry for this. :( I know I've reviewed/applied several of the patches
that
From: Rob Clark
Since the revision becomes an opaque identifier with future GPUs, move
away from treating different ranges of bits as having a given meaning.
This means that we need to explicitly list different patch revisions in
the device table.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/m
From: Rob Clark
Sometimes it is useful to know the sub-generation (or "family"). And in
any case, this helps us get away from infering the generation from the
numerical chip-id.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 31 ++-
drivers/gpu/drm/msm/a
From: Rob Clark
This is used in a few places, including one that is parsed by userspace
tools. So let's standardize it a bit better.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 8 +++-
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 19 ---
driv
From: Rob Clark
Upcoming GPUs use an opaque chip-id for identifying the GPU.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation/dev
From: Rob Clark
All of these are derivatives of a630.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/driver
From: Rob Clark
There are cases where there are differences due to SoC integration.
Such as cache-coherency support, and (in the next patch) e-fuse to
speedbin mappings.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 34 +++---
drivers/gpu/drm/msm/adr
From: Rob Clark
This simplifies the code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 171 ++---
drivers/gpu/drm/msm/adreno/adreno_device.c | 51 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 25 +++
3 files changed, 92 insertions(+), 155 d
From: Rob Clark
It is better to explicitly list it. With the move to opaque chip-id's
for future devices, we should avoid trying to infer things like
generation from the numerical value.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 23 +++---
drive
From: Rob Clark
Rather than just open coding a list of gpu-id matches.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 +
3 files changed, 6 insertions(+), 2 del
From: Rob Clark
This just duplicates what is in adreno_info, and can cause confusion if
used before it is set.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 1 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 22 +---
From: Rob Clark
Even in the ocmem case, the allocated ocmem buffer size should match the
requested size.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers
From: Rob Clark
No real need to have marketing names in the kernel.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 24 --
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 13 +---
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 1 -
3 files chan
From: Rob Clark
Downstream seems to be moving to using the chip_id as simply an opaque
identifier, and if we want to avoid headaches with userspace mesa
supporting both kgsl and upstream, we should move away from the
assumption that certain bits in the chip_id have a specific meaning.
Patches 6
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 fil
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Reviewed-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Ryan McCann
---
drivers/gpu/d
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +
The purpose of this patch series is to add support to print the registers
of sub-blocks in the DPU hardware catalog and fix the order in which all
hardware blocks are dumped for a device core dump. This involves:
1. Changing data structure from stack to queue to fix the printing order
of the devic
Currently, the device core dump mechanism does not dump registers of
sub-blocks within the DSPP, SSPP, DSC, and PINGPONG blocks. Edit
dpu_kms_mdp_snapshot function to account for sub-blocks.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +
The purpose of this patch series is to add support to print the registers
of sub-blocks in the DPU hardware catalog and fix the order in which all
hardware blocks are dumped for a device core dump. This involves:
1. Changing data structure from stack to queue to fix the printing order
of the devic
Drop unused parameter "num" from VIG_SBLK_NOSCALE and DMA sub-block
macros. Update calls to relevant macros to reflect change.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/
For a device core dump, the registers of sub-blocks are printed under a
title formatted as . For example, the csc sub-block
for an SSPP main block "sspp_0" would be printed "sspp_0_sspp_csc0". The
title is clearly redundant due to the duplicate "sspp" and "0" that exist
in both the mainBlkName and
Device core dump add block method adds hardware blocks to dumping queue
with stack behavior which causes the hardware blocks to be printed in
reverse order. Change the addition to dumping queue data structure
from "list_add" to "list_add_tail" for FIFO queue behavior.
Fixes: 98659487b845 ("drm/msm
Some sub-blocks in the hw catalog have not been given a name, so when the
registers from that block are dumped, there is no name to reference.
Define names for relevant sub-blocks to fix this.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 20 ++--
Currently, the names of main blocks are hardcoded into the
msm_disp_snapshot_add_block function rather than using the name that
already exists in the catalog. Change this to take the name directly from
the catalog instead of hardcoding it.
Signed-off-by: Ryan McCann
---
drivers/gpu/drm/msm/disp/
Hi,
On Mon, Jul 3, 2023 at 10:07 PM Cong Yang
wrote:
>
> From power on/off sequence for panel data sheet[1], T2 timing VSP to VSN
> needs 1ms delay when power on, and VSN to VSP also needs 1ms delay when
> power off. Some pmic may not be able to adjust the delay internally, so
> let's add a delay
Hi,
On Tue, Jul 4, 2023 at 12:39 AM Linus Walleij wrote:
>
> On Fri, Jun 30, 2023 at 2:42 AM Doug Anderson wrote:
>
> > ...this means that it lands in drm-misc-next-fixes, so I've pushed it there.
> >
> > 59bba51ec2a5 drm/panel: Fine tune Starry-ili9882t panel HFP and HBP
>
> I guess that means
On 7/6/23 17:08, Thomas Zimmermann wrote:
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that
is required for deferred I/O on system-memory framebuffers. Select
it from FB_BROADSHEET in favor of the existing identical selection.
Signed-off-by: Thomas Zimmermann
I'm actually not
> As context structure is shared memory for CPU/GPU, Wa_22016122933 is
> needed for this memory block as well.
>
> Signed-off-by: Zhanjun Dong
> CC: Fei Yang
Reviewed-by: Fei Yang
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> d
On 10/03/2023 00:20, Jordan Crouse wrote:
While booting with amd,imageon on a headless target the GPU probe was
failing with -ENOSPC in get_pages() from msm_gem.c.
Investigation showed that the driver was using the default 16MB VRAM
carveout because msm_use_mmu() was returning false since headle
On Fri, 30 Jun 2023 00:25:18 +0200
Danilo Krummrich wrote:
> +#ifdef CONFIG_LOCKDEP
> +typedef struct lockdep_map *lockdep_map_p;
> +#define drm_gpuva_manager_ext_assert_held(mgr) \
> + lockdep_assert(lock_is_held((mgr)->ext_lock) != LOCK_STATE_NOT_HELD)
> +/**
> + * drm_gpuva_m
As context structure is shared memory for CPU/GPU, Wa_22016122933 is
needed for this memory block as well.
Signed-off-by: Zhanjun Dong
CC: Fei Yang
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_l
Hi Thomas,
On Thu, Jul 06, 2023 at 05:08:43PM +0200, Thomas Zimmermann wrote:
> Generate the I/O callbacks for drivers with deferred I/O. As in
> the old, opencoded functions, the generated functions operate on
> system memory and trigger damage handling if necessary. Also bring
> the drivers' Kco
On Thu, Jul 06, 2023 at 05:08:51PM +0200, Thomas Zimmermann wrote:
> Use the existing generator macros to create deferred-I/O helpers
> for ssd1307fb and set them in the fb_ops structure. Functions
> for damage handling on memory ranges and areas are provided by
> the driver.
>
> Ssd1307fb's imple
On 7/6/23 17:48, Danilo Krummrich wrote:
Hi Thomas,
On 7/6/23 10:49, Thomas Hellström (Intel) wrote:
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager impl
On 06/07/2023 13:31, Jocelyn Falempe wrote:
On 06/07/2023 12:26, Thomas Zimmermann wrote:
Hi
Am 06.07.23 um 11:16 schrieb Jocelyn Falempe:
On 04/07/2023 18:45, Jocelyn Falempe wrote:
On 04/07/2023 16:54, Jani Nikula wrote:
On Fri, 23 Jun 2023, Jocelyn Falempe wrote:
Since commit fae7d186403
On 7/6/23 01:01, Pekka Paalanen wrote:
On Wed, 5 Jul 2023 09:08:07 -0700
Michael Banack wrote:
On 7/4/23 01:08, Pekka Paalanen wrote:
On Mon, 3 Jul 2023 14:06:56 -0700
Michael Banack wrote:
Hi, I can speak to the virtual mouse/console half of this from the
VMware-side.
I believe Zack
On Thu, 6 Jul 2023 17:06:08 +0200
Danilo Krummrich wrote:
> Hi Boris,
>
> On 6/30/23 10:02, Boris Brezillon wrote:
> > Hi Danilo,
> >
> > On Fri, 30 Jun 2023 00:25:18 +0200
> > Danilo Krummrich wrote:
> >
> >> + *int driver_gpuva_remap(struct drm_gpuva_op *op, void *__ctx)
> >> + *
Hi Donald,
On 7/6/23 17:45, Donald Robson wrote:
On Fri, 2023-06-30 at 00:25 +0200, Danilo Krummrich wrote:
+#ifdef CONFIG_LOCKDEP
+typedef struct lockdep_map *lockdep_map_p;
+#define drm_gpuva_manager_ext_assert_held(mgr) \
+ lockdep_assert(lock_is_held((mgr)->ext_lock) != LOCK_
Hi Thomas,
On 7/6/23 10:49, Thomas Hellström (Intel) wrote:
Hi, Danilo
Some review comments below:
On 6/30/23 00:25, Danilo Krummrich wrote:
Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.
New UAPIs, motivated by Vulkan
On 05/07/2023 01:09, Yang, Fei wrote:
>>> From: Tvrtko Ursulin
>>>
>>> Informal commit message for now.
>>>
>>> I got a bit impatient and curious to see if the idea we discussed would
>>> work so sketched something out. I think it is what I was describing
back
>>> then..
>>>
>>> So
On Fri, 2023-06-30 at 00:25 +0200, Danilo Krummrich wrote:
>
> +#ifdef CONFIG_LOCKDEP
> +typedef struct lockdep_map *lockdep_map_p;
> +#define drm_gpuva_manager_ext_assert_held(mgr) \
> + lockdep_assert(lock_is_held((mgr)->ext_lock) != LOCK_STATE_NOT_HELD)
> +/**
> + * drm_gpuva_
As of commit 6c80a93be62d398e ("drm/fb-helper: Initialize fb-helper's
preferred BPP in prepare function"), the preferred_bpp parameter of
drm_fb_helper_prepare() defaults to 32 instead of
drm_mode_config.preferred_depth. Hence this also applies to
drm_fbdev_dma_setup(), which just passes its own p
On 7/6/23 17:18, Paulo Pavacic wrote:
Hello Linus,
čet, 22. lip 2023. u 10:22 Linus Walleij napisao je:
On Wed, Jun 21, 2023 at 5:09 PM Paulo Pavacic wrote:
A lot of modifications to st7701 are required. I believe it would
result in a driver that doesn't look or work the same. e.g compare
Hello Linus,
čet, 22. lip 2023. u 10:22 Linus Walleij napisao je:
>
> On Wed, Jun 21, 2023 at 5:09 PM Paulo Pavacic wrote:
>
> > A lot of modifications to st7701 are required. I believe it would
> > result in a driver that doesn't look or work the same. e.g compare
> > delays between initializat
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that
is required for deferred I/O on system-memory framebuffers. Select
it from XEN_FBDEV_FRONTEND in favor of the existing identical selection.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 6 +-
1 file change
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that
is required for deferred I/O on system-memory framebuffers. Select
it from FB_BROADSHEET in favor of the existing identical selection.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 6 +-
1 file changed, 1
Use the existing generator macros to create deferred-I/O helpers
for xen-fbfront and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Xen-fbfront's implementation of fb_write writes to system memory,
so the generated code can us
Use the existing generator macros to create deferred-I/O helpers
for metronomefb and set them in the fb_ops structure. Functions
for damage handling on memory ranges and areas are provided by
the driver.
Metronomefb's implementation of fb_write writes to system memory,
so the generated code can us
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that
is required for deferred I/O on system-memory framebuffers. Select
it from FB_HECUBA.
Deferred I/O helpers were previously selected by n411, which builds
upon hecubafb. Remove these select statements in favor of the new one.
N411 do
The Kconfig token FB_SYS_HELPERS_DEFERRED selects everything that
is required for deferred I/O on system-memory framebuffers. Select
it from FB_SSD1307 in favor of the existing identical selection.
Signed-off-by: Thomas Zimmermann
---
drivers/video/fbdev/Kconfig | 6 +-
1 file changed, 1 ins
1 - 100 of 194 matches
Mail list logo
