From: nsekhar@ti.com (Sekhar Nori)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/6] uio_pruss cleanup and platform support
Date: Thu, 4 Oct 2012 18:24:56 +0530 [thread overview]
Message-ID: <506D8720.8040004@ti.com> (raw)
In-Reply-To: <20121004124253.GC11149@beef>
On 10/4/2012 6:12 PM, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
>> Hi Matt,
>>
>> On 10/3/12, Matt Porter <mporter@ti.com> wrote:
>>> This series enables uio_pruss on DA850 and removes use of the
>>> private SRAM API by the driver. The driver previously was not
>>> enabled by any platform and the private SRAM API was accessing
>>> an invalid SRAM bank.
>>
>> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
>> "Add device tree support for on-chip SRAM" ?
>
> Yes.
>
>> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
>> could be useful to map the L3RAM on Davinci.
>> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
>> uio_pruss driver could then use the gen_pool_find_by_phys() (or
>> of_get_named_gen_pool() for initialization from device tree) to
>> retrieve the struct gen_pool*.
>>
>> This way you could avoid handing it over via platform data and you could
>> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
>
> I did miss the gen_pool_find_by_phys() call in that series. That does
> look useful. I actually mentioned your series in an earlier posting
> since I like it, but since the initialization of the driver was inherently
> tied to DT it's not usable for DaVinci that's just starting to convert
> to DT and needs !DT support as well.
>
> 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.
I prefer going with this series now and switching to the SRAM driver
once it is available mainline.
Thanks,
Sekhar
WARNING: multiple messages have this Message-ID (diff)
From: Sekhar Nori <nsekhar@ti.com>
To: Matt Porter <mporter@ti.com>
Cc: Philipp Zabel <pza@pengutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Hans J. Koch" <hjk@hansjkoch.de>,
Ben Gardiner <bengardiner@nanometrics.ca>,
Linux DaVinci Kernel List
<davinci-linux-open-source@linux.davincidsp.com>,
Russell King <linux@arm.linux.org.uk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
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 18:24:56 +0530 [thread overview]
Message-ID: <506D8720.8040004@ti.com> (raw)
In-Reply-To: <20121004124253.GC11149@beef>
On 10/4/2012 6:12 PM, Matt Porter wrote:
> On Thu, Oct 04, 2012 at 11:11:45AM +0200, Philipp Zabel wrote:
>> Hi Matt,
>>
>> On 10/3/12, Matt Porter <mporter@ti.com> wrote:
>>> This series enables uio_pruss on DA850 and removes use of the
>>> private SRAM API by the driver. The driver previously was not
>>> enabled by any platform and the private SRAM API was accessing
>>> an invalid SRAM bank.
>>
>> have you seen my SRAM patch series at https://lkml.org/lkml/2012/9/7/281
>> "Add device tree support for on-chip SRAM" ?
>
> Yes.
>
>> I think the generic SRAM/genalloc driver (https://lkml.org/lkml/2012/9/7/282)
>> could be useful to map the L3RAM on Davinci.
>> With the gen_pool lookup patch (https://lkml.org/lkml/2012/9/7/284) the
>> uio_pruss driver could then use the gen_pool_find_by_phys() (or
>> of_get_named_gen_pool() for initialization from device tree) to
>> retrieve the struct gen_pool*.
>>
>> This way you could avoid handing it over via platform data and you could
>> get rid of arch/arm/mach-davinci/{sram.c,include/mach/sram.h} completely.
>
> I did miss the gen_pool_find_by_phys() call in that series. That does
> look useful. I actually mentioned your series in an earlier posting
> since I like it, but since the initialization of the driver was inherently
> tied to DT it's not usable for DaVinci that's just starting to convert
> to DT and needs !DT support as well.
>
> 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.
I prefer going with this series now and switching to the SRAM driver
once it is available mainline.
Thanks,
Sekhar
next prev parent reply other threads:[~2012-10-04 12:54 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 [this message]
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
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=506D8720.8040004@ti.com \
--to=nsekhar@ti.com \
--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.