Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
On Thu, 2015-12-17 at 11:19 +0800, Dave Young wrote: > > Cool, has the fix been in mainline or somewhere else? > https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=a87da0cbc42949cefc8282c39ab4cb8c460bd6ea johannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / sleep: define inline functions
On Thu, Dec 17, 2015 at 02:43:38AM +0100, Rafael J. Wysocki wrote:
> On Wednesday, December 16, 2015 04:41:37 PM Eric Anholt wrote:
> >
> > --=-=-=
> > Content-Type: text/plain
> >
> > Sudip Mukherjee writes:
> >
> > > If CONFIG_PM_SLEEP is not defined then the functions are defined as
> > > NULL. And as a result we are getting build failure with
> > > alpha allmodconfig with the error:
> > >
> > > drivers/gpu/drm/vc4/vc4_v3d.c: In function 'vc4_v3d_set_power':
> > > include/linux/stddef.h:7:14: error: called object is not a function or
> > > function pointer
> > > #define NULL ((void *)0)
> > > ^
> > > include/linux/pm.h:776:30: note: in expansion of macro 'NULL'
> > > #define pm_generic_poweroff NULL
> > > ^
> > > drivers/gpu/drm/vc4/vc4_v3d.c:157:10: note: in expansion of macro
> > > 'pm_generic_poweroff'
> > >return pm_generic_poweroff(>v3d->pdev->dev);
> > > ^
> > > include/linux/stddef.h:7:14: error: called object is not a function or
> > > function pointer
> > > #define NULL ((void *)0)
> > > ^
> > > include/linux/pm.h:764:28: note: in expansion of macro 'NULL'
> > > #define pm_generic_resume NULL
> > > ^
> > > drivers/gpu/drm/vc4/vc4_v3d.c:159:10: note: in expansion of macro
> > > 'pm_generic_resume'
> > >return pm_generic_resume(>v3d->pdev->dev);
> > > ^
> > >
> > > Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
> > > Cc: Eric Anholt
> > > Signed-off-by: Sudip Mukherjee
> >
> > I'm happy with this solution, and would also be willing to just depend
> > on the config option as well. Whatever people prefer.
>
> These functions are intended to be used as PM callbacks rather than to be
> called directly from code that doesn't depend on PM_SLEEP, so I'd prefer
> all code calling them directly to depend on the config option.
Apart from alpha some other arch also failed on allmodconfig for
next-20151216.
next-20151217 is now getting compiled on travis. If it still shows the
build failure I will send v2 with config options.
regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 00/10] perf tools: Support dynamic sort keys for tracepoints (v2)
Hi Arnaldo, On Wed, Dec 16, 2015 at 09:17:59PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Dec 16, 2015 at 12:35:33AM +0900, Namhyung Kim escreveu: > > Hello, > > > > This is an attempt to improve perf to deal with tracepoint events > > better. The perf tools can handle tracepoint events but perf report > > on them is less useful since they're always sampled in a fixed > > location and not provide event specific info. We can use perf script > > but I always wishes there's more convenient way to see the result. > > > > * changes in v2) > > - add 'trace' sort key and make it default (Jiri) > > - add '--raw-trace' option and '/raw' field modifier (Jiri) > > - support event name shortcuts (David) > > Can you take a look if you can reproduce this? Without callchains it works in > all tests I did. Argh, it was because I forgot to set raw_data/size field for --children case. I'll send the fix soon. Maybe we can disable --children for tracepoint sessions (or if it doesn't have symbol sort key)? Thanks, Namhyung > > [root@zoo ~]# perf record -g -e kmem:kmalloc -a > ^C[ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 1.193 MB perf.data (250 samples) ] > > [root@zoo ~]# perf report > perf: Segmentation fault > backtrace > perf[0x539f1b] > /lib64/libc.so.6(+0x34960)[0x7fc8e3752960] > perf(pevent_read_number+0x78)[0x542e40] > perf(pevent_read_number_field+0x70)[0x542ed3] > /root/.traceevent/plugins/plugin_kmem.so(+0x603)[0x7fc8e1a6c603] > perf(pevent_event_info+0x96)[0x547597] > perf[0x4dce26] > perf[0x4e0e89] > perf(hist_entry_iter__add+0xee)[0x4e125e] > perf[0x4304be] > perf[0x4c2db3] > perf[0x4c3301] > perf[0x4c6089] > perf(perf_session__process_events+0x3f1)[0x4c4b91] > perf(cmd_report+0x120b)[0x4319cb] > perf[0x47c871] > perf(main+0x63f)[0x42242f] > /lib64/libc.so.6(__libc_start_main+0xf0)[0x7fc8e373dfe0] > perf[0x422549] > [0x0] > [root@zoo ~]# ls -la ~/.traceevent/ > total 12 > drwxr-xr-x. 3 acme acme 4096 May 4 2015 . > drwx--. 61 acme acme 4096 Dec 16 21:12 .. > drwxr-xr-x. 2 acme acme 4096 Nov 23 11:15 plugins > [root@zoo ~]# ls -la ~/.traceevent > lrwxrwxrwx. 1 root root 23 May 4 2015 /root/.traceevent -> > /home/acme/.traceevent/ > [root@zoo ~]# perf record -e sched:sched_switch -a > > > ^C[ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 1.704 MB perf.data (4967 samples) ] > > [root@zoo ~]# perf report > [root@zoo ~]# perf record -g -e sched:sched_switch -a > ^C[ perf record: Woken up 2 times to write data ] > [ perf record: Captured and wrote 2.062 MB perf.data (4743 samples) ] > > [root@zoo ~]# perf report > perf: Segmentation fault > backtrace > perf[0x539f1b] > /lib64/libc.so.6(+0x34960)[0x7fecb3223960] > perf(pevent_read_number+0x60)[0x542e28] > perf(pevent_read_number_field+0x70)[0x542ed3] > perf(get_field_val+0x6b)[0x548cd5] > perf(pevent_get_field_val+0x6b)[0x548e77] > /root/.traceevent/plugins/plugin_sched_switch.so(+0x95b)[0x7fecb194195b] > perf(pevent_event_info+0x96)[0x547597] > perf[0x4dce26] > perf[0x4e0e89] > perf(hist_entry_iter__add+0xee)[0x4e125e] > perf[0x4304be] > perf[0x4c2db3] > perf[0x4c3301] > perf[0x4c5fdb] > perf[0x4c3535] > perf(perf_session__process_events+0x3a0)[0x4c4b40] > perf(cmd_report+0x120b)[0x4319cb] > perf[0x47c871] > perf(main+0x63f)[0x42242f] > /lib64/libc.so.6(__libc_start_main+0xf0)[0x7fecb320efe0] > perf[0x422549] > [0x0] > [root@zoo ~]# > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency
Hi Milan, On 16 December 2015 at 16:08, Milan Broz wrote: > On 12/16/2015 04:18 AM, Baolin Wang wrote: >> From the dm-crypt performance report, we found it shows low efficiency >> with crypto engine for some mode (like ecb or xts mode). Because in dm >> crypt, it will map the IO data buffer with scatterlist, and send the >> scatterlist of one bio to the encryption engine, if send more scatterlists >> with bigger size at one time, that helps the engine palys best performance, >> which means a high encryption speed. >> >> But now the dm-crypt only map one segment (always one sector) of one bio >> with one scatterlist to the crypto engine at one time. which is more >> time-consuming and ineffective for the crypto engine. Especially for some >> modes which don't need different IV for each sector, we can map the whole >> bio with multiple scatterlists to improve the engine performance. >> >> But this optimization is not support some ciphers and IV modes which should >> do sector by sector and need different IV for each sector. >> >> Change since v1: >> - Introduce one different IV mode. >> - Change the conditions for bulk mode. > > I tried the patchset on 32bit Intel VM and kernel immediately OOPsed (just > tried aes-ecb)... > I've checked the code and I guess some macros I used with different definitions on different arch. Could you please try the new patchset with some optimization on your platform? It can work well on my arm board. Thanks. -- Baolin.wang Best Regards -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/2] block: Introduce blk_bio_map_sg() to map one bio
In dm-crypt, it need to map one bio to scatterlist for improving the
encryption efficiency. Thus this patch introduces the blk_bio_map_sg()
function to map one bio with scatterlists.
Signed-off-by: Baolin Wang
---
block/blk-merge.c | 45 +
include/linux/blkdev.h |3 +++
2 files changed, 48 insertions(+)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index de5716d8..281b9e5 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -374,6 +374,51 @@ single_segment:
}
/*
+ * map a bio to scatterlist, return number of sg entries setup.
+ */
+int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg)
+{
+ struct bio_vec bvec, bvprv = { NULL };
+ struct bvec_iter iter;
+ int nsegs, cluster;
+
+ nsegs = 0;
+ cluster = blk_queue_cluster(q);
+
+ if (bio->bi_rw & REQ_DISCARD) {
+ /*
+* This is a hack - drivers should be neither modifying the
+* biovec, nor relying on bi_vcnt - but because of
+* blk_add_request_payload(), a discard bio may or may not have
+* a payload we need to set up here (thank you Christoph) and
+* bi_vcnt is really the only way of telling if we need to.
+*/
+
+ if (bio->bi_vcnt)
+ goto single_segment;
+
+ return 0;
+ }
+
+ if (bio->bi_rw & REQ_WRITE_SAME) {
+single_segment:
+ *sg = sglist;
+ bvec = bio_iovec(bio);
+ sg_set_page(*sg, bvec.bv_page, bvec.bv_len, bvec.bv_offset);
+ return 1;
+ }
+
+ bio_for_each_segment(bvec, bio, iter)
+ __blk_segment_map_sg(q, , sglist, , sg,
+, );
+
+ return nsegs;
+}
+EXPORT_SYMBOL(blk_bio_map_sg);
+
+/*
* map a request to scatterlist, return number of sg entries setup. Caller
* must make sure sg can hold rq->nr_phys_segments entries
*/
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 3fe27f8..3ca90ac 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1004,6 +1004,9 @@ extern void blk_queue_flush_queueable(struct
request_queue *q, bool queueable);
extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device
*bdev);
extern int blk_rq_map_sg(struct request_queue *, struct request *, struct
scatterlist *);
+extern int blk_bio_map_sg(struct request_queue *q, struct bio *bio,
+ struct scatterlist *sglist,
+ struct scatterlist **sg);
extern void blk_dump_rq_flags(struct request *, char *);
extern long nr_blockdev_pages(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/2] Introduce the bulk IV mode for improving the crypto engine efficiency
>From the dm-crypt performance report, we found it shows low efficiency with crypto engine for some mode (like ecb or xts mode). Because in dm crypt, it will map the IO data buffer with scatterlist, and send the scatterlist of one bio to the encryption engine, if send more scatterlists with bigger size at one time, that helps the engine palys best performance, which means a high encryption speed. But now the dm-crypt only map one segment (always one sector) of one bio with one scatterlist to the crypto engine at one time. which is more time-consuming and ineffective for the crypto engine. Especially for some modes which don't need different IV for each sector, we can map the whole bio with multiple scatterlists to improve the engine performance. But this optimization is not support some ciphers and IV modes which should do sector by sector and need different IV for each sector. Change since v2: - Introduce blk_bio_map_sg() function to map one bio. - Do some modifications for checking sg entry. Baolin Wang (2): block: Introduce blk_bio_map_sg() to map one bio md: dm-crypt: Introduce the bulk IV mode for bulk crypto block/blk-merge.c | 45 +++ drivers/md/dm-crypt.c | 333 +++- include/linux/blkdev.h |3 + 3 files changed, 375 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/2] md: dm-crypt: Introduce the bulk IV mode for bulk crypto
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV instead of different IV for each sector. In this situation We can consider
to use multiple scatterlists to map the whole bio and send all scatterlists
of one bio to crypto engine to encrypt or decrypt, which can improve the
hardware engine's efficiency.
With this optimization, On my test setup (beaglebone black board) using 64KB
I/Os on an eMMC storage device I saw about 60% improvement in throughput for
encrypted writes, and about 100% improvement for encrypted reads. But this
is not fit for other modes which need different IV for each sector.
Signed-off-by: Baolin Wang
---
drivers/md/dm-crypt.c | 333 -
1 file changed, 327 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 917d47e..003d2e9 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -32,6 +32,7 @@
#include
#define DM_MSG_PREFIX "crypt"
+#define DM_MAX_SG_LIST 1024
/*
* context holding the current state of a multi-part conversion
@@ -68,6 +69,8 @@ struct dm_crypt_request {
struct convert_context *ctx;
struct scatterlist sg_in;
struct scatterlist sg_out;
+ struct sg_table sgt_in;
+ struct sg_table sgt_out;
sector_t iv_sector;
};
@@ -140,6 +143,7 @@ struct crypt_config {
char *cipher;
char *cipher_string;
+ int bulk_crypto;
struct crypt_iv_operations *iv_gen_ops;
union {
struct iv_essiv_private essiv;
@@ -238,6 +242,9 @@ static struct crypto_ablkcipher *any_tfm(struct
crypt_config *cc)
*
* plumb: unimplemented, see:
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/454
+ *
+ * bulk: the initial vector is the 64-bit little-endian version of the sector
+ * number, which is used as just one initial IV for one bulk data.
*/
static int crypt_iv_plain_gen(struct crypt_config *cc, u8 *iv,
@@ -755,6 +762,15 @@ static int crypt_iv_tcw_post(struct crypt_config *cc, u8
*iv,
return r;
}
+static int crypt_iv_bulk_gen(struct crypt_config *cc, u8 *iv,
+struct dm_crypt_request *dmreq)
+{
+ memset(iv, 0, cc->iv_size);
+ *(__le64 *)iv = cpu_to_le64(dmreq->iv_sector);
+
+ return 0;
+}
+
static struct crypt_iv_operations crypt_iv_plain_ops = {
.generator = crypt_iv_plain_gen
};
@@ -799,6 +815,10 @@ static struct crypt_iv_operations crypt_iv_tcw_ops = {
.post = crypt_iv_tcw_post
};
+static struct crypt_iv_operations crypt_iv_bulk_ops = {
+ .generator = crypt_iv_bulk_gen
+};
+
static void crypt_convert_init(struct crypt_config *cc,
struct convert_context *ctx,
struct bio *bio_out, struct bio *bio_in,
@@ -833,6 +853,11 @@ static u8 *iv_of_dmreq(struct crypt_config *cc,
crypto_ablkcipher_alignmask(any_tfm(cc)) + 1);
}
+static int crypt_is_bulk_mode(struct crypt_config *cc)
+{
+ return cc->bulk_crypto;
+}
+
static int crypt_convert_block(struct crypt_config *cc,
struct convert_context *ctx,
struct ablkcipher_request *req)
@@ -881,24 +906,40 @@ static int crypt_convert_block(struct crypt_config *cc,
static void kcryptd_async_done(struct crypto_async_request *async_req,
int error);
+static void kcryptd_async_all_done(struct crypto_async_request *async_req,
+ int error);
static void crypt_alloc_req(struct crypt_config *cc,
struct convert_context *ctx)
{
unsigned key_index = ctx->cc_sector & (cc->tfms_count - 1);
+ struct dm_crypt_request *dmreq;
if (!ctx->req)
ctx->req = mempool_alloc(cc->req_pool, GFP_NOIO);
+ dmreq = dmreq_of_req(cc, ctx->req);
+ dmreq->sgt_in.orig_nents = 0;
+ dmreq->sgt_out.orig_nents = 0;
+
ablkcipher_request_set_tfm(ctx->req, cc->tfms[key_index]);
/*
* Use REQ_MAY_BACKLOG so a cipher driver internally backlogs
* requests if driver request queue is full.
*/
- ablkcipher_request_set_callback(ctx->req,
- CRYPTO_TFM_REQ_MAY_BACKLOG | CRYPTO_TFM_REQ_MAY_SLEEP,
- kcryptd_async_done, dmreq_of_req(cc, ctx->req));
+ if (crypt_is_bulk_mode(cc))
+ ablkcipher_request_set_callback(ctx->req,
+ CRYPTO_TFM_REQ_MAY_BACKLOG
+ | CRYPTO_TFM_REQ_MAY_SLEEP,
+ kcryptd_async_all_done,
+
Re: 4.4-rc5 Setting trap flag inside nmi handler results in HARD LOCKUP
On 12/16/15, Jeff Merkey wrote: > Setting the (trap flag | resume flag) inside of an nmi handler results > in a hard lockup while setting the resume flag works fine. > > The watchdog detector fails to detect the lockup. I am currently > examining the trap gate and interrupt gate setup on Linux and if > anyone has any ideas it would be nice to be able to debug and step > through the nmi handlers. I got breakpoints to work. I noticed > kgdb/kdb just punts here and refuses to allow someone to step inside > an nmi handler. > > There is no reason Linux should not allow this to work since windows > does and every other OS out there. I have seen this across some rex64 > sysret calls as well this lockup behavior. > > Anyone who is an intel expert with any clues would love some input if > you know about this problem. > > Jeff > This bug has been located. Results from returning from NMI interrupt with trap flag set in to a userspace address as Andy suspected but its not due to the RSP value being different as he suggested. This is a separate bug from the rex64 sysret bug. Results in the NMI handler switching IDT entries if an NMI fires off in a debug stack. Ironic since the code claims it is switching stacks to enable debugging of NMI handlers and does the opposite -- breaks them. Commenting out this code gets rid of the hard lockup. The user space process that gets the trap flag and doesn't expect a trap flag just hangs (but the just that process the rest of the system keeps running). So a few bugs to run down still. NMI handlers can now be debugged -- kindof. This bug is closed and I will issue a patch for it. It's a condition where a trap flag is set inside an nmi handler that exits to a userspace address. The code for setting and clearing the trap in kernel all worked correctly for the userspace path, except it put the process to sleep when it shouldn't have. It's not a condition that can happen during normal operations unless you set the trap flag from a debugger inside an NMI handler and try to debug it then exit the handler into userspace, so I think the probability of this showing up outside a debugging session is low. I verified that kgdb/kdb also experiences this bug (If I comment out the code blocking folks from debugging NMI handlers with kgdb/kdb). Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PELT initial task load and wake_up_new_task()
Hi Steve,
On Wed, Dec 16, 2015 at 06:50:43PM -0800, Steve Muckle wrote:
> On 12/15/2015 03:55 PM, Yuyang Du wrote:
> > Hope the following patch should work.
>
> Thanks Yuyang. AFAICS it should work, though I believe the test on
> last_update_time could instead go at the top of migrate_task_rq_fair()?
> It'd save the fn call to remove_entity_load_avg() and two unnecessary
> assignments (as p->se.avg.last_update_time and p->se.exec_start = 0 for
> newly forked tasks). This worked for me.
In a hindsight yesterday, this also occurred to me. But I think the fix is
also applicable to a group entity that is being removed but never used. And
such cases are not unlikely to happen.
To make the code less duplicate, I still do this in remove_entity_load_avg().
Make sense?
Sorry about the compile error.
---
Subject: [PATCH] sched: Fix new task's load avg removed from source CPU in
wake_up_new_task()
If a newly created task is selected to go to a different CPU in fork
balance when it wakes up the first time, its load averages should
not be removed from the source CPU since they are never added to
it before. The same is also applicable to a never used group entity.
Fix it in remove_entity_load_avg(): when entity's last_update_time
is 0, simply return. This should precisely identify the case in
question, because in other migrations, the last_update_time is set
to 0 after remove_entity_load_avg().
Reported-by: Steve Muckle
Signed-off-by: Yuyang Du
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e3266eb..3f6a8b3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2908,10 +2908,18 @@ void remove_entity_load_avg(struct sched_entity *se)
{
struct cfs_rq *cfs_rq = cfs_rq_of(se);
u64 last_update_time;
-
#ifndef CONFIG_64BIT
u64 last_update_time_copy;
+#endif
+ /*
+* Newly created task or never used group entity should not be removed
+* from its (source) cfs_rq
+*/
+ if (se->avg.last_update_time == 0)
+ return;
+
+#ifndef CONFIG_64BIT
do {
last_update_time_copy = cfs_rq->load_last_update_time_copy;
smp_rmb();
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] lpfc: Add lockdep assertions
On 11/20/2015 01:37 PM, Johannes Thumshirn wrote:
Several functions in lpfc have comments stating that the function must be
called with the hbalock (or hostlock, or ringlock) held. Add
lockdep_assert_held() annotations to these functions, so one can actually
verify the locks are held.
[ ... ]
@@ -2647,6 +2675,7 @@ lpfc_sli_iocbq_lookup(struct lpfc_hba *phba,
{
struct lpfc_iocbq *cmd_iocb = NULL;
uint16_t iotag;
+ lockdep_assert_held(>hbalock);
iotag = prspiocb->iocb.ulpIoTag;
(replying to an e-mail of one month ago)
Please leave a blank line after declarations. Checkpatch should have
reported this. Anyway:
Reviewed-by: Bart Van Assche
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Review & Reply
Greetings, My name is Mr.Michael J. Tynan, I am a banker with Bank Of America. It is true that we have not meet each other in person, but I strongly believe in trust and friendship in every business. I have a Lebanese deceased customer's abandoned fund, which I am his personal financial adviser before his accidental death, that being the main reason why I alone working in the bank here, know much about the existence of this fund and the secrets surrounding this money. But before I disclose the full details to you, I will like to know your interest and willingness to assist me. You can call me as soon you receive my message, so that i will send to you full details about the transaction. My best regards, Mr.Michael J. Tynan MOBILE: +1 347 269 3740 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv6 PATCH 03/10] sched: scheduler-driven cpu frequency selection
Hi Steve, On Wed, Dec 16, 2015 at 05:24:56PM -0800, Steve Muckle wrote: > Hi Leo, > > On 12/15/2015 07:48 PM, Leo Yan wrote: > > I also think "set_current_state(TASK_INTERRUPTIBLE)" will introduce > > logic error when software flow run into "else" block. The reason is > > after you set state with TASK_INTERRUPTIBLE, if there have some > > scheduling happen within cpufreq_sched_try_driver_target(), then the > > thread will be remove from rq. But generally we suppose the thread > > will be on rq and can continue run after next tick. > > > > Juri's suggestion can fix this issue. And we can use atomic_t to > > safely accessing gd->requested_freq. > > I agree, it's incorrect. As I replied earlier I believe setting the task > state back to TASK_RUNNING at the top of the else block is the easiest fix. Could you check if below corner case will introduce logic error? The task still will be removed from rq if timer tick is triggered between two time's set_current_state(). set_current_state(TASK_INTERRUPTIBLE); `---> timer_tick and schedule(); do_something... set_current_state(TASK_RUNNING); It will be safe for combination for set_current_state()/schedule() with waken_up_process(): Thread_A: Thread_B: set_current_state(TASK_INTERRUPTIBLE); `---> timer_tick and schedule(); wake_up_process(Thread_A); <-/ schedule(); The first time's schedule() will remove task from rq which is caused by timer tick and call schedule(), and the second time schdule() will be equal yeild(). Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Skein: Moved macros from skein_block.c to header file.
On Mon, Dec 14, 2015 at 07:08:08PM -0500, Sanidhya Solanki wrote: > The original code defined macros in the source code, making it > harder to read. Moved them to the header file, as per the TODO file. > > Updated the TODO file. I think the TODO file should not be updated now. There are still some macros in skein_block.c. regards sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] Rework tty_reopen()
On Wed, Dec 16, 2015 at 07:43:11AM -0800, Peter Hurley wrote: > Hi Greg, > > This series has been reported to fix a regression with Redhat's kdump > systemd service redirecting to /dev/console, when /dev/console is a > serial port. > > The redirection consistently fails with EIO since > "tty: Remove tty_wait_until_sent_from_close", which is new to 4.4-rc > Prior to that patch, redirection would only occasionally fail with EIO. :) > > [ The systemd repeated hangup of /dev/console also seems to be the > [ trigger for the serial driver crashes on hangup as well, which is > [ fixed by the 19-patch "Fix driver crashes on hangup" series. > [ That problem goes back to 3.10, but has only been reported recently, > [ which leads me to believe recent changes in systemd /dev/console > [ handling is a contributing factor (which I'm checking right now) > > Here are what I think are the options to resolve the regression: > > #1. Respin this series w/o the tty-next dependencies > #2. Split this series into the minimum necessary to fix the regression > #3. Revert from 4.4-rc (in revert order) > "tty: Remove wait_event_interruptible_tty()" > "tty: r3964: Replace/remove bogus tty lock use" > "tty: r3964: Use tty->read_wait waitqueue" > "tty: Remove tty_port::close_wait" > "usb: gadget: gserial: Privatize close_wait" > "tty: Remove ASYNC_CLOSING check in open()/hangup() methods" > "tty: Remove tty_wait_until_sent_from_close()" > > Let me know how you'd like me to handle this. Sounds like a reasonable approach, send the patches on and let's see what they look like. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] bpf samples: Uses libbpf in tools/lib to do BPF operations
On 12/17/2015 07:51 AM, Wangnan (F) wrote: > On 2015/12/17 14:38, Daniel Wagner wrote: >> On 12/17/2015 06:23 AM, Wang Nan wrote: >>> Since we already have libbpf in tools/lib, we don't need to maintain >>> another bpf loader and operations library in samples/bpf. >>> >>> In patchset: >>> >>> Patch 1/10 - 7/10 improves libbpf, add missing features to support >>> samples, >>> >>> Patch 8/10 adds utils.[ch], which creates similar API like old >>> bpf_load.c and libbpf.c. >>> >>> Patch 9/10 replace all sampels to use API provides by utils.[ch] and >>> libbpf. >>> >>> Patch 10/10 removes unneeded files. >> Which tree did you use for your patches? I tried to apply them against >> mainline and net-next which didn't really work out. > > These patches based on Arnaldo's 'perf/core' because of those libbpf > changes. Okay, I'll try with this one. > Which tree is the right one for this? net-next? The patches I was involved were routed via net-next but I don't know if that is the right tree for this patch set. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Dec 17
Hi all, Changes since 20151216: News: The arm defconfig build is broken during the configrations stage. The arm-soc tree gained a build failure for the arm defconfig build. I left it broken for today. The i2c tree still had its build failure for which I applied a patch. The regulator tree gained a conflict against the qcom tree. The clockevents tree gained a conflict against the h8300 tree and a build failure so I used the version from next-20151216. The gpio tree still had its build failure so I used the version from next-20151215. The rtc tree gained a build failure so I used the version from next-20151216. The akpm-current tree gained a conflict against the net-next tree. Non-merge commits (relative to Linus' tree): 6050 6483 files changed, 238800 insertions(+), 103832 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 231 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (a5e90b1b075f Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (5f82677f72cb ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing) Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (2475c362134a Partial revert of "powerpc: Individual System V IPC system calls") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (2c302e7e4105 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging net/master (c6ff5268293e rhashtable: Fix walker list corruption) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (eeec5d0ef7ee rtlwifi: rtl8821ae: Fix lockups on boot) Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from opmode notification IE in beacon) Merging sound-current/for-linus (b6903c0ed9f0 ALSA: hda - Add a fixup for Thinkpad X1 Carbon 2nd) Merging pci-current/for-linus (5bd242f824e2 Revert "PCI: hisi: Add HiSilicon SoC Hip05 PCIe driver") Merging driver-core.current/driver-core-linus (31ade3b83e18 Linux 4.4-rc3) Merging tty.current/tty-linus (9ce119f318ba tty: Fix GPF in flush_to_ldisc()) Merging usb.current/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (9f9499ae8e64 Linux 4.4-rc5) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL dereference) Merging staging.current/staging-linus (9f9499ae8e64 Linux 4.4-rc5) Merging char-misc.current/char-misc-linus (9f9499ae8e64 Linux 4.4-rc5) Merging input-current/for-linus (3eab4588c958 Input: elan_i2c - set input device's vendor and product IDs) Merging crypto-current/master (70d906bc1750 crypto:
Re: [PATCH 00/10] bpf samples: Uses libbpf in tools/lib to do BPF operations
On 2015/12/17 14:38, Daniel Wagner wrote: Hi, On 12/17/2015 06:23 AM, Wang Nan wrote: Since we already have libbpf in tools/lib, we don't need to maintain another bpf loader and operations library in samples/bpf. In patchset: Patch 1/10 - 7/10 improves libbpf, add missing features to support samples, Patch 8/10 adds utils.[ch], which creates similar API like old bpf_load.c and libbpf.c. Patch 9/10 replace all sampels to use API provides by utils.[ch] and libbpf. Patch 10/10 removes unneeded files. Which tree did you use for your patches? I tried to apply them against mainline and net-next which didn't really work out. These patches based on Arnaldo's 'perf/core' because of those libbpf changes. Which tree is the right one for this? net-next? Thank you. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ftrace: fix race between ftrace and insmod
On 2015/12/16 22:28, Steven Rostedt wrote:
> On Wed, 16 Dec 2015 18:28:35 +0800
> "Zhang, Yanmin" wrote:
>
>>> + /*
>>> +* If the tracing is enabled, go ahead and enable the record.
>>> +*
>>> +* The reason not to enable the record immediatelly is the
>>> +* inherent check of ftrace_make_nop/ftrace_make_call for
>>> +* correct previous instructions. Making first the NOP
>>> +* conversion puts the module to the correct state, thus
>>> +* passing the ftrace_make_call check.
>>> +*
>>> +* We also delay this to after the module code already set the
>>> +* text to read-only, as we now need to set it back to read-write
>>> +* so that we can modify the text.
>>> +*/
>>> + if (ftrace_start_up)
>>> + ftrace_arch_code_modify_prepare();
>>> +
>>> + do_for_each_ftrace_rec(pg, rec) {
>>> + int cnt;
>>> + /*
>>> +* do_for_each_ftrace_rec() is a double loop.
>>> +* module text shares the pg. If a record is
>>> +* not part of this module, then skip this pg,
>>> +* which the "break" will do.
>>> +*/
>>> + if (!within_module_core(rec->ip, mod))
>>> + break;
>>> +
>>> + cnt = 0;
>>> +
>>> + /*
>>> +* When adding a module, we need to check if tracers are
>>> +* currently enabled and if they are, and can trace this record,
>>> +* we need to enable the module functions as well as update the
>>> +* reference counts for those function records.
>>> +*/
>>> + if (ftrace_start_up)
>>> + cnt += referenced_filters(rec);
>>> +
>>> + /* This clears FTRACE_FL_DISABLED */
>>> + rec->flags = cnt;
>>> +
>>> + if (ftrace_start_up && cnt) {
>>> + int failed = __ftrace_replace_code(rec, 1);
>> If we choose to call ftrace_module_enable when receiving module notification
>> MODULE_STATE_COMING, TEXT section of the module is already changed to RO.
> And that's why we call ftrace_arch_code_modify_prepare(). That should
> change all text to RW.
Thanks for the kind pointer.
We would add codes into your patch based on notifier and send patch to you by
private email.
Yanmin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the arm-soc tree
Hi all, After merging the arm-soc tree, today's linux-next build (arm defconfig) failed like this: *** Default configuration is based on 'versatile_defconfig' # # configuration written to .config # make[1]: Leaving directory '/home/sfr/next/arm_defconfig' .config:2033:warning: symbol value '' invalid for DEBUG_UART_PHYS .config:2034:warning: symbol value '' invalid for DEBUG_UART_VIRT * * Restart config... * . . . Kernel low-level debugging functions (read help!) (DEBUG_LL) [Y/n/?] y Kernel low-level debugging port 1. Kernel low-level debugging messages via ARM Versatile UART (DEBUG_VERSATILE) 2. Kernel low-level debugging via EmbeddedICE DCC channel (DEBUG_ICEDCC) 3. Kernel low-level debug output via semihosting I/O (DEBUG_SEMIHOSTING) 4. Kernel low-level debugging via 8250 UART (DEBUG_LL_UART_8250) > 5. Kernel low-level debugging via ARM Ltd PL01x Primecell UART (DEBUG_LL_UART_PL01X) choice[1-5]: 5 Physical base address of debug UART (DEBUG_UART_PHYS) [] (NEW) aborted! Console input/output is redirected. Run 'make oldconfig' to update configuration. Presumably caused by the changes to arch/arm/Kconfig.debug in today's arm-soc tree. I left it broken for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] bpf samples: Uses libbpf in tools/lib to do BPF operations
Hi, On 12/17/2015 06:23 AM, Wang Nan wrote: > Since we already have libbpf in tools/lib, we don't need to maintain > another bpf loader and operations library in samples/bpf. > > In patchset: > > Patch 1/10 - 7/10 improves libbpf, add missing features to support > samples, > > Patch 8/10 adds utils.[ch], which creates similar API like old > bpf_load.c and libbpf.c. > > Patch 9/10 replace all sampels to use API provides by utils.[ch] and > libbpf. > > Patch 10/10 removes unneeded files. Which tree did you use for your patches? I tried to apply them against mainline and net-next which didn't really work out. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 06/10] bpf tools: Support new map operations
Add bpf_map_lookup_elem(), bpf_map_delete_elem() and bpf_map_get_next_key()
to libbpf so it can issue all BPF map operations.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
v1 -> v2: Remove tailing whitespaces.
---
tools/lib/bpf/bpf.c | 32
tools/lib/bpf/bpf.h | 4
2 files changed, 36 insertions(+)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index e0dccea..b8e7aaa 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -97,3 +97,35 @@ int bpf_map_update_elem(int fd, void *key, void *value,
return sys_bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));
}
+
+int bpf_map_lookup_elem(int fd, void *key, void *value)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ };
+
+ return sys_bpf(BPF_MAP_LOOKUP_ELEM, , sizeof(attr));
+}
+
+int bpf_map_delete_elem(int fd, void *key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ };
+
+ return sys_bpf(BPF_MAP_DELETE_ELEM, , sizeof(attr));
+}
+
+int bpf_map_get_next_key(int fd, void *key, void *next_key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .next_key = ptr_to_u64(next_key),
+ };
+
+ return sys_bpf(BPF_MAP_GET_NEXT_KEY, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 01a421a..3d22048 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -23,4 +23,8 @@ int bpf_load_program(enum bpf_prog_type type, const struct
bpf_insn *insns,
int bpf_map_update_elem(int fd, void *key, void *value,
__u64 flags);
+
+int bpf_map_lookup_elem(int fd, void *key, void *value);
+int bpf_map_delete_elem(int fd, void *key);
+int bpf_map_get_next_key(int fd, void *key, void *next_key);
#endif
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/10] bpf tools: Support new map operations
[SNIP]
+int bpf_map_lookup_elem(int fd, void *key, void *value)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ };
Tailing whitespace here. Sorry...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v4 2/3] tools: Move Makefile.arch from perf/config to tools/scripts
On 2015/12/17 13:10, Naveen N. Rao wrote: On 2015/12/17 01:43AM, Wang Nan wrote: After this patch other directories can use this architecture detector without directly including it from perf's directory. Libbpf would utilize it to get proper $(ARCH) so it can receive correct uapi include directory. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Tested-by: Naveen N. Rao Cc: Arnaldo Carvalho de Melo Cc: Naveen N. Rao Cc: Sukadev Bhattiprolu --- tools/perf/config/Makefile | 2 +- tools/perf/config/Makefile.arch | 18 -- tools/perf/tests/make | 2 +- tools/scripts/Makefile.arch | 18 ++ 4 files changed, 20 insertions(+), 20 deletions(-) delete mode 100644 tools/perf/config/Makefile.arch create mode 100644 tools/scripts/Makefile.arch ^^ This is different from your previous version. This should be a file rename. Forget to use git format -M. The content is identical. Should I send it again? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/12] Rework tty_reopen()
On 16/12/2015:07:43:11 AM, Peter Hurley wrote: > #1. Respin this series w/o the tty-next dependencies > #2. Split this series into the minimum necessary to fix the regression As far as kdump issue is concerned, backporting only 12/12 to 4.4-RC is able to resolve it. ~Pratyush -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/8] [Media] vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
On Wed, 2015-12-16 at 14:47 +0100, Hans Verkuil wrote:
> On 12/16/15 14:17, tiffany lin wrote:
> > Hi Hans,
> >
> >
> > On Tue, 2015-12-15 at 15:17 +0100, Hans Verkuil wrote:
> >>
> >> On 12/15/15 14:51, tiffany lin wrote:
> >>> We are not familiar with v4l2-compliance utility, we will check how to
> >>> use it.
> >>
> >> It's part of v4l-utils.git (http://git.linuxtv.org/v4l-utils.git/). There
> >> is a
> >> fairly decent man page. It does exhaustive compliance tests for V4L2
> >> devices.
> >>
> >> That said, the support for memory-to-memory codec devices is not great, so
> >> I wouldn't
> >> trust any failures it reports when using the streaming tests (i.e. the
> >> --stream*
> >> options). By default just run 'v4l2-compliance -d /dev/videoX' to do the
> >> compliance
> >> test.
> >>
> >> Note: before I accept this driver I do want to see that compliance test
> >> output!
> >>
> > Got it. We will provide it in next version.
> > Now our driver is developed and run base on kernel v3.18.
> > V4L2 and vb2 have some difference between Linux 4.4-rc1 and 3.18 kernel.
> > Is it ok we provided test output base on v3.18 or we need to base on
> > 4.4-rc1?
>
> I'm actually not sure if the latest v4l2-compliance test suite will work with
> a 3.18
> kernel. so either you have to go back to an older version of v4l2-compliance
> that
> works with 3.18 (go back to commit 4a57509a8334aca6ca8e81cd3beb08d5be397dac,
> that
> might do the trick) or (and that's what I recommend) go with the latest
> kernel.
>
> For the media tree that is http://git.linuxtv.org/media_tree.git/log/.
>
> The final version of the patch has to be against that kernel anyway.
>
Got it. Thanks for your help, we will try it. ^_^
> > +}
> > +
> > +int m2mctx_venc_queue_init(void *priv, struct vb2_queue *src_vq,
> > + struct vb2_queue *dst_vq)
> > +{
> > + struct mtk_vcodec_ctx *ctx = priv;
> > + int ret;
> > +
> > + src_vq->type= V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> > + src_vq->io_modes= VB2_DMABUF | VB2_MMAP | VB2_USERPTR;
>
> You're using videobuf2-dma-contig, so VB2_USERPTR is generally useless
> in that
> case. I would drop it.
>
> >>> Sorry, I don't get it.
> >>> We are using videobuf2-dma-contig, but we also using VB2_USERPTR.
> >>
> >> In that case the user pointer you pass in must point to physically
> >> contiguous
> >> memory. Which means you got it through some magic. Typically what should
> >> be used
> >> are dmabuf handles to pass buffers around between different subsystems.
> >>
> >> The use of VB2_USERPTR for that purpose is deprecated.
> >>
> >> Or am I misunderstanding you as well?
> >>
> > Our encoder support all three modes.
> > In case that A driver + Encode driver flow, OUTPUT buffer will be
> > VB2_DMABUF from A driver.
> > In case that read YCbCr frame data from file and encode them to bit
> > stream flow, we use VB2_USERPTR and VB2_MMAP.
> > In VB2_USERPTR case, videobuf2-dma-contig will help us get continuous
> > dma address.
> > Our chip has IOMMU and M4U that help us get continuous phy address for
> > encode HW.
> >
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-October/002525.html
>
> Ah, OK. Have you tested this with malloc()ed buffers? Just asking :-)
>
Yes. Actually we tested this with new()ed buffers. I think it default
call malloc.
> Regards,
>
> Hans
best regards,
Tiffany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] powercap, intel_rapl, implement get_max_time_window
On 2015-12-15 22:02, Prarit Bhargava wrote:
> The MSR_PKG_POWER_INFO register (Intel ASDM, section 14.9.3
> "Package RAPL Domain") provides a maximum time window which the
> system can support. This window is read-only and is currently
> not examined when setting the time windows for the package.
I have been having a question here long time.
Maximum Time Window (bits 53:48) in MSR_PKG_POWER_INFO is only
6-bit length even though Time Window for Power Limit #1 (bits 23:17)
and Time Window for Power Limit #2 (bits 55:49) in MSR_PKG_POWER_LIMIT
are both 7-bit length, not 6.
Do Intel guys have an answer for it?
The patch itself looks good to me.
Just minor comments below:
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index cc97f08..f765b2c 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -493,13 +493,42 @@ static int get_current_power_limit(struct powercap_zone
> *power_zone, int id,
> return ret;
> }
>
> +static int get_max_time_window(struct powercap_zone *power_zone, int id,
The 2nd arg "id" is not necessary.
> +u64 *data)
> +{
> + struct rapl_domain *rd;
> + int ret = 0;
> + u64 val;
> +
> + get_online_cpus();
> + rd = power_zone_to_rapl_domain(power_zone);
> +
> + if (rapl_read_data_raw(rd, MAX_TIME_WINDOW, true, ))
rapl_read_data_raw() can return -EINVAL and -ENODEV other than -EIO.
> + ret = -EIO;
Is it OK to limit ret to -EIO here?
> + else
> + *data = val;
> +
> + put_online_cpus();
> + return ret;
> +}
> +
> static int set_time_window(struct powercap_zone *power_zone, int id,
> u64 window)
> {
> struct rapl_domain *rd;
> int ret = 0;
> + u64 max_window;
>
> get_online_cpus();
> + ret = get_max_time_window(power_zone, id, _window);
> + if (ret < 0)
> + goto out;
> +
> + if (window > max_window) {
> + ret = -EINVAL;
> + goto out;
> + }
> +
> rd = power_zone_to_rapl_domain(power_zone);
> switch (rd->rpl[id].prim_id) {
> case PL1_ENABLE:
> @@ -511,6 +540,7 @@ static int set_time_window(struct powercap_zone
> *power_zone, int id,
> default:
> ret = -EINVAL;
> }
> +out:
> put_online_cpus();
> return ret;
> }
> @@ -590,6 +620,7 @@ static struct powercap_zone_constraint_ops constraint_ops
> = {
> .set_time_window_us = set_time_window,
> .get_time_window_us = get_time_window,
> .get_max_power_uw = get_max_power,
> + .get_max_time_window_us = get_max_time_window,
> .get_name = get_constraint_name,
> };
>
> diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c
> index 84419af..7d77b83 100644
> --- a/drivers/powercap/powercap_sys.c
> +++ b/drivers/powercap/powercap_sys.c
> @@ -101,7 +101,7 @@ static ssize_t store_constraint_##_attr(struct device
> *dev,\
> int err; \
> u64 value; \
> struct powercap_zone *power_zone = to_powercap_zone(dev); \
> - int id; \
> + int id, ret; \
> struct powercap_zone_constraint *pconst;\
> \
> if (!sscanf(dev_attr->attr.name, "constraint_%d_", )) \
> @@ -113,8 +113,10 @@ static ssize_t store_constraint_##_attr(struct device
> *dev,\
> if (err) \
> return -EINVAL; \
> if (pconst && pconst->ops && pconst->ops->set_##_attr) { \
> - if (!pconst->ops->set_##_attr(power_zone, id, value)) \
> + ret = pconst->ops->set_##_attr(power_zone, id, value); \
> + if (!ret) \
> return count; \
> + return ret; \
An opposite question to above.
Is it OK not to limit the return value to -EINVAL here?
Do you want this function to return -EIO or something?
> } \
> \
> return -ENODATA; \
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
4.4-rc4 crash net/80211 related
Hi, Triggered this with rc4, but the relevant parts are same in rc5: offending line is : (gdb) list *(ieee80211_scan_rx+0x158) 0xf68 is in ieee80211_scan_rx (net/mac80211/scan.c:205). 200 if (!(sdata1 && 201 (ether_addr_equal(mgmt->da, sdata1->vif.addr) || 202scan_req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR)) && 203 !(sdata2 && 204 (ether_addr_equal(mgmt->da, sdata2->vif.addr) || 205sched_scan_req->flags & NL80211_SCAN_FLAG_RANDOM_ADDR))) 206 return; 207 208 elements = mgmt->u.probe_resp.variable; 209 baselen = offsetof(struct ieee80211_mgmt, u.probe_resp.variable); (gdb) i.e. sched_scan_req->flags which means sched_scan_req is NULL. It is not easy to trigger (have been running for days) so its not easy to say if it's triggering with rc5. relevant hw info : i.mx6 + ti wl1835 wlan -- [471559.635143] Unable to handle kernel NULL pointer dereference at virtual address 0018 Internal error: Oops: 17 [#1] PREEMPT SMP ARM CPU: 1 PID: 24194 Comm: kworker/u8:1 Tainted: GW 4.4.0-rc4 #1 [a4c7e1(505x9a.76e9f0872] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) S[u4r7f1a559.717313] PC is at ieee80211_scan_rx+0x158/0x168 LR is at 0x2f04a578 ce(0xa7efe8) [471559.729744] pc : [<806a0bb0>]lr : [<2f04a578>]psr: a0030113 [471559.729744] sp : a8aa7da0 ip : 0066 fp : a800ac00 [471559.742599] r10: a89e6a00 r9 : r8 : [471559.747913] r7 : a8b00440 r6 : a87764c0 r5 : 647b r4 : a8b00440 [471559.754529] r3 : d0fbdb87 r2 : 9b84 r1 : a8cc76c0 r0 : a84d43e0 [471559.761146] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [471559.768544] Control: 10c5387d Table: 1b48804a DAC: 0055 [471559.774379] Process kworker/u8:1 (pid: 24194, stack limit = 0xa8aa6210) [471559.781081] Stack: (0xa8aa7da0 to 0xa8aa8000) [471559.785531] 7da0: 0006f631 afb50401 ab712080 a8aa7dfc 806dc340 ab712080 80042018 [471559.793799] 7dc0: 8a14a000 0002 8003e980 a82d5f48 a82d5f50 a82d5f48 800500d4 [471559.802066] 7de0: 5129e9f0 0001ace1 0001 a8aa7e3c 806d870c [471559.810334] 7e00: a8aa7e1c 800455e4 9c119808 ab7120c0 625e a82d5f00 [471559.818601] 7e20: ab7120c0 a82d5f48 80b6170c 0002 0001 ab712080 80053738 [471559.826868] 7e40: 9c119808 ab7120c0 1259 1259 0001 a84d43e0 [471559.835136] 7e60: 0050 a8cc76c0 a8b00440 806b6ee8 80b5c080 80b5c080 [471559.843403] 7e80: 0004 02953182 a8cc76c0 a84d43e0 [471559.851670] 7ea0: 0010 0010 a800ac00 a84d4c40 [471559.859938] 7ec0: a8cc76c0 a84d43e0 a84d4e00 803b37a4 a89e6a00 a800ac00 803b37c0 [471559.868205] 7ee0: a84d4ecc a84d4c40 a800ac00 a83c2f00 803b383c a89e6a00 a84d4ecc [471559.876473] 7f00: a800ac00 800388ac a800ac14 a800ac14 0001 a800ac00 a89e6a18 a800ac14 [471559.884740] 7f20: a8aa6000 0088 80b9a73b a89e6a00 a800ac00 80038b1c 80b60100 a800ad64 [471559.893007] 7f40: 80038ad0 a8a96f40 a89e6a00 80038ad0 [471559.901274] 7f60: 8003dd78 fff5 a89e6a00 [471559.909542] 7f80: a8aa7f80 a8aa7f80 a8aa7f90 a8aa7f90 a8aa7fac a8a96f40 [471559.917809] 7fa0: 8003dc90 8000f5a8 [471559.926076] 7fc0: [471559.934343] 7fe0: 0013 [471559.942623] [<806a0bb0>] (ieee80211_scan_rx) from [<806b6ee8>] (ieee80211_rx_napi+0x680/0x7a0) [471559.951330] [<806b6ee8>] (ieee80211_rx_napi) from [<803b37c0>] (wl1271_flush_deferred_work+0x30/0x98) [471559.960643] [<803b37c0>] (wl1271_flush_deferred_work) from [<803b383c>] (wl1271_netstack_work+0x14/0x24) [471559.970216] [<803b383c>] (wl1271_netstack_work) from [<800388ac>] (process_one_work+0x120/0x344) [471559.979093] [<800388ac>] (process_one_work) from [<80038b1c>] (worker_thread+0x4c/0x490) [471559.987279] [<80038b1c>] (worker_thread) from [<8003dd78>] (kthread+0xe8/0x104) [471559.994686] [<8003dd78>] (kthread) from [<8000f5a8>] (ret_from_fork+0x14/0x2c) [471560.002000] Code: e0222005 e023300e e1923003 0ac0 (e5993018) [471560.008219] ---[ end trace eb084eff56d23079 ]--- [471560.012947] Kernel panic - not syncing: Fatal exception in interrupt [471560.012954] CPU0: stopping [471560.012962] CPU: 0 PID: 24339 Comm: compositor Tainted: G D W 4.4.0-rc4 #1 [471560.012965] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [471560.012988] [<80016be4>] (unwind_backtrace) from
Re: + arc-convert-to-dma_map_ops.patch added to -mm tree
On Thu, 17 Dec 2015 10:58:55 +0530 Vineet Gupta wrote: > On Tuesday 24 November 2015 01:20 PM, h...@lst.de wrote: > > Hi Vineet, > > > > the original version went through the buildbot, which succeeded. It seems > > like the official buildbot does not support arc, and might benefit from > > helping to set up an arc environment. However in the meantime Guenther > > send me output from his buildbot and I sent a fix for arc. > > > > Hi Andrew, Christoph > > The dma mapping conversion build error fixlet (below) exists as a separate > patch > which will break bisectability. Will it be possible to squash it into the > orig commit. > That's the plan. In http://ozlabs.org/~akpm/mmots/series you'll see arc-convert-to-dma_map_ops.patch arc-convert-to-dma_map_ops-fix.patch I keep the base patch(es) and its fixes separate for various tacking/history/bookkeeping reasons and fold them all together just before sending things off to Linus. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the akpm-current tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/net/sock.h
net/ipv4/tcp_ipv4.c
between commit:
64be0aed59ad ("net: diag: Add the ability to destroy a socket.")
from the net-next tree and commit:
0e2cde9cf7b6 ("net: tcp_memcontrol: simplify linkage between socket and page
counter")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/net/sock.h
index f772b8245cae,edd552ef8e38..
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -309,8 -292,8 +293,8 @@@ struct cg_proto
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
* @sk_mark: generic packet mark
- * @sk_classid: this socket's cgroup classid
+ * @sk_cgrp_data: cgroup data for this cgroup
- * @sk_cgrp: this socket's cgroup-specific proto data
+ * @sk_memcg: this socket's memory cgroup association
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
@@@ -444,8 -428,11 +428,8 @@@ struct sock
#ifdef CONFIG_SECURITY
void*sk_security;
#endif
- __u32 sk_mark;
-#ifdef CONFIG_CGROUP_NET_CLASSID
- u32 sk_classid;
-#endif
+ struct sock_cgroup_data sk_cgrp_data;
- struct cg_proto *sk_cgrp;
+ struct mem_cgroup *sk_memcg;
void(*sk_state_change)(struct sock *sk);
void(*sk_data_ready)(struct sock *sk);
void(*sk_write_space)(struct sock *sk);
@@@ -1051,19 -1036,6 +1035,7 @@@ struct proto
#ifdef SOCK_REFCNT_DEBUG
atomic_tsocks;
#endif
- #ifdef CONFIG_MEMCG_KMEM
- /*
-* cgroup specific init/deinit functions. Called once for all
-* protocols that implement it, from cgroups populate function.
-* This function has to setup any files the protocol want to
-* appear in the kmem cgroup filesystem.
-*/
- int (*init_cgroup)(struct mem_cgroup *memcg,
- struct cgroup_subsys *ss);
- void(*destroy_cgroup)(struct mem_cgroup *memcg);
- struct cg_proto *(*proto_cgroup)(struct mem_cgroup *memcg);
- #endif
+ int (*diag_destroy)(struct sock *sk, int err);
};
int proto_register(struct proto *prot, int alloc_slab);
diff --cc net/ipv4/tcp_ipv4.c
index 205e6745393f,34c26782e114..
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@@ -2336,12 -2339,6 +2338,7 @@@ struct proto tcp_prot =
.compat_setsockopt = compat_tcp_setsockopt,
.compat_getsockopt = compat_tcp_getsockopt,
#endif
- #ifdef CONFIG_MEMCG_KMEM
- .init_cgroup= tcp_init_cgroup,
- .destroy_cgroup = tcp_destroy_cgroup,
- .proto_cgroup = tcp_proto_cgroup,
- #endif
+ .diag_destroy = tcp_abort,
};
EXPORT_SYMBOL(tcp_prot);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/9] samsung: pmu: split up SoC specific PMU data
On 17.11.2015 15:05, Pankaj Dubey wrote: > In this series I am splitting up SoC specific PMU configuration data into > mach-exynos folder itself, before moving all of them under > drivers/soc/samsung/. Also instead of making all changes in single patch it > has been broken into SoC specific patches to avoid large size of patch. > With this approach there will not be unwanted big churns just after > adding exynos-pmu under drivers/soc/samsung. > > All these patches are just refactoring to keep minimal changes while moving > exynos-pmu driver under drivers/soc/samsung/. Support for exynos7 PMU can > be added on top of it, in such a manner that for ARM64 build, ARM related > SoC's PMU will not get compiled and thus unnecessary increasing kernel image > size. > > These patches have been prepared on top of Kukjin Kim's for-next merged with > driver-samsung and on top of > cherry-picked change from [1]. > > 1: ARM: EXYNOS: Constify local exynos_pmu_data structure >https://lkml.org/lkml/2015/10/28/917 > > For testing entire patchset on Peach-Pi (Exynos5880) based chromebook for boot > and S2R functionality. > > Tested-by: Pankaj Dubey > > For testing entire patchset on on Trats2 (Exynos4412, S2R, reboot, poweroff) > and Odroid XU3 (Exynos5422, reboot, poweroff). > > Tested-by: Krzysztof Kozlowski > > Changes since v5: > - Removed extra blank line from patch 5/9 and 6/9. > - Modified soc/samsung/Kconfig for config EXNOS_PMU. Added depends on ARM. > > Changes since v4: > - In v3 I missed to give -M flag to detect rename, which made patches hard >to review, so resubmitting patches with rename detector flag. > - Addressed review comments from Krzysztof. > > Changes since v3: > - Keeping intact copyright dates in existing header files. > - Addressed review comments from Krzysztof for v3. > - Removing static inline function from exynos-pmu.h and >keeping them in PMU driver. > - Added new patch (2/9) for fixing potential null pointer reference in >exynos_sys_powerdown_conf. > - Added new patch (8/9) for rearranging static and non-static function for >better readability. > > Changes since v2: > - Removed Amit's Samsung id as it's no more valid. > - Rebased on latest kgene tree. > - Removed redundant code from regs-pmu.h > > Pankaj Dubey (9): > ARM: EXYNOS: removing redundant code from regs-pmu.h > ARM: EXYNOS: Fix potential NULL pointer access in > exynos_sys_powerdown_conf > ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung" > ARM: EXYNOS: split up exynos3250 SoC specific PMU data > ARM: EXYNOS: split up exynos4 SoC specific PMU data > ARM: EXYNOS: split up exynos5250 SoC specific PMU data > ARM: EXYNOS: split up exynos5420 SoC specific PMU data > ARM: EXYNOS: rearrange static and non-static functions of PMU driver > drivers: soc: Add support for Exynos PMU driver > I tried to apply this to my branch: next/stuff-late-not-split-per-branch https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch Unfortunately it fails on: error: patch failed: arch/arm/mach-exynos/pmu.c:17 error: arch/arm/mach-exynos/pmu.c: patch does not apply Patch failed at 0001 ARM: EXYNOS: Move pmu specific headers under "linux/soc/samsung" because of syscon-reboot handlers (Alim's work). I think I have all the dependencies already in my "next/stuff-late-not-split-per-branch". If you want to proceed now, can you rebase on top of it? Otherwise we could wait and rebase later (after v4.5-rc1). P.S. Please note that "next/stuff-late-not-split-per-branch" is not included in linux-next because I am not sure if I will be able to push it out soon. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] bpf samples: Uses libbpf in tools/lib to deal with BPF operations
Since we already have libbpf in tools/lib, there's no need to maintain a duplicate BPF loading and operations library in samples. This patch utilises previous introduced utils.[ch], which calls libbpf to do these work. The main changing in this relative large patch is very simple: 1. Makefile modification, makes all hostprogs depend on libbpf.a. Add include and library searching patch and rules for linker. Remove old bpf_load.o and libbpf.o, replaces them with utils.o 2. Make sure there are correct 'version' section so the BPF source files can be loaded by libbpf. 3. Uses API provided by utils.h and libbpf. Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: Alex Gartrell Cc: Arnaldo Carvalho de Melo Cc: Brenden Blanco Cc: Daniel Borkmann Cc: Daniel Wagner Cc: David S. Miller Cc: Ingo Molnar Cc: Kaixu Xia Cc: Michael Holzheu Cc: Yang Shi --- samples/bpf/Makefile| 65 ++--- samples/bpf/fds_example.c | 26 +++--- samples/bpf/lathist_user.c | 13 --- samples/bpf/sock_example.c | 13 +++ samples/bpf/sockex1_kern.c | 2 ++ samples/bpf/sockex1_user.c | 27 -- samples/bpf/sockex2_kern.c | 2 ++ samples/bpf/sockex2_user.c | 26 -- samples/bpf/sockex3_kern.c | 2 ++ samples/bpf/sockex3_user.c | 23 +++- samples/bpf/test_maps.c | 80 - samples/bpf/test_verifier.c | 13 --- samples/bpf/trace_output_user.c | 17 + samples/bpf/tracex1_user.c | 9 +++-- samples/bpf/tracex2_user.c | 31 +--- samples/bpf/tracex3_user.c | 15 samples/bpf/tracex4_user.c | 15 samples/bpf/tracex5_user.c | 9 +++-- samples/bpf/tracex6_user.c | 16 - 19 files changed, 221 insertions(+), 183 deletions(-) diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index edd638b..edb7c04 100644 --- a/samples/bpf/Makefile +++ b/samples/bpf/Makefile @@ -1,6 +1,20 @@ # kbuild trick to avoid linker error. Can be omitted if a module is built. obj- := dummy.o +INC_DIR = $(src)/include +TOOLS_DIR = $(realpath $(srctree))/tools +TOOLS_LIB_DIR = $(TOOLS_DIR)/lib +LIBBPF_DIR = $(TOOLS_LIB_DIR)/bpf + +$(obj)/libbpf/libbpf.a: + $(Q)mkdir -p $(obj)/libbpf + $(MAKE) -C $(LIBBPF_DIR) O=$(realpath $(obj))/libbpf CFLAGS= LDFLAGS= V=1 $(realpath $(obj))/libbpf/libbpf.a + +HOSTCFLAGS += -I$(TOOLS_LIB_DIR) -I$(INC_DIR) +HOSTLDFLAGS += -L$(obj)/libbpf +HOSTCFLAGS += -I$(INC_DIR) -I$(TOOLS_LIB_DIR) +HOST_LOADLIBES += -lelf -lbpf + # List of programs to build hostprogs-y := test_verifier test_maps hostprogs-y += sock_example @@ -17,21 +31,27 @@ hostprogs-y += tracex6 hostprogs-y += trace_output hostprogs-y += lathist -test_verifier-objs := test_verifier.o libbpf.o -test_maps-objs := test_maps.o libbpf.o -sock_example-objs := sock_example.o libbpf.o -fds_example-objs := bpf_load.o libbpf.o fds_example.o -sockex1-objs := bpf_load.o libbpf.o sockex1_user.o -sockex2-objs := bpf_load.o libbpf.o sockex2_user.o -sockex3-objs := bpf_load.o libbpf.o sockex3_user.o -tracex1-objs := bpf_load.o libbpf.o tracex1_user.o -tracex2-objs := bpf_load.o libbpf.o tracex2_user.o -tracex3-objs := bpf_load.o libbpf.o tracex3_user.o -tracex4-objs := bpf_load.o libbpf.o tracex4_user.o -tracex5-objs := bpf_load.o libbpf.o tracex5_user.o -tracex6-objs := bpf_load.o libbpf.o tracex6_user.o -trace_output-objs := bpf_load.o libbpf.o trace_output_user.o -lathist-objs := bpf_load.o libbpf.o lathist_user.o +test_verifier-objs := test_verifier.o +test_maps-objs := test_maps.o +sock_example-objs := sock_example.o utils.o +fds_example-objs := utils.o fds_example.o +sockex1-objs := utils.o sockex1_user.o +sockex2-objs := utils.o sockex2_user.o +sockex3-objs := utils.o sockex3_user.o +tracex1-objs := utils.o tracex1_user.o +tracex2-objs := utils.o tracex2_user.o +tracex3-objs := utils.o tracex3_user.o +tracex4-objs := utils.o tracex4_user.o +tracex5-objs := utils.o tracex5_user.o +tracex6-objs := utils.o tracex6_user.o +trace_output-objs := utils.o trace_output_user.o +lathist-objs := utils.o lathist_user.o + +define add_depend +$(foreach m, $(notdir $1), \ + $(eval $(obj)/$m: $(obj)/libbpf/libbpf.a)) +endef +$(call add_depend, $(hostprogs-y)) # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -50,19 +70,8 @@ always += lathist_kern.o HOSTCFLAGS += -I$(objtree)/usr/include -HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable -HOSTLOADLIBES_fds_example += -lelf -HOSTLOADLIBES_sockex1 += -lelf -HOSTLOADLIBES_sockex2 += -lelf -HOSTLOADLIBES_sockex3 += -lelf -HOSTLOADLIBES_tracex1 += -lelf -HOSTLOADLIBES_tracex2 += -lelf -HOSTLOADLIBES_tracex3 += -lelf -HOSTLOADLIBES_tracex4 += -lelf -lrt -HOSTLOADLIBES_tracex5 += -lelf -HOSTLOADLIBES_tracex6 += -lelf -HOSTLOADLIBES_trace_output += -lelf -lrt -HOSTLOADLIBES_lathist += -lelf
Re: + arc-convert-to-dma_map_ops.patch added to -mm tree
On Tuesday 24 November 2015 01:20 PM, h...@lst.de wrote: > Hi Vineet, > > the original version went through the buildbot, which succeeded. It seems > like the official buildbot does not support arc, and might benefit from > helping to set up an arc environment. However in the meantime Guenther > send me output from his buildbot and I sent a fix for arc. > Hi Andrew, Christoph The dma mapping conversion build error fixlet (below) exists as a separate patch which will break bisectability. Will it be possible to squash it into the orig commit. Thx, -Vineet commit 7f33b4a409493b81c24741dbad6700aae99d8ed0 Author: Christoph Hellwig Date: Fri Dec 11 15:59:33 2015 +1100 arc: dma mapping fixes Signed-off-by: Christoph Hellwig Reported-by: Guenter Roeck Signed-off-by: Andrew Morton -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] bpf samples: Remove old BPF helpers
Since we have switched to libbpf in tools/lib, old bpf_load.c and
libbpf.c can be removed safely.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Alex Gartrell
Cc: Arnaldo Carvalho de Melo
Cc: Brenden Blanco
Cc: Daniel Borkmann
Cc: Daniel Wagner
Cc: David S. Miller
Cc: Ingo Molnar
Cc: Kaixu Xia
Cc: Michael Holzheu
Cc: Yang Shi
---
samples/bpf/bpf_load.c | 345 -
samples/bpf/bpf_load.h | 27
samples/bpf/libbpf.c | 154 --
samples/bpf/libbpf.h | 201
4 files changed, 727 deletions(-)
delete mode 100644 samples/bpf/bpf_load.c
delete mode 100644 samples/bpf/bpf_load.h
delete mode 100644 samples/bpf/libbpf.c
delete mode 100644 samples/bpf/libbpf.h
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
deleted file mode 100644
index da86a8e..000
--- a/samples/bpf/bpf_load.c
+++ /dev/null
@@ -1,345 +0,0 @@
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "libbpf.h"
-#include "bpf_helpers.h"
-#include "bpf_load.h"
-
-#define DEBUGFS "/sys/kernel/debug/tracing/"
-
-static char license[128];
-static int kern_version;
-static bool processed_sec[128];
-int map_fd[MAX_MAPS];
-int prog_fd[MAX_PROGS];
-int event_fd[MAX_PROGS];
-int prog_cnt;
-int prog_array_fd = -1;
-
-static int populate_prog_array(const char *event, int prog_fd)
-{
- int ind = atoi(event), err;
-
- err = bpf_update_elem(prog_array_fd, , _fd, BPF_ANY);
- if (err < 0) {
- printf("failed to store prog_fd in prog_array\n");
- return -1;
- }
- return 0;
-}
-
-static int load_and_attach(const char *event, struct bpf_insn *prog, int size)
-{
- bool is_socket = strncmp(event, "socket", 6) == 0;
- bool is_kprobe = strncmp(event, "kprobe/", 7) == 0;
- bool is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;
- enum bpf_prog_type prog_type;
- char buf[256];
- int fd, efd, err, id;
- struct perf_event_attr attr = {};
-
- attr.type = PERF_TYPE_TRACEPOINT;
- attr.sample_type = PERF_SAMPLE_RAW;
- attr.sample_period = 1;
- attr.wakeup_events = 1;
-
- if (is_socket) {
- prog_type = BPF_PROG_TYPE_SOCKET_FILTER;
- } else if (is_kprobe || is_kretprobe) {
- prog_type = BPF_PROG_TYPE_KPROBE;
- } else {
- printf("Unknown event '%s'\n", event);
- return -1;
- }
-
- fd = bpf_prog_load(prog_type, prog, size, license, kern_version);
- if (fd < 0) {
- printf("bpf_prog_load() err=%d\n%s", errno, bpf_log_buf);
- return -1;
- }
-
- prog_fd[prog_cnt++] = fd;
-
- if (is_socket) {
- event += 6;
- if (*event != '/')
- return 0;
- event++;
- if (!isdigit(*event)) {
- printf("invalid prog number\n");
- return -1;
- }
- return populate_prog_array(event, fd);
- }
-
- if (is_kprobe || is_kretprobe) {
- if (is_kprobe)
- event += 7;
- else
- event += 10;
-
- if (*event == 0) {
- printf("event name cannot be empty\n");
- return -1;
- }
-
- if (isdigit(*event))
- return populate_prog_array(event, fd);
-
- snprintf(buf, sizeof(buf),
-"echo '%c:%s %s' >>
/sys/kernel/debug/tracing/kprobe_events",
-is_kprobe ? 'p' : 'r', event, event);
- err = system(buf);
- if (err < 0) {
- printf("failed to create kprobe '%s' error '%s'\n",
- event, strerror(errno));
- return -1;
- }
- }
-
- strcpy(buf, DEBUGFS);
- strcat(buf, "events/kprobes/");
- strcat(buf, event);
- strcat(buf, "/id");
-
- efd = open(buf, O_RDONLY, 0);
- if (efd < 0) {
- printf("failed to open event %s\n", event);
- return -1;
- }
-
- err = read(efd, buf, sizeof(buf));
- if (err < 0 || err >= sizeof(buf)) {
- printf("read from '%s' failed '%s'\n", event, strerror(errno));
- return -1;
- }
-
- close(efd);
-
- buf[err] = 0;
- id = atoi(buf);
- attr.config = id;
-
- efd = perf_event_open(, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 0);
- if (efd < 0) {
- printf("event %d fd %d err %s\n", id, efd, strerror(errno));
- return -1;
- }
- event_fd[prog_cnt - 1] = efd;
- ioctl(efd,
Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)
On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan wrote: > On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori wrote: >> >> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" >> wrote: >>> >>> Hi, >>> >>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori wrote: >>> > On 16 December 2015 at 22:41, Nish Aravamudan >>> > wrote: >>> >> Hi Daniel, >>> >> >>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta >>> >> wrote: >>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan >>> >>> wrote: >>> So, I apologize in advance for this relatively vague report, but I'm >>> fairly sure >>> the Yoga 900 has an accelerometer amongst other sensors (ambient >>> light?) >>> exported over IIO. >>> >>> But, these sensors seem to not be updating at all with a 4.4-rc5+ >>> kernel (a >>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to >>> Linus' >>> tree). >>> >>> The odd part is at some point in messing with this, I'm fairly sure >>> it did work! >>> That is, >>> >>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*` >>> >>> >>> >>> Can you send us a sample of the output? Also, would be >>> >>> good to identify the exact driver for accel. >>> >> >>> >> cat /sys/bus/iio/devices/iio:device*/*raw* >>> >> 65478 >>> >> 7 >>> >> 1023 >>> >> 0 >>> >> 0 >>> >> 0 >>> >> 100 >>> >> -539062 >>> >> -742187 >>> >> 1292968 >>> >> 1592 >>> >> 64932 >>> >> 2 >>> >> 275 >>> >> 0 0 0 0 >>> >> >>> >> Now, I should say that I distinctly remember at some point waving my >>> >> laptop around and seeing these values change ... but now they seem to >>> >> be "stuck". Maybe it's a hardware issue or something special that >>> >> WIndows does to leverage the IIO sensors? >>> >> >>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name >>> >> >>> >> $ cat /sys/bus/iio/devices/iio:device*/name >>> >> accel_3d >>> > >>> > Can you list the directory of iio:device with this name (it is: >>> > drivers/iio/accel/hid-sensor-accel-3d.c). >>> > This is something you will be looking at for accel debugging, but it >>> > seems more like >>> > standard >>> >>> /sys/bus/iio/devices/iio:device0/name >>> gyro_3d >>> /sys/bus/iio/devices/iio:device1/name >>> dev_rotation >>> /sys/bus/iio/devices/iio:device2/name >>> als >>> /sys/bus/iio/devices/iio:device3/name >>> magn_3d >>> /sys/bus/iio/devices/iio:device4/name >>> accel_3d >>> /sys/bus/iio/devices/iio:device5/name >>> incli_3d >>> >>> are all the IIO sensors, sorry about that! >>> >> >> I was more thinking what else is in iio:device4 directory, so that we can >> see if it was initialized OK. Can you also grep the dmesg for any errors? > > Well, I just noticed the device #s are not consistent boot-to-boot, so > this time it was device0. Trimming out the directories: > > /sys/bus/iio/devices/iio:device0/buffer > cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory > /sys/bus/iio/devices/iio:device0/dev > 250:0 > /sys/bus/iio/devices/iio:device0/in_accel_hysteresis > cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument > /sys/bus/iio/devices/iio:device0/in_accel_offset > 0 > /sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency > 8.00 > /sys/bus/iio/devices/iio:device0/in_accel_scale > 0.009806 > /sys/bus/iio/devices/iio:device0/in_accel_x_raw > 65478 > /sys/bus/iio/devices/iio:device0/in_accel_y_raw > 7 > /sys/bus/iio/devices/iio:device0/in_accel_z_raw > 1023 > /sys/bus/iio/devices/iio:device0/name > accel_3d > /sys/bus/iio/devices/iio:device0/uevent > MAJOR=250 > MINOR=0 > DEVNAME=iio:device0 > DEVTYPE=iio_device > > Another thing I just noticed: > > /sys/bus/iio/devices/iio:device0/buffer/enable > 0 > > The only error I'm getting consistently is: > > [1.115327] i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report > size:19 / ret_size:18 > > which I don't think is relevant, but I might be wrong. > >>> >> gyro_3d >>> >> als >>> >> magn_3d >>> >> incli_3d >>> >> dev_rotation >>> >> >>> >> >>> >>> showed updating values as I moved the laptop around. >>> >>> I've not done any accelerometer debugging before, so any suggestion >>> on >>> where to start would be greatly appreciated! >>> >>> >>> >>> Did you applied some patches and recompiled the kernel? Or when it did >>> >>> stopped >>> >>> working? >>> >> >>> >> As far as I can tell, it only worked that one one time and hasn't >>> >> since. Although your question does make me wonder *which* kernel I was >>> >> on that I experienced the values changing. Let me go back to a stock >>> >> 4.4-rc5 and see. >>> > >>> > Did you compile the stock kernel? It might be that .dts file you are >>> > using (or defconfig) >>> > is not correct. >>> >>> I compiled the stock kernel, based off the the Ubuntu 15.04 .config, >>> trimmed to account for the hardware I have on the system. I can attach >>> the .config if that will be useful. >>> >>> I just went back to 4.4-rc4 and it also didn't seem to have any >>> updates to
[PATCH 08/10] bpf samples: Add utils.[ch] for using BPF
We are going to uses libbpf to replace old libbpf.[ch] and
bpf_load.[ch]. This is the first patch of this work. In this patch,
several macros and helpers in libbpf.[ch] and bpf_load.[ch] are
merged into utils.[ch]. utils.[ch] utilizes libbpf in tools/lib to
deal with BPF related things. They would be compiled after Makefile
changes.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Alex Gartrell
Cc: Arnaldo Carvalho de Melo
Cc: Brenden Blanco
Cc: Daniel Borkmann
Cc: Daniel Wagner
Cc: David S. Miller
Cc: Ingo Molnar
Cc: Kaixu Xia
Cc: Michael Holzheu
Cc: Yang Shi
---
samples/bpf/include/linux/err.h | 56
samples/bpf/utils.c | 276
samples/bpf/utils.h | 217 +++
3 files changed, 549 insertions(+)
create mode 100644 samples/bpf/include/linux/err.h
create mode 100644 samples/bpf/utils.c
create mode 100644 samples/bpf/utils.h
diff --git a/samples/bpf/include/linux/err.h b/samples/bpf/include/linux/err.h
new file mode 100644
index 000..671b874
--- /dev/null
+++ b/samples/bpf/include/linux/err.h
@@ -0,0 +1,56 @@
+#ifndef __TOOLS_LINUX_ERR_H
+#define __TOOLS_LINUX_ERR_H
+
+#include
+
+#ifndef __must_check
+# define __must_check
+#endif
+#ifndef __force
+# define __force
+#endif
+#ifndef unlikely
+# define unlikely(x) x
+#endif
+
+/*
+ * Original kernel header comment:
+ *
+ * Kernel pointers have redundant information, so we can use a
+ * scheme where we can return either an error code or a normal
+ * pointer with the same return value.
+ *
+ * This should be a per-architecture thing, to allow different
+ * error and pointer decisions.
+ *
+ * Userspace note:
+ * The same principle works for userspace, because 'error' pointers
+ * fall down to the unused hole far from user space, as described
+ * in Documentation/x86/x86_64/mm.txt for x86_64 arch:
+ *
+ * - 7fff (=47 bits) user space, different per mm
hole caused by [48:63] sign extension
+ * ffe0 - (=2 MB) unused hole
+ *
+ * It should be the same case for other architectures, because
+ * this code is used in generic kernel code.
+ */
+#define MAX_ERRNO 4095
+
+#define IS_ERR_VALUE(x) unlikely((x) >= (unsigned long)-MAX_ERRNO)
+
+static inline void * __must_check ERR_PTR(long error_)
+{
+ return (void *) error_;
+}
+
+static inline long __must_check PTR_ERR(__force const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline bool __must_check IS_ERR(__force const void *ptr)
+{
+ return IS_ERR_VALUE((unsigned long)ptr);
+}
+
+#endif /* _LINUX_ERR_H */
diff --git a/samples/bpf/utils.c b/samples/bpf/utils.c
new file mode 100644
index 000..73262a9
--- /dev/null
+++ b/samples/bpf/utils.c
@@ -0,0 +1,276 @@
+/* eBPF mini library */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "utils.h"
+
+#define DEBUGFS "/sys/kernel/debug/tracing/"
+
+int open_raw_sock(const char *name)
+{
+ struct sockaddr_ll sll;
+ int sock;
+
+ sock = socket(PF_PACKET, SOCK_RAW | SOCK_NONBLOCK | SOCK_CLOEXEC,
htons(ETH_P_ALL));
+ if (sock < 0) {
+ printf("cannot create raw socket\n");
+ return -1;
+ }
+
+ memset(, 0, sizeof(sll));
+ sll.sll_family = AF_PACKET;
+ sll.sll_ifindex = if_nametoindex(name);
+ sll.sll_protocol = htons(ETH_P_ALL);
+ if (bind(sock, (struct sockaddr *), sizeof(sll)) < 0) {
+ printf("bind to %s: %s\n", name, strerror(errno));
+ close(sock);
+ return -1;
+ }
+
+ return sock;
+}
+
+void read_trace_pipe(void)
+{
+ int trace_fd;
+
+ trace_fd = open(DEBUGFS "trace_pipe", O_RDONLY, 0);
+ if (trace_fd < 0)
+ return;
+
+ while (1) {
+ static char buf[4096];
+ ssize_t sz;
+
+ sz = read(trace_fd, buf, sizeof(buf));
+ if (sz > 0) {
+ buf[sz] = 0;
+ puts(buf);
+ }
+ }
+}
+
+int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
+ int group_fd, unsigned long flags)
+{
+ return syscall(__NR_perf_event_open, attr, pid, cpu,
+ group_fd, flags);
+}
+
+static int prog_load_prep(struct bpf_program *prog, int n,
+ struct bpf_insn *insns, int insns_cnt,
+ struct bpf_prog_prep_result *res)
+{
+ enum bpf_prog_type prog_type;
+ int is_socket, is_kprobe, is_kretprobe;
+ const char *event = bpf_program__title(prog, false);
+
+ LIBBPF_PTR_ASSERT(event, return -1);
+
+ is_socket = strncmp(event, "socket", 6) == 0;
+ is_kprobe = strncmp(event, "kprobe/", 7) == 0;
+ is_kretprobe = strncmp(event, "kretprobe/", 10) == 0;
RE: [PATCHv2] pci: Update VPD size with correct length
> The only 'error' cases I've encountered so far is a read of all zeroes (and a > halting the machine once you've read beyond a certain point) or a read of > 0xff throughout the entire area. So that approach would work for both of them. I should add that I'd tested the previous patch and this patch. I'll retest once v3 is available. I have a card that repeats the vpd data every 4k for all 32k. The patch as it stands truncates that to just the valid data and lspci - shows the vpd data correctly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/8] irq: bcm2836: Add SMP support for the 2836
Hi Eric,
On Wed, Dec 16, 2015 at 03:55:09PM -0800, Eric Anholt wrote:
> @@ -226,6 +228,26 @@ static const struct irq_domain_ops
> bcm2836_arm_irqchip_intc_ops = {
> .xlate = irq_domain_xlate_onecell
> };
>
> +#ifdef CONFIG_SMP
Why not put this section under the existing '#ifdef CONFIG_SMP' just a few
lines above?
> +int __init bcm2836_smp_boot_secondary(unsigned int cpu,
> + struct task_struct *idle)
> +{
> + unsigned long secondary_startup_phys =
> + (unsigned long)virt_to_phys((void *)secondary_startup);
> +
> + dsb();
> + writel(secondary_startup_phys,
> +intc.base + LOCAL_MAILBOX3_SET0 + 16 * cpu);
> +
> + return 0;
> +}
> +
> +static const struct smp_operations bcm2836_smp_ops __initconst = {
> + .smp_boot_secondary = bcm2836_smp_boot_secondary,
> +};
> +
> +#endif
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10] bpf samples: Uses libbpf in tools/lib to do BPF operations
Since we already have libbpf in tools/lib, we don't need to maintain
another bpf loader and operations library in samples/bpf.
In patchset:
Patch 1/10 - 7/10 improves libbpf, add missing features to support
samples,
Patch 8/10 adds utils.[ch], which creates similar API like old
bpf_load.c and libbpf.c.
Patch 9/10 replace all sampels to use API provides by utils.[ch] and
libbpf.
Patch 10/10 removes unneeded files.
Cc: Alexei Starovoitov
Cc: Alex Gartrell
Cc: Arnaldo Carvalho de Melo
Cc: Brenden Blanco
Cc: Daniel Borkmann
Cc: Daniel Wagner
Cc: David S. Miller
Cc: Ingo Molnar
Cc: Jiri Olsa
Cc: Kaixu Xia
Cc: Michael Holzheu
Cc: Yang Shi
Wang Nan (10):
bpf samples: bpf: Fix tracex5_kern.c compiling error
bpf tools: Define LD and RM in Makefile for 'make -R'
bpf tools: Add const decoretor to 'license' and 'insns' for
bpf_load_program()
bpf tools: Switch to uapi style type names
bpf tools: Support load different type of programs
bpf tools: Support new map operations
bpf tools: Support BPF_OBJ_PIN and BPF_OBJ_GET
bpf samples: Add utils.[ch] for using BPF
bpf samples: Uses libbpf in tools/lib to deal with BPF operations
bpf samples: Remove old BPF helpers
samples/bpf/Makefile | 65 +++
samples/bpf/bpf_load.c| 345 --
samples/bpf/bpf_load.h| 27 ---
samples/bpf/fds_example.c | 26 +--
samples/bpf/include/linux/err.h | 56 +++
samples/bpf/lathist_user.c| 13 +-
samples/bpf/libbpf.c | 154 -
samples/bpf/sock_example.c| 13 +-
samples/bpf/sockex1_kern.c| 2 +
samples/bpf/sockex1_user.c| 27 +--
samples/bpf/sockex2_kern.c| 2 +
samples/bpf/sockex2_user.c| 26 +--
samples/bpf/sockex3_kern.c| 2 +
samples/bpf/sockex3_user.c| 23 ++-
samples/bpf/test_maps.c | 80 -
samples/bpf/test_verifier.c | 13 +-
samples/bpf/trace_output_user.c | 17 +-
samples/bpf/tracex1_user.c| 9 +-
samples/bpf/tracex2_user.c| 31 ++--
samples/bpf/tracex3_user.c| 15 +-
samples/bpf/tracex4_user.c| 15 +-
samples/bpf/tracex5_kern.c| 1 +
samples/bpf/tracex5_user.c| 9 +-
samples/bpf/tracex6_user.c| 16 +-
samples/bpf/utils.c | 276 ++
samples/bpf/{libbpf.h => utils.h} | 58 ---
tools/lib/bpf/Makefile| 2 +
tools/lib/bpf/bpf.c | 65 ++-
tools/lib/bpf/bpf.h | 16 +-
tools/lib/bpf/libbpf.c| 43 -
tools/lib/bpf/libbpf.h| 16 ++
31 files changed, 718 insertions(+), 745 deletions(-)
delete mode 100644 samples/bpf/bpf_load.c
delete mode 100644 samples/bpf/bpf_load.h
create mode 100644 samples/bpf/include/linux/err.h
delete mode 100644 samples/bpf/libbpf.c
create mode 100644 samples/bpf/utils.c
rename samples/bpf/{libbpf.h => utils.h} (81%)
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] bpf tools: Add const decoretor to 'license' and 'insns' for bpf_load_program()
Actually 'license' and 'insns' are const pointer. Before this patch
using 'bpf_load_program(... "GPL", ...)' triggers a warning, which is
unnecessary.
This patch makes these two arguments const pointers.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 8
tools/lib/bpf/bpf.h | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 1f91cc9..88e6a46 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -55,8 +55,8 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size,
return sys_bpf(BPF_MAP_CREATE, , sizeof(attr));
}
-int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
-size_t insns_cnt, char *license,
+int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
+size_t insns_cnt, const char *license,
u32 kern_version, char *log_buf, size_t log_buf_sz)
{
int fd;
@@ -65,8 +65,8 @@ int bpf_load_program(enum bpf_prog_type type, struct bpf_insn
*insns,
bzero(, sizeof(attr));
attr.prog_type = type;
attr.insn_cnt = (__u32)insns_cnt;
- attr.insns = ptr_to_u64(insns);
- attr.license = ptr_to_u64(license);
+ attr.insns = ptr_to_u64((void *)insns);
+ attr.license = ptr_to_u64((void *)license);
attr.log_buf = ptr_to_u64(NULL);
attr.log_size = 0;
attr.log_level = 0;
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index a764655..00cfeae 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -15,8 +15,8 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size,
int value_size,
/* Recommend log buffer size */
#define BPF_LOG_BUF_SIZE 65536
-int bpf_load_program(enum bpf_prog_type type, struct bpf_insn *insns,
-size_t insns_cnt, char *license,
+int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
+size_t insns_cnt, const char *license,
u32 kern_version, char *log_buf,
size_t log_buf_sz);
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] bpf tools: Switch to uapi style type names
Types "u64, u32" don't exist in uapi header (linux/types.h). Because of
that directly include bpf.h causes error.
This patch fixes this by replacing all occurrences of "u32, u64" in API
to "__u32, __u64". The later can be found in 'uapi/linux/types.h' so
it would be safe for normal program (other than perf).
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 4 ++--
tools/lib/bpf/bpf.h | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 88e6a46..e0dccea 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -57,7 +57,7 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size,
int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
size_t insns_cnt, const char *license,
-u32 kern_version, char *log_buf, size_t log_buf_sz)
+__u32 kern_version, char *log_buf, size_t log_buf_sz)
{
int fd;
union bpf_attr attr;
@@ -85,7 +85,7 @@ int bpf_load_program(enum bpf_prog_type type, const struct
bpf_insn *insns,
}
int bpf_map_update_elem(int fd, void *key, void *value,
- u64 flags)
+ __u64 flags)
{
union bpf_attr attr;
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 00cfeae..01a421a 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -8,6 +8,7 @@
#ifndef __BPF_BPF_H
#define __BPF_BPF_H
+#include
#include
int bpf_create_map(enum bpf_map_type map_type, int key_size, int value_size,
@@ -17,9 +18,9 @@ int bpf_create_map(enum bpf_map_type map_type, int key_size,
int value_size,
#define BPF_LOG_BUF_SIZE 65536
int bpf_load_program(enum bpf_prog_type type, const struct bpf_insn *insns,
size_t insns_cnt, const char *license,
-u32 kern_version, char *log_buf,
+__u32 kern_version, char *log_buf,
size_t log_buf_sz);
int bpf_map_update_elem(int fd, void *key, void *value,
- u64 flags);
+ __u64 flags);
#endif
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] bpf tools: Define LD and RM in Makefile for 'make -R'
Building libbpf with 'make -R' causes error: $ make -R Auto-detecting system features: ...libelf: [ on ] ... bpf: [ on ] CC fixdep.o LD fixdep-in.o /bin/sh: -r: command not found make[2]: *** [fixdep-in.o] Error 127 make[1]: *** [fixdep-in.o] Error 2 make: *** [fixdep] Error 2 Makefile for libbpf requires $(LD) and $(RM), but in case of 'make -R' the builtin variables are gone. This patch define default RM and LD so it won't fail in 'make -R'. Signed-off-by: Wang Nan Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa --- tools/lib/bpf/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index 0b6e013..7bec12f 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -5,6 +5,8 @@ BPF_PATCHLEVEL = 0 BPF_EXTRAVERSION = 1 MAKEFLAGS += --no-print-directory +RM ?= rm -f +LD ?= $(CROSS_COMPILE)ld ifeq ($(srctree),) srctree := $(patsubst %/,%,$(dir $(shell pwd))) -- 1.8.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/10] bpf tools: Support load different type of programs
Before this patch libbpf can only load program with type
BPF_PROG_TYPE_KPROBE program. To make libbpf useful in other scenarios,
this patch introduced bpf_program__set_type() and
bpf_object__set_type() which allows setting program type.
This changes doesn't break old API. The default program type is
BPF_PROG_TYPE_KPROBE. If caller wants to load program with other type,
one of these API should be called before bpf_object__load() or
in callback function of loader.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/libbpf.c | 43 ++-
tools/lib/bpf/libbpf.h | 16
2 files changed, 54 insertions(+), 5 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 8334a5a..99be7f1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -66,6 +66,7 @@ void libbpf_set_print(libbpf_print_fn_t warn,
#define ERRNO_OFFSET(e)((e) - __LIBBPF_ERRNO__START)
#define ERRCODE_OFFSET(c) ERRNO_OFFSET(LIBBPF_ERRNO__##c)
#define NR_ERRNO (__LIBBPF_ERRNO__END - __LIBBPF_ERRNO__START)
+#define BPF_PROG_TYPE_MAX BPF_PROG_TYPE_SCHED_ACT
static const char *libbpf_strerror_table[NR_ERRNO] = {
[ERRCODE_OFFSET(LIBELF)]= "Something wrong in libelf",
@@ -161,6 +162,7 @@ struct bpf_program {
struct bpf_object *obj;
void *priv;
bpf_program_clear_priv_t clear_priv;
+ enum bpf_prog_type type;
};
struct bpf_map {
@@ -323,6 +325,7 @@ bpf_object__add_program(struct bpf_object *obj, void *data,
size_t size,
obj->programs = progs;
obj->nr_programs = nr_progs + 1;
prog.obj = obj;
+ prog.type = BPF_PROG_TYPE_KPROBE;
progs[nr_progs] = prog;
return 0;
}
@@ -871,7 +874,7 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
}
static int
-load_program(struct bpf_insn *insns, int insns_cnt,
+load_program(struct bpf_insn *insns, int insns_cnt, enum bpf_prog_type type,
char *license, u32 kern_version, int *pfd)
{
int ret;
@@ -884,9 +887,8 @@ load_program(struct bpf_insn *insns, int insns_cnt,
if (!log_buf)
pr_warning("Alloc log buffer for bpf loader error, continue
without log\n");
- ret = bpf_load_program(BPF_PROG_TYPE_KPROBE, insns,
- insns_cnt, license, kern_version,
- log_buf, BPF_LOG_BUF_SIZE);
+ ret = bpf_load_program(type, insns, insns_cnt, license,
+ kern_version, log_buf, BPF_LOG_BUF_SIZE);
if (ret >= 0) {
*pfd = ret;
@@ -945,7 +947,7 @@ bpf_program__load(struct bpf_program *prog,
pr_warning("Program '%s' is inconsistent: nr(%d) !=
1\n",
prog->section_name, prog->instances.nr);
}
- err = load_program(prog->insns, prog->insns_cnt,
+ err = load_program(prog->insns, prog->insns_cnt, prog->type,
license, kern_version, );
if (!err)
prog->instances.fds[0] = fd;
@@ -976,6 +978,7 @@ bpf_program__load(struct bpf_program *prog,
err = load_program(result.new_insn_ptr,
result.new_insn_cnt,
+ prog->type,
license, kern_version, );
if (err) {
@@ -1192,6 +1195,25 @@ bpf_object__get_kversion(struct bpf_object *obj)
return obj->kern_version;
}
+int bpf_object__set_type(struct bpf_object *obj,
+enum bpf_prog_type type)
+{
+ struct bpf_program *prog;
+ int err;
+
+ if (!obj || type <= BPF_PROG_TYPE_UNSPEC ||
+ type > BPF_PROG_TYPE_MAX)
+ return -EINVAL;
+
+ bpf_object__for_each_program(prog, obj) {
+ err = bpf_program__set_type(prog, type);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
struct bpf_program *
bpf_program__next(struct bpf_program *prev, struct bpf_object *obj)
{
@@ -1281,6 +1303,17 @@ int bpf_program__set_prep(struct bpf_program *prog, int
nr_instances,
return 0;
}
+int bpf_program__set_type(struct bpf_program *prog,
+ enum bpf_prog_type type)
+{
+ if (!prog || type <= BPF_PROG_TYPE_UNSPEC ||
+ type > BPF_PROG_TYPE_MAX)
+ return -EINVAL;
+
+ prog->type = type;
+ return 0;
+}
+
int bpf_program__nth_fd(struct bpf_program *prog, int n)
{
int fd;
diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
index a51594c..c9d4130 100644
--- a/tools/lib/bpf/libbpf.h
+++ b/tools/lib/bpf/libbpf.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
enum libbpf_errno {
__LIBBPF_ERRNO__START = 4000,
@@ -58,6 +59,13 @@ int bpf_object__unload(struct bpf_object *obj);
const
[PATCH 06/10] bpf tools: Support new map operations
Add bpf_map_lookup_elem(), bpf_map_delete_elem() and bpf_map_get_next_key()
to libbpf so it can issue all BPF map operations.
Signed-off-by: Wang Nan
Cc: Arnaldo Carvalho de Melo
---
tools/lib/bpf/bpf.c | 32
tools/lib/bpf/bpf.h | 4
2 files changed, 36 insertions(+)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index e0dccea..89c9d0b 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -97,3 +97,35 @@ int bpf_map_update_elem(int fd, void *key, void *value,
return sys_bpf(BPF_MAP_UPDATE_ELEM, , sizeof(attr));
}
+
+int bpf_map_lookup_elem(int fd, void *key, void *value)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .value = ptr_to_u64(value),
+ };
+
+ return sys_bpf(BPF_MAP_LOOKUP_ELEM, , sizeof(attr));
+}
+
+int bpf_map_delete_elem(int fd, void *key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ };
+
+ return sys_bpf(BPF_MAP_DELETE_ELEM, , sizeof(attr));
+}
+
+int bpf_map_get_next_key(int fd, void *key, void *next_key)
+{
+ union bpf_attr attr = {
+ .map_fd = fd,
+ .key = ptr_to_u64(key),
+ .next_key = ptr_to_u64(next_key),
+ };
+
+ return sys_bpf(BPF_MAP_GET_NEXT_KEY, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 01a421a..3d22048 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -23,4 +23,8 @@ int bpf_load_program(enum bpf_prog_type type, const struct
bpf_insn *insns,
int bpf_map_update_elem(int fd, void *key, void *value,
__u64 flags);
+
+int bpf_map_lookup_elem(int fd, void *key, void *value);
+int bpf_map_delete_elem(int fd, void *key);
+int bpf_map_get_next_key(int fd, void *key, void *next_key);
#endif
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] bpf samples: bpf: Fix tracex5_kern.c compiling error
LLVM report compiling error:
/kpathsamples/bpf/tracex5_kern.c:33:15: error: use of undeclared identifier
'__NR_getuid'; did you
mean '__NR_vgetcpu'?
if (sd.nr >= __NR_getuid && sd.nr <= __NR_getsid) {
^~~
__NR_vgetcpu
/kpath/arch/x86/include/uapi/asm/vsyscall.h:7:2: note: '__NR_vgetcpu' declared
here
__NR_vgetcpu,
This patch fix it by adding asm/unistd.h to it.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: David S. Miller
---
samples/bpf/tracex5_kern.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/samples/bpf/tracex5_kern.c b/samples/bpf/tracex5_kern.c
index b3f4295..2964efd 100644
--- a/samples/bpf/tracex5_kern.c
+++ b/samples/bpf/tracex5_kern.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "bpf_helpers.h"
#define PROG(F) SEC("kprobe/"__stringify(F)) int bpf_func_##F
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] bpf tools: Support BPF_OBJ_PIN and BPF_OBJ_GET
Commit b2197755b2633e164a439682fb05a9b5ea48f706 ("bpf: add support for
persistent maps/progs") introduces two new operations to both map and
program. This patch makes libbpf support it.
Signed-off-by: Wang Nan
Cc: Alexei Starovoitov
Cc: Arnaldo Carvalho de Melo
Cc: Daniel Borkmann
---
tools/lib/bpf/bpf.c | 21 +
tools/lib/bpf/bpf.h | 3 +++
2 files changed, 24 insertions(+)
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index 89c9d0b..5f174c6 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -129,3 +129,24 @@ int bpf_map_get_next_key(int fd, void *key, void *next_key)
return sys_bpf(BPF_MAP_GET_NEXT_KEY, , sizeof(attr));
}
+
+int bpf_pin_object(int fd, const char *pathname)
+{
+ union bpf_attr attr;
+
+ bzero(, sizeof(attr));
+ attr.pathname = ptr_to_u64((void *)pathname);
+ attr.bpf_fd = fd;
+
+ return sys_bpf(BPF_OBJ_PIN, , sizeof(attr));
+}
+
+int bpf_get_pinned_object(const char *pathname)
+{
+ union bpf_attr attr;
+
+ bzero(, sizeof(attr));
+ attr.pathname = ptr_to_u64((void *)pathname);
+
+ return sys_bpf(BPF_OBJ_GET, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 3d22048..c9f1a1c 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -27,4 +27,7 @@ int bpf_map_update_elem(int fd, void *key, void *value,
int bpf_map_lookup_elem(int fd, void *key, void *value);
int bpf_map_delete_elem(int fd, void *key);
int bpf_map_get_next_key(int fd, void *key, void *next_key);
+
+int bpf_pin_object(int fd, const char *pathname);
+int bpf_get_pinned_object(const char *pathname);
#endif
--
1.8.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH] f2fs: optimize the flow of f2fs_map_blocks
check map->m_len right after it changes to avoid excess call
to update dnode_of_data.
Signed-off-by: Fan li
---
fs/f2fs/data.c | 69 +---
1 file changed, 36 insertions(+), 33 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 90a2ffe..8fa4560 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -573,6 +573,7 @@ int f2fs_map_blocks(struct inode *inode, struct
f2fs_map_blocks *map,
int err = 0, ofs = 1;
struct extent_info ei;
bool allocated = false;
+ block_t blkaddr;
map->m_len = 0;
map->m_flags = 0;
@@ -636,6 +637,9 @@ int f2fs_map_blocks(struct inode *inode, struct
f2fs_map_blocks *map,
pgofs++;
get_next:
+ if (map->m_len >= maxblocks)
+ goto sync_out;
+
if (dn.ofs_in_node >= end_offset) {
if (allocated)
sync_inode_page();
@@ -653,44 +657,43 @@ get_next:
end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
}
- if (maxblocks > map->m_len) {
- block_t blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
+ blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
- if (blkaddr == NEW_ADDR || blkaddr == NULL_ADDR) {
- if (create) {
- if (unlikely(f2fs_cp_error(sbi))) {
- err = -EIO;
- goto sync_out;
- }
- err = __allocate_data_block();
- if (err)
- goto sync_out;
- allocated = true;
- map->m_flags |= F2FS_MAP_NEW;
- blkaddr = dn.data_blkaddr;
- } else {
- /*
-* we only merge preallocated unwritten blocks
-* for fiemap.
-*/
- if (flag != F2FS_GET_BLOCK_FIEMAP ||
- blkaddr != NEW_ADDR)
- goto sync_out;
+ if (blkaddr == NEW_ADDR || blkaddr == NULL_ADDR) {
+ if (create) {
+ if (unlikely(f2fs_cp_error(sbi))) {
+ err = -EIO;
+ goto sync_out;
}
+ err = __allocate_data_block();
+ if (err)
+ goto sync_out;
+ allocated = true;
+ map->m_flags |= F2FS_MAP_NEW;
+ blkaddr = dn.data_blkaddr;
+ } else {
+ /*
+* we only merge preallocated unwritten blocks
+* for fiemap.
+*/
+ if (flag != F2FS_GET_BLOCK_FIEMAP ||
+ blkaddr != NEW_ADDR)
+ goto sync_out;
}
+ }
- /* Give more consecutive addresses for the readahead */
- if ((map->m_pblk != NEW_ADDR &&
- blkaddr == (map->m_pblk + ofs)) ||
- (map->m_pblk == NEW_ADDR &&
- blkaddr == NEW_ADDR)) {
- ofs++;
- dn.ofs_in_node++;
- pgofs++;
- map->m_len++;
- goto get_next;
- }
+ /* Give more consecutive addresses for the readahead */
+ if ((map->m_pblk != NEW_ADDR &&
+ blkaddr == (map->m_pblk + ofs)) ||
+ (map->m_pblk == NEW_ADDR &&
+ blkaddr == NEW_ADDR)) {
+ ofs++;
+ dn.ofs_in_node++;
+ pgofs++;
+ map->m_len++;
+ goto get_next;
}
+
sync_out:
if (allocated)
sync_inode_page();
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers: thunderbold: Fixed Coding Style - Missing a blank line after declarations
Fixed coding style issue for missing blank lines after variable
declarations.
Signed-off-by: Benjamin Young
---
drivers/thunderbolt/cap.c| 2 ++
drivers/thunderbolt/ctl.c| 10 ++
drivers/thunderbolt/eeprom.c | 11 +++
drivers/thunderbolt/nhi.c| 13 +
drivers/thunderbolt/path.c | 5 +
drivers/thunderbolt/switch.c | 8
drivers/thunderbolt/tb.c | 10 ++
drivers/thunderbolt/tunnel_pci.c | 4
8 files changed, 63 insertions(+)
diff --git a/drivers/thunderbolt/cap.c b/drivers/thunderbolt/cap.c
index a7b47e7..31be7bc 100644
--- a/drivers/thunderbolt/cap.c
+++ b/drivers/thunderbolt/cap.c
@@ -43,6 +43,7 @@ static enum tb_cap tb_cap(struct tb_cap_any *cap)
static u32 tb_cap_next(struct tb_cap_any *cap, u32 offset)
{
int next;
+
if (offset == 1) {
/*
* The first pointer is part of the switch header and always
@@ -83,6 +84,7 @@ int tb_find_cap(struct tb_port *port, enum tb_cfg_space
space, enum tb_cap cap)
struct tb_cap_any header;
int res;
int retries = 10;
+
while (retries--) {
res = tb_port_read(port, , space, offset, 1);
if (res) {
diff --git a/drivers/thunderbolt/ctl.c b/drivers/thunderbolt/ctl.c
index 799634b..0cde9d7 100644
--- a/drivers/thunderbolt/ctl.c
+++ b/drivers/thunderbolt/ctl.c
@@ -202,6 +202,7 @@ static struct tb_cfg_result decode_error(struct ctl_pkg
*response)
{
struct cfg_error_pkg *pkg = response->buffer;
struct tb_cfg_result res = { 0 };
+
res.response_route = get_route(pkg->header);
res.response_port = 0;
res.err = check_header(response, sizeof(*pkg), TB_CFG_PKG_ERROR,
@@ -276,6 +277,7 @@ static void tb_cfg_print_error(struct tb_ctl *ctl,
static void cpu_to_be32_array(__be32 *dst, u32 *src, size_t len)
{
int i;
+
for (i = 0; i < len; i++)
dst[i] = cpu_to_be32(src[i]);
}
@@ -283,6 +285,7 @@ static void cpu_to_be32_array(__be32 *dst, u32 *src, size_t
len)
static void be32_to_cpu_array(u32 *dst, __be32 *src, size_t len)
{
int i;
+
for (i = 0; i < len; i++)
dst[i] = be32_to_cpu(src[i]);
}
@@ -304,6 +307,7 @@ static void tb_ctl_pkg_free(struct ctl_pkg *pkg)
static struct ctl_pkg *tb_ctl_pkg_alloc(struct tb_ctl *ctl)
{
struct ctl_pkg *pkg = kzalloc(sizeof(*pkg), GFP_KERNEL);
+
if (!pkg)
return NULL;
pkg->ctl = ctl;
@@ -323,6 +327,7 @@ static void tb_ctl_tx_callback(struct tb_ring *ring, struct
ring_frame *frame,
bool canceled)
{
struct ctl_pkg *pkg = container_of(frame, typeof(*pkg), frame);
+
tb_ctl_pkg_free(pkg);
}
@@ -338,6 +343,7 @@ static int tb_ctl_tx(struct tb_ctl *ctl, void *data, size_t
len,
{
int res;
struct ctl_pkg *pkg;
+
if (len % 4 != 0) { /* required for le->be conversion */
tb_ctl_WARN(ctl, "TX: invalid size: %zu\n", len);
return -EINVAL;
@@ -370,6 +376,7 @@ static void tb_ctl_handle_plug_event(struct tb_ctl *ctl,
struct ctl_pkg *response)
{
struct cfg_event_pkg *pkg = response->buffer;
+
u64 route = get_route(pkg->header);
if (check_header(response, sizeof(*pkg), TB_CFG_PKG_EVENT, route)) {
@@ -475,6 +482,7 @@ struct tb_ctl *tb_ctl_alloc(struct tb_nhi *nhi, hotplug_cb
cb, void *cb_data)
{
int i;
struct tb_ctl *ctl = kzalloc(sizeof(*ctl), GFP_KERNEL);
+
if (!ctl)
return NULL;
ctl->nhi = nhi;
@@ -520,6 +528,7 @@ err:
void tb_ctl_free(struct tb_ctl *ctl)
{
int i;
+
if (ctl->rx)
ring_free(ctl->rx);
if (ctl->tx)
@@ -541,6 +550,7 @@ void tb_ctl_free(struct tb_ctl *ctl)
void tb_ctl_start(struct tb_ctl *ctl)
{
int i;
+
tb_ctl_info(ctl, "control channel starting...\n");
ring_start(ctl->tx); /* is used to ack hotplug packets, start first */
ring_start(ctl->rx);
diff --git a/drivers/thunderbolt/eeprom.c b/drivers/thunderbolt/eeprom.c
index 0dde34e..9ff432b 100644
--- a/drivers/thunderbolt/eeprom.c
+++ b/drivers/thunderbolt/eeprom.c
@@ -39,6 +39,7 @@ static int tb_eeprom_active(struct tb_switch *sw, bool enable)
{
struct tb_eeprom_ctl ctl;
int res = tb_eeprom_ctl_read(sw, );
+
if (res)
return res;
if (enable) {
@@ -68,6 +69,7 @@ static int tb_eeprom_transfer(struct tb_switch *sw, struct
tb_eeprom_ctl *ctl,
enum tb_eeprom_transfer direction)
{
int res;
+
if (direction == TB_EEPROM_OUT) {
res = tb_eeprom_ctl_write(sw, ctl);
if (res)
@@ -94,6 +96,7 @@ static int tb_eeprom_out(struct tb_switch *sw, u8 val)
struct tb_eeprom_ctl ctl;
int i;
int res = tb_eeprom_ctl_read(sw, );
+
Re: [PATCH v9 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410
On 16.11.2015 16:43, Pavel Fedin wrote:
> This patch extends Exynos SROM controller driver with ability to configure
> controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
> which is connected via SROMc bank #3.
>
> With this patchset, support for the whole existing SMDK range can be added.
> Actually, only bank number is different.
>
> This patchset also depends on Exynos 5410 pinctrl support, introduced by
> patches 0003 and 0004 from this set:
> [PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html
>
> Pinctrl support is necessary in order to correctly configure
> multifunctional pins of the Exynos chip.
>
Let me share the plan/status:
1. Currently Kukjin Kim is out of office (he told me he will be back on
Christmas).
2. I asked arm-soc people to pull my previous pull requests.
3. I applied this patchset to my branch:
next/stuff-late-not-split-per-branch
https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch
4. This branch is not pushed to linux-next. I will sort it out if my
previous pull requests get in. I will be out of office for Christmas so
depending on the timing of {arm-soc,Christmas,Kukjin} this may or may
not go into v4.5 (yay...).
5. If it does not get into v4.5, I will rebase it and proceed further
for v4.6.
If you have any questions, please let me know.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v5 0/8] Add support for Exynos SROM Controller driver
On 12.12.2015 16:43, Pankaj Dubey wrote: > THIS IS A RESEND OF ONCE MERGED INTO kgene/for-next AND LOST PATCHES > > Series v5 got merged in kgene/for-next but due to last moment change before > pull > these patches were not accepted during 4.3 merge window.After that > kgene/for-next > got rebased over 4.4-rc1 these patches got dropped into another branch and > till > date not included to for-next. > > Since then due to minor change in "drivers/soc/", patches are not getting > applied > cleanly so rebasing on current for-next and resending all these with fix in > memory > mapping included. > > > This patch set adds support for Exynos SROM controller DT based driver. > Currently SROM register sets are used only during S2R, so driver > basically added for taking care of S2R. It will help us in removing > static mapping from exynos.c and other extra code handline during S2R. > > This patch set also updated exynos4 and exynos5 dtsi files for with device > node for srom, and added binding documentation for the same. > > First two patches are some minor cleanup in mach-exynos. > > Patchset v1 was posted here[1] > [1]: https://lkml.org/lkml/2015/4/29/98 > Patchset v2 was posted here[2] > [2]: https://lkml.org/lkml/2015/8/24/125 > Patchset v3 was posted here[3] > [3]: https://lkml.org/lkml/2015/10/13/392 > Patchset v3 was posted here[4] > [4]: https://lkml.org/lkml/2015/10/19/278 > > This patchset, I have tested on Peach-Pi (Exynos5880) based chromebook for > boot > and S2R functionality. Let me share the plan/status: 1. Currently Kukjin Kim is on out of office (he told me he will be back on Christmas). 2. I asked arm-soc people to pull my requests. 3. I applied this patchset to my branch: next/stuff-late-not-split-per-branch https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=next/stuff-late-not-split-per-branch 4. This branch is not pushed to linux-next. I will sort it out if my previous pull requests get in. I will be out of office for Christmas so depending on the timing of arm-soc/Christmas/Kukjin this may or may not go into v4.5 (yay...). 5. If it does not get into v4.5, I will rebase it and proceed further for v4.6. If you have any questions, please let me know. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v4 2/3] tools: Move Makefile.arch from perf/config to tools/scripts
On 2015/12/17 01:43AM, Wang Nan wrote: > After this patch other directories can use this architecture detector > without directly including it from perf's directory. Libbpf would > utilize it to get proper $(ARCH) so it can receive correct uapi include > directory. > > Signed-off-by: Wang Nan > Acked-by: Jiri Olsa > Tested-by: Naveen N. Rao > Cc: Arnaldo Carvalho de Melo > Cc: Naveen N. Rao > Cc: Sukadev Bhattiprolu > --- > tools/perf/config/Makefile | 2 +- > tools/perf/config/Makefile.arch | 18 -- > tools/perf/tests/make | 2 +- > tools/scripts/Makefile.arch | 18 ++ > 4 files changed, 20 insertions(+), 20 deletions(-) > delete mode 100644 tools/perf/config/Makefile.arch > create mode 100644 tools/scripts/Makefile.arch ^^ This is different from your previous version. This should be a file rename. - Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] backlight: gpio-backlight: use default-on on GPIO request
Hi,
Any comment on this? I still think it is a valuable change...
--
Stefan
On 2015-10-23 16:44, Stefan Agner wrote:
> There are situations where the backlight should be on at boot time
> (e.g. if the boot loader already turned the display on). The DT
> bindings specify the "default-on" property for that purpose.
> Currently, the initial state of the GPIO at request time is always
> set to logical off (high or low depending on whether it is an
> active high or low GPIO). Since the GPIO is requested as an output,
> the GPIO will be driven low for a short period of time, which leads
> to a flickering display in the above use-case.
>
> Initialize the GPIO depending on the default-on property to be
> logical on or off.
>
> Signed-off-by: Stefan Agner
> ---
> drivers/video/backlight/gpio_backlight.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index 5fbbc2e..1813441 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -89,6 +89,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> struct device_node *np = pdev->dev.of_node;
> + unsigned long flags = GPIOF_DIR_OUT;
> int ret;
>
> if (!pdata && !np) {
> @@ -114,9 +115,12 @@ static int gpio_backlight_probe(struct
> platform_device *pdev)
> gbl->def_value = pdata->def_value;
> }
>
> - ret = devm_gpio_request_one(gbl->dev, gbl->gpio, GPIOF_DIR_OUT |
> - (gbl->active ? GPIOF_INIT_LOW
> - : GPIOF_INIT_HIGH),
> + if (gbl->active)
> + flags |= gbl->def_value ? GPIOF_INIT_HIGH : GPIOF_INIT_LOW;
> + else
> + flags |= gbl->def_value ? GPIOF_INIT_LOW : GPIOF_INIT_HIGH;
> +
> + ret = devm_gpio_request_one(gbl->dev, gbl->gpio, flags,
> pdata ? pdata->name : "backlight");
> if (ret < 0) {
> dev_err(>dev, "unable to request GPIO\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] perf: bpf: Fix build breakage due to libbpf
On 2015/12/17 09:29AM, Wang Nan wrote: > > > On 2015/12/17 3:42, Arnaldo Carvalho de Melo wrote: > >Em Tue, Dec 15, 2015 at 05:10:46PM +0530, Naveen N. Rao escreveu: > >>On 2015/12/15 08:51AM, Wang Nan wrote: > >>>From: "Naveen N. Rao" > >>> > >>>perf build is currently (v4.4-rc5) broken on powerpc: > >>> > >>>bpf.c:28:4: error: #error __NR_bpf not defined. libbpf does not support > >>>your arch. > >>> # error __NR_bpf not defined. libbpf does not support your arch. > >>> ^ > >>> > >>>Fix this by including tools/scripts/Makefile.arch for the proper > >>>$ARCH macro. While at it, remove redundant LP64 macro definition. > >>> > >>>Also, since libbpf require $(srctree) now, detect the path of > >>>srctree like perf. > >>> > >>>Signed-off-by: Naveen N. Rao > >>>Signed-off-by: Wang Nan > >>>Acked-by: Jiri Olsa > >>>Cc: Arnaldo Carvalho de Melo > >>>Cc: Sukadev Bhattiprolu > >>>--- > >>> > >>>v3 -> v4: Add srctree detector code so directly run 'make' in libbpf > >>> directory would not cause error. > >>Good catch! > >> > >>Tested-by: Naveen N. Rao > >Trying to apply the patchkit: > > > >[acme@zoo linux]$ make -C tools clean > /dev/null 2>&1 > >[acme@zoo linux]$ make -C tools/perf build-test > >make: Entering directory '/home/git/linux/tools/perf' > >Testing Makefile > >tests/make:15: /scripts/Makefile.arch: No such file or directory > >make[2]: *** No rule to make target '/scripts/Makefile.arch'. Stop. > >tests/make:5: recipe for target 'all' failed > >make[1]: *** [all] Error 2 > >Makefile:81: recipe for target 'build-test' failed > >make: *** [build-test] Error 2 > >make: Leaving directory '/home/git/linux/tools/perf' > >[acme@zoo linux]$ > > > >What am I doing wrong? > > You need all 3 patches. This v4 patch is a fix for previous v3 3/3 and I > send > this patch by replying that one. I thought your email client is sorted by > thread > so you can easily find it but it seems I was wrong... Arrgh! I see the confusion - your v4 didn't explicitly mention patch number 3, so that must have made Arnaldo think that this patch alone is enough. Perhaps [PATCH v4 3/3] would have been clearer. > > The whole thread is: > > [PATCH v3 0/3] perf build: PowerPC: Fix build breakage due to libbpf: > http://lkml.kernel.org/g/1450150557-127942-1-git-send-email-wangn...@huawei.com > > [PATCH v3 1/3] perf tools: Fix PowerPC native building > http://lkml.kernel.org/g/1450150557-127942-2-git-send-email-wangn...@huawei.com > > [PATCH v3 2/3] tools: Move Makefile.arch from perf/config to tools/scripts > http://lkml.kernel.org/g/1450150557-127942-3-git-send-email-wangn...@huawei.com > > [PATCH v3 3/3] perf: bpf: Fix build breakage due to libbpf > http://lkml.kernel.org/g/1450150557-127942-4-git-send-email-wangn...@huawei.com > > and [PATCH v3 3/3] breaks local building because the usage of "srctree", and ^^ You mean v4 here. Anyway, now that you've sent v4, it should be much clearer. Thanks, Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the rtc tree
Hi Alexandre,
After merging the rtc tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/built-in.o: In function `rtc_time64_to_tm':
sunxi_sid.c:(.text+0x366e54): undefined reference to `__aeabi_ldivmod'
sunxi_sid.c:(.text+0x366e6c): undefined reference to `__aeabi_ldivmod'
Caused by commit
bfad4c280be0 ("rtc: fix overflow and incorrect calculation in
rtc_time64_to_tm")
I have used the rtc tree from next-20151216 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
On 2015/12/17 13:48, Xishi Qiu wrote: > On 2015/12/17 10:53, Kamezawa Hiroyuki wrote: > >> On 2015/12/17 11:47, Xishi Qiu wrote: >>> On 2015/12/17 9:38, Izumi, Taku wrote: >>> Dear Xishi, Sorry for late. > -Original Message- > From: Xishi Qiu [mailto:qiuxi...@huawei.com] > Sent: Friday, December 11, 2015 6:44 PM > To: Izumi, Taku/泉 拓 > Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; > a...@linux-foundation.org; Kamezawa, Hiroyuki/亀澤 寛 > 之; m...@csn.ul.ie; Hansen, Dave; m...@codeblueprint.co.uk > Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option > > On 2015/12/11 13:53, Izumi, Taku wrote: > >> Dear Xishi, >> >>> Hi Taku, >>> >>> Whether it is possible that we rewrite the fallback function in buddy >>> system >>> when zone_movable and mirrored_kernelcore are both enabled? >> >> What does "when zone_movable and mirrored_kernelcore are both >> enabled?" mean ? >> >> My patchset just provides a new way to create ZONE_MOVABLE. >> > > Hi Taku, > >>> >>> Hi Taku, >>> >>> We can NOT specify kernelcore= "nn[KMG]" and "mirror" at the same time. >>> So when we use "mirror", in fact, the movable zone is a new zone. I think >>> it is >>> more appropriate with this name "mirrored zone", and also we can rewrite the >>> fallback function in buddy system in this case. >> >> kernelcore ="mirrored zone" ? > > No, it's zone_names[MAX_NR_ZONES] > How about "Movable", -> "Non-mirrored"? > That will break many user apps. I think we don't have enough reason. >> >> BTW, let me confirm. >> >>ZONE_NORMAL = mirrored >>ZONE_MOVABLE = not mirrored. >> > > Yes, > >> so, the new zone is "not-mirrored" zone. >> >> Now, fallback function is >> >> movable -> normal -> DMA. >> >> As Tony requested, we may need a knob to stop a fallback in >> "movable->normal", later. >> > > If the mirrored memory is small and the other is large, > I think we can both enable "non-mirrored -> normal" and "normal -> > non-mirrored". Size of mirrored memory can be configured by software(EFI var). So, having both is just overkill and normal->non-mirroed fallback is meaningless considering what the feature want to guarantee. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
On 2015/12/17 10:53, Kamezawa Hiroyuki wrote: > On 2015/12/17 11:47, Xishi Qiu wrote: >> On 2015/12/17 9:38, Izumi, Taku wrote: >> >>> Dear Xishi, >>> >>> Sorry for late. >>> -Original Message- From: Xishi Qiu [mailto:qiuxi...@huawei.com] Sent: Friday, December 11, 2015 6:44 PM To: Izumi, Taku/泉 拓 Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; a...@linux-foundation.org; Kamezawa, Hiroyuki/亀澤 寛 之; m...@csn.ul.ie; Hansen, Dave; m...@codeblueprint.co.uk Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option On 2015/12/11 13:53, Izumi, Taku wrote: > Dear Xishi, > >> Hi Taku, >> >> Whether it is possible that we rewrite the fallback function in buddy >> system >> when zone_movable and mirrored_kernelcore are both enabled? > >What does "when zone_movable and mirrored_kernelcore are both > enabled?" mean ? > >My patchset just provides a new way to create ZONE_MOVABLE. > Hi Taku, >> >> Hi Taku, >> >> We can NOT specify kernelcore= "nn[KMG]" and "mirror" at the same time. >> So when we use "mirror", in fact, the movable zone is a new zone. I think it >> is >> more appropriate with this name "mirrored zone", and also we can rewrite the >> fallback function in buddy system in this case. > > kernelcore ="mirrored zone" ? No, it's zone_names[MAX_NR_ZONES] How about "Movable", -> "Non-mirrored"? > > BTW, let me confirm. > > ZONE_NORMAL = mirrored > ZONE_MOVABLE = not mirrored. > Yes, > so, the new zone is "not-mirrored" zone. > > Now, fallback function is > >movable -> normal -> DMA. > > As Tony requested, we may need a knob to stop a fallback in > "movable->normal", later. > If the mirrored memory is small and the other is large, I think we can both enable "non-mirrored -> normal" and "normal -> non-mirrored". Thanks, Xishi Qiu > Thanks, > -Kame > > > > > > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Update for dcdbas driver
I guess it makes sense to add it. Thanks. Regards, G On Wednesday 16 December 2015 07:15 PM, Pali Rohár wrote: > On Wednesday 16 December 2015 14:53:04 srinivas_g_go...@dell.com wrote: >> >> Update Srinivas Gowda as dcdbas driver Maintainer >> >> Signed-off-by: Srinivas Gowda >> Acked-by: Doug Warzecha >> --- >> MAINTAINERS | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/MAINTAINERS b/MAINTAINERS >> index 79c2e48..7e3a8d5 100644 >> --- a/MAINTAINERS >> +++ b/MAINTAINERS >> @@ -3390,7 +3390,7 @@ F: drivers/hwmon/dell-smm-hwmon.c >> F: include/uapi/linux/i8k.h >> >> DELL SYSTEMS MANAGEMENT BASE DRIVER (dcdbas) >> -M: Doug Warzecha >> +M: Srinivas Gowda >> S: Maintained >> F: Documentation/dcdbas.txt >> F: drivers/firmware/dcdbas.* > > Hi! If you are CCing libsmbios ML maybe it could make sense to add > libsmbios-de...@lists.us.dell.com ML into that MAINTAINERS list? >
[PATCH v2] MAINTAINERS: Update for dcdbas driver
Update Srinivas Gowda as dcdbas driver Maintainer. Also adding relevant mailing list to this version of the patch Signed-off-by: Srinivas Gowda Acked-by: Doug Warzecha --- MAINTAINERS | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 79c2e48..60d598a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3390,7 +3390,8 @@ F:drivers/hwmon/dell-smm-hwmon.c F: include/uapi/linux/i8k.h DELL SYSTEMS MANAGEMENT BASE DRIVER (dcdbas) -M: Doug Warzecha +M: Srinivas Gowda +L: libsmbios-de...@lists.us.dell.com S: Maintained F: Documentation/dcdbas.txt F: drivers/firmware/dcdbas.* -- 1.9.1
Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2
On 2015/12/17 12:32, Johannes Weiner wrote: On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote: On 2015/12/16 20:09, Johannes Weiner wrote: On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: - swap-full notification via vmpressure or something mechanism. Why? I think it's a sign of unhealthy condition, starting file cache drop rate to rise. But I forgot that there are resource threshold notifier already. Does the notifier work for swap.usage ? That will be reflected in vmpressure or other distress mechanisms. I'm not convinced "ran out of swap space" needs special casing in any way. Most users checks swap space shortage as "system alarm" in enterprise systems. At least, our customers checks swap-full. - force swap-in at reducing swap.limit Why? If full, swap.limit cannot be reduced even if there are available memory in a cgroup. Another cgroup cannot make use of the swap resource while it's occupied by other cgroup. The job scheduler should have a chance to fix the situation. I don't see why swap space allowance would need to be as dynamically adjustable as the memory allowance. There is usually no need to be as tight with swap space as with memory, and the performance penalty of swapping, even with flash drives, is high enough that swap space acts as an overflow vessel rather than be part of the regularly backing of the anonymous/shmem working set. It really is NOT obvious that swap space would need to be adjusted on the fly, and that it's important that reducing the limit will be reflected in consumption right away. With my OS support experience, some customers consider swap-space as a resource. We shouldn't be adding hundreds of lines of likely terrible heuristics code* on speculation that somebody MIGHT find this useful in real life. We should wait until we are presented with a real usecase that applies to a whole class of users, and then see what the true requirements are. ok, we should wait. I'm just guessing (japanese) HPC people will want the feature for their job control. I hear many programs relies on swap. * If a group has 200M swapped out and the swap limit is reduced by 10M below the current consumption, which pages would you swap in? There is no LRU list for swap space. If a rotation can happen when a swap-in-by-real-pagefault, random swap-in at reducing swap.limit will work enough. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf kvm record/report: 'unprocessable sample' error while recording/reporting guest data
Hi acme,
I sent this patch few days ago. Unfortunately nobody has payed attention.
Can you please pick this up.
Regards,
Ravi
On Monday 07 December 2015 12:25 PM, Ravi Bangoria wrote:
While recording guest samples in host using perf kvm record, it will
populate unprocessable sample error, though samples will be recorded
properly. While generating report using perf kvm report, no samples will
be processed and same error will populate. We have seen this behaviour
with upstream perf(4.4-rc3) on x86 and ppc64 hardware.
Reason behind this failure is, when it tries to fetch machine from rb_tree
of machines, it fails. As a part of tracing a bug, we figured out that this
code was incorrectly refactored in commit
54245fdc357613633954bfd38cffb71cb9def067
("perf session: Remove wrappers to machines__find")
This patch will change the functionality such that if it can't fetch
machine in first trial, it will create one node of machine and add that to
rb_tree. So next time when it tries to fetch same machine from rb_tree,
it won't fail. Actually it was the case before refactoring of code in
aforementioned commit.
This patch is generated from acme perf/core branch.
Below I've mention an example that demonstrate the behaviour before and
after applying patch.
Before applying patch:
[Note: One needs to run guest before recording data in host]
ravi@ravi-bangoria:~$ ./perf kvm record -a
Warning:
5903 unprocessable samples recorded.
Do you have a KVM guest running and not using 'perf kvm'?
[ perf record: Captured and wrote 1.409 MB perf.data.guest (285 samples) ]
ravi@ravi-bangoria:~$ ./perf kvm report --stdio
Warning:
5903 unprocessable samples recorded.
Do you have a KVM guest running and not using 'perf kvm'?
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 285 of event 'cycles'
# Event count (approx.): 88715406
#
# Overhead Command Shared Object Symbol
# ... . ..
#
#
# (For a higher level overview, try: perf report --sort comm,dso)
#
After applying patch:
ravi@ravi-bangoria:~$ ./perf kvm record -a
[ perf record: Captured and wrote 1.188 MB perf.data.guest (17 samples) ]
ravi@ravi-bangoria:~$ ./perf kvm report --stdio
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 17 of event 'cycles'
# Event count (approx.): 700746
#
# Overhead Command Shared Object Symbol
# ... ..
#
34.19% :5758[unknown] [g] 0x818682ab
22.79% :5758[unknown] [g] 0x812dc7f8
22.79% :5758[unknown] [g] 0x818650d0
14.83% :5758[unknown] [g] 0x8161a1b6
2.49% :5758[unknown] [g] 0x818692bf
0.48% :5758[unknown] [g] 0x81869253
0.05% :5758[unknown] [g] 0x81869250
Signed-off-by: Ravi Bangoria
---
tools/perf/util/session.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index c35ffdd..468de95 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -972,7 +972,7 @@ static struct machine *machines__find_for_cpumode(struct
machines *machines,
machine = machines__find(machines, pid);
if (!machine)
- machine = machines__find(machines,
DEFAULT_GUEST_KERNEL_ID);
+ machine = machines__findnew(machines,
DEFAULT_GUEST_KERNEL_ID);
return machine;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/11] KVM: MMU: use page track for non-leaf shadow pages
On 12/17/2015 10:44 AM, Kai Huang wrote:
On 12/16/2015 04:39 PM, Xiao Guangrong wrote:
On 12/16/2015 03:51 PM, Kai Huang wrote:
On 12/15/2015 05:10 PM, Xiao Guangrong wrote:
On 12/15/2015 03:52 PM, Kai Huang wrote:
static bool __mmu_gfn_lpage_is_disallowed(gfn_t gfn, int level,
@@ -2140,12 +2150,18 @@ static struct kvm_mmu_page *kvm_mmu_get_page(struct
kvm_vcpu *vcpu,
hlist_add_head(>hash_link,
>kvm->arch.mmu_page_hash[kvm_page_table_hashfn(gfn)]);
if (!direct) {
-if (rmap_write_protect(vcpu, gfn))
+/*
+ * we should do write protection before syncing pages
+ * otherwise the content of the synced shadow page may
+ * be inconsistent with guest page table.
+ */
+account_shadowed(vcpu->kvm, sp);
+
+if (level == PT_PAGE_TABLE_LEVEL &&
+ rmap_write_protect(vcpu, gfn))
kvm_flush_remote_tlbs(vcpu->kvm);
I think your modification is good but I am little bit confused here. In
account_shadowed, if
sp->role.level > PT_PAGE_TABLE_LEVEL, the sp->gfn is write protected, and this
is reasonable.
So why
write protecting the gfn of PT_PAGE_TABLE_LEVEL here?
Because the shadow page will become 'sync' that means the shadow page will be
synced
with the page table in guest. So the shadow page need to be write-protected to
avoid
the guest page table is changed when we do the 'sync' thing.
The shadow page need to be write-protected to avoid that guest page table is
changed
when we are syncing the shadow page table. See kvm_sync_pages() after doing
rmap_write_protect().
I see. So why are you treat PT_PAGE_TABLE_LEVEL gfn separately here? why this
cannot be done in
account_shadowed, as you did for upper level sp?
non-leaf shadow pages are keepking write-protected which page fault handler can
not fix write
access on it. And leaf shadow pages are not.
My point is the original code didn't separate the two cases so I am not sure
why you need to
separate. Perhaps you want to make account_shadowed imply the non-leaf guest
page table is
write-protected while leaf page table is not.
That is why we get improvement after this patchset, we seep up the case for the
write access
happens on non-leaf page tables. ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 7/9] perf: Finalize subcmd independence
On Wed, Dec 16, 2015 at 10:27:11PM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Dec 16, 2015 at 07:09:53PM -0600, Josh Poimboeuf escreveu: > > On Wed, Dec 16, 2015 at 09:57:41PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Dec 15, 2015 at 09:39:38AM -0600, Josh Poimboeuf escreveu: > > > > For the files that will be moved to the subcmd library, remove all their > > > > perf-specific includes and duplicate any needed functionality. > > > > > > Breaks rhel6.7 building: > > > > > > > > > > > +typedef uint64_t u64; > > > > + > > > > > > > > > [acme@sandy linux]$ cat /etc/redhat-release > > > Red Hat Enterprise Linux Server release 6.7 (Santiago) > > > > > > CC /tmp/build/perf/parse-options.o > > > parse-options.c:15: error: redefinition of typedef ‘u64’ > > > /home/acme/git/linux/tools/include/linux/types.h:28: note: previous > > > declaration of ‘u64’ was here > > > mv: cannot stat `/tmp/build/perf/.parse-options.o.tmp': No such file or > > > directory > > > make[3]: *** [/tmp/build/perf/parse-options.o] Error 1 > > > make[2]: *** [/tmp/build/perf/libsubcmd-in.o] Error 2 > > > make[1]: *** [/tmp/build/perf/libsubcmd.a] Error 2 > > > make[1]: *** Waiting for unfinished jobs > > > MKDIR/tmp/build/perf/util/ > > > > Does this fix it? > > Yes, and it continues to build on fedora 21. > > - Arnaldo > > > ---8<--- > > > > diff --git a/tools/lib/subcmd/parse-options.c > > b/tools/lib/subcmd/parse-options.c > > index f424027..981bb44 100644 > > --- a/tools/lib/subcmd/parse-options.c > > +++ b/tools/lib/subcmd/parse-options.c > > @@ -1,4 +1,5 @@ > > #include > > +#include > > #include > > #include > > #include > > @@ -12,8 +13,6 @@ > > #define OPT_SHORT 1 > > #define OPT_UNSET 2 > > > > -typedef uint64_t u64; > > - > > char *error_buf; > > > > static int opterror(const struct option *opt, const char *reason, int > > flags) Here's the same patch but without the unnecessary addition of the include. Ideally it would be folded into "perf tools: Finalize subcmd independence" but in case it's too late for that, I added a changelog. ---8<--- Subject: [PATCH] tools subcmd: Fix 'u64' build error with older compilers Arnaldo reported the following error when building perf on RHEL 6.7: parse-options.c:15: error: redefinition of typedef ‘u64’ /home/acme/git/linux/tools/include/linux/types.h:28: note: previous declaration of ‘u64’ was here The parse-options.c file includes , which includes , which has a u64 typedef. So the u64 typedef in parse-options.c is unnecessary (and seems to trigger the above error on compilers which don't allow duplicate typedefs). Reported-by: Arnaldo Carvalho de Melo Signed-off-by: Josh Poimboeuf --- tools/lib/subcmd/parse-options.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/tools/lib/subcmd/parse-options.c b/tools/lib/subcmd/parse-options.c index f424027..c0c911a 100644 --- a/tools/lib/subcmd/parse-options.c +++ b/tools/lib/subcmd/parse-options.c @@ -12,8 +12,6 @@ #define OPT_SHORT 1 #define OPT_UNSET 2 -typedef uint64_t u64; - char *error_buf; static int opterror(const struct option *opt, const char *reason, int flags) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Input: add touchscreen support for TS-4800
Hi Damien,
On Thu, Dec 10, 2015 at 11:11:12AM -0500, Damien Riegel wrote:
> On this board, the touchscreen, an ads7843, is not handled directly by
> Linux but by a companion FPGA. This FPGA is memory-mapped and the IP
> design is very similar to the mk712.
>
> This commit adds the support for this IP.
>
> Signed-off-by: Damien Riegel
> ---
> drivers/input/touchscreen/Kconfig | 15 +++
> drivers/input/touchscreen/Makefile| 1 +
> drivers/input/touchscreen/ts4800-ts.c | 238
> ++
> 3 files changed, 254 insertions(+)
> create mode 100644 drivers/input/touchscreen/ts4800-ts.c
>
> diff --git a/drivers/input/touchscreen/Kconfig
> b/drivers/input/touchscreen/Kconfig
> index deb14c1..2d3b2f2 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -914,6 +914,21 @@ config TOUCHSCREEN_TOUCHIT213
>To compile this driver as a module, choose M here: the
>module will be called touchit213.
>
> +config TOUCHSCREEN_TS4800
> + tristate "TS-4800 touchscreen"
> + depends on HAS_IOMEM && OF
> + select MFD_SYSCON
You also need "select INPUT_POLLDEV" here.
> + help
> + Say Y here if you have a touchscreen on a TS-4800 board.
> +
> + On TS-4800, the touchscreen is not handled directly by Linux but by
> + a companion FPGA.
> +
> + If unsure, say N.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ts4800_ts.
> +
> config TOUCHSCREEN_TSC_SERIO
> tristate "TSC-10/25/40 serial touchscreen support"
> select SERIO
> diff --git a/drivers/input/touchscreen/Makefile
> b/drivers/input/touchscreen/Makefile
> index 1b79cc0..5d81ba8c 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_TOUCHSCREEN_TI_AM335X_TSC) += ti_am335x_tsc.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o
> obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o
> +obj-$(CONFIG_TOUCHSCREEN_TS4800) += ts4800-ts.o
> obj-$(CONFIG_TOUCHSCREEN_TSC_SERIO) += tsc40.o
> obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o
> obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o
> diff --git a/drivers/input/touchscreen/ts4800-ts.c
> b/drivers/input/touchscreen/ts4800-ts.c
> new file mode 100644
> index 000..1e81b17
> --- /dev/null
> +++ b/drivers/input/touchscreen/ts4800-ts.c
> @@ -0,0 +1,238 @@
> +/*
> + * Touchscreen driver for the TS-4800 board
> + *
> + * Copyright (c) 2015 - Savoir-faire Linux
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* polling interval in ms*/
> +#define POLL_INTERVAL 3
> +
> +/* sensor values are 12-bit wide */
> +#define MAX_12BIT ((1 << 12) - 1)
> +
> +#define PENDOWN_MASK0x1
> +
> +#define X_OFFSET0x0
> +#define Y_OFFSET0x2
> +
> +struct ts4800_ts {
> + struct input_polled_dev *poll_dev;
> + struct device *dev;
> + charphys[32];
> +
> + void __iomem*base;
> + struct regmap *regmap;
> + unsigned intreg;
> + unsigned intbit;
> +
> + boolpendown;
> + int debounce;
> +};
> +
> +static void ts4800_ts_open(struct input_polled_dev *dev)
> +{
> + struct ts4800_ts *ts = dev->private;
> + int ret;
> +
> + ret = regmap_update_bits(ts->regmap, ts->reg,
> + 1 << ts->bit, 1 << ts->bit);
Instead of doing shift every time you can store already shifted value in
ts->bit.
> + if (ret)
> + dev_warn(ts->dev, "Failed to enable touchscreen\n");
> +}
> +
> +static void ts4800_ts_close(struct input_polled_dev *dev)
> +{
> + struct ts4800_ts *ts = dev->private;
> + int ret;
> +
> + ret = regmap_update_bits(ts->regmap, ts->reg,
> + 1 << ts->bit, 0);
> + if (ret)
> + dev_warn(ts->dev, "Failed to disable touchscreen\n");
> +
> +}
> +
> +static void ts4800_ts_poll(struct input_polled_dev *dev)
> +{
> + struct input_dev *input_dev = dev->input;
> + struct ts4800_ts *ts = dev->private;
> + u16 last_x = readw(ts->base + X_OFFSET);
> + u16 last_y = readw(ts->base + Y_OFFSET);
> + bool pendown = last_x & PENDOWN_MASK;
> +
> + if (!pendown && ts->pendown) {
> + ts->pendown = false;
> + ts->debounce = 1;
> + input_report_key(input_dev, BTN_TOUCH, 0);
> + input_sync(input_dev);
> + }
> +
> + if (pendown) {
> + if (ts->debounce) {
> + ts->debounce = 0;
This looks like a boolean, but I think having a counter for debounce is
more natural.
> + return;
> + }
> +
> + if (!ts->pendown) {
> + input_report_key(input_dev, BTN_TOUCH, 1);
> + ts->pendown = true;
> + }
> +
> + last_x = ((~last_x) >> 4) & MAX_12BIT;
> + last_y = ((~last_y) >> 4) &
Re: block layer bug with 4.4-rc3+
On Wed, Dec 16, 2015 at 11:43 PM, Arnd Bergmann wrote: > On Wednesday 16 December 2015 14:55:43 Andre Przywara wrote: >> Using the plain multi_v7_defconfig (which doesn't have LPAE and makes me >> loose half of the RAM on that box) didn't show the bug so far. >> One of the effects of turning on LPAE is that dma_addr_t and phys_addr_t >> turn to 64-bit, with long, int and void* still being 32-bit. Can you >> think of any issues that could be related to that? >> > > Another difference between the platforms is highmem. On Midway, > almost all of RAM is highmem, which needs a lot of special handling > that we don't need on platform with less RAM. Yeah, block bounce can be triggered for highmem generally. > > To rule out both of highmem and LPAE, it might be interesting to > test again on Midway with CONFIG_HIGHMEM and CONFIG_LPAE disabled. > This will limit the RAM to 768MB, but if the bug still shows up, > you know it's something else. > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-block" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: block layer bug with 4.4-rc3+
On Wed, Dec 16, 2015 at 10:55 PM, Andre Przywara wrote:
> Hi,
>
> On 15/12/15 13:39, Ming Lei wrote:
>> On Tue, Dec 15, 2015 at 8:23 PM, Andre Przywara
>> wrote:
>>> Hi Ming,
>>>
>>> thanks for the answer!
>>>
>>> On 15/12/15 11:54, Ming Lei wrote:
On Tue, Dec 15, 2015 at 7:05 PM, Andre Przywara
wrote:
> Hi,
>
> I've been experiencing issues with at least 4.4-rc3 (including current
I'd suggest you to test the latest linus tree first, and at least two
fix patches
have been merged for blk-merge issue. If there is still the issue
with linus tree,
I am happy to take a look.
>>>
>>> Mmh, as said ("including current HEAD") this happens still with the
>>> latest HEAD from Linus (which is "9f9499ae8e64: Linux 4.4-rc5" for me).
>>> Just tested yesterday.
>>> Is there another branch/tree with block fixes I should test? Is it worth
>>> to try any of the upcoming branches in linux-block.git (for-4.5/core,
>>> maybe?)
>>
>> Both the fixes have been in linus tree already, and reverting the commit
>> basically makes merge not possible, so there must be issues somewhere.
>>
>> And can you see the issue on other 32bit ARM platform? I don't see the
>> issue on x86 and arm64, and the commit itself is correct, IMO.
>
> Quick tests on a Cubietruck didn't show the issue, but this board is
> nowhere near the Midway (2 in-order cores with 2GB RAM vs. 4
> out-of-order cores with 8 GB RAM), so the load isn't the same.
> I could rule out .config issues by using multi_v7_defconfig - with LPAE
> enabled on top, that is.
> Using the plain multi_v7_defconfig (which doesn't have LPAE and makes me
> loose half of the RAM on that box) didn't show the bug so far.
> One of the effects of turning on LPAE is that dma_addr_t and phys_addr_t
> turn to 64-bit, with long, int and void* still being 32-bit. Can you
> think of any issues that could be related to that?
>
> Also can you briefly sketch what that patch (578270bfbd) eventually
> changes? I see that the fix looks right, I am just wondering what the
> impact is: Do we get more blocks or less or bigger ones or smaller?
Without the change, 'bvprvp' always points to 'bv', then each bio vector
can't be merged to other bio vector, so each bvec becomes one single
physical segment(convert to one single sg element in driver), finally the
transfer size for each bio becomes much smaller, and size of each
segment becomes much smaller, but segment number may become
bigger.
>
> I will try to do more experiments and to find the real culprit.
It may be helpful to enable 'block:*' trace events, and get/analyze the
traces close to the kernel warning.
>
> Thanks,
> Andre.
>
>>
>>>
>>> Thanks,
>>> Andre.
>>>
Thanks,
> HEAD) on a Calxeda Midway (4*ARM Cortex-A15 (32-bit), 8GB RAM, SATA
> spinning disk or SSD).
> After some disk I/O load (kernel compile with -j6) I see the kernel
> screaming:
>
> [ 103.736982] ata1.00: exception Emask 0x0 SAct 0x30 SErr 0x0
> action 0x6 frozen
> [ 103.744476] ata1.00: failed command: WRITE FPDMA QUEUED
> [ 103.749707] ata1.00: cmd 61/00:20:48:6b:41/08:00:0a:00:00/40 tag 4
> ncq 1048576 out
> [ 103.749707] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> [ 103.764659] ata1.00: status: { DRDY }
> [ 103.768321] ata1.00: failed command: WRITE FPDMA QUEUED
> [ 103.773547] ata1.00: cmd 61/98:28:48:73:41/42:00:0a:00:00/40 tag 5
> ncq 8728576 out
> [ 103.773547] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask
> 0x4 (timeout)
> < repeated with increasing tag numbers>
>
> This repeats for a while, but then seems to recover later, though I
> haven't checked if there are more issues and rebooted instead to avoid
> filesystem damage.
>
> While I agree that this looks like a disk error on the first glance, I
> never saw this before 4.4-rc2, had the very same error on different
> nodes (with another spinning disk and even an SSD) and I can make it
> vanish by reverting the commit I identified after bisection:
>
> commit 578270bfbd2803dc7b0b03fbc2ac119efbc73195
> Author: Ming Lei
> Date: Tue Nov 24 10:35:29 2015 +0800
>
> block: fix segment split
> ...
> I understand that this fix seems sane, but actually reverting it fixes
> the issue for me: 4.4-rc5 crashed within some minutes with the above
> log, 4.4-rc5 with 578270bfbd reverted survived 19 hours of continuous
> kernel compiles without issues.
> Looking at the git history of that file I see quite some recent changes
> there, but it's beyond my understanding of the code to spot the real
> culprit.
>
> Can anyone point me to a change in blk-merge.c I could try to revert to
> identify the real root cause? I can run tests quickly, though a real
> positive case would need some hours of runtime to be sure it's fine.
>
> Many thanks!
[PATCH 6/6] dt-bindings: add document for rk3036-vop
Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Ian Campbell Cc: Kumar Gala Cc: devicet...@vger.kernel.org Signed-off-by: Mark Yao --- .../bindings/display/rockchip/rockchip-vop.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt index d15351f..5489b59 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -7,6 +7,7 @@ buffer to an external LCD interface. Required properties: - compatible: value should be one of the following "rockchip,rk3288-vop"; + "rockchip,rk3036-vop"; - interrupts: should contain a list of all VOP IP block interrupts in the order: VSYNC, LCD_SYSTEM. The interrupt specifier -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] drm/rockchip: vop: add rk3036 vop support
RK3036 registers layout is quite difference with rk3288 layout,
The IC design with different framework, rk3036 vop is VOP LITE,
and rk3288 is VOP FULL.
RK3036 support two overlay plane and one hwc plane, max output
resolution is 1080p. it support IOMMU, and its IOMMU same as
rk3288's.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 296 +--
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 243 +-
2 files changed, 336 insertions(+), 203 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 6495114..3166b46 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -25,7 +25,7 @@
.mask = _mask, \
.shift = s,}
-static const uint32_t formats_01[] = {
+static const uint32_t formats_win_full[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
@@ -39,7 +39,7 @@ static const uint32_t formats_01[] = {
DRM_FORMAT_NV24,
};
-static const uint32_t formats_234[] = {
+static const uint32_t formats_win_lite[] = {
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
DRM_FORMAT_XBGR,
@@ -50,102 +50,103 @@ static const uint32_t formats_234[] = {
DRM_FORMAT_BGR565,
};
-static const struct vop_scl_extension win_full_ext = {
- .cbcr_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 31),
- .cbcr_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 30),
- .cbcr_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 28),
- .cbcr_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 26),
- .cbcr_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 24),
- .yrgb_vsd_mode = VOP_REG(WIN0_CTRL1, 0x1, 23),
- .yrgb_vsu_mode = VOP_REG(WIN0_CTRL1, 0x1, 22),
- .yrgb_hsd_mode = VOP_REG(WIN0_CTRL1, 0x3, 20),
- .yrgb_ver_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 18),
- .yrgb_hor_scl_mode = VOP_REG(WIN0_CTRL1, 0x3, 16),
- .line_load_mode = VOP_REG(WIN0_CTRL1, 0x1, 15),
- .cbcr_axi_gather_num = VOP_REG(WIN0_CTRL1, 0x7, 12),
- .yrgb_axi_gather_num = VOP_REG(WIN0_CTRL1, 0xf, 8),
- .vsd_cbcr_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 7),
- .vsd_cbcr_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 6),
- .vsd_yrgb_gt2 = VOP_REG(WIN0_CTRL1, 0x1, 5),
- .vsd_yrgb_gt4 = VOP_REG(WIN0_CTRL1, 0x1, 4),
- .bic_coe_sel = VOP_REG(WIN0_CTRL1, 0x3, 2),
- .cbcr_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 1),
- .yrgb_axi_gather_en = VOP_REG(WIN0_CTRL1, 0x1, 0),
- .lb_mode = VOP_REG(WIN0_CTRL0, 0x7, 5),
-};
-
-static const struct vop_scl_regs win_full_scl = {
- .scale_yrgb_x = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 0x0),
- .scale_yrgb_y = VOP_REG(WIN0_SCL_FACTOR_YRGB, 0x, 16),
- .scale_cbcr_x = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 0x0),
- .scale_cbcr_y = VOP_REG(WIN0_SCL_FACTOR_CBR, 0x, 16),
-};
-
-static const struct vop_win_phy win01_data = {
- .scl = _full_scl,
- .data_formats = formats_01,
- .nformats = ARRAY_SIZE(formats_01),
- .enable = VOP_REG(WIN0_CTRL0, 0x1, 0),
- .format = VOP_REG(WIN0_CTRL0, 0x7, 1),
- .rb_swap = VOP_REG(WIN0_CTRL0, 0x1, 12),
- .act_info = VOP_REG(WIN0_ACT_INFO, 0x1fff1fff, 0),
- .dsp_info = VOP_REG(WIN0_DSP_INFO, 0x0fff0fff, 0),
- .dsp_st = VOP_REG(WIN0_DSP_ST, 0x1fff1fff, 0),
- .yrgb_mst = VOP_REG(WIN0_YRGB_MST, 0x, 0),
- .uv_mst = VOP_REG(WIN0_CBR_MST, 0x, 0),
- .yrgb_vir = VOP_REG(WIN0_VIR, 0x3fff, 0),
- .uv_vir = VOP_REG(WIN0_VIR, 0x3fff, 16),
- .src_alpha_ctl = VOP_REG(WIN0_SRC_ALPHA_CTRL, 0xff, 0),
- .dst_alpha_ctl = VOP_REG(WIN0_DST_ALPHA_CTRL, 0xff, 0),
-};
-
-static const struct vop_win_phy win23_data = {
- .data_formats = formats_234,
- .nformats = ARRAY_SIZE(formats_234),
- .enable = VOP_REG(WIN2_CTRL0, 0x1, 0),
- .format = VOP_REG(WIN2_CTRL0, 0x7, 1),
- .rb_swap = VOP_REG(WIN2_CTRL0, 0x1, 12),
- .dsp_info = VOP_REG(WIN2_DSP_INFO0, 0x0fff0fff, 0),
- .dsp_st = VOP_REG(WIN2_DSP_ST0, 0x1fff1fff, 0),
- .yrgb_mst = VOP_REG(WIN2_MST0, 0x, 0),
- .yrgb_vir = VOP_REG(WIN2_VIR0_1, 0x1fff, 0),
- .src_alpha_ctl = VOP_REG(WIN2_SRC_ALPHA_CTRL, 0xff, 0),
- .dst_alpha_ctl = VOP_REG(WIN2_DST_ALPHA_CTRL, 0xff, 0),
-};
-
-static const struct vop_ctrl ctrl_data = {
- .standby = VOP_REG(SYS_CTRL, 0x1, 22),
- .gate_en = VOP_REG(SYS_CTRL, 0x1, 23),
- .mmu_en = VOP_REG(SYS_CTRL, 0x1, 20),
- .rgb_en = VOP_REG(SYS_CTRL, 0x1, 12),
- .hdmi_en = VOP_REG(SYS_CTRL, 0x1, 13),
- .edp_en = VOP_REG(SYS_CTRL, 0x1, 14),
- .mipi_en = VOP_REG(SYS_CTRL, 0x1, 15),
- .dither_down = VOP_REG(DSP_CTRL1, 0xf, 1),
- .dither_up = VOP_REG(DSP_CTRL1, 0x1, 6),
- .data_blank = VOP_REG(DSP_CTRL0, 0x1, 19),
- .out_mode = VOP_REG(DSP_CTRL0, 0xf, 0),
- .pin_pol = VOP_REG(DSP_CTRL0, 0xf,
[PATCH 0/6] add rk3036 vop support
This series of patches add rk3036 vop support. RK3036 registers layout is quite difference with rk3288 layout, The IC design with different framework, rk3036 vop is VOP LITE, and rk3288 is VOP FULL. RK3036 support two overlay plane and one hwc plane, max output resolution is 1080p. it support IOMMU, and its IOMMU same as rk3288's. This patches is based on drm/rockchip atomic patches. [0] Tested on kylin board, kylin runs on 4.1 kernel. backport to 4.1, and picked Yakir Yang's inno hdmi patches [1]. works with test program atomictest[2] and modetest. [0]: https://lkml.org/lkml/2015/12/16/824 [1]: https://lkml.org/lkml/2015/11/11/53 [2]: https://github.com/markyzq/libdrm.git atomictest Mark Yao (6): drm/rockchip: vop: merge vop cfg_done into vop_data drm/rockchip: vop: move interrupt registers into vop_data drm/rockchip: vop: spilt register related into rockchip_reg_vop.c drm/rockchip: vop: spilt scale regsters to common and extension drm/rockchip: vop: add rk3036 vop support dt-bindings: add document for rk3036-vop .../bindings/display/rockchip/rockchip-vop.txt |1 + drivers/gpu/drm/rockchip/Makefile |3 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c| 411 drivers/gpu/drm/rockchip/rockchip_drm_vop.h| 230 ++- drivers/gpu/drm/rockchip/rockchip_vop_reg.c| 316 +++ drivers/gpu/drm/rockchip/rockchip_vop_reg.h| 169 6 files changed, 696 insertions(+), 434 deletions(-) create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.c create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] drm/rockchip: vop: spilt register related into rockchip_reg_vop.c
No functional updates. Spilt register related into another file
would be nice to multi vop driver,
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/Makefile |3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 325 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 220 +-
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 225 +++
drivers/gpu/drm/rockchip/rockchip_vop_reg.h | 124 ++
5 files changed, 468 insertions(+), 429 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.c
create mode 100644 drivers/gpu/drm/rockchip/rockchip_vop_reg.h
diff --git a/drivers/gpu/drm/rockchip/Makefile
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..a9d380f 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,4 +7,5 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o
rockchip_drm_fbdev.o \
obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
-obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
+obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o \
+ rockchip_vop_reg.o
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7674bdc..bbb781c 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -36,11 +36,6 @@
#include "rockchip_drm_fb.h"
#include "rockchip_drm_vop.h"
-#define VOP_REG(off, _mask, s) \
- {.offset = off, \
-.mask = _mask, \
-.shift = s,}
-
#define __REG_SET_RELAXED(x, off, mask, shift, v) \
vop_mask_write_relaxed(x, off, (mask) << shift, (v) << shift)
#define __REG_SET_NORMAL(x, off, mask, shift, v) \
@@ -143,285 +138,6 @@ struct vop {
struct vop_win win[];
};
-enum vop_data_format {
- VOP_FMT_ARGB = 0,
- VOP_FMT_RGB888,
- VOP_FMT_RGB565,
- VOP_FMT_YUV420SP = 4,
- VOP_FMT_YUV422SP,
- VOP_FMT_YUV444SP,
-};
-
-struct vop_reg_data {
- uint32_t offset;
- uint32_t value;
-};
-
-struct vop_reg {
- uint32_t offset;
- uint32_t shift;
- uint32_t mask;
-};
-
-struct vop_ctrl {
- struct vop_reg standby;
- struct vop_reg data_blank;
- struct vop_reg gate_en;
- struct vop_reg mmu_en;
- struct vop_reg rgb_en;
- struct vop_reg edp_en;
- struct vop_reg hdmi_en;
- struct vop_reg mipi_en;
- struct vop_reg out_mode;
- struct vop_reg dither_down;
- struct vop_reg dither_up;
- struct vop_reg pin_pol;
-
- struct vop_reg htotal_pw;
- struct vop_reg hact_st_end;
- struct vop_reg vtotal_pw;
- struct vop_reg vact_st_end;
- struct vop_reg hpost_st_end;
- struct vop_reg vpost_st_end;
-
- struct vop_reg cfg_done;
-};
-
-struct vop_intr {
- const int *intrs;
- uint32_t nintrs;
- struct vop_reg enable;
- struct vop_reg clear;
- struct vop_reg status;
-};
-struct vop_scl_regs {
- struct vop_reg cbcr_vsd_mode;
- struct vop_reg cbcr_vsu_mode;
- struct vop_reg cbcr_hsd_mode;
- struct vop_reg cbcr_ver_scl_mode;
- struct vop_reg cbcr_hor_scl_mode;
- struct vop_reg yrgb_vsd_mode;
- struct vop_reg yrgb_vsu_mode;
- struct vop_reg yrgb_hsd_mode;
- struct vop_reg yrgb_ver_scl_mode;
- struct vop_reg yrgb_hor_scl_mode;
- struct vop_reg line_load_mode;
- struct vop_reg cbcr_axi_gather_num;
- struct vop_reg yrgb_axi_gather_num;
- struct vop_reg vsd_cbcr_gt2;
- struct vop_reg vsd_cbcr_gt4;
- struct vop_reg vsd_yrgb_gt2;
- struct vop_reg vsd_yrgb_gt4;
- struct vop_reg bic_coe_sel;
- struct vop_reg cbcr_axi_gather_en;
- struct vop_reg yrgb_axi_gather_en;
-
- struct vop_reg lb_mode;
- struct vop_reg scale_yrgb_x;
- struct vop_reg scale_yrgb_y;
- struct vop_reg scale_cbcr_x;
- struct vop_reg scale_cbcr_y;
-};
-
-struct vop_win_phy {
- const struct vop_scl_regs *scl;
- const uint32_t *data_formats;
- uint32_t nformats;
-
- struct vop_reg enable;
- struct vop_reg format;
- struct vop_reg rb_swap;
- struct vop_reg act_info;
- struct vop_reg dsp_info;
- struct vop_reg dsp_st;
- struct vop_reg yrgb_mst;
- struct vop_reg uv_mst;
- struct vop_reg yrgb_vir;
- struct vop_reg uv_vir;
-
- struct vop_reg dst_alpha_ctl;
- struct vop_reg src_alpha_ctl;
-};
-
-struct vop_win_data {
- uint32_t base;
- const struct vop_win_phy *phy;
- enum drm_plane_type type;
-};
-
-struct vop_data {
- const struct vop_reg_data *init_table;
- unsigned int table_size;
- const struct vop_ctrl *ctrl;
- const struct vop_intr *intr;
- const struct vop_win_data *win;
- unsigned int win_size;
-};
-
[PATCH 4/6] drm/rockchip: vop: spilt scale regsters
There are two version scale control register found on vop,
scale full version found on rk3288, support extension registers.
and scale little version found on rk3036, only support common scale.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 46 ++-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 14 ++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.c |5 ++-
3 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index bbb781c..d83bf87 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -50,6 +50,8 @@
REG_SET(x, win->base, win->phy->name, v, RELAXED)
#define VOP_SCL_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->scl->name, v, RELAXED)
+#define VOP_SCL_SET_EXT(x, win, name, v) \
+ REG_SET(x, win->base, win->phy->scl->ext->name, v, RELAXED)
#define VOP_CTRL_SET(x, name, v) \
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
@@ -313,6 +315,20 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
return;
}
+ if (!win->phy->scl->ext) {
+ VOP_SCL_SET(vop, win, scale_yrgb_x,
+ scl_cal_scale2(src_w, dst_w));
+ VOP_SCL_SET(vop, win, scale_yrgb_y,
+ scl_cal_scale2(src_h, dst_h));
+ if (is_yuv) {
+ VOP_SCL_SET(vop, win, scale_cbcr_x,
+ scl_cal_scale2(src_w, dst_w));
+ VOP_SCL_SET(vop, win, scale_cbcr_y,
+ scl_cal_scale2(src_h, dst_h));
+ }
+ return;
+ }
+
yrgb_hor_scl_mode = scl_get_scl_mode(src_w, dst_w);
yrgb_ver_scl_mode = scl_get_scl_mode(src_h, dst_h);
@@ -330,7 +346,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
lb_mode = scl_vop_cal_lb_mode(src_w, false);
}
- VOP_SCL_SET(vop, win, lb_mode, lb_mode);
+ VOP_SCL_SET_EXT(vop, win, lb_mode, lb_mode);
if (lb_mode == LB_RGB_3840X2) {
if (yrgb_ver_scl_mode != SCALE_NONE) {
DRM_ERROR("ERROR : not allow yrgb ver scale\n");
@@ -354,14 +370,14 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
false, vsu_mode, );
VOP_SCL_SET(vop, win, scale_yrgb_y, val);
- VOP_SCL_SET(vop, win, vsd_yrgb_gt4, vskiplines == 4);
- VOP_SCL_SET(vop, win, vsd_yrgb_gt2, vskiplines == 2);
+ VOP_SCL_SET_EXT(vop, win, vsd_yrgb_gt4, vskiplines == 4);
+ VOP_SCL_SET_EXT(vop, win, vsd_yrgb_gt2, vskiplines == 2);
- VOP_SCL_SET(vop, win, yrgb_hor_scl_mode, yrgb_hor_scl_mode);
- VOP_SCL_SET(vop, win, yrgb_ver_scl_mode, yrgb_ver_scl_mode);
- VOP_SCL_SET(vop, win, yrgb_hsd_mode, SCALE_DOWN_BIL);
- VOP_SCL_SET(vop, win, yrgb_vsd_mode, SCALE_DOWN_BIL);
- VOP_SCL_SET(vop, win, yrgb_vsu_mode, vsu_mode);
+ VOP_SCL_SET_EXT(vop, win, yrgb_hor_scl_mode, yrgb_hor_scl_mode);
+ VOP_SCL_SET_EXT(vop, win, yrgb_ver_scl_mode, yrgb_ver_scl_mode);
+ VOP_SCL_SET_EXT(vop, win, yrgb_hsd_mode, SCALE_DOWN_BIL);
+ VOP_SCL_SET_EXT(vop, win, yrgb_vsd_mode, SCALE_DOWN_BIL);
+ VOP_SCL_SET_EXT(vop, win, yrgb_vsu_mode, vsu_mode);
if (is_yuv) {
val = scl_vop_cal_scale(cbcr_hor_scl_mode, cbcr_src_w,
dst_w, true, 0, NULL);
@@ -370,13 +386,13 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const
struct vop_win_data *win,
dst_h, false, vsu_mode, );
VOP_SCL_SET(vop, win, scale_cbcr_y, val);
- VOP_SCL_SET(vop, win, vsd_cbcr_gt4, vskiplines == 4);
- VOP_SCL_SET(vop, win, vsd_cbcr_gt2, vskiplines == 2);
- VOP_SCL_SET(vop, win, cbcr_hor_scl_mode, cbcr_hor_scl_mode);
- VOP_SCL_SET(vop, win, cbcr_ver_scl_mode, cbcr_ver_scl_mode);
- VOP_SCL_SET(vop, win, cbcr_hsd_mode, SCALE_DOWN_BIL);
- VOP_SCL_SET(vop, win, cbcr_vsd_mode, SCALE_DOWN_BIL);
- VOP_SCL_SET(vop, win, cbcr_vsu_mode, vsu_mode);
+ VOP_SCL_SET_EXT(vop, win, vsd_cbcr_gt4, vskiplines == 4);
+ VOP_SCL_SET_EXT(vop, win, vsd_cbcr_gt2, vskiplines == 2);
+ VOP_SCL_SET_EXT(vop, win, cbcr_hor_scl_mode, cbcr_hor_scl_mode);
+ VOP_SCL_SET_EXT(vop, win, cbcr_ver_scl_mode, cbcr_ver_scl_mode);
+ VOP_SCL_SET_EXT(vop, win, cbcr_hsd_mode, SCALE_DOWN_BIL);
+ VOP_SCL_SET_EXT(vop, win, cbcr_vsd_mode, SCALE_DOWN_BIL);
+ VOP_SCL_SET_EXT(vop, win, cbcr_vsu_mode, vsu_mode);
}
}
diff --git
[PATCH 2/6] drm/rockchip: vop: move interrupt registers into vop_data
Move interrupt registers into vop_data, so it can use at multi-vop driver
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 81 +++
1 file changed, 69 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index dcb1396..7674bdc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -48,6 +48,8 @@
#define REG_SET(x, base, reg, v, mode) \
__REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
+#define REG_SET_MASK(x, base, reg, v, mode) \
+ __REG_SET_##mode(x, base + reg.offset, reg.mask, reg.shift, v)
#define VOP_WIN_SET(x, win, name, v) \
REG_SET(x, win->base, win->phy->name, v, RELAXED)
@@ -56,6 +58,23 @@
#define VOP_CTRL_SET(x, name, v) \
REG_SET(x, 0, (x)->data->ctrl->name, v, NORMAL)
+#define VOP_INTR_GET(vop, name) \
+ vop_read_reg(vop, 0, >data->ctrl->name)
+
+#define VOP_INTR_SET(vop, name, v) \
+ REG_SET(vop, 0, vop->data->intr->name, v, NORMAL)
+#define VOP_INTR_SET_TYPE(vop, name, type, v) \
+ do { \
+ int i, reg = 0; \
+ for (i = 0; i < vop->data->intr->nintrs; i++) { \
+ if (vop->data->intr->intrs[i] & type) \
+ reg |= (v) << i; \
+ } \
+ VOP_INTR_SET(vop, name, reg); \
+ } while (0)
+#define VOP_INTR_GET_TYPE(vop, name, type) \
+ vop_get_intr_type(vop, >data->intr->name, type)
+
#define VOP_WIN_GET(x, win, name) \
vop_read_reg(x, win->base, >phy->name)
@@ -168,6 +187,13 @@ struct vop_ctrl {
struct vop_reg cfg_done;
};
+struct vop_intr {
+ const int *intrs;
+ uint32_t nintrs;
+ struct vop_reg enable;
+ struct vop_reg clear;
+ struct vop_reg status;
+};
struct vop_scl_regs {
struct vop_reg cbcr_vsd_mode;
struct vop_reg cbcr_vsu_mode;
@@ -227,6 +253,7 @@ struct vop_data {
const struct vop_reg_data *init_table;
unsigned int table_size;
const struct vop_ctrl *ctrl;
+ const struct vop_intr *intr;
const struct vop_win_data *win;
unsigned int win_size;
};
@@ -364,8 +391,24 @@ static const struct vop_win_data rk3288_vop_win_data[] = {
{ .base = 0x50, .phy = _data, .type = DRM_PLANE_TYPE_CURSOR },
};
+static const int rk3288_vop_intrs[] = {
+ DSP_HOLD_VALID_INTR,
+ FS_INTR,
+ LINE_FLAG_INTR,
+ BUS_ERROR_INTR,
+};
+
+static const struct vop_intr rk3288_vop_intr = {
+ .intrs = rk3288_vop_intrs,
+ .nintrs = ARRAY_SIZE(rk3288_vop_intrs),
+ .status = VOP_REG(INTR_CTRL0, 0xf, 0),
+ .enable = VOP_REG(INTR_CTRL0, 0xf, 4),
+ .clear = VOP_REG(INTR_CTRL0, 0xf, 8),
+};
+
static const struct vop_data rk3288_vop = {
.init_table = vop_init_reg_table,
+ .intr = _vop_intr,
.table_size = ARRAY_SIZE(vop_init_reg_table),
.ctrl = _data,
.win = rk3288_vop_win_data,
@@ -420,6 +463,20 @@ static inline void vop_mask_write_relaxed(struct vop *vop,
uint32_t offset,
}
}
+static inline uint32_t vop_get_intr_type(struct vop *vop,
+const struct vop_reg *reg, int type)
+{
+ uint32_t i, ret = 0;
+ uint32_t regs = vop_read_reg(vop, 0, reg);
+
+ for (i = 0; i < vop->data->intr->nintrs; i++) {
+ if ((type & vop->data->intr->intrs[i]) && (regs & 1 << i))
+ ret |= vop->data->intr->intrs[i];
+ }
+
+ return ret;
+}
+
static inline void vop_cfg_done(struct vop *vop)
{
VOP_CTRL_SET(vop, cfg_done, 1);
@@ -616,8 +673,7 @@ static void vop_dsp_hold_valid_irq_enable(struct vop *vop)
spin_lock_irqsave(>irq_lock, flags);
- vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
- DSP_HOLD_VALID_INTR_EN(1));
+ VOP_INTR_SET_TYPE(vop, enable, DSP_HOLD_VALID_INTR, 1);
spin_unlock_irqrestore(>irq_lock, flags);
}
@@ -631,8 +687,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_lock_irqsave(>irq_lock, flags);
- vop_mask_write(vop, INTR_CTRL0, DSP_HOLD_VALID_INTR_MASK,
- DSP_HOLD_VALID_INTR_EN(0));
+ VOP_INTR_SET_TYPE(vop, enable, DSP_HOLD_VALID_INTR, 0);
spin_unlock_irqrestore(>irq_lock, flags);
}
@@ -1051,7 +1106,7 @@ static int vop_crtc_enable_vblank(struct drm_crtc *crtc)
spin_lock_irqsave(>irq_lock, flags);
- vop_mask_write(vop, INTR_CTRL0, FS_INTR_MASK, FS_INTR_EN(1));
+ VOP_INTR_SET_TYPE(vop, enable, FS_INTR, 1);
spin_unlock_irqrestore(>irq_lock, flags);
@@ -1067,7 +1122,9 @@ static void vop_crtc_disable_vblank(struct drm_crtc *crtc)
return;
spin_lock_irqsave(>irq_lock, flags);
-
[PATCH 1/6] drm/rockchip: vop: merge vop cfg_done into vop_data
Move cfg_done register into vop_data, so it can use at multi-vop driver
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6ded4cc..dcb1396 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -164,6 +164,8 @@ struct vop_ctrl {
struct vop_reg vact_st_end;
struct vop_reg hpost_st_end;
struct vop_reg vpost_st_end;
+
+ struct vop_reg cfg_done;
};
struct vop_scl_regs {
@@ -333,6 +335,7 @@ static const struct vop_ctrl ctrl_data = {
.vact_st_end = VOP_REG(DSP_VACT_ST_END, 0x1fff1fff, 0),
.hpost_st_end = VOP_REG(POST_DSP_HACT_INFO, 0x1fff1fff, 0),
.vpost_st_end = VOP_REG(POST_DSP_VACT_INFO, 0x1fff1fff, 0),
+ .cfg_done = VOP_REG(REG_CFG_DONE, 0x1, 0),
};
static const struct vop_reg_data vop_init_reg_table[] = {
@@ -393,11 +396,6 @@ static inline uint32_t vop_read_reg(struct vop *vop,
uint32_t base,
return (vop_readl(vop, base + reg->offset) >> reg->shift) & reg->mask;
}
-static inline void vop_cfg_done(struct vop *vop)
-{
- writel(0x01, vop->regs + REG_CFG_DONE);
-}
-
static inline void vop_mask_write(struct vop *vop, uint32_t offset,
uint32_t mask, uint32_t v)
{
@@ -422,6 +420,11 @@ static inline void vop_mask_write_relaxed(struct vop *vop,
uint32_t offset,
}
}
+static inline void vop_cfg_done(struct vop *vop)
+{
+ VOP_CTRL_SET(vop, cfg_done, 1);
+}
+
static bool has_rb_swapped(uint32_t format)
{
switch (format) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] hisilicon/dts: Add hi655x pmic dts node
Mark,
+- regulator-vset-regs: Voltage set register offset.
+- regulator-vset-mask: voltage set control mask.
+- regulator-n-vol: The num of support voltages.
+- regulator-vset-table: The table of support voltages.
> Why is this in the binding? This is a binding for a specific device,
> there is no point in putting all these data tables in the DT - it just
> bloats the DT and makes it harder for us to enhance our support for this
> device in the future.
You mentioned in previous version,I I have some questions for it.
This regulator-vset-regs etc are vendor specific describe. The hi655x PMIC
is a series of chips. They all have this value, but the offset may be different.
And we can generate the dts file from excel which is defined by SOC.
I think the dts is designed to distinguish different platform. If we hard code
this
in files, it may be also different to use as common in next chip version.
I will appreciate it if you can give me some suggestions.
On 2015/12/15 20:54, Chen Feng wrote:
> Add dts node for hi665x MFD and regulator driver
>
> Signed-off-by: Chen Feng
> Signed-off-by: Fei Wang
> Tested-by: Xinwei Kong
> ---
> arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 178
> ++
> 1 file changed, 178 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> index 82d2488..5f98a72 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
> @@ -208,5 +208,183 @@
> clock-names = "uartclk", "apb_pclk";
> status = "disabled";
> };
> + pmic: pmic@F800 {
> + compatible = "hisilicon,hi655x-pmic";
> + reg = <0x0 0xf800 0x0 0x1000>;
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + pmic-gpios = <_pmu_irq_n>;
> + status = "okay";
> + ldo2: regulator@a21 {
> + compatible = "hisilicon,hi655x-regulator-pmic";
> + regulator-name = "ldo2";
> + regulator-min-microvolt = <250>;
> + regulator-max-microvolt = <320>;
> + regulator-valid-modes-mask = <0x02>;
> + regulator-enable-ramp-delay = <120>;
> + regulator-ctrl-regs = <0x029 0x02a 0x02b>;
> + regulator-ctrl-mask = <0x1>;
> + regulator-vset-regs = <0x072>;
> + regulator-vset-mask = <0x7>;
> + regulator-n-vol = <8>;
> + regulator-vset-table = <250>,<260>,
> + <270>,<280>,
> + <290>,<300>,
> + <310>,<320>;
> + };
> + ldo7: regulator@a26 {
> + compatible = "hisilicon,hi655x-regulator-pmic";
> + regulator-name = "ldo7";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;
> + regulator-valid-modes-mask = <0x0a>;
> + regulator-enable-ramp-delay = <120>;
> + regulator-ctrl-regs = <0x029 0x02a 0x02b>;
> + regulator-ctrl-mask = <0x6>;
> + regulator-vset-regs = <0x078>;
> + regulator-vset-mask = <0x7>;
> + regulator-n-vol = <8>;
> + regulator-vset-table = <180>,<185>,
> + <285>,<290>,
> + <300>,<310>,
> + <320>,<330>;
> + };
> + ldo10: regulator@a29 {
> + compatible = "hisilicon,hi655x-regulator-pmic";
> + regulator-name = "ldo10";
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <300>;
> + regulator-valid-modes-mask = <0x0a>;
> + regulator-enable-ramp-delay = <360>;
> + regulator-ctrl-regs = <0x02c 0x02d 0x02e>;
> + regulator-ctrl-mask = <0x1>;
> + regulator-vset-regs = <0x07b>;
> + regulator-vset-mask = <0x7>;
> + regulator-n-vol
[PATCH 2/3] NTB: Add AMD NTB support in Kconfig and Makefile
This patch is to enable AMD NTB support in Kconfig and Makefile. Signed-off-by: Xiangliang Yu --- drivers/ntb/hw/Kconfig | 1 + drivers/ntb/hw/Makefile | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/ntb/hw/Kconfig b/drivers/ntb/hw/Kconfig index 4d5535c..0c5c2a6 100644 --- a/drivers/ntb/hw/Kconfig +++ b/drivers/ntb/hw/Kconfig @@ -1 +1,2 @@ source "drivers/ntb/hw/intel/Kconfig" +source "drivers/ntb/hw/amd/Kconfig" diff --git a/drivers/ntb/hw/Makefile b/drivers/ntb/hw/Makefile index 175d7c9..636be7d 100644 --- a/drivers/ntb/hw/Makefile +++ b/drivers/ntb/hw/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_NTB_INTEL)+= intel/ +obj-$(CONFIG_NTB_AMD) += amd/ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] hisi_sas: use platform_get_irq()
> "John" == John Garry writes: John> It is preferred that drivers use platform_get_irq() instead of John> irq_of_parse_and_map(), so replace. Applied to 4.5/scsi-queue. -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] mm: memcontrol: charge swap to cgroup2
On Thu, Dec 17, 2015 at 11:46:27AM +0900, Kamezawa Hiroyuki wrote: > On 2015/12/16 20:09, Johannes Weiner wrote: > >On Wed, Dec 16, 2015 at 12:18:30PM +0900, Kamezawa Hiroyuki wrote: > >> - swap-full notification via vmpressure or something mechanism. > > > >Why? > > > > I think it's a sign of unhealthy condition, starting file cache drop rate to > rise. > But I forgot that there are resource threshold notifier already. Does the > notifier work > for swap.usage ? That will be reflected in vmpressure or other distress mechanisms. I'm not convinced "ran out of swap space" needs special casing in any way. > >> - force swap-in at reducing swap.limit > > > >Why? > > > If full, swap.limit cannot be reduced even if there are available memory in a > cgroup. > Another cgroup cannot make use of the swap resource while it's occupied by > other cgroup. > The job scheduler should have a chance to fix the situation. I don't see why swap space allowance would need to be as dynamically adjustable as the memory allowance. There is usually no need to be as tight with swap space as with memory, and the performance penalty of swapping, even with flash drives, is high enough that swap space acts as an overflow vessel rather than be part of the regularly backing of the anonymous/shmem working set. It really is NOT obvious that swap space would need to be adjusted on the fly, and that it's important that reducing the limit will be reflected in consumption right away. We shouldn't be adding hundreds of lines of likely terrible heuristics code* on speculation that somebody MIGHT find this useful in real life. We should wait until we are presented with a real usecase that applies to a whole class of users, and then see what the true requirements are. * If a group has 200M swapped out and the swap limit is reduced by 10M below the current consumption, which pages would you swap in? There is no LRU list for swap space. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] NTB: Add flush_req and wakeup interface
AMD NTB support two features: flush pending requests and wakeup
opposite side from low power state. This patch add two interface
to support these features.
Signed-off-by: Xiangliang Yu
---
drivers/ntb/hw/amd/ntb_hw_amd.c | 16
drivers/ntb/hw/amd/ntb_hw_amd.h | 2 ++
include/linux/ntb.h | 33 +
3 files changed, 51 insertions(+)
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
index 931dcdc..e0ff663 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.c
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -93,6 +93,8 @@ static const struct ntb_dev_ops amd_ntb_ops = {
.peer_spad_addr = amd_ntb_peer_spad_addr,
.peer_spad_read = amd_ntb_peer_spad_read,
.peer_spad_write= amd_ntb_peer_spad_write,
+ .flush_req = amd_ntb_flush_req,
+ .peer_wakeup= amd_ntb_wakeup_peer_side,
};
static int ndev_mw_to_bar(struct amd_ntb_dev *ndev, int idx)
@@ -501,6 +503,13 @@ static int amd_flush_peer_requests(struct amd_ntb_dev
*ndev)
return 0;
}
+static int amd_ntb_flush_req(struct ntb_dev *ntb)
+{
+ struct amd_ntb_dev *ndev = ntb_ndev(ntb);
+
+ return amd_flush_peer_requests(ndev);
+}
+
/*
* wake up the peer side
*/
@@ -522,6 +531,13 @@ static int amd_wakeup_peer_side(struct amd_ntb_dev *ndev)
return 0;
}
+static int amd_ntb_wakeup_peer_side(struct ntb_dev *ntb)
+{
+ struct amd_ntb_dev *ndev = ntb_ndev(ntb);
+
+ return amd_wakeup_peer_side(ndev);
+}
+
static void amd_handle_event(struct amd_ntb_dev *ndev, int vec)
{
u32 status;
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.h b/drivers/ntb/hw/amd/ntb_hw_amd.h
index c3085c8..2d9b5be 100644
--- a/drivers/ntb/hw/amd/ntb_hw_amd.h
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.h
@@ -263,4 +263,6 @@ static int amd_ntb_peer_spad_addr(struct ntb_dev *ntb, int
idx,
phys_addr_t *spad_addr);
static u32 amd_ntb_peer_spad_read(struct ntb_dev *ntb, int idx);
static int amd_ntb_peer_spad_write(struct ntb_dev *ntb, int idx, u32 val);
+static int amd_ntb_flush_req(struct ntb_dev *ntb);
+static int amd_ntb_wakeup_peer_side(struct ntb_dev *ntb);
#endif
diff --git a/include/linux/ntb.h b/include/linux/ntb.h
index f798e2a..9149138 100644
--- a/include/linux/ntb.h
+++ b/include/linux/ntb.h
@@ -210,6 +210,8 @@ static inline int ntb_ctx_ops_is_valid(const struct
ntb_ctx_ops *ops)
* @peer_spad_addr:See ntb_peer_spad_addr().
* @peer_spad_read:See ntb_peer_spad_read().
* @peer_spad_write: See ntb_peer_spad_write().
+ * @flush_req: See ntb_flush_requests().
+ * @peer_wakeup: See ntb_wakeup_peer_side().
*/
struct ntb_dev_ops {
int (*mw_count)(struct ntb_dev *ntb);
@@ -259,6 +261,9 @@ struct ntb_dev_ops {
phys_addr_t *spad_addr);
u32 (*peer_spad_read)(struct ntb_dev *ntb, int idx);
int (*peer_spad_write)(struct ntb_dev *ntb, int idx, u32 val);
+
+ int (*flush_req)(struct ntb_dev *ntb);
+ int (*peer_wakeup)(struct ntb_dev *ntb);
};
static inline int ntb_dev_ops_is_valid(const struct ntb_dev_ops *ops)
@@ -980,4 +985,32 @@ static inline int ntb_peer_spad_write(struct ntb_dev *ntb,
int idx, u32 val)
return ntb->ops->peer_spad_write(ntb, idx, val);
}
+/**
+ * ntb_flush_requests() - flush all pending requests
+ * @ntb: NTB device context.
+ *
+ * For some usage, one side of NTB need to first make sure that all previous
+ * requests have been completed and then execute next step such as power down,
+ * or device removed.
+ *
+ * Return: Zero on success, otherwise an error number.
+ */
+static inline int ntb_flush_requests(struct ntb_dev *ntb)
+{
+ return ntb->ops->flush_req(ntb);
+}
+
+/**
+ * ntb_wakeup_peer_side() - wakeup peer side of NTB.
+ * @ntb: NTB device context.
+ *
+ * Provide a mechanism that wakeup opposite side from low power state.
+ *
+ * Return: Zero on success, otherwise an error number.
+ */
+static inline int ntb_wakeup_peer_side(struct ntb_dev *ntb)
+{
+ return ntb->ops->peer_wakeup(ntb);
+}
+
#endif
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/5] regulator: add regulator driver of hi655x PMIC
Mark,
Thanks very much for your review.
On 2015/12/17 3:16, Mark Brown wrote:
> On Tue, Dec 15, 2015 at 08:54:15PM +0800, Chen Feng wrote:
>
>> +config REGULATOR_HI655X
>> +tristate "Hisilicon HI655X PMIC regulators support"
>> +depends on ARCH_HISI
>> +depends on MFD_HI655X_PMIC && OF
>> +help
>> + This driver provides support for the voltage regulators of the
>> + Hisilicon Hi655x PMIC device.
>> +
>
> On the previous version of this patch I said:
>
> | For both of these we should have an || COMPILE_TEST and there's no need
> | for either to be bool I can see, they should be tristate.
>
> I see you have made this a tristate which is good but you've not enabled
> COMPILE_TEST or indicated why - there may be a very good reason for
> doing this but nobody has said what it is. Please don't ignore review
> comments, people are generally making them for a reason and are likely
> to have the same concerns if issues remain unaddressed. Having to
> repeat the same comments can get repetitive and make people question the
> value of time spent reviewing. If you disagree with the review comments
> that's fine but you need to reply and discuss your concerns so that the
> reviewer can understand your decisions.
>
Sorry for this,I am busy with other issue these days.
Really appreciate your comments.
I will add the COMPILE_TEST next version.
>> +static int hi655x_is_enabled(struct regulator_dev *rdev)
>> +{
>> +unsigned int value = 0;
>> +
>> +struct hi655x_regulator *regulator = rdev_get_drvdata(rdev);
>> +struct hi655x_regulator_ctrl_regs *ctrl_regs = >ctrl_regs;
>
> The style here is not what we normally do - normally the struct lookups
> would be first, then any other variables and there wouldn't be any blank
> lines in the variable declarations. The same applies to quite a few
> functions.
>
ok, I will fix the style problem.
>> +static int hi655x_set_voltage(struct regulator_dev *rdev,
>> +int min_uV, int max_uV, unsigned *selector)
>> +{
>
> As I commented on the previous version of this driver:
>
> | Use the standard helpers, including one of the map_voltage()s and
> | set_voltage_sel_regmap(), don't open code them.
>
I change the regulator_enable method to regulator_enable_regmap this version.
But,since the hi655x PMIC use status register to ensure the regulator is okay
or not.
Three different register offset in these PMIC series.
enable register.
disable register.
status register.
I can't use regulator_is_enabled_regmap regulator_disable_regmap in helpers.c
int regulator_disable_regmap(struct regulator_dev *rdev)
{
...
return regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
rdev->desc->enable_mask, val);
...
}
Only enable_reg in the desc struct.
I will change the set voltage to regulator_set_voltage_sel_regmap next version.
Thanks again.
> You need to at least split the map and set_voltage_sel operations.
>
> I've stopped reviewing here.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] NTB: Add AMD PCI-Express NTB driver
AMD NTB support following main features:
(1) Three memory windows;
(2) Sixteen 32-bit scratch pad;
(3) Two 16-bit doorbell interrupt;
(4) Five event interrupts;
(5) One system can wake up opposite system of NTB;
(6) Flush previous request to the opposite system;
(7) There are reset and PME_TO mechanisms between two systems;
Signed-off-by: Xiangliang Yu
---
drivers/ntb/hw/amd/Kconfig |7 +
drivers/ntb/hw/amd/Makefile |1 +
drivers/ntb/hw/amd/ntb_hw_amd.c | 1225 +++
drivers/ntb/hw/amd/ntb_hw_amd.h | 266 +
4 files changed, 1499 insertions(+)
create mode 100644 drivers/ntb/hw/amd/Kconfig
create mode 100644 drivers/ntb/hw/amd/Makefile
create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.c
create mode 100644 drivers/ntb/hw/amd/ntb_hw_amd.h
diff --git a/drivers/ntb/hw/amd/Kconfig b/drivers/ntb/hw/amd/Kconfig
new file mode 100644
index 000..cfe903c
--- /dev/null
+++ b/drivers/ntb/hw/amd/Kconfig
@@ -0,0 +1,7 @@
+config NTB_AMD
+ tristate "AMD Non-Transparent Bridge support"
+ depends on X86_64
+ help
+This driver supports AMD NTB on capable Zeppelin hardware.
+
+If unsure, say N.
diff --git a/drivers/ntb/hw/amd/Makefile b/drivers/ntb/hw/amd/Makefile
new file mode 100644
index 000..ad54da9
--- /dev/null
+++ b/drivers/ntb/hw/amd/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_NTB_AMD) += ntb_hw_amd.o
diff --git a/drivers/ntb/hw/amd/ntb_hw_amd.c b/drivers/ntb/hw/amd/ntb_hw_amd.c
new file mode 100644
index 000..931dcdc
--- /dev/null
+++ b/drivers/ntb/hw/amd/ntb_hw_amd.c
@@ -0,0 +1,1225 @@
+/*
+ * This file is provided under a dual BSD/GPLv2 license. When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * BSD LICENSE
+ *
+ * Copyright (C) 2015 Advanced Micro Devices, Inc. All Rights Reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copy
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of AMD Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * AMD PCIe NTB Linux driver
+ *
+ * Contact Information:
+ * Xiangliang Yu
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ntb_hw_amd.h"
+
+#define NTB_NAME "ntb_hw_amd"
+#define NTB_DESC "AMD(R) PCI-E Non-Transparent Bridge Driver"
+#define NTB_VER"1.0"
+
+MODULE_DESCRIPTION(NTB_DESC);
+MODULE_VERSION(NTB_VER);
+MODULE_LICENSE("Dual BSD/GPL");
+MODULE_AUTHOR("AMD Inc.");
+
+static const struct file_operations amd_ntb_debugfs_info;
+static struct dentry *debugfs_dir;
+
+static const struct ntb_dev_ops amd_ntb_ops = {
+ .mw_count = amd_ntb_mw_count,
+ .mw_get_range = amd_ntb_mw_get_range,
+ .mw_set_trans = amd_ntb_mw_set_trans,
+ .link_is_up = amd_ntb_link_is_up,
+ .link_enable= amd_ntb_link_enable,
+ .link_disable = amd_ntb_link_disable,
+ .db_valid_mask = amd_ntb_db_valid_mask,
+ .db_vector_count= amd_ntb_db_vector_count,
+ .db_vector_mask = amd_ntb_db_vector_mask,
+ .db_read= amd_ntb_db_read,
+ .db_clear = amd_ntb_db_clear,
+
Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
Hi, On 12/11/15 at 03:26pm, Johannes Berg wrote: > On Mon, 2015-11-23 at 09:37 +0800, Dave Young wrote: > > > Seems there're a lot of other wireless messages. Should we refactor > > them as well? I still did not get chance to see where is the code. > > (My wireless driver being used is iwlwifi) > > Most are probably from net/mac80211/. > > > # dmesg|grep "Limiting TX power"|wc > > 4128 49600 360052 > > > > I fixed this one recently, due to a bug it was printed all the time > instead of just once when taking effect. Cool, has the fix been in mainline or somewhere else? Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iommu/amd: Assign default IOMMU when there is only one IOMMU
On 12/14/2015 9:08 AM, Joerg Roedel wrote: On Fri, Dec 11, 2015 at 04:54:38PM -0600, Suravee Suthikulpanit wrote: Current driver makes assumption that device with devid zero is always included in the range of devices to be managed by IOMMU. However, certain FW does not include devid zero in IVRS table. This has caused IOMMU perf driver to fail to initialize. Hmm, this is a firmware bug. Is this bug seen in any systems that are for sale? This patch implements a workaround for this case by always assign devid zero to be handled by the first IOMMU. Otherwise its better to fix the firmware than to add workarounds. Joerg Please ignore this patch. There are more stuff that I am planning to fix, and I am reworking them into V2. I'll send this out soon. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] drm/rockchip: dw_hdmi: use encoder enable function
Sorry, Ops, fat finger, discard this lost thread mail.
On 2015年12月17日 11:08, Mark Yao wrote:
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 525b5a8..8e1605c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -195,12 +195,15 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct
drm_encoder *encoder,
{
}
-static void dw_hdmi_rockchip_encoder_commit(struct drm_encoder *encoder)
+static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
{
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
u32 val;
int mux;
+ rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
+ ROCKCHIP_OUT_MODE_);
+
mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
@@ -212,17 +215,10 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
(mux) ? "LIT" : "BIG");
}
-static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
-{
- rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
-}
-
static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs
= {
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
- .prepare= dw_hdmi_rockchip_encoder_prepare,
- .commit = dw_hdmi_rockchip_encoder_commit,
+ .enable = dw_hdmi_rockchip_encoder_enable,
.disable= dw_hdmi_rockchip_encoder_disable,
};
--
Ｍark Yao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wireless: change cfg80211 regulatory domain info as debug messages
Hi, Johannes Sorry for late feedback, I was busying on other things. On 12/11/15 at 03:38pm, Johannes Berg wrote: > On Sun, 2015-11-15 at 15:31 +0800, Dave Young wrote: > > cfg80211 module prints a lot of messages like below. Actually > > printing once is acceptable but sometimes it will print again and > > again, it looks very annoying. It is better to change these detail > > messages to debugging only. > > > > Despite the objections, I've applied this patch now. > Thanks a lot. > I've made one change: keeping the alpha2 (e.g. "US") printed in some of > the pr_err() cases in this file. > I also got rid of CONFIG_CFG80211_REG_DEBUG in a separate patch. > > I somewhat agree with the objections, but if the kernel is with > CONFIG_DYNAMIC_DEBUG then it's really simple to get the messages back > by enabling them for this file. > > Where the messages were used as an indication of something having gone > awry at a different level (e.g. mac80211 disconnect) I don't really > quite agree - that then perhaps should have a more explicit (and less > noisy) message. > > I also agree that the regulatory code is quite opaque, and the way it > arrives at certain conclusions is not always obvious. These messages > don't help all that much though since they don't contain the actual > input to the decisions. I think for that, we'd be much better served > with some kind of tracepoint or so that records all the information. I think you guys are expert in this area, I will agree with all of above. But I hope we can have some rate limited messages at least especially for endless things. Thanks Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 7/8] drm: bridge/dw_hdmi: add atomic API support
Sorry, Ops, fat finger, discard this lost thread mail.
On 2015年12月17日 11:08, Mark Yao wrote:
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Cc: Russell King
Cc: Philipp Zabel
Cc: Andy Yan
Cc: Fabio Estevam
Cc: Thierry Reding
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2:
Adviced by Daniel Vetter
- check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
drivers/gpu/drm/bridge/dw_hdmi.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 56de9f1..dc0bdd4 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1522,6 +1523,17 @@ static struct drm_connector_funcs
dw_hdmi_connector_funcs = {
.force = dw_hdmi_connector_force,
};
+static struct drm_connector_funcs dw_hdmi_atomic_connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = dw_hdmi_connector_detect,
+ .destroy = dw_hdmi_connector_destroy,
+ .force = dw_hdmi_connector_force,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
.mode_valid = dw_hdmi_connector_mode_valid,
@@ -1645,8 +1657,15 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
drm_connector_helper_add(>connector,
_hdmi_connector_helper_funcs);
- drm_connector_init(drm, >connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+
+ if (drm_core_check_feature(drm, DRIVER_ATOMIC))
+ drm_connector_init(drm, >connector,
+ _hdmi_atomic_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
+ else
+ drm_connector_init(drm, >connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
hdmi->connector.encoder = encoder;
--
Ｍark Yao
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 8/8] drm/rockchip: dw_hdmi: use encoder enable function
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 525b5a8..8e1605c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -195,12 +195,15 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct
drm_encoder *encoder,
{
}
-static void dw_hdmi_rockchip_encoder_commit(struct drm_encoder *encoder)
+static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
{
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
u32 val;
int mux;
+ rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
+ ROCKCHIP_OUT_MODE_);
+
mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
@@ -212,17 +215,10 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
(mux) ? "LIT" : "BIG");
}
-static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
-{
- rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
-}
-
static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs =
{
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
- .prepare= dw_hdmi_rockchip_encoder_prepare,
- .commit = dw_hdmi_rockchip_encoder_commit,
+ .enable = dw_hdmi_rockchip_encoder_enable,
.disable= dw_hdmi_rockchip_encoder_disable,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/5] iommu/mediatek: Add mt8173 IOMMU driver
On Wed, 2015-12-16 at 12:48 +, Robin Murphy wrote:
> On 16/12/15 05:59, Yong Wu wrote:
> > On Tue, 2015-12-15 at 12:37 +, Robin Murphy wrote:
> >> On 15/12/15 03:28, Yong Wu wrote:
> >>> On Mon, 2015-12-14 at 15:16 +0100, Joerg Roedel wrote:
> On Tue, Dec 08, 2015 at 05:49:12PM +0800, Yong Wu wrote:
[...]
> > Following your comment above, I test as below. Then the flows seems meet
> > the "best case" that the iommu core will help create default DMA domain.
> >
> > @@ -664,19 +636,41 @@ static int mtk_iommu_probe(struct platform_device
> > *pdev)
> > for (i = 0; i < larb_nr; i++) {
> > struct device_node *larbnode;
> > struct platform_device *plarbdev;
> >
> > larbnode = of_parse_phandle(dev->of_node, "mediatek,larbs", i);
> > if (!larbnode)
> > return -EINVAL;
> >
> > plarbdev = of_find_device_by_node(larbnode);
> > of_node_put(larbnode);
> > - if (!plarbdev)
> > - return -EPROBE_DEFER;
> > + if (!plarbdev) {
> > + plarbdev = of_platform_device_create(larbnode,
> > NULL, platform_bus_type.dev_root);
> > + if (IS_ERR(pdev))
> > + return -EPROBE_DEFER;
> > + }
> > }
> >
> > I only add of_platform_device_create for the SMI local arbiter devices
> > here.
> >
> > This is a big improvement for us. If this is ok, I will send a quick
> > next version for this.
>
> In my opinion it's reasonable - we need the whole "IOMMU" to be ready,
Thanks.
> so if we already have to short-cut the creation of the M4U part it only
> seems fair to do the same for the SMI part. That said, would it work to
> just unconditionally poke the larbs in mtk_iommu_init_fn() before you
> poke the M4U itself? It would be nice to keep all that stuff together in
> the same place.
mtk_iommu_init_fn don't have the larb's "struct device_node". So I
cann't create its platform_device directly.
I have tried 2 method:
a) add a mtk_smi_larb_init_fn in the SMI patch.
static int mtk_smi_larb_init_fn(struct device_node *np)
{
struct platform_device *pdev;
pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
return IS_ERR(pdev) ? PTR_ERR(pdev) : 0;
}
IOMMU_OF_DECLARE(mtk_smi_larb, "mediatek,mt8173-smi-larb",
mtk_smi_larb_init_fn);
This don't work. It will run after mtk_iommu_init_fn. then the larb's
platform_device also don't exist while m4u's probe.
b) Copy the code below to mtk_iommu_init_fn.
for (i = 0; i < larb_nr; i++) {
xxx
plarbdev = of_platform_device_create(larbnode,
NULL, platform_bus_type.dev_root);
}
It works. But then there are 2 same code of parsing the SMI local
arbiter(one is in mtk_iommu_init_fn, the other is in mtk_iommu_init_fn).
It looks not good. I think that the one I wrote in the previous mail is
better, It only add 3 lines, What's your opinion?
> > +static struct iommu_group *mtk_iommu_device_group(struct device *dev)
> > +{
> > + struct mtk_iommu_data *data;
> > + struct mtk_iommu_client_priv *priv;
> > +
> > + priv = dev->archdata.iommu;
> > + if (!priv)
> > + return ERR_PTR(-ENODEV);
> > +
> > + /* All the client devices are in the same m4u iommu-group */
> > + data = dev_get_drvdata(priv->m4udev);
> > + if (!data->m4u_group) {
> > + data->m4u_group = iommu_group_alloc();
> > + if (IS_ERR(data->m4u_group))
> > + dev_err(dev, "Failed to allocate M4U IOMMU
> > group\n");
> > + }
> > + return data->m4u_group;
> > +}
> >>
> >> As long as this works as expected, then AFAICS you shouldn't have to
> >> have *any* special-case behaviour or tracking of domains at all.
> >
> > We only need one iommu-group, one iommu domain here.
> >
> > What's the special-case behavior, how can we track of domains.
> > Could you help give me a example?
>
> The beauty of it is that you don't need to. If you guarantee all of an
> IOMMU's client devices are in the same group, you know you've only got
> one thing which can be attached to that IOMMU's domains. Therefore, you
> can freely allow as many domains as you like to *exist*, because there
> can never be more than one *active* at any given time - the core code
> enforces that the group is detached from one domain before being
> attached to another, and the driver's attach and detach calls just
> become responsible for switching the given domain's page table in and
> out of the actual hardware. I think it's pretty neat.
It seems that mtk-iommu can not detach/attach dynamically. the iommu
core don't support iommu_detach_device/iommu_attach_device whose
iommu-group have many devices.(Normally there is only one device in a
iommu-group).
[PATCH v3 7/8] drm: bridge/dw_hdmi: add atomic API support
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Cc: Russell King
Cc: Philipp Zabel
Cc: Andy Yan
Cc: Fabio Estevam
Cc: Thierry Reding
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2:
Adviced by Daniel Vetter
- check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
drivers/gpu/drm/bridge/dw_hdmi.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 56de9f1..dc0bdd4 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1522,6 +1523,17 @@ static struct drm_connector_funcs
dw_hdmi_connector_funcs = {
.force = dw_hdmi_connector_force,
};
+static struct drm_connector_funcs dw_hdmi_atomic_connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = dw_hdmi_connector_detect,
+ .destroy = dw_hdmi_connector_destroy,
+ .force = dw_hdmi_connector_force,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
.mode_valid = dw_hdmi_connector_mode_valid,
@@ -1645,8 +1657,15 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
drm_connector_helper_add(>connector,
_hdmi_connector_helper_funcs);
- drm_connector_init(drm, >connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+
+ if (drm_core_check_feature(drm, DRIVER_ATOMIC))
+ drm_connector_init(drm, >connector,
+ _hdmi_atomic_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
+ else
+ drm_connector_init(drm, >connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
hdmi->connector.encoder = encoder;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 7/8] drm: bridge/dw_hdmi: add atomic API support
Fill atomic needed funcs with default atomic helper library.
Rockchip use dw_hdmi, and drm/rockchip will covert to atomic api,
we need dw_hdmi support atomic funcs.
Now another drm driver use dw_hdmi is imx, not yet atomic, so
check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
Cc: Russell King
Cc: Philipp Zabel
Cc: Andy Yan
Cc: Fabio Estevam
Cc: Thierry Reding
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2:
Adviced by Daniel Vetter
- check DRIVER_ATOMIC at runtime to spilt atomic and not atomic.
drivers/gpu/drm/bridge/dw_hdmi.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/dw_hdmi.c b/drivers/gpu/drm/bridge/dw_hdmi.c
index 56de9f1..dc0bdd4 100644
--- a/drivers/gpu/drm/bridge/dw_hdmi.c
+++ b/drivers/gpu/drm/bridge/dw_hdmi.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1522,6 +1523,17 @@ static struct drm_connector_funcs
dw_hdmi_connector_funcs = {
.force = dw_hdmi_connector_force,
};
+static struct drm_connector_funcs dw_hdmi_atomic_connector_funcs = {
+ .dpms = drm_atomic_helper_connector_dpms,
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = dw_hdmi_connector_detect,
+ .destroy = dw_hdmi_connector_destroy,
+ .force = dw_hdmi_connector_force,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
static struct drm_connector_helper_funcs dw_hdmi_connector_helper_funcs = {
.get_modes = dw_hdmi_connector_get_modes,
.mode_valid = dw_hdmi_connector_mode_valid,
@@ -1645,8 +1657,15 @@ static int dw_hdmi_register(struct drm_device *drm,
struct dw_hdmi *hdmi)
drm_connector_helper_add(>connector,
_hdmi_connector_helper_funcs);
- drm_connector_init(drm, >connector, _hdmi_connector_funcs,
- DRM_MODE_CONNECTOR_HDMIA);
+
+ if (drm_core_check_feature(drm, DRIVER_ATOMIC))
+ drm_connector_init(drm, >connector,
+ _hdmi_atomic_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
+ else
+ drm_connector_init(drm, >connector,
+ _hdmi_connector_funcs,
+ DRM_MODE_CONNECTOR_HDMIA);
hdmi->connector.encoder = encoder;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/8] drm/rockchip: dw_hdmi: use encoder enable function
encoder.enable is more compatible to atomic api than encoder.prepare/commit
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 525b5a8..8e1605c 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -195,12 +195,15 @@ static void dw_hdmi_rockchip_encoder_mode_set(struct
drm_encoder *encoder,
{
}
-static void dw_hdmi_rockchip_encoder_commit(struct drm_encoder *encoder)
+static void dw_hdmi_rockchip_encoder_enable(struct drm_encoder *encoder)
{
struct rockchip_hdmi *hdmi = to_rockchip_hdmi(encoder);
u32 val;
int mux;
+ rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
+ ROCKCHIP_OUT_MODE_);
+
mux = rockchip_drm_encoder_get_mux_id(hdmi->dev->of_node, encoder);
if (mux)
val = HDMI_SEL_VOP_LIT | (HDMI_SEL_VOP_LIT << 16);
@@ -212,17 +215,10 @@ static void dw_hdmi_rockchip_encoder_commit(struct
drm_encoder *encoder)
(mux) ? "LIT" : "BIG");
}
-static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
-{
- rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
-}
-
static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs =
{
.mode_fixup = dw_hdmi_rockchip_encoder_mode_fixup,
.mode_set = dw_hdmi_rockchip_encoder_mode_set,
- .prepare= dw_hdmi_rockchip_encoder_prepare,
- .commit = dw_hdmi_rockchip_encoder_commit,
+ .enable = dw_hdmi_rockchip_encoder_enable,
.disable= dw_hdmi_rockchip_encoder_disable,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 6/8] drm/rockchip: direct config connecter gate and out_mode
Both connecter gate and out_mode are not conflict with mode set
configure. Direct setting connecter gate and out_mode, that allow
connector do rockchip_drm_crtc_mode_config after mode set.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 39 +--
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 9ace3ae..6ded4cc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -89,9 +89,6 @@ struct vop {
struct drm_device *drm_dev;
bool is_enabled;
- int connector_type;
- int connector_out_mode;
-
/* mutex vsync_ work */
struct mutex vsync_mutex;
bool vsync_work_pending;
@@ -1018,8 +1015,24 @@ int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
{
struct vop *vop = to_vop(crtc);
- vop->connector_type = connector_type;
- vop->connector_out_mode = out_mode;
+ if (WARN_ON(!vop->is_enabled))
+ return -EINVAL;
+
+ switch (connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ VOP_CTRL_SET(vop, rgb_en, 1);
+ break;
+ case DRM_MODE_CONNECTOR_eDP:
+ VOP_CTRL_SET(vop, edp_en, 1);
+ break;
+ case DRM_MODE_CONNECTOR_HDMIA:
+ VOP_CTRL_SET(vop, hdmi_en, 1);
+ break;
+ default:
+ DRM_ERROR("unsupport connector_type[%d]\n", connector_type);
+ return -EINVAL;
+ };
+ VOP_CTRL_SET(vop, out_mode, out_mode);
return 0;
}
@@ -1132,22 +1145,6 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
vop_dsp_hold_valid_irq_disable(vop);
}
- switch (vop->connector_type) {
- case DRM_MODE_CONNECTOR_LVDS:
- VOP_CTRL_SET(vop, rgb_en, 1);
- break;
- case DRM_MODE_CONNECTOR_eDP:
- VOP_CTRL_SET(vop, edp_en, 1);
- break;
- case DRM_MODE_CONNECTOR_HDMIA:
- VOP_CTRL_SET(vop, hdmi_en, 1);
- break;
- default:
- DRM_ERROR("unsupport connector_type[%d]\n",
- vop->connector_type);
- };
- VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
-
val = 0x8;
val |= (adjusted_mode->flags & DRM_MODE_FLAG_NHSYNC) ? 0 : 1;
val |= (adjusted_mode->flags & DRM_MODE_FLAG_NVSYNC) ? 0 : (1 << 1);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 5/8] drm/rockchip: support atomic asynchronous commit
If drm core requests a async commit, rockchip_drm_atomic_commit
will schedule a work task to update later.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2:
- serialize outstanding asynchronous commits
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |3 ++
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 10 +
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54 ---
3 files changed, 54 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index ab3e0f6..5edd5ccb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -140,6 +140,9 @@ static int rockchip_drm_load(struct drm_device *drm_dev,
unsigned long flags)
if (!private)
return -ENOMEM;
+ mutex_init(>commit.lock);
+ INIT_WORK(>commit.work, rockchip_drm_atomic_work);
+
drm_dev->dev_private = private;
drm_mode_config_init(drm_dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 4468f98..bb8b076 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -42,6 +42,13 @@ struct rockchip_crtc_funcs {
void (*wait_for_update)(struct drm_crtc *crtc);
};
+struct rockchip_atomic_commit {
+ struct work_struct work;
+ struct drm_atomic_state *state;
+ struct drm_device *dev;
+ struct mutex lock;
+};
+
/*
* Rockchip drm private structure.
*
@@ -52,8 +59,11 @@ struct rockchip_drm_private {
struct drm_fb_helper fbdev_helper;
struct drm_gem_object *fbdev_bo;
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
+
+ struct rockchip_atomic_commit commit;
};
+void rockchip_drm_atomic_work(struct work_struct *work);
int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
const struct rockchip_crtc_funcs *crtc_funcs);
void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index 7c974a4..0bc1d5e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -210,20 +210,11 @@ rockchip_atomic_wait_for_complete(struct drm_atomic_state
*old_state)
}
}
-int rockchip_drm_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
+static void
+rockchip_atomic_commit_complete(struct rockchip_atomic_commit *commit)
{
- int ret;
-
- if (async)
- return -EBUSY;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- drm_atomic_helper_swap_state(dev, state);
+ struct drm_atomic_state *state = commit->state;
+ struct drm_device *dev = commit->dev;
/*
* TODO: do fence wait here.
@@ -255,6 +246,43 @@ int rockchip_drm_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_state_free(state);
+}
+
+void rockchip_drm_atomic_work(struct work_struct *work)
+{
+ struct rockchip_atomic_commit *commit = container_of(work,
+ struct rockchip_atomic_commit, work);
+
+ rockchip_atomic_commit_complete(commit);
+}
+
+int rockchip_drm_atomic_commit(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool async)
+{
+ struct rockchip_drm_private *private = dev->dev_private;
+ struct rockchip_atomic_commit *commit = >commit;
+ int ret;
+
+ ret = drm_atomic_helper_prepare_planes(dev, state);
+ if (ret)
+ return ret;
+
+ /* serialize outstanding asynchronous commits */
+ mutex_lock(>lock);
+ flush_work(>work);
+
+ drm_atomic_helper_swap_state(dev, state);
+
+ commit->dev = dev;
+ commit->state = state;
+
+ if (async)
+ schedule_work(>work);
+ else
+ rockchip_atomic_commit_complete(commit);
+
+ mutex_unlock(>lock);
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/8] drm/rockchip: Use new vblank api drm_crtc_vblank_*
No functional update, drm_vblank_* is the legacy version of
drm_crtc_vblank_*. and use new api make driver more clean.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 13 +++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.h |7 +++
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 +++-
3 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index f22e1e1..cfd9b83 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -64,11 +64,11 @@ void rockchip_drm_dma_detach_device(struct drm_device
*drm_dev,
}
EXPORT_SYMBOL_GPL(rockchip_drm_dma_detach_device);
-int rockchip_register_crtc_funcs(struct drm_device *dev,
-const struct rockchip_crtc_funcs *crtc_funcs,
-int pipe)
+int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
+const struct rockchip_crtc_funcs *crtc_funcs)
{
- struct rockchip_drm_private *priv = dev->dev_private;
+ int pipe = drm_crtc_index(crtc);
+ struct rockchip_drm_private *priv = crtc->dev->dev_private;
if (pipe > ROCKCHIP_MAX_CRTC)
return -EINVAL;
@@ -79,9 +79,10 @@ int rockchip_register_crtc_funcs(struct drm_device *dev,
}
EXPORT_SYMBOL_GPL(rockchip_register_crtc_funcs);
-void rockchip_unregister_crtc_funcs(struct drm_device *dev, int pipe)
+void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc)
{
- struct rockchip_drm_private *priv = dev->dev_private;
+ int pipe = drm_crtc_index(crtc);
+ struct rockchip_drm_private *priv = crtc->dev->dev_private;
if (pipe > ROCKCHIP_MAX_CRTC)
return;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..069d6d4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -52,10 +52,9 @@ struct rockchip_drm_private {
const struct rockchip_crtc_funcs *crtc_funcs[ROCKCHIP_MAX_CRTC];
};
-int rockchip_register_crtc_funcs(struct drm_device *dev,
-const struct rockchip_crtc_funcs *crtc_funcs,
-int pipe);
-void rockchip_unregister_crtc_funcs(struct drm_device *dev, int pipe);
+int rockchip_register_crtc_funcs(struct drm_crtc *crtc,
+const struct rockchip_crtc_funcs *crtc_funcs);
+void rockchip_unregister_crtc_funcs(struct drm_crtc *crtc);
int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index dd8e086..f82c7ba 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -119,8 +119,6 @@ struct vop {
/* vop dclk reset */
struct reset_control *dclk_rst;
- int pipe;
-
struct vop_win win[];
};
@@ -692,7 +690,7 @@ static void vop_enable(struct drm_crtc *crtc)
enable_irq(vop->irq);
- drm_vblank_on(vop->drm_dev, vop->pipe);
+ drm_crtc_vblank_on(crtc);
return;
@@ -711,7 +709,7 @@ static void vop_disable(struct drm_crtc *crtc)
if (!vop->is_enabled)
return;
- drm_vblank_off(crtc->dev, vop->pipe);
+ drm_crtc_vblank_off(crtc);
/*
* Vop standby will take effect at end of current frame,
@@ -918,7 +916,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
*/
mutex_lock(>vsync_mutex);
if (fb != vop_win_last_pending_fb(vop_win)) {
- ret = drm_vblank_get(plane->dev, vop->pipe);
+ ret = drm_crtc_vblank_get(crtc);
if (ret) {
DRM_ERROR("failed to get vblank, %d\n", ret);
mutex_unlock(>vsync_mutex);
@@ -929,7 +927,7 @@ static int vop_update_plane_event(struct drm_plane *plane,
ret = vop_win_queue_fb(vop_win, fb, yrgb_mst, event);
if (ret) {
- drm_vblank_put(plane->dev, vop->pipe);
+ drm_crtc_vblank_put(crtc);
mutex_unlock(>vsync_mutex);
return ret;
}
@@ -1023,7 +1021,7 @@ static int vop_disable_plane(struct drm_plane *plane)
vop = to_vop(plane->crtc);
- ret = drm_vblank_get(plane->dev, vop->pipe);
+ ret = drm_crtc_vblank_get(plane->crtc);
if (ret) {
DRM_ERROR("failed to get vblank, %d\n", ret);
return ret;
@@ -1033,7 +1031,7 @@ static int
[PATCH v3 0/8] drm/rockchip: covert to support atomic API
The series of patches coverting drm rockchip to atomic API, do some cleanup and some fixes on atomic side. TODO: fence is not support on current version. Tested on rk3288 popmetal board. All guys can test it with following url: test case: https://github.com/markyzq/libdrm.git atomictest kernel: https://github.com/markyzq/kernel-drm-rockchip.git drm-rockchip-next-12-17 Changes in v3: Reported by kbuild test robot - fix rockchip_crtc_wait_for_update undefined when build drm rockchip as modules. Changes in v2: - Optimization commit planes sequence. - Get vblank count on atomic_begin to protect vblank event. Advised by Daniel Stone - Direct return -EINVAL when yuv address is not support, instead of adjust it. - code formating and cleanup. Advised by Thierry Reding & Daniel Vetter - Hook mode_set into crtc enable instead of hack crtc enable on mode set. v2: http://www.spinics.net/lists/arm-kernel/msg468423.html v1: http://lists.freedesktop.org/archives/dri-devel/2015-November/095745.html Mark Yao (8): drm/rockchip: Use new vblank api drm_crtc_vblank_* drm/rockchip: vop: replace dpms with enable/disable drm/rockchip: Convert to support atomic API drm/rockchip: Optimization vop mode set drm/rockchip: support atomic asynchronous commit drm/rockchip: direct config connecter gate and out_mode drm: bridge/dw_hdmi: add atomic API support drm/rockchip: dw_hdmi: use encoder enable function drivers/gpu/drm/bridge/dw_hdmi.c| 23 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 14 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 21 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 20 +- drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 123 + drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 782 +++ 6 files changed, 495 insertions(+), 488 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/8] drm/rockchip: Optimization vop mode set
Rk3288 vop timing registers is immediately register, when configure
timing on display active time, will cause tearing. use dclk reset is
not a good idea to avoid this tearing. we can avoid tearing by using
standby register.
Vop standby register will take effect at end of current frame, and
go back to work immediately when exit standby.
So we can use standby register to protect this context.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 51 ++-
1 file changed, 35 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 44f6154..9ace3ae 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1097,10 +1097,40 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
vop_enable(crtc);
/*
-* disable dclk to stop frame scan, so that we can safe config mode and
-* enable iommu.
+* If dclk rate is zero, mean that scanout is stop,
+* we don't need wait any more.
*/
- clk_disable(vop->dclk);
+ if (clk_get_rate(vop->dclk)) {
+ /*
+* Rk3288 vop timing register is immediately, when configure
+* display timing on display time, may cause tearing.
+*
+* Vop standby will take effect at end of current frame,
+* if dsp hold valid irq happen, it means standby complete.
+*
+* mode set:
+*standby and wait complete --> |
+* | display time
+* |
+* |---> dsp hold irq
+* configure display timing --> |
+* standby exit |
+* | new frame start.
+*/
+
+ reinit_completion(>dsp_hold_completion);
+ vop_dsp_hold_valid_irq_enable(vop);
+
+ spin_lock(>reg_lock);
+
+ VOP_CTRL_SET(vop, standby, 1);
+
+ spin_unlock(>reg_lock);
+
+ wait_for_completion(>dsp_hold_completion);
+
+ vop_dsp_hold_valid_irq_disable(vop);
+ }
switch (vop->connector_type) {
case DRM_MODE_CONNECTOR_LVDS:
@@ -1115,7 +1145,6 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
default:
DRM_ERROR("unsupport connector_type[%d]\n",
vop->connector_type);
- goto out;
};
VOP_CTRL_SET(vop, out_mode, vop->connector_out_mode);
@@ -1136,19 +1165,9 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
-
- /*
-* reset dclk, take all mode config affect, so the clk would run in
-* correct frame.
-*/
- reset_control_assert(vop->dclk_rst);
- usleep_range(10, 20);
- reset_control_deassert(vop->dclk_rst);
-
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
-out:
- if (clk_enable(vop->dclk) < 0)
- dev_err(vop->dev, "failed to enable dclk\n");
+
+ VOP_CTRL_SET(vop, standby, 0);
}
static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/8] drm/rockchip: Convert to support atomic API
Rockchip vop not support hw vblank counter, needed check the committed
register if it's really take effect.
Signed-off-by: Mark Yao
Signed-off-by: Tomasz Figa
---
Changes in v3:
Reported by kbuild test robot
- fix rockchip_crtc_wait_for_update undefined when build drm rockchip as
modules.
Changes in v2:
- Optimization commit planes sequence.
- Get vblank count on atomic_begin to protect vblank event.
Adviced by Daniel Stone
- Direct return -EINVAL when yuv address is not support, instead of adjust it.
- code formating and cleanup.
Adviced by Thierry Reding & Daniel Vetter
- Hook mode_set into crtc enable instead of hack crtc enable on mode set.
drivers/gpu/drm/rockchip/rockchip_drm_drv.c |5 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h |3 +-
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 95
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 657 +++
4 files changed, 363 insertions(+), 397 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index cfd9b83..ab3e0f6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -213,6 +213,8 @@ static int rockchip_drm_load(struct drm_device *drm_dev,
unsigned long flags)
*/
drm_dev->vblank_disable_allowed = true;
+ drm_mode_config_reset(drm_dev);
+
ret = rockchip_drm_fbdev_init(drm_dev);
if (ret)
goto err_vblank_cleanup;
@@ -276,7 +278,8 @@ const struct vm_operations_struct rockchip_drm_vm_ops = {
};
static struct drm_driver rockchip_drm_driver = {
- .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+ .driver_features= DRIVER_MODESET | DRIVER_GEM |
+ DRIVER_PRIME | DRIVER_ATOMIC,
.load = rockchip_drm_load,
.unload = rockchip_drm_unload,
.lastclose = rockchip_drm_lastclose,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index 069d6d4..4468f98 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -18,6 +18,7 @@
#define _ROCKCHIP_DRM_DRV_H
#include
+#include
#include
#include
@@ -38,6 +39,7 @@ struct drm_connector;
struct rockchip_crtc_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
+ void (*wait_for_update)(struct drm_crtc *crtc);
};
/*
@@ -63,5 +65,4 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
-
#endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
index b8ac591..7c974a4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fb.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
@@ -166,9 +167,103 @@ static void rockchip_drm_output_poll_changed(struct
drm_device *dev)
drm_fb_helper_hotplug_event(fb_helper);
}
+static void rockchip_crtc_wait_for_update(struct drm_crtc *crtc)
+{
+ struct rockchip_drm_private *priv = crtc->dev->dev_private;
+ int pipe = drm_crtc_index(crtc);
+ const struct rockchip_crtc_funcs *crtc_funcs = priv->crtc_funcs[pipe];
+
+ if (crtc_funcs && crtc_funcs->wait_for_update)
+ crtc_funcs->wait_for_update(crtc);
+}
+
+static void
+rockchip_atomic_wait_for_complete(struct drm_atomic_state *old_state)
+{
+ struct drm_crtc_state *old_crtc_state;
+ struct drm_crtc *crtc;
+ int i, ret;
+
+ for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ /* No one cares about the old state, so abuse it for tracking
+* and store whether we hold a vblank reference (and should do a
+* vblank wait) in the ->enable boolean.
+*/
+ old_crtc_state->enable = false;
+
+ if (!crtc->state->active)
+ continue;
+
+ ret = drm_crtc_vblank_get(crtc);
+ if (ret != 0)
+ continue;
+
+ old_crtc_state->enable = true;
+ }
+
+ for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ if (!old_crtc_state->enable)
+ continue;
+
+ rockchip_crtc_wait_for_update(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+}
+
+int rockchip_drm_atomic_commit(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool async)
+{
+ int ret;
+
+ if (async)
+ return
[PATCH v3 2/8] drm/rockchip: vop: replace dpms with enable/disable
For vop, power by enable/disable is more suitable then legacy dpms
function, and enable/disable more closely to the new atomic API.
Signed-off-by: Mark Yao
---
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 37 +++
1 file changed, 4 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index f82c7ba..1e60ddd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -632,7 +632,7 @@ static void vop_dsp_hold_valid_irq_disable(struct vop *vop)
spin_unlock_irqrestore(>irq_lock, flags);
}
-static void vop_enable(struct drm_crtc *crtc)
+static void vop_crtc_enable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
int ret;
@@ -702,7 +702,7 @@ err_disable_hclk:
clk_disable(vop->hclk);
}
-static void vop_disable(struct drm_crtc *crtc)
+static void vop_crtc_disable(struct drm_crtc *crtc)
{
struct vop *vop = to_vop(crtc);
@@ -1107,30 +1107,6 @@ static const struct rockchip_crtc_funcs
private_crtc_funcs = {
.disable_vblank = vop_crtc_disable_vblank,
};
-static void vop_crtc_dpms(struct drm_crtc *crtc, int mode)
-{
- DRM_DEBUG_KMS("crtc[%d] mode[%d]\n", crtc->base.id, mode);
-
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- vop_enable(crtc);
- break;
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- case DRM_MODE_DPMS_OFF:
- vop_disable(crtc);
- break;
- default:
- DRM_DEBUG_KMS("unspecified mode %d\n", mode);
- break;
- }
-}
-
-static void vop_crtc_prepare(struct drm_crtc *crtc)
-{
- vop_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
-}
-
static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
@@ -1241,17 +1217,12 @@ out:
return ret;
}
-static void vop_crtc_commit(struct drm_crtc *crtc)
-{
-}
-
static const struct drm_crtc_helper_funcs vop_crtc_helper_funcs = {
- .dpms = vop_crtc_dpms,
- .prepare = vop_crtc_prepare,
+ .enable = vop_crtc_enable,
+ .disable = vop_crtc_disable,
.mode_fixup = vop_crtc_mode_fixup,
.mode_set = vop_crtc_mode_set,
.mode_set_base = vop_crtc_mode_set_base,
- .commit = vop_crtc_commit,
};
static int vop_crtc_page_flip(struct drm_crtc *crtc,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided
On 12/16/2015 8:56 PM, Loc Ho wrote: Hi, The current driver uses input clock source frequency to calculate values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not currently have a good way to provide the frequency information. Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used to directly provide these values. So, the clock information should no longer be required during probing. However, since clk can be invalid, additional checks must be done where we are making use of it. Signed-off-by: Suravee Suthikulpanit --- Note: This has been tested on AMD Seattle RevB for both DT and ACPI. Tested on X-Gene hardware also. -Loc Thanks for quick response. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option
On 2015/12/17 9:38, Izumi, Taku wrote: > Dear Xishi, > > Sorry for late. > >> -Original Message- >> From: Xishi Qiu [mailto:qiuxi...@huawei.com] >> Sent: Friday, December 11, 2015 6:44 PM >> To: Izumi, Taku/泉 拓 >> Cc: Luck, Tony; linux-kernel@vger.kernel.org; linux...@kvack.org; >> a...@linux-foundation.org; Kamezawa, Hiroyuki/亀澤 寛 >> 之; m...@csn.ul.ie; Hansen, Dave; m...@codeblueprint.co.uk >> Subject: Re: [PATCH v3 2/2] mm: Introduce kernelcore=mirror option >> >> On 2015/12/11 13:53, Izumi, Taku wrote: >> >>> Dear Xishi, >>> Hi Taku, Whether it is possible that we rewrite the fallback function in buddy system when zone_movable and mirrored_kernelcore are both enabled? >>> >>> What does "when zone_movable and mirrored_kernelcore are both enabled?" >>> mean ? >>> >>> My patchset just provides a new way to create ZONE_MOVABLE. >>> >> >> Hi Taku, >> Hi Taku, We can NOT specify kernelcore= "nn[KMG]" and "mirror" at the same time. So when we use "mirror", in fact, the movable zone is a new zone. I think it is more appropriate with this name "mirrored zone", and also we can rewrite the fallback function in buddy system in this case. Thanks, Xishi Qiu >> I mean when zone_movable is from kernelcore=mirror, not kernelcore=nn[KMG]. > > I'm not quite sure what you are saying, but if you want to screen user > memory > so that one is allocated from mirrored zone and another is from > non-mirrored zone, > I think it is possible to reuse my patchset. > > Sincerely, > Taku Izumi > >> Thanks, >> Xishi Qiu >> >>> Sincerely, >>> Taku Izumi It seems something like that we add a new zone but the name is zone_movable, not zone_mirror. And the prerequisite is that we won't enable these two features(movable memory and mirrored memory) at the same time. Thus we can reuse the code of movable zone. >>> >>> -- >>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >>> the body of a message to majord...@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> Please read the FAQ at http://www.tux.org/lkml/ >>> >>> . >>> >> >> > > > . > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided
Hi, > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not > currently have a good way to provide the frequency information. > Instead, we can leverage the SSCN and FFCN ACPI methods, which can be used > to directly provide these values. So, the clock information should > no longer be required during probing. > > However, since clk can be invalid, additional checks must be done where > we are making use of it. > > Signed-off-by: Suravee Suthikulpanit > --- > > Note: This has been tested on AMD Seattle RevB for both DT and ACPI. Tested on X-Gene hardware also. -Loc -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/11] KVM: MMU: simplify mmu_need_write_protect
On 12/16/2015 04:48 PM, Xiao Guangrong wrote:
On 12/16/2015 04:05 PM, Kai Huang wrote:
On 12/15/2015 05:25 PM, Xiao Guangrong wrote:
On 12/15/2015 04:43 PM, Kai Huang wrote:
On 12/01/2015 02:26 AM, Xiao Guangrong wrote:
Now, all non-leaf shadow page are page tracked, if gfn is not tracked
there is no non-leaf shadow page of gfn is existed, we can directly
make the shadow page of gfn to unsync
Signed-off-by: Xiao Guangrong
---
arch/x86/kvm/mmu.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 5a2ca73..f89e77f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -2461,41 +2461,31 @@ static void __kvm_unsync_page(struct
kvm_vcpu *vcpu, struct kvm_mmu_page
*sp)
kvm_mmu_mark_parents_unsync(sp);
}
-static void kvm_unsync_pages(struct kvm_vcpu *vcpu, gfn_t gfn)
+static bool kvm_unsync_pages(struct kvm_vcpu *vcpu, gfn_t gfn,
+ bool can_unsync)
{
struct kvm_mmu_page *s;
for_each_gfn_indirect_valid_sp(vcpu->kvm, s, gfn) {
+if (!can_unsync)
+return true;
How about moving this right before for_each_gfn_indirect_valid_sp?
As can_unsync is passed as
parameter, so there's no point checking it several times.
We can not do this. What we are doing here is checking if we have
shadow page mapping
for 'gfn':
a) if no, it can be writable.
I think in this case you should also check whether the GFN is being
write protection tracked. Ex, if
the spte never exists when you add the GFN to write protection
tracking, and in this case I think
mmu_need_write_protect should also report true. Right?
We have already checked it:
static bool mmu_need_write_protect(struct kvm_vcpu *vcpu, gfn_t gfn,
bool can_unsync)
{
if (kvm_page_track_check_mode(vcpu, gfn, KVM_PAGE_TRACK_WRITE))
return true;
return kvm_unsync_pages(vcpu, gfn, can_unsync);
}
Oh sorry I missed this :)
b) if yes, check 'can_unsync' to see if these shadow pages can make
to be 'unsync'.
Your suggestion can break the point a).
A further thinking is can we move it to mmu_need_write_protect?
Passing can_unsync as parameter to
kvm_unsync_pages sounds a little bit odd.
+
if (s->unsync)
continue;
WARN_ON(s->role.level != PT_PAGE_TABLE_LEVEL);
How about large page mapping? Such as if guest uses 2M mapping and
its shadow is indirect, does
above WARN_ON still meet? As you removed the PT level check in
mmu_need_write_protect.
The lager mapping are on the non-leaf shadow pages which can be
figured out by
kvm_page_track_check_mode() before we call this function.
Actually I am not quite understanding how large page mapping is
implemented. I see in
kvm_mmu_get_page, when sp is allocated, it is large page mapping
disabled, but I think we do support
large shadow mapping, right? I mean theoretically if guest uses 2M
mapping and shadow mapping can
certainly use 2M mapping as well, and the 2M shadow mapping can also
be 'unsynced' (as a leaf
mapping table). But in your series I see if we write protect some
GFN, the shadow large page
mapping is always disabled.
Am I wrong?
If the large page contains the page which is used as page table, kvm
does not map large page for
it, the reason is we track the 4k page instead of the whole large page
to reduce write emulation.
I don't know why breaking large page to 4K mapping can reduce write
emulation, but this explanation works for me. I guess KVM-GT doesn't
care about it neither. :)
Thanks,
-Kai
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the clockevents tree
Hi Daniel,
After merging the clockevents tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/clocksource/h8300_timer16.c: In function 'timer16_interrupt':
drivers/clocksource/h8300_timer16.c:64:2: error: implicit declaration of
function 'ctrl_bclr' [-Werror=implicit-function-declaration]
ctrl_bclr(p->ovf, p->mapcommon + TISRC);
^
Caused by commit
1ddca16cc5b3 ("clocksource/drivers/h8300: Use ioread / iowrite")
ctrl_bclr is only defined for the h8300 arch ...
I have used the clocksource tree from next-20151216 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
