Hi,
[[ CCing John for the trylock parts ]]
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A ke
Hi,
On Tue, Mar 12, 2019 at 11:58:10AM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 11.03.2019 20.23, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
[...]
> > >> +}
> > >> +
> > >> +static
Current driver sets the tile property only for DP MST connectors.
However there are some tiled displays where each SST connector
carries a single tile. So we need to attach this property object
for every connector and set it for every connector (DP SST and MST).
Plus since the tile information is o
On Thu, 2019-02-28 at 18:06 +0200, Imre Deak wrote:
> On Thu, Feb 28, 2019 at 02:32:38AM +0200, Souza, Jose wrote:
> > [...]
> > > > +* and then retrying the probe.
> > > > +*/
> > > > + if (state == INTEL_HOTPLUG_NOCHANGE &&
> > > > + connector->base.status !=
> > >
Right now we are aware of two cases that needs another hotplug retry:
- Unpowered type-c dongles
- HDMI slow unplug
Both have a complete explanation in the code to schedule another run
of the hotplug handler.
It could have more checks to just trigger the retry in those two
specific cases but why
From: Imre Deak
There is some scenarios that we are aware that sink probe can fail,
so lets add the infrastructure to let hotplug() hook to request
another probe after some time.
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
Signed-off-by: Jani Nikula
Signed-off-by: Imre Deak
---
d
This series defines new formats and adds implementation to the i915 driver.
Since posting v1 I have removed the pixel normalize property, as it's not needed
for basic functionality. Also, I have been working on adding support to
userspace, but we can't land any patches until drm_fourcc.h has been u
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
v4:
- Rename variables and move a declaration (Ville)
v6:
- Rebase and fix merge conflict
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: David Airli
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.o
Strange. DMC doesn't look at training patterns. I've asked the PSR2 guys to
look for any cross-connection.
> -Original Message-
> From: Souza, Jose
> Sent: Tuesday, 12 March, 2019 2:29 PM
> To: Vivi, Rodrigo ; Pandiyan, Dhinakaran
>
> Cc: Runyan, Arthur J ; Aigal, Pavana A
> ; intel-gf
On Tue, 2019-03-12 at 14:46 -0700, Pandiyan, Dhinakaran wrote:
> On Tue, 2019-03-12 at 14:28 -0700, Souza, Jose wrote:
> > On Tue, 2019-03-12 at 14:14 -0700, Dhinakaran Pandiyan wrote:
> > > On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> > > > On Tue, Mar 12, 2019 at 01:42:17PM -0700, Jos
On Tue, 2019-03-12 at 14:28 -0700, Souza, Jose wrote:
> On Tue, 2019-03-12 at 14:14 -0700, Dhinakaran Pandiyan wrote:
> > On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> > > On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> > > wrote:
> > > > For some reason if the PSR1 EDP
On Tue, 2019-03-12 at 14:14 -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> > On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> > wrote:
> > > For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is kept
> > > set
> > > while PSR2 is
The part of i915_drop_caches_set() is
Reviewed-by: Yokoyama, Caz
While I don't know whether we don't really need wakeref, calling
intel_runtime_pm_get() makes GPU active state from suspended state for
example. It makes i915_pm_rpm@gem-execbuf-stress-extra-wait test
difficult to make it faster. Th
On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> wrote:
> > For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is kept
> > set
> > while PSR2 is enabled, it causes some selective updates to fail
> > after
> > got back f
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we s
On Tue, 2019-03-12 at 13:53 -0700, Rodrigo Vivi wrote:
> On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza
> wrote:
> > For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is kept
> > set
> > while PSR2 is enabled, it causes some selective updates to fail
> > after
> > got back f
From: Ville Syrjälä
This series mainly fixes the DDB allocation for cursor on skl+.
Currently that is totally busted.
In an effort to optimize cursor behaviour I'm also changing
which plane watermarks we choose to disable. This was inspired
by the 2x-cursor-vs-flip fails, but I don't see how thi
From: Ville Syrjälä
skl_build_pipe_wm() is quite pointless now. Just inline it into
skl_compute_wm().
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 32 ++--
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/drivers/g
From: Ville Syrjälä
We use a fixed ddb allocation for the cursor. Now the calculation
actually makes sure we have enough ddb space, but let's double check
anyway.
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 11 +--
1 file changed, 9 insertions(+),
From: Ville Syrjälä
{skl,icl}_build_plane_wm() don't need to be passed the pipe_wm, so
don't. And skl_build_pipe_wm() can easily dig it out itself.
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 18 +++---
1 file changed, 7 insertions(+), 11 dele
From: Ville Syrjälä
skl_compute_plane_wm() doesn't actually need the plane state. While
it would make logically sense to pass it, we shall need to reuse
skl_compute_plane_wm() to compute the minimum ddb allocation for
the cursor before the cursor may be enabled. Thus we can't rely
on the plane st
From: Ville Syrjälä
Currently we disable all the watermarks above the selected max
level for every plane. That would mean that the cursor's watermarks
may also get modified when another plane causes the selected
max watermark level to change. That is not so great as we would
like to keep the curs
From: Ville Syrjälä
Extract the meat of skl_compute_plane_wm_params() into a lower
level helper that doesn't depend on the plane state. We'll
reuse this for the cursor ddb allocation calculations.
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 84 +++
From: Ville Syrjälä
Clean up skl_allocate_pipe_ddb() a bit by moving the 'wm' variable
to tighter scope. We'll also consitify it where appropriate.
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 23 +--
1 file changed, 13 insertions(+), 1
From: Ville Syrjälä
If the minimum required ddb space for all the planes equals the
total ddb space available we are allowed to use the relevant
watermark level.
Cc: Neel Desai
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Ville Syrjälä
Currently we just assume that 32 or 8 blocks of ddb is sufficient
for the cursor. The 32 might be, but the 8 is certainly not. The
minimum we need is at least what level 0 watermarks need, but that
is a bit restrictive, so instead let's calculate what level 7
would need for a
On 3/7/19 10:44 AM, Sujaritha Sundaresan wrote:
Adding the call to prepare for guc reset along with engine
reset. intel_uc_reset_prepare() calls to disable guc communication
and to sanitize.
Cc: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Signed-off-by: Sujaritha Sundaresan
Reviewed-by: D
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2019-03-12:
- HDCP state handling in ddi_update_pipe
- Protect i915_active iterators from the shrinker
- Reacquire priolist cache after dropping the engine lock
- (Selftest) Always free spinner on __sseu_prepare error
- Acquire breadcrumb ref bef
On Tue, Mar 12, 2019 at 01:42:17PM -0700, José Roberto de Souza wrote:
> For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is kept set
> while PSR2 is enabled, it causes some selective updates to fail after
> got back from DC6 for the first time.
> So lets clear this register before enabled
For some reason if the PSR1 EDP_PSR_TP1_TP3_SEL register is kept set
while PSR2 is enabled, it causes some selective updates to fail after
got back from DC6 for the first time.
So lets clear this register before enabled PSR2, as it could be set
by a previous i915 module, firmware/BIOS or by a previ
On unpinning the intel_context, we remove it from the active list
inside the GEM context. This list is supposed to be guarded by the GEM
context mutex, so remember to take it!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_context.c | 15 +++
drivers/gpu/drm/i915/
For virtual engines, we need to keep the HW context alive while it
remains in use. For regular HW contexts, they are created and kept alive
until the end of the GEM context. For simplicity, generalise the
requirements and keep an active reference to each HW context.
Signed-off-by: Chris Wilson
--
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.
A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we s
This will make hsw_activate_psr1() more easy to read and will make
future modification to TPS registers more easy to review and read.
v4: Rename new function to intel_psr1_get_tp_time() (Dhinakaran and
Rodrigo)
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Reviewed-by: Rodrigo Vivi
Signed-off-by: J
A new field with the training pattern(TP) wakeup time for PSR2 was
added to VBT, so lets use it when available otherwise it will
fallback to PSR1 wakeup time.
v2: replacing enum to numerical usec time (Jani)
BSpec: 20131
Cc: Jani Nikula
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Reviewed-by: Ro
When any other value than EDP_PSR_TP4_TIME_0US is set, TPS1 and TPS4
will be used to do the link training when exiting PSR1.
Happily the eDP panels tested so far was able to sync with source
even without HBR3/TPS4 support but let use the right training
pattern.
TPS4 support was added to PSR1 regis
On Sat, 2019-03-09 at 06:12 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Add new ICL PCI ID
> URL : https://patchwork.freedesktop.org/series/57769/
> State : success
Merged, thanks for the review Rodrigo.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5728_ful
On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dän
Den 12.03.2019 18.37, skrev Noralf Trønnes:
>
>
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 201
Den 12.03.2019 18.25, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds s
On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> >>> This adds support for outputting kernel messages on panic()
Den 12.03.2019 17.17, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>> This adds support for outputting kernel messages on panic().
>>> A kernel message dumper is used to dump the log. The dumper iterates
>
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find
If a test fails, we quite often mark the device as wedged. Provide the
stub functions so that we can wedge the mock device, and avoid exploding
on test failures.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109981
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_engi
We only need to acquire a wakeref for ourselves for a few operations, as
most either already acquire their own wakeref or imply a wakeref. In
particular, it is i915_gem_set_wedged() that needed us to present it
with a wakeref, which is incongruous with its "use anywhere" ability.
Suggested-by: Yok
== Series Details ==
Series: series starting with [1/2] drm/i915: Consolidate reset-request debug
message
URL : https://patchwork.freedesktop.org/series/57872/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735_full -> Patchwork_12440_full
Den 12.03.2019 11.58, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 11.03.2019 20.23, skrev Daniel Vetter:
>>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
This adds support for outputting kernel messages on panic().
>>
== Series Details ==
Series: gpu: i915: fix a missing check of get_free_page
URL : https://patchwork.freedesktop.org/series/57850/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735_full -> Patchwork_12438_full
Summary
Quoting Mika Kuoppala (2019-03-12 12:33:37)
> Chris Wilson writes:
>
> > Use a timedwait to promptly detect if the recovery after reset fails and
> > provide a meaningful debug dump.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > .../gpu/drm/i915/selftests/intel_hangcheck.c | 18
Chris Wilson writes:
> Use a timedwait to promptly detect if the recovery after reset fails and
> provide a meaningful debug dump.
>
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/i915/selftests/intel_hangcheck.c | 18 +-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
Quoting Mika Kuoppala (2019-03-12 12:23:15)
> Chris Wilson writes:
>
> > Move the pair of messages to the common callsite where it makes sense to
> > include a bit more information about which request is being reset.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > ---
> > drivers
Chris Wilson writes:
> Move the pair of messages to the common callsite where it makes sense to
> include a bit more information about which request is being reset.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_reset.c | 6 ++
> drivers/gpu/drm
== Series Details ==
Series: series starting with [1/2] drm/i915: Consolidate reset-request debug
message
URL : https://patchwork.freedesktop.org/series/57872/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735 -> Patchwork_12440
==
== Series Details ==
Series: gpu: i915: fix a missing check of get_free_page
URL : https://patchwork.freedesktop.org/series/57850/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735_full -> Patchwork_12438_full
Summary
Move the pair of messages to the common callsite where it makes sense to
include a bit more information about which request is being reset.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 6 ++
drivers/gpu/drm/i915/intel_lrc.c| 1 -
driver
Use a timedwait to promptly detect if the recovery after reset fails and
provide a meaningful debug dump.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/selftests/intel_hangcheck.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/sel
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>
>
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A kernel message dumper is used to dump the l
On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are run before this o
Hello!
I've been recently scouring through journalctl because of another error
and found this kernel error multiple times:
Nov 09 17:49:35 Leonidas kernel:
[drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A
FIFO underrun
They started happening around beginning of November 2018 a
Quoting Tvrtko Ursulin (2019-03-12 10:23:12)
>
> On 08/03/2019 18:11, Chris Wilson wrote:
> > Exercise the in-kernel load balancer checking that we can distribute
> > batches across the set of ctx->engines to avoid load.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > tests/Makefile.am
== Series Details ==
Series: gpu: i915: fix a missing check of get_free_page
URL : https://patchwork.freedesktop.org/series/57850/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735 -> Patchwork_12438
Summary
---
**S
On Mon, 11 Mar 2019, Rodrigo Vivi wrote:
> On Mon, Mar 11, 2019 at 11:12:06AM +0200, Jani Nikula wrote:
>> On Fri, 08 Mar 2019, Lucas De Marchi wrote:
>> > On Fri, Mar 08, 2019 at 02:39:36PM -0800, Rodrigo Vivi wrote:
>> >>> Given that every platform so far has had different oa configurations,
>>
On 08/03/2019 18:11, Chris Wilson wrote:
Exercise the in-kernel load balancer checking that we can distribute
batches across the set of ctx->engines to avoid load.
Signed-off-by: Chris Wilson
---
tests/Makefile.am | 1 +
tests/Makefile.sources | 1 +
tests/i915/gem
== Series Details ==
Series: drm: Add panic handling (rev2)
URL : https://patchwork.freedesktop.org/series/57848/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
DESCEND objtool
CHK include/generated/compile.h
make[3]: *** No rule to make target 'drivers/gpu/drm/drm_pan
On Tue, Mar 12, 2019 at 10:53:20AM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 11.03.2019 20.29, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> > >> On Mon, Mar 11, 2019 at 06:42:16PM +0
On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
>
>
> Den 11.03.2019 20.29, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> >> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >>> This adds support for outputting kernel me
== Series Details ==
Series: drm: Add panic handling
URL : https://patchwork.freedesktop.org/series/57848/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5735 -> Patchwork_12437
Summary
---
**SUCCESS**
No regressio
== Series Details ==
Series: gpu: i915: fix a missing check of get_free_page
URL : https://patchwork.freedesktop.org/series/57850/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: gpu: i915: fix a missing check of get_free_page
-drivers/gpu/drm/i915/i915
== Series Details ==
Series: drm: Add panic handling
URL : https://patchwork.freedesktop.org/series/57848/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm: Add support for panic message output
Okay!
Commit: drm/cma-helper: Add support for panic scr
== Series Details ==
Series: drm: Add panic handling
URL : https://patchwork.freedesktop.org/series/57848/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
24e305856f34 drm: Add support for panic message output
-:191: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), doe
Quoting Tvrtko Ursulin (2019-03-12 07:52:08)
>
> On 08/03/2019 14:12, Chris Wilson wrote:
> > +static int
> > +set_engines__load_balance(struct i915_user_extension __user *base, void
> > *data)
> > +{
> > + struct i915_context_engines_load_balance __user *ext =
> > + container_of_
On Tue, 12 Mar 2019, Al Viro wrote:
> On Mon, Mar 11, 2019 at 08:59:00PM -0700, syzbot wrote:
>> syzbot has bisected this bug to:
>>
>> commit 34e07e42c55aeaa78e93b057a6664e2ecde3fadb
>> Author: Chris Wilson
>> Date: Thu Feb 8 10:54:48 2018 +
>>
>> drm/i915: Add missing kerneldoc for
On 08/03/2019 14:12, Chris Wilson wrote:
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the
75 matches
Mail list logo
