On Wed, Dec 02, 2015 at 12:58:55PM +, Charles Keepax wrote:
> So after a bit more digging it seems this has been mitigated slightly
> as a lot of SPI driver have been updated to execute transfers in
> thread rather than from a worker thread and it seems the clock
> framework lets you re-enter
On Sun, Oct 25, 2015 at 02:54:39PM +0100, Rafael J. Wysocki wrote:
> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broo...@kernel.org> wrote:
> > There's also the understanding people had that the order things get
> > bound changes the ordering for some of the other cases (pe
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 a given
system so it's constantly being highlighted to people in a way that
other issues
On Thu, Oct 22, 2015 at 04:02:13PM +0100, Russell King - ARM Linux wrote:
> If it was such a problem, then in the _eight_ days that this has been
> discussed so far, _someone_ would have sent some data showing the
> problem. I think the fact is, there is no data.
> Someone prove me wrong.
On Tue, Oct 20, 2015 at 04:46:56PM +0100, Russell King - ARM Linux wrote:
> Something like this. I haven't put a lot of effort into it to change all
> the places which return an -EPROBE_DEFER, and it also looks like we need
> some helpers to report when we have only an device_node (or should
On Wed, Oct 21, 2015 at 08:59:51AM -0700, Frank Rowand wrote:
> On 10/19/2015 5:34 AM, Tomeu Vizoso wrote:
> > To be clear, I was saying that this series should NOT affect total
> > boot times much.
> I'm confused. If I understood correctly, improving boot time was
> the key justification for
On Wed, Oct 21, 2015 at 11:18:08AM -0700, Frank Rowand wrote:
> On 10/21/2015 9:27 AM, Mark Brown wrote:
> > Overall boot time and time to get some individual built in component up
> > and running aren't the same thing - what this'll do is get things up
> > more in the l
On Tue, Oct 20, 2015 at 01:14:46PM -0400, Alan Stern wrote:
> On Tue, 20 Oct 2015, Tomeu Vizoso wrote:
> > This iteration of the series would make this quite easy, as
> > dependencies are calculated before probes are attempted:
> > https://lkml.org/lkml/2015/6/17/311
> But what Rafael is
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 there the only restrictions are
> parent-child relations plus whatever explicit requirements that drivers
> impose by
On Mon, Oct 19, 2015 at 10:44:41AM +0100, David Woodhouse wrote:
> On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> > Do you mean firmware rather than bus here? I think that's the confusion
> > I have...
> Certainly, if it literally is adding of_* calls th
On Mon, Oct 19, 2015 at 01:47:50PM +0100, David Woodhouse wrote:
> On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
> > See version 2 of the series[1] which did that. It became obvious that
> > was pointless because the call paths ended up looking like this:
> > Generic subsystem code -> DT
On Mon, Oct 19, 2015 at 04:29:40PM +0100, 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 places where we should be using t
On Sat, Oct 17, 2015 at 08:47:09AM -0700, Greg Kroah-Hartman wrote:
> On Sat, Oct 17, 2015 at 10:04:55AM -0500, Rob Herring wrote:
> > I think Linus W, Mark B, and I all said a similar thing initially in
> > that dependencies should be handled in the driver core. We went down
> > the path of
On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> > > I can't see adding calls like this all over the tree just to solve a
On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
> I can't see adding calls like this all over the tree just to solve a
> bus-specific problem, you are adding of_* calls where they aren't
> needed, or wanted, at all.
This isn't bus specific, I'm not sure what makes you say
On Wed, Oct 14, 2015 at 10:34:00AM +0200, Tomeu Vizoso wrote:
> git+ssh://git.collabora.co.uk/git/user/tomeu/linux.git
> on-demand-probes-for-next
In don't think that's the URL you intended to use (also everything looks
word wrapped here)?
signature.asc
Description: PGP signature
On Tue, Aug 25, 2015 at 04:57:56PM +0200, Wolfram Sang wrote:
On Tue, Aug 25, 2015 at 06:25:13AM +0100, Mark Brown wrote:
On Mon, Aug 24, 2015 at 01:52:02PM +0300, Jarkko Nikula wrote:
Commit 70762abb9f89 (i2c: Use stable dev_name for ACPI enumerated I2C
slaves) broke the lm-sensors
enumerated their name became i2c-INTABCD:ij and sysfs
code in lm-sensors does not find them anymore:
Acked-by: Mark Brown broo...@kernel.org
signature.asc
Description: Digital signature
of
function 'readw' [-Werror=implicit-function-declaration]
../drivers/i2c/busses/i2c-jz4780.c:187:2: error: implicit declaration of
function 'writew' [-Werror=implicit-function-declaration]
Add an explicit inclusion to fix this.
Signed-off-by: Mark Brown broo...@kernel.org
---
drivers/i2c/busses/i2c
On Wed, Apr 15, 2015 at 06:30:01PM +0100, Build bot for Mark Brown wrote:
For the past couple of days -next has been failing to build on both arm
and arm64 with:
arm64-allmodconfig
../drivers/i2c/busses/i2c-jz4780.c:181:2: error: implicit declaration of
function 'readw' [-Werror
/i2c-davinci.ko] undefined!
ERROR: i2c_recover_bus [drivers/i2c/busses/i2c-davinci.ko] undefined!
Add exports to fix this.
Fixes: 5f9296ba21b3c (i2c: Add bus recovery infrastructure)
Signed-off-by: Mark Brown broo...@kernel.org
---
drivers/i2c/i2c-core.c | 3 +++
1 file changed, 3 insertions
On Wed, Apr 15, 2015 at 08:59:53PM +0200, Wolfram Sang wrote:
On Wed, Apr 15, 2015 at 07:08:25PM +0100, Mark Brown wrote:
arm64-allmodconfig
../drivers/i2c/busses/i2c-jz4780.c:181:2: error: implicit declaration of
function 'readw' [-Werror=implicit-function-declaration]
../drivers
On Tue, Feb 17, 2015 at 01:05:07PM +0100, Geert Uytterhoeven wrote:
However, as soon as the da9210 driver will get interrupt support (I wrote
something, based on the da9211 driver) and the da9210 will have an interrupts
property in DTS, the interrupt storm will reappear, irrespectively of the
On Tue, Feb 03, 2015 at 08:34:01PM +0200, Antti Palosaari wrote:
On 02/03/2015 07:53 PM, Mauro Carvalho Chehab wrote:
If latter a better way to lock the I2C mux appears, we can reverse
this change.
More I am worried about next patch in a serie, which converts all that to
regmap API... Same
On Tue, Jan 20, 2015 at 12:14:31PM +0100, Paul Osmialowski wrote:
On Mon, 19 Jan 2015, Mark Brown wrote:
OK, so that's what should go in the changelog (along with an explanation
of why this preparation is required at all) - but I still don't see the
async bit of this I'm afraid.
I don't
On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote:
W dniu 18.01.2015 o 07:30, Tomasz Figa pisze:
So, the question is, do we actually have hardware that _really_
requires _actual_ preparation or all the clk_prepare_enable()s in I2C
drivers (at least in i2c-s3c2410) are just
On Fri, Jan 16, 2015 at 03:39:53PM +0100, Paul Osmialowski wrote:
This uses the enhancement of i2c API in order to address following problem
caused by circular lock dependency:
Please don't just dump enormous backtraces into commit messages as
explanations, explain in words what the problem
On Fri, Jan 16, 2015 at 03:39:54PM +0100, Paul Osmialowski wrote:
This adopts i2c-s3c2410 driver for new enhancement of i2c API that
exposes preparation and unpreparation stages of i2c transfer.
This doesn't seem to have any dependency on the previous patch at all...
it probably does want a
On Wed, Oct 29, 2014 at 10:40:37AM +0200, Pantelis Antoniou wrote:
Dynamically inserting spi device nodes requires the use of a single
device registration method. Rework and export it.
Methods to lookup a device/master using a device node are added
as well, of_find_spi_master_by_node()
On Wed, Oct 29, 2014 at 01:48:06PM +0200, Pantelis Antoniou wrote:
On Oct 29, 2014, at 12:14 , Mark Brown broo...@kernel.org wrote:
This feels like there is an abstraction problem somewhere, whatever code
is supposed to use this is going to need to be taught about each
individual bus
On Sun, Aug 17, 2014 at 12:08:57PM +0200, Geert Uytterhoeven wrote:
Add explicit dependencies for the various regmap modules, so Kconfig
will print a warning message when another module selects a regmap module
without fulfilling its dependencies.
Applied, thanks. The second patch is a bug fix
On Fri, Jul 25, 2014 at 02:42:31PM -0700, Mike Turquette wrote:
Quoting Sylwester Nawrocki (2014-07-03 10:25:53)
I would appreciate a DT, SPI or the I2C maintainer opinions.
Yes, Acks from SPI and I2C maintainers would be good. I might need to
drop those parts of this patch if they don't
On Fri, Jun 13, 2014 at 02:58:26PM -0700, Doug Anderson wrote:
Anyway, suffice to say that the i2c core needs to be extended to
handle the idea that a single device has more than one compatible
string. I'll leave it to an eager reader of this thread to implement
this since we can also fix
On Thu, Jun 05, 2014 at 04:55:09PM +0100, Lee Jones wrote:
On Thu, 05 Jun 2014, Grant Likely wrote:
I still think the way to do it is to emulate the missing i2c_device_id
when calling the drivers .probe() hook by having a temporary copy on
the stack and filling it with data from the OF or
On Fri, May 09, 2014 at 05:50:00PM +0530, Naveen Krishna Ch wrote:
On 24 April 2014 21:55, Mark Brown broo...@kernel.org wrote:
Such solution has been proposed by Mark Brown to fix the problem of
the regulators not beeing available on the peripheral device probe():
http
On Fri, May 09, 2014 at 08:12:47PM +0530, Naveen Krishna Ch wrote:
On 9 May 2014 19:21, Mark Brown broo...@kernel.org wrote:
On Fri, May 09, 2014 at 05:50:00PM +0530, Naveen Krishna Ch wrote:
DRM related drivers like DP, FIMD, HDMI, Mixer wants to be probed ASAP
during the boot.
The real
been proposed by Mark Brown to fix the problem of
the regulators not beeing available on the peripheral device probe():
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011971.html
What specifically is this needed for? We *should* be able to use
deferred probe for most things
On Tue, Mar 04, 2014 at 12:38:28PM +0100, Sylwester Nawrocki wrote:
On 28/02/14 07:07, Mark Brown wrote:
On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:
The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
using standard DT binding and v4l2_subdev
On Fri, Feb 21, 2014 at 12:45:21PM +0100, Sylwester Nawrocki wrote:
The I2C bus driver with empty i2c_algorithm.master_xfer() helps WRT to
using standard DT binding and v4l2_subdev interface.
Wouldn't a platform device do just as well here if there's no actual
control?
signature.asc
On Wed, Feb 19, 2014 at 03:20:07PM +0100, Ulf Hansson wrote:
Also note that, Russell has already applied the corresponding part in
the amba bus (patch 1)
Why would this depend on an AMBA patch and if it does surely the two
need to be merged together somehow?
signature.asc
Description:
On Mon, Feb 10, 2014 at 01:33:50PM +0100, Ulf Hansson wrote:
On 4 February 2014 20:16, Mark Brown broo...@kernel.org wrote:
This seems like a fairly hideous thing to be having to open code in an
individual driver, it all looks generic and like something that most if
...
Putting
On Wed, Feb 05, 2014 at 01:49:49PM +0100, Linus Walleij wrote:
On Tue, Feb 4, 2014 at 8:22 PM, Kevin Hilman khil...@linaro.org wrote:
I'm trying to thing of a good reason to not make PM_SLEEP depend on
PM_RUNTIME for platforms like this.
Isn't the typical Android platform using PM_SLEEP
On Tue, Feb 04, 2014 at 09:31:19AM -0500, Matt Porter wrote:
On Tue, Feb 04, 2014 at 01:29:51PM +, Lee Jones wrote:
+static struct i2c_driver bcm59056_i2c_driver = {
+ .driver = {
+.name = bcm59056,
+.owner = THIS_MODULE,
+.of_match_table =
On Tue, Feb 04, 2014 at 04:58:49PM +0100, Ulf Hansson wrote:
Use clk_disable_unprepare and clk_prepare_enable from the runtime PM
callbacks, to fully gate|ungate clocks. Potentially this will save more
power, depending on the clock tree for the current SOC.
The same patch has already been
On Tue, Feb 04, 2014 at 05:08:32PM +, Lee Jones wrote:
What using of_match_ptr() should do is allow the compiler to figure out
that the table isn't used when DT is disabled and discard it without
ifdefs. Not sure if that actually works yet but that's the idea.
Right, but I'm guessing
On Tue, Feb 04, 2014 at 07:19:08AM -0500, Matt Porter wrote:
Add a DT binding for the BCM59056 PMU. The binding inherits from
the generic regulator bindings.
Is this really only a regulator - does the chip have no other functions?
+- regulators: This is the list of child nodes that specify
On Tue, Feb 04, 2014 at 07:19:10AM -0500, Matt Porter wrote:
+static unsigned int bcm59056_get_mode(struct regulator_dev *dev)
+{
+ return REGULATOR_MODE_NORMAL;
+}
+
+static int bcm59056_set_mode(struct regulator_dev *dev, unsigned int mode)
+{
+ if (mode ==
On Tue, Feb 04, 2014 at 04:58:41PM +0100, Ulf Hansson wrote:
The fixes for the amba bus needs to be merged prior to the other, thus I think
it could make sense to merge this complete patchset through Russell's tree,
if he and the other maintainers think this is okay.
What are the actual
On Tue, Feb 04, 2014 at 04:58:48PM +0100, Ulf Hansson wrote:
@@ -2328,8 +2300,23 @@ static int pl022_suspend(struct device *dev)
return ret;
}
- pm_runtime_get_sync(dev);
- pl022_suspend_resources(pl022, false);
+ pm_runtime_disable(dev);
+
+ if
On Tue, Feb 04, 2014 at 04:58:50PM +0100, Ulf Hansson wrote:
Make use of clk_prepare_enable and clk_disable_unprepare to simplify
code. No functional change.
I went ahead and applied this since it looks good and seems like an
unrelated cleanup to the runtime PM stuff which seems to be where the
On Tue, Feb 04, 2014 at 04:16:38PM -0500, Matt Porter wrote:
On Tue, Feb 04, 2014 at 05:23:09PM +, Mark Brown wrote:
Is this really only a regulator - does the chip have no other functions?
It's your average multi-function device with other functions as you are
suspecting. Buried
On Tue, Feb 04, 2014 at 04:29:14PM -0500, Matt Porter wrote:
On Tue, Feb 04, 2014 at 05:28:36PM +, Mark Brown wrote:
+ /*
+ * Regulator API handles empty constraints but not NULL
+ * constraints
+ */
+ if (!reg_data
On Fri, Jan 17, 2014 at 09:37:56AM +0200, Jarkko Nikula wrote:
On 01/16/2014 09:46 PM, Mark Brown wrote:
This is needed for ACPI because we rewrite the device names to give us
stable names. With OF for I2C and SPI nothing bus specific is done that
affects this stuff so the default behaviour
acpi_driver_match_device() in bus .match() callback.
But, the module autoloading is still broken.
Acked-by: Mark Brown broo...@linaro.org
modulo the PAGE_SIZE stuff Mika noted - unless this changes radically
please just assume I'm OK with it.
signature.asc
Description: Digital signature
On Thu, Jan 16, 2014 at 09:05:09PM +0800, Zhang Rui wrote:
On Thu, 2014-01-16 at 13:27 +0100, Wolfram Sang wrote:
I wonder why we don't have/need that with CONFIG_OF? Because probably
nobody is using modules with i2c devices there?
This seems a gap to me but I'm not 100% sure.
I saw Grant
On Tue, Jan 14, 2014 at 04:00:17PM +0800, Zhang Rui wrote:
On Mon, 2014-01-13 at 17:35 +, Mark Brown wrote:
On Mon, Jan 13, 2014 at 09:48:31PM +0800, Zhang Rui wrote:
ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading
On Mon, Jan 13, 2014 at 09:48:31PM +0800, Zhang Rui wrote:
ACPI enumerated devices has ACPI style _HID and _CID strings,
all of these strings can be used for both driver loading and matching.
But currently, in Platform, I2C and SPI bus, only the ACPI style
driver matching is supported by
On Tue, Nov 26, 2013 at 01:05:53PM +, Charles Keepax wrote:
On Fri, Nov 08, 2013 at 09:59:28AM -0700, Stephen Warren wrote:
That all said, I wonder if the I2C core shouldn't do something like the
following inside i2c_add_adapter():
if (!adap-dev.of_node adap-dev.parent)
On Thu, Nov 14, 2013 at 11:01:01AM +0200, Jarkko Nikula wrote:
Current spi bus_num.chip_select spix.y based device naming scheme may not
be stable enough to be used in name based matching, for instance within
ALSA SoC subsystem.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
On Mon, Oct 28, 2013 at 03:15:25PM +0200, Jarkko Nikula wrote:
One possible thing to do is to let structure definitions to be
available for non-ACPI builds. Then compiler won't fail on structure
access which will be anyway optimized away by later compiler stages.
You could also have inline
On Fri, Oct 25, 2013 at 03:19:00PM +0300, Jarkko Nikula wrote:
Current spi bus_num.chip_select spix.y based device naming scheme may not
be stable enough to be used in name based matching, for instance within
ALSA SoC subsystem.
I'm happy with this from the SPI side modulo Raphael's comments -
On Thu, Oct 10, 2013 at 09:12:56AM +0300, Mika Westerberg wrote:
On Wed, Oct 09, 2013 at 06:55:28PM +0100, Mark Brown wrote:
On Wed, Oct 09, 2013 at 05:04:21PM +0300, Mika Westerberg wrote:
+ if (ACPI_HANDLE(spi-dev))
+ acpi_dev_pm_attach(spi-dev, true);
Though I do wonder
On Sat, Oct 05, 2013 at 11:09:01AM +0300, Mika Westerberg wrote:
It looks like Windows actually powers the I2C controller off independently
of the I2C client power state. We should probably do the same in Linux even
though it is not following what the ACPI spec says (but makes sense with
On Tue, Oct 01, 2013 at 04:03:40PM +0530, Yuvaraj Kumar C D wrote:
+static bool is_ack(struct s3c24xx_i2c *i2c)
+{
+ u32 time_out = i2c-tx_setup;
+
+ while (--time_out) {
+ if (readl(i2c-regs + S3C2410_IICCON)
+ S3C2410_IICCON_IRQPEND) {
+
On Mon, Sep 30, 2013 at 01:13:52PM +0800, Hanjun Guo wrote:
For some devices especially on platform/I2C/SPI bus, they want to
be initialized earlier than other devices, so the driver use initcall
such as subsys_initcall to make this device initialize earlier.
We're trying to move away from
On Sun, Sep 29, 2013 at 10:51:05AM +0200, Lars-Peter Clausen wrote:
The 'driver' field of the i2c_client struct is redundant and is going to be
removed. Check i2c_client-dev.driver instead to see if a driver is bound to
the
device.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
On Tue, Sep 17, 2013 at 03:25:25AM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 17, 2013 12:31:11 AM Mark Brown wrote:
It shouldn't even need to do that, it should just be able to rely on the
controller to power itself up when asked to do work. This is how the
existing
On Sun, Sep 15, 2013 at 04:28:24PM +0300, Mika Westerberg wrote:
On Sun, Sep 15, 2013 at 01:47:44PM +0100, Mark Brown wrote:
On Sun, Sep 15, 2013 at 09:41:39AM +0300, Mika Westerberg wrote:
1. In I2C core i2c_device_probe() we power on the I2C controller
and attach the client device
On Mon, Sep 16, 2013 at 02:44:35PM +0200, Linus Walleij wrote:
I've tried to fix this for DT-only I2C devices
and this very driver was the reason.
But a tiresome regression due to drivers relying on this
i2c_device_id not being NULL and inability to remove it from the I2C
core without
On Mon, Sep 16, 2013 at 05:05:37PM +0100, Lee Jones wrote:
So in the mean time are you happy with this dummy approach?
No. dummy is reserved for a dummy device in case an i2c slave needs
more than one address. The proper solution would be if
i2c_sysfs_new_device() could recognize the
On Mon, Sep 16, 2013 at 09:07:07PM +0200, Rafael J. Wysocki wrote:
That may be left to the client driver altogether. I mean, if the client wants
the controller to be powered up, it should just call
pm_runtime_get_sync(controller device) at a suitable place (and then do the
corresponding _put
On Fri, Sep 13, 2013 at 09:54:34AM +0300, Mika Westerberg wrote:
On Thu, Sep 12, 2013 at 02:34:21PM -0700, Kevin Hilman wrote:
For hardware that is disabled/powered-off on startup, there will now be
a mismatch between the hardware state an the RPM core state.
The call to
On Fri, Sep 13, 2013 at 09:14:20AM +0800, Aaron Lu wrote:
On 09/13/2013 06:06 AM, Sylwester Nawrocki wrote:
So there is currently no way to avoid this behaviour, i.e. to have the
adapter
not activated before any of its client devices is probed, but only later on,
after explicit call to
On Fri, Sep 13, 2013 at 01:16:11PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 10:59:50AM +0100, Mark Brown wrote:
Accessing the bus isn't an issue for I2C outside of ACPI, the power
management of the device is totally disassociated from the bus and the
controller is responsible
On Fri, Sep 13, 2013 at 02:50:35PM +0300, Mika Westerberg wrote:
On Fri, Sep 13, 2013 at 11:31:52AM +0100, Mark Brown wrote:
Right, but this probably needs to be highlighted more since it's a very
surprising thing for I2C and is causing confusion.
By highlighted more, do you mean something
On Thu, Sep 12, 2013 at 12:27:43PM +0300, Mika Westerberg wrote:
On Wed, Sep 11, 2013 at 04:51:20PM +0100, Mark Brown wrote:
I would be able to have this and the other patch in the SPI tree in case
it overlaps with other work - I'm not sure what the plan will be for
merging this stuff
On Thu, Sep 12, 2013 at 02:07:48PM -0700, Kevin Hilman wrote:
IMO, this decision belongs to the PM domain, not to the core. We have
an established legacy with the current core default (auto) and changing
that means lots of breakage.
Yup.
The forbid by default can just as easily be handled
On Wed, Sep 11, 2013 at 09:01:16AM +0800, Aaron Lu wrote:
Looks like, it all boils down to how many I2C devices should be allowed
for runtime PM by default and how many I2C devices should be forbidden.
, and then we allow/forbid runtime PM for the majority case in I2C core
while individual
On Wed, Sep 11, 2013 at 02:05:43PM +0300, Mika Westerberg wrote:
I'll also look into converting the existing I2C client drivers to use this
method. One question, though, is it better to have the conversion in the
same patch that introduces the I2C core runtime PM change or as a separate
.
Acked-by: Mark Brown broo...@linaro.org
signature.asc
Description: Digital signature
that are not bound to any driver are not prepared for runtime PM.
Acked-by: Mark Brown broo...@linaro.org
I would be able to have this and the other patch in the SPI tree in case
it overlaps with other work - I'm not sure what the plan will be for
merging this stuff but if there were a branch which I
On Wed, Sep 11, 2013 at 06:32:31PM +0300, Mika Westerberg wrote:
Hi,
This is second version of the patches. The previous version can be found
here:
http://www.spinics.net/lists/linux-i2c/msg13152.html
Looks good to me now:
Reviwed-by: Mark Brown broo...@linaro.org
for what it's
On Wed, Sep 11, 2013 at 06:32:40PM +0300, Mika Westerberg wrote:
If the SPI device is enumerated from ACPI namespace (it has an ACPI handle)
it might have ACPI methods that needs to be called in order to transition
the device to different power states (such as _PSx).
Acked-by: Mark Brown broo
On Tue, Sep 10, 2013 at 10:51:00AM +0300, Mika Westerberg wrote:
On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
How is this going to interact with client devices which are already
enabling runtime PM for themselves, and what are the advantages of doing
this over having
On Tue, Sep 10, 2013 at 05:26:31PM +0300, Mika Westerberg wrote:
On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
There is one difference though -- runtime PM is now blocked by default and
it needs to be unblocked from the userspace per each device.
...as you say
On Tue, Sep 10, 2013 at 10:04:21PM +0200, Rafael J. Wysocki wrote:
On Tuesday, September 10, 2013 05:13:21 PM Mark Brown wrote:
OK, that is very much not the model which embedded systems follow, in
embedded systems the driver for the device is fully in control of its
own power. It gets
On Mon, Sep 09, 2013 at 04:34:38PM +0300, Mika Westerberg wrote:
+ /*
+ * Enable runtime PM for the client device. If the client wants to
+ * participate on runtime PM it should call pm_runtime_put() in its
+ * probe() callback.
+ *
+ * User still needs to allow
On Thu, Aug 22, 2013 at 10:23:28AM +0100, Pawel Moll wrote:
If the platform data used to carry the (custom) irq data, the DT-powered
driver could interrogate the DT on is own, couldn't it? Of course there
should be some helper available, maybe something of that sort? (warning,
untested)
Yes,
On Thu, Aug 22, 2013 at 12:44:04PM +0100, Pawel Moll wrote:
On Thu, 2013-08-22 at 12:26 +0100, Mark Brown wrote:
Yes, that's probably the most straightforward thing - we'd need to
either have the bindings specify which interrupt must be first for
reading i2c-irq or just have the drivers
On Wed, Aug 21, 2013 at 01:37:04PM +0100, Pawel Moll wrote:
So let me ask such question... If Device Tree didn't exist, how would
you make drive such device? I guess it would require some custom code,
It's always done using platform data, same for SPI - if we update one we
should probably
On Mon, Jul 08, 2013 at 10:25:38PM +0200, Maxime Ripard wrote:
On Mon, Jul 08, 2013 at 09:34:26AM +0100, Mark Brown wrote:
I'd really like to see more discussion of this DT parsing code for
regmap idea... I've missed almost all the context here.
The context was that I found we lack a way
On Sat, Jul 06, 2013 at 09:06:49PM +0200, Arnd Bergmann wrote:
On Saturday 06 July 2013 14:01:12 Maxime Ripard wrote:
a) like interrupts, regs, dmas, clocks, pinctrl, reset, pwm: fixed
property names
regmap = at25 0xstart 0xlen;
regmap-names = mac-address;
On Thu, Jun 06, 2013 at 11:33:46AM -0700, Bin Gao wrote:
A good example is that an ISP(Imaging Signal Processor) driver needs
register i2c camera sensor devices via v4l2, so it has to unregister
all i2c clients that were previously registered by calling
i2c_register_board_info(), and then
On Tue, Jun 18, 2013 at 01:30:13PM +0300, Mikko Perttunen wrote:
Commit i2c: core: make it possible to match a pure device tree driver
changed semantics of the i2c probing for device tree devices.
Device tree probed devices now get a NULL i2c_device_id pointer.
This causes the regulator name
On Tue, Jun 11, 2013 at 09:14:41AM +0800, Barry Song wrote:
the mainline idea you mentioned is that you don't care about any early
device, which means some devices want to start earlier than others in
some real automative user scenerioes.
but i think another important idea is that mainline
On Tue, Jun 11, 2013 at 07:13:33PM +0800, Barry Song wrote:
2013/6/11 Mark Brown broo...@kernel.org:
It's not that people don't care about these users, it's that people
don't care too much about out of tree users. Part of the goal here is
to convince people working on such applications
On Mon, May 27, 2013 at 09:54:56AM +0800, Barry Song wrote:
Mark, the case is not that deferred probing is slow or not. deferred
probing is pretty good.
the case is that we want to i2c and media connected with i2c probed
earlier than other devices.
in auto infotainment devices, we actually
On Thu, May 16, 2013 at 06:25:39PM +0800, Barry Song wrote:
2013/5/16 Wolfram Sang w...@the-dreams.de:
What about deferred probing?
deferred probing could work but could not work for automative.
what we really want is that devices begin to work as early as
possible. we want i2c clients
On Thu, May 23, 2013 at 04:27:20AM +, Craig McQueen wrote:
I'm trying to read data from a SGTL5000 audio CODEC, which has 16-bit
addresses and 16-bit wide data registers.
Unless I'm missing something, it looks impossible to read these registers
using i2cget, because it only supports
On Thu, May 16, 2013 at 09:37:11PM +0100, Russell King wrote:
As this driver does not advertise protocol mangling support
(I2C_FUNC_PROTOCOL_MANGLING is not set), having code to act on
I2C_M_NOSTART is illogical, and in any case isn't supportable on
anything but the first message - which
1 - 100 of 306 matches
Mail list logo
