All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prashant Alange <prashant.alange@gmail.com>
To: Dan Malek <dan@embeddededge.com>
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: How to disable dcache on MPC82xx platform
Date: Tue, 9 Aug 2005 14:50:33 -0700	[thread overview]
Message-ID: <6d145b4205080914506cbc5e80@mail.gmail.com> (raw)
In-Reply-To: <e0e99d07a5f20187cf45caac1ee9fa10@embeddededge.com>

Thanks Dan for your explaination. I am linking multiple BDs only but
no of BDs are very large in my case so I am allocating the memory and
updating the BD pointer for all BDs. I am thinking of using mem start
parameter option. I even tried using __get_free_page instead of using
cpm_hostalloc() but that also did not help.
If i use mem=3D option as kernel command line argument then I will have
to just ioremap() this reserved address in my driver and start
accessing the memory.  I do not have to worry about cache related
things.  right?

Thanks again,
Prashant


On 8/9/05, Dan Malek <dan@embeddededge.com> wrote:
>=20
> On Aug 9, 2005, at 10:57 AM, Prashant Alange wrote:
>=20
> > Since the existing UART/ethernet drivers are using cpm_hostalloc() so
> > I am also using the same function.
>=20
> As I have said too many times before, cpm_hostalloc() is only used
> to allocate small memory regions that would otherwise be wasteful
> with the normal Linux memory allocators.  This function does not
> do anything special with the memory, aside from allowing us have
> multiple drivers share a page for efficiency.
>=20
> >  Then can I use kmalloc() to alloc
> > such huge memory.
>=20
> Yes, and you should.
>=20
> >  If at all I have to configure BATx to just test how
> > it behaves.
>=20
> No, that's not all you have to do.  It's not a trivial process
> easily described here.
>=20
> > .....   One more thing is that
> > totally I am allocating about 1MB memory in a chunk of 200K.
>=20
> I can't comprehend a reason why you need to allocate so much
> space in a driver, especially for CPM devices.  The driver is just
> a temporary FIFO for data flowing to/from other consumer/producers
> of the data in the system.  If the software above a driver needs
> that kind of buffering, it should manage that itself.
>=20
> If you do need so much space, use the beauty of the CPM and
> link multiple BDs with reasonable sized buffers more easily
> managed by the existing Linux allocators.
>=20
> The other alternative is just reserve memory using the 'mem=3D'
> start parameter so it isn't know to Linux, and manage entirely
> yourself.
>=20
>=20
>        -- Dan
>=20
>

  reply	other threads:[~2005-08-09 21:50 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-09  2:30 How to disable dcache on MPC82xx platform Prashant Alange
2005-08-09 14:37 ` Dan Malek
2005-08-09 14:57   ` Prashant Alange
2005-08-09 16:37     ` Dan Malek
2005-08-09 21:50       ` Prashant Alange [this message]
2005-08-09 22:28         ` Dan Malek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d145b4205080914506cbc5e80@mail.gmail.com \
    --to=prashant.alange@gmail.com \
    --cc=dan@embeddededge.com \
    --cc=linuxppc-embedded@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.