Device tree BSP

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 [email protected], which is really the best place to ask such questions.

Steve

-----Original Message-----
From: Michal Simek [mailto:[email protected]]
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.

_______________________________________________
devicetree-discuss mailing list [email protected]
https://ozlabs.org/mailman/listinfo/devicetree-discuss

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

_______________________________________________
devicetree-discuss mailing list [email protected]
https://ozlabs.org/mailman/listinfo/devicetree-discuss

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:[email protected]]
Sent: Sun 7/5/2009 2:18 AM
To: Stephen Neuendorffer
Cc: [email protected]; John Linn; David DeBonis; [email protected]
Subject: Re: Device tree BSP

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.

_______________________________________________
devicetree-discuss mailing list [email protected]
https://ozlabs.org/mailman/listinfo/devicetree-discuss

[fixed quoting]

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.

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.

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

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

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.

2009/7/4 Stephen Neuendorffer <[email protected]>

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

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

_______________________________________________
devicetree-discuss mailing list [email protected]
https://ozlabs.org/mailman/listinfo/devicetree-discuss