This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c | 28
1
On Fri, Feb 24, 2012 at 01:35:08PM -0800, Stephen Warren wrote:
Can we eliminate this warning in of_get_regulator(), and let clients
Control whether they warn when a regulator isn't found, if they think
one is mandatory? I think I'd prefer this option; it's consistent with
the non-DT path in
This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c | 28
1
On Mon, Mar 05, 2012 at 07:48:42PM +0900, Jaehoon Chung wrote:
On 03/03/2012 09:46 AM, Mark Brown wrote:
+ pm_runtime_set_autosuspend_delay(pdev-dev, 50);
Could you explain why use 50ms?
It's essentially a random number, some other devices use the same one.
We're just trying to avoid
On Tue, Mar 06, 2012 at 03:17:20PM +0900, Jaehoon Chung wrote:
This patchset is the purpose for using sdhci-pltfm.c and
removing the arch dependency.
The sdhci-s3c has too heavy arch dependency.
For example, if work for sdhci-s3c.c at mmc-tree, sometime need to change
sdhci.h for
On Tue, Mar 06, 2012 at 11:40:08PM +0900, Jae hoon Chung wrote:
2012/3/6 Heiko Stübner he...@sntech.de:
Am Dienstag, 6. März 2012, 14:00:54 schrieb Mark Brown:
This series will break S3C64xx, you've not touched it at all in the
update but it uses the same SDHCI controller.
This problem
On Wed, Mar 07, 2012 at 12:03:31PM +0900, Jaehoon Chung wrote:
On 03/07/2012 01:30 AM, Mark Brown wrote:
The same IP is present and used with the same driver on other Samsung
SoCs.
I know that used with the same driver on other
Samsung-SoCs(S3C64XX/S3C24XX..etc)
I just only used
On Wed, Mar 07, 2012 at 10:05:54AM +0100, Rafael J. Wysocki wrote:
On Wednesday, March 07, 2012, Adrian Hunter wrote:
Maybe this needs to be re-thought. Userspace needs a simple, consistent and
understandable set of pm controls across the entire kernel, not piecemeal
across different
On Wed, Mar 07, 2012 at 09:51:07PM +0100, Rafael J. Wysocki wrote:
That would be fine, but it doesn't _conflict_ with a more direct (so to
speak) knob in sysfs, does it?
Well, perhaps - one of the issues I remember from last time we discussed
this was that there's a tension between the
On Thu, Mar 08, 2012 at 02:35:53PM +0900, Jaehoon Chung wrote:
So i think no problem that removed #include plat/regs-sdhci.h. is it
wrong?
Just touching the setup-gpio- files is problem?
It should be fine, like I say I didn't really read the patches in enough
detail as the diffstat set off
On Thu, Mar 08, 2012 at 12:30:28AM +0100, Rafael J. Wysocki wrote:
+ dev_pm_qos_hide_latency_limit(pdev-dev);
+
Shouldn't the core be able to cope with cleaning things up by itself
here? It seems like it'd be easier/less error prone to do that.
signature.asc
Description: Digital
:
Reviewed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
On Fri, Mar 09, 2012 at 10:53:26AM +0900, Jaehoon Chung wrote:
On 03/08/2012 08:01 PM, Mark Brown wrote:
It should be fine, like I say I didn't really read the patches in enough
detail as the diffstat set off alarm bells.
If you have any opinions, let me know.
I believe that these patches
On Fri, Mar 09, 2012 at 12:08:58AM -0500, Chris Ball wrote:
The reworked patch is below, please let me know if it looks incorrect:
That looks about right, I'll find out soon enough if it doesn't work in
-next as my main development system has the rootfs on this device :)
signature.asc
On Fri, Mar 16, 2012 at 12:36:35PM +, Arnd Bergmann wrote:
On Friday 16 March 2012, Linus Walleij wrote:
On Thu, Mar 15, 2012 at 9:58 PM, Arnd Bergmann a...@arndb.de wrote:
But I guess you're after modelling the levelshifter as a regulator?
Basically the level shifter is a separate
On Fri, Mar 16, 2012 at 12:48:15PM +, Arnd Bergmann wrote:
On Thursday 15 March 2012, Russell King - ARM Linux wrote:
We _do_ need a solution for GPIO-controlled voltage regulators, as these
are actually quite common - see the various soc-common using PCMCIA
drivers.
So I think
On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote:
On Tue, Feb 21 2012, Chris Ball wrote:
On Tue, Feb 21 2012, Kukjin Kim wrote:
I created topic branch for this we talked. You can pull that following:
git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
On Fri, Mar 30, 2012 at 06:45:07PM +, Arnd Bergmann wrote:
On Friday 30 March 2012, Stephen Warren wrote:
+- cd-inverted: when present, polarity on the wp gpio line is inverted
+- wp-inverted: when present, polarity on the wp gpio line is inverted
I'm not sure about those two: Some
Rather than just logging that we came up with an excessively large timeout
say what the timeout was, this may provide some clues as to what the issue
is.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
I'm seeing reams of these from my s3c64xx based system, looks like it's
On Fri, Apr 20, 2012 at 06:59:41PM +0200, Guennadi Liakhovetski wrote:
+static struct gpio_regulator_state mmcif_power_states[] = {
+ { .value = 330, .gpios = 0 },
+};
It doesn't make much odds but if you've only got one voltage the fixed
voltage regulator is a little more idiomatic
On Tue, Apr 24, 2012 at 06:41:45PM +0200, Guennadi Liakhovetski wrote:
+ host-vdd = regulator_get(mmc_dev(mmc), SD Vdd);
+ if (IS_ERR(host-vdd)) {
+ host-vdd = NULL;
+ } else {
This silently ignoring errors really isn't good practice :(
@@ -1052,6 +1079,7 @@ void
On Thu, May 03, 2012 at 05:05:35PM +0200, Guennadi Liakhovetski wrote:
Some consumers, e.g., the mmc subsystem, can benefit from an ability to
check, whether a regulator can switch power on and off.
You're going to have to expand a lot more on why this is a good idea...
Bear in mind that the
On Thu, May 03, 2012 at 05:05:34PM +0200, Guennadi Liakhovetski wrote:
- if (regulator == NULL || IS_ERR(regulator))
+ if (IS_ERR_OR_NULL(regulator))
The bigger question here is why we're accepting NULL in the first place.
signature.asc
Description: Digital signature
On Thu, May 03, 2012 at 05:05:36PM +0200, Guennadi Liakhovetski wrote:
+ ret = mmc_regulator_get_ocrmask(supply);
+ if (ret 0)
+ mmc-ocr_avail = ret;
+
+ if (regulator_can_change_status(supply)) {
+ mmc-caps |= MMC_CAP_POWER_OFF_CARD;
+
On Thu, May 03, 2012 at 05:05:37PM +0200, Guennadi Liakhovetski wrote:
+#include linux/regulator/consumer.h
Where's this used?
+static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios
*ios)
+{
+ struct sh_mmcif_plat_data *pd = host-pd-dev.platform_data;
+
+ if
On Thu, May 03, 2012 at 05:05:42PM +0200, Guennadi Liakhovetski wrote:
+static void tmio_mmc_set_power(struct tmio_mmc_host *host, struct mmc_ios
*ios)
+{
+ if (!(host-mmc-caps MMC_CAP_POWER_OFF_CARD))
+ return;
+
+ if (host-vdd)
+ /* Errors ignored... */
On Thu, May 03, 2012 at 05:05:33PM +0200, Guennadi Liakhovetski wrote:
devres_destroy() doesn't call the release() method, it only destroys the
resource. The caller should take care to release the associated object
itself.
+ regulator_put(regulator);
rc =
the reference to the regulator.
This looks like a good, simple solution - working out how we avoid extra
power ups will probably be more invasive and might not be worth the
effort for something that's boot time only.
Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description
On Fri, May 18, 2012 at 05:57:50PM +0900, Paul Mundt wrote:
On Thu, May 03, 2012 at 04:32:39PM +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 05:05:34PM +0200, Guennadi Liakhovetski wrote:
- if (regulator == NULL || IS_ERR(regulator))
+ if (IS_ERR_OR_NULL(regulator))
The bigger
On Fri, May 18, 2012 at 10:33:42AM +0200, Guennadi Liakhovetski wrote:
On Thu, 3 May 2012, Mark Brown wrote:
Bear in mind that the regulator may be shared by other users so even if
the regulator is flagged as potentially being able to change status that
doesn't mean that it actually can
On Fri, May 18, 2012 at 10:54:26AM +0200, Guennadi Liakhovetski wrote:
+ regulator_put(regulator);
rc = devres_destroy(regulator-dev, devm_regulator_release,
devm_regulator_match, regulator);
So, shall we rather use your new devres_release() here?
Yes, I
On Fri, May 18, 2012 at 11:28:31AM +0200, Guennadi Liakhovetski wrote:
1. A regulator that can (in principle) change state, i.e., switch on and
off. Such a regulator is good to keep for the runtime to power up and down
the card.
2. A regulator, that cannot switch, but at least can tell its
On Fri, May 18, 2012 at 11:55:53AM +0200, Guennadi Liakhovetski wrote:
On Thu, 3 May 2012, Mark Brown wrote:
should it be being factored out into the core?
Wll, it's not a lot of code. We could make this a library function,
provided by the core, but I don't think it would be very
On Fri, May 18, 2012 at 05:39:39PM +0200, Guennadi Liakhovetski wrote:
08/29] mmc: sh_mmcif: add regulator support). But perhaps giving
preference to the regulator is bogus. Maybe I should just switch both, or
even give preference to the call-back. What do you think? Switching both
is,
On Mon, May 28, 2012 at 11:12:18AM +0300, Adrian Hunter wrote:
On 28/05/12 06:32, Philip Rakity wrote:
I have started looking at this area and I am rather confused. It seems to
me two dedicated regulators are required.
It probably pays not to assume too much about regulators. For
On Fri, May 25, 2012 at 05:14:52PM +0200, Guennadi Liakhovetski wrote:
Add a function to get a regulator, supplying card's Vdd on a specific host.
If such a regulator is found, the function checks, whether a valid OCR mask
can be obtained from this regulator.
Reviwed-by: Mark Brown broo
to the version I just reviewed...
Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
On Sun, Jun 03, 2012 at 03:29:55PM +0200, Heiko St??bner wrote:
request_threaded_irq(sc-ext_cd_irq, NULL,
sdhci_s3c_gpio_card_detect_thread,
- IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING,
+
On Sat, Jun 09, 2012 at 12:39:15PM -0700, Philip Rakity wrote:
- trace_regulator_set_voltage_complete(rdev_get_name(rdev), selector);
+ voltage = _regulator_get_voltage(rdev);
+ if (voltage = 0)
+ _notifier_call_chain(rdev,
+
On Mon, Jun 11, 2012 at 01:38:13PM +0200, Guennadi Liakhovetski wrote:
On Fri, 18 May 2012, Mark Brown wrote:
This is checking the value of regulator_get(), NULL is a perfectly valid
regulator value to get passed back.
Sorry, could you clarify, how it is valid? No, I'm not proposing
On Mon, Jun 11, 2012 at 02:06:29PM +0200, Guennadi Liakhovetski wrote:
On Mon, 11 Jun 2012, Mark Brown wrote:
The stubs return NULL and we could decide in future to use NULL for
something else (though that seems unlikely).
Ah, sure, forgot about that, sorry. In fact, I was wondering
On Mon, Jun 11, 2012 at 02:39:29PM +0200, Guennadi Liakhovetski wrote:
On Mon, 28 May 2012, Mark Brown wrote:
Even if the supply is always on you can easily provide an always on
regulator. From the point of view of the consumer if there are two
physical supplies needed it's much clearer
On Thu, Jun 14, 2012 at 08:31:20AM +0200, Thierry Reding wrote:
On Wed, Jun 13, 2012 at 03:17:06PM -0600, Stephen Warren wrote:
The core of the issue is that:
* Tegra30 support is via device tree.
* We have an SDIO bus, and the WiFi device attached to that bus is
enumerable.
* Since
On Fri, Jun 15, 2012 at 11:28:38PM +0530, Pankaj Jangra wrote:
I am also curious to know if you pass the voltage here to notifier call
how does it make any difference, since in
blocking_notifier_call_chain() again passes the NULL. So does your patch
should modify the arguments to this
On Fri, Jun 15, 2012 at 11:27:36AM -0700, Philip Rakity wrote:
V3
--
Applied, thanks (though this changelog should've come in the --- after
the main changelog rather than before so it didn't appear in the
changelog). I made the spelling fix Pankaj pointed out as well.
signature.asc
On Thu, Jun 14, 2012 at 03:07:56PM -0700, Philip Rakity wrote:
minor optimization: move delay code to where delay is set and
thus where it is used vs in the main line path.
Applied, thanks.
signature.asc
Description: Digital signature
is
optional. A failure to get it is not fatal.
Reviwed-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
is to merge this along with the changes for
introducing -EPROBE_DEFER.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
signature.asc
Description: Digital signature
On Mon, Jun 18, 2012 at 07:00:14PM +0200, Roland Stigge wrote:
Basically, yes. But this would mean that doing via gpio, we would need
to pull other stuff from the sound tree over to gpio to build upon
because my tegra_* sound patches won't apply to the gpio branch currently.
Oh, yes.
On Tue, Jun 19, 2012 at 12:25:58PM +0800, Wei Ni wrote:
As Stephen previously said please fix your mail formatting - word
wrapping within paragraphs is important!
On Tue, Jun 19, 2012 at 09:23:35, Philip Rakity wrote:
Why can't you use the regulator notify to get called back on power or
On Tue, Jun 19, 2012 at 06:01:54PM -0600, Stephen Warren wrote:
Unfortunately, it should be noted that the WiFi device socket on Cardhu
apparently isn't some standardized thing (like PCIe) but something
rather more custom, although there are apparently devices available to
plug into it from
On Sat, Jun 30, 2012 at 04:05:36PM -0700, philipspatc...@gmail.com wrote:
From: Philip Rakity prak...@marvell.com
This definition is missing when CONFIG_REGULATOR is not defined.
This causes compiler errors when compiling sdhci.c. This can
be worked around by adding #ifdef CONFIG_REGULATOR
For most error conditions sdhci_add_host() will print a diagnostic
message indicating why it failed but there are a few cases where this
does not happen. Add error messages in these cases to aid diagnosis.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci.c
On Sat, Jul 14, 2012 at 09:57:08PM +0200, Linus Walleij wrote:
If I understand correctly this relates closely to another patch from Mark
Brown
we discussed the other day (sorry for missing this patch, which arrived
earlier, for a while).
Mark/Grant can you look at this patch?
Not unless I
On Tue, Jul 17, 2012 at 12:16:48AM +0200, Linus Walleij wrote:
On Sun, Jul 15, 2012 at 11:11 PM, Mark Brown
I had thought a version of this
had been submitted already and was in a similar place to the one for
gpio_request().
Me to...
Greg just merged the driver core patch for pushing
On Wed, Aug 29, 2012 at 09:08:47AM -0400, Chris Ball wrote:
On Wed, Aug 29 2012, Ulf Hansson wrote:
On 28 August 2012 01:33, Chris Ball c...@laptop.org wrote:
Some distributions build with CONFIG_REGULATOR_DUMMY=y -- this makes
regulator setup succeed harmlessly, but then trying to set the
On Thu, Aug 30, 2012 at 01:25:58PM -0400, Chris Ball wrote:
On Thu, Aug 30 2012, Mark Brown wrote:
Conversely there is nothing stopping other regulator drivers having
similar properties to the dummy driver, or constraints stopping them
implementing things. If the MMC framework wants
On Thu, Sep 20, 2012 at 07:39:34AM +, Arnd Bergmann wrote:
The first five branches are scheduled to go through the arm-soc tree, so
I'm fine with that. For the sound/for-3.7 branch, I'd like to know when
to expect that hitting mainline. If it always gets in very early during the
merge
On Thu, Sep 20, 2012 at 07:52:15PM +0800, Shawn Guo wrote:
On Thu, Sep 20, 2012 at 07:41:50AM -0400, Mark Brown wrote:
It's usually pretty early but Takashi will be on holiday this time so
I'm not sure if things might be different (he was going to send the pull
request from holiday). I
On Thu, Sep 20, 2012 at 10:43:46AM -0400, Matt Porter wrote:
Documentation/feature-removal-schedule.txt | 10 ++
1 file changed, 10 insertions(+)
We decided at kernel summit that we'd stop bothering with this, it's
mostly just bitrot and rarely read. I guess the ASoC driver update
On Fri, Sep 21, 2012 at 01:26:43AM -0700, Olof Johansson wrote:
I'll take a look at merging it tomorrow after I've dealt with smp_ops;
if it looks reasonably conflict-free I'll pull it in. We need the
sound dependency sorted out (or agreed upon) first though.
I guess in the light of the rest
support which
correctly takes the maxburst parameter in words. This patch
puts the sdma based sound back to work.
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Probably makes sense to send via the ARM tree unless there's merge
issues?
--
To unsubscribe from this list: send the line
On Thu, Aug 04, 2011 at 05:00:18PM -0600, Stephen Warren wrote:
+ } else {
+ gpio = irq_to_gpio(irq);
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, new-name);
+ if (ret 0)
+ goto
On Thu, Aug 04, 2011 at 08:53:34PM -0700, Stephen Warren wrote:
Well, things break. This is essentially the problem I was describing in
the PATCH 0 email, just with a slightly different motivation.
There's a bunch of existing code using that idiom.
I suppose that an alternative here would be
On Fri, Aug 05, 2011 at 09:06:20AM +0100, Ben Dooks wrote:
I would say that setting the interrupt should deal with all the necessary
configuration to get that interrupt working. In the case of pretty much all
of the SoCs I have been involved with have always set the GPIO's function
to allow
On Fri, Aug 05, 2011 at 08:29:38AM -0700, Stephen Warren wrote:
Mark Brown wrote at Thursday, August 04, 2011 11:35 PM:
But it's not a bug to use a GPIO as an IRQ source, otherwise we wouldn't
have gpio_to_irq() in the first place.
2) Two pieces of unrelated code somehow accidentally get
On Thu, Oct 06, 2011 at 11:43:49PM -0700, Greg KH wrote:
On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote:
+#define EPROBE_DEFER 517 /* restart probe again after some time
*/
Can we really do this? Isn't this some user/kernel api here?
What's wrong with
Now that the driver is using dev_pm_ops the suspend operations in the
platform_driver structure won't get called so don't need to be there,
and certainly shouldn't be the same function as dev_pm_ops since the
signatures are different.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
The mmc and therefore -next currently fail to build on Samsung platforms
due to commit 666b6a (mmc: sdhci-s3c: Add pm_caps into SD/MMC host)
which added use of a new field pm_caps in the platform data without
actually adding that field to the struct. I guess there's a separate
patch floating
On Fri, Dec 02, 2011 at 12:59:42PM +, Sangwook Lee wrote:
and I found out that the following patch wasn't applied This patch
was acked by you and Thomas.
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/7832
This patch has the title : [PATCH v2 1/2] ARM: SAMSUNG: Add pm_caps
This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/mmc/host/sdhci-s3c.c | 28
1
On Mon, Jan 02, 2012 at 11:07:59AM +0900, Jaehoon Chung wrote:
On 12/30/2011 11:24 AM, Mark Brown wrote:
+#include linux/pm.h
I think this include is unnecessary.
I think you are wrong. What makes you say that you think it is not
needed?
+#ifdef CONFIG_PM
static const struct
On Tue, Jan 03, 2012 at 12:24:53AM +0900, Jae hoon Chung wrote:
2012/1/2 Mark Brown broo...@opensource.wolfsonmicro.com:
On 12/30/2011 11:24 AM, Mark Brown wrote:
+#include linux/pm.h
I think this include is unnecessary.
I think you are wrong. What makes you say that you think
On Thu, Jan 19, 2012 at 09:58:56AM +0100, Wolfram Sang wrote:
(collecting all the proper acks from maintainers) since the changes are
Which is much more likely if you send them the patches.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to
On Sat, Mar 08, 2014 at 11:55:29AM +0800, Axel Lin wrote:
The is_enabled implementation is wrong in some cases:
e.g. for pbias_mmc_omap5: enable_mask is : BIT(27) | BIT(25) | BIT(26)
However, pbias_regulator_enable() only sets BIT(27) | BIT(26) bits.
So is_enabled callback will always return
On Wed, Apr 16, 2014 at 01:15:53PM -0700, Andrew Bresticker wrote:
Not true. If !CONFIG_REGULATOR, regulator_get() and co. will return
NULL. Normally it is ok to ignore this case, but the sdhci driver
will call regulator_is_supported_voltage() on vqmmc to determine
whether 1.8V signalling
On Tue, Apr 15, 2014 at 11:14:13PM +0800, Axel Lin wrote:
commit 60e8c1e34d3a
regulator: pbias: Convert to use regmap helper functions
might also required for 3.15.
The reason is this commit implements .list_voltage and the mmc core calls
regulator_list_voltage() in
On Fri, May 23, 2014 at 11:13:44AM +0200, Hans de Goede wrote:
Thinking more about this, I would like to make one change to my
proposal, the mmc-core should only do power up of child-nodes if
they have a compatible of: simple-sdio-powerup. This way
when we add something more complex, we can
On Fri, May 23, 2014 at 01:50:40PM +0200, Hans de Goede wrote:
On 05/23/2014 01:22 PM, Mark Brown wrote:
Would it not be better to have this be something in the driver struct
rather than in the device tree? Putting a compatible in there would be
encoding details of the Linux
On Sat, May 24, 2014 at 12:06:30PM +0200, Hans de Goede wrote:
On 05/23/2014 06:27 PM, Mark Brown wrote:
On Fri, May 23, 2014 at 01:50:40PM +0200, Hans de Goede wrote:
On 05/23/2014 01:22 PM, Mark Brown wrote:
The compatible is not a Linux specific thing, it is a marking saying
On Mon, May 26, 2014 at 01:12:43PM +0200, Hans de Goede wrote:
On 05/26/2014 12:38 PM, Mark Brown wrote:
On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
until we've powered up and enumerated. The only time that there's a
problem and would need to specify exactly what
On Mon, May 26, 2014 at 06:07:18PM +0200, Ulf Hansson wrote:
I'm not sure I'm buying the idea that we have a powerup driver that's
meaningfully not part of the main device driver.
I am having a bit hard to follow the terminology here. :-) What is a
powerup driver and what is a main device
On Mon, May 26, 2014 at 07:55:47PM +0200, Hans de Goede wrote:
power-on-seq = gpio_reg_enable, usleep
1000, clk_32khz, usleep 200;
...
Where power-on-seq would tell the mmc-core exactly how to bring up the sdio
device, using standard prefixes so that the
On Tue, May 27, 2014 at 03:50:33PM +0200, Ulf Hansson wrote:
To describe the HW in DT, the embedded SDIO card (actually it could be
any type of embedded card) shall be modelled as a child node to the
mmc host in DT. Similar to what you have proposed, but with the
difference that the child
On Wed, May 28, 2014 at 01:47:50PM +0200, Tomasz Figa wrote:
Moreover, there are already WLAN chips available that can use HSIC as
their host interface and I'm not talking here about some exotic
products, but rather widely recognized products of Broadcom (BCM4335),
Marvell (88W8797) or
On Tue, Jun 03, 2014 at 12:57:52PM +0200, Ulf Hansson wrote:
On 28 May 2014 13:03, Mark Brown broo...@kernel.org wrote:
No, runtime PM isn't really fine grained - I'm talking about things
like starting and stopping individual resources or configuring them.
Are you saying that you have
On Thu, Aug 14, 2014 at 07:13:00AM -0700, Tim Kryger wrote:
On Thu, Aug 14, 2014 at 5:39 AM, Javier Martinez Canillas
Without this patch, the following warning is reported when
a FET is used as a vmmc-supply:
dwmmc_exynos 1222.mmc: Failed getting OCR mask: -22
Signed-off-by: Javier
On Thu, Aug 14, 2014 at 10:36:18PM -0700, Tim Kryger wrote:
On Thu, Aug 14, 2014 at 8:19 AM, Mark Brown broo...@kernel.org wrote:
Right, there's two things going on here. One is that as you describe we
shouldn't be putting constraints in .dtsi files if we don't know they're
OK
On Fri, Aug 15, 2014 at 09:48:43AM +0200, Javier Martinez Canillas wrote:
But now I wonder why regulator_list_voltage() even list the voltage for
fixed regulators (desc-fixed_uV) since they don't have the ability to
vary voltage. The regulator_list_voltage() documentation says:
That's because
On Fri, Aug 15, 2014 at 07:19:41AM -0700, Tim Kryger wrote:
That is a little different from my suggestion where the constraints
check is skipped when the regulator output is fixed. It effectively
does this now when the regulator itself provides the fixed voltage.
However, the checks aren't
On Sun, Aug 17, 2014 at 10:11:30AM -0700, Tim Kryger wrote:
On Fri, Aug 15, 2014 at 3:29 PM, Mark Brown broo...@kernel.org wrote:
Nobody has written suitable code, and please bear in mind that even if
the code is written there will probably be cases where it's too
expensive for whatever
From: Mark Brown broo...@linaro.org
It is possible that we may fail to set the clock rate, if we do so then
log the failure and don't bother reprogramming the IP.
Signed-off-by: Mark Brown broo...@linaro.org
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 8
On Thu, Nov 27, 2014 at 12:41:29PM +0200, Peter Ujfalusi wrote:
The machine driver has no business with the underlying dma.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Mark Brown broo...@kernel.org
signature.asc
Description: Digital signature
On Fri, Nov 28, 2014 at 12:56:33PM +0100, Ulf Hansson wrote:
On 8 November 2014 at 01:14, NeilBrown ne...@suse.de wrote:
If the regulator supplying an SDIO device is shared
with another device, the turning the regulator 'on' and 'off'
will not actually cycle power and so will not reset
On Mon, Aug 12, 2013 at 11:26:49AM +0530, Sekhar Nori wrote:
No need for a separate patch for this, just do this in the patch where
you include the two linked sets.
Can you guys please think about the CC lists you're using for these
patch serieses? I've certainly no interest in random patches
From: Mark Brown broo...@linaro.org
It is possible that we may fail to set the clock rate, if we do so then
log the failure and don't bother reprogramming the IP.
Signed-off-by: Mark Brown broo...@linaro.org
---
drivers/mmc/host/sdhci-s3c.c | 8 +++-
1 file changed, 7 insertions(+), 1
On Tue, Sep 17, 2013 at 11:29:21AM +0200, Ulf Hansson wrote:
If you want to change voltage level for eMMC, both VCC and VCCQ must
be possible to power cycle, unless you have a hw-reset wire connected
to the eMMC which is implemented by a host-ops callback. This
complicates things for SD/SDIO
1 - 100 of 210 matches
Mail list logo
