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 __ RD 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.
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 __ RD 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! 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 __ RD 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: 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 __ RD 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: 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.
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: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Alessandro, Hi, Olof! Olof Johansson wrote: ds1307 requires you to register i2c_board_info for it to probe properly. Does your platform do so? I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init() is just never called despite the module gets loaded. Regards, Clemens Koller __ RD 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: [rtc-linux] Re: DS1337 RTC on I2C broken.
Clemens Koller wrote:
Hi, Alessandro, Hi, Olof!
Olof Johansson wrote:
ds1307 requires you to register i2c_board_info for it to probe properly.
Does your platform do so?
I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
is just never called despite the module gets loaded.
Hello Clemens,
Do you have rtc node in your dts file (I'm assuming arch/powerpc
situation)? If not, you'll have to add it - for example similarly to
what's being done in the attached patch (68 is the I2C address of the
RTC chip - a DS1339 in my case).
HTH,
Bartlomiej Sieka
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 112279b..ab39d61 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -329,10 +329,17 @@
device_type = i2c;
compatible = mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c;
cell-index = 1;
+ #cell-size = 0;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
+ [EMAIL PROTECTED] {
+ device_type = rtc;
+ compatible = dallas,ds1339;
+ reg = 68;
+ };
+
};
[EMAIL PROTECTED] {
device_type = sram;
___
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Bartlomiej! Bartlomiej Sieka schrieb: Do you have rtc node in your dts file (I'm assuming arch/powerpc situation)? If not, you'll have to add it - for example similarly to what's being done in the attached patch (68 is the I2C address of the RTC chip - a DS1339 in my case). Thank you also for your hint... that was indeed the problem here. Simple but not really obvious. Is it possible to have a maximum generic .dts configuration where the kernel is told to include any device it propably finds? I guess the failing reset since 2.6.22 is also just an entry in my .dts... ? Regards, -- Clemens Koller __ RD 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
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 __ RD 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.
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 __ RD 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: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Fri, Nov 30, 2007 at 03:12:31PM +0100, Clemens Koller wrote: Hello, Alessandro! Alessandro Zummo schrieb: It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... Here comes more debugging output: Please note that I have now _two_ almost identical systems up and running with the latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another one (fox_1) with an DS1337. Both RTCs work, but the kernel doesn't get the time right. ds1307 requires you to register i2c_board_info for it to probe properly. Does your platform do so? -Olof ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Fri, 30 Nov 2007 15:12:31 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Hello, Alessandro! Alessandro Zummo schrieb: It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... Here comes more debugging output: [..] your .config is right, the drivers are loaded but they are not bound to the chips as they are supposed to do. can you check that i2c_board_info structures / i2c_register_board_info are used by your platform? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Fri, 30 Nov 2007 19:12:01 +0100 Clemens Koller [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307 what is dmesg saying at this time? you might want to add some debug statements in the driver to see where it halts.. i guess the driver is not bound to the chip for some reason. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Alessandro Zummo schrieb: On Fri, 30 Nov 2007 12:04:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Modular doesn't make sense to me, because the filesystem check starts to complain when last mount time was way to far in the past or in the future. But I will try... It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307 [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by rtc_ds1307 6944 0 i2c_core 29936 1 rtc_ds1307 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core i2c_core doesn't pull in i2c_mpc (the MPC107/85xx i2c driver)! [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by i2c_mpc 8128 0 rtc_ds1307 6944 0 i2c_core 29936 2 i2c_mpc,rtc_ds1307 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core it's still unused. Doing it the other way around: [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by i2c_mpc 8128 0 i2c_core 29936 1 i2c_mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307 [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod Module Size Used by rtc_ds1307 6944 0 rtc_core 24248 1 rtc_ds1307 rtc_lib 3456 2 rtc_ds1307,rtc_core i2c_mpc 8128 0 i2c_core 29936 2 rtc_ds1307,i2c_mpc [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/i2c/busses$ cd /dev [EMAIL PROTECTED]:/dev$ ls -la r* crw-rw-rw- 1 root root 1, 8 Jan 1 1970 random I guess I'll have to dig in the code now since this is a 100% road block for my project. :-( Does it make sense to pickup some I2C people here? Same story, next week... Have a nice weekend. If you come up with some idea / patches, still let me know, I'll be able to login remotely. Thank you, Regards, Clemens Koller __ RD 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: [rtc-linux] Re: DS1337 RTC on I2C broken.
Hello, Alessandro! Alessandro Zummo schrieb: It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... Here comes more debugging output: Please note that I have now _two_ almost identical systems up and running with the latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another one (fox_1) with an DS1337. Both RTCs work, but the kernel doesn't get the time right. I have now the SENSORS_*=n as you said and the (new) RTC configured. The kernel configuration (attached) is identical for both machines. Can you please check that again?! Which CONFIG do I have to enable that I get /dev/rtc and/or /dev/rtc0 devices? Note that I don't get any /dev/rtc* entry right now despite RTC_INTF_DRV=Y Here are the outputs of the two hosts: HOST ECAM [EMAIL PROTECTED]:~$ dmesg Using MPC85xx ADS machine description Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb Linux version 2.6.24-rc3-g09f345da ([EMAIL PROTECTED]) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:38 CET 2007 Found legacy serial port 0 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] mem=e0004500, taddr=e0004500, irq=0, clk=33000, speed=0 Found legacy serial port 1 for /[EMAIL PROTECTED]/[EMAIL PROTECTED] mem=e0004600, taddr=e0004600, irq=0, clk=33000, speed=0 Entering add_active_range(0, 0, 65536) 0 entries of 256 used Found FSL PCI host bridge at 0xe0008000.Firmware bus number: 0-0 Top of RAM: 0x1000, Total RAM: 0x1000 Memory hole size: 0MB Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -65536 On node 0 totalpages: 65536 DMA zone: 512 pages used for memmap DMA zone: 0 pages reserved DMA zone: 65024 pages, LIFO batch:15 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/sdb3 ro console=ttyS0,115200 mpic: Setting up MPIC OpenPIC version 1.2 at e004, max 1 CPUs mpic: ISU size: 56, shift: 6, mask: 3f mpic: Initializing for 56 sources PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 41.25 MHz time_init: processor frequency = 825.00 MHz clocksource: timebase mult[60f83e1] shift[22] registered clockevent: decrementer mult[a8f] shift[16] cpu[0] Console: colour dummy device 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 256000k/262144k available (3296k kernel code, 5840k reserved, 144k data, 92k bss, 124k init) SLUB: Genslabs=11, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay loop... 82.43 BogoMIPS (lpj=164864) Mount-cache hash table entries: 512 net_namespace: 64 bytes NET: Registered protocol family 16 rstcr compatible register does not exist! PCI: Probing PCI hardware PCI: Cannot allocate resource region 0 of device :00:12.0 PCI: Cannot allocate resource region 1 of device :00:12.0 PCI: Cannot allocate resource region 2 of device :00:12.0 PCI: Cannot allocate resource region 3 of device :00:12.0 PCI: Cannot allocate resource region 4 of device :00:12.0 PCI: Cannot allocate resource region 0 of device :00:14.0 PCI: Cannot allocate resource region 2 of device :00:14.0 SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb NET: Registered protocol family 2 Time: timebase clocksource has been installed. Switched to high resolution mode on CPU 0 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A console [ttyS0] enabled serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A loop: module loaded Gianfar MII Bus: probed eth0: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:00 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size eth1: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:01 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size eth2: Gianfar Ethernet Controller Version 1.2, 00:40:42:01:00:02 eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size sata_promise :00:14.0: version 2.11 scsi0 : sata_promise scsi1 : sata_promise scsi2 : sata_promise ata1: SATA
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Fri, 30 Nov 2007 12:04:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: A kernel upgrade doesn't make the chip to disappear ;-) The I2C bus is/was basically working fine all the time... see below. you never know those pesky chips ;) Modular doesn't make sense to me, because the filesystem check starts to complain when last mount time was way to far in the past or in the future. But I will try... It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc. it should work anyway, but who knows... -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Alessandro Zummo schrieb: On Thu, 29 Nov 2007 21:03:49 +0100 Clemens Koller [EMAIL PROTECTED] wrote: My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( One more update: I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to verify that the problem with the RTC still persists. I startet to bisect, but ran quickly into other crashes. (no console on 2.6.23-rc2 and 2.6.23) So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and and 2.6.24-rc2-ge6a5c27f. did you tried compiling it modular? you might even check with i2cdetect if the chip is there A kernel upgrade doesn't make the chip to disappear ;-) The I2C bus is/was basically working fine all the time... see below. Modular doesn't make sense to me, because the filesystem check starts to complain when last mount time was way to far in the past or in the future. But I will try... I can: $ uname -a Linux fox_1 2.6.24-rc3-g09f345da #1 Thu Nov 29 21:21:39 CET 2007 ppc e500 GNU/Linux $ i2cdetect 0 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-0. I will probe address range 0x03-0x77. Continue? [Y/n] Y 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: UU -- -- -- -- -- -- UU -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- At 0x68 is the DS1337, at 0x48 I have an LM75 at 0x50 and 0x57 there is some EEPROM attached $ i2cdump 0 0x68 b Error: Could not set address to 0x68: Device or resource busy That would tell me AFAICT that the ds1307 driver claimed that address already... But... Well, I've attached the config again. (Note, I enabled the SENSORS_x during my manual bisecting again to find where it doesn't work anymore. Disabling them didn't work for sure, but will retry now...) Regards, -- Clemens Koller __ RD 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 config.gz Description: application/gzip ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hello, Allessandro! Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) Just to give you an update: The latest paulus.git as of today (Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday. Regards, Clemens Koller __ RD 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: DS1337 RTC on I2C broken.
Hello all, I am trying to use some devices on i2c protocol, one of them is the DS1337 RTC, but I don't know too much about how. I am using the Linux kernel 2.6.15 and a mpc866 processor. I've seen there is a cpm i2c interface for these processors (for a rpx board). However the corresponding code (i2c-algo8xx) doesn't appear in the sources. The i2c-rpx.c just initializes the ioports, the adapter struct and the isr. Maybe I am not understanding the i2c driver right. I am a bit confused about it. Could you give me some help about how it works or what should I have to do? Thanks in advance. Best regards, Raúl Moreno Clemens Koller [EMAIL PROTECTED] Clemens Koller Enviado por: [EMAIL PROTECTED] 29/11/2007 12:24 Para: Alessandro Zummo [EMAIL PROTECTED] cc: [EMAIL PROTECTED], linuxppc-embedded@ozlabs.org Asunto: Re: DS1337 RTC on I2C broken. Hello, Allessandro! Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) Just to give you an update: The latest paulus.git as of today (Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday. Regards, Clemens Koller __ RD 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 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hello, Raul! [EMAIL PROTECTED] schrieb: I am trying to use some devices on i2c protocol, one of them is the DS1337 RTC, but I don't know too much about how. I am using the Linux kernel 2.6.15 and a mpc866 processor. I don't remember too much about these old kernels. And, please notice, that - I am on an mpc8540 which is quite different from your mpc866 processor. - I am on the latest kernels which are also very different from the old ones regarding the RTC subsystem. Usually you have to configure the kernel using the right i2c interface for your processor (if supported). I am using the 'fsl-i2c' driver enabled by: I2C-support - I2C Hardware Bus support - MPC107/824x/85xx/52xx/86xx which will be: CONFIG_I2C_MPC=y Then, you might have to enable the (now deprecated) Misc I2C Chip Support - Dallas DS1337 and ... Real Time Clock support which gives you: CONFIG_SENSORS_DS1337=y I've seen there is a cpm i2c interface for these processors (for a rpx board). the fsl-i2c might be the right place However the corresponding code (i2c-algo8xx) doesn't appear in the sources. The i2c-rpx.c just initializes the ioports, the adapter struct and the isr. Maybe I am not understanding the i2c driver right. I am a bit confused about it. Could you give me some help about how it works or what should I have to do? I would suggest - despite the current problems - to use a current kernel and check your mileage there. I don't want to ride dead horses anymore. Regards, Clemens Koller __ RD 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: DS1337 RTC on I2C broken.
Hi There! Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( One more update: I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to verify that the problem with the RTC still persists. I startet to bisect, but ran quickly into other crashes. (no console on 2.6.23-rc2 and 2.6.23) So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and and 2.6.24-rc2-ge6a5c27f. Regards, Clemens Koller __ RD 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: DS1337 RTC on I2C broken.
On Thu, 29 Nov 2007 21:03:49 +0100 Clemens Koller [EMAIL PROTECTED] wrote: My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( One more update: I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to verify that the problem with the RTC still persists. I startet to bisect, but ran quickly into other crashes. (no console on 2.6.23-rc2 and 2.6.23) So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and and 2.6.24-rc2-ge6a5c27f. did you tried compiling it modular? you might even check with i2cdetect if the chip is there -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: DS1337 RTC on I2C broken.
Hi, Alessandro! Thank you for your quick response... I'll just follow your ideas and provide you with the dmesg output ASAP. If you are online for some more time, I will accelerate this debugging session... Just let me know. Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( mmm. I've been told it should work ;) Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y this one must be deselected. CONFIG_SENSORS_DS1337=y CONFIG_SENSORS_DS1374=y ditto. Will do. DEV: registering device: ID = '0-0068' bus i2c: add device 0-0068 bound device '0-0068' to driver 'ds1337' maybe the wrong driver is kicking in here. the fact that there is no rtc class related output in dmesg should and that there is no /dev/rtc0 could be a sign that the whole class is not going in. do you have full dmesg? Not a full one from the 2.6.24 right now... But I'll disable above stuff and get you a full one. (in 5..10 minutes). Regards, Clemens Koller __ RD 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: DS1337 RTC on I2C broken.
Alessandro Zummo schrieb: On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( mmm. I've been told it should work ;) Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y this one must be deselected. CONFIG_SENSORS_DS1337=y CONFIG_SENSORS_DS1374=y ditto. DEV: registering device: ID = '0-0068' bus i2c: add device 0-0068 bound device '0-0068' to driver 'ds1337' maybe the wrong driver is kicking in here. the fact that there is no rtc class related output in dmesg should and that there is no /dev/rtc0 could be a sign that the whole class is not going in. do you have full dmesg? My current .config as well as the dmesg is attached with your suggested changes. Regards, Clemens Koller __ RD 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 DEV: registering device: ID = 'tty47' DEV: registering device: ID = 'tty48' DEV: registering device: ID = 'tty49' DEV: registering device: ID = 'tty50' DEV: registering device: ID = 'tty51' DEV: registering device: ID = 'tty52' DEV: registering device: ID = 'tty53' DEV: registering device: ID = 'tty54' DEV: registering device: ID = 'tty55' DEV: registering device: ID = 'tty56' DEV: registering device: ID = 'tty57' DEV: registering device: ID = 'tty58' DEV: registering device: ID = 'tty59' DEV: registering device: ID = 'tty60' DEV: registering device: ID = 'tty61' DEV: registering device: ID = 'tty62' DEV: registering device: ID = 'tty63' Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled Registering platform device 'serial8250'. Parent at platform DEV: registering device: ID = 'serial8250' bus platform: add device serial8250 DEV: registering device: ID = 'ttyS0' DEV: registering device: ID = 'ttyS1' DEV: registering device: ID = 'ttyS2' DEV: registering device: ID = 'ttyS3' bus platform: add driver serial8250 platform: Matched Device serial8250.0 with Driver serial8250 platform: Probing driver serial8250 with device serial8250.0 DEV: Unregistering device. ID = 'ttyS0' device_create_release called for ttyS0 serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A console [ttyS0] enabled DEV: registering device: ID = 'ttyS0' DEV: Unregistering device. ID = 'ttyS1' device_create_release called for ttyS1 serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 42) is a 16550A DEV: registering device: ID = 'ttyS1' bound device 'serial8250.0' to driver 'serial8250' platform: Bound Device serial8250.0 to Driver serial8250 platform: Matched Device serial8250 with Driver serial8250 platform: Probing driver serial8250 with device serial8250 bound device 'serial8250' to driver 'serial8250' platform: Bound Device serial8250 to Driver serial8250 bus pci: add driver serial loop: module loaded bus platform: add driver fsl-gianfar_mdio platform: Matched Device fsl-gianfar_mdio.-5 with Driver fsl-gianfar_mdio platform: Probing driver fsl-gianfar_mdio with device fsl-gianfar_mdio.-5 DEV: registering device: ID = 'e0024520:00' bus mdio_bus: add device e0024520:00 DEV: registering device: ID = 'e0024520:1f' bus mdio_bus: add device e0024520:1f Gianfar MII Bus: probed bound device 'fsl-gianfar_mdio.-5' to driver 'fsl-gianfar_mdio' platform: Bound Device fsl-gianfar_mdio.-5 to Driver fsl-gianfar_mdio bus platform: add driver fsl-gianfar platform: Matched Device fsl-gianfar.0 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.0 DEV: registering device: ID = 'eth0' eth0: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c4 eth0: Running with NAPI enabled eth0: 256/256 RX/TX BD ring size bound device 'fsl-gianfar.0' to driver 'fsl-gianfar' platform: Bound Device fsl-gianfar.0 to Driver fsl-gianfar platform: Matched Device fsl-gianfar.1 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.1 DEV: registering device: ID = 'eth1' eth1: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c5 eth1: Running with NAPI enabled eth1: 256/256 RX/TX BD ring size bound device 'fsl-gianfar.1' to driver 'fsl-gianfar' platform: Bound Device fsl-gianfar.1 to Driver fsl-gianfar platform: Matched Device fsl-gianfar.2 with Driver fsl-gianfar platform: Probing driver fsl-gianfar with device fsl-gianfar.2 DEV: registering device: ID = 'eth2' eth2: Gianfar Ethernet Controller Version 1.2, 00:d0:93:0e:4e:c6 eth2: Running with NAPI enabled eth2: 256/256 RX/TX BD ring size bound
Re: DS1337 RTC on I2C broken.
On Wed, 28 Nov 2007 19:25:00 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Well, as already mentioned, I have problems to get my DS1337 RTC on I2C on my MPC8540(ads like) PowerPC working properly on latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc as well as a 2.6.22-rc6-gb75ae860 is working fine. (mainstream's console is broken, so cannot test these, yet.) My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken and it also breaks the deprecated SENSORS_DS1337. :-( mmm. I've been told it should work ;) Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y this one must be deselected. CONFIG_SENSORS_DS1337=y CONFIG_SENSORS_DS1374=y ditto. DEV: registering device: ID = '0-0068' bus i2c: add device 0-0068 bound device '0-0068' to driver 'ds1337' maybe the wrong driver is kicking in here. the fact that there is no rtc class related output in dmesg should and that there is no /dev/rtc0 could be a sign that the whole class is not going in. do you have full dmesg? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Re: [rtc-linux] Re: DS1337 RTC on I2C broken.
On Wed, 28 Nov 2007 20:36:06 +0100 Clemens Koller [EMAIL PROTECTED] wrote: My current .config as well as the dmesg is attached with your suggested changes. one more test, please. can you try compiling rtc-ds1307 as a module and then kick it in via modprobe? -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
