All of lore.kernel.org
 help / color / mirror / Atom feed
From: hl <hl@rock-chips.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
	Brian Norris <briannorris@chromium.org>,
	Rob Herring <robh+dt@kernel.org>,
	Sean Paul <seanpaul@chromium.org>,
	David Airlie <airlied@linux.ie>,
	"Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver
Date: Thu, 22 Mar 2018 09:49:25 +0800	[thread overview]
Message-ID: <b2f89ae1-c028-b6ab-2ccd-6fb93161ea1f@rock-chips.com> (raw)
In-Reply-To: <CACvgo53N7BgjuZReg3D721WaBm5kK3Xd=KfaybsdW47ztMFW8w@mail.gmail.com>

Hi


On Tuesday, March 20, 2018 06:20 PM, Emil Velikov wrote:
> On 20 March 2018 at 06:24, hl <hl@rock-chips.com> wrote:
>> Hi Emil,
>>
>>
>>
>> On Monday, March 19, 2018 09:09 PM, Emil Velikov wrote:
>>> On 15 March 2018 at 02:35, hl <hl@rock-chips.com> wrote:
>>>> Hi Emil,
>>>>
>>>>
>>>>
>>>> On Wednesday, March 14, 2018 08:02 PM, Emil Velikov wrote:
>>>>> Hi Lin,
>>>>>
>>>>> On 14 March 2018 at 09:12, Lin Huang <hl@rock-chips.com> wrote:
>>>>>> From: huang lin <hl@rock-chips.com>
>>>>>>
>>>>>> Refactor Innolux P079ZCA panel driver, let it support
>>>>>> multi panel.
>>>>>>
>>>>>> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
>>>>>> Signed-off-by: Lin Huang <hl@rock-chips.com>
>>>>>> ---
>>>>>> Changes in v2:
>>>>>> - Change regulator property name to meet the panel datasheet
>>>>>> Changes in v3:
>>>>>> - this patch only refactor P079ZCA panel to support multi panel,
>>>>>> support
>>>>>> P097PFG panel in another patch
>>>>>> Changes in v4:
>>>>>> - Modify the patch which suggest by Thierry
>>>>>>
>>>>> Thanks for splitting this up. I think there's another piece that fell
>>>>> through the cracks.
>>>>> I'm not deeply familiar with the driver, so just sharing some quick
>>>>> notes.
>>>>>
>>>>>
>>>>>>     struct innolux_panel {
>>>>>>            struct drm_panel base;
>>>>>>            struct mipi_dsi_device *link;
>>>>>> +       const struct panel_desc *desc;
>>>>>>
>>>>>>            struct backlight_device *backlight;
>>>>>> -       struct regulator *supply;
>>>>>> +       struct regulator *vddi;
>>>>>> +       struct regulator *avdd;
>>>>>> +       struct regulator *avee;
>>>>> These two seem are new addition, as opposed to a dummy refactor.
>>>>> Are they optional, does one need them for the existing panel (separate
>>>>> patch?) or only for the new one (squash with the new panel code)?
>>>>>
>>>>>
>>>>>>            struct gpio_desc *enable_gpio;
>>>>>>
>>>>>>            bool prepared;
>>>>>> @@ -77,9 +93,9 @@ static int innolux_panel_unprepare(struct drm_panel
>>>>>> *panel)
>>>>>>            /* T8: 80ms - 1000ms */
>>>>>>            msleep(80);
>>>>>>
>>>>>> -       err = regulator_disable(innolux->supply);
>>>>>> -       if (err < 0)
>>>>>> -               return err;
>>>>> Good call on dropping the early return here.
>>>>>
>>>>>
>>>>>> @@ -207,19 +248,28 @@ static const struct drm_panel_funcs
>>>>>> innolux_panel_funcs = {
>>>>>> -       innolux->supply = devm_regulator_get(dev, "power");
>>>>>> -       if (IS_ERR(innolux->supply))
>>>>>> -               return PTR_ERR(innolux->supply);
>>>>>> +       innolux = devm_kzalloc(dev, sizeof(*innolux), GFP_KERNEL);
>>>>>> +       if (!innolux)
>>>>>> +               return -ENOMEM;
>>>>>> +
>>>>>> +       innolux->desc = desc;
>>>>>> +       innolux->vddi = devm_regulator_get(dev, "power");
>>>>>> +       innolux->avdd = devm_regulator_get(dev, "avdd");
>>>>>> +       innolux->avee = devm_regulator_get(dev, "avee");
>>>>>>
>>>>> AFAICT devm_regulator_get returns a pointer which is unsuitable to be
>>>>> passed into regulator_{enable,disable}.
>>>>> Hence, the IS_ERR check should stay. If any of the regulators are
>>>>> optional, you want to call regulator_{enable,disable} only as
>>>>> applicable.
>>>>
>>>> devm_regulator_get() will use dummy_regulator if there not regulator pass
>>>> to
>>>> driver, so it not affect regulator_{enable, disable}.
>>> One of us is getting confused here:
>>> devm_regulator_get does not _use_ a regulator, it returns a pointer to
>>> a regulator, right?
>>>
>>> According to the 4.16-rc6 codebase - one error
>>> returns a ERR_PTR [1].
>> devm_regulator_get() will not reurn a ERR_PTR,  it will pass NORMAL_GET mode
>> to
>> _regulator_get() when you call devm_regulator_get(), and with following
>> code:
>>
> Just before the _regulator_get() call we have "return ERR_PTR(-ENOMEM);"
> See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/regulator/devres.c?h=v4.16-rc6#n34
Okay, i got what you concern now, yes, you are right, i will keep IS_ERR 
checking here.
>
>>> With the pointer dereferenced in regulator_enable [2], without a
>>> IS_ERR check, hence thing will go boom(?)
>>>
>>>> These three regulator are
>>>> optional,
>>>> the p079zca will use "power" and ,
>>>> so i think it better not to check ERR here.
>>>>
>>> What should happen if p079zca is missing "power" or p097pgf - "avdd" and
>>> "avee"?
>>> Obviously the latter two should be introduced with the p097pgf support.
>> i think it need dts to make sure configure the power node correct, if
>> missing
>> "power" node fo p079zca or "avdd" "avee" node for p097pgf, the panel can
>> not work, but do not affcet other driver, the kernel do not crash(as i
>> explain before and i also test it).
>>
> If you know it won't work just don't continue? And yes, it will crash ;-)
> Either way, if you don't like my feedback so be it.
>
> HTH
> Emil
> P.S. As a non native English speaker to another - spell checker helps a lot ;-)
>
>
>

  reply	other threads:[~2018-03-22  1:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-14  9:12 [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver Lin Huang
2018-03-14  9:12 ` [PATCH v4 2/3] drm/panel: support Innolux P097PFG panel Lin Huang
2018-03-14 12:16   ` Emil Velikov
2018-03-14 12:16     ` Emil Velikov
2018-03-14  9:12 ` [PATCH v4 3/3] dt-bindings: Add INNOLUX P097PFG panel bindings Lin Huang
2018-03-14 12:18   ` Emil Velikov
2018-03-14 12:18     ` Emil Velikov
2018-03-14 12:02 ` [PATCH v4 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver Emil Velikov
2018-03-14 12:02   ` Emil Velikov
2018-03-15  2:35   ` hl
2018-03-19 13:09     ` Emil Velikov
2018-03-19 13:09       ` Emil Velikov
2018-03-20  6:24       ` hl
2018-03-20 10:20         ` Emil Velikov
2018-03-20 10:20           ` Emil Velikov
2018-03-22  1:49           ` hl [this message]
2018-06-14 12:49   ` Heiko Stuebner
2018-06-14 12:49     ` Heiko Stuebner
2018-04-26 14:10 ` Thierry Reding
2018-04-26 14:10   ` Thierry Reding

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=b2f89ae1-c028-b6ab-2ccd-6fb93161ea1f@rock-chips.com \
    --to=hl@rock-chips.com \
    --cc=airlied@linux.ie \
    --cc=briannorris@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=thierry.reding@gmail.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.