All of lore.kernel.org
 help / color / mirror / Atom feed
From: pza@pengutronix.de (Philipp Zabel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/6] uio_pruss cleanup and platform support
Date: Thu, 4 Oct 2012 16:06:09 +0200	[thread overview]
Message-ID: <20121004140609.GA5464@pengutronix.de> (raw)
In-Reply-To: <20121004135433.GI11149@beef>

On Thu, Oct 04, 2012 at 09:54:33AM -0400, Matt Porter wrote:
> *sigh*, I see now. I looked at v2 and got wrapped up in the DT use case
> and missed your platform device support. I think it will work just fine
> for us to use in a "phase 2" of this work, replacing the backend of
> davinci sram allocation with this as Sekhar seems to be open to. 
> 
> > > I do see it moving to your driver exclusively, but I wanted to make this
> > > series focused on only getting rid of the private SRAM API using the
> > > existing pdata framework that's already there. I think once
> > > gen_pool_find_by_phys() goes upstream we can switch to that and get the
> > > address from a resource in the !DT case. I guess we should see if Sekhar
> > > would like to see this happen in two steps or just have us depend on
> > > the gen_pool_find_by_phys() patch now.
> > 
> > Thanks, I'm glad you are aware of the sram driver and consider it useful.
> > 
> > > BTW, I was going to post a patch for your driver to allow
> > > configurability of the allocation order, but have been busy with other
> > > things.  We'll eventually need that when switching to it as the
> > > hardcoded page size order isn't going to work for all cases.
> > 
> > Good point.
> 
> I think this is the only blocker to DaVinci adopting it once it goes
> upstream. I can add a patch in your driver thread if that helps.

Yes, that would be welcome.

regards
Philipp

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

WARNING: multiple messages have this Message-ID (diff)
From: Philipp Zabel <pza@pengutronix.de>
To: Matt Porter <mporter@ti.com>
Cc: Linux DaVinci Kernel List 
	<davinci-linux-open-source@linux.davincidsp.com>,
	Russell King <linux@arm.linux.org.uk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Hans J. Koch" <hjk@hansjkoch.de>,
	Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 0/6] uio_pruss cleanup and platform support
Date: Thu, 4 Oct 2012 16:06:09 +0200	[thread overview]
Message-ID: <20121004140609.GA5464@pengutronix.de> (raw)
In-Reply-To: <20121004135433.GI11149@beef>

On Thu, Oct 04, 2012 at 09:54:33AM -0400, Matt Porter wrote:
> *sigh*, I see now. I looked at v2 and got wrapped up in the DT use case
> and missed your platform device support. I think it will work just fine
> for us to use in a "phase 2" of this work, replacing the backend of
> davinci sram allocation with this as Sekhar seems to be open to. 
> 
> > > I do see it moving to your driver exclusively, but I wanted to make this
> > > series focused on only getting rid of the private SRAM API using the
> > > existing pdata framework that's already there. I think once
> > > gen_pool_find_by_phys() goes upstream we can switch to that and get the
> > > address from a resource in the !DT case. I guess we should see if Sekhar
> > > would like to see this happen in two steps or just have us depend on
> > > the gen_pool_find_by_phys() patch now.
> > 
> > Thanks, I'm glad you are aware of the sram driver and consider it useful.
> > 
> > > BTW, I was going to post a patch for your driver to allow
> > > configurability of the allocation order, but have been busy with other
> > > things.  We'll eventually need that when switching to it as the
> > > hardcoded page size order isn't going to work for all cases.
> > 
> > Good point.
> 
> I think this is the only blocker to DaVinci adopting it once it goes
> upstream. I can add a patch in your driver thread if that helps.

Yes, that would be welcome.

regards
Philipp

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2012-10-04 14:06 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-03 14:55 [PATCH v3 0/6] uio_pruss cleanup and platform support Matt Porter
2012-10-03 14:55 ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 1/6] ARM: davinci: sram: ioremap the davinci_soc_info specified sram regions Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:48   ` Sekhar Nori
2012-10-04 11:48     ` Sekhar Nori
2012-10-04 12:49     ` Matt Porter
2012-10-04 12:49       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 2/6] ARM: davinci: da850-dm646x: remove the SRAM_VIRT iotable entry Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:53   ` Sekhar Nori
2012-10-04 11:53     ` Sekhar Nori
2012-10-04 12:54     ` Matt Porter
2012-10-04 12:54       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 3/6] ARM: davinci: da850: changed SRAM allocator to shared ram Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 11:57   ` Sekhar Nori
2012-10-04 11:57     ` Sekhar Nori
2012-10-04 12:56     ` Matt Porter
2012-10-04 12:56       ` Matt Porter
2012-10-04 20:39     ` Matt Porter
2012-10-04 20:39       ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 4/6] ARM: davinci: add platform hook to fetch the SRAM pool Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-03 14:55 ` [PATCH v3 5/6] ARM: davinci: Add support for PRUSS on DA850 Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04 12:22   ` Sekhar Nori
2012-10-04 12:22     ` Sekhar Nori
2012-10-04 13:08     ` Matt Porter
2012-10-04 13:08       ` Matt Porter
2012-10-04 16:35     ` Matt Porter
2012-10-04 16:35       ` Matt Porter
2012-10-05 10:30       ` Sekhar Nori
2012-10-05 10:30         ` Sekhar Nori
2012-10-03 14:55 ` [PATCH v3 6/6] uio: uio_pruss: replace private SRAM API with genalloc Matt Porter
2012-10-03 14:55   ` Matt Porter
2012-10-04  9:11 ` [PATCH v3 0/6] uio_pruss cleanup and platform support Philipp Zabel
2012-10-04  9:11   ` Philipp Zabel
2012-10-04 12:42   ` Matt Porter
2012-10-04 12:42     ` Matt Porter
2012-10-04 12:54     ` Sekhar Nori
2012-10-04 12:54       ` Sekhar Nori
2012-10-04 13:10       ` Matt Porter
2012-10-04 13:10         ` Matt Porter
2012-10-04 13:35     ` Philipp Zabel
2012-10-04 13:35       ` Philipp Zabel
2012-10-04 13:54       ` Matt Porter
2012-10-04 13:54         ` Matt Porter
2012-10-04 14:06         ` Philipp Zabel [this message]
2012-10-04 14:06           ` Philipp Zabel

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=20121004140609.GA5464@pengutronix.de \
    --to=pza@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.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.