From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: alsa-devel@alsa-project.org, tiwai@suse.de, broonie@kernel.org, Daniel Matuschek <daniel@hifiberry.com>, Matthias Reichl <hias@horus.com>, Hui Wang <hui.wang@canonical.com>, linux-gpio@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>, Bartosz Golaszewski <bgolaszewski@baylibre.com>, linux-clk@vger.kernel.org, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org> Subject: Re: [RFC PATCH 01/16] ASoC: pcm512x: expose 6 GPIOs Date: Tue, 14 Apr 2020 20:09:34 +0300 [thread overview] Message-ID: <20200414170934.GA34613@smile.fi.intel.com> (raw) In-Reply-To: <20200409195841.18901-2-pierre-louis.bossart@linux.intel.com> On Thu, Apr 09, 2020 at 02:58:26PM -0500, Pierre-Louis Bossart wrote: > The GPIOs are used e.g. on HifiBerry DAC+ HATs to control the LED > (GPIO3) and the choice of the 44.1 (GPIO6) or 48 (GPIO3) kHz > oscillator (when present). > > Enable basic gpio_chip to get/set values and get/set > directions. Tested with GPIO_LIB from sys/class/gpio, the LED turns > on/off as desired. One question, can this use existing GPIO infrastructure, like bgpio_init()? Ah, I see, that one operates over MMIO, while we would need something based on regmap API. Bartosz, do we have plans to have bgpio_regmap_init() or alike? ... > +static int pcm512x_gpio_get_direction(struct gpio_chip *chip, > + unsigned int offset) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + unsigned int val; > + int ret; > + > + ret = regmap_read(pcm512x->regmap, PCM512x_GPIO_EN, &val); > + if (ret < 0) > + return ret; > + val = (val >> offset) & 1; > + > + /* val is 0 for input, 1 for output, return inverted */ > + return val ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; This better to read as simple conditional, like if (val & BIT(offset)) return ..._OUT; return ..._IN; > +} ... > +static int pcm512x_gpio_direction_output(struct gpio_chip *chip, > + unsigned int offset, > + int value) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + unsigned int reg; > + int ret; > + > + /* select Register GPIOx output for OUTPUT_x (1..6) */ > + reg = PCM512x_GPIO_OUTPUT_1 + offset; > + ret = regmap_update_bits(pcm512x->regmap, reg, 0x0f, 0x02); Magic numbers detected. > + if (ret < 0) Drop unnecessary ' < 0' parts where it makes sense, like here. > + return ret; > + > + /* enable output x */ (1) > + ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN, > + BIT(offset), BIT(offset)); > + if (ret < 0) > + return ret; > + > + /* set value */ (2) With this (1)->(2) ordering it may be a glitch. So, first set value (if hardware allows you, otherwise it seems like a broken one), and then switch it to output. > + return regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_CONTROL_1, > + BIT(offset), value << offset); You are using many times BIT(offset) mask above, perhaps int mask = BIT(offset); Also, more robust is to use ternary here: 'value ? BIT(offset) : 0'. Rationale: think what happen with value != 1 (theoretical possibility in the future). > +} ... > +static int pcm512x_gpio_get(struct gpio_chip *chip, unsigned int offset) > +{ > + return (val >> offset) & 1; Don't forget to use BIT() macro. return !!(val & BIT(offset)); > +} ... > +static void pcm512x_gpio_set(struct gpio_chip *chip, unsigned int offset, > + int value) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + int ret; > + > + ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_CONTROL_1, > + BIT(offset), value << offset); value ? BIT(offset) : 0 > + if (ret < 0) > + pr_debug("%s: regmap_update_bits failed: %d\n", __func__, ret); No __func__ in debug messages. Use dev_dbg() when we have struct device available. > +} ... > +static const struct gpio_chip template_chip = { Give better name, please. E.g. pcm512x_gpio_chip. > + .label = "pcm512x-gpio", > + .names = pcm512x_gpio_names, > + .owner = THIS_MODULE, > + .get_direction = pcm512x_gpio_get_direction, > + .direction_input = pcm512x_gpio_direction_input, > + .direction_output = pcm512x_gpio_direction_output, > + .get = pcm512x_gpio_get, > + .set = pcm512x_gpio_set, > + .base = -1, /* let gpiolib select the base */ > + .ngpio = ARRAY_SIZE(pcm512x_gpio_names), > +}; ... > + /* expose 6 GPIO pins, numbered from 1 to 6 */ > + pcm512x->chip = template_chip; > + pcm512x->chip.parent = dev; > + > + ret = devm_gpiochip_add_data(dev, &pcm512x->chip, pcm512x); > + if (ret != 0) { if (ret) > + dev_err(dev, "Failed to register gpio chip: %d\n", ret); > + goto err; > + } -- With Best Regards, Andy Shevchenko
WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: alsa-devel@alsa-project.org, Rob Herring <robh+dt@kernel.org>, linux-gpio@vger.kernel.org, tiwai@suse.de, Linus Walleij <linus.walleij@linaro.org>, Stephen Boyd <sboyd@kernel.org>, Daniel Matuschek <daniel@hifiberry.com>, Hui Wang <hui.wang@canonical.com>, Matthias Reichl <hias@horus.com>, broonie@kernel.org, Bartosz Golaszewski <bgolaszewski@baylibre.com>, Michael Turquette <mturquette@baylibre.com>, linux-clk@vger.kernel.org Subject: Re: [RFC PATCH 01/16] ASoC: pcm512x: expose 6 GPIOs Date: Tue, 14 Apr 2020 20:09:34 +0300 [thread overview] Message-ID: <20200414170934.GA34613@smile.fi.intel.com> (raw) In-Reply-To: <20200409195841.18901-2-pierre-louis.bossart@linux.intel.com> On Thu, Apr 09, 2020 at 02:58:26PM -0500, Pierre-Louis Bossart wrote: > The GPIOs are used e.g. on HifiBerry DAC+ HATs to control the LED > (GPIO3) and the choice of the 44.1 (GPIO6) or 48 (GPIO3) kHz > oscillator (when present). > > Enable basic gpio_chip to get/set values and get/set > directions. Tested with GPIO_LIB from sys/class/gpio, the LED turns > on/off as desired. One question, can this use existing GPIO infrastructure, like bgpio_init()? Ah, I see, that one operates over MMIO, while we would need something based on regmap API. Bartosz, do we have plans to have bgpio_regmap_init() or alike? ... > +static int pcm512x_gpio_get_direction(struct gpio_chip *chip, > + unsigned int offset) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + unsigned int val; > + int ret; > + > + ret = regmap_read(pcm512x->regmap, PCM512x_GPIO_EN, &val); > + if (ret < 0) > + return ret; > + val = (val >> offset) & 1; > + > + /* val is 0 for input, 1 for output, return inverted */ > + return val ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN; This better to read as simple conditional, like if (val & BIT(offset)) return ..._OUT; return ..._IN; > +} ... > +static int pcm512x_gpio_direction_output(struct gpio_chip *chip, > + unsigned int offset, > + int value) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + unsigned int reg; > + int ret; > + > + /* select Register GPIOx output for OUTPUT_x (1..6) */ > + reg = PCM512x_GPIO_OUTPUT_1 + offset; > + ret = regmap_update_bits(pcm512x->regmap, reg, 0x0f, 0x02); Magic numbers detected. > + if (ret < 0) Drop unnecessary ' < 0' parts where it makes sense, like here. > + return ret; > + > + /* enable output x */ (1) > + ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN, > + BIT(offset), BIT(offset)); > + if (ret < 0) > + return ret; > + > + /* set value */ (2) With this (1)->(2) ordering it may be a glitch. So, first set value (if hardware allows you, otherwise it seems like a broken one), and then switch it to output. > + return regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_CONTROL_1, > + BIT(offset), value << offset); You are using many times BIT(offset) mask above, perhaps int mask = BIT(offset); Also, more robust is to use ternary here: 'value ? BIT(offset) : 0'. Rationale: think what happen with value != 1 (theoretical possibility in the future). > +} ... > +static int pcm512x_gpio_get(struct gpio_chip *chip, unsigned int offset) > +{ > + return (val >> offset) & 1; Don't forget to use BIT() macro. return !!(val & BIT(offset)); > +} ... > +static void pcm512x_gpio_set(struct gpio_chip *chip, unsigned int offset, > + int value) > +{ > + struct pcm512x_priv *pcm512x = gpiochip_get_data(chip); > + int ret; > + > + ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_CONTROL_1, > + BIT(offset), value << offset); value ? BIT(offset) : 0 > + if (ret < 0) > + pr_debug("%s: regmap_update_bits failed: %d\n", __func__, ret); No __func__ in debug messages. Use dev_dbg() when we have struct device available. > +} ... > +static const struct gpio_chip template_chip = { Give better name, please. E.g. pcm512x_gpio_chip. > + .label = "pcm512x-gpio", > + .names = pcm512x_gpio_names, > + .owner = THIS_MODULE, > + .get_direction = pcm512x_gpio_get_direction, > + .direction_input = pcm512x_gpio_direction_input, > + .direction_output = pcm512x_gpio_direction_output, > + .get = pcm512x_gpio_get, > + .set = pcm512x_gpio_set, > + .base = -1, /* let gpiolib select the base */ > + .ngpio = ARRAY_SIZE(pcm512x_gpio_names), > +}; ... > + /* expose 6 GPIO pins, numbered from 1 to 6 */ > + pcm512x->chip = template_chip; > + pcm512x->chip.parent = dev; > + > + ret = devm_gpiochip_add_data(dev, &pcm512x->chip, pcm512x); > + if (ret != 0) { if (ret) > + dev_err(dev, "Failed to register gpio chip: %d\n", ret); > + goto err; > + } -- With Best Regards, Andy Shevchenko
next prev parent reply other threads:[~2020-04-14 17:09 UTC|newest] Thread overview: 136+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-09 19:58 [RFC PATCH 00/16] ASoC/SOF/clk/gpio/dt: add Hifiberry DAC+ PRO support Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 01/16] ASoC: pcm512x: expose 6 GPIOs Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:09 ` Andy Shevchenko [this message] 2020-04-14 17:09 ` Andy Shevchenko 2020-04-14 17:52 ` Pierre-Louis Bossart 2020-04-14 17:52 ` Pierre-Louis Bossart 2020-04-15 9:49 ` Andy Shevchenko 2020-04-15 9:49 ` Andy Shevchenko 2020-04-16 11:42 ` Linus Walleij 2020-04-16 11:42 ` Linus Walleij 2020-04-16 14:25 ` Pierre-Louis Bossart 2020-04-16 14:25 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 02/16] ASoC: pcm512x: use "sclk" string to retrieve clock Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:11 ` Andy Shevchenko 2020-04-14 17:11 ` Andy Shevchenko 2020-04-14 17:54 ` Pierre-Louis Bossart 2020-04-14 17:54 ` Pierre-Louis Bossart 2020-04-15 9:52 ` Andy Shevchenko 2020-04-15 9:52 ` Andy Shevchenko 2020-04-15 14:19 ` Pierre-Louis Bossart 2020-04-15 14:19 ` Pierre-Louis Bossart 2020-04-15 15:10 ` Andy Shevchenko 2020-04-15 15:10 ` Andy Shevchenko 2020-04-14 17:45 ` Mark Brown 2020-04-14 17:45 ` Mark Brown 2020-04-14 18:14 ` Pierre-Louis Bossart 2020-04-14 18:14 ` Pierre-Louis Bossart 2020-04-14 18:27 ` Mark Brown 2020-04-14 18:27 ` Mark Brown 2020-04-14 19:15 ` Pierre-Louis Bossart 2020-04-14 19:15 ` Pierre-Louis Bossart 2020-04-14 19:50 ` Mark Brown 2020-04-14 19:50 ` Mark Brown 2020-04-14 20:13 ` Pierre-Louis Bossart 2020-04-14 20:13 ` Pierre-Louis Bossart 2020-04-14 21:02 ` Pierre-Louis Bossart 2020-04-14 21:02 ` Pierre-Louis Bossart 2020-04-15 11:07 ` Mark Brown 2020-04-15 11:07 ` Mark Brown 2020-04-15 11:36 ` Mark Brown 2020-04-15 11:36 ` Mark Brown 2020-04-15 14:44 ` Pierre-Louis Bossart 2020-04-15 14:44 ` Pierre-Louis Bossart 2020-04-15 16:22 ` Mark Brown 2020-04-15 16:22 ` Mark Brown 2020-04-15 17:26 ` Pierre-Louis Bossart 2020-04-15 17:26 ` Pierre-Louis Bossart 2020-04-15 19:50 ` Mark Brown 2020-04-15 19:50 ` Mark Brown 2020-04-15 20:22 ` Pierre-Louis Bossart 2020-04-15 20:22 ` Pierre-Louis Bossart 2020-04-15 20:39 ` Mark Brown 2020-04-15 20:39 ` Mark Brown 2020-04-09 19:58 ` [RFC PATCH 03/16] ASoC: Intel: sof-pcm512x: use gpiod for LED Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:17 ` Andy Shevchenko 2020-04-14 17:17 ` Andy Shevchenko 2020-04-14 17:52 ` Mark Brown 2020-04-14 17:52 ` Mark Brown 2020-04-14 17:57 ` Pierre-Louis Bossart 2020-04-14 17:57 ` Pierre-Louis Bossart 2020-04-15 9:51 ` Andy Shevchenko 2020-04-15 9:51 ` Andy Shevchenko 2020-04-09 19:58 ` [RFC PATCH 04/16] ASoC: Intel: sof-pcm512x: detect Hifiberry DAC+ PRO Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:20 ` Andy Shevchenko 2020-04-14 17:20 ` Andy Shevchenko 2020-04-14 18:02 ` Pierre-Louis Bossart 2020-04-14 18:02 ` Pierre-Louis Bossart 2020-04-15 9:55 ` Andy Shevchenko 2020-04-15 9:55 ` Andy Shevchenko 2020-04-15 14:07 ` Pierre-Louis Bossart 2020-04-15 14:07 ` Pierre-Louis Bossart 2020-04-15 15:05 ` Andy Shevchenko 2020-04-15 15:05 ` Andy Shevchenko 2020-04-09 19:58 ` [RFC PATCH 05/16] ASoC: Intel: sof-pcm512x: reconfigure sclk in hw_params if needed Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:24 ` Andy Shevchenko 2020-04-14 17:24 ` Andy Shevchenko 2020-04-14 18:06 ` Pierre-Louis Bossart 2020-04-14 18:06 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 06/16] ASoC: Intel: sof-pcm512x: select HIFIBERRY_DACPRO clk Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 07/16] clk: hifiberry-dacpro: initial import Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:31 ` Andy Shevchenko 2020-04-14 17:31 ` Andy Shevchenko 2020-04-14 18:09 ` Pierre-Louis Bossart 2020-04-14 18:09 ` Pierre-Louis Bossart 2020-04-15 10:00 ` Andy Shevchenko 2020-04-15 10:00 ` Andy Shevchenko 2020-04-09 19:58 ` [RFC PATCH 08/16] clk: hifiberry-dacpro: update SDPX/copyright Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 09/16] clk: hifiberry-dacpro: style cleanups, use devm_ Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 10/16] clk: hifiberry-dacpro: add OF dependency Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 11/16] clk: hifiberry-dacpro: transition to _hw functions Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 12/16] clk: hifiberry-dacpro: add ACPI support Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-22 9:32 ` Stephen Boyd 2020-04-22 9:32 ` Stephen Boyd 2020-04-22 9:47 ` Andy Shevchenko 2020-04-22 9:47 ` Andy Shevchenko 2020-04-22 9:54 ` Pierre-Louis Bossart 2020-04-22 9:54 ` Pierre-Louis Bossart 2020-04-22 20:52 ` Stephen Boyd 2020-04-22 20:52 ` Stephen Boyd 2020-04-22 21:08 ` Pierre-Louis Bossart 2020-04-22 21:08 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 13/16] clk: hifiberry-dacpro: add "sclk" lookup Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-22 9:35 ` Stephen Boyd 2020-04-22 9:35 ` Stephen Boyd 2020-04-22 9:51 ` Pierre-Louis Bossart 2020-04-22 9:51 ` Pierre-Louis Bossart 2020-04-22 11:54 ` Andy Shevchenko 2020-04-22 11:54 ` Andy Shevchenko 2020-04-09 19:58 ` [RFC PATCH 14/16] clk: hifiberry-dacpro: toggle GPIOs on prepare/unprepare Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 15/16] clk: hifiberry-dacpro: add delay on clock prepare/deprepare Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-09 19:58 ` [RFC PATCH 16/16] ASoC: dt-bindings: add document for Hifiberry DAC+ PRO clock Pierre-Louis Bossart 2020-04-09 19:58 ` Pierre-Louis Bossart 2020-04-14 17:27 ` Andy Shevchenko 2020-04-14 17:27 ` Andy Shevchenko 2020-04-14 18:10 ` Pierre-Louis Bossart 2020-04-14 18:10 ` Pierre-Louis Bossart 2020-04-14 16:50 ` [RFC PATCH 00/16] ASoC/SOF/clk/gpio/dt: add Hifiberry DAC+ PRO support Andy Shevchenko 2020-04-14 16:50 ` Andy Shevchenko 2020-04-14 16:57 ` Pierre-Louis Bossart 2020-04-14 16:57 ` Pierre-Louis Bossart
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200414170934.GA34613@smile.fi.intel.com \ --to=andriy.shevchenko@linux.intel.com \ --cc=alsa-devel@alsa-project.org \ --cc=bgolaszewski@baylibre.com \ --cc=broonie@kernel.org \ --cc=daniel@hifiberry.com \ --cc=hias@horus.com \ --cc=hui.wang@canonical.com \ --cc=linus.walleij@linaro.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-gpio@vger.kernel.org \ --cc=mturquette@baylibre.com \ --cc=pierre-louis.bossart@linux.intel.com \ --cc=robh+dt@kernel.org \ --cc=sboyd@kernel.org \ --cc=tiwai@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.