On Sat, Jun 11, 2011 at 5:33 AM, zhangfei gao wrote:
> If you power down and up the device, then IO reset is not needed and
> 8686 can process host init sequence correctly.
Thanks, that's what I thought.
Daniel, this ultimately means that whenever sending a reset is
required to re-init the 8686,
On Fri, Jun 10, 2011 at 12:28 PM, Ohad Ben-Cohen wrote:
> Hi Zhangfei,
>
> On Fri, Jun 10, 2011 at 5:02 AM, zhangfei gao wrote:
>> Here is answer got from the sd8686 maintainer.
>>
>> For 8686, the SDIO state machine can only handle init sequence (CMD5,
>> 5, 3, 7) from host once. If host sends a
Hi Zhangfei,
On Fri, Jun 10, 2011 at 5:02 AM, zhangfei gao wrote:
> Here is answer got from the sd8686 maintainer.
>
> For 8686, the SDIO state machine can only handle init sequence (CMD5,
> 5, 3, 7) from host once. If host sends another init sequence, it will
> not be able to handle CMD5 and cau
On Wed, Jun 8, 2011 at 10:34 PM, Ohad Ben-Cohen wrote:
> Hi Bing,
>
> On Sat, Jun 4, 2011 at 1:52 AM, Ohad Ben-Cohen wrote:
>> On Sat, Jun 4, 2011 at 1:28 AM, Bing Zhao wrote:
>>> "CMD5 Arg=0" refers to the very first CMD5 sent from host during
>>> initialization sequence.
>>> This is required
Hi Bing,
On Sat, Jun 4, 2011 at 1:52 AM, Ohad Ben-Cohen wrote:
> On Sat, Jun 4, 2011 at 1:28 AM, Bing Zhao wrote:
>> "CMD5 Arg=0" refers to the very first CMD5 sent from host during
>> initialization sequence.
>> This is required because our state machine always expects two CMD5 from host
>> (
Hi Ohad,
Am 04.06.2011 00:52, schrieb Ohad Ben-Cohen:
> (cc'ing Arnd Hannermann)
>
> On Sat, Jun 4, 2011 at 1:28 AM, Bing Zhao wrote:
>> "CMD5 Arg=0" refers to the very first CMD5 sent from host during
>> initialization sequence.
>> This is required because our state machine always expects two
On Tue, Jun 7, 2011 at 5:34 PM, Arnd Hannemann wrote:
> Sorry, I don't have the hardware anymore so I'm not able to check this.
Ok, thanks for the reply !
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo i
(cc'ing Arnd Hannermann)
On Sat, Jun 4, 2011 at 1:28 AM, Bing Zhao wrote:
> "CMD5 Arg=0" refers to the very first CMD5 sent from host during
> initialization sequence.
> This is required because our state machine always expects two CMD5 from host
> (5, 5, 3, 7, ...).
Great, thanks for confirmi
> On Thu, Jun 2, 2011 at 11:39 AM, Bing Zhao wrote:
>>> If we power down the sd8686, and power it up again, without toggling
>>> the reset pin at all (e.g. keep it always high), will the card work ?
>>
>> Yes. The card should work without toggling the reset pin.
>
> Thanks.
>
> Just for closure-
On Thu, Jun 2, 2011 at 11:39 AM, Bing Zhao wrote:
>> If we power down the sd8686, and power it up again, without toggling
>> the reset pin at all (e.g. keep it always high), will the card work ?
>
> Yes. The card should work without toggling the reset pin.
Thanks.
Just for closure-sake, can you
Hi Ohad,
> If we power down the sd8686, and power it up again, without toggling
> the reset pin at all (e.g. keep it always high), will the card work ?
Yes. The card should work without toggling the reset pin.
Regards,
Bing--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" i
Hi Zhangfei, Bing,
On Mon, May 30, 2011 at 2:04 PM, zhangfei gao wrote:
> sd8686 requires two pins to control power, PDn and RESETn.
> To enable sd8686, PDn and RESETn should both set high.
> To disable sd8686, PDn should be set low.
If we power down the sd8686, and power it up again, without to
On Mon, May 30, 2011 at 3:32 AM, Ohad Ben-Cohen wrote:
> On Mon, May 30, 2011 at 10:01 AM, Daniel Drake wrote:
>> On 30 May 2011 07:52, Ohad Ben-Cohen wrote:
>>> Last we talked, we found out runtime PM didn't work because the sd8686
>>> required an additional manipulation of an external reset gp
On Mon, May 30, 2011 at 10:01 AM, Daniel Drake wrote:
> On 30 May 2011 07:52, Ohad Ben-Cohen wrote:
>> Last we talked, we found out runtime PM didn't work because the sd8686
>> required an additional manipulation of an external reset gpio line,
>> and that the only reason OLPC could power it down
On 30 May 2011 07:52, Ohad Ben-Cohen wrote:
> On Sun, May 29, 2011 at 7:21 PM, Daniel Drake wrote:
>> It's certainly possible that there's something weird about the
>> hardware in question, but we *are* able to successfully power down and
>> up the card with a hacky rfkill driver that calls mmc_s
Hi Daniel,
On Sun, May 29, 2011 at 7:21 PM, Daniel Drake wrote:
> It's certainly possible that there's something weird about the
> hardware in question, but we *are* able to successfully power down and
> up the card with a hacky rfkill driver that calls mmc_stop_host /
> mmc_start_host.
Are we t
Hi Ohad,
On 31 October 2010 19:06, Ohad Ben-Cohen wrote:
> OK, as expected.
>
> So to summarize:
> 1. Card is powered up at boot, and successfully initialized
> 2. After mmc + sdio devices are added to the device tree, power is
> (seemingly) taken down by runtime PM
> 3. When the driver is loaded
On Tue, Nov 16, 2010 at 4:29 PM, Daniel Drake wrote:
> On 16 November 2010 13:22, Ohad Ben-Cohen wrote:
>> Just to update the list, the problem with the XO-1.5 was because the
>> sd8686 has an external reset gpio line which is currently being
>> manipulated manually by an out-of-tree kernel patch
On 16 November 2010 13:22, Ohad Ben-Cohen wrote:
> Just to update the list, the problem with the XO-1.5 was because the
> sd8686 has an external reset gpio line which is currently being
> manipulated manually by an out-of-tree kernel patch:
>
> http://dev.laptop.org/git/olpc-2.6/commit/?h=olpc-2.6
On Wed, 17 Nov 2010, Ohad Ben-Cohen wrote:
> On Wed, Nov 17, 2010 at 8:46 AM, Mike Rapoport wrote:
> > On our platforms we just keep it powered on after boot with the reset line
> > held
> > high. (e.g. arch/arm/mach-pxa/cm-x300.c, arch/arm/mach-omap/board-cm-t35.c).
> > We don't bother much for
On Wed, Nov 17, 2010 at 8:46 AM, Mike Rapoport wrote:
> On our platforms we just keep it powered on after boot with the reset line
> held
> high. (e.g. arch/arm/mach-pxa/cm-x300.c, arch/arm/mach-omap/board-cm-t35.c).
> We don't bother much for power savings, though.
Thanks, Mike !
This paves th
On 11/16/10 16:49, Ohad Ben-Cohen wrote:
> On Tue, Nov 16, 2010 at 4:29 PM, Daniel Drake wrote:
>> On 16 November 2010 13:22, Ohad Ben-Cohen wrote:
>>> Just to update the list, the problem with the XO-1.5 was because the
>>> sd8686 has an external reset gpio line which is currently being
>>> mani
On Tue, Nov 16, 2010 at 11:16 PM, Arnd Hannemann wrote:
> Yes, just plugged it in. No extra wire whatsover.
I wonder - when you suspend/resume the host, with that card plugged
in, do you see any errors (particularly in the resume phase) ?
After suspend/resume was completed, can you still work wi
Am 16.11.2010 21:58, schrieb Ohad Ben-Cohen:
> On Tue, Nov 16, 2010 at 7:17 PM, Arnd Hannemann
> >> > Its an AP4 (SH7372) evaluation
> board from renesas. It has an SD-Slot,
>
>> where you plug the SDIO card into it. No special wiring or something
>> like this. So I doubt some external GPIOs ar
On Tue, Nov 16, 2010 at 7:17 PM, Arnd Hannemann
>> > Its an AP4 (SH7372) evaluation
board from renesas. It has an SD-Slot,
> where you plug the SDIO card into it. No special wiring or something
> like this. So I doubt some external GPIOs are involved.
> I have no idea how the wifi card gets its po
Am 16.11.2010 14:22, schrieb Ohad Ben-Cohen:
> On Mon, Nov 1, 2010 at 10:27 AM, Ohad Ben-Cohen wrote:
>
>> On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen wrote:
>> ...
>>
>>> we need to support boards with controllers/cards
>>> which we can't power off in runtime.
>>>
>>> On such boards,
On Mon, Nov 1, 2010 at 10:27 AM, Ohad Ben-Cohen wrote:
> On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen wrote:
> ...
>> we need to support boards with controllers/cards
>> which we can't power off in runtime.
>>
>> On such boards, the right thing to do would be to disable runtime PM
>> altogeth
On Sun, 7 Nov 2010, Daniel Drake wrote:
> On 7 November 2010 01:48, Nicolas Pitre wrote:
> > Couldn't you implement this any other way? This seems to be a really
> > bad strategy for this IMHO.
>
> What's so bad about it?
> Any suggestions?
If you want rfkill functionality, then maybe that wou
On Sun, Nov 7, 2010 at 12:51 PM, Daniel Drake wrote:
> If you take the interface down, the card is still powered up in some
> way.
With SDIO runtime pm support, it shouldn't be.
> When I asked the hardware guy he said it was entirely controlled by
> the normal SD power pin, but a full card reset
On 7 November 2010 10:42, Ohad Ben-Cohen wrote:
> Good. Did it also solve the 1st issue you had ?
Yes.
>> But, what you point out is quite interesting.
>> We currently have a (not-yet-upstream) rfkill driver for the XO-1.5,
>> which we also put in place for power saving reasons.
>
> Can you plea
On Sat, Nov 6, 2010 at 11:19 PM, Daniel Drake wrote:
> Thanks.
> It solves the problem.
Good. Did it also solve the 1st issue you had ?
Anyway I'm still interested to reproduce that crash. No reason to get
a kernel panic whatsoever.
>
> But, what you point out is quite interesting.
> We current
On 7 November 2010 01:48, Nicolas Pitre wrote:
> Couldn't you implement this any other way? This seems to be a really
> bad strategy for this IMHO.
What's so bad about it?
Any suggestions?
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to
On Sat, 6 Nov 2010, Daniel Drake wrote:
> On 1 November 2010 08:27, Ohad Ben-Cohen wrote:
> >> On such boards, the right thing to do would be to disable runtime PM
> >> altogether.
> >
> > The patch below (/attached) should trivially fix the problem - can you
> > please check it out ?
>
> Thank
On 1 November 2010 08:27, Ohad Ben-Cohen wrote:
>> On such boards, the right thing to do would be to disable runtime PM
>> altogether.
>
> The patch below (/attached) should trivially fix the problem - can you
> please check it out ?
Thanks.
It solves the problem.
But, what you point out is qui
Hi Daniel,
On Sun, Oct 31, 2010 at 9:06 PM, Ohad Ben-Cohen wrote:
...
> we need to support boards with controllers/cards
> which we can't power off in runtime.
>
> On such boards, the right thing to do would be to disable runtime PM
> altogether.
The patch below (/attached) should trivially fix
On Sun, Oct 31, 2010 at 6:24 PM, Daniel Drake wrote:
> On 31 October 2010 16:16, Ohad Ben-Cohen wrote:
>> Just to make sure - on an older kernel (that doesn't have SDIO runtime
>> pm), the card is powered on at this stage (this info will help me rule
>> out some corner cases) ?
>
> Looks that way
On 31 October 2010 16:16, Ohad Ben-Cohen wrote:
> Just to make sure - on an older kernel (that doesn't have SDIO runtime
> pm), the card is powered on at this stage (this info will help me rule
> out some corner cases) ?
Looks that way. Same test, after reverting your patches:
clock: 25
On Sun, Oct 31, 2010 at 5:57 PM, Daniel Drake wrote:
>> cat /sys/kernel/debug/mmc1/ios
>
> clock: 0 Hz
> vdd: 0 (invalid)
> bus mode: 1 (open drain)
> chip select: 0 (don't care)
> power mode: 0 (off)
> bus width: 0 (1 bits)
> timing spec: 0 (legacy)
Good.
On 31 October 2010 15:27, Ohad Ben-Cohen wrote:
> Can you please tell me the output of the following line
> (after boot, but before you load the driver):
>
> cat /sys/kernel/debug/mmc1/ios
clock: 0 Hz
vdd:0 (invalid)
bus mode: 1 (open drain)
chip select:0 (don't car
On Sun, Oct 31, 2010 at 5:21 PM, Daniel Drake wrote:
> The power can be controlled by the regular SD power pin. There is no
> GPIO to control it.
OK, Good.
Can you please tell me the output of the following line
(after boot, but before you load the driver):
cat /sys/kernel/debug/mmc1/ios
(obvi
On 31 October 2010 15:16, Ohad Ben-Cohen wrote:
> No, I'm asking a more general question about the sd8686 and the XO-1.5.
> How can one control the power to the sd8686 ? Is it always on and
> can't be controlled ? Is there a GPIO that controls it ? or any other
> mean to control its power ?
The p
On 31 October 2010 15:16, Ohad Ben-Cohen wrote:
> No, I'm asking a more general question about the sd8686 and the XO-1.5.
> How can one control the power to the sd8686 ? Is it always on and
> can't be controlled ? Is there a GPIO that controls it ? or any other
> mean to control its power ?
The p
On Sun, Oct 31, 2010 at 5:10 PM, Daniel Drake wrote:
> On 31 October 2010 15:08, Ohad Ben-Cohen wrote:
>> Quick question - how did you manage the power to the sd8686 ? Was it
>> possible to power it down after boot or was it always kept high ?
>
> I didn't do anything except boot then try and loa
On 31 October 2010 15:08, Ohad Ben-Cohen wrote:
> Quick question - how did you manage the power to the sd8686 ? Was it
> possible to power it down after boot or was it always kept high ?
I didn't do anything except boot then try and load the module. Does
that answer the question?
Daniel
--
To un
On Sun, Oct 31, 2010 at 4:55 PM, Daniel Drake wrote:
> /*
> * For native busses: set card RCA and quit open drain mode.
> */
> if (!powered_resume && !mmc_host_is_spi(host)) {
> err = mmc_send_relative_addr(host, &card->rca);
>
> This returns -110
Qui
On 31 October 2010 14:42, Ohad Ben-Cohen wrote:
> I guess the error comes from mmc_sdio_init_card() - can you please
> check out what exactly triggers it inside that function (just put some
> printk's there..) ?
/*
* For native busses: set card RCA and quit open drain mode.
Hi Daniel,
On Sun, Oct 31, 2010 at 4:29 PM, Daniel Drake wrote:
> I'm running linus master and can't load the libertas module for the
> sd8686 wifi hardware in the OLPC XO-1.5 laptop.
> Probe fails with -16.
That's why I asked you if this scenario works in the other thread.
It's probably the sam
Hi,
I'm running linus master and can't load the libertas module for the
sd8686 wifi hardware in the OLPC XO-1.5 laptop.
Probe fails with -16.
dmesg and config:
http://dev.laptop.org/~dsd/20101031/dmesg-sdio-probe-fail.txt
http://dev.laptop.org/~dsd/20101031/config-sdio-probe-fail.txt
I've done s
48 matches
Mail list logo
