linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hdegoede@redhat.com (Hans de Goede)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] Re: [PATCH] ARM: dts: sun4i: Add dts file for the pov protab2-ips9 tablet
Date: Tue, 20 Oct 2015 23:59:49 +0200	[thread overview]
Message-ID: <5626B955.3070906@redhat.com> (raw)
In-Reply-To: <20151019194313.GY2711@lukather>

Hi,

On 10/19/2015 09:43 PM, Maxime Ripard wrote:
> On Tue, Sep 22, 2015 at 05:24:37PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 22-09-15 17:02, Maxime Ripard wrote:
>>> On Sun, Sep 13, 2015 at 07:33:36PM +0200, Hans de Goede wrote:
>>>>> Anyway. In both cases, the regulator really shouldn't be drifting
>>>>> along like this.
>>>>
>>>> Right which is why I've added the always-on property.
>>>
>>> Which is exactly what I meant by drifting along: that regulator will
>>> never be associated to the i2c bus, and will always be enabled even
>>> though the i2c bus might not even be accessible in the first place
>>> (driver not selected, compiled as a module and not loaded yet), which
>>> is just as bad.
>>>
>>>>> If the i2c bus needs a regulator to be operationaly,
>>>>> then we can just add an optional bus-supply property or something to
>>>>> give that to the i2c driver so that it can enable it when needed.
>>>>
>>>> I agree that that would be sensible if this regulator were tied to
>>>> the pull-ups, but I've my doubts that it is. We've not seen anything
>>>> similar on any other allwinner tablet, other then ChenYu-s Ippo-q8-v5
>>>> tablet.
>>>>
>>>> This tablet is sort of a high-end tablet (with a nice ips screen) and
>>>> such it also uses a different (better) sensor for its frontcam, a
>>>> gc2015 rather then the usual gc0308. I believe that this is the
>>>> culprit.
>>>>
>>>> Which would make modelling this as some sort of i2c-bus power-supply
>>>> wrong, and I've checked and none of the existing i2c bindings under
>>>> Documentation/devicetree/bindings/i2c contain such a thing, so we
>>>> would be the first and we will likely have a hard time selling a
>>>> binding for this upstream, esp. since we do not know what exactly
>>>> is going on.
>>>
>>> Well, strictly speaking, it is a supply needed to get the bus to
>>> work. We should really try to avoid having always-on for regulators,
>>> especially for devices that are already represented in the DT.
>>>
>>>> So all in all I strongly believe that just setting always-on
>>>> on the regulator in question is the best solution.
>>>
>>> It's a hack we can avoid.
>>
>> How? By adding a regulator property to the i2c controller node
>> and then have the i2c controller driver enable this on probe ?
>
> Yes.

Ok, I'll send a v2 marking i2c1 as failed for now, as you've done with
sun6i-a31-hummingbird.dts, and drop the ldo3 node.

And I'll put looking into fixing this via a supply property for the
i2c-host node on my todo list.

Regards,

Hans

      reply	other threads:[~2015-10-20 21:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-05  8:21 [PATCH] ARM: dts: sun4i: Add dts file for the pov protab2-ips9 tablet Hans de Goede
2015-09-06 16:30 ` Maxime Ripard
2015-09-07  7:05   ` [linux-sunxi] " Hans de Goede
2015-09-07  7:49     ` Priit Laes
2015-09-07  8:49       ` Hans de Goede
2015-09-07  9:14         ` Priit Laes
2015-09-07  9:30           ` Hans de Goede
2015-09-07 20:52             ` Maxime Ripard
2015-09-08  7:48               ` Hans de Goede
2015-09-10 13:56                 ` Maxime Ripard
2015-09-07 20:56     ` Maxime Ripard
2015-09-08  7:45       ` Hans de Goede
2015-09-08  8:40         ` Chen-Yu Tsai
2015-09-08 12:49           ` Hans de Goede
2015-09-08 13:14             ` Chen-Yu Tsai
2015-09-13 15:22         ` Maxime Ripard
2015-09-13 17:33           ` Hans de Goede
2015-09-22 15:02             ` Maxime Ripard
2015-09-22 15:24               ` Hans de Goede
2015-10-10 12:32                 ` Hans de Goede
2015-10-19 19:43                 ` Maxime Ripard
2015-10-20 21:59                   ` Hans de Goede [this message]

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=5626B955.3070906@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).