linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: jonghwa3.lee@samsung.com
To: Yadwinder Singh Brar <yadi.brar01@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Liam Girdwood <lrg@ti.com>,
	Yadwinder Singh Brar <yadi.brar@samsung.com>,
	Kyungmin Park <kmpark@infradead.org>,
	Samuel Ortiz <sameo@linux.intel.com>
Subject: Re: [PATCH v3 2/2] regulator: Add support for MAX77686.
Date: Wed, 23 May 2012 14:33:28 +0900	[thread overview]
Message-ID: <4FBC76A8.2070004@samsung.com> (raw)
In-Reply-To: <CAKew6eUew+=f-dGjJZD7Wy8Xt2f4smEhkYh=CUhx6Y_EMByFFw@mail.gmail.com>

On 2012년 05월 23일 14:23, Yadwinder Singh Brar wrote:

> On Wed, May 23, 2012 at 10:10 AM,  <jonghwa3.lee@samsung.com> wrote:
>> On 2012년 05월 23일 13:16, Yadwinder Singh Brar wrote:
>>
>>>>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK2CTRL1,
>>>>> +             max77686->ramp_delay << 6, RAMP_MASK);
>>>>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK3CTRL1,
>>>>> +             max77686->ramp_delay << 6, RAMP_MASK);
>>>>> +     max77686_update_reg(i2c, MAX77686_REG_BUCK4CTRL1,
>>>>> +             max77686->ramp_delay << 6, RAMP_MASK);
>>>>> +
>>>>
>>>>
>>>> Why do you use i2c client still? If you registered regmap you can use
>>>> its API. I recommend you to use regmap_update_bits() directly.
>>>>
>>>>
>>>
>>> Yes, we are using regmap_update_bits().  max77686_update_reg() is just
>>> a wrapper over it.
>>>
>>
>>
>> Yes, i know what you mean. However it doesn't need max77686_update_reg()
>> any more since it uses regmap API. Why don't you just pass iodev->regmap
>> to regmap_update_bits(). It is clear that there is no reason for using
>> i2c client as a medium. Please check regulator and mfd driver of my
>> previous patch.
>>
> 
> I agree with you we can use directly  regmap API. But I preferred
> max77686_update_reg() because its a common practice to use
> common read/write API which we define in mfd driver to access
> that particular mfd device from other drivers.
> 
> Regards,
> Yadwinder.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


I inform you my mfd driver has been confirmed by Samuel Oritz and there
is no mfd private API. This situation looks unusual that we registers
mfd driver and regulator driver separately. But how should we do? For
corporation , i'm asking you to consider my suggestion.

Thanks.


Thanks.

  reply	other threads:[~2012-05-23  5:33 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <y@samsung.com>
2012-05-22  5:57 ` [PATCH v3 2/2] regulator: Add support for MAX77686 yadi.brar01
2012-05-23  1:40   ` jonghwa3.lee
2012-05-23  4:16     ` Yadwinder Singh Brar
2012-05-23  4:40       ` jonghwa3.lee
2012-05-23  5:23         ` Yadwinder Singh Brar
2012-05-23  5:33           ` jonghwa3.lee [this message]
2012-05-23 10:18             ` Mark Brown
2012-05-23 13:02               ` Yadwinder Singh Brar
2012-05-23  6:08       ` Yadwinder Singh Brar
2012-05-23  1:50   ` jonghwa3.lee
2012-05-23  4:17     ` Yadwinder Singh Brar
2014-07-23  1:40 ` [PATCH] extcon: Add missing REGMAP_I2C/REGMAP_IRQ dependency on extcon driver Chanwoo Choi
2014-07-23  8:20   ` Krzysztof Kozlowski
2014-07-25  8:39   ` Charles Keepax
2014-08-12  2:01 ` [PATCHv2 0/5] rtc: s3c: Refactoring s3c-rtc driver and support Exynos3250 RTC y
2014-08-12  2:01   ` [PATCHv2 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables y
2014-08-22 20:42     ` Andrew Morton
2014-08-25  0:57       ` Chanwoo Choi
2014-08-26 21:31         ` Andrew Morton
2014-08-28  4:49           ` Chanwoo Choi
2014-08-12  2:01   ` [PATCHv2 2/5] rtc: s3c: Remove warning message when checking coding style with checkpatch script y
2014-08-12  2:01   ` [PATCHv2 3/5] rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type y
2014-08-12  2:01   ` [PATCHv2 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC y
2014-08-12  2:01   ` [PATCHv2 5/5] ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node y
2015-12-01  9:13 ` [PATCH 3/6] net: thunderx: Increase transmit queue length Sunil Goutham
2015-12-01 14:40   ` Pavel Fedin
2015-12-01 15:33     ` Eric Dumazet
2015-12-01 16:30       ` Sunil Kovvuri
2015-12-01 19:30         ` David Miller
2015-12-02  5:48           ` Sunil Kovvuri
2015-12-02 13:25             ` Eric Dumazet
2015-12-02 16:50               ` Sunil Kovvuri
2015-12-02 16:59                 ` Eric Dumazet
2015-12-02 17:31             ` David Miller
2015-12-02  9:05         ` Pavel Fedin
2015-12-02 10:31           ` Pavel Fedin
2015-12-02 12:29             ` Pavel Fedin
2015-12-02 12:57               ` Sunil Kovvuri
2015-12-02 13:22                 ` Pavel Fedin
2015-12-02  8:09       ` Pavel Fedin
2015-12-01  9:13 ` [PATCH 5/6] net: thunderx: Switchon carrier only upon interface link up Sunil Goutham
2015-12-01 15:32   ` Pavel Fedin
2015-12-01 16:39     ` Sunil Kovvuri
2015-12-07  5:00 ` [PATCH 0/2] net: thunderx: Miscellaneous cleanups Sunil Goutham
2015-12-07 10:33   ` Pavel Fedin
2015-12-07 18:40   ` David Miller
2015-12-09 11:38 ` [PATCH 1/2] net: thunderx: HW TSO support for pass-2 hardware Sunil Goutham
2015-12-09 12:05   ` Pavel Fedin
2015-12-09 12:24     ` Sunil Kovvuri
2015-12-09 20:26     ` David Miller
2015-12-09 11:38 ` [PATCH 2/2] net: thunderx: Enable CQE count threshold interrupt Sunil Goutham
2015-12-09 12:07   ` Pavel Fedin
2015-12-09 12:26     ` Sunil Kovvuri
2015-12-10  7:55 ` [PATCH v2 0/2] net: thunderx: Support for pass-2 hw features Sunil Goutham
2015-12-10  8:52   ` Pavel Fedin
2015-12-12  4:38   ` David Miller

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=4FBC76A8.2070004@samsung.com \
    --to=jonghwa3.lee@samsung.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=kmpark@infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=sameo@linux.intel.com \
    --cc=yadi.brar01@gmail.com \
    --cc=yadi.brar@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).