On Thu, 02 Apr 2020, Pankaj Bharadiya
wrote:
> Now we have new struct drm_device based drm_WARN* macros. These are
> preferred over the regular WARN* macros.
>
> Remove WARN_ON and WARN_ON_ONCE overriedes to avoid any temptations to
> use them in the future.
Well, since they are overrides of mac
On 01/04/2020 21:43, Umesh Nerlige Ramappa wrote:
On Tue, Mar 31, 2020 at 02:46:46PM +0300, Lionel Landwerlin wrote:
Gen12 brought an important redesign of the OA unit, splitting it in 2
with a per context part (OAR) and a global part (OAG).
OAR deals with per context counters and implements th
Now we have new struct drm_device based drm_WARN* macros. These are
preferred over the regular WARN* macros.
Remove WARN_ON and WARN_ON_ONCE overriedes to avoid any temptations to
use them in the future.
Suggested-by: Jani Nikula
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/i915_ut
On Thu, Apr 2, 2020 at 2:50 AM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> (On a side note, git-format-patch accepts a -v argument to specify the
> version, I didn't realize you were not aware of it :-))
>
> On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> > A few things:
> > - Upda
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the copy pasted port sync crtc enable functions and instead
> just split the normal function into the two parts we need.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drive
On Fri, 2020-03-13 at 18:48 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're going to want access to the atomic state for iterating
> the slave crtcs when enabling the port sync master crtc. Pass
> the atomic state all the way down.
>
> The alternative would be yet another encoder hoo
On Thu, Apr 02, 2020 at 02:36:53AM +0300, Souza, Jose wrote:
> On Wed, 2020-04-01 at 15:55 +0300, Imre Deak wrote:
> > On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza
> > wrote:
> > > TC ports can enter in TCCOLD to save power and is required to
> > > request
> > > to PCODE to exit
On Thu, Apr 02, 2020 at 01:35:30AM +0300, Souza, Jose wrote:
> On Wed, 2020-04-01 at 15:43 +0300, Imre Deak wrote:
> > On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza
> > wrote:
> > > This is required for legacy/static TC ports as IOM is not aware of
> > > the connection and will no
On Wed, 2020-03-18 at 19:02 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a bunch of code that would like to know which
> CPU transcoders are actually present in the hardware. Rather than
> use various ad-hoc methods let's just include a full bitmask in
> the device info, alongsid
Hi Daniel,
(On a side note, git-format-patch accepts a -v argument to specify the
version, I didn't realize you were not aware of it :-))
On Mon, Mar 23, 2020 at 03:49:18PM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfre
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev3)
URL : https://patchwork.freedesktop.org/series/74593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8235 -> Patchwork_17173
Summary
---
**
On Wed, Feb 12, 2020 at 06:17:34PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Most of the pfit functions are of the form:
>
> func()
> {
> if (pfit_enabled) {
> ...
> }
> }
>
> Flip the pfit_enabled check around to flatten the functions.
>
> And while we're
On Wed, 2020-04-01 at 15:55 +0300, Imre Deak wrote:
> On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza
> wrote:
> > TC ports can enter in TCCOLD to save power and is required to
> > request
> > to PCODE to exit this state before use or read to TC registers.
> >
> > For TGL there is
On Wed, Feb 12, 2020 at 06:17:33PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix skl_update_scaler_crtc() to deal with different scaling
> modes correctly. The current implementation assumes
> DRM_MODE_SCALE_FULLSCREEN. Fortunately we don't expose any
> border properties currently so
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev3)
URL : https://patchwork.freedesktop.org/series/74593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c3b89dcced32 drm/i915/gem: Drop cached obj->bind_count
-:160: WARNING:LONG_LINE: line over 100 chara
' 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/Maarten-Lankhorst/Revert-drm-i915-gem-Drop-relocation-slowpath/20200401-005710
>
Hi,
on my Intel Compute Stick STCK1 (baytrail hdmi audio)
sound is not working with the kernel 5.6
I have bisected the kernel and I found the commit that introduced the issue:
commit 58d124ea2739e1440ddd743d46c470fe724aca9a
Author: Maarten Lankhorst
Date: Thu Oct 31 12:26:04 2019 +0100
d
On Wed, Feb 12, 2020 at 07:43:51PM +0200, Jani Nikula wrote:
> On Wed, 12 Feb 2020, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Make the PFIT_PIPE stuff less ugly via parametrization.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_panel.c | 3 +--
>
We cached the number of vma bound to the object in order to speed up
shrinker decisions. This has been superseded by being more proactive in
removing objects we cannot shrink from the shrinker lists, and so we can
drop the clumsy attempt at atomically counting the bind count and
comparing it to the
On Wed, 2020-04-01 at 15:43 +0300, Imre Deak wrote:
> On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza
> wrote:
> > This is required for legacy/static TC ports as IOM is not aware of
> > the connection and will not trigger the TC cold exit.
> >
> > Just request PCODE to exit TCCOLD
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence
URL : https://patchwork.freedesktop.org/series/75383/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8234 -> Patchwork_17172
===
Only GPU activity via the GGTT fence is asynchronous, we know that we
control the CPU access directly, so we only need to wait for the GPU to
stop using the fence before we relinquish it.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 25
If we must revoke the fence because the VMA is no longer present, or
because the fence no longer applies, ensure that we do and convert it
into an error if we try but cannot.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 21 +++-
Make a copy of the object tiling parameters at the point of grabbing the
fence.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 93 +++-
drivers/gpu/drm/i915/gt/intel_ggtt_fencing.h | 4 +
2 files changed, 37 insertions(+
== Series Details ==
Series: drm/i915/gem: Try allocating va from free space (rev3)
URL : https://patchwork.freedesktop.org/series/74748/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17171
Summary
---
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
v2: Use the final pin_flags so that we won't have to move the object if
we find the wrong free space.
Sign
Quoting Patchwork (2020-04-01 20:31:15)
> == Series Details ==
>
> Series: drm/i915/gem: Try allocating va from free space (rev2)
> URL : https://patchwork.freedesktop.org/series/74748/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17170
> =
== Series Details ==
Series: drm/i915/gem: Try allocating va from free space (rev2)
URL : https://patchwork.freedesktop.org/series/74748/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8233 -> Patchwork_17170
Summary
---
On Wed, 1 Apr 2020 at 20:02, Chris Wilson wrote:
>
> Quoting Matthew Auld (2020-04-01 19:56:23)
> > On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> > >
> > > Only GPU activity via the GGTT fence is asynchronous, we know that we
> > > control the CPU access directly, so we only need to wait fo
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> We cached the number of vma bound to the object in order to speed up
> shrinker decisions. This has been superseded by being more proactive in
> removing objects we cannot shrink from the shrinker lists, and so we can
> drop the clumsy attempt
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> If we must revoke the fence because the VMA is no longer present, or
> because the fence no longer applies, ensure that we do and convert it
> into an error if we try but cannot.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
_
== Series Details ==
Series: drm/i915/gem: Try allocating va from free space (rev2)
URL : https://patchwork.freedesktop.org/series/74748/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f645456d24f7 drm/i915/gem: Try allocating va from free space
-:27: CHECK:PREFER_KERNEL_TYPES:
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> Make a copy of the object tiling parameters at the point of grabbing the
> fence.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Quoting Matthew Auld (2020-04-01 19:56:23)
> On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> >
> > Only GPU activity via the GGTT fence is asynchronous, we know that we
> > control the CPU access directly, so we only need to wait for the GPU to
> > stop using the fence before we relinquish it.
If the current node/entry location is occupied, and the object is not
pinned, try assigning it some free space. We cannot wait here, so if in
doubt, we unreserve and try to grab all at once.
v2: Use the final pin_flags so that we won't have to move the object if
we find the wrong free space.
Sign
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> Only GPU activity via the GGTT fence is asynchronous, we know that we
> control the CPU access directly, so we only need to wait for the GPU to
> stop using the fence before we relinquish it.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gp
== Series Details ==
Series: series starting with [01/23] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75303/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17153_full
On Tue, Mar 31, 2020 at 02:46:46PM +0300, Lionel Landwerlin wrote:
Gen12 brought an important redesign of the OA unit, splitting it in 2
with a per context part (OAR) and a global part (OAG).
OAR deals with per context counters and implements the
MI_REPORT_PERF_COUNT command.
OAG deals with glo
Quoting Matthew Auld (2020-04-01 19:20:56)
> On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
> >
> > If the current node/entry location is occupied, and the object is not
> > pinned, try assigning it some free space. We cannot wait here, so if in
> > doubt, we unreserve and try to grab all at on
From: Dominik Grzegorzek
A low priority client should not block a high priority client. In this
case we check that if a low priority client poisons its own GTT and so
its execbuf may take ages to process, a high priority client can still
execute in parallel.
Signed-off-by: Dominik Grzegorzek
Cc
On Tue, 31 Mar 2020 at 22:31, Chris Wilson wrote:
>
> If the current node/entry location is occupied, and the object is not
> pinned, try assigning it some free space. We cannot wait here, so if in
> doubt, we unreserve and try to grab all at once.
>
> Signed-off-by: Chris Wilson
> ---
> drivers
On Wed, 2020-04-01 at 15:18 +0800, You-Sheng Yang wrote:
> On 2020-04-01 08:41, José Roberto de Souza wrote:
> > Moving the code to return the digital port of the aux channel also
> > removing the intel_phy_is_tc() to make it generic.
> > digital_port will be needed in icl_tc_phy_aux_power_well_ena
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev6)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8230_full -> Patchwork_17166_full
== Series Details ==
Series: drm/i915/gt: move remaining debugfs interfaces into gt (rev2)
URL : https://patchwork.freedesktop.org/series/75333/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8230_full -> Patchwork_17165_full
== Series Details ==
Series: drm/i915/gt: Fill all the unused space in the GGTT (rev2)
URL : https://patchwork.freedesktop.org/series/75320/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8229_full -> Patchwork_17160_full
Su
On 31-03-2020 17:07, Anshuman Gupta wrote:
New i915_pm_lpsp igt solution approach relies on connector specific
debugfs attribute i915_lpsp_info, it exposes whether an output is
capable of driving lpsp and exposes lpsp enablement info.
v2:
- CI fixup.
v3:
- register i915_lpsp_info only for supp
== Series Details ==
Series: drm/i915: Report all failed registers for ctx isolation (rev2)
URL : https://patchwork.freedesktop.org/series/75318/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17159_full
===
== Series Details ==
Series: drm/i915/tgl: Make Wa_14010229206 permanent
URL : https://patchwork.freedesktop.org/series/75139/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8197_full -> Patchwork_17107_full
Summary
---
== Series Details ==
Series: drm/i915/gt: Include a few tracek for timeslicing
URL : https://patchwork.freedesktop.org/series/75317/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17158_full
Summary
--
== Series Details ==
Series: drm/i915: Defer kicking the tasklet until all rescheduling is complete
URL : https://patchwork.freedesktop.org/series/75314/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17157_full
===
== Series Details ==
Series: i915 lpsp support for lpsp igt (rev6)
URL : https://patchwork.freedesktop.org/series/74648/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8228_full -> Patchwork_17155_full
Summary
---
**F
On 31/03/2020 11:36, Chris Wilson wrote:
Don't bother trying and failing to test bonding if the kernel doesn't
even support it.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
tests/i915/gem_exec_balancer.c | 34 +++---
1 file changed, 27 ins
Jani Nikula writes:
> On Mon, 30 Mar 2020, Dirk Gouders wrote:
>> Dirk Gouders writes:
>>
>>> Some additional information:
>>>
>>> I tried to get more information by using netconsole with kernel
>>> 5.6.0-rc7+. After some time, the system stopped to respond and I
>>> checked the messages sent
== Series Details ==
Series: drm/i915/gt: Align engine dump active/pending
URL : https://patchwork.freedesktop.org/series/75363/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8232 -> Patchwork_17169
Summary
---
**SUC
Use igt_subtest_with_dynamic for the flexible approach to engine
dependent test discovery.
Signed-off-by: Chris Wilson
---
lib/i915/gem_engine_topology.h | 6 +-
tests/i915/gem_exec_schedule.c | 432 -
2 files changed, 207 insertions(+), 231 deletions(-)
diff -
On Wed, Apr 01, 2020 at 05:42:24PM +0530, Jeevan B wrote:
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this info to
On Tue, Mar 31, 2020 at 05:41:20PM -0700, José Roberto de Souza wrote:
> TC ports can enter in TCCOLD to save power and is required to request
> to PCODE to exit this state before use or read to TC registers.
>
> For TGL there is a new MBOX command to do that with a parameter to ask
> PCODE to exi
On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza wrote:
> This is required for legacy/static TC ports as IOM is not aware of
> the connection and will not trigger the TC cold exit.
>
> Just request PCODE to exit TCCOLD is not enough as it could enter
> again be driver makes use of t
>
> > -Original Message-
> > From: B, Jeevan
> > Sent: Wednesday, April 1, 2020 5:42 PM
> > To: Shankar, Uma
> > Cc: B, Jeevan ; Ville Syrjälä
> > ; intel-gfx@lists.freedesktop.org
> > Subject: [PATCH 1/5] drm: report dp downstream port type as a
> > subconnector property
> >
> > Current
> -Original Message-
> From: B, Jeevan
> Sent: Wednesday, April 1, 2020 5:42 PM
> To: Shankar, Uma
> Cc: B, Jeevan ; Ville Syrjälä
> ;
> intel-gfx@lists.freedesktop.org
> Subject: [PATCH 1/5] drm: report dp downstream port type as a subconnector
> property
>
> Currently, downstream po
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is already utilized for DVI-
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: updates to match previous commit changes
Reviewed-by: Emil Velikov
Tested-by: Oleg Vasilev
Signed-off-by: Oleg Vasilev
Cc: Ville Syrjälä
Cc: intel-gfx@lists.fre
On Tue, Mar 31, 2020 at 05:41:17PM -0700, José Roberto de Souza wrote:
> This is a similar function to intel_aux_power_domain() but it do not
> care about TBT ports, this will be needed by GEN11 TC sequences.
>
> Cc: Imre Deak
> Cc: Cooper Chiou
> Cc: Kai-Heng Feng
> Signed-off-by: José Roberto
There is a spelling mistake in comment, fix it.
Signed-off-by: Chen Zhou
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b6cf284..3be6797
On 2020-04-01 08:41, José Roberto de Souza wrote:
> Moving the code to return the digital port of the aux channel also
> removing the intel_phy_is_tc() to make it generic.
> digital_port will be needed in icl_tc_phy_aux_power_well_enable()
> so adding it as a parameter to icl_tc_port_assert_ref_hel
On Wed, Apr 01, 2020 at 04:50:23PM +0530, Anshuman Gupta wrote:
> On 2020-03-30 at 15:24:25 +0530, Imre Deak wrote:
> > On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
> > a hotplug interrupt without the sink getting unplugged/replugged from
> > the connector, there can be a
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Peek at the next
submission for error interrupts
URL : https://patchwork.freedesktop.org/series/75362/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8231 -> Patchwork_17168
===
On 2020-03-30 at 15:24:25 +0530, Imre Deak wrote:
> On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
> a hotplug interrupt without the sink getting unplugged/replugged from
> the connector, there can be an up to 3 seconds delay until the AUX
> channel gets functional. To avoi
Insert a space so that the same fields between active/pending execlists
state are aligned.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engin
If we receive the error interrupt before the CS interrupt, we may find
ourselves without an active request to reset, skipping the GPU reset.
All because the attempt to reset was too early.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 41 -
1 f
If we cannot trust the reset will flush out the CS event queue such that
process_csb() reports an accurate view of HW, we will need to search the
active and pending contexts to determine which was actually running at
the time we issued the reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i
== Series Details ==
Series: drm/i915/gem: Utilize rcu iteration of context engines (rev2)
URL : https://patchwork.freedesktop.org/series/75270/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8223_full -> Patchwork_17151_full
== Series Details ==
Series: drm/i915/gt: Include the execlists CCID of each port in the engine dump
URL : https://patchwork.freedesktop.org/series/75298/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8223_full -> Patchwork_17150_full
==
== Series Details ==
Series: drm/i915/tgl: Make Wa_14010229206 permanent
URL : https://patchwork.freedesktop.org/series/75139/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8197_full -> Patchwork_17107_full
Summary
---
Hi Swathi, I have addressed the issue and re-reported the results last night.
But the results were not updated. Now I am re-reporting for the second time. I
will update you. I will keep you posted.
Lakshmi.
-Original Message-
From: Dhanavanthri, Swathi
Sent: Wednesday, April 1, 2020 1
== Series Details ==
Series: series starting with [1/4] drm/i915/selftests: Tidy up an error message
for live_error_interrupt
URL : https://patchwork.freedesktop.org/series/75296/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8222_full -> Patchwork_17149_full
On Tue, Feb 25, 2020 at 07:11:13PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a global state to track the dbuf slices. Gets rid of all the nasty
> coupling between state->modeset and dbuf recomputation. Also we can now
> totally nuke state->active_pipe_changes.
>
> dev_priv->wm.di
On Mon, Mar 02, 2020 at 04:50:37PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 05:30:57PM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Currently skl_compute_dbuf_slices() returns 0 for any inactive p
On 01/04/2020 10:43, Dixit, Ashutosh wrote:
On Tue, 31 Mar 2020 23:57:57 -0700, Lionel Landwerlin wrote:
On 01/04/2020 02:14, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the prev
On Tue, 31 Mar 2020 23:57:57 -0700, Lionel Landwerlin wrote:
>
> On 01/04/2020 02:14, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
80 matches
Mail list logo
