Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization
On Thu, May 30, 2024 at 11:07:53AM +0300, Dmitry Baryshkov wrote: > On Thu, 30 May 2024 at 07:41, Limonciello, Mario > wrote: > > > > > > >> Also a direct acpi_lid_open() call seems a bit iffy. But I guess if > > >> someone needs this to work on non-ACPI system they get to figure out > > >> how to abstract it better. acpi_lid_open() does seem to return != 0 > > >> when ACPI is not supported, so at least it would err on the side > > >> of enabling everything. > > > > > > Thanks. I was going to comment, but you got it first. I think a proper > > > implementation should check for SW_LID input device instead of simply > > > using acpi_lid_open(). This will handle the issue for other, > > > non-ACPI-based laptops. > > > > > > > Can you suggest how this would actually work? AFAICT the only way to > > discover if input devices support SW_LID would be to iterate all the > > input devices in the kernel and look for whether ->swbit has SW_LID set. > > > > This then turns into a dependency problem of whether any myriad of > > drivers have started to report SW_LID. It's also a state machine > > problem because other drivers can be unloaded at will. > > > > And then what do you if more than one sets SW_LID? > > It might be easier to handle this in the input subsystem. For example > by using a refcount-like variable which handles all the LIDs and > counts if all of them are closed. Or if any of the LIDs is closed. Yes, install an input handler matching on EV_SW/SW_LID so you will get notified when input devices capable of reporting SW_LID appear and disappear and also when SW_LID event is being generated, and handle as you wish. Something like https://chromium.googlesource.com/chromiumos/third_party/kernel/+/40e9f6a991856ee7d504ac1ccd587e435775cfc4%5E%21/#F0 In practice I think it is pretty safe to assume only 1 lid for a laptop/device. Thanks. -- Dmitry
Re: Implement per-key keyboard backlight as auxdisplay?
On Fri, Jan 19, 2024 at 12:51:21PM +0200, Jani Nikula wrote: > On Fri, 19 Jan 2024, Hans de Goede wrote: > > For per key controllable rgb LEDs we need to discuss a coordinate > > system. I propose using a fixed size of 16 rows of 64 keys, > > so 64x16 in standard WxH notation. > > > > And then storing RGB in separate bytes, so userspace will then > > always send a buffer of 192 bytes per line (64x3) x 14 rows > > = 3072 bytes. With the kernel driver ignoring parts of > > the buffer where there are no actual keys. > > > > I would then like the map the standard 105 key layout onto this, > > starting at x.y (column.row) coordinates of 16.6 (with 0.0 being > > the top left). Leaving plenty of space on the left top and right > > (and some on the bottom) for extra media key rows, macro keys, etc. > > > > The idea to have the standard layout at a fixed place is to allow > > userspace to have a database of preset patterns which will work > > everywhere. > > > > Note I say standard 105 key layout, but in reality for > > defining the standardized part of the buffer we should > > use the maximum amount of keys per row of all the standard layouts, > > so for row 6 (the ESC row) and for extra keys on the right outside > > the main block we use the standard layout as shown here: > > Doesn't the input stack already have to have pretty much all of this > already covered? I can view the keyboard layout in my desktop > environment, and it's a reasonably accurate match, even if unlikely to > be pixel perfect. But crucially, it has to have all the possible layouts > covered already. The kernel actually is not aware of the keyboard geometry, it had no idea if you are dealing with a standard full 101/102 keys keyboard, TKL or even smaller one, if it is split or not, maybe something like Kinesis Advantage360. Arguably, it could potentially know about 101/TLK if vendors would program accurate descriptors into their devices, but nobody does... And geometry is not a part of HID interface at all. So your desktop environment makes an [un]educated guess. > > And while I would personally hate it, you can imagine a use case where > you'd like a keypress to have a visual effect around the key you > pressed. A kind of force feedback, if you will. I don't actually know, > and correct me if I'm wrong, but feels like implementing that outside of > the input subsystem would be non-trivial. Actually I think it does not belong to the input subsystem as it is, where the goal is to deliver keystrokes and gestures to userspace. The "force feedback" kind of fits, but not really practical, again because of lack of geometry info. It is also not really essential to be fully and automatically handled by the kernel. So I think the best way is to have an API that is flexible enough for the userspace solution to control, and that is not restricted by the input core design. The hardware drivers are not restricted to using a single API, they can implement both an input device and whatever new "rgbled" and userspace can associate them by topology/sysfs. > > Cc: Dmitry, could we at least have some input from the input subsystem > POV on this? AFAICT we have received none. Sorry, I was not CCed and I missed this on the mainling list. Thanks. -- Dmitry
Re: [PATCH] vt: remove superfluous CONFIG_HW_CONSOLE
On Mon, Jan 08, 2024 at 02:41:02PM +0100, Lukas Bulwahn wrote: > The config HW_CONSOLE is always identical to the config VT and is not > visible in the kernel's build menuconfig. So, CONFIG_HW_CONSOLE is > redundant. > > Replace all references to CONFIG_HW_CONSOLE with CONFIG_VT and remove > CONFIG_HW_CONSOLE. > > Signed-off-by: Lukas Bulwahn > --- > I think this patch is best picked up by Greg rather than splitting it > in smaller pieces for m68k, amiga keyboard, fbdev etc. > > Greg, if that is fine, could you pick this for the next merge window? > > I was also considering to rename config VT_HW_CONSOLE_BINDING to > VT_CONSOLE_BINDING, as the dependency is on VT, not HW_CONSOLE, but > at the moment, that seemed more churn than value of clarification. > > arch/m68k/amiga/config.c| 2 +- > drivers/input/keyboard/amikbd.c | 6 +++--- Acked-by: Dmitry Torokhov Thanks. -- Dmitry
Re: [PATCH v6 1/4] pwm: rename pwm_apply_state() to pwm_apply_might_sleep()
On Wed, Nov 29, 2023 at 09:13:34AM +, Sean Young wrote: > drivers/input/misc/da7280.c | 4 +-- > drivers/input/misc/pwm-beeper.c | 4 +-- > drivers/input/misc/pwm-vibra.c| 8 +++--- Acked-by: Dmitry Torokhov # for input Thanks. -- Dmitry
Re: [PATCH 4/6] input/vmmouse: Use vmware_hypercall API
On Wed, Nov 22, 2023 at 03:30:49PM -0800, Alexey Makhalov wrote: > Switch from VMWARE_HYPERCALL macro to vmware_hypercall API. > Eliminate arch specific code. No functional changes intended. > > Signed-off-by: Alexey Makhalov Acked-by: Dmitry Torokhov Please feel free to merge with the rest of the series. Thanks. -- Dmitry
Re: [Intel-gfx] [PATCH] drm/i915/quirk: Add quirk for devices with incorrect PWM frequency
Hi Allen,
On Tue, Oct 17, 2023 at 06:01:39PM +, Allen Ballway wrote:
> Cyernet T10C has a bad default PWM frequency causing the display to
> strobe when the brightness is less than 100%. Create a new quirk to use
> the value from the BIOS rather than the default register value.
>
> Signed-off-by: Allen Ballway
>
> ---
>
> .../gpu/drm/i915/display/intel_backlight.c| 3 ++-
> drivers/gpu/drm/i915/display/intel_quirks.c | 26 +++
> drivers/gpu/drm/i915/display/intel_quirks.h | 1 +
> 3 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
> b/drivers/gpu/drm/i915/display/intel_backlight.c
> index 2e8f17c045222..c4dcfece9deca 100644
> --- a/drivers/gpu/drm/i915/display/intel_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c
> @@ -1388,7 +1388,8 @@ static int vlv_setup_backlight(struct intel_connector
> *connector, enum pipe pipe
> ctl = intel_de_read(i915, VLV_BLC_PWM_CTL(pipe));
> panel->backlight.pwm_level_max = ctl >> 16;
>
> - if (!panel->backlight.pwm_level_max)
> + if (!panel->backlight.pwm_level_max ||
> + intel_has_quirk(i915, QUIRK_IGNORE_DEFAULT_PWM_FREQUENCY))
> panel->backlight.pwm_level_max =
> get_backlight_max_vbt(connector);
I think it would be better if we did:
if (!intel_has_quirk(i915, QUIRK_IGNORE_DEFAULT_PWM_FREQUENCY)) {
ctl = intel_de_read(i915, VLV_BLC_PWM_CTL(pipe));
panel->backlight.pwm_level_max = ctl >> 16;
} else {
panel->backlight.pwm_level_max = 0;
}
if (!panel->backlight.pwm_level_max)
panel->backlight.pwm_level_max =
get_backlight_max_vbt(connector);
The "else" branch can potentially be omitted if we know that backlight
member is initialized to 0 (I suspect it is).
>
> if (!panel->backlight.pwm_level_max)
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
> b/drivers/gpu/drm/i915/display/intel_quirks.c
> index a280448df771a..ff6cb499428ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.c
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.c
> @@ -65,6 +65,12 @@ static void quirk_no_pps_backlight_power_hook(struct
> drm_i915_private *i915)
> drm_info(>drm, "Applying no pps backlight power quirk\n");
> }
>
> +static void quirk_ignore_default_pwm_frequency(struct drm_i915_private *i915)
> +{
> + intel_set_quirk(i915, QUIRK_IGNORE_DEFAULT_PWM_FREQUENCY);
> + drm_info(>drm, "Applying ignore default pwm frequency quirk");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -90,6 +96,12 @@ static int intel_dmi_no_pps_backlight(const struct
> dmi_system_id *id)
> return 1;
> }
>
> +static int intel_dmi_ignore_default_pwm_frequency(const struct dmi_system_id
> *id)
> +{
> + DRM_INFO("Default PWM frequency is incorrect and is overridden on
> %s\n", id->ident);
> + return 1;
> +}
> +
> static const struct intel_dmi_quirk intel_dmi_quirks[] = {
> {
> .dmi_id_list = &(const struct dmi_system_id[]) {
> @@ -136,6 +148,20 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] =
> {
> },
> .hook = quirk_no_pps_backlight_power_hook,
> },
> + {
> + .dmi_id_list = &(const struct dmi_system_id[]) {
> + {
> + .callback =
> intel_dmi_ignore_default_pwm_frequency,
> + .ident = "Cybernet T10C Tablet",
> + .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR,
> + "Cybernet
> Manufacturing Inc."),
> + DMI_EXACT_MATCH(DMI_BOARD_NAME,
> "T10C Tablet"),
> + },
> + },
> + { }
> + },
> + .hook = quirk_ignore_default_pwm_frequency,
> + },
> };
>
> static struct intel_quirk intel_quirks[] = {
> diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h
> b/drivers/gpu/drm/i915/display/intel_quirks.h
> index 10a4d163149fd..70589505e5a0e 100644
> --- a/drivers/gpu/drm/i915/display/intel_quirks.h
> +++ b/drivers/gpu/drm/i915/display/intel_quirks.h
> @@ -17,6 +17,7 @@ enum intel_quirk_id {
> QUIRK_INVERT_BRIGHTNESS,
> QUIRK_LVDS_SSC_DISABLE,
> QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK,
> + QUIRK_IGNORE_DEFAULT_PWM_FREQUENCY
You want a trailing comma here.
> };
>
> void intel_init_quirks(struct drm_i915_private *i915);
> --
> 2.42.0.655.g421f12c284-goog
>
Thanks.
--
Dmitry
Re: [PATCH 0/9] drm/panel and i2c-hid: Allow panels and touchscreens to power sequence together
Hi Doug,
On Tue, May 23, 2023 at 12:27:54PM -0700, Douglas Anderson wrote:
>
> The big motivation for this patch series is mostly described in the patch
> ("drm/panel: Add a way for other devices to follow panel state"), but to
> quickly summarize here: for touchscreens that are connected to a panel we
> need the ability to power sequence the two device together. This is not a
> new need, but so far we've managed to get by through a combination of
> inefficiency, added costs, or perhaps just a little bit of brokenness.
> It's time to do better. This patch series allows us to do better.
This seems to grow a new way of building relationship between panels and
associated devices. Can we make device_link_*() work for us?
Thanks.
--
Dmitry
Re: [PATCH v3 1/3] Input: ads7846 - Convert to use software nodes
On Mon, May 08, 2023 at 11:23:44PM +0200, Linus Walleij wrote: > On Fri, May 5, 2023 at 8:08 PM Dmitry Torokhov > wrote: > > > > - return !gpio_get_value(ts->gpio_pendown); > > > + return !gpiod_get_value(ts->gpio_pendown); > > > > This needs to be > > > > return !gpiod_get_value_raw(ts->gpio_pendown); > > There is no such function. The gpio descriptor runpath simply assumes that > device trees can be trusted. Sorry, this was supposed to be gpiod_get_raw_value(): https://elixir.bootlin.com/linux/latest/source/drivers/gpio/gpiolib.c#L2854 > > > I looked at various DTSes we have and they use a mix of active high and > > active low annotations, so we have to go with the "raw" variant for now, > > and then update to normal one once we update bad DTSes. > > I just sighed and fixed all the device trees :D Yeah, we we can land the DT fixes ahead of the driver change that would be great. Otherwise we need a temporary application of gpiod_get_raw_value(). > > Yours, > Linus Walleij -- Dmitry
Re: [PATCH v4 1/4] Input: ads7846 - Convert to use software nodes
On Mon, May 08, 2023 at 11:20:06PM +0200, Linus Walleij wrote:
> The Nokia 770 is using GPIOs from the global numberspace on the
> CBUS node to pass down to the LCD controller. This regresses when we
> let the OMAP GPIO driver use dynamic GPIO base.
>
> The Nokia 770 now has dynamic allocation of IRQ numbers, so this
> needs to be fixed for it to work.
>
> As this is the only user of LCD MIPID we can easily augment the
> driver to use a GPIO descriptor instead and resolve the issue.
>
> The platform data .shutdown() callback wasn't even used in the
> code, but we encode a shutdown asserting RESET in the remove()
> callback for completeness sake.
>
> The CBUS also has the ADS7846 touchscreen attached.
>
> Populate the devices on the Nokia 770 CBUS I2C using software
> nodes instead of platform data quirks. This includes the LCD
> and the ADS7846 touchscreen so the conversion just brings the LCD
> along with it as software nodes is an all-or-nothing design
> pattern.
>
> The ADS7846 has some limited support for using GPIO descriptors,
> let's convert it over completely to using device properties and then
> fix all remaining boardfile users to provide all platform data using
> software nodes.
>
> Dump the of includes and of_match_ptr() in the ADS7846 driver as part
> of the job.
>
> Since we have to move ADS7846 over to obtaining the GPIOs it is
> using exclusively from descriptors, we provide descriptor tables
> for the two remaining in-kernel boardfiles using ADS7846:
>
> - PXA Spitz
> - MIPS Alchemy DB1000 development board
>
> It was too hard for me to include software node conversion of
> these two remaining users at this time: the spitz is using a
> hscync callback in the platform data that would require further
> GPIO descriptor conversion of the Spitz, and moving the hsync
> callback down into the driver: it will just become too big of
> a job, but it can be done separately.
>
> The MIPS Alchemy DB1000 is simply something I cannot test, so take
> the easier approach of just providing some GPIO descriptors in
> this case as I don't want the patch to grow too intrusive.
>
> As we see that several device trees have incorrect polarity flags
> and just expect to bypass the gpiolib polarity handling, fix up
> all device trees too, in a separate patch.
>
> Suggested-by: Dmitry Torokhov
> Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v3->v4:
> - Fix all board file polarity flags to be active low, because
> this pendown signal is active low.
> - Fix all erroneous device trees too.
> - Drop some unnecessary commas.
> ChangeLog v2->v3:
> - Drop leftover OF ifdefs no longer needed and causing compile
> errors.
> ---
> arch/arm/mach-omap1/board-nokia770.c| 98 +--
> arch/arm/mach-pxa/spitz.c | 11 +++-
> arch/mips/alchemy/devboards/db1000.c| 11 +++-
> drivers/input/touchscreen/ads7846.c | 113
>
For input:
Acked-by: Dmitry Torokhov
In general:
Reviewed-by: Dmitry Torokhov
Thanks.
--
Dmitry
Re: [PATCH v3 1/3] Input: ads7846 - Convert to use software nodes
Hi Linus,
On Fri, May 05, 2023 at 01:16:55PM +0200, Linus Walleij wrote:
>
> Populate the devices on the Nokia 770 CBUS I2C using software
> nodes instead of platform data quirks. This includes the LCD
> and the ADS7846 touchscreen so the conversion just brings the LCD
> along with it as software nodes is an all-or-nothing design
> pattern.
Wow, so that worked , awesome!
> +static const struct property_entry nokia770_ads7846_props[] = {
> + PROPERTY_ENTRY_U32("touchscreen-size-x", 4096),
> + PROPERTY_ENTRY_U32("touchscreen-size-y", 4096),
> + PROPERTY_ENTRY_U32("touchscreen-max-pressure", 256),
> + PROPERTY_ENTRY_U32("touchscreen-average-samples", 10),
> + PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
> + PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
> + PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
> + PROPERTY_ENTRY_GPIO("pendown-gpios", _gpiochip1_node,
> + ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_HIGH),
Looking at the driver this actually needs to be GPIO_ACTIVE_LOW.
>
> +static struct gpiod_lookup_table spitz_ads7846_gpio_table = {
> + .dev_id = "spi2.0",
> + .table = {
> + GPIO_LOOKUP("gpio-pxa", SPITZ_GPIO_TP_INT,
> + "pendown", GPIO_ACTIVE_HIGH),
GPIO_ACTIVE_LOW here too.
> +static struct gpiod_lookup_table db1100_touch_gpio_table = {
> + .dev_id = "spi0.0",
> + .table = {
> + GPIO_LOOKUP("alchemy-gpio2", 21,
> + "pendown", GPIO_ACTIVE_HIGH),
And here as well.
> @@ -223,7 +220,7 @@ static int get_pendown_state(struct ads7846 *ts)
> if (ts->get_pendown_state)
> return ts->get_pendown_state();
>
> - return !gpio_get_value(ts->gpio_pendown);
> + return !gpiod_get_value(ts->gpio_pendown);
This needs to be
return !gpiod_get_value_raw(ts->gpio_pendown);
I looked at various DTSes we have and they use a mix of active high and
active low annotations, so we have to go with the "raw" variant for now,
and then update to normal one once we update bad DTSes.
Thanks!
--
Dmitry
Re: [PATCH 1/4] Input/ARM: ads7846: Get pendown IRQ from descriptors
On Sun, Apr 30, 2023 at 11:22:16AM +0200, Linus Walleij wrote:
> The ADS7846 has some limited support for using GPIO descriptors,
> let's convert it over completely and fix all users to provide
> GPIOs in descriptor tables.
>
> The Nokia 770 now has dynamic allocation of IRQ numbers, so this
> needs to be fixed for it to work.
>
> Fixes: 92bf78b33b0b ("gpio: omap: use dynamic allocation of base")
> Signed-off-by: Linus Walleij
> ---
> arch/arm/mach-omap1/board-nokia770.c | 12 +++-
> arch/arm/mach-pxa/spitz.c| 11 ++-
> arch/mips/alchemy/devboards/db1000.c | 11 ++-
> drivers/input/touchscreen/ads7846.c | 32
> include/linux/spi/ads7846.h | 2 --
> 5 files changed, 39 insertions(+), 29 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/board-nokia770.c
> b/arch/arm/mach-omap1/board-nokia770.c
> index a501a473ffd6..eb7652670447 100644
> --- a/arch/arm/mach-omap1/board-nokia770.c
> +++ b/arch/arm/mach-omap1/board-nokia770.c
> @@ -118,7 +118,16 @@ static struct ads7846_platform_data
> nokia770_ads7846_platform_data __initdata =
> .debounce_max = 10,
> .debounce_tol = 3,
> .debounce_rep = 1,
> - .gpio_pendown = ADS7846_PENDOWN_GPIO,
> +};
> +
> +static struct gpiod_lookup_table nokia770_ads7846_gpio_table = {
> + /* SPI bus 2, device with chip select 0 */
> + .dev_id = "spi2.0",
> + .table = {
> + GPIO_LOOKUP("gpio-0-15", ADS7846_PENDOWN_GPIO,
> + "pendown", GPIO_ACTIVE_HIGH),
> + { }
> + },
> };
I would like to eventually get rid of GPIO_LOOKUP in favor of
PROPERTY_ENTRY_GPIO. Can we try something like the draft below (just
typed, not even compiled):
diff --git a/arch/arm/mach-omap1/board-nokia770.c
b/arch/arm/mach-omap1/board-nokia770.c
index a501a473ffd6..34b8e392b917 100644
--- a/arch/arm/mach-omap1/board-nokia770.c
+++ b/arch/arm/mach-omap1/board-nokia770.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
@@ -35,6 +36,24 @@
#include "clock.h"
#include "mmc.h"
+static const struct software_node nokia770_mpuio_gpiochip_node = {
+ .name = "mpuio",
+};
+
+static const struct software_node nokia770_gpiochip1_node = {
+ .name = "gpio-0-15",
+};
+
+static const struct software_node nokia770_gpiochip2_node = {
+ .name = "gpio-16-31",
+};
+
+static const struct software_node nokia770_gpiochip_nodes[] = {
+ _mpuio_gpiochip_node
+ _gpiochip1_node,
+ _gpiochip2_node,
+};
+
#define ADS7846_PENDOWN_GPIO 15
static const unsigned int nokia770_keymap[] = {
@@ -102,6 +121,17 @@ static const struct omap_lcd_config nokia770_lcd_config
__initconst = {
.ctrl_name = "hwa742",
};
+static const struct property_entry nokia770_mipid_props[] = {
+ PROPERTY_ENTRY_GPIO("reset-gpios", _gpiochip1_node,
+ 13, GPIO_ACTIVE_LOW),
+ { }
+};
+
+static const struct software_node nokia770_mipid_swnode = {
+ .name = "lcd_mipid",
+ .properties = nokia770_mipid_props,
+};
+
static void __init mipid_dev_init(void)
{
nokia770_mipid_platform_data.nreset_gpio = 13;
@@ -110,15 +140,22 @@ static void __init mipid_dev_init(void)
omapfb_set_lcd_config(_lcd_config);
}
-static struct ads7846_platform_data nokia770_ads7846_platform_data __initdata
= {
- .x_max = 0x0fff,
- .y_max = 0x0fff,
- .x_plate_ohms = 180,
- .pressure_max = 255,
- .debounce_max = 10,
- .debounce_tol = 3,
- .debounce_rep = 1,
- .gpio_pendown = ADS7846_PENDOWN_GPIO,
+static const struct property_entry nokia770_ads7846_props[] = {
+ PROPERTY_ENTRY_U32("touchscreen-size-x", 4096),
+ PROPERTY_ENTRY_U32("touchscreen-size-y", 4096),
+ PROPERTY_ENTRY_U32("touchscreen-max-pressure", 256),
+ PROPERTY_ENTRY_U32("touchscreen-average-samples", 10),
+ PROPERTY_ENTRY_U16("ti,x-plate-ohms", 180),
+ PROPERTY_ENTRY_U16("ti,debounce-tol", 3),
+ PROPERTY_ENTRY_U16("ti,debounce-rep", 1),
+ PROPERTY_ENTRY_GPIO("pendown-gpios", _gpiochip1_node,
+ ADS7846_PENDOWN_GPIO, GPIO_ACTIVE_HIGH),
+ { }
+};
+
+static const struct software_node nokia770_ads7846_swnode = {
+ .name = "ads7846",
+ .properties = nokia770_ads7846_props,
};
static struct spi_board_info nokia770_spi_board_info[] __initdata = {
@@ -128,13 +165,14 @@ static struct spi_board_info nokia770_spi_board_info[]
__initdata = {
.chip_select= 3,
.max_speed_hz = 1200,
.platform_data = _mipid_platform_data,
+ .swnode = _mipid_swnode,
},
[1] = {
.modalias = "ads7846",
.bus_num= 2,
.chip_select= 0,
.max_speed_hz = 250,
- .platform_data =
Re: [PATCH 1/2] backlight: hx8357: switch to using gpiod API
On Mon, Feb 06, 2023 at 11:35:32AM +, Daniel Thompson wrote:
> On Tue, Jan 31, 2023 at 02:57:06PM -0800, Dmitry Torokhov wrote:
> > Switch the driver from legacy gpio API that is deprecated to the newer
> > gpiod API that respects line polarities described in ACPI/DT.
> >
> > This makes driver use standard property name for the reset gpio
> > ("reset-gpios" vs "gpios-reset"), however there is a quirk in gpiolib
> > to also recognize the legacy name and keep compatibility with older
> > DTSes.
> >
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > All preparation gpiolib work to handle legacy names and polarity quirks
> > has landed in mainline...
> >
> > drivers/video/backlight/hx8357.c | 82 ++--
> > 1 file changed, 37 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/video/backlight/hx8357.c
> > b/drivers/video/backlight/hx8357.c
> > index 9b50bc96e00f..a93e14adb846 100644
> > --- a/drivers/video/backlight/hx8357.c
> > +++ b/drivers/video/backlight/hx8357.c
> > [snip]
> > - if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
> > - lcd->use_im_pins = 1;
> > -
> > - for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> > - lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
> > - "im-gpios", i);
> > - if (lcd->im_pins[i] == -EPROBE_DEFER) {
> > - dev_info(>dev, "GPIO requested is not here
> > yet, deferring the probe\n");
> > - return -EPROBE_DEFER;
> > - }
> > - if (!gpio_is_valid(lcd->im_pins[i])) {
> > - dev_err(>dev, "Missing dt property:
> > im-gpios\n");
> > - return -EINVAL;
> > + gpiod_set_consumer_name(lcd->reset, "hx8357-reset");
> > +
> > + for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
> > + lcd->im_pins[i] = devm_gpiod_get_index(>dev,
> > + "im", i, GPIOD_OUT_LOW);
> > + ret = PTR_ERR_OR_ZERO(lcd->im_pins[i]);
> > + if (ret) {
> > + if (ret == -ENOENT) {
> > + if (i == 0)
> > + break;
> > + dev_err(>dev, "Missing im gpios[%d]\n", i);
> > + ret = -EINVAL;
> > + } if (ret == -EPROBE_DEFER) {
I see I miss "else" here...
> > + dev_info(>dev, "im gpio[%d] is not here
> > yet, deferring the probe\n",
> > +i);
> > + } else {
> > + dev_err(>dev, "failed to request im
> > gpio[%d]: %d\n",
> > + i, ret);
> > }
>
> These last two clauses should be updated to return dev_err_probe(...)
> instead.
>
> With that change:
> Reviewed-by: Daniel Thompson
So you want to actually suppress the deferral message unless debug
printks are enabled? So you want this to read:
if (ret) {
if (ret == -ENOENT) {
if (i == 0)
break;
dev_err(>dev, "Missing im gpios[%d]\n", i);
return -EINVAL;
}
return dev_err_probe(>dev, ret,
"failed to request im gpio[%d]\n",
i);
}
Did I get it right?
Thanks.
--
Dmitry
[PATCH 2/2] backlight: hx8357: stop using of-specific APIs
There is no need for this driver to be OF-specific, so switch it to
use device_get_match_data() and stop including various of-related
headers.
Signed-off-by: Dmitry Torokhov
---
drivers/video/backlight/hx8357.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a93e14adb846..2e162a70c1ce 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -10,8 +10,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -581,11 +581,15 @@ MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
static int hx8357_probe(struct spi_device *spi)
{
+ int (*lcd_init_fn)(struct lcd_device *);
struct lcd_device *lcdev;
struct hx8357_data *lcd;
- const struct of_device_id *match;
int i, ret;
+ lcd_init_fn = device_get_match_data(>dev);
+ if (!lcd_init_fn)
+ return -EINVAL;
+
lcd = devm_kzalloc(>dev, sizeof(*lcd), GFP_KERNEL);
if (!lcd)
return -ENOMEM;
@@ -598,10 +602,6 @@ static int hx8357_probe(struct spi_device *spi)
lcd->spi = spi;
- match = of_match_device(hx8357_dt_ids, >dev);
- if (!match || !match->data)
- return -EINVAL;
-
lcd->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
@@ -647,7 +647,7 @@ static int hx8357_probe(struct spi_device *spi)
hx8357_lcd_reset(lcdev);
- ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
+ ret = lcd_init_fn(lcdev);
if (ret) {
dev_err(>dev, "Couldn't initialize panel\n");
return ret;
--
2.39.1.456.gfc5497dd1b-goog
[PATCH 1/2] backlight: hx8357: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
This makes driver use standard property name for the reset gpio
("reset-gpios" vs "gpios-reset"), however there is a quirk in gpiolib
to also recognize the legacy name and keep compatibility with older
DTSes.
Signed-off-by: Dmitry Torokhov
---
All preparation gpiolib work to handle legacy names and polarity quirks
has landed in mainline...
drivers/video/backlight/hx8357.c | 82 ++--
1 file changed, 37 insertions(+), 45 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 9b50bc96e00f..a93e14adb846 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -6,11 +6,12 @@
*/
#include
+#include
+#include
#include
#include
#include
#include
-#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -83,8 +84,8 @@
#define HX8369_SET_GAMMA_CURVE_RELATED 0xe0
struct hx8357_data {
- unsignedim_pins[HX8357_NUM_IM_PINS];
- unsignedreset;
+ struct gpio_desc*im_pins[HX8357_NUM_IM_PINS];
+ struct gpio_desc*reset;
struct spi_device *spi;
int state;
booluse_im_pins;
@@ -321,11 +322,11 @@ static void hx8357_lcd_reset(struct lcd_device *lcdev)
struct hx8357_data *lcd = lcd_get_data(lcdev);
/* Reset the screen */
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 0);
+ gpiod_set_value_cansleep(lcd->reset, 1);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
/* The controller needs 120ms to recover from reset */
msleep(120);
@@ -341,9 +342,9 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
* wires
*/
if (lcd->use_im_pins) {
- gpio_set_value_cansleep(lcd->im_pins[0], 1);
- gpio_set_value_cansleep(lcd->im_pins[1], 0);
- gpio_set_value_cansleep(lcd->im_pins[2], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[0], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[1], 0);
+ gpiod_set_value_cansleep(lcd->im_pins[2], 1);
}
ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
@@ -601,48 +602,39 @@ static int hx8357_probe(struct spi_device *spi)
if (!match || !match->data)
return -EINVAL;
- lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
- if (!gpio_is_valid(lcd->reset)) {
- dev_err(>dev, "Missing dt property: gpios-reset\n");
- return -EINVAL;
- }
-
- ret = devm_gpio_request_one(>dev, lcd->reset,
- GPIOF_OUT_INIT_HIGH,
- "hx8357-reset");
+ lcd->reset = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
- dev_err(>dev,
- "failed to request gpio %d: %d\n",
- lcd->reset, ret);
- return -EINVAL;
+ dev_err(>dev, "failed to request reset gpio: %d\n", ret);
+ return ret;
}
- if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
- lcd->use_im_pins = 1;
-
- for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
- lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
- "im-gpios", i);
- if (lcd->im_pins[i] == -EPROBE_DEFER) {
- dev_info(>dev, "GPIO requested is not here
yet, deferring the probe\n");
- return -EPROBE_DEFER;
- }
- if (!gpio_is_valid(lcd->im_pins[i])) {
- dev_err(>dev, "Missing dt property:
im-gpios\n");
- return -EINVAL;
+ gpiod_set_consumer_name(lcd->reset, "hx8357-reset");
+
+ for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+ lcd->im_pins[i] = devm_gpiod_get_index(>dev,
+ "im", i, GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->im_pins[i]);
+ if (ret) {
+ if (ret == -ENOENT) {
+ if (i == 0)
+ break;
+
[RESEND PATCH] drm/tegra: switch to using devm_fwnode_gpiod_get()
devm_gpiod_get_from_of_node() is going away and GPIO consumers should
use generic device/firmware node APIs to fetch GPIOs assigned to them.
Switch the driver to use devm_fwnode_gpiod_get() instead.
Signed-off-by: Dmitry Torokhov
---
Marked as "resend" since the contents of the patch are the same (however
I did update the description a bit).
drivers/gpu/drm/tegra/output.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 47d26b5d9945..a8925dcd7edd 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -133,11 +133,11 @@ int tegra_output_probe(struct tegra_output *output)
}
}
- output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
- output->of_node,
- "nvidia,hpd-gpio", 0,
- GPIOD_IN,
- "HDMI hotplug detect");
+ output->hpd_gpio = devm_fwnode_gpiod_get(output->dev,
+ of_fwnode_handle(output->of_node),
+ "nvidia,hpd",
+ GPIOD_IN,
+ "HDMI hotplug detect");
if (IS_ERR(output->hpd_gpio)) {
if (PTR_ERR(output->hpd_gpio) != -ENOENT)
return PTR_ERR(output->hpd_gpio);
--
2.38.1.431.g37b22c650d-goog
--
Dmitry
[PATCH RESEND 13/13] omapfb: panel-sharp-ls037v7dw01: fix included headers
The driver is using gpiod API so it should include gpio/consumer.h and not gpio.gh or of_gpio.h. Signed-off-by: Dmitry Torokhov --- drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c index f1072c319de8..cc30758300e2 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c @@ -7,10 +7,9 @@ */ #include -#include +#include #include #include -#include #include #include #include -- b4 0.11.0-dev-28747
[PATCH RESEND 10/13] omapfb: encoder-opa362: fix included headers
The driver has been switched to gpiod API, so it should include gpio/consumer.h instead of gpio.h and of_gpio.h. With of_gpio.h no longer included we need mod_devicetable.h for of_device_id definition. Signed-off-by: Dmitry Torokhov --- drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c index ba7ed4039f8a..dd29dc5c77ec 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c @@ -11,11 +11,11 @@ * Author: Tomi Valkeinen */ -#include +#include #include +#include #include #include -#include #include -- b4 0.11.0-dev-28747
[PATCH RESEND 11/13] omapfb: panel-lgphilips-lb035q02: remove backlight GPIO handling
With f048e8c1d169 ("omapfb: panel-lgphilips-lb035q02: Remove legacy boot
support") it is no longer possible to specify GPIO to control the
backlight. Remove code trying to request and toggle it.
Signed-off-by: Dmitry Torokhov
---
.../omapfb/displays/panel-lgphilips-lb035q02.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git
a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
index 3ce1f9d2e7c4..e69856cb62d5 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#include
+#include
#include
@@ -46,9 +46,6 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- /* used for non-DT boot, to be removed */
- int backlight_gpio;
-
struct gpio_desc *enable_gpio;
};
@@ -166,9 +163,6 @@ static int lb035q02_enable(struct omap_dss_device *dssdev)
if (ddata->enable_gpio)
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 1);
-
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -185,9 +179,6 @@ static void lb035q02_disable(struct omap_dss_device *dssdev)
if (ddata->enable_gpio)
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 0);
-
in->ops.dpi->disable(in);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
@@ -250,8 +241,6 @@ static int lb035q02_probe_of(struct spi_device *spi)
ddata->enable_gpio = gpio;
- ddata->backlight_gpio = -ENOENT;
-
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(>dev, "failed to find video source\n");
@@ -284,13 +273,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
if (r)
return r;
- if (gpio_is_valid(ddata->backlight_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->backlight_gpio,
- GPIOF_OUT_INIT_LOW, "panel backlight");
- if (r)
- goto err_gpio;
- }
-
ddata->videomode = lb035q02_timings;
dssdev = >dssdev;
@@ -310,7 +292,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
b4 0.11.0-dev-28747
[PATCH RESEND 12/13] omapfb: panel-tpo-td028ttec1: stop including gpio.h
The driver does not use gpios, so there is no need to include gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 3c0f887d3092..c18d290693c1 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
struct panel_drv_data {
--
b4 0.11.0-dev-28747
[PATCH RESEND 07/13] omapfb: panel-nec-nl8048hl11: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 ++
1 file changed, 20 insertions(+), 52 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
index b407173e27b1..33563953b2ff 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
@@ -7,12 +7,12 @@
* Converted to new DSS device model: Tomi Valkeinen
*/
-#include
#include
-#include
+#include
#include
-#include
-#include
+#include
+#include
+#include
#include
@@ -24,8 +24,7 @@ struct panel_drv_data {
int data_lines;
- int res_gpio;
- int qvga_gpio;
+ struct gpio_desc *res_gpio;
struct spi_device *spi;
};
@@ -155,8 +154,8 @@ static int nec_8048_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata->res_gpio))
- gpio_set_value_cansleep(ddata->res_gpio, 1);
+ /* Apparently existing DTSes use incorrect polarity (active high) */
+ gpiod_set_value_cansleep(ddata->res_gpio, 1);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -171,8 +170,8 @@ static void nec_8048_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->res_gpio))
- gpio_set_value_cansleep(ddata->res_gpio, 0);
+ /* Apparently existing DTSes use incorrect polarity (active high) */
+ gpiod_set_value_cansleep(ddata->res_gpio, 0);
in->ops.dpi->disable(in);
@@ -222,35 +221,6 @@ static struct omap_dss_driver nec_8048_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-
-static int nec_8048_probe_of(struct spi_device *spi)
-{
- struct device_node *node = spi->dev.of_node;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse enable gpio\n");
- return gpio;
- }
- ddata->res_gpio = gpio;
-
- /* XXX the panel spec doesn't mention any QVGA pin?? */
- ddata->qvga_gpio = -ENOENT;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int nec_8048_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -281,24 +251,22 @@ static int nec_8048_probe(struct spi_device *spi)
ddata->spi = spi;
- r = nec_8048_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
return r;
-
- if (gpio_is_valid(ddata->qvga_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->qvga_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd QVGA");
- if (r)
- goto err_gpio;
}
- if (gpio_is_valid(ddata->res_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->res_gpio,
- GPIOF_OUT_INIT_LOW, "lcd RES");
- if (r)
- goto err_gpio;
+ ddata->res_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ r = PTR_ERR_OR_ZERO(ddata->res_gpio);
+ if (r) {
+ dev_err(>dev, "failed to request reset gpio: %d\n", r);
+ goto err_gpio;
}
+ gpiod_set_consumer_name(ddata->res_gpio, "lcd RES");
+
ddata->videomode = nec_8048_panel_timings;
dssdev = >dssdev;
--
b4 0.11.0-dev-28747
[PATCH RESEND 08/13] omapfb: panel-dpi: remove support for platform data
There are no users of panel_dpi_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++
include/video/omap-panel-data.h| 21 --
2 files changed, 7 insertions(+), 97 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
index ff3d1e8e1e7b..9790053c5877 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
@@ -6,15 +6,13 @@
* Author: Tomi Valkeinen
*/
-#include
+#include
#include
#include
#include
#include
-#include
#include
-#include
#include
struct panel_drv_data {
@@ -25,9 +23,6 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- /* used for non-DT boot, to be removed */
- int backlight_gpio;
-
struct gpio_desc *enable_gpio;
};
@@ -77,9 +72,6 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 1);
-
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -93,9 +85,6 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 0);
-
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
in->ops.dpi->disable(in);
@@ -146,49 +135,6 @@ static struct omap_dss_driver panel_dpi_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int panel_dpi_probe_pdata(struct platform_device *pdev)
-{
- const struct panel_dpi_platform_data *pdata;
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *dssdev, *in;
- struct videomode vm;
- int r;
-
- pdata = dev_get_platdata(>dev);
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "failed to find video source '%s'\n",
- pdata->source);
- return -EPROBE_DEFER;
- }
-
- ddata->in = in;
-
- ddata->data_lines = pdata->data_lines;
-
- videomode_from_timing(pdata->display_timing, );
- videomode_to_omap_video_timings(, >videomode);
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- r = devm_gpio_request_one(>dev, pdata->enable_gpio,
- GPIOF_OUT_INIT_LOW, "panel enable");
- if (r)
- goto err_gpio;
-
- ddata->enable_gpio = gpio_to_desc(pdata->enable_gpio);
-
- ddata->backlight_gpio = pdata->backlight_gpio;
-
- return 0;
-
-err_gpio:
- omap_dss_put_device(ddata->in);
- return r;
-}
-
static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
@@ -205,8 +151,6 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
ddata->enable_gpio = gpio;
- ddata->backlight_gpio = -ENOENT;
-
r = of_get_display_timing(node, "panel-timing", );
if (r) {
dev_err(>dev, "failed to get video timing\n");
@@ -233,30 +177,18 @@ static int panel_dpi_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (ddata == NULL)
return -ENOMEM;
platform_set_drvdata(pdev, ddata);
- if (dev_get_platdata(>dev)) {
- r = panel_dpi_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = panel_dpi_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
- }
-
- if (gpio_is_valid(ddata->backlight_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->backlight_gpio,
- GPIOF_OUT_INIT_LOW, "panel backlight");
- if (r)
- goto err_gpio;
- }
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
dssdev = >dssdev;
dssdev->dev = >dev;
@@ -275,7 +207,6 @@ static int panel_dpi_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return
[PATCH RESEND 09/13] omapfb: connector-analog-tv: remove support for platform data
There are no users of connector_atv_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/connector-analog-tv.c| 60 +++---
include/video/omap-panel-data.h| 34
2 files changed, 8 insertions(+), 86 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
index a9fd732f8103..0daaf9f89bab 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
@@ -12,7 +12,6 @@
#include
#include
-#include
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -178,53 +177,15 @@ static struct omap_dss_driver tvc_driver = {
.set_wss= tvc_set_wss,
};
-static int tvc_probe_pdata(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct connector_atv_platform_data *pdata;
- struct omap_dss_device *in, *dssdev;
-
- pdata = dev_get_platdata(>dev);
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "Failed to find video source\n");
- return -EPROBE_DEFER;
- }
-
- ddata->in = in;
-
- ddata->invert_polarity = pdata->invert_polarity;
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
-static int tvc_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
@@ -232,16 +193,11 @@ static int tvc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = >dev;
- if (dev_get_platdata(>dev)) {
- r = tvc_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = tvc_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
+ return r;
}
ddata->timings = tvc_pal_timings;
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
deleted file mode 100644
index 18172d7b97d0..
--- a/include/video/omap-panel-data.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Header containing platform_data structs for omap panels
- *
- * Copyright (C) 2013 Texas Instruments
- * Author: Tomi Valkeinen
- *Archit Taneja
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Mayuresh Janorkar
- *
- * Copyright (C) 2010 Canonical Ltd.
- * Author: Bryan Wu
- */
-
-#ifndef __OMAP_PANEL_DATA_H
-#define __OMAP_PANEL_DATA_H
-
-#include
-
-/**
- * connector_atv platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- * @invert_polarity: invert signal polarity
- */
-struct connector_atv_platform_data {
- const char *name;
- const char *source;
-
- bool invert_polarity;
-};
-
-#endif /* __OMAP_PANEL_DATA_H */
--
b4 0.11.0-dev-28747
[PATCH RESEND 06/13] omapfb: panel-tpo-td043mtea1: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 ++
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
index c0e4e0315b6b..1eaa35c27835 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
@@ -10,10 +10,9 @@
#include
#include
#include
-#include
+#include
#include
#include
-#include
#include
@@ -58,7 +57,7 @@ struct panel_drv_data {
struct spi_device *spi;
struct regulator *vcc_reg;
- int nreset_gpio;
+ struct gpio_desc *reset_gpio;
u16 gamma[12];
u32 mode;
u32 hmirror:1;
@@ -296,8 +295,7 @@ static int tpo_td043_power_on(struct panel_drv_data *ddata)
/* wait for panel to stabilize */
msleep(160);
- if (gpio_is_valid(ddata->nreset_gpio))
- gpio_set_value(ddata->nreset_gpio, 1);
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
tpo_td043_write(ddata->spi, 2,
TPO_R02_MODE(ddata->mode) | TPO_R02_NCLK_RISING);
@@ -320,8 +318,7 @@ static void tpo_td043_power_off(struct panel_drv_data
*ddata)
tpo_td043_write(ddata->spi, 3,
TPO_R03_VAL_STANDBY | TPO_R03_EN_PWM);
- if (gpio_is_valid(ddata->nreset_gpio))
- gpio_set_value(ddata->nreset_gpio, 0);
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
/* wait for at least 2 vsyncs before cutting off power */
msleep(50);
@@ -454,32 +451,6 @@ static struct omap_dss_driver tpo_td043_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-
-static int tpo_td043_probe_of(struct spi_device *spi)
-{
- struct device_node *node = spi->dev.of_node;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse enable gpio\n");
- return gpio;
- }
- ddata->nreset_gpio = gpio;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tpo_td043_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -508,9 +479,12 @@ static int tpo_td043_probe(struct spi_device *spi)
ddata->spi = spi;
- r = tpo_td043_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
return r;
+ }
ddata->mode = TPO_R02_MODE_800x480;
memcpy(ddata->gamma, tpo_td043_def_gamma, sizeof(ddata->gamma));
@@ -521,16 +495,15 @@ static int tpo_td043_probe(struct spi_device *spi)
goto err_regulator;
}
- if (gpio_is_valid(ddata->nreset_gpio)) {
- r = devm_gpio_request_one(>dev,
- ddata->nreset_gpio, GPIOF_OUT_INIT_LOW,
- "lcd reset");
- if (r < 0) {
- dev_err(>dev, "couldn't request reset GPIO\n");
- goto err_gpio_req;
- }
+ ddata->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
+ r = PTR_ERR_OR_ZERO(ddata->reset_gpio);
+ if (r) {
+ dev_err(>dev, "couldn't request reset GPIO\n");
+ goto err_gpio_req;
}
+ gpiod_set_consumer_name(ddata->reset_gpio, "lcd reset");
+
r = sysfs_create_group(>dev.kobj, _td043_attr_group);
if (r) {
dev_err(>dev, "failed to create sysfs files\n");
--
b4 0.11.0-dev-28747
[PATCH RESEND 05/13] omapfb: panel-dsi-cm: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 -
1 file changed, 45 insertions(+), 71 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index a2c7c5cb1523..4fc4b26a8d30 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -10,8 +10,9 @@
#include
#include
+#include
#include
-#include
+#include
#include
#include
#include
@@ -20,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
@@ -53,8 +53,8 @@ struct panel_drv_data {
unsigned long hw_guard_wait; /* max guard time in jiffies */
/* panel HW configuration from DT or platform data */
- int reset_gpio;
- int ext_te_gpio;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *ext_te_gpio;
bool use_dsi_backlight;
@@ -250,8 +250,8 @@ static int dsicm_enter_ulps(struct panel_drv_data *ddata)
if (r)
goto err;
- if (gpio_is_valid(ddata->ext_te_gpio))
- disable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ disable_irq(gpiod_to_irq(ddata->ext_te_gpio));
in->ops.dsi->disable(in, false, true);
@@ -292,8 +292,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
goto err2;
}
- if (gpio_is_valid(ddata->ext_te_gpio))
- enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
dsicm_queue_ulps_work(ddata);
@@ -306,8 +306,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
r = dsicm_panel_reset(ddata);
if (!r) {
- if (gpio_is_valid(ddata->ext_te_gpio))
- enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
ddata->ulps_enabled = false;
}
err1:
@@ -556,16 +556,19 @@ static const struct attribute_group dsicm_attr_group = {
static void dsicm_hw_reset(struct panel_drv_data *ddata)
{
- if (!gpio_is_valid(ddata->reset_gpio))
- return;
-
- gpio_set_value(ddata->reset_gpio, 1);
+ /*
+* Note that we appear to activate the reset line here. However
+* existing DTSes specified incorrect polarity for it (active high),
+* so in fact this deasserts the reset line.
+*/
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
udelay(10);
/* reset the panel */
- gpio_set_value(ddata->reset_gpio, 0);
- /* assert reset */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
+ /* keep reset asserted */
udelay(10);
- gpio_set_value(ddata->reset_gpio, 1);
+ /* release reset line */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
/* wait after releasing reset */
usleep_range(5000, 1);
}
@@ -886,7 +889,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
if (r)
goto err;
- if (ddata->te_enabled && gpio_is_valid(ddata->ext_te_gpio)) {
+ if (ddata->te_enabled && ddata->ext_te_gpio) {
schedule_delayed_work(>te_timeout_work,
msecs_to_jiffies(250));
atomic_set(>do_update, 1);
@@ -933,7 +936,7 @@ static int _dsicm_enable_te(struct panel_drv_data *ddata,
bool enable)
else
r = dsicm_dcs_write_0(ddata, MIPI_DCS_SET_TEAR_OFF);
- if (!gpio_is_valid(ddata->ext_te_gpio))
+ if (!ddata->ext_te_gpio)
in->ops.dsi->enable_te(in, enable);
/* possible panel bug */
@@ -1115,41 +1118,6 @@ static struct omap_dss_driver dsicm_ops = {
.memory_read= dsicm_memory_read,
};
-static int dsicm_probe_of(struct platform_device *pdev)
-{
- struct device_node *node = pdev->dev.of_node;
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse reset gpio\n");
- return gpio;
- }
- ddata->reset_gpio = gpio;
-
- gpio = of_get_nam
[PATCH RESEND 04/13] omapfb: encoder-tfp410: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 +++---
1 file changed, 22 insertions(+), 45 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
index 09a59bd93d61..7bac420169a6 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
@@ -6,11 +6,12 @@
* Author: Tomi Valkeinen
*/
-#include
+#include
+#include
#include
+#include
#include
#include
-#include
#include
@@ -18,7 +19,8 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
- int pd_gpio;
+ struct gpio_desc *pd_gpio;
+
int data_lines;
struct omap_video_timings timings;
@@ -86,8 +88,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 1);
+ if (ddata->pd_gpio)
+ gpiod_set_value_cansleep(ddata->pd_gpio, 0);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -102,8 +104,8 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 0);
+ if (ddata->pd_gpio)
+ gpiod_set_value_cansleep(ddata->pd_gpio, 1);
in->ops.dpi->disable(in);
@@ -162,33 +164,6 @@ static const struct omapdss_dvi_ops tfp410_dvi_ops = {
.get_timings= tfp410_get_timings,
};
-static int tfp410_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "powerdown-gpios", 0);
-
- if (gpio_is_valid(gpio) || gpio == -ENOENT) {
- ddata->pd_gpio = gpio;
- } else {
- dev_err(>dev, "failed to parse PD gpio\n");
- return gpio;
- }
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -204,18 +179,21 @@ static int tfp410_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
- r = tfp410_probe_of(pdev);
- if (r)
+ ddata->pd_gpio = devm_gpiod_get_optional(>dev, "powerdown",
+GPIOD_OUT_HIGH);
+ r = PTR_ERR_OR_ZERO(ddata->pd_gpio);
+ if (r) {
+ dev_err(>dev, "Failed to request PD GPIO: %d\n", r);
return r;
+ }
+
+ gpiod_set_consumer_name(ddata->pd_gpio, "tfp410 PD");
- if (gpio_is_valid(ddata->pd_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->pd_gpio,
- GPIOF_OUT_INIT_LOW, "tfp410 PD");
- if (r) {
- dev_err(>dev, "Failed to request PD GPIO %d\n",
- ddata->pd_gpio);
- goto err_gpio;
- }
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
+ return r;
}
dssdev = >dssdev;
@@ -235,7 +213,6 @@ static int tfp410_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
b4 0.11.0-dev-28747
[PATCH RESEND 01/13] omapfb: connector-hdmi: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++---
1 file changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
index 670b9c6eb5a9..8f9ff9fb4ca4 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
@@ -6,11 +6,12 @@
* Author: Tomi Valkeinen
*/
+#include
+#include
#include
#include
#include
#include
-#include
#include
@@ -41,7 +42,7 @@ struct panel_drv_data {
struct omap_video_timings timings;
- int hpd_gpio;
+ struct gpio_desc *hpd_gpio;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -155,8 +156,8 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
- if (gpio_is_valid(ddata->hpd_gpio))
- return gpio_get_value_cansleep(ddata->hpd_gpio);
+ if (ddata->hpd_gpio)
+ return gpiod_get_value_cansleep(ddata->hpd_gpio);
else
return in->ops.hdmi->detect(in);
}
@@ -197,31 +198,6 @@ static struct omap_dss_driver hdmic_driver = {
.set_hdmi_infoframe = hdmic_set_infoframe,
};
-static int hdmic_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
- int gpio;
-
- /* HPD GPIO */
- gpio = of_get_named_gpio(node, "hpd-gpios", 0);
- if (gpio_is_valid(gpio))
- ddata->hpd_gpio = gpio;
- else
- ddata->hpd_gpio = -ENODEV;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -238,15 +214,18 @@ static int hdmic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = >dev;
- r = hdmic_probe_of(pdev);
+ ddata->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd", GPIOD_IN);
+ r = PTR_ERR_OR_ZERO(ddata->hpd_gpio);
if (r)
return r;
- if (gpio_is_valid(ddata->hpd_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->hpd_gpio,
- GPIOF_DIR_IN, "hdmi_hpd");
- if (r)
- goto err_reg;
+ gpiod_set_consumer_name(ddata->hpd_gpio, "hdmi_hpd");
+
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
+ return r;
}
ddata->timings = hdmic_default_timings;
--
b4 0.11.0-dev-28747
[PATCH RESEND 03/13] omapfb: panel-sony-acx565akm: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 66 ++
1 file changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index 0c81d3ff4197..685c63aa4e03 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -18,9 +18,8 @@
#include
#include
#include
-#include
+#include
#include
-#include
#include
@@ -56,7 +55,8 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
- int reset_gpio;
+ struct gpio_desc *reset_gpio;
+
int datapairs;
struct omap_video_timings videomode;
@@ -545,8 +545,13 @@ static int acx565akm_panel_power_on(struct omap_dss_device
*dssdev)
/*FIXME tweak me */
msleep(50);
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 1);
+ /*
+* Note that we appear to activate the reset line here. However
+* existing DTSes specified incorrect polarity for it (active high),
+* so in fact this deasserts the reset line.
+*/
+ if (ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
if (ddata->enabled) {
dev_dbg(>spi->dev, "panel already enabled\n");
@@ -595,8 +600,9 @@ static void acx565akm_panel_power_off(struct
omap_dss_device *dssdev)
*/
msleep(50);
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 0);
+ /* see comment in acx565akm_panel_power_on() */
+ if (ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
/* FIXME need to tweak this delay */
msleep(100);
@@ -687,22 +693,6 @@ static struct omap_dss_driver acx565akm_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int acx565akm_probe_of(struct spi_device *spi)
-{
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct device_node *np = spi->dev.of_node;
-
- ddata->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
-
- ddata->in = omapdss_of_find_source_for_first_ep(np);
- if (IS_ERR(ddata->in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(ddata->in);
- }
-
- return 0;
-}
-
static int acx565akm_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -729,19 +719,25 @@ static int acx565akm_probe(struct spi_device *spi)
mutex_init(>mutex);
- r = acx565akm_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
return r;
-
- if (gpio_is_valid(ddata->reset_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->reset_gpio,
- GPIOF_OUT_INIT_LOW, "lcd reset");
- if (r)
- goto err_gpio;
}
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 1);
+ ddata->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
+ GPIOD_OUT_LOW);
+ r = PTR_ERR_OR_ZERO(ddata->reset_gpio);
+ if (r)
+ goto err_gpio;
+
+ if (ddata->reset_gpio) {
+ gpiod_set_consumer_name(ddata->reset_gpio, "lcd reset");
+
+ /* release the reset line */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
+ }
/*
* After reset we have to wait 5 msec before the first
@@ -753,8 +749,8 @@ static int acx565akm_probe(struct spi_device *spi)
r = panel_detect(ddata);
- if (!ddata->enabled && gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 0);
+ if (!ddata->enabled && ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
if (r) {
dev_err(>dev, "%s panel detect error\n", __func__);
--
b4 0.11.0-dev-28747
[PATCH RESEND 02/13] omapfb: panel-sony-acx565akm: remove support for platform data
There are no users of panel_acx565akm_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 45 +++---
include/video/omap-panel-data.h| 16
2 files changed, 6 insertions(+), 55 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index c0965bee12c5..0c81d3ff4197 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -23,7 +23,6 @@
#include
#include
-#include
#define MIPID_CMD_READ_DISP_ID 0x04
#define MIPID_CMD_READ_RED 0x06
@@ -688,32 +687,6 @@ static struct omap_dss_driver acx565akm_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int acx565akm_probe_pdata(struct spi_device *spi)
-{
- const struct panel_acx565akm_platform_data *pdata;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *dssdev, *in;
-
- pdata = dev_get_platdata(>dev);
-
- ddata->reset_gpio = pdata->reset_gpio;
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "failed to find video source '%s'\n",
- pdata->source);
- return -EPROBE_DEFER;
- }
- ddata->in = in;
-
- ddata->datapairs = pdata->datapairs;
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
static int acx565akm_probe_of(struct spi_device *spi)
{
struct panel_drv_data *ddata = dev_get_drvdata(>dev);
@@ -741,6 +714,9 @@ static int acx565akm_probe(struct spi_device *spi)
dev_dbg(>dev, "%s\n", __func__);
+ if (!spi->dev.of_node)
+ return -ENODEV;
+
spi->mode = SPI_MODE_3;
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
@@ -753,18 +729,9 @@ static int acx565akm_probe(struct spi_device *spi)
mutex_init(>mutex);
- if (dev_get_platdata(>dev)) {
- r = acx565akm_probe_pdata(spi);
- if (r)
- return r;
- } else if (spi->dev.of_node) {
- r = acx565akm_probe_of(spi);
- if (r)
- return r;
- } else {
- dev_err(>dev, "platform data missing!\n");
- return -ENODEV;
- }
+ r = acx565akm_probe_of(spi);
+ if (r)
+ return r;
if (gpio_is_valid(ddata->reset_gpio)) {
r = devm_gpio_request_one(>dev, ddata->reset_gpio,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 42b77249ee14..b7733150b55c 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -52,20 +52,4 @@ struct panel_dpi_platform_data {
int enable_gpio;
};
-/**
- * panel_acx565akm platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- * @reset_gpio: gpio to reset the panel (or -1)
- * @datapairs: number of SDI datapairs
- */
-struct panel_acx565akm_platform_data {
- const char *name;
- const char *source;
-
- int reset_gpio;
-
- int datapairs;
-};
-
#endif /* __OMAP_PANEL_DATA_H */
--
b4 0.11.0-dev-28747
[PATCH RESEND 00/13] Convert omapfb drivers to gpiod API
This series converts various OMAPFB drivers to use the newer gpiod API that respects line polarity specified in DTS. Unfortunately existing DTS files specify incorrect (active high) polarity for reset lines. As discussed in [1] we will not try to correct existing DTSes, but instead follow the path established by DRM drivers for the same components, and continue using inverted polarity in the FB drivers. [1] https://lore.kernel.org/all/20221004213503.848262-1-dmitry.torok...@gmail.com/ To: Helge Deller To: Tony Lindgren To: Tomi Valkeinen To: Sebastian Reichel Cc: linux-o...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org --- Dmitry Torokhov (13): omapfb: connector-hdmi: switch to using gpiod API omapfb: panel-sony-acx565akm: remove support for platform data omapfb: panel-sony-acx565akm: switch to using gpiod API omapfb: encoder-tfp410: switch to using gpiod API omapfb: panel-dsi-cm: switch to using gpiod API omapfb: panel-tpo-td043mtea1: switch to using gpiod API omapfb: panel-nec-nl8048hl11: switch to using gpiod API omapfb: panel-dpi: remove support for platform data omapfb: connector-analog-tv: remove support for platform data omapfb: encoder-opa362: fix included headers omapfb: panel-lgphilips-lb035q02: remove backlight GPIO handling omapfb: panel-tpo-td028ttec1: stop including gpio.h omapfb: panel-sharp-ls037v7dw01: fix included headers .../omap2/omapfb/displays/connector-analog-tv.c| 60 ++- .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++-- .../fbdev/omap2/omapfb/displays/encoder-opa362.c | 4 +- .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 .../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++- .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 - .../omapfb/displays/panel-lgphilips-lb035q02.c | 21 +--- .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 - .../omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +- .../omap2/omapfb/displays/panel-sony-acx565akm.c | 105 ++- .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 - .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++ include/video/omap-panel-data.h| 71 - 13 files changed, 170 insertions(+), 541 deletions(-) --- base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd change-id: 20221103-omapfb-gpiod-87ca2550bd90 -- Dmitry
Re: [PATCH 00/13] Convert omapfb drivers to gpiod API
On Thu, Nov 03, 2022 at 03:46:35PM -0700, Dmitry Torokhov wrote: > This series converts various OMAPFB drivers to use the newer gpiod API > that respects line polarity specified in DTS. > > Unfortunately existing DTS files specify incorrect (active high) polarity > for reset lines. As discussed in [1] we will not try to correct existing > DTSes, but instead follow the path established by DRM drivers for the same > components, and continue using inverted polarity in the FB drivers. > > [1] > https://lore.kernel.org/all/20221004213503.848262-1-dmitry.torok...@gmail.com/ Sorry, it looks like I did not clear temporary directory, so there is a bit of mess in the patches. I'll resend properly in a second. > > To: Helge Deller > To: Tony Lindgren > To: Tomi Valkeinen > To: Sebastian Reichel > Cc: linux-o...@vger.kernel.org > Cc: linux-fb...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-ker...@vger.kernel.org > > --- > Dmitry Torokhov (13): > omapfb: connector-hdmi: switch to using gpiod API > omapfb: panel-sony-acx565akm: remove support for platform data > omapfb: panel-sony-acx565akm: switch to using gpiod API > omapfb: encoder-tfp410: switch to using gpiod API > omapfb: panel-dsi-cm: switch to using gpiod API > omapfb: panel-tpo-td043mtea1: switch to using gpiod API > omapfb: panel-nec-nl8048hl11: switch to using gpiod API > omapfb: panel-dpi: remove support for platform data > omapfb: connector-analog-tv: remove support for platform data > omapfb: encoder-opa362: fix included headers > omapfb: panel-lgphilips-lb035q02: remove backlight GPIO handling > omapfb: panel-tpo-td028ttec1: stop including gpio.h > omapfb: panel-sharp-ls037v7dw01: fix included headers > > .../omap2/omapfb/displays/connector-analog-tv.c| 60 ++- > .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++-- > .../fbdev/omap2/omapfb/displays/encoder-opa362.c | 4 +- > .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 > .../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++- > .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 > - > .../omapfb/displays/panel-lgphilips-lb035q02.c | 21 +--- > .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 - > .../omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +- > .../omap2/omapfb/displays/panel-sony-acx565akm.c | 105 ++- > .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 - > .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++ > include/video/omap-panel-data.h| 71 - > 13 files changed, 170 insertions(+), 541 deletions(-) > --- > base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd > change-id: 20221103-omapfb-gpiod-87ca2550bd90 > > -- > Dmitry > -- Dmitry
[PATCH 12/13] omapfb: panel-tpo-td028ttec1: stop including gpio.h
The driver does not use gpios, so there is no need to include gpio.h.
Signed-off-by: Dmitry Torokhov
---
drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
index 3c0f887d3092..c18d290693c1 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c
@@ -16,7 +16,6 @@
#include
#include
#include
-#include
#include
struct panel_drv_data {
--
b4 0.11.0-dev-5166b
[PATCH 13/13] omapfb: panel-sharp-ls037v7dw01: stop i
The driver is using gpiod API so it should include gpio/consumer.h and not gpio.gh or of_gpio.h. Signed-off-by: Dmitry Torokhov --- drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c index f1072c319de8..cc30758300e2 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c @@ -7,10 +7,9 @@ */ #include -#include +#include #include #include -#include #include #include #include -- b4 0.11.0-dev-5166b
[PATCH 13/13] omapfb: panel-sharp-ls037v7dw01: fix included headers
The driver is using gpiod API so it should include gpio/consumer.h and not gpio.gh or of_gpio.h. Signed-off-by: Dmitry Torokhov --- drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c index f1072c319de8..cc30758300e2 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sharp-ls037v7dw01.c @@ -7,10 +7,9 @@ */ #include -#include +#include #include #include -#include #include #include #include -- b4 0.11.0-dev-5166b
[PATCH 10/13] omapfb: encoder-opa362: fix included headers
The driver has been switched to gpiod API, so it should include gpio/consumer.h instead of gpio.h and of_gpio.h. With of_gpio.h no longer included we need mod_devicetable.h for of_device_id definition. Signed-off-by: Dmitry Torokhov --- drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c index ba7ed4039f8a..dd29dc5c77ec 100644 --- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c +++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c @@ -11,11 +11,11 @@ * Author: Tomi Valkeinen */ -#include +#include #include +#include #include #include -#include #include -- b4 0.11.0-dev-5166b
[PATCH 09/13] omapfb: connector-analog-tv: remove support for platform data
There are no users of connector_atv_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/connector-analog-tv.c| 60 +++---
include/video/omap-panel-data.h| 34
2 files changed, 8 insertions(+), 86 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
index a9fd732f8103..0daaf9f89bab 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-analog-tv.c
@@ -12,7 +12,6 @@
#include
#include
-#include
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -178,53 +177,15 @@ static struct omap_dss_driver tvc_driver = {
.set_wss= tvc_set_wss,
};
-static int tvc_probe_pdata(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct connector_atv_platform_data *pdata;
- struct omap_dss_device *in, *dssdev;
-
- pdata = dev_get_platdata(>dev);
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "Failed to find video source\n");
- return -EPROBE_DEFER;
- }
-
- ddata->in = in;
-
- ddata->invert_polarity = pdata->invert_polarity;
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
-static int tvc_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
@@ -232,16 +193,11 @@ static int tvc_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = >dev;
- if (dev_get_platdata(>dev)) {
- r = tvc_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = tvc_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
+ return r;
}
ddata->timings = tvc_pal_timings;
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
deleted file mode 100644
index 18172d7b97d0..
--- a/include/video/omap-panel-data.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * Header containing platform_data structs for omap panels
- *
- * Copyright (C) 2013 Texas Instruments
- * Author: Tomi Valkeinen
- *Archit Taneja
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Mayuresh Janorkar
- *
- * Copyright (C) 2010 Canonical Ltd.
- * Author: Bryan Wu
- */
-
-#ifndef __OMAP_PANEL_DATA_H
-#define __OMAP_PANEL_DATA_H
-
-#include
-
-/**
- * connector_atv platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- * @invert_polarity: invert signal polarity
- */
-struct connector_atv_platform_data {
- const char *name;
- const char *source;
-
- bool invert_polarity;
-};
-
-#endif /* __OMAP_PANEL_DATA_H */
--
b4 0.11.0-dev-5166b
[PATCH 07/13] omapfb: panel-nec-nl8048hl11: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 ++
1 file changed, 20 insertions(+), 52 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
index b407173e27b1..33563953b2ff 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-nec-nl8048hl11.c
@@ -7,12 +7,12 @@
* Converted to new DSS device model: Tomi Valkeinen
*/
-#include
#include
-#include
+#include
#include
-#include
-#include
+#include
+#include
+#include
#include
@@ -24,8 +24,7 @@ struct panel_drv_data {
int data_lines;
- int res_gpio;
- int qvga_gpio;
+ struct gpio_desc *res_gpio;
struct spi_device *spi;
};
@@ -155,8 +154,8 @@ static int nec_8048_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata->res_gpio))
- gpio_set_value_cansleep(ddata->res_gpio, 1);
+ /* Apparently existing DTSes use incorrect polarity (active high) */
+ gpiod_set_value_cansleep(ddata->res_gpio, 1);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -171,8 +170,8 @@ static void nec_8048_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->res_gpio))
- gpio_set_value_cansleep(ddata->res_gpio, 0);
+ /* Apparently existing DTSes use incorrect polarity (active high) */
+ gpiod_set_value_cansleep(ddata->res_gpio, 0);
in->ops.dpi->disable(in);
@@ -222,35 +221,6 @@ static struct omap_dss_driver nec_8048_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-
-static int nec_8048_probe_of(struct spi_device *spi)
-{
- struct device_node *node = spi->dev.of_node;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse enable gpio\n");
- return gpio;
- }
- ddata->res_gpio = gpio;
-
- /* XXX the panel spec doesn't mention any QVGA pin?? */
- ddata->qvga_gpio = -ENOENT;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int nec_8048_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -281,24 +251,22 @@ static int nec_8048_probe(struct spi_device *spi)
ddata->spi = spi;
- r = nec_8048_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
return r;
-
- if (gpio_is_valid(ddata->qvga_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->qvga_gpio,
- GPIOF_OUT_INIT_HIGH, "lcd QVGA");
- if (r)
- goto err_gpio;
}
- if (gpio_is_valid(ddata->res_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->res_gpio,
- GPIOF_OUT_INIT_LOW, "lcd RES");
- if (r)
- goto err_gpio;
+ ddata->res_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+ r = PTR_ERR_OR_ZERO(ddata->res_gpio);
+ if (r) {
+ dev_err(>dev, "failed to request reset gpio: %d\n", r);
+ goto err_gpio;
}
+ gpiod_set_consumer_name(ddata->res_gpio, "lcd RES");
+
ddata->videomode = nec_8048_panel_timings;
dssdev = >dssdev;
--
b4 0.11.0-dev-5166b
[PATCH 11/13] omapfb: panel-lgphilips-lb035q02: remove backlight GPIO handling
With f048e8c1d169 ("omapfb: panel-lgphilips-lb035q02: Remove legacy boot
support") it is no longer possible to specify GPIO to control the
backlight. Remove code trying to request and toggle it.
Signed-off-by: Dmitry Torokhov
---
.../omapfb/displays/panel-lgphilips-lb035q02.c | 21 +
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git
a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
index 3ce1f9d2e7c4..e69856cb62d5 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c
@@ -11,7 +11,7 @@
#include
#include
#include
-#include
+#include
#include
@@ -46,9 +46,6 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- /* used for non-DT boot, to be removed */
- int backlight_gpio;
-
struct gpio_desc *enable_gpio;
};
@@ -166,9 +163,6 @@ static int lb035q02_enable(struct omap_dss_device *dssdev)
if (ddata->enable_gpio)
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 1);
-
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -185,9 +179,6 @@ static void lb035q02_disable(struct omap_dss_device *dssdev)
if (ddata->enable_gpio)
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 0);
-
in->ops.dpi->disable(in);
dssdev->state = OMAP_DSS_DISPLAY_DISABLED;
@@ -250,8 +241,6 @@ static int lb035q02_probe_of(struct spi_device *spi)
ddata->enable_gpio = gpio;
- ddata->backlight_gpio = -ENOENT;
-
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(>dev, "failed to find video source\n");
@@ -284,13 +273,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
if (r)
return r;
- if (gpio_is_valid(ddata->backlight_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->backlight_gpio,
- GPIOF_OUT_INIT_LOW, "panel backlight");
- if (r)
- goto err_gpio;
- }
-
ddata->videomode = lb035q02_timings;
dssdev = >dssdev;
@@ -310,7 +292,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
b4 0.11.0-dev-5166b
[PATCH 08/13] omapfb: panel-dpi: remove support for platform data
There are no users of panel_dpi_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++
include/video/omap-panel-data.h| 21 --
2 files changed, 7 insertions(+), 97 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
index ff3d1e8e1e7b..9790053c5877 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dpi.c
@@ -6,15 +6,13 @@
* Author: Tomi Valkeinen
*/
-#include
+#include
#include
#include
#include
#include
-#include
#include
-#include
#include
struct panel_drv_data {
@@ -25,9 +23,6 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- /* used for non-DT boot, to be removed */
- int backlight_gpio;
-
struct gpio_desc *enable_gpio;
};
@@ -77,9 +72,6 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 1);
-
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
return 0;
@@ -93,9 +85,6 @@ static void panel_dpi_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->backlight_gpio))
- gpio_set_value_cansleep(ddata->backlight_gpio, 0);
-
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
in->ops.dpi->disable(in);
@@ -146,49 +135,6 @@ static struct omap_dss_driver panel_dpi_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int panel_dpi_probe_pdata(struct platform_device *pdev)
-{
- const struct panel_dpi_platform_data *pdata;
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *dssdev, *in;
- struct videomode vm;
- int r;
-
- pdata = dev_get_platdata(>dev);
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "failed to find video source '%s'\n",
- pdata->source);
- return -EPROBE_DEFER;
- }
-
- ddata->in = in;
-
- ddata->data_lines = pdata->data_lines;
-
- videomode_from_timing(pdata->display_timing, );
- videomode_to_omap_video_timings(, >videomode);
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- r = devm_gpio_request_one(>dev, pdata->enable_gpio,
- GPIOF_OUT_INIT_LOW, "panel enable");
- if (r)
- goto err_gpio;
-
- ddata->enable_gpio = gpio_to_desc(pdata->enable_gpio);
-
- ddata->backlight_gpio = pdata->backlight_gpio;
-
- return 0;
-
-err_gpio:
- omap_dss_put_device(ddata->in);
- return r;
-}
-
static int panel_dpi_probe_of(struct platform_device *pdev)
{
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
@@ -205,8 +151,6 @@ static int panel_dpi_probe_of(struct platform_device *pdev)
ddata->enable_gpio = gpio;
- ddata->backlight_gpio = -ENOENT;
-
r = of_get_display_timing(node, "panel-timing", );
if (r) {
dev_err(>dev, "failed to get video timing\n");
@@ -233,30 +177,18 @@ static int panel_dpi_probe(struct platform_device *pdev)
struct omap_dss_device *dssdev;
int r;
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
if (ddata == NULL)
return -ENOMEM;
platform_set_drvdata(pdev, ddata);
- if (dev_get_platdata(>dev)) {
- r = panel_dpi_probe_pdata(pdev);
- if (r)
- return r;
- } else if (pdev->dev.of_node) {
- r = panel_dpi_probe_of(pdev);
- if (r)
- return r;
- } else {
- return -ENODEV;
- }
-
- if (gpio_is_valid(ddata->backlight_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->backlight_gpio,
- GPIOF_OUT_INIT_LOW, "panel backlight");
- if (r)
- goto err_gpio;
- }
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
dssdev = >dssdev;
dssdev->dev = >dev;
@@ -275,7 +207,6 @@ static int panel_dpi_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return
[PATCH 05/13] omapfb: panel-dsi-cm: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 -
1 file changed, 45 insertions(+), 71 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
index a2c7c5cb1523..4fc4b26a8d30 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.c
@@ -10,8 +10,9 @@
#include
#include
+#include
#include
-#include
+#include
#include
#include
#include
@@ -20,7 +21,6 @@
#include
#include
#include
-#include
#include
#include
@@ -53,8 +53,8 @@ struct panel_drv_data {
unsigned long hw_guard_wait; /* max guard time in jiffies */
/* panel HW configuration from DT or platform data */
- int reset_gpio;
- int ext_te_gpio;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *ext_te_gpio;
bool use_dsi_backlight;
@@ -250,8 +250,8 @@ static int dsicm_enter_ulps(struct panel_drv_data *ddata)
if (r)
goto err;
- if (gpio_is_valid(ddata->ext_te_gpio))
- disable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ disable_irq(gpiod_to_irq(ddata->ext_te_gpio));
in->ops.dsi->disable(in, false, true);
@@ -292,8 +292,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
goto err2;
}
- if (gpio_is_valid(ddata->ext_te_gpio))
- enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
dsicm_queue_ulps_work(ddata);
@@ -306,8 +306,8 @@ static int dsicm_exit_ulps(struct panel_drv_data *ddata)
r = dsicm_panel_reset(ddata);
if (!r) {
- if (gpio_is_valid(ddata->ext_te_gpio))
- enable_irq(gpio_to_irq(ddata->ext_te_gpio));
+ if (ddata->ext_te_gpio)
+ enable_irq(gpiod_to_irq(ddata->ext_te_gpio));
ddata->ulps_enabled = false;
}
err1:
@@ -556,16 +556,19 @@ static const struct attribute_group dsicm_attr_group = {
static void dsicm_hw_reset(struct panel_drv_data *ddata)
{
- if (!gpio_is_valid(ddata->reset_gpio))
- return;
-
- gpio_set_value(ddata->reset_gpio, 1);
+ /*
+* Note that we appear to activate the reset line here. However
+* existing DTSes specified incorrect polarity for it (active high),
+* so in fact this deasserts the reset line.
+*/
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
udelay(10);
/* reset the panel */
- gpio_set_value(ddata->reset_gpio, 0);
- /* assert reset */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
+ /* keep reset asserted */
udelay(10);
- gpio_set_value(ddata->reset_gpio, 1);
+ /* release reset line */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
/* wait after releasing reset */
usleep_range(5000, 1);
}
@@ -886,7 +889,7 @@ static int dsicm_update(struct omap_dss_device *dssdev,
if (r)
goto err;
- if (ddata->te_enabled && gpio_is_valid(ddata->ext_te_gpio)) {
+ if (ddata->te_enabled && ddata->ext_te_gpio) {
schedule_delayed_work(>te_timeout_work,
msecs_to_jiffies(250));
atomic_set(>do_update, 1);
@@ -933,7 +936,7 @@ static int _dsicm_enable_te(struct panel_drv_data *ddata,
bool enable)
else
r = dsicm_dcs_write_0(ddata, MIPI_DCS_SET_TEAR_OFF);
- if (!gpio_is_valid(ddata->ext_te_gpio))
+ if (!ddata->ext_te_gpio)
in->ops.dsi->enable_te(in, enable);
/* possible panel bug */
@@ -1115,41 +1118,6 @@ static struct omap_dss_driver dsicm_ops = {
.memory_read= dsicm_memory_read,
};
-static int dsicm_probe_of(struct platform_device *pdev)
-{
- struct device_node *node = pdev->dev.of_node;
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse reset gpio\n");
- return gpio;
- }
- ddata->reset_gpio = gpio;
-
- gpio = of_get_nam
[PATCH 06/13] omapfb: panel-tpo-td043mtea1: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 ++
1 file changed, 16 insertions(+), 43 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
index c0e4e0315b6b..1eaa35c27835 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td043mtea1.c
@@ -10,10 +10,9 @@
#include
#include
#include
-#include
+#include
#include
#include
-#include
#include
@@ -58,7 +57,7 @@ struct panel_drv_data {
struct spi_device *spi;
struct regulator *vcc_reg;
- int nreset_gpio;
+ struct gpio_desc *reset_gpio;
u16 gamma[12];
u32 mode;
u32 hmirror:1;
@@ -296,8 +295,7 @@ static int tpo_td043_power_on(struct panel_drv_data *ddata)
/* wait for panel to stabilize */
msleep(160);
- if (gpio_is_valid(ddata->nreset_gpio))
- gpio_set_value(ddata->nreset_gpio, 1);
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
tpo_td043_write(ddata->spi, 2,
TPO_R02_MODE(ddata->mode) | TPO_R02_NCLK_RISING);
@@ -320,8 +318,7 @@ static void tpo_td043_power_off(struct panel_drv_data
*ddata)
tpo_td043_write(ddata->spi, 3,
TPO_R03_VAL_STANDBY | TPO_R03_EN_PWM);
- if (gpio_is_valid(ddata->nreset_gpio))
- gpio_set_value(ddata->nreset_gpio, 0);
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
/* wait for at least 2 vsyncs before cutting off power */
msleep(50);
@@ -454,32 +451,6 @@ static struct omap_dss_driver tpo_td043_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-
-static int tpo_td043_probe_of(struct spi_device *spi)
-{
- struct device_node *node = spi->dev.of_node;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "reset-gpios", 0);
- if (!gpio_is_valid(gpio)) {
- dev_err(>dev, "failed to parse enable gpio\n");
- return gpio;
- }
- ddata->nreset_gpio = gpio;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tpo_td043_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -508,9 +479,12 @@ static int tpo_td043_probe(struct spi_device *spi)
ddata->spi = spi;
- r = tpo_td043_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
return r;
+ }
ddata->mode = TPO_R02_MODE_800x480;
memcpy(ddata->gamma, tpo_td043_def_gamma, sizeof(ddata->gamma));
@@ -521,16 +495,15 @@ static int tpo_td043_probe(struct spi_device *spi)
goto err_regulator;
}
- if (gpio_is_valid(ddata->nreset_gpio)) {
- r = devm_gpio_request_one(>dev,
- ddata->nreset_gpio, GPIOF_OUT_INIT_LOW,
- "lcd reset");
- if (r < 0) {
- dev_err(>dev, "couldn't request reset GPIO\n");
- goto err_gpio_req;
- }
+ ddata->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_HIGH);
+ r = PTR_ERR_OR_ZERO(ddata->reset_gpio);
+ if (r) {
+ dev_err(>dev, "couldn't request reset GPIO\n");
+ goto err_gpio_req;
}
+ gpiod_set_consumer_name(ddata->reset_gpio, "lcd reset");
+
r = sysfs_create_group(>dev.kobj, _td043_attr_group);
if (r) {
dev_err(>dev, "failed to create sysfs files\n");
--
b4 0.11.0-dev-5166b
[PATCH 03/13] omapfb: panel-sony-acx565akm: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Note that because existing DTSes specify incorrect polarity of reset
lines (active high) and GPU drivers have adopted to this, we follow
the suit and use inverted values when controlling reset lines.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 66 ++
1 file changed, 31 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index 0c81d3ff4197..685c63aa4e03 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -18,9 +18,8 @@
#include
#include
#include
-#include
+#include
#include
-#include
#include
@@ -56,7 +55,8 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
- int reset_gpio;
+ struct gpio_desc *reset_gpio;
+
int datapairs;
struct omap_video_timings videomode;
@@ -545,8 +545,13 @@ static int acx565akm_panel_power_on(struct omap_dss_device
*dssdev)
/*FIXME tweak me */
msleep(50);
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 1);
+ /*
+* Note that we appear to activate the reset line here. However
+* existing DTSes specified incorrect polarity for it (active high),
+* so in fact this deasserts the reset line.
+*/
+ if (ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
if (ddata->enabled) {
dev_dbg(>spi->dev, "panel already enabled\n");
@@ -595,8 +600,9 @@ static void acx565akm_panel_power_off(struct
omap_dss_device *dssdev)
*/
msleep(50);
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 0);
+ /* see comment in acx565akm_panel_power_on() */
+ if (ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
/* FIXME need to tweak this delay */
msleep(100);
@@ -687,22 +693,6 @@ static struct omap_dss_driver acx565akm_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int acx565akm_probe_of(struct spi_device *spi)
-{
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct device_node *np = spi->dev.of_node;
-
- ddata->reset_gpio = of_get_named_gpio(np, "reset-gpios", 0);
-
- ddata->in = omapdss_of_find_source_for_first_ep(np);
- if (IS_ERR(ddata->in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(ddata->in);
- }
-
- return 0;
-}
-
static int acx565akm_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -729,19 +719,25 @@ static int acx565akm_probe(struct spi_device *spi)
mutex_init(>mutex);
- r = acx565akm_probe_of(spi);
- if (r)
+ ddata->in = omapdss_of_find_source_for_first_ep(spi->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
return r;
-
- if (gpio_is_valid(ddata->reset_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->reset_gpio,
- GPIOF_OUT_INIT_LOW, "lcd reset");
- if (r)
- goto err_gpio;
}
- if (gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 1);
+ ddata->reset_gpio = devm_gpiod_get_optional(>dev, "reset",
+ GPIOD_OUT_LOW);
+ r = PTR_ERR_OR_ZERO(ddata->reset_gpio);
+ if (r)
+ goto err_gpio;
+
+ if (ddata->reset_gpio) {
+ gpiod_set_consumer_name(ddata->reset_gpio, "lcd reset");
+
+ /* release the reset line */
+ gpiod_set_value_cansleep(ddata->reset_gpio, 1);
+ }
/*
* After reset we have to wait 5 msec before the first
@@ -753,8 +749,8 @@ static int acx565akm_probe(struct spi_device *spi)
r = panel_detect(ddata);
- if (!ddata->enabled && gpio_is_valid(ddata->reset_gpio))
- gpio_set_value(ddata->reset_gpio, 0);
+ if (!ddata->enabled && ddata->reset_gpio)
+ gpiod_set_value_cansleep(ddata->reset_gpio, 0);
if (r) {
dev_err(>dev, "%s panel detect error\n", __func__);
--
b4 0.11.0-dev-5166b
[PATCH 04/13] omapfb: encoder-tfp410: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 +++---
1 file changed, 22 insertions(+), 45 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
index 09a59bd93d61..7bac420169a6 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/encoder-tfp410.c
@@ -6,11 +6,12 @@
* Author: Tomi Valkeinen
*/
-#include
+#include
+#include
#include
+#include
#include
#include
-#include
#include
@@ -18,7 +19,8 @@ struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
- int pd_gpio;
+ struct gpio_desc *pd_gpio;
+
int data_lines;
struct omap_video_timings timings;
@@ -86,8 +88,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 1);
+ if (ddata->pd_gpio)
+ gpiod_set_value_cansleep(ddata->pd_gpio, 0);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -102,8 +104,8 @@ static void tfp410_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 0);
+ if (ddata->pd_gpio)
+ gpiod_set_value_cansleep(ddata->pd_gpio, 1);
in->ops.dpi->disable(in);
@@ -162,33 +164,6 @@ static const struct omapdss_dvi_ops tfp410_dvi_ops = {
.get_timings= tfp410_get_timings,
};
-static int tfp410_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
- int gpio;
-
- gpio = of_get_named_gpio(node, "powerdown-gpios", 0);
-
- if (gpio_is_valid(gpio) || gpio == -ENOENT) {
- ddata->pd_gpio = gpio;
- } else {
- dev_err(>dev, "failed to parse PD gpio\n");
- return gpio;
- }
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -204,18 +179,21 @@ static int tfp410_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
- r = tfp410_probe_of(pdev);
- if (r)
+ ddata->pd_gpio = devm_gpiod_get_optional(>dev, "powerdown",
+GPIOD_OUT_HIGH);
+ r = PTR_ERR_OR_ZERO(ddata->pd_gpio);
+ if (r) {
+ dev_err(>dev, "Failed to request PD GPIO: %d\n", r);
return r;
+ }
+
+ gpiod_set_consumer_name(ddata->pd_gpio, "tfp410 PD");
- if (gpio_is_valid(ddata->pd_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->pd_gpio,
- GPIOF_OUT_INIT_LOW, "tfp410 PD");
- if (r) {
- dev_err(>dev, "Failed to request PD GPIO %d\n",
- ddata->pd_gpio);
- goto err_gpio;
- }
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source: %d\n", r);
+ return r;
}
dssdev = >dssdev;
@@ -235,7 +213,6 @@ static int tfp410_probe(struct platform_device *pdev)
return 0;
err_reg:
-err_gpio:
omap_dss_put_device(ddata->in);
return r;
}
--
b4 0.11.0-dev-5166b
[PATCH 02/13] omapfb: panel-sony-acx565akm: remove support for platform data
There are no users of panel_acx565akm_platform_data in the mainline
kernel so support for it can be removed from the panel driver.
Signed-off-by: Dmitry Torokhov
---
.../omap2/omapfb/displays/panel-sony-acx565akm.c | 45 +++---
include/video/omap-panel-data.h| 16
2 files changed, 6 insertions(+), 55 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
index c0965bee12c5..0c81d3ff4197 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/panel-sony-acx565akm.c
@@ -23,7 +23,6 @@
#include
#include
-#include
#define MIPID_CMD_READ_DISP_ID 0x04
#define MIPID_CMD_READ_RED 0x06
@@ -688,32 +687,6 @@ static struct omap_dss_driver acx565akm_ops = {
.get_resolution = omapdss_default_get_resolution,
};
-static int acx565akm_probe_pdata(struct spi_device *spi)
-{
- const struct panel_acx565akm_platform_data *pdata;
- struct panel_drv_data *ddata = dev_get_drvdata(>dev);
- struct omap_dss_device *dssdev, *in;
-
- pdata = dev_get_platdata(>dev);
-
- ddata->reset_gpio = pdata->reset_gpio;
-
- in = omap_dss_find_output(pdata->source);
- if (in == NULL) {
- dev_err(>dev, "failed to find video source '%s'\n",
- pdata->source);
- return -EPROBE_DEFER;
- }
- ddata->in = in;
-
- ddata->datapairs = pdata->datapairs;
-
- dssdev = >dssdev;
- dssdev->name = pdata->name;
-
- return 0;
-}
-
static int acx565akm_probe_of(struct spi_device *spi)
{
struct panel_drv_data *ddata = dev_get_drvdata(>dev);
@@ -741,6 +714,9 @@ static int acx565akm_probe(struct spi_device *spi)
dev_dbg(>dev, "%s\n", __func__);
+ if (!spi->dev.of_node)
+ return -ENODEV;
+
spi->mode = SPI_MODE_3;
ddata = devm_kzalloc(>dev, sizeof(*ddata), GFP_KERNEL);
@@ -753,18 +729,9 @@ static int acx565akm_probe(struct spi_device *spi)
mutex_init(>mutex);
- if (dev_get_platdata(>dev)) {
- r = acx565akm_probe_pdata(spi);
- if (r)
- return r;
- } else if (spi->dev.of_node) {
- r = acx565akm_probe_of(spi);
- if (r)
- return r;
- } else {
- dev_err(>dev, "platform data missing!\n");
- return -ENODEV;
- }
+ r = acx565akm_probe_of(spi);
+ if (r)
+ return r;
if (gpio_is_valid(ddata->reset_gpio)) {
r = devm_gpio_request_one(>dev, ddata->reset_gpio,
diff --git a/include/video/omap-panel-data.h b/include/video/omap-panel-data.h
index 42b77249ee14..b7733150b55c 100644
--- a/include/video/omap-panel-data.h
+++ b/include/video/omap-panel-data.h
@@ -52,20 +52,4 @@ struct panel_dpi_platform_data {
int enable_gpio;
};
-/**
- * panel_acx565akm platform data
- * @name: name for this display entity
- * @source: name of the display entity used as a video source
- * @reset_gpio: gpio to reset the panel (or -1)
- * @datapairs: number of SDI datapairs
- */
-struct panel_acx565akm_platform_data {
- const char *name;
- const char *source;
-
- int reset_gpio;
-
- int datapairs;
-};
-
#endif /* __OMAP_PANEL_DATA_H */
--
b4 0.11.0-dev-5166b
[PATCH 01/13] omapfb: connector-hdmi: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
Signed-off-by: Dmitry Torokhov
---
.../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++---
1 file changed, 14 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
index 670b9c6eb5a9..8f9ff9fb4ca4 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/omapfb/displays/connector-hdmi.c
@@ -6,11 +6,12 @@
* Author: Tomi Valkeinen
*/
+#include
+#include
#include
#include
#include
#include
-#include
#include
@@ -41,7 +42,7 @@ struct panel_drv_data {
struct omap_video_timings timings;
- int hpd_gpio;
+ struct gpio_desc *hpd_gpio;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -155,8 +156,8 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata->in;
- if (gpio_is_valid(ddata->hpd_gpio))
- return gpio_get_value_cansleep(ddata->hpd_gpio);
+ if (ddata->hpd_gpio)
+ return gpiod_get_value_cansleep(ddata->hpd_gpio);
else
return in->ops.hdmi->detect(in);
}
@@ -197,31 +198,6 @@ static struct omap_dss_driver hdmic_driver = {
.set_hdmi_infoframe = hdmic_set_infoframe,
};
-static int hdmic_probe_of(struct platform_device *pdev)
-{
- struct panel_drv_data *ddata = platform_get_drvdata(pdev);
- struct device_node *node = pdev->dev.of_node;
- struct omap_dss_device *in;
- int gpio;
-
- /* HPD GPIO */
- gpio = of_get_named_gpio(node, "hpd-gpios", 0);
- if (gpio_is_valid(gpio))
- ddata->hpd_gpio = gpio;
- else
- ddata->hpd_gpio = -ENODEV;
-
- in = omapdss_of_find_source_for_first_ep(node);
- if (IS_ERR(in)) {
- dev_err(>dev, "failed to find video source\n");
- return PTR_ERR(in);
- }
-
- ddata->in = in;
-
- return 0;
-}
-
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -238,15 +214,18 @@ static int hdmic_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ddata);
ddata->dev = >dev;
- r = hdmic_probe_of(pdev);
+ ddata->hpd_gpio = devm_gpiod_get_optional(>dev, "hpd", GPIOD_IN);
+ r = PTR_ERR_OR_ZERO(ddata->hpd_gpio);
if (r)
return r;
- if (gpio_is_valid(ddata->hpd_gpio)) {
- r = devm_gpio_request_one(>dev, ddata->hpd_gpio,
- GPIOF_DIR_IN, "hdmi_hpd");
- if (r)
- goto err_reg;
+ gpiod_set_consumer_name(ddata->hpd_gpio, "hdmi_hpd");
+
+ ddata->in = omapdss_of_find_source_for_first_ep(pdev->dev.of_node);
+ r = PTR_ERR_OR_ZERO(ddata->in);
+ if (r) {
+ dev_err(>dev, "failed to find video source\n");
+ return r;
}
ddata->timings = hdmic_default_timings;
--
b4 0.11.0-dev-5166b
[PATCH 0/7] Convert omapfb drivers to gpiod API
This series converts various OMAPFB drivers to use the newer gpiod API that respects line polarity specified in DTS. Unfortunately existing DTS files specify incorrect (active high) polarity for reset lines. As discussed in [1] we will not try to correct existing DTSes, but instead follow the path established by DRM drivers for the same components, and continue using inverted polarity in the FB drivers. [1] https://lore.kernel.org/all/20221004213503.848262-1-dmitry.torok...@gmail.com/ To: Helge Deller To: Tony Lindgren To: Tomi Valkeinen To: Sebastian Reichel Cc: linux-o...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org --- Dmitry Torokhov (7): omapfb: connector-hdmi: switch to using gpiod API omapfb: panel-sony-acx565akm: remove support for platform data omapfb: panel-sony-acx565akm: switch to using gpiod API omapfb: encoder-tfp410: switch to using gpiod API omapfb: panel-dsi-cm: switch to using gpiod API omapfb: panel-tpo-td043mtea1: switch to using gpiod API omapfb: panel-nec-nl8048hl11: switch to using gpiod API .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++-- .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 - .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 - .../omap2/omapfb/displays/panel-sony-acx565akm.c | 105 ++- .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++ include/video/omap-panel-data.h| 16 --- 7 files changed, 151 insertions(+), 333 deletions(-) --- base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd change-id: 20221103-omapfb-gpiod-87ca2550bd90 -- Dmitry
[PATCH 00/13] Convert omapfb drivers to gpiod API
This series converts various OMAPFB drivers to use the newer gpiod API that respects line polarity specified in DTS. Unfortunately existing DTS files specify incorrect (active high) polarity for reset lines. As discussed in [1] we will not try to correct existing DTSes, but instead follow the path established by DRM drivers for the same components, and continue using inverted polarity in the FB drivers. [1] https://lore.kernel.org/all/20221004213503.848262-1-dmitry.torok...@gmail.com/ To: Helge Deller To: Tony Lindgren To: Tomi Valkeinen To: Sebastian Reichel Cc: linux-o...@vger.kernel.org Cc: linux-fb...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org --- Dmitry Torokhov (13): omapfb: connector-hdmi: switch to using gpiod API omapfb: panel-sony-acx565akm: remove support for platform data omapfb: panel-sony-acx565akm: switch to using gpiod API omapfb: encoder-tfp410: switch to using gpiod API omapfb: panel-dsi-cm: switch to using gpiod API omapfb: panel-tpo-td043mtea1: switch to using gpiod API omapfb: panel-nec-nl8048hl11: switch to using gpiod API omapfb: panel-dpi: remove support for platform data omapfb: connector-analog-tv: remove support for platform data omapfb: encoder-opa362: fix included headers omapfb: panel-lgphilips-lb035q02: remove backlight GPIO handling omapfb: panel-tpo-td028ttec1: stop including gpio.h omapfb: panel-sharp-ls037v7dw01: fix included headers .../omap2/omapfb/displays/connector-analog-tv.c| 60 ++- .../fbdev/omap2/omapfb/displays/connector-hdmi.c | 49 +++-- .../fbdev/omap2/omapfb/displays/encoder-opa362.c | 4 +- .../fbdev/omap2/omapfb/displays/encoder-tfp410.c | 67 .../video/fbdev/omap2/omapfb/displays/panel-dpi.c | 83 ++- .../fbdev/omap2/omapfb/displays/panel-dsi-cm.c | 116 - .../omapfb/displays/panel-lgphilips-lb035q02.c | 21 +--- .../omap2/omapfb/displays/panel-nec-nl8048hl11.c | 72 - .../omapfb/displays/panel-sharp-ls037v7dw01.c | 3 +- .../omap2/omapfb/displays/panel-sony-acx565akm.c | 105 ++- .../omap2/omapfb/displays/panel-tpo-td028ttec1.c | 1 - .../omap2/omapfb/displays/panel-tpo-td043mtea1.c | 59 +++ include/video/omap-panel-data.h| 71 - 13 files changed, 170 insertions(+), 541 deletions(-) --- base-commit: 61c3426aca2c71052ddcd06c32e29d92304990fd change-id: 20221103-omapfb-gpiod-87ca2550bd90 -- Dmitry
Re: (subset) [PATCH v1 00/11] Get rid of [devm_]gpiod_get_from_of_node() public APIs
Hi Lorenzo, On Thu, Oct 27, 2022 at 03:38:11PM +0200, Lorenzo Pieralisi wrote: > On Sun, 4 Sep 2022 23:30:52 -0700, Dmitry Torokhov wrote: > > I would like to stop exporting OF-specific [devm_]gpiod_get_from_of_node() > > so that gpiolib can be cleaned a bit. We can do that by switching drivers > > to use generic fwnode API ([devm_]fwnode_gpiod_get()). By doing so we open > > the door to augmenting device tree and ACPI information through secondary > > software properties (once we teach gpiolib how to handle those). > > > > I hope that relevant maintainers will take patches through their trees and > > then we could merge the last one some time after -rc1. > > > > [...] > > Applied to pci/tegra, thanks! > > [01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get > https://git.kernel.org/lpieralisi/pci/c/16e3f4077965 Any chance you could also pick up [06/11] PCI: aardvark: switch to using devm_gpiod_get_optional() (20220903-gpiod_get_from_of_node-remove-v1-6-b29adfb27...@gmail.com) - Pali Rohár has acked it. Thanks! -- Dmitry
Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
On Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote: > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson > wrote: > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote: > > > On Tue, Oct 4, 2022 at 10:35 PM Dmitry Torokhov > > > wrote: > > > > > > > > Dmitry, could you fix this? Just patch away in gpiolib-of.c. > > > > > > > > Sure, I'll add a few quirks. I wonder what is the best way to merge > > > > this? I can create a bunch of IBs to be pulled, or I can send quirks to > > > > you/Bartosz and once they land send the patches to drivers... > > > > > > When I did it I was sufficiently convinced that I was the only one > > > patching > > > the quirks in gpiolib-of.c that merge window so I just included it as > > > a hunk in the driver patch. If there will be some more patches to that > > > file I guess some separate patch(es) for gpiolib-of.c is needed, maybe > > > an immutable branch for those if it becomes a lot. > > > > Are renames likely to be a common quirk on the road to libgpiod > > conversion? > > > > I admit I sort of expected it to be common enough that there would be > > one rename quirk in the code supported by an alphabetized string table. > > Such a table would certainly still provoke troublesome merges but ones > > that are trivially resolved. > > Dmitry added a table of sorts, the problems are usually a bit unique > for each instance of nonstandard DT GPIO bindings, that's why I > mostly solved it with open coding in gpiolib-of.c. OK, so I sent out the patch adding "reset-gpios" -> "gpios-reset" translation quirk to keep compatibility with the legacy names, but we still need to figure out what to do with incorrect line polarity in current DTses in tree. Unlike with names we have no indication if out of tree DTSes specify correct polarity or not, so we can't reasonably come up with workarounds that are guaranteed to work for everyone. I see several options: - the driver could continue ignoring line polarity specified in DTS (and use gpiod_set_value_raw()) and hope that they all/will be wired in the same way? - we could fix up in-kernel DTSes, allow flexibility of connection in new designs and respect polarity specified in out of tree DTSes, but accept that there can be breakages with old DTSes not contributed to the mainline or DTSes that were "cached" from an older kernel release - add another quirk forcing "active low" polarity for the legacy "gpios-reset" name, which will allow us respecting polarity in new "reset-gpios" name. Thanks. -- Dmitry
Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
On Tue, Oct 04, 2022 at 09:50:25PM +0200, Linus Walleij wrote: > On Tue, Oct 4, 2022 at 2:54 PM Daniel Thompson > wrote: > > > > We need to know if i.MX is shipping device trees stored in flash, > > > or if they bundle it with the kernel. > > > > This part is frequently found in add-on boards so it's not purely an > > i.MX-only question. > > Oh > > > IMHO for not-in-the-soc devices like this the presence of in-kernel DTs > > isn't enough to make a decision. What is needed is a degree of > > due-diligence to show that there are no obvious out-of-kernel users. > > OK I think this is a good case to use a special quirk in this case. > I actually envisioned keeping piling them up, and that they would > not be innumerable. > > Dmitry, could you fix this? Just patch away in gpiolib-of.c. Sure, I'll add a few quirks. I wonder what is the best way to merge this? I can create a bunch of IBs to be pulled, or I can send quirks to you/Bartosz and once they land send the patches to drivers... Thanks. -- Dmitry
Re: [RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
On Wed, Sep 28, 2022 at 12:00:51PM +0100, Daniel Thompson wrote:
> On Tue, Sep 27, 2022 at 03:32:35PM -0700, Dmitry Torokhov wrote:
> > Properties describing GPIOs should be named as "-gpios" or
> > "-gpio", and that is what gpiod API expects, however the
> > driver uses non-standard "gpios-reset" name. Let's adjust this, and also
> > note that the reset line is active low as that is also important to
> > gpiod API.
>
> No objections to the goal but...
>
>
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > Another option is to add another quirk into gpiolib-of.c, but we
> > may end up with a ton of them once we convert everything away from
> > of_get_named_gpio() to gpiod API, so I'd prefer not doing that.
>
> ... it is unusual to permit backwards incompatible changes to the DT
> bindings[1]: creating "flag days" where hardware stops functioning if
> you boot an new kernel with an old DT is a known annoyance to users.
>
> I usually favour quirks tables or similar[2] rather than break legacy
> DTs. Very occasionally I accept (believable) arguments that no legacy
> DTs actually exist but that can very difficult to verify.
>
> Overall I'd like to solicit views from both GPIO and DT maintainers
> before rejecting quirks tables as a way to help smooth these sort of
> changes (or links to ML archives if this has already been discussed).
I believe I was able to convince Rob once or twice that keeping
compatibility was not worth it (not in general but in a couple of
concrete cases), at least while device tree bindings are part of the
kernel. Can't find the emails though...
I think we should consider several options:
1. DTS/DTB is in firmware. In this case absolutely, we need to keep
binary compatibility as we can not expect users to reflash firmware
(there might not even be a new firmware). This situation matches what we
have with ACPI systems where we are trying to work around issues
2. DTS is shipped with the kernel:
2a. DTS is present in upstream kernel - awesome, we can patch it
as needed and have one less thing to worry about.
2b. DTS is not upstream. Vendor did not bother sending it. In
this case it is extremely unlikely that an upstream kernel
will work on such system out of the box, and updating the
kernel is a large engineering task where you pull down new
kernel, rework and apply non-upstream patches, rework kernel
config (new Kconfig options can be introduced, old options
can be renamed, etc). And then spend several weeks
stabilizing the system and tracking down regressions (in
general, not DTS-related ones)
3. DTS is not in firmware and not in kernel. Are there such systems?
So my opinion is that while device trees are part of kernel code and
have not been split into a separate project they are a fair game. If the
change can be handled in the driver without much effort (something like
"wakeup-source" vs "linux,wakeup" vs "linux,keypad-wakeup") - fine, we
can just put a tiny quirk in the driver, but if we need something more
substantial we need to think long and hard if we should implement a
fallback and how much effort there is to maintain/test it so it does not
bitrot.
Anyway, I hope Rob, Linux and Krzysztof to chime in on this exciting
topic once again ;)
>
> [1] For this particular driver the situation is muddied slightly
> because it looks like complex since it looks the bindings for
> himax,hx8357 and himax,hx8369 are undocumented (and badly named).
>
> [2] When the property is not parsed by library code mostly we handle
> legacy by consuming both new or old names in the parser code.
>
>
> > diff --git a/drivers/video/backlight/hx8357.c
> > b/drivers/video/backlight/hx8357.c
> > index 9b50bc96e00f..41332f48b2df 100644
> > --- a/drivers/video/backlight/hx8357.c
> > +++ b/drivers/video/backlight/hx8357.c
> > @@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi)
> > if (!match || !match->data)
> > return -EINVAL;
> >
> > - lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
> > + lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0);
> > if (!gpio_is_valid(lcd->reset)) {
> > dev_err(>dev, "Missing dt property: gpios-reset\n");
> > return -EINVAL;
>
> Daniel.
Thanks.
--
Dmitry
[RFC/PATCH] backlight: hx8357: prepare to conversion to gpiod API
Properties describing GPIOs should be named as "-gpios" or
"-gpio", and that is what gpiod API expects, however the
driver uses non-standard "gpios-reset" name. Let's adjust this, and also
note that the reset line is active low as that is also important to
gpiod API.
Signed-off-by: Dmitry Torokhov
---
Another option is to add another quirk into gpiolib-of.c, but we
may end up with a ton of them once we convert everything away from
of_get_named_gpio() to gpiod API, so I'd prefer not doing that.
arch/arm/boot/dts/imx28-cfa10049.dts | 7 +--
arch/arm/boot/dts/imx28-cfa10055.dts | 3 ++-
arch/arm/boot/dts/imx28-cfa10056.dts | 3 ++-
drivers/video/backlight/hx8357.c | 2 +-
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts
b/arch/arm/boot/dts/imx28-cfa10049.dts
index 9ef0d567ea48..ae51a2aa2028 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -3,6 +3,7 @@
* Copyright 2012 Free Electrons
*/
+#include
/*
* The CFA-10049 is an expansion board for the CFA-10036 module, thus we
* need to include the CFA-10036 DTS.
@@ -346,8 +347,10 @@ hx8357: hx8357@0 {
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
- gpios-reset = < 30 0>;
- im-gpios = < 4 0 5 0 6 0>;
+ reset-gpios = < 30 GPIO_ACTIVE_LOW>;
+ im-gpios = < 4 GPIO_ACTIVE_HIGH
+5 GPIO_ACTIVE_HIGH
+6 GPIO_ACTIVE_HIGH>;
};
};
diff --git a/arch/arm/boot/dts/imx28-cfa10055.dts
b/arch/arm/boot/dts/imx28-cfa10055.dts
index fac5bbda7a93..70e4dc67f7d2 100644
--- a/arch/arm/boot/dts/imx28-cfa10055.dts
+++ b/arch/arm/boot/dts/imx28-cfa10055.dts
@@ -4,6 +4,7 @@
* Free Electrons
*/
+#include
/*
* The CFA-10055 is an expansion board for the CFA-10036 module and
* CFA-10037, thus we need to include the CFA-10037 DTS.
@@ -148,7 +149,7 @@ hx8357: hx8357@0 {
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
- gpios-reset = < 30 0>;
+ reset-gpios = < 30 GPIO_ACTIVE_LOW>;
};
};
diff --git a/arch/arm/boot/dts/imx28-cfa10056.dts
b/arch/arm/boot/dts/imx28-cfa10056.dts
index c5f3337e8b39..687eaa555a15 100644
--- a/arch/arm/boot/dts/imx28-cfa10056.dts
+++ b/arch/arm/boot/dts/imx28-cfa10056.dts
@@ -3,6 +3,7 @@
* Copyright 2013 Free Electrons
*/
+#include
/*
* The CFA-10055 is an expansion board for the CFA-10036 module and
* CFA-10037, thus we need to include the CFA-10037 DTS.
@@ -107,7 +108,7 @@ hx8369: hx8369@0 {
spi-max-frequency = <10>;
spi-cpol;
spi-cpha;
- gpios-reset = < 30 0>;
+ reset-gpios = < 30 GPIO_ACTIVE_LOW>;
};
};
};
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 9b50bc96e00f..41332f48b2df 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -601,7 +601,7 @@ static int hx8357_probe(struct spi_device *spi)
if (!match || !match->data)
return -EINVAL;
- lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
+ lcd->reset = of_get_named_gpio(spi->dev.of_node, "reset-gpios", 0);
if (!gpio_is_valid(lcd->reset)) {
dev_err(>dev, "Missing dt property: gpios-reset\n");
return -EINVAL;
--
2.38.0.rc1.362.ged0d419d3c-goog
--
Dmitry
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On Mon, Sep 05, 2022 at 03:09:05PM -0700, Guenter Roeck wrote:
> On 9/5/22 12:47, Dmitry Torokhov wrote:
> [ ... ]
> > > We know that count is either 1 or 2 here, so strictly speaking
> > > if (count == 1) {
> > > } else {
> > > }
> > > would be sufficient. On the other side, that depends on ARRAY_SIZE() being
> > > exactly 2, so
> > > if (count == 1) {
> > > } else if (count == 2) {
> > > }
> > > would also make sense. Either way is fine with me. I'll leave it up
> > > to Dmitry to decide what he wants to do.
> >
> > My goal is to drop usage of devm_gpiod_get_from_of_node(), beyond that I
> > do not have strong preferences either way really. It is probing code, so
> > performance is not critical, but I'm obviously satisfied with how the
> > code looks now, or I would not have sent it.
> >
>
> Good point.
>
> Reviewed-by: Guenter Roeck
Guenter, individual patches are going through maintainer's trees, will
you take this one?
Thanks.
--
Dmitry
Re: [PATCH v1 07/11] PCI: apple: switch to using fwnode_gpiod_get_index()
On Sun, Sep 04, 2022 at 11:30:59PM -0700, Dmitry Torokhov wrote: > I would like to stop exporting OF-specific gpiod_get_from_of_node() > so that gpiolib can be cleaned a bit, so let's switch to the generic > fwnode property API. > > Signed-off-by: Dmitry Torokhov > > diff --git a/drivers/pci/controller/pcie-apple.c > b/drivers/pci/controller/pcie-apple.c > index a2c3c207a04b..d83817d3ff86 100644 > --- a/drivers/pci/controller/pcie-apple.c > +++ b/drivers/pci/controller/pcie-apple.c > @@ -516,8 +516,8 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie, > u32 stat, idx; > int ret, i; > > - reset = gpiod_get_from_of_node(np, "reset-gpios", 0, > -GPIOD_OUT_LOW, "PERST#"); > + reset = fwnode_gpiod_get_index(of_fwnode_handle(np), > +"reset", 0, GPIOD_OUT_LOW, "PERST#"); Hmm, I am looking at the driver and it leaks the reset gpio on unbind/unload. I guess it does not matter in practice, but still nice not to leak. Thankfully it is easy to cure by switching to devm option: devm_fwnode_gpiod_get(). I'll send and updated patch with a new justification. Thanks. -- Dmitry
Re: [PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()
On Tue, Sep 06, 2022 at 01:10:10AM +0200, Pali Rohár wrote: > On Monday 05 September 2022 15:54:53 Dmitry Torokhov wrote: > > On Mon, Sep 05, 2022 at 09:00:46AM +0200, Pali Rohár wrote: > > > On Sunday 04 September 2022 23:30:58 Dmitry Torokhov wrote: > > > > I would like to stop exporting OF-specific devm_gpiod_get_from_of_node() > > > > so that gpiolib can be cleaned a bit, so let's switch to the generic > > > > device property API. > > > > > > > > I believe that the only reason the driver, instead of the standard > > > > devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is > > > > because it wanted to set up a pretty consumer name for the GPIO, > > > > > > IIRC consumer name is not used at all. > > > > > > The reason was to specify full name of DTS property, for easier > > > identification of the code. DTS property is "reset-gpios" but API > > > specify only "reset". > > > > I see. Do you want me to reset the patch with updated desctiption as to > > the reason devm_gpiod_get_from_of_node() was used? > > I think it is fine. So add my: > > Acked-by: Pali Rohár > > Anyway as another improvement for future I would suggest some API > function with _optional_ logic, so it could be used for more PCIe I think we need to see how many are attaching reset lines to subnodes. If there are multiple then I agree we could add _optional. So far I see: dtor@dtor-ws:~/kernel/linux-next (gpiod_get_from_of_node-remove)$ git grep '"reset"' -- drivers/pci/controller/ drivers/pci/controller/cadence/pci-j721e.c: gpiod = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); drivers/pci/controller/dwc/pci-keystone.c: gpiod = devm_gpiod_get_optional(dev, "reset", drivers/pci/controller/dwc/pci-meson.c: mp->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); drivers/pci/controller/dwc/pcie-dw-rockchip.c: rockchip->rst_gpio = devm_gpiod_get_optional(>dev, "reset", drivers/pci/controller/dwc/pcie-fu740.c:afp->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); drivers/pci/controller/dwc/pcie-intel-gw.c: pcie->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW); drivers/pci/controller/dwc/pcie-keembay.c: pcie->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH); drivers/pci/controller/dwc/pcie-qcom-ep.c: pcie_ep->reset = devm_gpiod_get(dev, "reset", GPIOD_IN); drivers/pci/controller/dwc/pcie-tegra194.c: pcie->pex_rst_gpiod = devm_gpiod_get(pcie->dev, "reset", GPIOD_IN); drivers/pci/controller/pci-aardvark.c: pcie->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW); drivers/pci/controller/pci-tegra.c: "reset", drivers/pci/controller/pcie-apple.c: "reset", 0, GPIOD_OUT_LOW, "PERST#"); drivers/pci/controller/pcie-mt7621.c: port->gpio_rst = devm_gpiod_get_index_optional(dev, "reset", slot, So majority have reset lines attached to the "main" node and thus can use devm_gpiod_get_optional(). Thanks. -- Dmitry
Re: [PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()
On Mon, Sep 05, 2022 at 09:00:46AM +0200, Pali Rohár wrote:
> On Sunday 04 September 2022 23:30:58 Dmitry Torokhov wrote:
> > I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
> > so that gpiolib can be cleaned a bit, so let's switch to the generic
> > device property API.
> >
> > I believe that the only reason the driver, instead of the standard
> > devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is
> > because it wanted to set up a pretty consumer name for the GPIO,
>
> IIRC consumer name is not used at all.
>
> The reason was to specify full name of DTS property, for easier
> identification of the code. DTS property is "reset-gpios" but API
> specify only "reset".
I see. Do you want me to reset the patch with updated desctiption as to
the reason devm_gpiod_get_from_of_node() was used?
>
> > and we now have a special API for that.
> >
> > Signed-off-by: Dmitry Torokhov
> >
> > diff --git a/drivers/pci/controller/pci-aardvark.c
> > b/drivers/pci/controller/pci-aardvark.c
> > index 4834198cc86b..4a8a4a8522cb 100644
> > --- a/drivers/pci/controller/pci-aardvark.c
> > +++ b/drivers/pci/controller/pci-aardvark.c
> > @@ -1856,20 +1856,19 @@ static int advk_pcie_probe(struct platform_device
> > *pdev)
> > return ret;
> > }
> >
> > - pcie->reset_gpio = devm_gpiod_get_from_of_node(dev, dev->of_node,
> > - "reset-gpios", 0,
> > - GPIOD_OUT_LOW,
> > - "pcie1-reset");
> > + pcie->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
> > ret = PTR_ERR_OR_ZERO(pcie->reset_gpio);
> > if (ret) {
> > - if (ret == -ENOENT) {
> > - pcie->reset_gpio = NULL;
> > - } else {
> > - if (ret != -EPROBE_DEFER)
> > - dev_err(dev, "Failed to get reset-gpio: %i\n",
> > - ret);
> > - return ret;
> > - }
> > + if (ret != -EPROBE_DEFER)
> > + dev_err(dev, "Failed to get reset-gpio: %i\n",
> > + ret);
> > + return ret;
> > + }
> > +
> > + ret = gpiod_set_consumer_name(pcie->reset_gpio, "pcie1-reset");
> > + if (ret) {
> > + dev_err(dev, "Failed to set reset gpio name: %d\n", ret);
> > + return ret;
> > }
> >
> > ret = of_pci_get_max_link_speed(dev->of_node);
> >
> > --
> > b4 0.10.0-dev-fc921
Thanks.
--
Dmitry
Re: [PATCH v1 01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get
On Mon, Sep 05, 2022 at 09:19:02AM +0200, Pali Rohár wrote: > On Sunday 04 September 2022 23:30:53 Dmitry Torokhov wrote: > > I would like to limit (or maybe even remove) use of > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > a bit, so let's switch to the generic device property API. It may even > > help with handling secondary fwnodes when gpiolib is taught to handle > > gpios described by swnodes. > > > > Signed-off-by: Dmitry Torokhov > > > > diff --git a/drivers/pci/controller/pci-tegra.c > > b/drivers/pci/controller/pci-tegra.c > > index 8e323e93be91..929f9363e94b 100644 > > --- a/drivers/pci/controller/pci-tegra.c > > +++ b/drivers/pci/controller/pci-tegra.c > > @@ -2202,10 +2202,11 @@ static int tegra_pcie_parse_dt(struct tegra_pcie > > *pcie) > > * and in this case fall back to using AFI per port register > > * to toggle PERST# SFIO line. > > */ > > - rp->reset_gpio = devm_gpiod_get_from_of_node(dev, port, > > -"reset-gpios", 0, > > -GPIOD_OUT_LOW, > > -label); > > + rp->reset_gpio = devm_fwnode_gpiod_get(dev, > > + of_fwnode_handle(port), > > + "reset", > > + GPIOD_OUT_LOW, > > + label); > > Why in pci-aardvark.c for PERST# reset-gpio you have used > devm_gpiod_get_optional() and here in pci-tegra.c you have used > devm_fwnode_gpiod_get()? I think that PERST# logic is same in both > drivers. I believe Andy already answered that, but in this driver we can have several root ports described via subnodes of dev->of_node, and reset GPIOs are attached to those subnodes. We are forced to use devm_fwnode_gpiod_get() instead of devm_gpiod_get_optional() as we need to supply the exact fwnode we need to look up GPIO in, and can not infer it from the 'dev' parameter of devm_gpiod_get(). Thanks. -- Dmitry
Re: [PATCH v1 02/11] drm/tegra: switch to using devm_fwnode_gpiod_get
On Mon, Sep 05, 2022 at 11:03:38PM +0200, Linus Walleij wrote: > On Mon, Sep 5, 2022 at 9:37 PM Dmitry Torokhov > wrote: > > On Mon, Sep 05, 2022 at 01:57:01PM +0300, Andy Shevchenko wrote: > > > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > > > wrote: > > > > > > > > I would like to limit (or maybe even remove) use of > > > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > > > a bit, so let's switch to the generic device property API. > > > > > > > It may even > > > > help with handling secondary fwnodes when gpiolib is taught to handle > > > > gpios described by swnodes. > > > > > > I would remove this sentence from all commit messages since it's a > > > debatable thing and might even not happen, so the above is a pure > > > speculation. > > > > I have the patches. Granted, I had them since '19 ;) but I'm rebasing > > them and going to push them. I need them to convert bunch of input > > drivers away from platform data. > > That's good news! > > Are you referring to this patch set mentioned in a discussion > from 2017 thru 2020? > https://lore.kernel.org/linux-input/20200826161222.GA1665100@dtor-ws/ > > I put aside GPIO descriptor conversion for input devices (keys, buttons) > in board files anticipating a swnode mechanism. Yep, that one, exactly. It is taking a bit longer than I anticipated ;) Thanks. -- Dmitry
Re: [PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()
On Mon, Sep 05, 2022 at 01:47:41PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 10:02 AM Pali Rohár wrote: > > On Sunday 04 September 2022 23:30:58 Dmitry Torokhov wrote: > > > I would like to stop exporting OF-specific devm_gpiod_get_from_of_node() > > > so that gpiolib can be cleaned a bit, so let's switch to the generic > > > device property API. > > > > > > I believe that the only reason the driver, instead of the standard > > > devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is > > > because it wanted to set up a pretty consumer name for the GPIO, > > > > IIRC consumer name is not used at all. > > It's. The user space tools use it as a label. So, GPIO line can have > "name" (this is provider specific) and "label" (which is consumer > specific, i.o.w. how we use this line). > > ... > > > > + if (ret != -EPROBE_DEFER) > > > + dev_err(dev, "Failed to get reset-gpio: %i\n", > > > + ret); > > > + return ret; > > I understand that in the input subsystem maintainer's hat you don't > like dev_err_probe(), but it's a good case to have it here. The driver currently does not use this API, so I elected not to introduce it in this series. Thanks, -- Dmitry
Re: [PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get()
On Mon, Sep 05, 2022 at 10:41:40PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 10:40 PM Dmitry Torokhov > wrote: > > On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote: > > > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > > > wrote: > > ... > > > > > - gpiod = devm_gpiod_get_from_of_node(>dev, np, > > > > - > > > > "nvidia,phy-reset-gpio", > > > > - 0, GPIOD_OUT_HIGH, > > > > - "ulpi_phy_reset_b"); > > > > + gpiod = devm_gpiod_get(>dev, "nvidia,phy-reset", > > > > + GPIOD_OUT_HIGH); > > > > err = PTR_ERR_OR_ZERO(gpiod); > > > > > > What does _OR_ZERO mean now? > > > > This converts a pointer to an error code if a pointer represents > > ERR_PTR() encoded error, or 0 to indicate success. > > Yes, I know that. My point is, how is it useful now (or even before)? > I mean that devm_gpio_get() never returns NULL, right? What does returning NULL have to do with anything. It converts a pointer to a "classic" return code, with negative errors and 0 on success. It allows to not use multiple IS_ERR/PTR_ERR in the code (I'd need 1 IS_ERR and 2 PTR_ERR, one in dev_err() and another to return). Thanks. -- Dmitry
Re: [PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
On Mon, Sep 05, 2022 at 08:49:58AM -0700, Guenter Roeck wrote:
> On 9/5/22 08:21, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 6:13 PM Guenter Roeck wrote:
> > > On 9/5/22 04:09, Andy Shevchenko wrote:
> > > > On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
> > > > wrote:
> >
> > ...
> >
> > > > > + count = device_property_count_u32(dev->parent,
> > > > > "rohm,hw-timeout-ms");
> > > > > + if (count < 0 && count != -EINVAL)
> > > > > + return count;
> > > > > +
> > > > > + if (count > 0) {
> > > >
> > > > > + if (count > ARRAY_SIZE(hw_margin))
> > > > > + return -EINVAL;
> > > >
> > > > Why double check? You may move it out of the (count > 0).
> >
> > > Two checks will always be needed, so I don't entirely see
> > > how that would be better.
> >
> > But not nested. That's my point:
> >
> > if (count > ARRAY_SIZE())
> >return ...
> > if (count > 0)
> >...
> >
>
> The old code has either 1 or two checks if there is no error.
> Your suggested code has always two checks. I don't see how that
> is an improvement.
>
> > > > > - if (ret == 1)
> > > > > - hw_margin_max = hw_margin[0];
> > > >
> > > > > + ret = device_property_read_u32_array(dev->parent,
> > > > > +
> > > > > "rohm,hw-timeout-ms",
> > > > > +hw_margin,
> > > > > count);
> > > > > + if (ret < 0)
> > > > > + return ret;
> > > >
> > > > So, only this needs the count > 0 check since below already has it
> > > > implicitly.
> > > >
> > > Sorry, I don't understand this comment.
> >
> > if (count > 0) {
> >ret = device_property_read_u32_array(...);
> >...
> > }
> > if (count == 1)
> > ...
> > if (count == 2)
> > ...
> >
> > But here it might be better to have the nested conditionals.
> >
>
> We know that count is either 1 or 2 here, so strictly speaking
> if (count == 1) {
> } else {
> }
> would be sufficient. On the other side, that depends on ARRAY_SIZE() being
> exactly 2, so
> if (count == 1) {
> } else if (count == 2) {
> }
> would also make sense. Either way is fine with me. I'll leave it up
> to Dmitry to decide what he wants to do.
My goal is to drop usage of devm_gpiod_get_from_of_node(), beyond that I
do not have strong preferences either way really. It is probing code, so
performance is not critical, but I'm obviously satisfied with how the
code looks now, or I would not have sent it.
Thanks.
--
Dmitry
Re: [PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get()
On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote:
> On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov
> wrote:
> >
> > I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
> > so that gpiolib can be cleaned a bit, so let's switch to the generic
> > device property API.
> >
> > I believe that the only reason the driver, instead of the standard
> > devm_gpiod_get(), used devm_gpiod_get_from_of_node() is because it
> > wanted to set up a pretty consumer name for the GPIO, and we now have
> > a special API for that.
>
> ...
>
> > - gpiod = devm_gpiod_get_from_of_node(>dev, np,
> > - "nvidia,phy-reset-gpio",
> > - 0, GPIOD_OUT_HIGH,
> > - "ulpi_phy_reset_b");
> > + gpiod = devm_gpiod_get(>dev, "nvidia,phy-reset",
> > + GPIOD_OUT_HIGH);
> > err = PTR_ERR_OR_ZERO(gpiod);
>
> What does _OR_ZERO mean now?
This converts a pointer to an error code if a pointer represents
ERR_PTR() encoded error, or 0 to indicate success.
static inline int __must_check PTR_ERR_OR_ZERO(__force const void *ptr)
{
if (IS_ERR(ptr))
return PTR_ERR(ptr);
else
return 0;
}
Thanks.
--
Dmitry
Re: [PATCH v1 02/11] drm/tegra: switch to using devm_fwnode_gpiod_get
On Mon, Sep 05, 2022 at 01:57:01PM +0300, Andy Shevchenko wrote: > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov > wrote: > > > > I would like to limit (or maybe even remove) use of > > [devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned > > a bit, so let's switch to the generic device property API. > > > It may even > > help with handling secondary fwnodes when gpiolib is taught to handle > > gpios described by swnodes. > > I would remove this sentence from all commit messages since it's a > debatable thing and might even not happen, so the above is a pure > speculation. I have the patches. Granted, I had them since '19 ;) but I'm rebasing them and going to push them. I need them to convert bunch of input drivers away from platform data. Thanks. -- Dmitry
[PATCH v1 09/11] regulator: bd9576: switch to using devm_fwnode_gpiod_get()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
While at it switch the rest of the calls to read properties in
bd957x_probe() to the generic device property API as well.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/regulator/bd9576-regulator.c
b/drivers/regulator/bd9576-regulator.c
index aa42da4d141e..393c8693b327 100644
--- a/drivers/regulator/bd9576-regulator.c
+++ b/drivers/regulator/bd9576-regulator.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -939,8 +940,8 @@ static int bd957x_probe(struct platform_device *pdev)
}
ic_data->regmap = regmap;
- vout_mode = of_property_read_bool(pdev->dev.parent->of_node,
-"rohm,vout1-en-low");
+ vout_mode = device_property_read_bool(pdev->dev.parent,
+ "rohm,vout1-en-low");
if (vout_mode) {
struct gpio_desc *en;
@@ -948,10 +949,10 @@ static int bd957x_probe(struct platform_device *pdev)
/* VOUT1 enable state judged by VOUT1_EN pin */
/* See if we have GPIO defined */
- en = devm_gpiod_get_from_of_node(>dev,
-pdev->dev.parent->of_node,
-"rohm,vout1-en-gpios", 0,
-GPIOD_OUT_LOW, "vout1-en");
+ en = devm_fwnode_gpiod_get(>dev,
+ dev_fwnode(pdev->dev.parent),
+ "rohm,vout1-en", GPIOD_OUT_LOW,
+ "vout1-en");
if (!IS_ERR(en)) {
/* VOUT1_OPS gpio ctrl */
/*
@@ -986,8 +987,8 @@ static int bd957x_probe(struct platform_device *pdev)
* like DDR voltage selection.
*/
platform_set_drvdata(pdev, ic_data);
- ddr_sel = of_property_read_bool(pdev->dev.parent->of_node,
-"rohm,ddr-sel-low");
+ ddr_sel = device_property_read_bool(pdev->dev.parent,
+ "rohm,ddr-sel-low");
if (ddr_sel)
ic_data->regulator_data[2].desc.fixed_uV = 135;
else
--
b4 0.10.0-dev-fc921
[PATCH v1 11/11] gpiolib: of: remove [devm_]gpiod_get_from_of_node() APIs
Now that everyone is using [devm_]fwnode_gpiod_get[_index]() APIs, we no
longer need to expose OF-specific [devm_]gpiod_get_from_of_node().
Note that we are keeping gpiod_get_from_of_node() but only as a private
to gpiolib function.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/gpio/gpiolib-devres.c b/drivers/gpio/gpiolib-devres.c
index 16a696249229..fe9ce6b19f15 100644
--- a/drivers/gpio/gpiolib-devres.c
+++ b/drivers/gpio/gpiolib-devres.c
@@ -129,61 +129,6 @@ struct gpio_desc *__must_check devm_gpiod_get_index(struct
device *dev,
}
EXPORT_SYMBOL_GPL(devm_gpiod_get_index);
-/**
- * devm_gpiod_get_from_of_node() - obtain a GPIO from an OF node
- * @dev: device for lifecycle management
- * @node: handle of the OF node
- * @propname: name of the DT property representing the GPIO
- * @index: index of the GPIO to obtain for the consumer
- * @dflags:GPIO initialization flags
- * @label: label to attach to the requested GPIO
- *
- * Returns:
- * On successful request the GPIO pin is configured in accordance with
- * provided @dflags.
- *
- * In case of error an ERR_PTR() is returned.
- */
-struct gpio_desc *devm_gpiod_get_from_of_node(struct device *dev,
- const struct device_node *node,
- const char *propname, int index,
- enum gpiod_flags dflags,
- const char *label)
-{
- struct gpio_desc **dr;
- struct gpio_desc *desc;
-
- desc = gpiod_get_from_of_node(node, propname, index, dflags, label);
- if (IS_ERR(desc))
- return desc;
-
- /*
-* For non-exclusive GPIO descriptors, check if this descriptor is
-* already under resource management by this device.
-*/
- if (dflags & GPIOD_FLAGS_BIT_NONEXCLUSIVE) {
- struct devres *dres;
-
- dres = devres_find(dev, devm_gpiod_release,
- devm_gpiod_match, );
- if (dres)
- return desc;
- }
-
- dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
- GFP_KERNEL);
- if (!dr) {
- gpiod_put(desc);
- return ERR_PTR(-ENOMEM);
- }
-
- *dr = desc;
- devres_add(dev, dr);
-
- return desc;
-}
-EXPORT_SYMBOL_GPL(devm_gpiod_get_from_of_node);
-
/**
* devm_fwnode_gpiod_get_index - get a GPIO descriptor from a given node
* @dev: GPIO consumer
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index a037b50bef33..b0e0723b12ab 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -365,7 +365,6 @@ struct gpio_desc *gpiod_get_from_of_node(const struct
device_node *node,
return desc;
}
-EXPORT_SYMBOL_GPL(gpiod_get_from_of_node);
/*
* The SPI GPIO bindings happened before we managed to establish that GPIO
diff --git a/drivers/gpio/gpiolib-of.h b/drivers/gpio/gpiolib-of.h
index 8af2bc899aab..e0da568d6da3 100644
--- a/drivers/gpio/gpiolib-of.h
+++ b/drivers/gpio/gpiolib-of.h
@@ -3,6 +3,7 @@
#ifndef GPIOLIB_OF_H
#define GPIOLIB_OF_H
+struct device_node;
struct gpio_chip;
enum of_gpio_flags;
@@ -16,6 +17,10 @@ void of_gpiochip_remove(struct gpio_chip *gc);
int of_gpio_get_count(struct device *dev, const char *con_id);
bool of_gpio_need_valid_mask(const struct gpio_chip *gc);
void of_gpio_dev_init(struct gpio_chip *gc, struct gpio_device *gdev);
+struct gpio_desc *gpiod_get_from_of_node(const struct device_node *node,
+const char *propname, int index,
+enum gpiod_flags dflags,
+const char *label);
#else
static inline struct gpio_desc *of_find_gpio(struct device *dev,
const char *con_id,
@@ -38,6 +43,14 @@ static inline void of_gpio_dev_init(struct gpio_chip *gc,
struct gpio_device *gdev)
{
}
+static inline
+struct gpio_desc *gpiod_get_from_of_node(const struct device_node *node,
+const char *propname, int index,
+enum gpiod_flags dflags,
+const char *label)
+{
+ return ERR_PTR(-ENOSYS);
+}
#endif /* CONFIG_OF_GPIO */
extern struct notifier_block gpio_of_notifier;
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index fe0f460d9a3b..37448ee17e81 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -615,54 +615,6 @@ struct gpio_desc *devm_fwnode_get_gpiod_from_child(struct
device *dev,
return devm_fwnode_gpiod_get_index(dev, child, con_id, 0, flags, label);
}
-#if IS_ENABLED(CONFIG_GPIOLIB) && IS_ENABLED(CONFIG_OF_GPIO)
-struct device_nod
[PATCH v1 10/11] watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
While at it switch the rest of the calls to read properties in
bd9576_wdt_probe() to the generic device property API as well.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/watchdog/bd9576_wdt.c b/drivers/watchdog/bd9576_wdt.c
index 0b6999f3b6e8..4a20e07fbb69 100644
--- a/drivers/watchdog/bd9576_wdt.c
+++ b/drivers/watchdog/bd9576_wdt.c
@@ -9,8 +9,8 @@
#include
#include
#include
-#include
#include
+#include
#include
#include
@@ -202,10 +202,10 @@ static int bd957x_set_wdt_mode(struct bd9576_wdt_priv
*priv, int hw_margin,
static int bd9576_wdt_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
- struct device_node *np = dev->parent->of_node;
struct bd9576_wdt_priv *priv;
u32 hw_margin[2];
u32 hw_margin_max = BD957X_WDT_DEFAULT_MARGIN, hw_margin_min = 0;
+ int count;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -221,40 +221,51 @@ static int bd9576_wdt_probe(struct platform_device *pdev)
return -ENODEV;
}
- priv->gpiod_en = devm_gpiod_get_from_of_node(dev, dev->parent->of_node,
-
"rohm,watchdog-enable-gpios",
-0, GPIOD_OUT_LOW,
-"watchdog-enable");
+ priv->gpiod_en = devm_fwnode_gpiod_get(dev, dev_fwnode(dev->parent),
+ "rohm,watchdog-enable",
+ GPIOD_OUT_LOW,
+ "watchdog-enable");
if (IS_ERR(priv->gpiod_en))
return dev_err_probe(dev, PTR_ERR(priv->gpiod_en),
"getting watchdog-enable GPIO failed\n");
- priv->gpiod_ping = devm_gpiod_get_from_of_node(dev,
dev->parent->of_node,
-"rohm,watchdog-ping-gpios",
-0, GPIOD_OUT_LOW,
-"watchdog-ping");
+ priv->gpiod_ping = devm_fwnode_gpiod_get(dev, dev_fwnode(dev->parent),
+"rohm,watchdog-ping",
+GPIOD_OUT_LOW,
+"watchdog-ping");
if (IS_ERR(priv->gpiod_ping))
return dev_err_probe(dev, PTR_ERR(priv->gpiod_ping),
"getting watchdog-ping GPIO failed\n");
- ret = of_property_read_variable_u32_array(np, "rohm,hw-timeout-ms",
- _margin[0], 1, 2);
- if (ret < 0 && ret != -EINVAL)
- return ret;
+ count = device_property_count_u32(dev->parent, "rohm,hw-timeout-ms");
+ if (count < 0 && count != -EINVAL)
+ return count;
+
+ if (count > 0) {
+ if (count > ARRAY_SIZE(hw_margin))
+ return -EINVAL;
- if (ret == 1)
- hw_margin_max = hw_margin[0];
+ ret = device_property_read_u32_array(dev->parent,
+"rohm,hw-timeout-ms",
+hw_margin, count);
+ if (ret < 0)
+ return ret;
- if (ret == 2) {
- hw_margin_max = hw_margin[1];
- hw_margin_min = hw_margin[0];
+ if (count == 1)
+ hw_margin_max = hw_margin[0];
+
+ if (count == 2) {
+ hw_margin_max = hw_margin[1];
+ hw_margin_min = hw_margin[0];
+ }
}
ret = bd957x_set_wdt_mode(priv, hw_margin_max, hw_margin_min);
if (ret)
return ret;
- priv->always_running = of_property_read_bool(np, "always-running");
+ priv->always_running = device_property_read_bool(dev->parent,
+"always-running");
watchdog_set_drvdata(>wdd, priv);
--
b4 0.10.0-dev-fc921
[PATCH v1 07/11] PCI: apple: switch to using fwnode_gpiod_get_index()
I would like to stop exporting OF-specific gpiod_get_from_of_node() so that gpiolib can be cleaned a bit, so let's switch to the generic fwnode property API. Signed-off-by: Dmitry Torokhov diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c index a2c3c207a04b..d83817d3ff86 100644 --- a/drivers/pci/controller/pcie-apple.c +++ b/drivers/pci/controller/pcie-apple.c @@ -516,8 +516,8 @@ static int apple_pcie_setup_port(struct apple_pcie *pcie, u32 stat, idx; int ret, i; - reset = gpiod_get_from_of_node(np, "reset-gpios", 0, - GPIOD_OUT_LOW, "PERST#"); + reset = fwnode_gpiod_get_index(of_fwnode_handle(np), + "reset", 0, GPIOD_OUT_LOW, "PERST#"); if (IS_ERR(reset)) return PTR_ERR(reset); -- b4 0.10.0-dev-fc921
[PATCH v1 06/11] PCI: aardvark: switch to using devm_gpiod_get_optional()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
device property API.
I believe that the only reason the driver, instead of the standard
devm_gpiod_get_optional(), used devm_gpiod_get_from_of_node() is
because it wanted to set up a pretty consumer name for the GPIO,
and we now have a special API for that.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/pci/controller/pci-aardvark.c
b/drivers/pci/controller/pci-aardvark.c
index 4834198cc86b..4a8a4a8522cb 100644
--- a/drivers/pci/controller/pci-aardvark.c
+++ b/drivers/pci/controller/pci-aardvark.c
@@ -1856,20 +1856,19 @@ static int advk_pcie_probe(struct platform_device *pdev)
return ret;
}
- pcie->reset_gpio = devm_gpiod_get_from_of_node(dev, dev->of_node,
- "reset-gpios", 0,
- GPIOD_OUT_LOW,
- "pcie1-reset");
+ pcie->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_LOW);
ret = PTR_ERR_OR_ZERO(pcie->reset_gpio);
if (ret) {
- if (ret == -ENOENT) {
- pcie->reset_gpio = NULL;
- } else {
- if (ret != -EPROBE_DEFER)
- dev_err(dev, "Failed to get reset-gpio: %i\n",
- ret);
- return ret;
- }
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get reset-gpio: %i\n",
+ ret);
+ return ret;
+ }
+
+ ret = gpiod_set_consumer_name(pcie->reset_gpio, "pcie1-reset");
+ if (ret) {
+ dev_err(dev, "Failed to set reset gpio name: %d\n", ret);
+ return ret;
}
ret = of_pci_get_max_link_speed(dev->of_node);
--
b4 0.10.0-dev-fc921
[PATCH v1 08/11] regulator: bd71815: switch to using devm_fwnode_gpiod_get()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/regulator/bd71815-regulator.c
b/drivers/regulator/bd71815-regulator.c
index acaa6607898e..c2b8b8be7824 100644
--- a/drivers/regulator/bd71815-regulator.c
+++ b/drivers/regulator/bd71815-regulator.c
@@ -571,11 +571,10 @@ static int bd7181x_probe(struct platform_device *pdev)
dev_err(>dev, "No parent regmap\n");
return -ENODEV;
}
- ldo4_en = devm_gpiod_get_from_of_node(>dev,
- pdev->dev.parent->of_node,
-"rohm,vsel-gpios", 0,
-GPIOD_ASIS, "ldo4-en");
+ ldo4_en = devm_fwnode_gpiod_get(>dev,
+ dev_fwnode(pdev->dev.parent),
+ "rohm,vsel", GPIOD_ASIS, "ldo4-en");
if (IS_ERR(ldo4_en)) {
ret = PTR_ERR(ldo4_en);
if (ret != -ENOENT)
--
b4 0.10.0-dev-fc921
[PATCH v1 05/11] usb: gadget: udc: at91: switch to using fwnode_gpiod_get_index()
I would like to stop exporting OF-specific gpiod_get_from_of_node() so that gpiolib can be cleaned a bit, so let's switch to the generic fwnode property API. Signed-off-by: Dmitry Torokhov diff --git a/drivers/usb/gadget/udc/at91_udc.c b/drivers/usb/gadget/udc/at91_udc.c index 728987280373..1db1dbbab79a 100644 --- a/drivers/usb/gadget/udc/at91_udc.c +++ b/drivers/usb/gadget/udc/at91_udc.c @@ -1779,12 +1779,14 @@ static void at91udc_of_init(struct at91_udc *udc, struct device_node *np) if (of_property_read_u32(np, "atmel,vbus-polled", ) == 0) board->vbus_polled = 1; - board->vbus_pin = gpiod_get_from_of_node(np, "atmel,vbus-gpio", 0, -GPIOD_IN, "udc_vbus"); + board->vbus_pin = fwnode_gpiod_get_index(of_fwnode_handle(np), +"atmel,vbus", 0, GPIOD_IN, +"udc_vbus"); if (IS_ERR(board->vbus_pin)) board->vbus_pin = NULL; - board->pullup_pin = gpiod_get_from_of_node(np, "atmel,pullup-gpio", 0, + board->pullup_pin = fwnode_gpiod_get_index(of_fwnode_handle(np), + "atmel,pullup", 0, GPIOD_ASIS, "udc_pullup"); if (IS_ERR(board->pullup_pin)) board->pullup_pin = NULL; -- b4 0.10.0-dev-fc921
[PATCH v1 04/11] usb: phy: tegra: switch to using devm_gpiod_get()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
device property API.
I believe that the only reason the driver, instead of the standard
devm_gpiod_get(), used devm_gpiod_get_from_of_node() is because it
wanted to set up a pretty consumer name for the GPIO, and we now have
a special API for that.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/usb/phy/phy-tegra-usb.c b/drivers/usb/phy/phy-tegra-usb.c
index 68cd4b68e3a2..f0240107edb1 100644
--- a/drivers/usb/phy/phy-tegra-usb.c
+++ b/drivers/usb/phy/phy-tegra-usb.c
@@ -1440,16 +1440,22 @@ static int tegra_usb_phy_probe(struct platform_device
*pdev)
return err;
}
- gpiod = devm_gpiod_get_from_of_node(>dev, np,
- "nvidia,phy-reset-gpio",
- 0, GPIOD_OUT_HIGH,
- "ulpi_phy_reset_b");
+ gpiod = devm_gpiod_get(>dev, "nvidia,phy-reset",
+ GPIOD_OUT_HIGH);
err = PTR_ERR_OR_ZERO(gpiod);
if (err) {
dev_err(>dev,
"Request failed for reset GPIO: %d\n", err);
return err;
}
+
+ err = gpiod_set_consumer_name(gpiod, "ulpi_phy_reset_b");
+ if (err) {
+ dev_err(>dev,
+ "Failed to set up reset GPIO name: %d\n", err);
+ return err;
+ }
+
tegra_phy->reset_gpio = gpiod;
phy = devm_otg_ulpi_create(>dev,
--
b4 0.10.0-dev-fc921
[PATCH v1 03/11] mtd: rawnand: stm32_fmc2: switch to using devm_fwnode_gpiod_get()
I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
index 87c1c7dd97eb..7e466b840368 100644
--- a/drivers/mtd/nand/raw/stm32_fmc2_nand.c
+++ b/drivers/mtd/nand/raw/stm32_fmc2_nand.c
@@ -1799,9 +1799,8 @@ static int stm32_fmc2_nfc_parse_child(struct
stm32_fmc2_nfc *nfc,
nand->cs_used[i] = cs;
}
- nand->wp_gpio = devm_gpiod_get_from_of_node(nfc->dev, dn,
- "wp-gpios", 0,
- GPIOD_OUT_HIGH, "wp");
+ nand->wp_gpio = devm_fwnode_gpiod_get(nfc->dev, of_fwnode_handle(dn),
+ "wp", GPIOD_OUT_HIGH, "wp");
if (IS_ERR(nand->wp_gpio)) {
ret = PTR_ERR(nand->wp_gpio);
if (ret != -ENOENT)
--
b4 0.10.0-dev-fc921
[PATCH v1 02/11] drm/tegra: switch to using devm_fwnode_gpiod_get
I would like to limit (or maybe even remove) use of
[devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned
a bit, so let's switch to the generic device property API. It may even
help with handling secondary fwnodes when gpiolib is taught to handle
gpios described by swnodes.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 47d26b5d9945..a8925dcd7edd 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -133,11 +133,11 @@ int tegra_output_probe(struct tegra_output *output)
}
}
- output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
- output->of_node,
- "nvidia,hpd-gpio", 0,
- GPIOD_IN,
- "HDMI hotplug detect");
+ output->hpd_gpio = devm_fwnode_gpiod_get(output->dev,
+ of_fwnode_handle(output->of_node),
+ "nvidia,hpd",
+ GPIOD_IN,
+ "HDMI hotplug detect");
if (IS_ERR(output->hpd_gpio)) {
if (PTR_ERR(output->hpd_gpio) != -ENOENT)
return PTR_ERR(output->hpd_gpio);
--
b4 0.10.0-dev-fc921
[PATCH v1 01/11] PCI: tegra: switch to using devm_fwnode_gpiod_get
I would like to limit (or maybe even remove) use of
[devm_]gpiod_get_from_of_node in drivers so that gpiolib can be cleaned
a bit, so let's switch to the generic device property API. It may even
help with handling secondary fwnodes when gpiolib is taught to handle
gpios described by swnodes.
Signed-off-by: Dmitry Torokhov
diff --git a/drivers/pci/controller/pci-tegra.c
b/drivers/pci/controller/pci-tegra.c
index 8e323e93be91..929f9363e94b 100644
--- a/drivers/pci/controller/pci-tegra.c
+++ b/drivers/pci/controller/pci-tegra.c
@@ -2202,10 +2202,11 @@ static int tegra_pcie_parse_dt(struct tegra_pcie *pcie)
* and in this case fall back to using AFI per port register
* to toggle PERST# SFIO line.
*/
- rp->reset_gpio = devm_gpiod_get_from_of_node(dev, port,
-"reset-gpios", 0,
-GPIOD_OUT_LOW,
-label);
+ rp->reset_gpio = devm_fwnode_gpiod_get(dev,
+ of_fwnode_handle(port),
+ "reset",
+ GPIOD_OUT_LOW,
+ label);
if (IS_ERR(rp->reset_gpio)) {
if (PTR_ERR(rp->reset_gpio) == -ENOENT) {
rp->reset_gpio = NULL;
--
b4 0.10.0-dev-fc921
[PATCH v1 00/11] Get rid of [devm_]gpiod_get_from_of_node() public APIs
I would like to stop exporting OF-specific [devm_]gpiod_get_from_of_node() so that gpiolib can be cleaned a bit. We can do that by switching drivers to use generic fwnode API ([devm_]fwnode_gpiod_get()). By doing so we open the door to augmenting device tree and ACPI information through secondary software properties (once we teach gpiolib how to handle those). I hope that relevant maintainers will take patches through their trees and then we could merge the last one some time after -rc1. Signed-off-by: Dmitry Torokhov --- Dmitry Torokhov (11): PCI: tegra: switch to using devm_fwnode_gpiod_get drm/tegra: switch to using devm_fwnode_gpiod_get mtd: rawnand: stm32_fmc2: switch to using devm_fwnode_gpiod_get() usb: phy: tegra: switch to using devm_gpiod_get() usb: gadget: udc: at91: switch to using fwnode_gpiod_get_index() PCI: aardvark: switch to using devm_gpiod_get_optional() PCI: apple: switch to using fwnode_gpiod_get_index() regulator: bd71815: switch to using devm_fwnode_gpiod_get() regulator: bd9576: switch to using devm_fwnode_gpiod_get() watchdog: bd9576_wdt: switch to using devm_fwnode_gpiod_get() gpiolib: of: remove [devm_]gpiod_get_from_of_node() APIs drivers/gpio/gpiolib-devres.c | 55 -- drivers/gpio/gpiolib-of.c | 1 - drivers/gpio/gpiolib-of.h | 13 drivers/gpu/drm/tegra/output.c | 10 +++ drivers/mtd/nand/raw/stm32_fmc2_nand.c | 5 ++-- drivers/pci/controller/pci-aardvark.c | 23 +++--- drivers/pci/controller/pci-tegra.c | 9 +++--- drivers/pci/controller/pcie-apple.c| 4 +-- drivers/regulator/bd71815-regulator.c | 7 ++--- drivers/regulator/bd9576-regulator.c | 17 ++- drivers/usb/gadget/udc/at91_udc.c | 8 +++-- drivers/usb/phy/phy-tegra-usb.c| 14 ++--- drivers/watchdog/bd9576_wdt.c | 51 ++- include/linux/gpio/consumer.h | 48 - 14 files changed, 96 insertions(+), 169 deletions(-) --- base-commit: 7fd22855300e693668c3397771b3a2b3948f827a change-id: 20220903-gpiod_get_from_of_node-remove-de3032fc01de Best regards, -- Dmitry
Re: [PATCH 15/41] input: omap: void using mach/*.h headers
On Tue, Apr 19, 2022 at 03:36:57PM +0200, Arnd Bergmann wrote: > From: Arnd Bergmann > > The omap-keypad driver currently relies on including mach/memory.h > implicitly, but that won't happen once omap1 is converted to > CONFIG_ARCH_MULTIPLATFORM. Include the required header > explicitly. > > Signed-off-by: Arnd Bergmann Acked-by: Dmitry Torokhov > --- > drivers/input/keyboard/omap-keypad.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/input/keyboard/omap-keypad.c > b/drivers/input/keyboard/omap-keypad.c > index eb3a687796e7..57447d6c9007 100644 > --- a/drivers/input/keyboard/omap-keypad.c > +++ b/drivers/input/keyboard/omap-keypad.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #undef NEW_BOARD_LEARNING_MODE > > -- > 2.29.2 > -- Dmitry
Re: [PATCH V3 6/13] input: serio: use time_is_before_jiffies() instead of open coding it
Hi Wang,
On Mon, Feb 14, 2022 at 05:55:43PM -0800, Qing Wang wrote:
> From: Wang Qing
>
> Use the helper function time_is_{before,after}_jiffies() to improve
> code readability.
I applied changes by Danilo Krummrich converting the driver to use
ktime_t (see
https://lore.kernel.org/r/20220215160208.34826-3-danilokrummr...@dk-develop.de)
which makes this change not applicable.
Thanks.
--
Dmitry
Re: [PATCH v4 2/3] platform/chrome: Add driver for ChromeOS privacy-screen
Hi Rajat,
On Tue, Dec 21, 2021 at 04:11:26PM -0800, Rajat Jain wrote:
> +static int chromeos_privacy_screen_remove(struct acpi_device *adev)
> +{
> + struct drm_privacy_screen *drm_privacy_screen = acpi_driver_data(adev);
Please add an empty line here:
WARNING: Missing a blank line after declarations
#292: FILE: drivers/platform/chrome/chromeos_privacy_screen.c:129:
+ struct drm_privacy_screen *drm_privacy_screen = acpi_driver_data(adev);
+ drm_privacy_screen_unregister(drm_privacy_screen);
> + drm_privacy_screen_unregister(drm_privacy_screen);
> + return 0;
> +}
> +
> +static const struct acpi_device_id chromeos_privacy_screen_device_ids[] = {
> + {"GOOG0010", 0}, /* Google's electronic privacy screen for eDP-1 */
> + {}
> +};
> +MODULE_DEVICE_TABLE(acpi, chromeos_privacy_screen_device_ids);
> +
> +static struct acpi_driver chromeos_privacy_screen_driver = {
> + .name = "chromeos_privacy_screen_drvr",
Could I buy 2 move vowels? ;)
> + .class = "ChromeOS",
> + .ids = chromeos_privacy_screen_device_ids,
> + .ops = {
> + .add = chromeos_privacy_screen_add,
> + .remove = chromeos_privacy_screen_remove,
> + },
> +};
> +
> +module_acpi_driver(chromeos_privacy_screen_driver);
> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("ChromeOS ACPI Privacy Screen driver");
> +MODULE_AUTHOR("Rajat Jain ");
Otherwise
Reviewed-by: Dmitry Torokhov
Thanks.
--
Dmitry
Re: [PATCH v2 1/2] platform/chrome: Add driver for ChromeOS privacy-screen
On Mon, Dec 20, 2021 at 12:21:47PM -0800, Rajat Jain wrote: > Hi Dmitry, > > Thanks for the review. Please see inline. > > On Mon, Dec 20, 2021 at 11:42 AM Dmitry Torokhov > wrote: > > > > Hi Rajat, > > > > On Fri, Dec 17, 2021 at 12:28:49PM -0800, Rajat Jain wrote: > > > This adds the ACPI driver for the ChromeOS privacy screen that is > > > present on some chromeos devices. > > > > > > Note that ideally, we'd want this privacy screen driver to be probed > > > BEFORE the drm probe in order to avoid a drm probe deferral: > > > https://hansdegoede.livejournal.com/25948.html > > > > > > In practise, I found that ACPI drivers are bound to their devices AFTER > > > the drm probe on chromebooks. So on chromebooks with privacy-screen, > > > this patch along with the next one in this series results in a probe > > > deferral of about 250ms for i915 driver. However, it did not result in > > > any user noticeable delay of splash screen in my personal experience. > > > > > > In future if this probe deferral turns out to be an issue, we can > > > consider turning this ACPI driver into something that is probed > > > earlier than the drm drivers. > > > > > > Signed-off-by: Rajat Jain > > > --- > > > v2: * Reword the commit log > > > * Make the Kconfig into a tristate > > > * Reorder the patches in the series. > > > > > > drivers/platform/chrome/Kconfig | 9 ++ > > > drivers/platform/chrome/Makefile | 1 + > > > drivers/platform/chrome/chromeos_priv_scrn.c | 132 +++ > > > 3 files changed, 142 insertions(+) > > > create mode 100644 drivers/platform/chrome/chromeos_priv_scrn.c > > > > > > diff --git a/drivers/platform/chrome/Kconfig > > > b/drivers/platform/chrome/Kconfig > > > index ccc23d8686e8..d1c209a45a62 100644 > > > --- a/drivers/platform/chrome/Kconfig > > > +++ b/drivers/platform/chrome/Kconfig > > > @@ -243,6 +243,15 @@ config CROS_USBPD_NOTIFY > > > To compile this driver as a module, choose M here: the > > > module will be called cros_usbpd_notify. > > > > > > +config CHROMEOS_PRIVACY_SCREEN > > > + tristate "ChromeOS Privacy Screen support" > > > + depends on ACPI > > > + depends on DRM > > > + select DRM_PRIVACY_SCREEN > > > + help > > > + This driver provides the support needed for the in-built > > > electronic > > > + privacy screen that is present on some ChromeOS devices. > > > + > > > source "drivers/platform/chrome/wilco_ec/Kconfig" > > > > > > endif # CHROMEOS_PLATFORMS > > > diff --git a/drivers/platform/chrome/Makefile > > > b/drivers/platform/chrome/Makefile > > > index f901d2e43166..cfa0bb4e9e34 100644 > > > --- a/drivers/platform/chrome/Makefile > > > +++ b/drivers/platform/chrome/Makefile > > > @@ -4,6 +4,7 @@ > > > CFLAGS_cros_ec_trace.o:= -I$(src) > > > > > > obj-$(CONFIG_CHROMEOS_LAPTOP)+= chromeos_laptop.o > > > +obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)+= chromeos_priv_scrn.o > > > obj-$(CONFIG_CHROMEOS_PSTORE)+= chromeos_pstore.o > > > obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o > > > obj-$(CONFIG_CROS_EC)+= cros_ec.o > > > diff --git a/drivers/platform/chrome/chromeos_priv_scrn.c > > > b/drivers/platform/chrome/chromeos_priv_scrn.c > > > new file mode 100644 > > > index ..a4cbf5c79c2a > > > --- /dev/null > > > +++ b/drivers/platform/chrome/chromeos_priv_scrn.c > > > > I think we can spare a few more characters :) chromeos_privacy_screen.c > > maybe? > > > > And also see if maybe variables in the code are not that unseemly long > > even if not abbreviated? > > Sure, I can certainly replace "chromeos_priv_scrn" with > "chromeos_privacy_screen" everywhere. Some of the variables may be a > little long, but I think that should be OK (my main concern was > > chromeos_privacy_screen_device_ids > chromeos_privacy_screen_get_hw_state() > > Let me know if that doesn't sound right (in which case, I can probably > omit "chromeos" from the local variable and function names) Another option to go all the way into different direction, and use "cps_" prefix for everything. It is probably just me but combinat
Re: [PATCH v2 2/2] drm/privacy_screen_x86: Add entry for ChromeOS privacy-screen
On Fri, Dec 17, 2021 at 12:28:50PM -0800, Rajat Jain wrote:
> Add a static entry in the x86 table, to detect and wait for
> privacy-screen on some ChromeOS platforms.
>
> Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
> enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
> shall return EPROBE_DEFER until a platform driver actually registers the
> privacy-screen: https://hansdegoede.livejournal.com/25948.html
>
> Signed-off-by: Rajat Jain
> ---
> v2: * Use #if instead of #elif
> * Reorder the patches in the series.
> * Rebased on drm-tip
>
> drivers/gpu/drm/drm_privacy_screen_x86.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c
> b/drivers/gpu/drm/drm_privacy_screen_x86.c
> index a2cafb294ca6..0c5699ad70a3 100644
> --- a/drivers/gpu/drm/drm_privacy_screen_x86.c
> +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c
> @@ -47,6 +47,18 @@ static bool __init detect_thinkpad_privacy_screen(void)
> }
> #endif
>
> +#if IS_ENABLED(CONFIG_CHROMEOS_PRIVACY_SCREEN)
> +static bool __init detect_chromeos_privacy_screen(void)
Does marking this __init work in case there is a deferral? Can it happen
that privacy screen is a module and so will get loaded only after we
discarded __init sections.
> +{
> + if (!acpi_dev_present("GOOG0010", NULL, -1))
> + return false;
> +
> + pr_info("%s: Need to wait for ChromeOS privacy-screen drvr", __func__);
I still do not see how this message is helpful. If it is really desired,
I'd put something into the code that calls into lookups.
> + return true;
> +
> +}
> +#endif
> +
> static const struct arch_init_data arch_init_data[] __initconst = {
> #if IS_ENABLED(CONFIG_THINKPAD_ACPI)
> {
> @@ -58,6 +70,16 @@ static const struct arch_init_data arch_init_data[]
> __initconst = {
> .detect = detect_thinkpad_privacy_screen,
> },
> #endif
> +#if IS_ENABLED(CONFIG_CHROMEOS_PRIVACY_SCREEN)
> + {
> + .lookup = {
> + .dev_id = NULL,
> + .con_id = NULL,
> + .provider = "privacy_screen-GOOG0010:00",
> + },
> + .detect = detect_chromeos_privacy_screen,
> + },
> +#endif
> };
>
> void __init drm_privacy_screen_lookup_init(void)
> --
> 2.34.1.307.g9b7440fafd-goog
>
Thanks.
--
Dmitry
Re: [PATCH v2 1/2] platform/chrome: Add driver for ChromeOS privacy-screen
Hi Rajat,
On Fri, Dec 17, 2021 at 12:28:49PM -0800, Rajat Jain wrote:
> This adds the ACPI driver for the ChromeOS privacy screen that is
> present on some chromeos devices.
>
> Note that ideally, we'd want this privacy screen driver to be probed
> BEFORE the drm probe in order to avoid a drm probe deferral:
> https://hansdegoede.livejournal.com/25948.html
>
> In practise, I found that ACPI drivers are bound to their devices AFTER
> the drm probe on chromebooks. So on chromebooks with privacy-screen,
> this patch along with the next one in this series results in a probe
> deferral of about 250ms for i915 driver. However, it did not result in
> any user noticeable delay of splash screen in my personal experience.
>
> In future if this probe deferral turns out to be an issue, we can
> consider turning this ACPI driver into something that is probed
> earlier than the drm drivers.
>
> Signed-off-by: Rajat Jain
> ---
> v2: * Reword the commit log
> * Make the Kconfig into a tristate
> * Reorder the patches in the series.
>
> drivers/platform/chrome/Kconfig | 9 ++
> drivers/platform/chrome/Makefile | 1 +
> drivers/platform/chrome/chromeos_priv_scrn.c | 132 +++
> 3 files changed, 142 insertions(+)
> create mode 100644 drivers/platform/chrome/chromeos_priv_scrn.c
>
> diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
> index ccc23d8686e8..d1c209a45a62 100644
> --- a/drivers/platform/chrome/Kconfig
> +++ b/drivers/platform/chrome/Kconfig
> @@ -243,6 +243,15 @@ config CROS_USBPD_NOTIFY
> To compile this driver as a module, choose M here: the
> module will be called cros_usbpd_notify.
>
> +config CHROMEOS_PRIVACY_SCREEN
> + tristate "ChromeOS Privacy Screen support"
> + depends on ACPI
> + depends on DRM
> + select DRM_PRIVACY_SCREEN
> + help
> + This driver provides the support needed for the in-built electronic
> + privacy screen that is present on some ChromeOS devices.
> +
> source "drivers/platform/chrome/wilco_ec/Kconfig"
>
> endif # CHROMEOS_PLATFORMS
> diff --git a/drivers/platform/chrome/Makefile
> b/drivers/platform/chrome/Makefile
> index f901d2e43166..cfa0bb4e9e34 100644
> --- a/drivers/platform/chrome/Makefile
> +++ b/drivers/platform/chrome/Makefile
> @@ -4,6 +4,7 @@
> CFLAGS_cros_ec_trace.o:= -I$(src)
>
> obj-$(CONFIG_CHROMEOS_LAPTOP)+= chromeos_laptop.o
> +obj-$(CONFIG_CHROMEOS_PRIVACY_SCREEN)+= chromeos_priv_scrn.o
> obj-$(CONFIG_CHROMEOS_PSTORE)+= chromeos_pstore.o
> obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o
> obj-$(CONFIG_CROS_EC)+= cros_ec.o
> diff --git a/drivers/platform/chrome/chromeos_priv_scrn.c
> b/drivers/platform/chrome/chromeos_priv_scrn.c
> new file mode 100644
> index ..a4cbf5c79c2a
> --- /dev/null
> +++ b/drivers/platform/chrome/chromeos_priv_scrn.c
I think we can spare a few more characters :) chromeos_privacy_screen.c
maybe?
And also see if maybe variables in the code are not that unseemly long
even if not abbreviated?
> @@ -0,0 +1,132 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * chromeos_priv_scrn.c - ChromeOS Privacy Screen support
I'd avoid mentioning file name as those tend to change.
> + *
> + * Copyright (C) 2022 The Chromium OS Authors
This is not correct copyright for kernel contributions. It should be
attributed to "Google LLC". Note that it is different from CrOS
userspace.
> + *
> + */
> +
> +#include
> +#include
> +
> +/*
> + * The DSM (Define Specific Method) constants below are the agreed API with
> + * the firmware team, on how to control privacy screen using ACPI methods.
> + */
> +#define PRIV_SCRN_DSM_REVID 1 /* DSM version */
> +#define PRIV_SCRN_DSM_FN_GET_STATUS 1 /* Get privacy screen status */
> +#define PRIV_SCRN_DSM_FN_ENABLE 2 /* Enable privacy
> screen */
> +#define PRIV_SCRN_DSM_FN_DISABLE 3 /* Disable privacy screen */
> +
> +static const guid_t chromeos_priv_scrn_dsm_guid =
> + GUID_INIT(0xc7033113, 0x8720, 0x4ceb,
> + 0x90, 0x90, 0x9d, 0x52, 0xb3, 0xe5, 0x2d, 0x73);
> +
> +static void
> +chromeos_priv_scrn_get_hw_state(struct drm_privacy_screen *drm_priv_scrn)
> +{
> + union acpi_object *obj;
> + acpi_handle handle;
> + struct device *priv_scrn = drm_priv_scrn->dev.parent;
This is really bad that we need to poke into internals of
drm_privacy_screen to get to "our" device. I think there is only one
consume of the privacy screen API at the moment, the thinkpad driver, so
maybe it is not too late to change drm_privacy_screen_register() to
either accept instance of struct drm_privacy_screen (which then could be
embedded into something) or accept a void pointer to attach arbitrary
data to it, and then add drm_privacy_screen_get_drvdata() to get to that
pointer.
> +
> +
Re: [PATCH v2 2/2] drm/privacy_screen_x86: Add entry for ChromeOS privacy-screen
On Mon, Dec 20, 2021 at 12:29:18PM -0800, Rajat Jain wrote: > Hello, > > On Mon, Dec 20, 2021 at 11:50 AM Dmitry Torokhov > wrote: > > > > On Fri, Dec 17, 2021 at 12:28:50PM -0800, Rajat Jain wrote: > > > Add a static entry in the x86 table, to detect and wait for > > > privacy-screen on some ChromeOS platforms. > > > > > > Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is > > > enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe > > > shall return EPROBE_DEFER until a platform driver actually registers the > > > privacy-screen: https://hansdegoede.livejournal.com/25948.html > > > > > > Signed-off-by: Rajat Jain > > > --- > > > v2: * Use #if instead of #elif > > > * Reorder the patches in the series. > > > * Rebased on drm-tip > > > > > > drivers/gpu/drm/drm_privacy_screen_x86.c | 22 ++ > > > 1 file changed, 22 insertions(+) > > > > > > diff --git a/drivers/gpu/drm/drm_privacy_screen_x86.c > > > b/drivers/gpu/drm/drm_privacy_screen_x86.c > > > index a2cafb294ca6..0c5699ad70a3 100644 > > > --- a/drivers/gpu/drm/drm_privacy_screen_x86.c > > > +++ b/drivers/gpu/drm/drm_privacy_screen_x86.c > > > @@ -47,6 +47,18 @@ static bool __init detect_thinkpad_privacy_screen(void) > > > } > > > #endif > > > > > > +#if IS_ENABLED(CONFIG_CHROMEOS_PRIVACY_SCREEN) > > > +static bool __init detect_chromeos_privacy_screen(void) > > > > Does marking this __init work in case there is a deferral? > > Yes, I have verified that for Chromeos case, it is a deferral. > > > Can it happen > > that privacy screen is a module and so will get loaded only after we > > discarded __init sections. > > Perhaps. But I do not think that is a problem. All the functions and > data in this file are in __init sections, and this entry is here to > ensure that the drm probe will wait for the privacy screen driver > (whenever it is loaded). Ah, OK, we are not leaking detect() pointers outside this module. > That is the reason, ideally we would want to > somehow restrict the privacy screen to be built into the kernel so as > to minimize the delay if any. I understand, but we can not code to the config we expect to use on Chrome OS, we need to make sure we cover all possibilities. Thanks. -- Dmitry
Re: [PATCH] dt-bindings: Add missing array size constraints
On Mon, Jan 04, 2021 at 04:02:53PM -0700, Rob Herring wrote: > .../input/touchscreen/elan,elants_i2c.yaml| 1 + Acked-by: Dmitry Torokhov -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ARM: locomo: make locomo bus's remove callback return void
On Thu, Nov 26, 2020 at 12:01:40PM +0100, Uwe Kleine-König wrote: > The driver core ignores the return value of struct bus_type::remove > because there is only little that can be done. To simplify the quest to > make this function return void, let struct locomo_driver::remove return > void, too. All users already unconditionally return 0, this commit makes > it obvious that returning an error code is a bad idea and ensures future > users behave accordingly. > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > if desired the change to arch/arm/mach-sa1100/collie.c can be split out > of this patch. The change of prototype then doesn't affect this driver > any more. There is one locomo-driver that is already now unaffected: > drivers/leds/leds-locomo.c. This driver doesn't have a remove callback. > > Best regards > Uwe > > arch/arm/common/locomo.c | 5 ++--- > arch/arm/include/asm/hardware/locomo.h | 2 +- > arch/arm/mach-sa1100/collie.c | 6 ------ > drivers/input/keyboard/locomokbd.c | 4 +--- Acked-by: Dmitry Torokhov > drivers/video/backlight/locomolcd.c| 3 +-- > 5 files changed, 5 insertions(+), 15 deletions(-) Thanks. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] dt-bindings: Add missing 'unevaluatedProperties'
On Mon, Oct 05, 2020 at 01:38:27PM -0500, Rob Herring wrote: > This doesn't yet do anything in the tools, but make it explicit so we can > check either 'unevaluatedProperties' or 'additionalProperties' is present > in schemas. > > 'unevaluatedProperties' is appropriate when including another schema (via > '$ref') and all possible properties and/or child nodes are not > explicitly listed in the schema with the '$ref'. > > This is in preparation to add a meta-schema to check for missing > 'unevaluatedProperties' or 'additionalProperties'. This has been a > constant source of review issues. > > Signed-off-by: Rob Herring For input: Acked-by: Dmitry Torokhov -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/4] dt-bindings: Explicitly allow additional properties in common schemas
On Mon, Oct 05, 2020 at 01:38:30PM -0500, Rob Herring wrote: > In order to add meta-schema checks for additional/unevaluatedProperties > being present, all schema need to make this explicit. As common/shared > schema are included by other schemas, they should always allow for > additionalProperties. > > Signed-off-by: Rob Herring For input: Acked-by: Dmitry Torokhov -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] driver core: add probe error check helper
On Thu, Jul 30, 2020 at 11:16 AM Mark Brown wrote: > > On Thu, Jul 30, 2020 at 10:46:31AM -0700, Dmitry Torokhov wrote: > > On Thu, Jul 30, 2020 at 9:49 AM Mark Brown wrote: > > > > The error messages are frequently in the caller rather than the > > > frameworks, it's often helpful for the comprehensibility of the error > > > messages especially in cases where things may be legitimately absent. > > > Not for deferral. All you need to know in this case is: > > > "device A is attempting to request resource B which is not ready yet" > > > There is nothing to handle on the caller part except to float the error up. > > You can sometimes do a better job of explaining what the resource you > were looking for was, I think it is true for very esoteric cases. I.e. your driver uses 2 interrupt lines, or something like that. For GPIO, regulators, and clocks we normally have a name/connection ID that provides enough of context. We need to remember, the error messages really only make total sense to a person familiar with the driver to begin with, not for a random person looking at the log. > and of course you still need diagnostics in the > non-deferral case. Whatever happens we'll need a lot of per-driver > churn, either removing existing diagnostics that get factored into cores > or updating to use this new API. The point is if you push it into core you'll get the benefit of notifying about the deferral (and can "attach" deferral reason to a device) without changing drivers at all. You can clean them up later if you want, or decide that additional logging in error paths does not hurt. This new API does not do you any good unless you convert drivers, and you need to convert the majority of them to be able to rely on the deferral diagnostic that is being added. Thanks. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] driver core: add probe error check helper
On Thu, Jul 30, 2020 at 12:10 AM Greg Kroah-Hartman wrote: > > On Tue, Jul 28, 2020 at 05:05:03PM +0200, Andrzej Hajda wrote: > > Hi Greg, > > > > Apparently the patchset has no more comments. > > > > Could you take the patches to your tree? At least 1st and 2nd. > > All now queued up, thanks! I believe it still has not been answered why this can't be pushed into resource providers (clock, regulators, gpio, interrupts, etc), especially for devm APIs where we know exactly what device we are requesting a resource for, so that individual drivers do not need to change anything. We can mark the device as being probed so that probe deferral is only handled when we actually execute probe() (and for the bonus points scream loudly if someone tries to return -EPROBE_DEFER outside of probe path). And now with coccinelle script we can expect a deluge of patches reshuffling drivers... Thanks. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9 0/4] driver core: add probe error check helper
On Thu, Jul 30, 2020 at 9:49 AM Mark Brown wrote: > > On Thu, Jul 30, 2020 at 09:18:30AM -0700, Dmitry Torokhov wrote: > > > I believe it still has not been answered why this can't be pushed into > > resource providers (clock, regulators, gpio, interrupts, etc), > > especially for devm APIs where we know exactly what device we are > > requesting a resource for, so that individual drivers do not need to > > change anything. > > The error messages are frequently in the caller rather than the > frameworks, it's often helpful for the comprehensibility of the error > messages especially in cases where things may be legitimately absent. Not for deferral. All you need to know in this case is: "device A is attempting to request resource B which is not ready yet" There is nothing to handle on the caller part except to float the error up. > > > We can mark the device as being probed so that probe > > deferral is only handled when we actually execute probe() (and for the > > bonus points scream loudly if someone tries to return -EPROBE_DEFER > > outside of probe path). > > Is this a big issue? We do not know ;) Probably not. It will just get reported as an ordinary failure and the driver will handle it somehow. Still it would be nice to know if we attempt to raise deferrals in code paths where they do not make sense. Thanks. -- Dmitry ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property
On Thu, Jul 02, 2020 at 08:57:55AM +0200, Andrzej Hajda wrote:
>
> On 30.06.2020 20:00, Dmitry Torokhov wrote:
> > On Tue, Jun 30, 2020 at 8:42 AM Andrzej Hajda wrote:
> >>
> >> On 30.06.2020 10:59, Grygorii Strashko wrote:
> >>> Hi
> >>>
> >>> On 29/06/2020 14:28, Andrzej Hajda wrote:
> >>>> Hi Grygorii,
> >>>>
> >>>> (...)
> >>>>
> >>>>>> /*
> >>>>>> * deferred_devs_show() - Show the devices in the deferred probe
> >>>>>> pending list.
> >>>>>> */
> >>>>>> @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
> >>>>>> void *data)
> >>>>>> mutex_lock(_probe_mutex);
> >>>>>> list_for_each_entry(curr, _probe_pending_list,
> >>>>>> deferred_probe)
> >>>>>> -seq_printf(s, "%s\n", dev_name(curr->device));
> >>>>>> +seq_printf(s, "%s\t%s", dev_name(curr->device),
> >>>>>> + curr->device->p->deferred_probe_reason ?: "\n");
> >>>>>> mutex_unlock(_probe_mutex);
> >>>>>>
> >>>>> Sry, may be i missing smth, but shouldn't it be optional
> >>>>> (CONFIG_DEBUG_FS is probably too generic).
> >>>>>
> >>>> I am not sure what exactly are you referring to, but this patch does not
> >>>> add new property, it just extends functionality of existing one.
> >>> Sry, needed to be more specific.
> >>>
> >>> You've added device_set_deferred_probe_reson(dev, );
> >>> which expected to be used on every EPROBE_DEFER in dev_err_probe() in
> >>> combination with
> >>>
> >>> + } else {
> >>> + device_set_deferred_probe_reson(dev, );
> >>> dev_dbg(dev, "error %d: %pV", err, );
> >>>
> >>> ^^ dev_dbg() does not add any runtime overhead during boot unless enabled
> >>> + }
> >>>
> >>> But:
> >>>
> >>> +void device_set_deferred_probe_reson(const struct device *dev, struct
> >>> va_format *vaf)
> >>> +{
> >>> + const char *drv = dev_driver_string(dev);
> >>> +
> >>> + mutex_lock(_probe_mutex);
> >>> +
> >>> + kfree(dev->p->deferred_probe_reason);
> >>> + dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s:
> >>> %pV", drv, vaf);
> >>> +
> >>> + mutex_unlock(_probe_mutex);
> >>> +}
> >>>
> >>> ^^ Adds locking, kfree() and kasprintf() for every deferred probe
> >>> during boot and can't be disabled.
> >>>
> >>> Right?
> >>
> >> Right, but usually the burden should be insignificant in comparison to
> >> probe time, so I do not think it is worth optimizing.
> > I do not think this is going to take. You are suggesting that we
> > modify pretty much every driver to supply this deferral reason, and I
> > doubt it will happen. Can we put this burden on providers that raise
> > the deferral?
>
>
> I wouldn't say they raise the deferral, they just inform resource is not
> yet available. Only device driver, and only in its probe function can
> "raise the deferral".
Well, this is a matter of perspective. If devm_gpiod_get() returns
-EBUSY and this is returned to driver core, is it GPIO line signals that
line is busy, or is it the driver applies its knowledge. I say that in
majority of cases driver does not really get a say in this and simply
has to pass whatever error condition that is signalled by providers up
the stack.
I would consider whenever a driver does not propagate -EPROBE_DEFER to
the driver code a bug that needs fixing, because it should not degrade
functionality and/or performance just because we have not figured out
how to order probing properly and have to rely on deferrals.
>
>
> > I.e. majority of code are using devm API now, so we most
> > likely know the device for which deferral is being raised. We can have
> > a list of deferral reasons and their devices and when in device code
> > once probe is done we could try reconciling it with the deferred
> > devicelist, and this would mean you only need to implement this in
> > gpiolib, regulator core, clocks core, etc.
>
>
> This patchset tri
Re: [PATCH v6 2/4] driver core: add deferring probe reason to devices_deferred property
On Tue, Jun 30, 2020 at 8:42 AM Andrzej Hajda wrote:
>
>
> On 30.06.2020 10:59, Grygorii Strashko wrote:
> > Hi
> >
> > On 29/06/2020 14:28, Andrzej Hajda wrote:
> >> Hi Grygorii,
> >>
> >> (...)
> >>
> /*
> * deferred_devs_show() - Show the devices in the deferred probe
> pending list.
> */
> @@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s,
> void *data)
> mutex_lock(_probe_mutex);
> list_for_each_entry(curr, _probe_pending_list,
> deferred_probe)
> -seq_printf(s, "%s\n", dev_name(curr->device));
> +seq_printf(s, "%s\t%s", dev_name(curr->device),
> + curr->device->p->deferred_probe_reason ?: "\n");
> mutex_unlock(_probe_mutex);
>
> >>>
> >>> Sry, may be i missing smth, but shouldn't it be optional
> >>> (CONFIG_DEBUG_FS is probably too generic).
> >>>
> >>
> >> I am not sure what exactly are you referring to, but this patch does not
> >> add new property, it just extends functionality of existing one.
> >
> > Sry, needed to be more specific.
> >
> > You've added device_set_deferred_probe_reson(dev, );
> > which expected to be used on every EPROBE_DEFER in dev_err_probe() in
> > combination with
> >
> > + } else {
> > + device_set_deferred_probe_reson(dev, );
> > dev_dbg(dev, "error %d: %pV", err, );
> >
> > ^^ dev_dbg() does not add any runtime overhead during boot unless enabled
> > + }
> >
> > But:
> >
> > +void device_set_deferred_probe_reson(const struct device *dev, struct
> > va_format *vaf)
> > +{
> > + const char *drv = dev_driver_string(dev);
> > +
> > + mutex_lock(_probe_mutex);
> > +
> > + kfree(dev->p->deferred_probe_reason);
> > + dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s:
> > %pV", drv, vaf);
> > +
> > + mutex_unlock(_probe_mutex);
> > +}
> >
> > ^^ Adds locking, kfree() and kasprintf() for every deferred probe
> > during boot and can't be disabled.
> >
> > Right?
>
>
> Right, but usually the burden should be insignificant in comparison to
> probe time, so I do not think it is worth optimizing.
I do not think this is going to take. You are suggesting that we
modify pretty much every driver to supply this deferral reason, and I
doubt it will happen. Can we put this burden on providers that raise
the deferral? I.e. majority of code are using devm API now, so we most
likely know the device for which deferral is being raised. We can have
a list of deferral reasons and their devices and when in device code
once probe is done we could try reconciling it with the deferred
devicelist, and this would mean you only need to implement this in
gpiolib, regulator core, clocks core, etc.
Thanks.
--
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
On Mon, Oct 14, 2019 at 11:43:20AM -0700, Dmitry Torokhov wrote:
> Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
> the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but
> works with arbitrary firmware node.
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Dmitry Torokhov
> ---
>
> Andrzej, Neil,
>
> This depends on the new code that can be bound in
> ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree:
>
> git pull
> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
> ib-fwnode-gpiod-get-index
>
> I hope that it would be possible to pull in this immutable branch and
> not wait until after 5.5 merge window, or, alternatively, merge through
> Linus Walleij's tree.
Any chance this could be merged, please?
>
> Thanks!
>
> drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
> b/drivers/gpu/drm/bridge/ti-tfp410.c
> index aa3198dc9903..6f6d6d1e60ae 100644
> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
> @@ -285,8 +285,8 @@ static int tfp410_get_connector_properties(struct tfp410
> *dvi)
> else
> dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
>
> - dvi->hpd = fwnode_get_named_gpiod(_node->fwnode,
> - "hpd-gpios", 0, GPIOD_IN, "hpd");
> + dvi->hpd = fwnode_gpiod_get_index(_node->fwnode,
> + "hpd", 0, GPIOD_IN, "hpd");
> if (IS_ERR(dvi->hpd)) {
> ret = PTR_ERR(dvi->hpd);
> dvi->hpd = NULL;
> --
> 2.23.0.700.g56cf767bdb-goog
>
>
> --
> Dmitry
--
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/46] ARM: pxa: split up mach/hardware.h
On Fri, Oct 18, 2019 at 05:41:20PM +0200, Arnd Bergmann wrote: > The mach/hardware.h is included in lots of places, and it provides > three different things on pxa: > > - the cpu_is_pxa* macros > - an indirect inclusion of mach/addr-map.h > - the __REG() and io_pv2() helper macros > > Split it up into separate and mach/pxa-regs.h > headers, then change all the files that use mach/hardware.h to > include the exact set of those three headers that they actually > need, allowing for further more targeted cleanup. > > linux/soc/pxa/cpu.h can remain permanently exported and is now in > a global location along with similar headers. pxa-regs.h and > addr-map.h are only used in a very small number of drivers now > and can be moved to arch/arm/mach-pxa/ directly when those drivers > are to pass the necessary data as resources. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Viresh Kumar > Cc: Dmitry Torokhov > Cc: Jacek Anaszewski > Cc: Pavel Machek > Cc: Ulf Hansson > Cc: Dominik Brodowski > Cc: Alexandre Belloni > Cc: Greg Kroah-Hartman > Cc: Guenter Roeck > Cc: Mark Brown > Cc: linux-...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-in...@vger.kernel.org > Cc: linux-l...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@lists.infradead.org > Cc: linux-...@vger.kernel.org > Cc: linux-...@vger.kernel.org > Cc: dri-devel@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Cc: linux-watch...@vger.kernel.org > Cc: alsa-de...@alsa-project.org > Signed-off-by: Arnd Bergmann For input bits: Acked-by: Dmitry Torokhov -- Dmitry
[PATCH] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), but
works with arbitrary firmware node.
Reviewed-by: Laurent Pinchart
Signed-off-by: Dmitry Torokhov
---
Andrzej, Neil,
This depends on the new code that can be bound in
ib-fwnode-gpiod-get-index immutable branch of Linus' Walleij tree:
git pull
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git
ib-fwnode-gpiod-get-index
I hope that it would be possible to pull in this immutable branch and
not wait until after 5.5 merge window, or, alternatively, merge through
Linus Walleij's tree.
Thanks!
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index aa3198dc9903..6f6d6d1e60ae 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -285,8 +285,8 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
else
dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
- dvi->hpd = fwnode_get_named_gpiod(_node->fwnode,
- "hpd-gpios", 0, GPIOD_IN, "hpd");
+ dvi->hpd = fwnode_gpiod_get_index(_node->fwnode,
+ "hpd", 0, GPIOD_IN, "hpd");
if (IS_ERR(dvi->hpd)) {
ret = PTR_ERR(dvi->hpd);
dvi->hpd = NULL;
--
2.23.0.700.g56cf767bdb-goog
--
Dmitry
Re: [PATCH 00/11] Add support for software nodes to gpiolib
Hi Linus, On Mon, Sep 16, 2019 at 05:22:07PM -0700, Dmitry Torokhov wrote: > On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote: > > On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov > > wrote: > > > > > If we agree in principle, I would like to have the very first 3 patches > > > in an immutable branch off maybe -rc8 so that it can be pulled into > > > individual subsystems so that patches switching various drivers to > > > fwnode_gpiod_get_index() could be applied. > > > > I think it seems a bit enthusiastic to have non-GPIO subsystems > > pick up these changes this close to the merge window so my plan > > is to merge patches 1.2.3 (1 already merged) and then you could > > massage the other subsystems in v5.4-rc1. > > > > But if other subsystems say "hey we want do fix this in like 3 days" > > then I'm game for an immutable branch as well. > > No, if it is still has a chance for -rc1 then I'm good. I was thinking > if it does not go into -rc1 I could convince some of them merge a > targeted immutable branch off -rc8 or 5.3 final and then apply patches > relevant to their subsystems so we do not have to wait till 5.6 to land > everything. So I guess we missed -rc1. Any chance we could get an immutable branch off -rc1 that you will pull into your main branch and I hopefully can persuade other maintainers to pull as well so we do not need to drag it over 2+ merge windows? Thanks. -- Dmitry
Re: [PATCH 00/11] Add support for software nodes to gpiolib
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote: > On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov > wrote: > > > If we agree in principle, I would like to have the very first 3 patches > > in an immutable branch off maybe -rc8 so that it can be pulled into > > individual subsystems so that patches switching various drivers to > > fwnode_gpiod_get_index() could be applied. > > I think it seems a bit enthusiastic to have non-GPIO subsystems > pick up these changes this close to the merge window so my plan > is to merge patches 1.2.3 (1 already merged) and then you could > massage the other subsystems in v5.4-rc1. > > But if other subsystems say "hey we want do fix this in like 3 days" > then I'm game for an immutable branch as well. No, if it is still has a chance for -rc1 then I'm good. I was thinking if it does not go into -rc1 I could convince some of them merge a targeted immutable branch off -rc8 or 5.3 final and then apply patches relevant to their subsystems so we do not have to wait till 5.6 to land everything. Thanks. -- Dmitry
Re: [PATCH] drm/tegra: switch to using devm_gpiod_get_optional
On Mon, Sep 16, 2019 at 03:59:04PM +0200, Thierry Reding wrote: > On Sun, Sep 15, 2019 at 12:13:23AM -0700, Dmitry Torokhov wrote: > > We do not really need to use API that fetches GPIO data from an > > arbitrary device tree node, as we are dealing with device tree node > > assigned to the device structure. We can easily switch to > > devm_gpiod_get_optional() plus gpiod_set_consumer_name() and clean up > > the code. > > > > Note this is part of efforts to get rid of [devm_]gpiod_get_from_of_node > > in drivers so that gpiolib can be cleaned up. > > > > Signed-off-by: Dmitry Torokhov > > --- > > drivers/gpu/drm/tegra/output.c | 18 +++--- > > 1 file changed, 7 insertions(+), 11 deletions(-) > > We can't do that. There's a special case in rgb.c that sets > output->of_node to something different than output->dev, so we actually > need to pass the struct device_node * separately. Ugh, brainfart on my part. I totally read it is output->dev.of_node, similar to another driver I was looking at... Please discard, there will be another patch changing devm_gpiod_get_from_of_node() to devm_fwnode_gpiod_get() once Linus merges this new GPIO method. Thanks. -- Dmitry
[PATCH] drm/tegra: switch to using devm_gpiod_get_optional
We do not really need to use API that fetches GPIO data from an
arbitrary device tree node, as we are dealing with device tree node
assigned to the device structure. We can easily switch to
devm_gpiod_get_optional() plus gpiod_set_consumer_name() and clean up
the code.
Note this is part of efforts to get rid of [devm_]gpiod_get_from_of_node
in drivers so that gpiolib can be cleaned up.
Signed-off-by: Dmitry Torokhov
---
drivers/gpu/drm/tegra/output.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index bdcaa4c7168c..b4248125b844 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -121,19 +121,15 @@ int tegra_output_probe(struct tegra_output *output)
of_node_put(ddc);
}
- output->hpd_gpio = devm_gpiod_get_from_of_node(output->dev,
- output->of_node,
- "nvidia,hpd-gpio", 0,
- GPIOD_IN,
- "HDMI hotplug detect");
- if (IS_ERR(output->hpd_gpio)) {
- if (PTR_ERR(output->hpd_gpio) != -ENOENT)
- return PTR_ERR(output->hpd_gpio);
-
- output->hpd_gpio = NULL;
- }
+ output->hpd_gpio = devm_gpiod_get_optional(output->dev,
+ "nvidia,hpd", GPIOD_IN);
+ if (IS_ERR(output->hpd_gpio))
+ return PTR_ERR(output->hpd_gpio);
if (output->hpd_gpio) {
+ gpiod_set_consumer_name(output->hpd_gpio,
+ "HDMI hotplug detect");
+
err = gpiod_to_irq(output->hpd_gpio);
if (err < 0) {
dev_err(output->dev, "gpiod_to_irq(): %d\n", err);
--
2.23.0.237.gc6a4ce50a0-goog
--
Dmitry
[PATCH 06/11] drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
Instead of fwnode_get_named_gpiod() that I plan to hide away, let's use
the new fwnode_gpiod_get_index() that mimics gpiod_get_index(), bit
works with arbitrary firmware node.
Signed-off-by: Dmitry Torokhov
---
drivers/gpu/drm/bridge/ti-tfp410.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
b/drivers/gpu/drm/bridge/ti-tfp410.c
index 61cc2354ef1b..d9c9c9ebad2b 100644
--- a/drivers/gpu/drm/bridge/ti-tfp410.c
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -284,8 +284,8 @@ static int tfp410_get_connector_properties(struct tfp410
*dvi)
else
dvi->connector_type = DRM_MODE_CONNECTOR_DVID;
- dvi->hpd = fwnode_get_named_gpiod(_node->fwnode,
- "hpd-gpios", 0, GPIOD_IN, "hpd");
+ dvi->hpd = fwnode_gpiod_get_index(_node->fwnode,
+ "hpd", 0, GPIOD_IN, "hpd");
if (IS_ERR(dvi->hpd)) {
ret = PTR_ERR(dvi->hpd);
dvi->hpd = NULL;
--
2.23.0.162.g0b9fbb3734-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] Add support for software nodes to gpiolib
This series attempts to add support for software nodes to gpiolib, using
software node references that were introduced recently. This allows us
to convert more drivers to the generic device properties and drop
support for custom platform data:
static const struct software_node gpio_bank_b_node = {
|---.name = "B",
};
static const struct property_entry simone_key_enter_props[] = {
|---PROPERTY_ENTRY_U32("linux,code", KEY_ENTER),
|---PROPERTY_ENTRY_STRING("label", "enter"),
|---PROPERTY_ENTRY_REF("gpios", _bank_b_node, 123, GPIO_ACTIVE_LOW),
|---{ }
};
If we agree in principle, I would like to have the very first 3 patches
in an immutable branch off maybe -rc8 so that it can be pulled into
individual subsystems so that patches switching various drivers to
fwnode_gpiod_get_index() could be applied.
Thanks,
Dmitry
Dmitry Torokhov (11):
gpiolib: of: add a fallback for wlf,reset GPIO name
gpiolib: introduce devm_fwnode_gpiod_get_index()
gpiolib: introduce fwnode_gpiod_get_index()
net: phylink: switch to using fwnode_gpiod_get_index()
net: mdio: switch to using fwnode_gpiod_get_index()
drm/bridge: ti-tfp410: switch to using fwnode_gpiod_get_index()
gpliolib: make fwnode_get_named_gpiod() static
gpiolib: of: tease apart of_find_gpio()
gpiolib: of: tease apart acpi_find_gpio()
gpiolib: consolidate fwnode GPIO lookups
gpiolib: add support for software nodes
drivers/gpio/Makefile | 1 +
drivers/gpio/gpiolib-acpi.c| 153 ++--
drivers/gpio/gpiolib-acpi.h| 21 ++--
drivers/gpio/gpiolib-devres.c | 33 ++
drivers/gpio/gpiolib-of.c | 159 ++---
drivers/gpio/gpiolib-of.h | 26 ++--
drivers/gpio/gpiolib-swnode.c | 92 +++
drivers/gpio/gpiolib-swnode.h | 13 ++
drivers/gpio/gpiolib.c | 184 -
drivers/gpu/drm/bridge/ti-tfp410.c | 4 +-
drivers/net/phy/mdio_bus.c | 4 +-
drivers/net/phy/phylink.c | 4 +-
include/linux/gpio/consumer.h | 53 ++---
13 files changed, 471 insertions(+), 276 deletions(-)
create mode 100644 drivers/gpio/gpiolib-swnode.c
create mode 100644 drivers/gpio/gpiolib-swnode.h
--
2.23.0.162.g0b9fbb3734-goog
Re: [PATCH v2 03/10] input: keyboard: gpio_keys: convert platform driver to use dev_groups
On Wed, Jul 31, 2019 at 02:43:42PM +0200, Greg Kroah-Hartman wrote:
> Platform drivers now have the option to have the platform core create
> and remove any needed sysfs attribute files. So take advantage of that
> and do not register "by hand" a bunch of sysfs files.
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Greg Kroah-Hartman
Applied, thank you.
> ---
> drivers/input/keyboard/gpio_keys.c | 13 ++---
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c
> b/drivers/input/keyboard/gpio_keys.c
> index 03f4d152f6b7..1373dc5b0765 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -351,10 +351,7 @@ static struct attribute *gpio_keys_attrs[] = {
> _attr_disabled_switches.attr,
> NULL,
> };
> -
> -static const struct attribute_group gpio_keys_attr_group = {
> - .attrs = gpio_keys_attrs,
> -};
> +ATTRIBUTE_GROUPS(gpio_keys);
>
> static void gpio_keys_gpio_report_event(struct gpio_button_data *bdata)
> {
> @@ -851,13 +848,6 @@ static int gpio_keys_probe(struct platform_device *pdev)
>
> fwnode_handle_put(child);
>
> - error = devm_device_add_group(dev, _keys_attr_group);
> - if (error) {
> - dev_err(dev, "Unable to export keys/switches, error: %d\n",
> - error);
> - return error;
> - }
> -
> error = input_register_device(input);
> if (error) {
> dev_err(dev, "Unable to register input device, error: %d\n",
> @@ -1026,6 +1016,7 @@ static struct platform_driver gpio_keys_device_driver =
> {
> .name = "gpio-keys",
> .pm = _keys_pm_ops,
> .of_match_table = gpio_keys_of_match,
> + .dev_groups = gpio_keys_groups,
> }
> };
>
> --
> 2.22.0
>
--
Dmitry
