On Wed, Mar 25, 2015 at 03:55:43PM +0100, Linus Walleij wrote:
> On Wed, Mar 25, 2015 at 2:13 PM, Daniel Vetter wrote:
>
> > I quickly checked out your linux-gpio and it only has patch 2 to implement
> > the gpio. We also need patch 1 (but with the leak Thierry spotted fixed).
> > Should we drop
On Wed, Mar 25, 2015 at 2:13 PM, Daniel Vetter wrote:
> I quickly checked out your linux-gpio and it only has patch 2 to implement
> the gpio. We also need patch 1 (but with the leak Thierry spotted fixed).
> Should we drop Shobit's patch until that's done?
Nah I trust that Lee will merge it to
On 03/25/2015 06:43 PM, Daniel Vetter wrote:
> On Wed, Mar 25, 2015 at 01:24:01PM +0100, Linus Walleij wrote:
>> On Tue, Mar 24, 2015 at 11:53 AM, Daniel Vetter wrote:
>>> On Tue, Mar 24, 2015 at 11:16 AM, Linus Walleij
>>> wrote:
>>
>>> So summary:
>>> - Reusing the dynamic gpio lookup stuff wou
On Wed, Mar 25, 2015 at 01:24:01PM +0100, Linus Walleij wrote:
> On Tue, Mar 24, 2015 at 11:53 AM, Daniel Vetter wrote:
> > On Tue, Mar 24, 2015 at 11:16 AM, Linus Walleij
> > wrote:
>
> > So summary:
> > - Reusing the dynamic gpio lookup stuff would be nice, and might be
> > interesting as a ne
On Tue, Mar 24, 2015 at 11:53 AM, Daniel Vetter wrote:
> On Tue, Mar 24, 2015 at 11:16 AM, Linus Walleij
> wrote:
> So summary:
> - Reusing the dynamic gpio lookup stuff would be nice, and might be
> interesting as a new crazy use-case (or maybe not). But not a
> requirement since we have the co
On Tue, Mar 24, 2015 at 11:16 AM, Linus Walleij
wrote:
> On Tue, Mar 24, 2015 at 10:50 AM, Daniel Vetter wrote:
>> On Tue, Mar 24, 2015 at 10:35:32AM +0100, Linus Walleij wrote:
>
>>> Some stuff may be needed to associate the regulator with the right
>>> device indeed but nothing horribly complic
On Tue, Mar 24, 2015 at 10:50 AM, Daniel Vetter wrote:
> On Tue, Mar 24, 2015 at 10:35:32AM +0100, Linus Walleij wrote:
>> Some stuff may be needed to associate the regulator with the right
>> device indeed but nothing horribly complicated.
>
> Nack, really. We've had an epic discussion at ks two
On Tue, Mar 24, 2015 at 10:35:32AM +0100, Linus Walleij wrote:
> On Tue, Mar 24, 2015 at 9:32 AM, Daniel Vetter wrote:
>
> > The crystalcove pmic thing here really is just a dumb gpio line that for
> > the reference design gets routed to the panel (and hence has that as the
> > usual name).
>
>
On Tue, Mar 24, 2015 at 9:32 AM, Daniel Vetter wrote:
> The crystalcove pmic thing here really is just a dumb gpio line that for
> the reference design gets routed to the panel (and hence has that as the
> usual name).
So obviously the refman calls this register at offset 0x52
PANEL_EN/DISABLE n
On Wed, Mar 18, 2015 at 01:19:33PM +0100, Linus Walleij wrote:
> On Mon, Mar 16, 2015 at 5:42 AM, Shobhit Kumar
> wrote:
>
> > The CRC (Crystal Cove) PMIC, controls the panel enable and disable
> > signals for BYT for dsi panels. This is indicated in the VBT fields. Use
> > that to initialize an
On Mon, Mar 16, 2015 at 5:42 AM, Shobhit Kumar wrote:
> The CRC (Crystal Cove) PMIC, controls the panel enable and disable
> signals for BYT for dsi panels. This is indicated in the VBT fields. Use
> that to initialize and use GPIO based control for these signals.
>
> v2: Use the newer gpiod inte
The CRC (Crystal Cove) PMIC, controls the panel enable and disable
signals for BYT for dsi panels. This is indicated in the VBT fields. Use
that to initialize and use GPIO based control for these signals.
v2: Use the newer gpiod interface(Alexandre)
v3: Remove the redundant checks and unused code
12 matches
Mail list logo
