On 6/24/20 2:11 AM, Greg KH wrote:
On Tue, Jun 23, 2020 at 11:04:30PM -0400, Andrey Grodzovsky wrote:
On 6/23/20 2:05 AM, Greg KH wrote:
On Tue, Jun 23, 2020 at 12:51:00AM -0400, Andrey Grodzovsky wrote:
On 6/22/20 12:45 PM, Greg KH wrote:
On Mon, Jun 22, 2020 at 12:07:25PM -0400, Andrey
> > > Thanks for the review. Unfortunately only the first vmbus message
> > > take
> > > effect and subsequent calls are ignored. I originally implemented
> > > using
> > > vram helpers but I figured out calling this vmbus message again
> > > won't
> > > change the vram location.
>
> /me
Use generic names for the quirks to make it clear it is not just about
the IOMMU, it's about DMA access in general.
changes from v1:
added patch 2
Michael S. Tsirkin (2):
virtio: VIRTIO_F_IOMMU_PLATFORM -> VIRTIO_F_ACCESS_PLATFORM
virtio: virtio_has_iommu_quirk ->
Now that the corresponding feature bit has been renamed,
rename the quirk too - it's about special ways to
do DMA, not necessarily about the IOMMU.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp"
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
This got me confused for a bit while looking over this code: I had been
planning on adding some blocking function calls into this function, but
seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it
very clear whether or not that would actually be safe.
So I went ahead and
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary
Nvidia released some documentation on how CRC support works on their
GPUs, hooray!
So: this patch series implements said CRC support in nouveau, along with
adding some special debugfs interfaces for some relevant igt-gpu-tools
tests (already on the ML).
First - we add some new functionality to
Hi Daniel,
On Wed, Jun 24, 2020 at 09:23:04AM +0200, Daniel Vetter wrote:
> On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> > > > The DRM
From: Bhanuprakash Modem
v2:
* Rebase (Manasi)
As both VRR min and max are already part of drm_display_info,
drm can expose this VRR range for each connector.
Hence this logic should move to core DRM.
This reverts commit 727962f030c23422a01e8b22d0f463815fb15ec4.
Signed-off-by: Bhanuprakash
Hi Dave, Daniel,
Fixes for 5.8.
The following changes since commit 48778464bb7d346b47157d21ffde2af6b2d39110:
Linux 5.8-rc2 (2020-06-21 15:45:29 -0700)
are available in the Git repository at:
git://people.freedesktop.org/~agd5f/linux tags/amd-drm-fixes-5.8-2020-06-24
for you to fetch
Hi Andrzej,
On Wed, Jun 24, 2020 at 04:03:30PM +0200, Andrzej Hajda wrote:
> On 24.06.2020 15:33, Laurent Pinchart wrote:
> > On Wed, Jun 24, 2020 at 01:41:27PM +0200, Andrzej Hajda wrote:
> >> Using probe_err code has following advantages:
> >> - shorter code,
> >> - recorded defer probe reason
Hi Evan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: d86eab497ead0df7157704c0ed540652d6ba7ddc
commit: 5872ef0b03247fe659226973998ff28e835afbe4 [333/496] drm/amd/powerplay:
forbid to use pr_err/warn/info/debug
config:
https://bugzilla.kernel.org/show_bug.cgi?id=206475
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
https://bugzilla.kernel.org/show_bug.cgi?id=206475
--- Comment #15 from Andrew Ammerlaan (andrewammerl...@riseup.net) ---
So today it was *really* hot, and I had this issue occur a couple of times.
(The solution with the extra fans was nice and all, but not enough to prevent
it entirely)
On Wed, Jun 24, 2020 at 4:57 AM Kalyan Thota wrote:
>
> This change enables dither block for primary interface
> in display.
>
> Enabled for 6bpc in the current version.
>
> Signed-off-by: Kalyan Thota
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 45 +
>
On Wed, Jun 24, 2020 at 3:31 PM Daniel Vetter wrote:
>
> On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wrote:
> >
> > On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
> > >
> > > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > > Hi Sam,
> > > >
> > > > On Sun, Jun 21,
On 24.06.2020 17:16, Robin Murphy wrote:
> On 2020-06-24 16:04, Mark Brown wrote:
>> On Wed, Jun 24, 2020 at 03:25:33PM +0100, Robin Murphy wrote:
>>
>>> And yeah, anyone who pipes up suggesting that places where an
>>> ERR_PTR value
>>> could be passed to probe_err() could simply refactor
On Fri, Jun 12, 2020 at 09:05:35AM +0200, Daniel Vetter wrote:
> Just some tiny edits:
> - fix link to struct dma_fence
> - give slightly more meaningful title - the polling here is about
> implicit fences, explicit fences (in sync_file or drm_syncobj) also
> have their own polling
>
> v2: I
On Wed, Jun 24, 2020 at 5:24 PM Alex Deucher wrote:
>
> On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
> >
> > On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > > Hi Sam,
> > >
> > > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > > On Tue, May 26,
https://bugzilla.kernel.org/show_bug.cgi?id=204241
poinck (an...@poinck.de) changed:
What|Removed |Added
CC||an...@poinck.de
--- Comment
On Wed, Jun 24, 2020 at 08:30:25PM +0200, Boris Brezillon wrote:
> Hello Dan,
>
> On Wed, 24 Jun 2020 20:58:06 +0300
> Dan Carpenter wrote:
>
> > Hello Boris Brezillon,
> >
> > The patch 033bfe7538a1: "drm/vc4: dsi: Fix bridge chain handling"
> > from Dec 27, 2019, leads to the following
Hello Dan,
On Wed, 24 Jun 2020 20:58:06 +0300
Dan Carpenter wrote:
> Hello Boris Brezillon,
>
> The patch 033bfe7538a1: "drm/vc4: dsi: Fix bridge chain handling"
> from Dec 27, 2019, leads to the following static checker warning:
>
> drivers/gpu/drm/vc4/vc4_dsi.c:758
Hello Boris Brezillon,
The patch 033bfe7538a1: "drm/vc4: dsi: Fix bridge chain handling"
from Dec 27, 2019, leads to the following static checker warning:
drivers/gpu/drm/vc4/vc4_dsi.c:758 vc4_dsi_encoder_disable()
warn: iterator used outside loop: 'iter'
Hi,
On Thu, Jun 18, 2020 at 10:52:09AM -0700, Rob Clark wrote:
> On Fri, Jun 5, 2020 at 9:26 PM Sharat Masetty wrote:
> >
> > 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
Hi Dave,
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-5.8-rc3
for you to fetch changes up to
Hi Lee.
On Wed, Jun 24, 2020 at 04:43:21PM +0100, Lee Jones wrote:
> On Wed, 24 Jun 2020, Sam Ravnborg wrote:
>
> > Hi Lee.
> >
> > On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote:
> > > Attempting to clean-up W=1 kernel builds, which are currently
> > > overwhelmingly riddled with
On Wed, 24 Jun 2020, Sam Ravnborg wrote:
> Hi Lee.
>
> On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote:
> > Attempting to clean-up W=1 kernel builds, which are currently
> > overwhelmingly riddled with niggly little warnings.
> >
> > Lee Jones (8):
> > backlight: lms501kf03: Remove
Hello Angelo,
thanks for the patch.
Tested-by: Yannick Fertre
Tested OK on STM32MP1-DISCO, DSI v1.31
Best regards
On 4/6/20 3:49 PM, Angelo Ribeiro wrote:
> Add support for the video pattern generator (VPG) BER pattern mode and
> configuration in runtime.
>
> This enables using the debugfs
Hi Lee.
On Wed, Jun 24, 2020 at 03:57:13PM +0100, Lee Jones wrote:
> Attempting to clean-up W=1 kernel builds, which are currently
> overwhelmingly riddled with niggly little warnings.
>
> Lee Jones (8):
> backlight: lms501kf03: Remove unused const variables
> backlight: lcd: Add missing
On Wed, Jun 24, 2020 at 04:00:34PM +0100, Robin Murphy wrote:
> Be thankful... And count me in as one of those miserable users; here's one
> of mine being bad enough without even printing any specific messages about
> deferring ;)
> [robin@weasel-cheese ~]$ dmesg | grep dwmmc
> [3.046297]
On Wed, Jun 24, 2020 at 3:23 AM Daniel Vetter wrote:
>
> On Wed, Jun 24, 2020 at 04:12:09AM +0300, Laurent Pinchart wrote:
> > Hi Sam,
> >
> > On Sun, Jun 21, 2020 at 10:40:00AM +0200, Sam Ravnborg wrote:
> > > On Tue, May 26, 2020 at 04:15:05AM +0300, Laurent Pinchart wrote:
> > > > The DRM CRTC
On Wed, Jun 10, 2020 at 12:12 PM Lukasz Luba wrote:
>
> Add support for other devices than CPUs. The registration function
> does not require a valid cpumask pointer and is ready to handle new
> devices. Some of the internal structures has been reorganized in order to
> keep consistent view (like
Applied. Thanks!
Alex
On Wed, Jun 24, 2020 at 8:07 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is an off-by-one bounds check on the index into arrays
> table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that
> can lead to reads and writes outside of arrays. Fix the
On Wed, Jun 24, 2020 at 10:54 AM Colin King wrote:
>
> From: Colin Ian King
>
> In the cases where adev->jpeg.num_jpeg_inst is zero or the condition
> adev->jpeg.harvest_config & (1 << i) is always non-zero the variable
> ret is never set to an error condition and the function returns
> an
On 2020-06-24 16:04, Mark Brown wrote:
On Wed, Jun 24, 2020 at 03:25:33PM +0100, Robin Murphy wrote:
And yeah, anyone who pipes up suggesting that places where an ERR_PTR value
could be passed to probe_err() could simply refactor IS_ERR() checks with
more uses of the god-awful
Applied. Thanks!
Alex
On Wed, Jun 24, 2020 at 10:32 AM Nirmoy wrote:
>
> Acked-by: Nirmoy Das
>
>
> Thanks,
>
> Nirmoy
>
> On 6/24/20 4:14 PM, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the goto statement is skipping over a lot of setup code
> > because it is outside of an
Hello Angelo,
thank for patch.
Reviewed-by: Yannick Fertre
On 4/3/20 3:30 PM, Angelo Ribeiro wrote:
> dw-mipi-dsi does not use any definition from drm_probe_helper.
>
> Coverity output:
> Event unnecessary_header:
> Including .../include/drm/drm_probe_helper.h does not provide any
> needed
Fixes W=1 warnings:
drivers/video/backlight/qcom-wled.c:1294:34: warning: ‘wled4_string_cfg’
defined but not used [-Wunused-const-variable=]
1294 | static const struct wled_var_cfg wled4_string_cfg = {
| ^~~~
drivers/video/backlight/qcom-wled.c:1290:34: warning:
unsigned ints 'sources' and 'bank' cannot be less than LM3630A_SINK_0 (0)
and LM3630A_BANK_0 (0) respecitively, so change the logic to only check
for thier two possible valid values.
Fixes W=1 warnings:
drivers/video/backlight/lm3630a_bl.c: In function ‘lm3630a_parse_led_sources’:
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/video/backlight/ili922x.c:116: warning: Function parameter or member
's' not described in 'CHECK_FREQ_REG'
drivers/video/backlight/ili922x.c:116: warning: Function parameter or member
'x' not
W=1 kernel build reports:
drivers/video/backlight/lms501kf03.c:96:28: warning: ‘seq_sleep_in’ defined
but not used [-Wunused-const-variable=]
96 | static const unsigned char seq_sleep_in[] = {
| ^~~~
drivers/video/backlight/lms501kf03.c:92:28: warning: ‘seq_up_dn’ defined but
not
Attempting to clean-up W=1 kernel builds, which are currently
overwhelmingly riddled with niggly little warnings.
Lee Jones (8):
backlight: lms501kf03: Remove unused const variables
backlight: lcd: Add missing kerneldoc entry for 'struct device parent'
backlight: ili922x: Add missing
Kerneldoc is for documenting function arguments and return values.
Prevents warnings like:
drivers/video/backlight/ili922x.c:127: warning: cannot understand function
prototype: 'int ili922x_id = 1; '
drivers/video/backlight/ili922x.c:136: warning: cannot understand function
prototype:
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/video/backlight/backlight.c:329: warning: Function parameter or member
'reason' not described in 'backlight_force_update'
drivers/video/backlight/backlight.c:354: warning: Function parameter or
This has been missing since the conversion to 'struct device' in 2007.
Cc:
Cc: Bartlomiej Zolnierkiewicz
Cc: Jamey Hicks
Cc: Andrew Zabolotny
Signed-off-by: Lee Jones
---
drivers/video/backlight/lcd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/backlight/lcd.c
Kerneldoc syntax is used, but not complete. Descriptions required.
Prevents warnings like:
drivers/video/backlight/ili922x.c:298: warning: Function parameter or member
'spi' not described in 'ili922x_reg_dump'
Cc:
Cc: Bartlomiej Zolnierkiewicz
Cc: Software Engineering
Signed-off-by: Lee
On Wed, Jun 24, 2020 at 03:25:33PM +0100, Robin Murphy wrote:
> And yeah, anyone who pipes up suggesting that places where an ERR_PTR value
> could be passed to probe_err() could simply refactor IS_ERR() checks with
> more uses of the god-awful PTR_ERR_OR_ZERO() obfuscator gets a long stare of
>
On 2020-06-24 15:02, Mark Brown wrote:
> On Wed, Jun 24, 2020 at 04:45:28PM +0300, Andy Shevchenko wrote:
>> On Wed, Jun 24, 2020 at 4:27 PM Mark Brown wrote:
>
>>> As I said down the thread that's not a great pattern since it means that
>>> probe deferral errors never get displayed and users
On Wed, Jun 24, 2020 at 4:44 PM Andrzej Hajda wrote:
>
>
> On 24.06.2020 14:14, Rafael J. Wysocki wrote:
> > On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
> >> Many resource acquisition functions return error value encapsulated in
> >> pointer instead of integer value. To simplify coding
From: Colin Ian King
In the cases where adev->jpeg.num_jpeg_inst is zero or the condition
adev->jpeg.harvest_config & (1 << i) is always non-zero the variable
ret is never set to an error condition and the function returns
an uninitialized value in ret. Since the only exit condition at
the end
On 24.06.2020 14:30, Greg Kroah-Hartman wrote:
> On Wed, Jun 24, 2020 at 01:41:25PM +0200, Andrzej Hajda wrote:
>> Many resource acquisition functions return error value encapsulated in
>> pointer instead of integer value. To simplify coding we can use macro
>> which will accept both types of
On 24.06.2020 14:14, Rafael J. Wysocki wrote:
> On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>> Many resource acquisition functions return error value encapsulated in
>> pointer instead of integer value. To simplify coding we can use macro
>> which will accept both types of error.
>>
Acked-by: Nirmoy Das
Thanks,
Nirmoy
On 6/24/20 4:14 PM, Colin King wrote:
From: Colin Ian King
Currently the goto statement is skipping over a lot of setup code
because it is outside of an if-block and should be inside it. Fix
this by adding missing if statement braces.
On Wed, Jun 24, 2020 at 5:29 AM Daniel Vetter wrote:
>
> In the past we had a pile of hacks to orchestrate access between fbdev
> emulation and native kms clients. We've tried to streamline this, by
> always preferring the kms side above fbdev calls when a drm master
> exists, because drm master
On 2020-06-24 13:55, Andy Shevchenko wrote:
On Wed, Jun 24, 2020 at 3:37 PM Robin Murphy wrote:
On 2020-06-24 12:41, Andrzej Hajda wrote:
Many resource acquisition functions return error value encapsulated in
pointer instead of integer value. To simplify coding we can use macro
which will
From: Colin Ian King
Currently the goto statement is skipping over a lot of setup code
because it is outside of an if-block and should be inside it. Fix
this by adding missing if statement braces.
Addresses-Coverity: ("Structurally dead code")
Fixes: fd151ca5396d ("drm amdgpu: SI UVD v3_1")
On Wed, Jun 24, 2020 at 03:43:10PM +0200, Andrzej Hajda wrote:
>
> On 24.06.2020 15:25, Mark Brown wrote:
> > If we silently ignore all deferred probe errors we make it hard for
> > anyone who is experiencing issues with deferred probe to figure out what
> > they're missing. We should at least
On 24.06.2020 15:23, Laurent Pinchart wrote:
> On Wed, Jun 24, 2020 at 02:31:40PM +0200, Greg Kroah-Hartman wrote:
>> On Wed, Jun 24, 2020 at 01:41:23PM +0200, Andrzej Hajda wrote:
>>> During probe every time driver gets resource it should usually check for
>>> error
>>> printk some message if
On 24.06.2020 15:33, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wed, Jun 24, 2020 at 01:41:27PM +0200, Andrzej Hajda wrote:
>> Using probe_err code has following advantages:
>> - shorter code,
>> - recorded defer probe reason for debugging,
>> - uniform error code logging.
>>
>> Signed-off-by:
On Wed, Jun 24, 2020 at 04:45:28PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 24, 2020 at 4:27 PM Mark Brown wrote:
> > As I said down the thread that's not a great pattern since it means that
> > probe deferral errors never get displayed and users have a hard time
> > figuring out why their
On Wed, Jun 24, 2020 at 4:27 PM Mark Brown wrote:
>
> On Wed, Jun 24, 2020 at 01:41:23PM +0200, Andrzej Hajda wrote:
> > During probe every time driver gets resource it should usually check for
> > error
> > printk some message if it is not -EPROBE_DEFER and return the error. This
>
> As I said
On 24.06.2020 15:25, Mark Brown wrote:
On Wed, Jun 24, 2020 at 01:41:26PM +0200, Andrzej Hajda wrote:
In case of error during resource acquisition driver should print error
message only in case it is not deferred probe, using probe_err helper
solves the issue. Moreover it records defer probe
We only need the page array when the BO is about to be accessed.
So not only populate, but also create it on demand.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 26 --
drivers/gpu/drm/ttm/ttm_bo_util.c | 9 +++--
Instead of signaling failure by setting the node pointer to
NULL do so by returning -ENOSPC.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 4 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 8
Hi Andrzej,
On Wed, Jun 24, 2020 at 01:41:27PM +0200, Andrzej Hajda wrote:
> Using probe_err code has following advantages:
> - shorter code,
> - recorded defer probe reason for debugging,
> - uniform error code logging.
>
> Signed-off-by: Andrzej Hajda
> ---
>
On Wed, Jun 24, 2020 at 01:37:52PM +0100, Robin Murphy wrote:
> On 2020-06-24 12:41, Andrzej Hajda wrote:
> > Many resource acquisition functions return error value encapsulated in
> > pointer instead of integer value. To simplify coding we can use macro
> > which will accept both types of error.
On 24.06.2020 14:11, Rafael J. Wysocki wrote:
> On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>> /sys/kernel/debug/devices_deferred property contains list of deferred
>> devices.
>> This list does not contain reason why the driver deferred probe, the patch
>> improves it.
>> The natural
On Wed, Jun 24, 2020 at 01:41:23PM +0200, Andrzej Hajda wrote:
> During probe every time driver gets resource it should usually check for error
> printk some message if it is not -EPROBE_DEFER and return the error. This
As I said down the thread that's not a great pattern since it means that
Looks good now, thanks!
On Wed, Jun 24, 2020 at 01:01:31PM +, Simon Ser wrote:
> There have suggestions to bake pitch alignment, address alignement,
> contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> constraints into modifiers. Last time this was brought up it seemed
> like
On 24.06.2020 14:34, Greg Kroah-Hartman wrote:
> On Wed, Jun 24, 2020 at 01:41:24PM +0200, Andrzej Hajda wrote:
>> /sys/kernel/debug/devices_deferred property contains list of deferred
>> devices.
>> This list does not contain reason why the driver deferred probe, the patch
>> improves it.
>>
On Wed, Jun 24, 2020 at 01:41:26PM +0200, Andrzej Hajda wrote:
> In case of error during resource acquisition driver should print error
> message only in case it is not deferred probe, using probe_err helper
> solves the issue. Moreover it records defer probe reason for debugging.
If we silently
On Wed, Jun 24, 2020 at 02:31:40PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jun 24, 2020 at 01:41:23PM +0200, Andrzej Hajda wrote:
> > During probe every time driver gets resource it should usually check for
> > error
> > printk some message if it is not -EPROBE_DEFER and return the error. This
On 24.06.2020 14:53, Andy Shevchenko wrote:
> On Wed, Jun 24, 2020 at 2:41 PM Andrzej Hajda wrote:
>> Many resource acquisition functions return error value encapsulated in
>> pointer instead of integer value. To simplify coding we can use macro
>> which will accept both types of error.
>> With
On 05/06/2020 10:32, Thomas Zimmermann wrote:
> Create GEM objects with drm_gem_cma_create_object_default_funcs(), which
> allocates the object and sets CMA's default object functions. Corresponding
> callbacks in struct drm_driver are cleared. No functional changes are made.
>
> Driver and
On 05/06/2020 10:32, Thomas Zimmermann wrote:
> DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver
> to their defaults. No functional changes are made.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Emil Velikov
Reviewed-by: Jyri Sarha
Tested-by: Jyri Sarha
> ---
>
There have suggestions to bake pitch alignment, address alignement,
contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
constraints into modifiers. Last time this was brought up it seemed
like the consensus was to not allow this. Document this in drm_fourcc.h.
There are several
> > The new paragraph below looks good, but this sentence from the end of
> > the paragraph above still needs to be removed:
> > An example is AFBC, where both ARGB and ABGR have the exact same compressed
> > layout.
>
> I think that entire paragraph was meant to be deleted, the replacement
> is
On Wed, Jun 24, 2020 at 1:08 PM Brian Starkey wrote:
>
> Hi,
>
> On Tue, Jun 23, 2020 at 03:25:08PM +, Simon Ser wrote:
> > There have suggestions to bake pitch alignment, address alignement,
> > contiguous memory or other placement (hidden VRAM, GTT/BAR, etc)
> > constraints into modifiers.
On Wed, Jun 24, 2020 at 3:37 PM Robin Murphy wrote:
> On 2020-06-24 12:41, Andrzej Hajda wrote:
> > Many resource acquisition functions return error value encapsulated in
> > pointer instead of integer value. To simplify coding we can use macro
> > which will accept both types of error.
> > With
On Wed, Jun 24, 2020 at 2:41 PM Andrzej Hajda wrote:
>
> Many resource acquisition functions return error value encapsulated in
> pointer instead of integer value. To simplify coding we can use macro
> which will accept both types of error.
> With this patch user can use:
> probe_err(dev,
On 2020-06-24 12:41, Andrzej Hajda wrote:
Many resource acquisition functions return error value encapsulated in
pointer instead of integer value. To simplify coding we can use macro
which will accept both types of error.
With this patch user can use:
probe_err(dev, ptr, ...)
instead of:
On Wed, Jun 24, 2020 at 01:41:24PM +0200, Andrzej Hajda wrote:
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is probe_err function
On Wed, Jun 24, 2020 at 01:41:23PM +0200, Andrzej Hajda wrote:
> During probe every time driver gets resource it should usually check for error
> printk some message if it is not -EPROBE_DEFER and return the error. This
> pattern is simple but requires adding few lines after any resource
On Wed, Jun 24, 2020 at 01:41:25PM +0200, Andrzej Hajda wrote:
> Many resource acquisition functions return error value encapsulated in
> pointer instead of integer value. To simplify coding we can use macro
> which will accept both types of error.
> With this patch user can use:
>
On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>
> Many resource acquisition functions return error value encapsulated in
> pointer instead of integer value. To simplify coding we can use macro
> which will accept both types of error.
> With this patch user can use:
> probe_err(dev,
On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>
> /sys/kernel/debug/devices_deferred property contains list of deferred devices.
> This list does not contain reason why the driver deferred probe, the patch
> improves it.
> The natural place to set the reason is probe_err function
From: Colin Ian King
There is an off-by-one bounds check on the index into arrays
table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that
can lead to reads and writes outside of arrays. Fix the bound checking
off-by-one error.
Addresses-Coverity: ("Out-of-bounds read/write")
On Wed, Jun 24, 2020 at 1:41 PM Andrzej Hajda wrote:
>
> During probe every time driver gets resource it should usually check for error
> printk some message if it is not -EPROBE_DEFER and return the error. This
> pattern is simple but requires adding few lines after any resource acquisition
>
During probe every time driver gets resource it should usually check for error
printk some message if it is not -EPROBE_DEFER and return the error. This
pattern is simple but requires adding few lines after any resource acquisition
code, as a result it is often omited or implemented only
In case of error during resource acquisition driver should print error
message only in case it is not deferred probe, using probe_err helper
solves the issue. Moreover it records defer probe reason for debugging.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/sil-sii8620.c | 18
Many resource acquisition functions return error value encapsulated in
pointer instead of integer value. To simplify coding we can use macro
which will accept both types of error.
With this patch user can use:
probe_err(dev, ptr, ...)
instead of:
probe_err(dev, PTR_ERR(ptr), ...)
1 - 100 of 133 matches
Mail list logo
