Re: [PATCH v8 1/2] mfd: add atmel-hlcdc driver

[Nicolas Ferre <nicolas.ferre@atmel.com>]

Hi Lee,

On 07/10/2014 14:22, Lee Jones :
> On Tue, 07 Oct 2014, Thierry Reding wrote:
>> On Tue, Oct 07, 2014 at 01:41:12PM +0200, Boris Brezillon wrote:
>>> On Tue, 7 Oct 2014 12:38:14 +0100
>>> Lee Jones <lee.jones@linaro.org> wrote:
>>>
>>>> On Tue, 07 Oct 2014, Thierry Reding wrote:
>>>>
>>>>> On Tue, Oct 07, 2014 at 11:17:43AM +0100, Lee Jones wrote:
>>>>>> On Tue, 07 Oct 2014, Thierry Reding wrote:
>>>>>>
>>>>>>> On Tue, Oct 07, 2014 at 10:59:32AM +0100, Lee Jones wrote:
>>>>>>>> On Tue, 07 Oct 2014, Thierry Reding wrote:
>>>>>>>>
>>>>>>>>> On Tue, Oct 07, 2014 at 10:44:27AM +0100, Lee Jones wrote:
>>>>>>>>>> On Mon, 06 Oct 2014, Boris Brezillon wrote:
>>>>>>>>>>
>>>>>>>>>>> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
>>>>>>>>>>> family or sama5d3 family) exposes 2 subdevices:
>>>>>>>>>>> - a display controller (controlled by a DRM driver)
>>>>>>>>>>> - a PWM chip
>>>>>>>>>>>
>>>>>>>>>>> The MFD device provides a regmap and several clocks (those connected
>>>>>>>>>>> to this hardware block) to its subdevices.
>>>>>>>>>>>
>>>>>>>>>>> This way concurrent accesses to the iomem range are handled by the regmap
>>>>>>>>>>> framework, and each subdevice can safely access HLCDC registers.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
>>>>>>>>>>> Acked-by: Lee Jones <lee.jones@linaro.org>
>>>>>>>>>>> Tested-by: Anthony Harivel <anthony.harivel@emtrion.de>
>>>>>>>>>>> Tested-by: Ludovic Desroches <ludovic.desroches@atmel.com>
>>>>>>>>>>> ---
>>>>>>>>>>>  drivers/mfd/Kconfig             |   6 ++
>>>>>>>>>>>  drivers/mfd/Makefile            |   1 +
>>>>>>>>>>>  drivers/mfd/atmel-hlcdc.c       | 122 ++++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>>  include/linux/mfd/atmel-hlcdc.h |  85 ++++++++++++++++++++++++++++
>>>>>>>>>>>  4 files changed, 214 insertions(+)
>>>>>>>>>>>  create mode 100644 drivers/mfd/atmel-hlcdc.c
>>>>>>>>>>>  create mode 100644 include/linux/mfd/atmel-hlcdc.h
>>>>>>>>>>
>>>>>>>>>> Applied for v3.19.
>>>>>>>>>
>>>>>>>>> Will you provide a stable branch that I can pull into the PWM tree?
>>>>>>>>
>>>>>>>> I hadn't planned on it.  What do you need that for?
>>>>>>>
>>>>>>> Because the PWM driver depends on this series. But if you prefer you
>>>>>>> could also take the PWM driver through your tree.
>>>>>>
>>>>>> Probably better to deal with that via Kconfig.
>>>>>
>>>>> Do you have any suggestions? The PWM driver currently selects the
>>>>> MFD_ATMEL_HLCDC symbol, which as I understand will cause a Kconfig error
>>>>> if the latter isn't defined.
>>>>
>>>> s/select/depends on/ for the desired effect.
>>>>
>>>
>>> Don't forget the atmel-hlcdc.h header file which is referenced by both
>>> the DRM and the PWM drivers.
>>
>> The depends on will prevent the PWM driver from being built until MFD
>> becomes available, so the missing header file shouldn't be a problem.
>>
>> That said, Nicolas Ferre (Cc'ing) at some point requested this to become
>> a select (or at least for the DRM driver, but I guess the same applies
>> to PWM) on the grounds that a depends on will make it more difficult to
>> enable the driver.
> 
> It's not that much more difficult.  It just entails enabling 3 instead
> of 2 config options.

Yes it is more difficult. Believe me, it's a mess, but...

> Once all of the required components are merged,
> feel free to drop back to 'select'.  This is easier than sharing round
> immutable branches all over the place.

.. I agree with this option of moving to an easier-to-merge solution and
then dealing with the ease of use.

>> So we have two options here: 1) turn the select into a depends on here
>> and allow the dependency to be resolved that way, or 2) solve the
>> dependency by making sure the MFD part is merged first (either by
>> pulling the MFD tree into the PWM and DRM trees or waiting for a full
>> cycle for the MFD changes to land).
>>
>> I don't mind either way.
> 
> I'll go with either of the two suggestions above.

So, Lee and Thierry, you can both take your part in your respective
trees with the change (1) described above and with my:

Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>

(if you feel it is needed).

Thanks, bye,
-- 
Nicolas Ferre