From: Stephen Warren
Modify cmd_dtc to run the C pre-processor on the input .dts file before
passing it to dtc for final compilation. This allows the use of #define
and #include within the .dts file.
Signed-off-by: Stephen Warren
---
v5:
* Update Documentation/kbuild for the new command and
From: Stephen Warren
All architectures that use cmd_dtc do so in the same way. Move the build
rule to a central location to avoid duplication.
Update Documentation/kbuild to remove the explicit call to cmd_dtc from
the example, now that the rule exists in a centralized location, and in
fact
On 10/31/2012 04:32 AM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-10-30 11:02:05)
>> On 10/29/2012 12:32 PM, Mike Turquette wrote:
>>> Quoting Stephen Warren (2012-10-23 14:45:56)
>>>> What do people think of this? Does it sound like a good idea to go ahe
On 11/01/2012 09:53 AM, Dmitry Osipenko wrote:
> Added suspend/resume pm ops. We need to store current regs vals on suspend and
> restore them on resume.
Interesting. Just literally a couple days ago, I was reviewing a patch
to our internal kernel tree that implemented the same thing for the
pinct
On 11/01/2012 08:16 AM, Axel Lin wrote:
> The of_device_id table is supposed to be zero-terminated.
Thanks. How embarrassing! I forwarded this to arm-soc for inclusion into
3.7.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ke
On 11/02/2012 04:23 AM, Ralf Baechle wrote:
> On Fri, Nov 02, 2012 at 10:58:01AM +0100, Ralf Baechle wrote:
>
>> Can you fold these MIPS bits into your patch?
>
> I missed Lantiq.
Thanks, I've squashed that in, and with a quick grep noticed that
arch/{arm64,microblaze} also need updating.
--
To
On 11/02/2012 10:21 AM, Murali Karicheri wrote:
> This is a platform driver for asynchronous external memory interface
> available on TI SoCs. This driver was previously located inside the
> mach-davinci folder. As this DaVinci IP is re-used across multiple
> family of devices such as c6x, keystone
On 11/04/2012 11:04 AM, Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote:
>
>> Would anyone be opposed to having a gpio_get() function that works similarly
>> to e.g. regulator_get() and clk_get()?
>
> I understand the concept and why you want to do this.
>
> However
Mark, Liam,
A couple of the regulators I'm looking at (I guess many/most in fact)
are structured as:
Battery, AC, USB, ... -> PMIC -> main output (unregulated?)
main output -> PMIC input pins for some of the SW-controllable
regulators. This is an external connection on the board.
Should this "m
ral cleanup.
Signed-off-by: Gyungoh Yoo
Signed-off-by: Stephen Warren
---
Note that I also have a regulator driver for this part, which I'll post
in the near future. That driver will depend on this patch (at least the
header file). I'm not sure how dependencies between the mfd and regula
On 07/26/2012 02:35 PM, Mark Brown wrote:
> On Thu, Jul 26, 2012 at 01:40:30PM -0600, Stephen Warren wrote:
>> +if (!irqd_irq_disabled(d) && (value & irq_data->offs)) {
>
> This looks very suspicious... why do we need to call
> irqd_irq_disab
On 07/26/2012 02:35 PM, Mark Brown wrote:
> On Thu, Jul 26, 2012 at 01:40:30PM -0600, Stephen Warren wrote:
>> +if (irqd_is_wakeup_set(d)) {
>> +/* 1 -- disable, 0 -- enable */
>> +switch (irq_data->mask_reg) {
>
>
From: Stephen Warren
A number of places in the code were printing error messages that included
the address of a register, but were not calculating the register address
in the same way as the access to the register. Use a temporary to solve
this.
Signed-off-by: Stephen Warren
---
Note: This
From: Stephen Warren
When suspending, we set up the wake mask registers as required. Some
chips don't have separate wake mask registers, so they set mask_base
equal to wake_base. In that case, when resuming, we re-program the
interrupt enable registers based on enable state rather than
From: Stephen Warren
Some devices contain a single interrupt output, and multiple separate
interrupt controllers that all trigger that interrupt output, yet provide
no top-level interrupt controller/registers to allow determination of
which child interrupt controller caused the interrupt.
In
From: Stephen Warren
The Arizona chip contains a single interrupt that represents the unified
output of multiple internal interrupt controllers. This pattern has been
factored out into regmap-irq, so convert the Arizona driver to use the
new regmap-irq code.
This introduces some hopefully minor
Yoo
Signed-off-by: Stephen Warren
---
Note, this depends on the regmap series I just posted to compile.
v2:
* Rework interrupt code to use regmap-irq. NOTE: This depends on new regmap
feature/patches not yet checked in.
* Implement precious regmap callback to prevent debugfs reading clear
d in the remove
> function.
>
> Signed-off-by: Julia Lawall
Tested-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info
On 07/29/2012 02:36 PM, Mark Brown wrote:
> On Fri, Jul 27, 2012 at 01:01:56PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> Some devices contain a single interrupt output, and multiple separate
>> interrupt controllers that all trigger that interrupt ou
On 07/29/2012 02:38 PM, Mark Brown wrote:
> On Fri, Jul 27, 2012 at 01:02:56PM -0600, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> The Arizona chip contains a single interrupt that represents the unified
>> output of multiple internal interrupt control
On 07/29/2012 03:04 PM, Mark Brown wrote:
> On Fri, Jul 27, 2012 at 01:01:55PM -0600, Stephen Warren wrote:
>
>> When suspending, we set up the wake mask registers as required. Some
>> chips don't have separate wake mask registers, so they set mask_base
>> equal to
On 07/30/2012 09:44 AM, Rob Herring wrote:
> On 07/27/2012 07:05 AM, Alexandre Courbot wrote:
>> Some device drivers (panel backlights especially) need to follow precise
>> sequences for powering on and off, involving gpios, regulators, PWMs
>> with a precise powering order and delays to respect be
On 07/27/2012 06:05 AM, Alexandre Courbot wrote:
> Some device drivers (panel backlights especially) need to follow precise
> sequences for powering on and off, involving gpios, regulators, PWMs
> with a precise powering order and delays to respect between each steps.
> These sequences are board-sp
On 07/31/2012 04:32 AM, Alex Courbot wrote:
> On 07/31/2012 07:45 AM, Stephen Warren wrote:
...
>> If the nodes have a unit address (i.e. end in "@n"), which they will
>> have to if all named "step" and there's more than one of them, then they
>> w
On 07/30/2012 12:03 PM, Mark Brown wrote:
> On Mon, Jul 30, 2012 at 11:05:08AM -0600, Stephen Warren wrote:
>> On 07/29/2012 02:38 PM, Mark Brown wrote:
>>> On Fri, Jul 27, 2012 at 01:02:56PM -0600, Stephen Warren wrote:
>
>>>> 1) regmap_add_irq_chips() calls
On 07/30/2012 11:38 AM, Mark Brown wrote:
> On Mon, Jul 30, 2012 at 11:10:30AM -0600, Stephen Warren wrote:
>
>> hence exit sleep. If we are to port that code into the regmap-irq core,
>> it seems to make sense to have enable_base==wake_base, since the same
>> register
On 09/20/2012 10:51 PM, Philip, Avinash wrote:
> Some backlights perform poorly when driven by a PWM with a short
> duty-cycle. For such devices, the low threshold can be used to specify a
> lower bound for the duty-cycle and should be chosen to exclude the
> problematic range.
>
> This patch adds
On 09/21/2012 01:17 AM, Venu Byravarasu wrote:
> Removed description for unused variables: irq_base, nr_irq &
> hwirq_base, from the irq_domain structure.
The variables/fields aren't unused (present but not used) but rather not
present, deleted, or removed.
--
To unsubscribe from this list: send t
On 09/21/2012 05:00 AM, Venu Byravarasu wrote:
> As RTC driver needs only irq number from platform data,
> using platform_get_irq(), instead of generic dev_get_platdata().
I assume this patch depends on "mfd: tps65910: Add alarm interrupt of
TPS65910 RTC to mfd device list" which you posted just b
On 09/21/2012 07:09 AM, ABRAHAM, KISHON VIJAY wrote:
> Hi,
>
> On Fri, Sep 21, 2012 at 5:50 PM, Venu Byravarasu
> wrote:
>> NVIDIA produces several Tegra SoCs viz Tegra20, Tegra30 etc.
>> In order to support USB PHY drivers on these SoCs, existing
>> PHY driver is split into SoC agnostic common
On 09/21/2012 08:39 AM, Arend van Spriel wrote:
> On 09/21/2012 10:55 AM, Wei Ni wrote:
>> New options enabled:
>> * CFG80211_WEXT: (dependency)
>> * BRCMFMAC: wlan driver, enable as module.
>>
>> Signed-off-by: Wei Ni
>> ---
>> arch/arm/configs/tegra_defconfig |2 ++
>> 1 files changed, 2
On 09/21/2012 12:03 AM, Philip, Avinash wrote:
> Hi Stephen,
>
> On Fri, Sep 21, 2012 at 10:46:45, Stephen Warren wrote:
>> On 09/20/2012 10:51 PM, Philip, Avinash wrote:
>>> Some backlights perform poorly when driven by a PWM with a short
>>> duty-cycle. For su
l facilitate
> easy addition and deletion of phy drivers for Tegra SoCs.
>
> Signed-off-by: Venu Byravarasu
Tested-by: Stephen Warren
> ---
> delta from v2:
>
> Added an if condition to check for device_node to be not NULL,
> before dereferencing it.
I suppose that doesn&
On 09/22/2012 09:56 AM, Mark Brown wrote:
> On Thu, Sep 20, 2012 at 04:04:57PM -0600, Stephen Warren wrote:
>
>> Mark, if this gets into 3.7, I can fix up all the Tegra .dts files during
>> 3.8.
>
> I don't know which branch you generated this against but it
On 09/24/2012 10:07 AM, Stephen Rothwell wrote:
> Hi Randy,
>
> On Mon, 24 Sep 2012 08:39:05 -0700 Randy Dunlap
> wrote:
>>
>> On 09/24/2012 07:53 AM, Stephen Rothwell wrote:
>>
>>> Today was a train wreck, with lots of new conflicts across
>>> several trees and a few build failures as well.
>>
Commit 89214f0 "ARM: bcm2835: add interrupt controller driver" added an
empty drivers/irqchip/Kconfig. Empty files apparently don't work well
with git (sometimes, with some versions?) so add some dummy content to
resolve this issue.
Signed-off-by: Stephen Warren
---
drivers/
On 09/24/2012 12:18 AM, Venu Byravarasu wrote:
>> -Original Message-
>> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
>> Sent: Friday, September 21, 2012 9:21 PM
>> To: Venu Byravarasu
>> Cc: a...@linux-foundation.org; a.zu...@towertech.it; linux-
>
On 09/21/2012 01:05 PM, Arend van Spriel wrote:
> On 09/21/2012 06:19 PM, Stephen Warren wrote:
>> On 09/21/2012 08:39 AM, Arend van Spriel wrote:
>>> On 09/21/2012 10:55 AM, Wei Ni wrote:
>>>> New options enabled:
>>>> * CFG80211_WEXT: (dependency)
>
From: Stephen Warren
Commit "regulator: deprecate regulator-compatible DT property" deprecated
the use of the regulator-compatible DT property. Update the DT example in
the TPS6586x binding documentation to reflect this.
Signed-off-by: Stephen Warren
---
This commit is based on r
From: Stephen Warren
As explained in patch 1, this series deprecates the regulator-compatible
DT property, and updates various binding documentation and examples for
this change.
I expect patches 1-3 to go into various regulator topic trees, and patch
4 to go into the MFD tree.
Stephen Warren
From: Stephen Warren
Commit "regulator: deprecate regulator-compatible DT property" deprecated
the use of the regulator-compatible DT property. Update the DT example in
the TPS65217 binding documentation to reflect this.
Signed-off-by: Stephen Warren
---
This commit is based on r
From: Stephen Warren
Commit "regulator: deprecate regulator-compatible DT property" deprecated
the use of the regulator-compatible DT property. Update the DT example in
the MAX8907 binding documentation to reflect this.
Signed-off-by: Stephen Warren
---
This commit is based on the
From: Stephen Warren
When the bindings for the TPS6586x regulator were being proposed, I
asserted that DT node naming rules for bus child nodes should also be
applied to nodes inside the TPS6586x regulator node itself. In other
words, that each node providing regulator init data should be named
On 09/24/2012 10:29 PM, Philip, Avinash wrote:
> On Fri, Sep 21, 2012 at 23:13:39, Stephen Warren wrote:
>> On 09/21/2012 12:03 AM, Philip, Avinash wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Sep 21, 2012 at 10:46:45, Stephen Warren wrote:
>>>> On 09/20/
On 09/24/2012 11:29 PM, Venu Byravarasu wrote:
> As RTC driver needs only irq number from platform data,
> using platform_get_irq(), instead of generic dev_get_platdata().
This seems fine to me now.
However, it'd be useful to post all the patches related to this issue at
one time, so we can get a
On 09/14/2012 04:23 PM, Markus Mayer wrote:
> Prior to this change, an empty input file would cause a segfault, because
> yylloc had never been initialized. There was never any characters for the
> lexer to match, so YY_USER_ACTION was never executed before the parse error
> was detected.
>
> When
On 09/25/2012 10:35 PM, Philip, Avinash wrote:
> On Tue, Sep 25, 2012 at 11:49:14, Stephen Warren wrote:
>> On 09/24/2012 10:29 PM, Philip, Avinash wrote:
>>> On Fri, Sep 21, 2012 at 23:13:39, Stephen Warren wrote:
>>>> On 09/21/2012 12:03 AM, Philip, A
On 09/26/2012 07:01 AM, Linus Walleij wrote:
> From: Linus Walleij
>
> This pure documentation fix tries to align the "idle" and
> "sleep" pin states to the idle and suspend states from
> runtime PM.
Seems reasonable,
Acked-by: Stephen Warren
--
To unsubs
From: Stephen Warren
All architectures that use cmd_dtc do so in the same way. Move the build
rule to a central location to avoid duplication.
Signed-off-by: Stephen Warren
---
v4: No change.
v3: No change.
v2: New patch.
---
arch/arm/boot/Makefile |4
arch/c6x/boot/Makefile
From: Stephen Warren
Modify cmd_dtc to run the C pre-processor on the input .dts file before
passing it to dtc for final compilation. This allows the use of #define
and #include within the .dts file.
Signed-off-by: Stephen Warren
---
v4:
* Use -x assembler-with-cpp so pre-defined macros are
On 10/27/2012 07:06 PM, Rob Herring wrote:
> Mark Brown wrote:
>
> On Fri, Oct 26, 2012 at 02:57:50PM -0500, Rob Herring wrote:
>
> Like I said previously, I think we first need guidelines on what
> is and
> isn't acceptable use of C preprocessor in dts files.
>
>
>
On 10/26/2012 12:49 PM, Laxman Dewangan wrote:
> Thanks Stephen for review.
> I have taken care of almost all feedback. Some of having my below comments.
>
> On Tuesday 23 October 2012 01:32 AM, Stephen Warren wrote:
>> On 10/18/2012 04:47 AM, Laxman Dewangan wrote:
>>&g
On 10/28/2012 08:17 AM, Dmitry Osipenko wrote:
> Fixed channel "lock" after free.
>
> Example: Channel 1 was allocated and prepared as slave_sg, used and freed.
> Now preparation of cyclic dma on channel 1 will fail with err "DMA
> configuration conflict" because tdc->isr_handler still selected t
On 10/29/2012 01:21 AM, Danny Huang wrote:
> Detect CPU and core process ID by checking speedo corner tables.
> This can provide a more accurate process ID.
> diff --git a/arch/arm/mach-tegra/fuse.c b/arch/arm/mach-tegra/fuse.c
> @@ -114,6 +109,8 @@ void tegra_init_fuse(void)
>
> tegra_re
On 10/29/2012 01:21 AM, Danny Huang wrote:
> This patch adds speedo-based identification support for T30.
> diff --git a/arch/arm/mach-tegra/fuse.c b/arch/arm/mach-tegra/fuse.c
> -#define FUSE_SPARE_BIT 0x200
> +
> +#define TEGRA20_FUSE_SPARE_BIT 0x200
> +#define TEGRA
On 10/29/2012 11:19 AM, Laxman Dewangan wrote:
> Add slink controller details in the dts file of
> Tegra20 and Tegra30.
> diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
> + slink@7000d400 {
I think the node names should be spi@..., since the generic controller
t
On 10/29/2012 11:19 AM, Laxman Dewangan wrote:
> Add OF_DEV_AUXDATA for slink driver for Tegra20 and Tegra30
> board dt files.
> Set the parent clock of slink controller to PLLP and configure
> clock to 100MHz.
> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
> b/arch/arm/mach-tegra/board-dt
On 10/29/2012 10:18 AM, Laxman Dewangan wrote:
> On Monday 29 October 2012 08:47 PM, Stephen Warren wrote:
>> On 10/26/2012 12:49 PM, Laxman Dewangan wrote:
>>>>
>>>> Why not just always set SLINK_FIFO_ERROR; does it have to be set in the
>>>> write o
On 10/29/2012 11:18 AM, Laxman Dewangan wrote:
> Tegra20/Tegra30 supports the spi interface through its SLINK
> controller. Add spi driver for SLINK controller.
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> +config SPI_TEGRA20_SLINK
> + tristate "Nvidia Tegra20/Tegra30 SLINK Cont
On 10/29/2012 12:32 PM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-10-23 14:45:56)
>> What do people think of this? Does it sound like a good idea to go ahead
>> with a reset subsystem? Should we simply add a new API to the common clock
>> subsystem instead (and
Also I added small optimization to
> prepare
> functions, so current channel type checked before making allocations.
Reviewed-by: Stephen Warren
I believe this looks OK. However, I would like Laxman to also ack/review
this since he wrote the driver.
--
To unsubscribe from this list: s
On 10/30/2012 01:04 AM, Laxman Dewangan wrote:
> Tegra20/Tegra30 supports the spi interface through its SLINK
> controller. Add spi driver for SLINK controller.
Reviewed-by: Stephen Warren
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On 10/30/2012 08:23 AM, Dmitry Osipenko wrote:
> This prevents playing sound with wrong speed.
Reviewed-by: Stephen Warren
I guess this is fine, although as you say it makes little practical
difference in the mainline kernel; I'm sure there is much other work to
be done in order to
On 10/30/2012 01:05 AM, Laxman Dewangan wrote:
> This series modify the dts file to add the slink addresses,
> make AUXDATA in board dt files, enable slink4 for tegra30-cardhu and
> enable slink controller defconfig.
This series only instantiates the SPI controller, and not any SPI
devices. I tri
On 10/30/2012 04:07 AM, Pritesh Raithatha wrote:
>...
(a commit description wouuld have been nice; I'll add one)
Applied to Tegra's for-3.7/fixes-for-rc4 branch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
On 08/23/2013 06:22 PM, Colin Cross wrote:
> On Fri, Aug 23, 2013 at 4:09 PM, Stephen Warren wrote:
>> On 08/23/2013 01:45 PM, Colin Cross wrote:
>>> Calling cpuidle_enter_state is expected to return with interrupts
>>> enabled, but interrupts must be disabled before
On 08/24/2013 03:35 PM, Boris BREZILLON wrote:
> Add a new parameter to support deglitch filter configuration.
> A deglitch filter works like a debounce filter but with a smaller
> delay (nanoseconds).
Why not use the existing debounce property, just with a small delay
specified. It seems like tha
On 08/24/2013 03:37 PM, Boris BREZILLON wrote:
> Add support for generic pin configuration to pinctrl-at91 driver.
> diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> Required properties for iomux
On 08/25/2013 01:44 PM, Fabian Vogt wrote:
> Hi,
>
>> On 08/07/2013 06:53 AM, Fabian Vogt wrote:
>>> This driver supports the GPIO controller found in LSI ZEVIO SoCs.
>>> It has been successfully tested on a TI nspire CX calculator.
>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-z
On 08/25/2013 01:49 PM, Fabian Vogt wrote:
> This driver supports the GPIO controller found in LSI ZEVIO SoCs.
> It has been successfully tested on a TI nspire CX calculator.
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
> b/Documentation/devicetree/bindings/gpio/gpio-zevio
On 08/25/2013 11:35 PM, Xiubo Li-B47053 wrote:
>> Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
...
>>> Why do you need to manipulate the pinctrl to en/disable a channel?
>>
>> This is because in Vybrid VF610 TOWER board, there are 4 leds, and each
>> led's one point(diode's
On 08/26/2013 12:45 PM, boris brezillon wrote:
> Hello Jean-Christophe,
>
> Le 26/08/2013 19:53, Jean-Christophe PLAGNIOL-VILLARD a écrit :
>> On 23:37 Sat 24 Aug , Boris BREZILLON wrote:
>>> Add support for generic pin configuration to pinctrl-at91 driver.
...
>>> a/Documentation/devicetree/b
On 08/26/2013 11:01 AM, boris brezillon wrote:
> Hello Stephen,
>
> On 26/08/2013 18:50, Stephen Warren wrote:
>> On 08/24/2013 03:35 PM, Boris BREZILLON wrote:
>>> Add a new parameter to support deglitch filter configuration.
>>> A deglitch filter works like a d
On 08/26/2013 11:17 AM, boris brezillon wrote:
> On 26/08/2013 18:53, Stephen Warren wrote:
>> On 08/24/2013 03:37 PM, Boris BREZILLON wrote:
>>> Add support for generic pin configuration to pinctrl-at91 driver.
>>> diff --git
>>> a/Documentation/devicetree/bin
On 08/26/2013 09:48 PM, Xiubo Li-B47053 wrote:
> Hi Stephen,
>
>
>> Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
>> Freescale FTM PWM
>>
>> On 08/25/2013 11:35 PM, Xiubo Li-B47053 wrote:
Subject: Re: [PATCH 4/4] Documentation: Add device tree bindings for
>> ...
>
On 08/27/2013 02:14 AM, Thierry Reding wrote:
> On Mon, Aug 19, 2013 at 02:49:07PM -0600, Bjorn Helgaas wrote:
>> On Mon, Aug 19, 2013 at 2:12 PM, Thierry Reding
>> wrote:
>>> On Mon, Aug 19, 2013 at 02:04:24PM -0600, Bjorn Helgaas wrote:
On Mon, Aug 19, 2013 at 6:02 AM, Thierry Reding
On 08/27/2013 02:29 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/boot/dts/tegra20-trimslice.dts between commit
> 30ca2226bea6 ("ARM: tegra: always enable USB VBUS regulators") from
> Linus' tree and commit 23f95ef2d951 ("ARM:
On 08/26/2013 04:45 AM, Lars Poeschel wrote:
> On Friday 23 August 2013 at 21:52:20, Stephen Warren wrote:
>> On 08/23/2013 12:45 PM, Linus Walleij wrote:
>>> On Thu, Aug 22, 2013 at 11:10 PM, Stephen Warren
> wrote:
>>>> On 08/21/2013 05:36 PM, Linus Walleij wro
On 08/26/2013 12:18 PM, Fabian Vogt wrote:
> This driver supports the GPIO controller found in LSI ZEVIO SoCs.
> It has been successfully tested on a TI nspire CX calculator.
What changed in v5 (or indeed any other versions?)
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
>
On 08/27/2013 08:40 AM, Mark Rutland wrote:
> On Sun, Aug 25, 2013 at 08:49:40PM +0100, Fabian Vogt wrote:
>> This driver supports the GPIO controller found in LSI ZEVIO SoCs.
>> It has been successfully tested on a TI nspire CX calculator.
>> ---
>> .../devicetree/bindings/gpio/gpio-zevio.txt
On 08/26/2013 08:07 AM, Lars Poeschel wrote:
> From: Linus Walleij
>
> Currently the kernel is ambigously treating GPIOs and interrupts
> from a GPIO controller: GPIOs and interrupts are treated as
> orthogonal. This unfortunately makes it unclear how to actually
> retrieve and request a GPIO lin
On 08/27/2013 02:10 AM, Libo Chen wrote:
> Use the wrapper functions for getting and setting the driver data using
> platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
> so we can directly pass a struct platform_device.
Acked-by: Stephen Warren
--
To unsub
On 08/27/2013 12:04 AM, boris brezillon wrote:
> On 27/08/2013 05:54, Stephen Warren wrote:
>> On 08/26/2013 12:45 PM, boris brezillon wrote:
>>> Hello Jean-Christophe,
>>>
>>> Le 26/08/2013 19:53, Jean-Christophe PLAGNIOL-VILLARD a écrit :
>>>>
On 08/27/2013 01:42 AM, Nicolas Ferre wrote:
> On 27/08/2013 08:16, boris brezillon :
>> On 27/08/2013 05:55, Stephen Warren wrote:
>>> On 08/26/2013 11:01 AM, boris brezillon wrote:
>>>> Hello Stephen,
>>>>
>>>> On 26/08/2013 18:50, Ste
On 08/27/2013 12:40 AM, boris brezillon wrote:
> On 27/08/2013 05:57, Stephen Warren wrote:
>> On 08/26/2013 11:17 AM, boris brezillon wrote:
>>> On 26/08/2013 18:53, Stephen Warren wrote:
>>>> On 08/24/2013 03:37 PM, Boris BREZILLON wrote:
>>>>>
On 08/27/2013 03:30 AM, Sonic Zhang wrote:
> Hi Stephen,
>
> On Fri, Aug 23, 2013 at 4:48 AM, Stephen Warren wrote:
>> On 08/22/2013 01:07 AM, Sonic Zhang wrote:
>>> Hi Stephen,
>>>
>>> On Thu, Aug 22, 2013 at 2:45 AM, Stephen Warren
>>> wr
Use named gpios, as suggested by Stephen Warren
The move and the change to the binding should probably be separate
patches since they're logically separate things. I didn't intend you to
update the rename patch to fix the binding issue I pointed out.
Is the driver updated for this bind
On 08/27/2013 11:01 AM, Josh Cartwright wrote:
...
> If we want to ensure for the generic bindings that we are fulling
> characterizing/describing the SPMI bus, then we'll additionally need to
> tackle an additional identified assumption:
>
> 4. One master per SPMI bus. (The SPMI spec allows fo
On 08/27/2013 03:28 PM, Sebastian Hesselbarth wrote:
> From: Stephen Warren
>
> Tegra's board file currently initializes clocks much earlier than those
> for most other ARM SoCs. The reason is:
>
> * The PMC HW block is involved in the path of some interrupts (i.e. it
>
On 08/27/2013 09:56 PM, Sonic Zhang wrote:
> Hi Stephen,
>
> On Wed, Aug 28, 2013 at 5:39 AM, Stephen Warren wrote:
>> On 08/27/2013 03:30 AM, Sonic Zhang wrote:
>>> Hi Stephen,
>>>
>>> On Fri, Aug 23, 2013 at 4:48 AM, Stephen Warren
>>> wr
On 08/28/2013 12:22 AM, Johannes Thumshirn wrote:
> On Tue, Aug 27, 2013 at 03:41:42PM -0600, Stephen Warren wrote:
>> On 08/27/2013 05:10 AM, Johannes Thumshirn wrote:
>>> I accidently put the devicetree bindings for the MEN A21 watchdog driver in
>>> Documentati
On 08/28/2013 12:00 PM, Josh Cartwright wrote:
> On Tue, Aug 27, 2013 at 03:55:19PM -0600, Stephen Warren wrote:
>> On 08/27/2013 11:01 AM, Josh Cartwright wrote:
>> ...
>>> If we want to ensure for the generic bindings that we are fulling
>>> characterizing/de
On 10/01/2013 08:59 AM, Manish Badarkhe wrote:
> Hi Mark,
>
> Thank you for your reply.
>
> On Tue, Oct 1, 2013 at 2:52 PM, Mark Brown wrote:
>> On Tue, Oct 01, 2013 at 09:41:04AM +0530, Manish Badarkhe wrote:
>>> This patch changes the driver to avoid the usage of IS_ERR_OR_NULL()
>>> macro.
>>
On 10/01/2013 02:08 AM, Uwe Kleine-König wrote:
> On Wed, Sep 25, 2013 at 04:33:24PM +0200, Daniel Lezcano wrote:
>> On 09/16/2013 11:44 AM, Uwe Kleine-König wrote:
>>> Signed-off-by: Uwe Kleine-König
>>> ---
>>> Hello,
>>>
>>> I'm not sure that the way I implemented if a given timer is used as
>>
On 09/23/2013 08:24 AM, Peter De Schrijver wrote:
> This patchset introduces common infrastructure for clocks which exist in
> several Tegra SoCs. We also move Tegra114 to this new infrastructure.
> Tegra20 and Tegra30 will be moved later in separate patchsets.
>
> Changes since v1:
> + move commo
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This far we have enabled gr2d clock on device probe and disabled
> it on device deinitialisation. This patch adds runtime pm support
> for the hardware unit allowing dynamic power management. If pm
> runtime is not enabl
On 09/24/2013 06:05 AM, Arto Merilainen wrote:
> From: Mayuresh Kulkarni
>
> This patch adds runtime pm support for host1x hardware unit. This
> allows host1x clock to be turned off when it is idle. If pm runtime
> is not configured, we enable host1x clock in device probe and disable
> it in remo
On 09/23/2013 03:40 PM, Thierry Reding wrote:
> In preparation for adding an optional regulator and enable GPIO to the
> driver, split the power on and power off sequences into separate
> functions to reduce code duplication at the multiple call sites.
> diff --git a/drivers/video/backlight/pwm_bl
On 09/23/2013 03:41 PM, Thierry Reding wrote:
> The GPIO API defines 0 as being a valid GPIO number, so this field needs
> to be initialized explicitly.
> static void __init smdkv210_map_io(void)
> @@ -70,6 +70,7 @@ static struct samsung_bl_drvdata samsung_dfl_bl_data
> __initdata = {
>
On 09/23/2013 03:41 PM, Thierry Reding wrote:
> Make use of the new enable_gpio field and allow it to be set from DT as
> well. Now that all legacy users of platform data have been converted to
> initialize this field to an invalid value, it is safe to use the field
> from the driver.
> diff --git
401 - 500 of 2891 matches
Mail list logo
