[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <59E5BBC3.2020504@rock-chips.com>
Date: Tue, 17 Oct 2017 16:13:55 +0800
From: jeffy <jeffy.chen@...k-chips.com>
To: Brian Norris <briannorris@...omium.org>
CC: linux-kernel@...r.kernel.org, dmitry.torokhov@...il.com,
heiko@...ech.de, rjw@...ysocki.net, dianders@...omium.org,
tfiga@...omium.org, broonie@...nel.org, seanpaul@...omium.org,
linux-pwm@...r.kernel.org, linux-fbdev@...r.kernel.org,
Daniel Thompson <daniel.thompson@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
dri-devel@...ts.freedesktop.org, Jingoo Han <jingoohan1@...il.com>,
Lee Jones <lee.jones@...aro.org>
Subject: Re: [RESEND PATCH v2 2/5] backlight: pwm_bl: Add device link for
pwm_bl and pwm
Hi Brian,
On 10/17/2017 07:57 AM, Brian Norris wrote:
> This is going to be a*lot* of churn throughout the tree, if we expect
> all resource consumers to do this. I think we'd want some kind of
> agreement from the PM maintainers and (larger) subsystem owners before
> going down this route...
>
> And in the PWM case, pwm_get() already has the device pointer. Why can't
> we just instrument it instead?
according to pwm_bl driver, we may need to take care of pwm_request() too:
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm) && PTR_ERR(pb->pwm) != -EPROBE_DEFER &&
!node) {
dev_err(&pdev->dev, "unable to request PWM, trying
legacy API\n");
pb->legacy = true;
pb->pwm = pwm_request(data->pwm_id, "pwm-backlight");
}
and maybe also *of_pwm_get...
maybe we can add a dummy pwm chip for those orphan pwms?
>
> Brian
Powered by blists - more mailing lists