Changes since v3:
- In Patch 4/6, a recommendation is added in the pl330 binding documentation
for the name of the property which specifies the dma channel in the client
device node.
- In Patch 6/6, dropped #ifdef around of_have_populated_dt.
Changes since v2:
- Only the sixth patch is
The dma channel selection filter function is moved from plat-samsung
into the pl330 driver. In additon to that, a check is added in the
filter function to ensure that the channel on which the filter has
been invoked is pl330 channel instance (and avoid any incorrect
access of chan-private in a
With the 'struct dma_pl330_peri' removed, the platfrom data for dma
driver can be simplified to a simple list of peripheral request ids.
Cc: Jassi Brar jassisinghb...@gmail.com
Cc: Boojin Kim boojin@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Acked-by: Kukjin Kim
For PL330 dma controllers instantiated from device tree, the channel
lookup is based on phandle of the dma controller and dma request id
specified by the client node. During probe, the private data of each
channel of the controller is set to point to the device node of the
dma controller. The
A new dma request id 'DMACH_DT_PROP' is introduced for client drivers
requesting a dma channel. This request indicates that a device tree
node property represting the dma channel is available in
'struct samsung_dma_info'. The dma channel request wrapper uses the
node property value as the value
The pl330 device instances and associated platform data is required only
for non-device-tree builds. With device tree enabled, the data about the
platform is obtained from the device tree. For images that include both
dt and non-dt platforms, an addditional check is added to ensure that
static
On Sun, Sep 18, 2011 at 7:31 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
What I do to thest it here is along those lines:
make whatever_foo_defconfig_you_want
make zImage
cat foobar.dtb arch/arm/boot/zImage
make uImage
BTW this sequence does not work, and
On Sun, Sep 18, 2011 at 10:46:04PM -0700, Simon Glass wrote:
Hi David,
On Sun, Sep 18, 2011 at 7:04 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Fri, Sep 16, 2011 at 09:25:10AM -0700, Simon Glass wrote:
Hi David,
[snip]
One useful extension of what you have now might be to
On 9/18/2011 8:15 AM, Grant Likely wrote:
On Thu, Sep 15, 2011 at 12:07:25PM +0200, Cousson, Benoit wrote:
Hi Rob,
On 9/15/2011 9:55 AM, Thomas Abraham wrote:
Hi Rob,
On 14 September 2011 22:01, Rob Herringrobherri...@gmail.com wrote:
From: Rob Herringrob.herr...@calxeda.com
This adds
On Thu, Sep 8, 2011 at 12:14 PM, Linus Walleij
linus.wall...@stericsson.com wrote:
This makes it easy to script the kernel build with
different device trees, and it also vastly simplifies
building uImages since make uImage will now pick
up the devcie tree and include it in the final image
as
Hi Grant,
Thanks for looking at this.
On Sat, Sep 17, 2011 at 4:56 PM, Grant Likely grant.lik...@secretlab.ca wrote:
drivers/mfd/vx855.c should be modified to assign pdev-of_node, which
can be used here for setting up c-of_node.
There doesn't seem to be any obvious place in mfd/vx855.c to
Hi,
On Fri, Sep 16, 2011 at 10:43 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Fri, Sep 16, 2011 at 03:38:10PM +0100, Dave Martin wrote:
This patch enables device-tree-based probing of the pata-generic
platform driver across all architectures:
[...]
This may not be the
Changes since v2:
- Addressed comments from Grant Likely.
- Renamed 'keypad,key-code' property name to 'linux,code'.
- Fixed incorrect data types for all instances of of_property+read_u32.
- linux,input-type binding was not added as suggested since the driver
supports only EV_KEY event
For platforms using device tree, the static keypad device instances
are not required and SAMSUNG_DEV_KEYPAD is not selected. Since,
samsung keypad driver has dependency on SAMSUNG_DEV_KEYPAD config
option, the driver is left out of the compilation for dt enabled
platforms.
An additional config
Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim jy0922.s...@samsung.com
Cc: Donghwa Lee dh09@samsung.com
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++
Thomas Abraham wrote:
Dear Mr. Kim,
On 5 September 2011 10:47, Kukjin Kim kgene@samsung.com wrote:
Subject: [PATCH v2 6/6] ARM: EXYNOS4: Limit usage of pl330 device
instance
to
non-dt build
The pl330 device instances and associated platform data is required
only
for
On Mon, Sep 19, 2011 at 11:23 AM, Pawel Moll pawel.m...@arm.com wrote:
This may not be the correct way to support the CF slot on Versatile
Express - it depends whether the CF slot on VE supports just CF
memory cards or whether it can take any CF card.
If the latter, then what may be
On Sun, Sep 18, 2011 at 7:21 AM, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well as wasteful -- expressing
+ 32 using a
On 9/18/2011 11:23 PM, Rob Herring wrote:
On 09/15/2011 11:43 AM, Rob Herring wrote:
On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
On 9/15/2011 3:11 PM, Rob Herring wrote:
On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
[...]
I have another concern on a similar topic.
On OMAP4 the SoC
Hi Grant,
On 18 September 2011 11:40, Grant Likely grant.lik...@secretlab.ca wrote:
On Fri, Sep 16, 2011 at 03:04:11PM +0530, Thomas Abraham wrote:
Hi Rob,
On 15 September 2011 18:24, Rob Herring robherri...@gmail.com wrote:
On 09/15/2011 02:55 AM, Thomas Abraham wrote:
+void __init
On 9/19/2011 2:07 PM, Dave Martin wrote:
On Sun, Sep 18, 2011 at 7:21 AM, Grant Likelygrant.lik...@secretlab.ca wrote:
On Fri, Sep 16, 2011 at 05:09:39PM +0100, Dave Martin wrote:
For now, we express the mapping by putting an interrupt-map in the
core-tile DT, but this feels inelegant as well
On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
Since the cpumask is not relevant for the SPI, maybe having two
interrupt controllers will be more relevant. Or maybe 3, since there is
some SGIs as well.
I don't think anyone uses SGIs outside of the common SMP code.
On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
On 9/18/2011 11:23 PM, Rob Herring wrote:
On 09/15/2011 11:43 AM, Rob Herring wrote:
On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
On 9/15/2011 3:11 PM, Rob Herring wrote:
On 09/15/2011 05:07 AM, Cousson, Benoit wrote:
[...]
I have another
On 9/19/2011 3:48 PM, Rob Herring wrote:
On 09/19/2011 07:09 AM, Cousson, Benoit wrote:
On 9/18/2011 11:23 PM, Rob Herring wrote:
On 09/15/2011 11:43 AM, Rob Herring wrote:
On 09/15/2011 08:52 AM, Cousson, Benoit wrote:
On 9/15/2011 3:11 PM, Rob Herring wrote:
On 09/15/2011 05:07 AM,
On Mon, 19 Sep 2011, Linus Walleij wrote:
On Sun, Sep 18, 2011 at 7:31 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
What I do to thest it here is along those lines:
make whatever_foo_defconfig_you_want
make zImage
cat foobar.dtb arch/arm/boot/zImage
On Mon, Aug 15, 2011 at 03:28:14PM +0800, Shawn Guo wrote:
The patch adds function of_alias_scan to populate a global lookup
table with the properties of 'aliases' node and function
of_alias_get_id for drivers to find alias id from the lookup table.
Signed-off-by: Shawn Guo
On Mon, Sep 19, 2011 at 02:09:46PM +0200, Cousson, Benoit wrote:
Every CortexA9 based SoC have to add the 32 offset to the SoC level
interrupt number line. The ID numbering scheme is relevant only inside
the GIC, but at SoC level only the IRQ lines that entered the MP core
are relevant. That
What I'm saying is that in that scenario it should not be necessary to edit
the
kernel to invent new SoC types, and then teach it that Tegra4 is mostly the
same as Tegra3. That information should all be encoded into the DT rather
than the C code in the kernel.
So, I think adding this SoC
On Mon, Sep 19, 2011 at 7:33 AM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Sep 19, 2011 at 11:47:18AM +0200, Cousson, Benoit wrote:
Since the cpumask is not relevant for the SPI, maybe having two
interrupt controllers will be more relevant. Or maybe 3, since there is
some
This patch set adds two new utilities:
fdtget for reading properties from a device tree binary file
fdtput for updating the device tree binary file
These are useful in scripts where configuration or other information must be
passed to the running system from the build system or vice versa.
We want to avoid a separate Makefile include for each utility, so this sets
up a general one for utilities.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Use Makefile.utils instead of separate Makefiles
Makefile|2 +-
Makefile.ftdump | 13 -
The load_blob() and save_blob() functions are very similar to the utilfdt
versions. This removes the duplicated code.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Make testutils.c use utilfdt for load/save blobs
tests/Makefile.tests |6 ++--
tests/testutils.c| 60
This adds a few tests for the simple type argument supported by
utilfdt_decode_type.
I assume this will be squashed in with utilfdt, but I have left it out
for easier review here.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v3:
- Add tests for utilfdt
tests/Makefile.tests |
This adds a new utility library for performing libfdt operations.
This is a separate library from libfdt because it performs OS operations,
like open/close/read/write, while libfdt is OS-neutral. These utility
functions are useful within the dtc package, and could potentially even
be generally
Now that we have utilfdt_read(), ftdump should use it too.
Signed-off-by: Simon Glass s...@chromium.org
---
Makefile |2 +-
ftdump.c | 33 +
2 files changed, 6 insertions(+), 29 deletions(-)
diff --git a/Makefile b/Makefile
index 4f5ccdd..6238541 100644
---
This simply utility makes it easy for scripts to read values from the device
tree. It is written in C and uses the same libfdt as the rest of the dtc
package.
What is it for:
- Reading fdt values from scripts
- Extracting fdt information within build systems
- Looking at particular values without
This simple utility allows writing of values into a device tree from the
command line. It aimes to be the opposite of fdtget.
What is it for:
- Updating fdt values when a binary blob already exists
(even though source may be available it might be easier to use this
utility rather than sed,
On Sun, Sep 18, 2011 at 04:23:40PM -0500, Rob Herring wrote:
On 09/15/2011 11:43 AM, Rob Herring wrote:
I see 2 options (besides leaving it as is):
- Revert back to my previous binding where PPIs are a sub-node and a
different interrupt parent.
- Use the current binding, but allow
David Gibson wrote at Thursday, September 08, 2011 7:35 PM:
On Thu, Sep 08, 2011 at 11:32:11AM -0700, Grant Likely wrote:
On Thu, Sep 08, 2011 at 06:09:27AM -0700, Simon Glass wrote:
Hi Stephen,
On Fri, Sep 2, 2011 at 11:34 AM, Stephen Warren swar...@nvidia.com
wrote:
Stephen
On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring robherri...@gmail.com wrote:
On 09/19/2011 04:14 PM, Grant Likely wrote:
* ARM Generic Interrupt Controller
ARM SMP cores are often associated with a GIC, providing per processor
interrupts (PPI), shared processor interrupts (SPI) and software
On Mon, Sep 19, 2011 at 09:45:34AM -0700, Anton Staaf wrote:
On Sun, Sep 18, 2011 at 7:00 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Sat, Sep 17, 2011 at 11:49:21AM -0500, Jon Loeliger wrote:
On Fri, Sep 09, 2011 at 12:16:30PM -0700, Anton Staaf wrote:
With this patch the
On Mon, Sep 19, 2011 at 01:21:02PM -0700, Simon Glass wrote:
We want to avoid a separate Makefile include for each utility, so this sets
up a general one for utilities.
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: David Gibson da...@gibson.dropbear.id.au
--
David Gibson
On Mon, Sep 19, 2011 at 01:21:03PM -0700, Simon Glass wrote:
This adds a new utility library for performing libfdt operations.
This is a separate library from libfdt because it performs OS operations,
like open/close/read/write, while libfdt is OS-neutral. These utility
functions are useful
On Mon, Sep 19, 2011 at 01:21:04PM -0700, Simon Glass wrote:
This adds a few tests for the simple type argument supported by
utilfdt_decode_type.
I assume this will be squashed in with utilfdt, but I have left it out
for easier review here.
Yes, it should be squashed in. Fwiw, in my
On Mon, Sep 19, 2011 at 07:54:09PM -0700, Anton Staaf wrote:
On Mon, Sep 19, 2011 at 5:59 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Mon, Sep 19, 2011 at 09:45:34AM -0700, Anton Staaf wrote:
On Sun, Sep 18, 2011 at 7:00 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On
On Mon, Sep 19, 2011 at 04:53:39PM -0500, Rob Herring wrote:
On 09/19/2011 04:14 PM, Grant Likely wrote:
(Alternately, if there is no need for a CPU mask because PPI
interrupts will never be wired to more than one CPU, then it would be
better to encode the CPU number into the second cell
I know the device tree has a protocol for vendors to extend the types of nodes
without
causing namespace collisions, e.g. acme,explosives. Do subnodes and properties
of the
extended nodes also need the leading vendor and comma?
--
David VL
___
On Mon, Sep 19, 2011 at 10:37 PM, David VomLehn dvoml...@cisco.com wrote:
I know the device tree has a protocol for vendors to extend the types of
nodes without
causing namespace collisions, e.g. acme,explosives. Do subnodes and
properties of the
extended nodes also need the leading vendor
On Tue, Sep 20, 2011 at 02:50:15PM +1000, Benjamin Herrenschmidt wrote:
We used to overwrite with CONFIG_CMDLINE if we found a chosen
node but failed to get bootargs out of it or they were empty,
unless CONFIG_CMDLINE_FORCE is set.
Instead change that to overwrite if data is non empty after
On Mon, Sep 19, 2011 at 09:37:35PM -0700, David VomLehn wrote:
I know the device tree has a protocol for vendors to extend the types of
nodes without
causing namespace collisions, e.g. acme,explosives. Do subnodes and
properties of the
extended nodes also need the leading vendor and comma?
On Mon, Sep 19, 2011 at 10:58 PM, David Gibson
da...@gibson.dropbear.id.au wrote:
On Mon, Sep 19, 2011 at 09:37:35PM -0700, David VomLehn wrote:
I know the device tree has a protocol for vendors to extend the types of
nodes without
causing namespace collisions, e.g. acme,explosives. Do
51 matches
Mail list logo
