On 4 June 2014 17:55, Mark Brown wrote:
> On Tue, Jun 03, 2014 at 12:57:52PM +0200, Ulf Hansson wrote:
>> On 28 May 2014 13:03, Mark Brown wrote:
>
>> > No, runtime PM isn't really fine grained - I'm talking about things
>> > like starting and stopping individual resources or configuring them.
>
On Tue, Jun 03, 2014 at 12:57:52PM +0200, Ulf Hansson wrote:
> On 28 May 2014 13:03, Mark Brown 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 several levels of
[snip]
>>
>> Why do we need to put the sdio functions devices in DT?
>
> To define sdio function specific non probable info, such as oob irqs,
> also see the "mmc: Add SDIO function devicetree subnode parsing" patch-set
> of which I send v3 this morning.
Yes, of course - makes sense.
[snip]
>>>
Hi,
On 06/03/2014 02:58 PM, Ulf Hansson wrote:
> On 3 June 2014 13:07, Hans de Goede wrote:
>> Hi,
>>
>> On 06/03/2014 12:14 PM, Ulf Hansson wrote:
>>> On 28 May 2014 11:42, Hans de Goede wrote:
>>
>>
>>
> If the mmc_of_parse() returns -EPROBE_DEFER, the mmc host driver will
> return th
On 3 June 2014 13:07, Hans de Goede wrote:
> Hi,
>
> On 06/03/2014 12:14 PM, Ulf Hansson wrote:
>> On 28 May 2014 11:42, Hans de Goede wrote:
>
>
>
If the mmc_of_parse() returns -EPROBE_DEFER, the mmc host driver will
return the same error code from it's ->probe(). This provides us wit
Hi,
On 06/03/2014 12:14 PM, Ulf Hansson wrote:
> On 28 May 2014 11:42, Hans de Goede wrote:
>>> If the mmc_of_parse() returns -EPROBE_DEFER, the mmc host driver will
>>> return the same error code from it's ->probe(). This provides us with
>>> the ability of waiting for the "powerup driver" to
On 28 May 2014 13:03, Mark Brown wrote:
> On Wed, May 28, 2014 at 10:19:11AM +0200, Ulf Hansson wrote:
>> On 27 May 2014 19:53, Mark Brown wrote:
>
>> > This then either conflicts with cases where we need to describe the
>> > actual contents of the slot with a compatible string or means that the
On 28 May 2014 11:42, Hans de Goede wrote:
> Hi,
>
> On 05/27/2014 03:50 PM, Ulf Hansson wrote:
>> [snip]
>>
I am having a bit hard to follow the terminology here. :-) What is a
"powerup driver" and what is a "main device driver" in this context?
I had a slide which I used at a
Hi,
On 05/28/2014 06:43 PM, Mark Brown wrote:
> On Wed, May 28, 2014 at 01:47:50PM +0200, Tomasz Figa wrote:
>> IMHO, all we need here is a way to tell the MMC (or HSIC) core when to
>> look for a new device and when not (e.g. power down the host controller
>> completely). Anything else, includ
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 Qua
I'm following this discussion continuously, but (un)fortunately I'm on
vacation right now and don't have much time to work on this, so sorry
for a very selective reply.
On 28.05.2014 11:42, Hans de Goede wrote:
> Hi,
>
> On 05/27/2014 03:50 PM, Ulf Hansson wrote:
>> [snip]
>>
>> Powerup driver's
On Wed, May 28, 2014 at 10:19:11AM +0200, Ulf Hansson wrote:
> On 27 May 2014 19:53, Mark Brown wrote:
> > This then either conflicts with cases where we need to describe the
> > actual contents of the slot with a compatible string or means that the
> > SDIO driver needs to handle powerup sequenc
Hi,
On 05/28/2014 12:12 PM, Arend van Spriel wrote:
Yes, although I must admit that have not thought about how to deal with
slots, I've no experience with the mmc slots concept at all, or is slot
just a different name for sdio function ?
>>>
>>> Some mmc hosts may support more th
On 05/28/14 11:42, Hans de Goede wrote:
Hi,
On 05/27/2014 03:50 PM, Ulf Hansson wrote:
[snip]
I am having a bit hard to follow the terminology here. :-) What is a
"powerup driver" and what is a "main device driver" in this context?
I had a slide which I used at a mmc subsystem crash course r
Hi,
On 05/27/2014 03:50 PM, Ulf Hansson wrote:
> [snip]
>
>>> I am having a bit hard to follow the terminology here. :-) What is a
>>> "powerup driver" and what is a "main device driver" in this context?
>>>
>>> I had a slide which I used at a mmc subsystem crash course recently,
>>> please have
On 27 May 2014 20:55, Olof Johansson wrote:
> On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote:
>> 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
On 27 May 2014 19:53, Mark Brown wrote:
> 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 prop
On 05/27/14 20:55, Olof Johansson wrote:
On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote:
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
On Tue, May 27, 2014 at 06:53:26PM +0100, Mark Brown wrote:
> 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. Simila
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 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 tha
[snip]
>> I am having a bit hard to follow the terminology here. :-) What is a
>> "powerup driver" and what is a "main device driver" in this context?
>>
>> I had a slide which I used at a mmc subsystem crash course recently,
>> please have a look - hopefully this will help us to sort out this.
>>
Hi,
On 05/26/2014 06:07 PM, Ulf Hansson wrote:
> [snip]
>
>>>
>>> We don't typically actually bind multiple compatibles for a single
>>> device. We've got a bunch of options we can choose from but we
>>> generally pick the one that matches best and ignore the others.
>>>
Where as what you'r
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 "ma
[snip]
>>
>> We don't typically actually bind multiple compatibles for a single
>> device. We've got a bunch of options we can choose from but we
>> generally pick the one that matches best and ignore the others.
>>
>>> Where as what you're suggesting is to always pick driver foo, unless
>>> driv
Hi,
On 05/26/2014 04:22 PM, Mark Brown wrote:
> 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
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
Hi,
On 05/26/2014 12:38 PM, Mark Brown wrote:
> On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
>> Also the mmc people are very much against specifying a driver, as that is
>> something which should be probed not specified. I agree with them I've
>> already seen boards were more
On Sun, May 25, 2014 at 09:20:52PM +0200, Hans de Goede wrote:
> On 05/25/2014 02:34 PM, Mark Brown wrote:
> > Why is that a problem - if we have no driver for the device there is no
> > point in powering it up in the first place is there?
> Well the driver may show up later, so if we only do the
On 05/26/14 10:07, Hans de Goede wrote:
Hi,
On 05/26/2014 09:59 AM, Chen-Yu Tsai wrote:
On Mon, May 26, 2014 at 3:51 PM, Arend van Spriel wrote:
+ Russell
Hi Hans,
I recalled a recent patchset from Russell King. He was working on i.MX6
platform with brcmfmac device and ended reworking s
Hi,
On 05/26/2014 09:59 AM, Chen-Yu Tsai wrote:
> On Mon, May 26, 2014 at 3:51 PM, Arend van Spriel wrote:
>> + Russell
>> Hi Hans,
>>
>> I recalled a recent patchset from Russell King. He was working on i.MX6
>> platform with brcmfmac device and ended reworking sdhci/mmc host controller
>> co
On Mon, May 26, 2014 at 3:51 PM, Arend van Spriel wrote:
> + Russell
>
>
> On 05/25/14 21:20, Hans de Goede wrote:
>>
>> Hi,
>>
>> On 05/25/2014 02:34 PM, Mark Brown wrote:
>>>
>>> On Sat, May 24, 2014 at 12:06:30PM +0200, Hans de Goede wrote:
On 05/23/2014 06:27 PM, Mark Brown wrote:
>>
+ Russell
On 05/25/14 21:20, Hans de Goede wrote:
Hi,
On 05/25/2014 02:34 PM, Mark Brown wrote:
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, Mar
Hi,
On 05/25/2014 02:34 PM, Mark Brown wrote:
> 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 no
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
> >
Hi,
On 05/23/2014 04:54 PM, Arend van Spriel wrote:
> 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:44
Hi,
On 05/23/2014 06:47 PM, Olof Johansson wrote:
> On Thu, May 22, 2014 at 07:20:55PM +0200, Tomasz Figa wrote:
>> Hi,
>>
>>
>> On 22.05.2014 13:38, Hans de Goede wrote:
>>> On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
>>
>> snip
>>
>
Hi,
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:
>
>>> Would it not be better to have this be something in the driver struct
>>> rather than in the device tree? Putting a compatible in ther
On Thu, May 22, 2014 at 07:20:55PM +0200, Tomasz Figa wrote:
> Hi,
>
>
> On 22.05.2014 13:38, Hans de Goede wrote:
> > On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
> >> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
>
> snip
>
> >>> I've been thinking a bit about this, and it is a non tr
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 impleme
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 on
On 22 May 2014 19:20, Tomasz Figa wrote:
> Hi,
>
>
> On 22.05.2014 13:38, Hans de Goede wrote:
>> On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
>>> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
>
> snip
>
I've been thinking a bit about this, and it is a non trivial problem since
s
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
prop
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 com
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-poweru
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
Hi,
On 05/22/2014 07:20 PM, Tomasz Figa wrote:
> Hi,
>
>
> On 22.05.2014 13:38, Hans de Goede wrote:
>> On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
>>> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
>
> snip
>
I've been thinking a bit about this, and it is a non trivial problem si
Hi,
On 22.05.2014 13:38, Hans de Goede wrote:
> On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
>> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
snip
>>> I've been thinking a bit about this, and it is a non trivial problem since
>>> sdio devices are normally instantiated when probed, unlik
Hi,
On 05/22/2014 12:23 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
>> Hi All,
>>
>> Arend asked me to test these 2 patches for adding devicetree support to
>> brcmfmac sdio devices:
>> "dt: bindings: add bindings for Broadcom bcm43xx sdio devices"
>>
Hi,
On Thu, May 22, 2014 at 5:49 PM, Hans de Goede wrote:
> Hi All,
>
> Arend asked me to test these 2 patches for adding devicetree support to
> brcmfmac sdio devices:
> "dt: bindings: add bindings for Broadcom bcm43xx sdio devices"
> "brcmfmac: add device tree support for SDIO devices"
> https
Hi All,
Arend asked me to test these 2 patches for adding devicetree support to
brcmfmac sdio devices:
"dt: bindings: add bindings for Broadcom bcm43xx sdio devices"
"brcmfmac: add device tree support for SDIO devices"
https://groups.google.com/forum/#!msg/linux-sunxi/Zph6zDTnAcw/_-wOO-gnIuQJ
Ge
51 matches
Mail list logo
