Re: [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 10, 2015 at 6:36 PM, Shobhit Kumar <kumar@xxxxxxxxxxxx> wrote:
> On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker
> <paul.gortmaker@xxxxxxxxxxxxx> wrote:
>> [Re:  [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control] On 26/06/2015 (Fri 20:47) Ville Syrjälä wrote:
>>
>>> On Fri, Jun 26, 2015 at 06:31:37PM +0200, Daniel Vetter wrote:
>>> > On Fri, Jun 26, 2015 at 02:32:03PM +0530, Shobhit Kumar wrote:
>>> > > Hi,
>>> > > Next update of the series reviewed at
>>> > > https://lkml.org/lkml/2015/6/22/155
>>> > >
>>> > > Major changes are few review comments from Varka and Ville being addressed. Also except
>>> > > for intel-gfx patches, all patches reviesion history is moved out of commit message.
>>> > >
>>> > > Hope this series finally finds its mark.
>>> > >
>>> > > Regards
>>> > > Shobhit
>>> > >
>>> > > Shobhit Kumar (7):
>>> > >   gpiolib: Add support for removing registered consumer lookup table
>>> > >   mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO
>>> > >     signal
>>> > >   mfd: intel_soc_pmic_crc: Add PWM cell device for Crystalcove PMIC
>>> > >   mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM
>>> > >   pwm: crc: Add Crystalcove (CRC) PWM driver
>>> > >   drm/i915: Use the CRC gpio for panel enable/disable
>>> > >   drm/i915: Backlight control using CRC PMIC based PWM driver
>>> >
>>> > I think we have r-b/acks on all the patches now. Ok if I pull this in
>>> > through drm-intel.git for 4.3? Or should I make a topic branch with tag
>>> > and then send out pull requests to everyone? Or will each maintainer merge
>>> > on their own since it's all only coupled at runtime anyway? Any of these
>>> > would suit me.
>>>
>>> I forgot to mention that I had a build failure due to
>>> builtin_platform_driver() when I tried this (just changed it to
>>> module_platform_driver() to get past it). So I'm not sure if this
>>> now depends on some tree which isn't included in -nightly...
>>
>> builtin_platform_register does not yet exist in mainline; as Paul (the
>> other one) said earlier.  So you can either open-code what it does for
>> now, or use  module_platform_register.  If you do the latter, then
>> ensure you (temorarily) also include module.h or you risk additional
>> breakage in the future.
>>
>
> Guess its in mainline now. Whats the plan for the merge of these patches ?
>

Do I need to do anything further on these patches ? Daniel can you
help in the next steps.

Regards
Shobhit
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux