[Intel-gfx] [v3 0/7] Crystalcove (CRC) PMIC based panel and pwm control
Shobhit Kumar
kumar at shobhit.info
Tue Jul 21 00:13:48 PDT 2015
On Fri, Jul 10, 2015 at 6:36 PM, Shobhit Kumar <kumar at shobhit.info> wrote:
> On Mon, Jun 29, 2015 at 3:48 AM, Paul Gortmaker
> <paul.gortmaker at windriver.com> wrote:
>> [Re: [Intel-gfx] [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
More information about the dri-devel
mailing list