On Thu, Nov 24, 2011 at 8:54 PM, Tony Lindgren wrote:
> We should probably pass over
> the static board specific mapping as platform_data to the pinmux device
> and make it be part of struct pinctrl_dev. Then new driver instances
> can have their own pctldev->mapping and we can support both platf
Hi,
* Linus Walleij [24 01:29]:
> On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren wrote:
>
> > Note that with device tree things get simpler for muxing as we can
> > get rid of the hardcoded grouping of pins in mux drivers. Instead of
> > hardcoded pingroups, the groups can be created dynami
On Wed, Nov 23, 2011 at 1:28 AM, Stephen Warren wrote:
> Describing the HW doesn't necessarily
> mean that each device needs to describe what pinmux pins it uses; one
> could quite easily have the pinmux describe what settings the various
> pins should have and which drivers will use those pins.
On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren wrote:
> Note that with device tree things get simpler for muxing as we can
> get rid of the hardcoded grouping of pins in mux drivers. Instead of
> hardcoded pingroups, the groups can be created dynamically based on
> what the driver DT entries have
ernel.org; linaro-dev@lists.linaro.org;
> linus.wall...@stericsson.com; linux-samsung-soc; devicetree-
> disc...@lists.ozlabs.org
> Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
>
>
> Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven
Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
> * Linus Walleij [22 03:30]:
>> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
>> wrote:
>>> On 17 November 2011 19:27, Linus Walleij wrote:
Maybe I'm mistaken about the device tree ambitions, but
I w
On 16:28 Tue 22 Nov , Stephen Warren wrote:
> Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> > * Linus Walleij [22 03:30]:
> > > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > > wrote:
> > > > On 17 November 2011 19:27, Linus Walleij
> > > > wrote:
> > > >>
> > > >>
Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> * Linus Walleij [22 03:30]:
> > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > wrote:
> > > On 17 November 2011 19:27, Linus Walleij wrote:
> > >>
> > >> Maybe I'm mistaken about the device tree ambitions, but
> > >> I was s
* Linus Walleij [22 03:30]:
> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> wrote:
> > On 17 November 2011 19:27, Linus Walleij wrote:
> >>
> >> Maybe I'm mistaken about the device tree ambitions, but
> >> I was sort of hoping that it would not contain too much
> >> custom magic numbers
On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
wrote:
> On 17 November 2011 19:27, Linus Walleij wrote:
>>
>> Maybe I'm mistaken about the device tree ambitions, but
>> I was sort of hoping that it would not contain too much
>> custom magic numbers that need to be cross-referenced
>> elsewhere
Hi Linus,
On 17 November 2011 19:27, Linus Walleij wrote:
> On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
> wrote:
>
>> For now, the Samsung GPIO, Pinconfig and Pinmux information is
>> represented in device tree as listed below.
>
> Does this mean that the understanding of this format is mer
On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
wrote:
> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.
Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?
> i2c
On 17 November 2011 13:38, Linus Walleij wrote:
>> Linus,
>> Is there a plan to move even the data that exists in the pinmux
>> drivers today (including the function/pin-groups definition)
>> eventually to DT? Or is it just the 'mapping' data to map
>> devices to functions (that today is done from
On Thursday 17 November 2011 01:50 PM, Linus Walleij wrote:
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
+ * The OMAP control module has a device-control sub-module
+ * which handles all pin/padmuxing for OMAP. The sub-module
+ * is further split into a 'core' instance within t
On Mon, Nov 14, 2011 at 1:40 PM, Rajendra Nayak wrote:
(...)
> + * The OMAP control module has a device-control sub-module
> + * which handles all pin/padmuxing for OMAP. The sub-module
> + * is further split into a 'core' instance within the CORE
> + * powerdomain and a 'wkup' instance within th
On Tue, Nov 15, 2011 at 5:33 AM, Rajendra Nayak wrote:
> On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
>> * Rajendra Nayak [14 04:05]:
>>>
>>> > +static const struct pinctrl_pin_desc omap4_core_pads[] = {
>>> > + PINCTRL_PIN(0, "c12"),
>>> > + PINCTRL_PIN(1, "d12"),
>>> >
On Monday 14 November 2011 10:53 PM, Tony Lindgren wrote:
* Rajendra Nayak [14 04:05]:
> --- /dev/null
> +++ b/drivers/pinctrl/pinmux-omap.c
> @@ -0,0 +1,735 @@
> +
> +/* omap4 core pads */
> +static const struct pinctrl_pin_desc omap4_core_pads[] = {
> + PINCTRL_PIN(0, "c12"),
> +
* Rajendra Nayak [14 04:05]:
> --- /dev/null
> +++ b/drivers/pinctrl/pinmux-omap.c
> @@ -0,0 +1,735 @@
> +
> +/* omap4 core pads */
> +static const struct pinctrl_pin_desc omap4_core_pads[] = {
> + PINCTRL_PIN(0, "c12"),
> + PINCTRL_PIN(1, "d12"),
> + PINCTRL_PIN(2, "c13"),
...
Le
This adds a driver for the OMAP pinmux portions of the system
control module.
The driver is based on the u300 pinmux driver and only supports
OMAP4 platforms for now. Also has very minimal functions/pin-groups
for OMAP4 defined.
Signed-off-by: Rajendra Nayak
---
drivers/pinctrl/Kconfig |
19 matches
Mail list logo
