From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-1580499-1516446686-2-5931446245933673702 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, FREEMAIL_ENVFROM_END_DIGIT 0.25, FREEMAIL_FROM 0.001, RCVD_IN_DNSWL_NONE -0.0001, RCVD_IN_MSPIKE_H2 -0.001, SPF_PASS -0.001, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.85.223.193', Host='mail-io0-f193.google.com', Country='US', FromHeader='com', MailFrom='com' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: deanbo422@gmail.com ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516446685; b=ooxFgFh2OONFwFvDWDsZIo99N9gCodrGoVR0SLwnl6ehpJ/ NjQxzgcBnogY/+hTBKMQeY3JmVEh5ZsPI0LHQ292Ta/TECUZ7cu0axdJ/SSvMabn I81VfMAmO11NpUsxAWL0fRH6VsgUhw+DuZsoHkO2uiv4eWPdw8AnL8U/5c6toUtk +KqVE8jzXvdmmGJ4ChLsD6m775drqS+Io5r2U3b9cNExuEhpsReIPNG38vXF4qBs 9jlTFjtQvR5UsUOpLlIXM0iBZm0md1h2ddD4+lrC4laVx+g1pTnz+9HpCphNxtYc /Y/5gW9JAlkJbOjzSZ4XmMOToMMzEU3DcskLOmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; s=arctest; t= 1516446685; bh=57bX/3BiH68zRdaDwRbABeHXIIwDAUyr99+lVYXFAig=; b=N CrjoCZ8hs3BuiaVjqqnGZ9tHfS8MJo9nlq7RkppJ2XEKdarEnPSJKNYScOJQT8nN A5GP952TXCVDdFa+M4KsA0WYz7QTM852rBn2RZL5DtGraShZ3ERT6+LbA/Xt5cP0 U9FY7yfpagAUiuiIG/7Ld2aAp8QZ8qIwTJlupQSIc+mNIjIA7jedSf+Ir9dEIeS3 JWSKQMTo62WdpXQ1j00SscZt4lRB3CPMFMWcRlNvVeGXqv9QE807IQgT4+Wf6SBs nVXcxSVK7pagDhVxAZqP9CqK81iMaCLXxZVaRvXltVBXq0NmsYs2j1htIAAZiub0 hd8ozbGHxMWhpQu3RsPiQ== ARC-Authentication-Results: i=1; mx6.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=RFkBEd/2 x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.223.193 (mail-io0-f193.google.com); spf=pass smtp.mailfrom=deanbo422@gmail.com smtp.helo=mail-io0-f193.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=tqnbEsdy; x-ptr=pass x-ptr-helo=mail-io0-f193.google.com x-ptr-lookup=mail-io0-f193.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 Authentication-Results: mx6.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=RFkBEd/2 x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.223.193 (mail-io0-f193.google.com); spf=pass smtp.mailfrom=deanbo422@gmail.com smtp.helo=mail-io0-f193.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=tqnbEsdy; x-ptr=pass x-ptr-helo=mail-io0-f193.google.com x-ptr-lookup=mail-io0-f193.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 X-Google-Smtp-Source: AH8x227VLcH4Vrtl5Tutn/9lhExnhesZ6e7MFF/nZzG3vwU5Dt85w37NeBL7+35G0JU5nTepi/Z8JjgnvtbZeYvYRKQ= MIME-Version: 1.0 In-Reply-To: References: From: Vincent Chen Date: Sat, 20 Jan 2018 19:11:22 +0800 Message-ID: Subject: Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support To: Arnd Bergmann Cc: Greentime Hu , Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren , Randy Dunlap , David Miller , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Rick Chen , Rick Chen , Vincent Chen Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: 2018-01-18 19:08 GMT+08:00 Arnd Bergmann : > On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu wrote: >> From: Rick Chen >> >> VDSO needs real-time cycle count to ensure the time accuracy. >> Unlike others, nds32 architecture does not define clock source, >> hence VDSO needs atcpit100 offering real-time cycle count >> to derive the correct time. >> >> Signed-off-by: Vincent Chen >> Signed-off-by: Rick Chen >> Signed-off-by: Greentime Hu > > I'm a bit puzzled by this patch, can you explain how the vdso actually > manages to access the clock hardware? It looks like you make the > physical address and the register offset available to user space, but > how does it end up accessing it? > > Arnd Dear Arnd: Accessing clock hardware in vdso can be divided to 2 step. 1. Setup an additional memory mapping for clock hardware in user space when establishing vdso-needed memory mapping In arch_setup_additional_pages(), kernel establishes memory mapping for vdso's text and vdata page in user space. In order to make clock hardware be accessible in user space, we try to establish an additional memory mapping for clock hardware here based on clock information from driver. This page is located between vdata page and vdso text page. For safety, this region for clock accessing is read-only. 2. Accessing clock hardware in vdso After step 1, clock hardware is accessible in user space through memory-mapped IO. However, it is not enough to access a specific register. Therefore, we store register offset information in vdata page to make it visible in user space. Now, vdso can derive the address of counter register by summation of __get_timerpage() and counter register offset where __get_timerpage() is used to derive the virtual address of memory-mapped clock. Vincent From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Chen Subject: Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support Date: Sat, 20 Jan 2018 19:11:22 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Greentime Hu , Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 2018-01-18 19:08 GMT+08:00 Arnd Bergmann : > On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu wrote: >> From: Rick Chen >> >> VDSO needs real-time cycle count to ensure the time accuracy. >> Unlike others, nds32 architecture does not define clock source, >> hence VDSO needs atcpit100 offering real-time cycle count >> to derive the correct time. >> >> Signed-off-by: Vincent Chen >> Signed-off-by: Rick Chen >> Signed-off-by: Greentime Hu > > I'm a bit puzzled by this patch, can you explain how the vdso actually > manages to access the clock hardware? It looks like you make the > physical address and the register offset available to user space, but > how does it end up accessing it? > > Arnd Dear Arnd: Accessing clock hardware in vdso can be divided to 2 step. 1. Setup an additional memory mapping for clock hardware in user space when establishing vdso-needed memory mapping In arch_setup_additional_pages(), kernel establishes memory mapping for vdso's text and vdata page in user space. In order to make clock hardware be accessible in user space, we try to establish an additional memory mapping for clock hardware here based on clock information from driver. This page is located between vdata page and vdso text page. For safety, this region for clock accessing is read-only. 2. Accessing clock hardware in vdso After step 1, clock hardware is accessible in user space through memory-mapped IO. However, it is not enough to access a specific register. Therefore, we store register offset information in vdata page to make it visible in user space. Now, vdso can derive the address of counter register by summation of __get_timerpage() and counter register offset where __get_timerpage() is used to derive the virtual address of memory-mapped clock. Vincent From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Chen Subject: Re: [PATCH v6 2/3] clocksource/drivers/atcpit100: VDSO support Date: Sat, 20 Jan 2018 19:11:22 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.org To: Arnd Bergmann Cc: Greentime Hu , Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: devicetree@vger.kernel.org 2018-01-18 19:08 GMT+08:00 Arnd Bergmann : > On Mon, Jan 15, 2018 at 6:57 AM, Greentime Hu wrote: >> From: Rick Chen >> >> VDSO needs real-time cycle count to ensure the time accuracy. >> Unlike others, nds32 architecture does not define clock source, >> hence VDSO needs atcpit100 offering real-time cycle count >> to derive the correct time. >> >> Signed-off-by: Vincent Chen >> Signed-off-by: Rick Chen >> Signed-off-by: Greentime Hu > > I'm a bit puzzled by this patch, can you explain how the vdso actually > manages to access the clock hardware? It looks like you make the > physical address and the register offset available to user space, but > how does it end up accessing it? > > Arnd Dear Arnd: Accessing clock hardware in vdso can be divided to 2 step. 1. Setup an additional memory mapping for clock hardware in user space when establishing vdso-needed memory mapping In arch_setup_additional_pages(), kernel establishes memory mapping for vdso's text and vdata page in user space. In order to make clock hardware be accessible in user space, we try to establish an additional memory mapping for clock hardware here based on clock information from driver. This page is located between vdata page and vdso text page. For safety, this region for clock accessing is read-only. 2. Accessing clock hardware in vdso After step 1, clock hardware is accessible in user space through memory-mapped IO. However, it is not enough to access a specific register. Therefore, we store register offset information in vdata page to make it visible in user space. Now, vdso can derive the address of counter register by summation of __get_timerpage() and counter register offset where __get_timerpage() is used to derive the virtual address of memory-mapped clock. Vincent