Hi Heiko,
On 7/1/22 8:13 AM, Heiko Stuebner wrote:
> Am Sonntag, 26. Juni 2022, 04:11:47 CEST schrieb Samuel Holland:
>> These SoCs contain a pinctrl with a new register layout. Use the variant
>> parameter to set the right register offsets. This pinctrl also increases
>> the number of functions per pin from 8 to 16, taking advantage of all 4
>> bits in the mux config field (so far, only functions 0-8 and 14-15 are
>> used). This increases the maximum possible number of functions.
>>
>> D1s is a low pin count version of the D1 SoC, with some pins omitted.
>> The remaining pins have the same function assignments as D1.
>>
>> Signed-off-by: Samuel Holland <samuel@xxxxxxxxxxxx>
>
> On a D1-Nezha
> Tested-by: Heiko Stuebner <heiko@xxxxxxxxx>
>
> Reviewed-by: Heiko Stuebner <heiko@xxxxxxxxx>
>
> with one remark below
Thanks for reviewing the series.
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> index ec7daaa5666b..350044d4c1b5 100644
>> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> @@ -1297,11 +1297,11 @@ static int sunxi_pinctrl_build_state(struct platform_device *pdev)
>>
>> /*
>> * Find an upper bound for the maximum number of functions: in
>> - * the worst case we have gpio_in, gpio_out, irq and up to four
>> + * the worst case we have gpio_in, gpio_out, irq and up to seven
>> * special functions per pin, plus one entry for the sentinel.
>> * We'll reallocate that later anyway.
>> */
>> - pctl->functions = kcalloc(4 * pctl->ngroups + 4,
>> + pctl->functions = kcalloc(7 * pctl->ngroups + 4,
>> sizeof(*pctl->functions),
>> GFP_KERNEL);
>> if (!pctl->functions)
>> @@ -1494,9 +1494,15 @@ int sunxi_pinctrl_init_with_variant(struct platform_device *pdev,
>> pctl->dev = &pdev->dev;
>> pctl->desc = desc;
>> pctl->variant = variant;
>> - pctl->bank_mem_size = BANK_MEM_SIZE;
>> - pctl->pull_regs_offset = PULL_REGS_OFFSET;
>> - pctl->dlevel_field_width = DLEVEL_FIELD_WIDTH;
>> + if (pctl->variant >= PINCTRL_SUN20I_D1) {
>> + pctl->bank_mem_size = D1_BANK_MEM_SIZE;
>> + pctl->pull_regs_offset = D1_PULL_REGS_OFFSET;
>> + pctl->dlevel_field_width = D1_DLEVEL_FIELD_WIDTH;
>> + } else {
>> + pctl->bank_mem_size = BANK_MEM_SIZE;
>> + pctl->pull_regs_offset = PULL_REGS_OFFSET;
>> + pctl->dlevel_field_width = DLEVEL_FIELD_WIDTH;
>> + }
>
> this is likely ok for _one_ variant (so for now this should be ok) but
> will get ugly when there are more of them.
>
> So in the long term it might make sense to pass these values in from
> the soc-specific driver maybe?
Yes, in the long term. It took 10 years before the first layout change, so I do
not expect another layout change any time soon.
For now, I did not want to deal with the overhead of passing in the offsets
individually, nor coming up with a name for each layout to look up the offsets
from a table. (The BSP calls the variants "SUNXI_PCTL_HW_TYPE_0" and
"SUNXI_PCTL_HW_TYPE_1", which is... not descriptive.)
Regards,
Samuel
