On Fri, Dec 09, 2011 at 01:52:00PM -0800, Stephen Warren wrote:
> I'd originally made this property specific to the Tegra+WM8903 machine
> driver, and you'd asked me to make it generic. Is there room to use
> the binding above for the Tegra+WM8903 machine driver only, in order
> to get the driver
On Wed, Dec 07, 2011 at 01:58:28PM -0700, Stephen Warren wrote:
> DAI link endpoints and platform (DMA) devices are currently specified
> by name. When instantiating sound cards from device tree, it may be more
> convenient to refer to these devices by phandle in the device tree, and
> for code to
On Wed, Dec 07, 2011 at 01:58:27PM -0700, Stephen Warren wrote:
> Transform some loops from:
Applied, thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Thu, Dec 08, 2011 at 07:17:05PM +, Liam Girdwood wrote:
> It also seems that once 1 & 2 are applied, we would almost be able to
> just have a generic "device tree" machine driver for some simple ASoC
> machines that have DAPM and no other external logic atm. We would just
> be missing some
On Wed, Dec 07, 2011 at 01:58:29PM -0700, Stephen Warren wrote:
> Move DAS routing setup into the DAS driver itself. This removes the need
> to duplicate this in each machine driver, of which we'll soon have three.
Applied, thanks.
___
devicetree-discuss
On Wed, Dec 07, 2011 at 01:58:26PM -0700, Stephen Warren wrote:
> + audio-routing =
> + "Headphone Jack", "HPOUTR",
> + "Headphone Jack", "HPOUTL",
> + "Int Spk", "ROP",
> + "Int Spk", "RON",
> + "Int Spk", "LOP",
> + "Int
On Wed, Dec 07, 2011 at 01:58:25PM -0700, Stephen Warren wrote:
> +sound {
> + compatible = "nvidia,tegra-audio-wm8903",
> + "generic,soc-audio-complex";
> + user-visible-name = "tegra-wm8903-harmony";
That user visible name is idiomatic for device tree but it's not
idiom
On Wed, Dec 07, 2011 at 03:49:27PM -0800, Olof Johansson wrote:
> On Fri, Dec 02, 2011 at 03:08:37PM -0700, Stephen Warren wrote:
> > Olof, Colin, could you please ack this so that Mark can apply it to the
> > ASoC tree even though it touches Tegra code? Thanks.
> Mark, since Stephen is a tegra m
On Tue, Dec 06, 2011 at 10:22:24AM -0800, Stephen Warren wrote:
> Now, everything still works without this. Looking at the Linux OF code,
> it works by retrieving the compatible property, taking everything after
> the comma if present, and then creating an i2c_board_info with that
> type, which in
On Fri, Dec 02, 2011 at 03:08:37PM -0700, Stephen Warren wrote:
> wm8903_platform_data.gpio_cfg[] was intended to be interpreted as follows:
> 0: Don't touch this GPIO's configuration register
> 1..7fff: Write that value to the GPIO's configuration register
> 8000:Write zero to the GPIO's
On Tue, Dec 06, 2011 at 11:26:43AM +0800, Shawn Guo wrote:
> On Mon, Dec 05, 2011 at 07:09:47PM +0000, Mark Brown wrote:
> > That doesn't answer the question - I've still no idea how the binding is
> > supposed to map the nodes contained within regulators onto the physic
On Thu, Dec 01, 2011 at 05:21:06PM +0800, Shawn Guo wrote:
> It's not always true that the device_node of regulator can be found
> at dev->of_node at the time when of_get_regulator_init_data() is being
> called, because in some cases the regulator nodes in device tree do
> not have 'struct device'
On Mon, Dec 05, 2011 at 02:41:24PM +0800, Shawn Guo wrote:
> On Fri, Dec 02, 2011 at 03:36:38PM +0000, Mark Brown wrote:
> > On Thu, Dec 01, 2011 at 05:21:05PM +0800, Shawn Guo wrote:
> > > +Sub-nodes:
> > > +- regulators : Contain the regulator nodes. The bindings d
On Mon, Dec 05, 2011 at 03:45:04PM +0200, Peter Ujfalusi wrote:
> On 12/03/2011 01:22 PM, Mark Brown wrote:
> > Actually thinking about this some more I think what's concerning me is
> > the documentation as much as anything else - if it was just an internal,
> > unpubli
On Mon, Dec 05, 2011 at 04:14:40PM +0530, Thomas Abraham wrote:
> On 5 December 2011 16:04, Mark Brown
> > With the regulator device tree bindings if the regulator is configured
> > to run a single voltage the bindings will set apply_uV unconditionally
> > so there
On Mon, Dec 05, 2011 at 02:40:50PM +0530, Thomas Abraham wrote:
> On 4 December 2011 21:24, Mark Brown
> > If the regulator isn't software managed then always_on covers this - the
> > regulator core will enable any always_on regulators that haven't been
> > enabled
On Sun, Dec 04, 2011 at 06:51:23PM +0530, Thomas Abraham wrote:
> For regulators that are not turned on by bootloader, and which require
> 'apply_uV' constraint, is there any alternative for turning on the
> regulator when using dt?
If the regulator isn't software managed then always_on covers th
On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> @@ -0,0 +1,13 @@
> +* Texas Instruments OMAP4 Digital Microphone Module
> +
> +Required properties:
> + - compatible : "ti,omap4-dmic"
> + - ti,hwmods : List of hwmod names associated with DMIC, in most case
> + it i
On Fri, Dec 02, 2011 at 03:08:38PM -0700, Stephen Warren wrote:
> When no platform data is supplied, point pdata at a default platform
> structure. This enables two future changes:
Applied, thanks. The rest are OK too but I'll leave them for a little
while for the Tegra guys (though the changes a
On Fri, Dec 02, 2011 at 03:08:40PM -0700, Stephen Warren wrote:
> + switch (irqd_get_trigger_type(irq_data)) {
> + case IRQ_TYPE_NONE:
> + /*
> + * We assume the controller imposes no restrictions,
> + * so we are able to select active-high
> +
On Thu, Dec 01, 2011 at 05:21:05PM +0800, Shawn Guo wrote:
> +Sub-nodes:
> +- regulators : Contain the regulator nodes. The bindings details of
> individual
> + regulator node can be found in:
> + Documentation/devicetree/bindings/regulator/regulator.txt
How does the driver figure out which r
On Fri, Dec 02, 2011 at 03:59:01PM +0100, Cousson, Benoit wrote:
> On 12/2/2011 3:00 PM, Mark Brown wrote:
> >At least the DMA bindings seem fairly well sorted - we just merged the
> >Tegra audio bindings which define a Tegra property for the DMA request
> >signal. There
On Sat, Dec 03, 2011 at 01:31:07AM +1100, David Gibson wrote:
> My apologies. I was mixing up who said what. It was Stephen who made
> this proposal, kicking off the thread.
Ah, OK - I think there's been some misreading here.
> SW> One possibility is to describe this directly in the binding fo
On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote:
> Even if the reg-names and interrupts-names are accepted, which is
> still not obvious due to a little bit of resistance, we still do not
Yeah, it seems like there's very little traction on any of the problems
with legacy bindings
On Fri, Dec 02, 2011 at 11:24:18PM +1100, David Gibson wrote:
> No, you suggested it be a global property of the interrupt source.
> Same problem, just less so.
Cite?
> > Not in the real world, in the real world we don't have device tree
> > bindings for most of the interrupt controllers out the
On Fri, Dec 02, 2011 at 02:32:59PM +0200, Peter Ujfalusi wrote:
> As of now we receive all these information via OMAP hwmod.
> All the properties (addresses, irq, etc) of the HW IP will be coming
> from DT as soon as I can remove the ti,hwmod property.
Oh, right. We should really be churning the
On Fri, Dec 02, 2011 at 11:52:56AM +0200, Peter Ujfalusi wrote:
> +Required properties:
> + - compatible : "ti,omap4-dmic"
> + - ti,hwmods : List of hwmod names associated with DMIC, in most case
> + it is "dmic".
Shouldn't there also be a regs property giving the register window?
On Fri, Dec 02, 2011 at 04:38:14PM +1100, David Gibson wrote:
> On Thu, Dec 01, 2011 at 11:07:39AM +0000, Mark Brown wrote:
> > Right, but you could stuff those in an enormous array or whatever - the
> > point was to describe the per interrupt information.
> Well, ok, but t
On Thu, Dec 01, 2011 at 01:49:19PM -0700, Stephen Warren wrote:
> The GPIO registers are 15 bits wide. Hence values, higher than 0x7fff are
> not legal GPIO register values. Modify the pdata.gpio_cfg handling code
> to reject all illegal values, not just WM8903_GPIO_NO_CONFIG (0x8000). This
> will
On Thu, Dec 01, 2011 at 04:48:11PM -0800, Stephen Warren wrote:
> Mark Brown wrote at Thursday, December 01, 2011 5:28 PM:
> > This will break existing users in counjuntion with the previous patch.
> > Previously if the user provided platform data but left gpio_base as zero
>
On Thu, Dec 01, 2011 at 01:49:20PM -0700, Stephen Warren wrote:
> + /* Default platform data, for use if none is supplied */
> + defpdata.irq_active_low = false;
> + defpdata.micdet_cfg = 0;
> + defpdata.micdet_delay = 0;
No need to set things to zero (or just memset the structure
On Thu, Dec 01, 2011 at 01:49:21PM -0700, Stephen Warren wrote:
> - if (pdata && pdata->gpio_base)
> - wm8903->gpio_chip.base = pdata->gpio_base;
> - else
> - wm8903->gpio_chip.base = -1;
> + wm8903->gpio_chip.base = pdata->gpio_base;
This will break existing u
On Thu, Dec 01, 2011 at 08:46:35AM -0800, Stephen Warren wrote:
> Mark Brown wrote at Thursday, December 01, 2011 6:26 AM:
> > This all seems really complicated and invasive, especially the
> > have_pdata flag. Why not just always have a platform data structure and
> > fill
On Wed, Nov 30, 2011 at 05:47:35PM -0700, Stephen Warren wrote:
> v2: (swarren) Significantly reworked based on review feedback.
> v1: (swarren) Applied the following modifications relative to John's code:
> * Cleaned up DT parsing code
> * Documented DT binding
> * Set up wm8903->gpio_chip.of_nod
On Wed, Nov 30, 2011 at 04:38:26PM -0500, Nicolas Pitre wrote:
> On Wed, 30 Nov 2011, Mark Brown wrote:
> > Oh, dear. Any pointers to the discussions on the u-boot side?
> Certainly. Many different threads actually. Here's a few:
OK, thanks - I see Stephen just followed up a
On Thu, Dec 01, 2011 at 12:31:40AM +1100, David Gibson wrote:
> On Wed, Nov 30, 2011 at 09:33:06AM +0000, Mark Brown wrote:
> > I'm sorry, I'm not following you. In what way is this duplicating
> > information that's already there,
> Each interrupt source de
On Wed, Nov 30, 2011 at 03:43:50PM -0500, Nicolas Pitre wrote:
> annoying. If nothing moves I might just go ahead with those changes and
> simply rip the uImage make target out of the kernel as well. Maybe the
> inconvenience will be a sufficient incentive for people to lobby proper
> u-Boot
On Tue, Nov 29, 2011 at 06:36:48PM -0700, Stephen Warren wrote:
> Signed-off-by: Stephen Warren
Applied, thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Wed, Nov 30, 2011 at 04:13:49PM +1100, David Gibson wrote:
> On Tue, Nov 29, 2011 at 10:55:38AM +0000, Mark Brown wrote:
> > On Tue, Nov 29, 2011 at 12:30:55PM +1100, David Gibson wrote:
> > > Um.. why? These new properties don't appear to give any information
> >
On Tue, Nov 29, 2011 at 07:59:26AM +0100, Thierry Reding wrote:
> of hook that allows the driver to specify at probe time that some resources
> are still missing and is used for cases where there is no explicit dependency
> information and thus the driver core doesn't know in which order devices n
On Mon, Nov 28, 2011 at 05:23:30PM -0600, Rob Herring wrote:
> I think adding another property is the wrong approach. The information
> is already there in the interrupt binding. irq_create_of_mapping almost
> does what you need. Perhaps it could be extended to return the type as
> part of the irq
On Tue, Nov 29, 2011 at 12:30:55PM +1100, David Gibson wrote:
> On Mon, Nov 28, 2011 at 03:29:51PM -0700, Stephen Warren wrote:
> > One possibility is to describe this directly in the binding for each
> > interrupt source. I originally proposed the following for the WM8903:
...
On Mon, Nov 28, 2011 at 03:29:51PM -0700, Stephen Warren wrote:
> Perhaps one of:
> irq-active-low;
> irq-active-high;
> irq-edge-falling;
> irq-edge-rising;
> or:
>
> interrupts-config = <"active-low"> // or "active-high", etc.
> (perhaps with indices in that list matching the interrupts prope
On Mon, Nov 28, 2011 at 09:37:16PM +0800, Shawn Guo wrote:
> Device tree compiler does not recognize '-' in label name. Instead,
> '_' works fine.
Applied, thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozl
On Mon, Nov 28, 2011 at 09:37:18PM +0800, Shawn Guo wrote:
> It adds device tree probe support for mc13892-regulator driver.
You haven't documented the binding here at all. Documentation is
mandatory for all device tree bindings.
___
devicetree-discuss
On Mon, Nov 28, 2011 at 09:37:17PM +0800, Shawn Guo wrote:
> ---
> drivers/regulator/of_regulator.c |7 ---
> include/linux/regulator/of_regulator.h |6 --
> 2 files changed, 8 insertions(+), 5 deletions(-)
Clearly this is going to break the build as you've not updated the
On Sat, Nov 26, 2011 at 10:07:01PM -0600, Rob Herring wrote:
> On 11/25/2011 10:09 AM, Mark Brown wrote:
> > On Fri, Nov 25, 2011 at 09:55:23AM -0600, Rob Herring wrote:
> >> Although, I think you are possibly missing some other properties for
> >> i2s mode like word si
On Fri, Nov 25, 2011 at 09:55:23AM -0600, Rob Herring wrote:
> Although, I think you are possibly missing some other properties for
> i2s mode like word size and master/slave mode. I think the ideal case
> is that a single ASoC platform driver for DT could handle multiple
> SoCs.
No. You're not
On Fri, Nov 18, 2011 at 04:47:16PM +0530, Rajendra Nayak wrote:
> For the first 2 patches (1/4 and 2/4) I have dropped
> Acks from Mark, since they have changed to some extent
> from the last post and retained the Acks recieved on the
> last 2 patches (3/4 and 4/4) as they remain unchanged.
Looks
On Fri, Nov 18, 2011 at 04:47:20PM +0530, Rajendra Nayak wrote:
> + struct device_node *regnode = NULL;
> + char prop_name[32]; /* 32 is max size of property name */
There ought to be a #define for that though I can't see one right now -
this can't be the only place where we need to do st
On Wed, Nov 23, 2011 at 09:54:21AM -0800, Stephen Warren wrote:
> Mark Brown wrote at Wednesday, November 23, 2011 4:04 AM:
> > This should really be part of the same commit as the arch/arm side
> > change in order to avoid bisection breaks as from the point of view of
> >
On Tue, Nov 22, 2011 at 06:21:19PM -0700, Stephen Warren wrote:
> + /*
> + * FIXME: Perhaps there should be a standard binding for this
> + * that ends up creating the IORESOURCE_DMA resource for us.
> + */
> + if (of_property_read_u32
On Tue, Nov 22, 2011 at 06:21:25PM -0700, Stephen Warren wrote:
This looks basically fine, a few comments and obviously it depends on
the other patches in the series.
> + nvidia,routing =
> + "Headphone Jack", "HPOUTR",
> + "Headphone Jack", "HPOUTL",
> + "
On Tue, Nov 22, 2011 at 06:21:22PM -0700, Stephen Warren wrote:
> Codecs often have a large number of external pins, and not all of these pins
> will be connected on all board designs. Some machine drivers therefore call
> snd_soc_dapm_nc_pin() for all the unused pins, in order to tell the ASoC cor
On Tue, Nov 22, 2011 at 06:21:21PM -0700, Stephen Warren wrote:
> module_platform_drive saves some boiler-plate code.
>
> The devm_ APIs remove the need to manually clean up allocations,
> thus removing some code.
Applied, thanks - again should be split.
__
On Tue, Nov 22, 2011 at 06:21:20PM -0700, Stephen Warren wrote:
> module_platform_drive saves some boiler-plate code.
>
> The devm_ APIs remove the need to manually clean up allocations,
> thus removing some code.
Applied, thanks. Again, should be two changes.
___
On Tue, Nov 22, 2011 at 06:21:18PM -0700, Stephen Warren wrote:
> Signed-off-by: Stephen Warren
Applied, thanks - the binding seems entirely uncontroversial as there's
just a compatible and register binding, if there are problems we can
always revert or fix before 3.3.
BTW, you probably want to
On Tue, Nov 22, 2011 at 06:21:17PM -0700, Stephen Warren wrote:
> + i2s->dai = tegra_i2s_dai_template;
> + i2s->dai.name = pdev->name;
> +
This should really be part of the same commit as the arch/arm side
change in order to avoid bisection breaks as from the point of view of
non-DT syste
On Wed, Nov 23, 2011 at 08:04:49AM +0100, Thierry Reding wrote:
Always delete unneeded context from your mails so that people can
actually find the content you've added and don't have to scroll through
the entire patch.
___
devicetree-discuss mailing lis
On Tue, Nov 22, 2011 at 06:21:09PM -0700, Stephen Warren wrote:
> OF_DEV_AUXDATA("nvidia,tegra20-i2c", TEGRA_DVC_BASE, "tegra-i2c.3",
> NULL),
> OF_DEV_AUXDATA("nvidia,tegra20-i2s", TEGRA_I2S1_BASE, "tegra-i2s.0",
> NULL),
> - OF_DEV_AUXDATA("nvidia,tegra20-i2s", TEGRA_I2S1_BASE,
On Tue, Nov 22, 2011 at 06:21:16PM -0700, Stephen Warren wrote:
> module_platform_drive saves some boiler-plate code.
>
> The devm_ APIs remove the need to manually clean up allocations,
> thus removing some code.
Applied but again this should be split into two separate patches.
_
On Tue, Nov 22, 2011 at 06:21:15PM -0700, Stephen Warren wrote:
> module_platform_drive saves some boiler-plate code.
>
> The devm_ APIs remove the need to manually clean up allocations,
> thus removing some code.
Applied but this is two separate changes and should've been split.
On Tue, Nov 22, 2011 at 06:21:14PM -0700, Stephen Warren wrote:
> This saves some boiler-plate code.
Applied, thanks.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Tue, Nov 22, 2011 at 06:21:13PM -0700, Stephen Warren wrote:
> This removes potentially machine-specific routing knowledge from the
> I2S driverinto the machine drivers, which is better equipped to know
> what the appropriate routing configuration is.
Applied, thanks.
__
On Wed, Nov 23, 2011 at 07:58:08AM +0100, Thierry Reding wrote:
> * Stephen Warren wrote:
> > - platform_set_drvdata(pdev, NULL);
> > -
> Setting the driver data to NULL may still be a good idea.
It's always been a waste of time.
___
devicetree-discu
On Tue, Nov 22, 2011 at 06:21:12PM -0700, Stephen Warren wrote:
> + - irq-active-low : Indicates whether the IRQ output should be active low
> +(property present) or active high (property absent).
I think we ought to be coming up with a standard binding for this stuff
rather than having eve
Add a placeholder device tree binding for the wm8994 driver. At present
the binding is essentially null as none of the platform data is supported,
and at least some of that will depend on the pending regulator bindings.
Signed-off-by: Mark Brown
---
Documentation/devicetree/bindings/sound
On Fri, Nov 04, 2011 at 03:16:12PM -0700, Olof Johansson wrote:
> On Fri, Nov 4, 2011 at 2:46 PM, Mark Brown
> >> Describing that in the device tree using regulator-specifiers
> >> shouldn't be too bad? The LDO will reference the DCDC as the parent
> >> supply
On Fri, Nov 04, 2011 at 03:09:32PM -0700, Olof Johansson wrote:
> But even things like allowing (optional) attributes such as
> startup-delay on non-fixed regulators could make sense. Keep in mind
> that the device tree should focus on describing the hardware, not just
> what the linux driver need
On Fri, Nov 04, 2011 at 02:47:05PM -0700, Olof Johansson wrote:
> On Fri, Nov 4, 2011 at 2:25 PM, Mark Brown
> > I don't see how you can usefully do that, the task of plumbing a
> > regulator into a board is largely orthogonal to the specific feature set
> > of a give
On Fri, Nov 04, 2011 at 02:34:35PM -0700, Olof Johansson wrote:
> On Fri, Nov 4, 2011 at 2:29 PM, Mark Brown
> > I think it's useful to define how consumers are supposed to do this
> > somewhere - it is actually part of the core binding how consumers are
> > supposed to
On Fri, Nov 04, 2011 at 02:22:16PM -0700, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 09:14:48PM +0000, Mark Brown wrote:
> > The name will be fixed by the individual device bindings, this is
> > specifying the general form of a supply property. Each device binding
> > w
On Fri, Nov 04, 2011 at 02:18:24PM -0700, Olof Johansson wrote:
> On Fri, Nov 04, 2011 at 09:01:52PM +0000, Mark Brown wrote:
> > No, the fixed voltage regultor is a superset of a general regulator - it
> > has additional information like the voltage it supplies and the optional
On Fri, Nov 04, 2011 at 01:29:05PM -0700, Olof Johansson wrote:
> On Thu, Oct 27, 2011 at 06:54:24PM +0530, Rajendra Nayak wrote:
> > @@ -0,0 +1,33 @@
> > +Voltage/Current Regulators
> There should be a mandatory compatible field here, right? I.e. a topmost
> generic one, "regulator" or similar.
On Fri, Nov 04, 2011 at 01:21:26PM -0700, Olof Johansson wrote:
> On Thu, Oct 27, 2011 at 2:08 AM, Mark Brown
> > Looking at the device bindings I notice that these bindings loose the
> > ability to assign a descriptive name to regulator outputs. This is
> > really useful
On Fri, Nov 04, 2011 at 01:34:22PM -0700, Olof Johansson wrote:
> Shouldn't a fixed regulator just be a subset of a fixed one? If so, should the
> binding be merged with that one?
No, the fixed voltage regultor is a superset of a general regulator - it
has additional information like the voltage
On Wed, Nov 02, 2011 at 06:35:05PM +0530, Thomas Abraham wrote:
> On 1 November 2011 13:52, Sylwester Nawrocki wrote:
> > It doesn't give as much advantage, and introduces an overhead of doing
> > an additional remapping. However I find current mapping of the DT specifier
> > values to real drive
On Thu, Oct 27, 2011 at 01:26:25PM +0530, Rajendra Nayak wrote:
> Device nodes in DT can associate themselves with one or more
> regulators/supply by providing a list of phandles (to regulator nodes)
> and corresponding supply names.
Acked-by: M
the dt-adapted driver can
> then pass this additional info onto the regulator core.
Acked-by: Mark Brown
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
t can be passed through dt.
Acked-by: Mark Brown
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
ith the status change thing
but I think we need to gather some experience to figure that out and
since it's implicit hopefully that won't have any compatibility issues
if it does happen.
Acked-by: Mark Brown
I guess it might be useful to resend without this bit at the top to make
it
On Thu, Oct 27, 2011 at 01:26:21PM +0530, Rajendra Nayak wrote:
> v3 is based on the latest devicetree/next and is tested
> (with twl adaptaions, which will be posted seperately)
> on the OMAP4 panda and OMAP4 sdp boards.
Looking at the device bindings I notice that these bindings loose the
abili
On Thu, Oct 27, 2011 at 01:34:33PM +0530, Rajendra Nayak wrote:
> Also add documentation for TWL regulator specific bindings.
This should've been in the previous patch.
> +For twl6030 regulators/LDO's
LDOs.
___
devicetree-discuss mailing list
devicetr
On Thu, Oct 27, 2011 at 01:34:32PM +0530, Rajendra Nayak wrote:
> + select OF_REGULATOR if OF
We should probably just not have OF_REGULATOR or do the select from the
core, this is just going to end up being noisy.
___
devicetree-discuss mailing list
On Thu, Oct 27, 2011 at 01:26:22PM +0530, Rajendra Nayak wrote:
> + min_uV = of_get_property(np, "regulator-min-uV", NULL);
> + if (min_uV)
> + (*init_data)->constraints.min_uV = be32_to_cpu(*min_uV);
> + max_uV = of_get_property(np, "regulator-max-uV", NULL);
> + if (m
On Mon, Oct 24, 2011 at 10:47:17PM +0800, Shawn Guo wrote:
> On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> > Might be best to just
> > search within dev and get drivers to pass the "real" device in when
> > registering the regulator rather than t
On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> +++ b/drivers/regulator/core.c
> @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct
> regulator_desc *regulator_desc,
> BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
>
> /* find device_node and attach
On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> If we can attach the device_node of 'regulators' node to dev->of_node
> when calling regulator_register(regulator_desc, dev, ...) from
> regulator driver, the regulator core will be able to find all nodes under
> 'regulators' using for_e
On Mon, Oct 24, 2011 at 11:24:11AM +0200, Grant Likely wrote:
> To follow up from my earlier comment, this .dts structure looks fine
> and reasonable to me, and it would also be fine for the mc13892 driver
> to use for_each_child_of_node() to find all the children of the
> regulators node. Even f
On Mon, Oct 24, 2011 at 02:23:50PM +0530, Rajendra Nayak wrote:
> How about the driver passing the of_node to be associated with the
> regulator, as part of regulator_desc, to the regulator core,
> instead of this complete DT search and the restriction of having
> to match DT node names with names
On Mon, Oct 24, 2011 at 11:32:19AM +0530, Rajendra Nayak wrote:
> On Friday 21 October 2011 05:28 PM, Shawn Guo wrote:
> >Driver name does not matter. The key for this search to work is having
> >regulator's name (regulator_desc->name) match device tree node's name,
> >case ignored.
> Mark, what
On Thu, Oct 20, 2011 at 01:10:55PM -0700, Tony Lindgren wrote:
> * Mark Brown [111020 12:23]:
> > I don't understand what an "arch independent DT node" would be?
> Well that's the standard non-Linux specific parts. Basically what's
> in the $Subject p
On Thu, Oct 20, 2011 at 10:22:19AM -0700, Tony Lindgren wrote:
> Hmm, actually, can't we just pass the board specific configuration in
> the board specific .dts file and then it gets merged in with the
> arch independent DT node?
I don't understand what an "arch independent DT node" would be?
___
On Thu, Oct 20, 2011 at 10:05:34AM -0700, Tony Lindgren wrote:
> Right, but in addition the board specific integration variables still
> need to be passed somehow to the driver.
I'm not sure you're aware of what the regulator bindings that are being
discussed are - they're entirely board specific
On Thu, Oct 20, 2011 at 09:27:43AM -0700, Tony Lindgren wrote:
> * Mark Brown [111020 02:07]:
> > We can always start off just completely omitting the data and then see
> > how we go from there. If we only cover 50% of users that's still 50%
> > more than are currentl
On Thu, Oct 20, 2011 at 09:12:10AM +0530, Rajendra Nayak wrote:
> On Wednesday 19 October 2011 08:40 PM, Mark Brown wrote:
> >I don't see any issue with leaving some things out of the DT bindings;
> >you were the one raising that as a concern.
> The problem is, that the
On Wed, Oct 19, 2011 at 11:04:49PM +0800, Shawn Guo wrote:
> On Wed, Oct 19, 2011 at 03:47:34PM +0100, Mark Brown wrote:
> > Only the board can come to a final decision.
> The dts is very capable and suitable to describe the board's decision.
> But you disagree that we
On Wed, Oct 19, 2011 at 10:42:16PM +0800, Shawn Guo wrote:
*Please* delete irrelevant quotes from mails.
> On Wed, Oct 19, 2011 at 05:05:56PM +0530, Rajendra Nayak wrote:
> > Yes, it seems like a good idea given that most drivers seem to blindly
> > pass the regulator_init_data onto regulator_re
On Wed, Oct 19, 2011 at 01:33:55PM +0800, Shawn Guo wrote:
> On Tue, Oct 18, 2011 at 05:00:46PM +0100, Mark Brown wrote:
> > It's not just Linux-specific stuff, some of this is even specific to
> > what current Linux drivers can do - updating the kernel could mean a
On Tue, Oct 18, 2011 at 07:58:37PM +0800, Shawn Guo wrote:
> I understand that ideally device tree is supposed to describe pure
> hardware configurations. But practically, when migrating a driver
> to device tree probe, we are trying to move the configurations
> described by platform_data into de
701 - 800 of 927 matches
Mail list logo
