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 69E9FDDE18 for ; Thu, 27 Sep 2007 18:12:22 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IaoTr-0000R6-FL for linuxppc-embedded@ozlabs.org; Thu, 27 Sep 2007 01:12:19 -0700 Message-ID: <12916782.post@talk.nabble.com> Date: Thu, 27 Sep 2007 01:12:19 -0700 (PDT) From: Misbah khan To: linuxppc-embedded@ozlabs.org Subject: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19903_32446584.1190880739470" List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------=_Part_19903_32446584.1190880739470 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. I need your comments in this regard Thank you Misbah -- 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#a12916782 Sent from the linuxppc-embedded mailing list archive at Nabble.com. ------=_Part_19903_32446584.1190880739470 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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. I need your comments in this regard Thank you Misbah
View this message in context: Is it safe to use these Linux function (test_bit(),set_bit(),clear_bit()) in character device driver for 2.6.10 ppc kernel.
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
------=_Part_19903_32446584.1190880739470-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 07374DDE1C for ; Fri, 28 Sep 2007 02:10:39 +1000 (EST) Message-ID: <46FBD483.6090403@freescale.com> Date: Thu, 27 Sep 2007 11:04:19 -0500 From: Scott Wood MIME-Version: 1.0 To: Misbah khan 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. References: <12916782.post@talk.nabble.com> In-Reply-To: <12916782.post@talk.nabble.com> Content-Type: text/plain; charset=UTF-8; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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 C505BDDDF9 for ; Fri, 28 Sep 2007 14:29:03 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Ib7TH-0000pN-Bn for linuxppc-embedded@ozlabs.org; Thu, 27 Sep 2007 21:28:59 -0700 Message-ID: <12934517.post@talk.nabble.com> Date: Thu, 27 Sep 2007 21:28:59 -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: <46FBD483.6090403@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. > > 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#a12934517 Sent from the linuxppc-embedded mailing list archive at Nabble.com. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mock.com (gw.mock.com [209.157.146.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.mock.com", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 309E3DDE11 for ; Fri, 28 Sep 2007 15:20:04 +1000 (EST) Message-ID: <46FC8EFE.2000108@mock.com> Date: Thu, 27 Sep 2007 22:19:58 -0700 From: Jeff Mock MIME-Version: 1.0 To: Misbah khan 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. References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> In-Reply-To: <12934517.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 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 6784DDDE17 for ; Fri, 28 Sep 2007 19:12:37 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IbBti-0007Qp-6w for linuxppc-embedded@ozlabs.org; Fri, 28 Sep 2007 02:12:34 -0700 Message-ID: <12937117.post@talk.nabble.com> Date: Fri, 28 Sep 2007 02:12:34 -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: <46FC8EFE.2000108@mock.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> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTP id C2542DDE05 for ; Sat, 29 Sep 2007 02:10:01 +1000 (EST) Message-ID: <46FD273A.1050503@freescale.com> Date: Fri, 28 Sep 2007 11:09:30 -0500 From: Scott Wood MIME-Version: 1.0 To: Misbah khan 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. References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> In-Reply-To: <12934517.post@talk.nabble.com> Content-Type: text/plain; charset=UTF-8; format=flowed Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Misbah khan wrote: > > > Scott Wood-2 wrote: >> 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 :- Please don't use quote markers on newly added text. >> /* 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)) You should use in_be32() rather than direct dereferencing. >> { >> 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 . I don't suppose the "few minutes" corresponds to MAX_DELAY_BUSY? -Scott 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lixom.net (lixom.net [66.141.50.11]) by ozlabs.org (Postfix) with ESMTP id E0726DDE26 for ; Mon, 1 Oct 2007 14:22:12 +1000 (EST) Date: Sun, 30 Sep 2007 23:25:59 -0500 From: Olof Johansson To: Misbah khan 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. Message-ID: <20071001042559.GA32255@lixom.net> References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> <46FC8EFE.2000108@mock.com> <12937117.post@talk.nabble.com> <12966462.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <12966462.post@talk.nabble.com> Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , First, PLEASE stop quoting your own text. Do not append > in front of the lines you write yourself in the reply. It makes it impossible to tell what parts are new and what are old. On Sun, Sep 30, 2007 at 07:54:28AM -0700, Misbah khan wrote: > >> 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 You cannot ever use set_bit/clear_bit to uncacheable memory. Ever. It uses load-reserve/store-conditional, and they are not legal to use to uncacheable memory. Also, regular ioremap() is by default uncacheable, so it's quite adequate to use in this case, no need to use the _nocache version. > >> do you think in_be32() could be the best approach than direct > >> dereferencing. And about test_bit() function does it looks fine to you You need to use in_be32() + manipulating the value + out_be32(), yes. Depending on the rest of your driver you might need to protect it with a spinlock, but that's beyond the scope of this question. -Olof 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 8F49ADDE03 for ; Mon, 1 Oct 2007 15:38:35 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IcDzE-0006tp-BR for linuxppc-embedded@ozlabs.org; Sun, 30 Sep 2007 22:38:32 -0700 Message-ID: <12973587.post@talk.nabble.com> Date: Sun, 30 Sep 2007 22:38:32 -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: <20071001042559.GA32255@lixom.net> 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> <12966462.post@talk.nabble.com> <20071001042559.GA32255@lixom.net> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Olof Johansson-2 wrote: > > First, PLEASE stop quoting your own text. Do not append > in front of > the lines you write yourself in the reply. It makes it impossible to > tell what parts are new and what are old. > > On Sun, Sep 30, 2007 at 07:54:28AM -0700, Misbah khan wrote: > >> >> 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 > > You cannot ever use set_bit/clear_bit to uncacheable memory. Ever. It > uses load-reserve/store-conditional, and they are not legal to use to > uncacheable memory. > > Also, regular ioremap() is by default uncacheable, so it's quite adequate > to use in this case, no need to use the _nocache version. > >> >> do you think in_be32() could be the best approach than direct >> >> dereferencing. And about test_bit() function does it looks fine to you > > You need to use in_be32() + manipulating the value + out_be32(), > yes. Depending on the rest of your driver you might need to protect it > with a spinlock, but that's beyond the scope of this question. > > > -Olof > > I am confused that some people tells me to map the memory noncacheble and > some tells me not. could you tell me which is the best approach and please > elaborate the reason as well. The part of the code is mentioned above is a > reference and my concern are as follows:- > > 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it > absolutely fine???? > > 2. I am directly dereferencing the pointer to the mapped region insted of > using a wrapper function due to (1) Aready used in the past and have faith > in it . > (2) I had used functions like ioread32() iowrite32() in the past which > is suggested by rubini in his book on Linux device Driver but the output i > got was bitswapped . > > 3. test_bit()/clear_bit() are the functions which i am using in my driver > and in the way i described above , please let me know that is looks fine > in the Implimention or shall i read the value and mask the bits rather > than beliving in these functions for eg :- > > dfr_data_ret=*(volatile UINT32 *)((volatile UINT32 > *)mmap_reg_ptr+DATA_STATUS_REG); > > dfr_data_ret&=STATUS_MASK; > > Please reply to clear my doubts. > > 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#a12973587 Sent from the linuxppc-embedded mailing list archive at Nabble.com. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lixom.net (lixom.net [66.141.50.11]) by ozlabs.org (Postfix) with ESMTP id 36786DDE18 for ; Mon, 1 Oct 2007 23:51:25 +1000 (EST) Date: Mon, 1 Oct 2007 08:55:16 -0500 From: Olof Johansson To: Misbah khan 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. Message-ID: <20071001135516.GA8572@lixom.net> References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> <46FC8EFE.2000108@mock.com> <12937117.post@talk.nabble.com> <12966462.post@talk.nabble.com> <20071001042559.GA32255@lixom.net> <12973587.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <12973587.post@talk.nabble.com> Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sun, Sep 30, 2007 at 10:38:32PM -0700, Misbah khan wrote: > Olof Johansson-2 wrote: > > > > First, PLEASE stop quoting your own text. Do not append > in front of > > the lines you write yourself in the reply. It makes it impossible to > > tell what parts are new and what are old. Please read the above again, since you didn't fix your mailer. Also, make sure it doesn't prepend spaces in front of the lines you are writing. > > I am confused that some people tells me to map the memory noncacheble and > > some tells me not. could you tell me which is the best approach and please > > elaborate the reason as well. The part of the code is mentioned above is a > > reference and my concern are as follows:- It depends on your application and how the FPGA is attached. Buf if it is attached outside of the coherence domain (for example on PCI), then you should map it uncacheable. Otherwise you will have to do manual flushing of caches to make sure writes make it out to the device, and also flush any copy in cache before you read any register. In other words, it makes things considerably more complicated and error-prone. > > 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it > > absolutely fine???? Just use ioremap(). > > 2. I am directly dereferencing the pointer to the mapped region insted of > > using a wrapper function due to (1) Aready used in the past and have faith > > in it . I don't care if you have faith in it or not, it's still not the correct way to do it. It might work right some of the time by pure luck but it is the incorrect way of accessing device memory. > > (2) I had used functions like ioread32() iowrite32() in the past which > > is suggested by rubini in his book on Linux device Driver but the output i > > got was bitswapped . I assume you mean byte swapped and not bit swapped. Are your registers on the device big- or little endian? If they are big endian, use in_be32/out_be32. If they're little endian, use in_le32/out_le32. That will take care of any swapping for you. > > 3. test_bit()/clear_bit() are the functions which i am using in my driver > > and in the way i described above , please let me know that is looks fine > > in the Implimention No it is not fine. You cannot use set_bit/clear_bit against noncacheable memory. EVER. > > or shall i read the value and mask the bits rather > > than beliving in these functions for eg :- > > > > dfr_data_ret=*(volatile UINT32 *)((volatile UINT32 > > *)mmap_reg_ptr+DATA_STATUS_REG); > > > > dfr_data_ret&=STATUS_MASK; > > > > Please reply to clear my doubts. Just do what I told you earlier: To read the status register, mask out the STATUS_MASK and write it back, do: val = in_be32(mmap_reg_ptr + DATA_STATUS_REG); val &= STATUS_MASK; out_be32(MMAP_REG_PTR + DATA_STATUS_REG, val); -Olof 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 5D900DDE07 for ; Thu, 4 Oct 2007 23:02:59 +1000 (EST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IdQLt-0007E5-RL for linuxppc-embedded@ozlabs.org; Thu, 04 Oct 2007 06:02:53 -0700 Message-ID: <13039401.post@talk.nabble.com> Date: Thu, 4 Oct 2007 06:02:53 -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: <20071001135516.GA8572@lixom.net> 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> <12966462.post@talk.nabble.com> <20071001042559.GA32255@lixom.net> <12973587.post@talk.nabble.com> <20071001135516.GA8572@lixom.net> List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi ... I did followed you and it worked as well. I really Thank you for it. At one Place i am doing memcpy() of floating point data to the memory mapped registers, what could be the substitute of it like "memcpy_toio() " which is suggested in the Book. I am working BE architecture. I would really appreaciate if you would let me know the defineation of these wrapper functions (in_be32,out_be32(),ioread32(),iowrite32(),etc) so that i could have the clear idea of the reason for not directly dreferencing the Pointer. Misbah Olof Johansson-2 wrote: > > On Sun, Sep 30, 2007 at 10:38:32PM -0700, Misbah khan wrote: > >> Olof Johansson-2 wrote: >> > >> > First, PLEASE stop quoting your own text. Do not append > in front of >> > the lines you write yourself in the reply. It makes it impossible to >> > tell what parts are new and what are old. > > Please read the above again, since you didn't fix your mailer. > > Also, make sure it doesn't prepend spaces in front of the lines you are > writing. > >> > I am confused that some people tells me to map the memory noncacheble >> and >> > some tells me not. could you tell me which is the best approach and >> please >> > elaborate the reason as well. The part of the code is mentioned above >> is a >> > reference and my concern are as follows:- > > It depends on your application and how the FPGA is attached. Buf if it is > attached outside of the coherence domain (for example on PCI), then you > should map it uncacheable. Otherwise you will have to do manual flushing > of caches to make sure writes make it out to the device, and also flush > any copy in cache before you read any register. In other words, it makes > things considerably more complicated and error-prone. > >> > 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it >> > absolutely fine???? > > Just use ioremap(). > >> > 2. I am directly dereferencing the pointer to the mapped region insted >> of >> > using a wrapper function due to (1) Aready used in the past and have >> faith >> > in it . > > I don't care if you have faith in it or not, it's still not the correct > way to do it. It might work right some of the time by pure luck but it > is the incorrect way of accessing device memory. > >> > (2) I had used functions like ioread32() iowrite32() in the past >> which >> > is suggested by rubini in his book on Linux device Driver but the >> output i >> > got was bitswapped . > > I assume you mean byte swapped and not bit swapped. > > Are your registers on the device big- or little endian? > > If they are big endian, use in_be32/out_be32. If they're little endian, > use > in_le32/out_le32. That will take care of any swapping for you. > >> > 3. test_bit()/clear_bit() are the functions which i am using in my >> driver >> > and in the way i described above , please let me know that is looks >> fine >> > in the Implimention > > No it is not fine. You cannot use set_bit/clear_bit against noncacheable > memory. EVER. > >> > or shall i read the value and mask the bits rather >> > than beliving in these functions for eg :- >> > >> > dfr_data_ret=*(volatile UINT32 *)((volatile UINT32 >> > *)mmap_reg_ptr+DATA_STATUS_REG); >> > >> > dfr_data_ret&=STATUS_MASK; >> > >> > Please reply to clear my doubts. > > Just do what I told you earlier: > > To read the status register, mask out the STATUS_MASK and write it > back, do: > > val = in_be32(mmap_reg_ptr + DATA_STATUS_REG); > val &= STATUS_MASK; > out_be32(MMAP_REG_PTR + DATA_STATUS_REG, val); > > > -Olof > _______________________________________________ > 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#a13039401 Sent from the linuxppc-embedded mailing list archive at Nabble.com. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by ozlabs.org (Postfix) with ESMTP id 8BB48DDE0D for ; Fri, 5 Oct 2007 02:42:35 +1000 (EST) Received: by nz-out-0506.google.com with SMTP id i1so210360nzh for ; Thu, 04 Oct 2007 09:42:34 -0700 (PDT) Message-ID: Date: Thu, 4 Oct 2007 10:42:33 -0600 From: "Grant Likely" Sender: glikely@secretlab.ca To: "Misbah khan" 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: <13039401.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <12916782.post@talk.nabble.com> <46FBD483.6090403@freescale.com> <12934517.post@talk.nabble.com> <46FC8EFE.2000108@mock.com> <12937117.post@talk.nabble.com> <12966462.post@talk.nabble.com> <20071001042559.GA32255@lixom.net> <12973587.post@talk.nabble.com> <20071001135516.GA8572@lixom.net> <13039401.post@talk.nabble.com> Cc: linuxppc-embedded@ozlabs.org List-Id: Linux on Embedded PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 10/4/07, Misbah khan wrote: > > Hi ... > I did followed you and it worked as well. I really Thank you for it. > > At one Place i am doing memcpy() of floating point data to the memory mapped > registers, what could be the substitute of it like "memcpy_toio() " which is > suggested in the Book. I am working BE architecture. > > I would really appreaciate if you would let me know the defineation of these > wrapper functions (in_be32,out_be32(),ioread32(),iowrite32(),etc) so that i > could have the clear idea of the reason for not directly dreferencing the > Pointer. You don't want to directly dereference pointers to device registers because you don't want the processor or compiler to reorder your register accesses. The in/out_* wrappers keeps the compiler from reordering things, and the wrappers contain the 'sync' instruction which prevents the processor from reordering operations at runtime. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. grant.likely@secretlab.ca (403) 399-0195