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: Fri, 28 Sep 2007 02:12:34 -0700 (PDT)	[thread overview]
Message-ID: <12937117.post@talk.nabble.com> (raw)
In-Reply-To: <46FC8EFE.2000108@mock.com>




Jeff Mock-2 wrote:
> 
> 
> 
> Misbah khan wrote:
>> 
>> 
>> Scott Wood-2 wrote:
>>> Misbah khan wrote:
>>>> Hi all I am using "test_bit(),set_bit(),clear_bit() etc" API functions 
>>>> provided by the Linux kernel. I want to know that if anybody is used it 
>>>> and have full faith in its operation then please let me know. Driver in 
>>>> the while loop is calling these API's hence i want to make sure that
>>>> its 
>>>> operation will remain stable.
>>> They're used all over the place.  Is there anything about them that you 
>>> find suspect?
>>>
>>> -Scott
>>>
>>> I have devloped a character driver for FPGA which is memory mapped and
>>> using these API's to test a bit , set a bit or to clear a bit in the
>>> memory for eg :-
>>>
>>> /* poll till data is transfered from sdram to dpram */
>>> 		while((test_bit(DFR_BUSY,(UINT32 *)(\
>>> 			(void *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
>>> 			&& (delay < MAX_DELAY_BUSY))
>>> 		{
>>> 			KDEBUG3(" In the Dfr delay loop \n");
>>> 			mdelay(DELAY);
>>> 			delay+=DELAY;
>>> 		}/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
>>>
>>> 		if(delay==MAX_DELAY_BUSY)
>>> 		{
>>> 			KDEBUG1("Out of the the Dfr busy loop \n");
>>> 			return -1;
>>> 		}
>>>
>>> People working for FPGA are sure that they are not making the bit high
>>> where in my driver is returning -1 from the kernel space aborting it
>>> after
>>> running for few minutes or so . Please let me know that This function is
>>> stable and i should tell them that the driver is stable in its operation
>>> and they should check it from there side.
>>>
> 
> 
> I think a more more likely source of the problem is that the FPGA
> pointer is not cast volatile, or perhaps the FPGA is mapped cached and 
> the hardware doesn't always get touched when you think it does.  The bit 
> manipulation macros are probably fine.
> 
> jeff
> 
> 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 
> 
> /* poll till data is transfered from sdram to dpram */
> 		while((test_bit(DFR_BUSY,(volatile UINT32 *)(\
> 			(volatile UINT32 *)mmap_reg_ptr + DATA_STATUS_REG))==1)\
> 			&& (delay < MAX_DELAY_BUSY))
> 		{
> 			KDEBUG3(" In the Dfr delay loop \n");
> 			mdelay(DELAY);
> 			delay+=DELAY;
> 		}/* End of while(test_bit(FPGA_BUSY,(void *)register name) */
> 
> 		if(delay==MAX_DELAY_BUSY)
> 		{
> 			KDEBUG1("Out of the the Dfr busy loop \n");
> 			return CASHEL_FAILURE;
> 		}
> __________________
> 
> is there anything else that we could do to rely fully in our code.
> 
> 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#a12937117
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

  reply	other threads:[~2007-09-28  9:12 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 [this message]
2007-09-30 14:54         ` Misbah khan
2007-10-01  4:25           ` Olof Johansson
2007-10-01  5:38             ` Misbah khan
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=12937117.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).