On Thu, May 14, 2020 at 1:39 AM Laurent Pinchart
wrote:
> From: Fabrizio Castro
>
> Document RZ/G2E support for property renesas,companion.
>
> Signed-off-by: Fabrizio Castro
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Laurent Pinchart
> --- a/Documentation/devicetree/bindings/display/br
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?
Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
On Thursday, May 14, 2020 12:58 AM, Laurent Pinchart
wrote:
> The zpos property is used by userspace to sort the order of planes.
> While the property is not mandatory for drivers to implement, mixing
> planes with and without zpos confuses userspace, and shall not be
> allowed. Clarify this in
Hi Bartlomiej and Laurent Pinchart, can I have your ack for merging
this via drm-intel along
with the rest of the series, please?
BR,
G.G.
On Thu, 2020-05-14 at 09:07 +0300, Gwan-gyeong Mun wrote:
> It adds an unpack only function for DRM infoframe for dynamic range
> and
> mastering infoframe r
Added state readout for DP HDR Metadata Infoframe SDP.
v9: Rebased
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/g
Added state readout for DP VSC SDP and enabled state validation
for DP VSC SDP.
v2: Minor style fix
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
v4: Use struct drm_device logging macros
v10: Skip checking of VSC SDP when a crtc config has psr.
Signed-off-by: Gwan-gyeong Mu
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 SDPs (Secondary Data Packet) that uses
computed configs
Call intel_dp_set_infoframes() function on pipe updates to make sure
that we send VSC SDP and HDR Metadata Infoframe SDP (when applicable)
on fastsets.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
dif
Dump out the HDMI Dynamic Range and Mastering (DRM) infoframe in the
normal crtc state dump.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display
In order to use computed config for DP SDPs (DP VSC SDP and DP HDR Metadata
Infoframe SDP), it replaces intel_dp_vsc_enable() function and
intel_dp_hdr_metadata_enable() function to intel_dp_set_infoframes()
function.
And it removes unused functions.
Before:
intel_dp_vsc_enable() and intel_dp_hdr
Dump out the DP VSC SDP in the normal crtc state dump
v3: Replace a structure name to drm_dp_vsc_sdp from intel_dp_vsc_sdp
Use drm core's DP VSC SDP logging function
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
It adds an unpack only function for DRM infoframe for dynamic range and
mastering infoframe readout.
It unpacks the information data block contained in the binary buffer into
a structured frame of the HDMI Dynamic Range and Mastering (DRM)
information frame.
In contrast to hdmi_drm_infoframe_unpac
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it uses a new psr vsc sdp compute routine.
Because PSR routine has its own scenario and timings of writing a VSC SDP,
the current PSR routine needs to have its own drm_dp_vsc_sdp structure
member variable on struct i915_psr.
In
Call intel_dp_set_infoframes(false) function on intel_ddi_post_disable_dp()
to make sure not to send VSC SDP and HDR Metadata Infoframe SDP.
v5: Polish commit message [Uma]
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 ++
1 file chang
Dump out the DP HDR Metadata Infoframe SDP in the normal crtc state dump.
HDMI Dynamic Range and Mastering (DRM) infoframe and DP HDR Metadata
Infoframe SDP use the same member variable in infoframes of crtc state.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i91
Compared to implementation of DP and HDMI's encoder->infoframes_enabled,
the lspcon's implementation returns its active state. (we expect enabled
infoframe states of HW.) It leads to pipe state mismatch error
when ddi_get_config is called.
Because the current implementation of lspcon is not ready
In order to use a common VSC SDP Colorimetry calculating code on PSR,
it adds a compute routine for PSR VSC SDP.
As PSR routine can not use infoframes.vsc of crtc state, it also adds new
writing of DP SDPs (Secondary Data Packet) for PSR.
PSR routine has its own scenario and timings of writing a VS
When receiving video it is very useful to be able to log DP VSC SDP.
This greatly simplifies debugging.
v2: Minor style fix
v3: Move logging functions to drm core [Jani N]
v5: Rebased
v10: Rebased
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_dp_helper.c | 174
It adds code to read the DP SDPs from the video DIP and unpack them into
the crtc state.
It adds routines that read out DP VSC SDP and DP HDR Metadata Infoframe SDP
In order to unpack DP VSC SDP, it adds intel_dp_vsc_sdp_unpack() function.
It follows DP 1.4a spec. [Table 2-116: VSC SDP Header Byte
https://bugzilla.kernel.org/show_bug.cgi?id=207667
alek...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 swap, config mipi_tx current and impedance,
> > >
Hi Dave.
On Thu, May 14, 2020 at 01:35:22PM +1000, Dave Airlie wrote:
> On Thu, 7 May 2020 at 04:57, Sam Ravnborg wrote:
> >
> > Hi Harigovindan
> >
> > On Wed, Apr 29, 2020 at 11:15:14AM +0530, Harigovindan P wrote:
> > > Add support for Visionox panel driver.
> > >
> > > Signed-off-by: Harigovi
Hi Dave and Daniel,
This one looks big, but it actually includes the one I had
sent last week, but probably too late on Thursday. Sorry.
There are various fixes acummulated here around preemption,
timeslices, fences and vma unbind, mostly for GPU hangs,
and deadlocks. There's also Some display wo
[Why]
It's useful to know the min and max vrr range for IGT testing.
[How]
Expose the min and max vfreq for the connector via a debugfs file on the
connector, "vrr_range".
Example usage: cat /sys/kernel/debug/dri/0/DP-1/vrr_range
v5:
* Rename to vrr_range to match AMD debugfs
v4:
* Rebase
v3:
*
Hi Dave, Daniel,
Fixes for 5.7.
The following changes since commit a9fe6f18cde03c20facbf75dc910a372c1c1025b:
Merge tag 'drm-misc-fixes-2020-05-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2020-05-08 15:04:25
+1000)
are available in the Git repository at:
git://people
On Thu, 7 May 2020 at 04:57, Sam Ravnborg wrote:
>
> Hi Harigovindan
>
> On Wed, Apr 29, 2020 at 11:15:14AM +0530, Harigovindan P wrote:
> > Add support for Visionox panel driver.
> >
> > Signed-off-by: Harigovindan P
> > Reviewed-by: Matthias Kaehlcke
>
> Thanks for your persistence on this.
>
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/dts/dove.dtsi only uses the 'core' clock.
arch/arm/boot/dts/stm32mp157.dtsi us
Hello,
Just a few misc changes related to Renesas R-Car DU and associated
bridges.
The following changes since commit 3fd911b69b3117e03181262fc19ae6c3ef6962ce:
Merge tag 'drm-misc-next-2020-05-07' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2020-05-08 15:17:08
+1000)
are av
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 patchwork. I've
checked both the dri-devel and intel-gfx patchw
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 .mode_valid() operation instead.
Signed-off-by: Laurent
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 retrieved from the connector.
Pass the dw_hdmi pointer to
From: Fabrizio Castro
Document RZ/G2E support for property renesas,companion.
Signed-off-by: Fabrizio Castro
Reviewed-by: Laurent Pinchart
Signed-off-by: Laurent Pinchart
---
Changes compared to RFC:
- Rebased on top of YAML conversion
---
.../devicetree/bindings/display/bridge/renesas,lvds
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 swap, config mipi_tx current and impedance,
> > convert mtk-dpi to drm_bridge API, and some fixup.
> >
> > The following
Convert the Renesas R-Car LVDS encoder text binding to YAML.
Signed-off-by: Laurent Pinchart
Acked-by: Maxime Ripard
---
Changes since v1:
- Mention RZ/G1 and R2/G2 explicitly
- Drop the part numbers in comments, only keep the SoC names
---
.../bindings/display/bridge/renesas,lvds.txt | 85 -
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
---
.../display/bridge/thine,thc63lvd1024.yaml | 16 +++-
1 file changed, 11 insertions(+), 5 d
The zpos property is used by userspace to sort the order of planes.
While the property is not mandatory for drivers to implement, mixing
planes with and without zpos confuses userspace, and shall not be
allowed. Clarify this in the documentation and warn at runtime if the
drivers mixes planes with
On Wed, May 13, 2020 at 10:43:51PM +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: "Paul E. McKenney"
> Cc: J
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
> ability for drivers to add/remove attribute groups easily.
>
> This is part of my driv
As talked about in commit c2bfc223882d ("drm/bridge: ti-sn65dsi86:
Remove the mystery delay"), the normal HPD pin on ti-sn65dsi86 is
kinda useless, at least for embedded DisplayPort (eDP). However,
despite the fact that the actual HPD pin on the bridge is mostly
useless for eDP, the concept of H
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has a dedicated hardware
HPD (Hot Plug Detect) pin on it, but it's mostly useless for eDP
because of excessive debouncing in hardware. Specifically there is no
way to disable the debouncing and for eDP debouncing hurts you because
HPD is just used for k
This moves the bindings over, based a lot on toshiba,tc358768.yaml.
Unless there's someone known to be better, I've set the maintainer in
the yaml as the first person to submit bindings.
Signed-off-by: Douglas Anderson
Reviewed-by: Stephen Boyd
---
I removed Stephen's review tag on v5 since I sq
The ti-sn65dsi86 MIPI DSI to eDP bridge chip has 4 pins on it that can
be used as GPIOs in a system. Each pin can be configured as input,
output, or a special function for the bridge chip. These are:
- GPIO1: SUSPEND Input
- GPIO2: DSIA VSYNC
- GPIO3: DSIA HSYNC or VSYNC
- GPIO4: PWM
Let's expos
From: Emil Velikov
Date: Wed, 13 May 2020 22:43:47 +0100
> 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: "David S. Miller"
> Cc: sparc
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 supports all that hardware (modulo nv03) just mark
these as obsolete/
On Wed, May 13, 2020 at 6: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
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 Thompson
Cc: kgdb-bugrep...@lists.sourceforge.net
Signed-off-by: Emil Velikov
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: "David S. Miller"
Cc: sparcli...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in th
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: "Paul E. McKenney"
Cc: Josh Triplett
Cc: r...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please
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: Thomas Bogendoerfer
Cc: linux-m...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in
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: Maxime Ripard
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Signed
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 Brown
Cc: linux...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Pleas
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: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-...@lists.ozlabs.org
Sig
Export a pointer to the sysrq_get_key_op(). This way we can cleanly
unregister it, instead of the current solutions of modifuing it inplace.
Since __sysrq_get_key_op() is no longer used externally, let's make it
a static function.
This patch will allow us to limit access to each and every sysrq o
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: Richard Henderson
Cc: Ivan Kokshaysky
Cc: Matt Turner
Cc: linux-al...@vger.kernel.org
Signed-off-by:
The user is not supposed to thinker with the underlying sysrq_key_op.
Make that explicit by adding a handful of const notations.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in the CC list, as I'm not subscribed to the lis
All the users threat them as immutable - annotate them as such.
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Emil Velikov
---
Please keep me in the CC list, as I'm not subscribed to the list.
IMHO it would be better if this gets merged this via the tty
On Wednesday 13. May 2020 09.37.49 Neil Armstrong wrote:
> Hi Paul,
>
> I'm one of the drm/bridge maintainer and, with Jernel & Jonas, we did most
> of the changes on the dw-hdmi driver recently for the Amlogic, Rockchip &
> Allwinner platforms.
Thanks for following up to my message!
> On 12/05/
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #60 from Jordan Maris (jman6...@gmail.com) ---
Created attachment 289129
--> https://bugzilla.kernel.org/attachment.cgi?id=289129&action=edit
dmesg log on suspend
--
You are receiving this mail because:
You are watching the assigne
On Thu, May 14, 2020 at 12:16:59AM +0800, Chun-Kuang Hu wrote:
> Hi, Dave & Daniel:
>
> This include dpi pin mode swap, config mipi_tx current and impedance,
> convert mtk-dpi to drm_bridge API, and some fixup.
>
> The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
> L
On Wed, May 13, 2020 at 8:12 PM Wambui Karuga wrote:
>
>
>
> On Wed, 13 May 2020, Thomas Zimmermann wrote:
>
> > Hi
> >
> > Am 13.05.20 um 13:41 schrieb Wambui Karuga:
> >> Introduce the ability to track requests for the addition of drm debugfs
> >> files at any time and have them added all at onc
Hi Vinod,
Few high-level comments:
- handful of functions always return 0 and the return value is never
checked - switch to return void
- annotate all (nearly) arrays as static const
- consistently use multi_reg_write - in some cases non-const array
will be fine, overwriting a few entries as ne
Quoting Nathan Chancellor (2020-05-13 19:23:40)
> When building with clang:
>
> drivers/gpu/drm/i915/gt/gen8_ppgtt.c:392:24: warning: duplicate
> 'inline' declaration specifier [-Wduplicate-decl-specifier]
> declaration specifier [-Wduplicate-decl-specifier]
> static __always_inline inline voi
On Wed, May 13, 2020 at 04:08:38AM -0700, Modem, Bhanuprakash wrote:
> -Original Message-
> From: Navare, Manasi D
> Sent: Wednesday, May 13, 2020 11:05 AM
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Modem, Bhanuprakash ; Navare, Manasi D
> ; Jani Nikula ;
On Wed, May 13, 2020 at 10:32:56AM -0400, Andrey Grodzovsky wrote:
>
> On 5/11/20 5:54 AM, Daniel Vetter wrote:
> > On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
> > > This RFC is a more of a proof of concept then a fully working solution as
> > > there are a few unresolved i
Hi Daniel
Am 13.05.20 um 17:49 schrieb Daniel Vetter:
> 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 writec
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.
Regards, Joonas
Quoting Joonas Lahtinen (2020-04-30 15:49:04)
> Hi Dave & Daniel,
>
> Fix for performance regression GitLab #1698: Iris Plus 655 and
> 4K screen. Missing w
> Ok, but what does that mean for us?
>
> You need to say why you are sending a patch, otherwise we will guess wrong.
In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does
user_access_begin() without doing access_ok(Checks if a user space pointer is
valid) first.
A local attacker
On Wed, May 13, 2020 at 12:08 PM Lubomir Rintel wrote:
>
> There might be good reasons why the getting a clock failed. To treat the
> clocks as optional we're specifically only interested in ignoring -ENOENT,
> and devm_clk_get_optional() does just that.
>
> Signed-off-by: Lubomir Rintel
> ---
>
system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200513-181150
base: https://git.kernel.org/pub
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 operations across
> multiple bridges when necessary, instead of having the
On Wed, Mar 11, 2020 at 08:20:04PM +0900, David Stevens wrote:
> Add support for UUID-based resource sharing mechanism to virtgpu. This
> implements the new virtgpu commands and hooks them up to dma-buf's
> get_uuid callback.
>
> Signed-off-by: David Stevens
> ---
> drivers/gpu/drm/virtio/virtgp
Hi, Dave & Daniel:
This include dpi pin mode swap, config mipi_tx current and impedance,
convert mtk-dpi to drm_bridge API, and some fixup.
The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:
Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)
are available in the Git repository
the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Vinod-Koul/Add-LT9611-DSI-to-HDMI-bridge/20200513-181150
base: https://git.kernel.o
Hi Lubomir,
On Wed, May 13, 2020 at 12:08 PM Lubomir Rintel wrote:
> /* Get Clocks: */
> - gpu->clk_reg = devm_clk_get(&pdev->dev, "reg");
> + gpu->clk_reg = devm_clk_get_optional(&pdev->dev, "reg");
> DBG("clk_reg: %p", gpu->clk_reg);
> if (IS_ERR(gpu->clk_re
On Wed, 13 May 2020 at 21:16, Daniel Vetter wrote:
>
> On Wed, May 13, 2020 at 02:51:12PM +0200, Greg KH wrote:
> > On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
> > >
> > > Thank you Greg for the comments.
> > > On 5/12/2020 2:22 PM, Greg KH wrote:
> > > > On Fri, May 08, 202
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 Wed, May 13, 2020 at 02:51:12PM +0200, Greg KH wrote:
> On Wed, May 13, 2020 at 05:40:26PM +0530, Charan Teja Kalla wrote:
> >
> > Thank you Greg for the comments.
> > On 5/12/2020 2:22 PM, Greg KH wrote:
> > > On Fri, May 08, 2020 at 12:11:03PM +0530, Charan Teja Reddy wrote:
> > >> The follow
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 share exported objects. The new operation allows
> the importing driver to query the exporting driver for the UUID which
> identifies the underl
Am 13.05.20 um 17:03 schrieb Thomas Zimmermann:
> 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 to writecombine
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 functions. There's no reason
to have udl behave differently from all other SHME
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 to writecombine mappings.
Use cached mappings by default. The exception i
This patchset complements Daniel's recent patches for SHMEM. [1]
By default SHMEM maps pages using writecombine. Only virtio sets the
SHMEM implmentation to use cached mappings. Udl implements its own
vmap/mmap functions, which always maps pages with caching.
Unify the settings by switching the S
On 5/11/20 5:54 AM, Daniel Vetter wrote:
On Sat, May 09, 2020 at 02:51:44PM -0400, Andrey Grodzovsky wrote:
This RFC is a more of a proof of concept then a fully working solution as there
are a few unresolved issues we are hopping to get advise on from people on the
mailing list.
Until now ex
On 28/04/2020 15:17, Bernard Zhao wrote:
> pm_resump api did not handle drm_mode_config_helper_resume error.
> This change add handle to return drm_mode_config_helper_resume`s
> error number. This code logic is aligned with api pm_suspend.
> After this change, the code maybe a bit readable.
>
> Si
Hi Marek,
Thank you for the patch.
On Wed, May 13, 2020 at 03:32:36PM +0200, 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_
Hi Laurent,
On mié 13-05-2020 17:08:32, Laurent Pinchart wrote:
> The driver doesn't apply any setting to the device :-) The ti,deskew
> property is meant to report the deskew settings selected by the chip's
> configuration pins, not to set a value to be programmed to the device.
Oh, I see, thank
Hi
Am 13.05.20 um 13:41 schrieb Wambui Karuga:
> Introduce the ability to track requests for the addition of drm debugfs
> files at any time and have them added all at once during
> drm_dev_register().
>
> Drivers can add drm debugfs file requests to a new list tied to drm_device.
> During drm_de
Hi Ricardo,
On Wed, May 13, 2020 at 01:09:57PM +0200, Ricardo Cañuelo wrote:
> On mié 06-05-2020 18:53:20, Laurent Pinchart wrote:
> > I didn't if I remember correctly, I just mapped it to the hardware
> > features. The hardware register indeed takes a value between 0 and 7,
> > and that is mapped
Hello Christian!
On 5/13/20 3:44 PM, Christian Zigotzky wrote:
> AGP mode/support is deactivated on PowerPC and it doesn't work reliable
>
> And what does these lines mean:
AGP mode is actually disabled in the Radeon driver for PowerPC as Alex has
pointed
out earlier in this thread [1]. You
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 be called with the original number of the entries
passed to the dma_
Replace the current hand-crafted code for extracting pages and DMA
addresses from the given scatterlist by the much more robust
code based on the generic scatterlist iterators and recently
introduced sg_table-based wrappers. The resulting code is simple and
easy to understand, so the comment descri
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 be called with the original number of the entries
passed to the dma_
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 be called with the original number of the entries
passed to the dma_
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 be called with the original number of the entries
passed to the dma_
Use recently introduced common wrappers operating directly on the struct
sg_table objects and scatterlist page iterators to make the code a bit
more compact, robust, easier to follow and copy/paste safe.
No functional change, because the code already properly did all the
scaterlist related calls.
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 be called with the original number of the entries
passed to the dma_
Use common helper for converting a sg_table object into struct
page pointer array.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@s
Use common helper for checking the contiguity of the imported dma-buf.
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v5 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/linux-iommu/20200513132114.6046-1-m.szyprow...@samsung.com/T
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 be called with the original number of the entries
passed to the dma_
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 be called with the original number of the entries
passed to the dma_
1 - 100 of 220 matches
Mail list logo
