2015-01-16 16:36 GMT+08:00 Ulf Hansson :
> [...]
>
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0)
+ dev_err(dev, "Failed to pm_runtime_get_sync: %d\n", ret);
On pią, 2015-01-16 at 15:30 +0100, Paul Osmialowski wrote:
> This change addresses following problem:
>
> [2.560726] [ cut here ]
> [2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744
> lockdep_trace_alloc+0xec/0x118()
> [2.574439] DEBUG_LOCKS_WA
This change addresses following problem:
[2.560726] [ cut here ]
[2.565341] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2744
lockdep_trace_alloc+0xec/0x118()
[2.574439] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[2.579821] Modules linked in:
[
On 16 January 2015 at 13:45, Sascha Hauer wrote:
> On Fri, Jan 16, 2015 at 01:37:41PM +0100, Ulf Hansson wrote:
>> On 16 January 2015 at 12:34, Tomeu Vizoso wrote:
>> > On 16 January 2015 at 11:47, Ulf Hansson wrote:
>> >>
>> >> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *
On Fri, Jan 16, 2015 at 01:37:41PM +0100, Ulf Hansson wrote:
> On 16 January 2015 at 12:34, Tomeu Vizoso wrote:
> > On 16 January 2015 at 11:47, Ulf Hansson wrote:
> >>
> >> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
> >> {
> >> struct mmc_pwrseq_simple *pwrs
On 16 January 2015 at 12:34, Tomeu Vizoso wrote:
> On 16 January 2015 at 11:47, Ulf Hansson wrote:
>>
>> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
>> {
>> struct mmc_pwrseq_simple *pwrseq;
>> + int ret = 0;
>>
>> pwrseq = kzalloc(sizeof(struct
On Fri, Jan 16, 2015 at 07:53:08AM +1300, NeilBrown wrote:
> Also, it isn't clear to me whether the need for power/reset is a function of
> the mmc-host, or a function of the device attached to the host. I suspect
> some are needed by one, some by the other. Any by both?
Neil,
There's a horrid
On 16 January 2015 at 11:47, Ulf Hansson wrote:
>
> int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
> {
> struct mmc_pwrseq_simple *pwrseq;
> + int ret = 0;
>
> pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
> if (!pwrseq)
>
System on chip designs may specify a specific MMC power sequence. To
successfully detect an (e)MMC/SD/SDIO card, that power sequence must
be followed while initializing the card.
To be able to handle these SOC specific power sequences, let's add a
MMC power sequence interface. It provides the foll
To support SOCs which specifies specific MMC power sequences, document
some MMC DT bindings to be able to describe these hardwares.
Let's also document bindings for a simple MMC power sequence provider,
which purpose is to support a set of common properties between various
SOCs.
In this initial s
The need for reset GPIOs has several times been pointed out from
erlier posted patchsets. Especially some WLAN chips which are
attached to an SDIO interface may use a GPIO reset.
The reset GPIO is asserted at initialization and prior we start the
power up procedure. The GPIO will be de-asserted ri
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 MMC power sequence provider are
verified.
At this point we don'
Changes in v3:
Fixed comments from Mark Rutland:
- Document binding in one patch to get the big picture.
- Keep code and DT document consistent around how many GPIO resets we
support. I decided to go for one GPIO, we can extend that if needed
later on.
On 15 January 2015 at 19:53, NeilBrown wrote:
> On Thu, 15 Jan 2015 16:58:26 + Mark Rutland wrote:
>
>> Hi Ulf,
>>
>> On Wed, Jan 14, 2015 at 01:02:08PM +, Ulf Hansson wrote:
>> > The simple MMC power sequence provider, intends to supports a set of
>> > common properties between SOC desig
On 15 January 2015 at 17:58, Mark Rutland wrote:
> Hi Ulf,
>
> On Wed, Jan 14, 2015 at 01:02:08PM +, Ulf Hansson wrote:
>> The simple MMC power sequence provider, intends to supports a set of
>> common properties between SOC designs. It thus enables us to re-use the
>> same provider for severa
On 15 January 2015 at 18:04, Mark Rutland wrote:
> Hi,
>
> On Wed, Jan 14, 2015 at 01:02:10PM +, Ulf Hansson wrote:
>> The need for a reset GPIO has several times been pointed out from
>> earlier posted patchsets. Especially some WLAN chips which are
>> attached to an SDIO interface may use a
[...]
>>> + pm_runtime_set_active(&pdev->dev);
>>> + pm_runtime_enable(&pdev->dev);
>>> + ret = pm_runtime_get_sync(&pdev->dev);
>>> + if (ret < 0)
>>> + dev_err(dev, "Failed to pm_runtime_get_sync: %d\n", ret);
>>
>> As I stated earlier I think this is a stra
[...]
>>
>> Also, please don't forget to provide some perfomance numbers.
>
> I can provide some performance numbers in the last week of february or in
> the beginning of March. Is that fine ?
> Do you want the comments addressed before I publish the performance numbers
> or do you prefer the comm
18 matches
Mail list logo
