Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
On Thu, Sep 06, 2007 at 04:13:56PM +0200, Segher Boessenkool wrote: AFAIK, there is no other standard data structure that could take place of the par_io nodes in the DTS. The device tree is not a dumping ground for all your I need some standard data structure stuff. Use an XML file if you have to ;-) Bah. How about we just remove the nodes you don't want to see before passing it on to the kernel? :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
_and system GPIOs_ :-) Yup, firmware should set up gpios, to make initial kernel boot. After that, kernel can and should manage GPIOs. Sure. But only the GPIOs it _does_ need to toggle, not the ones that have to be fixed to a certain value (like everything that is described in the par_io nodes now). Devices that really _use_ some GPIO, should use some generic GPIO binding in the device tree, and the generic GPIO subsystem in the kernel. Few examples. [some good examples of why GPIOs can be useful at runtime snipped] At the same time I agree: doing gpio setup in the board file isn't a great solution, just like doing it in the device tree. But hard-code gpio setup in the firmware is much worse and short-sighted approach. It is the correct solution for 99.99% of GPIOs: every GPIO needs to either be set to some fixed configuration (and value), dictated by the board design; or at least it needs to be initialised to something that results in a stable system ;-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
The kernel is of course welcome to do so -- and this may be a valid reason to attach pin information to specific device nodes, if it actually saves a non-negligible amount of power -- but it's not a reason to force the kernel to have to care by not setting things up in the firmware. Well, I might agree here. But to me it seems unnatural that I have to upgrade bootloader to use SPI -- I can already boot the kernel. Bootloader's duties are finished when kernel booted. And if already running kernel is unable to do something, it's not bootloader's fault anymore, but kernel's itself. If the firmware failed to properly initialise the system into some stable state, then yeah, it _is_ the firmware's fault. And from the practical point of view, upgrading bootloader is much more error-prone and risky for the users without proper rescue tools and knowledge. Yeah well -- it's hardly rocket science to make this a very reliable and safe procedure. Kernel is easier to deploy after bug-fixing (and wrongly set up GPIO pin is a bug). That's why I tend to like dumb and simple bootloaders and do not hang up too much duties on it. That's one of the ways it is done -- have a dumb and simple recovery firmware that can install new versions of the main firmware. Anyway, we're getting very far off-topic now :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
David Gibson wrote: Firmwares are, more often than not, crap, and that's unlikely to change. For a lot of things, having the kernel or bootwrapper cope as a special case with a handful of crap firmwares which don't set things up properly isn't actually any easier than having it set them up itself, always. Similarly, firmware is very often unlikely to be updated. So we need to support situations where we use old firmware with new kernels. The cuImage support is a classic example of this. Moving code from kernel to firmware just because some people think it belongs in the firmware is usually impractical. If we added code to U-Boot today to configure the par_io pins, it would probably still be years before we could safely remove that code from the kernel. -- Timur Tabi Linux Kernel Developer @ Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote: On Tue, Sep 04, 2007 at 02:47:50PM +0400, Anton Vorontsov wrote: _and system GPIOs_ :-) Yup, firmware should set up gpios, to make initial kernel boot. No, it should set all pins and similar setup-once type initialization that is board-specific rather than device-specific -- there's no reason for the kernel to need to care about that sort of thing. After that, kernel can and should manage GPIOs. Few examples. Say units (like USB or SPI) can work in very different modes. And it's okay if user want to change device mode in the runtime. This is a special case that warrants kernel involvement. It should not be used as justification for the bootloader leaving pins unconfigured in the majority of cases where it does not make sense to change them at runtime. Another example, power management - if some unit temporarily unused, to save power GPIOs should be set up differently. Say if SPI unit turned off (unused just now), it's wise to bring their dedicated GPIOs to power saving state (be it output0/1 or input, it depends). The kernel is of course welcome to do so -- and this may be a valid reason to attach pin information to specific device nodes, if it actually saves a non-negligible amount of power -- but it's not a reason to force the kernel to have to care by not setting things up in the firmware. Well, I might agree here. But to me it seems unnatural that I have to upgrade bootloader to use SPI -- I can already boot the kernel. Bootloader's duties are finished when kernel booted. And if already running kernel is unable to do something, it's not bootloader's fault anymore, but kernel's itself. At least I like to think so. Maybe I'm wrong, yet not sure. ;-) And from the practical point of view, upgrading bootloader is much more error-prone and risky for the users without proper rescue tools and knowledge. Kernel is easier to deploy after bug-fixing (and wrongly set up GPIO pin is a bug). That's why I tend to like dumb and simple bootloaders and do not hang up too much duties on it. Anyhow, all above is just my own preference, I'm not arguing at all, because personally I'm fine with any option, be it dts, board file, device driver's file, the bootloader, or all at once. ;-) -Scott Thanks, -- Anton Vorontsov email: [EMAIL PROTECTED] backup email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
On Wed, Sep 05, 2007 at 03:40:23PM +0400, Anton Vorontsov wrote: On Tue, Sep 04, 2007 at 01:20:28PM -0500, Scott Wood wrote: The kernel is of course welcome to do so -- and this may be a valid reason to attach pin information to specific device nodes, if it actually saves a non-negligible amount of power -- but it's not a reason to force the kernel to have to care by not setting things up in the firmware. Well, I might agree here. But to me it seems unnatural that I have to upgrade bootloader to use SPI -- I can already boot the kernel. Sure -- the firmware should have been done right the first time. Unfortunately, it very often doesn't, and thus fixups in the kernel's platform code are warranted, but the firmware is still the preferred place to do it. Bootloader's duties are finished when kernel booted. And this line of thinking is what causes boards to be shipped with half-assed firmware. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
On Tue, 4 Sep 2007 13:20:28 -0500 Scott Wood wrote: _and system GPIOs_ :-) Yup, firmware should set up gpios, to make initial kernel boot. No, it should set all pins and similar setup-once type initialization that is board-specific rather than device-specific -- there's no reason for the kernel to need to care about that sort of thing. After that, kernel can and should manage GPIOs. Few examples. Say units (like USB or SPI) can work in very different modes. And it's okay if user want to change device mode in the runtime. This is a special case that warrants kernel involvement. It should not be used as justification for the bootloader leaving pins unconfigured in the majority of cases where it does not make sense to change them at runtime. This argue is useless: both opinions have same weight. Firmware is able to provide meaningful default gpio setup, and nobody will object. The point is, that blindly assume all the low-level stuff is fine, you are able only in case you've developed respective bits in the firmware. More usual case is additional overhead of checking if the firmware not attempting to do something not really wanted, so we'll always have a tradeoff. -- Sincerely, Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
I expect very few things from the bootloader: setup memory controller, Setup CPUs, clocks and voltages, system busses, system controllers, memory controllers, memory itself, _and system GPIOs_ :-) You know, all the basic and/or board-specific stuff that is needed to run a system. This kind of GPIOs definitely belongs to that category. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */ + par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */ + par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */ Why are you doing this here, and not in the device tree? I saw you used pio node, but later changed to make it hardcoded. What's the reason? IMO, device tree is used to describe the hardware settings, pio node is a perfect match. Not at all. The device tree describe how the hardware _is_ set up (after firmware, bootloader etc.); now how it _should be_ set up by the kernel. It would make a lot of sense to do this work in the firmware instead, but it doesn't make sense at all to put this stuff into the device tree. Moreover, changing the device tree is much easier than changing the code. How so? You don't like C code? :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Tabi Timur-B04825
Sent: Friday, August 31, 2007 5:07 AM
To: Anton Vorontsov
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts
to use SPI1in QE, register mmc_spi stub
Anton Vorontsov wrote:
+static int __init mpc832x_spi_init(void) {
+ if (!machine_is(mpc832x_rdb))
+ return 0;
+
+ par_io_config_pin(3, 0, 3, 0, 1, 0); /* SPI1 MOSI, I/O */
+ par_io_config_pin(3, 1, 3, 0, 1, 0); /* SPI1 MISO, I/O */
+ par_io_config_pin(3, 2, 3, 0, 1, 0); /* SPI1 CLK, I/O */
+ par_io_config_pin(3, 3, 2, 0, 1, 0); /* SPI1 SEL, I */
+
+ par_io_config_pin(3, 13, 1, 0, 0, 0); /* !SD_CS,O */
+ par_io_config_pin(3, 14, 2, 0, 0, 0); /* SD_INSERT, I */
+ par_io_config_pin(3, 15, 2, 0, 0, 0); /* SD_PROTECT,I */
Why are you doing this here, and not in the device tree?
I saw you used pio node, but later changed to make it hardcoded. What's
the reason? IMO, device tree is used to describe the hardware settings,
pio node is a perfect match. Moreover, changing the device tree is much
easier than changing the code.
- Leo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
