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
> [email protected]
> 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.
_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
