All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Anderson <sean.anderson@linux.dev>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Michal Simek <michal.simek@amd.com>,
	linux-gpio@vger.kernel.org,
	Krishna Potthuri <sai.krishna.potthuri@amd.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] pinctrl: zynqmp: Support muxing individual pins
Date: Mon, 6 May 2024 15:38:09 -0400	[thread overview]
Message-ID: <628abfa4-7e7a-4be1-ab4c-f01b7a90e4af@linux.dev> (raw)
In-Reply-To: <ZjkuzKEt2aiHIwg_@surfacebook.localdomain>

On 5/6/24 15:26, Andy Shevchenko wrote:
> Fri, May 03, 2024 at 12:22:17PM -0400, Sean Anderson kirjoitti:
>> While muxing groups of pins at once can be convenient for large
>> interfaces, it can also be rigid. This is because the group is set to
>> all pins which support a particular function, even though not all pins
>> may be used. For example, the sdhci0 function may be used with a 8-bit
>> eMMC, 4-bit SD card, or even a 1-bit SD card. In these cases, the extra
>> pins may be repurposed for other uses, but this is not currently
>> allowed.
>> 
>> Add a new group for each pin which can be muxed. These groups are part
>> of each function the pin can be muxed to. We treat group selectors
>> beyond the number of groups as "pin" groups. To set this up, we
>> initialize groups before functions, and then create a bitmap of used
>> pins for each function. These used pins are appended to the function's
>> list of groups.
> 
> ...
> 
>> +			for (pin = 0; pin < groups[resp[i]].npins; pin++)
>> +				set_bit(groups[resp[i]].pins[pin], used_pins);
> 
> Why atomic bit operation?

The name was easier to remember. I can make it non-atomic.

> ...
> 
>> +	fgroups = devm_kcalloc(dev, func->ngroups + npins, sizeof(*fgroups),
> 
> size_add() from overflow.h.

OK

>> +			       GFP_KERNEL);
>> +	if (!fgroups)
>> +		return -ENOMEM;
> 
> ...
> 
>> +	for (i = 0; i < func->ngroups; i++) {
>> +		fgroups[i] = devm_kasprintf(dev, GFP_KERNEL, "%s_%d_grp",
>> +					    func->name, i);
>> +		if (!fgroups[i])
>> +			return -ENOMEM;
>> +	}
> 
> Hmm... Can this benefit from devm_kasprintf_strarray()?
> 

I don't think so, since the prefix is different for each group.

Thanks for the suggestions.

--Sean

WARNING: multiple messages have this Message-ID (diff)
From: Sean Anderson <sean.anderson@linux.dev>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Michal Simek <michal.simek@amd.com>,
	linux-gpio@vger.kernel.org,
	Krishna Potthuri <sai.krishna.potthuri@amd.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] pinctrl: zynqmp: Support muxing individual pins
Date: Mon, 6 May 2024 15:38:09 -0400	[thread overview]
Message-ID: <628abfa4-7e7a-4be1-ab4c-f01b7a90e4af@linux.dev> (raw)
In-Reply-To: <ZjkuzKEt2aiHIwg_@surfacebook.localdomain>

On 5/6/24 15:26, Andy Shevchenko wrote:
> Fri, May 03, 2024 at 12:22:17PM -0400, Sean Anderson kirjoitti:
>> While muxing groups of pins at once can be convenient for large
>> interfaces, it can also be rigid. This is because the group is set to
>> all pins which support a particular function, even though not all pins
>> may be used. For example, the sdhci0 function may be used with a 8-bit
>> eMMC, 4-bit SD card, or even a 1-bit SD card. In these cases, the extra
>> pins may be repurposed for other uses, but this is not currently
>> allowed.
>> 
>> Add a new group for each pin which can be muxed. These groups are part
>> of each function the pin can be muxed to. We treat group selectors
>> beyond the number of groups as "pin" groups. To set this up, we
>> initialize groups before functions, and then create a bitmap of used
>> pins for each function. These used pins are appended to the function's
>> list of groups.
> 
> ...
> 
>> +			for (pin = 0; pin < groups[resp[i]].npins; pin++)
>> +				set_bit(groups[resp[i]].pins[pin], used_pins);
> 
> Why atomic bit operation?

The name was easier to remember. I can make it non-atomic.

> ...
> 
>> +	fgroups = devm_kcalloc(dev, func->ngroups + npins, sizeof(*fgroups),
> 
> size_add() from overflow.h.

OK

>> +			       GFP_KERNEL);
>> +	if (!fgroups)
>> +		return -ENOMEM;
> 
> ...
> 
>> +	for (i = 0; i < func->ngroups; i++) {
>> +		fgroups[i] = devm_kasprintf(dev, GFP_KERNEL, "%s_%d_grp",
>> +					    func->name, i);
>> +		if (!fgroups[i])
>> +			return -ENOMEM;
>> +	}
> 
> Hmm... Can this benefit from devm_kasprintf_strarray()?
> 

I don't think so, since the prefix is different for each group.

Thanks for the suggestions.

--Sean

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-05-06 19:38 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-03 16:22 [PATCH 0/2] pinctrl: zynqmp: Support muxing individual pins Sean Anderson
2024-05-03 16:22 ` Sean Anderson
2024-05-03 16:22 ` [PATCH 1/2] dt-bindings: pinctrl: xilinx: Add support for function with pins Sean Anderson
2024-05-03 16:22   ` Sean Anderson
2024-05-03 16:22 ` [PATCH 2/2] pinctrl: zynqmp: Support muxing individual pins Sean Anderson
2024-05-03 16:22   ` Sean Anderson
2024-05-06 19:26   ` Andy Shevchenko
2024-05-06 19:26     ` Andy Shevchenko
2024-05-06 19:38     ` Sean Anderson [this message]
2024-05-06 19:38       ` Sean Anderson
2024-05-06 19:39       ` Sean Anderson
2024-05-06 19:39         ` Sean Anderson
2024-05-06  6:43 ` [PATCH 0/2] " Linus Walleij
2024-05-06  6:43   ` Linus Walleij
2024-05-06 14:45   ` Sean Anderson
2024-05-06 14:45     ` Sean Anderson
2024-05-08 11:54     ` Michal Simek
2024-05-08 11:54       ` Michal Simek
2024-05-27 13:15     ` Linus Walleij
2024-05-27 13:15       ` Linus Walleij
2024-05-28 14:28       ` Sean Anderson
2024-05-28 14:28         ` Sean Anderson
2024-05-29  8:38         ` Linus Walleij
2024-05-29  8:38           ` Linus Walleij
2024-05-30 17:08           ` Sean Anderson
2024-05-30 17:08             ` Sean Anderson
2024-06-03  9:02             ` Linus Walleij
2024-06-03  9:02               ` Linus Walleij
2024-06-03 12:36               ` Michal Simek
2024-06-03 12:36                 ` Michal Simek
2024-06-03 13:37                 ` Linus Walleij
2024-06-03 13:37                   ` Linus Walleij

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=628abfa4-7e7a-4be1-ab4c-f01b7a90e4af@linux.dev \
    --to=sean.anderson@linux.dev \
    --cc=andy.shevchenko@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=sai.krishna.potthuri@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.