On Tue, Oct 28, 2008 at 02:31:29PM +0100, Konstantinos Margaritis wrote:
>
> Pardon my intrusion in the conversation, but I just couldn't not comment on
> this:
>
> On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson
> <[EMAIL PROTECTED]> wrote:
> >> So now my qualm is back to the beginning of the d
Grant Likely wrote:
At this level, the 'compatible = "gpio-group";' is completely
irrelevant. The binding for "crystalfontz,something-gpio" must
specify that there are two subnodes; one named data-bus and one named
rw-ctrl. The driver, which binds against compatible in the parent
node, would
On Tue, Oct 28, 2008 at 10:53 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> Is it still possible to perhaps create a node under lcd-controller which
> describes the pin groupings? Maybe we should call it a gpio-group.
>
> That way lcd-controller looks like
>
> lcd-controller {
>compatible =
On Tue, Oct 28, 2008 at 11:06 AM, Matt Sealey <[EMAIL PROTECTED]> wrote:
> The other problem was defining pins which most definitely ARE
> connected to something (as GPIO) but could well be in an ill-defined
> order or for no defined purpose with regards to the peripheral. A
> lot of GPIO drivers r
Grant Likely wrote:
For Matt's purposes, I think he wants to describe which GPIO pins are
available to be used, but are not yet connected to anything. In such
a case I think it does make sense to add a node for available GPIO
pins and give it a gpios property with a list of the pins wired to
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 08:11:12PM -0500, Matt Sealey wrote:
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller? W
On Tue, Oct 28, 2008 at 7:31 AM, Konstantinos Margaritis
<[EMAIL PROTECTED]> wrote:
>
> Pardon my intrusion in the conversation, but I just couldn't not comment on
> this:
>
> On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson
> <[EMAIL PROTECTED]> wrote:
>>> So now my qualm is back to the beginning
On Tue, Oct 28, 2008 at 02:31:29PM +0100, Konstantinos Margaritis wrote:
>
> Pardon my intrusion in the conversation, but I just couldn't not comment on
> this:
>
> On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson
> <[EMAIL PROTECTED]> wrote:
> >> So now my qualm is back to the beginning of the d
Pardon my intrusion in the conversation, but I just couldn't not comment on
this:
On Tue, 28 Oct 2008 12:50:03 +1100, David Gibson
<[EMAIL PROTECTED]> wrote:
>> So now my qualm is back to the beginning of the discussion. How do
>> we encode the purpose of those pins reliably and within some
>> st
On Mon, Oct 27, 2008 at 6:51 PM, Matt Sealey <[EMAIL PROTECTED]> wrote:
>
>
> David Gibson wrote:
>>
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> So, you use
>>gpios = <&controller pin1-specifier &controller pin8-specifier
>> &controller pin9-specifi
On Mon, Oct 27, 2008 at 08:11:12PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
>>>
>>> A bunch of things spring to mind:
>>>
>>> * How do you define a GPIO bank in a device tree, not a controller
>>
>> Not a controller? What d
On Mon, Oct 27, 2008 at 07:51:23PM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>> On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>>
>> Uh.. no. The gpio specifier has a format that's gpio controller
>> specific, but it must include the actual pin number, although exactly
>> h
Anton Vorontsov wrote:
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
A bunch of things spring to mind:
* How do you define a GPIO bank in a device tree, not a controller
Not a controller? What do you mean by "bank"? There is no such
thing. There are GPIO controllers, and _
David Gibson wrote:
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
Uh.. no. The gpio specifier has a format that's gpio controller
specific, but it must include the actual pin number, although exactly
how it's encoded might vary.
So, you use
gpios = <&controller pin1-sp
Anton Vorontsov wrote:
On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote:
[...]
* How do you stop GPIOLIB from blindly approving requests to use
pins marked X, without making it "controller-specific"?
Btw, as for pins marked X... If the gpio controller has some register
th
On Mon, Oct 27, 2008 at 12:54:15PM -0500, Scott Wood wrote:
> Matt Sealey wrote:
>> Scott Wood wrote:
>>> It's deprecated *in the context of flat device trees*. Anything not
>>> using flat device trees is out-of-scope with respect to ePAPR.
>>
>> Isn't the beauty of a device tree that every firm
On Mon, Oct 27, 2008 at 11:12:07AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>> On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
>>>
>>> Mitch Bradley wrote:
>>
>> device_type in 1275 defines the runtime method interface. It's *not*
>> for declaring the general class of the d
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>
>> Um.. I can't actually follow what you're getting at there, sorry.
>
> Imagine in your head that you have a GPIO controller that has a
> 32-bit register potentially controlling 32 pins on the chip.
>
> Imagin
On Tue, Oct 28, 2008 at 02:12:21AM +0300, Anton Vorontsov wrote:
[...]
> > * How do you stop GPIOLIB from blindly approving requests to use
> > pins marked X, without making it "controller-specific"?
Btw, as for pins marked X... If the gpio controller has some register
that specify which pin
On Mon, Oct 27, 2008 at 04:56:57PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> Can you _simply_ describe the problem you're trying to solve,
>> w/o that much emotions? Can you give examples of what
>> you've tried, and describe why you don't like it?
>
> I've not tried anything because I
Anton Vorontsov wrote:
Can you _simply_ describe the problem you're trying to solve,
w/o that much emotions? Can you give examples of what
you've tried, and describe why you don't like it?
I've not tried anything because I don't feel confident that the
documentation or device tree examples expl
On Mon, Oct 27, 2008 at 01:56:03PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> The GPIO spec doesn't specify a controller bank. It says
>>
>> - - - -
>> gpio-specifier may encode: bank, pin position inside the bank,
>> whether pin is open-drain and whether pin is logically inverted.
>> -
Anton Vorontsov wrote:
The GPIO spec doesn't specify a controller bank. It says
- - - -
gpio-specifier may encode: bank, pin position inside the bank,
whether pin is open-drain and whether pin is logically inverted.
- - - -
May encode. Or may not encode. FYI, for most (all) SOC GPIO
controlle
On Mon, Oct 27, 2008 at 10:40:12AM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>
>> Um.. I can't actually follow what you're getting at there, sorry.
>
> Imagine in your head that you have a GPIO controller that has a
> 32-bit register potentially controlling 32 pins on the chip.
>
> Imagin
Matt Sealey wrote:
Scott Wood wrote:
It's deprecated *in the context of flat device trees*. Anything not
using flat device trees is out-of-scope with respect to ePAPR.
Isn't the beauty of a device tree that every firmware no matter what
type can present it in whatever form it chooses, but sti
Scott Wood wrote:
They did always work. The real sore points here are device bindings and a
grand total of nothing changed between OF and now with that.
The assertion in ePAPR that device_type is deprecated and ignored
because ePAPR doesn't support FCode is naive at best.
It's deprecated *i
Matt Sealey wrote:
I say ANY firmware environment because at the end
of the day what methods the OF implements, or even if the firmware
(like a U-Boot modification) "lies" about it being device_type serial
or device_type network, Linux completely f**ks over the client
interface at the first oppor
Scott Wood wrote:
Matt Sealey wrote:
Nobody is saying that device_type should not be used in real OF when an
appropriate method interface exists. What we're saying is that flat
device trees, which are incapable of providing a method interface,
should not lie and claim that they have one.
Matt Sealey wrote:
I'm all for it being legacy and optional but marking ethernet ports as
network, and serial ports as serial, is a wonderfully good idea especially
if they were used in ANY firmware environment to bring up the console,
drag in the boot files, or provide a framebuffer display.
N
David Gibson wrote:
On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
Mitch Bradley wrote:
device_type in 1275 defines the runtime method interface. It's *not*
for declaring the general class of the device, although it often
matches that in practice.
It *is* for declaring the
David Gibson wrote:
Um.. I can't actually follow what you're getting at there, sorry.
Imagine in your head that you have a GPIO controller that has a
32-bit register potentially controlling 32 pins on the chip.
Imagine that rather than being able to allocate 6 GPIO pins
*right next to each
On Sun, Oct 26, 2008 at 04:13:26PM -0500, Matt Sealey wrote:
>
>
> Mitch Bradley wrote:
>>
>> I don't use device_type much, if at all, anymore. Generic name +
>> compatible just works better than device_type + specific name. When
> > I write code that has to find a node that is suitable for a g
On Fri, Oct 24, 2008 at 05:14:26PM -0500, Matt Sealey wrote:
>
>
> David Gibson wrote:
>> Don't be patronising.
>>
>> There is an existing address space defined by the gpio binding.
>> Defining another one is pointless redundancy. This is standard good
>> ideas in computer science, no further argu
Stephen Neuendorffer wrote:
One thing I had a crazy dream about was a GUI-based device tree
builder for platforms.
Why is this crazy? This is essentially what we do today with PowerPC
and Microblaze processors in Xilinx FPGAs. Even for ASIC SOCs, there
are several commercial 'connect-your-I
Mitch Bradley wrote:
I don't use device_type much, if at all, anymore. Generic name +
compatible just works better than device_type + specific name. When
> I write code that has to find a node that is suitable for a given purpose,
> I look for the existence of suitable methods and perhaps
Right. I had a similar discussion about this the other day with Anton (I
think he forwarded it here but I wasn't subscribed at that point..). The
current ideology for device trees is to get rid of device_type for new
trees that aren't OF-based. I think it's relevant to give nodes fancy
names (i.e.
On Fri, Oct 24, 2008 at 05:17:42PM -0500, Matt Sealey wrote:
> Anton Vorontsov wrote:
>> On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
>> [...]
Would we suggest a node;
gpio-header {
compatible = "bplan,efika-gpio";
gpios = <&gpio-standard 16 0 17 0
> One thing I had a crazy dream about was a GUI-based device tree
builder
> for platforms. Instead of editing them manually and passing them
> through the compiler, wouldn't it be fun to drag and drop system
> components (and build new ones) into something like a DirectX Filter
> Graph Builder (or
Anton Vorontsov wrote:
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
Would we suggest a node;
gpio-header {
compatible = "bplan,efika-gpio";
gpios = <&gpio-standard 16 0 17 0>;
};
gpio-header2 {
compatible = "bplan,efika-gpio-wkup";
gp
David Gibson wrote:
Don't be patronising.
There is an existing address space defined by the gpio binding.
Defining another one is pointless redundancy. This is standard good
ideas in computer science, no further argument necessary.
The existing address space, and the patches Anton etc. just
Mitch Bradley wrote:
[EMAIL PROTECTED] {
The name here should reflect the purpose of the pin, i.e. what it does
(perhaps "NAME,magic"), not the fact that is is GPIO pin. By analogy,
an ethernet controller's node name is "ethernet", not "pci-card". The
fact that the node represen
On Fri, Oct 24, 2008 at 08:41:20PM +0400, Anton Vorontsov wrote:
[...]
> > So, how do we define in a bank of GPIOs, which ones are free for use,
> > without them being attached to a device and given as a "gpios" property?
> >
> > Would we suggest a node;
> >
> > gpio-header {
> > compatible =
On Thu, Oct 23, 2008 at 04:32:49PM -0500, Matt Sealey wrote:
> Hi guys,
>
> I'm a little perplexed as to how I would define a GPIO controller in a
> device tree but mark off pins as available or not, so users can geek
> around in their own drivers without defining in a device tree exactly
> what
On Thu, Oct 23, 2008 at 06:05:19PM -0500, Matt Sealey wrote:
>
>
> Mitch Bradley wrote:
> [snip]
>
>> You could adopt the convention that preassigned GPIOs must be
>> represented by subordinate nodes, and any GPIO that is not covered by a
>> subordinate node's "reg" property is implicitly availa
On Thu, Oct 23, 2008 at 06:17:45PM -1000, Mitch Bradley wrote:
>>
>> No, no, no, no, no. Making complex multi-level representations of
>> nested things for gpios is just insanity.
>
>
> You know, I don't find this "argument" particularly compelling. But it
> certainly is strongly worded.
>
>>
No, no, no, no, no. Making complex multi-level representations of
nested things for gpios is just insanity.
You know, I don't find this "argument" particularly compelling. But it
certainly is strongly worded.
Just use the same encoded
format as we already use for gpio descriptors in 'g
On Thu, Oct 23, 2008 at 02:52:18PM -1000, Mitch Bradley wrote:
>>
>>
>> Mitch Bradley wrote:
>> [snip]
>>
>>> You could adopt the convention that preassigned GPIOs must be
>>> represented by subordinate nodes, and any GPIO that is not covered by
>>> a subordinate node's "reg" property is implici
On Thu, Oct 23, 2008 at 12:22:03PM -1000, Mitch Bradley wrote:
> You could have the gpio node define an "address space" where each
> "address" is a GPIO pin number.
>
> The node would have one address cell and one size cell, and the
Not necessarily. If you were to have such an address space,
Mitch Bradley wrote:
[snip]
You could adopt the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by
a subordinate node's "reg" property is implicitly available. That's
the way it works for other address spaces.
I like that idea e
Mitch Bradley wrote:
[snip]
You could adopt the convention that preassigned GPIOs must be
represented by subordinate nodes, and any GPIO that is not covered by a
subordinate node's "reg" property is implicitly available. That's the
way it works for other address spaces.
I like that idea e
You could have the gpio node define an "address space" where each
"address" is a GPIO pin number.
The node would have one address cell and one size cell, and the
"decode-unit" and "encode-unit" methods would be the garden-variety
flavors that just convert integers between binary and ASCII. Si
Hi guys,
I'm a little perplexed as to how I would define a GPIO
controller in a device tree but mark off pins as available or
not, so users can geek around in their own drivers without
defining in a device tree exactly what they intend to use it
for (especially if it's something really weird)
52 matches
Mail list logo
