* [PATCH] i2c: davinci: Avoid zero value of CLKH
From: Wolfram Sang @ 2018-07-23 18:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180713152017.2207-1-alexander.sverdlin@nokia.com>
On Fri, Jul 13, 2018 at 05:20:17PM +0200, Alexander Sverdlin wrote:
> If CLKH is set to 0 I2C clock is not generated at all, so avoid this value
> and stretch the clock in this case.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Applied to for-current, thanks!
I did not add stable because Alexander told me this is very likely not
to be observed on HW out there. But TI people are investigating more.
I suggest they resend this patch to stable if they see fit. D'accord
everyone?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180723/8ea58ced/attachment.sig>
^ permalink raw reply
* Re: [PATCH] i2c: davinci: Avoid zero value of CLKH
From: Wolfram Sang @ 2018-07-23 18:07 UTC (permalink / raw)
To: Alexander Sverdlin; +Cc: Sekhar Nori, linux-i2c, linux-arm-kernel, Kevin Hilman
In-Reply-To: <20180713152017.2207-1-alexander.sverdlin@nokia.com>
[-- Attachment #1.1: Type: text/plain, Size: 521 bytes --]
On Fri, Jul 13, 2018 at 05:20:17PM +0200, Alexander Sverdlin wrote:
> If CLKH is set to 0 I2C clock is not generated at all, so avoid this value
> and stretch the clock in this case.
>
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Applied to for-current, thanks!
I did not add stable because Alexander told me this is very likely not
to be observed on HW out there. But TI people are investigating more.
I suggest they resend this patch to stable if they see fit. D'accord
everyone?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] media: usb: pwc: Don't use coherent DMA buffers for ISO transfer
From: Matwey V. Kornilov @ 2018-07-23 17:04 UTC (permalink / raw)
To: Tomasz Figa
Cc: Alan Stern, Ezequiel Garcia, Hans de Goede, Hans Verkuil,
Mauro Carvalho Chehab, Laurent Pinchart, Steven Rostedt, mingo,
Mike Isely, Bhumika Goyal, Colin King, Linux Media Mailing List,
Linux Kernel Mailing List, Kieran Bingham, keiichiw
In-Reply-To: <CAJs94EaXpiHaJS0M7SxUtmjNAL869sPe9XpC1rorHgJOum-Oog@mail.gmail.com>
2018-07-20 14:57 GMT+03:00 Matwey V. Kornilov <matwey@sai.msu.ru>:
> 2018-07-20 14:33 GMT+03:00 Tomasz Figa <tfiga@chromium.org>:
>> On Fri, Jul 20, 2018 at 8:23 PM Matwey V. Kornilov <matwey@sai.msu.ru> wrote:
>>>
>>> 2018-07-20 13:55 GMT+03:00 Tomasz Figa <tfiga@chromium.org>:
>>> > On Wed, Jul 18, 2018 at 5:51 AM Alan Stern <stern@rowland.harvard.edu> wrote:
>>> >>
>>> >> On Tue, 17 Jul 2018, Ezequiel Garcia wrote:
>>> >>
>>> >> > Hi Matwey,
>>> >> >
>>> >> > First of all, sorry for the delay.
>>> >> >
>>> >> > Adding Alan and Hans. Guys, do you have any feedback here?
>>> >>
>>> >> ...
>>> >>
>>> >> > > > So, what is the benefit of using consistent
>>> >> > > > for these URBs, as opposed to streaming?
>>> >> > >
>>> >> > > I don't know, I think there is no real benefit and all we see is a
>>> >> > > consequence of copy-pasta when some webcam drivers were inspired by
>>> >> > > others and development priparily was going at x86 platforms.
>>> >> >
>>> >> > You are probably right about the copy-pasta.
>>> >> >
>>> >> > > It would
>>> >> > > be great if somebody corrected me here. DMA Coherence is quite strong
>>> >> > > property and I cannot figure out how can it help when streaming video.
>>> >> > > The CPU host always reads from the buffer and never writes to.
>>> >> > > Hardware perepherial always writes to and never reads from. Moreover,
>>> >> > > buffer access is mutually exclusive and separated in time by Interrupt
>>> >> > > fireing and URB starting (when we reuse existing URB for new request).
>>> >> > > Only single one memory barrier is really required here.
>>> >> > >
>>> >> >
>>> >> > Yeah, and not setting URB_NO_TRANSFER_DMA_MAP makes the USB core
>>> >> > create DMA mappings and use the streaming API. Which makes more
>>> >> > sense in hardware without hardware coherency.
>>> >>
>>> >> As far as I know, the _only_ advantage to using coherent DMA in this
>>> >> situation is that you then do not have to pay the overhead of
>>> >> constantly setting up and tearing down the streaming mappings. So it
>>> >> depends very much on the platform: If coherent buffers are cached then
>>> >> it's a slight win and otherwise it's a big lose.
>>> >
>>> > Isn't it about usb_alloc_coherent() being backed by DMA coherent API
>>> > (dma_alloc_coherent/attrs()) and ending up allocating uncached (or
>>> > write-combine) memory for devices with non-coherent DMAs? I'm not sure
>>>
>>> Yes, this is what exactly happens at armv7l platforms.
>>
>> Okay, thanks. So this seems to be exactly the same thing that is
>> happening in the UVC driver. There is quite a bit of random accesses
>> to extract some header fields and then a big memcpy into VB2 buffer to
>> assemble final frame.
>>
>> If we don't want to pay the cost of creating and destroying the
>> streaming mapping, we could map (dma_map_single()) once, set
>> transfer_dma of URB and URB_NO_TRANSFER_DMA_MAP and then just
>> synchronize the caches (dma_sync_single()) before submitting/after
>> completing the URB.
>
> Thank you. Now it is becoming clearer to me. Please allow me some time
> to try to sketch the implementation.
I've tried to strategies:
1) Use dma_unmap and dma_map inside the handler (I suppose this is
similar to how USB core does when there is no URB_NO_TRANSFER_DMA_MAP)
2) Use sync_cpu and sync_device inside the handler (and dma_map only
once at memory allocation)
It is interesting that dma_unmap/dma_map pair leads to the lower
overhead (+1us) than sync_cpu/sync_device (+2us) at x86_64 platform.
At armv7l platform using dma_unmap/dma_map leads to ~50 usec in the
handler, and sync_cpu/sync_device - ~65 usec.
However, I am not sure is it mandatory to call
dma_sync_single_for_device for FROM_DEVICE direction?
>
>>
>> Best regards,
>> Tomasz
>>
>
>
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119234, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
^ permalink raw reply
* Re: [PATCH v2] pack-objects: fix performance issues on packing large deltas
From: Junio C Hamano @ 2018-07-23 18:04 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Elijah Newren, Jeff King
In-Reply-To: <20180722080421.12887-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Access to e->delta_size_ (and by extension
> pack->delta_size[e - pack->objects]) is unprotected as before, the
> thread scheduler in pack-objects must make sure "e" is never updated
> by two different threads.
OK. Do we need to worry about "e" (e.g. "e->delta_size_valid")
being accessed while/before it is set by another thread?
oe_delta_size() makes unprotected accesses to .delta_size_ and
pack->delta_size[e - pack->objects], so we apparently do not, and
oe_set_delta_size() only protects the allocation call and does not
prevent a reader in oe_delta_size() from first reading the _valid
field, noticing that it is 0 as initialized, and goes on to read the
pack->delta_size[] slot for the entry, while the writer is setting
the size to .delta_size_ field and flipping _valid bit, without ever
storing the size in the pack->delta_size[] array.
> @@ -130,6 +131,7 @@ struct packing_data {
> uint32_t index_size;
>
> unsigned int *in_pack_pos;
> + unsigned long *delta_size;
>
> /*
> * Only one of these can be non-NULL and they have different
> @@ -140,10 +142,29 @@ struct packing_data {
> struct packed_git **in_pack_by_idx;
> struct packed_git **in_pack;
>
> +#ifndef NO_PTHREADS
> + pthread_mutex_t lock;
I am wondering if we want the variable to say what data it is
protecting from simultaneous accesses, or leave it as generic so
that any new caller that wants to lock any (new) thing that is
associated with a packing_data structure can grab it for other
purposes. The design of this patch clearly is the latter, which is
OK for now, I think.
> @@ -332,18 +353,34 @@ static inline unsigned long oe_delta_size(struct packing_data *pack,
> {
> if (e->delta_size_valid)
> return e->delta_size_;
> - return oe_size(pack, e);
> +
> + /*
> + * pack->detla_size[] can't be NULL because oe_set_delta_size()
> + * must have been called when a new delta is saved with
> + * oe_set_delta().
> + * If oe_delta() returns NULL (i.e. default state, which means
> + * delta_size_valid is also false), then the caller must never
> + * call oe_delta_size().
> + */
> + return pack->delta_size[e - pack->objects];
> }
>
> static inline void oe_set_delta_size(struct packing_data *pack,
> struct object_entry *e,
> unsigned long size)
> {
> - e->delta_size_ = size;
> - e->delta_size_valid = e->delta_size_ == size;
> - if (!e->delta_size_valid && size != oe_size(pack, e))
> - BUG("this can only happen in check_object() "
> - "where delta size is the same as entry size");
> + if (size < pack->oe_delta_size_limit) {
> + e->delta_size_ = size;
> + e->delta_size_valid = 1;
> + } else {
> + packing_data_lock(pack);
> + if (!pack->delta_size)
> + ALLOC_ARRAY(pack->delta_size, pack->nr_alloc);
> + packing_data_unlock(pack);
> +
> + pack->delta_size[e - pack->objects] = size;
> + e->delta_size_valid = 0;
> + }
> }
^ permalink raw reply
* [Qemu-arm] [PATCH for-3.0?] hw/intc/arm_gicv3: Check correct HCR_EL2 bit when routing IRQ
From: Peter Maydell @ 2018-07-23 18:03 UTC (permalink / raw)
To: qemu-arm, qemu-devel; +Cc: patches
In icc_dir_write() we were incorrectly checking HCR_EL2.FMO
when determining whether IRQ should be routed to EL2; this should
be HCR_EL2.IMO (compare the GICv3 pseudocode ICC_DIR_EL1[]).
Use the correct mask.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
Cut-n-paste bug we've had since forever. Linux always sets
FMO and IMO to the same thing, so we haven't noticed this.
Probably should go into 3.0, though...
hw/intc/arm_gicv3_cpuif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 5c89be1af07..2a60568d82c 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -1550,7 +1550,7 @@ static void icc_dir_write(CPUARMState *env, const ARMCPRegInfo *ri,
* tested in cases where we know !IsSecure is true.
*/
route_fiq_to_el2 = env->cp15.hcr_el2 & HCR_FMO;
- route_irq_to_el2 = env->cp15.hcr_el2 & HCR_FMO;
+ route_irq_to_el2 = env->cp15.hcr_el2 & HCR_IMO;
switch (arm_current_el(env)) {
case 3:
--
2.17.1
^ permalink raw reply related
* [Qemu-devel] [PATCH for-3.0?] hw/intc/arm_gicv3: Check correct HCR_EL2 bit when routing IRQ
From: Peter Maydell @ 2018-07-23 18:03 UTC (permalink / raw)
To: qemu-arm, qemu-devel; +Cc: patches
In icc_dir_write() we were incorrectly checking HCR_EL2.FMO
when determining whether IRQ should be routed to EL2; this should
be HCR_EL2.IMO (compare the GICv3 pseudocode ICC_DIR_EL1[]).
Use the correct mask.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
Cut-n-paste bug we've had since forever. Linux always sets
FMO and IMO to the same thing, so we haven't noticed this.
Probably should go into 3.0, though...
hw/intc/arm_gicv3_cpuif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/intc/arm_gicv3_cpuif.c b/hw/intc/arm_gicv3_cpuif.c
index 5c89be1af07..2a60568d82c 100644
--- a/hw/intc/arm_gicv3_cpuif.c
+++ b/hw/intc/arm_gicv3_cpuif.c
@@ -1550,7 +1550,7 @@ static void icc_dir_write(CPUARMState *env, const ARMCPRegInfo *ri,
* tested in cases where we know !IsSecure is true.
*/
route_fiq_to_el2 = env->cp15.hcr_el2 & HCR_FMO;
- route_irq_to_el2 = env->cp15.hcr_el2 & HCR_FMO;
+ route_irq_to_el2 = env->cp15.hcr_el2 & HCR_IMO;
switch (arm_current_el(env)) {
case 3:
--
2.17.1
^ permalink raw reply related
* [PATCH v3] compress/isal: add chained mbuf support
From: Daly, Lee @ 2018-07-23 18:02 UTC (permalink / raw)
To: pablo.de.lara.guarch; +Cc: dev, Daly, Lee
In-Reply-To: <1531312811-177746-1-git-send-email-lee.daly@intel.com>
This patch adds chained mbuf support for input or output buffers
during compression/decompression operations.
Signed-off-by: Lee Daly <lee.daly@intel.com>
---
doc/guides/compressdevs/features/isal.ini | 17 +-
doc/guides/compressdevs/isal.rst | 2 -
drivers/compress/isal/isal_compress_pmd.c | 397 ++++++++++++++++++++------
drivers/compress/isal/isal_compress_pmd_ops.c | 5 +-
4 files changed, 323 insertions(+), 98 deletions(-)
diff --git a/doc/guides/compressdevs/features/isal.ini b/doc/guides/compressdevs/features/isal.ini
index 7183d10..919cf70 100644
--- a/doc/guides/compressdevs/features/isal.ini
+++ b/doc/guides/compressdevs/features/isal.ini
@@ -4,10 +4,13 @@
; Supported features of 'ISA-L' compression driver.
;
[Features]
-CPU SSE = Y
-CPU AVX = Y
-CPU AVX2 = Y
-CPU AVX512 = Y
-Deflate = Y
-Fixed = Y
-Dynamic = Y
+CPU SSE = Y
+CPU AVX = Y
+CPU AVX2 = Y
+CPU AVX512 = Y
+OOP SGL In SGL Out = Y
+OOP SGL In LB Out = Y
+OOP LB In SGL Out = Y
+Deflate = Y
+Fixed = Y
+Dynamic = Y
diff --git a/doc/guides/compressdevs/isal.rst b/doc/guides/compressdevs/isal.rst
index 276ff06..3bc3022 100644
--- a/doc/guides/compressdevs/isal.rst
+++ b/doc/guides/compressdevs/isal.rst
@@ -78,8 +78,6 @@ As a result the level mappings from the API to the PMD are shown below.
Limitations
-----------
-* Chained mbufs will not be supported until a future release, meaning max data size being passed to PMD through a single mbuf is 64K - 1. If data is larger than this it will need to be split up and sent as multiple operations.
-
* Compressdev level 0, no compression, is not supported.
* Checksums will not be supported until future release.
diff --git a/drivers/compress/isal/isal_compress_pmd.c b/drivers/compress/isal/isal_compress_pmd.c
index 5966cc3..a776019 100644
--- a/drivers/compress/isal/isal_compress_pmd.c
+++ b/drivers/compress/isal/isal_compress_pmd.c
@@ -188,6 +188,206 @@ isal_comp_set_priv_xform_parameters(struct isal_priv_xform *priv_xform,
return 0;
}
+/* Compression using chained mbufs for input/output data */
+static int
+chained_mbuf_compression(struct rte_comp_op *op, struct isal_comp_qp *qp)
+{
+ int ret;
+ uint32_t remaining_offset;
+ uint32_t remaining_data = op->src.length;
+ struct rte_mbuf *src = op->m_src;
+ struct rte_mbuf *dst = op->m_dst;
+
+ /* check for offset passing multiple segments
+ * and point compression stream to input/output buffer
+ */
+ if (op->src.offset > src->data_len) {
+ remaining_offset = op->src.offset;
+ while (remaining_offset > src->data_len) {
+ remaining_offset -= src->data_len;
+ src = src->next;
+ }
+
+
+ qp->stream->avail_in = src->data_len - remaining_offset;
+ qp->stream->next_in = rte_pktmbuf_mtod_offset(src, uint8_t *,
+ (op->src.offset % src->data_len));
+ } else {
+ qp->stream->avail_in = src->data_len - op->src.offset;
+ qp->stream->next_in = rte_pktmbuf_mtod_offset(src, uint8_t *,
+ op->src.offset);
+ }
+
+ if (op->dst.offset > dst->data_len) {
+ remaining_offset = op->dst.offset;
+ while (remaining_offset > dst->data_len) {
+ remaining_offset -= dst->data_len;
+ dst = dst->next;
+ }
+
+ qp->stream->avail_out = dst->data_len - remaining_offset;
+ qp->stream->next_out = rte_pktmbuf_mtod_offset(dst, uint8_t *,
+ (op->dst.offset % dst->data_len));
+ } else {
+ qp->stream->avail_out = dst->data_len - op->dst.offset;
+ qp->stream->next_out = rte_pktmbuf_mtod_offset(dst, uint8_t *,
+ op->dst.offset);
+ }
+
+ if (unlikely(!qp->stream->next_in || !qp->stream->next_out)) {
+ ISAL_PMD_LOG(ERR, "Invalid source or destination buffer\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
+
+ while (qp->stream->internal_state.state != ZSTATE_END) {
+ /* Last segment of data */
+ if (remaining_data <= src->data_len)
+ qp->stream->end_of_stream = 1;
+
+ /* Execute compression operation */
+ ret = isal_deflate(qp->stream);
+
+ remaining_data = op->src.length - qp->stream->total_in;
+
+ if (ret != COMP_OK) {
+ ISAL_PMD_LOG(ERR, "Compression operation failed\n");
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return ret;
+ }
+
+ if (qp->stream->avail_in == 0 &&
+ qp->stream->total_in != op->src.length) {
+ if (src->next != NULL) {
+ src = src->next;
+ qp->stream->next_in =
+ rte_pktmbuf_mtod(src, uint8_t *);
+ qp->stream->avail_in =
+ RTE_MIN(remaining_data, src->data_len);
+ } else {
+ ISAL_PMD_LOG(ERR,
+ "Not enough input buffer segments\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
+ }
+
+ if (qp->stream->avail_out == 0 &&
+ qp->stream->internal_state.state != ZSTATE_END) {
+ if (dst->next != NULL) {
+ dst = dst->next;
+ qp->stream->next_out =
+ rte_pktmbuf_mtod(dst, uint8_t *);
+ qp->stream->avail_out = dst->data_len;
+ } else {
+ ISAL_PMD_LOG(ERR,
+ "Not enough output buffer segments\n");
+ op->status =
+ RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
+ return -1;
+ }
+ }
+ }
+ op->consumed = qp->stream->total_in;
+ op->produced = qp->stream->total_out;
+
+ return 0;
+}
+
+/* Decompression using chained mbufs for input/output data */
+static int
+chained_mbuf_decompression(struct rte_comp_op *op, struct isal_comp_qp *qp)
+{
+ int ret;
+ uint32_t consumed_data, remaining_offset;
+ uint32_t remaining_data = op->src.length;
+ struct rte_mbuf *src = op->m_src;
+ struct rte_mbuf *dst = op->m_dst;
+
+ /* check for offset passing multiple segments
+ * and point decompression state to input/output buffer
+ */
+ if (op->src.offset > src->data_len) {
+ remaining_offset = op->src.offset;
+ while (remaining_offset > src->data_len) {
+ remaining_offset -= src->data_len;
+ src = src->next;
+ }
+
+ qp->state->avail_in = src->data_len - remaining_offset;
+ qp->state->next_in = rte_pktmbuf_mtod_offset(src,
+ uint8_t *, (op->src.offset % src->data_len));
+ } else {
+ qp->state->avail_in = src->data_len - op->src.offset;
+ qp->state->next_in = rte_pktmbuf_mtod_offset(src, uint8_t *,
+ op->src.offset);
+ }
+ if (op->dst.offset > dst->data_len) {
+ remaining_offset = op->dst.offset;
+ while (remaining_offset > dst->data_len) {
+ remaining_offset -= dst->data_len;
+ dst = dst->next;
+ }
+
+ qp->state->avail_out = dst->data_len - remaining_offset;
+ qp->state->next_out = rte_pktmbuf_mtod_offset(dst, uint8_t *,
+ (op->dst.offset % dst->data_len));
+ } else {
+ qp->state->avail_out = dst->data_len - op->dst.offset;
+ qp->state->next_out = rte_pktmbuf_mtod_offset(dst, uint8_t *,
+ op->dst.offset);
+ }
+ while (qp->state->block_state != ISAL_BLOCK_FINISH) {
+
+ ret = isal_inflate(qp->state);
+
+ if (remaining_data == op->src.length) {
+ consumed_data = src->data_len - qp->state->avail_in -
+ (op->src.offset % src->data_len);
+ } else
+ consumed_data = src->data_len - qp->state->avail_in;
+
+ op->consumed += consumed_data;
+ remaining_data -= consumed_data;
+
+ if (ret != ISAL_DECOMP_OK) {
+ ISAL_PMD_LOG(ERR, "Decompression operation failed\n");
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return ret;
+ }
+
+ if (qp->state->avail_in == 0
+ && op->consumed != op->src.length) {
+ if (src->next != NULL) {
+ src = src->next;
+ qp->state->next_in =
+ rte_pktmbuf_mtod(src, uint8_t *);
+ qp->state->avail_in =
+ RTE_MIN(remaining_data, src->data_len);
+ }
+ }
+
+ if (qp->state->avail_out == 0 &&
+ qp->state->block_state != ISAL_BLOCK_FINISH) {
+ if (dst->next != NULL) {
+ dst = dst->next;
+ qp->state->next_out =
+ rte_pktmbuf_mtod(dst, uint8_t *);
+ qp->state->avail_out = dst->data_len;
+ } else {
+ ISAL_PMD_LOG(ERR,
+ "Not enough output buffer segments\n");
+ op->status =
+ RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
+ return -1;
+ }
+ }
+ }
+ op->produced = qp->state->total_out;
+
+ return 0;
+}
+
/* Stateless Compression Function */
static int
process_isal_deflate(struct rte_comp_op *op, struct isal_comp_qp *qp,
@@ -207,7 +407,7 @@ process_isal_deflate(struct rte_comp_op *op, struct isal_comp_qp *qp,
/* Stateless operation, input will be consumed in one go */
qp->stream->flush = NO_FLUSH;
- /* set op level & intermediate level buffer */
+ /* set compression level & intermediate level buffer size */
qp->stream->level = priv_xform->compress.level;
qp->stream->level_buf_size = priv_xform->level_buffer_size;
@@ -225,59 +425,70 @@ process_isal_deflate(struct rte_comp_op *op, struct isal_comp_qp *qp,
isal_deflate_set_hufftables(qp->stream, NULL,
IGZIP_HUFFTABLE_DEFAULT);
- qp->stream->end_of_stream = 1; /* All input consumed in one go */
- if ((op->src.length + op->src.offset) > op->m_src->data_len) {
- ISAL_PMD_LOG(ERR, "Input mbuf not big enough for the length and"
- " offset provided.\n");
- op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
- return -1;
- }
- /* Point compression stream to input buffer */
- qp->stream->avail_in = op->src.length;
- qp->stream->next_in = rte_pktmbuf_mtod_offset(op->m_src, uint8_t *,
- op->src.offset);
-
- if (op->dst.offset > op->m_dst->data_len) {
- ISAL_PMD_LOG(ERR, "Output mbuf not big enough for the length"
- " and offset provided.\n");
+ if (op->m_src->pkt_len < (op->src.length + op->src.offset)) {
+ ISAL_PMD_LOG(ERR, "Input mbuf(s) not big enough.\n");
op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
return -1;
}
- /* Point compression stream to output buffer */
- qp->stream->avail_out = op->m_dst->data_len - op->dst.offset;
- qp->stream->next_out = rte_pktmbuf_mtod_offset(op->m_dst, uint8_t *,
- op->dst.offset);
- if (unlikely(!qp->stream->next_in || !qp->stream->next_out)) {
- ISAL_PMD_LOG(ERR, "Invalid source or destination buffers\n");
- op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
- return -1;
- }
+ /* Chained mbufs */
+ if (op->m_src->nb_segs > 1 || op->m_dst->nb_segs > 1) {
+ ret = chained_mbuf_compression(op, qp);
+ if (ret < 0)
+ return ret;
+ } else {
+ /* Linear buffer */
+ qp->stream->end_of_stream = 1; /* All input consumed in one */
+ /* Point compression stream to input buffer */
+ qp->stream->avail_in = op->src.length;
+ qp->stream->next_in = rte_pktmbuf_mtod_offset(op->m_src,
+ uint8_t *, op->src.offset);
+
+ if (op->dst.offset > op->m_dst->data_len) {
+ ISAL_PMD_LOG(ERR, "Output mbuf not big enough for "
+ "length and offset provided.\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
+ /* Point compression stream to output buffer */
+ qp->stream->avail_out = op->m_dst->data_len - op->dst.offset;
+ qp->stream->next_out = rte_pktmbuf_mtod_offset(op->m_dst,
+ uint8_t *, op->dst.offset);
+
+ if (unlikely(!qp->stream->next_in || !qp->stream->next_out)) {
+ ISAL_PMD_LOG(ERR, "Invalid source or destination"
+ " buffers\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
- /* Execute compression operation */
- ret = isal_deflate_stateless(qp->stream);
+ /* Execute compression operation */
+ ret = isal_deflate_stateless(qp->stream);
- /* Check that output buffer did not run out of space */
- if (ret == STATELESS_OVERFLOW) {
- ISAL_PMD_LOG(ERR, "Output buffer not big enough\n");
- op->status = RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
- return ret;
- }
+ /* Check that output buffer did not run out of space */
+ if (ret == STATELESS_OVERFLOW) {
+ ISAL_PMD_LOG(ERR, "Output buffer not big enough\n");
+ op->status = RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
+ return ret;
+ }
- /* Check that input buffer has been fully consumed */
- if (qp->stream->avail_in != (uint32_t)0) {
- ISAL_PMD_LOG(ERR, "Input buffer could not be read entirely\n");
- op->status = RTE_COMP_OP_STATUS_ERROR;
- return -1;
- }
+ /* Check that input buffer has been fully consumed */
+ if (qp->stream->avail_in != (uint32_t)0) {
+ ISAL_PMD_LOG(ERR, "Input buffer could not be read"
+ " entirely\n");
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return -1;
+ }
- if (ret != COMP_OK) {
- op->status = RTE_COMP_OP_STATUS_ERROR;
- return ret;
- }
+ if (ret != COMP_OK) {
+ ISAL_PMD_LOG(ERR, "Compression operation failed\n");
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return ret;
+ }
- op->consumed = qp->stream->total_in;
- op->produced = qp->stream->total_out;
+ op->consumed = qp->stream->total_in;
+ op->produced = qp->stream->total_out;
+ }
return ret;
}
@@ -293,59 +504,69 @@ process_isal_inflate(struct rte_comp_op *op, struct isal_comp_qp *qp)
/* Initialize decompression state */
isal_inflate_init(qp->state);
- if ((op->src.length + op->src.offset) > op->m_src->data_len) {
- ISAL_PMD_LOG(ERR, "Input mbuf not big enough for the length and"
- " offset provided.\n");
- op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
- return -1;
- }
- /* Point decompression state to input buffer */
- qp->state->avail_in = op->src.length;
- qp->state->next_in = rte_pktmbuf_mtod_offset(op->m_src, uint8_t *,
- op->src.offset);
-
- if (op->dst.offset > op->m_dst->data_len) {
- ISAL_PMD_LOG(ERR, "Output mbuf not big enough for the length "
- "and offset provided.\n");
+ if (op->m_src->pkt_len < (op->src.length + op->src.offset)) {
+ ISAL_PMD_LOG(ERR, "Input mbuf(s) not big enough.\n");
op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
return -1;
}
- /* Point decompression state to output buffer */
- qp->state->avail_out = op->m_dst->data_len - op->dst.offset;
- qp->state->next_out = rte_pktmbuf_mtod_offset(op->m_dst, uint8_t *,
- op->dst.offset);
- if (unlikely(!qp->state->next_in || !qp->state->next_out)) {
- ISAL_PMD_LOG(ERR, "Invalid source or destination buffers\n");
- op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
- return -1;
- }
+ /* Chained mbufs */
+ if (op->m_src->nb_segs > 1 || op->m_dst->nb_segs > 1) {
+ ret = chained_mbuf_decompression(op, qp);
+ if (ret != 0)
+ return ret;
+ } else {
+ /* Linear buffer */
+ /* Point decompression state to input buffer */
+ qp->state->avail_in = op->src.length;
+ qp->state->next_in = rte_pktmbuf_mtod_offset(op->m_src,
+ uint8_t *, op->src.offset);
+
+ if (op->dst.offset > op->m_dst->data_len) {
+ ISAL_PMD_LOG(ERR, "Output mbuf not big enough for "
+ "length and offset provided.\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
+ /* Point decompression state to output buffer */
+ qp->state->avail_out = op->m_dst->data_len - op->dst.offset;
+ qp->state->next_out = rte_pktmbuf_mtod_offset(op->m_dst,
+ uint8_t *, op->dst.offset);
+
+ if (unlikely(!qp->state->next_in || !qp->state->next_out)) {
+ ISAL_PMD_LOG(ERR, "Invalid source or destination"
+ " buffers\n");
+ op->status = RTE_COMP_OP_STATUS_INVALID_ARGS;
+ return -1;
+ }
- /* Execute decompression operation */
- ret = isal_inflate_stateless(qp->state);
+ /* Execute decompression operation */
+ ret = isal_inflate_stateless(qp->state);
- if (ret == ISAL_OUT_OVERFLOW) {
- ISAL_PMD_LOG(ERR, "Output buffer not big enough\n");
- op->status = RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
- return ret;
- }
+ if (ret == ISAL_OUT_OVERFLOW) {
+ ISAL_PMD_LOG(ERR, "Output buffer not big enough\n");
+ op->status = RTE_COMP_OP_STATUS_OUT_OF_SPACE_TERMINATED;
+ return ret;
+ }
- /* Check that input buffer has been fully consumed */
- if (qp->state->avail_in != (uint32_t)0) {
- ISAL_PMD_LOG(ERR, "Input buffer could not be read entirely\n");
- op->status = RTE_COMP_OP_STATUS_ERROR;
- return -1;
- }
+ /* Check that input buffer has been fully consumed */
+ if (qp->state->avail_in != (uint32_t)0) {
+ ISAL_PMD_LOG(ERR, "Input buffer could not be read"
+ " entirely\n");
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return -1;
+ }
- if (ret != ISAL_DECOMP_OK) {
- op->status = RTE_COMP_OP_STATUS_ERROR;
- return ret;
- }
+ if (ret != ISAL_DECOMP_OK) {
+ op->status = RTE_COMP_OP_STATUS_ERROR;
+ return ret;
+ }
- op->consumed = op->src.length - qp->state->avail_in;
- op->produced = qp->state->total_out;
+ op->consumed = op->src.length - qp->state->avail_in;
+ op->produced = qp->state->total_out;
+ }
-return ret;
+ return ret;
}
/* Process compression/decompression operation */
diff --git a/drivers/compress/isal/isal_compress_pmd_ops.c b/drivers/compress/isal/isal_compress_pmd_ops.c
index c61acd4..41cade8 100644
--- a/drivers/compress/isal/isal_compress_pmd_ops.c
+++ b/drivers/compress/isal/isal_compress_pmd_ops.c
@@ -12,7 +12,10 @@
static const struct rte_compressdev_capabilities isal_pmd_capabilities[] = {
{
.algo = RTE_COMP_ALGO_DEFLATE,
- .comp_feature_flags = RTE_COMP_FF_SHAREABLE_PRIV_XFORM |
+ .comp_feature_flags = RTE_COMP_FF_OOP_SGL_IN_SGL_OUT |
+ RTE_COMP_FF_OOP_SGL_IN_LB_OUT |
+ RTE_COMP_FF_OOP_LB_IN_SGL_OUT |
+ RTE_COMP_FF_SHAREABLE_PRIV_XFORM |
RTE_COMP_FF_HUFFMAN_FIXED |
RTE_COMP_FF_HUFFMAN_DYNAMIC,
.window_size = {
--
2.7.4
^ permalink raw reply related
* Re: pull-request: can 2018-07-23
From: David Miller @ 2018-07-23 18:02 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can, kernel
In-Reply-To: <20180723125843.391-1-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Mon, 23 Jul 2018 14:58:31 +0200
> this is a pull request of 12 patches for net/master.
>
> The patch by Stephane Grosjean for the peak_canfd CAN driver fixes a problem
> with older firmware. The next patch is by Roman Fietze and fixes the setup of
> the CCCR register in the m_can driver. Nicholas Mc Guire's patch for the
> mpc5xxx_can driver adds missing error checking. The two patches by Faiz Abbas
> fix the runtime resume and clean up the probe function in the m_can driver. The
> last 7 patches by Anssi Hannula fix several problem in the xilinx_can driver.
Pulled, thanks Marc.
^ permalink raw reply
* [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Sinclair Yeh @ 2018-07-23 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hello Alex,
other than adding a brief commit message to this patch,
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
On Fri, Jul 20, 2018 at 10:15:09PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
^ permalink raw reply
* Re: [PATCH 10/10] drm/vmwgfx: Use __drm_atomic_helper_plane_reset instead of copying the logic
From: Sinclair Yeh @ 2018-07-23 18:02 UTC (permalink / raw)
To: Alexandru Gheorghe
Cc: alexandre.belloni, airlied, liviu.dudau, dri-devel,
laurent.pinchart, thellstrom, krzk, maxime.ripard, wens, kgene,
malidp, linux-graphics-maintainer, sunpeng.li, boris.brezillon,
linux-samsung-soc, nd, Tony.Cheng, linux-arm-kernel, sw0312.kim,
nicolas.ferre, shirish.s, kyungmin.park, alexander.deucher,
christian.koenig
In-Reply-To: <20180720211509.23605-11-alexandru-cosmin.gheorghe@arm.com>
Hello Alex,
other than adding a brief commit message to this patch,
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
On Fri, Jul 20, 2018 at 10:15:09PM +0100, Alexandru Gheorghe wrote:
> Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index 466336b34fff..1e0fb3c79b50 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -720,9 +720,7 @@ void vmw_du_plane_reset(struct drm_plane *plane)
> return;
> }
>
> - plane->state = &vps->base;
> - plane->state->plane = plane;
> - plane->state->rotation = DRM_MODE_ROTATE_0;
> + __drm_atomic_helper_plane_reset(plane, &vps->base);
> }
>
>
> --
> 2.18.0
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 02/21] xen/arm: make allocate_memory work for non 1:1 mapped guests
From: Andrii Anisov @ 2018-07-23 18:01 UTC (permalink / raw)
To: Stefano Stabellini, julien.grall; +Cc: Stefano Stabellini, xen-devel
In-Reply-To: <1530918736-13965-2-git-send-email-sstabellini@kernel.org>
Hello Stefano,
On 07.07.18 02:11, Stefano Stabellini wrote:
> Extend allocate_memory to work for non 1:1 mapped domUs. Specifically,
> memory allocated for domU will be mapped into the domU pseudo-physical
> address space at the appropriate addresses according to the guest memory
> map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
I would speculate about GUEST_RAMx_BASE and GUEST_RAMx_SIZE macros.
Those values might not fit the real SoC memory map. And it becomes a
problem once we decided to assign some peripheral directly to the guest
because a RAM space specified to VM would overlap with IO range of the
assigned device.
In my practice, we always align those macros with the SoC memory map.
This becomes more convenient and practical than IO remapping.
It might be the moment to get those values configurable for the guests.
At least for those, which are configured from the device tree. Here
naturally fit making `memory` property similar to `reg` - the list of
<base, size> values.
--
*Andrii Anisov*
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v4 5/5] doc: add ZLIB PMD guide
From: Verma, Shally @ 2018-07-23 18:00 UTC (permalink / raw)
To: De Lara Guarch, Pablo
Cc: dev@dpdk.org, Athreya, Narayana Prasad, Challa, Mahipal,
Sahu, Sunila, Gupta, Ashish
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8977F8FFA99@IRSMSX107.ger.corp.intel.com>
>-----Original Message-----
>From: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Sent: 23 July 2018 23:28
>To: Verma, Shally <Shally.Verma@cavium.com>
>Cc: dev@dpdk.org; Athreya, Narayana Prasad <NarayanaPrasad.Athreya@cavium.com>; Challa, Mahipal
><Mahipal.Challa@cavium.com>; Sahu, Sunila <Sunila.Sahu@cavium.com>; Gupta, Ashish <Ashish.Gupta@cavium.com>
>Subject: RE: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>
>External Email
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shally Verma
>> Sent: Monday, July 23, 2018 3:51 PM
>> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
>> mchalla@caviumnetworks.com; Sunila Sahu
>> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
>> <ashish.gupta@caviumnetworks.com>
>> Subject: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>>
>> Add zlib pmd feature support and user guide with build and run instructions
>>
>> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
>> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
>> ---
>> MAINTAINERS | 2 +
>> doc/guides/compressdevs/features/zlib.ini | 11 +++++
>> doc/guides/compressdevs/index.rst | 1 +
>> doc/guides/compressdevs/zlib.rst | 69
>> +++++++++++++++++++++++++++++++
>> 4 files changed, 83 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index ca27c6f..7e3c450 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -875,6 +875,8 @@ F: drivers/common/qat/ ZLIB
>> M: Sunila Sahu <sunila.sahu@caviumnetworks.com>
>> F: drivers/compress/zlib/
>> +F: doc/guides/compressdevs/zlib.rst
>> +F: doc/guides/compressdevs/features/zlib.ini
>>
>> Eventdev Drivers
>> ----------------
>> diff --git a/doc/guides/compressdevs/features/zlib.ini
>> b/doc/guides/compressdevs/features/zlib.ini
>> new file mode 100644
>> index 0000000..c794643
>> --- /dev/null
>> +++ b/doc/guides/compressdevs/features/zlib.ini
>> @@ -0,0 +1,11 @@
>> +;
>> +; Refer to default.ini for the full list of available PMD features.
>> +;
>> +; Supported features of 'ZLIB' compression driver.
>> +;
>> +[Features]
>> +Pass-through = Y
>> +Deflate = Y
>> +Fixed = Y
>> +Dynamic = Y
>> +OOP SGL In SGL Out = Y
>
>I assume that you support also "OOP SGL In LB Out" and "OOP LB In SGL Out", right?
yes, but untested thus not claiming.
Thanks
Shally
^ permalink raw reply
* [PATCH] net/mlx5: fix assert for Tx completion queue count
From: Yongseok Koh @ 2018-07-23 18:00 UTC (permalink / raw)
To: shahafs; +Cc: dev, Yongseok Koh, stable
There should be at least one Tx CQE remained if Tx WQ and txq->elts[] have
available slots to send a packet because the size of Tx CQ is exactly
calculated from the size of other resources. As it is guaranteed, it is
checked by an assertion.
max_elts is checked after the assertion for Tx CQ. If no slot is available
in txq->elts[], the assertion would be wrong.
Fixes: 2eefbec531c7 ("net/mlx5: add missing sanity checks for Tx completion queue")
Fixes: 6ce84bd88919 ("net/mlx5: add enhanced multi-packet send for ConnectX-5")
Cc: stable@dpdk.org
Signed-off-by: Yongseok Koh <yskoh@mellanox.com>
Acked-by: Xueming Li <xuemingl@mellanox.com>
---
drivers/net/mlx5/mlx5_rxtx.c | 28 ++++++++--------------------
drivers/net/mlx5/mlx5_rxtx_vec_neon.h | 14 ++++----------
drivers/net/mlx5/mlx5_rxtx_vec_sse.h | 14 ++++----------
3 files changed, 16 insertions(+), 40 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_rxtx.c b/drivers/net/mlx5/mlx5_rxtx.c
index 52a1074a8..2d14f8a6e 100644
--- a/drivers/net/mlx5/mlx5_rxtx.c
+++ b/drivers/net/mlx5/mlx5_rxtx.c
@@ -504,8 +504,6 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -817,14 +815,13 @@ mlx5_tx_burst(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Check whether completion threshold has been reached. */
comp = txq->elts_comp + i + j + k;
if (comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
last_wqe->ctrl2 = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
last_wqe->ctrl3 = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -943,8 +940,6 @@ mlx5_tx_burst_mpw(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -1033,14 +1028,13 @@ mlx5_tx_burst_mpw(void *dpdk_txq, struct rte_mbuf **pkts, uint16_t pkts_n)
if (comp >= MLX5_TX_COMP_THRESH) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -1172,8 +1166,6 @@ mlx5_tx_burst_mpw_inline(void *dpdk_txq, struct rte_mbuf **pkts,
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
do {
struct rte_mbuf *buf = *(pkts++);
uintptr_t addr;
@@ -1330,14 +1322,13 @@ mlx5_tx_burst_mpw_inline(void *dpdk_txq, struct rte_mbuf **pkts,
if (comp >= MLX5_TX_COMP_THRESH) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp = comp;
}
@@ -1461,8 +1452,6 @@ txq_burst_empw(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
/* Start processing. */
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
if (unlikely(!max_wqe))
return 0;
@@ -1618,15 +1607,14 @@ txq_burst_empw(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
(1 << txq->wqe_n) / MLX5_TX_COMP_THRESH_INLINE_DIV) {
volatile struct mlx5_wqe *wqe = mpw.wqe;
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request completion on last WQE. */
wqe->ctrl[2] = rte_cpu_to_be_32(8);
/* Save elts_head in unused "immediate" field of WQE. */
wqe->ctrl[3] = elts_head;
txq->elts_comp = 0;
txq->mpw_comp = txq->wqe_ci;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
} else {
txq->elts_comp += j;
}
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
index 3ebf34823..b37b7381c 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_neon.h
@@ -107,8 +107,6 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
if (unlikely(!pkts_n))
return 0;
for (n = 0; n < pkts_n; ++n) {
@@ -176,12 +174,11 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
txq->elts_comp += (uint16_t)(elts_head - txq->elts_head);
txq->elts_head = elts_head;
if (txq->elts_comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
wqe->ctrl[2] = rte_cpu_to_be_32(8);
wqe->ctrl[3] = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
}
#ifdef MLX5_PMD_SOFT_COUNTERS
txq->stats.opackets += n;
@@ -245,8 +242,6 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
pkts_n = RTE_MIN((unsigned int)RTE_MIN(pkts_n, max_wqe), max_elts);
if (unlikely(!pkts_n))
@@ -282,11 +277,10 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
if (txq->elts_comp + pkts_n < MLX5_TX_COMP_THRESH) {
txq->elts_comp += pkts_n;
} else {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request a completion. */
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
comp_req = 8;
}
/* Fill CTRL in the header. */
diff --git a/drivers/net/mlx5/mlx5_rxtx_vec_sse.h b/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
index f0d888831..54b3783cf 100644
--- a/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
+++ b/drivers/net/mlx5/mlx5_rxtx_vec_sse.h
@@ -107,8 +107,6 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
if (unlikely(!pkts_n))
return 0;
for (n = 0; n < pkts_n; ++n) {
@@ -177,12 +175,11 @@ txq_scatter_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts,
txq->elts_comp += (uint16_t)(elts_head - txq->elts_head);
txq->elts_head = elts_head;
if (txq->elts_comp >= MLX5_TX_COMP_THRESH) {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
wqe->ctrl[2] = rte_cpu_to_be_32(8);
wqe->ctrl[3] = txq->elts_head;
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
}
#ifdef MLX5_PMD_SOFT_COUNTERS
txq->stats.opackets += n;
@@ -244,8 +241,6 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
assert(elts_n > pkts_n);
mlx5_tx_complete(txq);
max_elts = (elts_n - (elts_head - txq->elts_tail));
- /* A CQE slot must always be available. */
- assert((1u << txq->cqe_n) - (txq->cq_pi - txq->cq_ci));
max_wqe = (1u << txq->wqe_n) - (txq->wqe_ci - txq->wqe_pi);
pkts_n = RTE_MIN((unsigned int)RTE_MIN(pkts_n, max_wqe), max_elts);
assert(pkts_n <= MLX5_DSEG_MAX - nb_dword_in_hdr);
@@ -283,11 +278,10 @@ txq_burst_v(struct mlx5_txq_data *txq, struct rte_mbuf **pkts, uint16_t pkts_n,
if (txq->elts_comp + pkts_n < MLX5_TX_COMP_THRESH) {
txq->elts_comp += pkts_n;
} else {
+ /* A CQE slot must always be available. */
+ assert((1u << txq->cqe_n) - (txq->cq_pi++ - txq->cq_ci));
/* Request a completion. */
txq->elts_comp = 0;
-#ifndef NDEBUG
- ++txq->cq_pi;
-#endif
comp_req = 8;
}
/* Fill CTRL in the header. */
--
2.11.0
^ permalink raw reply related
* [qemu-mainline test] 125503: regressions - FAIL
From: osstest service owner @ 2018-07-23 17:59 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 125503 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125503/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-credit2 <job status> broken in 125485
test-arm64-arm64-libvirt-xsm <job status> broken in 125485
test-amd64-amd64-xl 10 debian-install fail REGR. vs. 125169
Tests which are failing intermittently (not blocking):
test-arm64-arm64-xl-credit2 4 host-install(4) broken in 125485 pass in 125503
test-arm64-arm64-libvirt-xsm 4 host-install(4) broken in 125485 pass in 125503
test-amd64-i386-freebsd10-amd64 10 freebsd-install fail in 125485 pass in 125503
test-armhf-armhf-libvirt 5 host-ping-check-native fail in 125485 pass in 125503
test-amd64-i386-qemuu-rhel6hvm-amd 10 redhat-install fail pass in 125485
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 125169
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 125169
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 125169
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 125169
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail like 125169
test-amd64-i386-xl-pvshim 12 guest-start fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-arm64-arm64-libvirt-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-libvirt-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 5b3ecd3d941a0ae8a8cfbba5ab8139b2bf104822
baseline version:
qemuu 9277d81f5c2c6f4d0b5e47c8476eb7ee7e5c0beb
Last test of basis 125169 2018-07-14 20:30:43 Z 8 days
Failing since 125246 2018-07-16 15:53:25 Z 7 days 5 attempts
Testing same since 125485 2018-07-20 21:12:02 Z 2 days 2 attempts
------------------------------------------------------------
People who touched revisions under test:
Alex Bennée <alex.bennee@linaro.org>
Alistair Francis <alistair.francis@wdc.com>
Andrew Jeffery <andrew@aj.id.au>
BALATON Zoltan <balaton@eik.bme.hu>
Calvin Lee <cyrus296@gmail.com>
Christian Borntraeger <borntraeger@de.ibm.com>
Cornelia Huck <cohuck@redhat.com>
Daniel P. Berrangé <berrange@redhat.com>
David Gibson <david@gibson.dropbear.id.au>
David Hildenbrand <david@redhat.com>
Eduardo Habkost <ehabkost@redhat.com>
Emanuele Giuseppe Esposito <e.emanuelegiuseppe@gmail.com>
Greg Kurz <groug@kaod.org>
Guenter Roeck <linux@roeck-us.net>
Igor Mammedov <imammedo@redhat.com>
Jan Kiszka <jan.kiszka@siemens.com>
Jason Wang <jasowang@redhat.com>
Jonas Schievink <jonasschievink@gmail.com>
Laurent Vivier <laurent@vivier.eu>
Marc-André Lureau <marcandre.lureau@redhat.com>
Marc-André Lureau <marcandre.lureau@redhat.com>
Markus Armbruster <armbru@redhat.com>
Michael Davidsaver <mdavidsaver@gmail.com>
Michael Roth <mdroth@linux.vnet.ibm.com>
Paolo Bonzini <pbonzini@redhat.com>
Peter Maydell <peter.maydell@linaro.org>
Philippe Mathieu-Daudé <f4bug@amsat.org>
Richard Henderson <richard.henderson@linaro.org>
Roman Kagan <rkagan@virtuozzo.com>
Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Stefan Hajnoczi <stefanha@redhat.com>
Stefan Weil <sw@weilnetz.de>
Thomas Huth <thuth@redhat.com>
Viktor Prutyanov <viktor.prutyanov@virtuozzo.com>
Yaowei Bai <baiyaowei@cmss.chinamobile.com>
Yunjian Wang <wangyunjian@huawei.com>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-arm64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl fail
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-arm64-arm64-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd fail
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-xl-pvshim pass
test-amd64-i386-xl-pvshim fail
test-amd64-amd64-pygrub pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
broken-job test-arm64-arm64-xl-credit2 broken
broken-job test-arm64-arm64-libvirt-xsm broken
Not pushing.
(No revision log; it would be 1904 lines long.)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* ✓ Fi.CI.BAT: success for drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
From: Patchwork @ 2018-07-23 17:59 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20180723145335.24579-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: drm/i915: Skip repeated calls to i915_gem_set_wedged() (rev2)
URL : https://patchwork.freedesktop.org/series/47067/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4529 -> Patchwork_9749 =
== Summary - WARNING ==
Minor unknown changes coming with Patchwork_9749 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_9749, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://patchwork.freedesktop.org/api/1.0/series/47067/revisions/2/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_9749:
=== IGT changes ===
==== Warnings ====
igt@drv_selftest@live_execlists:
fi-kbl-7500u: SKIP -> PASS +1
== Known issues ==
Here are the changes found in Patchwork_9749 that come from known issues:
=== IGT changes ===
==== Issues hit ====
igt@drv_selftest@mock_sanitycheck:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#107344)
igt@gem_exec_fence@nb-await-default:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#105719)
igt@kms_flip@basic-flip-vs-modeset:
fi-glk-j4005: PASS -> DMESG-WARN (fdo#106000)
==== Possible fixes ====
igt@drv_selftest@live_hangcheck:
fi-kbl-7500u: DMESG-FAIL (fdo#106947) -> PASS
fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
igt@drv_selftest@live_workarounds:
fi-skl-6700hq: DMESG-FAIL (fdo#107292) -> PASS
igt@gem_exec_gttfill@basic:
fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS
fdo#105719 https://bugs.freedesktop.org/show_bug.cgi?id=105719
fdo#106000 https://bugs.freedesktop.org/show_bug.cgi?id=106000
fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097
fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292
fdo#107344 https://bugs.freedesktop.org/show_bug.cgi?id=107344
== Participating hosts (50 -> 43) ==
Missing (7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-caroline fi-byt-clapper
== Build changes ==
* Linux: CI_DRM_4529 -> Patchwork_9749
CI_DRM_4529: f44f476c6bb735cb4067af0c4417c49d105bf419 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4571: 65fccc149b85968cdce4737266b056059c1510f3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_9749: 9b348bfd231b38751c4d528a89d795745484c760 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9b348bfd231b drm/i915: Skip repeated calls to i915_gem_set_wedged()
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9749/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 00/18] JZ4780 DMA patchset v3
From: Paul Burton @ 2018-07-23 17:58 UTC (permalink / raw)
To: Paul Cercueil, Vinod Koul
Cc: Rob Herring, Mark Rutland, Ralf Baechle, James Hogan,
Zubair Lutfullah Kakakhel, Mathieu Malaterre, Daniel Silsby,
dmaengine, devicetree, linux-kernel, linux-mips
In-Reply-To: <20180721110643.19624-1-paul@crapouillou.net>
Hi Paul & Vinod,
On Sat, Jul 21, 2018 at 01:06:25PM +0200, Paul Cercueil wrote:
> This is the version 3 of my jz4780-dma driver update patchset.
>
> Apologies to the DMA people, the v2 of this patchset did not make it to
> their mailing-list; see the bottom of this email for a description of
> what happened in v2.
>
> Changelog from v2 to v3:
>
> - Modified the devicetree bindings to comply with the specification
>
> - New patch [06/18] allows the JZ4780 DMA driver to be compiled within a
> generic MIPS kernel.
Would you prefer to take the MIPS .dts changes in patches 16-18 through
the DMA tree with the rest of the series?
If so then for patches 16-18:
Acked-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
^ permalink raw reply
* [PATCH 2/2] Add support for CPCAP regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood
Cc: broonie, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
Added support for the CPCAP power management regulator functions on
Tegra devices.
Added sw2_sw4 value tables, which provide power to the Tegra core and
aux devices.
Added the Tegra init tables and device tree compatibility match.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 80 +++++++++++++++++++
2 files changed, 81 insertions(+)
diff --git
a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
index 675f4437ce92..3e2d33ab1731 100644
--- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
@@ -4,6 +4,7 @@ Motorola CPCAP PMIC voltage regulators
Requires node properties:
- "compatible" value one of:
"motorola,cpcap-regulator"
+ "motorola,tegra-cpcap-regulator"
"motorola,mapphone-cpcap-regulator"
Required regulator properties:
diff --git a/drivers/regulator/cpcap-regulator.c
b/drivers/regulator/cpcap-regulator.c
index c0b1e04bd90f..cb3774be445d 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -412,6 +412,82 @@ static struct cpcap_regulator omap4_regulators[] = {
{ /* sentinel */ },
};
+static struct cpcap_regulator tegra_regulators[] = {
+ CPCAP_REG(SW1, CPCAP_REG_S1C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW1_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW2, CPCAP_REG_S2C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW2_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x800, 0, 120),
+ CPCAP_REG(SW3, CPCAP_REG_S3C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW3_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(SW4, CPCAP_REG_S4C1, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW4_SEL, sw2_sw4_val_tbl,
+ 0xf00, 0x7f, 0, 0x900, 0, 100),
+ CPCAP_REG(SW5, CPCAP_REG_S5C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW5_SEL, sw5_val_tbl,
+ 0x2a, 0, 0, 0x22, 0, 0),
+ CPCAP_REG(SW6, CPCAP_REG_S6C, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_SW6_SEL, unknown_val_tbl,
+ 0, 0, 0, 0, 0, 0),
+ CPCAP_REG(VCAM, CPCAP_REG_VCAMC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VCAM_SEL, vcam_val_tbl,
+ 0x87, 0x30, 4, 0x7, 0, 420),
+ CPCAP_REG(VCSI, CPCAP_REG_VCSIC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VCSI_SEL, vcsi_val_tbl,
+ 0x47, 0x10, 4, 0x7, 0, 350),
+ CPCAP_REG(VDAC, CPCAP_REG_VDACC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VDAC_SEL, vdac_val_tbl,
+ 0x87, 0x30, 4, 0x3, 0, 420),
+ CPCAP_REG(VDIG, CPCAP_REG_VDIGC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VDIG_SEL, vdig_val_tbl,
+ 0x87, 0x30, 4, 0x5, 0, 420),
+ CPCAP_REG(VFUSE, CPCAP_REG_VFUSEC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VFUSE_SEL, vfuse_val_tbl,
+ 0x80, 0xf, 0, 0x80, 0, 420),
+ CPCAP_REG(VHVIO, CPCAP_REG_VHVIOC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VHVIO_SEL, vhvio_val_tbl,
+ 0x17, 0, 0, 0x2, 0, 0),
+ CPCAP_REG(VSDIO, CPCAP_REG_VSDIOC, CPCAP_REG_ASSIGN2,
+ CPCAP_BIT_VSDIO_SEL, vsdio_val_tbl,
+ 0x87, 0x38, 3, 0x2, 0, 420),
+ CPCAP_REG(VPLL, CPCAP_REG_VPLLC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VPLL_SEL, vpll_val_tbl,
+ 0x43, 0x18, 3, 0x1, 0, 420),
+ CPCAP_REG(VRF1, CPCAP_REG_VRF1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF1_SEL, vrf1_val_tbl,
+ 0xac, 0x2, 1, 0xc, 0, 10),
+ CPCAP_REG(VRF2, CPCAP_REG_VRF2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRF2_SEL, vrf2_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 10),
+ CPCAP_REG(VRFREF, CPCAP_REG_VRFREFC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VRFREF_SEL, vrfref_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VWLAN1, CPCAP_REG_VWLAN1C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN1_SEL, vwlan1_val_tbl,
+ 0x47, 0x10, 4, 0x5, 0, 420),
+ CPCAP_REG(VWLAN2, CPCAP_REG_VWLAN2C, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VWLAN2_SEL, vwlan2_val_tbl,
+ 0x20c, 0xc0, 6, 0x8, 0, 420),
+ CPCAP_REG(VSIM, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsim_val_tbl,
+ 0x23, 0x8, 3, 0x3, 0, 420),
+ CPCAP_REG(VSIMCARD, CPCAP_REG_VSIMC, CPCAP_REG_ASSIGN3,
+ 0xffff, vsimcard_val_tbl,
+ 0x1e80, 0x8, 3, 0x1e00, 0, 420),
+ CPCAP_REG(VVIB, CPCAP_REG_VVIBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VVIB_SEL, vvib_val_tbl,
+ 0x1, 0xc, 2, 0, 0x1, 500),
+ CPCAP_REG(VUSB, CPCAP_REG_VUSBC, CPCAP_REG_ASSIGN3,
+ CPCAP_BIT_VUSB_SEL, vusb_val_tbl,
+ 0x11c, 0x40, 6, 0xc, 0, 0),
+ CPCAP_REG(VAUDIO, CPCAP_REG_VAUDIOC, CPCAP_REG_ASSIGN4,
+ CPCAP_BIT_VAUDIO_SEL, vaudio_val_tbl,
+ 0x16, 0x1, 0, 0x4, 0, 0),
+ { /* sentinel */ },
+};
+
static const struct of_device_id cpcap_regulator_id_table[] = {
{
.compatible = "motorola,cpcap-regulator",
@@ -420,6 +496,10 @@ static const struct of_device_id
cpcap_regulator_id_table[] = {
.compatible = "motorola,mapphone-cpcap-regulator",
.data = omap4_regulators,
},
+ {
+ .compatible = "motorola,tegra-cpcap-regulator",
+ .data = tegra_regulators,
+ },
{},
};
MODULE_DEVICE_TABLE(of, cpcap_regulator_id_table);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] doc: add ZLIB PMD guide
From: De Lara Guarch, Pablo @ 2018-07-23 17:58 UTC (permalink / raw)
To: Shally Verma
Cc: dev@dpdk.org, pathreya@caviumnetworks.com,
mchalla@caviumnetworks.com, Sunila Sahu, Ashish Gupta
In-Reply-To: <1532357474-9544-6-git-send-email-shally.verma@caviumnetworks.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shally Verma
> Sent: Monday, July 23, 2018 3:51 PM
> To: De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
> Cc: dev@dpdk.org; pathreya@caviumnetworks.com;
> mchalla@caviumnetworks.com; Sunila Sahu
> <sunila.sahu@caviumnetworks.com>; Ashish Gupta
> <ashish.gupta@caviumnetworks.com>
> Subject: [dpdk-dev] [PATCH v4 5/5] doc: add ZLIB PMD guide
>
> Add zlib pmd feature support and user guide with build and run instructions
>
> Signed-off-by: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> Signed-off-by: Shally Verma <shally.verma@caviumnetworks.com>
> Signed-off-by: Ashish Gupta <ashish.gupta@caviumnetworks.com>
> ---
> MAINTAINERS | 2 +
> doc/guides/compressdevs/features/zlib.ini | 11 +++++
> doc/guides/compressdevs/index.rst | 1 +
> doc/guides/compressdevs/zlib.rst | 69
> +++++++++++++++++++++++++++++++
> 4 files changed, 83 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ca27c6f..7e3c450 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -875,6 +875,8 @@ F: drivers/common/qat/ ZLIB
> M: Sunila Sahu <sunila.sahu@caviumnetworks.com>
> F: drivers/compress/zlib/
> +F: doc/guides/compressdevs/zlib.rst
> +F: doc/guides/compressdevs/features/zlib.ini
>
> Eventdev Drivers
> ----------------
> diff --git a/doc/guides/compressdevs/features/zlib.ini
> b/doc/guides/compressdevs/features/zlib.ini
> new file mode 100644
> index 0000000..c794643
> --- /dev/null
> +++ b/doc/guides/compressdevs/features/zlib.ini
> @@ -0,0 +1,11 @@
> +;
> +; Refer to default.ini for the full list of available PMD features.
> +;
> +; Supported features of 'ZLIB' compression driver.
> +;
> +[Features]
> +Pass-through = Y
> +Deflate = Y
> +Fixed = Y
> +Dynamic = Y
> +OOP SGL In SGL Out = Y
I assume that you support also "OOP SGL In LB Out" and "OOP LB In SGL Out", right?
^ permalink raw reply
* [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh+dt, mark.rutland, linux-kernel, devicetree, linux-tegra
SW2 and SW4 use a shared table to provide voltage to the cpu core and
devices on Tegra hardware.
Added this table to the cpcap regulator driver as the first step to
supporting this device on Tegra.
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
---
drivers/regulator/cpcap-regulator.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/regulator/cpcap-regulator.c
b/drivers/regulator/cpcap-regulator.c
index bd910fe123d9..c0b1e04bd90f 100644
--- a/drivers/regulator/cpcap-regulator.c
+++ b/drivers/regulator/cpcap-regulator.c
@@ -271,6 +271,29 @@ static struct regulator_ops cpcap_regulator_ops = {
};
static const unsigned int unknown_val_tbl[] = { 0, };
+static const unsigned int sw2_sw4_val_tbl[] = { 612500, 625000, 637500,
+ 650000, 662500, 675000,
+ 687500, 700000, 712500,
+ 725000, 737500, 750000,
+ 762500, 775000, 787500,
+ 800000, 812500, 825000,
+ 837500, 850000, 862500,
+ 875000, 887500, 900000,
+ 912500, 925000, 937500,
+ 950000, 962500, 975000,
+ 987500, 1000000, 1012500,
+ 1025000, 1037500, 1050000,
+ 1062500, 1075000, 1087500,
+ 1100000, 1112500, 1125000,
+ 1137500, 1150000, 1162500,
+ 1175000, 1187500, 1200000,
+ 1212500, 1225000, 1237500,
+ 1250000, 1262500, 1275000,
+ 1287500, 1300000, 1312500,
+ 1325000, 1337500, 1350000,
+ 1362500, 1375000, 1387500,
+ 1400000, 1412500, 1425000,
+ 1437500, 1450000, 1462500, };
static const unsigned int sw5_val_tbl[] = { 0, 5050000, };
static const unsigned int vcam_val_tbl[] = { 2600000, 2700000, 2800000,
2900000, };
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/4] iio: vcnl4000: add support for vcnl4200
From: Tomas Novotny @ 2018-07-23 17:58 UTC (permalink / raw)
To: Jonathan Cameron
Cc: linux-iio, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler
In-Reply-To: <20180721182526.6d29a6d9@archlinux>
Hi Jonathan,
On Sat, 21 Jul 2018 18:25:26 +0100
Jonathan Cameron <jic23@kernel.org> wrote:
> On Tue, 17 Jul 2018 18:46:51 +0200
> Tomas Novotny <tomas@novotny.cz> wrote:
>
> > This is the second iteration of vcnl4200 support. The first one was posted
> > on February, sorry for the long delay. I've implemented all notes from
> > reviews (thanks to Peter and Jonathan) and nothing more.
> >
> > Changes in v2:
> > - reading light and proximity values for vcnl4200 is blocking (if you
> > request new value too early)
> > - patches 2 and 3 were added; original patch 2 is now patch 4
> > - vcnl4010 id is handled (patch 2)
> > - warn user on incorrect usage of vcnl40{0,1}0 id (patch 3)
> > - minor stuff (add parenthesis, switch instead of if, rename sensors to
> > channels, fix return)
> >
> > Please note that I'm not sure if it is still good idea to have same driver
> > for vcnl4000 and vcnl4200. The amount of different parts in v2 is even
> > bigger. Just see below for differences and add the blocking read which is
> > added in v2 for vcnl4200.
>
> Definitely marginal. My view is it's your choice as the person doing
> the work! Which would you prefer?
Well, I was thinking about different driver in the first place. But the reason
was quite selfish (and not the technical one), as I'm interested only in
vcnl4200. But I've seen general attitude to combine similar drivers so I've
tried that way and I'm fine with the result. The only ugly part are some chip
specific things in a shared data structure.
> I'm pretty happy with these patches if you want to go this way, but
> given I assume you might add the support for other features, if you
> think that is going to get even worse, then now is the time to make
> the decision to not have a unified driver.
I will probably add some settings, but this should be handled easily. I don't
see anything problematic in the future (well, maybe interrupts or
thresholds?), as both variants are more or less simple light and proximity
chips.
> Sadly it might be a case of doing a 'hatchet' job on the code to
> make a separate driver and see what it looks like. If it's really
> short and clean (which it probably is) then go with separate drivers.
The separate vcnl4200 would be indeed short and clean. The structure and
size would be very similar to current vcnl4000.
Anyway, I don't have enough experience to judge what is better. I'm ok to do
any variant.
Thanks for the review,
Tomas
> Jonathan
>
> >
> > Cover letter from v1:
> >
> > VCNL4200 is another proximity and ambient light sensor from Vishay. I'm
> > adding support for that sensor to vcnl4000 driver, which currently supports
> > VCNL4000/10/20.
> >
> > The VCNL4200 is a bit different from VCNL4000/10/20. Common things are:
> > - integrated proximity and ambient light sensor
> > - SMBus compatible I2C interface
> > - Vishay VCNL4xxx series...
> >
> > Different things are:
> > - totally different register map
> > - 8-bit vs. 16-bit registers. The 16-bit values are in two 8-bit registers
> > on VCNL4000. 16-bit value is in one register on VCNL4200.
> > - VCNL4000 has flags when the measurement is finished
> >
> > The first patch generalizes the driver to support differencies. The second
> > patch adds the support for VCNL4200.
> >
> > It is tested on VCNL4020 and VCNL4200.
> >
> > Tomas Novotny (4):
> > iio: vcnl4000: make the driver extendable
> > iio: vcnl4000: add VCNL4010 device id
> > iio: vcnl4000: warn on incorrectly specified device id
> > iio: vcnl4000: add support for VCNL4200
> >
> > drivers/iio/light/Kconfig | 5 +-
> > drivers/iio/light/vcnl4000.c | 219 ++++++++++++++++++++++++++++++++++++++-----
> > 2 files changed, 196 insertions(+), 28 deletions(-)
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 0/2 V1] Add support for cpcap regulators on Tegra devices.
From: Peter Geis @ 2018-07-23 17:58 UTC (permalink / raw)
To: lgirdwood, broonie
Cc: robh+dt, mark.rutland, linux-kernel, devicetree, linux-tegra
Good Afternoon,
I am re-sending the whole patch set due to my error of accidentally
converting the tabulation to spaces.
The CPCAP regulator driver can support various devices, but currently
only supports Omap4 devices.
Adds the sw2 and sw4 voltage tables, which power the Tegra core, and a
DT match for the Tegra device.
Tested on the Motorola Xoom MZ602.
v1:
Fix conversion of tabulation to spaces.
Peter Geis (2):
Add sw2_sw4 voltage table to cpcap regulator.
Add support for CPCAP regulators on Tegra devices.
.../bindings/regulator/cpcap-regulator.txt | 1 +
drivers/regulator/cpcap-regulator.c | 103 ++++++++++++++++++
2 files changed, 104 insertions(+)
--
2.17.1
^ permalink raw reply
* Re: Hash algorithm analysis
From: Stefan Beller @ 2018-07-23 17:57 UTC (permalink / raw)
To: demerphq
Cc: brian m. carlson, Johannes Schindelin, Jonathan Nieder, git,
Linus Torvalds, Adam Langley, keccak
In-Reply-To: <CANgJU+X39NoEoMyLu+FX38=x19LrRqatz_dUpUAc+WFV+Uw+=A@mail.gmail.com>
On Mon, Jul 23, 2018 at 5:41 AM demerphq <demerphq@gmail.com> wrote:
>
> On Sun, 22 Jul 2018 at 01:59, brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > I will admit that I don't love making this decision by myself, because
> > right now, whatever I pick, somebody is going to be unhappy. I want to
> > state, unambiguously, that I'm trying to make a decision that is in the
> > interests of the Git Project, the community, and our users.
> >
> > I'm happy to wait a few more days to see if a consensus develops; if so,
> > I'll follow it. If we haven't come to one by, say, Wednesday, I'll make
> > a decision and write my patches accordingly. The community is free, as
> > always, to reject my patches if taking them is not in the interest of
> > the project.
>
> Hi Brian.
>
> I do not envy you this decision.
>
> Personally I would aim towards pushing this decision out to the git
> user base and facilitating things so we can choose whatever hash
> function (and config) we wish, including ones not invented yet.
By Git user base you actually mean millions of people?
(And they'll have different opinions and needs)
One of the goals of the hash transition is to pick a hash function
such that git repositories are compatible.
If users were to pick their own hashes, we would need to not just give
a SHA-1 -> <newhash> transition plan, but we'd have to make sure the
full matrix of possible hashes is interchangeable as we have no idea
of what the user would think of "safer". For example one server operator
might decide to settle on SHA2 and another would settle on blake2,
whereas a user that uses both servers as remotes settles with k12.
Then there would be a whole lot of conversion going on (you cannot talk
natively to a remote with a different hash; checking pgp signatures is
also harder as you have an abstraction layer in between).
I would rather just have the discussion now and then provide only one
conversion tool which might be easy to adapt, but after the majority
converted, it is rather left to bitrot instead of needing to support ongoing
conversions.
On the other hand, even if we'd provide a "different hashes are fine"
solution, I would think the network effect would make sure that eventually
most people end up with one hash.
One example of using different hashes successfully are transports,
like TLS, SSH. The difference there is that it is a point-to-point communication
whereas a git repository needs to be read by many parties involved; also
a communication over TLS/SSH is ephemeral unlike objects in Git.
> Failing that I would aim towards a hashing strategy which has the most
> flexibility. Keccak for instance has the interesting property that its
> security level is tunable, and that it can produce aribitrarily long
> hashes. Leaving aside other concerns raised elsewhere in this thread,
> these two features alone seem to make it a superior choice for an
> initial implementation. You can find bugs by selecting unusual hash
> sizes, including very long ones, and you can provide ways to tune the
> function to peoples security and speed preferences. Someone really
> paranoid can specify an unusually large round count and a very long
> hash.
I do not object to this in theory, but I would rather not want to burden
the need to write code for this on the community.
> I am not a cryptographer.
Same here. My personal preference would be blake2b
as that is the fastest IIRC.
Re-reading brians initial mail, I think we should settle on
SHA-256, as that is a conservative choice for security and
the winner in HW accelerated setups, and not to shabby in
a software implementation; it is also widely available.
Stefan
^ permalink raw reply
* Re: [PATCH] NTB: fix debugfs_simple_attr.cocci warnings
From: Logan Gunthorpe @ 2018-07-23 17:57 UTC (permalink / raw)
To: Julia Lawall
Cc: Jon Mason, Dave Jiang, Allen Hubbe, linux-ntb, linux-kernel,
kbuild-all
In-Reply-To: <alpine.DEB.2.20.1807210845090.2381@hadrien>
On 21/07/18 12:47 AM, Julia Lawall wrote:
> From: kbuild test robot <fengguang.wu@intel.com>
>
> Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> for debugfs files.
>
> Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> imposes some significant overhead as compared to
> DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
>
> Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Fixes: c75153197d20 ("NTB: Introduce NTB MSI Test Client")
> Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
>
> I don't know much about this issue, beyondwhat is explained by the
> semantic patch. Please check if the changes can be relevant.
Oops, this work wasn't meant for public consumption yet. Everyone
pretend you didn't see that ;). I must have pushed it to my repo that
kbuild tests by accident.
Though, I'm glad to have learned about the more efficient use of debugfs
attributes.
Logan
^ permalink raw reply
* Re: [PATCH 1/2] Add sw2_sw4 voltage table to cpcap regulator.
From: Peter Geis @ 2018-07-23 17:57 UTC (permalink / raw)
To: Mark Brown
Cc: lgirdwood, robh+dt, mark.rutland, linux-kernel, devicetree,
linux-tegra
In-Reply-To: <20180723170157.GD13981@sirena.org.uk>
On 07/23/2018 01:01 PM, Mark Brown wrote:
> On Fri, Jul 20, 2018 at 08:43:49PM -0400, Peter Geis wrote:
>> SW2 and SW4 use a shared table to provide voltage to the cpu core and
>> devices on Tegra hardware.
>> Added this table to the cpcap regulator driver as the first step to
>> supporting this device on Tegra.
>
> This fails to apply with:
>
> Applying: Add sw2_sw4 voltage table to cpcap regulator.
> .git/rebase-apply/patch:37: trailing whitespace.
> 1437500, 1450000,
> error: corrupt patch at line 38
> Patch failed at 0001 Add sw2_sw4 voltage table to cpcap regulator.
>
> Please check and resend.
>
Apologies, I accidentally converted all of the tabs to spaces.
Re-sending both patches with tabulation intact.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net/smc: patches 2018-07-23
From: David Miller @ 2018-07-23 17:57 UTC (permalink / raw)
To: ubraun; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl,
linux-kernel
In-Reply-To: <20180723115312.54694-1-ubraun@linux.ibm.com>
From: Ursula Braun <ubraun@linux.ibm.com>
Date: Mon, 23 Jul 2018 13:53:07 +0200
> here are some small patches for SMC: Just the first patch contains a
> functional change. It allows to differ between the modes SMCR and SMCD
> on s390 when monitoring SMC sockets. The remaining patches are cleanups
> without functional changes.
Series applied, thank you.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.