* [PATCH 6/6] btrfs: Remove bio_offset argument from submit_bio_hook
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
In-Reply-To: <20190410142443.6470-1-nborisov@suse.com>
None of the implementers of the submit_bio_hook use the bio_offset
parameter, simply remove it. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/disk-io.c | 4 ++--
fs/btrfs/extent_io.c | 6 ++----
fs/btrfs/extent_io.h | 3 +--
fs/btrfs/inode.c | 5 +++--
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index ee9e03b8aae3..0a7897adc58f 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -885,8 +885,8 @@ static int check_async_write(struct btrfs_inode *bi)
}
static blk_status_t btree_submit_bio_hook(struct inode *inode, struct bio *bio,
- int mirror_num, unsigned long bio_flags,
- u64 bio_offset)
+ int mirror_num,
+ unsigned long bio_flags)
{
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
int async = check_async_write(BTRFS_I(inode));
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 048d6c6fe7b9..61191156ee2b 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -152,16 +152,14 @@ static int __must_check submit_one_bio(struct bio *bio, int mirror_num,
struct bio_vec *bvec = bio_last_bvec_all(bio);
struct bio_vec bv;
struct extent_io_tree *tree = bio->bi_private;
- u64 start;
mp_bvec_last_segment(bvec, &bv);
- start = page_offset(bv.bv_page) + bv.bv_offset;
bio->bi_private = NULL;
if (tree->ops)
ret = tree->ops->submit_bio_hook(tree->private_data, bio,
- mirror_num, bio_flags, start);
+ mirror_num, bio_flags);
else
btrfsic_submit_bio(bio);
@@ -2546,7 +2544,7 @@ static int bio_readpage_error(struct bio *failed_bio, u64 phy_offset,
read_mode, failrec->this_mirror, failrec->in_validation);
status = tree->ops->submit_bio_hook(tree->private_data, bio, failrec->this_mirror,
- failrec->bio_flags, 0);
+ failrec->bio_flags);
if (status) {
free_io_failure(failure_tree, tree, failrec);
bio_put(bio);
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 37240e03c4e3..aa18a16a6ed7 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -105,8 +105,7 @@ struct extent_io_ops {
* pointer will be called unconditionally.
*/
blk_status_t (*submit_bio_hook)(struct inode *inode, struct bio *bio,
- int mirror_num, unsigned long bio_flags,
- u64 bio_offset);
+ int mirror_num, unsigned long bio_flags);
int (*readpage_end_io_hook)(struct btrfs_io_bio *io_bio, u64 phy_offset,
struct page *page, u64 start, u64 end,
int mirror);
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 6e5f1afa7407..476111d44021 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1954,8 +1954,9 @@ static blk_status_t btrfs_submit_bio_start(void *private_data, struct bio *bio,
* c-3) otherwise: async submit
*/
static blk_status_t btrfs_submit_bio_hook(struct inode *inode, struct bio *bio,
- int mirror_num, unsigned long bio_flags,
- u64 bio_offset)
+ int mirror_num,
+ unsigned long bio_flags)
+
{
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
struct btrfs_root *root = BTRFS_I(inode)->root;
--
2.17.1
^ permalink raw reply related
* [PATCH 5/6] btrfs: Always pass 0 bio_offset for btree_submit_bio_start
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
In-Reply-To: <20190410142443.6470-1-nborisov@suse.com>
The btree submit hook queues the async csum and forwards the bio_offset
parameter passed to btree_submit_bio_hook. This is redundant since
btree_submit_bio_start calls btree_csum_one_bio which doesn't use
the offset at all. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/disk-io.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 2f535e9d816e..ee9e03b8aae3 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -913,8 +913,7 @@ static blk_status_t btree_submit_bio_hook(struct inode *inode, struct bio *bio,
* checksumming can happen in parallel across all CPUs
*/
ret = btrfs_wq_submit_bio(fs_info, bio, mirror_num, 0,
- bio_offset, inode,
- btree_submit_bio_start);
+ 0, inode, btree_submit_bio_start);
}
if (ret)
--
2.17.1
^ permalink raw reply related
* [PATCH 2/6] btrfs: Change submit_bio_hook to taking an inode directly
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
In-Reply-To: <20190410142443.6470-1-nborisov@suse.com>
The only possible 'private_data' that is passed to this function is
actually an inode. Make that explicit by changing the signature of the
call back. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/disk-io.c | 5 ++---
fs/btrfs/extent_io.h | 2 +-
fs/btrfs/inode.c | 3 +--
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 31bdedfb7490..b05adaf2bb80 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -885,11 +885,10 @@ static int check_async_write(struct btrfs_inode *bi)
return 1;
}
-static blk_status_t btree_submit_bio_hook(void *private_data, struct bio *bio,
+static blk_status_t btree_submit_bio_hook(struct inode *inode, struct bio *bio,
int mirror_num, unsigned long bio_flags,
u64 bio_offset)
{
- struct inode *inode = private_data;
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
int async = check_async_write(BTRFS_I(inode));
blk_status_t ret;
@@ -915,7 +914,7 @@ static blk_status_t btree_submit_bio_hook(void *private_data, struct bio *bio,
* checksumming can happen in parallel across all CPUs
*/
ret = btrfs_wq_submit_bio(fs_info, bio, mirror_num, 0,
- bio_offset, private_data,
+ bio_offset, inode,
btree_submit_bio_start);
}
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index 79bd20cf4226..abafb48947ef 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -104,7 +104,7 @@ struct extent_io_ops {
* The following callbacks must be always defined, the function
* pointer will be called unconditionally.
*/
- blk_status_t (*submit_bio_hook)(void *private_data, struct bio *bio,
+ blk_status_t (*submit_bio_hook)(struct inode *inode, struct bio *bio,
int mirror_num, unsigned long bio_flags,
u64 bio_offset);
int (*readpage_end_io_hook)(struct btrfs_io_bio *io_bio, u64 phy_offset,
diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 4e2f9f66bf59..07cf7050c99f 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -1953,11 +1953,10 @@ static blk_status_t btrfs_submit_bio_start(void *private_data, struct bio *bio,
*
* c-3) otherwise: async submit
*/
-static blk_status_t btrfs_submit_bio_hook(void *private_data, struct bio *bio,
+static blk_status_t btrfs_submit_bio_hook(struct inode *inode, struct bio *bio,
int mirror_num, unsigned long bio_flags,
u64 bio_offset)
{
- struct inode *inode = private_data;
struct btrfs_fs_info *fs_info = btrfs_sb(inode->i_sb);
struct btrfs_root *root = BTRFS_I(inode)->root;
enum btrfs_wq_endio_type metadata = BTRFS_WQ_ENDIO_DATA;
--
2.17.1
^ permalink raw reply related
* [PATCH 3/6] btrfs: Remove 'tree' argument from read_extent_buffer_pages
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
In-Reply-To: <20190410142443.6470-1-nborisov@suse.com>
This function always uses the btree inode's io_tree. Stop taking the
tree as a function argument and instead access it internally from
read_extent_buffer_pages. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/disk-io.c | 12 +++---------
fs/btrfs/extent_io.c | 4 ++--
fs/btrfs/extent_io.h | 3 +--
3 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index b05adaf2bb80..2f535e9d816e 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -465,8 +465,7 @@ static int btree_read_extent_buffer_pages(struct extent_buffer *eb,
io_tree = &BTRFS_I(fs_info->btree_inode)->io_tree;
while (1) {
clear_bit(EXTENT_BUFFER_CORRUPT, &eb->bflags);
- ret = read_extent_buffer_pages(io_tree, eb, WAIT_COMPLETE,
- mirror_num);
+ ret = read_extent_buffer_pages(eb, WAIT_COMPLETE, mirror_num);
if (!ret) {
if (verify_parent_transid(io_tree, eb,
parent_transid, 0))
@@ -1034,15 +1033,13 @@ static const struct address_space_operations btree_aops = {
void readahead_tree_block(struct btrfs_fs_info *fs_info, u64 bytenr)
{
struct extent_buffer *buf = NULL;
- struct inode *btree_inode = fs_info->btree_inode;
int ret;
buf = btrfs_find_create_tree_block(fs_info, bytenr);
if (IS_ERR(buf))
return;
- ret = read_extent_buffer_pages(&BTRFS_I(btree_inode)->io_tree, buf,
- WAIT_NONE, 0);
+ ret = read_extent_buffer_pages(buf, WAIT_NONE, 0);
if (ret < 0)
free_extent_buffer_stale(buf);
else
@@ -1053,8 +1050,6 @@ int reada_tree_block_flagged(struct btrfs_fs_info *fs_info, u64 bytenr,
int mirror_num, struct extent_buffer **eb)
{
struct extent_buffer *buf = NULL;
- struct inode *btree_inode = fs_info->btree_inode;
- struct extent_io_tree *io_tree = &BTRFS_I(btree_inode)->io_tree;
int ret;
buf = btrfs_find_create_tree_block(fs_info, bytenr);
@@ -1063,8 +1058,7 @@ int reada_tree_block_flagged(struct btrfs_fs_info *fs_info, u64 bytenr,
set_bit(EXTENT_BUFFER_READAHEAD, &buf->bflags);
- ret = read_extent_buffer_pages(io_tree, buf, WAIT_PAGE_LOCK,
- mirror_num);
+ ret = read_extent_buffer_pages(buf, WAIT_PAGE_LOCK, mirror_num);
if (ret) {
free_extent_buffer_stale(buf);
return ret;
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 828708f6510c..048d6c6fe7b9 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -5330,8 +5330,7 @@ void set_extent_buffer_uptodate(struct extent_buffer *eb)
}
}
-int read_extent_buffer_pages(struct extent_io_tree *tree,
- struct extent_buffer *eb, int wait, int mirror_num)
+int read_extent_buffer_pages(struct extent_buffer *eb, int wait, int mirror_num)
{
int i;
struct page *page;
@@ -5343,6 +5342,7 @@ int read_extent_buffer_pages(struct extent_io_tree *tree,
unsigned long num_reads = 0;
struct bio *bio = NULL;
unsigned long bio_flags = 0;
+ struct extent_io_tree *tree = &BTRFS_I(eb->fs_info->btree_inode)->io_tree;
if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))
return 0;
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index abafb48947ef..37240e03c4e3 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -433,8 +433,7 @@ void free_extent_buffer_stale(struct extent_buffer *eb);
#define WAIT_NONE 0
#define WAIT_COMPLETE 1
#define WAIT_PAGE_LOCK 2
-int read_extent_buffer_pages(struct extent_io_tree *tree,
- struct extent_buffer *eb, int wait,
+int read_extent_buffer_pages(struct extent_buffer *eb, int wait,
int mirror_num);
void wait_on_extent_buffer_writeback(struct extent_buffer *eb);
--
2.17.1
^ permalink raw reply related
* [PATCH 0/6] Simplifications around submit_bio_hook
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
I've been taking a look at the submit_bio_hook et al and I saw some
opportunities for improvement. First I begin by simplifying the definition of
submit_bio_hook callback and making one of its arguments explicit.
Patch 3 removes a redundant extent_io_tree argument that was passed through
several layers of functions and ultimately made it somewhat cumbersome to reason
what extent_io_tree is being used.
Patch 4 and 5 hardcode a 0 being passed for the bio_offset parameter to
btrfs_submit_bio_start/btree_submit_bio_start since it only matters for DIO.
Patch 6 finally does away with the bio_offset parameter of submit_bio_hook.
Here is the output of bloat-o-meter for posterity:
add/remove: 0/0 grow/shrink: 4/7 up/down: 48/-319 (-271)
Function old new delta
read_extent_buffer_pages 784 822 +38
btrfs_add_ordered_sum 100 104 +4
btrfs_submit_bio_hook 364 367 +3
btree_submit_bio_hook 175 178 +3
end_bio_extent_readpage 2119 2116 -3
btrfs_reloc_clone_csums 272 262 -10
btrfs_csum_one_bio 1358 1348 -10
btree_read_extent_buffer_pages 282 272 -10
readahead_tree_block 73 55 -18
reada_tree_block_flagged 194 165 -29
submit_one_bio 313 74 -239
Total: Before=1072719, After=1072448, chg -0.03%
Nikolay Borisov (6):
btrfs: Define submit_bio_hook's type directly
btrfs: Change submit_bio_hook to taking an inode directly
btrfs: Remove 'tree' argument from read_extent_buffer_pages
btrfs: Pass 0 for bio_offset to btrfs_wq_submit_bio
btrfs: Always pass 0 bio_offset for btree_submit_bio_start
btrfs: Remove bio_offset argument from submit_bio_hook
fs/btrfs/disk-io.c | 22 +++++++---------------
fs/btrfs/extent_io.c | 10 ++++------
fs/btrfs/extent_io.h | 9 +++------
fs/btrfs/inode.c | 11 +++++------
4 files changed, 19 insertions(+), 33 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/6] btrfs: Define submit_bio_hook's type directly
From: Nikolay Borisov @ 2019-04-10 14:24 UTC (permalink / raw)
To: linux-btrfs; +Cc: Nikolay Borisov
In-Reply-To: <20190410142443.6470-1-nborisov@suse.com>
There is no need to use a typedef to define the type of the function
and then use that to define the respective member in extent_io_ops.
Define struct's member directly. No functional changes.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
fs/btrfs/extent_io.h | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/fs/btrfs/extent_io.h b/fs/btrfs/extent_io.h
index f7ca1516f70b..79bd20cf4226 100644
--- a/fs/btrfs/extent_io.h
+++ b/fs/btrfs/extent_io.h
@@ -95,9 +95,6 @@ struct btrfs_inode;
struct btrfs_io_bio;
struct io_failure_record;
-typedef blk_status_t (extent_submit_bio_hook_t)(void *private_data, struct bio *bio,
- int mirror_num, unsigned long bio_flags,
- u64 bio_offset);
typedef blk_status_t (extent_submit_bio_start_t)(void *private_data,
struct bio *bio, u64 bio_offset);
@@ -107,7 +104,9 @@ struct extent_io_ops {
* The following callbacks must be always defined, the function
* pointer will be called unconditionally.
*/
- extent_submit_bio_hook_t *submit_bio_hook;
+ blk_status_t (*submit_bio_hook)(void *private_data, struct bio *bio,
+ int mirror_num, unsigned long bio_flags,
+ u64 bio_offset);
int (*readpage_end_io_hook)(struct btrfs_io_bio *io_bio, u64 phy_offset,
struct page *page, u64 start, u64 end,
int mirror);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 1/1] cobalt: mode argument from open forwarded for O_TMPFILE
From: Jan Kiszka @ 2019-04-10 14:24 UTC (permalink / raw)
To: Norbert Lange, xenomai
In-Reply-To: <20190410111813.19185-1-norbert.lange@andritz.com>
On 10.04.19 13:18, Norbert Lange via Xenomai wrote:
> The optional mode argument (open is a vararg function),
> was only be read and forwarded if the O_CREAT flag is set.
>
> That is not complete, as O_TMPFILE will require this
> argument aswell. Fixed in this commit, and a fallback definition
> of O_TMPFILE is added, incase libcobalt is built against an
> library lacking this macro.
>
> Signed-off-by: Norbert Lange <norbert.lange@andritz.com>
> ---
> lib/cobalt/rtdm.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/lib/cobalt/rtdm.c b/lib/cobalt/rtdm.c
> index 6b8898e70..176210ddc 100644
> --- a/lib/cobalt/rtdm.c
> +++ b/lib/cobalt/rtdm.c
> @@ -30,6 +30,12 @@
> #include <asm/xenomai/syscall.h>
> #include "internal.h"
>
> +/* support for very old c libraries not supporting O_TMPFILE */
> +#ifndef O_TMPFILE
> +#define O_TMPFILE (020000000 | 0200000)
> +#endif
> +
> +
> static inline int set_errno(int ret)
> {
> if (ret >= 0)
> @@ -65,7 +71,7 @@ COBALT_IMPL(int, open, (const char *path, int oflag, ...))
> mode_t mode = 0;
> va_list ap;
>
> - if (oflag & O_CREAT) {
> + if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
> va_start(ap, oflag);
> mode = va_arg(ap, int);
> va_end(ap);
> @@ -79,7 +85,7 @@ COBALT_IMPL(int, open64, (const char *path, int oflag, ...))
> mode_t mode = 0;
> va_list ap;
>
> - if (oflag & O_CREAT) {
> + if ((oflag & O_CREAT) || (oflag & O_TMPFILE) == O_TMPFILE) {
> va_start(ap, oflag);
> mode = va_arg(ap, int);
> va_end(ap);
>
Thanks, applied.
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH] drm/i915: Don't disable interrupts independently of the lock
From: Sebastian Andrzej Siewior @ 2019-04-10 14:24 UTC (permalink / raw)
To: dri-devel
Cc: David Airlie, intel-gfx, Steven Rostedt, tglx,
Sebastian Andrzej Siewior
The locks (timeline->lock and rq->lock) need to be taken with disabled
interrupts. This is done in __retire_engine_request() by disabling the
interrupts independently of the locks itself.
While local_irq_disable()+spin_lock() equals spin_lock_irq() on vanilla
it does not on RT. Also, it is not obvious if there is a special reason
to why the interrupts are disabled independently of the lock.
Enable/disable interrupts as part of the locking instruction.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/gpu/drm/i915/i915_request.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index ca95ab2f4cfa3..8744d20ac1681 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -278,9 +278,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine,
GEM_BUG_ON(!i915_request_completed(rq));
- local_irq_disable();
-
- spin_lock(&engine->timeline.lock);
+ spin_lock_irq(&engine->timeline.lock);
GEM_BUG_ON(!list_is_first(&rq->link, &engine->timeline.requests));
list_del_init(&rq->link);
spin_unlock(&engine->timeline.lock);
@@ -294,9 +292,7 @@ static void __retire_engine_request(struct intel_engine_cs *engine,
GEM_BUG_ON(!atomic_read(&rq->i915->gt_pm.rps.num_waiters));
atomic_dec(&rq->i915->gt_pm.rps.num_waiters);
}
- spin_unlock(&rq->lock);
-
- local_irq_enable();
+ spin_unlock_irq(&rq->lock);
/*
* The backing object for the context is done after switching to the
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH] ASoC: wcd9335: Fix missing regmap requirement
From: Marc Gonzalez @ 2019-04-10 14:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Srinivas Kandagatla
Cc: LKML, alsa-devel, Arnd Bergmann
wcd9335.c: undefined reference to 'devm_regmap_add_irq_chip'
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
---
sound/soc/codecs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 419142111b6d..33778dc99108 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -1162,6 +1162,7 @@ config SND_SOC_WCD9335
tristate "WCD9335 Codec"
depends on SLIMBUS
select REGMAP_SLIMBUS
+ select REGMAP_IRQ
help
The WCD9335 is a standalone Hi-Fi audio CODEC IC, supports
Qualcomm Technologies, Inc. (QTI) multimedia solutions,
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 08/10] media: coda: allow encoder to set colorimetry on the output queue
From: Philipp Zabel @ 2019-04-10 14:23 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: kernel
In-Reply-To: <1c5e978c-eecb-8847-8746-51e83e48ae85@xs4all.nl>
On Wed, 2019-04-10 at 15:48 +0200, Hans Verkuil wrote:
[...]
> Isn't the colorimetry information encoded in the stream's metadata?
That depends on the codec. Colorimetry information can be stored in
optional headers (for example Sequence Display Extension for MPEG-2,
Video Usability Information for H.264) but I don't know that the CODA
firmware can parse or generate any of them.
> So should it be set i an encoder register so it ends up in the right
> place in the bitstream?
I could produce the necessary headers manually and inject them into the
bitstream in the driver.
But for example for JPEG it is not clear to me if there even is a
correct way to do that. Can V4L2 colorimetry settings be translated into
ICC profiles?
> And for decoders it should then be read back from a register.
Same as above, I'd have to parse the headers in the driver.
> Just curious how this would work for this codec and if it is even possible.
>
> For now this patch is OK, but I think more work is needed.
Agreed.
regards
Philipp
^ permalink raw reply
* RE: [PATCH] drm/amdgpu: support dpm level modification under virtualization v2
From: Tao, Yintian @ 2019-04-10 14:23 UTC (permalink / raw)
To: Koenig, Christian,
amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <72f356d9-f3bd-9031-a6dc-5622ac086aa8-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Christian
Many thanks for your review. I will correct the patch by v3
Best Regards
Yintian Tao
-----Original Message-----
From: Christian König <ckoenig.leichtzumerken@gmail.com>
Sent: Wednesday, April 10, 2019 10:02 PM
To: Tao, Yintian <Yintian.Tao@amd.com>; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: support dpm level modification under virtualization v2
Am 10.04.19 um 15:02 schrieb Yintian Tao:
> Under vega10 virtualuzation, smu ip block will not be added.
> Therefore, we need add pp clk query and force dpm level function at
> amdgpu_virt_ops to support the feature.
>
> v2: add get_pp_clk existence check and use kzalloc to allocate buf
>
> Change-Id: I713419c57b854082f6f739f1d32a055c7115e620
> Signed-off-by: Yintian Tao <yttao@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 15 ++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 49 +++++++++++++++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h | 11 +++++
> drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 78 ++++++++++++++++++++++++++++++
> drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h | 6 +++
> 7 files changed, 164 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 3ff8899..bb0fd5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2486,6 +2486,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
> mutex_init(&adev->virt.vf_errors.lock);
> hash_init(adev->mn_hash);
> mutex_init(&adev->lock_reset);
> + mutex_init(&adev->virt.dpm_mutex);
>
> amdgpu_device_check_arguments(adev);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 6190495..29ec28f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -727,6 +727,10 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void *data, struct drm_file
> if (adev->pm.dpm_enabled) {
> dev_info.max_engine_clock = amdgpu_dpm_get_sclk(adev, false) * 10;
> dev_info.max_memory_clock = amdgpu_dpm_get_mclk(adev, false) *
> 10;
> + } else if (amdgpu_sriov_vf(adev) && amdgim_is_hwperf(adev) &&
> + adev->virt.ops->get_pp_clk) {
> + dev_info.max_engine_clock = amdgpu_virt_get_sclk(adev, false) * 10;
> + dev_info.max_memory_clock = amdgpu_virt_get_mclk(adev, false) *
> +10;
> } else {
> dev_info.max_engine_clock = adev->clock.default_sclk * 10;
> dev_info.max_memory_clock = adev->clock.default_mclk * 10; diff
> --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> index 5540259..0162d1e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
> @@ -380,6 +380,17 @@ static ssize_t amdgpu_set_dpm_forced_performance_level(struct device *dev,
> goto fail;
> }
>
> + if (amdgpu_sriov_vf(adev)) {
> + if (amdgim_is_hwperf(adev) &&
> + adev->virt.ops->force_dpm_level) {
> + mutex_lock(&adev->pm.mutex);
> + adev->virt.ops->force_dpm_level(adev, level);
> + mutex_unlock(&adev->pm.mutex);
> + return count;
> + } else
> + return -EINVAL;
> + }
> +
> if (current_level == level)
> return count;
>
> @@ -843,6 +854,10 @@ static ssize_t amdgpu_get_pp_dpm_sclk(struct device *dev,
> struct drm_device *ddev = dev_get_drvdata(dev);
> struct amdgpu_device *adev = ddev->dev_private;
>
> + if (amdgpu_sriov_vf(adev) && amdgim_is_hwperf(adev) &&
> + adev->virt.ops->get_pp_clk)
> + return adev->virt.ops->get_pp_clk(adev, PP_SCLK, buf);
> +
> if (is_support_sw_smu(adev))
> return smu_print_clk_levels(&adev->smu, PP_SCLK, buf);
> else if (adev->powerplay.pp_funcs->print_clock_levels)
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index 462a04e..efdb6b7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -375,4 +375,53 @@ void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev)
> }
> }
>
> +static uint32_t parse_clk(char *buf, bool min) {
> + char *ptr = buf;
> + uint32_t clk = 0;
> +
> + do {
> + ptr = strchr(ptr, ':');
> + if (!ptr)
> + break;
> + ptr+=2;
> + clk = simple_strtoul(ptr, NULL, 10);
> + } while (!min);
> +
> + return clk * 100;
> +}
> +
> +uint32_t amdgpu_virt_get_sclk(struct amdgpu_device *adev, bool
> +lowest) {
> + char *buf = NULL;
> + uint32_t clk = 0;
> +
> + buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (NULL == buf)
According to coding style rules that should be "if (!buf)".
> + return -EINVAL;
Please return -ENOMEM here.
> +
> + adev->virt.ops->get_pp_clk(adev, PP_SCLK, buf);
> + clk = parse_clk(buf, lowest);
Looks like you are using spaces instead of tabs here.
> +
> + kfree(buf);
> +
> + return clk;
> +}
> +
> +uint32_t amdgpu_virt_get_mclk(struct amdgpu_device *adev, bool
> +lowest) {
> + char *buf = NULL;
> + uint32_t clk = 0;
> +
> + buf = kzalloc(PAGE_SIZE, GFP_KERNEL);
> + if (NULL == buf)
> + return -EINVAL;
> +
> + adev->virt.ops->get_pp_clk(adev, PP_MCLK, buf);
> + clk = parse_clk(buf, lowest);
Dito.
Apart from that looks good to me of hand, Christian.
> +
> + kfree(buf);
> +
> + return clk;
> +}
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> index 722deef..584947b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.h
> @@ -57,6 +57,8 @@ struct amdgpu_virt_ops {
> int (*reset_gpu)(struct amdgpu_device *adev);
> int (*wait_reset)(struct amdgpu_device *adev);
> void (*trans_msg)(struct amdgpu_device *adev, u32 req, u32 data1,
> u32 data2, u32 data3);
> + int (*get_pp_clk)(struct amdgpu_device *adev, u32 type, char *buf);
> + int (*force_dpm_level)(struct amdgpu_device *adev, u32 level);
> };
>
> /*
> @@ -83,6 +85,8 @@ enum AMDGIM_FEATURE_FLAG {
> AMDGIM_FEATURE_GIM_LOAD_UCODES = 0x2,
> /* VRAM LOST by GIM */
> AMDGIM_FEATURE_GIM_FLR_VRAMLOST = 0x4,
> + /* HW PERF SIM in GIM */
> + AMDGIM_FEATURE_HW_PERF_SIMULATION = (1 << 3),
> };
>
> struct amd_sriov_msg_pf2vf_info_header { @@ -252,6 +256,8 @@ struct
> amdgpu_virt {
> struct amdgpu_vf_error_buffer vf_errors;
> struct amdgpu_virt_fw_reserve fw_reserve;
> uint32_t gim_feature;
> + /* protect DPM events to GIM */
> + struct mutex dpm_mutex;
> };
>
> #define amdgpu_sriov_enabled(adev) \ @@ -278,6 +284,9 @@ static
> inline bool is_virtual_machine(void)
> #endif
> }
>
> +#define amdgim_is_hwperf(adev) \
> + ((adev)->virt.gim_feature & AMDGIM_FEATURE_HW_PERF_SIMULATION)
> +
> bool amdgpu_virt_mmio_blocked(struct amdgpu_device *adev);
> void amdgpu_virt_init_setting(struct amdgpu_device *adev);
> uint32_t amdgpu_virt_kiq_rreg(struct amdgpu_device *adev, uint32_t
> reg); @@ -295,5 +304,7 @@ int amdgpu_virt_fw_reserve_get_checksum(void *obj, unsigned long obj_size,
> unsigned int key,
> unsigned int chksum);
> void amdgpu_virt_init_data_exchange(struct amdgpu_device *adev);
> +uint32_t amdgpu_virt_get_sclk(struct amdgpu_device *adev, bool
> +lowest); uint32_t amdgpu_virt_get_mclk(struct amdgpu_device *adev,
> +bool lowest);
>
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> index 73851eb..8dbad49 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c
> @@ -157,6 +157,82 @@ static void xgpu_ai_mailbox_trans_msg (struct amdgpu_device *adev,
> xgpu_ai_mailbox_set_valid(adev, false);
> }
>
> +static int xgpu_ai_get_pp_clk(struct amdgpu_device *adev, u32 type,
> +char *buf) {
> + int r = 0;
> + u32 req, val, size;
> +
> + if (!amdgim_is_hwperf(adev) || buf == NULL)
> + return -EBADRQC;
> +
> + switch(type) {
> + case PP_SCLK:
> + req = IDH_IRQ_GET_PP_SCLK;
> + break;
> + case PP_MCLK:
> + req = IDH_IRQ_GET_PP_MCLK;
> + break;
> + default:
> + return -EBADRQC;
> + }
> +
> + mutex_lock(&adev->virt.dpm_mutex);
> +
> + xgpu_ai_mailbox_trans_msg(adev, req, 0, 0, 0);
> +
> + r = xgpu_ai_poll_msg(adev, IDH_SUCCESS);
> + if (!r && adev->fw_vram_usage.va != NULL) {
> + val = RREG32_NO_KIQ(
> + SOC15_REG_OFFSET(NBIO, 0,
> + mmBIF_BX_PF0_MAILBOX_MSGBUF_RCV_DW1));
> + size = strnlen((((char *)adev->virt.fw_reserve.p_pf2vf) +
> + val), PAGE_SIZE);
> +
> + if (size < PAGE_SIZE)
> + strcpy(buf,((char *)adev->virt.fw_reserve.p_pf2vf + val));
> + else
> + size = 0;
> +
> + r = size;
> + goto out;
> + }
> +
> + r = xgpu_ai_poll_msg(adev, IDH_FAIL);
> + if(r)
> + pr_info("%s DPM request failed",
> + (type == PP_SCLK)? "SCLK" : "MCLK");
> +
> +out:
> + mutex_unlock(&adev->virt.dpm_mutex);
> + return r;
> +}
> +
> +static int xgpu_ai_force_dpm_level(struct amdgpu_device *adev, u32
> +level) {
> + int r = 0;
> + u32 req = IDH_IRQ_FORCE_DPM_LEVEL;
> +
> + if (!amdgim_is_hwperf(adev))
> + return -EBADRQC;
> +
> + mutex_lock(&adev->virt.dpm_mutex);
> + xgpu_ai_mailbox_trans_msg(adev, req, level, 0, 0);
> +
> + r = xgpu_ai_poll_msg(adev, IDH_SUCCESS);
> + if (!r)
> + goto out;
> +
> + r = xgpu_ai_poll_msg(adev, IDH_FAIL);
> + if (!r)
> + pr_info("DPM request failed");
> + else
> + pr_info("Mailbox is broken");
> +
> +out:
> + mutex_unlock(&adev->virt.dpm_mutex);
> + return r;
> +}
> +
> static int xgpu_ai_send_access_requests(struct amdgpu_device *adev,
> enum idh_request req)
> {
> @@ -375,4 +451,6 @@ const struct amdgpu_virt_ops xgpu_ai_virt_ops = {
> .reset_gpu = xgpu_ai_request_reset,
> .wait_reset = NULL,
> .trans_msg = xgpu_ai_mailbox_trans_msg,
> + .get_pp_clk = xgpu_ai_get_pp_clk,
> + .force_dpm_level = xgpu_ai_force_dpm_level,
> };
> diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h
> b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h
> index b4a9cee..39d151b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h
> +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_ai.h
> @@ -35,6 +35,10 @@ enum idh_request {
> IDH_REL_GPU_FINI_ACCESS,
> IDH_REQ_GPU_RESET_ACCESS,
>
> + IDH_IRQ_FORCE_DPM_LEVEL = 10,
> + IDH_IRQ_GET_PP_SCLK,
> + IDH_IRQ_GET_PP_MCLK,
> +
> IDH_LOG_VF_ERROR = 200,
> };
>
> @@ -43,6 +47,8 @@ enum idh_event {
> IDH_READY_TO_ACCESS_GPU,
> IDH_FLR_NOTIFICATION,
> IDH_FLR_NOTIFICATION_CMPL,
> + IDH_SUCCESS,
> + IDH_FAIL,
> IDH_EVENT_MAX
> };
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 2/3] x86/mm: Introduce altp2m_set_entry_by_page_order
From: Alexandru Stefan ISAILA @ 2019-04-10 14:22 UTC (permalink / raw)
To: George Dunlap, xen-devel@lists.xenproject.org
Cc: tamas@tklengyel.com, wei.liu2@citrix.com,
rcojocaru@bitdefender.com, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, jbeulich@suse.com,
roger.pau@citrix.com
In-Reply-To: <0ed3bfad-8c35-2143-0c1d-047492a00f31@citrix.com>
On 10.04.2019 17:18, George Dunlap wrote:
> On 4/9/19 1:03 PM, Alexandru Stefan ISAILA wrote:
>> This patch moves common code from p2m_set_altp2m_mem_access() and
>> p2m_change_altp2m_gfn() into one function
>>
>> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
>> ---
>> xen/arch/x86/mm/mem_access.c | 2 +-
>> xen/include/asm-x86/p2m.h | 11 +++++++++++
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index bf67ddb15a..6a22512555 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
>> gfn_t gfn2 = _gfn(gfn_l & mask);
>> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>>
>> - /* Note: currently it is not safe to remap to a shared entry */
>> + /* Note: currently it is not safe to remap to a shared entry */
>> if ( t != p2m_ram_rw )
>> return -ESRCH;
>>
>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>> index 6de1546d76..90a6c135a7 100644
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -467,6 +467,17 @@ static inline mfn_t altp2m_get_gfn_type_access(
>> return mfn;
>> }
>>
>> +static inline int altp2m_set_entry_by_page_order(
>> + struct p2m_domain *ap2m, unsigned long gfn, mfn_t mfn,
>> + unsigned int page_order, p2m_type_t t, p2m_access_t a)
>
> This function doesn't seem to be called anywhere in this series.
Yes I saw that yesterday after sending the patch. The call got lost in
the re-base/merge process. Sorry about that, it will go on again in v4
Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 07/10] media: coda: limit frame interval enumeration to supported frame sizes
From: Philipp Zabel @ 2019-04-10 14:22 UTC (permalink / raw)
To: Hans Verkuil, linux-media; +Cc: kernel
In-Reply-To: <ebbc3d03-e59e-32d5-c943-f9e426414848@xs4all.nl>
On Wed, 2019-04-10 at 15:43 +0200, Hans Verkuil wrote:
[...]
> > @@ -1126,12 +1127,32 @@ static int coda_enum_frameintervals(struct file *file, void *fh,
[...]
>
> Why support VIDIOC_ENUM_FRAMEINTERVALS at all? It makes no sense for a codec.
> I'd remove it altogether.
It returns the range supported by the frame rate registers that can be
set for constant bitrate encoding. I think the idea was to let the
GStreamer v4l2 elements know about possible frame rate range.
I think I should be able to remove it without any negative effects.
regards
Philipp
^ permalink raw reply
* Re: [dpdk-dev] [PATCH v7 2/4] meson: add infra to support machine specific flags
From: Pavan Nikhilesh Bhagavatula @ 2019-04-10 14:22 UTC (permalink / raw)
To: Yongseok Koh, jerinjacobk@gmail.com
Cc: Thomas Monjalon, dev, Jerin Jacob Kollanukkaran
In-Reply-To: <122A13B7-4883-4719-A682-AE3C40DDAA96@mellanox.com>
>-----Original Message-----
>From: Yongseok Koh <yskoh@mellanox.com>
>Sent: Wednesday, April 10, 2019 7:45 AM
>To: jerinjacobk@gmail.com; Pavan Nikhilesh Bhagavatula
><pbhagavatula@marvell.com>
>Cc: Thomas Monjalon <thomas@monjalon.net>; dev <dev@dpdk.org>; Jerin
>Jacob Kollanukkaran <jerinj@marvell.com>
>Subject: [EXT] Re: [dpdk-dev] [PATCH v7 2/4] meson: add infra to support
>machine specific flags
>
>External Email
>
>----------------------------------------------------------------------
>
>> On Apr 9, 2019, at 5:40 PM, Yongseok Koh <yskoh@mellanox.com> wrote:
>>
>>>
>>> On Apr 6, 2019, at 7:27 AM, jerinjacobk@gmail.com wrote:
>>>
>>> From: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>>
>>> Currently, RTE_* flags are set based on the implementer ID but there
>>> might be some micro arch specific differences from the same vendor
>>> eg. CACHE_LINESIZE. Add support to set micro arch specific flags.
>>>
>>> Signed-off-by: Pavan Nikhilesh <pbhagavatula@marvell.com>
>>> Signed-off-by: Jerin Jacob <jerinj@marvell.com>
>>> ---
>>> config/arm/meson.build | 37 ++++++++++++++++++++++++++++++++-----
>>> 1 file changed, 32 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/config/arm/meson.build b/config/arm/meson.build index
>>> 170a4981a..8de3f3e3a 100644
>>> --- a/config/arm/meson.build
>>> +++ b/config/arm/meson.build
>>> @@ -52,12 +52,10 @@ flags_generic = [
>>> ['RTE_USE_C11_MEM_MODEL', true],
>>> ['RTE_CACHE_LINE_SIZE', 128]]
>>> flags_cavium = [
>>> - ['RTE_MACHINE', '"thunderx"'],
>>> ['RTE_CACHE_LINE_SIZE', 128],
>>> ['RTE_MAX_NUMA_NODES', 2],
>>> ['RTE_MAX_LCORE', 96],
>>> - ['RTE_MAX_VFIO_GROUPS', 128],
>>> - ['RTE_USE_C11_MEM_MODEL', false]]
>>> + ['RTE_MAX_VFIO_GROUPS', 128]]
>>> flags_dpaa = [
>>> ['RTE_MACHINE', '"dpaa"'],
>>> ['RTE_USE_C11_MEM_MODEL', true],
>>> @@ -71,6 +69,27 @@ flags_dpaa2 = [
>>> ['RTE_MAX_NUMA_NODES', 1],
>>> ['RTE_MAX_LCORE', 16],
>>> ['RTE_LIBRTE_DPAA2_USE_PHYS_IOVA', false]]
>>> +flags_default_extra = []
>>> +flags_thunderx_extra = [
>>> + ['RTE_MACHINE', '"thunderx"'],
>>> + ['RTE_USE_C11_MEM_MODEL', false]]
>>> +
>>> +machine_args_generic = [
>>> + ['default', ['-march=armv8-a+crc+crypto']],
>>> + ['native', ['-march=native']],
>>> + ['0xd03', ['-mcpu=cortex-a53']],
>>> + ['0xd04', ['-mcpu=cortex-a35']],
>>> + ['0xd07', ['-mcpu=cortex-a57']],
>>> + ['0xd08', ['-mcpu=cortex-a72']],
>>> + ['0xd09', ['-mcpu=cortex-a73']],
>>> + ['0xd0a', ['-mcpu=cortex-a75']]]
>>> +
>>> +machine_args_cavium = [
>>> + ['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
>>> + ['native', ['-march=native']],
>>> + ['0xa1', ['-mcpu=thunderxt88'], flags_thunderx_extra],
>>> + ['0xa2', ['-mcpu=thunderxt81'], flags_thunderx_extra],
>>> + ['0xa3', ['-mcpu=thunderxt83'], flags_thunderx_extra]]
>>
>> Looks like there's a mistake in rebasing it?
Seems so will send out v8.
>> You should've removed machine_args_generic and machine_args_cavium in
>> the beginning of this file.
>>
>> Other than that, it looks good to me.
>>
>> BTW, thanks for the patch. I raised this issue before and I was
>> supposed to make the change but you have taken it.
>>
>> Yongseok
>>
>>> ## Arm implementer ID (ARM DDI 0487C.a, Section G7.2.106, Page
>>> G7-5321) impl_generic = ['Generic armv8', flags_generic,
>>> machine_args_generic] @@ -157,8 +176,16 @@ else
>>> endif
>>> foreach marg: machine[2]
>>> if marg[0] == impl_pn
>>> - foreach f: marg[1]
>>> - machine_args += f
>>> + foreach flag: marg[1]
>>> + if cc.has_argument(flag)
>>> + machine_args += flag
>>> + endif
>>> + endforeach
>>> + # Apply any extra machine specific flags.
>>> + foreach flag: marg.get(2, flags_default_extra)
>>> + if flag.length() > 0
>>> + dpdk_conf.set(flag[0], flag[1])
>>> + endif
>
>And setting the extra flags doesn't work well with gcc < 7 because of the
>following,
Extra flags aren't set in this case as the third variable in the list is missing when 'native' or 'default' is selected
generic=
['default', ['-march=armv8-a+crc+crypto']],
['native', ['-march=native']]
cavium=
['default', ['-march=armv8-a+crc+crypto','-mcpu=thunderx']],
['native', ['-march=native']]
And marg.get falls back to flags_default_extra = [].
>
> # Primary part number based mcpu flags are supported
> # for gcc versions > 7
> if cc.version().version_compare(
> '<7.0') or cmd_output.length() == 0
> if not meson.is_cross_build() and arm_force_native_march == true
> impl_pn = 'native'
> else
> impl_pn = 'default'
> endif
> endif
>
>Thanks,
>Yongseok
>
>>> endforeach
>>> endif
>>> endforeach
>>> --
>>> 2.21.0
^ permalink raw reply
* Re: [PATCH v3 2/3] x86/mm: Introduce altp2m_set_entry_by_page_order
From: Alexandru Stefan ISAILA @ 2019-04-10 14:22 UTC (permalink / raw)
To: George Dunlap, xen-devel@lists.xenproject.org
Cc: tamas@tklengyel.com, wei.liu2@citrix.com,
rcojocaru@bitdefender.com, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, jbeulich@suse.com,
roger.pau@citrix.com
In-Reply-To: <0ed3bfad-8c35-2143-0c1d-047492a00f31@citrix.com>
On 10.04.2019 17:18, George Dunlap wrote:
> On 4/9/19 1:03 PM, Alexandru Stefan ISAILA wrote:
>> This patch moves common code from p2m_set_altp2m_mem_access() and
>> p2m_change_altp2m_gfn() into one function
>>
>> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
>> ---
>> xen/arch/x86/mm/mem_access.c | 2 +-
>> xen/include/asm-x86/p2m.h | 11 +++++++++++
>> 2 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
>> index bf67ddb15a..6a22512555 100644
>> --- a/xen/arch/x86/mm/mem_access.c
>> +++ b/xen/arch/x86/mm/mem_access.c
>> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
>> gfn_t gfn2 = _gfn(gfn_l & mask);
>> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>>
>> - /* Note: currently it is not safe to remap to a shared entry */
>> + /* Note: currently it is not safe to remap to a shared entry */
>> if ( t != p2m_ram_rw )
>> return -ESRCH;
>>
>> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
>> index 6de1546d76..90a6c135a7 100644
>> --- a/xen/include/asm-x86/p2m.h
>> +++ b/xen/include/asm-x86/p2m.h
>> @@ -467,6 +467,17 @@ static inline mfn_t altp2m_get_gfn_type_access(
>> return mfn;
>> }
>>
>> +static inline int altp2m_set_entry_by_page_order(
>> + struct p2m_domain *ap2m, unsigned long gfn, mfn_t mfn,
>> + unsigned int page_order, p2m_type_t t, p2m_access_t a)
>
> This function doesn't seem to be called anywhere in this series.
Yes I saw that yesterday after sending the patch. The call got lost in
the re-base/merge process. Sorry about that, it will go on again in v4
Alex
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: YueHaibing @ 2019-04-10 14:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: bbrezillon, richard, linux-kernel, marek.vasut, paul.burton,
linux-mtd, miquel.raynal, computersforpeace
In-Reply-To: <20190410155856.655122c8@collabora.com>
On 2019/4/10 21:58, Boris Brezillon wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
>> On Wed, 10 Apr 2019 21:07:47 +0800
>> Yue Haibing <yuehaibing@huawei.com> wrote:
>>
>>> From: YueHaibing <yuehaibing@huawei.com>
>>>
>>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
>>> is set to module:
>>>
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
>>> (.text+0xef6): undefined reference to `nand_bch_free'
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
>>> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
>>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
>>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
>>>
>>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
>>> because MTD_RAW_NAND need it while linked.
>>>
>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>>
>> Nope, it's not this one that introduced the regression.
>>
>>
>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> drivers/mtd/nand/raw/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>>> index 615d738..0500c42 100644
>>> --- a/drivers/mtd/nand/raw/Kconfig
>>> +++ b/drivers/mtd/nand/raw/Kconfig
>>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
>>> if MTD_RAW_NAND
>>>
>>> config MTD_NAND_ECC_SW_BCH
>>> - tristate "Support software BCH ECC"
>>> + bool "Support software BCH ECC"
>>> select BCH
>>> default n
>>> help
>>
>> Should be fixed with the following diff squashed into:
>>
>> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
>>
>> --->8---
>> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
>> index b8106651f807..06ce2b655c13 100644
>> --- a/include/linux/mtd/nand_bch.h
>> +++ b/include/linux/mtd/nand_bch.h
>> @@ -15,7 +15,7 @@ struct mtd_info;
>> struct nand_chip;
>> struct nand_bch_control;
>>
>> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
>> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>>
>> static inline int mtd_nand_has_bch(void) { return 1; }
>>
>> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
>> */
>> void nand_bch_free(struct nand_bch_control *nbc);
>>
>> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
>> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> static inline int mtd_nand_has_bch(void) { return 0; }
>>
>> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>>
>> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>>
>> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
>> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
It seems this dependency is not always need,
case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not set.
>
> .
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] mtd: nand: Fix build error while CONFIG_MTD_NAND_ECC_SW_BCH is set to module
From: YueHaibing @ 2019-04-10 14:22 UTC (permalink / raw)
To: Boris Brezillon
Cc: miquel.raynal, richard, computersforpeace, marek.vasut,
paul.burton, bbrezillon, linux-kernel, linux-mtd
In-Reply-To: <20190410155856.655122c8@collabora.com>
On 2019/4/10 21:58, Boris Brezillon wrote:
> On Wed, 10 Apr 2019 15:39:28 +0200
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
>> On Wed, 10 Apr 2019 21:07:47 +0800
>> Yue Haibing <yuehaibing@huawei.com> wrote:
>>
>>> From: YueHaibing <yuehaibing@huawei.com>
>>>
>>> Fix gcc build error while CONFIG_MTD_NAND_ECC_SW_BCH
>>> is set to module:
>>>
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_cleanup':
>>> (.text+0xef6): undefined reference to `nand_bch_free'
>>> drivers/mtd/nand/raw/nand_base.o: In function `nand_scan_tail':
>>> nand_base.c:(.text+0xa101): undefined reference to `nand_bch_calculate_ecc'
>>> nand_base.c:(.text+0xa120): undefined reference to `nand_bch_correct_data'
>>> nand_base.c:(.text+0xa269): undefined reference to `nand_bch_init'
>>>
>>> CONFIG_MTD_NAND_ECC_SW_BCH should not be set to M,
>>> because MTD_RAW_NAND need it while linked.
>>>
>>> Reported-by: Hulk Robot <hulkci@huawei.com>
>>> Fixes: 193bd4002644 ("mtd: nand: add software BCH ECC support"
>>
>> Nope, it's not this one that introduced the regression.
>>
>>
>>
>>> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
>>> ---
>>> drivers/mtd/nand/raw/Kconfig | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
>>> index 615d738..0500c42 100644
>>> --- a/drivers/mtd/nand/raw/Kconfig
>>> +++ b/drivers/mtd/nand/raw/Kconfig
>>> @@ -22,7 +22,7 @@ menuconfig MTD_RAW_NAND
>>> if MTD_RAW_NAND
>>>
>>> config MTD_NAND_ECC_SW_BCH
>>> - tristate "Support software BCH ECC"
>>> + bool "Support software BCH ECC"
>>> select BCH
>>> default n
>>> help
>>
>> Should be fixed with the following diff squashed into:
>>
>> 51ef1d0b2095 ("mtd: nand: Clarify Kconfig entry for software BCH ECC algorithm")
>>
>> --->8---
>> diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
>> index b8106651f807..06ce2b655c13 100644
>> --- a/include/linux/mtd/nand_bch.h
>> +++ b/include/linux/mtd/nand_bch.h
>> @@ -15,7 +15,7 @@ struct mtd_info;
>> struct nand_chip;
>> struct nand_bch_control;
>>
>> -#if defined(CONFIG_MTD_NAND_ECC_BCH)
>> +#if defined(CONFIG_MTD_NAND_ECC_SW_BCH)
>>
>> static inline int mtd_nand_has_bch(void) { return 1; }
>>
>> @@ -39,7 +39,7 @@ struct nand_bch_control *nand_bch_init(struct mtd_info *mtd);
>> */
>> void nand_bch_free(struct nand_bch_control *nbc);
>>
>> -#else /* !CONFIG_MTD_NAND_ECC_BCH */
>> +#else /* !CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> static inline int mtd_nand_has_bch(void) { return 0; }
>>
>> @@ -64,6 +64,6 @@ static inline struct nand_bch_control *nand_bch_init(struct mtd_info *mtd)
>>
>> static inline void nand_bch_free(struct nand_bch_control *nbc) {}
>>
>> -#endif /* CONFIG_MTD_NAND_ECC_BCH */
>> +#endif /* CONFIG_MTD_NAND_ECC_SW_BCH */
>>
>> #endif /* __MTD_NAND_BCH_H__ */
>
> Sorry, I didn't look at the right branch, this part of the code was
> correct, but we still have a problem to express the RAW_NAND(y) ->
> SW_BCH(y) dependency.
It seems this dependency is not always need,
case MTD_RAW_NAND set to y works well while CONFIG_MTD_NAND_ECC_SW_BCH is not set.
>
> .
>
^ permalink raw reply
* Re: Bug: VHCI + USB 3.0
From: Alan Stern @ 2019-04-10 14:22 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Seth Bollinger, Ming Lei, Jens Axboe, linux-block, USB list
In-Reply-To: <1554883329.21725.1.camel@suse.com>
On Wed, 10 Apr 2019, Oliver Neukum wrote:
> On Di, 2019-04-09 at 15:57 -0400, Alan Stern wrote:
> > On Tue, 9 Apr 2019, Bollinger, Seth wrote:
> >
> > > I will do that as a test. However, I’m concerned that we’re solving only a specific case. Won’t it fail in a similar way if a different subsystem does the same thing (USB modem or video drivers, etc.)?
> >
> > Those other drivers don't use the block device interface, as far as I
> > know. So they would have to use other methods for addressing the
> > potential problems in any case. usb-storage is perhaps distinct in
> > that it doesn't generate the scatter-gather lists that it uses, but
> > instead has to work with whatever the block layer provides.
>
> UAS, too. But I can pick up the corresponding fix.
> Are you sure about sound though?
Yes; I just did a quick check for occurrences of "blk_queue" under
sound/.
Besides, sound drivers use the ALSA interface to userspace. The
devices don't show up as regular block devices.
Alan Stern
^ permalink raw reply
* Re: Device Description for FPGA Components on x86 system
From: Alan Tull @ 2019-04-10 14:21 UTC (permalink / raw)
To: Federico Vaga
Cc: Eric Schwarz, linux-kernel, linux-fpga, linux-pci,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-x86_64, linux-fpga-owner
In-Reply-To: <31100498.IIhqzTXyFT@pcbe13614>
On Wed, Apr 10, 2019 at 7:50 AM Federico Vaga <federico.vaga@cern.ch> wrote:
Hi Federico,
I wish I could point you to a complete solution, but there is a lot of
work to be done in this area. Most of what is in the kernel is a low
level in-kernel API [4]. As you correctly state, the hardest part of
this is doing the enumerating if you are on x86 and aren't using
devicetree.
>
> Hi,
>
> P.S. sorry if I'm too verbose, hopefully it is useful
>
> thanks for the answer
>
> On Wednesday, April 10, 2019 12:30:14 PM CEST Eric Schwarz wrote:
> > Hi,
> >
> > everything you want is already available and on the way to mainline
> > concerning support for various FPGA loading modes or available for
> > checkout from a git repository.
> > All that has already been discussed on the mailing list.
> >
> > FPGA loading interface is available here [1].
> > Patchset missing for FPGA loading has been sent to the mailing list from
> > Anatolij Gustschin for various Linux kernel versions. Link to the most
> > recent patchset version [2].
> > FPGA Manager mailing list archive link [3] - Please read up the story
> > here around those patches and also the replies of the others.
>
> This does not answer the problem, which perhaps need to be clarified.
>
> Loading FPGA is **not** the problem, I listed it in the things I want to
> achieve because it is a pre-requirement for the real problem and because the
> two processes are linked (or could be).
>
> I continue by commenting myself below, trying to make the use case clearer.
>
> >
> > Cheers
> > Eric
> >
> > [1] https://github.com/vdsao/fpga-cfg
> > [2] https://marc.info/?l=linux-fpga&m=155078072107199&w=2
> > [3] https://marc.info/?l=linux-fpga
> >
> > Am 10.04.2019 12:01, schrieb Federico Vaga:
> > > Hello,
> > >
> > > sorry to push for an answer but I do not want to take the risk of
> > > designing
> > > something useless. I do not know how should I interpret a no-answer.
> > >
> > > If the solution really does not exist today, then I would like to
> > > collect
> > > opinions/arguments/requirements on the topic so that I can write
> > > something
> > > useful not only for CERN but for the entire community.
> > >
> > > Thank you
> > >
> > > On Wednesday, March 27, 2019 6:17:18 PM CEST Federico Vaga wrote:
> > >> Hello,
> > >>
> > >> I'm looking for guidance
> > >>
> > >> What I have:
> > >> * Intel x86_64 computer
> > >> * PCIe card with FPGA on it
> > >>
> > >> What I want to achieve:
> > >> * load an FPGA bitstream on the card
> > >> * load a device-tree like description for the FPGA devices contained
> > >> in the bitstream
>
> Let me first elaborate on my knowledge to avoid misunderstandings.
>
> On ARM, nowadays, we boot with a device tree. Later we program an FPGA in
> which there are other devices described by a device tree overlay. This can be
> done easily.
>
> A typical PC (x86/x86_64) does not boot with DeviceTree (it is possible, but
> it is not common and probably not even suggested, not sure), instead it uses
> ACPI.
I have heard it suggested that we work on using DT overlays on x86*.
It's clear there's work to be done to make that work. I don't know if
anybody has really tried. It seems impractical to map or translate a
x86 systems ACPI into a DT and go from there. One suggestion a few
years ago was adding a partial DT that had nodes that could serve as
overlay targets and have that running in parallel with ACPI.
>
> The FPGA Manager has support only for DeviceTree (there are patching floating
> around to load a bitstream with configfs, debugfs or a chardevice (guilty))
There's one other interface in the kernel upstream. The DFL (device
feature list) framework built on the FPGA manager/bridge/region stuff
[5]. It's probably not what you specifically are looking for, I'm
mentioning as it exists in upstream. It has a limited type of
enumeration and appears to mostly be geared for acceleration rather
than adding and enumerating any random hardware block. Also it
requires specific bitstreams as the feature list is in fpga fabric.
>
> Most drivers foresee a DeviceTree loading but not an ACPI one (my feeling, I
> did not extract exact numbers from the sources)
>
> DeviceTree overlay requires that the system boots with DeviceTree.
>
> DeviceTree and ACPI do not work together
>
> So, this is the state of art that I am aware of. Correct me if, and where, I
> am wrong.
>
>
> Restarting from this point. I have a PC (x86_64) with a PCIe FPGA card (e.g.
> sis8160, spec, links below). How to load the FPGA bitstream (not really a
> problem as you correctly pointed out) **and** load all the IP-core instances
> in that FPGA bitstream so that drivers will start running?
>
> - Is there a recommendation for such use case?
> - ACPI SSDT overlay?
> - DT overlay?
> - is there a standard way to load FPGA IP-core devices which is architecture
> independent?
>
> A simple and practical example. The i2c-ocore.c is a platform_driver for an
> HDL I2C Master from open cores. I synthesize it and then load it on the FPGA.
> How to create the Linux platform_device instance to driver that IP-core? How
> to do that when you have also IRQ controller(s), DMA engine(s), EEPROM(s) and
> other devices?
>
> The fastest solution is to do what was common on ARM systems: having all
> platform devices declared (hard coded) in a file and load them. Which is not a
> good solution, for the same reasons why arm stuff moved to devicetree.
>
> Is it clearer?
>
> I do not know if it important to highlight but those cards are extensible,
> potentially any FMC module could be plugged and this needs a different FPGA,
> with different FPGA devices etc. So, It is not possible to hardcode the
> description of all possible FPGA code (infinite) that can enable the usage of
> all possible FMC module (not infinite, but definitively grater than 1)
>
>
> https://www.struck.de/sis8160.html
> https://ohwr.org/project/spec/wikis/home
>
>
> > >>
> > >> This is achievable on ARM with DeviceTree, overlay-dt, fpga-mgr; but
> > >> I'm
> > >> puzzled about the x86_64 use-case. I'm not able to find recent and
> > >> clear
> > >> information.
> > >>
> > >> Does anyone know if this is doable? Perhaps with ACPI SSDTs overlay?
> > >> Or with
> > >> the DT?
> > >>
> > >> thanks
Thanks,
Alan
[4] https://www.kernel.org/doc/html/latest/driver-api/fpga/index.html
[5] https://github.com/torvalds/linux/blob/master/Documentation/fpga/dfl.txt
^ permalink raw reply
* Re: [RFC PATCH] media/doc: Allow sizeimage to be set by v4l clients
From: Stanimir Varbanov @ 2019-04-10 14:21 UTC (permalink / raw)
To: Hans Verkuil, linux-media
Cc: Mauro Carvalho Chehab, linux-kernel, linux-arm-msm,
Vikash Garodia, Tomasz Figa, Alexandre Courbot, Malathi Gottam
In-Reply-To: <c103b0d8-0020-17e0-4584-e5c3ca6bbc51@xs4all.nl>
Hi Hans,
On 3/14/19 3:11 PM, Hans Verkuil wrote:
> On 1/21/19 11:48 AM, Stanimir Varbanov wrote:
>> Hi Hans,
>>
>> On 1/18/19 11:13 AM, Hans Verkuil wrote:
>>> On 1/16/19 1:37 PM, Stanimir Varbanov wrote:
>>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage
>>>> field description to allow v4l clients to set bigger image size
>>>> in case of variable length compressed data.
>>>>
>>>> Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
>>>> ---
>>>> Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst | 5 ++++-
>>>> Documentation/media/uapi/v4l/pixfmt-v4l2.rst | 3 ++-
>>>> 2 files changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> index 7f82dad9013a..dbe0b74e9ba4 100644
>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2-mplane.rst
>>>> @@ -30,7 +30,10 @@ describing all planes of that format.
>>>>
>>>> * - __u32
>>>> - ``sizeimage``
>>>> - - Maximum size in bytes required for image data in this plane.
>>>> + - Maximum size in bytes required for image data in this plane,
>>>> + set by the driver. When the image consists of variable length
>>>> + compressed data this is the maximum number of bytes required
>>>> + to hold an image, and it is allowed to be set by the client.
>>>> * - __u32
>>>> - ``bytesperline``
>>>> - Distance in bytes between the leftmost pixels in two adjacent
>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> index 71eebfc6d853..54b6d2b67bd7 100644
>>>> --- a/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-v4l2.rst
>>>> @@ -89,7 +89,8 @@ Single-planar format structure
>>>> - Size in bytes of the buffer to hold a complete image, set by the
>>>> driver. Usually this is ``bytesperline`` times ``height``. When
>>>> the image consists of variable length compressed data this is the
>>>> - maximum number of bytes required to hold an image.
>>>> + maximum number of bytes required to hold an image, and it is
>>>> + allowed to be set by the client.
>>>> * - __u32
>>>> - ``colorspace``
>>>> - Image colorspace, from enum :c:type:`v4l2_colorspace`.
>>>>
>>>
>>> Hmm. "maximum number of bytes required to hold an image": that's not actually true
>>> for bitstream formats like MPEG. It's just the size of the buffer used to store the
>>> bitstream, i.e. one buffer may actually contain multiple compressed images, or a
>>> compressed image is split over multiple buffers.
>>>
>>
>> Do you want me to change something in the current documentation, i.e.
>> the quoted above?
>
> Hmm, it looks like this discussion stalled (i.e. I forgot to reply).
>
> How about this:
>
> "When the image consists of variable length compressed data this is the
> number of bytes required by the encoder to support the worst-case
I don't think 'encoder' is the right word here:
s/encoder/encoder or decoder
> compression scenario. Clients are allowed to set this field. However,
> drivers may ignore the value or modify it."
Can we rephrase to:
"Clients are allowed to set sizeimage field, but however drivers my
ignore the value or modify it."
--
regards,
Stan
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] crypto/qat: fix second seg fault in QAT PMD
From: Iremonger, Bernard @ 2019-04-10 14:19 UTC (permalink / raw)
To: Iremonger, Bernard, Trahe, Fiona, dev@dpdk.org,
Ananyev, Konstantin, akhil.goyal@nxp.com
In-Reply-To: <8CEF83825BEC744B83065625E567D7C260D867E5@IRSMSX108.ger.corp.intel.com>
Hi Fiona,
<snip>
> > > Subject: [PATCH] crypto/qat: fix second seg fault in QAT PMD
> > >
> > > While running the IPsec unit tests the following segmentation fault
> > > is
> > > occurring:
> > >
> > > Thread 1 "test" received signal SIGSEGV, Segmentation fault.
> > > 0x0000000000bf3b50 in qat_sym_process_response (
> > > op=0x5355280 <unittest_params+512>, resp=0x100455100 "") at
> > > /root/dpdk/drivers/crypto/qat/qat_sym.h:161
> > > 161 if (sess->bpi_ctx)
> > >
> > > Fixes: 91614c73b67c ("crypto/qat: make response process function
> > > inline")
> > > Signed-off-by: Bernard Iremonger <bernard.iremonger@intel.com>
> > > ---
> > > drivers/crypto/qat/qat_sym.h | 8 +++++---
> > > 1 file changed, 5 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/crypto/qat/qat_sym.h
> > > b/drivers/crypto/qat/qat_sym.h index bc6426c..685c6c0 100644
> > > --- a/drivers/crypto/qat/qat_sym.h
> > > +++ b/drivers/crypto/qat/qat_sym.h
> > > @@ -157,10 +157,12 @@ qat_sym_process_response(void **op, uint8_t
> > *resp)
> > > rx_op->sym->session,
> > > cryptodev_qat_driver_id);
> > >
> > > -
> > > - if (sess->bpi_ctx)
> > > + if (sess == NULL)
> > > + rx_op->status =
> > RTE_CRYPTO_OP_STATUS_AUTH_FAILED;
> > > + else if (sess->bpi_ctx) {
> > > qat_bpicipher_postprocess(sess, rx_op);
> > > - rx_op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
> > > + rx_op->status = RTE_CRYPTO_OP_STATUS_SUCCESS;
> > > + }
> > > }
> > > *op = (void *)rx_op;
> > > }
> > > --
> > > 2.7.4
> > [Fiona] As for previous seg-fault- this is on data-path and likely due
> > to the application sending in an invalid session - or a session
> > created for a symmetric PMD, but being sent to a QAT asymmetric PMD -
> > whose driver_id would not appear in the session array.
> > Can you make sure to check for SYMMETRIC support in capabilities.
> >
> I have the asym PMD disabled in the common/config_base file.
> I will investigate further.
Self NAK of this patch as causing test failures.
Regards,
Bernard.
^ permalink raw reply
* Re: [PATCH 1/7] media: atmel: atmel-isc: add safe checks and fixed wrong ISC state in error case
From: Hans Verkuil @ 2019-04-10 14:19 UTC (permalink / raw)
To: Eugen.Hristev, linux-media, Nicolas.Ferre, linux-arm-kernel,
linux-kernel, mchehab
Cc: ksloat
In-Reply-To: <1554807715-2353-2-git-send-email-eugen.hristev@microchip.com>
On 4/9/19 1:07 PM, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> This adds safety checks on some scenarios:
> - start streaming but streaming is already started
Can't happen. vb2 checks for that.
> - start streaming but no buffer in the dma queue
Can't happen since min_buffers_needed is > 0. So start_streaming will
never be called unless at least one buffer is queued.
> - spin lock is not released in error scenario
> - no frame is configured but dma is requested to start
Can this ever happen? It's set by start_streaming when you know there is
at least one buffer, so this seems overkill.
Regards,
Hans
> - configure ISC may have been called without need, before checking if buffer is
> ok.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> drivers/media/platform/atmel/atmel-isc.c | 32 +++++++++++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index a10db16..3c19761 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -722,6 +722,11 @@ static void isc_start_dma(struct isc_device *isc)
> u32 dctrl_dview;
> dma_addr_t addr0;
>
> + if (!isc->cur_frm) {
> + v4l2_err(&isc->v4l2_dev, "Video buffer not available\n");
> + return;
> + }
> +
> addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
> regmap_write(regmap, ISC_DAD0, addr0);
>
> @@ -886,6 +891,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
> unsigned long flags;
> int ret;
>
> + if (vb2_is_streaming(&isc->vb2_vidq))
> + return -EBUSY;
> +
> /* Enable stream on the sub device */
> ret = v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 1);
> if (ret && ret != -ENOIOCTLCMD) {
> @@ -896,6 +904,20 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> pm_runtime_get_sync(isc->dev);
>
> + spin_lock_irqsave(&isc->dma_queue_lock, flags);
> +
> + isc->sequence = 0;
> + isc->stop = false;
> + reinit_completion(&isc->comp);
> +
> + if (list_empty(&isc->dma_queue)) {
> + v4l2_err(&isc->v4l2_dev, "dma queue empty\n");
> + ret = -EINVAL;
> + goto err_configure_unlock;
> + }
> +
> + spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
> +
> ret = isc_configure(isc);
> if (unlikely(ret))
> goto err_configure;
> @@ -905,10 +927,6 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> spin_lock_irqsave(&isc->dma_queue_lock, flags);
>
> - isc->sequence = 0;
> - isc->stop = false;
> - reinit_completion(&isc->comp);
> -
> isc->cur_frm = list_first_entry(&isc->dma_queue,
> struct isc_buffer, list);
> list_del(&isc->cur_frm->list);
> @@ -919,8 +937,11 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> return 0;
>
> +err_configure_unlock:
> + spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
> +
> err_configure:
> - pm_runtime_put_sync(isc->dev);
> + isc->stop = true;
>
> v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
>
> @@ -931,6 +952,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
> INIT_LIST_HEAD(&isc->dma_queue);
> spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
>
> + pm_runtime_put_sync(isc->dev);
> return ret;
> }
>
>
_______________________________________________
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 1/7] media: atmel: atmel-isc: add safe checks and fixed wrong ISC state in error case
From: Hans Verkuil @ 2019-04-10 14:19 UTC (permalink / raw)
To: Eugen.Hristev, linux-media, Nicolas.Ferre, linux-arm-kernel,
linux-kernel, mchehab
Cc: ksloat
In-Reply-To: <1554807715-2353-2-git-send-email-eugen.hristev@microchip.com>
On 4/9/19 1:07 PM, Eugen.Hristev@microchip.com wrote:
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> This adds safety checks on some scenarios:
> - start streaming but streaming is already started
Can't happen. vb2 checks for that.
> - start streaming but no buffer in the dma queue
Can't happen since min_buffers_needed is > 0. So start_streaming will
never be called unless at least one buffer is queued.
> - spin lock is not released in error scenario
> - no frame is configured but dma is requested to start
Can this ever happen? It's set by start_streaming when you know there is
at least one buffer, so this seems overkill.
Regards,
Hans
> - configure ISC may have been called without need, before checking if buffer is
> ok.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
> drivers/media/platform/atmel/atmel-isc.c | 32 +++++++++++++++++++++++++++-----
> 1 file changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/atmel/atmel-isc.c b/drivers/media/platform/atmel/atmel-isc.c
> index a10db16..3c19761 100644
> --- a/drivers/media/platform/atmel/atmel-isc.c
> +++ b/drivers/media/platform/atmel/atmel-isc.c
> @@ -722,6 +722,11 @@ static void isc_start_dma(struct isc_device *isc)
> u32 dctrl_dview;
> dma_addr_t addr0;
>
> + if (!isc->cur_frm) {
> + v4l2_err(&isc->v4l2_dev, "Video buffer not available\n");
> + return;
> + }
> +
> addr0 = vb2_dma_contig_plane_dma_addr(&isc->cur_frm->vb.vb2_buf, 0);
> regmap_write(regmap, ISC_DAD0, addr0);
>
> @@ -886,6 +891,9 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
> unsigned long flags;
> int ret;
>
> + if (vb2_is_streaming(&isc->vb2_vidq))
> + return -EBUSY;
> +
> /* Enable stream on the sub device */
> ret = v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 1);
> if (ret && ret != -ENOIOCTLCMD) {
> @@ -896,6 +904,20 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> pm_runtime_get_sync(isc->dev);
>
> + spin_lock_irqsave(&isc->dma_queue_lock, flags);
> +
> + isc->sequence = 0;
> + isc->stop = false;
> + reinit_completion(&isc->comp);
> +
> + if (list_empty(&isc->dma_queue)) {
> + v4l2_err(&isc->v4l2_dev, "dma queue empty\n");
> + ret = -EINVAL;
> + goto err_configure_unlock;
> + }
> +
> + spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
> +
> ret = isc_configure(isc);
> if (unlikely(ret))
> goto err_configure;
> @@ -905,10 +927,6 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> spin_lock_irqsave(&isc->dma_queue_lock, flags);
>
> - isc->sequence = 0;
> - isc->stop = false;
> - reinit_completion(&isc->comp);
> -
> isc->cur_frm = list_first_entry(&isc->dma_queue,
> struct isc_buffer, list);
> list_del(&isc->cur_frm->list);
> @@ -919,8 +937,11 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
>
> return 0;
>
> +err_configure_unlock:
> + spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
> +
> err_configure:
> - pm_runtime_put_sync(isc->dev);
> + isc->stop = true;
>
> v4l2_subdev_call(isc->current_subdev->sd, video, s_stream, 0);
>
> @@ -931,6 +952,7 @@ static int isc_start_streaming(struct vb2_queue *vq, unsigned int count)
> INIT_LIST_HEAD(&isc->dma_queue);
> spin_unlock_irqrestore(&isc->dma_queue_lock, flags);
>
> + pm_runtime_put_sync(isc->dev);
> return ret;
> }
>
>
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 2/3] x86/mm: Introduce altp2m_set_entry_by_page_order
From: George Dunlap @ 2019-04-10 14:18 UTC (permalink / raw)
To: Alexandru Stefan ISAILA, xen-devel@lists.xenproject.org
Cc: tamas@tklengyel.com, wei.liu2@citrix.com,
rcojocaru@bitdefender.com, george.dunlap@eu.citrix.com,
andrew.cooper3@citrix.com, jbeulich@suse.com,
roger.pau@citrix.com
In-Reply-To: <20190409120324.13940-2-aisaila@bitdefender.com>
On 4/9/19 1:03 PM, Alexandru Stefan ISAILA wrote:
> This patch moves common code from p2m_set_altp2m_mem_access() and
> p2m_change_altp2m_gfn() into one function
>
> Signed-off-by: Alexandru Isaila <aisaila@bitdefender.com>
> ---
> xen/arch/x86/mm/mem_access.c | 2 +-
> xen/include/asm-x86/p2m.h | 11 +++++++++++
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/xen/arch/x86/mm/mem_access.c b/xen/arch/x86/mm/mem_access.c
> index bf67ddb15a..6a22512555 100644
> --- a/xen/arch/x86/mm/mem_access.c
> +++ b/xen/arch/x86/mm/mem_access.c
> @@ -279,7 +279,7 @@ int p2m_set_altp2m_mem_access(struct domain *d, struct p2m_domain *hp2m,
> gfn_t gfn2 = _gfn(gfn_l & mask);
> mfn_t mfn2 = _mfn(mfn_x(mfn) & mask);
>
> - /* Note: currently it is not safe to remap to a shared entry */
> + /* Note: currently it is not safe to remap to a shared entry */
> if ( t != p2m_ram_rw )
> return -ESRCH;
>
> diff --git a/xen/include/asm-x86/p2m.h b/xen/include/asm-x86/p2m.h
> index 6de1546d76..90a6c135a7 100644
> --- a/xen/include/asm-x86/p2m.h
> +++ b/xen/include/asm-x86/p2m.h
> @@ -467,6 +467,17 @@ static inline mfn_t altp2m_get_gfn_type_access(
> return mfn;
> }
>
> +static inline int altp2m_set_entry_by_page_order(
> + struct p2m_domain *ap2m, unsigned long gfn, mfn_t mfn,
> + unsigned int page_order, p2m_type_t t, p2m_access_t a)
This function doesn't seem to be called anywhere in this series.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 0/2] Limit number of hw queues by nr_cpu_ids for virtio-blk and virtio-scsi
From: Jens Axboe @ 2019-04-10 14:18 UTC (permalink / raw)
To: Dongli Zhang, linux-scsi, virtualization, linux-block
Cc: mst, jasowang, jejb, martin.petersen, cohuck, linux-kernel
In-Reply-To: <1553682995-5682-1-git-send-email-dongli.zhang@oracle.com>
On 3/27/19 4:36 AM, Dongli Zhang wrote:
> When tag_set->nr_maps is 1, the block layer limits the number of hw queues
> by nr_cpu_ids. No matter how many hw queues are use by
> virtio-blk/virtio-scsi, as they both have (tag_set->nr_maps == 1), they
> can use at most nr_cpu_ids hw queues.
>
> In addition, specifically for pci scenario, when the 'num-queues' specified
> by qemu is more than maxcpus, virtio-blk/virtio-scsi would not be able to
> allocate more than maxcpus vectors in order to have a vector for each
> queue. As a result, they fall back into MSI-X with one vector for config
> and one shared for queues.
>
> Considering above reasons, this patch set limits the number of hw queues
> used by nr_cpu_ids for both virtio-blk and virtio-scsi.
I picked both up for 5.1.
--
Jens Axboe
^ 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.