All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
Date: Mon, 10 Sep 2012 14:55:30 +0300	[thread overview]
Message-ID: <504DD532.4040400@ti.com> (raw)
In-Reply-To: <20120907165553.GV1303@atomide.com>

On 09/07/2012 07:55 PM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [120907 08:13]:
>> On 09/06/2012 10:10 PM, Tony Lindgren wrote:
>>>
>>> Is it now safe to assume that we always have width of three if
>>> pinctrl-single,bits is specified? The reason I'm asking is..
>>>
>>>> @@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
>>>>  {
>>>>  	struct pcs_func_vals *vals;
>>>>  	const __be32 *mux;
>>>> -	int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>>>> +	int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>>>>  	struct pcs_function *function;
>>>>  
>>>> -	mux = of_get_property(np, PCS_MUX_NAME, &size);
>>>> -	if ((!mux) || (size < sizeof(*mux) * 2)) {
>>>> -		dev_err(pcs->dev, "bad data for mux %s\n",
>>>> -			np->name);
>>>> +	mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>>>> +	if (mux) {
>>>> +		params = 2;
>>>> +	} else {
>>>> +		mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>>>> +		if (!mux) {
>>>> +			dev_err(pcs->dev, "no valid property for %s\n",
>>>> +				np->name);
>>>> +			return -EINVAL;
>>>> +		}
>>>> +		params = 3;
>>>> +	}
>>>
>>> ..because here we could assume the default value for params is 2
>>> if pinctrl-single,pins is specified, and otherwise params is 3
>>> if pinctrl-single,bits is specified for the controller. That would
>>> avoid querying a potentially non-exiting property for each entry.
>>>
>>>> @@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
>>>>  		val = be32_to_cpup(mux + index++);
>>>>  		vals[found].reg = pcs->base + offset;
>>>>  		vals[found].val = val;
>>>> +		if (params == 3) {
>>>> +			val = be32_to_cpup(mux + index++);
>>>> +			vals[found].mask = val;
>>>> +		}
>>>>  
>>>>  		pin = pcs_get_pin_by_offset(pcs, offset);
>>>>  		if (pin < 0) {
>>>
>>> Here params too would be then set during probe already.
>>
>> I'm afraid you lost me here...
>> We only know if the user specified the mux configuration with
>> pinctrl-single,pins or  pinctrl-single,bits in this function.
> 
> Sorry right, yeah we don't know that at probe time currently.
> 
> I'd like to have something that specifies the controller type so
> we don't need to mix two types of controllers and test for
> non-existing properties when parsing the pins.
> 
> How about we require something specified for the pinctrl driver
> in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux?
> 
> And then in the pinctrl-single probe we set params = 3 if
> pinctrl-single,bit-per-mux is specified. And if no
> pinctrl-single,bit-per-mux is specified then set params = 2.
> 
> That way pcs_parse_one_pinctrl_entry() can just test for params.
> 
> Sorry I don't have a better name in mind than bit-per-mux..

I'm not sure if this would make things more prone to error or make the DTS or
the code more clean in any ways.

Both pinctrl-single,pins and pinctrl-single,bits works on top of the same
pinctrl-single area.
In most cases we are going to use pinctrl-single,pins for the mux
configuration and only in few places we need to fall back to pinctrl-single,bits.

With this patch we will have maximum of two query to find out which type is
used, while if we add the 'bit-per-mux' property we will always have need to
have two of_get_property() call to figure out what is used.
IMHO in this way we could also have copy-paste errors coming at us when adding
the mux configurations for the pins and at the end we also need to do same
safety/sanity checks if the user really provided the correct type with
correlation to the 'bit-per-mux'.

This would just complicate the code.
The existence of pinctrl-single,pins or pinctrl-single,bits property alone
gives enough information for the number of parameters.

>  
>> One thing I could do to make the code a bit better to look at is:
>> int params = 2;
>>
>> mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>> if (!mux) {
>> 	mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>> 	if (!mux) {
>> 		dev_err(pcs->dev, "no valid property for %s\n",
>> 		np->name);
>> 		return -EINVAL;
>> 	}
>> 	params = 3;
>> }
>>
>> This might make the code a bit more compact but at the same time one might
>> need to spend few more seconds to understand it.
> 
> Yes well there's no need to do of_get_property second guessing
> if we already know params from the pinctrl-single.c probe time.
> 
> I think we're safe to assume that we don't need to mix parsing
> two different types of configuration for the same controller
> as they can always be set up as separate controllers.
> 
> Regards,
> 
> Tony
> 


-- 
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux
Date: Mon, 10 Sep 2012 14:55:30 +0300	[thread overview]
Message-ID: <504DD532.4040400@ti.com> (raw)
In-Reply-To: <20120907165553.GV1303@atomide.com>

On 09/07/2012 07:55 PM, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [120907 08:13]:
>> On 09/06/2012 10:10 PM, Tony Lindgren wrote:
>>>
>>> Is it now safe to assume that we always have width of three if
>>> pinctrl-single,bits is specified? The reason I'm asking is..
>>>
>>>> @@ -657,18 +664,29 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
>>>>  {
>>>>  	struct pcs_func_vals *vals;
>>>>  	const __be32 *mux;
>>>> -	int size, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>>>> +	int size, params, rows, *pins, index = 0, found = 0, res = -ENOMEM;
>>>>  	struct pcs_function *function;
>>>>  
>>>> -	mux = of_get_property(np, PCS_MUX_NAME, &size);
>>>> -	if ((!mux) || (size < sizeof(*mux) * 2)) {
>>>> -		dev_err(pcs->dev, "bad data for mux %s\n",
>>>> -			np->name);
>>>> +	mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>>>> +	if (mux) {
>>>> +		params = 2;
>>>> +	} else {
>>>> +		mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>>>> +		if (!mux) {
>>>> +			dev_err(pcs->dev, "no valid property for %s\n",
>>>> +				np->name);
>>>> +			return -EINVAL;
>>>> +		}
>>>> +		params = 3;
>>>> +	}
>>>
>>> ..because here we could assume the default value for params is 2
>>> if pinctrl-single,pins is specified, and otherwise params is 3
>>> if pinctrl-single,bits is specified for the controller. That would
>>> avoid querying a potentially non-exiting property for each entry.
>>>
>>>> @@ -686,6 +704,10 @@ static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
>>>>  		val = be32_to_cpup(mux + index++);
>>>>  		vals[found].reg = pcs->base + offset;
>>>>  		vals[found].val = val;
>>>> +		if (params == 3) {
>>>> +			val = be32_to_cpup(mux + index++);
>>>> +			vals[found].mask = val;
>>>> +		}
>>>>  
>>>>  		pin = pcs_get_pin_by_offset(pcs, offset);
>>>>  		if (pin < 0) {
>>>
>>> Here params too would be then set during probe already.
>>
>> I'm afraid you lost me here...
>> We only know if the user specified the mux configuration with
>> pinctrl-single,pins or  pinctrl-single,bits in this function.
> 
> Sorry right, yeah we don't know that at probe time currently.
> 
> I'd like to have something that specifies the controller type so
> we don't need to mix two types of controllers and test for
> non-existing properties when parsing the pins.
> 
> How about we require something specified for the pinctrl driver
> in the "one-bit-per-mux" case like pinctrl-single,bit-per-mux?
> 
> And then in the pinctrl-single probe we set params = 3 if
> pinctrl-single,bit-per-mux is specified. And if no
> pinctrl-single,bit-per-mux is specified then set params = 2.
> 
> That way pcs_parse_one_pinctrl_entry() can just test for params.
> 
> Sorry I don't have a better name in mind than bit-per-mux..

I'm not sure if this would make things more prone to error or make the DTS or
the code more clean in any ways.

Both pinctrl-single,pins and pinctrl-single,bits works on top of the same
pinctrl-single area.
In most cases we are going to use pinctrl-single,pins for the mux
configuration and only in few places we need to fall back to pinctrl-single,bits.

With this patch we will have maximum of two query to find out which type is
used, while if we add the 'bit-per-mux' property we will always have need to
have two of_get_property() call to figure out what is used.
IMHO in this way we could also have copy-paste errors coming at us when adding
the mux configurations for the pins and at the end we also need to do same
safety/sanity checks if the user really provided the correct type with
correlation to the 'bit-per-mux'.

This would just complicate the code.
The existence of pinctrl-single,pins or pinctrl-single,bits property alone
gives enough information for the number of parameters.

>  
>> One thing I could do to make the code a bit better to look at is:
>> int params = 2;
>>
>> mux = of_get_property(np, PCS_MUX_PINS_NAME, &size);
>> if (!mux) {
>> 	mux = of_get_property(np, PCS_MUX_BITS_NAME, &size);
>> 	if (!mux) {
>> 		dev_err(pcs->dev, "no valid property for %s\n",
>> 		np->name);
>> 		return -EINVAL;
>> 	}
>> 	params = 3;
>> }
>>
>> This might make the code a bit more compact but at the same time one might
>> need to spend few more seconds to understand it.
> 
> Yes well there's no need to do of_get_property second guessing
> if we already know params from the pinctrl-single.c probe time.
> 
> I think we're safe to assume that we don't need to mix parsing
> two different types of configuration for the same controller
> as they can always be set up as separate controllers.
> 
> Regards,
> 
> Tony
> 


-- 
Péter

  reply	other threads:[~2012-09-10 11:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-05  9:01 [PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits Peter Ujfalusi
2012-09-05  9:01 ` [PATCH 1/2] pinctrl: pinctrl-single: Make sure we do not change bits outside of mask Peter Ujfalusi
2012-09-06 18:59   ` Tony Lindgren
2012-09-07 21:13     ` Linus Walleij
2012-09-07 21:39       ` Tony Lindgren
2012-09-10  7:09   ` Linus Walleij
2012-09-05  9:01 ` [PATCH 2/2] pinctrl: pinctrl-single: Add pinctrl-single,bits type of mux Peter Ujfalusi
2012-09-06 19:10   ` Tony Lindgren
2012-09-07 15:13     ` Peter Ujfalusi
2012-09-07 16:55       ` Tony Lindgren
2012-09-10 11:55         ` Peter Ujfalusi [this message]
2012-09-10 11:55           ` Peter Ujfalusi
2012-09-10 17:10           ` Tony Lindgren
2012-09-10  7:10   ` Linus Walleij
2012-09-10 18:49     ` Tony Lindgren
2012-09-05 12:10 ` [PATCH 0/2] pinctrl: pinctrl-single: new type: pinctrl-single,bits Linus Walleij
2012-09-05 18:20   ` Tony Lindgren

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=504DD532.4040400@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.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.