From: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>, <krzk+dt@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/3] leds: tlc5925: Add support for non blocking operations
Date: Tue, 14 Jun 2022 15:44:14 +0200 [thread overview]
Message-ID: <84da79a6-9515-2b42-b34a-0c089d7a41b7@traphandler.com> (raw)
In-Reply-To: <CAHp75VftbVOwPFra83T-k5d1qu3NnD_sDHYxiiSEDDrW3NObNQ@mail.gmail.com>
On 09/06/2022 18:43, Andy Shevchenko wrote:
> On Thu, Jun 9, 2022 at 6:29 PM Jean-Jacques Hiblot
> <jjhiblot@traphandler.com> wrote:
>> Settings multiple LEDs in a row can be a slow operation because of the
>> time required to acquire the bus and prepare the transfer.
>> And, in most cases, it is not required that the operation is synchronous.
>>
>> Implementing the non-blocking brightness_set() for such cases.
>> A work queue is used to perform the actual SPI transfer.
>>
>> The blocking method is still available in case someone needs to perform
>> this operation synchronously (ie by calling led_set_brightness_sync()).
> i.e.
>
>> +#define BITS_PER_ATOMIC (sizeof(atomic_t) * 8)
> We have BITS_PER_TYPE(). Use it directly in the code, no need for a
> whole new macro.
>
> ...
>
>> +static int xmit(struct tlc5925_leds_priv *priv)
>> +{
>> + int i;
>> +
>> + spin_lock(&priv->lock);
> This can't be called during IRQ?
>
>> + for (i = 0; i < priv->max_state / (sizeof(atomic_t) * 8) ; i++)
> BITS_PER_TYPE() ?
>
>> + priv->spi_buffer[i] = atomic_read(&priv->state[i]);
>> + spin_unlock(&priv->lock);
>> +
>> + return spi_write(priv->spi, priv->spi_buffer, priv->max_num_leds / 8);
>> +}
> ...
>
>> +static void xmit_work(struct work_struct *ws)
>> +{
>> + struct tlc5925_leds_priv *priv =
>> + container_of(ws, struct tlc5925_leds_priv, xmit_work);
> One line?
>
> Missed blank line here.
>
>> + xmit(priv);
>> +};
> ...
>
>> if (brightness)
>> - priv->state[index / 8] |= (1 << (index % 8));
>> + atomic_or(1 << (index % BITS_PER_ATOMIC),
>> + &priv->state[index / BITS_PER_ATOMIC]);
>> else
>> - priv->state[index / 8] &= ~(1 << (index % 8));
>> - spin_unlock(&priv->lock);
>> + atomic_and(~(1 << (index % BITS_PER_ATOMIC)),
>> + &priv->state[index / BITS_PER_ATOMIC]);
> The whole bunch looks like reinventing the bitmap / bitops.
> Use unsigned long (or DECLARE_BITMAP() if it can be higher than 32)
> for state and set_bit() / clear_bit() / assign_bit() that are atomic.
Thanks for pointing this out.
It will drastically simplify the code.
>
> ...
>
>> + if (brightness)
>> + atomic_or(1 << (index % BITS_PER_ATOMIC),
>> + &priv->state[index / BITS_PER_ATOMIC]);
>> + else
>> + atomic_and(~(1 << (index % BITS_PER_ATOMIC)),
>> + &priv->state[index / BITS_PER_ATOMIC]);
> assign_bit()
>
> ...
>
>> + // Allocate the buffer used to hold the state of each LED
>> + priv->max_state = round_up(max_num_leds, BITS_PER_ATOMIC);
>> + priv->state = devm_kzalloc(dev,
>> + priv->max_state / 8,
>> + GFP_KERNEL);
>> if (!priv->state)
>> return -ENOMEM;
> devm_bitmap_zalloc() ?
>
> ...
>
>> + // Allocate a second buffer for the communication on the SPI bus
>> + priv->spi_buffer = devm_kzalloc(dev,
>> + priv->max_state / 8,
>> + GFP_KERNEL);
> Not sure I understand the output, but perhaps here the BITS_TO_BYTES()
> should be used.
>
prev parent reply other threads:[~2022-06-14 13:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 16:27 [PATCH v3 0/3] Add support for the TLC5925 Jean-Jacques Hiblot
2022-06-09 16:27 ` [PATCH v3 1/3] dt-bindings: leds: Add bindings for the TLC5925 controller Jean-Jacques Hiblot
2022-06-09 16:27 ` [PATCH v3 2/3] leds: Add driver for the TLC5925 LED controller Jean-Jacques Hiblot
2022-06-09 16:57 ` Andy Shevchenko
2022-06-14 12:52 ` Jean-Jacques Hiblot
2022-06-27 8:49 ` Pavel Machek
2022-06-28 13:05 ` Andy Shevchenko
2022-06-09 16:27 ` [PATCH v3 3/3] leds: tlc5925: Add support for non blocking operations Jean-Jacques Hiblot
2022-06-09 16:43 ` Andy Shevchenko
2022-06-14 13:44 ` Jean-Jacques Hiblot [this message]
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=84da79a6-9515-2b42-b34a-0c089d7a41b7@traphandler.com \
--to=jjhiblot@traphandler.com \
--cc=andy.shevchenko@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox