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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.