Misbah khan wrote:
>
>
>
> 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
>> MAX_DELAY_BUSY corresponds to 10 ms .Driver should poll the bit for few
>> micro second at the max and come out .
>>
>> I had earlier tried with ioread32() and iowrite32() wrapper functions but
>> the output i got is bit swapped hence i went for direct dereferencing
>> the pointer .
>>
>> do you think in_be32() could be the best approach than direct
>> dereferencing. And about test_bit() function does it looks fine to you
>>
>> 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#a12966462
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
