On Wed, Feb 20, 2013 at 7:27 PM, Anatolij Gustschin ag...@denx.de wrote:
On hardware with limited gpios one column select gpio can select
two different rows when using some additional hardware logic:
high value selects one row, low value selects another row. Add
support for such matrix
On 02/20/2013 07:24 PM, Guenter Roeck wrote:
On Wed, Feb 20, 2013 at 06:51:08PM +, Jonathan Cameron wrote:
Guenter Roeck li...@roeck-us.net wrote:
On Wed, Feb 20, 2013 at 11:38:22AM -0600, Rob Herring wrote:
On 02/07/2013 11:09 AM, Guenter Roeck wrote:
Provide bindings and parse OF
On 02/11/2013 06:06 AM, Amit Daniel Kachhap wrote:
Added S5M8767 PMIC DT nodes for Arndale board. Only the used
LDO's/BUCK are defined here. Also the nodes describe the default/reset
state LDO's and no power mangement tuning is implemented. The usage
desription can be found in s5m8767 device
On 21 February 2013 03:04, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/20/2013 12:08 AM, Shawn Guo wrote:
Currently, all imx pinctrl drivers maintain a big array of struct
imx_pin_reg which hard-codes data like register offset and mux mode
setting for each pin function. Every time a new
On Wed, Feb 20, 2013 at 06:25:13PM +0100, Stephen Warren wrote:
On 02/20/2013 06:26 AM, Laxman Dewangan wrote:
On Wednesday 20 February 2013 06:41 PM, Mark Brown wrote:
* PGP Signed by an unknown key
On Wed, Feb 20, 2013 at 05:59:03PM +0530, Laxman Dewangan wrote:
+tspi-clk =
On Fri, Feb 15, 2013 at 05:45:45PM +0100, Stephen Warren wrote:
...
I would suggest removing this clock. It's not actually implemented in the
CCF
and rather useless. If you would gate the CPU clock from the CPU by writing
to
this register, how would you ungate it? :) Note that this
On Wednesday 20 February 2013 12:09 AM, Stephen Warren wrote:
On 02/15/2013 05:36 AM, Peter De Schrijver wrote:
This is the seventh version of the Tegra114 clockframework. It is based on the
for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git and
On 02/20/2013 01:24 PM, Guenter Roeck wrote:
On Wed, Feb 20, 2013 at 06:51:08PM +, Jonathan Cameron wrote:
Guenter Roeck li...@roeck-us.net wrote:
On Wed, Feb 20, 2013 at 11:38:22AM -0600, Rob Herring wrote:
On 02/07/2013 11:09 AM, Guenter Roeck wrote:
Provide bindings and parse OF
On Thu, Feb 21, 2013 at 01:25:36PM +0100, Peter De Schrijver wrote:
On Fri, Feb 15, 2013 at 05:45:45PM +0100, Stephen Warren wrote:
...
I would suggest removing this clock. It's not actually implemented in the
CCF
and rather useless. If you would gate the CPU clock from the CPU by
DT bindings for PCI host bridges often use the ranges property to describe
memory and IO ranges - this binding tends to be the same across architectures
yet several parsing implementations exist, e.g. arch/mips/pci/pci.c,
arch/powerpc/kernel/pci-common.c, arch/sparc/kernel/pci.c and
On Thu, Feb 21, 2013 at 11:56:54AM +0200, Peter De Schrijver wrote:
On Wed, Feb 20, 2013 at 06:25:13PM +0100, Stephen Warren wrote:
OK, so that's certainly an argument for requesting a specific clock name
rather than NULL.
The list of possible parents for each clock is determined by the
On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo shawn@linaro.org wrote:
On Wed, Feb 20, 2013 at 06:03:39PM -0600, Matt Sealey wrote:
I am not sure I am getting this point across, but.. damn it.. nack nack nack
:D
Do you see any downgrade side that the series introduces over the
existing
On 02/20/2013 09:37 PM, Shawn Guo wrote:
On Wed, Feb 20, 2013 at 02:05:56PM -0700, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will
On 02/21/2013 02:36 AM, Dong Aisheng wrote:
On 21 February 2013 03:04, Stephen Warren swar...@wwwdotorg.org wrote:
On 02/20/2013 12:08 AM, Shawn Guo wrote:
Currently, all imx pinctrl drivers maintain a big array of struct
imx_pin_reg which hard-codes data like register offset and mux mode
I like where this is heading. I'm interested in a use case where IP
can be loaded into a FPGA, then add a blob to the device tree and load
some drivers.
I see your github tree. If I wanted to cherry-pick your code and play
around with it, which branch should I use? not-capebus-21?
Thanks,
On Thu, Feb 21, 2013 at 11:36:36AM -0600, Matt Sealey wrote:
On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo shawn@linaro.org wrote:
On Wed, Feb 20, 2013 at 06:03:39PM -0600, Matt Sealey wrote:
I am not sure I am getting this point across, but.. damn it.. nack nack
nack :D
Do you see
On 02/21/2013 02:50 PM, Rob Herring wrote:
On 02/20/2013 01:24 PM, Guenter Roeck wrote:
On Wed, Feb 20, 2013 at 06:51:08PM +, Jonathan Cameron wrote:
Guenter Roeck li...@roeck-us.net wrote:
On Wed, Feb 20, 2013 at 11:38:22AM -0600, Rob Herring wrote:
On 02/07/2013 11:09 AM, Guenter
Hi Alan,
On Feb 21, 2013, at 1:25 PM, delicious quinoa wrote:
I like where this is heading. I'm interested in a use case where IP
can be loaded into a FPGA, then add a blob to the device tree and load
some drivers.
I see your github tree. If I wanted to cherry-pick your code and play
On 20.2.2013 22:05, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
The recent dtc+cpp support allows header files and C pre-processor
defines/macros to be used when compiling device tree files. These
headers will typically define various constants that are part of the
device
This property is meant to be used in device nodes which represent
power_supply devices that wish to provide a list of supplies to
which they provide power. A common case is a AC Charger with
the batteries it powers.
Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
v2:
- Changed property to
This series is an attempt to define a common way for devicetree
initialized power_supplies to define their list of supplicants
in a common manner.
Instead of relying on custom properties which contain is list of
strings, use the much more direct method of phandles to reference
the supplies and
With the growing support for dt, it make sense to try to make use of
dt features to make the general code cleaner. This patch is an
attempt to commonize how chargers and their supplies are linked.
Following common dt convention, the supplied-to char** list is
replaced with phandle lists defined
With the addition of the device_nodes to use to link suppliers and
supplicants, its useful to add logic to handle the creation of
the list in a common place so as to be common for all drivers.
As of now, as long as the supply's device_node is supplied, the core
will attempt to parse the list of
On Thu, Feb 21, 2013 at 11:43:13AM -0700, Stephen Warren wrote:
There are two things that include DT-related headers:
a) Device trees (*.dts, *.dtsi)
b) The kernel
All the headers relevant here fall into category (a) by definition. I'd
actually expect most to also fall into category (b),
Hi Lars, Stephen
Thank you for your advice
The requirement to be able to find the DAI via devicetree is not specific to
the simple-audio driver. I'd prefer if we could come up with a common
binding which can be used by multiple drivers. Since you also add the xlate
(or match) function
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function rcar_thermal_update_temp()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/thermal/rcar_thermal.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, Feb 21, 2013 at 11:36:36AM -0600, Matt Sealey wrote:
On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo shawn@linaro.org wrote:
On Wed, Feb 20, 2013 at 06:03:39PM -0600, Matt Sealey wrote:
I am not sure I am getting this point across, but.. damn it.. nack nack
nack :D
Do you see
Hi Wei
Thank you for your patch
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function rcar_thermal_update_temp()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/thermal/rcar_thermal.c | 1 +
On 21 February 2013 12:34, Vikas Sajjan vikas.saj...@linaro.org wrote:
Hi,
On 19 February 2013 03:16, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
Hi,
On 02/18/2013 11:51 AM, Vikas Sajjan wrote:
On 15 February 2013 16:08, Sylwester Nawrockis.nawro...@samsung.com
wrote:
On
On Fri, Feb 22, 2013 at 01:52:04PM +0800, Shawn Guo wrote:
On Thu, Feb 21, 2013 at 11:36:36AM -0600, Matt Sealey wrote:
On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo shawn@linaro.org wrote:
On Wed, Feb 20, 2013 at 06:03:39PM -0600, Matt Sealey wrote:
I am not sure I am getting this
On Fri, Feb 22, 2013 at 08:27:43AM +0100, Sascha Hauer wrote:
On Fri, Feb 22, 2013 at 01:52:04PM +0800, Shawn Guo wrote:
On Thu, Feb 21, 2013 at 11:36:36AM -0600, Matt Sealey wrote:
On Wed, Feb 20, 2013 at 11:02 PM, Shawn Guo shawn@linaro.org wrote:
On Wed, Feb 20, 2013 at 06:03:39PM
On Thu, Feb 21, 2013 at 10:43:03PM +0100, Sascha Hauer wrote:
This would leave the question how we make up a pin number for the
pinctrl framework, but as said, this should be solved inside the kernel
and not pushed into the devicetree.
Ok, Dong has the same opinion to remove pin number from
32 matches
Mail list logo
