Hi,

On 22-12-15 05:29, Chen-Yu Tsai wrote:
On Tue, Dec 22, 2015 at 3:36 AM, Hans de Goede <hdego...@redhat.com> wrote:
Hi,

On 21-12-15 17:11, Maxime Ripard wrote:

Hi,x

On Mon, Dec 21, 2015 at 11:46:18AM +0100, Hans de Goede wrote:

On the side, any thoughts on how to handle the differences between
various "Q8"
tablets, like different I2C-based sensors and WiFi chips?


For i2c based sensors the plan is to use devicetree overlays + an in
kernel
overlay manager which probes the i2c bus (checking known touchscreen /
accelerometer
addresses) and then picks the right touchscreen + accelerometer overlays.

Wifi is somewhat more tricky I must admit, esp. since there seem to be q8
a23 based
tablet variants with usb wifi and others with sdio wifi. Since both
busses are
discoverable I'm tempted to just enable both in devicetree, and let the
kernel probe
and see what is actually there. This assume that the way the wifichip is
powered
is the same on all boards, or at least that it is safe to enable the
necessary
regulators on all boards ...

I'm asking because with Maxime's couple-regulator we should be able to
get the
RTL8723BS on the Q8 A23/33 v1.5 working.


So this means enabled the sdio controller (should be safe on all boards?)
and
enabling 2 regulators to power the wifi-chip. I think it will be safe to
do this
even on boards where those regulators are not used, what do you think ?


Wouldn't that introduce some useless power drain on those boards?


If nothing is attached to those regulators (which I expect to be the case
when
they are not used to power wifi) then I would expect the drain to be
minimal,
my biggest worry is some board having tied these to ground, but I don't
think
that is very likely.

AFAIK the AXP datasheets mention that unused DCDC outputs should be left
floating. Not sure if this applies to LDO outputs as well. But any used
outputs would have a bypass capacitor.

 From the board designs I've seen, this seems to be the common case.
I'm not an electrical engineer, but I think we're covered here.

Another thing we need to deal with is the different power sequencing
requirements for the different SDIO chips.

In my experience there are not that much sequences, as simply making sure
all necessary resources are one before probing the sdio bus, I have yet to
see a case where the order in which the resources are enabled matters.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to