Re: [PATCH v11 3/4] ARM64: add SBSA Generic Watchdog device node in amd-seattle-soc.dtsi
Hi Suravee,
On 11 February 2016 at 04:56, Suravee Suthikulpanit
wrote:
> Hi Fu Wei,
>
> On 2/10/16 00:00, fu@linaro.org wrote:
>>
>> From: Fu Wei
>>
>> This can be a example of adding SBSA Generic Watchdog device node
>> into some dts files for the Soc which contains SBSA Generic Watchdog.
>>
>> Acked-by: Arnd Bergmann
>> Signed-off-by: Suravee Suthikulpanit
>> Signed-off-by: Fu Wei
>> ---
>> arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> index 2874d92..67eb636 100644
>> --- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> +++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
>> @@ -84,6 +84,15 @@
>> clock-names = "uartclk", "apb_pclk";
>> };
>>
>> + watchdog0: watchdog@e0bb {
>> + compatible = "arm,sbsa-gwdt";
>> + reg = <0x0 0xe0bc 0 0x1000>,
>> + <0x0 0xe0bb 0 0x1000>;
>> + interrupts = <0 337 4>;
>> + timeout-sec = <15>;
>> + status = "disabled";
>
>
> Could you please remove this status line? I do not think it is necessary for
> this one here anymore.
OK, will do
:-)
>
> Thanks,
> Suravee
>
>
>> + };
>> +
>> spi0: ssp@e102 {
>> status = "disabled";
>> compatible = "arm,pl022", "arm,primecell";
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel docs: muddying the waters a bit
On Sun, Feb 14, 2016 at 1:57 AM, Keith Packard wrote: > Jonathan Corbet writes: > >> Asciidoc is a credible solution to the formatted documentation problem, >> but it's not the only such; I'd like to be sure that we pick the right >> one. I worry that asciidoc seems to be aimed mostly at small documents, >> and that the project itself seems a little lifeless - it's not a good >> sign when your main page's link to the repository has been dead for a long >> time. (Asciidoctor seems more active, with the Github folks behind it, >> but that means bringing Ruby into the picture). > > I was surprised when one of the asciidoctor developers said that > asciidoc itself was 'in maintenance mode for existing users'. I've tried > asciidoctor but never got it to the point where I was happy with the > results. Having two tools using the same nominal format doesn't seem > like a great idea to me. > > It's also clear from my hacking in asciidoc that docbook is the expected > target for that tool. I've managed to make direct HTML output usable, > but LaTeX doesn't work at all. Something which focuses on direct HTML > (and ePub) output would be pretty nice. > >> An alternative we haven't really looked at yet is ReStructuredText (or >> "RST") and the Sphinx system (sphinx-doc.org) built on top of it. RST is >> YA simple markup scheme, remarkably similar to Markdown or Asciidoc; >> Sphinx is a fairly sophisticated documentation system that uses RST. > > I've installed debian's python3-sphinx package; it looks like it doesn't > have a huge dependency chain below it, which is a nice change. > > I translated a fairly long document from asciidoc to rst using pandoc by > using the docbook output from asciidoc -- pandoc doesn't have a native > asciidoc reader, only a writer. The result didn't totally suck, although > I haven't messed with fixing the css or using a different theme at all. > > http://keithp.com/~keithp/altusmetrum-sphinx/altusmetrum.html > > I installed the sphinxcontrib.fulltoc extension so that the whole TOC > was visible from each section; this made navigating a lot easier. Having > search included (if you have javascript) seems like a nice feature. > >> Like asciidoc, Sphinx is Python-based, so it adds little to the toolchain >> requirements there. > > Having functional native latex output means that even PDF generation is > lighterweight though. > >> It produces integrated, multi-file HTML natively, >> with a TOC, an index, cross-file cross references, and more. It can make >> things like function indexes. It claims output in epub, docbook, and man >> (I've not yet messed with those). The path to PDF is via latex; clearly >> the docbook path could be used too. > > I've tried epub and latex backends; epub seems just fine (it's just > html, after all). LaTeX works, and generates functional PDF, but I'm > going to have to spend a bunch of time making it looks nice. > > http://keithp.com/~keithp/altusmetrum-sphinx/AltusMetrum.pdf > >> So can we discuss? I'm not saying we have to use Sphinx, but, should we >> choose not to, we should do so with open eyes and good reasons for the >> course we do take. What do you all think? > > Having spent the afternoon playing with it, I'm definitely > impressed. I've spent a ton of time getting asciidoc to generate html > and pdf that I can tolerate; far too much of that involved hacking XML > files related to the docbook backend. > > Pros > > * Credible HTML output without docbook > > * Credible PDF output without docbook. > > * Constructs a unified set of documents across >multiple files. > > * Written in Python (2 or 3) > > * PanDoc already supports rst for both input and output. So, if we get >bored with RST, we've got a way out. > > Cons > > * Table formatting doesn't seem as sophisticated as asciidoc > > Questions > > * Conditional text appears to be harder to manage (I haven't managed to >make it work at all). > > * Takes over a directory making building more than one >document in a directory hard/impossible? The config file must be >named 'conf.py'? One concern/open I have for pro/cons are the hyperlinks from kerneldoc comments. Currently we have the postproc hack, iirc Jani's patches generated links native when extracting the kerneldoc. What's the solution with spinx? The other one is graphs - Keith showed me some neat stuff that asciidoc can do, and I definitely wanted to integrate something like that as a follow-up into the kerneldoc toolchain. Often a diagram is a lot more helpful than lots of words. Can sphinx gives us that too? Wrt reformatting: I'm not going to like it, but I hope that with a bit of sed we can fix up any of the asciidoc comments we have already easily - right now we don't (yet) use much of the more sophisticated markup yet. So much better to change now than 1 year down the road. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe
Re: Kernel docs: muddying the waters a bit
Daniel Vetter writes:
> The other one is graphs - Keith showed me some neat stuff that
> asciidoc can do, and I definitely wanted to integrate something like
> that as a follow-up into the kerneldoc toolchain. Often a diagram is a
> lot more helpful than lots of words. Can sphinx gives us that too?
.. graphviz::
digraph foo {
"bar" -> "baz";
}
Even better than asciidoc -- svg output is supported in both html and
pdf (when using rst2pdf). I had to hack asciidoc to add support for svg
output when using docbook.
> Wrt reformatting: I'm not going to like it, but I hope that with a bit
> of sed we can fix up any of the asciidoc comments we have already
> easily - right now we don't (yet) use much of the more sophisticated
> markup yet. So much better to change now than 1 year down the road.
I used pandoc on the docbook output from asciidoc to get a 100 page
document converted here. It wasn't perfect -- all of the internal links
were busted, and labels for tables were mis-positioned. It might be that
a few minor fixes to pandoc could be done to add 'sphinx'-specific rst
support that could fix this?
I spent (too much) time yesterday playing with sphinx and generated a
new html theme. Here's the result:
http://keithp.com/~keithp/altusmetrum-sphinx/altusmetrum.html
Here's the PDF output from rst2pdf, a python-based PDF output which
doesn't use docbook *or* latex:
http://keithp.com/~keithp/altusmetrum-sphinx/Altus%20Metrum.pdf
I need to spend some quality time building my own PDF theme; the default
provided by rst2pdf isn't great. It does, however, use fontconfig, so
switching fonts is *way* easier than with docbook...
There's currently an incompatibility between the rst2pdf and sphnix
packages in debian (and upstream) which I hacked around to generate that
output, but otherwise I'm using packaged bits.
So, another pro for sphinx appears to be native PDF generation...
--
-keith
signature.asc
Description: PGP signature
Re: [PATCH] Documentation: Chinese translation of arm64/silicon-errata.txt
2016-02-14 3:40 GMT+08:00 :
> From: Fu Wei
>
> This is a Chinese translated version of Documentation/arm64/silicon-errata.txt
>
> Signed-off-by: Fu Wei
Reviewed-by: Weiwei Jia
> ---
> Documentation/zh_CN/arm64/silicon-errata.txt | 74
>
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt
>
> diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt
> b/Documentation/zh_CN/arm64/silicon-errata.txt
> new file mode 100644
> index 000..0584bd6
> --- /dev/null
> +++ b/Documentation/zh_CN/arm64/silicon-errata.txt
> @@ -0,0 +1,74 @@
> +Chinese translated version of Documentation/arm64/silicon-errata.txt
> +
> +If you have any comment or update to the content, please contact the
> +original document maintainer directly. However, if you have a problem
> +communicating in English you can also ask the Chinese maintainer for
> +help. Contact the Chinese maintainer if this translation is outdated
> +or if there is a problem with the translation.
> +
> +M: Will Deacon
> +zh_CN: Fu Wei
> +C: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835
> +-
> +Documentation/arm64/silicon-errata.txt 的中文翻译
> +
> +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
> +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
> +译存在问题，请联系中文版维护者。
> +
> +英文版维护者： Will Deacon
> +中文版维护者： 傅炜 Fu Wei
> +中文版翻译者： 傅炜 Fu Wei
> +中文版校译者： 傅炜 Fu Wei
> +本文翻译提交时的 Git 检出点为： e835a65f7ab143acf9aee6f9a98ef1c7afd2a835
> +
> +以下为正文
> +-
> +芯片勘误和软件解决办法
> +==
> +
> +作者: Will Deacon
> +日期: 2015年11月27日
> +
> +一个不幸的现实：硬件经常带有一些所谓的“错误（errata）”，致使其在
> +某些特定的情况下会违背构架定义的行为。对基于 ARM 的硬件，这些错误
> +大体被分为以下几类：
> +
> + A 类：无可行解决方法的严重错误。
> + B 类：有可接受的解决方法的重大或严重错误。
> + C 类：在正常操作中不会显现的小错误。
> +
> +更多资讯，请在 infocenter.arm.com （需注册）中查阅“软件开发者勘误
> +笔记”（“Software Developers Errata Notice”）文档。
> +
> +对于 Linux 而言，B 类错误可能需要操作系统的某些特别处理。例如，避免
> +一个特殊的代码序列，或是以一种特定的方式配置处理器。在某种不太常见的
> +情况下，为将 A 类错误当作 C 类处理，可能需要用类似手段。这些手段被
> +统称为“软件解决办法”，且仅在少数情况需要（例如，那些需要一个在非安全
> +异常级运行的解决方法 *且* 能被 Linux 触发的情况）。
I think it may be better like this.
（例如，那些需要在一个非安全异常级别运行的解决方法 *并且* 能被 Linux 触发的情况）
> +
> +对于尚在讨论中的可能对未受错误影响的系统产生不利影响的软件解决办法，
> +有一个相应的内核配置（Kconfig）选项被加在 “内核特性（Kernel Features）”
> +- > “基于可选方案框架的 ARM 错误解决办法（ARM errata workarounds via
> +the alternatives framework）"。这些选项被默认开启，若探测到受影响的CPU，
> +补丁将在运行时被打入。对于对系统运行影响较小的解决办法，内核配置选项
> +并不存在，且代码以一种避开错误的方式被构造（带注释为宜）。
> +
> +这种做法对于在任意内核源代码树中准确地判断出哪个错误已被软件方法所解决
> +稍微有点麻烦，所以这个文件在 Linux 内核中作为软件解决办法的注册表，
> +并将在新的软件解决办法被提交和反向移植到稳定内核时被更新。
> +
> +| 实现者 | 受影响的组件| 勘误编号| 内核配置|
> +++-+-+-+
> +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319
> |
> +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319
> |
> +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069
> |
> +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472
> |
> +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719
> |
> +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419
> |
> +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075
> |
> +| ARM| Cortex-A57 | #852523 | N/A
> |
> +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220
> |
> +|| | |
> |
> +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375
> |
> +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154
> |
> --
> 2.5.0
>
N�r��yb�X��ǧv�^�){.n�+{�v�"��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count
On Fri, Feb 12, 2016 at 12:14:39PM -0800, Daniel Walker wrote: > From: Khalid Mughal > > Currently there is no way to figure out the droppable pagecache size > from the meminfo output. The MemFree size can shrink during normal > system operation, when some of the memory pages get cached and is > reflected in "Cached" field. Similarly for file operations some of > the buffer memory gets cached and it is reflected in "Buffers" field. > The kernel automatically reclaims all this cached & buffered memory, > when it is needed elsewhere on the system. The only way to manually > reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. But > this can have performance impact. Since it discards cached objects, > it may cause high CPU & I/O utilization to recreate the dropped > objects during heavy system load. > This patch computes the droppable pagecache count, using same > algorithm as "vm/drop_caches". It is non-destructive and does not > drop any pages. Therefore it does not have any impact on system > performance. The computation does not include the size of > reclaimable slab. Why, exactly, do you need this? You've described what the patch does (i.e. redundant, because we can read the code), and described that the kernel already accounts this reclaimable memory elsewhere and you can already read that and infer the amount of reclaimable memory from it. So why isn't that accounting sufficient? As to the code, I think it is a horrible hack - the calculation does not come for free. Forcing iteration all the inodes in the inode cache is not something we should allow users to do - what's to stop someone just doing this 100 times in parallel and DOSing the machine? Or what happens when someone does 'grep "" /proc/sys/vm/*" to see what all the VM settings are on a machine with a couple of TB of page cache spread across a couple of hundred million cached inodes? It a) takes a long time, b) adds sustained load to an already contended lock (sb->s_inode_list_lock), and c) isn't configuration information. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Chinese translation of arm64/silicon-errata.txt
Hi Harry, Thanks for your rapid response :-) On 02/15/2016 03:23 AM, Weiwei Jia wrote: 2016-02-14 3:40 GMT+08:00 : From: Fu Wei This is a Chinese translated version of Documentation/arm64/silicon-errata.txt Signed-off-by: Fu Wei Reviewed-by: Weiwei Jia --- Documentation/zh_CN/arm64/silicon-errata.txt | 74 1 file changed, 74 insertions(+) create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt b/Documentation/zh_CN/arm64/silicon-errata.txt new file mode 100644 index 000..0584bd6 --- /dev/null +++ b/Documentation/zh_CN/arm64/silicon-errata.txt @@ -0,0 +1,74 @@ +Chinese translated version of Documentation/arm64/silicon-errata.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +M: Will Deacon +zh_CN: Fu Wei +C: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 +- +Documentation/arm64/silicon-errata.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 + +英文版维护者： Will Deacon +中文版维护者： 傅炜 Fu Wei +中文版翻译者： 傅炜 Fu Wei +中文版校译者： 傅炜 Fu Wei +本文翻译提交时的 Git 检出点为： e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 + +以下为正文 +- +芯片勘误和软件解决办法 +== + +作者: Will Deacon +日期: 2015年11月27日 + +一个不幸的现实：硬件经常带有一些所谓的“错误（errata）”，致使其在 +某些特定的情况下会违背构架定义的行为。对基于 ARM 的硬件，这些错误 +大体被分为以下几类： + + A 类：无可行解决方法的严重错误。 + B 类：有可接受的解决方法的重大或严重错误。 + C 类：在正常操作中不会显现的小错误。 + +更多资讯，请在 infocenter.arm.com （需注册）中查阅“软件开发者勘误 +笔记”（“Software Developers Errata Notice”）文档。 + +对于 Linux 而言，B 类错误可能需要操作系统的某些特别处理。例如，避免 +一个特殊的代码序列，或是以一种特定的方式配置处理器。在某种不太常见的 +情况下，为将 A 类错误当作 C 类处理，可能需要用类似手段。这些手段被 +统称为“软件解决办法”，且仅在少数情况需要（例如，那些需要一个在非安全 I am thinking about a better translation of "workaround" 变通方法 修补方案 替代办法 修正方案 Which one does look better to you? or do you have any suggestion? :-) +异常级运行的解决方法 *且* 能被 Linux 触发的情况）。 I think it may be better like this. （例如，那些需要在一个非安全异常级别运行的解决方法 *并且* 能被 Linux 触发的情况） How about this? （例如，那些需要一个运行在非安全异常级的解决方法 *并且* 能被 Linux 触发 的情况） Because 一个*解决方法 and "运行在非安全异常级的" is adjective。 + +对于尚在讨论中的可能对未受错误影响的系统产生不利影响的软件解决办法， +有一个相应的内核配置（Kconfig）选项被加在 “内核特性（Kernel Features）” +- > “基于可选方案框架的 ARM 错误解决办法（ARM errata workarounds via +the alternatives framework）"。这些选项被默认开启，若探测到受影响的CPU， +补丁将在运行时被打入。对于对系统运行影响较小的解决办法，内核配置选项 +并不存在，且代码以一种避开错误的方式被构造（带注释为宜）。 + +这种做法对于在任意内核源代码树中准确地判断出哪个错误已被软件方法所解决 +稍微有点麻烦，所以这个文件在 Linux 内核中作为软件解决办法的注册表， +并将在新的软件解决办法被提交和反向移植到稳定内核时被更新。 + +| 实现者 | 受影响的组件| 勘误编号| 内核配置| +++-+-+-+ +| ARM| Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +| ARM| Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | +| ARM| Cortex-A53 | #824069 | ARM64_ERRATUM_824069 | +| ARM| Cortex-A53 | #819472 | ARM64_ERRATUM_819472 | +| ARM| Cortex-A53 | #845719 | ARM64_ERRATUM_845719 | +| ARM| Cortex-A53 | #843419 | ARM64_ERRATUM_843419 | +| ARM| Cortex-A57 | #832075 | ARM64_ERRATUM_832075 | +| ARM| Cortex-A57 | #852523 | N/A | +| ARM| Cortex-A57 | #834220 | ARM64_ERRATUM_834220 | +|| | | | +| Cavium | ThunderX ITS| #22375, #24313 | CAVIUM_ERRATUM_22375 | +| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Chinese translation of arm64/silicon-errata.txt
2016-02-15 12:57 GMT+08:00 Fu Wei : > Hi Harry, Hi Wei Fu, > > Thanks for your rapid response :-) > > > On 02/15/2016 03:23 AM, Weiwei Jia wrote: >> >> 2016-02-14 3:40 GMT+08:00 : >>> >>> From: Fu Wei >>> >>> This is a Chinese translated version of >>> Documentation/arm64/silicon-errata.txt >>> >>> Signed-off-by: Fu Wei >> >> >> Reviewed-by: Weiwei Jia >> >>> --- >>> Documentation/zh_CN/arm64/silicon-errata.txt | 74 >>> >>> 1 file changed, 74 insertions(+) >>> create mode 100644 Documentation/zh_CN/arm64/silicon-errata.txt >>> >>> diff --git a/Documentation/zh_CN/arm64/silicon-errata.txt >>> b/Documentation/zh_CN/arm64/silicon-errata.txt >>> new file mode 100644 >>> index 000..0584bd6 >>> --- /dev/null >>> +++ b/Documentation/zh_CN/arm64/silicon-errata.txt >>> @@ -0,0 +1,74 @@ >>> +Chinese translated version of Documentation/arm64/silicon-errata.txt >>> + >>> +If you have any comment or update to the content, please contact the >>> +original document maintainer directly. However, if you have a problem >>> +communicating in English you can also ask the Chinese maintainer for >>> +help. Contact the Chinese maintainer if this translation is outdated >>> +or if there is a problem with the translation. >>> + >>> +M: Will Deacon >>> +zh_CN: Fu Wei >>> +C: e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 >>> +- >>> +Documentation/arm64/silicon-errata.txt 的中文翻译 >>> + >>> +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 >>> +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 >>> +译存在问题，请联系中文版维护者。 >>> + >>> +英文版维护者： Will Deacon >>> +中文版维护者： 傅炜 Fu Wei >>> +中文版翻译者： 傅炜 Fu Wei >>> +中文版校译者： 傅炜 Fu Wei >>> +本文翻译提交时的 Git 检出点为： e835a65f7ab143acf9aee6f9a98ef1c7afd2a835 >>> + >>> +以下为正文 >>> +- >>> +芯片勘误和软件解决办法 >>> +== >>> + >>> +作者: Will Deacon >>> +日期: 2015年11月27日 >>> + >>> +一个不幸的现实：硬件经常带有一些所谓的“错误（errata）”，致使其在 >>> +某些特定的情况下会违背构架定义的行为。对基于 ARM 的硬件，这些错误 >>> +大体被分为以下几类： >>> + >>> + A 类：无可行解决方法的严重错误。 >>> + B 类：有可接受的解决方法的重大或严重错误。 >>> + C 类：在正常操作中不会显现的小错误。 >>> + >>> +更多资讯，请在 infocenter.arm.com （需注册）中查阅“软件开发者勘误 >>> +笔记”（“Software Developers Errata Notice”）文档。 >>> + >>> +对于 Linux 而言，B 类错误可能需要操作系统的某些特别处理。例如，避免 >>> +一个特殊的代码序列，或是以一种特定的方式配置处理器。在某种不太常见的 >>> +情况下，为将 A 类错误当作 C 类处理，可能需要用类似手段。这些手段被 >>> +统称为“软件解决办法”，且仅在少数情况需要（例如，那些需要一个在非安全 > > > I am thinking about a better translation of "workaround" > 变通方法 > 修补方案 > 替代办法 > 修正方案 > > Which one does look better to you? or do you have any suggestion? As discussed by Google Hangout. > > :-) > >>> +异常级运行的解决方法 *且* 能被 Linux 触发的情况）。 >> >> >> I think it may be better like this. >> >> （例如，那些需要在一个非安全异常级别运行的解决方法 *并且* 能被 Linux 触发的情况） > > > How about this? > （例如，那些需要一个运行在非安全异常级的解决方法 *并且* 能被 Linux 触发 的情况） > > Because 一个*解决方法 and "运行在非安全异常级的" is adjective。 ACK. > > >> >>> + >>> +对于尚在讨论中的可能对未受错误影响的系统产生不利影响的软件解决办法， >>> +有一个相应的内核配置（Kconfig）选项被加在 “内核特性（Kernel Features）” >>> +- > “基于可选方案框架的 ARM 错误解决办法（ARM errata workarounds via >>> +the alternatives framework）"。这些选项被默认开启，若探测到受影响的CPU， >>> +补丁将在运行时被打入。对于对系统运行影响较小的解决办法，内核配置选项 >>> +并不存在，且代码以一种避开错误的方式被构造（带注释为宜）。 >>> + >>> +这种做法对于在任意内核源代码树中准确地判断出哪个错误已被软件方法所解决 >>> +稍微有点麻烦，所以这个文件在 Linux 内核中作为软件解决办法的注册表， >>> +并将在新的软件解决办法被提交和反向移植到稳定内核时被更新。 >>> + >>> +| 实现者 | 受影响的组件| 勘误编号| 内核配置| >>> >>> +++-+-+-+ >>> +| ARM| Cortex-A53 | #826319 | >>> ARM64_ERRATUM_826319| >>> +| ARM| Cortex-A53 | #827319 | >>> ARM64_ERRATUM_827319| >>> +| ARM| Cortex-A53 | #824069 | >>> ARM64_ERRATUM_824069| >>> +| ARM| Cortex-A53 | #819472 | >>> ARM64_ERRATUM_819472| >>> +| ARM| Cortex-A53 | #845719 | >>> ARM64_ERRATUM_845719| >>> +| ARM| Cortex-A53 | #843419 | >>> ARM64_ERRATUM_843419| >>> +| ARM| Cortex-A57 | #832075 | >>> ARM64_ERRATUM_832075| >>> +| ARM| Cortex-A57 | #852523 | N/A >>> | >>> +| ARM| Cortex-A57 | #834220 | >>> ARM64_ERRATUM_834220| >>> +|| | | >>> | >>> +| Cavium | ThunderX ITS| #22375, #24313 | >>> CAVIUM_ERRATUM_22375| >>> +| Cavium | ThunderX GICv3 | #23154 | >>> CAVIUM_ERRATUM_23154| >>> -- >>> 2.5.0 >>> > Thanks, Harry
Re: [PATCH v4 01/11] drm/hisilicon: Add device tree binding for hi6220 display subsystem
On 9 February 2016 at 04:12, Rob Herring wrote:
> On Sat, Feb 06, 2016 at 11:24:48AM +0800, Xinliang Liu wrote:
>> Add ADE display controller binding doc.
>> Add DesignWare DSI Host Controller v1.20a binding doc.
>
> One comment, otherwise:
>
> Acked-by: Rob Herring
>
>> +Board specific:
>> + &dsi {
>> + status = "ok";
>> +
>> + ports {
>> + /* 1 for output port */
>> + port@1 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <1>;
>> +
>> + /* 0 for bridge, other value for panel */
>
> The endpoint address would not change based on bridge or panel. So you
> can drop the unit address here.
yes, I can drop the unit address, since it only support bridge in the
DSI code currently, right?
One question: How to distinguish panel and bridge endpoint? I am
thinking to support panel now.
Thanks,
-xinliang
>
>> + dsi_out0: endpoint@0 {
>> + reg = <0>;
>> + remote-endpoint = <&adv7533_in>;
>> + };
>> + };
>> + };
>> + };
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
