Add device tree based discovery support for Samsung's keypad controller.
Cc: Joonyoung Shim
Cc: Donghwa Lee
Signed-off-by: Thomas Abraham
Acked-by: Grant Likely
---
.../devicetree/bindings/input/samsung-keypad.txt | 88 ++
drivers/input/keyboard/samsung-keypad.c| 174
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 opt
Changes since v3:
- Addressed comments from Grant Likely.
- Set num_rows and num_cols to zero in samsung_keypad_parse_dt function.
- Fixed the wierd looking if-else block in samsung_keypad_probe function.
Changes since v2:
- Addressed comments from Grant Likely.
- Renamed 'keypad,key-code' p
Arnd Bergmann wrote at Friday, September 23, 2011 10:49 AM:
> On Thursday 22 September 2011, Stephen Warren wrote:
> >
> > This series converts the Tegra GPIO and pinmux drivers to be regular
> > platform devices.
>
> Looks good overall.
Thanks.
> > The series is extracted from an earlier series
From: Rob Herring
Add binding documentation for ARM's Primecell PL022 SPI controller.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/spi/spi_pl022.txt | 12
1 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/s
From: Rob Herring
Add binding documentation for ARM's Primecell PL061 GPIO controller.
Signed-off-by: Rob Herring
---
.../devicetree/bindings/gpio/pl061-gpio.txt| 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gp
On Tue, Sep 20, 2011 at 12:35:29PM -0500, Scott Wood wrote:
> On 09/20/2011 03:04 AM, David Gibson wrote:
> > So, there are basically two approaches to macro or function support.
> >
> > A) Functions
> >
> > We allow definition of functions with parameters. These are stored
> > in some kind of p
v2: Update bindings to use "reg" and "mdio-parent-bus" insutead of
"cell-index" and "parent-bus"
v1:
We have several different boards with a multiplexer in the MDIO bus.
There is an MDIO bus controller connected to a switching device with
several child MDIO busses.
Everything is wired up usi
Add of_mdio_find_bus() which allows an mii_bus to be located given its
associated the device tree node.
This is needed by the follow-on patch to add a driver for MDIO bus
multiplexers.
The of_mdiobus_register() function is modified so that the device tree
node is recorded in the mii_bus. Then we
This patch adds a somewhat generic framework for MDIO bus
multiplexers. It is modeled on the I2C multiplexer.
The multiplexer is needed if there are multiple PHYs with the same
address connected to the same MDIO bus adepter, or if there is
insufficient electrical drive capability for all the conn
The GPIO pins select which sub bus is connected to the master.
Initially tested with an sn74cbtlv3253 switch device wired into the
MDIO bus.
Signed-off-by: David Daney
Cc: Grant Likely
Cc: "David S. Miller"
---
.../devicetree/bindings/net/mdio-mux-gpio.txt | 129 ++
driv
And adjust all callers.
The new device parameter is used in the next patch to initialize the
mux's of_node so that its children may be automatically populated.
Signed-off-by: David Daney
---
drivers/i2c/i2c-mux.c | 19 ++-
drivers/i2c/muxes/gpio-i2cmux.c |3 ++-
For 'normal' i2c bus drivers, we can call of_i2c_register_devices()
and have the device tree framework automatically populate the bus with
the devices specified in the device tree.
This patch adds a common code to the i2c mux framework to have the mux
sub-busses be populated by the of_i2c_register
v2: Update bindings to use "reg" insutead of "cell-index"
v1:
Unchanged from the original RFC where I said:
We need to populate our I2C devices from the device tree, but some
of our systems have multiplexers which currently break this process.
The basic idea is to have the generic i2c-mux
On Tue, Sep 27, 2011 at 7:03 AM, Rob Herring wrote:
> Grant,
>
> On 09/26/2011 08:53 PM, Grant Likely wrote:
>> On Mon, Sep 26, 2011 at 02:24:43PM -0500, Rob Herring wrote:
>>> From: Rob Herring
>>>
>>> of_irq_init will scan the devicetree for matching interrupt controller
>>> nodes. Then it call
On Tue, Sep 27, 2011 at 01:16:42PM +0100, Jamie Iles wrote:
> Add a handler for the VIC that is suitable for MULTI_IRQ_HANDLER
> platforms. This only works for platforms with CONFIG_OF=y as we can
> determine which controllers are the primary controllers (no parent).
>
> Signed-off-by: Jamie Iles
On Tue, Sep 27, 2011 at 01:16:41PM +0100, Jamie Iles wrote:
> This adds a device tree binding for the VIC based on the of_irq_init()
> support.
>
> Cc: Rob Herring
> Signed-off-by: Jamie Iles
> ---
> Documentation/devicetree/bindings/arm/vic.txt | 29 ++
> arch/arm/common/vic.c
On Tue, Sep 27, 2011 at 08:19:37PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> >>+ if (!dev)
> >>+ return NULL;
> >So how do we handle CPUs? cpufreq is one of the most act
On Tue, Sep 27, 2011 at 07:28:40PM +0100, Daniel Drake wrote:
> On Tue, Sep 27, 2011 at 7:26 PM, Mark Brown
> > That seems like a bug that just happened to get noticed while reviewing
> > this change, though...
> Sorry if I'm missing something obvious but I'm not seeing the issue.
> What exactly
On Tue, Sep 27, 2011 at 7:26 PM, Mark Brown
wrote:
> That seems like a bug that just happened to get noticed while reviewing
> this change, though...
Sorry if I'm missing something obvious but I'm not seeing the issue.
What exactly is this bug and what effects could it cause?
Thanks,
Daniel
On Tue, Sep 27, 2011 at 07:25:03PM +0100, Daniel Drake wrote:
> On Tue, Sep 27, 2011 at 7:14 PM, Mark Brown
> > Why not just kmemdup() the template you're using rather than modifying
> > it in place?
> Could do, but is there any point in this case? I'm not seeing it. The
> "template" is already b
On Tue, Sep 27, 2011 at 7:14 PM, Mark Brown
wrote:
> On Tue, Sep 27, 2011 at 05:44:04PM +0100, Daniel Drake wrote:
>
>> However, it does take Mark's suggestion into account that the mfd
>> should have some clear representation in the device tree. For us it
>> already did have (naturally), but this
On Tue, Sep 27, 2011 at 05:44:04PM +0100, Daniel Drake wrote:
> However, it does take Mark's suggestion into account that the mfd
> should have some clear representation in the device tree. For us it
> already did have (naturally), but this wasn't reflected in my earlier
> patch. It is now - the l
This utility routine will be used in the variable size cell literal
append code. It is a straightforward adaptation of the fdt32_to_cpu
function.
Signed-off-by: Anton Staaf
Cc: Jon Loeliger
Cc: David Gibson
Cc: Grant Likely
---
libfdt/libfdt_env.h |6 ++
1 files changed, 6 insertions
Elements of size 8, 16, 32, and 64 bits are supported. The new
/bits/ syntax was selected so as to not pollute the reserved
keyword space with uint8/uint16/... type names.
With this patch the following property assignment:
property = /bits/ 16 <0x1234 0x5678 0x0 0x>;
is equivalent to:
This function deals with appending integers of various sizes (8, 16
32, and 64 bit currently). It handles endianess conversions. If the
integer will not fit in the requested number of bits of storage it
will have it's high bits ignored.
This patch also rewrites data_append_cell and data_append_a
This patch set adds, tests, and documents support for variable sized elements in
arrays (known as cell lists when they could only support 32-bit entries). The
new syntax is:
property = /bits/ [8|16|32|64] <0x00 0x12>;
So arrays of 8, 16, 32, or 64-bit elements can now be created. No pa
On Mon, Sep 26, 2011 at 5:55 PM, David Gibson
wrote:
> On Mon, Sep 26, 2011 at 10:15:48AM -0700, Anton Staaf wrote:
>> On Sun, Sep 25, 2011 at 4:04 AM, David Gibson
>> wrote:
>> > On Fri, Sep 23, 2011 at 11:02:54AM -0700, Anton Staaf wrote:
> [snip]
>> > Uh, so, this is actually worse than what y
On Tue, Sep 27, 2011 at 4:05 PM, Grant Likely wrote:
> What is a hard rule is that the code creating the children needs to
> know what the binding is and populate the child's of_node
> appropriately. Similarly, the child driver needs to know something
> about the kinds of nodes it will be passed
On Mon, Sep 26, 2011 at 5:58 PM, David Gibson
wrote:
> On Mon, Sep 26, 2011 at 01:48:31PM -0700, Anton Staaf wrote:
>> On Sun, Sep 25, 2011 at 4:04 AM, David Gibson
>> wrote:
>> > On Fri, Sep 23, 2011 at 11:02:54AM -0700, Anton Staaf wrote:
>> > 1) Exactly what to call the keyword. /bits/
On Tue, Sep 27, 2011 at 08:19:00PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> >>+Optional properties:
> >>+- regulator-fixed-supply: Name of the regulator supply
> >This is going to b
On Tue, Sep 27, 2011 at 09:05:55AM -0600, Grant Likely wrote:
> On Tue, Sep 27, 2011 at 03:44:56PM +0100, Daniel Drake wrote:
> > On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
> > > My suspicion is that for device tree in cases where the MFD really is
> > > totally independent of the parent we shoul
On Tue, Sep 27, 2011 at 03:44:56PM +0100, Daniel Drake wrote:
> On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
> wrote:
> >> Not sure how the MFD cells could get at the OF node by using the
> >> parent device - if the parent device had a OF node, wouldn't this
> >> correspond to the parent instead of
On Tue, Sep 27, 2011 at 08:18:04PM +0530, Rajendra Nayak wrote:
> On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
> >On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> >>+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> >>+
On Tuesday 27 September 2011 05:53 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
As with the f
On Tuesday 27 September 2011 05:51 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
+ if (!dev)
+ return NULL;
So how do we handle CPUs? cpufreq is one of the most active users of
regulators...
Hmm, never thought of it :(
Maybe I sho
On Tuesday 27 September 2011 05:46 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
re
On Tuesday 27 September 2011 05:44 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
+#ifdef CONFIG_OF
+ charcompatible[128];
+#endif
Might it not be better to just make this a pointer to const char?
Yes, my bad.
On Tuesday 27 September 2011 05:40 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
+ init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
+GFP_KERNEL);
+ if (!init_data)
+
On Tuesday 27 September 2011 05:07 PM, Mark Brown wrote:
On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
- /* Con
On Wed, Sep 21, 2011 at 2:16 PM, Mark Brown
wrote:
>> Not sure how the MFD cells could get at the OF node by using the
>> parent device - if the parent device had a OF node, wouldn't this
>> correspond to the parent instead of the child? Also, as far as I can
>
> Well, obviously. But then with a
On Tue, Sep 27, 2011 at 08:25:30AM -0500, Rob Herring wrote:
> On 09/27/2011 07:16 AM, Jamie Iles wrote:
> > Add a handler for the VIC that is suitable for MULTI_IRQ_HANDLER
> > platforms. This only works for platforms with CONFIG_OF=y as we can
> > determine which controllers are the primary cont
Hi Rob,
On Tue, Sep 27, 2011 at 08:30:43AM -0500, Rob Herring wrote:
> On 09/27/2011 07:16 AM, Jamie Iles wrote:
[...]
> > +#ifdef CONFIG_OF
> > +static int
> > +vic_irq_domain_dt_translate(struct irq_domain *d, struct device_node *np,
> > + const u32 *intspec, unsigned int i
On 09/27/2011 07:16 AM, Jamie Iles wrote:
> This adds a device tree binding for the VIC based on the of_irq_init()
> support.
>
> Cc: Rob Herring
> Signed-off-by: Jamie Iles
> ---
> Documentation/devicetree/bindings/arm/vic.txt | 29 ++
> arch/arm/common/vic.c | 1
On 09/27/2011 07:16 AM, Jamie Iles wrote:
> Add a handler for the VIC that is suitable for MULTI_IRQ_HANDLER
> platforms. This only works for platforms with CONFIG_OF=y as we can
> determine which controllers are the primary controllers (no parent).
That's probably not an acceptable limitation. I
Grant,
On 09/26/2011 08:53 PM, Grant Likely wrote:
> On Mon, Sep 26, 2011 at 02:24:43PM -0500, Rob Herring wrote:
>> From: Rob Herring
>>
>> of_irq_init will scan the devicetree for matching interrupt controller
>> nodes. Then it calls an initialization function for each found controller
>> in th
On Tue, Sep 27, 2011 at 03:42:52PM +0530, Rajendra Nayak wrote:
> Look up the regulator for a given consumer from device tree, during
> a regulator_get(). If not found fallback and lookup through
> the regulator_map_list instead.
As with the fixed voltage regulator patch just use the code along wi
On Tue, Sep 27, 2011 at 03:42:51PM +0530, Rajendra Nayak wrote:
> + if (!dev)
> + return NULL;
So how do we handle CPUs? cpufreq is one of the most active users of
regulators...
> + snprintf(prop_name, 32, "%s-supply", supply);
> +
> + prop = of_get_property(dev->of_node
Add a handler for the VIC that is suitable for MULTI_IRQ_HANDLER
platforms. This only works for platforms with CONFIG_OF=y as we can
determine which controllers are the primary controllers (no parent).
Signed-off-by: Jamie Iles
---
arch/arm/common/vic.c | 48
This adds a device tree binding for the VIC based on the of_irq_init()
support.
Cc: Rob Herring
Signed-off-by: Jamie Iles
---
Documentation/devicetree/bindings/arm/vic.txt | 29 ++
arch/arm/common/vic.c | 121 -
arch/arm/include/asm/hardwar
On Tue, Sep 27, 2011 at 03:42:48PM +0530, Rajendra Nayak wrote:
> The helper routine of_get_fixed_voltage_config() extracts
> fixed_voltage_config structure contents from device tree.
>
> Also add documenation for additional bindings for fixed
> regulators that can be passed through dt.
Why not j
On Tue, Sep 27, 2011 at 03:42:47PM +0530, Rajendra Nayak wrote:
> +#ifdef CONFIG_OF
> + charcompatible[128];
> +#endif
Might it not be better to just make this a pointer to const char?
___
devicetree-discuss mailing list
devicetr
On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
> + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> + GFP_KERNEL);
> + if (!init_data)
> + return NULL; /* Out of memory? */
This means that the ini
On Tue, Sep 27, 2011 at 03:42:44PM +0530, Rajendra Nayak wrote:
> Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
> each regulator from the twl driver and let the boards pass it.
>
> Signed-off-by: Rajendra Nayak
> - /* Constrain board-specific capabilities according to what
The helper routine is meant to be used by regulator drivers
to extract the regulator_init_data structure from the data
that is passed from device tree.
'consumer_supplies' which is part of regulator_init_data is not extracted
as the regulator consumer mappings are passed through DT differently,
imp
Hi Mark, Grant,
This is a respin of my RFC series I posted sometime back
and is now based on top of the latest omap i2c-twl support
series posted by Benoit
git://gitorious.org/omap-pm/linux.git for_3.2/4_omap_dt_i2c_twl
some changes done since the RFC:
1. twl driver fixed to remove hardcoded boar
Modify the fixed regulator driver to extract fixed_voltage_config from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/fixed.c | 18 +-
1 files changed, 17 insertions(+), 1 de
Remove the hardcoded .valid_modes_mask and .valid_ops_mask for
each regulator from the twl driver and let the boards pass it.
Signed-off-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/drivers/regulator/twl-
Modify the twl regulator driver to extract the regulator_init_data from
device tree when passed, instead of getting it through platform_data
structures (on non-DT builds)
Signed-off-by: Rajendra Nayak
---
drivers/regulator/twl-regulator.c | 117 -
1 files cha
Device nodes in DT can associate themselves with one or more
regulators by providing a list of phandles (to regulator nodes)
and corresponding supply names.
For Example:
devicenode: node@0x0 {
...
...
vmmc-supply = <®ulator1>;
Look up the regulator for a given consumer from device tree, during
a regulator_get(). If not found fallback and lookup through
the regulator_map_list instead.
Devices can associate with one or more regulators by providing a
list of phandles and supply names.
For Example:
devicenode: node
Pass the fixed and adjustable voltage regulator information for
omap4panda board from device tree.
Signed-off-by: Rajendra Nayak
---
arch/arm/boot/dts/omap4-panda.dts | 54 +
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/o
Pass adjustable regulator information for omap4sdp from device tree so the
regulator driver can then use the regulator helper
routine to extract and use them during the driver probe().
Also add documentation for TWL regulator specific bindings.
Signed-off-by: Rajendra Nayak
---
.../bindings/reg
The helper routine of_get_fixed_voltage_config() extracts
fixed_voltage_config structure contents from device tree.
Also add documenation for additional bindings for fixed
regulators that can be passed through dt.
Signed-off-by: Rajendra Nayak
---
.../bindings/regulator/fixed-regulator.txt
Hi Grant,
On 22 September 2011 23:05, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 03:49:12PM +0530, Thomas Abraham wrote:
>> 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 depend
Hi Grant,
On 22 September 2011 23:10, Grant Likely wrote:
> On Mon, Sep 19, 2011 at 03:49:13PM +0530, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's keypad controller.
>>
>> Cc: Joonyoung Shim
>> Cc: Donghwa Lee
>> Signed-off-by: Thomas Abraham
>
> A few things
66 matches
Mail list logo
