Hello Emil,
Thanks for the comments.
On 13-05-20, 20:20, Emil Velikov wrote:
> Hi Vinod,
>
> Few high-level comments:
> - handful of functions always return 0 and the return value is never
> checked - switch to return void
Sure makes sense, will do
> - annotate all (nearly) arrays as static
Hi Dave and Daniel,
this is the forth pull request for drm-misc-next for what will become v5.8.
It's fairly small number of patches without major changes. There's one fix
to the UAPI headers, but it only affects comments.
Best regards
Thomsa
drm-misc-next-2020-05-14:
drm-misc-next for 5.8:
UAPI
On Thu, May 14, 2020 at 8:42 AM Daniel Stone wrote:
>
> On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote:
> > Resending because last attempt failed CI and meanwhile the results are
> > lost :-/
>
> Did anything happen with this?
Nope. There's an igt now that fails with this, and I'm not sure
whe
On Wed, May 13, 2020 at 11:18:15PM +0100, Emil Velikov wrote:
> Hi Greg,
>
> On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman
> wrote:
>
> >
> > I have now done this with patch 1/10. Here's the pull info if any
> > subsystem maintainer wants to suck this into their tree to provide the
> > abilit
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on imported buffers. The trouble is in the locks these take - I want
> to change dma_buf_vmap locking, and so need to make sure that we only
> ever take certain locks on one sid
Hi,
On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > Did anything happen with this?
>
> Nope. There's an igt now that fails with this, and I'm not sure
> whether changing the igt is the right idea or not.
>
> I'm kinda now thinking about changing this to instead document under
> which exact
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> Currently this seems to work by converting the sgt into a pages array,
> and then treating it like a native object. Do the right thing and
> redirect mmap to the exporter.
>
> With this nothing is calling get_pages anymore on imported dma-buf,
> an
On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
>
> Hi,
>
> On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > > Did anything happen with this?
> >
> > Nope. There's an igt now that fails with this, and I'm not sure
> > whether changing the igt is the right idea or not.
> >
> > I'm kinda
Hi,
given the upcoming removal of this file, I don't know if you really want
to merge this patch. If so, please see my comment on patch 6 and
Acked-by: Thomas Zimmermann
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> There's no direct harm, because for the shmem helpers these are noops
> on impo
Hi Laurent,
On Thu, May 14, 2020 at 02:21:27AM +0300, Laurent Pinchart wrote:
> The DT binding support both dual-input and dual-output mode, but only
> dual-input is documented. Document dual-output mode.
>
> Suggested-by: Jacopo Mondi
> Signed-off-by: Laurent Pinchart
Thanks
Acked-by: Jacopo M
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> Just a bit of light paranoia. Also sprinkle this check over
> drm_gem_shmem_get_sg_table, which should only be called when
> exporting, same for the pin/unpin functions, on which it relies to
> work correctly.
>
> Cc: Gerd Hoffmann
> Cc: Rob Herri
Hi Laurent,
On Thu, May 14, 2020 at 1:29 AM Laurent Pinchart
wrote:
> Convert the Renesas R-Car LVDS encoder text binding to YAML.
>
> Signed-off-by: Laurent Pinchart
> Acked-by: Maxime Ripard
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml
> +exampl
On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > I'd be very much in favour of putting the blocking down in the kernel
> > at least until the kernel can give us a clear indication t
Hi
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> - Ditch the ->pages array
> - Make it a private gem bo, which means no shmem object, which means
> fireworks if anyone calls drm_gem_object_get_pages. But we've just
> made sure that's all covered.
>
> Cc: Gerd Hoffmann
> Cc: Rob Herring
> Cc
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> drm_gem_shmem_get_sg_table is meant to implement
> obj->funcs->get_sg_table, for prime exporting. The one we want is
> drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not
> just native objects.
>
> v2: Rebase, this stuff moved aroun
Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> No real functional change, since this just converts an annoying Oops
> into a more harmless WARNING backtrace. It's still a driver bug.
>
> Signed-off-by: Daniel Vetter
Acked-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/drm_gem.c | 8
>
Hi,
> - for the runtime upcasting the usual approach is to check the ->ops
> pointer. Which means that would need to be the same for all virtio
> dma_bufs, which might get a bit awkward. But I'd really prefer we not
> add allocator specific stuff like this to dma-buf.
This is exactly the proble
On Wed, 13 May 2020 11:28:38 -0700
Rajat Jain wrote:
> On Wed, May 13, 2020 at 12:49 AM Pekka Paalanen wrote:
...
> > On Tue, 12 May 2020 10:38:11 -0700
> > Rajat Jain wrote:
> >
> > > The chrome browser currently uses the API exposed by my (previous)
> > > patchset to control privacy scree
Hi Dillon,
thanks for your patch! Overall this looks like a good start.
On Tue, May 12, 2020 at 9:04 AM wrote:
> #define ILI9341_SLEEP_OUT0x11 /* Sleep out register */
This is not a register, also just use MIPI_DCS_EXIT_SLEEP_MODE
in the code.
> +#define ILI9341_DFC
Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote:
>
> > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > says that only the 'reg' clock could be optional, the others are
> > required.
>
> arch/arm/boot/
On Tue, May 12, 2020 at 9:03 AM wrote:
> From: dillon min
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min
This looks good to me.
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@li
On Tue, May 12, 2020 at 9:04 AM wrote:
> From: dillon min
>
> Enable the ltdc & ili9341 on stm32429-disco board.
>
> Signed-off-by: dillon min
This mostly looks good but...
> +&spi5 {
> + status = "okay";
> + pinctrl-0 = <&spi5_pins>;
> + pinctrl-names = "default";
> +
I've pulled that into our tree, thanks!
Roland
Am 07.05.20 um 13:07 schrieb Jason Yan:
> Fix the following coccicheck warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:518:9-10: WARNING: return of 0/1
> in function 'vmw_fence_obj_signaled' with return type bool
>
> Signed-off-by: Jason Yan
>
Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux
admin:
> On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote:
> > >
> > > > The bindi
On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > On Wed, May 13, 2020 at 2:09 PM Fabio Estevam wrote:
> >
> > > The binding doc Documentation/devicetree/bindings/gpu/vivante,gc.yaml
> > > says that only the 'reg' cl
On Thu, May 14, 2020 at 10:40:58AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 14.05.2020, 09:27 +0100 schrieb Russell King - ARM Linux
> admin:
> > On Thu, May 14, 2020 at 10:18:02AM +0200, Lucas Stach wrote:
> > > Am Mittwoch, den 13.05.2020, 23:41 -0300 schrieb Fabio Estevam:
> > > > On Wed,
Hi,
On 14/05/2020 03:17, Laurent Pinchart wrote:
> Platform glue drivers for dw_hdmi may need to access device-specific
> data from their .mode_valid() implementation. They currently have no
> clean way to do so, and one driver hacks around it by accessing the
> dev_private data of the drm_device
Hi Alex,
On Thu, 30 Apr 2020 at 22:30, Alex Deucher wrote:
> UAPI:
> - Add amdgpu UAPI for encrypted GPU memory
> Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
Did this ever go through uAPI review? It's been pushed to the kernel
before Mesa review was complete. Even t
Hi Hans,
On Thu, 30 Apr 2020 at 15:55, Hans de Goede wrote:
>
> Hi,
>
> On 4/30/20 4:52 PM, Ville Syrjälä wrote:
> > On Thu, Apr 30, 2020 at 02:47:00PM +0100, Emil Velikov wrote:
> >> Hi Hans,
> >>
> >> On Fri, 21 Feb 2020 at 17:33, Hans de Goede wrote:
> >>>
> >>> drm_helper_probe_add_cmdline_m
Runtime power management is essential for the Exynos Mixer driver
operation. It should be enabled before adding its DRM component, because
in some cases (when deferred probe takes place due to the IOMMU
availability) the DRM driver might be initialized directly from the
Mixer's component_add() call
This converts the Analogix ANX7814 bridge DT binding to yaml. Port
definitions and descriptions were expanded, apart from that it's a
direct translation from the original binding.
Signed-off-by: Ricardo Cañuelo
Acked-by: Sam Ravnborg
Reviewed-by: Enric Balletbo i Serra
---
Changes in v4:
- Ma
From: Sibi Sankar
Add and export 'dev_pm_opp_set_bw' to set the bandwidth
levels associated with an OPP for a given frequency.
Signed-off-by: Sibi Sankar
Signed-off-by: Sharat Masetty
---
drivers/opp/core.c | 43 +++
include/linux/pm_opp.h | 6
Update documentation to list the gpu opp table bindings including the
newly added "opp-peak-kBps" needed for GPU-DDR bandwidth scaling.
Signed-off-by: Sharat Masetty
---
.../devicetree/bindings/display/msm/gpu.txt| 28 ++
1 file changed, 28 insertions(+)
diff --git a
Add opp-peak-kBps bindings to the GPU opp table, listing the peak
GPU -> DDR bandwidth requirement for each opp level. This will be
used to scale the DDR bandwidth along with the GPU frequency dynamically.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 7 +++
1 file
This is a rework of my previous series [1], but this time based on the bindings
from Georgi [2] + a few fixes which look to be fixed in v8 of Georgi's series
[3]. The work is based on the chromeOS tip.
[1]: https://patchwork.freedesktop.org/series/75291/
[2]: https://lore.kernel.org/patchwork/cove
This patch adds the interconnect bindings to the GPU node. This enables
the GPU->DDR path bandwidth voting.
Signed-off-by: Sharat Masetty
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qco
This patches replaces the previously used static DDR vote and uses
dev_pm_opp_set_bw() to scale GPU->DDR bandwidth along with scaling
GPU frequency.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dr
This patch changes the plumbing to send the devfreq recommended opp rather
than the frequency. Also consolidate and rearrange the code in a6xx to set
the GPU frequency and the icc vote in preparation for the upcoming
changes for GPU->DDR scaling votes.
Signed-off-by: Sharat Masetty
---
drivers/g
On Thu, 14 May 2020, Gwan-gyeong Mun wrote:
> In order to readout DP SDPs (Secondary Data Packet: DP HDR Metadata
> Infoframe SDP, DP VSC SDP), it refactors handling DP SDPs codes.
> It adds new compute routines for DP HDR Metadata Infoframe SDP
> and DP VSC SDP.
> And new writing routines of DP
On Wed, May 13, 2020 at 11:46 PM Emil Velikov wrote:
>
> With earlier commits, the API no longer discards the const-ness of the
> sysrq_key_op. As such we can add the notation.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: linux-ker...@vger.kernel.org
> Cc: "Rafael J. Wysocki"
> Cc: Len Bro
On Tue, May 12, 2020 at 9:12 AM Daniel Vetter wrote:
>
> On Tue, May 12, 2020 at 4:14 AM Dave Airlie wrote:
> >
> > On Mon, 11 May 2020 at 19:37, Oded Gabbay wrote:
> > >
> > > On Mon, May 11, 2020 at 12:11 PM Daniel Vetter
> > > wrote:
> > > >
> > > > It's the default.
> > > Thanks for catchi
On Thu, 14 May 2020 at 08:16, Greg Kroah-Hartman
wrote:
>
> On Wed, May 13, 2020 at 11:18:15PM +0100, Emil Velikov wrote:
> > Hi Greg,
> >
> > On Fri, 2 Aug 2019 at 11:46, Greg Kroah-Hartman
> > wrote:
> >
> > >
> > > I have now done this with patch 1/10. Here's the pull info if any
> > > subsys
On Thu, May 14, 2020 at 11:08:52AM +0900, David Stevens wrote:
> On Thu, May 14, 2020 at 12:45 AM Daniel Vetter wrote:
> > On Wed, Mar 11, 2020 at 12:20 PM David Stevens
> > wrote:
> > >
> > > This change adds a new dma-buf operation that allows dma-bufs to be used
> > > by virtio drivers to sha
On Thu, May 14, 2020 at 05:19:40PM +0900, David Stevens wrote:
> Sorry for the duplicate reply, didn't notice this until now.
>
> > Just storing
> > the uuid should be doable (assuming this doesn't change during the
> > lifetime of the buffer), so no need for a callback.
>
> Directly storing the
On Thu, May 14, 2020 at 09:59:52AM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > - for the runtime upcasting the usual approach is to check the ->ops
> > pointer. Which means that would need to be the same for all virtio
> > dma_bufs, which might get a bit awkward. But I'd really prefer we not
> > add
On Thu, May 14, 2020 at 08:40:21AM +0100, Daniel Stone wrote:
> On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> > On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > > On Thu, 14 May 2020 at 08:08, Daniel Vetter
> > > wrote:
> > > I'd be very much in favour of putting the blocking down
On Wed, May 13, 2020 at 10:10:16PM +0200, Wolfram Sang wrote:
> The R-Car DU driver calls drm_vblank_init via some helper functions in
> probe(). From what I checked, most drivers do this as well. I have a
> config now where DU always stays in deferred_probe state because of a
> missing dependency.
On Wed, May 13, 2020 at 10:43:48PM +0100, Emil Velikov wrote:
> With earlier commits, the API no longer discards the const-ness of the
> sysrq_key_op. As such we can add the notation.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: linux-ker...@vger.kernel.org
> Cc: Maarten Lankhorst
> Cc: Ma
On Wed, May 13, 2020 at 10:53:42PM +0100, Emil Velikov wrote:
> Drivers have not seen any love for years.
>
> Be that fixes or improvements, or cosmetics like introducing symbolic
> names, style and code-flow polish.
>
> Seemingly the maintainer has also disappeared years ago :-\
>
> Considering
On Wed, May 13, 2020 at 05:03:11PM +0200, Thomas Zimmermann wrote:
> SHMEM-buffer backing storage is allocated from system memory; which is
> typically cachable. Currently, only virtio uses cachable mappings; udl
> uses its own vmap/mmap implementation for cachable mappings. Other
> drivers default
On Wed, May 13, 2020 at 05:03:12PM +0200, Thomas Zimmermann wrote:
> The udl driver contains an implementation of GEM vmap and mmap
> operations that is identical to the common SHMEM helper; except
> that udl's code does not support writecombine mappings.
>
> Convert udl to regular SHMEM helper fu
On Thu, May 14, 2020 at 09:23:37AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > Currently this seems to work by converting the sgt into a pages array,
> > and then treating it like a native object. Do the right thing and
> > redirect mmap to the exporter
On Thu, May 14, 2020 at 09:25:18AM +0200, Thomas Zimmermann wrote:
> Hi,
>
> given the upcoming removal of this file, I don't know if you really want
> to merge this patch. If so, please see my comment on patch 6 and
Yeah I can wait for your patch to land, I just looked at that series. I'm
kinda
On 14/05/2020 03:17, Laurent Pinchart wrote:
> The meson-dw-hdmi driver needs to access its own context from the
> .mode_valid() operation. It currently gets it from the dev_private field
> of the drm_device retrieved from the connector, which is a hack. Use the
> dw_hdmi context passed to the .mod
On Thu, May 14, 2020 at 09:16:54AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > There's no direct harm, because for the shmem helpers these are noops
> > on imported buffers. The trouble is in the locks these take - I want
> > to change dma_buf_vmap lock
On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
> > - Ditch the ->pages array
> > - Make it a private gem bo, which means no shmem object, which means
> > fireworks if anyone calls drm_gem_object_get_pages. But we've just
>
Hi!
On 5/13/20 11:53 PM, Emil Velikov wrote:
> Drivers have not seen any love for years.
>
> Be that fixes or improvements, or cosmetics like introducing symbolic
> names, style and code-flow polish.
>
> Seemingly the maintainer has also disappeared years ago :-\
>
> Considering nouveau suppo
On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote:
>
> Hi Alex,
>
> On Thu, 30 Apr 2020 at 22:30, Alex Deucher wrote:
> > UAPI:
> > - Add amdgpu UAPI for encrypted GPU memory
> > Used by: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4401
>
> Did this ever go through uAPI review? I
Hi All,
On 14.05.2020 07:25, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 1:33 AM Chun-Kuang Hu wrote:
>> Hi, Daniel:
>>
>> Daniel Vetter 於 2020年5月14日 週四 上午3:45寫道:
>>> On Thu, May 14, 2020 at 12:16:59AM +0800, Chun-Kuang Hu wrote:
Hi, Dave & Daniel:
This include dpi pin mode sw
On Wed, May 13, 2020 at 8:33 AM Marek Szyprowski
wrote:
>
> The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
> returns the number of the created entries in the DMA address space.
> However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
> dma_unmap_sg must b
On Thu, May 14, 2020 at 12:22 PM dillon min wrote:
> > > + /* Gamma */
> > > + mipi_dbi_command(dbi, ILI9341_3GAMMA_EN, 0x00);
> > > + mipi_dbi_command(dbi, MIPI_DCS_SET_GAMMA_CURVE, 0x01);
> > > + mipi_dbi_command(dbi, ILI9341_PGAMMA,
> > > +0x0f,
Hi,
On Thu, 14 May 2020 at 14:36, Alex Deucher wrote:
> On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote:
> > Did this ever go through uAPI review? It's been pushed to the kernel
> > before Mesa review was complete. Even then, Mesa only uses it when
> > behind a magic environment variable, rat
Hi Daniel,
On Thu, May 14, 2020 at 07:25:10AM +0200, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 1:33 AM Chun-Kuang Hu wrote:
> > Daniel Vetter 於 2020年5月14日 週四 上午3:45寫道:
> > > On Thu, May 14, 2020 at 12:16:59AM +0800, Chun-Kuang Hu wrote:
> > > > Hi, Dave & Daniel:
> > > >
> > > > This includ
tree: git://people.freedesktop.org/~gabbayo/linux habanalabs-next
head: 26238fa1d1b5837f4ff047721adbfafed48bf175
commit: f58f37e092abe1577fcc4fd5d29b9b1a533c6e54 [32/36] habanalabs: add gaudi
asic-dependent code
config: i386-randconfig-a002-20200514 (attached as .config)
compiler: gcc-4.9
Hi, Enric:
Enric Balletbo Serra 於 2020年5月14日 週四 上午12:41寫道:
>
> Hi Chun-Kuang,
>
> Missatge de Enric Balletbo i Serra del
> dia dv., 1 de maig 2020 a les 17:25:
> >
> > Use the drm_bridge_connector helper to create a connector for pipelines
> > that use drm_bridge. This allows splitting connector
Hi,
On 5/14/20 11:53 AM, Emil Velikov wrote:
Hi Hans,
On Thu, 30 Apr 2020 at 15:55, Hans de Goede wrote:
Hi,
On 4/30/20 4:52 PM, Ville Syrjälä wrote:
On Thu, Apr 30, 2020 at 02:47:00PM +0100, Emil Velikov wrote:
Hi Hans,
On Fri, 21 Feb 2020 at 17:33, Hans de Goede wrote:
drm_helper_pr
Convert the DT binding documentation for the TI TFP410 DPI-to-DVI
encoder to json-schema.
The 'ti,deskew' is now an unsigned value from 0 to 7 instead of a signed
value from -4 to 3. The rest of the binding is a direct translation from
the old one.
Signed-off-by: Ricardo Cañuelo
---
.../binding
The tfp410 has a data de-skew feature that allows the user to compensate
the skew between IDCK and the pixel data and control signals.
In the driver, the setup and hold times are calculated from the de-skew
value. This retrieves the deskew value from the DT using the proper
datatype and range chec
Group the port definitions of the dvi-converter in a 'ports' node to
make it compliant with the ti,tfp410 binding.
Signed-off-by: Ricardo Cañuelo
---
arch/arm/boot/dts/imx53-cx9020.dts | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/d
Define a 'ports' node for 'dvi: video@39' and use the proper naming for
the powerdown-gpios property to make it compliant with the ti,tfp410
binding.
This fills the minimum requirements to meet the binding requirements,
port endpoints are not defined.
Signed-off-by: Ricardo Cañuelo
---
arch/arm
This series converts the DT binding documentation for the TI TFP410
DPI-to-DVI encoder to json-schema.
Some minor changes were made to two DTs in order to make them compliant
with the binding. These changes shouldn't have any functional effect.
This also fixes a minor bug in the ti-tfp410 driver
On Wed, May 13, 2020 at 5:44 AM Brian Starkey wrote:
>
> Hi Rob,
>
> On Tue, May 12, 2020 at 11:37:14AM -0500, Rob Herring wrote:
> > On Mon, May 04, 2020 at 10:06:28AM +0100, Brian Starkey wrote:
> > > On Fri, May 01, 2020 at 12:01:40PM -0700, John Stultz wrote:
> > > > On Fri, May 1, 2020 at 4:0
On Wed, May 06, 2020 at 03:04:20PM +0800, Xin Ji wrote:
> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> for portable device. It converts MIPI to DisplayPort 1.3 4K.
>
> You can add support to your board with binding.
We have an example in the binding, no reason to also put
Quoting Dave Airlie (2020-05-14 04:28:17)
> On Thu, 14 May 2020 at 03:10, Joonas Lahtinen
> wrote:
> >
> > Ping for merging this? If there are no issues, I'd prefer to pull in
> > next gvt-next and tag the final pull sooner than later.
>
> Can you check that I'm correct and this isn;'t in patchwo
Hi Lubomir
Am Do., 14. Mai 2020 um 00:02 Uhr schrieb Lubomir Rintel :
>
> On a GC860 (both 3D and 2D capable) GPU, kmscube crashes:
>
> # strace -f ~lkundrak/src/kmscube/build/kmscube
> ...
> ioctl(6, DRM_IOCTL_ETNAVIV_PM_QUERY_DOM, 0xbe92b720) = 0
> ioctl(6, DRM_IOCTL_ETNAVIV_PM_QUERY_SI
DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
with a handle, making it easier to debug issues in userspace
applications.
DRM_IOCTL_HANDLE_GET_LABEL lets you read the label associated
with a buffer.
Changes in v2:
- Hoist the IOCTL up into the drm_driver framework
Changes in v3:
Hi
I've been reworking these label'ing patches in conjunction
with their userspace usage that can be found here [1].
The intention is that these patches will be useful for driver
developers and application developers alike in conjuction with
something like the OpenGL Label'ing extension [2].
Chee
Set the default labeling helpers in order to be able
to label the buffers.
Signed-off-by: Rohan Garg
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index 882fecc
The R-Car DU supports inverting the polarity of the output pixel clock.
At the moment the driver hardcodes the clock polarity to drive signals
on the rising edge of the clock. Configure it instead based on the needs
of the display pipeline.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rca
Replace iteration over encoders with iteration over connectors. This is
a bit more aligned with the atomic framework, but more importantly, the
change prepares for code that will need to access the connector.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +++
Hi Geert,
On Thu, May 14, 2020 at 09:31:53AM +0200, Geert Uytterhoeven wrote:
> On Thu, May 14, 2020 at 1:29 AM Laurent Pinchart wrote:
> > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart
> > Acked-by: Maxime Ripard
>
> > --- /dev/null
> > ++
On Thu, May 14, 2020 at 10:15 AM Daniel Stone wrote:
>
> Hi,
>
> On Thu, 14 May 2020 at 14:36, Alex Deucher wrote:
> > On Thu, May 14, 2020 at 5:42 AM Daniel Stone wrote:
> > > Did this ever go through uAPI review? It's been pushed to the kernel
> > > before Mesa review was complete. Even then,
On Thu, May 07, 2020 at 04:07:59PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Spelling out _unlocked for each and every driver is a annoying.
> Especially if we consider how many drivers, do not know (or need to)
> about the horror stories involving struct_mutex.
>
> Just drop the suffi
Hi
Am 14.05.20 um 14:55 schrieb Daniel Vetter:
> On Thu, May 14, 2020 at 09:44:02AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 11.05.20 um 11:35 schrieb Daniel Vetter:
>>> - Ditch the ->pages array
>>> - Make it a private gem bo, which means no shmem object, which means
>>> fireworks if anyo
Hi
Am 14.05.20 um 14:40 schrieb Daniel Vetter:
> On Wed, May 13, 2020 at 05:03:11PM +0200, Thomas Zimmermann wrote:
>> SHMEM-buffer backing storage is allocated from system memory; which is
>> typically cachable. Currently, only virtio uses cachable mappings; udl
>> uses its own vmap/mmap implemen
Hi Neil,
On Thu, May 14, 2020 at 11:15:52AM +0200, Neil Armstrong wrote:
> On 14/05/2020 03:17, Laurent Pinchart wrote:
> > Platform glue drivers for dw_hdmi may need to access device-specific
> > data from their .mode_valid() implementation. They currently have no
> > clean way to do so, and one
Hi,
On Fri, May 1, 2020 at 6:31 AM Kalyan Thota wrote:
>
> "The PM core always increments the runtime usage counter
> before calling the ->suspend() callback and decrements it
> after calling the ->resume() callback"
>
> DPU and DSI are managed as runtime devices. When
> suspend is triggered, PM
Hi, Enric:
Enric Balletbo i Serra 於 2020年5月14日 週四 下午11:42寫道:
>
> Hi Chun-Kuang,
>
> On 14/5/20 16:28, Chun-Kuang Hu wrote:
> > Hi, Enric:
> >
> > Enric Balletbo Serra 於 2020年5月14日 週四 上午12:41寫道:
> >>
> >> Hi Chun-Kuang,
> >>
> >> Missatge de Enric Balletbo i Serra del
> >> dia dv., 1 de maig 202
On Wed, May 13, 2020 at 10:43:49PM +0100, Emil Velikov wrote:
> With earlier commits, the API no longer discards the const-ness of the
> sysrq_key_op. As such we can add the notation.
>
> Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: linux-ker...@vger.kernel.org
> Cc: Jason Wessel
> Cc: Daniel
On 14/05/2020 17:28, Laurent Pinchart wrote:
> Hi Neil,
>
> On Thu, May 14, 2020 at 11:15:52AM +0200, Neil Armstrong wrote:
>> On 14/05/2020 03:17, Laurent Pinchart wrote:
>>> Platform glue drivers for dw_hdmi may need to access device-specific
>>> data from their .mode_valid() implementation. The
From: Ville Syrjälä
To make it easier to figure out what caused a particular debug
message let's print out aux->name.
v2: Convert drm_dp_send_real_edid_checksum() too
Cc: Sam Ravnborg
Signed-off-by: Ville Syrjälä
---
IIRC Sam suggested that I switch to per-device logging functions at the
same
From: Arnd Bergmann
[ Upstream commit 3a3a71f97c30983f1627c2c550d43566e9b634d2 ]
Older compilers warn about initializers with incorrect curly
braces:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_encoder_enable':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing brac
From: Roman Li
[ Upstream commit 80797dd6f1a525d1160c463d6a9f9d29af182cbb ]
[Why]
Wait counter is not being reset for each pipe.
[How]
Move counter reset into pipe loop scope.
Signed-off-by: Roman Li
Reviewed-by: Zhan Liu
Acked-by: Aurabindo Pillai
Signed-off-by: Alex Deucher
Signed-off-by
From: Aurabindo Pillai
[ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ]
[why]
During hotplug, a DP port may be connected to the sink through
passive adapter which does not support DPCD reads. Issuing reads
without checking for this condition will result in errors
[how]
Ensure the li
From: Sung Lee
[ Upstream commit b95e51eb9f2ee7b6d6c3203a2f75122349aa77be ]
[WHY & HOW]
There is a problem in hscale_pixel_rate, the bug
causes DCN to be more optimistic (more likely to underflow)
in upscale cases during prefetch.
This commit ports the fix from DV code to address these issues.
From: Aurabindo Pillai
[ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ]
[why]
During hotplug, a DP port may be connected to the sink through
passive adapter which does not support DPCD reads. Issuing reads
without checking for this condition will result in errors
[how]
Ensure the li
From: Arnd Bergmann
[ Upstream commit 3a3a71f97c30983f1627c2c550d43566e9b634d2 ]
Older compilers warn about initializers with incorrect curly
braces:
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: In function 'sun6i_dsi_encoder_enable':
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:720:8: error: missing brac
Hi Ville.
On Thu, May 14, 2020 at 09:40:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make it easier to figure out what caused a particular debug
> message let's print out aux->name.
>
> v2: Convert drm_dp_send_real_edid_checksum() too
>
> Cc: Sam Ravnborg
> Signed-off-by: Vil
Hi Laurent,
On Thu, May 14, 2020 at 5:17 PM Laurent Pinchart
wrote:
> On Thu, May 14, 2020 at 09:31:53AM +0200, Geert Uytterhoeven wrote:
> > On Thu, May 14, 2020 at 1:29 AM Laurent Pinchart wrote:
> > > Convert the Renesas R-Car LVDS encoder text binding to YAML.
> > >
> > > Signed-off-by: Laure
The following series touches a lot of backlight things.
It starts by migrating users of of_find_backlight_by_node()
over to devm_of_find_backlight() to simplify code and to
use the preferred way to register backlight.
All the functions in the backlight core that is no longer
used by any drivers a
1 - 100 of 206 matches
Mail list logo