On Tue, May 08, 2012 at 10:15:51AM -0600, Stephen Warren wrote:
under-power issues in the earlier variants. But I believe there is
some Tegra30 reference board equivalent to Whistler with all kinds of
pluggable modules, although I haven't touched one yet, and don't
recall its name.
It's
On Tue, May 08, 2012 at 11:42:41AM -0700, Rhyland Klein wrote:
Add devicetree based initialization support for TI tps65910 regulators.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
On Fri, May 11, 2012 at 01:02:26PM +0200, Cousson, Benoit wrote:
On 5/9/2012 3:35 PM, Mark Brown wrote:
Clearly. This is all very circular. Obviously if you're intent on
using a phandle specific to the MFD child then you need to have that in
the device tree but this is because you're making
On Fri, May 11, 2012 at 12:08:43PM +0530, Laxman Dewangan wrote:
This looks good overall but I do have a few things with the binding.
+Optional properties:
+- ti,enable-force-pwm: Enable force PWM mode. This is boolean value.
Hrm, this is fairly generic - it's REGULATOR_MODE_ACTIVE. But I'm
On Fri, May 11, 2012 at 12:08:42PM +0530, Laxman Dewangan wrote:
Convert platform data member regulator_init_data to pointer type.
This will avoid the copy of entire regualator init data into
platform data member when adding dt support and it can be achieve
by simple assignment:
On Fri, May 11, 2012 at 05:44:19PM +0200, Cousson, Benoit wrote:
On 5/11/2012 3:08 PM, Mark Brown wrote:
This binding doesn't do anything to move towards that goal given that
the only information it includes about the contents of the chip is the
name.
But it does not have to expose
On Fri, May 11, 2012 at 12:08:43PM +0530, Laxman Dewangan wrote:
Add dt support for the pmu device tps62360 and
Add binding documentation with example.
With this patch driver will support both device-tree and
non-device tree registration.
Oh, sorry - I meant to say that I went ahead and
On Fri, May 11, 2012 at 09:05:01PM +0530, Laxman Dewangan wrote:
Yaah, I think this flag can map directly to REGULATOR_MODE_FAST. If
I understand PWM mode properly then this is used when high current
load is require or fast switching on load current is require. By
enabling force PWM enable,
On Wed, May 09, 2012 at 03:34:49AM +0530, Thomas Abraham wrote:
With the addition of platform specific driver data in the spi-s3c64xx
driver, the device name of spi controllers are changed. Accordingly,
update the device name of spi clocks instances.
This should've been squashed into the patch
On Wed, May 09, 2012 at 03:34:50AM +0530, Thomas Abraham wrote:
+ s3c64xx_spi0_set_platdata(s3c6410-spi, NULL, 0, 1);
Shouldn't we just set the name in the struct platform_device rather than
requiring the machine to pass it through by hand?
___
On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
+- gpios: The gpio specifier for clock, mosi and miso interface lines (in no
+ particular order). The format of the gpio specifier depends on the gpio
+ controller.
This seems odd... This isn't a bitbanging controller, and
On Tue, May 08, 2012 at 03:26:16PM -0600, Stephen Warren wrote:
On 05/07/2012 10:24 AM, Mark Brown wrote:
It's really not idiomatic for drivers using GPIOs to allow
configuration of their flags in the first place. Or, quite
frankly, to use flags. Honestly I'd not expect any bindings
On Wed, May 09, 2012 at 11:10:14AM +0200, Heiko Stübner wrote:
Similar to the adc and rtc driver, all Samsung platforms reuse a common
platform-device definition for the s3c64xx-spi and simply will set the
correct
name when the machine type is determined during boot.
Right, that doesn't
On Wed, May 09, 2012 at 09:40:26PM +0800, Thomas Abraham wrote:
On 9 May 2012 16:52, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
This should've been squashed into the patch that updated to use driver
data in order to avoid breaking bisection.
This patch updates clock devname
On Wed, May 09, 2012 at 10:13:28PM +0800, Thomas Abraham wrote:
On 9 May 2012 17:07, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
On Wed, May 09, 2012 at 03:34:54AM +0530, Thomas Abraham wrote:
+- gpios: The gpio specifier for clock, mosi and miso interface lines
On Wed, May 09, 2012 at 10:22:26PM +0800, Thomas Abraham wrote:
On 9 May 2012 18:55, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
Yes, that's the normal way of handling this and is actually what the
code was originally doing - there's a bunch of ifdefed devices in
plat-samsung
On Thu, May 10, 2012 at 12:39:29AM +0800, Thomas Abraham wrote:
On 9 May 2012 22:32, Mark Brown broo...@opensource.wolfsonmicro.com wrote:
Yeah, I know. I'm saying we should try to come up with a binding for
this that can be used by new SPI contollers going forward so things
On Tue, May 08, 2012 at 02:33:29PM +0300, Peter Ujfalusi wrote:
The client drivers will receive their interrupt numbers via pdata which
is configured based on the received IRQ range we got from irq_alloc_descs()
The idiomatic thing is to use resources and have mfd_add_devices() do
the fixup,
On Tue, May 08, 2012 at 11:42:42AM -0700, Rhyland Klein wrote:
+ if (pdata-irq_base = 0)
+ pdata-irq_base = irq_alloc_descs(-1, 0, tps65910-irq_num, -1);
+
+ if (pdata-irq_base = 0) {
+ dev_err(tps65910-dev, Failed to allocate irq descs: %d\n,
+
On Tue, May 08, 2012 at 09:56:02AM -0600, Stephen Warren wrote:
On 05/08/2012 12:42 PM, Rhyland Klein wrote:
Add support for the tps65910 pmic on cardhu.
Lets ignore this one patch for now; it's not clear whether Cardhu should
instantiate the TPS65910 or TPS62360 PMU; apparently different
On Tue, May 08, 2012 at 12:11:31PM -0700, Rhyland Klein wrote:
Is this more what you would expect? If the dt code initialized the
irq_base to 0 instead of -1 then this should also work.
pdata-irq_base = irq_alloc_descs(-1, pdata-irq_base,
tps65910-irq_num, -1);
if
On Tue, May 08, 2012 at 11:42:37AM -0700, Rhyland Klein wrote:
mfd: tps65910-irq: Add devicetree init support
Actually, it's not really relevant to this patch series but looking at
the code for the interrupt controller here it looks like it could be
done in terms of regmap-irq.
On Mon, May 07, 2012 at 09:49:55AM +0300, Peter Ujfalusi wrote:
On 05/04/2012 03:47 PM, Mark Brown wrote:
If there is irq expander type of chip I assume it would have similar
way to get the IRQ number based on either GPIO number or some other
enumeration value.
No, there's no generic
On Mon, May 07, 2012 at 03:58:19PM +0530, Laxman Dewangan wrote:
Add property for the gpio flag open drain when registering
fixed regulator.
Applied, thanks.
There's no need to put stuff like v1 in your patch description, it can
sometimes be useful to do this if it's a revision of a previous
On Mon, May 07, 2012 at 09:20:33AM -0600, Stephen Warren wrote:
My point is that there's clear intent for of_gpio_simple_xlate() to
return the GPIO flags from a field in the GPIO specifier in device tree,
irrespective of whether some GPIO bindings don't allow this, or whether
this is fully
On Fri, May 04, 2012 at 11:38:34AM +0300, Peter Ujfalusi wrote:
The irq_base was used to map the nested interrupt numbers somewhere high
enough. twl6040 has one irq line towards the CPU (comes via
i2c_client-irq).
With this change we just change the mapping of the nested interrupt
range
On Fri, May 04, 2012 at 01:37:54PM +0300, Peter Ujfalusi wrote:
On 05/04/2012 12:08 PM, Mark Brown wrote:
You're not understanding the issue at all - the issue is that if
some driver outside the twl6040 driver is using an interrupt in that
range based off the irq_base that they supplied
On Fri, May 04, 2012 at 02:55:37PM +0300, Peter Ujfalusi wrote:
On 05/04/2012 02:22 PM, Mark Brown wrote:
The OMAP platform related drives has been already converted to use
irq_alloc_descs(-1, 0, nr_irqs, 0); to map their range (including GPIO,
twl6030, etc).
How does this work
On Thu, Apr 26, 2012 at 04:52:20PM +0200, Thierry Reding wrote:
Looking up init data for regulators found on chips is a common operation
that can be handled in a generic way. The new helper function introduced
by this patch looks up the children of a given node by names specified
in a match
On Thu, May 03, 2012 at 03:54:24PM +0300, Peter Ujfalusi wrote:
/* In order to operate correctly we need valid interrupt config */
- if (!client-irq || !pdata-irq_base) {
+ if (!client-irq) {
It looks like you're totally removing the use of irq_base which will
break any boards
On Thu, May 03, 2012 at 04:28:59PM +0300, Peter Ujfalusi wrote:
On 05/03/2012 04:20 PM, Mark Brown wrote:
It looks like you're totally removing the use of irq_base which will
break any boards that didn't convert to DT. The usual idiom is to use
In the current board files the pdata
On Thu, May 03, 2012 at 06:13:16PM +0300, Peter Ujfalusi wrote:
On 05/03/2012 05:52 PM, Mark Brown wrote:
Are you sure there aren't any boards out there which rely on the
interrupt base (eg, using a GPIO with the IRQ output of a chip)?
Yes, I'm sure.
Because...?
signature.asc
Description
On Fri, Apr 27, 2012 at 01:34:19PM -0600, Stephen Warren wrote:
From: Stephen Warren swar...@nvidia.com
This binding doesn't include the nvidia,model or nvidia,audio-routing
properties the other Tegra audio DT bindings have, because this binding
is targetted at a single machine, rather than
On Thu, Apr 26, 2012 at 04:52:20PM +0200, Thierry Reding wrote:
Looking up init data for regulators found on chips is a common operation
that can be handled in a generic way. The new helper function introduced
by this patch looks up the children of a given node by names specified
in a match
On Wed, Apr 25, 2012 at 11:44:59AM +0200, Thierry Reding wrote:
This commit adds device tree support for the TPS6586x regulator.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
This looks basically good from a quick scan through but the pattern of
looking up regulator nodes by
On Wed, Apr 25, 2012 at 12:41:47PM +0200, Thierry Reding wrote:
After taking a closer look I don't think Rhyland's patch is very useful for
this driver. I need to lookup the platform ID by regulator name anyway so
using the new code is actually more work and requires a second table that
lists
On Tue, Apr 24, 2012 at 01:11:09AM -0300, Fabio Estevam wrote:
Add description for 'reg' field.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
On Wed, Apr 18, 2012 at 12:35:58PM -0700, Rhyland Klein wrote:
On Wed, 2012-04-18 at 02:01 -0700, Mark Brown wrote:
This is a really odd idiom - normally the pattern for device tree
support is to just go and try to use the device tree data if it's there
and there's no need for any flag
On Wed, Apr 18, 2012 at 01:19:31PM -0700, Rhyland Klein wrote:
On Wed, 2012-04-18 at 13:03 -0700, Rhyland Klein wrote:
Which interface are you saying is broken? The regmap interface or the
one internal to the tps65910 code?
This driver is broken.
So to be clear... Your recommendation is
On Thu, Apr 19, 2012 at 09:35:49AM -0600, Stephen Warren wrote:
That's not right - the idea is that pdata should override device tree so
that if there's a platform where the DT is known to contain incorrect
data, then some early platform code can add pdata to the device to fix
the problem,
On Tue, Apr 17, 2012 at 06:00:27PM -0700, Rhyland Klein wrote:
Add device tree bindings for TI's tps65910 pmic.
Signed-off-by: Rhyland Klein rkl...@nvidia.com
---
Documentation/devicetree/bindings/mfd/tps65910.txt | 132
1 files changed, 132 insertions(+), 0
On Tue, Apr 17, 2012 at 06:00:28PM -0700, Rhyland Klein wrote:
Add device tree based initialization support for TI's tps65910 pmic.
Actually, now I look at the larger patch this probably wants to be split
up by driver and possibly split further within that.
+ board_data =
On Tue, Apr 17, 2012 at 06:00:26PM -0700, Rhyland Klein wrote:
When accessing the regmap via the read/write functions, we need to use a
unsigned int * instead of a u8 * otherwise corruption will occur.
Signed-off-by: Rhyland Klein rkl...@nvidia.com
static inline int tps65910_read(struct
On Wed, Apr 18, 2012 at 03:01:02PM +0530, Thomas Abraham wrote:
struct max8997_platform_data {
/* IRQ */
- int irq_base;
int ono;
int wakeup;
This will *still* break the build.
signature.asc
Description: Digital signature
On Wed, Apr 18, 2012 at 12:05:59AM +0530, Thomas Abraham wrote:
On 28 March 2012 22:33, Karol Lewandowski k.lewando...@samsung.com wrote:
+ For BUCK's:
No 's here, BTW.
- EN32KHz_AP
- EN32KHz_CP
- ENVICHG
- ESAFEOUT1
- ESAFEOUT2
- CHARGER
- CHARGER_CV
-
On Sat, Mar 24, 2012 at 03:19:49PM +0530, Thomas Abraham wrote:
Add irq domain support for max8997 interrupts. The reverse mapping method
used is linear mapping since the sub-drivers of max8997 such as regulator
and charger drivers can use the max8997 irq_domain to get the linux irq
number for
On Sat, Mar 24, 2012 at 03:19:50PM +0530, Thomas Abraham wrote:
Add device tree based discovery support for max8997.
I tried to apply this but it's collided with some other changes in the
driver which have arrived in the meantime and the rejects were too large
to fix up. I suspect it's mostly
by providing a table with a provider/consumer map in the board
setup code.
With the new pwm_get() and pwm_put() functions available, usage of
pwm_request() and pwm_free() becomes deprecated.
Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
On Tue, Apr 10, 2012 at 05:06:39PM +0200, Thierry Reding wrote:
This commit adds very basic support for device tree probing. Currently,
only a PWM and a list of distinct brightness levels can be specified.
Enabling or disabling backlight power via GPIOs is not yet supported.
Reviewed-by: Mark
On Wed, Apr 11, 2012 at 08:33:56PM +0800, Shawn Guo wrote:
On Tue, Apr 10, 2012 at 05:06:26PM +0200, Thierry Reding wrote:
Reviewed-by: Reviewed-by: Shawn Guo shawn@linaro.org
I have done review only once :)
But it was a really thorough and detailed review!
On Wed, Apr 04, 2012 at 08:00:33PM +, Arnd Bergmann wrote:
On Wednesday 04 April 2012, Mark Brown wrote:
+static const struct of_device_id bmp085_of_match[] = {
+ { .compatible = bosch-sensortec,bmp085, },
Traditionally the stock ticker symbol would be used.
I though about
On Sat, Mar 24, 2012 at 03:19:49PM +0530, Thomas Abraham wrote:
Add irq domain support for max8997 interrupts. The reverse mapping method
used is linear mapping since the sub-drivers of max8997 such as regulator
and charger drivers can use the max8997 irq_domain to get the linux irq
number for
On Fri, Mar 30, 2012 at 06:45:07PM +, Arnd Bergmann wrote:
On Friday 30 March 2012, Stephen Warren wrote:
+- cd-inverted: when present, polarity on the wp gpio line is inverted
+- wp-inverted: when present, polarity on the wp gpio line is inverted
I'm not sure about those two: Some
On Fri, Mar 30, 2012 at 07:06:41AM +0200, Thierry Reding wrote:
* Mark Brown wrote:
The clock and regulator APIs namespace the consumers by struct device -
might this not be sensible here? pwm_get() does already take the device
as an argument. It'd feel safer, and for example there's
On Wed, Mar 28, 2012 at 04:33:43PM +0200, Thierry Reding wrote:
From: Sascha Hauer s.ha...@pengutronix.de
This patch adds framework support for PWM (pulse width modulation) devices.
Looking good, hope we can get this in for 3.5!
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
On Wed, Mar 28, 2012 at 04:33:47PM +0200, Thierry Reding wrote:
+ pwm-list ::= single-pwm [pwm-list]
+ single-pwm ::= pwm-phandle pwm-specifier
+ pwm-phandle : phandle to PWM controller node
+ pwm-specifier : array of #pwm-cells specifying the given PWM
+
this change allows easy integration with the device tree
where a given PWM can be looked up based on the PWM chip's phandle and a
corresponding index.
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
On Wed, Mar 28, 2012 at 04:33:45PM +0200, Thierry Reding wrote:
This commit adds a debugfs interface that can be used to list the
current internal state of the PWM devices registered with the PWM
framework.
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
I'm not sure I don't find
On Wed, Mar 28, 2012 at 04:33:46PM +0200, Thierry Reding wrote:
+ static struct pwm_lookup board_pwm_lookup[] = {
+ PWM_LOOKUP(tegra-pwm, 0, pwm-backlight),
+ };
The clock and regulator APIs namespace the consumers by struct device -
might this not be sensible here?
On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote:
On Tue, Feb 21 2012, Chris Ball wrote:
On Tue, Feb 21 2012, Kukjin Kim wrote:
I created topic branch for this we talked. You can pull that following:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
On Wed, Mar 21, 2012 at 11:33:58AM +0100, Karol Lewandowski wrote:
What do you think about following changes, then?
That looks reasonable.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
int that holds
bitmask with revision-specific quirks
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https
On Tue, Mar 20, 2012 at 09:56:09AM -0600, Stephen Warren wrote:
On 03/20/2012 09:43 AM, Thierry Reding wrote:
What would be a good way to represent this in platform data?
I think most get subsystems have a get API that works for both DT and
non-DT, rather than using platform data:
Yes,
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
After implementing both schemes (ie. interrupts+interrupt-names [*-]gpios)
I definitely prefer the fixed property name plus a separate names property.
It is easier to use common code with that scheme, and easier to statically
On Thu, Mar 15, 2012 at 05:54:33PM +0100, Karol Lewandowski wrote:
If you consider code to be inherently less readable because of this
approach I'll rework it. If it's not a such big deal for you I would
prefer to keep it as is.
The thing that was causing me to think the code was funny was
On Thu, Mar 15, 2012 at 08:40:42AM +, Arnd Bergmann wrote:
On Wednesday 14 March 2012, Thierry Reding wrote:
+static struct pwm_chip *of_node_to_pwmchip(struct device_node *np)
+{
+ return ERR_PTR(-EPROBE_DEFER);
+}
EPROBE_DEFER doesn't exist yet in my kernel, and I wonder if
On Thu, Mar 15, 2012 at 11:04:56AM +0100, Karol Lewandowski wrote:
Introducing separate type (TYPE_S3C2440_HDMIPHY) has been our original
attempt to solve this issue. However, this required adding explicit
checks to driver code all over the place (if (type == S3C2400 ||
type ==
On Thu, Mar 08, 2012 at 02:31:41PM -0700, Stephen Warren wrote:
On 03/08/2012 07:51 AM, Thierry Reding wrote:
+- vdd-supply: power supply for controller (1.05V)
Should those *-supply properties really be optional? I got the
impression talking to Mark in a different thread that all
On Mon, Mar 12, 2012 at 03:17:05PM +0100, Thierry Reding wrote:
My understanding of the fixed regulator was that it was meant to be used for
fixed voltage supplies that can still be enabled or disabled (for example as
supplied by a GPIO) but not regulators that are fix in the sense that they
On Mon, Mar 12, 2012 at 03:28:58PM +0100, Thierry Reding wrote:
In that case I'll mark the *-supply properties required. Would it be a good
idea to mention this (or even give an example with fixed regulators) in the
binding documentation or can I assume this to be common knowledge?
Probably
On Thu, Mar 08, 2012 at 03:51:23PM +0100, Thierry Reding wrote:
If the specified GPIO is not found, return -EPROBE_DEFER. This will
cause the driver to be probed again later when the required GPIO may
have become available.
Might be worth pushing this into gpiolib? It seems like wanting to
On Thu, Mar 08, 2012 at 03:51:25PM +0100, Thierry Reding wrote:
+- gpio-controller: mark the device as a GPIO controller
+- regulators: list of regulators provided by this controller, must be in the
+ following order:
+SM0, SM1, SM2, LDO0, LDO1, LDO2, LDO3, LDO4, LDO5, LDO6, LDO7, LDO8,
On Thu, Mar 08, 2012 at 04:15:46PM +0100, Thierry Reding wrote:
* Mark Brown wrote:
...they all seem to be explicitly named in the device tree so presumably
there's enough information in there for the driver to pick any set of
regulators in any order. This would be much nicer to use.
I
On Thu, Mar 08, 2012 at 03:51:24PM +0100, Thierry Reding wrote:
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
On Fri, Mar 02, 2012 at 02:53:35PM +0100, Samuel Ortiz wrote:
Mark, Liam, are you guys taking this one ?
Yes.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
On Tue, Feb 28, 2012 at 03:09:09PM +0530, Rajendra Nayak wrote:
Hi Mark,
Here is a consolidated series which adds DT support for twl regulator
driver and adds support for VDD1/2/3 regulator and support for
fixed LDO V1V8 and V2V1. The patches are based on -next and tested
on omap3 beagle
On Tue, Feb 28, 2012 at 11:11:48AM +0530, Rajendra Nayak wrote:
changes have no dependencies with any other DT series. I will repost
all of Tero/Peter and my changes (to add DT support to the driver) as
one single series and drop the dts file updates, which I guess can go
via Tony/OMAP tree.
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
Depending on what order Mark happens to pull them in, I am fine
re-sending adding support for the 2 twl6030 fixed regulators.
Please can you guys come up with a single unified series for this stuff
- I'll hold off on applying
On Mon, Feb 27, 2012 at 02:52:05PM +0100, Cousson, Benoit wrote:
On 2/27/2012 2:41 PM, Mark Brown wrote:
On Mon, Feb 27, 2012 at 06:01:20PM +0530, Rajendra Nayak wrote:
Please can you guys come up with a single unified series for this stuff
- I'll hold off on applying anything to allow you
On Thu, Feb 23, 2012 at 05:05:53PM +0530, Rajendra Nayak wrote:
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)
This doesn't apply to current -next, I expect because of
On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:
Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge
to Linus.)
I've been sending patches adding runtime PM support to this driver for a
while with no response - are there any issues with those?
On Tue, Feb 14, 2012 at 03:34:15PM +0800, Richard Zhao wrote:
On Mon, Feb 13, 2012 at 10:06:28PM -0800, Mark Brown wrote:
Machine drivers can easily get platform data, they're just regular
drivers of whatever type so can get platform data in the same way that
any other driver for their bus
On Tue, Feb 14, 2012 at 09:35:07AM +0800, Richard Zhao wrote:
On Sun, Feb 05, 2012 at 12:50:15PM +0800, Richard Zhao wrote:
no, it is asoc machine driver to have machine specific code.
the machine driver do not correspond to any hw device, which cause hard
to bind dt or create platform
On Tue, Feb 07, 2012 at 03:56:24AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
On 16:09 Mon 06 Feb , Mark Brown wrote:
+ - udelay: half clock cycle time in us (may depend on each platform)
+ udelay = 2; /* ~100 kHz */
Why not specify this in kHz and do the conversion
On Tue, Feb 07, 2012 at 08:04:00AM +0100, Thierry Reding wrote:
* Lars-Peter Clausen wrote:
If we've learned one thing from gpiolib, I think it is that using a global
index to identify a resource was a bad idea.
Yes, that concern has been raised several times already. The reason for it
On Sun, Feb 05, 2012 at 04:13:48PM +, Russell King - ARM Linux wrote:
It's not quite correct, because OMAP4 has issues in this area as well
(which does select IRQ_DOMAIN but can be without OF.) The result is
an oops from irq_domain_add() because domain-ops is NULL.
The right solution is
On Sun, Feb 05, 2012 at 11:38:53AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
+ - udelay: half clock cycle time in us (may depend on each platform)
+ udelay = 2; /* ~100 kHz */
Why not specify this in kHz and do the conversion in the driver? It
seems a more intuitive
On Sun, Feb 05, 2012 at 09:53:38PM -0800, Stephen Warren wrote:
On 02/05/2012 08:20 PM, Linus Walleij wrote:
A controlled set of register read/writes and maybe also conditionals
(if that bit is 1, do this, else do that, plus a loop command to wait
for a flag or similar) are known as a jam
On Thu, Feb 02, 2012 at 10:12:05AM +0800, Richard Zhao wrote:
static void __init mxc_init_audio(void)
{
imx31_add_imx_ssi(0, NULL);
mxc_iomux_setup_multiple_pins(ssi_pins, ARRAY_SIZE(ssi_pins), ssi);
+ imx_add_platform_device(audmux-v2, 0,
+
On Thu, Feb 02, 2012 at 10:12:07AM +0800, Richard Zhao wrote:
+Required properties:
+- compatible : fsl,imx31-audmux.
+
+Example:
+
+audmux@021d8000 {
+ compatible = fsl,imx6q-audmux, fsl,imx31-audmux;
+ reg = 0x021d8000 0x4000;
It's kind of obvious what it is but you should
On Thu, Feb 02, 2012 at 09:58:07PM +0800, Richard Zhao wrote:
On Thu, Feb 02, 2012 at 09:09:03PM +0800, Shawn Guo wrote:
It's logically part of this series.
I don't know much about the above boards and I can not test either. I think I
have to leave it to other volunteers. I mainly focus on
On Thu, Feb 02, 2012 at 10:11:26PM +0800, Shawn Guo wrote:
On Thu, Feb 02, 2012 at 01:26:18PM +, Mark Brown wrote:
That's why I'm saying perhaps make it conditional on having ASoC built
(or even on having the AUDMUX driver built).
Do you mean by having the below in some place like
On Wed, Feb 01, 2012 at 03:01:53PM +0100, Frederic LAMBERT wrote:
Don't top post!
Because this bus number is used to create the device name on
/sys/bus/spi/..., name that the user app must know to work with.
Why must the user application know this? What is missing to allow the
application to
On Wed, Feb 01, 2012 at 03:25:33PM +0100, Frederic LAMBERT wrote:
Because this bus number is used to create the device name on
/sys/bus/spi/..., name that the user app must know to work with.
Why must the user application know this? What is missing to allow the
application to discover
On Wed, Feb 01, 2012 at 03:53:00PM +0100, Frederic LAMBERT wrote:
I wrote a piece of code that uses this nvSRAM as a persistent storage.
This runs in a softcore embedded in an FPGA, in an equipment.
The PC version of this application uses a simple file to emulate this
behavior.
The simulated
On Wed, Feb 01, 2012 at 04:29:25PM +0100, Frederic LAMBERT wrote:
To sumarize, I have a same code that works for the 3 architecture, the
single difference being in the device name:
/sys/proc/spi/drivers/at25/spi0.0/eeprom for Nios2
dataBase.dat on Linux
/dev/sdb on the Virtual
On Wed, Feb 01, 2012 at 04:52:14PM +0100, Frederic LAMBERT wrote:
Yes, that seems simple said like that.
It was thus more simple for me, at that time, to modify a specific driver
for a specific port (Nios2), than to modify a core used by every one.
Question of time, and confidence in my own
On Tue, Jan 31, 2012 at 09:30:40AM +0200, Leon Romanovsky wrote:
Document device tree binding for the tegra board with ALC5632 codec
according to datasheet functional block description.
If resending please send the documentation in the same patch as you add
the binding (unless that patch is
On Tue, Jan 31, 2012 at 01:51:43PM +0200, Leon Romanovsky wrote:
On Tue, Jan 31, 2012 at 13:27, Mark Brown
This should really be more detailed, mentioning the CODEC.
Can it be done in followup patch ? or do I need resend them all ?
Followup.
signature.asc
Description: Digital signature
On Tue, Jan 31, 2012 at 09:29:45AM +0200, Leon Romanovsky wrote:
Document the device tree binding for the ALC5632 codec and update vendor
specific prefix for the Realtek.
Applied, thanks.
signature.asc
Description: Digital signature
___
501 - 600 of 823 matches
Mail list logo
