From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 623DADDE04 for ; Mon, 1 Oct 2007 00:54:31 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ic0Bg-000573-0g for linuxppc-embedded@ozlabs.org; Sun, 30 Sep 2007 07:54:28 -0700 Message-ID: <12966462.post@talk.nabble.com> Date: Sun, 30 Sep 2007 07:54:28 -0700 (PDT) From: Misbah khan 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. In-Reply-To: <12937117.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> <46FC8EFE.2000108@mock.com> <12937117.post@talk.nabble.com> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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.