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.

[Misbah khan <misbah_khan@engineer.com>]

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.