linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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.

  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).