All of lore.kernel.org
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 05/10] pinctrl: single: support pinconf generic
Date: Wed, 21 Nov 2012 16:08:07 -0800	[thread overview]
Message-ID: <20121122000807.GD5279@atomide.com> (raw)
In-Reply-To: <CAN1soZzzET1tNVJVgaocDnbzjQZsD8AkA-P=q0YF=09SFy6wzw@mail.gmail.com>

* Haojian Zhuang <haojian.zhuang@gmail.com> [121118 06:25]:
> 
> pin_config_set() sets the config value into pinmux register. The upper 16-bit
> is config argument, and the lower 16-bit is config parameter. The
> pinmux register
> is 32-bit in Marvell's silicon. I think it's 32-bit value in most silicons.

Well what if we soon have a 64-bit mux register? We should probably
reserve more than 5 bits for the shift to handle those cases as
well.
 
> And real field value could be lower 16-bit. So I have to pack mask,
> shift, config value
> & config parameter into 32-bit data. The limitation is mask, shift,
> value are all 5-bit
> value. And this is also the reason that I define pinctrl_lookup_map()
> into consumer.h.

Yes this might be problematic for 64-bit systems..

> How could consumer driver know mask & shift? It has to lookup map to
> get the real
> configuration.

I think the consumer driver should not know anything about the
mask & shift.
 
> We also need to keep pin_config_get() compatible with pin_config_set(). I define
> the config data as packed mask, shift, config value & config parameter.
> 
> The conclusion is that we have two choices.
> 1. Use packed way. It's a little complex.

I think the packed way won't work well for consumer drivers.

> 2. Change the interface of pin_config_set()/pin_config_get(). We need
> to use the new
> interface in below.
>     pin_config_set(const char *dev_name, const char *name, unsigned
> long parameter,
>                           unsigned long config);
>     pin_config_get(const char *dev_name, const char *name, unsigned
> long parameter,
>                           unsigned long *config);
>     And the config should be "value >> shift".
> 
> What's your opinion? I prefer the second method since it's easy to
> understand and maintain.
> Then I could hide pinctrl_lookup_map() in core.h.

Yes something like that makes sense to me. Except IMHO we should
use some cookie for a pin instead of dev_name + name, and have
some struct for the config. Something like this perhaps:

pin_config_get(struct pin *pin, struct pin_config *config,
		unsigned long parameter);

Regards,

Tony 

  reply	other threads:[~2012-11-22  0:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15  8:36 [PATCH v5 0/10] use pinctrl-single in arch mmp Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 01/10] ARM: mmp: select pinctrl driver Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 02/10] pinctrl: single: support gpio request and free Haojian Zhuang
2012-11-17  0:44   ` Tony Lindgren
2012-11-20 14:44   ` Linus Walleij
2012-11-15  8:36 ` [PATCH v5 03/10] pinctrl: append method of lookup pinctrl map Haojian Zhuang
2012-11-17  0:46   ` Tony Lindgren
2012-11-17 15:17     ` Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 04/10] pinctrl: generic: add input schmitt disable parameter Haojian Zhuang
2012-11-20 14:42   ` Linus Walleij
2012-11-15  8:36 ` [PATCH v5 05/10] pinctrl: single: support pinconf generic Haojian Zhuang
2012-11-17  0:43   ` Tony Lindgren
2012-11-18  4:51     ` Haojian Zhuang
2012-11-18 14:23       ` Haojian Zhuang
2012-11-22  0:08         ` Tony Lindgren [this message]
2012-11-22  0:08       ` Tony Lindgren
2012-11-15  8:36 ` [PATCH v5 06/10] ARM: dts: support pinctrl single in pxa910 Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 07/10] document: devicetree: bind pinconf with pin single Haojian Zhuang
2012-11-26 19:08   ` Stephen Warren
2012-11-15  8:36 ` [PATCH v5 08/10] tty: pxa: configure pin Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 09/10] i2c: pxa: use devm_kzalloc Haojian Zhuang
2012-11-15  8:36 ` [PATCH v5 10/10] i2c: pxa: configure pinmux Haojian Zhuang

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=20121122000807.GD5279@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.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 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.