On Sun, Jan 28, 2024 at 07:34:23PM +, David Laight wrote:
> These are the only uses of max() that require a constant value
> from constant parameters.
> There don't seem to be any similar uses of min().
>
> Replacing the max() by max_const() lets min()/max() be simplified
> speeding up compila
On 25.01.24 19:44, Adam Ford wrote:
> On Mon, Dec 11, 2023 at 9:33 PM Adam Ford wrote:
>>
>> When using video sync pulses, the HFP, HBP, and HSA are divided between
>> the available lanes if there is more than one lane. For certain
>> timings and lane configurations, the HFP may not be evenly div
@rmf...@gmail.com@Laurent
Pinchart@martin.kepplin...@puri.sm@ker...@puri.sm@linux-me...@vger.kernel.org
Any feedback?
Thanks
B&R.
Name: Alice Yuan
Address: No.192, Zhangjiang Liangjing Road, Pudong New Area, Shanghai
> -Original Message-
> From: Alice Yuan
> Sent: 2023年12月8
In function i915_vma_pin_iomap(), vma->iomap is read using READ_ONCE()
in line 562
562ptr = READ_ONCE(vma->iomap);
while read directly in line 597
592if (unlikely(cmpxchg(&vma->iomap, NULL, ptr))) {
593if (page_unmask_bits(ptr))
594__i915_gem_object_release_map(vma->o
Hi Conor,
On Fri, 2024-01-26 at 16:27 +, Conor Dooley wrote:
> Hey,
>
> On Fri, Jan 26, 2024 at 09:57:23AM +0100, Yannic Moog wrote:
> > Add Emerging Display Technology Corp. etml1010g3dra 10.1" LCD-TFT LVDS
> > panel compatible string.
> >
> > Signed-off-by: Yannic Moog
>
> > [PATCH RFC f
On Sun, 28 Jan 2024 18:25:13 -0300
André Almeida wrote:
> Some hardware are more flexible on what they can flip asynchronously, so
> rework the plane check so drivers can implement their own check, lifting
> up some of the restrictions.
>
> Signed-off-by: André Almeida
> ---
> v3: no changes
>
On Mon, 29 Jan 2024 09:16:04 +0300
Dmitry Osipenko wrote:
> On 1/26/24 21:12, Boris Brezillon wrote:
> > On Fri, 26 Jan 2024 19:27:49 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 1/26/24 12:55, Boris Brezillon wrote:
> >>> On Fri, 26 Jan 2024 00:56:47 +0300
> >>> Dmitry Osipenko wrote:
> >
On Fri, 5 Jan 2024 21:46:16 +0300
Dmitry Osipenko wrote:
> +/**
> + * drm_gem_shmem_swapin_locked() - Moves shmem GEM back to memory and enables
> + * hardware access to the memory.
> + * @shmem: shmem GEM object
> + *
> + * This function moves shmem GEM back to m
On Mon, 29 Jan 2024 09:55:11 +0100
Boris Brezillon wrote:
> On Mon, 29 Jan 2024 09:16:04 +0300
> Dmitry Osipenko wrote:
>
> > On 1/26/24 21:12, Boris Brezillon wrote:
> > > On Fri, 26 Jan 2024 19:27:49 +0300
> > > Dmitry Osipenko wrote:
> > >
> > >> On 1/26/24 12:55, Boris Brezillon wro
On Sun, 28 Jan 2024, David Laight wrote:
> blk_stack_limits() contains:
> t->zoned = max(t->zoned, b->zoned);
> These are bool, so it is just a bitwise or.
Should be a logical or, really. And || in code.
BR,
Jani.
> However it generates:
> error: comparison of constant ‘0’ with boole
On 1/23/24 21:14, Sebastian Ott wrote:
> drm/virtio: set segment size for virtio_gpu device
>
> Set the segment size of the virtio_gpu device to the value
> used by the drm helpers when allocating sg lists to fix the
> following complaint from DMA_API debug code:
> DMA-API: virtio-pci :07:00.0
On 26.01.24 19:28, Dave Airlie wrote:
> Just FYI this conflictted pretty heavily with drm-misc-next changes in
> the same area, someone should check drm-tip has the correct
> resolution, I'm not really sure what is definitely should be.
>
> Dave.
Thanks! I took a quick look at what is now in Linu
From: Jani Nikula
> Sent: 29 January 2024 09:08
>
> On Sun, 28 Jan 2024, David Laight wrote:
> > blk_stack_limits() contains:
> > t->zoned = max(t->zoned, b->zoned);
> > These are bool, so it is just a bitwise or.
>
> Should be a logical or, really. And || in code.
Not really, bitwise is fi
Hi Janusz,
There seems to be a regression in CI related to this:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129026v2/bat-dg1-7/igt@gem_lmem_swapping@random-engi...@lmem0.html#dmesg-warnings1053
Please have a look.
Regards,
Nirmoy
On 1/24/2024 6:13 PM, Janusz Krzysztofik wrote:
Obje
On 1/29/24 12:01, Boris Brezillon wrote:
> On Fri, 5 Jan 2024 21:46:16 +0300
> Dmitry Osipenko wrote:
>
>> +/**
>> + * drm_gem_shmem_swapin_locked() - Moves shmem GEM back to memory and
>> enables
>> + * hardware access to the memory.
>> + * @shmem: shmem GEM obj
On Fri, 26 Jan 2024, Mario Limonciello wrote:
> On 1/26/2024 10:28, Melissa Wen wrote:
>> Hi,
>>
>> I'm debugging a null-pointer dereference when running
>> igt@kms_connector_force_edid and the way I found to solve the bug is to
>> stop using raw edid handler in amdgpu_connector_funcs_force and
>
This patch series aims to add support for XLCDC IP of sam9x7 SoC family
to the DRM subsystem.XLCDC IP has additional registers and new
configuration bits compared to the existing register set of HLCDC IP.
The new compatible string "microchip,sam9x75-xlcdc" is defined for sam9x75
variant of the sam9
Add is_xlcdc flag and LCD IP specific ops in driver data to differentiate
XLCDC and HLCDC code within the atmel-hlcdc driver files.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 37
1 file changed, 37 insertions(+)
diff --git a/dr
Add the LCD controller layer definition and descriptor structure for
sam9x75 for the following layers:
- Base Layer
- Overlay1 Layer
- Overlay2 Layer
- High End Overlay
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 97
1 file chang
From: Durai Manickam KR
The register address of the XLCDC IP used in SAM9X7 SoC family
are different from the previous HLCDC. Defining those address
space with valid macros.
Signed-off-by: Durai Manickam KR
[manikanda...@microchip.com: Remove unused macro definitions]
Signed-off-by: Manikandan
XLCDC in SAM9X7 has different sets of registers and additional
configuration bits when compared to previous HLCDC IP. Read/write
operation on the controller registers is now separated using the
XLCDC status flag and with HLCDC and XLCDC IP specific ops.
HEO scaling, window resampling, Alpha blendin
Update the LCDC_HEOCFG30 and LCDC_HEOCFG31 registers of XLCDC IP which
supports vertical and horizontal scaling with Bilinear and Bicubic
co-efficients taps for Chroma and Luma componenets of the Pixel.
Signed-off-by: Manikandan Muralidharan
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2
Add support for Display Pixel Interface (DPI) Compatible Mode
support in atmel-hlcdc driver for XLCDC IP along with legacy
pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register.
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update DPI mode bit using is_xlcdc fl
Add support for the following DPI mode if the encoder type
is DSI as per the XLCDC IP datasheet:
- 16BPPCFG1
- 16BPPCFG2
- 16BPPCFG3
- 18BPPCFG1
- 18BPPCFG2
- 24BPP
Signed-off-by: Manikandan Muralidharan
[durai.manicka...@microchip.com: update output format using is_xlcdc flag]
Signed-off-by: Dur
Hi Boris：
Thanks for you great work。
One thing please take note：
commit (arm64: dts: rockchip: rk3588: Add GPU nodes) in [1] seems remove the
"disabled" status
of usb_host2_xhci, this may cause a boot issue on some boards that use
combphy2_psu phy for other functions.
https://gitlab.freede
On Fri, 26 Jan 2024, Mario Limonciello wrote:
> Some manufacturers have intentionally put an EDID that differs from
> the EDID on the internal panel on laptops.
>
> Attempt to fetch this EDID if it exists and prefer it over the EDID
> that is provided by the panel.
>
> Signed-off-by: Mario Limonci
On Mon, 29 Jan 2024, David Laight wrote:
> From: Jani Nikula
>> Sent: 29 January 2024 09:08
>>
>> On Sun, 28 Jan 2024, David Laight wrote:
>> > blk_stack_limits() contains:
>> >t->zoned = max(t->zoned, b->zoned);
>> > These are bool, so it is just a bitwise or.
>>
>> Should be a logical or,
Am 26.01.24 um 21:13 schrieb Zeng, Oak:
-Original Message-
From: Christian König
Sent: Friday, January 26, 2024 5:10 AM
To: Zeng, Oak; David Airlie
Cc: Ghimiray, Himal Prasad;
thomas.hellst...@linux.intel.com; Winiarski, Michal
; Felix Kuehling; Welty,
Brian; Shah, Ankur N; dri-
de...@lis
To realize dGPU prime feature for virtio gpu, we are trying to let dGPU
import vram object of virtio gpu. As vram objects don't have backing pages
and thus can't implement the drm_gem_object_funcs.get_sg_table callback,
this removes calling drm_gem_map_dma_buf in virtgpu_gem_map_dma_buf and
impleme
On Mon, Jan 29, 2024 at 09:22:40AM +, David Laight wrote:
> From: Jani Nikula
> > Sent: 29 January 2024 09:08
> >
> > On Sun, 28 Jan 2024, David Laight wrote:
> > > blk_stack_limits() contains:
> > > t->zoned = max(t->zoned, b->zoned);
> > > These are bool, so it is just a bitwise or.
> >
Well Daniel and Dave noted it as well, so I'm just repeating it: Your
design choices are not an argument to get something upstream.
It's the job of the maintainers and at the end of the Linus to judge of
something is acceptable or not.
As far as I can see a good part of this this idea has bee
Hi Lucas,
On Fri, 26 Jan 2024 at 17:00, Lucas Stach wrote:
> The dma sync operation needs to be done with DMA_BIDIRECTIONAL when
> the BO is prepared for both read and write operations. With the
> current inverted if ladder it would only be synced for DMA_FROM_DEVICE.
>
> [...]
>
> static inline
As vram objects don't have backing pages and thus can't implement
drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
and implement virtgpu specific map/unmap/attach callbacks to support
both of shmem objects and vr
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
On Tue, 2024-01-23 at 12:28 +0200, Imre Deak wrote:
> On shared (Thunderbolt) links with DP tunnels, the modeset may need
> to
> be retried on all connectors on the link due to a link BW limitation
> arising only after the atomic check phase. To support this add a
> helper
> function queuing a work
Also merge commit 663a907e199b (Merge remote-tracking branch
'drm-misc/drm-misc-next' into drm-tip) is broken because it
completely removes samsung_dsim_atomic_disable(). Dunno whats
going on there.
Actually, that merge commit looks even worse. It somehow folds
the original samsung_dsim_atomic_d
Hi,
On Fri, 26 Jan 2024 09:57:22 +0100, Yannic Moog wrote:
> This series adds the LVDS panel support in simple-panel, introduces
> device tree support for the LVDS panel on the phyBOARD-Pollux and
> enables the FSL_LDB config option needed for the driver for the imx8mp
> ldb bridge.
>
Thanks, Ap
Thomas Zimmermann writes:
Hello Thomas,
> The plain values as stored in struct screen_info need to be decoded
> before being used. Add helpers that decode the type of video output
> and the framebuffer I/O aperture.
>
> Old or non-x86 systems may not set the type of video directly, but
> only in
Use RUNTIME_PM_OPS() instead of the old SET_SYSTEM_SLEEP_PM_OPS().
This means we don't need __maybe_unused on the functions.
Signed-off-by: Raphael Gallais-Pou
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/s
From: Yannick Fertre
Update control of clocks and supply thanks to the PM runtime
mechanism to avoid kernel crash during a system suspend.
Signed-off-by: Yannick Fertre
Signed-off-by: Raphael Gallais-Pou
---
Changes in v2:
- Changed SET_RUNTIME_PM_OPS to RUNTIME_PM_OPS and removed
DSISRC __
__\_
|\
pll4_p_ck ->| 1 |dsi_k
ck_dsi_phy ->| 0 |
|/
A DSI clock is missing in the clock framework. Looking at the
clk_summary, it appears that 'ck_dsi_phy' is not implem
This patch series aims to add several features of the dw-mipi-dsi phy
driver that are missing or need to be updated.
First patch update a PM macro.
Second patch adds runtime PM functionality to the driver.
Third patch adds a clock provider generated by the PHY itself. As
explained in the comm
On Mon, 29 Jan 2024 17:20:47 +0800 (CST)
"Andy Yan" wrote:
> Hi Boris：
>
> Thanks for you great work。
>
> One thing please take note：
> commit (arm64: dts: rockchip: rk3588: Add GPU nodes) in [1] seems remove the
> "disabled" status
> of usb_host2_xhci, this may cause a boot issue on some bo
On Mon, Jan 29, 2024 at 12:36:12PM +0200, Hogander, Jouni wrote:
> On Tue, 2024-01-23 at 12:28 +0200, Imre Deak wrote:
> > [...]
> > +void
> > +intel_dp_queue_modeset_retry_for_link(struct intel_atomic_state *state,
> > + struct intel_encoder *encoder,
> > +
On Fri, 2024-01-26 at 16:22 -0600, Lucas De Marchi wrote:
> On Fri, Jan 26, 2024 at 04:16:58PM -0600, Lucas De Marchi wrote:
> > On Thu, Jan 18, 2024 at 05:38:16PM +0100, Thomas Hellström wrote:
> > >
> > > On 1/17/24 13:27, Thomas Hellström wrote:
> > > >
> > > > On 1/17/24 11:47, Thomas Hellstr
Hi Nirmoy,
On Monday, 29 January 2024 10:24:07 CET Nirmoy Das wrote:
> Hi Janusz,
>
> There seems to be a regression in CI related to this:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_129026v2/bat-dg1-7/
igt@gem_lmem_swapping@random-engi...@lmem0.html#dmesg-warnings1053
>
> Please ha
Thomas Zimmermann writes:
> Add screen_info_get_pci_dev() to find the PCI device of an instance
> of screen_info. Does nothing on systems without PCI bus.
>
> Signed-off-by: Thomas Zimmermann
> ---
[...]
> +struct pci_dev *screen_info_pci_dev(const struct screen_info *si)
> +{
> + struct r
Hi Philipp,
On 1/23/24 10:43, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was caused by t
Thomas Zimmermann writes:
> Set the firmware framebuffer's parent device, which usually is the
> graphics hardware's physical device. Integrates the framebuffer in
> the Linux device hierarchy and lets Linux handle dependencies among
> devices. For example, the graphics hardware won't be suspende
Thomas Zimmermann writes:
> The EFI device has the correct parent device set. This allows Linux
> to handle the power management internally. Hence, remove the manual
> PM management for the parent device from efifb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canilla
Thomas Zimmermann writes:
> Test if the firmware framebuffer's parent PCI device, if any, has
> been enabled. If not, the firmware framebuffer is most likely not
> working. Hence, do not create a device for the firmware framebuffer
> on disabled PCI devices.
>
> So far, efifb tracked the status o
Thomas Zimmermann writes:
> There will be no EFI framebuffer device for disabled parent devices
> and thus we never probe efifb in that case. Hence remove the tracking
> code from efifb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Nice cleanup.
Reviewed-by: Javier Martinez Canillas
--
Best r
Thomas Zimmermann writes:
> On ARM PCI systems, the PCI hierarchy might be reconfigured during
> boot and the firmware framebuffer might move as a result of that.
> The values in screen_info will then be invalid.
>
> Work around this problem by tracking the framebuffer's initial
> location before
Javier Martinez Canillas writes:
> Thomas Zimmermann writes:
>
>> On ARM PCI systems, the PCI hierarchy might be reconfigured during
>> boot and the firmware framebuffer might move as a result of that.
>> The values in screen_info will then be invalid.
>>
>> Work around this problem by tracking
Thomas Zimmermann writes:
> If the firmware framebuffer has been reloacted, the sysfb code
> fixes the screen_info state before it creates the framebuffer's
> platform device. Efifb will automatically receive a screen_info
> with updated values. Hence remove the tracking from efifb.
>
> Signed-of
Am 26.01.24 um 18:24 schrieb Andrew Davis:
On 1/25/24 2:30 PM, Daniel Vetter wrote:
On Tue, Jan 23, 2024 at 04:12:26PM -0600, Andrew Davis wrote:
Currently this driver creates a SGT table using the CPU as the
target device, then performs the dma_sync operations against
that SGT. This is backwar
of_property_read_u32 returns 0 when success, so reverse the
return value to get the true value.
Fixes: f8449c8f7355 ("backlight: ktz8866: Add support for Kinetic KTZ8866
backlight")
Signed-off-by: Jianhua Lu
---
drivers/video/backlight/ktz8866.c | 6 +++---
1 file changed, 3 insertions(+), 3 de
Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
+ iio_buffer_dmabuf_put(attach);
+
+out_dmabuf_put:
+ dma_buf_put(dmabuf);
As below. Feels like a __free(dma_buf_put) bit of magic would be a
nice to have.
I'm working on the patches right now, just one quick question.
Having a __free(
Hi Christian,
Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
> > > > > + iio_buffer_dmabuf_put(attach);
> > > > > +
> > > > > +out_dmabuf_put:
> > > > > + dma_buf_put(dmabuf);
> > > > As below. Feels like a __free(dma_buf_
Hi,
On Mon, 2024-01-29 at 12:15 +0100, Hans de Goede wrote:
> Hi Philipp,
>
> On 1/23/24 10:43, Philipp Stanner wrote:
> > When the PCI devres API was introduced to this driver, it was
> > wrongly
> > assumed that initializing the device with pcim_enable_device()
> > instead
> > of pci_enable_dev
Am 29.01.24 um 11:31 schrieb Julia Zhang:
As vram objects don't have backing pages and thus can't implement
drm_gem_object_funcs.get_sg_table callback. This removes drm dma-buf
callbacks in virtgpu_gem_map_dma_buf()/virtgpu_gem_unmap_dma_buf()
and implement virtgpu specific map/unmap/attach callb
Am 29.01.24 um 14:06 schrieb Paul Cercueil:
Hi Christian,
Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
+ iio_buffer_dmabuf_put(attach);
+
+out_dmabuf_put:
+ dma_buf_put(dmabuf);
As below. Feels like a __free(dma_b
This patchset adds support for display for X1E80100.
The support for embedded DisplayPort on this platform will not
be enabled using the connetor type from driver match data,
but through some 'is-edp' property via DT. This subsequent work
will be part of a separate patchset.
Signed-off-by: Abel Ve
Document the MDSS hardware found on the Qualcomm X1E80100 platform.
Signed-off-by: Abel Vesa
---
.../bindings/display/msm/qcom,x1e80100-mdss.yaml | 249 +
1 file changed, 249 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/msm/qcom,x1e80100-mdss.yaml
Document the DPU for Qualcomm X1E80100 platform in the SM8650 schema, as
they are similar.
Signed-off-by: Abel Vesa
---
Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dis
Add support for MDSS on X1E80100.
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/msm/msm_mdss.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
index 455b2e3a0cdd..eddf7fdbb60a 100644
--- a/drivers/gpu/drm/msm/msm_mdss
Add definitions for the display hardware used on the Qualcomm X1E80100
platform.
Co-developed-by: Abhinav Kumar
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
.../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449 +
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog
From: Abhinav Kumar
On platforms where the endpoint used is on port@0, looking for port@1
instead results in just ignoring the max link-frequencies altogether.
Look at port@0 first, then, if not found, look for port@1.
Signed-off-by: Abhinav Kumar
Signed-off-by: Abel Vesa
---
drivers/gpu/drm/
Hi,
On 1/19/24 21:15, Pavel Machek wrote:
> Hi!
>
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular
entity"
- Con:
>
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
> Am 19.01.24 um 09:44 schrieb Hans de Goede:
>> So my proposal would be an ioctl interface (ioctl only no r/w)
>> using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
>>
>> For per key controllable rgb LEDs we need to discuss a
Le lundi 29 janvier 2024 à 14:17 +0100, Christian König a écrit :
> Am 29.01.24 um 14:06 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> > > Am 27.01.24 um 17:50 schrieb Jonathan Cameron:
> > > > > > > + iio_buffer_dmabuf_put(att
On Fri, Jan 26, 2024 at 7:55 PM Mario Limonciello
wrote:
>
> The ACPI specification allows for an EDID to be up to 512 bytes but
> the _DDC EDID fetching code will only try up to 256 bytes.
>
> Modify the code to instead start at 512 bytes and work it's way
> down instead.
>
> Link:
> https://uef
Le lundi 29 janvier 2024 à 14:32 +0100, Paul Cercueil a écrit :
> Le lundi 29 janvier 2024 à 14:17 +0100, Christian König a écrit :
> > Am 29.01.24 um 14:06 schrieb Paul Cercueil:
> > > Hi Christian,
> > >
> > > Le lundi 29 janvier 2024 à 13:52 +0100, Christian König a écrit :
> > > > Am 27.01.24
On Wed, Jan 24, 2024 at 07:27:58AM -0800, Yury Norov wrote:
On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> On Tue, 23 Jan 2024, Lucas De Marchi wrote:
> > From: Yury Norov
> >
> > Generalize __GENMASK() to support
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exception I know is actually the kfd SVM API. If you look at the svm_ioctl
function, it is per-proce
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> From: Abhinav Kumar
>
> On platforms where the endpoint used is on port@0, looking for port@1
> instead results in just ignoring the max link-frequencies altogether.
> Look at port@0 first, then, if not found, look for port@1.
NAK. Platforms do
On Mon, Jan 29, 2024 at 08:49:35AM -0600, Lucas De Marchi wrote:
> On Wed, Jan 24, 2024 at 07:27:58AM -0800, Yury Norov wrote:
> > On Wed, Jan 24, 2024 at 08:03:53AM -0600, Lucas De Marchi wrote:
> > > On Wed, Jan 24, 2024 at 09:58:26AM +0200, Jani Nikula wrote:
> > > > On Tue, 23 Jan 2024, Lucas D
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> Add support for MDSS on X1E80100.
>
> Signed-off-by: Abel Vesa
> ---
> drivers/gpu/drm/msm/msm_mdss.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/msm_mdss.c b/drivers/gpu/drm/msm/msm_mdss.c
> index 45
On Mon, 29 Jan 2024 at 15:19, Abel Vesa wrote:
>
> Add definitions for the display hardware used on the Qualcomm X1E80100
> platform.
>
> Co-developed-by: Abhinav Kumar
> Signed-off-by: Abhinav Kumar
> Signed-off-by: Abel Vesa
> ---
> .../drm/msm/disp/dpu1/catalog/dpu_9_2_x1e80100.h | 449
>
That we include so many C files with relative paths seems to be odd.
Apart from that looks good to me.
Christian.
Am 26.01.24 um 16:48 schrieb Rodrigo Siqueira:
In 2022, we got a great patchset from a GSoC project introducing unit
tests to the amdgpu display. Since version 3, this effort was p
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exception I know is actually the kfd SVM API. If you lo
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
FWIW, this looks rather messy now. The drm-tip doesn't build.
There was a new call to samsung_dsim_set
On 1/29/2024 03:39, Jani Nikula wrote:
On Fri, 26 Jan 2024, Mario Limonciello wrote:
Some manufacturers have intentionally put an EDID that differs from
the EDID on the internal panel on laptops.
Attempt to fetch this EDID if it exists and prefer it over the EDID
that is provided by the panel.
On 1/29/2024 07:54, Rafael J. Wysocki wrote:
On Fri, Jan 26, 2024 at 7:55 PM Mario Limonciello
wrote:
The ACPI specification allows for an EDID to be up to 512 bytes but
the _DDC EDID fetching code will only try up to 256 bytes.
Modify the code to instead start at 512 bytes and work it's way
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exceptio
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes
On Mon, 29 Jan 2024, Mario Limonciello wrote:
> On 1/29/2024 03:39, Jani Nikula wrote:
>> On Fri, 26 Jan 2024, Mario Limonciello wrote:
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
>>> index 9caba10315a8..c7e1563a46d3 100644
Am 27.01.24 um 16:53 schrieb Oak Zeng:
This fixes a build failure on drm-tip. This issue was introduced during
merge of "drm/ttm: replace busy placement with flags v6". For some
reason, the xe_bo.c part of above change is not merged. Manually merge
the missing part to drm_tip
Mhm, I provided th
On 29.01.24 10:20, Frieder Schrempf wrote:
> On 26.01.24 19:28, Dave Airlie wrote:
>> Just FYI this conflictted pretty heavily with drm-misc-next changes in
>> the same area, someone should check drm-tip has the correct
>> resolution, I'm not really sure what is definitely should be.
>>
>> Dave.
>
On 1/29/2024 10:46, Jani Nikula wrote:
On Mon, 29 Jan 2024, Mario Limonciello wrote:
On 1/29/2024 03:39, Jani Nikula wrote:
On Fri, 26 Jan 2024, Mario Limonciello wrote:
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 9caba1
27;s in, I will gladly send a follow-up patch to use __free() where it
makes sense.
For performance numbers, I'll point you to the cover letter for my v5
patchset [2].
This patchset was based on next-20240129.
Cheers,
-Paul
[1] https://lore.kernel.org/all/20230322092118.9213-1-p...@crap
Add implementation of the .device_prep_slave_dma_vec() callback.
Signed-off-by: Paul Cercueil
---
v3: New patch
v5: Implement .device_prep_slave_dma_vec() instead of v3's
.device_prep_slave_dma_array().
v6: Use new prototype for axi_dmac_alloc_desc() as it changed upstream.
---
drivers/dm
This function can be used to initiate a scatter-gather DMA transfer,
where the address and size of each segment is located in one entry of
the dma_vec array.
The major difference with dmaengine_prep_slave_sg() is that it supports
specifying the lengths of each DMA transfer; as trying to override t
Add the necessary infrastructure to the IIO core to support a new
optional DMABUF based interface.
With this new interface, DMABUF objects (externally created) can be
attached to a IIO buffer, and subsequently used for data transfer.
A userspace application can then use this interface to share DM
Use the functions provided by the buffer-dma core to implement the
DMABUF userspace API in the buffer-dmaengine IIO buffer implementation.
Since we want to be able to transfer an arbitrary number of bytes and
not necesarily the full DMABUF, the associated scatterlist is converted
to an array of DM
Implement iio_dma_buffer_attach_dmabuf(), iio_dma_buffer_detach_dmabuf()
and iio_dma_buffer_transfer_dmabuf(), which can then be used by the IIO
DMA buffer implementations.
Signed-off-by: Paul Cercueil
---
v3: Update code to provide the functions that will be used as callbacks
for the new IO
Document the new DMABUF based API.
Signed-off-by: Paul Cercueil
---
v2: - Explicitly state that the new interface is optional and is
not implemented by all drivers.
- The IOCTLs can now only be called on the buffer FD returned by
IIO_BUFFER_GET_FD_IOCTL.
- Move the page up a
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Zimmermann
commit 9cf5ca1f485cae406968947a92bf304603999fa1 upstream.
Non-KMS drivers have been removed from DRM. Update the TODO list
accordingly.
Signed-off-by: Thomas Zimmermann
Fixe
6.7-stable review patch. If anyone has any objections, please let me know.
--
From: Zack Rusin
commit 4e3b70da64a53784683cfcbac2deda5d6e540407 upstream.
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. th
On 2024-01-29 02:44, Christian König wrote:
> Am 26.01.24 um 17:29 schrieb Matthew Brost:
>> On Fri, Jan 26, 2024 at 11:32:57AM +0100, Christian König wrote:
>>> Am 25.01.24 um 18:30 schrieb Matthew Brost:
On Thu, Jan 25, 2024 at 04:12:58PM +0100, Christian König wrote:
> Am 24.01.24 um 22
1 - 100 of 140 matches
Mail list logo
