All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Laxman Dewangan <ldewangan@nvidia.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Mark Brown <broonie@kernel.org>,
	rtc-linux@googlegroups.com, robh+dt@kernel.org,
	pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linus.walleij@linaro.org, gnurou@gmail.com, lee.jones@linaro.org,
	a.zummo@towertech.it, lgirdwood@gmail.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-gpio@vger.kernel.org, swarren@nvidia.com,
	treding@nvidia.com, Chaitanya Bandi <bandik@nvidia.com>
Subject: Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver
Date: Tue, 12 Jan 2016 09:13:20 +0900	[thread overview]
Message-ID: <56944520.6090301@samsung.com> (raw)
In-Reply-To: <5693E14B.4050306@nvidia.com>

On 12.01.2016 02:07, Laxman Dewangan wrote:
> 
> On Monday 11 January 2016 09:34 PM, Alexandre Belloni wrote:
>> On 11/01/2016 at 18:47:34 +0530, Laxman Dewangan wrote :
>>> On Friday 08 January 2016 07:06 PM, Laxman Dewangan wrote:
>>>> On Friday 08 January 2016 07:06 PM, Mark Brown wrote:
>>>>> * PGP Signed by an unknown key
>>>>>
>>>>> On Fri, Jan 08, 2016 at 06:34:29PM +0530, Laxman Dewangan wrote:
>>>>>
>>>>>> If we get the parent device, regmap handle and interrupt number from
>>>>>> mfd
>>>>>> core independent of the PMIC (MAX77620 or MAX77686), then same driver
>>>>>> can be
>>>>>> used here.
>>>>>> Two way which I can think of here:
>>>>> Parent device is just dev->parent, you can use dev_get_regmap() to
>>>>> get a
>>>>> regmap given a struct device and you can use platform resources to
>>>>> pass
>>>>> the interrupts to the children from the MFD (there's some examples,
>>>>> wm831x is one).
>>>>>
>>>>>
>>>> I think it should work with named regmap. mfd whould init regmap
>>>> with name
>>>> and rtc driver should ask with same name.
>>>>
>>>> I saw three drivers which looks same:
>>>> rtc-max77620.c (new from me) and already available rtc-max77686.c,
>>>> rtc-max77802.c
>>>>
>>>> Seems I can develop IP based rtc driver as rtc-max77xxx.c
>>> I came with one of issue when doing this.
>>>
>>> The RTC driver parent is not the same parent for which i2c slave
>>> address get
>>> registered.
>>> There is two slave address from max77620, 0x3C (for general) and 0x68
>>> for
>>> RTC.
>>>
>>> In max77620 mfd driver, we make dummy i2c client for 0x68 and initialize
>>> regmap with this address.
>>>
>>> Now on mfd_add_devices, we pass the device for 0x3c and hence the RTC
>>> driver
>>> treat the parent as the 0x3c device but actually it should be 0x68 to
>>> get
>>> the proper regmap.
>>>
>>>
>>> Two approach:
>>> 1. If we add the option to pass parent_dev when adding cells form
>>> mfd_add_devices and select the parent device based on this option
>>> then it
>>> can be easily handle.
>>>      Add parent_dev structure in struct mfd_cell and then change the
>>> parent
>>> in mfd_add_device() if cells has parent device.
>>>
>>> 2. Register the RTC driver with different mfd_add_devices with dummy i2c
>>> client device.
>>> So two times mfd_add_devices.

Lexman,

I don't quite get the problem. This looks exactly the same as for
max77686. What is the difference? I don't see any need to change the
mfd_cell for current drivers...


>>>
>>>
>>> IMO, approach 1 looks good to me.
>>>
>>> Any opinion?
>>>
>> If the RTC is not at the same address, I'd say this is not an mfd
>> anymore, can't you probe it directly from DT?
>>
>>
> This approach is also possible but,
> 
> although this is independent IP with separate i2c address but became it
> is inside the PMIC and its interrupt depends on PMIC internals, I like
> to register this rtc device from the mfd core.
> So that when mfd core is ready with their interrupts and initial
> setting, it can register rtc device.

Alexandre,

All of these devices have some of the blocks under separate I2C address.
It is still a MFD because for example interrupts are shared and governed
by parent.

Best regards,
Krzysztof



WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <k.kozlowski@samsung.com>
To: Laxman Dewangan <ldewangan@nvidia.com>,
	Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Mark Brown <broonie@kernel.org>,
	rtc-linux@googlegroups.com, robh+dt@kernel.org,
	pawel.moll@arm.com, mark.rutland@arm.com,
	ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
	linus.walleij@linaro.org, gnurou@gmail.com, lee.jones@linaro.org,
	a.zummo@towertech.it, lgirdwood@gmail.com,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-gpio@vger.kernel.org, swarren@nvidia.com,
	treding@nvidia.com, Chaitanya Bandi <bandik@nvidia.com>
Subject: Re: [rtc-linux] [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver
Date: Tue, 12 Jan 2016 09:13:20 +0900	[thread overview]
Message-ID: <56944520.6090301@samsung.com> (raw)
In-Reply-To: <5693E14B.4050306@nvidia.com>

On 12.01.2016 02:07, Laxman Dewangan wrote:
> 
> On Monday 11 January 2016 09:34 PM, Alexandre Belloni wrote:
>> On 11/01/2016 at 18:47:34 +0530, Laxman Dewangan wrote :
>>> On Friday 08 January 2016 07:06 PM, Laxman Dewangan wrote:
>>>> On Friday 08 January 2016 07:06 PM, Mark Brown wrote:
>>>>> * PGP Signed by an unknown key
>>>>>
>>>>> On Fri, Jan 08, 2016 at 06:34:29PM +0530, Laxman Dewangan wrote:
>>>>>
>>>>>> If we get the parent device, regmap handle and interrupt number from
>>>>>> mfd
>>>>>> core independent of the PMIC (MAX77620 or MAX77686), then same driver
>>>>>> can be
>>>>>> used here.
>>>>>> Two way which I can think of here:
>>>>> Parent device is just dev->parent, you can use dev_get_regmap() to
>>>>> get a
>>>>> regmap given a struct device and you can use platform resources to
>>>>> pass
>>>>> the interrupts to the children from the MFD (there's some examples,
>>>>> wm831x is one).
>>>>>
>>>>>
>>>> I think it should work with named regmap. mfd whould init regmap
>>>> with name
>>>> and rtc driver should ask with same name.
>>>>
>>>> I saw three drivers which looks same:
>>>> rtc-max77620.c (new from me) and already available rtc-max77686.c,
>>>> rtc-max77802.c
>>>>
>>>> Seems I can develop IP based rtc driver as rtc-max77xxx.c
>>> I came with one of issue when doing this.
>>>
>>> The RTC driver parent is not the same parent for which i2c slave
>>> address get
>>> registered.
>>> There is two slave address from max77620, 0x3C (for general) and 0x68
>>> for
>>> RTC.
>>>
>>> In max77620 mfd driver, we make dummy i2c client for 0x68 and initialize
>>> regmap with this address.
>>>
>>> Now on mfd_add_devices, we pass the device for 0x3c and hence the RTC
>>> driver
>>> treat the parent as the 0x3c device but actually it should be 0x68 to
>>> get
>>> the proper regmap.
>>>
>>>
>>> Two approach:
>>> 1. If we add the option to pass parent_dev when adding cells form
>>> mfd_add_devices and select the parent device based on this option
>>> then it
>>> can be easily handle.
>>>      Add parent_dev structure in struct mfd_cell and then change the
>>> parent
>>> in mfd_add_device() if cells has parent device.
>>>
>>> 2. Register the RTC driver with different mfd_add_devices with dummy i2c
>>> client device.
>>> So two times mfd_add_devices.

Lexman,

I don't quite get the problem. This looks exactly the same as for
max77686. What is the difference? I don't see any need to change the
mfd_cell for current drivers...


>>>
>>>
>>> IMO, approach 1 looks good to me.
>>>
>>> Any opinion?
>>>
>> If the RTC is not at the same address, I'd say this is not an mfd
>> anymore, can't you probe it directly from DT?
>>
>>
> This approach is also possible but,
> 
> although this is independent IP with separate i2c address but became it
> is inside the PMIC and its interrupt depends on PMIC internals, I like
> to register this rtc device from the mfd core.
> So that when mfd core is ready with their interrupts and initial
> setting, it can register rtc device.

Alexandre,

All of these devices have some of the blocks under separate I2C address.
It is still a MFD because for example interrupts are shared and governed
by parent.

Best regards,
Krzysztof


-- 
-- 
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
--- 
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

  reply	other threads:[~2016-01-12  0:13 UTC|newest]

Thread overview: 103+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-07 14:38 [PATCH 0/6] Add support for MAXIM MAX77620/MAX20024 PMIC Laxman Dewangan
2016-01-07 14:38 ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38 ` Laxman Dewangan
2016-01-07 14:38 ` [PATCH 1/6] DT: mfd: add device-tree binding doc fro PMIC max77620/max20024 Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-07 23:12   ` Rob Herring
2016-01-07 23:12     ` [rtc-linux] " Rob Herring
2016-01-08  6:06     ` Laxman Dewangan
2016-01-08  6:06       ` [rtc-linux] " Laxman Dewangan
2016-01-08  6:06       ` Laxman Dewangan
2016-01-08 14:19       ` Rob Herring
2016-01-08 14:19         ` [rtc-linux] " Rob Herring
2016-01-08 14:19         ` Rob Herring
2016-01-07 14:38 ` [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-07 15:56   ` kbuild test robot
2016-01-07 15:56     ` [rtc-linux] " kbuild test robot
2016-01-07 15:56     ` kbuild test robot
2016-01-11  5:48     ` Lee Jones
2016-01-11  5:48       ` [rtc-linux] " Lee Jones
2016-01-07 15:56   ` [PATCH] mfd: max77620: fix platform_no_drv_owner.cocci warnings kbuild test robot
2016-01-07 15:56     ` [rtc-linux] " kbuild test robot
2016-01-07 15:56     ` kbuild test robot
2016-01-08  1:35   ` [rtc-linux] [PATCH 2/6] mfd: max77620: add core driver for MAX77620/MAX20024 Krzysztof Kozlowski
2016-01-08  1:35     ` Krzysztof Kozlowski
     [not found]     ` <CAJKOXPfa0jjRWE6LKvNmwCRcG9Es7=36_03kTqCx-aB1wENx0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-01-08  9:16       ` Laxman Dewangan
2016-01-08  9:16         ` Laxman Dewangan
2016-01-08  9:16         ` Laxman Dewangan
2016-01-08 13:14         ` Krzysztof Kozlowski
2016-01-08 13:14           ` Krzysztof Kozlowski
2016-01-08 13:19           ` Laxman Dewangan
2016-01-08 13:19             ` Laxman Dewangan
2016-01-08 13:19             ` Laxman Dewangan
2016-01-08 13:32             ` Krzysztof Kozlowski
2016-01-08 13:32               ` Krzysztof Kozlowski
2016-01-11  5:46     ` Lee Jones
2016-01-11  5:46       ` Lee Jones
2016-01-11  5:46       ` Lee Jones
2016-01-11  6:26       ` Krzysztof Kozlowski
2016-01-11  6:26         ` Krzysztof Kozlowski
2016-01-11  9:05         ` Lee Jones
2016-01-11  9:05           ` Lee Jones
2016-01-07 14:38 ` [PATCH 3/6] pinctrl: max77620: add pincontrol " Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-07 14:38 ` [PATCH 4/6] gpio: max77620: add gpio " Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-07 14:38 ` [PATCH 5/6] rtc: max77620: add support for max77620/max20024 RTC driver Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-08  1:07   ` Linux Kernel
2016-01-08  1:07     ` [rtc-linux] " Linux Kernel
2016-01-11  5:46     ` Lee Jones
2016-01-11  5:46       ` [rtc-linux] " Lee Jones
2016-01-11  5:46       ` Lee Jones
2016-01-14  9:06       ` Linus Walleij
2016-01-14  9:06         ` [rtc-linux] " Linus Walleij
2016-01-08  2:03   ` [rtc-linux] " Krzysztof Kozlowski
2016-01-08  2:03     ` Krzysztof Kozlowski
2016-01-08 10:20     ` Laxman Dewangan
2016-01-08 10:20       ` Laxman Dewangan
2016-01-08 10:20       ` Laxman Dewangan
2016-01-08 12:51       ` Mark Brown
2016-01-08 12:51         ` Mark Brown
2016-01-08 13:04         ` Laxman Dewangan
2016-01-08 13:04           ` Laxman Dewangan
2016-01-08 13:04           ` Laxman Dewangan
2016-01-08 13:36           ` Mark Brown
2016-01-08 13:36             ` Mark Brown
2016-01-08 13:36             ` Laxman Dewangan
2016-01-08 13:36               ` Laxman Dewangan
2016-01-08 13:36               ` Laxman Dewangan
2016-01-11 13:17               ` Laxman Dewangan
2016-01-11 13:17                 ` Laxman Dewangan
2016-01-11 13:17                 ` Laxman Dewangan
2016-01-11 16:04                 ` Alexandre Belloni
2016-01-11 16:04                   ` Alexandre Belloni
2016-01-11 17:07                   ` Laxman Dewangan
2016-01-11 17:07                     ` Laxman Dewangan
2016-01-11 17:07                     ` Laxman Dewangan
2016-01-12  0:13                     ` Krzysztof Kozlowski [this message]
2016-01-12  0:13                       ` Krzysztof Kozlowski
2016-01-12  2:32                       ` Laxman Dewangan
2016-01-12  2:32                         ` Laxman Dewangan
2016-01-12  2:32                         ` Laxman Dewangan
2016-01-12  3:51                         ` Krzysztof Kozlowski
2016-01-12  3:51                           ` Krzysztof Kozlowski
2016-01-08 13:05       ` Krzysztof Kozlowski
2016-01-08 13:05         ` Krzysztof Kozlowski
     [not found]         ` <568FB423.7030108-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-01-08 13:13           ` Laxman Dewangan
2016-01-08 13:13             ` Laxman Dewangan
2016-01-08 13:13             ` Laxman Dewangan
2016-01-07 14:38 ` [PATCH 6/6] regulator: max77620: add regulator driver for max77620/max20024 Laxman Dewangan
2016-01-07 14:38   ` [rtc-linux] " Laxman Dewangan
2016-01-07 14:38   ` Laxman Dewangan
2016-01-10 12:40   ` Mark Brown
2016-01-10 12:40     ` [rtc-linux] " Mark Brown
     [not found]     ` <20160110124014.GZ6588-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-01-11 10:16       ` Laxman Dewangan
2016-01-11 10:16         ` [rtc-linux] " Laxman Dewangan
2016-01-11 10:16         ` Laxman Dewangan

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=56944520.6090301@samsung.com \
    --to=k.kozlowski@samsung.com \
    --cc=a.zummo@towertech.it \
    --cc=alexandre.belloni@free-electrons.com \
    --cc=bandik@nvidia.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gnurou@gmail.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=ldewangan@nvidia.com \
    --cc=lee.jones@linaro.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=rtc-linux@googlegroups.com \
    --cc=swarren@nvidia.com \
    --cc=treding@nvidia.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.