On Thu, 24 Jun 2021 at 02:20, Daniel Vetter wrote:
>
> Docs for struct dma_resv are fairly clear:
>
> "A reservation object can have attached one exclusive fence (normally
> associated with write operations) or N shared fences (read
> operations)."
>
> https://dri.freedesktop.org/docs/drm/driver-a
On 24/06/21 05:57, David Stevens wrote:
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and a
From: John Harrison
In the case of a full GPU reset (e.g. because GuC has died or because
GuC's hang detection has been disabled), the driver can't rely on GuC
reporting the guilty context. Instead, the driver needs to scan all
active contexts and find one that is currently executing, as per the
From: John Harrison
It is impossible to seal all race conditions of resets occurring
concurrent to other operations. At least, not without introducing
excesive mutex locking. Instead, don't complain if it occurs. In
particular, don't complain if trying to send a H2G during a reset.
Whatever the H
From: John Harrison
Use the official driver default scheduling policies for configuring
the GuC scheduler rather than a bunch of hardcoded values.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Cc: Jose Souza
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/dr
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/intel_engine_heartbeat.c | 63 +++
.../gpu/drm/i915/gt/intel_en
From: John Harrison
The serial number tracking of engines happens at the backend of
request submission and was expecting to only be given physical
engines. However, in GuC submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted to
Hold a reference to the intel_context over life of an i915_request.
Without this an i915_request can exist after the context has been
destroyed (e.g. request retired, context closed, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine,
From: John Harrison
Clear the 'disable resets' flag to allow GuC to reset hung contexts
(detected via pre-emption timeout).
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
Cc: Matthew Brost
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
further muddling our error state.
There is o
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the ADS.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_gt.c
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 6 +
.../g
Semaphores are an optimization and not required for basic GuC submission
to work properly. Disable until we have time to do the implementation to
enable semaphores and tune them for performance. Also long direction is
just to delete semaphores from the i915 so another reason to not enable
these for
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio ct);
}
+static inline void intel_guc_reset_interrupts(struct intel_guc *guc)
+{
+ gu
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8 +++
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the CTB
channels. It is safe to suspend once thi
From: John Harrison
The driver must provide GuC with a list of mmio registers
that should be saved/restored during a GuC-based engine reset.
Unfortunately, the list must be dynamically allocated as its size is
variable. That means the driver must generate the list twice - once to
work out the siz
From: John Harrison
Added the scheduling policy parameters to the 'guc_info' debugfs state
dump.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 13 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.h | 2 ++
drivers/gpu
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/
From: John Harrison
Changing the reset module parameter has no effect on a running GuC.
The corresponding entry in the ADS must be updated and then the GuC
informed via a Host2GuC message.
The new debugfs interface to module parameters allows this to happen.
However, connecting the parameter dat
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 3 ++
.../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 23 +++-
..
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same physical engine but different context this
doesn't ensur
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary
From: John Harrison
Add several module failure load inject points in the CT buffer creation
code path.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
1 file changed, 8 insertions(+)
diff --g
Remove old GuC stage descriptor, add lrc descriptor which will be used
by the new GuC interface implemented in this patch series.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 65
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to that of all the siblings.
Cc: Daniele Ceraolo Sp
Sometime during context pinning a context with the same guc_id is
registered with the GuC. In this a case deregister must be before before
the context can be registered. A fence is inserted on all requests while
the deregister is in flight. Once the G2H is received indicating the
deregistration is
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarantees the HW will not reference the context. Hence it is
not necessary to defer unpinning until a kernel context request
completes on each engine in t
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
---
drivers/gpu/drm/i915/gt/intel_rps.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/d
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/i
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 14 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 41 +++
2 files changed, 55 inserti
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
drivers/gpu/drm/i915/gt/intel_context_types.h | 22 +-
drivers/gpu/drm/i9
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet submits is used for the submission path.
Also the per engine interrupt handler has been updated to disable the
rescheduling of the phys
When running the GuC the GPU can't be considered idle if the GuC still
has contexts pinned. As such, a call has been added in
intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for
the number of unpinned contexts to go to zero.
v2: rtimeout -> remaining_timeout
Cc: John Harrison
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value hardcoded value of 1s instead.
v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
v3:
(Daniel Vetter)
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required
Add non blocking CTB send function, intel_guc_send_nb. GuC submission
will send CTBs in the critical path and does not need to wait for these
CTBs to complete before moving on, hence the need for this new function.
The non-blocking CTB now must have a flow control mechanism to ensure
the buffer is
With GuC scheduling, it isn't safe to unpin a context while scheduling
is enabled for that context as the GuC may touch some of the pinned
state (e.g. LRC). To ensure scheduling isn't enabled when an unpin is
done, a call back is added to intel_context_unpin when pin count == 1
to disable schedulin
Disable preempt busywait when using GuC scheduling. This isn't need as
the GuC control preemption when scheduling.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/dr
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 2 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 3 ++
.../gpu
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all physica
With the introduction of non-blocking CTBs more than one CTB can be in
flight at a time. Increasing the size of the CTBs should reduce how
often software hits the case where no space is available in the CTB
buffer.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/in
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
and ring tail value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 3 ++
drivers/gpu/drm/i915/i915_reque
Implement a stall timer which fails H2G CTBs once a period of time
with no forward progress is reached to prevent deadlock.
Also update to ct_write to return -EIO rather than -EPIPE on a
corrupted descriptor.
Signed-off-by: John Harrison
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt
As discussed in [1], [2] we are enabling GuC submission support in the
i915. This is a subset of the patches in step 5 described in [1],
basically it is absolute to enable CI with GuC submission on gen11+
platforms.
This series itself will likely be broken down into smaller patch sets to
merge. Li
Improve the error message when a unsolicited CT response is received by
printing fence that couldn't be found, the last fence, and all requests
with a response outstanding.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
1 file changed, 7 insertions(+)
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/drivers/g
Add lrc descriptor context lookup array which can resolve the
intel_context from the lrc descriptor index. In addition to lookup, it
can determine in the lrc descriptor context is currently registered with
the GuC by checking if an entry for a descriptor index is present.
Future patches in the seri
On 23/06/2021 18:43, Rob Herring wrote:
> In testing out under development json-schema 2020-12 support, there's a
> few issues with 'unevaluatedProperties' and the graph schema. If
> 'graph.yaml#/properties/port' is used, then neither the port nor the
> endpoint(s) can have additional properties. '
radeon_ttm_bo_destroy() is attempting to access the resource object to
update memory counters. However, the resource object is already freed when
ttm calls this function via the destroy callback. This causes an oops when
a bo is freed:
BUG: kernel NULL pointer dereference, address: 000
On Wednesday, June 23, 2021 2:55:04 AM EDT Christian König wrote:
> Please rather keep the new resource as parameter here and update before
> adjusting bo->resource.
>
> This way you also don't need to export radeon_update_memory_usage().
I wasn't sure exactly what you intended with the request t
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
>
> On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
> >
> > is_swiotlb_force_bounce() was the new function introduced in this patch
> > here.
> >
> >
Thanks for taking it up :)
On 23-06-21, 17:07, Rob Herring wrote:
> diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
> b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml
> +$id: http://devicetree.org/schemas/opp/opp-v2-base.yaml#
> +$schema: http://devicetree.org/meta-sch
Please ignore this last patch. It was put together as an afterthought
and wasn't properly tested.
-David
On Thu, Jun 24, 2021 at 12:59 PM David Stevens wrote:
>
> Return struct page instead of pfn from gfn_to_mfn. This function is only
> used to determine if the page is a transparent hugepage, t
On 23-06-21, 17:07, Rob Herring wrote:
> In preparation to convert OPP bindings to DT schema, clean-up a few OPP
> binding node names in the binding examples.
>
> Cc: Georgi Djakov
> Cc: Shawn Guo
> Cc: Sascha Hauer
> Cc: Leonard Crestez
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux...@vge
Return struct page instead of pfn from gfn_to_mfn. This function is only
used to determine if the page is a transparent hugepage, to enable 2MB
huge gtt shadowing. Returning the page directly avoids the risk of
calling pfn_to_page on a VM_IO|VM_PFNMAP pfn.
This change also properly releases the re
From: David Stevens
Remove two warnings that require ref counts for pages to be non-zero, as
mapped pfns from follow_pfn may not have an initialized ref count.
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu.c | 7 ---
virt/kvm/kvm_main.c| 2 +-
2 files changed, 1 insertion(+), 8
From: David Stevens
Avoid converting pfns returned by follow_fault_pfn to struct pages to
transiently take a reference. The reference was originally taken to
match the reference taken by gup. However, pfns returned by
follow_fault_pfn may not have a struct page set up for reference
counting.
Sig
From: David Stevens
Avoid converting pfns returned by follow_fault_pfn to struct pages to
transiently take a reference. The reference was originally taken to
match the reference taken by gup. However, pfns returned by
follow_fault_pfn may not have a struct page set up for reference
counting.
Sig
From: David Stevens
Return a struct kvm_pfn_page containing both a pfn and an optional
struct page from the gfn_to_pfn family of functions. This differentiates
the gup and follow_fault_pfn cases, which allows callers that only need
a pfn to avoid touching the page struct in the latter case. For c
From: David Stevens
Signed-off-by: David Stevens
---
arch/x86/kvm/mmu/mmu_audit.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kvm/mmu/mmu_audit.c b/arch/x86/kvm/mmu/mmu_audit.c
index cedc17b2f60e..97ff184084b4 100644
--- a/arch/x86/kvm/mmu/mmu_audit.c
+++ b/arch/x86/kvm/mmu/m
KVM supports mapping VM_IO and VM_PFNMAP memory into the guest by using
follow_pte in gfn_to_pfn. However, the resolved pfns may not have
assoicated struct pages, so they should not be passed to pfn_to_page.
This series removes such calls from the x86 and arm64 secondary MMU. To
do this, this serie
https://bugzilla.kernel.org/show_bug.cgi?id=213561
--- Comment #2 from tgn-ff (tgnff...@gmail.com) ---
It's not just locked at the highest clock states, the GPU seems to be under
"load": radeontop shows the GPU utilisation to be at nearly 100%. Consequently,
performance is terrible.
--
You may r
https://bugzilla.kernel.org/show_bug.cgi?id=213561
matoro (mat...@airmail.cc) changed:
What|Removed |Added
CC||mat...@airmail.cc
--- Commen
Hi Jagan/Laurent,
On Wed, Jun 23, 2021 at 7:23 PM Laurent Pinchart
wrote:
> Looking at the register set, it seems to match the Exynos 5433,
> supported by drivers/gpu/drm/exynos/exynos_drm_dsi.c. Can we leverage
> that driver instead of adding a new one for the same IP core ?
Yes. there was an
On Wed 23 Jun 18:37 CDT 2021, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 22, 2021 at 8:28 PM Bjorn Andersson
> wrote:
> >
> > +static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
> > +unsigned int reg, u16 *val)
> > +{
> > + unsigned int tmp;
> > +
On Wed 23 Jun 17:19 CDT 2021, Doug Anderson wrote:
> Hi,
>
> On Tue, Jun 22, 2021 at 8:28 PM Bjorn Andersson
> wrote:
> >
> > The existing pxa driver and the upcoming addition of PWM support in the
> > TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
> > thereby a need for a
fix the warning- variable 'dev' set but not used
Signed-off-by: Cai Huoqing
Reviewed-by: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 984721bf3ab4..
On Wed, Jun 23, 2021 at 10:39:48PM +0300, Oded Gabbay wrote:
> On Wed, Jun 23, 2021 at 10:34 PM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 23, 2021 at 10:00:29PM +0300, Oded Gabbay wrote:
> > > On Wed, Jun 23, 2021 at 9:50 PM Jason Gunthorpe wrote:
> > > >
> > > > On Wed, Jun 23, 2021 at 09:43:04
Hi Rob,
Thank you for the patch.
On Wed, Jun 23, 2021 at 10:43:08AM -0600, Rob Herring wrote:
> Fix the renesas,du binding 'ports' schema which is referencing the 'port'
> schema instead of the 'ports' schema.
>
> Fixes: 99d66127fad2 ("dt-bindings: display: renesas,du: Convert binding to
> YAML
The enable signal may not be controllable by the kernel. Make it
optional.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jagan Teki
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
Reorganize the functions in sections, related to connector operations,
bridge operations, AUX adapter, GPIO controller and probe & remove.
This prepares for proper support of DRM_BRIDGE_ATTACH_NO_CONNECTOR that
will add more functions, to ensure that the code will stay readable.
No functional cha
To simplify interfacing with the panel, wrap it in a panel-bridge and
let the DRM bridge helpers handle chaining of operations.
This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which
requires all components in the display pipeline to be represented by
bridges.
Signed-off-by: Laur
The valid rates are stored in an array of 8 booleans. Replace it with a
bitmask to save space.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 24 +---
1 file changed, 13 insertions(+), 11 d
To prepare for making connector creation option, move connector creation
out of ti_sn_bridge_attach to a separate function.
No functional change intended.
Signed-off-by: Laurent Pinchart
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 31 +++
The SN65DSI86 EN pin can be hardwired to a high level, or connected to a
global reset signal, not controllable by the kernel. Make it optional in
those cases.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jagan Teki
Reviewed-by: Stephen Boyd
Reviewed-by: Douglas Anderson
Acked-by: Rob Herring
Hello,
This patch series contains miscellaneous improvements to the
ti-sn65dsi86 driver, and prepares it for optional connector creation and
DisplayPort (non-eDP) support.
The patches have been posted previously as part of the "[RFC PATCH
00/11] drm/bridge: ti-sn65dsi86: Support DisplayPort mode"
Hi,
On Wed, Jun 23, 2021 at 4:26 PM Laurent Pinchart
wrote:
>
> > > @@ -1365,7 +1384,8 @@ static int ti_sn_bridge_probe(struct i2c_client
> > > *client,
> > >
> > > pdata->bridge.funcs = &ti_sn_bridge_funcs;
> > > pdata->bridge.of_node = client->dev.of_node;
> > > - pdata->
Hi,
On Tue, Jun 22, 2021 at 8:28 PM Bjorn Andersson
wrote:
>
> +static int ti_sn65dsi86_read_u16(struct ti_sn65dsi86 *pdata,
> +unsigned int reg, u16 *val)
> +{
> + unsigned int tmp;
> + int ret;
> +
> + ret = regmap_read(pdata->regmap, reg, &tmp)
Hi Doug,
On Wed, Mar 24, 2021 at 03:47:38PM -0700, Doug Anderson wrote:
> On Sun, Mar 21, 2021 at 8:02 PM Laurent Pinchart wrote:
> >
> > When the SN65DSI86 is used in DisplayPort mode, its output is likely
> > routed to a DisplayPort connector, which can benefit from hotplug
> > detection. Suppor
On Wed 23 Jun 03:29 CDT 2021, Uwe Kleine-K?nig wrote:
> Hello Bjorn,
>
> On Tue, Jun 22, 2021 at 08:12:48PM -0500, Bjorn Andersson wrote:
> > On Tue 22 Jun 15:29 CDT 2021, Uwe Kleine-K?nig wrote:
> > > On Mon, Jun 21, 2021 at 10:09:48PM -0500, Bjorn Andersson wrote:
> > > > + /*
> >
Convert the OPP v1 and v2 bindings to DT schema format. As the OPPv2 binding
can be extended by vendors, we need to split the common part out from the
"operating-points-v2" conforming compatible.
Cc: Yangtao Li
Cc: Viresh Kumar
Cc: Nishanth Menon
Cc: Stephen Boyd
Cc: Maxime Ripard
Cc: Chen-Yu
In preparation to convert OPP bindings to DT schema, clean-up a few OPP
binding node names in the binding examples.
Cc: Georgi Djakov
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Leonard Crestez
Cc: dri-devel@lists.freedesktop.org
Cc: linux...@vger.kernel.org
Signed-off-by: Rob Herring
---
Documentati
The OPP bindings are one of the most common occurring bindings that are
not yet converted to schema, so let's convert them.
Note this depends on a dtschema change in property-units.yaml to allow
a matrix for opp-microvolt.
Rob
Rob Herring (2):
dt-bindings: Clean-up OPP binding node names in e
Hi Jagan,
Thank you for the patch.
On Mon, Jun 21, 2021 at 12:54:17PM +0530, Jagan Teki wrote:
> Samsung SEC MIPI DSIM Bridge controller is MIPI DSI bridge
> available in NXP's i.MX8M Mini and Nano Processors.
>
> Add bridge driver for it.
>
> Cc: Andrzej Hajda
> Cc: Neil Armstrong
> Cc: Robe
Hi,
On Tue, Jun 22, 2021 at 8:28 PM Bjorn Andersson
wrote:
>
> The existing pxa driver and the upcoming addition of PWM support in the
> TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and
> thereby a need for a of_xlate function with the period as its single
> argument.
>
> Int
On 2021-06-20 10:14 a.m., Theodore Ts'o wrote:
On Thu, Jun 17, 2021 at 10:16:57AM -0500, Alex Sierra wrote:
v1:
AMD is building a system architecture for the Frontier supercomputer with a
coherent interconnect between CPUs and GPUs. This hardware architecture allows
the CPUs to coherently access
On 6/16/2021 11:43 PM, Dale B Stimson wrote:
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
The following standard HWMON power sensors are currently supported
(and appropriately scaled):
/sys/class/drm/card0/device/hwmon/hwmon
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.13-rc7 next-20210623]
[If your patch is applied to the wrong git tree
Hi Dave & Daniel,
Updated to revert last commit which was breaking armv7 build (and
updated description below)
Here is msm-next for v5.14
Notable additions this time around:
* devcoredump support for display errors
* dpu: irq cleanup/refactor
* dpu: dt bindings conversion to yaml
* dsi: dt bind
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.13-rc7 next-20210623]
[If your patch is applied to the wrong git tree
re_class
[ 22.362512][ T256] igb 0006:01:00.0: eth0: PBA No: G69016-004
[ 22.372287][T7] CPU: 13 PID: 7 Comm: kworker/u64:0 Not tainted
5.13.0-rc7-next-20210623+ #47
[ 22.372293][T7] Hardware name: MiTAC RAPTOR EV-883832-X3-0001/RAPTOR,
BIOS 1.6 06/28/2020
[ 22.372298][T7] Workq
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, Claire Chang wrote:
>>> Propagate the swiotlb_force into io_tlb_default_mem->force_bounce and
>>> use it to determine whether to bounce the data or not. This will
On Wed, Jun 23, 2021 at 10:34 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 23, 2021 at 10:00:29PM +0300, Oded Gabbay wrote:
> > On Wed, Jun 23, 2021 at 9:50 PM Jason Gunthorpe wrote:
> > >
> > > On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote:
> > >
> > > > Can you please explain why it
On Wed, 23 Jun 2021 at 20:15, Daniel Vetter wrote:
>
> On Wed, Jun 23, 2021 at 06:27:06PM +0100, Matthew Auld wrote:
> > Looks like it got lost along the way, so add it back. This is needed for
> > the region query uAPI where we want to report a snapshot of how much
> > lmem is available.
> >
> >
On Wed, Jun 23, 2021 at 10:00:29PM +0300, Oded Gabbay wrote:
> On Wed, Jun 23, 2021 at 9:50 PM Jason Gunthorpe wrote:
> >
> > On Wed, Jun 23, 2021 at 09:43:04PM +0300, Oded Gabbay wrote:
> >
> > > Can you please explain why it is so important to (allow) access them
> > > through the CPU ?
> >
> >
On Wed, Jun 23, 2021 at 06:47:37PM +0200, Boris Brezillon wrote:
> On Tue, 22 Jun 2021 18:55:02 +0200
> Daniel Vetter wrote:
>
> > Currently this has no practial relevance I think because there's not
> > many who can pull off a setup with panfrost and another gpu in the
> > same system. But the r
On Wed, Jun 23, 2021 at 06:27:06PM +0100, Matthew Auld wrote:
> Looks like it got lost along the way, so add it back. This is needed for
> the region query uAPI where we want to report a snapshot of how much
> lmem is available.
>
> This time around let's push it directly into the allocator, which
1 - 100 of 238 matches
Mail list logo
