[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I/O caching prob
errr.. please ignore
On Wed, 31 Mar 2004, Muthukumar Ratty wrote:
>
> 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@xxxxxx]
> > Sent: Thursday, March 25, 2004 11:12 PM
> > To: Mandeep Singh Sandhu; kernelnewbies@xxxxxxxxxxxx
> > 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@xxxxxxxxx]
> > Sent: Thursday, March 25, 2004 3:19 PM
> > To: Mandeep Singh Sandhu
> > Subject: Re: PCI DMA mapping question
> >
> >
> > >>>>> "Mandeep" == Mandeep Singh Sandhu <mandeep_sandhu@xxxxxxxxxxx>
> > >>>>> 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/
>
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/