On Mon, Jun 20, 2022 at 12:54 PM Chen-Yu Tsai wrote:
>
> On Sat, Jun 18, 2022 at 3:29 PM Yunfei Dong wrote:
> >
> > Need to get dec_capability from scp first, then initialize decoder
> > supported format and other parameters according to dec_capability value.
> >
> > Signed-off-by: Yunfei Dong
On Sat, Jun 18, 2022 at 3:29 PM Yunfei Dong wrote:
>
> Need to get dec_capability from scp first, then initialize decoder
> supported format and other parameters according to dec_capability value.
>
> Signed-off-by: Yunfei Dong
Reviewed-by: Chen-Yu Tsai
Tested-by: Chen-Yu Tsai
Tested on
Dear Krzysztof,
Thank you for the valuable command.
Krzysztof Kozlowski 於 2022年6月17日 週五 清晨5:09寫道：
>
> On 13/06/2022 04:11, ChiaEn Wu wrote:
> > From: ChiYuan Huang
> >
> > Add Mediatek mt6370 current sink type LED indicator binding documentation.
> >
> > Signed-off-by: ChiYuan Huang
> > ---
>
On Fri, Jun 17, 2022 at 01:54:05AM -0700, Christoph Hellwig wrote:
> There is a bunch of code an comments in the iommu type1 code that
> suggest we can pin memory that is not page backed.
AFAIK you can.. The whole follow_pte() mechanism allows raw PFNs to be
loaded into the type1 maps and the
On Fri, Jun 17, 2022 at 01:44:30AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 16, 2022 at 04:52:11PM -0700, Nicolin Chen wrote:
> > The pinned PFN list returned from vfio_pin_pages() is simply converted
> > using page_to_pfn() without protection, so direct access via memcpy()
> > will crash on
-20220619
(https://download.01.org/0day-ci/archive/20220619/202206191404.z1x0boih-...@intel.com/config)
compiler: riscv32-linux-gcc (GCC) 11.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
Add #clock-cells property to the HDMI PHY device node to let other nodes
resolve the hdmipll clock. While we are at it, also add the XO clock to
the device node.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2
On MSM8996 the HDMI PHY provides the PLL clock to the MMCC. As we are
preparing to convert the MSM8996 to use DT clocks properties (rather
than global clock names), register the OF clock provider.
While we are at it, also change the driver to use clk_parent_data rather
parent_names to setup a
As the QMP HDMI PHY is a clock provider, add constant #clock-cells
property. For the compatibility with older DTs the property is not
marked as required. Also add the XO clock to the list of the clocks used
by the driver.
Signed-off-by: Dmitry Baryshkov
---
On MSM8996 the HDMI PHY is the QMP PHY, it provides an HDMI PLL clock
used by the MMCC. Add support for providing this clock to the OF
framework by registerding the clock provider and adding #clock-cells
property to the DT node.
Changes since v1:
- Also handle the xo clock (include it into the
Oded Gabbay writes:
> On Fri, Jun 17, 2022 at 8:20 PM Sierra Guiza, Alejandro (Alex)
> wrote:
>>
>>
>> On 6/17/2022 4:40 AM, David Hildenbrand wrote:
>> > On 31.05.22 22:00, Alex Sierra wrote:
>> >> Device memory that is cache coherent from device and CPU point of view.
>> >> This is used on
On Fri, Jun 17, 2022 at 10:27 AM Thomas Zimmermann wrote:
> Could you please try the attached patch? It's similar to your solution,
> but closer to the original intention of the code.
Works fine.
Tested-by: Nuno Gonçalves
Thanks,
Nuno
After adding 3D LUT (and shaper LUT) to DRM CRTC color management
properties, map shaper lut and 3d lut properties to MPC blocks if DC hw
is capable to handle 3dlut after-blending. In this case, the property
only applies to DCN 3 family, as DCN 2 only has 3D support pre-blending
and should be
Add details about color correction capabilities and explain a bit about
differences between DC hw generations and also how they are mapped
between DRM and DC interface. Two schemas for DCN 2.0 and 3.0
(rasterized from the original png) is included to illustrate it. They
were obtained from a
Add 3D LUT for gammar correction using a 3D lookup table. The position
in the color correction pipeline where 3D LUT is applied depends on hw
design, being after CTM or gamma. If just after CTM, a shaper lut must
be set to shape the content for a non-linear space. That details should
be handled
Shaper LUT is used to shape the contect after blending, i.e.,
de-linearize space before applying 3D LUT color correction. In the next
patch, we are adding 3D LUT property to DRM color mgmt.
Signed-off-by: Melissa Wen
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4 +++
AMDGPU DM maps DRM color management properties (degamma, ctm and gamma)
to DC color correction entities. Part of this mapping is already
documented as code comments and can be converted as kernel docs.
Signed-off-by: Melissa Wen
---
.../gpu/amdgpu/display/display-manager.rst| 9 ++
Hi,
I've been working on a proposal to add 3D LUT interface to DRM CRTC
color mgmt, that means new **after-blending** properties for color
correction. As I'm targeting AMD display drivers, I need to map these
new properties to AMD DC interface and I have some doubts about the 3D
LUT programming
On 6/19/22 07:27, Javier Martinez Canillas wrote:
> Hello Randy,
>
> On 6/19/22 00:49, Randy Dunlap wrote:
>>
>> kernel robot reports today:
>>
>> * riscv64-linux-ld: ttm_bo_vm.c:undefined reference to `vmf_insert_pfn_prot'
>>
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
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker
On Thu, Apr 28, 2022 at 11:20 AM Dmitry Osipenko
wrote:
>
> 27.04.2022 18:03, Daniel Vetter wrote:
> >> ...
> @@ -172,6 +172,41 @@ struct drm_gem_object_funcs {
> * This is optional but necessary for mmap support.
> */
> const struct vm_operations_struct
Hi, Oleksandr!
On 09.05.22 16:51, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> With Xen PV Display driver in use the "expected" VM_DONTEXPAND flag
> is not set (neither explicitly nor implicitly), so the driver hits
> the code path in drm_gem_mmap_obj() which triggers the
Den sön 19 juni 2022 kl 00:20 skrev Masahiro Yamada :
> On Wed, Jun 15, 2022 at 5:35 PM Michel Dänzer
> wrote:
> >
> > On 2022-04-14 18:57, Michel Dänzer wrote:
> > > On 2022-04-14 17:04, Masahiro Yamada wrote:
> > >> On Thu, Apr 14, 2022 at 10:50 PM Michel Dänzer
> > >> wrote:
> > >>> On
Hello Hans,
On 6/19/22 16:57, Hans de Goede wrote:
> Hi,
>
> On 6/19/22 13:46, Javier Martinez Canillas wrote:
>> Hello Maya,
>>
>> On 6/19/22 13:19, Maccraft123 wrote:
>>> From: Maya Matuszczyk
>>>
>>> The device is identified by "NEXT" in board name, however there are
>>> different versions
https://bugzilla.kernel.org/show_bug.cgi?id=172421
Matt Weiland (matt.weil...@gmx.at) changed:
What|Removed |Added
CC||matt.weil...@gmx.at
chive/20220619/202206192329.jxlymohn-...@intel.com/config)
compiler: mips-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/inte
https://bugzilla.kernel.org/show_bug.cgi?id=172421
--- Comment #22 from Elmar Stellnberger (estel...@elstel.org) ---
The patch was not accepted because someone claimed it could damage the
hardware. All lies. As years have gone by these graphics cards are still under
daily use with this UHD
Hi,
On 6/19/22 13:46, Javier Martinez Canillas wrote:
> Hello Maya,
>
> On 6/19/22 13:19, Maccraft123 wrote:
>> From: Maya Matuszczyk
>>
>> The device is identified by "NEXT" in board name, however there are
>> different versions of it, "Next Advance" and "Next Pro", that have
>> different DMI
Hello Randy,
On 6/19/22 00:49, Randy Dunlap wrote:
>
> kernel robot reports today:
>
> * riscv64-linux-ld: ttm_bo_vm.c:undefined reference to `vmf_insert_pfn_prot'
> https://lore.kernel.org/lkml/202206190651.smtms3ay-...@intel.com/T/#u
>
> * ttm_bo_vm.c:undefined reference to
On 6/19/22 16:05, Javier Martinez Canillas wrote:
> Hello Randy,
>
> On 5/31/22 04:55, Randy Dunlap wrote:
>> Prevent a kconfig warning when MMU is not enabled by making
>> DRM_HISI_HIBMC depend on MMU.
>>
>> WARNING: unmet direct dependencies detected for DRM_TTM
>> Depends on [n]: HAS_IOMEM
Hello Randy,
On 5/31/22 04:55, Randy Dunlap wrote:
> Prevent a kconfig warning when MMU is not enabled by making
> DRM_HISI_HIBMC depend on MMU.
>
> WARNING: unmet direct dependencies detected for DRM_TTM
> Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
> Selected by [m]:
> -
Hello Maya,
On 6/19/22 13:19, Maccraft123 wrote:
> From: Maya Matuszczyk
>
> The device is identified by "NEXT" in board name, however there are
> different versions of it, "Next Advance" and "Next Pro", that have
> different DMI board names.
> Due to a production error a batch or two have
From: Maya Matuszczyk
The device is identified by "NEXT" in board name, however there are
different versions of it, "Next Advance" and "Next Pro", that have
different DMI board names.
Due to a production error a batch or two have their board names prefixed
by "AYANEO", this makes it 6 different
On Sat, Jun 18, 2022 at 11:18:17PM -0700, Christoph Hellwig wrote:
> > > There is a bunch of code an comments in the iommu type1 code that
> > > suggest we can pin memory that is not page backed.
> >
> > Would you mind explaining the use case for pinning memory that
> > isn't page backed? And
35 matches
Mail list logo
