[Armadillo:07141] Re: [Armadillo-440] I2C通信で失敗する

g-kihara email@hidden
2011年 4月 26日 (火) 12:29:29 JST


> 独自機器も接続していない状態で、「Could not grab Bus ownership」が発生
しているということは
> どういうことなのでしょうか?

他のデバイスドライバがgrab Bus ownershipしようとしているということで
すね。

/sys/devices/platform/の下にi2c_hoge.1
のような名前のフォルダはありますか?
あったら、そのフォルダの下をls -l でみせていただけませんか?

以上


(2011/04/26 11:55), 下村智範 wrote:
> お世話になっております。
> 下村です。
> 
>> - 起動ログで「Could not grab Bus ownership」が発生していますか?(RTCドライバでエラーが発生している)
>> - アプリで通信しようとしたときに、「Could not grab Bus ownership」が発生していますか?
> 両方で発生しております。
> 独自機器を接続していてもいなくても発生しております。
> 
>>> 上記のように修正しても、I2C-1 スレーブアドレス = 0x30 が一度セットされて
>>> ダミーコールされているようでした。
>> これは、どこで確認した結果でしょうか?
> 起動時に出力されたと思われるログ(dmesg)で確認しました。
> 
>> - アプリでアドレス0x30を指定した
>> - SDA/SCLをプロトコルアナライザ等で確認したところ、アドレス部分が0x30になっていた
>> - I2Cスレーブデバイスのレジスタを確認したところ、0x30になっていた
> こちらは全部確認しておりません。
> 
> 起動時のダミークロック出力処理、およびRTCドライバのはずし方をご教授いただきましたので
> ひとつずつ適用したKernelを作成し、試してみました。
> 結果、初期化処理が若干変わったようですが、すべてのdmesgログにおいて
> 「Could not grab Bus ownership」が発生していることを確認いたしました。
> 独自機器も接続していない状態で、「Could not grab Bus ownership」が発生しているということは
> どういうことなのでしょうか?
> RTCドライバかダミークロック処理をはずせば、起動時は「Could not grab Bus ownership」が
> 発生しないのではないかと期待しておりましたが、ちょっと予想外でした。
> ログを保存しておりますので、添付させていただきます。
> 
>>> おそらくですが、この仕様書に記載されているサンプルソースでも
>>> バス競合が発生すると思います。
>> こちらで確認している限りでは、問題なく動いています。
> 動作しているサンプルソースがございましたら、ご提供いただけませんでしょうか。
> 参考にさせていいただきたいと思います。
> 
> まったく原因がわかりません・・・。
> 独自機器を作成していただいた企業様にも協力をお願いしておりますが
> なかなか原因特定にいたりません。
> 些細な情報でも不確かな情報でも構いません。
> 何かございましたら、ご教授お願いいたします。
> 
> 以上、よろしくお願いいたします。
> 
> 
> 2011年4月23日17:33 Takenoshita Koyo<email@hidden>:
>> 竹之下です。
>>
>>> ダミー初期化は、動作不能なスレーブデバイスを救うための処理ですので
>>> 電源投入時のダミー初期化処理で、「Could not grab Bus ownership」が
>>> 発生するということは、根本的に何か設定ができていないのではないかと
>>> 思いますが、いかがでしょうか。
>> "電源投入時のダミー初期化処理"が、"起動時に128回のダミークロックを出力すること"だとして、
>>
>> 「Could not grab Bus ownership」が発生しているのは、"電源投入時のダミー初期化処理"時
>> ではありません。"電源投入時のダミー初期化処理"時には、単にSCLをHigh->Low->High->Lowと
>> 強制的に変化させているだけですので、エラーが発生したかどうか、は確認していません。
>>
>> 「Could not grab Bus ownership」が発生しているのは、RTCドライバかアプリが(i2c-dev経由で)
>> スレーブデバイスとの通信をしようとしたとき、どちらかのはずです。
>> 「Could not grab Bus ownership」が発生しているのは、どちらでしょうか?
>> - 起動ログで「Could not grab Bus ownership」が発生していますか?(RTCドライバでエラーが発生している)
>> - アプリで通信しようとしたときに、「Could not grab Bus ownership」が発生していますか?
>>
>>> 上記のように修正しても、I2C-1 スレーブアドレス = 0x30 が一度セットされて
>>> ダミーコールされているようでした。
>> これは、どこで確認した結果でしょうか?
>> - アプリでアドレス0x30を指定した
>> - SDA/SCLをプロトコルアナライザ等で確認したところ、アドレス部分が0x30になっていた
>> - I2Cスレーブデバイスのレジスタを確認したところ、0x30になっていた
>>
>>> armadillo400.c以外にも設定箇所がございますでしょうか。
>>> (armadillo400_gpio.cも確認しましたが、スレーブに関する処理は
>>> ございませんでしたので、何も修正しておりません)
>> i2c-dev経由でスレーブデバイスと通信をしたい場合は、何も変更する必要はありません。
>>
>>> ダミー初期化に関してですが、本処理は稀なエラー処理になりますので
>>> I2Cの接続が確認できていない現段階では、原因切り分けのために
>>> はずしたいと考えております。
>>> (しっかりとI2C接続が確立された後に、稀なエラー処理に対応したいと思います)
>>>
>>> どのように修正すれば多機能に弊害なく初期化処理がはずせますでしょうか。
>> 以下のように、ダミークロックを生成している関数で、何もしないようにすると
>> 良いと思います。
>> --- a/arch/arm/mach-mx25/armadillo400_gpio.c
>> +++ b/arch/arm/mach-mx25/armadillo400_gpio.c
>> @@ -864,6 +864,8 @@ int gpio_i2c_dummy_clock(unsigned gpio_clk, unsigned gpio_da
>>   {
>>         int i;
>>
>> +       return 0;
>> +
>>         if (gpio_request(gpio_clk, "i2c_clk_gpio"))
>>                 return -EINVAL;
>>
>>
>> また、RTCドライバも外してしまえば、I2Cバスを動かす要因が自分のアプリだけに
>> なるので、デバッグしやすくなると思います。menuconfigで、以下のように
>> コンフィギュレーションを変更してください。
>>
>> Linux Kernel Configuration
>>   Device Drivers
>>     <*>  Real Time Clock  --->
>>       <  >    Seiko Instruments S-35390A #チェックを外す
>>
>>> おそらくですが、この仕様書に記載されているサンプルソースでも
>>> バス競合が発生すると思います。
>> こちらで確認している限りでは、問題なく動いています。
>>
>> --
>> Koyo Takenoshita
>>
>> _______________________________________________
>> armadillo mailing list
>> email@hidden
>> http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo
>>
>>
>>
>> _______________________________________________
>> armadillo mailing list
>> email@hidden
>> http://lists.atmark-techno.com/cgi-bin/mailman/listinfo/armadillo



armadillo メーリングリストの案内