From: Misbah khan <misbah_khan@engineer.com>
To: linuxppc-embedded@ozlabs.org
Subject: Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
Date: Sun, 30 Sep 2007 22:38:32 -0700 (PDT) [thread overview]
Message-ID: <12973587.post@talk.nabble.com> (raw)
In-Reply-To: <20071001042559.GA32255@lixom.net>
Olof Johansson-2 wrote:
>
> First, PLEASE stop quoting your own text. Do not append > in front of
> the lines you write yourself in the reply. It makes it impossible to
> tell what parts are new and what are old.
>
> On Sun, Sep 30, 2007 at 07:54:28AM -0700, Misbah khan wrote:
>
>> >> FPGA is Indeed mapped non cashed here is the part of the code
>> >>
>> >> /* Physical bus memory is mapped */
>> >> mmap_reg_ptr=(UINT32 *)ioremap_nocache(PHY_MEM_ADDR,PHY_MEM_SIZE);
>> >>
>> >> And is it ok if I caste FPGA pointer volatile like this will reduce
>> the
>> >> probability of failure
>
> You cannot ever use set_bit/clear_bit to uncacheable memory. Ever. It
> uses load-reserve/store-conditional, and they are not legal to use to
> uncacheable memory.
>
> Also, regular ioremap() is by default uncacheable, so it's quite adequate
> to use in this case, no need to use the _nocache version.
>
>> >> do you think in_be32() could be the best approach than direct
>> >> dereferencing. And about test_bit() function does it looks fine to you
>
> You need to use in_be32() + manipulating the value + out_be32(),
> yes. Depending on the rest of your driver you might need to protect it
> with a spinlock, but that's beyond the scope of this question.
>
>
> -Olof
>
> I am confused that some people tells me to map the memory noncacheble and
> some tells me not. could you tell me which is the best approach and please
> elaborate the reason as well. The part of the code is mentioned above is a
> reference and my concern are as follows:-
>
> 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it
> absolutely fine????
>
> 2. I am directly dereferencing the pointer to the mapped region insted of
> using a wrapper function due to (1) Aready used in the past and have faith
> in it .
> (2) I had used functions like ioread32() iowrite32() in the past which
> is suggested by rubini in his book on Linux device Driver but the output i
> got was bitswapped .
>
> 3. test_bit()/clear_bit() are the functions which i am using in my driver
> and in the way i described above , please let me know that is looks fine
> in the Implimention or shall i read the value and mask the bits rather
> than beliving in these functions for eg :-
>
> dfr_data_ret=*(volatile UINT32 *)((volatile UINT32
> *)mmap_reg_ptr+DATA_STATUS_REG);
>
> dfr_data_ret&=STATUS_MASK;
>
> Please reply to clear my doubts.
>
> Misbah
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/Is-it-safe-to-use-these-Linux-function-%28test_bit%28%29%2Cset_bit%28%29%2Cclear_bit%28%29%29-in-character-device-driver-for-2.6.10-ppc-kernel.-tf4527008.html#a12973587
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
next prev parent reply other threads:[~2007-10-01 5:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-27 8:12 Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel Misbah khan
2007-09-27 16:04 ` Scott Wood
2007-09-28 4:28 ` Misbah khan
2007-09-28 5:19 ` Jeff Mock
2007-09-28 9:12 ` Misbah khan
2007-09-30 14:54 ` Misbah khan
2007-10-01 4:25 ` Olof Johansson
2007-10-01 5:38 ` Misbah khan [this message]
2007-10-01 13:55 ` Olof Johansson
2007-10-04 13:02 ` Misbah khan
2007-10-04 16:42 ` Grant Likely
2007-09-28 16:09 ` Scott Wood
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=12973587.post@talk.nabble.com \
--to=misbah_khan@engineer.com \
--cc=linuxppc-embedded@ozlabs.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).