From: arend@broadcom•com (Arend van Spriel)
To: linux-arm-kernel@lists•infradead.org
Subject: RFC: representing sdio devices oob interrupt, clks, etc. in device tree
Date: Fri, 23 May 2014 16:54:59 +0200 [thread overview]
Message-ID: <537F6143.3050703@broadcom.com> (raw)
In-Reply-To: <537F4CE5.10707@redhat.com>
On 05/23/14 15:28, Hans de Goede wrote:
> Hi,
>
> On 05/23/2014 03:21 PM, Arend van Spriel wrote:
>> On 05/23/14 13:50, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 05/23/2014 01:22 PM, Mark Brown wrote:
>>>> 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 keep the simple powerup
>>>>> code in the mmc core, keeping what we've already using this working
>>>>> and the mmc core won't respond to the child nodes for more complex
>>>>> devices, so it won't conflict with more complex power-up handling
>>>>> handled by some other driver.
>>>>
>>>> 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 implementation in the DT which doesn't
>>>> seem right especially since these are details we're thinking of changing
>>>> later on.
>>>
>>> The compatible is not a Linux specific thing, it is a marking saying
>>> that something needs to take care of enabling the clks (and whatever
>>> else we will make part of the binding for this compatible), before
>>> scanning the mmc bus.
>>>
>>>> Something like have the driver set flags saying if it wants
>>>> to do complicated things.
>>>
>>> Chicken<-> egg, we won't know which driver to use before we've probed
>>> the mmc bus, and we cannot probe the bus before enabling the clks, etc.
>>
>> The approach I took with brcmfmac is that upon module init I search the DT for "brcm,bcm43xx-fmac" compatible and get the clock and/or gpio resource and enable them before registering the sdio driver. The difficulty is probably when using the driver built-in as the clocks and gpios may not be available yet and we can not rely on deferred probing in module init stage.
>
> I know, and that approach does not work, by the time the brcmfmac loads,
> the mmc core has long probed the mmc bus and decided no one is home.
Ok. That is due to the non-removable property, right? I assumed a mmc
rescan, which is (supposedly) triggered upon sdio driver registration,
would subsequently find the device.
Regards,
Arend
> Regards,
>
> Hans
>
next prev parent reply other threads:[~2014-05-23 14:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-22 9:49 RFC: representing sdio devices oob interrupt, clks, etc. in device tree Hans de Goede
2014-05-22 10:23 ` Chen-Yu Tsai
2014-05-22 11:38 ` Hans de Goede
2014-05-22 17:20 ` Tomasz Figa
2014-05-23 9:13 ` Hans de Goede
2014-05-23 11:22 ` Mark Brown
2014-05-23 11:50 ` Hans de Goede
2014-05-23 13:21 ` Arend van Spriel
2014-05-23 13:28 ` Hans de Goede
2014-05-23 14:54 ` Arend van Spriel [this message]
2014-05-24 10:10 ` Hans de Goede
2014-05-23 16:27 ` Mark Brown
2014-05-24 10:06 ` Hans de Goede
2014-05-25 12:34 ` Mark Brown
2014-05-25 19:20 ` Hans de Goede
2014-05-26 7:51 ` Arend van Spriel
2014-05-26 7:59 ` Chen-Yu Tsai
2014-05-26 8:07 ` Hans de Goede
2014-05-26 9:08 ` Arend van Spriel
2014-05-26 10:38 ` Mark Brown
2014-05-26 11:12 ` Hans de Goede
2014-05-26 14:22 ` Mark Brown
2014-05-26 14:59 ` Hans de Goede
2014-05-26 16:07 ` Ulf Hansson
2014-05-26 16:14 ` Mark Brown
2014-05-26 17:55 ` Hans de Goede
2014-05-27 13:50 ` Ulf Hansson
2014-05-27 17:53 ` Mark Brown
2014-05-27 18:55 ` Olof Johansson
2014-05-27 20:27 ` Arend van Spriel
2014-05-28 8:43 ` Ulf Hansson
2014-05-28 8:19 ` Ulf Hansson
2014-05-28 11:03 ` Mark Brown
2014-06-03 10:57 ` Ulf Hansson
2014-06-04 15:55 ` Mark Brown
2014-06-09 14:07 ` Ulf Hansson
2014-05-28 9:42 ` Hans de Goede
2014-05-28 10:12 ` Arend van Spriel
2014-05-28 10:27 ` Hans de Goede
2014-05-28 11:47 ` Tomasz Figa
2014-05-28 16:43 ` Mark Brown
2014-05-30 8:17 ` Hans de Goede
2014-06-03 10:14 ` Ulf Hansson
2014-06-03 11:07 ` Hans de Goede
2014-06-03 12:58 ` Ulf Hansson
2014-06-03 13:06 ` Hans de Goede
2014-06-03 13:28 ` Ulf Hansson
2014-05-27 15:47 ` Mark Brown
2014-05-23 13:34 ` Ulf Hansson
2014-05-23 16:47 ` Olof Johansson
2014-05-24 10:09 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=537F6143.3050703@broadcom.com \
--to=arend@broadcom$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox