コグノスケ

未来から過去へ表示(*) link

過去から未来へ表示

もっと前

2019年7月4日 >>> 2019年6月21日

もっと後

2019年7月4日

permalink

編集する

HiFive Unleashedの動作周波数

目次: RISC-V

SiFive FU540のコア動作周波数は簡単に見ることはできなかったので、求め方をメモしておきます。

アドレス0x10000000にPRCI（Power Reset Clocking Interrupt）のレジスタがありますので、実機でその辺をダンプします。

突然ダンプしますって言われても、どうしたら良いんですか？という方は拙作のmemaccess（GitHubへのリンク）をお使いください。使い慣れたツールがあれば、RISC-V上でビルドすれば使えます（UnleashedはLinuxが動くので）。

私の持っているHiFive Unleashedでは下記のようになっていました。

PRCIレジスタ領域のダンプ

10000000 c0000000 82110ec0 00000000 82110dc0
10000010 80000000 00000000 00000000 82128ec0
10000020 80000000 00000000 0000002f 00000004

COREPLL周波数を司るレジスタは、corepllcfg0（offset: 0x04）です。値は0x82110ec0ですね。

[ 5: 0] divr = 0x0
[14: 6] divf = 0x3b = 59
[17:15] divq = 0x2
[20:18] range = 3'b100 => 33MHz

レジスタの各フィールドはこんな意味になっています。計算式は、

COREPLL周波数の計算式

COREPLL = 33.33MHz / (divr + 1) * 2 * (divf + 1) / 2 ^ divq

ですので、上記の値を当てはめますと、

COREPLL周波数

COREPLL
= 33.33MHz / (0 + 1) * 2 * (59 + 1) / 2 ^ 2
= 33.33 * 120 / 4 = 999.99MHz≒1GHz

すなわち1GHz駆動であることがわかります。

ウソは書いていないつもりですが、情報源が気になる方はFU540の仕様書 "Chapter.7 Cloking and Reset" の章を見てください。

FU540の仕様書はSiFiveのサイト（FU540のサイトへのリンク）から、誰でもゲットできます。ページの下側かつ左側にある "FU540-C000 Manual" と書いてあるリンクです。

ARMの場合は簡単

Unleashedは面倒でしたが、Rockchip系（に限らないと思いますが）のSoCは /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freqを見ると簡単に最大動作周波数を取得できます。

RK3328の各コアの最大動作周波数

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1296000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1296000

RK3399の各コアの最大動作周波数

$ for i in /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_max_freq ; do echo $i; cat $i; done
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_max_freq
1416000
/sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq
1800000
/sys/devices/system/cpu/cpu5/cpufreq/cpuinfo_max_freq
1800000

簡単で良いですね。こういう細かい使い勝手はRISC-Vはこれからでしょうか。とはいえ世界はRISC-V旋風が吹き荒れているそうなので、次第に充実していくことでしょう。

メモ: 技術系の話はFacebookから転記しておくことにした。大幅に追記。

編集者:すずき(2021/06/28 15:25)

コメント一覧

コメントはありません。

この記事にコメントする

2019年6月27日

permalink

編集する

ROCK64の音がlinux-nextで鳴らなくなった

目次: ARM

ある時からlinux-nextでROCK64のPCMデバイスが全部消えて、一切音が鳴らなくなっていました。ROCKPro64も同じようです。

結論だけ先に言うと、この問題は既にALSA MLで指摘されていて、下記のコミットをリバートすると直ります。

問題のコミット

commit b9f2e25c599bbbf0646957e07ebb72b942c286cc
Author: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Date:   Thu Jun 20 09:49:33 2019 +0900

    ASoC: soc-core: use soc_find_component() at snd_soc_find_dai()

    snd_soc_find_dai() finds component first via specified
    snd_soc_dai_link_component, and find DAI from it.

    We already have soc_find_component() to find component,
    but soc_find_dai() has original implementation to find component.

    We shouldn't have duplicate implementation to do same things.
    This patch uses soc_find_component() at soc_find_dai()

    Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
    Signed-off-by: Mark Brown <broonie@kernel.org>

これは散々調べた後で知りました。悲しい。せっかくなので調べたこともメモしておきます。

ASoCとコンポーネントの登録

最近、ALSA SoC Layer（以下、ASoC）は、ルネサスの森本さんという方の尽力により、実装がかなり変わっているのですが、その一部がバグっていたようです。

ASoCは大まかにいうと、登録と組み合わせの2段階に分かれています。

ドライバのprobe時に、2つのcomponentを登録します。正式な呼び名がわからないので、ここではとりあえずPCMとDMACのcomponentと呼びます。

PCM componentはDAI（Digital Audio Interface）を持っています。DAIはPCMデータの入出力インタフェースのことらしいです。他にもCODECと呼ばれる、PCMデータ（デジタル音声）←→ アナログ音声に変換するドライバもcomponentとして扱われています。

サウンドカードのドライバは、複数のcomponentを組み合わせて、PCMの入出力やアナログ音声出力などを実現する仕組みです。

もう少しコード寄りに説明するとPCM componentはdevm_snd_soc_register_component() を使い、DMAC componentはdevm_snd_dmaengine_pcm_register() を使って登録します。

これらの関数を呼び出すと、

PCM用のcomponent登録時


devm_snd_soc_register_component()
  snd_soc_register_component()
    snd_soc_add_component()
      snd_soc_register_dais()
        soc_add_dai()          ★DAIをcomponentに登録★
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★componentをリストに登録★

DMAC用のcomponent登録時


devm_snd_dmaengine_pcm_register()
  snd_dmaengine_pcm_register()
    snd_soc_add_component()
      snd_soc_component_add()
        list_add(&component->list, &component_list); ★componentをリストに登録★

このような経路を辿ります。

一方、componentを組み合わせる際は、

componentを組み合わせてサウンドカードを登録


devm_snd_soc_register_card()
  snd_soc_register_card()
    snd_soc_bind_card()
      snd_soc_instantiate_card()
        soc_bind_dai_link()
          snd_soc_find_dai()
            soc_find_component() ★最近変更された部分、適切なcomponentを探す、しかし…★

このように処理されます。

問題の箇所

前置きがかなり長くなりましたが、上記の処理のうちsnd_soc_find_dai() の変更にバグがあるようです。元々は関数内にcomponentを探す処理が記述されていましたが、処理は削除されsoc_find_component() で適切なコンポーネントを探してくる、という実装に変わりました。

先ほど説明した通り、大抵のASoCドライバはPCM用のcomponentをdevm_snd_soc_register_component() で、DMAC用のコンポーネントをdevm_snd_dmaengine_pcm_register() で登録しますが、かなり残念なことに双方とも全く同じ名前で登録されてしまいます。

例えばROCKPro64で /sys/kernel/debug/asoc/componentsを見ると、

ASoC登録済みcomponent一覧を見る方法

root@rockpro64:/# cat /sys/kernel/debug/asoc/components
hdmi-audio-codec.3.auto
ff870000.spdif
ff870000.spdif
ff8a0000.i2s
ff8a0000.i2s
ff890000.i2s
ff890000.i2s
ff880000.i2s
ff880000.i2s
spdif-dit
snd-soc-dummy

このように、同じ名前のcomponentが2つ登録されていることがわかります。今回のバグの件をさておいても、名前が重複しているのはイマイチですよね……。

組み合わせる際はdevm_snd_soc_register_component() で登録した方、つまりPCM用のcomponent（こいつがDAIを持っている）を探してこなければ、PCMデバイスは正常に登録されません。

しかしsoc_find_component() は動きがおかしくて、devm_snd_dmaengine_pcm_register() で登録した方のコンポーネントを返してしまいます。

結果、DAIが見つけることができず、エラーになってしまい、1つもサウンドカードが登録されないままドライバの登録処理が終わります。