Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Jon Smirl schrieb: > On 12/4/07, Clemens Koller <[EMAIL PROTECTED]> wrote: >> That was discussed already in detail in several threads and there >> were already decisions made that the DT went into the kernel - no problem >> with that. >> I just don't see that it 'really does help' in it's current state if >> things are broken in a way they are hard to fix for non DT-familiar >> developers, almost impossible to fix for users which just need to >> compile their own kernel to achieve their project goal. >> >> Well... let's take it easy. I'll dig into the pcf8563 code now. > > Most of this is addressed in the patch series starting with this message: > http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html > > The pcf8563 driver is converted to the new format and is modified to > pick up it's address from the device tree. > > This patch series is being held waiting for an ok on the low level > changes to the i2c subsystem. Hopefully it will go into 2.6.25 Thanks Jon, thanks Scott for the pointers, this works for me. (Patches have some whitespace damage, you propably want to run it thru checkpatch.pl before pushing upstream.) Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! >> Well, the subject is about RTCs. > > Not really, it's about a change in the i2c subsystem (I noticed you > didn't include the i2c list or linuxppc-dev... you'd get a larger > audience of the people that actually made the change that way). That it > happens to be an RTC chip you're using on the i2c bus is an > inconsequential detail. Looks like I wasn't subscribed to the list anymore, so I missed lots of DT related discussions - my bad. :-( >> Well... let's take it easy. I'll dig into the pcf8563 code now. > > BTW, there were patches posted recently by Jon Smirl to convert that > driver to new-style, and to change the i2c subsystem to have the OF > matches in the driver itself. That looks promising. I really didn't expect to find rtc driver names in fsl_soc.c... Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On 12/4/07, Clemens Koller <[EMAIL PROTECTED]> wrote: > That was discussed already in detail in several threads and there > were already decisions made that the DT went into the kernel - no problem > with that. > I just don't see that it 'really does help' in it's current state if > things are broken in a way they are hard to fix for non DT-familiar > developers, almost impossible to fix for users which just need to > compile their own kernel to achieve their project goal. > > Well... let's take it easy. I'll dig into the pcf8563 code now. Most of this is addressed in the patch series starting with this message: http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html The pcf8563 driver is converted to the new format and is modified to pick up it's address from the device tree. This patch series is being held waiting for an ok on the low level changes to the i2c subsystem. Hopefully it will go into 2.6.25 -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Clemens Koller wrote: > Scott Wood schrieb: > >> I would prefer to not tell the driver for 'foo' that it should attach to > >> 0-0068 > >> because it should attach to the first i2c bus (0) it finds per default. > > > > Absolutely wrong. > > Hmm... Why? It's error prone. > > What if foo is on bus 1? > > Then I would need to tell the driver 'foo' that it should attach > to 1-0068. So we're back to the situation where drivers that aren't explicitly told where to look are making assumptions that are possibly incorrect. You should be able to enable drivers without harm, even if the hardware isn't there. > Propably you should see the bigger picture here: Pot, meet kettle. :-) > We just need to tell what we have, if it's not some default... > statically (kconfig) or dynamically (of/dt) to get it right > because we cannot probe for sure what we have (in contrast to PCI). > > I just don't want to be pushed into configuring things twice or on > two different places because that's error prone. The new system is far less error prone than the old system. You seem to be suggesting a third system, with a radically different kconfig format and no multiplatform support (again, this was one of your complaints in your original e-mail -- why do you ignore it now?). Please show us the code, or at least some description of how you would change kconfig to get it up to the task, and how you would handle multiplatform kernels. > >> Then I would need to tell 'bar' to attach to 1-0068. Where is the > problem? > > > > OK, now say there's another foo on bus 2, and a pair of bars on buses > 3 and > > 4? > > Okay, let's play that game: > foo -> connect an instance to 0-0068 and 2-0068 > bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068 That doesn't resemble kconfig in the least -- and even if you transform it into some sort of runtime-parsable textual list, what do those bus numbers mean, anyway? How do you associate those with various i2c buses, potentially coming from different i2c drivers? How do you specify IRQs? How do you specify device variants among those the driver supports? By the time you fix all of that, you'll basically have the device tree. The device tree provides a hierarchy that is well suited to handling this sort of problem, and it also logically separates what the kernel supports from what the hardware has (which is *necessary* for multiplatform support). > >> The 0068 is already redundant in the case of these RTCs because they > are > >> fixed. > > > > How do you know I'm even talking about RTCs? > > Well, the subject is about RTCs. Not really, it's about a change in the i2c subsystem (I noticed you didn't include the i2c list or linuxppc-dev... you'd get a larger audience of the people that actually made the change that way). That it happens to be an RTC chip you're using on the i2c bus is an inconsequential detail. > >> linux-2.6/Documentation/powerpc$ grep "rtc" * > >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, > >> btw.). > >> which could give a clue what's going on here. > >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" * > >> - nothing - > > > > Uh, did you try grepping for "i2c"? > > No, I've just read the whole file from time to time. OK, it seems the description of i2c devices didn't make it into that file. I'm not sure why. > That was discussed already in detail in several threads and there > were already decisions made that the DT went into the kernel - no problem > with that. > I just don't see that it 'really does help' in it's current state if > things are broken in a way they are hard to fix for non DT-familiar > developers, almost impossible to fix for users which just need to > compile their own kernel to achieve their project goal. I agree there's been excessive roughness in the transition -- but in this case, it's largely due to the i2c subsystem change, whereby a driver can't be new-style and old-style at the same time. Thus, once the driver is converted, all platforms have to register the device. On powerpc, we happen to do it using the device tree (though you could do it with board-specific platform code the way other arches do if you really wanted). > Well... let's take it easy. I'll dig into the pcf8563 code now. BTW, there were patches posted recently by Jon Smirl to convert that driver to new-style, and to change the i2c subsystem to have the OF matches in the driver itself. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! Scott Wood schrieb: >>> How would you tell the >>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c >>> bus >>> 0, and a "bar" chip at address 0x68 on i2c bus 1? >> >> I would prefer to not tell the driver for 'foo' that it should attach to >> 0-0068 >> because it should attach to the first i2c bus (0) it finds per default. > > Absolutely wrong. Hmm... Why? > What if foo is on bus 1? Then I would need to tell the driver 'foo' that it should attach to 1-0068. Sorry, I really don't understand your problem here. If we have 'foo' on both busses, I need of course tell it to attach to 0-0068 as well as 1-0068. Propably you should see the bigger picture here: We just need to tell what we have, if it's not some default... statically (kconfig) or dynamically (of/dt) to get it right because we cannot probe for sure what we have (in contrast to PCI). I just don't want to be pushed into configuring things twice or on two different places because that's error prone. >> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? > > OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and > 4? Okay, let's play that game: foo -> connect an instance to 0-0068 and 2-0068 bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068 If i.e. bar is a 8-page eeprom which hw-configurable addresses nailed down to 0x50 and 0x58 to have a contigous eeprom area from 0x50 to 0x5f it can also look like: bar -> connect an instance to 1-0050 and 1-0058 I still don't see a conflict here. You cannot connect more than one device to an address, that would violate the I2C Spec. If you have different devices with the same address, you have to nail down which ones belong together. >> The 0068 is already redundant in the case of these RTCs because they are >> fixed. > > How do you know I'm even talking about RTCs? Well, the subject is about RTCs. But still the same applys for other i2c devices. > Those chips at 0x68 could be > anything. There are many chips that don't have a single fixed address. Sure. Just to make sure >> There is already an example in the kernel for a very similar configuration >> issue: see CONFIG_RTC_HCTOSYS_DEVICE. > > That's not remotely the same. That's telling a kernel init procedure what > kernel device to use, not describing the layout of hardware. I was trying to tell you that the structure to embed above information is already there. >>> The structure for this already present in kconfig, > > It is not. Okay, our point of view is different here. > We really should try to get the table populated with names for all of the > new-style drivers in the kernel, though. Yes. That's what's really necessary to put usability back in. >> linux-2.6/Documentation/powerpc$ grep "rtc" * >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, >> btw.). >> which could give a clue what's going on here. >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" * >> - nothing - > > Uh, did you try grepping for "i2c"? No, I've just read the whole file from time to time. >> The configuration process is away from KISS - I would simply >> state: it's broken - or - it's a regression from 2.6.22. > > The transition could have been done more smoothly if the i2c driver model > allowed a driver to be both new-style and old-style at the same time > (subject to a config option to shut off old-style if it's screwing things > up), I'll agree with that much. > But please, try to understand that the > device tree really does help. That was discussed already in detail in several threads and there were already decisions made that the DT went into the kernel - no problem with that. I just don't see that it 'really does help' in it's current state if things are broken in a way they are hard to fix for non DT-familiar developers, almost impossible to fix for users which just need to compile their own kernel to achieve their project goal. Well... let's take it easy. I'll dig into the pcf8563 code now. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Tue, Dec 04, 2007 at 12:42:41PM +0100, Clemens Koller wrote: > Scott Wood schrieb: >> That's precisely what we do, via the device tree. It is not practical to >> do it with kconfig. > > It's propably not practical to do it with kconfig right now, It's not practical at all. It forces you to support one and only one target per kernel image, and the basic structure of it is not nearly flexible enough. > but creating a separate configuration repository with strong relation to > the kernel config is IMO the wrong way to do it. It has a weak relation to the kernel config, not a strong one. > > Again putting aside multiplatform kernels for the moment, >> what would you do in kconfig to describe the addresses of multiple chips >> without having a fixed-size list of possibilities? > > I don't see ? > > How would you tell the >> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c >> bus >> 0, and a "bar" chip at address 0x68 on i2c bus 1? > > I would prefer to not tell the driver for 'foo' that it should attach to > 0-0068 > because it should attach to the first i2c bus (0) it finds per default. Absolutely wrong. What if foo is on bus 1? > Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and 4? > The 0068 is already redundant in the case of these RTCs because they are > fixed. How do you know I'm even talking about RTCs? Those chips at 0x68 could be anything. There are many chips that don't have a single fixed address. > There is already an example in the kernel for a very similar configuration > issue: see CONFIG_RTC_HCTOSYS_DEVICE. That's not remotely the same. That's telling a kernel init procedure what kernel device to use, not describing the layout of hardware. > The structure for this already present in kconfig, It is not. > and I don't see any road block not to be able to use it. If later on, we > want to have OF to be able to reconfigure it in the form of a DT > structure, we could still feed a tool like the dtc with the .config and > generate one. Please, feel free to make a patch that does this. You may find it to be a bit more difficult than you thought. :-) And again, there's the multiplatform issue. > Just let me make the point clear, why I got so upset here: Having two > different non-independent repositories make the configuration much more > error-prone, especially if the second one (the DT) is partially redundant > and not sufficiently documented. The device tree is not a configuration repository, it is a description of the hardware. > Example: > I need to use the PCF8563 on the MPC8540' I2C as well (*) - it > was just working in 2.6.22. Now, somebody > > a) has to enable it in the kernel config > b) then add it to the i2c_driver_device struct in fsl_soc.c > c) then add it to the DTS. > > Step b and c are not difficult at all, but completely non-obvious > and undocumented for non-developers. You actually have to dig in > the code to find out that you need it and this s. Step b is something that only needs to be done once per chip, and step c is something that only needs to be done once per board. Why is it unreasonable for it to be done by a developer? We really should try to get the table populated with names for all of the new-style drivers in the kernel, though. > linux-2.6/Documentation/powerpc$ grep "rtc" * > only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, > btw.). > which could give a clue what's going on here. > linux-2.6/Documentation/powerpc$ grep "fsl_soc" * > - nothing - Uh, did you try grepping for "i2c"? > The configuration process is away from KISS - I would simply > state: it's broken - or - it's a regression from 2.6.22. The transition could have been done more smoothly if the i2c driver model allowed a driver to be both new-style and old-style at the same time (subject to a config option to shut off old-style if it's screwing things up), I'll agree with that much. But please, try to understand that the device tree really does help. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Scott! Scott Wood schrieb: > On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote: >> Even if I have an eeprom which can have varying addresses, >> I can simply tell the driver/the kernel .config what address >> it should use... > > That's precisely what we do, via the device tree. It is not practical to do > it with kconfig. It's propably not practical to do it with kconfig right now, but creating a separate configuration repository with strong relation to the kernel config is IMO the wrong way to do it. > Again putting aside multiplatform kernels for the moment, > what would you do in kconfig to describe the addresses of multiple chips > without having a fixed-size list of possibilities? I don't see > How would you tell the > kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus > 0, and a "bar" chip at address 0x68 on i2c bus 1? I would prefer to not tell the driver for 'foo' that it should attach to 0-0068 because it should attach to the first i2c bus (0) it finds per default. Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? The 0068 is already redundant in the case of these RTCs because they are fixed. There is already an example in the kernel for a very similar configuration issue: see CONFIG_RTC_HCTOSYS_DEVICE. The structure for this already present in kconfig, and I don't see any road block not to be able to use it. If later on, we want to have OF to be able to reconfigure it in the form of a DT structure, we could still feed a tool like the dtc with the .config and generate one. Just let me make the point clear, why I got so upset here: Having two different non-independent repositories make the configuration much more error-prone, especially if the second one (the DT) is partially redundant and not sufficiently documented. Example: I need to use the PCF8563 on the MPC8540' I2C as well (*) - it was just working in 2.6.22. Now, somebody a) has to enable it in the kernel config b) then add it to the i2c_driver_device struct in fsl_soc.c c) then add it to the DTS. Step b and c are not difficult at all, but completely non-obvious and undocumented for non-developers. You actually have to dig in the code to find out that you need it and this s. linux-2.6/Documentation/powerpc$ grep "rtc" * only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, btw.). which could give a clue what's going on here. linux-2.6/Documentation/powerpc$ grep "fsl_soc" * - nothing - The configuration process is away from KISS - I would simply state: it's broken - or - it's a regression from 2.6.22. (*) Patch will follow, let me see if I guess it right. :-) Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote: > Hello, Scott! > > Scott Wood schrieb: > >> Here, the next idea which comes to my mind: > >> Maybe we should think about a kernel-config -> dts compiler for > >> the future where the enabled drivers generate their default dts > >> entries automagically? > > > > Sorry, there's just not enough information in .config for that. > > If there is really the need to put more information (which I don't > see in the case of the RTCs) It's not uncommon for RTCs to have an alarm IRQ. It's not uncommon for multiple not-quite-compatible RTC chips to be driven by the same driver, which needs to know what it's dealing with. > to .config, it might be an idea to extend the current structure for this > use instead of duplicating and maintaining a second repository. .config is not nearly as flexible in describing hardware as the device tree is. Sorry, but even apart from the multiplatform issue, it's the wrong tool for the job. > And regarding the DS1337 (or the PCF8563 and similar RTCs): > It's address (0x68) is immutable fixed by the manufacturer > of that device. So, why do we include it in the DT, when we > already told the kernel what driver we want to use? You did not tell the kernel what driver you wanted to use; you told the driver which address the chip will be on. There are other chips that also use address 0x68, such as DS1374, which is completely incompatible with DS1337 and uses a different driver. > Even if I have an eeprom which can have varying addresses, > I can simply tell the driver/the kernel .config what address > it should use... That's precisely what we do, via the device tree. It is not practical to do it with kconfig. Again putting aside multiplatform kernels for the moment, what would you do in kconfig to describe the addresses of multiple chips without having a fixed-size list of possibilities? How would you tell the kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus 0, and a "bar" chip at address 0x68 on i2c bus 1? -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On 12/3/07, Clemens Koller <[EMAIL PROTECTED]> wrote: > Hello, Scott! > > Scott Wood schrieb: > >> Here, the next idea which comes to my mind: > >> Maybe we should think about a kernel-config -> dts compiler for > >> the future where the enabled drivers generate their default dts > >> entries automagically? > > > > Sorry, there's just not enough information in .config for that. > > If there is really the need to put more information (which I don't > see in the case of the RTCs) to .config, it might be an idea to > extend the current structure for this use instead of duplicating > and maintaining a second repository. > > And regarding the DS1337 (or the PCF8563 and similar RTCs): > It's address (0x68) is immutable fixed by the manufacturer > of that device. So, why do we include it in the DT, when we > already told the kernel what driver we want to use? I2C is an odd bus in that it is only partially probeable; you can probe for presence, but you can't trust that you know what is there. The device tree approach sidesteps that uncertainty by just mandating that you specify that address and type of each device. This is neither hard or onerous on the developer to do. If we *could* trust the i2c probing (like we can on PCI), then i2c devices would *not* need to be in the device tree. > Even if I have an eeprom which can have varying addresses, > I can simply tell the driver/the kernel .config what address > it should use... If I want to be able to alter that address > for whatever reason by OF, I still don't want to touch a > separate file in the kernel tree. Kconfig was never designed for that type of board level detail and it would be awkward to shoehorn that in (not to mention that it doesn't solve the problem of one kernel running on many boards.) Historically we solved the config problem with board specific code in .c files. A solution I'm sure you'll agree might work, but it's not sustainable in the long run. As for modifying the device tree; you've got many choices; choose what works best for you. For example, you could: a. write a separate .dts file per board varient, or b. write single .dts files which only contains the common properties and the bootloader populates the board specific ones, or c. write a single .dts file which contains all possible nodes and the bootloader deletes the nodes which are irrelevant. Regardless of what method you choose, you just need to make sure that the device tree that the kernel receives is an accurate representation of the hardware (ie. no nodes for non-present devices) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. [EMAIL PROTECTED] (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Scott! Scott Wood schrieb: >> Here, the next idea which comes to my mind: >> Maybe we should think about a kernel-config -> dts compiler for >> the future where the enabled drivers generate their default dts >> entries automagically? > > Sorry, there's just not enough information in .config for that. If there is really the need to put more information (which I don't see in the case of the RTCs) to .config, it might be an idea to extend the current structure for this use instead of duplicating and maintaining a second repository. And regarding the DS1337 (or the PCF8563 and similar RTCs): It's address (0x68) is immutable fixed by the manufacturer of that device. So, why do we include it in the DT, when we already told the kernel what driver we want to use? Even if I have an eeprom which can have varying addresses, I can simply tell the driver/the kernel .config what address it should use... If I want to be able to alter that address for whatever reason by OF, I still don't want to touch a separate file in the kernel tree. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Clemens Koller wrote: > Scott Wood schrieb: > > The problem is the "probed successfully" bit -- i2c can't be > > automatically detected like PCI can, and the probing that was being done > > before was very error-prone. > > I think I understood the original purpose of device trees, or it's > intended advantage but don't see much of this yet. > > Before (2.6.22) everything was working fine just by enabling the proper > kernel config. Just because it worked fine *for you* doesn't mean it worked fine in general. 1. This means that you can't use the same kernel with different hardware, which is precisely what you were complaining that you couldn't do. 2. What if you have two i2c devices at the same address on different buses? Or if you have two devices, these devices can reside on a variety of ports, and the driver for one tries to probe the port of the other? .config doesn't help you now. 3. What if you need to pass in extra information to the driver, such as the exact chip type when more than one is handled by the same driver, or the IRQ line if the chip uses one, etc? > Well, I don't want to start a flamewar on this since we have had > already enough pro & contra Device Tree discussions. I just want > to point out that the current situation doesn't really follow > the KISS principle at all in my eyes. It should be as simple as it can be and still work, but no simpler. Before, it was too simple to work. > Here, the next idea which comes to my mind: > Maybe we should think about a kernel-config -> dts compiler for > the future where the enabled drivers generate their default dts > entries automagically? Sorry, there's just not enough information in .config for that. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Scott! Scott Wood schrieb: > Clemens Koller wrote: >> [OT+sarcasm on] >> >> So, the time is over, where you just enable a driver in the kernel >> config and >> the device gets probed and - if it's probed successfully - it usually >> works. > > The problem is the "probed successfully" bit -- i2c can't be > automatically detected like PCI can, and the probing that was being done > before was very error-prone. I think I understood the original purpose of device trees, or it's intended advantage but don't see much of this yet. Before (2.6.22) everything was working fine just by enabling the proper kernel config. But in it's current implementation I primarily see the an additional, duplicate, badly documented configuration step for these - in my case - stupid, usually trivial to handle RTC chips. > That's the simplest way, but not the only way. You could also have a > wrapper platform that chooses the proper device tree based on something > you detect. Here is the problem: something it detects = probing (what we planned to avoid) something I detect = configurating (currently duplicated work). This wrapper platform doesn't really exist yet in practice. >> Hmmm... this just s! > > There are some growing pains, but the old method of blindly poking at > i2c addresses and hoping that the first driver to ask for a port that > something responds to is actually the right driver for that port is just > shit. That's not a good example: Of course, blindly poking is bad... therefore there is the (kernel.)configuration step to have only the relevant drivers enabled: The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68. The drivers don't touch foreign addresses at all and they are fixed. No issues there... proved by 2.6.22. Well, I don't want to start a flamewar on this since we have had already enough pro & contra Device Tree discussions. I just want to point out that the current situation doesn't really follow the KISS principle at all in my eyes. Here, the next idea which comes to my mind: Maybe we should think about a kernel-config -> dts compiler for the future where the enabled drivers generate their default dts entries automagically? Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Clemens Koller wrote: > [OT+sarcasm on] > > So, the time is over, where you just enable a driver in the kernel config and > the device gets probed and - if it's probed successfully - it usually works. The problem is the "probed successfully" bit -- i2c can't be automatically detected like PCI can, and the probing that was being done before was very error-prone. Thus, there needs to be something describing what hardware is actually there, not just what the kernel supports. > Now, the way is like this: > > - enable the desired driver in the kernel. As always. > - check that the platform driver fsl_soc.c (in my case) defines the >desired rtc-chip in the i2c_board_info Once the glue code gets consolidated, it'll just be a one-time thing for any given chip to be added to the OF I2C table. I don't know why it was ever done in platform-specific code. > - check that the rtc is included in the device tree. This is the substitute for probing. > - embed the device tree to the kernel (cuImage) Or get it from the firmware. > - boot'n'pray. > > That looks really groundbreaking! > > Now, I cannot use one kernel for two almost identical hardware revisions > anymore because the rtc's on i2c are different? This must be a joke! Not at all true. The kernel just needs to know, at runtime, what hardware you actually have. It uses the device tree for this. With cuImage, you're limited to one device tree in a given build, though you can invoke the wrapper manually to create multiple images. However, cuImage is a compatibility measure; if you use a newer u-boot with device tree support, the tree does not need to be statically wrapped in the kernel image. > It seems like I first need to have full device tree support included in > the boot-loader to be able to duplicate my configuration work to allow > one kernel to boot on both hardware. That's the simplest way, but not the only way. You could also have a wrapper platform that chooses the proper device tree based on something you detect. > Hmmm... this just s! There are some growing pains, but the old method of blindly poking at i2c addresses and hoping that the first driver to ask for a port that something responds to is actually the right driver for that port is just shit. -Scott ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
