Hi Anitha,
On Tue, Oct 19, 2021 at 04:07:19PM -0700, Anitha Chrisanthus wrote:
> Enable support for fbcon (framebuffer console).
>
> v2: added missing static clk_enable
> v3: removed module parameter, use fbdev_emulation instead. Use
> preferred depth of 24 for color depth. (Thomas Z.)
>
>
Hi Anitha,
On Tue, Oct 19, 2021 at 04:07:18PM -0700, Anitha Chrisanthus wrote:
> On KMB, ADV bridge must be programmed and powered on prior to
> MIPI DSI HW initialization.
>
> v2: changed to atomic_bridge_chain_enable (Sam)
>
> Fixes: 98521f4d4b4c ("drm/kmb: Mipi DSI part of the display
On Tue, Oct 19, 2021 at 09:32:07AM +0100, Tvrtko Ursulin wrote:
On 18/10/2021 19:35, Umesh Nerlige Ramappa wrote:
On Mon, Oct 18, 2021 at 08:58:01AM +0100, Tvrtko Ursulin wrote:
On 16/10/2021 00:47, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time
Quoting Krishna Manikandan (2021-10-18 22:30:28)
> In the current implementation, substring comparison
> using device node name is used to find mdp node
> during driver probe. Use compatible string list instead
> of node name to get mdp node from the parent mdss node.
>
> Signed-off-by: Krishna
On Tue, Oct 19, 2021 at 9:00 PM Brian Norris wrote:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html gives
> HTTP 404, and https://drm.pages.freedesktop.org/maintainer-tools/
> redirects to freedesktop.org now.
>
> Let's save people the pain of figuring that out.
>
Nice
https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html gives
HTTP 404, and https://drm.pages.freedesktop.org/maintainer-tools/
redirects to freedesktop.org now.
Let's save people the pain of figuring that out.
Signed-off-by: Brian Norris
---
MAINTAINERS | 2 +-
1 file changed, 1
Hey Dan,
On 10/1/2021 6:50 AM, Dan Carpenter wrote:
On Fri, Oct 01, 2021 at 04:49:12PM +0300, Dan Carpenter wrote:
Hello Jeykumar Sankaran,
This is a semi-automatic email about new static checker warnings.
The patch 25fdd5933e4c: "drm/msm: Add SDM845 DPU support" from Jun
27, 2018, leads to
On 2021-10-06 13:48, Dmitry Baryshkov wrote:
There is no reason to set clock parents manually, use device tree to
assign DSI/display clock parents to DSI PHY clocks. Dropping this
manual
setup allows us to drop repeating code and to move registration of hw
clock providers to generic place.
On 2021-10-06 13:48, Dmitry Baryshkov wrote:
Move DPHY/CPHY setting from msm_dsi_host_set_src_pll() to new function
msm_dsi_host_set_phy_mode().
Signed-off-by: Dmitry Baryshkov
Just a minor comment, can you also include the part which removes
msm_host->cphy_mode = src_phy->cphy_mode; from
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And vmf_insert_pfn_pmd_prot() unconditionally sets
entry =
Enable support for fbcon (framebuffer console).
v2: added missing static clk_enable
v3: removed module parameter, use fbdev_emulation instead. Use
preferred depth of 24 for color depth. (Thomas Z.)
Signed-off-by: Anitha Chrisanthus
---
drivers/gpu/drm/kmb/kmb_drv.c | 4
1 file changed, 4
On KMB, ADV bridge must be programmed and powered on prior to
MIPI DSI HW initialization.
v2: changed to atomic_bridge_chain_enable (Sam)
Fixes: 98521f4d4b4c ("drm/kmb: Mipi DSI part of the display driver")
Co-developed-by: Edmund Dea
Signed-off-by: Anitha Chrisanthus
---
Remove drm_mm references and add DRM buddy
functions
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 233 +++
2 files changed, 138 insertions(+), 99 deletions(-)
diff --git
Remove i915 buddy references and add DRM buddy
functions
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/i915_module.c| 3 -
drivers/gpu/drm/i915/i915_scatterlist.c | 11 +--
Move vram defines and inline functions into
a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 18 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 72
2 files changed, 73 insertions(+), 17 deletions(-)
create mode 100644
- Add res cursor support for drm buddy
- Replace if..else statement with switch case statement
Signed-off-by: Arunpravin
---
.../gpu/drm/amd/amdgpu/amdgpu_res_cursor.h| 97 +++
1 file changed, 78 insertions(+), 19 deletions(-)
diff --git
i915 buddy selftests will be moved to drm selftest folder,
hence the config condition check may be removed.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index
Export functions and write kerneldoc description
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 89 ++---
1 file changed, 83 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
On contiguous allocation, we round up the size
to the nearest power of 2, implement a function
to free unused pages.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 87 +
include/drm/drm_buddy.h | 4 ++
2 files changed, 91 insertions(+)
diff
This function becomes obsolete and may be removed.
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 101
include/drm/drm_buddy.h | 4 --
2 files changed, 105 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands.
- Implemented a new function alloc_range() which allocates
the requested order (in bytes) comply with range limitations
- Moved memory alignment logic from i915 driver
Signed-off-by:
- Include drm buddy to DRM root Makefile
- Add drm buddy init and exit function calls
to drm core
Signed-off-by: Arunpravin
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_drv.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Makefile
- Move i915_buddy.c to drm root folder
- Rename "i915" string with "drm" string wherever applicable
- Rename "I915" string with "DRM" string wherever applicable
- Fix header file dependencies
- Fix alignment issues
Signed-off-by: Arunpravin
---
.../drm/{i915/i915_buddy.c => drm_buddy.c}|
- Move i915_buddy.h to include/drm
- rename "i915" string to "drm"
- rename "I915" string to "DRM"
Signed-off-by: Arunpravin
---
drivers/gpu/drm/i915/i915_buddy.h | 143 --
include/drm/drm_buddy.h | 143 ++
2 files changed, 143
This series of patches implemented to move i915 buddy allocator
to drm root, and introduce new features include
- make drm_buddy_alloc a prime vehicle for allocation
- TOPDOWN range of address allocation support
- a function to free unused pages on contiguous allocation
- a function to allocate
drm_get_edid() internally calls to drm_connector_update_edid_property()
and then drm_add_display_info(), which parses the EDID.
This happens in the function intel_hdmi_set_edid() and
intel_sdvo_tmds_sink_detect() (via intel_sdvo_get_edid()).
Once EDID is parsed, the monitor HDMI support
According to the documentation, drm_add_edid_modes
"... Also fills out the _display_info structure and ELD in @connector
with any information which can be derived from the edid."
drm_add_edid_modes accepts a struct edid *edid parameter which may have a
value or may be null. When it is not null,
Add CRC support to DPU, which is currently not supported by
this driver. Only supports CRC for CRTC for now, but will extend support
to other blocks later on.
Changes in v2:
- Added kfree() calls for return paths in dpu_crtc_get_crc()
- Propogated error code for dpu_crtc_get_crc()
- Renamed
On Tue, Oct 19, 2021 at 09:35:08PM +0300, Ville Syrjälä wrote:
> On Sat, Oct 16, 2021 at 08:42:14PM +0200, Claudio Suarez wrote:
> > According to the documentation, drm_add_edid_modes
> > "... Also fills out the _display_info structure and ELD in @connector
> > with any information which can be
Define the memory region on RK3399 VOPs containing the gamma LUT at
base+0x2000.
Signed-off-by: Hugh Cole-Baker
---
Changes from v1: no changes in this patch
arch/arm64/boot/dts/rockchip/rk3399.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The RK3399 has a 1024-entry gamma LUT with 10 bits per component on its
"big" VOP and a 256-entry, 8 bit per component LUT on the "little" VOP.
Compared to the RK3288, it no longer requires disabling gamma while
updating the LUT. On the RK3399, the LUT can be updated at any time as
the hardware
The VOP on RK3399 has a different approach from previous versions for
setting a gamma lookup table, using an update_gamma_lut register. As
this differs from RK3288, give RK3399 its own set of "common" register
definitions.
Signed-off-by: Hugh Cole-Baker
---
Changes from v1: no changes in this
This extends the Rockchip VOP driver to support setting the gamma LUT on the
RK3399 SoC. Previously, the driver supported gamma control for the RK3288
only. On the RK3399 the method for updating the LUT is slightly different.
This implementation was based on the code and description from the
On Thu, Oct 07, 2021 at 10:19:30AM +0200, AngeloGioacchino Del Regno wrote:
> Convert the Parade PS8622 eDP/DP to LVDS bridge documentation to YAML.
>
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
> .../display/bridge/parade,ps8622.yaml | 102 ++
>
On Tue, Oct 19, 2021 at 05:37:27PM +0200, Christian König wrote:
>
>
> Am 19.10.21 um 14:41 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
> > > From: Guangming Cao
> > >
> > > Since there is no mandatory inspection for attachments in
Hi Pekka,
On 10/19/21 5:05 AM, Pekka Paalanen wrote:
On Mon, 18 Oct 2021 16:26:06 -0300
Igor Matheus Andrade Torrente wrote:
Hi Pekka,
On 10/18/21 5:30 AM, Pekka Paalanen wrote:
On Tue, 5 Oct 2021 17:16:37 -0300
Igor Matheus Andrade Torrente wrote:
Currently the blend function only
19.10.2021 12:47, Robert Foss пишет:
> Applied to drm-misc-next
>
> On Sun, 3 Oct 2021 at 01:35, Dmitry Osipenko wrote:
>>
>> This series adds couple improvements to the TC358768 DSI bridge driver,
>> enabling Panasonic VVX10F004B00 DSI panel support. This panel is used by
>> ASUS Transformer
Applied. thanks!
On Fri, Oct 15, 2021 at 2:48 AM Qing Wang wrote:
>
> show() must not use snprintf() when formatting the value to be
> returned to user space.
>
> Fix the following coccicheck warning:
> drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:427:
> WARNING: use scnprintf or sprintf.
>
>
> > >
> > > That will not help validating that new DTs are compliant with the last
> > > version of the bindings.
> > >
> > > We have one tool, and two needs. The tool should be extended to cover
> > > both, but today it can only support one. Which of these two is the most
> > > important:
> > >
On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
>
> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> > On 10/19/21 00:06, Jason Gunthorpe wrote:
> > > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> > >
> > >>> device-dax uses PUD, along with TTM, they are
From: Arnd Bergmann
The check_reserve_boundaries() function has a large array on the stack,
over 500 bytes. It gets inlined into __igt_reserve, which has multiple
other large structures as well but stayed just under the stack size
warning limit of 1024 bytes until one more member got added to
Hi Thomas,
On 10/19/21 4:17 AM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 21:32 schrieb Igor Matheus Andrade Torrente:
Hi Thomas,
On 10/18/21 3:06 PM, Thomas Zimmermann wrote:
Hi
Am 18.10.21 um 19:41 schrieb Igor Matheus Andrade Torrente:
Hello,
On 10/18/21 7:14 AM, Thomas Zimmermann
On 10/19/21 20:52, Jason Gunthorpe wrote:
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
Hi,
On 10/19/21 20:21, Jason Gunthorpe wrote:
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
On Tue, Oct 19, 2021 at 08:49:29PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/19/21 20:21, Jason Gunthorpe wrote:
> > PUD and PMD entries do not have a special bit.
> >
> > get_user_pages_fast() considers any page that passed pmd_huge() as
> > usable:
> >
> > if
Hi,
On 10/19/21 20:21, Jason Gunthorpe wrote:
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And
On Sat, Oct 16, 2021 at 08:42:26PM +0200, Claudio Suarez wrote:
> Once EDID is parsed, the monitor HDMI support information is available
> through drm_display_info.is_hdmi. Retriving the same information with
> drm_detect_hdmi_monitor() is less efficient. Change to
> drm_display_info.is_hdmi where
On Sat, Oct 16, 2021 at 08:42:14PM +0200, Claudio Suarez wrote:
> According to the documentation, drm_add_edid_modes
> "... Also fills out the _display_info structure and ELD in @connector
> with any information which can be derived from the edid."
>
> drm_add_edid_modes accepts a struct edid
PUD and PMD entries do not have a special bit.
get_user_pages_fast() considers any page that passed pmd_huge() as
usable:
if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) ||
pmd_devmap(pmd))) {
And vmf_insert_pfn_pmd_prot() unconditionally sets
On Tue, Oct 05, 2021 at 10:40:18PM -0400, Lyude Paul wrote:
> Hooray! We've managed to hit enough bugs upstream that I've been able to
> come up with a pretty solid explanation for how backlight controls are
> actually supposed to be detected and used these days. As well, having the
> rest of the
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
Driver never uses virtual address of DRM CMA buffers. Switch to CMA
helpers which don't deal with virtual mapping.
This was actually already the case before commit ad408c766cef
("drm/sun4i: Use DRM_GEM_CMA_VMAP_DRIVER_OPS for GEM operations"),
but only convenient macro at the time used helpers
On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> This simply adds proper support for panel backlights that can be controlled
> via VESA's backlight control protocol, but which also require that we
> enable and disable the backlight via PWM instead of via the DPCD interface.
> We also
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission
Hey Dan,
On 10/1/2021 6:59 AM, Dan Carpenter wrote:
Hello Abhinav Kumar,
The patch d11a93690df7: "drm/msm/dp: add debugfs support to DP
driver" from Sep 12, 2020, leads to the following
Smatch static checker warning:
drivers/gpu/drm/msm/dp/dp_debug.c:194 dp_debug_read_info()
On 10/19/21 00:06, Jason Gunthorpe wrote:
> On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
>
>>> device-dax uses PUD, along with TTM, they are the only places. I'm not
>>> sure TTM is a real place though.
>>
>> I was setting device-dax aside because it can use Joao's changes to
>>
Hi, Nancy:
Nancy.Lin 於 2021年10月4日 週一 下午2:21寫道：
>
> Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
> the ovl_adaptor component.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/Makefile | 3 +-
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
>
Am 2021-10-19 um 7:36 a.m. schrieb Christian König:
> Am 13.10.21 um 16:07 schrieb Daniel Vetter:
>> On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
>>> Simplifying the code a bit.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14
On 19-10-21, 18:52, Dmitry Baryshkov wrote:
> On Tue, 19 Oct 2021 at 18:30, Vinod Koul wrote:
> >
> > On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> > > On 07/10/2021 10:08, Vinod Koul wrote:
> >
> > > > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > > > + struct
Drop the local intel_dp_phy_name() function, and replace with
drm_dp_phy_name(). This lets us drop a number of local buffers.
v2: Rebase
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä # v1
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_dp_link_training.c | 83 ---
1
Add a helper for getting the DP PHY name. In the interest of caller
simplicity and to avoid allocations and passing in of buffers, duplicate
the const strings to return. It's a minor penalty to pay for simplicity
in all the call sites.
Cc: Ville Syrjälä
Reviewed-by: Ville Syrjälä
Signed-off-by:
On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> On 10/19/21 00:06, Jason Gunthorpe wrote:
> > On Mon, Oct 18, 2021 at 12:37:30PM -0700, Dan Williams wrote:
> >
> >>> device-dax uses PUD, along with TTM, they are the only places. I'm not
> >>> sure TTM is a real place though.
> >>
On Tue, 19 Oct 2021 at 18:30, Vinod Koul wrote:
>
> On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> > On 07/10/2021 10:08, Vinod Koul wrote:
>
> > > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > > + struct dpu_global_state *global_state,
> > > +
Am 19.10.21 um 16:30 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
Am 13.10.21 um 16:23 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
On Thu, 14 Oct 2021, Jani Nikula wrote:
> Use the new link training delay helpers, fixing the delays for
> 128b/132b.
>
> For existing 8b/10b functionality, this will cause additional 1-byte
> DPCD reads for LTTPR delays instead of using the cached values. It's
> just too complicated to combine
Am 19.10.21 um 14:41 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
From: Guangming Cao
Since there is no mandatory inspection for attachments in dma_buf_release.
There will be a case that dma_buf already released but attachment is still
On Tue, 19 Oct 2021, Maxime Ripard wrote:
> On Tue, Oct 19, 2021 at 12:59:57PM +0300, Jani Nikula wrote:
>>
>> Hi all -
>>
>> These are the drm dp helpers for figuring out link training delays, to
>> be pulled to both drm-misc-next and drm-intel-next.
>>
>>
>>
On 14-10-21, 17:11, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > +static int _dpu_rm_reserve_dsc(struct dpu_rm *rm,
> > + struct dpu_global_state *global_state,
> > + struct drm_encoder *enc)
> > +{
> > + struct
On 10/19/21 8:49 AM, Laurent Pinchart wrote:
Hi Marek,
Hi,
diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index 1faae3e323a4..708de84ac138 100644
---
On Tue, Oct 19, 2021 at 03:02:26PM +0200, Christian König wrote:
> Am 13.10.21 um 16:23 schrieb Daniel Vetter:
> > On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
> > > Makes the handling a bit more complex, but avoids the use of
> > > dma_resv_get_excl_unlocked().
> > >
> > >
Fixes screen orientation for the Aya Neo 2021 handheld gaming console.
Signed-off-by: Bryant Mairs
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
On 14-10-21, 17:40, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > +static void dpu_hw_dsc_config(struct dpu_hw_dsc *hw_dsc,
> > + struct msm_display_dsc_config *dsc, u32 mode)
> > +{
> > + struct dpu_hw_blk_reg_map *c = _dsc->hw;
> > + u32 data,
On Mon, Oct 18, 2021 at 08:47:30AM +, Simon Ser wrote:
> If an hotplug event only updates a single connector, use
> drm_kms_helper_connector_hotplug_event instead of
> drm_kms_helper_hotplug_event.
>
> Changes in v4:
> - Simplify loop logic (Ville, Sam)
> - Update
Am 24.06.21 um 11:55 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective rockchip functions are being removed. The file_operations
structure fops is now being created by the helper
On Tue, Oct 19, 2021 at 02:54:04PM +0200, Christian König wrote:
> Am 13.10.21 um 16:21 schrieb Daniel Vetter:
> > On Tue, Oct 05, 2021 at 01:37:37PM +0200, Christian König wrote:
> > > Simplifying the code a bit.
> > >
> > > v2: add missing rcu_read_lock()/unlock()
> > > v3: switch to locked
On Tue, Oct 19, 2021 at 12:59:57PM +0300, Jani Nikula wrote:
>
> Hi all -
>
> These are the drm dp helpers for figuring out link training delays, to
> be pulled to both drm-misc-next and drm-intel-next.
>
>
> topic/drm-dp-training-delay-helpers-2021-10-19:
> Core Changes:
> - drm dp helpers
On Dienstag, 19. Oktober 2021 15:06:31 CEST Christian König wrote:
>
> Am 19.10.21 um 14:35 schrieb Daniel Vetter:
> > On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
> >> Trivial fix since we now need to grab a reference to the fence we have
> >> added. Previously the dma_resv
On 2021-10-19 14:24:29 [+0200], Daniel Vetter wrote:
>
> Ah dmesg help me understand what's going on. Does the below patch help? If
> it's this one that would also explain why intel CI hasn't hit it - it's a
> leak between tests and we run them all individually instead of once at
> boot-up.
Yes,
Am 19.10.21 um 14:35 schrieb Daniel Vetter:
On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
Trivial fix since we now need to grab a reference to the fence we have
added. Previously the dma_resv function where doing that for us.
Signed-off-by: Christian König
Fixes:
Am 13.10.21 um 16:23 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:38PM +0200, Christian König wrote:
Makes the handling a bit more complex, but avoids the use of
dma_resv_get_excl_unlocked().
v2: improve coding and documentation
Signed-off-by: Christian König
---
Am 13.10.21 um 16:21 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:37PM +0200, Christian König wrote:
Simplifying the code a bit.
v2: add missing rcu_read_lock()/unlock()
v3: switch to locked version
Signed-off-by: Christian König
Reviewed-by: Tvrtko Ursulin
Please make sure you
On Dienstag, 19. Oktober 2021 13:27:06 CEST Christian König wrote:
> Trivial fix since we now need to grab a reference to the fence we have
> added. Previously the dma_resv function where doing that for us.
>
> Signed-off-by: Christian König
> Fixes: 9c2ba265352a drm/scheduler: ("use new
On Tue, Oct 19, 2021 at 08:23:45PM +0800, guangming@mediatek.com wrote:
> From: Guangming Cao
>
> Since there is no mandatory inspection for attachments in dma_buf_release.
> There will be a case that dma_buf already released but attachment is still
> in use, which can points to the dmabuf,
It was <2021-10-18 pon 21:13>, when Andrzej Hajda wrote:
> Beside updating email, the patch updates maintainers
> of Samsung drivers.
>
> Signed-off-by: Andrzej Hajda
> ---
> .mailmap| 1 +
> MAINTAINERS | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git
On Mon, 18 Oct 2021, Maxime Ripard wrote:
> Hi Jani,
>
> On Fri, Oct 15, 2021 at 06:21:35PM +0300, Jani Nikula wrote:
>> On Thu, 14 Oct 2021, Jani Nikula wrote:
>> > The link training delays are different and/or available in different
>> > DPCD offsets depending on:
>> >
>> > - Clock recovery
On Tue, Oct 19, 2021 at 01:27:06PM +0200, Christian König wrote:
> Trivial fix since we now need to grab a reference to the fence we have
> added. Previously the dma_resv function where doing that for us.
>
> Signed-off-by: Christian König
> Fixes: 9c2ba265352a drm/scheduler: ("use new iterator
On Tue, Oct 19, 2021 at 10:09:42AM +0200, Thomas Zimmermann wrote:
> Gma500 currently removes generic fbdev drivers, but ignores
> generic DRM drivers. Use aperture helpers to remove all generic
> graphics drivers before loading gma500. Makes gma500 compatible
> with simpledrm.
>
> Signed-off-by:
On Thu, Oct 14, 2021 at 03:47:31PM +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-14 15:21:22 [+0200], Daniel Vetter wrote:
> > On Wed, Oct 13, 2021 at 07:35:48PM +0200, Sebastian Andrzej Siewior wrote:
> > > c7fcbf2513973 -> does not boot
> > > c7fcbf2513973 + 2f425cf5242a0 -> boots, 18 x
From: Guangming Cao
Since there is no mandatory inspection for attachments in dma_buf_release.
There will be a case that dma_buf already released but attachment is still
in use, which can points to the dmabuf, and it maybe cause
some unexpected issues.
With IOMMU, when this cases occurs, there
On Mon, 18 Oct 2021, Jani Nikula wrote:
> From: Stephen Rothwell
>
> Commit cd06ab2fd48f ("drm/locking: add backtrace for locking contended
> locks without backoff") added functions named __stack_depot_* in drm
> which conflict with stack depot. Rename to __drm_stack_depot_*.
>
> v2 by Jani:
> -
On Sun, Oct 17, 2021 at 10:05 PM Marek Vasut wrote:
>
> On 10/17/21 7:52 PM, Sam Ravnborg wrote:
> > Hi Marek,
> >
> > On Wed, Sep 08, 2021 at 08:24:20PM +0200, Daniel Vetter wrote:
> >> On Tue, Sep 07, 2021 at 04:49:00AM +0200, Marek Vasut wrote:
> >>> The mxsfb->crtc.funcs may already be NULL
Hi Maxime,
Thank you for the patch.
On Wed, Sep 29, 2021 at 10:42:28AM +0200, Maxime Ripard wrote:
> of_graph_get_port_by_id doesn't modify the device_node pointer it takes
> as argument, so we can make it const.
>From a C point of view that's right, but conceptually speaking, is it
right to
Am 13.10.21 um 16:14 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:28PM +0200, Christian König wrote:
Simplifying the code a bit. Also drop the RCU read side lock since the
object is locked anyway.
Untested since I can't get the driver to compile on !ARM.
Cross-compiler install is
On Sun, 17 Oct 2021 at 10:38, Dmitry Osipenko wrote:
>
> 01.10.2021 18:01, Ulf Hansson пишет:
> > On Fri, 1 Oct 2021 at 16:35, Dmitry Osipenko wrote:
> >>
> >> 01.10.2021 17:24, Ulf Hansson пишет:
> >>> On Mon, 27 Sept 2021 at 00:42, Dmitry Osipenko wrote:
>
> The NAND on Tegra
Am 13.10.21 um 16:07 schrieb Daniel Vetter:
On Tue, Oct 05, 2021 at 01:37:26PM +0200, Christian König wrote:
Simplifying the code a bit.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff
Trivial fix since we now need to grab a reference to the fence we have
added. Previously the dma_resv function where doing that for us.
Signed-off-by: Christian König
Fixes: 9c2ba265352a drm/scheduler: ("use new iterator in
drm_sched_job_add_implicit_dependencies v2")
---
From: chongjiapeng
This symbol is not used outside of panel-novatek-nt35950.c, so marks it
static.
Fixes the following sparse warning:
drivers/gpu/drm/panel/panel-novatek-nt35950.c:671:33: warning: symbol
'sharp_ls055d1sx04' was not declared. Should it be static?
Reported-by: Abaci Robot
Hi Maxime,
On Tue, Oct 19, 2021 at 09:37:28AM +0200, Maxime Ripard wrote:
> On Mon, Oct 18, 2021 at 08:48:52PM +0300, Laurent Pinchart wrote:
> > On Mon, Oct 18, 2021 at 05:20:13PM +0200, Maxime Ripard wrote:
> > > On Sat, Oct 16, 2021 at 05:34:59AM +0300, Laurent Pinchart wrote:
> > > > On Thu,
1 - 100 of 127 matches
Mail list logo
