On Mon, Nov 26, 2012 at 08:15:12PM +0530, Padma Venkat wrote:
> On Wed, Nov 14, 2012 at 5:39 PM, Padmavathi Venna wrote:
> > +module_init(smdk_audio_init);
> > +module_exit(smdk_audio_exit);
> Ping. Any comments on this patch?
Don't send contentless pings and delete irrelevant context from repl
On Tue, Nov 27, 2012 at 08:44:29AM +, Arnd Bergmann wrote:
> I think I'm missing context here. What's holding this up? It looks like it
> should
> have been merged before 531f67e41d, possibly into both arm-soc and asoc.
Jean-Christophe was very insistent that the pinctrl stuff got added and
On Mon, Nov 26, 2012 at 09:55:33PM -0800, Peter Korsgaard wrote:
> >>>>> "Mark" == Mark Brown writes:
> Mark> Since the driver is happy to continue without the pins why is it
> Mark> bothering requesting them in the first place? In other words, this
&
On Tue, Nov 27, 2012 at 04:37:32PM +0100, Laurent Pinchart wrote:
> One possibly crazy idea I had was to replace backlight devices as we know
> them
> with LED devices (a LED driver IC shouldn't be supported by different APIs
> depending on whether the LEDs it drives are used as a backlight or
On Tue, Nov 27, 2012 at 02:04:32PM +0530, Thomas Abraham wrote:
> Add device tree based discovery support for max8997.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
On Wed, Nov 28, 2012 at 11:21:31AM +0530, Padma Venkat wrote:
> On Wed, Nov 28, 2012 at 10:55 AM, Sangbeom Kim wrote:
> >> > The requirement for an alias is also very odd, where does that come from?
> >> I don't know that Which one is odd. Please let me know.
> > Having them at all is odd - it'
On Wed, Nov 28, 2012 at 11:35:43AM +0100, Peter Ujfalusi wrote:
> Handle the jack detection inforamtion as bool from devicetree.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.
On Wed, Nov 28, 2012 at 04:17:48PM +0530, Padmavathi Venna wrote:
> As the I2S src clks are registered with clkdev using generic
> connection id, driver can get the clk name using generic id.
> So the variable representing the array of rclk src clks is
> deleted.
Applied, thanks.
signature.asc
D
On Sat, Dec 01, 2012 at 03:37:26PM +0530, Padmavathi Venna wrote:
> Add the basic device tree based lookup.
>
> Signed-off-by: Padmavathi Venna
> ---
> sound/soc/samsung/smdk_wm8994.c | 23 +++
Any new device tree bindings need binding documentation.
Your subject line is a
On Sat, Dec 01, 2012 at 03:37:27PM +0530, Padmavathi Venna wrote:
> sound/soc/samsung/dma.c | 24 ++--
> sound/soc/samsung/dma.h |3 +++
> sound/soc/samsung/i2s.c |3 +++
> sound/soc/samsung/smdk_wm8994.c |7 +--
> 4 files changed, 17
On Thu, Dec 06, 2012 at 09:31:40AM +0530, Padma Venkat wrote:
> On Wed, Nov 28, 2012 at 4:17 PM, Padmavathi Venna wrote:
> > Padmavathi Venna (2):
> > ASoC: Samsung: Get I2S src_clk from clock alias id.
> > ASoC: SAMSUNG: Add DT support for i2s
> Any comments on DT support for i2s patch? If
On Thu, Dec 06, 2012 at 11:55:11AM +0530, Abhilash Kesavan wrote:
> As of now there is no support in the regulator core to specify the suspend
> state
> (mode, enabled/disabled) using dt. I can add new properties specifying
> the intial_state,
> mode, enable/disable but I am not too sure if it is
On Thu, Dec 06, 2012 at 09:20:36AM +0530, Padmavathi Venna wrote:
> Previously, the ASoC 'platform' (PCM/DMA) object was instantiated via a
> platform_device. This didn't represent the hardware well, since there
> was no separate hardware associated with this platform_device; it was a
> virtual dev
On Fri, Dec 07, 2012 at 01:59:21PM +0530, Padmavathi Venna wrote:
> Previously, the ASoC 'platform' (PCM/DMA) object was instantiated via a
> platform_device. This didn't represent the hardware well, since there
> was no separate hardware associated with this platform_device; it was a
> virtual dev
On Sat, Dec 08, 2012 at 10:07:54AM +0530, Padma Venkat wrote:
> Samsung i2s driver registers the platform device twice one for the
> samsung-i2s.0,1 or 2 and two for samsung-i2s.4(which actually doesn't
> represent any H/W peripheral). The max number of I2S blocks on any
> Samsung SoC are 3, the s
On Mon, Dec 10, 2012 at 04:30:50PM +0530, Padma Venkat wrote:
> Could you please explain me in more detail about "single DT link
> automatically expanded into two DAI links".
> How this can be done?
The device tree should only represent the single physical link that
exists and the handling of the
On Mon, Dec 10, 2012 at 02:06:49PM +0530, Abhilash Kesavan wrote:
> On Mon, Dec 10, 2012 at 1:49 PM, Abhilash Kesavan
> wrote:
> > Mark Brown opensource.wolfsonmicro.com> writes:
> >> Binding documenation is mandatory for any new OF properties, please add
> >
On Fri, Dec 14, 2012 at 09:06:49AM -0700, Stephen Warren wrote:
> On 12/13/2012 10:50 PM, Naveen Krishna Chatradhi wrote:
> > +The first should be an output, and is used to claim the I2C bus,
> > +the second should be an input, and signals that the other side (Client)
> > +wants to claim the bus.
On Mon, Dec 17, 2012 at 11:23:20AM +0100, Nicolas Ferre wrote:
> Mark, what about rebasing this one on top of current Linus' tree
> (toguether with the one that you have just applied on the topic/atmel
> branch: (ASoC: atmel-ssc: change disable to disable in dts node)?
> I hope that once reworked
On Wed, Dec 19, 2012 at 01:24:14PM +, Grant Likely wrote:
> On Thu, 13 Dec 2012 16:12:53 +0530, Padmavathi Venna
> wrote:
> > +- compatible : "samsung,samsung-i2s"
> Isn't that kind of redundant? :-)
> The format of the compatible strings should be ",-i2s".
> Please be specific about the
On Wed, Dec 19, 2012 at 12:32:01PM +, Grant Likely wrote:
> I'm not convinced on the design of this protocol. It won't scale beyond
> 2 bus masters and it seems very specific to the design of a specific
> piece of hardware. I don't think it is mature enough to bake into the
I ought to point o
On Wed, Dec 26, 2012 at 04:21:58PM +0530, Padma Venkat wrote:
> Hi,
>
> On Mon, Dec 24, 2012 at 9:33 AM, Padma Venkat wrote:
> > Hi,
You should always delete irrelevant text from mails, it makes it much
easier for people to find whatever content you've added.
> >> I agree with using version her
On Tue, Dec 25, 2012 at 08:35:59PM +0530, Laxman Dewangan wrote:
> All TPS51632 registers are not readable/writable and
> non-volatiles.
Applied both, thanks, but you might wish to consider...
> +static bool is_read_reg(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + cas
On Mon, Dec 31, 2012 at 11:51:42AM +0100, Peter Ujfalusi wrote:
> In order to be able to use the Voice port of twl4030 three bits need to be
> handled in VOICE_IF register:
> VIF_EN: to enable the voice port (needed for both playback and capture)
> VIF_DIN_EN: Need to be enabled for playback only (
On Fri, Jan 04, 2013 at 03:24:36PM +0530, Hebbar Gururaja wrote:
> From: "Hebbar, Gururaja"
>
> Signed-off-by: Hebbar, Gururaja
Linus has a change for this in the core which currently looks like it'll
get merged in v3.8 so there doesn't seem to be any pressing need for
driver specific changes t
On Fri, Jan 04, 2013 at 03:24:37PM +0530, Hebbar Gururaja wrote:
> + "MIC3L","Mic Bias 2V",
> + "MIC3R","Mic Bias 2V",
> + "Mic Bias 2V", "Mic Jack",
The CODEC driver biases should be changed over to be supplies, this
ma
On Mon, Jan 07, 2013 at 09:20:16AM +, Hebbar, Gururaja wrote:
> I will be looking into this now. To speed up the things, do you have any
> reference link/implementation which I can refer to?
Any modern CODEC driver.
> I looked at the OMAP implementation but they are following the same (mean
On Thu, Jan 10, 2013 at 12:41:47AM +0100, Tomasz Figa wrote:
> + * The following lookup table is used to override device names when devices
> + * are registered from device tree. This is temporarily added to enable
> + * device tree support addition for the Exynos4 architecture.
Cut'n'paste.
si
On Thu, Jan 10, 2013 at 12:41:43AM +0100, Tomasz Figa wrote:
> +- interrupt-mask : Bit mask of valid interrupt sources (defaults to all
> valid)
> +- wakeup-mask : Bit mask of interrupt sources that can wake up the system
> + (defaults to all allowed)
Should this really be configured in the VIC
On Thu, Jan 10, 2013 at 12:41:45AM +0100, Tomasz Figa wrote:
> This patch modifies IRQ initialization code of S3C64xx to support
> Device Tree-based initialization of VICs.
Reviewed-by: Mark Brown
signature.asc
Description: Digital sig
On Thu, Jan 10, 2013 at 12:10:38PM +0100, Tomasz Figa wrote:
> This is not the runtime interrupt/wakeup mask, but a global mask of
> available interrupt/wakeup lines on particular platform, which still have
> to be configured and enabled appropriately by user.
Ah, OK.
Reviewed-by: M
On Tue, Jan 08, 2013 at 05:55:42PM +0530, Laxman Dewangan wrote:
> I am not sure that the patches are created on correct sequence for
> adapting this in regulator subsystem and mfd subsystem.
> Can you please review whether the changes split is fine or not?
> Idea was to make independent patch for
On Thu, Nov 01, 2012 at 05:32:26PM +0200, Pantelis Antoniou wrote:
> Introducing capebus; a bus that allows small boards (capes) to connect
> to a complex SoC using simple expansion connectors.
>
> Up to now to support these kind of boards, one had to hack the board files,
> and do all sort of gym
On Thu, Nov 01, 2012 at 05:32:25PM +0200, Pantelis Antoniou wrote:
> Capebus is created to address the problem of many SoCs that can provide a
> multitude of hardware interfaces but in order to keep costs down the main
> boards only support a limited number of them. The rest are typically brought
>
On Fri, Dec 28, 2012 at 02:59:39PM +0530, Laxman Dewangan wrote:
> Add DT support for TI PMIC tps65090 regulator driver. The DT of this
> device have node regulator and all regulator's node of this device is
> added under this node.
Reviewed-by: Mark Brown
Seems sensible for this
not require to implement the same in the driver.
>
> Remove this non-require code.
Acked-by: Mark Brown
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Tue, Jan 22, 2013 at 09:26:34PM +0530, Sekhar Nori wrote:
> On 1/16/2013 2:02 AM, Matt Porter wrote:
> > This series adds DMA Engine support for AM33xx, which uses
> > an EDMA DMAC. The EDMA DMAC has been previously supported by only
> > a private API implementation (much like the situation wit
On Wed, Jan 23, 2013 at 12:39:35PM +, Hebbar, Gururaja wrote:
> On Fri, Jan 04, 2013 at 17:56:12, Mark Brown wrote:
> > The CODEC driver biases should be changed over to be supplies, this
> > makes the above much more natural - the routing there is a hack for
> > o
On Fri, Jan 18, 2013 at 05:17:00PM +0530, Padmavathi Venna wrote:
> All Samsung SoCs has max 3 i2s controllers. So the i2s secondary fifo
> interface device id was named as samsung-i2s.4. Renaming this to
> "samsung-i2s-sec" to support device tree in i2s driver.
Applied, thanks.
signature.asc
De
On Thu, Jan 24, 2013 at 09:33:34AM +, Hebbar, Gururaja wrote:
> So, by just using the SND_SOC_DAPM_POST_PMU & SND_SOC_DAPM_PRE_PMD I can mask
> & handle one particular voltage.
What makes you say that? That is just not true.
signature.asc
Description: Digital signature
__
On Thu, Jan 24, 2013 at 10:06:42AM +, Hebbar, Gururaja wrote:
> What I meant was that by using this macro (SND_SOC_DAPM_POST_PMU &
> SND_SOC_DAPM_PRE_PMD) I can just save and restore existing voltage values
> inside
> the event. They will not be user configurable (available to user through so
On Thu, Jan 24, 2013 at 12:13:29PM +0100, Wolfram Sang wrote:
> On Sat, Dec 15, 2012 at 11:21:36PM +0900, Mark Brown wrote:
> > also get things like read operations which appear as multiple
> > transactions on the I2C bus so require something higher level than what
> > multi-
On Thu, Jan 24, 2013 at 04:25:19PM +0530, Vishwanathrao Badarkhe, Manish wrote:
> ---
> arch/arm/boot/dts/tps6507x.dtsi | 47
> +++
Why are you putting this in arch/arm?
signature.asc
Description: Digital signature
_
On Thu, Jan 24, 2013 at 12:39:48PM +0100, Wolfram Sang wrote:
> On Thu, Jan 24, 2013 at 07:18:47PM +0800, Mark Brown wrote:
> > A read is typically implemented as a write of the register address
> > followed by a read of the value, usually with the ability to free the
> > bu
On Fri, Jan 25, 2013 at 06:29:49AM +, Vishwanathrao Badarkhe, Manish wrote:
> On Thu, Jan 24, 2013 at 17:30:51, Mark Brown wrote:
> I too doubt that whether it should be in architecture specific folder,
> My code is in reference to below patch:
> arm/dts: regulator: Add tps65910
On Thu, Jan 24, 2013 at 04:25:18PM +0530, Vishwanathrao Badarkhe, Manish wrote:
> Add device tree based initialization support for
> TI's tps6507x regulators.
Applied, thanks. Please always use subject lines appropriate for the
subsystem you are submitting against - this is not a DaVinci change.
On Fri, Jan 18, 2013 at 05:17:09PM +0530, Padmavathi Venna wrote:
> Signed-off-by: Padmavathi Venna
This should be sent separately to Vinod for merge into v3.8, it's not
obviously related to the rest of the series and is a bug fix.
signature.asc
Description: Digital signature
__
On Mon, Jan 14, 2013 at 06:36:04PM -0800, Kuninori Morimoto wrote:
> This patch adds snd_soc_of_parse_daifmt() and supports below style on DT.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-
On Mon, Jan 14, 2013 at 06:40:37PM -0800, Kuninori Morimoto wrote:
Sorry about the delay in getting back to you on this.
> +- simple-audio,cpu,dai,clock-gating : if needed, see below
A lot of these are listed as "if needed" - this means they should be
listed separately as optional prope
On Mon, Jan 28, 2013 at 02:11:38PM -0700, Stephen Warren wrote:
> On 01/14/2013 07:40 PM, Kuninori Morimoto wrote:
> > +simple-audio,xxx,dai,clock-gating
> > + "continuous"
> > + "gated"
> Don't you need to use the common clock bindings to define which clock to
> gate? Or, is the I2S/... node
On Mon, Jan 28, 2013 at 05:31:33PM -0800, Kuninori Morimoto wrote:
> > > +- simple-audio,cpu,dai,clock-gating : if needed, see below
> > A lot of these are listed as "if needed" - this means they should be
> > listed separately as optional properties rather than in the required
> > p
ould get all the necessary information from the device tree.
>
> Like the patch that converts the dw_dma controller, this is completely
> untested and is looking for someone to try it out.
Acked-by: Mark Brown
I've no ability to test this but it looks good from a code poin
On Fri, Jan 18, 2013 at 05:17:03PM +0530, Padmavathi Venna wrote:
> This patch modifies the SPI driver to use generic dma dt bindings
> support. This passes all the required arguments to dma dev request
> functon which in turn calls the dma_request_slave_channel or dma__
> request_channel based on
On Fri, Jan 18, 2013 at 05:17:02PM +0530, Padmavathi Venna wrote:
> This patch make the dma dev request operation compatible for both
> DT and non-DT cases. It takes the all the arguments required for
> dma_request_slave_channel and dma_request_channel. If the driver
> is initiated via DT or non-DT
On Fri, Jan 18, 2013 at 05:17:06PM +0530, Padmavathi Venna wrote:
> +Samsung SMDK audio complex
This is just for SMDKs with WM8994. I'll apply but please send a
followup patch to clarify this - it'll be a different binding for others
like the older boards using WM8580 and WM9713.
> +
On Fri, Jan 18, 2013 at 05:17:07PM +0530, Padmavathi Venna wrote:
> This patch removes custom way of adding spi dma channels and
> adds according to new generic DMA DT bindings.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetr
On Fri, Jan 18, 2013 at 05:17:08PM +0530, Padmavathi Venna wrote:
> Update Kconfig file to enable I2S,PCM audio for wm8994 and spdif on all
> samsung platforms.
Applied, thanks.
signature.asc
Description: Digital signature
___
devicetree-discuss mailin
On Tue, Jan 29, 2013 at 02:35:16PM +0530, Laxman Dewangan wrote:
> Add DT support for TI PMIC tps65090 regulator driver. The DT of this
> device have node regulator and all regulator's node of this device is
> added under this node.
There doesn't seem to be any dependency on the rest of the series
T and is the only user
> implementing EDMA so in the !DT case we can default to the OMAP DMA
> filter.
Acked-by: Mark Brown
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Wed, Jan 30, 2013 at 01:14:07PM -0700, Stephen Warren wrote:
> > +CPU / CODEC DAI is represented as a sub-node.
> > +Then, sub-node name should be "simple-audio,cpu" or "simple-audio,codec".
> Why require sub-nodes? it seem over-complex.
I suggested this because it seemed more legible to repe
On Thu, Jan 31, 2013 at 11:23:53AM -0500, Anson Huang wrote:
> some of anatop's regulators(cpu, vddpu and vddsoc) have
> register settings about LDO's step time, which will impact
> the LDO ramp up speed, need to use set_voltage_time_sel
> interface to add necessary delay everytime LDOs' voltage
>
On Thu, Jan 31, 2013 at 04:53:10PM +0530, Hebbar Gururaja wrote:
> :100644 100644 e7b98f4... f47c3f5... M
> Documentation/devicetree/bindings/sound/tlv320aic3x.txt
> :100644 100644 ffd9bc7... 9407fd0... Minclude/sound/tlv320aic3x.h
> :100644 100644 4989143... 65d09d6... Mso
On Thu, Jan 31, 2013 at 11:27:07AM +, Hebbar, Gururaja wrote:
> On Thu, Jan 31, 2013 at 16:54:16, Mark Brown wrote:
> > As mentioned when you posted this before this patch needs to update the
> > machine drivers using the device too.
> The patch-set 2/4 does the same t
On Thu, Jan 31, 2013 at 10:09:37AM -0700, Stephen Warren wrote:
> On 01/30/2013 06:35 PM, Mark Brown wrote:
> > I suggested this because it seemed more legible to repeat the
> > properties by having a named structure for each property rather
> > than by repeating them all wi
On Thu, Jan 31, 2013 at 10:15:55AM -0700, Stephen Warren wrote:
> In that diagram, it looks like the CPU-side simply doesn't receive a
> system clock at all, so it's recovering any clock by multiplying up the
> bit clock.
Practically speaking this is the case for most simple CPU DAIs, unless
you'
On Thu, Jan 31, 2013 at 10:17:20AM -0700, Stephen Warren wrote:
> On 01/31/2013 10:11 AM, Mark Brown wrote:
> > There's more attributes that we might want to configure on the
> > devices than just the actual DAI link. Clocks for example.
> Sure, but this binding is *simpl
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 28, 2012 at 04:33:43PM +0200, Thierry Reding wrote:
> From: Sascha Hauer
>
> 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
signature.asc
Description: Digital
On Wed, Mar 28, 2012 at 04:33:47PM +0200, Thierry Reding wrote:
> + pwm-list ::= [pwm-list]
> + single-pwm ::=
> + pwm-phandle : phandle to PWM controller node
> + pwm-specifier : array of #pwm-cells specifying the given PWM
> + (controller specific)
> +PWM
side-effect 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
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
I'm not sure I don't find the style w
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 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 f
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 tw
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 st
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
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
> I have done review only once :)
But it was a really thorough and detailed review!
__
gt; works 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
signature.asc
Descri
viewed-by: Mark Brown
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
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
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 j
On Wed, Apr 18, 2012 at 12:05:59AM +0530, Thomas Abraham wrote:
> On 28 March 2012 22:33, Karol Lewandowski wrote:
> >> + For BUCK's:
No 's here, BTW.
> > - EN32KHz_AP
> > - EN32KHz_CP
> > - ENVICHG
> > - ESAFEOUT1
> > - ESAFEOUT2
> > - CHARGER
> > - CHARGER_CV
> > - CHARGER_TOPOFF
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
> ---
> Documentation/devicetree/bindings/mfd/tps65910.txt | 132
>
> 1 files changed, 132 insertions(+), 0 deletions(-)
Ther
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 = tps65910->board_
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
> static inline int tps65910_read(struct tps65910_reg *p
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: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
> > a
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 recommendat
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 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
https://lists.ozlabs
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
This looks basically good from a quick scan through but the pattern of
looking up regulator nodes by name is very common so should
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
> li
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 Fri, Apr 27, 2012 at 01:34:19PM -0600, Stephen Warren wrote:
> From: Stephen Warren
>
> 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 for any machin
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 boa
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 c
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.
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
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,
> >> twl
201 - 300 of 927 matches
Mail list logo
