tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 1c6c4f42b3de4f18ea96d62950d0e266ca35a055 Add linux-next specific
files for 20220929
Error/Warning reports:
https://lore.kernel.org/linux-mm/202209150141.wgbakqmx-...@intel.com
https
clean up one inconsistent indenting
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2321
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/dcn301/dcn301_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
clean up one inconsistent indenting
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2238
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/gpu/drm/amd/display/dc/dcn321/dcn321_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
ce->wa_bb_page is allocated only for graphics version 12. However
__gen125_emit_bb_start() is used for any graphics version >= 12.50. For
the currently supported platforms this is not an issue, but for future
ones there's a mismatch causing the jump to
`wa_offset + DG2_PREDICATE_RESULT_BB` to be
Some small improvements to future-proof the initialization around the
register state context.
Lucas De Marchi (3):
drm/i915: Fix __gen125_emit_bb_start() without WA
drm/i915/gt: Document function to decode register state context
drm/i915/gt: Fix platform prefix
It's no obviously clear how the encode/decode of the per platform tables
is done. Document it so while adding tables for new platforms people can
be confident they right things is being done.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 24
1
Different handling for XeHP and later platforms should be using the
xehp prefix, not gen125. Rename them.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 24 +--
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 12 +-
Hi Niranjana,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm/drm-next
drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.0-rc7
next-20220927]
[If your patch is applied to the wrong git
This chip can not handle aux defer if the host directly program
its aux registers to access edid/dpcd. So we need let software
to handle the aux defer situation.
Signed-off-by: Jason Yen
---
Changes in v2:
- Add aux defer handler
- Remove incorrect statements
From: Andrey Grodzovsky
When many entities are competing for the same run queue
on the same scheduler, we observe an unusually long wait
times and some jobs get starved. This has been observed on GPUVis.
The issue is due to the Round Robin policy used by schedulers
to pick up the next entity's
Hi Laurent,
On Thu, 2022-09-29 at 23:42 +0300, Laurent Pinchart wrote:
> From: Kieran Bingham
>
> The LCDIF includes a color space converter that supports YUV input. Use
> it to support YUV planes, either through the converter if the output
> format is RGB, or in conversion bypass mode
Add mediatek av1 decoder linux driver which use the stateless API in
MT8195.
Signed-off-by: Xiaoyong Lu
---
Changes from v3:
- modify comment for struct vdec_av1_slice_slot
- add define SEG_LVL_ALT_Q
- change use_lr/use_chroma_lr parse from av1 spec
- use ARRAY_SIZE to replace size for
[AMD Official Use Only - General]
Hi Christian
This looks on kernel revision 5.15, currently, the Zork use 5.4
Google also comment that kernel 5.15 fix the issue.
I'm not sure the kernel have rev plan to 5.15 or not
We will discuss this on 10/3.
Do you suggest that use kernel 5.15 and
> From: Alex Williamson
> Sent: Friday, September 30, 2022 2:24 AM
>
> On Thu, 29 Sep 2022 14:49:56 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > > Hi Kevin,
> > >
> > > This introduced the regression discovered here:
> > >
> > >
>
Alistair Popple wrote:
>
> Dan Williams writes:
>
> > Alistair Popple wrote:
> >>
> >> Jason Gunthorpe writes:
> >>
> >> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> >> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
> >> >> refcount") device
Hi,
On 2022/9/30 4:38, Rob Clark wrote:
On Thu, Sep 29, 2022 at 4:51 AM Akhil P Oommen wrote:
On 9/29/2022 3:00 PM, Yang Yingliang wrote:
I got the compile error:
drivers/gpu/drm/msm/msm_gem_shrinker.c: In function ‘can_block’:
drivers/gpu/drm/msm/msm_gem_shrinker.c:29:21: error:
> From: Jason Gunthorpe
> Sent: Friday, September 30, 2022 1:49 AM
>
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
>
> This was missed for gvt, add
On 9/12/2022 12:25 PM, Dmitry Baryshkov wrote:
On 12/09/2022 22:21, Kuogee Hsieh wrote:
On 9/12/2022 11:39 AM, Dmitry Baryshkov wrote:
On 12/09/2022 19:23, Kuogee Hsieh wrote:
DOWNSPREAD_CTRL (0x107) shall be cleared to 0 upon power-on reset or an
upstream device disconnect. This patch
在 2022/9/30 5:08, Doug Anderson 写道:
Hi,
On Wed, Sep 28, 2022 at 6:57 PM Yuan Can wrote:
In the probe path, dev_err() can be replaced with dev_err_probe()
which will check if error code is -EPROBE_DEFER and prints the
error name. It also sets the defer probe reason which can be
checked later
Dan Williams writes:
> Alistair Popple wrote:
>>
>> Jason Gunthorpe writes:
>>
>> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
>> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
>> >> refcount") device private pages have no longer had an extra
Hi Linus,
Last set of fixes for 6.0 hopefully, minor bridge fixes, i915 fixes,
and a bunch of amdgpu fixes for new IP blocks, along with a couple of
regression fixes. Hopefully all set for merge window next week.
Dave.
drm-fixes-2022-09-30-1:
drm fixes for 6.0 final
amdgpu:
- GC 11.x fixes
-
On Wed, Sep 28, 2022 at 08:55:11AM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state on MTL are nearly similar to DG2 (and PVC).
The difference being PRT_BB_STATE being replaced with NOP.
Hello Michael,
Thank you for the patch. Sorry for the late reply, I wasn't on the CC
list so I didn't notice it.
On Fri, Aug 26, 2022 at 11:11:21AM +0200, Michael Rodin wrote:
> "detect" should not be called and its return value shall not be used when a
> connector is forced as hinted in the
On Fri, Sep 30, 2022 at 12:34:41AM +0200, Andrzej Hajda wrote:
> On 22.09.2022 21:51, Nathan Chancellor wrote:
> > When booting with clang's kernel control flow integrity series [1],
> > there are numerous violations when accessing the files under
> >
On Mon, Aug 08, 2022, Maxim Levitsky wrote:
> Hi Sean, Paolo, and everyone else who wants to review my nested AVIC work.
Before we dive deep into design details, I think we should first decide whether
or not nested AVIC is worth pursing/supporting.
- Rome has a ucode/silicon bug with no known
On 22.09.2022 21:51, Nathan Chancellor wrote:
When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
On Tue, Sep 27, 2022 at 07:12:06PM -0300, Maíra Canal wrote:
> The drm_test_dp_mst_sideband_msg_req_decode repeats the same test
> structure with different parameters. This could be better represented
> by parameterized tests, provided by KUnit.
>
> In order to convert the tests to parameterized
On Tue, 27 Sep 2022 01:45:01 +0200, Marek Vasut wrote:
> Handle 'data-lanes' property of the DSI output endpoint, it is possible
> to describe DSI link with 1 or 2 data lanes this way.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Alexandre Torgue
> Cc: Krzysztof Kozlowski
> Cc: Maxime Coquelin
On Mon, 26 Sep 2022 14:14:27 -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for the NewVision NV3051D panel bindings.
> Note that for the two expected consumers of this panel binding
> the underlying LCD model is unknown. Name "anbernic,rg353p-panel"
> is used because the
On Mon, 26 Sep 2022 11:43:32 -0500, Chris Morgan wrote:
> From: Chris Morgan
>
> Add documentation for the Samsung AMS495QA01 panel.
>
> Signed-off-by: Chris Morgan
> Signed-off-by: Maya Matuszczyk
> ---
> .../display/panel/samsung,ams495qa01.yaml | 56 +++
> 1 file
Hi,
On Wed, Sep 28, 2022 at 6:57 PM Yuan Can wrote:
>
> In the probe path, dev_err() can be replaced with dev_err_probe()
> which will check if error code is -EPROBE_DEFER and prints the
> error name. It also sets the defer probe reason which can be
> checked later through debugfs.
>
>
Hi,
On Wed, Sep 28, 2022 at 6:56 PM Yuan Can wrote:
>
> In the probe path, dev_err() can be replaced with dev_err_probe()
> which will check if error code is -EPROBE_DEFER and prints the
> error name. It also sets the defer probe reason which can be
> checked later through debugfs.
>
>
On Thu, Sep 29, 2022 at 05:16:58PM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and HAS_LMEM()
> returns false. However the platform's stolen memory is presented via
> BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX)
> and should be
Up to and including v1.3, HDMI supported limited quantization range only
for YCbCr. HDMI v1.4 introduced selectable quantization ranges, but this
feature isn't supported in the dw-hdmi driver that is used in
conjunction with the LCDIF in the i.MX8MP. The HDMI YCbCr output is thus
always advertised
The BIT() macro is meant to represent a single bit. Don't use it for
values of register fields that span multiple bits.
Signed-off-by: Laurent Pinchart
Reviewed-by: Marek Vasut
Reviewed-by: Kieran Bingham
Reviewed-by: Liu Ying
---
Changes since v1:
- Use hex for field values
---
From: Kieran Bingham
The LCDIF includes a color space converter that supports YUV input. Use
it to support YUV planes, either through the converter if the output
format is RGB, or in conversion bypass mode otherwise.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Reviewed-by:
A couple of the register macro values are incorrectly indented. Fix
them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Marek Vasut
Reviewed-by: Kieran Bingham
Reviewed-by: Liu Ying
---
drivers/gpu/drm/mxsfb/lcdif_regs.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Hello,
This small patch series improves YUV support in the i.MX8MP LCDIF
driver. After patches 1/4 and 2/4 that fix tiny cosmetic issues, patch
3/4 fixes YUV quantization range for the RGB to YUV conversion. Patch
4/4 addresses the other direction and adds support for YUV planes.
Please see
On Thu, Sep 29, 2022 at 4:51 AM Akhil P Oommen wrote:
>
> On 9/29/2022 3:00 PM, Yang Yingliang wrote:
> > I got the compile error:
> >
> >drivers/gpu/drm/msm/msm_gem_shrinker.c: In function ‘can_block’:
> >drivers/gpu/drm/msm/msm_gem_shrinker.c:29:21: error: ‘__GFP_ATOMIC’
> > undeclared
Hi Liu,
On Thu, Sep 29, 2022 at 05:53:37PM +0800, Liu Ying wrote:
> On Wed, 2022-09-28 at 03:58 +0300, Laurent Pinchart wrote:
> > From: Kieran Bingham
> >
> > The LCDIF includes a color space converter that supports YUV input. Use
> > it to support YUV planes, either through the converter if
Alistair Popple wrote:
>
> Jason Gunthorpe writes:
>
> > On Mon, Sep 26, 2022 at 04:03:06PM +1000, Alistair Popple wrote:
> >> Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
> >> refcount") device private pages have no longer had an extra reference
> >> count when the page is
On Sat, 24 Sep 2022 15:36:11 +0300, Dmitry Baryshkov wrote:
> Add DPU and MDSS schemas to describe MDSS and DPU blocks on the Qualcomm
> SM8250 platform.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/mdss-common.yaml | 4 +-
>
On Sat, 24 Sep 2022 15:36:10 +0300, Dmitry Baryshkov wrote:
> Add missing device nodes (DSI, PHYs, DP/eDP) to the existing MDSS
> schemas.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../display/msm/qcom,msm8998-mdss.yaml| 153 +
> .../display/msm/qcom,qcm2290-mdss.yaml|
On Sat, 24 Sep 2022 15:36:09 +0300, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-qcm2290 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/dpu-qcm2290.yaml |
On Fri, Sep 23, 2022 at 3:41 PM Rob Clark wrote:
>
> From: Rob Clark
>
> The introduction of 025d27239a2f exposes a problem with f371bcc0c2ac, in
> that we need to keep the object pinned in the time the submit is queued
> up in the gpu scheduler. Otherwise the shrinker will see it as a thing
>
On Sat, 24 Sep 2022 15:36:08 +0300, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-msm8998 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../display/msm/qcom,msm8998-dpu.yaml |
On Sat, 24 Sep 2022 15:36:07 +0300, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-sdm845 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/dpu-sdm845.yaml |
On Sat, 24 Sep 2022 15:36:06 +0300, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-sc7280 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/dpu-sc7280.yaml |
On Sat, 24 Sep 2022 15:36:05 +0300, Dmitry Baryshkov wrote:
> In order to make the schema more readable, split dpu-sc7180 into the DPU
> and MDSS parts, each one describing just a single device binding.
>
> Signed-off-by: Dmitry Baryshkov
> ---
> .../bindings/display/msm/dpu-sc7180.yaml |
On Sat, 24 Sep 2022 15:36:04 +0300, Dmitry Baryshkov wrote:
> Move properties common to all MDSS DT nodes to the mdss-common.yaml.
>
> This extends qcom,msm8998-mdss schema to allow interconnect nodes, which
> will be added later, once msm8998 gains interconnect support.
>
> Signed-off-by:
On Sat, 24 Sep 2022 15:36:03 +0300, Dmitry Baryshkov wrote:
> Move properties common to all DPU DT nodes to the dpu-common.yaml.
>
> Note, this removes description of individual DPU port@ nodes. However
> such definitions add no additional value. The reg values do not
> correspond to hardware
On 2022-09-28 08:01, Alistair Popple wrote:
Since 27674ef6c73f ("mm: remove the extra ZONE_DEVICE struct page
refcount") device private pages have no longer had an extra reference
count when the page is in use. However before handing them back to the
owning device driver we add an extra
On 2022-09-29 09:21, Christian König wrote:
This was buggy because when we had to wait for entities which were
killed as well we would just deadlock.
Instead move all the dependency handling into the callbacks so that
will all happen asynchronously.
Signed-off-by: Christian König
---
Inlined:
On 2022-09-29 14:46, Luben Tuikov wrote:
> From: Andrey Grodzovsky
>
> When many entities are competing for the same run queue
> on the same scheduler, we observe an unusually long wait
> times and some jobs get starved. This has been observed on GPUVis.
>
> The issue is due to the
On Thu, Sep 29, 2022 at 04:07:14PM +0200, Thomas Zimmermann wrote:
> In drm_atomic_helper_check_crtc_state(), do not add a new plane state
> to the global state if it does not exist already. Adding a new plane
> state will results in overhead for the plane during the atomic-commit
> step.
>
> For
From: Andrey Grodzovsky
When many entities are competing for the same run queue
on the same scheduler, we observe an unusually long wait
times and some jobs get starved. This has been observed on GPUVis.
The issue is due to the Round Robin policy used by schedulers
to pick up the next entity's
amdgpu_dm_commit_planes() already sets the flip_immediate flag for
async page-flips. This flag is used to set the UNP_FLIP_CONTROL
register. Thus, no additional change is required to handle async
page-flips with the atomic uAPI.
v2: make it clear this commit is about DC and not only DCN
Up until now, amdgpu was silently degrading to vsync when
user-space requested an async flip but the hardware didn't support
it.
The hardware doesn't support immediate flips when the update changes
the FB pitch, the DCC state, the rotation, enables or disables CRTCs
or planes, etc. This is
This new kernel capability indicates whether async page-flips are
supported via the atomic uAPI. DRM clients can use it to check
for support before feeding DRM_MODE_PAGE_FLIP_ASYNC to the kernel.
Make it clear that DRM_CAP_ASYNC_PAGE_FLIP is for legacy uAPI only.
Signed-off-by: Simon Ser
This new field indicates whether the driver has the necessary logic
to support async page-flips via the atomic uAPI. This is leveraged by
the next commit to allow user-space to use this functionality.
All atomic drivers setting drm_mode_config.async_page_flip are updated
to also set
If the driver supports it, allow user-space to supply the
DRM_MODE_PAGE_FLIP_ASYNC flag to request an async page-flip.
Set drm_crtc_state.async_flip accordingly.
Document that drivers will reject atomic commits if an async
flip isn't possible. This allows user-space to fall back to
something
This is a subset of [1], included here because a subsequent patch
needs to document the behavior of this flag under the atomic uAPI.
v2: new patch
[1]: https://patchwork.freedesktop.org/patch/500177/
Signed-off-by: Simon Ser
Reviewed-by: André Almeida
Reviewed-by: Alex Deucher
---
This series adds support for DRM_MODE_PAGE_FLIP_ASYNC for atomic
commits, aka. "immediate flip" (which might result in tearing).
The feature was only available via the legacy uAPI, however for
gaming use-cases it may be desirable to enable it via the atomic
uAPI too.
- Patchwork:
Series is Reviewed-by: Andrey Grodzovsky
Andrey
On 2022-09-29 14:01, Christian König wrote:
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.
Signed-off-by: Christian König
---
Am 29.09.22 um 20:30 schrieb Yadav, Arvind:
On 9/29/2022 11:48 PM, Christian König wrote:
Am 27.09.22 um 19:24 schrieb Arvind Yadav:
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled_locked() function ever returns true.
Since drivers and implementations sometimes
On 2022-09-28 08:01, Alistair Popple wrote:
When the CPU tries to access a device private page the migrate_to_ram()
callback associated with the pgmap for the page is called. However no
reference is taken on the faulting page. Therefore a concurrent
migration of the device private page can free
On 9/29/2022 11:48 PM, Christian König wrote:
Am 27.09.22 um 19:24 schrieb Arvind Yadav:
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled_locked() function ever returns true.
Since drivers and implementations sometimes mess this up,
this ensures correct behaviour
On Thu, 29 Sep 2022 14:49:56 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > Hi Kevin,
> >
> > This introduced the regression discovered here:
> >
> > https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
> >
> >
On Thu, Sep 29, 2022 at 8:11 PM Simon Ser wrote:
>
> On Wednesday, September 28th, 2022 at 12:06, Pekka Paalanen
> wrote:
>
> > > +/**
> > > + * DRM_MODE_PAGE_FLIP_FLAGS
> > > + *
> > > + * Bitmask of flags suitable for _mode_crtc_page_flip_target.flags.
> >
> > Should this mention also
Am 27.09.22 um 19:24 schrieb Arvind Yadav:
Fence signaling must be enabled to make sure that
the dma_fence_is_signaled_locked() function ever returns true.
Since drivers and implementations sometimes mess this up,
this ensures correct behaviour when DMABUF_DEBUG_ENABLE_SIGNALING
is used during
Am 27.09.22 um 19:24 schrieb Arvind Yadav:
Here's enabling software signaling on fence for sw_sync.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
---
drivers/dma-buf/sw_sync.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma-buf/sw_sync.c
Am 27.09.22 um 19:24 schrieb Arvind Yadav:
Remove the extra signaled bit status check because
it is returning early when the fence is already signaled and
__dma_fence_enable_signaling is checking the status of signaled
bit again.
Signed-off-by: Arvind Yadav
Reviewed-by: Christian König
On Wednesday, September 28th, 2022 at 12:06, Pekka Paalanen
wrote:
> > +/**
> > + * DRM_MODE_PAGE_FLIP_FLAGS
> > + *
> > + * Bitmask of flags suitable for _mode_crtc_page_flip_target.flags.
>
> Should this mention also drm_mode_crtc_page_flip.flags?
>
> UAPI header defines both structs.
If it is supposed to be a non-linear luminance curve, which one is it?
It would be much clearer if user space can control linear luminance
and use whatever definition of perceived brightness it wants. The
obvious downside of it is that it requires bits to encode changes that
users can't perceive.
Otherwise we would crash if the job is not resubmitted.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
The JDI LPM102A188A is a 2560x1800 IPS panel found in the Google Pixel C.
This driver is based on the downstream GPLv2 driver released by Google
written by Sean Paul [1], which was then adapted to the newer kernel APIs.
[1]:
The Google Pixel C has a JDI LPM102A188A display panel. Add a
DT node for it. Tested on Pixel C.
Signed-off-by: Diogo Ivo
---
arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
The LPM102A188A is a 10.2" 2560x1800 IPS panel found in
the Google Pixel C.
Signed-off-by: Diogo Ivo
---
.../display/panel/jdi,lpm102a188a.yaml| 100 ++
1 file changed, 100 insertions(+)
create mode 100644
Hello!
These patches add support for the JDI LPM102A188A display panel,
found in the Google Pixel C.
Patch 1 adds the DT bindings for the panel.
Patch 2 adds an optional register clear to the Tegra DSI driver.
Patch 3 adds the panel driver, which is based on the downstream
kernel driver
In cases where the DSI module is left on by the bootloader
some panels may fail to initialize if the enable register is not cleared
before the panel's initialization sequence. Clear it and add an optional
device tree property to inform the driver if this is the case.
Signed-off-by: Diogo Ivo
---
On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> Hi Kevin,
>
> This introduced the regression discovered here:
>
> https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
>
> Seems we're not releasing the resources when removing an mdev. This is
> a
On Thu, Sep 29, 2022 at 06:28:39PM +0100, Matthew Auld wrote:
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
When converting to directly create the vfio_device the mdev driver has to
put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
vfio_unregister_group_dev() in the remove.
This was missed for gvt, add it.
Cc: sta...@vger.kernel.org
Fixes: 978cf586ac35 ("drm/i915/gvt: convert to
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
Am 29.09.22 um 17:31 schrieb Steven Price:
On 29/09/2022 15:57, Christian König wrote:
Am 29.09.22 um 16:53 schrieb Steven Price:
On 14/09/2022 17:43, Arvind Yadav wrote:
Using the parent fence instead of the finished fence
to get the job status. This change is to avoid GPU
scheduler timeout
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing.
Hi Kevin,
This introduced the regression discovered here:
https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
Seems we're not releasing the resources when removing an mdev. This is
a regression, so it needs to be fixed or reverted before the merge
window. Thanks,
On Thu, Sep 29, 2022 at 06:46:34PM +0200, Andi Shyti wrote:
> Hi Nathan,
>
> thanks for this refactoring... looks good even though i would
> have split it in more patches as this is doing quite many things.
Right, sorry about that :/ I initially thought the problem was much
simpler and the diff
Hi Nathan,
thanks for this refactoring... looks good even though i would
have split it in more patches as this is doing quite many things.
But I will not be stubborn, I understand that it's not trivial to
have things split. I will give my r-b for now but I will check it
again before applying it
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be
On 9/29/22 09:14, Rob Clark wrote:
> From: Rob Clark
>
> 9178e3dcb121 ("mm: discard __GFP_ATOMIC") removed __GFP_ATOMIC,
> replacing it with a check for not __GFP_DIRECT_RECLAIM.
>
> Reported-by: Randy Dunlap
> Reported-by: Stephen Rothwell
> Signed-off-by: Rob Clark
Acked-by: Randy
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by:
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 148 ++-
drivers/gpu/drm/vc4/vc4_vec.c| 5 +-
2 files changed, 54
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though,
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
1 - 100 of 213 matches
Mail list logo
