RE: Device tree BSP

RE: Device tree BSP

[Stephen Neuendorffer]

[-- Attachment #1.1: Type: text/plain, Size: 2253 bytes --]



I'm not exactly sure what you're trying to do here, but it doesn't look right to me.
In particular, why would I have to have a separate core for these functions?
Furthermore, I'm sure there must be some generic mechanisms that can/should be used for these kind of things.
In general, we shouldn't reinvent the wheel here..

CC'ing devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, which is really the best place to ask such questions.

Steve

-----Original Message-----
From: Michal Simek [mailto:michal.simek-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org]
Sent: Tue 6/30/2009 4:18 AM
To: John Williams; John Linn; David DeBonis; Stephen Neuendorffer
Subject: Device tree BSP
 
Hi all,

I need to talk to you about names for at least one new compatible
property name.
It is for heartbeat led gpio and (not important now) reset gpio.
Currently linux kernel takes
first gpio for heartbeat led which needn't be led gpio that's why we
need to specify which gpio
node is for it. I think we can't used it aliases because in case you
enable gpio linux driver
heartbeat go away because that node had gpio compatible property.

Our proposed compatible names are xlnx,heartbeat-gpio-1.00.a and
xlnx,reset-gpio-1.00.a
which replaced all gpio compatible properties. Below are two parts of
fragments.

LEDs_8Bit: gpio@42000000 {
    compatible = "xlnx,heartbeat-gpio-1.00.a";
    reg = < 0x42000000 0x10000 >;
    xlnx,all-inputs = <0x0>;

Push_Buttons: gpio@42600000 {
    compatible = "xlnx,reset-gpio-1.00.a";
    interrupt-parent = <&xps_intc_0>;
    interrupts = < 4 2 >;

If you agree with heartbeat name, I will change it in linux kernel code.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663





This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #1.2: Type: text/html, Size: 3062 bytes --]

[-- Attachment #2: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss

Re: Device tree BSP

[John Williams]

[-- Attachment #1.1: Type: text/plain, Size: 1511 bytes --]

On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <
stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:

>
>
> I'm not exactly sure what you're trying to do here, but it doesn't look
> right to me.
> In particular, why would I have to have a separate core for these
> functions?
> Furthermore, I'm sure there must be some generic mechanisms that can/should
> be used for these kind of things.
> In general, we shouldn't reinvent the wheel here..
>

The issue as I see it is that in a hardware design, the GPIO is a very
convenient core to drive a heartbeat LED, and aux input on proc_sys_reset
(for software-driven reset), or whatever.

Clearly you don't want these GPIO cores to enumerate as regular xps_gpio
devices, binding to the standard GPIO driver and appearing in /dev/gpioN

Is your concern the manual override of OF_ binding (the "compatible"
strings), or just the HW overhead of an extra core to drive these HW utility
functions?  Save us from the bad old days of "misc_logic"  IP cores that
drove this stuff in older Xilinx reference designs!

Would you propose to get tricky and allocate specific bits on existing GPIOs
for these "special" functions, and write the GPIO driver/framework to mask
off these bits etc?  Seems like a complicated software solution to a problem
trivially solved with a few extra gates.

Cheers,

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663

[-- Attachment #1.2: Type: text/html, Size: 2032 bytes --]

[-- Attachment #2: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss

RE: Device tree BSP

[Stephen Neuendorffer]

[-- Attachment #1.1: Type: text/plain, Size: 2627 bytes --]


My (limited) understanding from reading other posts is that there is already a GPIO subsystem for handling such misc-GPIO things.
To me the cost of gates for multiple GPIO cores is small compared to the system cost of having
a separate OF binding.  IMHO, this should be exposed the way any other GPIO with such capabilities
is on any other OF/device-tree enabled system.

Steve

-----Original Message-----
From: John Williams [mailto:john.williams-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org]
Sent: Sun 7/5/2009 2:18 AM
To: Stephen Neuendorffer
Cc: michal.simek-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org; John Linn; David DeBonis; devicetree-discuss@ozlabs.org
Subject: Re: Device tree BSP
 
On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer <
stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:

>
>
> I'm not exactly sure what you're trying to do here, but it doesn't look
> right to me.
> In particular, why would I have to have a separate core for these
> functions?
> Furthermore, I'm sure there must be some generic mechanisms that can/should
> be used for these kind of things.
> In general, we shouldn't reinvent the wheel here..
>

The issue as I see it is that in a hardware design, the GPIO is a very
convenient core to drive a heartbeat LED, and aux input on proc_sys_reset
(for software-driven reset), or whatever.

Clearly you don't want these GPIO cores to enumerate as regular xps_gpio
devices, binding to the standard GPIO driver and appearing in /dev/gpioN

Is your concern the manual override of OF_ binding (the "compatible"
strings), or just the HW overhead of an extra core to drive these HW utility
functions?  Save us from the bad old days of "misc_logic"  IP cores that
drove this stuff in older Xilinx reference designs!

Would you propose to get tricky and allocate specific bits on existing GPIOs
for these "special" functions, and write the GPIO driver/framework to mask
off these bits etc?  Seems like a complicated software solution to a problem
trivially solved with a few extra gates.

Cheers,

John
-- 
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com  p: +61-7-30090663  f: +61-7-30090663



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


[-- Attachment #1.2: Type: text/html, Size: 3387 bytes --]

[-- Attachment #2: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss

Re: Device tree BSP

[Grant Likely]

[fixed quoting]

On Sun, Jul 5, 2009 at 2:43 PM, Stephen
Neuendorffer<stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
> John Williams wrote:
>> On Sun, Jul 5, 2009 at 4:15 AM, Stephen Neuendorffer wrote:
>>> I'm not exactly sure what you're trying to do here, but it doesn't look
>>> right to me.
>>> In particular, why would I have to have a separate core for these
>>> functions?
>>> Furthermore, I'm sure there must be some generic mechanisms that
>>> can/should
>>> be used for these kind of things.
>>> In general, we shouldn't reinvent the wheel here..
>>
>> The issue as I see it is that in a hardware design, the GPIO is a very
>> convenient core to drive a heartbeat LED, and aux input on proc_sys_reset
>> (for software-driven reset), or whatever.
>>
>> Clearly you don't want these GPIO cores to enumerate as regular xps_gpio
>> devices, binding to the standard GPIO driver and appearing in /dev/gpioN
>>
>> Is your concern the manual override of OF_ binding (the "compatible"
>> strings), or just the HW overhead of an extra core to drive these HW utility
>> functions?  Save us from the bad old days of "misc_logic"  IP cores that
>> drove this stuff in older Xilinx reference designs!
>>
>> Would you propose to get tricky and allocate specific bits on existing GPIOs
>> for these "special" functions, and write the GPIO driver/framework to mask
>> off these bits etc?  Seems like a complicated software solution to a problem
>> trivially solved with a few extra gates.
>
> My (limited) understanding from reading other posts is that there is already
> a GPIO subsystem for handling such misc-GPIO things.
> To me the cost of gates for multiple GPIO cores is small compared to the
> system cost of having
> a separate OF binding.  IMHO, this should be exposed the way any other GPIO
> with such capabilities
> is on any other OF/device-tree enabled system.

There are two things at issue here, and it is important not to
conflate them to avoid the risk of leaking Linux internal details out
into the device tree binding.

The first issue is how to describe the hardware in the device tree.  A
GPIO device is clearly being used, so it is entirely appropriate to
use the xps gpio binding to describe the device and the gpios property
to describe that it is being used for either a heartbeat LED or a
reset line.  The goal when designing a binding is to uniquely and
accurately describe the hardware.  If you find yourself trying to
manipulate how Linux behaves by changing the binding, then you're
probably taking a wrong approach, and you risk encoding Linux kernel
implementation details into the hardware description.

The second issue is how Linux actually uses the data.  The kernel does
have infrastructure for managing GPIO devices, but that doesn't mean
that it must use it for all GPIO devices.  If there is a reasonable
use case for it, then there is absolutely no problem with having
board-specific platform code that choses not to register a xps-gpio
device with gpiolib and doing its own thing.  This is one of the
reasons why powerpc platform code must make an explicit call to
register devices on the of_platform bus.  If platform code for a
particular board needs to manipulate the set of registered devices,
then it is free to do so.  So, for example, if you currently choose to
implement a custom heartbeat-gpio driver, then you are free to do so
in platform code.  But if 3 months from now you decide that was a bad
idea and go back to using the common gpio-leds driver, then you don't
need to change the device tree data because it should already
accurately describe the hardware.  You just need to change the custom
board support code.

Related to this is the question of where to describe things like GPIO
leds, reset GPIOs, clock sources, audio complexes, and other types of
board level things that aren't really addressable devices.
Addressable devices (like serial ports or i2c devices) are typically
child nodes of the addressable bus they are attached to, but that
doesn't work for something like an MDIO or SPI bus implemented with
GPIOs; especially when the GPIOs may not all come from the same GPIO
controller.  This is not a question that I've got an answer to, but
I've been thinking about defining a "machine" node, or something
similar that can be a parent of such non-addressable devices.  I'm
hoping Mitch, Ben, DavidG, Scott, or some other OF active folks will
jump in here and give their opinion before I go and define something
braindead.  I was thinking something like this, where the root node
would be the parent of this machine node:

        machine {
                spi@0 {
                        compatible = "virtual,mdio-gpio";
                        #address-cells = <1>;
                        #size-cells = <0>;
                        gpios = <&gpio 11 &gpio 12>;
                        phy@1 {
                                compatible = "nsm,dp83848k";
                                reg = <1>;
                        };
                };
                leds {
                        compatible = "gpio-leds";
                        heartbeat {
                                label = "heartbeat";
                                gpios = <&gpio 4>;
                        };
                };
        };

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Device tree BSP

[Benjamin Herrenschmidt]

On Sun, 2009-07-05 at 15:53 -0600, Grant Likely wrote:
> This is not a question that I've got an answer to, but
> I've been thinking about defining a "machine" node, or something
> similar that can be a parent of such non-addressable devices.  I'm
> hoping Mitch, Ben, DavidG, Scott, or some other OF active folks will
> jump in here and give their opinion before I go and define something
> braindead.  I was thinking something like this, where the root node
> would be the parent of this machine node:

Well, device nodes can perfectly represent non addressable devices...
One way is to have no "reg" property but that sucks as you get no unit
address neither which can cause problems when you have multiple of them.

So hosting them under some kind of node that would break that address
translatability (have no "ranges" property) makes some amount of sense
though I don't necessarily like the term "machine".

But if no "reg" is good for you, then stick them in the soc node with
distinct names.

Also, why "virtual," in your compatible property for the SPI node ? It's
not really virtual... 

Cheers,
Ben.

Re: Device tree BSP

[Grant Likely]

On Sun, Jul 5, 2009 at 4:10 PM, Benjamin
Herrenschmidt<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> On Sun, 2009-07-05 at 15:53 -0600, Grant Likely wrote:
>> This is not a question that I've got an answer to, but
>> I've been thinking about defining a "machine" node, or something
>> similar that can be a parent of such non-addressable devices.  I'm
>> hoping Mitch, Ben, DavidG, Scott, or some other OF active folks will
>> jump in here and give their opinion before I go and define something
>> braindead.  I was thinking something like this, where the root node
>> would be the parent of this machine node:
>
> Well, device nodes can perfectly represent non addressable devices...
> One way is to have no "reg" property but that sucks as you get no unit
> address neither which can cause problems when you have multiple of them.
>
> So hosting them under some kind of node that would break that address
> translatability (have no "ranges" property) makes some amount of sense
> though I don't necessarily like the term "machine".

Neither do I, but I've got nothing better.  I'm open to suggestions.  :-)

> But if no "reg" is good for you, then stick them in the soc node with
> distinct names.

It doesn't really belong in the soc node either because it is all
stuff external to the SoC.

> Also, why "virtual," in your compatible property for the SPI node ? It's
> not really virtual...

I don't like 'virtual,' either, but its in the currently documented
binding.  (Documentation/powerpc/dts-bindings/gpio/mdio.txt).

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: Device tree BSP

[Michal Simek]

[-- Attachment #1.1: Type: text/plain, Size: 2988 bytes --]

2009/7/4 Stephen Neuendorffer <stephen.neuendorffer-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>

>
>
> I'm not exactly sure what you're trying to do here, but it doesn't look
> right to me.
> In particular, why would I have to have a separate core for these
> functions?
> Furthermore, I'm sure there must be some generic mechanisms that can/should
> be used for these kind of things.
> In general, we shouldn't reinvent the wheel here..
>
> CC'ing devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, which is really the best place to
> ask such questions.



Yes, I know - I talked with Grant about too. And I found a solution for
heartbeat.
We have there one small problem that led-gpio heartbeat trigger starts when
driver is ready (long time from the system start)
Current heartbeat works when timer/intc is setup. That big time gap between
current - proposed solution I don't like and
I want to remove it.
I am doing different work now and I'll solve it later.

Thanks,
Michal


>
>
> Steve
>
> -----Original Message-----
> From: Michal Simek [mailto:michal.simek-g5w7nrANp4BDPfheJLI6IQ@public.gmane.org]
> Sent: Tue 6/30/2009 4:18 AM
> To: John Williams; John Linn; David DeBonis; Stephen Neuendorffer
> Subject: Device tree BSP
>
> Hi all,
>
> I need to talk to you about names for at least one new compatible
> property name.
> It is for heartbeat led gpio and (not important now) reset gpio.
> Currently linux kernel takes
> first gpio for heartbeat led which needn't be led gpio that's why we
> need to specify which gpio
> node is for it. I think we can't used it aliases because in case you
> enable gpio linux driver
> heartbeat go away because that node had gpio compatible property.
>
> Our proposed compatible names are xlnx,heartbeat-gpio-1.00.a and
> xlnx,reset-gpio-1.00.a
> which replaced all gpio compatible properties. Below are two parts of
> fragments.
>
> LEDs_8Bit: gpio@42000000 {
>    compatible = "xlnx,heartbeat-gpio-1.00.a";
>    reg = < 0x42000000 0x10000 >;
>    xlnx,all-inputs = <0x0>;
>
> Push_Buttons: gpio@42600000 {
>    compatible = "xlnx,reset-gpio-1.00.a";
>    interrupt-parent = <&xps_intc_0>;
>    interrupts = < 4 2 >;
>
> If you agree with heartbeat name, I will change it in linux kernel code.
>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng)
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
>
>
>
>
>
> This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
>
>


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

[-- Attachment #1.2: Type: text/html, Size: 4181 bytes --]

[-- Attachment #2: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss