From: SeongJae Park <sj38.park@gmail.com>
To: corbet@lwn.net, will@kernel.org, paulmck@kernel.org
Cc: linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
SeongJae Park <sj38.park@gmail.com>
Subject: [PATCH 3/7] docs/memory-barriers.txt/kokr: Fix style, spacing and grammar in I/O section
Date: Fri, 22 Nov 2019 00:41:21 +0100 [thread overview]
Message-ID: <20191121234125.28032-4-sj38.park@gmail.com> (raw)
In-Reply-To: <20191121234125.28032-1-sj38.park@gmail.com>
Translate this commit to Korean:
0cde62a46e88 ("docs/memory-barriers.txt: Fix style, spacing and grammar in I/O section")
Signed-off-by: SeongJae Park <sj38.park@gmail.com>
---
.../translations/ko_KR/memory-barriers.txt | 112 ++++++++++--------
1 file changed, 60 insertions(+), 52 deletions(-)
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index 584bb0bdf2c4..1b9bfe54b3a5 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -2480,75 +2480,83 @@ I/O 액세스를 통한 주변장치와의 통신은 아키텍쳐와 기기에
(*) readX(), writeX():
- readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를
- __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터 (예:
- ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
-
- 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
- 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
- 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
-
- 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
- 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent() 를
- 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을 시작시키기 위해
- CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA 엔진에 보일 것이
- 보장됩니다.
-
- 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
- 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
- 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의 완료를
- 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된 데이터를 읽지
- 않을 것이 보장됩니다.
-
- 4. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가 수행을
- 시작하기 전에 완료됩니다. 예를 들어, CPU 의 특정 주변장치로의 두개의
- MMIO 레지스터 쓰기가 행해지는데 첫번째 쓰기가 readX() 를 통해 곧바로
- 읽어졌고 이어 두번째 writeX() 전에 udelay(1) 이 호출되었다면 이 두개의
- 쓰기는 최소 1us 의 간격을 두고 행해질 것이 보장됩니다.
-
- 디폴트가 아닌 기능을 통해 얻어지는 __iomem 포인터 (예: ioremap_wc() 를
- 통해 리턴되는 것) 는 이런 보장사항들 중 다수를 제공하지 않을 수 있습니다.
+ readX() 와 writeX() MMIO 액세스 함수는 접근되는 주변장치로의 포인터를
+ __iomem * 패러미터로 받습니다. 디폴트 I/O 기능으로 매핑되는 포인터
+ (예: ioremap() 으로 반환되는 것) 의 순서 보장은 다음과 같습니다:
+
+ 1. 같은 주변장치로의 모든 readX() 와 writeX() 액세스는 각자에 대해
+ 순서지어집니다. 예를 들어, CPU 의 특정 디바이스로의 MMIO 레지스터
+ 쓰기는 프로그램 순서대로 도착할 것이 보장됩니다.
+
+ 2. CPU 에 의한 특정 주변장치로의 writeX() 는 모든 앞선 CPU 의 메모리
+ 쓰기가 완료되기를 먼저 기다립니다. 예를 들어, dma_alloc_coherent()
+ 를 통해 할당된 전송용 DMA 버퍼로의 CPU 의 쓰기는 이 전송을
+ 시작시키기 위해 CPU 가 MMIO 컨트롤 레지스터에 쓰기를 할 때 DMA
+ 엔진에 보일 것이 보장됩니다.
+
+ 3. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 CPU 의 메모리
+ 읽기가 시작되기 전에 완료됩니다. 예를 들어, dma_alloc_coherent() 를
+ 통해 할당된 수신용 DMA 버퍼로부터의 CPU 의 읽기는 이 DMA 수신의
+ 완료를 표시하는 DMA 엔진의 MMIO 상태 레지스터 읽기 후에는 오염된
+ 데이터를 읽지 않을 것이 보장됩니다.
+
+ 4. CPU 에 의한 주변장치로의 readX() 는 모든 뒤따르는 delay() 루프가
+ 수행을 시작하기 전에 완료됩니다. 예를 들어, CPU 의 특정
+ 주변장치로의 두개의 MMIO 레지스터 쓰기가 행해지는데 첫번째 쓰기가
+ readX() 를 통해 곧바로 읽어졌고 이어 두번째 writeX() 전에 udelay(1)
+ 이 호출되었다면 이 두개의 쓰기는 최소 1us 의 간격을 두고 행해질 것이
+ 보장됩니다:
+
+ writel(42, DEVICE_REGISTER_0); // 디바이스에 도착함...
+ readl(DEVICE_REGISTER_0);
+ udelay(1);
+ writel(42, DEVICE_REGISTER_1); // ...이것보다 최소 1us 전에.
+
+ 디폴트가 아닌 기능을 통해 얻어지는 __iomem 포인터 (예: ioremap_wc() 를
+ 통해 리턴되는 것) 의 순서 속성은 실제 아키텍쳐에 의존적이어서 이런
+ 종류의 매핑으로의 액세스는 앞서 설명된 보장사항에 의존할 수 없습니다.
(*) readX_relaxed(), writeX_relaxed()
- 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서 보장을
- 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay() 루프
- (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O 기능으로
- 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의 액세스에는 순서가
- 맞춰질 것이 보장됩니다.
+ 이것들은 readX() 와 writeX() 랑 비슷하지만, 더 완화된 메모리 순서
+ 보장을 제공합니다. 구체적으로, 이것들은 일반적 메모리 액세스나 delay()
+ 루프 (예:앞의 2-4 항목) 에 대해 순서를 보장하지 않습니다만 디폴트 I/O
+ 기능으로 매핑된 __iomem 포인터에 대해 동작할 때 같은 주변장치로의
+ 액세스에는 순서가 맞춰질 것이 보장됩니다.
(*) readsX(), writesX():
- readsX() 와 writesX() MMIO 액세스 함수는 DMA 를 수행하는데 적절치 않은,
- 주변장치 내의 메모리 매핑된 레지스터 기반 FIFO 로의 액세스를 위해
- 설계되었습니다. 따라서, 이 기능들은 앞서 설명된 readX_relaxed() 와
- writeX_relaxed() 의 순서 보장만을 제공합니다.
+ readsX() 와 writesX() MMIO 액세스 함수는 DMA 를 수행하는데 적절치 않은,
+ 주변장치 내의 메모리 매핑된 레지스터 기반 FIFO 로의 액세스를 위해
+ 설계되었습니다. 따라서, 이 기능들은 앞서 설명된 readX_relaxed() 와
+ writeX_relaxed() 의 순서 보장만을 제공합니다.
(*) inX(), outX():
- inX() 와 outX() 액세스 함수는 일부 아키텍쳐 (특히 x86) 에서는 특수한
- 명령어를 필요로 하며 포트에 매핑되는, 과거의 유산인 I/O 주변장치로의
- 접근을 위해 만들어졌습니다.
+ inX() 와 outX() 액세스 함수는 일부 아키텍쳐 (특히 x86) 에서는 특수한
+ 명령어를 필요로 하며 포트에 매핑되는, 과거의 유산인 I/O 주변장치로의
+ 접근을 위해 만들어졌습니다.
- 많은 CPU 아키텍쳐가 결국은 이런 주변장치를 내부의 가상 메모리 매핑을 통해
- 접근하기 때문에, inX() 와 outX() 가 제공하는 이식성 있는 순서 보장은
- 디폴트 I/O 기능을 통한 매핑을 접근할 때의 readX() 와 writeX() 에 의해
- 제공되는 것과 각각 동일합니다.
+ 많은 CPU 아키텍쳐가 결국은 이런 주변장치를 내부의 가상 메모리 매핑을
+ 통해 접근하기 때문에, inX() 와 outX() 가 제공하는 이식성 있는 순서
+ 보장은 디폴트 I/O 기능을 통한 매핑을 접근할 때의 readX() 와 writeX() 에
+ 의해 제공되는 것과 각각 동일합니다.
- 디바이스 드라이버는 outX() 가 리턴하기 전에 해당 I/O 주변장치로부터의 완료
- 응답을 기다리는 쓰기 트랜잭션을 만들어 낸다고 기대할 수도 있습니다. 이는
- 모든 아키텍쳐에서 보장되지는 않고, 따라서 이식성 있는 순서 규칙의 일부분이
- 아닙니다.
+ 디바이스 드라이버는 outX() 가 리턴하기 전에 해당 I/O 주변장치로부터의
+ 완료 응답을 기다리는 쓰기 트랜잭션을 만들어 낸다고 기대할 수도
+ 있습니다. 이는 모든 아키텍쳐에서 보장되지는 않고, 따라서 이식성 있는
+ 순서 규칙의 일부분이 아닙니다.
(*) insX(), outsX():
- 앞에서와 같이, insX() 와 outsX() 액세스 함수는 디폴트 I/O 기능을 통한
- 매핑을 접근할 때 각각 readX() 와 writeX() 와 같은 순서 보장을 제공합니다.
+ 앞에서와 같이, insX() 와 outsX() 액세스 함수는 디폴트 I/O 기능을 통한
+ 매핑을 접근할 때 각각 readX() 와 writeX() 와 같은 순서 보장을
+ 제공합니다.
(*) ioreadX(), iowriteX()
- 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의
- 종류에 따라 적절하게 수행될 것입니다.
+ 이것들은 inX()/outX() 나 readX()/writeX() 처럼 실제로 수행하는 액세스의
+ 종류에 따라 적절하게 수행될 것입니다.
이 모든 액세스 함수들은 아랫단의 주변장치가 little-endian 이라 가정하며, 따라서
big-endian 아키텍쳐에서는 byte-swapping 오퍼레이션을 수행합니다.
--
2.17.2
next prev parent reply other threads:[~2019-11-21 23:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-21 23:41 [PATCH 0/7] docs: Update ko_KR translations SeongJae Park
2019-11-21 23:41 ` [PATCH 1/7] docs/memory-barriers.txt/kokr: Rewrite "KERNEL I/O BARRIER EFFECTS" section SeongJae Park
2019-11-21 23:41 ` [PATCH 2/7] Documentation/kokr: Kill all references to mmiowb() SeongJae Park
2019-11-21 23:41 ` SeongJae Park [this message]
2019-11-21 23:41 ` [PATCH 4/7] docs/memory-barriers.txt/kokr: Update I/O section to be clearer about CPU vs thread SeongJae Park
2019-11-21 23:41 ` [PATCH 5/7] docs/memory-barriers.txt: Remove remaining references to mmiowb() SeongJae Park
2019-11-21 23:41 ` [PATCH 6/7] Documentation/translation: Use Korean for Korean translation title SeongJae Park
2019-11-21 23:41 ` [PATCH 7/7] Documentation/process/howto/kokr: Update for 4.x -> 5.x versioning SeongJae Park
2019-11-22 17:01 ` [PATCH 0/7] docs: Update ko_KR translations Jonathan Corbet
2019-11-26 22:21 ` Paul E. McKenney
2019-11-26 22:36 ` SeongJae Park
2019-11-27 14:12 ` Jonathan Corbet
2019-11-27 14:27 ` Paul E. McKenney
2019-11-29 18:28 ` [PATCH] docs/memory-barriers.txt.kokr: Minor wordsmith SeongJae Park
2019-12-06 17:21 ` SeongJae Park
2019-12-12 17:30 ` SeongJae Park
2019-12-19 16:41 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191121234125.28032-4-sj38.park@gmail.com \
--to=sj38.park@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).