On Mon, Jun 20, 2022 at 3:33 AM Alistair Popple wrote:
>
>
> 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 i
Hi Jonathan,
Thanks for your helpful comments, and I have some questions want to
ask you below.
Jonathan Cameron 於 2022年6月18日 週六 晚上11:39寫道：
>
> On Mon, 13 Jun 2022 19:11:38 +0800
> ChiaEn Wu wrote:
>
> > From: ChiaEn Wu
> >
> > Add ABI documentation for mt6370 non-standard ADC sysfs interfaces
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 MT818
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 pi
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 S
onfig-s031-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/
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 deletions(-
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 link
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
---
.../devicetree/bindings/phy/qcom,hdmi-
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 dts
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 p
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 expos
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 discuss
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 by
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 +++
drivers/gpu/drm/drm_ato
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 ++
.../gpu
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
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'
>> https://lore.kernel.org/lkml/202206190651.smtms3ay-...@intel.com/T
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 driv
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 *vm
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 WARNING.
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 2022-0
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 of
https://bugzilla.kernel.org/show_bug.cgi?id=172421
Matt Weiland (matt.weil...@gmx.at) changed:
What|Removed |Added
CC||matt.weil...@gmx.at
0day-ci/archive/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://githu
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 patch
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 b
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 `vmf_insert_pfn_
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]:
> - DRM_TT
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 their
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 D
36 matches
Mail list logo
