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.
next prev parent 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).