On Tue, Oct 20, 2015 at 3:39 AM, Russell King - ARM Linux
wrote:
> On Mon, Oct 19, 2015 at 08:27:44PM +0200, Uwe Kleine-König wrote:
>> Hello,
>>
>> On Mon, Oct 19, 2015 at 04:43:24PM +0100, Russell King - ARM Linux wrote:
>> > It's a bit ironic that you've chosen GPIO as an example there. The
>>
dev)
> +{
> + struct tps65912_gpio *gpio = platform_get_drvdata(pdev);
> +
> + gpiochip_remove(&gpio->gpio_chip);
> +
> + return 0;
> +}
> +
> +static struct platform_driver tps65912_gpio_driver = {
> + .driver = {
> + .name = "tp
On Tue, Sep 22, 2015 at 10:54 PM, Chris Read wrote:
> On Mon, Sep 21, 2015 at 4:55 PM, Linus Walleij
> wrote:
>> On Wed, Sep 2, 2015 at 6:35 AM, Chris Read wrote:
>>> There are some hardware aspects/parameters
>>> of exporting that aren't controllable from userspace, such as whether or not
>>>
On Sun, Aug 30, 2015 at 4:44 PM, Markus Pargmann wrote:
> There is no reason to find out chip and hwnum to use to request a gpio
> and get another gpio descriptor. We already have the descriptor we want
> to use so we can directly use it.
>
> Signed-off-by: Markus Pargmann
> ---
> drivers/gpio/g
On Sat, Sep 19, 2015 at 2:17 AM, Javier Martinez Canillas
wrote:
> Hello Alexandre,
>
> On 09/18/2015 05:44 PM, Alexandre Courbot wrote:
>> On Thu, Sep 17, 2015 at 10:33 AM, Javier Martinez Canillas
>> wrote:
>>> The GPIO DT binding doc mentions that GPIO are m
On Thu, Sep 17, 2015 at 10:33 AM, Javier Martinez Canillas
wrote:
> The GPIO DT binding doc mentions that GPIO are mapped by defining
> a -gpios property in the consumer device's node but a -gpio
> sufix is also supported after commit:
>
> dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property n
On Tue, Sep 1, 2015 at 4:20 AM, Chris Read wrote:
> From what I see the standard kernel allows exposing GPIOs to userspace.
> There are kernel calls to do so. It seems to be recognized as an important
> feature. The standard kernel also has a regulator-consumer whose whole
> purpose is to expose
s to userspace.
>
> I believe that the GPIO subsystem maintainers (Linus Walleij and
> Alexandre Courbot) were trying to make GPIO control from userspace more
> consistent (independent of DT) for a while. However I am not all that
> familiar with the GPIO subsystem and may have misun
On Tue, Apr 28, 2015 at 3:45 PM, Uwe Kleine-König
wrote:
> Hello,
>
> On Tue, Apr 28, 2015 at 12:31:37PM +0900, Alexandre Courbot wrote:
>> On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König
>> wrote:
>> > On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Co
On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König
wrote:
> Hello,
>
> On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Courbot wrote:
>> I should have replied one month ago, but if gpiolib is disabled, how
>> can we use gpiolib-like logic to check the existence of a GP
On Fri, Mar 6, 2015 at 5:59 PM, Uwe Kleine-König
wrote:
> Hello,
>
> On Fri, Mar 06, 2015 at 09:26:26AM +0100, Linus Walleij wrote:
>> On Thu, Feb 12, 2015 at 10:03 AM, Uwe Kleine-König
>> wrote:
>>
>> > I wonder if gpiod_get_optional et all should be changed to return NULL
>> > instead.
>>
>> Th
On Wed, Mar 18, 2015 at 3:27 PM, Tomeu Vizoso
wrote:
> On 18 March 2015 at 06:10, MyungJoo Ham wrote:
>>> Hello,
>>>
>>> something happened during the last cycle and an old version of the devfreq
>>> driver was merged.
>>>
>>> This thread contains patches that bring it up to date to the last subm
ned-off-by: Stephen Warren
The series, and this patch in particular,
Tested-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 12, 2015 at 11:06 PM, Tomeu Vizoso
wrote:
> From: Mikko Perttunen
>
> Add binding documentation for the nvidia,tegra124-emc device tree node.
>
> Signed-off-by: Mikko Perttunen
> Signed-off-by: Tomeu Vizoso
>
> ---
>
> v5: * Add a short description for each of the register prope
n in the
> common dtsi so we can paste the output as is and be sure that the kernel
> doesn't diverge from the canonical data.
FWIW, the series:
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
t; * Renamed helper function
> * Refactored pr_* calls to remove "__func__"
>
> Changes since v4:
> * Addressed review comments from Alexandre Courbot
>
> Changes since v3:
> * Relocated the non-DT "hog" function to gpiolib.c.
> * Rename some of
On Thu, Feb 19, 2015 at 2:23 AM, Benoit Parrot wrote:
> Gentle ping.
>
> Is there any chance this will make it in 3.21?
I'm good with it - Linus will probably come to it after the 3.20 merge
window closes.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a m
On Wed, Feb 11, 2015 at 1:28 PM, Ulf Hansson wrote:
> [...]
>
>>> +int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
>>> +{
>>> + struct mmc_pwrseq_simple *pwrseq;
>>> +
>>> + pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
>>> + if (!pwrseq)
IO for the consumer.
>
> Signed-off-by: Ulf Hansson
Excellent, with this I can probe the wifi chip on NVIDIA SHIELD which
requires a GPIO to be high for reset to be de-asserted.
The series:
Tested-by: Alexandre Courbot
> ---
>
> Changes in v4:
> - Fixed call
On Mon, Jan 19, 2015 at 6:13 PM, Ulf Hansson wrote:
> To add the core part for the MMC power sequence, let's start by adding
> initial support for the simple MMC power sequence provider.
>
> In this initial step, the MMC power sequence node are fetched and the
> compatible string for the simple MM
On Tue, Feb 10, 2015 at 2:38 AM, Robert Jarzmik wrote:
> Tyler Hall writes:
>
>>> The issue with multiple gpiochips per of-node could be worked around as
>>> followed I believe, comments?
>>>
>>> diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
>>> index 08261f2..43984ab 100644
Adding Robert who reported the same thing.
On Sat, Feb 7, 2015 at 6:28 AM, Tyler Hall wrote:
> Hi,
>
> Commit 7b8792b ("gpiolib: of: Correct error handling in
> of_get_named_gpiod_flags") seems to break the ability to use DT
> bindings to reference this driver's GPIOs by phandle for banks above
>
s this match your vision of how it should work, i.e. ACK?
Pretty much, yes - as I mentioned in the previous versions there may
be shortcomings for ACPI, but we need a refactor of the whole thing -
nothing that this patch should address by itself.
So this patch:
Reviewed-by: Alexandre Courbot
--
To un
On Thu, Jan 22, 2015 at 6:44 AM, Olliver Schinagl wrote:
> Hey Alexandre,
>
> On 01/19/2015 05:04 AM, Alexandre Courbot wrote:
>>
>> On Wed, Jan 7, 2015 at 6:08 PM, Olliver Schinagl
>> wrote:
>>>
>>> From: Olliver Schinagl
>>>
>>>
On Sun, Jan 18, 2015 at 8:39 PM, Ricardo Ribalda Delgado
wrote:
> This way we do not need to transverse the device tree manually.
... and this makes things much more legible.
Acked-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
On Mon, Jan 19, 2015 at 12:43 PM, Alexandre Courbot wrote:
> On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl wrote:
>>
>> On 14-01-15 13:45, Linus Walleij wrote:
>>>
>>> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov
>>> wrote:
>>>&
On Wed, Jan 7, 2015 at 6:08 PM, Olliver Schinagl
wrote:
> From: Olliver Schinagl
>
> The gpio binding document says that new code should always use named
> gpios. Patch 40b73183 added support to parse a list of gpios from child
> nodes, but does not make it possible to use named gpios. This patch
On Wed, Jan 14, 2015 at 10:20 PM, Olliver Schinagl wrote:
>
> On 14-01-15 13:45, Linus Walleij wrote:
>>
>> On Thu, Jan 8, 2015 at 11:12 PM, Dmitry Torokhov
>> wrote:
>>>
>>> On Thu, Jan 08, 2015 at 08:40:20AM -0600, Rob Herring wrote:
On Thu, Jan 8, 2015 at 2:45 AM, Olliver Schinagl
>
On Wed, Jan 14, 2015 at 8:20 PM, Álvaro Fernández Rojas
wrote:
> El 14/01/2015 a las 6:32, Alexandre Courbot escribió:
>> On Wed, Dec 17, 2014 at 7:41 AM, Álvaro Fernández Rojas
>> wrote:
>>> Add DT support while keeping legacy support.
>>>
>>
On Sat, Jan 17, 2015 at 12:24 AM, Linus Walleij
wrote:
> On Wed, Jan 14, 2015 at 9:17 AM, Alexandre Courbot wrote:
>> On Wed, Jan 14, 2015 at 5:13 PM, Linus Walleij
>> wrote:
>>> On Wed, Dec 10, 2014 at 9:51 AM, Alexandre Courbot wrote:
>>>> On Fri, Dec 5
On Wed, Jan 14, 2015 at 5:13 PM, Linus Walleij wrote:
> On Wed, Dec 10, 2014 at 9:51 AM, Alexandre Courbot wrote:
>> On Fri, Dec 5, 2014 at 12:38 PM, Zhou Wang wrote:
>>> In function gpiochip_find_base, base number of a GPIO controller
>>> is found in decreasing orde
On Tue, Jan 13, 2015 at 1:39 AM, Benoit Parrot wrote:
> Linus Walleij wrote on Mon [2015-Jan-12 11:20:14
> +0100]:
>> On Fri, Dec 19, 2014 at 9:07 PM, Benoit Parrot wrote:
>>
>> > Add GPIO hogging documentation to gpio.txt
>> >
>> > Signed-off-b
On Tue, Dec 16, 2014 at 5:41 PM, Tomeu Vizoso
wrote:
> Add device node for the ACTMON block to the Tegra124 device tree.
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
M
cles in a sampling period */
> + stat->total_time = ACTMON_SAMPLING_PERIOD * tegra->cur_freq;
> +
> + stat->busy_time = min(stat->busy_time, stat->total_time);
> +
> + return 0;
> +}
> +
> +static struct devfreq_dev_profile tegra_devfreq_prof
andard interrupt property
> +- clocks: Must contain a phandle and clock specifier pair for each entry in
> clock-names. See ../clock/clock-bindings.txt for details.
Mmm, shouldn't this line be wrapper at character 80? Same throughout this file.
Also from this file the correct patch to c
On Fri, Dec 19, 2014 at 2:08 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Wed [2014-Dec-17 17:41:51
> +0900]:
>> Looks ok to me. I have a few nits below, but otherwise I am happy with
>> how it turned out:
>>
>> Reviewed-by: Alexandre Courbot
>
On Wed, Dec 17, 2014 at 7:26 PM, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 11:45:01 Alexandre Courbot wrote:
>>
>> Actually we are not that far from being able to do completely without
>> any GPIO number, and maybe that's what we should aim for. I think the
On Wed, Dec 17, 2014 at 7:44 PM, Russell King - ARM Linux
wrote:
> On Wed, Dec 17, 2014 at 11:45:01AM +0900, Alexandre Courbot wrote:
>> Actually we are not that far from being able to do completely without
>> any GPIO number, and maybe that's what we should aim for. I think t
t node (GPIO controller
> +node).
> +- state: A property specifying the direction/value needed. This property
> + can take the folowing values: input, output-high, output-low.
s/folowing/following
This aside,
Reviewed-by: Alexandre Courbot
--
To unsubscribe fro
Looks ok to me. I have a few nits below, but otherwise I am happy with
how it turned out:
Reviewed-by: Alexandre Courbot
Thanks for your patience with this!
On Sat, Dec 13, 2014 at 7:07 AM, Benoit Parrot wrote:
> Based on Boris Brezillion's work this is a reworked patch
> of his i
Fix it by changing
> modules unit and reg base addresses to proper ones.
Checked with the TRM, you are absolutely correct.
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.
gt; the same Cygnus GPIO driver
No objections for this v6. The series,
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Dec 15, 2014 at 1:01 PM, Zhou Wang wrote:
> On 2014年12月10日 16:51, Alexandre Courbot wrote:
>>
>> On Fri, Dec 5, 2014 at 12:38 PM, Zhou Wang wrote:
>>>
>>> In function gpiochip_find_base, base number of a GPIO controller
>>> is found in decreas
On Tue, Dec 16, 2014 at 6:57 AM, Arnd Bergmann wrote:
> On Monday 15 December 2014 13:35:47 Ray Jui wrote:
>>
>> Like I said previously, dynamic GPIO allocation works fine in the
>> kernel, as long as all of our GPIO clients in the kernel use gpiod based
>> API, which is what we will enforce going
On Sat, Dec 13, 2014 at 12:28 AM, Arnd Bergmann wrote:
> On Friday 12 December 2014 22:05:37 Alexandre Courbot wrote:
>> On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann wrote:
>> > On Thursday 11 December 2014 16:05:04 Ray Jui wrote:
>> >> +
>> >> +- li
On Fri, Dec 12, 2014 at 9:08 PM, Arnd Bergmann wrote:
> On Thursday 11 December 2014 16:05:04 Ray Jui wrote:
>> +
>> +- linux,gpio-base:
>> +Base GPIO number of this controller
>> +
>>
>
> We've NAK'ed properties like this multiple times before, and it
> doesn't get any better this time. What
On Thu, Dec 11, 2014 at 8:48 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Wed [2014-Dec-10 20:19:51
> +0900]:
>> On Fri, Dec 5, 2014 at 6:02 AM, Benoit Parrot wrote:
>> > Based on Boris Brezillion's work this is a reworked patch
>> > of his initia
On Thu, Dec 11, 2014 at 7:50 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Wed [2014-Dec-10 19:56:17
> +0900]:
>> On Fri, Dec 5, 2014 at 6:02 AM, Benoit Parrot wrote:
>> > Add GPIO hogging documentation to gpio.txt
>> >
>> > Signed-off-by: Benoit
Hi Tomeu,
On Tue, Dec 9, 2014 at 10:15 PM, Tomeu Vizoso
wrote:
> The ACTMON block can monitor several counters, providing averaging and firing
> interrupts based on watermarking configuration. This implementation monitors
> the MCALL and MCCPU counters to choose an appropriate frequency for the
>
On Fri, Dec 5, 2014 at 6:02 AM, Benoit Parrot wrote:
> Based on Boris Brezillion's work this is a reworked patch
> of his initial GPIO hogging mechanism.
> This patch provides a way to initally configure specific GPIO
> when the gpio controller is probed.
>
> The actual DT scanning to collect the
On Fri, Dec 5, 2014 at 6:02 AM, Benoit Parrot wrote:
> Add GPIO hogging documentation to gpio.txt
>
> Signed-off-by: Benoit Parrot
> ---
> Changes since v2:
> * Updated to the latest hog syntax.
>
> Changes since v1:
> * Split the devicetree bindings documentation in its own patch.
>
> Documen
On Tue, Dec 9, 2014 at 5:41 AM, Ray Jui wrote:
> This GPIO driver supports all 3 GPIO controllers in the Broadcom Cygnus
> SoC. The 3 GPIO controllers are 1) the ASIU GPIO controller, 2) the
> chipCommonG GPIO controller, and 3) the ALWAYS-ON GPIO controller
>
> Signed-off-by: Ray Jui
> Reviewed-
On Fri, Dec 5, 2014 at 12:38 PM, Zhou Wang wrote:
> In function gpiochip_find_base, base number of a GPIO controller
> is found in decreasing order. ARCH_NR_GPIOS is used to define from
> which number we begin to search for base number of a GPIO controller.
>
> In fact, ARCH_NR_GPIOS brings us som
On Tue, Dec 9, 2014 at 11:14 PM, Tomeu Vizoso
wrote:
> On 12/09/2014 06:38 AM, Alexandre Courbot wrote:
>> On Fri, Dec 5, 2014 at 1:14 AM, Tomeu Vizoso
>> wrote:
>>> Hello,
>>>
>>> this v3 addresses the comments that the devfreq implementation got, na
On Fri, Dec 5, 2014 at 1:14 AM, Tomeu Vizoso wrote:
> Hello,
>
> this v3 addresses the comments that the devfreq implementation got, namely:
>
> * Address misc. style issues found by Thierry and Alexander
> * Added helpers for register i/o
> * Further documented the structs
> * Enable the ACTMON a
On Fri, Dec 5, 2014 at 1:14 AM, Tomeu Vizoso wrote:
> Add device node for the ACTMON block to the Tegra124 device tree.
>
> Signed-off-by: Tomeu Vizoso
>
> ---
>
> v3: * Address misc. style issues found by Thierry and Alexander
> * Added helpers for register i/o
> * Further do
On Fri, Dec 5, 2014 at 7:24 PM, Maxime Ripard
wrote:
> On Thu, Dec 04, 2014 at 11:49:19PM +0900, Alexandre Courbot wrote:
>> On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard
>> wrote:
>> > Hi,
>> >
>> > On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre C
On Fri, Dec 5, 2014 at 12:22 AM, Pantelis Antoniou
wrote:
> Hi Alexandre,
>
>> On Dec 4, 2014, at 17:10 , Alexandre Courbot wrote:
>>
>> On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou
>> wrote:
>>> Hi Alexandre,
>>>
>>>> On Dec 4,
On Fri, Dec 5, 2014 at 12:02 AM, Pantelis Antoniou
wrote:
> Hi Alexandre,
>
>> On Dec 4, 2014, at 16:58 , Alexandre Courbot wrote:
>>
>> On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou
>> wrote:
>>> Hi Alexandre,
>>>
>>>> On Dec 4,
On Thu, Dec 4, 2014 at 11:52 PM, Maxime Ripard
wrote:
> Hi again,
>
> It looks like I missed some part of it.
>
> On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote:
>> > GPIO hogging needs to be the ideal solution for that, since we can
>> > jus
On Thu, Dec 4, 2014 at 11:47 PM, Pantelis Antoniou
wrote:
> Hi Alexandre,
>
>> On Dec 4, 2014, at 16:41 , Alexandre Courbot wrote:
>>
>> On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou
>> wrote:
>>> Hi Alexandre,
>>>
>>> I
On Thu, Dec 4, 2014 at 11:27 PM, Maxime Ripard
wrote:
> Hi,
>
> On Thu, Dec 04, 2014 at 11:15:38PM +0900, Alexandre Courbot wrote:
>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
>> wrote:
>> > On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote:
>&g
On Thu, Dec 4, 2014 at 11:27 PM, Pantelis Antoniou
wrote:
> Hi Alexandre,
>
> I tried to stay away while things are being fleshed out but…
>
>> On Dec 4, 2014, at 16:15 , Alexandre Courbot wrote:
>>
>> On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
>> wrot
On Wed, Dec 3, 2014 at 1:12 AM, Maxime Ripard
wrote:
> On Tue, Dec 02, 2014 at 03:29:46PM +0100, Linus Walleij wrote:
>> On Tue, Dec 2, 2014 at 3:13 PM, Alexandre Courbot wrote:
>> > On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
>> > wrote:
>>
>> >>
On Tue, Dec 2, 2014 at 1:36 AM, Maxime Ripard
wrote:
> Hi,
>
> On Fri, Nov 28, 2014 at 04:30:01PM +0900, Alexandre Courbot wrote:
>> > +/**
>> > + * do_gpio_hog - Given node is a GPIO hog configuration, handle it
>> > + * @np:device node to get
On Tue, Dec 2, 2014 at 9:22 AM, Benoit Parrot wrote:
>> > + }
>> > +
>> > + if (tmp > MAX_PHANDLE_ARGS) {
>> > + desc = ERR_PTR(-EINVAL);
>> > + goto out;
>> > + }
>> > +
>> > + gg_data.gpiospec.args_count = tmp;
>> > + gg_data.gpiospec.np
On Tue, Dec 2, 2014 at 7:57 AM, Benoit Parrot wrote:
> Alexandre Courbot wrote on Fri [2014-Nov-28 16:31:19
> +0900]:
>> On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
>> > Add GPIO hogging documentation to gpio.txt
>> >
>> > Signed-off-by: Benoit
On Sat, Nov 29, 2014 at 6:16 AM, Arnd Bergmann wrote:
> On Friday 28 November 2014 16:54:44 Linus Walleij wrote:
>> On Fri, Nov 28, 2014 at 10:33 AM, Arnd Bergmann wrote:
>> > On Friday 28 November 2014 14:29:47 Zhou Wang wrote:
>>
>> >> Set ARCH_NR_GPIO for Hisilicon Soc Hip04, which has 4 GPIO
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
> Add GPIO hogging documentation to gpio.txt
>
> Signed-off-by: Benoit Parrot
> ---
> Changes since v1:
> * Split the devicetree bindings documentation in its own patch.
>
> Documentation/devicetree/bindings/gpio/gpio.txt | 25
> +++
On Fri, Nov 21, 2014 at 8:54 AM, Benoit Parrot wrote:
> Based on Boris Brezillion's work this is a reworked patch
> of his initial GPIO hogging mechanism.
> This patch provides a way to initally configure specific GPIO
> when the gpio controller is probed.
>
> The actual DT scanning to collect the
On Thu, Nov 20, 2014 at 9:37 PM, Vincent Yang
wrote:
> Driver for Fujitsu MB86S7x SoCs that have a memory mapped GPIO controller.
>
> Signed-off-by: Andy Green
> Signed-off-by: Jassi Brar
> Signed-off-by: Vincent Yang
> Signed-off-by: Tetsuya Nuriya
> ---
> .../bindings/gpio/fujitsu,mb86s70-g
On Mon, Nov 24, 2014 at 9:28 PM, Tomeu Vizoso
wrote:
> The ACTMON block can monitor several counters, providing averaging and firing
> interrupts based on watermarking configuration. This implementation monitors
> the MCALL and MCCPU counters to choose an appropriate frequency for the
> external m
rs to fit the new
> API design. No functional change is introduced in this patch.
A good idea even if no ops were to be added!
Reviewed-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@v
On Mon, Nov 17, 2014 at 11:30 PM, Geert Uytterhoeven
wrote:
> Use dynamic allocation of GPIOs instead of looking at the gpio%u alias
> in DT.
> ---
> - Is this correct? Not having to care about the alias would simplify the
> to-be-written DT binding documentation.
> - Completely untested.
On Fri, Nov 14, 2014 at 5:58 PM, Linus Walleij wrote:
> On Mon, Nov 3, 2014 at 11:56 PM, Rafael J. Wysocki wrote:
>> On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote:
>
>>> With that change:
>>> Reviewed-by: Linus Walleij
>>
>> OK, made the changes and added your Reviewed-by.
>>
>> O
his mean this device was never probed because the driver
did not recognize its compatible property? I cannot find "ak,ak8975"
anywhere else in the kernel.
If so,
Acked-by: Alexandre Courbot
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/11/2014 03:57 PM, Terje Bergström wrote:
On 11.11.2014 06:29, Alexandre Courbot wrote:
I think (after a quick look at devfreq's source) that you can avoid
polling altogether if you set polling_ms to 0 in your
devfreq_dev_profile instance. Then it is up to you to call
update_devfreq()
On 11/07/2014 09:35 PM, Tomeu Vizoso wrote:
On 11/07/2014 10:07 AM, Alexandre Courbot wrote:
On 10/29/2014 11:50 PM, Tomeu Vizoso wrote:
Hello,
these patches implement support for setting the rate of the EMC clock based on
stats collected from the ACTMON, a piece of hw in the Tegra124 that
On 10/29/2014 11:50 PM, Tomeu Vizoso wrote:
Hello,
these patches implement support for setting the rate of the EMC clock based on
stats collected from the ACTMON, a piece of hw in the Tegra124 that counts
memory accesses (among others).
It depends on the following in-flight patches:
* MC drive
On 11/07/2014 12:12 AM, Rob Herring wrote:
On Thu, Nov 6, 2014 at 12:37 AM, Alexandre Courbot wrote:
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
The EMC clock needs some extra information for changing its rate.
Signed-off-by: Tomeu Vizoso
---
.../bindings/clock/nvidia,tegra124-car.txt
On 11/06/2014 06:11 PM, Tomeu Vizoso wrote:
On 6 November 2014 07:37, Alexandre Courbot wrote:
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
The EMC clock needs some extra information for changing its rate.
Signed-off-by: Tomeu Vizoso
---
.../bindings/clock/nvidia,tegra124-car.txt
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
The MC driver needs some timing-specific information to program the EMEM during
a rate change of the EMC clock.
Signed-off-by: Tomeu Vizoso
---
.../memory-controllers/nvidia,tegra-mc.txt | 46 +-
1 file changed, 44 inser
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
From: Mikko Perttunen
Implements functionality needed to change the rate of the memory bus clock.
Signed-off-by: Mikko Perttunen
Signed-off-by: Tomeu Vizoso
---
v2: * Use subsys_initcall(), so it gets probed after the MC driver and
On 10/30/2014 01:22 AM, Tomeu Vizoso wrote:
The EMC clock needs some extra information for changing its rate.
Signed-off-by: Tomeu Vizoso
---
.../bindings/clock/nvidia,tegra124-car.txt | 46 +-
1 file changed, 44 insertions(+), 2 deletions(-)
diff --git a/Documen
On Fri, Oct 31, 2014 at 4:51 PM, Krzysztof Kozlowski
wrote:
> On pią, 2014-10-31 at 12:31 +0900, Alexandre Courbot wrote:
>> On Fri, Oct 31, 2014 at 12:03 AM, Krzysztof Kozlowski
>> wrote:
>> > On czw, 2014-10-30 at 22:56 +0900, Alexandre Courbot wrote:
>> >&
On Fri, Oct 31, 2014 at 12:03 AM, Krzysztof Kozlowski
wrote:
> On czw, 2014-10-30 at 22:56 +0900, Alexandre Courbot wrote:
>> Hi, and thanks for bringing this issue to us!
>>
>> On Wed, Oct 29, 2014 at 7:49 PM, Javier Martinez Canillas
>> wrote:
>> > [addin
Hi, and thanks for bringing this issue to us!
On Wed, Oct 29, 2014 at 7:49 PM, Javier Martinez Canillas
wrote:
> [adding Linus and Alexandre to the cc list]
>
> Hello Krzysztof,
>
> On 10/29/2014 11:42 AM, Krzysztof Kozlowski wrote:
>> On wto, 2014-10-28 at 13:11 +0100, Krzysztof Kozlowski wrote:
On Thu, Oct 30, 2014 at 1:42 AM, Pantelis Antoniou
wrote:
> Hi Benoit,
>
>> On Oct 29, 2014, at 18:34 , Benoit Parrot wrote:
>>
>> Pantelis,
>>
>> Thanks for the feedback.
>>
>> Pantelis Antoniou wrote on Wed [2014-Oct-29
>> 10:53:44 +0200]:
>>> Hi Benoit,
>>>
On Oct 21, 2014, at 23:09 , B
On Thu, Oct 30, 2014 at 1:21 AM, Benoit Parrot wrote:
>> > +
>> > if (status)
>> > goto fail;
>> >
>> > @@ -1742,6 +1757,72 @@ struct gpio_desc *__must_check
>> > __gpiod_get_index_optional(struct device *dev,
>> > EXPORT_SYMBOL_GPL(__gpiod_get_index_optional);
>> >
>> >
purpose, a case that should remain exceptional (e.g. bit-banged
data lines).
Signed-off-by: Alexandre Courbot
CC: Linus Walleij
CC: Arnd Bergmann
CC: Rafael J. Wysocki
CC: Mika Westerberg
---
Changes since v1:
- Rewritten in OS-neutral manner.
Documentation/devicetree/binding
Sorry for the delay in reviewing. Adding Jiri and Pantelis who might
want to extend over this patch and thus will likely have interesting
comments to make.
On Wed, Oct 22, 2014 at 5:09 AM, Benoit Parrot wrote:
> Based on Boris Brezillion work this is a reworked patch
> of his initial GPIO hogging
On Wed, Oct 29, 2014 at 7:27 AM, Andrew Bresticker
wrote:
> This series adds support for xHCI on NVIDIA Tegra SoCs. This includes:
> - patches 1 and 2: adding a driver for the mailbox used to communicate
>with the xHCI controller's firmware,
> - patches 3 and 4: extending the XUSB pad contr
On Tue, Oct 28, 2014 at 6:08 PM, Arnd Bergmann wrote:
> On Tuesday 28 October 2014 13:20:34 Alexandre Courbot wrote:
>> +GPIO properties should be named "[-]gpios", with being the
>> con_id
>> +argument that is passed to gpiod_get(). While a NULL con_id is accep
On Tue, Oct 28, 2014 at 1:42 AM, Felipe Balbi wrote:
> On Mon, Oct 27, 2014 at 04:26:52PM +, Romain Perier wrote:
>> Signed-off-by: Romain Perier
>> ---
>> arch/arm/boot/dts/tegra30-apalis.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/tegr
purpose, a case that should remain exceptional (e.g. bit-banged
data lines).
Signed-off-by: Alexandre Courbot
CC: Linus Walleij
CC: Arnd Bergmann
CC: Rafael J. Wysocki
CC: Mika Westerberg
---
Documentation/devicetree/bindings/gpio/gpio.txt | 41 +
1 file changed,
On Tue, Oct 28, 2014 at 7:34 AM, Rafael J. Wysocki wrote:
> On Monday, October 27, 2014 02:21:23 PM Alexandre Courbot wrote:
>> On Sat, Oct 25, 2014 at 7:05 AM, Rafael J. Wysocki
>> wrote:
>> > From: Rafael J. Wysocki
>> >
>> > Provide a way for de
thrown a BUG() in this situation, if it
> happens here, it means mvchip->soc_variant has been corrupted, and so
> bad things are happening. So a BUG() is maybe called for?
I agree that BUG() is adequate here. probe() should recognize the
exact same set of chips - if we reach this poin
ect referred to by the
> GPIO mapping. That should be done in the driver's .probe() routine.
>
> On removal, the driver should unregister its GPIO mapping table
> by calling acpi_dev_remove_driver_gpios() on the ACPI device
> object where that table was previously registe
On Fri, Oct 24, 2014 at 6:51 AM, Rafael J. Wysocki wrote:
> On Thursday, October 23, 2014 03:56:55 PM Mika Westerberg wrote:
>> On Thu, Oct 23, 2014 at 01:21:06AM +0200, Rafael J. Wysocki wrote:
>> > OK, would the below make sense, then (completely untested, on top of the v6
>> > of the device pro
Added the DT maintainers and fixed the DT mailing-list's address so
this discussion becomes visible to them as well.
On Thu, Oct 23, 2014 at 8:23 PM, Pantelis Antoniou
wrote:
> Hi Alexandre,
>
>> On Oct 23, 2014, at 11:53 AM, Alexandre Courbot wrote:
>>
>> On Thu,
1 - 100 of 196 matches
Mail list logo
