On Mon, 2011-02-07 at 22:05 -0700, Grant Likely wrote:
>
> Hmmm, of all the ideas, I think I like this one the best. It is a
> little more verbose than I was thinking, but making each reserved
> region (or set of reserved regions) have separate node has some very
> real advantages. For one, the
This patch adds support of OpenCores tiny SPI driver.
http://opencores.org/project,tiny_spi
Signed-off-by: Thomas Chou
---
v2 minor cleanup, same as Grant suggest for spi_altera.
v3 rename driver to spi_oc_tiny as Grant suggested.
set version to tiny-spi-rtlsvn2 as Jonas suggested.
v4 add dts
This patch adds a new SPI driver to support the Altera SOPC Builder
SPI component. It uses the bitbanging library.
Signed-off-by: Thomas Chou
---
v2 add devicetree support
v3 remove platform header, as Grant suggested.
no irq resource means polling.
v4 minor cleanup, as Grant suggested.
v5 add
This driver supports the Altera PIO core.
Signed-off-by: Thomas Chou
---
v2 change compatible vendor to uppercase, ALTR.
add dts binding doc.
v3 remove subsys_initcall.
add to_altera_gpio() macro.
.../devicetree/bindings/gpio/altera_gpio.txt |7 +
drivers/gpio/Kconfig
On Mon, Feb 7, 2011 at 3:00 PM, Jimi Xenidis wrote:
> On Feb 7, 2011, at 3:45 PM, Grant Likely wrote:
>>
>> On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
>> wrote:
>>>
In addition to the reserved regions block in the header, define a set
of properties in the memory node that sp
Grant,
On 11/16/2010 11:24 PM, Grant Likely wrote:
On Tue, Nov 16, 2010 at 02:33:55PM -0600, Rob Herring wrote:
From: Rob Herring
Various drivers require dma_mask to be valid, so it needs to be setup
when doing OF probing on ARM.
Signed-off-by: Rob Herring
I'll let patches 6& 7 lay fallow
On 02/07/2011 04:23 AM, Peter Korsgaard wrote:
"Thomas" == Thomas Chou writes:
Hi,
Thomas> +++ b/drivers/spi/Kconfig
Thomas> @@ -53,6 +53,13 @@ if SPI_MASTER
Thomas> comment "SPI Master Controller Drivers"
Thomas> +config SPI_ALTERA
Thomas> + tristate "Altera SPI Controller"
On Mon, 2011-02-07 at 14:45 -0700, Grant Likely wrote:
> On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
> wrote:
> >
> >> In addition to the reserved regions block in the header, define a set
> >> of properties in the memory node that specify the reserved regions
> >> with the name reflect
On Mon, Feb 07, 2011 at 04:01:28PM -0600, Jimi Xenidis wrote:
> On Feb 7, 2011, at 3:56 PM, Grant Likely wrote:
> >
> > On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
> > wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Beh
On 02/07/2011 03:45 PM, Benjamin Herrenschmidt wrote:
In my previous reply I said that "it is not so much as a need as it is a
potential simplification." After further reflection, I don't think that
is completely true. As we get into AMP systems with higher core counts,
then implementing this
I've seen three types of reserved regions so far:
(1) Reserved regions that are permanently reserved. For example,
RAM used for configuration of a device not communicated in the
device tree. Nothing further needs to be said about this class.
(2) Reserved regions that are in use by somethin
> -Original Message-
> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
> Likely
> Sent: Monday, February 07, 2011 3:45 PM
> To: Benjamin Herrenschmidt
> Cc: pa...@power.org; devicetree-discuss; David Gibson; Yoder Stuart-B08248;
> McClintock Matthew-B29882; Woo
On Tue, 8 Feb 2011 08:39:26 +1100
Benjamin Herrenschmidt wrote:
>
> > In addition to the reserved regions block in the header, define a set
> > of properties in the memory node that specify the reserved regions
> > with the name reflecting the usage.
> > For example:
> >
> > memory@0 {
> >
On Feb 7, 2011, at 3:56 PM, Grant Likely wrote:
>
> On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
> wrote:
>>
>>
>>> -Original Message-
>>> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
>>> Likely
>>> Sent: Monday, February 07, 2011 3:45 PM
>>> To: Be
On Feb 7, 2011, at 3:45 PM, Grant Likely wrote:
>
> On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
> wrote:
>>
>>> In addition to the reserved regions block in the header, define a set
>>> of properties in the memory node that specify the reserved regions
>>> with the name reflecting the
On Mon, 7 Feb 2011 15:53:09 -0600
Yoder Stuart-B08248 wrote:
> Could we not do both? Use an enum to identify the region type:
>
> reserved = <0x1 0xc0 0x20>; /* 2MB ramdisk
> reserved = <0x2 0xbf 0x1000>; /* devicetree */
> reserved = <0x3 0x100 0x40>; /* framebuf
On Mon, Feb 7, 2011 at 2:53 PM, Yoder Stuart-B08248
wrote:
>
>
>> -Original Message-
>> From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant
>> Likely
>> Sent: Monday, February 07, 2011 3:45 PM
>> To: Benjamin Herrenschmidt
>> Cc: pa...@power.org; devicetree-discuss;
> In my previous reply I said that "it is not so much as a need as it is a
> potential simplification." After further reflection, I don't think that
> is completely true. As we get into AMP systems with higher core counts,
> then implementing this functionality using the existing
> "protecte
On Mon, Feb 7, 2011 at 2:39 PM, Benjamin Herrenschmidt
wrote:
>
>> In addition to the reserved regions block in the header, define a set
>> of properties in the memory node that specify the reserved regions
>> with the name reflecting the usage.
>> For example:
>>
>> memory@0 {
>>
> In addition to the reserved regions block in the header, define a set
> of properties in the memory node that specify the reserved regions
> with the name reflecting the usage.
> For example:
>
> memory@0 {
> device_type = "memory";
> reg = <0 0x4000>;
>
As part of the process of bringing dt support up on non-powerpc
platforms, I've been thinking about the usage mode of the reserved
regions section in the flattened device tree structure. First, for
reference, here is the description of reserved regions from ePAPR
1.0:
> 7.3 Memory Reservation Blo
On Mon, Feb 7, 2011 at 1:46 AM, Amit Kucheria wrote:
> On 11 Feb 05, Grant Likely wrote:
>> 2 - Task status
>> ---
>> Core infrastructure:
>> [glikely] basic infrastructure to enable dt: DONE
>> [r-herring] Allow dtb to be located anywhere in RAM: DONE
>> [bones] Debug dtb corruption d
On 02/07/2011 01:24 PM, Rob Herring wrote:
David, Thomas,
On 02/06/2011 06:04 PM, David Gibson wrote:
On Sun, Feb 06, 2011 at 06:47:28PM +0530, Thomas Abraham wrote:
This patch adds a basic dts file for Samsung's SMDKV310 machine.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-s5pv310/mac
Thomas,
On 02/06/2011 07:17 AM, Thomas Abraham wrote:
This patch adds the of_match_table to enable s3c2410-wdt driver
to be probed when watchdog device node is found in the device tree.
Signed-off-by: Thomas Abraham
---
drivers/watchdog/s3c2410_wdt.c | 10 ++
1 files changed, 10 in
David, Thomas,
On 02/06/2011 06:04 PM, David Gibson wrote:
On Sun, Feb 06, 2011 at 06:47:28PM +0530, Thomas Abraham wrote:
This patch adds a basic dts file for Samsung's SMDKV310 machine.
Signed-off-by: Thomas Abraham
---
arch/arm/mach-s5pv310/mach-smdkv310.dts | 38 +++
On 02/06/2011 05:35 PM, Benjamin Herrenschmidt wrote:
On Fri, 2011-02-04 at 17:25 -0600, Meador Inge wrote:
In a recent thread [1,2,3] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose. The general
consensus was that a new boolean property
On Sunday 06 February 2011, Thomas Abraham wrote:
> diff --git a/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
> b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
> new file mode 100644
> index 000..367fdb1
> --- /dev/null
> +++ b/arch/arm/mach-s5pv310/mach-smdkv310-dt.c
> @@ -0,0 +1,101 @@
> +/* linux/a
On Sun, Feb 6, 2011 at 12:42 PM, Grant Likely wrote:
> Hi all,
>
[...]
>
> imx51 tasks
> enable dtb support in u-boot: TODO
> enable basic kernel dtb support: TODO
> enable registration of devices form dt: TODO
> ... add more details here, specific devices, etc...
>
[...]
> Shawn Guo [] imx51
I'm
On 11 Feb 05, Grant Likely wrote:
> Hi all,
>
> With several more engineers working on ARM device tree support, I'm
> going to start collecting the status of all the work that is going on
> (and I know about) and posting it in a regular status report,
> hopefully weekly, for the next few months un
29 matches
Mail list logo
