Hi,
just a few nits.
Am 25.09.20 um 08:49 schrieb Tian Tao:
> drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
contains -> includes
> already declared in this file, so there is no need to declare struct
declared -> defined
> drm_device in hibm_drm_drv.h.
>
> Signed-off-by
syzbot has reported an issue in the framebuffer layer, where a malicious
user may overflow our built-in font data buffers.
In order to perform a reliable range check, subsystems need to know
`FONTDATAMAX` for each built-in font. Unfortunately, our font descriptor,
`struct console_font` does not co
The sii902x chip family requires IO and core voltages to reach the
correct voltage before chip initialization. Add binding for describing
the two supplies.
Signed-off-by: Alexandru Gagniuc
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 4
1 file changed, 4 insertions(+)
cc back a few others who were unintentionally dropped from the thread earlier.
Someone (at Google) helped me dig into this a little more and they
found a document titled "eDP Backlight Brightness bit alignment" sent
out for review in January 2017. I registered for a new account (google
is a member
The BCM2711 supports higher bpc count than just 8, so let's support it in
our driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 68 +-
drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +-
drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 9 -
3 files cha
Hi!
On Thu, Sep 24, 2020 at 02:42:18PM +, David Laight wrote:
> > On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > > Hi all,
> > >
> > > syzbot has reported [1] a global out-of-bounds read issue in
> > > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
>
On 9/24/20 3:22 PM, Fabio Estevam wrote:
Hi Fabio,
On Thu, Sep 24, 2020 at 5:16 PM Alexandru Gagniuc wrote:
+ ret = regulator_enable(sii902x->cvcc12);
+ if (ret < 0) {
+ dev_err(dev, "Failed to enable cvcc12 supply: %d\n", ret);
+ regulator_disable(sii9
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/video/fbdev/sis/300vtbl.h:1064:28: warning:
‘SiS300_CHTVVCLKSONTSC’ defined but not used [-Wunused-const-variable=]
Reported-by: Hulk Robot
Signed-off-by: Li Heng
---
drivers/video/fbdev/sis/300vtbl.h | 2 --
1 file changed, 2 deletions(-)
The pixel rate is for now quite simple to compute, but with more features
(30 and 36 bits output, YUV output, etc.) will depend on a bunch of
connectors properties.
Let's store the rate we have to run the pixel clock at in our custom
connector state, and compute it in atomic_check.
Signed-off-by:
Hi,
Here's some patches to enable the HDR output in the RPi4 HDMI controller.
This needed a quite intrusive rework in the first patch to allow a CRTC to
have access to the whole DRM state at atomic_enable / atomic_disable time.
Let me know what you think,
Maxime
Maxime Ripard (6):
drm/atomic:
fix warnings reported by make W=1
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:195: warning: cannot
understand function prototype: 'const struct dpu_intr_reg
dpu_intr_set[] = '
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c:252: warning: cannot
understand function prototype: 'const struct d
drivers/video/console/newport_con.c is borrowing FONT_EXTRA_WORDS macros
from drivers/video/fbdev/core/fbcon.h. To keep things simple, move all
definitions into .
Since newport_con now uses four extra words, initialize the fourth word in
newport_set_font() properly.
Cc: sta...@vger.kernel.org
Sig
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
> >
return connection status base on hpd realtime state status
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 13 +++
drivers/gpu/drm/msm/dp/dp_catalog.h | 1 +
drivers/gpu/drm/msm/dp/dp_display.c | 58 -
drivers/gpu/drm/msm/dp/dp_reg.h |
drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_set_audio_infoframe’:
drivers/gpu/drm/vc4/vc4_hdmi.c:334:6: warning: variable ‘ret’ set but not
used [-Wunused-but-set-variable]
Signed-off-by: Tian Tao
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git
On Thu, Sep 24 2020 at 08:32, Steven Rostedt wrote:
> On Thu, 24 Sep 2020 08:57:52 +0200
> Thomas Gleixner wrote:
>
>> > Now as for migration disabled nesting, at least now we would have
>> > groupings of this, and perhaps the theorists can handle that. I mean,
>> > how is this much different that
On Thu, Sep 24, 2020 at 06:45:16PM +0300, Dan Carpenter wrote:
> Smatch has a tool to show where struct members are set.
>
> `~/smatch/smatch_data/db/smdb.py where console_font height`
>
> It's not perfect and this output comes from allmodconfig on yesterday's
> linux-next.
>
> regards,
> dan ca
On 09/24/20 10:49, Daniel Vetter wrote:
[...]
> > > I also thought kernel threads can be distinguished from others, so
> > > userspace shouldn't be able to sneak in and get elevated by accident.
> >
> > I guess maybe you could look at the parent? I still would like to
> > think that we could co
On the SII9022, the IOVCC and CVCC12 supplies must reach the correct
voltage before the reset sequence is initiated. On most boards, this
assumption is true at boot-up, so initialization succeeds.
However, when we try to initialize the chip with incorrect supply
voltages, it will not respond to I2
Hi all,
syzbot has reported [1] a global out-of-bounds read issue in
fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
value in vt_ioctl(), causing fbcon_get_font() to overflow our built-in
font data buffers, declared in lib/fonts/font_*.c:
(e.g. lib/fonts/font_8x8.c)
#def
drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
already declared in this file, so there is no need to declare struct
drm_device in hibm_drm_drv.h.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 --
1 file changed, 2 deletions(-)
diff --git a
If the CRTC driver ever needs to access the full DRM state, it can't do so
at atomic_enable / atomic_disable time since drm_atomic_helper_swap_state
will have cleared the pointer from the struct drm_crtc_state to the struct
drm_atomic_state before calling those hooks.
In order to allow that, let's
fbcon_get_font() is reading out-of-bounds. A malicious user may resize
`vc->vc_font.height` to a large value, causing fbcon_get_font() to
read out of `fontdata`.
fbcon_get_font() handles both built-in and user-provided fonts.
Fortunately, recently we have added FONT_EXTRA_WORDS support for built-i
We'll need to access the connector state in our encoder setup, so let's
just pass the whole DRM state to our private encoder hooks.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 18 ++
drivers/gpu/drm/vc4/vc4_drv.h | 10 +-
drivers/gpu/drm/vc4/vc4_hdm
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Peilin Ye (3):
> > fbdev, newport_con: Move FONT_EXTRA_WORDS macros into linux/font.h
> > Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
> > fbcon: F
When run with a higher bpc than 8, the clock of the HDMI controller needs
to be adjusted. Let's create a connector state that will be used at
atomic_check and atomic_enable to compute and store the clock rate
associated to the state.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.
Since the CRTC setup in vc4 is split between the PixelValves/TXP and the
HVS, only the PV/TXP atomic hooks were updated in the previous commits, but
it makes sense to update the HVS ones too.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_crtc.c | 4 +---
drivers/gpu/drm/vc4/vc4_drv.h
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
>
> On 22/09/2020 09:39, Leon Romanovsky wrote:
> > From: Maor Gottlieb
> >
> > Extend __sg_alloc_table_from_pages to support dynamic allocation of
> > SG table from pages. It should be used by drivers that can't supply
> > all the pa
Hi
Am 25.09.20 um 09:02 schrieb Thomas Zimmermann:
> Hi,
>
> just a few nits.
>
> Am 25.09.20 um 08:49 schrieb Tian Tao:
>> drm_framebuffer.h contains drm/drm_device.h and struct drm_device is
>
> contains -> includes
>
>> already declared in this file, so there is no need to declare struct
>
https://bugzilla.kernel.org/show_bug.cgi?id=204241
waltib...@protonmail.com changed:
What|Removed |Added
CC||waltib...@protonmail.com
--- C
https://bugzilla.kernel.org/show_bug.cgi?id=204241
--- Comment #66 from waltib...@protonmail.com ---
Created attachment 292637
--> https://bugzilla.kernel.org/attachment.cgi?id=292637&action=edit
dmesg 5.8.9-arch2-1
truncated dmesg logs of resume failures on 5.8.9-arch2-1
3 boot/suspend/resume/
Am 25.09.20 um 01:14 schrieb Dave Airlie:
On Thu, 24 Sep 2020 at 22:42, Christian König wrote:
Am 24.09.20 um 07:18 schrieb Dave Airlie:
From: Dave Airlie
All the accel moves do the same pattern here, provide a helper
And exactly that pattern I want to get away from.
Currently this is just
On Wed, 23 Sep 2020 14:57:23 +0300
Tomi Valkeinen wrote:
> We currently have drm_atomic_helper_legacy_gamma_set() helper which can
> be used to handle legacy gamma-set ioctl.
> drm_atomic_helper_legacy_gamma_set() sets GAMMA_LUT, and clears
> CTM and DEGAMMA_LUT. This works fine on HW where we ha
On Wed, 23 Sep 2020 14:57:24 +0300
Tomi Valkeinen wrote:
> omapdrm supports gamma via GAMMA_LUT property. However, the HW we have
> is:
>
> gamma -> ctm -> out
>
> instead of what the model DRM framework uses:
>
> ctm -> gamma -> out
>
> As the following patches add CTM support for omapdrm, l
On Fri, Sep 25, 2020 at 9:39 AM Christian König
wrote:
>
> Am 25.09.20 um 01:14 schrieb Dave Airlie:
> > On Thu, 24 Sep 2020 at 22:42, Christian König
> > wrote:
> >> Am 24.09.20 um 07:18 schrieb Dave Airlie:
> >>> From: Dave Airlie
> >>>
> >>> All the accel moves do the same pattern here, prov
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
>
> On Fri, Sep 25, 2020 at 9:39 AM Christian König
> wrote:
> >
> > Am 25.09.20 um 01:14 schrieb Dave Airlie:
> > > On Thu, 24 Sep 2020 at 22:42, Christian König
> > > wrote:
> > >> Am 24.09.20 um 07:18 schrieb Dave Airlie:
> > >>> From: Da
On Thu, Sep 24, 2020 at 05:15:00PM +0100, Qais Yousef wrote:
> On 09/24/20 10:49, Daniel Vetter wrote:
>
> [...]
>
> > > > I also thought kernel threads can be distinguished from others, so
> > > > userspace shouldn't be able to sneak in and get elevated by accident.
> > >
> > > I guess maybe yo
On Wed, 23 Sep 2020 17:18:52 +0200
Daniel Vetter wrote:
> When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> pull in arbitrary other resources, including CRTCs (e.g. when
> reconfiguring global resources).
>
> But in nonblocking mode userspace has then no idea this happened
On Wed, 23 Sep 2020 12:57:37 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
These debug messages will be especially useful with the flight
recorder, but also without. :-)
...
>
On Thu, Sep 24, 2020 at 04:09:37PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 24, 2020 at 09:38:22AM -0400, Peilin Ye wrote:
> > Hi all,
> >
> > syzbot has reported [1] a global out-of-bounds read issue in
> > fbcon_get_font(). A malicious user may resize `vc_font.height` to a large
> > value
Hi
Am 23.09.20 um 16:33 schrieb Christian König:
> Feel free to add an Acked-by: Christian König
> to all patches which I haven't explicitly reviewed.
Done, thanks.
>
> I would say we should just push this to drm-misc-next now.
It's merged now.
Best regards
Thomas
>
> Thanks for the nice c
On Fri, Sep 25, 2020 at 11:24:46AM +0300, Pekka Paalanen wrote:
> On Wed, 23 Sep 2020 17:18:52 +0200
> Daniel Vetter wrote:
>
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resou
Hopefully we'll have the drm crash recorder RSN, but meanwhile
compositors would like to know a bit better why they get an EBUSY.
v2: Move misplaced hunk to the right patch (Pekka)
Cc: Sean Paul
Cc: Daniel Stone
Cc: Pekka Paalanen
Cc: Simon Ser
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
On 24.09.20 23:50, Dan Williams wrote:
> On Thu, Sep 24, 2020 at 2:42 PM David Hildenbrand wrote:
>>
>>
>>
>>> Am 24.09.2020 um 23:26 schrieb Dan Williams :
>>>
>>> [..]
> I'm not suggesting to busy the whole "virtio" range, just the portion
> that's about to be passed to add_memory_drive
On Fri, Sep 25, 2020 at 04:51:38PM +0800, Tian Tao wrote:
> drm_modeset_lock.h already declares struct drm_device, so there's no
> need to declare it in vc4_drv.h
>
> Signed-off-by: Tian Tao
Just an aside, when submitting patches please use
scripts/get_maintainers.pl to generate the recipient li
On Fri, 25 Sep 2020 10:46:51 +0200
Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
>
> v2: Move misplaced hunk to the right patch (Pekka)
Hi,
both patches
Acked-by: Pekka Paalanen
Tha
Am 25.09.20 um 10:18 schrieb Daniel Vetter:
On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
On Fri, Sep 25, 2020 at 9:39 AM Christian König
wrote:
Am 25.09.20 um 01:14 schrieb Dave Airlie:
On Thu, 24 Sep 2020 at 22:42, Christian König wrote:
Am 24.09.20 um 07:18 schrieb Dave Airlie:
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> These two perf counters represent the total read and write
> GPU bandwidth in terms of 64bits.
>
> The used sequence was taken from Vivante kernel driver.
>
> Signed-off-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_pe
On Fr, 2020-08-14 at 11:05 +0200, Christian Gmeiner wrote:
> This little patch set adds support for the total bandwidth used by HI. The
> basic hi bandwidth read-out is quite simple but I needed to add some little
> clean-ups to make it nice looking.
>
> Christian Gmeiner (4):
> drm/etnaviv: ren
On Do, 2020-09-03 at 21:40 +0100, Robin Murphy wrote:
> Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
> for platform devices"), struct platform_device already provides a
> dma_parms structure, so we can save allocating another one.
>
> Signed-off-by: Robin Murphy
Thanks
Standardize on the dev_ based logging and drop the include of drm_print.h.
Remove useless dsi_color_from_mipi function.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 87 ++-
1 file changed, 45 insertions(+), 42 deletions(-)
diff --git a/driver
On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
>
> Hi Daniel/Arnd.
>
> On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > The fbdev code uses compat_alloc_user_space in a few of its
> > > compat_ioctl handle
Hi
Am 23.09.20 um 16:27 schrieb Christian König:
> Am 23.09.20 um 14:32 schrieb Thomas Zimmermann:
>> The new type struct dma_buf_map represents a mapping of dma-buf memory
>> into kernel space. It contains a flag, is_iomem, that signals users to
>> access the mapped memory with I/O operations ins
On 24/09/2020 14:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
>> On x64 we get:
>>
>> drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning:
>> conversion from 'long unsigned int' to 'unsigne
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend __sg_alloc_table_from_pages to support dynamic allocation of
SG table from pages. It should be used by drivers
On Fri, 25 Sep 2020 at 12:38, Maxime Ripard wrote:
>
> Hi Dave,
>
> On Wed, Sep 23, 2020 at 03:59:04PM +0100, Dave Stevenson wrote:
> > Hi Maxime
> >
> > On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
> > >
> > > The current CRTC state reset hook in vc4 allocates a vc4_crtc_state
> > > struct
The new type struct dma_buf_map represents a mapping of dma-buf memory
into kernel space. It contains a flag, is_iomem, that signals users to
access the mapped memory with I/O operations instead of regular loads
and stores.
It was assumed that DMA buffer memory can be accessed with regular load
an
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use
struct dma_buf_map.
The interfaces used to return a buffer address. This address now gets
stored in an instance of the structure that is given as an additional
argument. The functions return an errno code on errors.
Users of the
Dma-buf provides vmap() and vunmap() for retriving and releasing mappings
of dma-buf memory in kernel address space. The functions operate with plain
addresses and the assumption is that the memory can be accessed with load
and store operations. This is not the case on some architectures (e.g.,
spa
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to
use struct dma_buf_map. The interfaces used to receive a buffer address.
This address is now given in an instance of the structure.
Users of the functions are updated accordingly. This is only an interface
change. It is currently
This patch adds struct dma_buf_map and its helpers to the documentation. A
short tutorial is included.
v3:
* update documentation in a separate patch
* expand docs (Daniel)
* carry-over acks from patch 1
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
Revie
On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> On 24/09/2020 14:48, Laurent Pinchart wrote:
> > Hi Tomi,
> >
> > Thank you for the patch.
> >
> > On Wed, Sep 23, 2020 at 11:30:57AM +0300, Tomi Valkeinen wrote:
> >> On x64 we get:
> >>
> >> drivers/gpu/drm/bridge/cadence/cdns-mh
On Fri, 2020-09-25 at 12:22 +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
> Remove useless dsi_color_from_mipi function.
[]
> diff --git a/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
> b/drivers/gpu/drm/stm/dw_mipi_dsi-stm.c
[]
> - DRM_DEBU
Hi Maxime
Sorry for the delay.
On Wed, 23 Sep 2020 at 09:40, Maxime Ripard wrote:
>
> The HVS FIFOs are currently assigned each time we have an atomic_check
> for all the enabled CRTCs.
>
> However, if we are running multiple outputs in parallel and we happen to
> disable the first (by index) CR
On Fri, Sep 25, 2020 at 03:05:52PM +0300, Tomi Valkeinen wrote:
> On 25/09/2020 15:00, Laurent Pinchart wrote:
> > On Fri, Sep 25, 2020 at 10:36:44AM +0300, Tomi Valkeinen wrote:
> >> On 24/09/2020 14:48, Laurent Pinchart wrote:
> >>> Hi Tomi,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Wed
This patch series attempts to add support for a DP-HDMI2.1 Protocol
Convertor. The VESA spec for the HDMI2.1 PCON are proposed in Errata
E5 to DisplayPort_v2.0:
https://vesa.org/join-vesamemberships/member-downloads/?action=stamp&fileid=42299
The details are mentioned in DP to HDMI2.1 PCON Enum/Con
This patch adds functions to start FRL training for an HDMI2.1 sink,
connected via a PCON as a DP branch device.
This patch also adds a new structure for storing frl training related
data, when FRL training is completed.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.
From: Swati Sharma
The HDMI2.1 extends HFVSBD (HDMI Forum Vendor Specific
Data block) to have fields related to newly defined methods of FRL
(Fixed Rate Link) levels, number of lanes supported, DSC Color bit
depth, VRR min/max, FVA (Fast Vactive), ALLM etc.
This patch adds the new HFVSDB fields
This patch calls functions to check FRL training requirements
for an HDMI2.1 sink, when connected through PCON.
The call is made before the DP link training. In case FRL is not
required or failure during FRL training, the TMDS mode is selected
for the pcon.
Signed-off-by: Ankit Nautiyal
---
driv
From: Swati Sharma
This patch adds support for link status and link recovery. There
are specific DPCD’s defined for link status check and recovery in
case of any issues. PCON will communicate the same using an IRQ_HPD
to source. HDMI sink would have indicated the same to PCON using
SCDC interrupt
This patch adds support for configuring a PCON device,
connected as a DP branched device to enable FRL Link training
with a HDMI2.1 + sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_dp_helper.c | 305
include/drm/drm_dp_helper.h | 81 +
2
From: Swati Sharma
In this patch enabled support for link status and recovery in i915
driver. HDMI link loss indication to upstream DP source is indicated
via IRQ_HPD. This is followed by reading of HDMI link configuration
status (HDMI_TX_LINK_ACTIVE_STATUS). If the PCON → HDMI 2.1 link status
is
From: Swati Sharma
This patch parses MAX_FRL field to get the MAX rate in Gbps that
the HDMI 2.1 panel can support in FRL mode. Source need this
field to determine the optimal rate between the source and sink
during FRL training.
Signed-off-by: Sharma, Swati2
Signed-off-by: Ankit Nautiyal
---
On 25/09/2020 12:58, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 12:41:29PM +0100, Tvrtko Ursulin wrote:
On 25/09/2020 08:13, Leon Romanovsky wrote:
On Thu, Sep 24, 2020 at 09:21:20AM +0100, Tvrtko Ursulin wrote:
On 22/09/2020 09:39, Leon Romanovsky wrote:
From: Maor Gottlieb
Extend
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tools/testing/scatterlist/main.c
index 0a1464181226..4899359a31ac 100644
+++ b/tools/testing/
On 24/09/2020 14:58, Christoph Hellwig wrote:
kmap for !PageHighmem is just a convoluted way to say page_address,
and kunmap is a no-op in that case.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
On 24/09/2020 14:58, Christoph Hellwig wrote:
shmem_pin_map somewhat awkwardly reimplements vmap using
alloc_vm_area and manual pte setup. The only practical difference
is that alloc_vm_area prefeaults the vmalloc area PTEs, which doesn't
seem to be required here (and could be added to vmap us
On 24/09/2020 14:58, Christoph Hellwig wrote:
i915_gem_object_map implements fairly low-level vmap functionality in
a driver. Split it into two helpers, one for remapping kernel memory
which can use vmap, and one for I/O memory that uses vmap_pfn.
The only practical difference is that alloc_v
On Fri, Sep 25, 2020 at 11:34 AM Christian König
wrote:
>
> Am 25.09.20 um 10:18 schrieb Daniel Vetter:
> > On Fri, Sep 25, 2020 at 10:16 AM Daniel Vetter wrote:
> >> On Fri, Sep 25, 2020 at 9:39 AM Christian König
> >> wrote:
> >>> Am 25.09.20 um 01:14 schrieb Dave Airlie:
> On Thu, 24 Sep
On Fri, Sep 25, 2020 at 06:13:00AM -0400, Peilin Ye wrote:
> Hi all!
>
> On Fri, Sep 25, 2020 at 08:46:04AM +0200, Jiri Slaby wrote:
> > > In order to perform a reliable range check, fbcon_get_font() needs to know
> > > `FONTDATAMAX` for each built-in font under lib/fonts/. Unfortunately, we
> > >
Hi Maxime,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to shawnguo/for-next drm-intel/for-linux-next linus/master
anholt/for-next v5.9-rc6 next-20200925]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Am 25.09.20 um 15:17 schrieb Daniel Vetter:
[SNIP]
Eviction is not a problem because the driver gets asked where to put an
evicted BO and then TTM does all the moving.
Hm I guess then I don't quite get where you see the ping-pong
happening, I thought that only happens for evicting stuff.
No,
On 25/09/2020 14:39, Maor Gottlieb wrote:
On 9/25/2020 3:33 PM, Tvrtko Ursulin wrote:
On 25/09/2020 13:18, Maor Gottlieb wrote:
On 9/25/2020 2:55 PM, Jason Gunthorpe wrote:
On Fri, Sep 25, 2020 at 10:13:30AM +0300, Leon Romanovsky wrote:
diff --git a/tools/testing/scatterlist/main.c
b/tool
On Fri, Sep 25, 2020 at 3:40 PM Christian König
wrote:
>
> Am 25.09.20 um 15:17 schrieb Daniel Vetter:
> > [SNIP]
> >> Eviction is not a problem because the driver gets asked where to put an
> >> evicted BO and then TTM does all the moving.
> > Hm I guess then I don't quite get where you see the p
On Thu, 24 Sep 2020 at 14:59, Christoph Hellwig wrote:
>
> i915_gem_object_map implements fairly low-level vmap functionality in
> a driver. Split it into two helpers, one for remapping kernel memory
> which can use vmap, and one for I/O memory that uses vmap_pfn.
>
> The only practical differenc
Compute new timings to get a framerate of 50fps with a pixel clock
@54Mhz.
Signed-off-by: Yannick Fertre
---
drivers/gpu/drm/panel/panel-raydium-rm68200.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-raydium-rm68200.c
b/drivers/gpu
Hi,
whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole
kernel. I guess it auto-selects some architecture-specific feature. That
full rebuild might be avoidable if I could enable that feature permanently.
Any ideas what this could be and how to avoid the full rebuilt?
Best re
On Fri, Sep 25, 2020 at 01:31:51PM +0200, Arnd Bergmann wrote:
> On Thu, Sep 24, 2020 at 10:54 PM Sam Ravnborg wrote:
> >
> > Hi Daniel/Arnd.
> >
> > On Fri, Sep 18, 2020 at 02:48:08PM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 18, 2020 at 12:08:10PM +0200, Arnd Bergmann wrote:
> > > > The fbde
Hi Yannick.
On Fri, Sep 25, 2020 at 12:22:33PM +0200, Yannick Fertre wrote:
> Standardize on the dev_ based logging and drop the include of drm_print.h.
The patchs filas to drop the include mentioned here.
> Remove useless dsi_color_from_mipi function.
IMO the dsi_color_from_mipi() was nice, and
Hi
Am 29.06.20 um 10:40 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:03PM +0200, Thomas Zimmermann wrote:
>> The memcpy's destination buffer might have a different pitch than the
>> source. Support different pitches as function argument.
>>
>> Signed-off-by: Thomas Zimmermann
>
> Revie
Maybe MMU notifiers? But honestly I don't know for sure.
Christian.
Am 25.09.20 um 16:29 schrieb Thomas Zimmermann:
Hi,
whenever I change the option CONFIG_AMDGPU, I have to rebuild the whole
kernel. I guess it auto-selects some architecture-specific feature. That
full rebuild might be avoidab
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 22 +++
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 29 +++
Just check earlier if a BO can be page faulted in the first place.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 98a00
Implement the fault handler ourself using the provided TTM functions.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 20 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 40 +++---
3 file
Another one bites the dust.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 22 --
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 25 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 991ef132e10
We already implemented the fault handler ourself,
just open code what is necessary here.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 50 ++-
drivers/gpu/drm/nouveau/nouveau_bo.h | 1 +
drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++---
3 f
Hi Daniel
Am 29.06.20 um 11:06 schrieb Daniel Vetter:
> On Thu, Jun 25, 2020 at 02:00:05PM +0200, Thomas Zimmermann wrote:
>> The simplekms driver is a DRM driver for simplefb framebuffers as
>> provided by the kernel's boot code. This driver enables basic
>> graphical output on many different gra
Hi Christian
Am 25.09.20 um 16:54 schrieb Christian König:
> Maybe MMU notifiers? But honestly I don't know for sure.
I checked. In my current config MMU_NOTIFIERS is y and DRM_AMDGPU is n.
So it shouldn't have triggered the rebuilds, I guess.
Anyway, thanks for trying to help.
Best regards
Tho
Hi all,
Friendly ping: who can take this?
Thanks
--
Gustavo
On 9/10/20 05:21, Gustavo A. R. Silva wrote:
> Fix inconsistent IS_ERR and PTR_ERR in i915_gem_object_copy_blt().
>
> The proper pointer to be passed as argument to PTR_ERR() is vma[1].
>
> This bug was detected with the help of Cocci
1 - 100 of 131 matches
Mail list logo
