All of lore.kernel.org
 help / color / mirror / Atom feed
From: Enric Balletbo Serra <eballetbo@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "Javier Martinez Canillas" <javier@osg.samsung.com>,
	linux-kernel@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Agustí Fontquerni i Gorchs" <afontquerni@iseebcn.com>,
	"Pau Pajuel" <ppajuel@gmail.com>
Subject: Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init
Date: Fri, 4 Dec 2015 15:39:35 +0100	[thread overview]
Message-ID: <CAFqH_536_sG7fju=u39aMKmzXt8KDCxU1-dFM03H060zbh5qxw@mail.gmail.com> (raw)
In-Reply-To: <20151203192719.GZ23396@atomide.com>

2015-12-03 20:27 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> * Javier Martinez Canillas <javier@osg.samsung.com> [151203 10:29]:
>> Hello Tony,
>>
>> On 12/03/2015 03:16 PM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas <javier@osg.samsung.com> [151203 10:03]:
>> >> Hello,
>> >>
>> >> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
>> >> Device Tree to use the MMC power sequence provider to initialize the SDIO
>> >> WiFi chip instead of using fake fixed regulators to just toggle the Reset
>> >> and Power pins in the chip.
>> >>
>> >> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
>> >> is the same with regard to the SDIO WiFi so it should be safe to land too.
>> >>
>> >> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
>> >> using a different WiFi chip (wlcore instead of libertas) than the one in
>> >> the board I've access to test so I preferred to leave those untouched.
>> >
>> > Do you have some solution for the start-up latency issue?
>> >
>>
>> No, I don't and that's one of the reasons why I didn't want to touch the
>> DTS that have the wlcore chip.
>>
>> The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a
>> startup-delay-us property in the regulator for the WLAN_EN pin as is
>> the case for the IGEPv5 DTS but I don't know if those DTS are just wrong.
>
> OK
>
>> The DTS for the igep0020 and igep0030 that have the libertas chip,
>> did have a startup-delay-us for the WIFI_PDN but using the GPIOs
>> for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is
>> enough to make the SDIO chip reset, be enumerated and WiFi to work
>> correctly so I don't know if that is really needed or is just a bad
>> description in the DTS.
>
> Hmm OK.
>
>> Since is working for the boards with the libertas chip, I preferred
>> to remove the DTS hack but left the boards with wlcore chip since
>> you said the startup-delay-us is needed there (but probably we should
>> add to the regulators in the boards that don't have it then).
>
> OK
>
> Thanks,
>
> Tony

I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.

Thanks,
    Enric

WARNING: multiple messages have this Message-ID (diff)
From: Enric Balletbo Serra <eballetbo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Cc: "Javier Martinez Canillas"
	<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"Agustí Fontquerni i Gorchs"
	<afontquerni-VIneJrwqLopBDgjK7y7TUQ@public.gmane.org>,
	"Pau Pajuel" <ppajuel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init
Date: Fri, 4 Dec 2015 15:39:35 +0100	[thread overview]
Message-ID: <CAFqH_536_sG7fju=u39aMKmzXt8KDCxU1-dFM03H060zbh5qxw@mail.gmail.com> (raw)
In-Reply-To: <20151203192719.GZ23396-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

2015-12-03 20:27 GMT+01:00 Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> * Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> [151203 10:29]:
>> Hello Tony,
>>
>> On 12/03/2015 03:16 PM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> [151203 10:03]:
>> >> Hello,
>> >>
>> >> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
>> >> Device Tree to use the MMC power sequence provider to initialize the SDIO
>> >> WiFi chip instead of using fake fixed regulators to just toggle the Reset
>> >> and Power pins in the chip.
>> >>
>> >> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
>> >> is the same with regard to the SDIO WiFi so it should be safe to land too.
>> >>
>> >> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
>> >> using a different WiFi chip (wlcore instead of libertas) than the one in
>> >> the board I've access to test so I preferred to leave those untouched.
>> >
>> > Do you have some solution for the start-up latency issue?
>> >
>>
>> No, I don't and that's one of the reasons why I didn't want to touch the
>> DTS that have the wlcore chip.
>>
>> The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a
>> startup-delay-us property in the regulator for the WLAN_EN pin as is
>> the case for the IGEPv5 DTS but I don't know if those DTS are just wrong.
>
> OK
>
>> The DTS for the igep0020 and igep0030 that have the libertas chip,
>> did have a startup-delay-us for the WIFI_PDN but using the GPIOs
>> for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is
>> enough to make the SDIO chip reset, be enumerated and WiFi to work
>> correctly so I don't know if that is really needed or is just a bad
>> description in the DTS.
>
> Hmm OK.
>
>> Since is working for the boards with the libertas chip, I preferred
>> to remove the DTS hack but left the boards with wlcore chip since
>> you said the startup-delay-us is needed there (but probably we should
>> add to the regulators in the boards that don't have it then).
>
> OK
>
> Thanks,
>
> Tony

I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.

Thanks,
    Enric
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: eballetbo@gmail.com (Enric Balletbo Serra)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init
Date: Fri, 4 Dec 2015 15:39:35 +0100	[thread overview]
Message-ID: <CAFqH_536_sG7fju=u39aMKmzXt8KDCxU1-dFM03H060zbh5qxw@mail.gmail.com> (raw)
In-Reply-To: <20151203192719.GZ23396@atomide.com>

2015-12-03 20:27 GMT+01:00 Tony Lindgren <tony@atomide.com>:
> * Javier Martinez Canillas <javier@osg.samsung.com> [151203 10:29]:
>> Hello Tony,
>>
>> On 12/03/2015 03:16 PM, Tony Lindgren wrote:
>> > * Javier Martinez Canillas <javier@osg.samsung.com> [151203 10:03]:
>> >> Hello,
>> >>
>> >> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030)
>> >> Device Tree to use the MMC power sequence provider to initialize the SDIO
>> >> WiFi chip instead of using fake fixed regulators to just toggle the Reset
>> >> and Power pins in the chip.
>> >>
>> >> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module
>> >> is the same with regard to the SDIO WiFi so it should be safe to land too.
>> >>
>> >> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due
>> >> using a different WiFi chip (wlcore instead of libertas) than the one in
>> >> the board I've access to test so I preferred to leave those untouched.
>> >
>> > Do you have some solution for the start-up latency issue?
>> >
>>
>> No, I don't and that's one of the reasons why I didn't want to touch the
>> DTS that have the wlcore chip.
>>
>> The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a
>> startup-delay-us property in the regulator for the WLAN_EN pin as is
>> the case for the IGEPv5 DTS but I don't know if those DTS are just wrong.
>
> OK
>
>> The DTS for the igep0020 and igep0030 that have the libertas chip,
>> did have a startup-delay-us for the WIFI_PDN but using the GPIOs
>> for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is
>> enough to make the SDIO chip reset, be enumerated and WiFi to work
>> correctly so I don't know if that is really needed or is just a bad
>> description in the DTS.
>
> Hmm OK.
>
>> Since is working for the boards with the libertas chip, I preferred
>> to remove the DTS hack but left the boards with wlcore chip since
>> you said the startup-delay-us is needed there (but probably we should
>> add to the regulators in the boards that don't have it then).
>
> OK
>
> Thanks,
>
> Tony

I guess will be interesting cc'ing the ISEE people. Added Agusti and Pau.

Thanks,
    Enric

  reply	other threads:[~2015-12-04 14:39 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 18:02 [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init Javier Martinez Canillas
2015-12-03 18:02 ` Javier Martinez Canillas
2015-12-03 18:02 ` Javier Martinez Canillas
2015-12-03 18:02 ` [PATCH 1/2] ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi Javier Martinez Canillas
2015-12-03 18:02   ` Javier Martinez Canillas
2015-12-04 14:36   ` Enric Balletbo Serra
2015-12-04 14:36     ` Enric Balletbo Serra
2015-12-04 14:36     ` Enric Balletbo Serra
2015-12-03 18:02 ` [PATCH 2/2] ARM: dts: omap3-igep0030: " Javier Martinez Canillas
2015-12-03 18:02   ` Javier Martinez Canillas
2015-12-04 14:37   ` Enric Balletbo Serra
2015-12-04 14:37     ` Enric Balletbo Serra
2015-12-04 14:37     ` Enric Balletbo Serra
2015-12-03 18:16 ` [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init Tony Lindgren
2015-12-03 18:16   ` Tony Lindgren
2015-12-03 18:16   ` Tony Lindgren
2015-12-03 18:28   ` Javier Martinez Canillas
2015-12-03 18:28     ` Javier Martinez Canillas
2015-12-03 19:27     ` Tony Lindgren
2015-12-03 19:27       ` Tony Lindgren
2015-12-03 19:27       ` Tony Lindgren
2015-12-04 14:39       ` Enric Balletbo Serra [this message]
2015-12-04 14:39         ` Enric Balletbo Serra
2015-12-04 14:39         ` Enric Balletbo Serra
2015-12-08  0:14         ` Tony Lindgren
2015-12-08  0:14           ` Tony Lindgren
2015-12-08  0:14           ` Tony Lindgren
2015-12-09 14:26 Agustí Fontquerni
2015-12-09 14:26 ` Agustí Fontquerni

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='CAFqH_536_sG7fju=u39aMKmzXt8KDCxU1-dFM03H060zbh5qxw@mail.gmail.com' \
    --to=eballetbo@gmail.com \
    --cc=afontquerni@iseebcn.com \
    --cc=devicetree@vger.kernel.org \
    --cc=javier@osg.samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ppajuel@gmail.com \
    --cc=tony@atomide.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.