On Fri, Aug 19, 2011 at 11:53 AM, Linus Walleij
wrote:
> +
> +/**
> + * pin_request() - request a single pin to be muxed in, typically for GPIO
> + * @pin: the pin number in the global pin space
> + * @function: a functional name to give to this pin, passed to the driver
> + * so it knows what
On Fri, Sep 2, 2011 at 9:02 AM, Stijn Devriendt wrote:
> On Fri, Aug 19, 2011 at 11:53 AM, Linus Walleij
> wrote:
>> + if (desc->mux_requested) {
>> + pr_err("pin already requested\n");
>> + goto out;
>> + }
>
> Isn't locking missing here?
You're right, I
On Fri, Aug 26, 2011 at 7:33 PM, Stephen Warren wrote:
> However, we'd then need a extra table defining what each locality meant:
>
> function locality list_of_pins_in_function_at_locality
>
> i2c0 0 0, 1
> i2c0 1 2, 3
>
Linus Walleij wrote at Friday, August 26, 2011 2:35 AM:
> On Thu, Aug 25, 2011 at 9:13 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Thursday, August 25, 2011 4:13 AM:
> >
> >> So this is radically different in that it requires the pin control
> >> system to assume basically that any one pi
On Thu, Aug 25, 2011 at 08:12:10AM -0700, David Brown wrote:
> On Thu, Aug 25, 2011 at 12:12:59PM +0200, Linus Walleij wrote:
>
> > mach-msm:
> >
> >
> > Hard to tell how this works and what's available, support
> > seems to be incomplete. Currently it seems to be wired
> > to do
On Thu, Aug 25, 2011 at 12:12:59PM +0200, Linus Walleij wrote:
> mach-msm:
>
>
> Hard to tell how this works and what's available, support
> seems to be incomplete. Currently it seems to be wired
> to do either a dedicated function (like some UART pin)
> or GPIO, like each pin ca
On Fri, Aug 26, 2011 at 5:12 AM, Barry Song <21cn...@gmail.com> wrote:
> Tested-by: Barry Song
Thanks!
> Linus, i'll also send the patch of csr pinmux prototype. you might
> review and take it as another example except your stericsson U300 and
> take care while you merge pinmux.
OK I'm modifyi
On Thu, Aug 25, 2011 at 9:13 PM, Stephen Warren wrote:
> Linus Walleij wrote at Thursday, August 25, 2011 4:13 AM:
>
>> So this is radically different in that it requires the pin control
>> system to assume basically that any one pin can be used for
>> any one function.
>
> I think that's the wron
2011/8/19 Linus Walleij :
> From: Linus Walleij
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
>
> Currently it handled pinmuxing, i.e. assign electronic functions
> to groups of pins of pins on primarily PGA
Linus Walleij wrote at Thursday, August 25, 2011 4:13 AM:
> On Wed, Aug 24, 2011 at 8:29 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
> >>
> >> This creates a subsystem for handling of pin control devices.
> >> These are devices that control different aspec
On Thu, Aug 25, 2011 at 01:58:12PM +0200, Linus Walleij wrote:
> On Thu, Aug 25, 2011 at 1:04 PM, Sascha Hauer wrote:
>
> > Not really. UART2_CTS can't be routed to arbitrary pads, but it can be
> > routed to more than one pad:
> >
> > #define _MX51_PAD_EIM_D16__UART2_CTS IOMUX_PAD(0x3
On Thu, Aug 25, 2011 at 1:04 PM, Sascha Hauer wrote:
> Not really. UART2_CTS can't be routed to arbitrary pads, but it can be
> routed to more than one pad:
>
> #define _MX51_PAD_EIM_D16__UART2_CTS IOMUX_PAD(0x3f0, 0x5c, 3,
> 0x, 0, 0)
> #define _MX51_PAD_EIM_D25__UART2_CTS
On Thu, Aug 25, 2011 at 12:12:59PM +0200, Linus Walleij wrote:
> On Wed, Aug 24, 2011 at 8:29 PM, Stephen Warren wrote:
> > Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
> >>
> >> This creates a subsystem for handling of pin control devices.
> >> These are devices that control different
On Wed, Aug 24, 2011 at 8:29 PM, Stephen Warren wrote:
> Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
>>
>> This creates a subsystem for handling of pin control devices.
>> These are devices that control different aspects of package
>> pins.
>
> Sorry to keep harping on about this, but
Linus Walleij wrote at Friday, August 19, 2011 3:54 AM:
> From: Linus Walleij
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.
Sorry to keep harping on about this, but I'm still not convinced the data
model is
On Wed, Aug 24, 2011 at 8:24 AM, Barry Song <21cn...@gmail.com> wrote:
>> +int foo_list(struct pinmux_dev *pmxdev, unsigned selector)
>
> pinctrl_dev?
Thanks Barry, fixed all instances!
Yours,
Linus Walleij
___
linaro-dev mailing list
linaro-dev@lists
> +int foo_list(struct pinmux_dev *pmxdev, unsigned selector)
pinctrl_dev?
> +{
> + if (selector >= ARRAY_SIZE(myfuncs))
> + return -EINVAL;
> + return 0;
> +}
> +
> +const char *foo_get_fname(struct pinmux_dev *pmxdev, unsigned selector)
pinctrl_dev?
> +{
> + if
On Mon, Aug 22, 2011 at 02:38:16PM +0200, Linus Walleij wrote:
> On Sun, Aug 21, 2011 at 4:24 PM, Jamie Iles wrote:
>
> > for device tree, when the gpio
> > controllers are registered, the base is typically dynamically assigned. I
> > suspect that this can be solved in the device tree binding fo
On Sun, Aug 21, 2011 at 4:24 PM, Jamie Iles wrote:
> for device tree, when the gpio
> controllers are registered, the base is typically dynamically assigned. I
> suspect that this can be solved in the device tree binding for the controller
> that references the bindings of the pinctrl, but this
On Fri, Aug 19, 2011 at 6:52 PM, Greg KH wrote:
>> IIRC Greg would prefer now to never have had the distinction
>> and wants to make all future uses use a bus_type.
>
> Yes, that is totally correct. Kay has also written much more about this
> and why this is the way forward many times in the pas
> +
> +Pinmux board/machine configuration
> +==
> +
> +Boards and machines define how a certain complete running system is put
> +together, including how GPIOs and devices are muxed, how regulators are
> +constrained and how the clock tree looks. Of course pinmux set
Hi Linus,
On Fri, Aug 19, 2011 at 03:26:08PM +0100, Jamie Iles wrote:
> On Fri, Aug 19, 2011 at 04:04:54PM +0200, Linus Walleij wrote:
> > On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
[...]
> > But yes, there is an assumption that each pin controller will only
> > deal with one block of GP
On Fri, Aug 19, 2011 at 04:36:28PM +0200, Arnd Bergmann wrote:
> On Friday 19 August 2011, Linus Walleij wrote:
> > On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
> >
> > >> +static struct class pinctrl_class = {
> > >> + .name = "pinctrl",
> > >> + .dev_release = pinctrl_dev_release
Hi Linus,
On Fri, Aug 19, 2011 at 04:04:54PM +0200, Linus Walleij wrote:
> On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
> > On Fri, Aug 19, 2011 at 11:53:50AM +0200, Linus Walleij wrote:
> >> +Interaction with the GPIO subsystem
> >> +===
> >> +
> >> +The GP
On Friday 19 August 2011, Linus Walleij wrote:
> On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
>
> >> +static struct class pinctrl_class = {
> >> + .name = "pinctrl",
> >> + .dev_release = pinctrl_dev_release,
> >> + .dev_attrs = pinctrl_dev_attrs,
> >> +};
> >
> > Greg K-H has
On Fri, Aug 19, 2011 at 12:48 PM, Jamie Iles wrote:
> On Fri, Aug 19, 2011 at 11:53:50AM +0200, Linus Walleij wrote:
>> +Interaction with the GPIO subsystem
>> +===
>> +
>> +The GPIO drivers may want to perform operations of various types on the same
>> +physical pi
Hi Linus,
This is looking really nice. I have a few comments/queries inline
though.
Jamie
On Fri, Aug 19, 2011 at 11:53:50AM +0200, Linus Walleij wrote:
> From: Linus Walleij
>
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects
27 matches
Mail list logo
