On Tuesday, December 29, 2015 09:20:54 AM Viresh Kumar wrote:
> On 28-12-15, 21:06, Pi-Cheng Chen wrote:
> > Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
> > share the same OPP table. This might be helpful when handling cpumask
> > without the original CPU bitfield set.
>
On Friday, December 11, 2015 07:05:32 AM Lee Jones wrote:
> On Fri, 11 Dec 2015, Viresh Kumar wrote:
> > On 10-12-15, 22:38, Rafael J. Wysocki wrote:
> > > Do they depend on anything special?
> >
> > My opp-binding-parsing patches which you applied to bleeding-
On Thursday, November 26, 2015 05:21:11 PM Jia Hongtao wrote:
> Register the qoriq cpufreq driver as a cooling device, based on the
> thermal device tree framework. When temperature crosses the passive trip
> point cpufreq is used to throttle CPUs.
>
> Signed-off-by: Jia Hongtao
> Reviewed-by: Vi
On Wednesday, November 18, 2015 07:34:39 PM Viresh Kumar wrote:
> On 18-11-15, 13:33, Punit Agrawal wrote:
> > Thanks for the Ack.
> >
> > Will you or Rafael be picking up the series or do they need to go via
> > arm-soc?
>
> Rafael will pick this up, it should go via PM tree.
Applied now, thank
On Thursday, December 10, 2015 09:42:15 AM Lee Jones wrote:
> Hi Rafael,
>
> Would you be kind enough to pick these 2 patches up please.
> The have the required Acks.
I can do that.
Do they depend on anything special?
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe
On Tuesday, November 24, 2015 12:04:00 AM Rafael J. Wysocki wrote:
> On Wednesday, November 11, 2015 08:10:58 AM Viresh Kumar wrote:
> > OPP bindings got updated to name OPP nodes this way, make changes
> > according to that.
> >
> > Reviewed-by: Krzysztof Kozlowski
On Wednesday, November 11, 2015 08:10:58 AM Viresh Kumar wrote:
> OPP bindings got updated to name OPP nodes this way, make changes
> according to that.
>
> Reviewed-by: Krzysztof Kozlowski
> Signed-off-by: Viresh Kumar
> ---
> arch/arm/boot/dts/exynos4412.dtsi | 28 ++--
On Wednesday, November 11, 2015 08:10:53 AM Viresh Kumar wrote:
> Hi Rafael,
>
> Rob only needs to Ack the modified 2/5 patch and then you can safely
> apply this series.
>
> The first patch enables us to select only a subset of OPPs from the
> bigger table, based on what version of the hardware
Hi,
On Thu, Nov 19, 2015 at 7:24 PM, Dmitry Torokhov
wrote:
> On Thu, Nov 19, 2015 at 02:26:37PM +0200, Irina Tirdea wrote:
>> Implement suspend/resume for goodix driver.
>>
[cut]
>>
>> +static int __maybe_unused goodix_suspend(struct device *dev)
>> +{
>> + struct i2c_client *client = to_i
On Thursday, November 05, 2015 07:11:51 AM Viresh Kumar wrote:
> Hi Rafael,
>
> All the bindings are Reviewed by Stephen now and Rob didn't had a
> problem with them (though he didn't Ack them separately yet) :)
>
> The first patch enables us to select only a subset of OPPs from the
> bigger tabl
On Tuesday, October 27, 2015 03:48:40 PM Tomeu Vizoso wrote:
> On 24 October 2015 at 15:57, Rafael J. Wysocki wrote:
[...]
> >
> > Well, once that has happened, your new device pointer in the given
> > device_node
> > becomes useless. Why exactly is that fine?
On Tuesday, October 20, 2015 12:04:05 PM Alan Stern wrote:
> On Tue, 20 Oct 2015, Mark Brown wrote:
>
> > On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >
> > > Furthermore, that applies only to devices that use synchronous suspend.
> > > Async suspend is becoming common, and the
On Mon, Oct 26, 2015 at 11:51 AM, Michael Turquette
wrote:
> Quoting Rafael J. Wysocki (2015-10-25 06:54:39)
>> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote:
>> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>> >
>> >> Well, I&#
On Mon, Oct 26, 2015 at 1:13 AM, Mark Brown wrote:
> On Sat, Oct 24, 2015 at 03:09:06PM -0500, Rob Herring wrote:
>
>> Let's get agreement on the flow and structure and how to address other
>> issues like suspend, then we can worry about whether this needs to be
>> abstracted from subsystems. We c
On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown wrote:
> On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote:
>
>> Well, I'm not quite sure why exactly everyone is so focused on probing here.
>
> Probe deferral is really noisy even if it's working fine
On Friday, October 23, 2015 08:54:19 AM Mark Brown wrote:
>
> --7cm2iqirTL37Ot+N
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Oct 22, 2015 at 03:03:37PM +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 03:06, Rafael J. Wysoc
On Friday, October 23, 2015 11:34:34 AM Rob Herring wrote:
> On Fri, Oct 23, 2015 at 10:45 AM, Tim Bird wrote:
> > On 10/22/2015 11:53 AM, Frank Rowand wrote:
> >> On 10/22/2015 7:44 AM, Greg Kroah-Hartman wrote:
> >>>
> >>>
> >>> On Thu, Oct 22, 2015 at 11:05:11AM +0200, Tomeu Vizoso wrote:
> >>
On Thursday, October 22, 2015 03:01:45 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:02, Rafael J. Wysocki wrote:
> > On Monday, September 21, 2015 04:02:43 PM Tomeu Vizoso wrote:
> >> When adding platform and AMBA devices, set the device node's device
>
On Thursday, October 22, 2015 03:03:37 PM Tomeu Vizoso wrote:
> On 22 October 2015 at 03:06, Rafael J. Wysocki wrote:
> > On Monday, September 21, 2015 04:02:44 PM Tomeu Vizoso wrote:
> >> Walks the OF tree up and finds the closest ancestor that has a struct
> >>
On Thursday, October 22, 2015 04:27:10 PM Scott Wood wrote:
> On Thu, 2015-10-22 at 15:04 +0200, Tomeu Vizoso wrote:
> > On 22 October 2015 at 00:51, Scott Wood wrote:
> > > On Wed, 2015-10-21 at 08:44 -0500, Rob Herring wrote:
> > > > On Wed, Oct 21, 2015 at 12:54 AM, Scott Wood
> > > > wrote:
>
nt_env
> *env);
> extern int of_device_uevent_modalias(struct device *dev, struct
> kobj_uevent_env *env);
> +extern void of_device_probe(struct device_node *np);
>
> static inline void of_device_node_put(struct device *dev)
> {
> @@ -84,6 +85,8 @@ static inline int of_device_uevent_
On Monday, September 21, 2015 04:02:43 PM Tomeu Vizoso wrote:
> When adding platform and AMBA devices, set the device node's device
> member to point to it.
>
> This speeds lookups considerably and is safe because we only create one
> of these devices for any given device node.
>
> Signed-off-by:
On Monday, September 21, 2015 04:02:41 PM Tomeu Vizoso wrote:
> Lets implementations of the match() callback in struct bus_type to
> return errors and if it's -EPROBE_DEFER then queue the device for
> deferred probing.
>
> This is useful to buses such as AMBA in which devices are registered
> befo
On Tuesday, October 20, 2015 06:21:55 PM Tomeu Vizoso wrote:
> On 20 October 2015 at 18:04, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Mark Brown wrote:
> >
> >> On Tue, Oct 20, 2015 at 10:40:03AM -0400, Alan Stern wrote:
> >>
> >> > Furthermore, that applies only to devices that use synchronous s
On Wednesday, October 21, 2015 10:55:14 AM Geert Uytterhoeven wrote:
> Hi Rafael,
>
> On Wed, Oct 21, 2015 at 1:34 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> >> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki
>
On Tuesday, October 20, 2015 08:35:28 PM Mark Brown wrote:
>
> --7fVr/IRGAG9sAW4J
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> > On Tue, 20 Oct 2015, Tomeu
On Tuesday, October 20, 2015 09:15:01 AM Rob Herring wrote:
> On Tue, Oct 20, 2015 at 2:56 AM, Rafael J. Wysocki wrote:
> > On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki
> >> wrote:
> >> &g
On Monday, October 19, 2015 05:58:40 PM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 4:40 PM, Rafael J. Wysocki wrote:
> > On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> >> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse
> >> wrote:
> >> >
On Monday, October 19, 2015 10:58:25 AM Rob Herring wrote:
> On Mon, Oct 19, 2015 at 10:29 AM, David Woodhouse wrote:
> > On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> >> > But the point I'm making is that we are working towards *fixing* that,
> >> > and *not* using DT-specific code in pl
o MTK tree, it doesn't have any dependency on
> > rest of the patches for build/boot. The only thing is that cpufreq
> > wouldn't work and it will work as soon as Rafael's and MTK's trees are
> > merged by Linus.
>
> Thanks for your explanation.
&
On 8/25/2015 11:37 AM, Jon Hunter wrote:
On 25/08/15 01:04, Rafael J. Wysocki wrote:
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote:
On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote:
On 24/08/15 10:22, Vinod Koul wrote:
On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter
On Tuesday, August 25, 2015 10:10:44 AM Pi-Cheng Chen wrote:
> On Mon, Aug 17, 2015 at 5:24 PM, Pi-Cheng Chen
> wrote:
> > MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster
> > share the same power and clock domain. This series tries to add cpufreq
> > support
> > for MT8
On Monday, August 24, 2015 07:51:43 PM Vinod Koul wrote:
> On Mon, Aug 24, 2015 at 02:22:49PM +0100, Jon Hunter wrote:
> >
> > On 24/08/15 10:22, Vinod Koul wrote:
> > > On Mon, Aug 24, 2015 at 09:47:13AM +0100, Jon Hunter wrote:
> > >>
> > >> On 23/08/15 15:17, Vinod Koul wrote:
> > >>> On Tue, A
Hi David,
On Sat, Aug 8, 2015 at 2:11 AM, David Daney wrote:
> On 08/07/2015 05:05 PM, Rafael J. Wysocki wrote:
[cut]
>>
>> It is actually useful to people as far as I can say.
>>
>> Also, if somebody is going to use properties with ACPI, why whould
>> they
On Tuesday, July 28, 2015 03:19:31 PM Tomeu Vizoso wrote:
> Hello,
>
> I have a problem with the panel on my Tegra Chromebook taking longer
> than expected to be ready during boot (Stéphane Marchesin reported what
> is basically the same issue in [0]), and have looked into ordered
> probing as a b
Hi Mark,
On Thu, Jul 16, 2015 at 10:23 PM, Mark Brown wrote:
> On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote:
>
>> Delay matches of platform devices until late_initcall, when we are sure
>> that all built-in drivers have been registered already. This is needed
>> to prevent deferre
On Friday, July 10, 2015 03:14:38 PM Tomeu Vizoso wrote:
> On 2 July 2015 at 02:02, Rafael J. Wysocki wrote:
> > On Wednesday, July 01, 2015 11:40:57 AM Tomeu Vizoso wrote:
> >> Adds API that allows callers to find out what other firmware nodes a
> >> node depends on
river_match_device(struct device *dev,
> const struct device_driver *drv);
>
> +void fwnode_add_dependency(struct fwnode_handle *fwnode,
> +struct list_head *list);
> +
> +void fwnode_add_dependency_parser(
> + void (*func)(struct fwnode
rent ? : &platform_bus;
>
> if (bus_id)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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
ce *dev,
> return false;
> }
> EXPORT_SYMBOL_GPL(fwnode_driver_match_device);
> +
> +static int __device_attach(struct device *dev, void *data)
> +{
> + device_initial_probe(dev);
> +
> + return 0;
> +}
> +
> +static int fwnode_match_initcall(void)
On Tuesday, June 30, 2015 04:54:58 PM Tomeu Vizoso wrote:
> Hi,
>
> this series makes it possible to extract device dependencies from firmware
> data
> with fwnode, thus not depending on the particular format of that data.
>
> The first patches are about making sure that we can reach the fwnode
On Tuesday, June 23, 2015 01:45:00 AM Rafael J. Wysocki wrote:
> On Monday, June 22, 2015 10:38:53 PM Alexander Sverdlin wrote:
> > Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
> > but there were already ~63 of_node local variables or function par
On Monday, June 22, 2015 10:38:53 PM Alexander Sverdlin wrote:
> Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
> but there were already ~63 of_node local variables or function parameters
> (no single acpi_node though, but anyway).
>
> After debugging undefined but us
On Wed, Jun 17, 2015 at 4:38 AM, Viresh Kumar wrote:
> On 16-06-15, 23:21, Rafael J. Wysocki wrote:
>> Does your ACK also apply to patches [1-2/3] in this series?
>
> His RBY tag is already present for 1/3 :)
Yes, it is, sorry for overlooking that.
--
To unsubscribe from this list
On Tuesday, June 16, 2015 02:23:23 PM Rob Herring wrote:
> On Mon, Jun 15, 2015 at 9:54 PM, Viresh Kumar wrote:
> > On 16-06-15, 06:01, Viresh Kumar wrote:
> >> On 16 June 2015 at 05:05, Rob Herring wrote:
> >> >> +- opp-suspend: Phandle of the OPP to set while device is suspended.
> >> >> +
> >>
9 +328,10 @@ DVFS state together.
>
> cluster1_opp: opp_table1 {
> compatible = "operating-points-v2";
> + opp-suspend = <&suspend_opp1>;
> opp-shared;
>
> - opp10 {
> + suspend_opp: opp10 {
> opp-hz = <13>;
> opp-microvolt = <1045000 105 1055000>;
> opp-microamp = <95000>;
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
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
From: Rafael J. Wysocki
Now that the ACPI companions of devices are pointed to by the fwnode
field in struct device, the device_property_*() accessor functions
can be modified to use their fwnode_property_*() counterparts
internally with minimum extra overhead in the IS_ENABLED(CONFIG_OF)
case
On Friday, March 20, 2015 12:16:59 PM Russell King - ARM Linux wrote:
> On Thu, Mar 19, 2015 at 11:02:35PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, March 19, 2015 10:59:20 PM Rafael J. Wysocki wrote:
> > > On Thursday, March 12, 2015 06:30:21 PM Russell King - ARM Linux w
On Thursday, March 19, 2015 10:59:20 PM Rafael J. Wysocki wrote:
> On Thursday, March 12, 2015 06:30:21 PM Russell King - ARM Linux wrote:
> > This is a re-posting of the patch set which I posted almost 10 months
> > ago to support the Dove PMU, with a few additional changes.
On Thursday, March 12, 2015 06:30:21 PM Russell King - ARM Linux wrote:
> This is a re-posting of the patch set which I posted almost 10 months
> ago to support the Dove PMU, with a few additional changes. This set
> is based upon 3.19.
>
> In this set are:
>
> * two patches which Rafael origina
On Friday, February 20, 2015 10:31:44 AM Mark Rutland wrote:
> [...]
[cut]
> Given all of the above I'll go back to the IRQF_SHARED_TIMER_OK approach
> you proposed, along with documentation updates and comments at usage
> sites to make it clear when it is valid to use.
>
> Thank you for bearin
On Thursday, February 19, 2015 11:23:46 AM Mark Rutland wrote:
> On Thu, Feb 19, 2015 at 01:16:50AM +0000, Rafael J. Wysocki wrote:
> > On Monday, February 16, 2015 12:23:43 PM Mark Rutland wrote:
> > > [...]
> > >
> > > > > The "suspend" pa
nable,disable}_irq_wake.
>
> However, we'd then need to handle mismatch with wakeup interrupts (which
> is effectively the same problem as sharing with a timer).
IRQF_NO_SUSPEND and wakeup fundamentally don't match due to the way
wakeup is implemented in the IRQ core now.
Unless
On Wednesday, February 11, 2015 05:15:15 PM Boris Brezillon wrote:
> On Wed, 11 Feb 2015 15:57:20 +
> Mark Rutland wrote:
>
> > [...]
> >
> > > > > > So for the flag at request time approach to work, all the drivers
> > > > > > using
> > > > > > the interrupt would have to flag they're safe
On Wednesday, February 11, 2015 03:12:38 PM Mark Rutland wrote:
> On Wed, Feb 11, 2015 at 03:17:20PM +0000, Rafael J. Wysocki wrote:
> > On Wednesday, February 11, 2015 02:43:45 PM Mark Rutland wrote:
> > > [...]
> > >
> > > > > > > > +static irq
On Wednesday, February 11, 2015 04:03:17 PM Boris Brezillon wrote:
> On Wed, 11 Feb 2015 16:17:20 +0100
> "Rafael J. Wysocki" wrote:
>
> > On Wednesday, February 11, 2015 02:43:45 PM Mark Rutland wrote:
> > > [...]
> > >
> > > > > > &
On Wednesday, February 11, 2015 02:43:45 PM Mark Rutland wrote:
> [...]
>
> > > > > > +static irqreturn_t __handle_irq_event_percpu(unsigned int irq,
> > > > > > struct irqaction *action)
> > > > > > +{
> > > > > > + /*
> > > > > > +* During suspend we must not call potentially unsafe irq
On Wednesday, February 11, 2015 02:14:37 PM Mark Rutland wrote:
> On Wed, Feb 11, 2015 at 02:31:18PM +0000, Rafael J. Wysocki wrote:
> > On Wednesday, February 11, 2015 11:15:17 AM Mark Rutland wrote:
> > > On Wed, Feb 11, 2015 at 09:11:59AM +, Peter Zijlstra wrote:
>
On Wednesday, February 11, 2015 01:24:37 PM Boris Brezillon wrote:
> Hi Mark,
>
> On Wed, 11 Feb 2015 11:11:06 +
> Mark Rutland wrote:
>
> > On Wed, Feb 11, 2015 at 08:53:39AM +, Boris Brezillon wrote:
> > > Hi Mark,
> > >
> > > On Tue, 10 Feb 2015 20:48:36 +
> > > Mark Rutland wro
On Wednesday, February 11, 2015 11:11:06 AM Mark Rutland wrote:
> On Wed, Feb 11, 2015 at 08:53:39AM +, Boris Brezillon wrote:
> > Hi Mark,
> >
> > On Tue, 10 Feb 2015 20:48:36 +
> > Mark Rutland wrote:
> >
> > > On Tue, Feb 10, 2015 at 03:52:01PM +, Boris Brezillon wrote:
> > > > Hi
which we expect interrupts during suspend (e.g. timers) and those we do
> not (e.g. anything we cut the power to). Where a driver did not request
> the interrupt with IRQF_NO_SUSPEND, it's unlikely that it can handle
> being called during suspend, and it may bring down the system.
&
spend, only the handlers requested with IRQF_NO_SUSPEND will be
> > > called. The handlers requested without IRQF_NO_SUSPEND will be skipped
> > > as if they had immediately returned IRQF_NONE.
> > >
> > > Cc: Boris Brezillon
> > > Cc: Jason Cooper
o do the lookup again for themselves... and in that case
> should we make of_match_id() available or produce a new
> device_match_id() that they are expected to switch to?
So far we've been targeting drivers that already have of_match_id() rather
than ones that want to use the
On Friday, December 12, 2014 03:42:07 PM Rafael J. Wysocki wrote:
> On Thursday, December 11, 2014 07:59:20 PM Linus Torvalds wrote:
> > On Mon, Dec 8, 2014 at 4:21 PM, Rafael J. Wysocki wrote:
> > >
> > > Also the ACPI core is now going to support the _DEP configura
On Thursday, December 11, 2014 07:59:20 PM Linus Torvalds wrote:
> On Mon, Dec 8, 2014 at 4:21 PM, Rafael J. Wysocki wrote:
> >
> > Also the ACPI core is now going to support the _DEP configuration
> > information in a limited way.
>
> Hmm. That seems to be the cause o
ubsystem
is additionally modified to allow device drivers to assign names
to GPIO resources returned by ACPI _CRS objects (in case _DSD is
not present or does not provide the expected data). The changes
in this set are mostly from Mika Westerberg, Rafael J Wysocki,
Aaron Lu, and D
On Monday, November 17, 2014 01:28:54 PM Alexandre Courbot wrote:
> 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:
more generic
> PM / clock_ops: add and enable clocks always if !CONFIG_PM_RUNTIME
>
> drivers/base/power/clock_ops.c | 89
> +++++++++++---
> include/linux/pm_clock.h | 8
> 2 files changed, 65 insertions(+), 32 deletions(-)
Patches [1-2
On Friday, November 14, 2014 09:58:41 AM 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
> >
>
On Tuesday, November 04, 2014 05:01:04 PM Grant Likely wrote:
> On Mon, Nov 3, 2014 at 10:04 PM, Rafael J. Wysocki wrote:
> >> I also found that this parser code doesn't correctly handle malformed
> >> (unterminated) string properties. It will overflow. The existing
&g
From: Rafael J. Wysocki
Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).
The following
From: "Rafael J. Wysocki"
Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type. The purpose of it is to help to
write portable code that won't depend on any part
On Tuesday, November 04, 2014 03:49:50 PM Grant Likely wrote:
> On Sat, 25 Oct 2014 00:10:20 +0200
> , "Rafael J. Wysocki"
> wrote:
> > On Tuesday, October 21, 2014 11:08:59 PM Rafael J. Wysocki wrote:
> > > Hi Everyone,
> > >
> > > This is
On Tuesday, November 04, 2014 03:51:12 PM Grant Likely wrote:
> On Tue, 21 Oct 2014 23:15:50 +0200
> , "Rafael J. Wysocki"
> wrote:
> > From: "Rafael J. Wysocki"
> >
> > Add a uniform interface by which device drivers can request device
> >
On Tuesday, November 04, 2014 03:04:54 PM Grant Likely wrote:
> On Tue, Nov 4, 2014 at 2:38 PM, Mika Westerberg
> wrote:
> > On Tue, Nov 04, 2014 at 02:18:26PM +, Grant Likely wrote:
> >> > - strncpy(chip->name, np->name, sizeof(chip->name));
> >> > + strncpy(chip->name, "at25", sizeof(chi
On Monday, November 03, 2014 11:38:24 PM Grant Likely wrote:
[cut]
> diff --git a/include/linux/of.h b/include/linux/of.h
> index 6545e7aec7bb..3b3c6e849ae8 100644
> --- a/include/linux/of.h
> +++ b/include/linux/of.h
> @@ -267,14 +267,12 @@ extern int of_property_read_u64(const struct
> device_
On Monday, November 03, 2014 02:22:10 PM Linus Walleij wrote:
> On Sat, Oct 25, 2014 at 12:05 AM, Rafael J. Wysocki
> wrote:
>
> > From: Rafael J. Wysocki
> >
> > Provide a way for device drivers using GPIOs described by ACPI
> > GpioIo resources in _CRS to t
It will either need to be respun, or we'll need
> to give Linus some guidance on resolving the conflicts when merging.
Respin might be better, we still have a number of -rcs before final 3.18.
> Other comments below...
>
> On Tue, Oct 21, 2014 at 10:15 PM, Rafael J. Wysocki
&g
On Saturday, November 01, 2014 05:13:45 AM Rob Herring wrote:
> On Fri, Oct 31, 2014 at 6:59 AM, Gilad Avidov wrote:
> >
> > Device-Tree compact API
> >
> >
> > Common code seen in driver’s probe reads device tree values and handling
> > erroneous return codes from all tho
On Tuesday, October 28, 2014 01:11:50 PM Alexandre Courbot wrote:
> 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:
[cut]
> > Yes, I'm going to provide documentation.
> >
> > One
On Tuesday, October 28, 2014 04:26:25 PM Linus Walleij wrote:
> On Fri, Oct 17, 2014 at 2:11 PM, Rafael J. Wysocki wrote:
>
> > From: Mika Westerberg
> >
> > GPIO descriptors are the preferred way over legacy GPIO numbers
> > nowadays. Convert the driver to use G
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 device drivers using GPIOs described by ACPI
> > GpioIo resources in _CRS to tell th
On Tuesday, October 21, 2014 11:08:59 PM Rafael J. Wysocki wrote:
> Hi Everyone,
>
> This is version 6 of the unified device properties interface patchset.
>
> The original cover letter from Mika is here:
>
> http://marc.info/?l=devicetree&m=141087052200600&w=4
From: Rafael J. Wysocki
Provide a way for device drivers using GPIOs described by ACPI
GpioIo resources in _CRS to tell the GPIO subsystem what names
(connection IDs) to associate with specific GPIO pins defined
in there.
To do that, a driver needs to define a mapping table as a
NULL-terminated
On Friday, October 24, 2014 10:34:36 AM Mika Westerberg wrote:
> On Thu, Oct 23, 2014 at 11:51:59PM +0200, Rafael J. Wysocki wrote:
> > OK, let's try to take that a bit farther. :-)
> >
> > With the (untested) patch below applied (which is a replacement for the one
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 properties patchset)?
>
> Yes it does :-)
&g
On Wednesday, October 22, 2014 05:56:51 PM Mika Westerberg wrote:
> On Wed, Oct 22, 2014 at 04:07:08PM +0200, Rafael J. Wysocki wrote:
> > Moreover, we need to clarify what situation we're really talking about.
> >
> > For one, drivers using the unified interface only
On Wednesday, October 22, 2014 11:28:40 AM Arnd Bergmann wrote:
> On Wednesday 22 October 2014 11:51:40 Mika Westerberg wrote:
> > On Wed, Oct 22, 2014 at 10:33:32AM +0200, Arnd Bergmann wrote:
> > > On Wednesday 22 October 2014 11:10:44 Mika Westerberg wrote:
> > > >
> > > > It expects that GPIOs
Acked-by: Alexandre Courbot
Reviewed-by: Linus Walleij
Acked-by: Dmitry Torokhov
Signed-off-by: Rafael J. Wysocki
---
drivers/input/keyboard/gpio_keys_polled.c | 39 +--
include/linux/gpio_keys.h | 3 +++
2 files changed, 30 insertions(+), 12
Courbot
Acked-by: Bryan Wu
Signed-off-by: Rafael J. Wysocki
---
drivers/leds/leds-gpio.c | 80 ++-
include/linux/leds.h |1
2 files changed, 46 insertions(+), 35 deletions(-)
Index: linux-pm/drivers/leds/leds-gpio.c
From: Rafael J. Wysocki
Add new generic routines are provided for retrieving properties from
device description objects in the platform firmware in case there are
no struct device objects for them (either those objects have not been
created yet or they do not exist at all).
The following
, and requests the GPIO properly.
Signed-off-by: Mika Westerberg
Acked-by: Alexandre Courbot
Signed-off-by: Rafael J. Wysocki
---
Changes from v5:
- fwnode_get_named_gpiod() takes 2 arguments (instead of 3; index has been
dropped).
- devm_get_gpiod_from_child() (renamed from
From: Rafael J. Wysocki
Make use of device property API in this driver so that both OF and ACPI
based system can use the same driver.
This change contains material from Max Eliaser and Mika Westerberg.
Signed-off-by: Mika Westerberg
Acked-by: Bryan Wu
Signed-off-by: Rafael J. Wysocki
etooth example the "reset-gpio" refers to the second GpioIo()
resource, second pin in that resource with the GPIO number of 31.
This patch implements necessary support to gpiolib for extracting GPIOs
using _DSD device properties.
Signed-off-by: Mika Westerberg
Acked-by: Linus Walleij
Sign
ACPI GPIO
translation in the core in a more generic way, since the two GPIO chips
share the same parent ACPI device.
Signed-off-by: Mika Westerberg
Acked-by: Linus Walleij
Signed-off-by: Rafael J. Wysocki
---
drivers/gpio/gpio-sch.c | 293 ++--
1 file
From: Mika Westerberg
Make use of device property API in this driver so that both DT and ACPI
based systems can use this driver.
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
drivers/misc/eeprom/at25.c | 34 +-
1 file changed, 13
able instead if the driver
is missing .acpi_match_table.
If there is a need to distinguish from where the device is enumerated
(DT/ACPI) driver can check dev->of_node or ACPI_COMPATION(dev).
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
Changes from v5:
- Package () { &
ing the series on MinnowBoard 1 and
MinnowBoard Max. In case anybody else would like to test it, it is available
from the device-properties branch of the linux-pm.git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
device-properties
Thanks!
--
I speak only for myself.
Rafael
From: "Rafael J. Wysocki"
Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type. The purpose of it is to help to
write portable code that won't depend on any part
kely
Signed-off-by: Darren Hart
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/Makefile |1
drivers/acpi/internal.h |6
drivers/acpi/property.c | 364
drivers/acpi/sca
1 - 100 of 232 matches
Mail list logo
