Re: I/O caching prob

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



embedded 101
------------
use volatile variables.
Muthu.


On Thu, 1 Apr 2004, Mandeep Singh Sandhu wrote:

> hi all,
>
> i'm facing a problem while reseting a chip.
> to reset the chip (RTL8139) i write a byte into it's
> command reg. and wait for the a bit to be 0 which
> indicates that the reset is complete.
>
> to test this bit i had first written a tight while loop
> as follows
>
> while((readb(ChipCmdReg) & ResetCmd) == 0);
>
> but the comp used to hang when it used reach this loop.
> it never came out.
>
> then i wrote:
> i = 1000;
> while(i)
> 	if((readb(ChipCmdReg) & ResetCmd) == 0)
> 		break;
> 	else
> 		i--;
>
> this worked!
> can ne one tell why the first way of testing the reset bit does not
> work, is it b'cos of some CPU caching, cos i also inserted a rmb()
> call but that too did not help.
>
> TIA
>
> - /dev/mandeep
>
>
> -----Original Message-----
> From: Curran, Dominic [mailto:dcurran@ti.com]
> Sent: Thursday, March 25, 2004 11:12 PM
> To: Mandeep Singh Sandhu; kernelnewbies@nl.linux.org
> Subject: RE: PCI DMA mapping question
>
>
>
> I was under the impression that GFP_DMA was only needed if you were
> allocating memory to be used with the ISA bus.  At least on x86 the PCI bus
> can perform DMA on any 32-bit memory address.
>
> ISA (presumably because it's a 16-bit bus) can only access memory from 0 to
> 16MB, and this is why GFP_DMA is needed.
>
> Am I completely wrong ?
>
> dom
>
>
>
> -----Original Message-----
> From: Momchil Velikov [mailto:velco@fadata.bg]
> Sent: Thursday, March 25, 2004 3:19 PM
> To: Mandeep Singh Sandhu
> Subject: Re: PCI DMA mapping question
>
>
> >>>>> "Mandeep" == Mandeep Singh Sandhu <mandeep_sandhu@infosys.com>
> >>>>> writes:
>
> Mandeep> if i'm allocating by transmit and recieve buffers,
> Mandeep> for my ethernet driver, using pci_alloc_consistent then do i
> Mandeep> need to establish bounce buffers as well in case i get a
> Mandeep> mapping in a non-DMA zone?? but in Rubini's book it's written -
> Mandeep> "Allocation is handled in this function so that the buffer will
> Mandeep> be placed in a location that works with DMA..."
>
>   That function checks the device addressing capabilities.  It assumes that
> if a device can be addressed in a region with certain characteristics then
> *IT* can also address any region with the same characteristics.  For
> example, if a device requested to be accessible for MMIO in a region under
> 1M, the kernel assumes that the device itself can address any region under
> 1M, thus it allocates page(s) with GFP_DMA set.
>
> Mandeep> so then do i need to keep bounce buffers??
>
>   I'm not sure what's the exact meaning of ``bounce buffer''.  I tend to
> think that these ARE the bounce buffers (as opposed to having potentially
> larger buffers elsewhere or locking user pages for doing DMA to them).
>
> Mandeep> then it says that the allocation uses GFP_ATOMIC priority,
> Mandeep> shud'nt it use the GFP_DMA priority instead to ensure the
> Mandeep> addresses are allocated in the DMA zone??
>
>   GFP_ATOMIC and GPF_DMA are independent and can be set at once. GFP_ATOMIC
> means ``don't sleep'' (which, btw, is by no means ``atomic''), GPF_DMA means
> ``allocate under 1M''.
>
> ~velco
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive:       http://mail.nl.linux.org/kernelnewbies/
> FAQ:           http://kernelnewbies.org/faq/
>
>
> --
> Kernelnewbies: Help each other learn about the Linux kernel.
> Archive:       http://mail.nl.linux.org/kernelnewbies/
> FAQ:           http://kernelnewbies.org/faq/
>


--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive:       http://mail.nl.linux.org/kernelnewbies/
FAQ:           http://kernelnewbies.org/faq/


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux