All of lore.kernel.org
 help / color / mirror / Atom feed
* Device tree and external RTC
@ 2007-10-03 21:00 Bruce_Leonard
  2007-10-03 23:15 ` Bruce_Leonard
  2007-10-04 11:21 ` Peter Korsgaard
  0 siblings, 2 replies; 12+ messages in thread
From: Bruce_Leonard @ 2007-10-03 21:00 UTC (permalink / raw)
  To: linuxppc-embedded

Hi all,

I'm seriously confused by how things are supposed to work now with device 
trees on the PowerPC arch.  I'm bringing up our custom HW which is bassed 
on the mpc8347e, with an m41t00 RTC hanging off the i2c bus, U-boot is 
1.2.0, kernel is 2.6.22.  My problem is I can't get the kernel to access 
the RTC.  It works fine in U-boot, but nothing in the kernel.

Where I get confused is I'm not sure if this is something that the device 
tree is supposed to be telling the kernel about or if it's something that 
the kernel should probe for.  I've turned on everything in Kconfig I can 
find for I2C and RTC.  Here's what I think are the relavant parts of 
.config:

<snip># CONFIG_TCG_TPM is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=y

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y

#
# I2C Hardware Bus support
#
CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not set
CONFIG_I2C_ALI15X3=y
CONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
CONFIG_I2C_AMD8111=y
CONFIG_I2C_I801=y
CONFIG_I2C_I810=y
CONFIG_I2C_PIIX4=y
CONFIG_I2C_MPC=y
CONFIG_I2C_NFORCE2=y
# CONFIG_I2C_OCORES is not set
CONFIG_I2C_PARPORT_LIGHT=y
CONFIG_I2C_PROSAVAGE=y
# CONFIG_I2C_SAVAGE4 is not set
CONFIG_I2C_SIMTEC=y
CONFIG_I2C_SIS5595=y
CONFIG_I2C_SIS630=y
CONFIG_I2C_SIS96X=y
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
CONFIG_I2C_VIAPRO=y
CONFIG_I2C_VOODOO3=y

#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
CONFIG_SENSORS_M41T00=y
# CONFIG_SENSORS_MAX6875 is not set
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y

<snip>

#
# Real Time Clock
#
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_DEBUG=y

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
CONFIG_RTC_DRV_DS1307=y
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#

However, I get the following error when I run hwclock --debug:
hwclock from util-linux-2.12r
hwclock: Open of /dev/rtc failed, errno=19: No such device.  (note that 
the device is present with a major of 10 and a minor of 135)
No usable clock interface found.
Cannot access the Hardware Clock via any known method.

When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time, 
read_rtc_val, etc.) are all NULL.

I've searched through all the device tree files that come with the kernel 
and I can't find any that explicitly show an external device as a child 
node to a SoC I2C controller but it sure seems to me that the purpose of 
the device tree is to describe to the kernel all the hardware in the 
system.  Therefore it seems to me that there should be something like the 
following in the device tree:

<snip>
i2c@3000 {
        device_type = "i2c";
        compatible = "fsl-i2c";
        reg = <3000 100>;
        interrupts = <e 8>;
        interrupt-parent = < &ipic >;
        dfsrr;

        rtc@54 {
                device_type = "rtc";
                something;
                something;
                something;
        }
}
<snip>

I've googled for "device tree & rtc" and various other things that haven't 
poped out anything that really gives me any direction and 
booting_without_of.txt doesn't really help me very much because I think 
I'm just too dumb to understand it :-\.  (Took me two days to understand 
the ranges filed for the PCI node :(  ).

So, long winded way to get to it: Am I missing something in Kconfig for 
the kernel or am I missing something in the device tree?  Also, is there 
any place where things like the "dfsrr" attribute in the above device tree 
are described/defined?  I have no idea what that's supposed to mean and 
conversly I don't know what things are acceptable.  For example, if I need 
a RTC node in my device tree, what are the required attributes and what 
should the be set to?  Any direction as to where I should be looking to 
figure this sort of stuff out is greatly appreciated.

Sorry for the length of this post and thanks for any direction that can be 
provided.

Bruce

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-03 21:00 Device tree and external RTC Bruce_Leonard
@ 2007-10-03 23:15 ` Bruce_Leonard
  2007-10-03 23:33   ` Jon Smirl
                     ` (2 more replies)
  2007-10-04 11:21 ` Peter Korsgaard
  1 sibling, 3 replies; 12+ messages in thread
From: Bruce_Leonard @ 2007-10-03 23:15 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-embedded

linuxppc-embedded-bounces+brucle=selinc.com@ozlabs.org wrote on 10/03/2007 
02:00:49 PM:

> Hi all,
> 
> I'm seriously confused by how things are supposed to work now with 
device 
> trees on the PowerPC arch.  I'm bringing up our custom HW which is 
bassed 

<HUGE snip>

Follow up:

Okay, I figured out that I was indeed reading the clock (should have been 
using date command rather than hwclock command), so sorry for the noise. 
So what is is that hwclock is trying to do that it's unhappy about?

I still think I've got a valid question about the device tree.  Isn't the 
purpose of the device tree to completely describe the HW to the kernel? 
Shouldn't I be able to add a child node to the i2c node describing the 
M41T00 RTC and have the kernel figure out that there's an RTC hanging off 
the I2C bus?  Or am I completely off base here?

Bruce

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-03 23:15 ` Bruce_Leonard
@ 2007-10-03 23:33   ` Jon Smirl
  2007-10-04  0:59   ` linux ethernet problem jxnuxdy
  2007-10-04  9:29   ` Device tree and external RTC Guennadi Liakhovetski
  2 siblings, 0 replies; 12+ messages in thread
From: Jon Smirl @ 2007-10-03 23:33 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-embedded

On 10/3/07, Bruce_Leonard@selinc.com <Bruce_Leonard@selinc.com> wrote:
> I still think I've got a valid question about the device tree.  Isn't the
> purpose of the device tree to completely describe the HW to the kernel?
> Shouldn't I be able to add a child node to the i2c node describing the
> M41T00 RTC and have the kernel figure out that there's an RTC hanging off
> the I2C bus?  Or am I completely off base here?

I am having the same question about audio codecs. ALSA soc support is
designed to automatically load the right drivers depending on the
hardware in the device. Doesn't the device tree need to include the
codec chips? These chips are hooked up with various combinations of
i2s, ac97 and i2c.

-- 
Jon Smirl
jonsmirl@gmail.com

^ permalink raw reply	[flat|nested] 12+ messages in thread

* linux ethernet problem
  2007-10-03 23:15 ` Bruce_Leonard
  2007-10-03 23:33   ` Jon Smirl
@ 2007-10-04  0:59   ` jxnuxdy
  2007-10-04 11:45     ` Valentine Barshak
  2007-10-04  9:29   ` Device tree and external RTC Guennadi Liakhovetski
  2 siblings, 1 reply; 12+ messages in thread
From: jxnuxdy @ 2007-10-04  0:59 UTC (permalink / raw)
  To: linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Hi,    I use the 440epx CPU and bcm5241 PHY in my system, the ehternet works fine in u-boot, however I can't use the ethernet in linux if I didn't active the ehernet in u-boot(such as 'ping'... or 'tftp'...).    Is there anyone even encounter such problem? is the issue due to my u-boot or linux?  ,Regards- Denny

[-- Attachment #2: Type: text/html, Size: 805 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-03 23:15 ` Bruce_Leonard
  2007-10-03 23:33   ` Jon Smirl
  2007-10-04  0:59   ` linux ethernet problem jxnuxdy
@ 2007-10-04  9:29   ` Guennadi Liakhovetski
  2007-10-04 18:17     ` Bruce_Leonard
  2 siblings, 1 reply; 12+ messages in thread
From: Guennadi Liakhovetski @ 2007-10-04  9:29 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-embedded

On Wed, 3 Oct 2007 Bruce_Leonard@selinc.com wrote:

> I'm seriously confused by how things are supposed to work now with device 
> trees on the PowerPC arch.  I'm bringing up our custom HW which is bassed 
> on the mpc8347e, with an m41t00 RTC hanging off the i2c bus, U-boot is 
> 1.2.0, kernel is 2.6.22.  My problem is I can't get the kernel to access 
> the RTC.  It works fine in U-boot, but nothing in the kernel.
> 
> Where I get confused is I'm not sure if this is something that the device 
> tree is supposed to be telling the kernel about or if it's something that 
> the kernel should probe for.

i2c probing is not perfectly reliable, so, yes, you have to tell the i2c 
subsystem what i2c devices you have. There are several possibilities to do 
this currently in the kernel, one of which is using the device-tree, which 
is also the way I personally prefer:-)

> I've turned on everything in Kconfig I can 
> find for I2C and RTC.  Here's what I think are the relavant parts of 
> .config:

Let's see

...
> CONFIG_I2C_BOARDINFO=y

This is good.

> #
> # I2C Algorithms
> #
> CONFIG_I2C_ALGOBIT=y
> CONFIG_I2C_ALGOPCF=y
> CONFIG_I2C_ALGOPCA=y

You don't need any of these.

> #
> # I2C Hardware Bus support
> #
> CONFIG_I2C_ALI1535=y
> # CONFIG_I2C_ALI1563 is not set
> CONFIG_I2C_ALI15X3=y
> CONFIG_I2C_AMD756=y
> # CONFIG_I2C_AMD756_S4882 is not set
> CONFIG_I2C_AMD8111=y
> CONFIG_I2C_I801=y
> CONFIG_I2C_I810=y
> CONFIG_I2C_PIIX4=y
> CONFIG_I2C_MPC=y

You only have one i2c bus, I guess, and it is the one above: "I2C_MPC".

> CONFIG_I2C_NFORCE2=y
> # CONFIG_I2C_OCORES is not set
> CONFIG_I2C_PARPORT_LIGHT=y
> CONFIG_I2C_PROSAVAGE=y
> # CONFIG_I2C_SAVAGE4 is not set
> CONFIG_I2C_SIMTEC=y
> CONFIG_I2C_SIS5595=y
> CONFIG_I2C_SIS630=y
> CONFIG_I2C_SIS96X=y
> # CONFIG_I2C_STUB is not set
> # CONFIG_I2C_VIA is not set
> CONFIG_I2C_VIAPRO=y
> CONFIG_I2C_VOODOO3=y
> 
> #
> # Miscellaneous I2C Chip support
> #
> # CONFIG_SENSORS_DS1337 is not set
> # CONFIG_SENSORS_DS1374 is not set
> # CONFIG_SENSORS_EEPROM is not set
> # CONFIG_SENSORS_PCF8574 is not set
> # CONFIG_SENSORS_PCA9539 is not set
> # CONFIG_SENSORS_PCF8591 is not set
> CONFIG_SENSORS_M41T00=y

It shall not hurt, but do you really have this one?

> # CONFIG_SENSORS_MAX6875 is not set
> CONFIG_I2C_DEBUG_CORE=y
> CONFIG_I2C_DEBUG_ALGO=y
> CONFIG_I2C_DEBUG_BUS=y
> CONFIG_I2C_DEBUG_CHIP=y
> 
> <snip>
> 
> #
> # Real Time Clock
> #
> CONFIG_RTC_LIB=y
> CONFIG_RTC_CLASS=y
> CONFIG_RTC_HCTOSYS=y
> CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
> CONFIG_RTC_DEBUG=y
> 
> #
> # RTC interfaces
> #
> CONFIG_RTC_INTF_SYSFS=y
> CONFIG_RTC_INTF_PROC=y
> CONFIG_RTC_INTF_DEV=y
> # CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
> # CONFIG_RTC_DRV_TEST is not set
> 
> #
> # I2C RTC drivers
> #
> CONFIG_RTC_DRV_DS1307=y

Ok, so, this is your rtc.

> However, I get the following error when I run hwclock --debug:
> hwclock from util-linux-2.12r
> hwclock: Open of /dev/rtc failed, errno=19: No such device.  (note that 
> the device is present with a major of 10 and a minor of 135)
> No usable clock interface found.
> Cannot access the Hardware Clock via any known method.

First, this might be either a userspace or a kernel problem. Do you have 
the correct device nodes? Are you using udev? Should be something like

$ ls -l /dev/rtc*
lrwxrwxrwx 1 root root      4 Oct  4 10:44 /dev/rtc -> rtc0
crw-rw---- 1 root root 254, 0 Oct  4 10:44 /dev/rtc0

> When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time, 
> read_rtc_val, etc.) are all NULL.

Don't think you need those. Those are for powerpc platforms not using 
the generic rtc driver.

> I've searched through all the device tree files that come with the kernel 
> and I can't find any that explicitly show an external device as a child 
> node to a SoC I2C controller but it sure seems to me that the purpose of 
> the device tree is to describe to the kernel all the hardware in the 
> system.  Therefore it seems to me that there should be something like the 
> following in the device tree:
> 
> <snip>
> i2c@3000 {
>         device_type = "i2c";
>         compatible = "fsl-i2c";
>         reg = <3000 100>;
>         interrupts = <e 8>;
>         interrupt-parent = < &ipic >;
>         dfsrr;
> 
>         rtc@54 {
>                 device_type = "rtc";
>                 something;
>                 something;
>                 something;
>         }
> }
> <snip>

Yes, this is exactly what you need, if you don't want to hard code your 
rtc in the kernel board-specific code. I'm gessing, examples you were 
looking at are in arch/powerpc/boot/dts/kuroboxH[DG].dts. For this to work 
you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the 
i2c_devices array. I think, patch at 
http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you 
need.

Having applied the above patch and booted with the new kernel and 
device-tree, after "cd /proc/device-tree" and calling lsprop you should 
see something like

soc10x/i2c@80003000:
name             "i2c"
interrupt-parent 00000001
interrupts       00000005 00000002
reg              80003000 00001000
compatible       "fsl-i2c"
device_type      "i2c"
#size-cells      00000000
#address-cells   00000001

soc10x/i2c@80003000/rtc@32:
name             "rtc"
reg              00000032 (50)
compatible       "ricoh,rs5c372a"
device_type      "rtc"

Then you should have a directory like

/sys/devices/platform/fsl-i2c.0/i2c-adapter/i2c-0/0-0032

with a link in it like

lrwxrwxrwx 1 root root    0 Oct  4 11:00 driver -> ../../../../../../bus/i2c/drivers/rtc-rs5c372

dmesg should report something like

rtc-rs5c372 0-0032: rtc core: registered rtc-rs5c372 as rtc0

and

rtc-rs5c372 0-0032: setting the system clock to 2007-10-04 08:44:26 (1191487466)

Don't know what other messages ds1307 prints out.

> Okay, I figured out that I was indeed reading the clock (should have been 
> using date command rather than hwclock command), so sorry for the noise. 
> So what is is that hwclock is trying to do that it's unhappy about?

No, date is just giving you the system time, set either from rtc, or from 
an ntp server, or to 1.1.1970 on startup.

Thanks
Guennadi
---
Guennadi Liakhovetski

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-03 21:00 Device tree and external RTC Bruce_Leonard
  2007-10-03 23:15 ` Bruce_Leonard
@ 2007-10-04 11:21 ` Peter Korsgaard
  2007-10-04 18:25   ` Bruce_Leonard
  1 sibling, 1 reply; 12+ messages in thread
From: Peter Korsgaard @ 2007-10-04 11:21 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-embedded

>>>>> "Bruce" == Bruce Leonard <Bruce_Leonard@selinc.com> writes:

Hi,

 Bruce> I'm seriously confused by how things are supposed to work now
 Bruce> with device trees on the PowerPC arch.  I'm bringing up our
 Bruce> custom HW which is bassed on the mpc8347e, with an m41t00 RTC
 Bruce> hanging off the i2c bus, U-boot is 1.2.0, kernel is 2.6.22.
 Bruce> My problem is I can't get the kernel to access the RTC.  It
 Bruce> works fine in U-boot, but nothing in the kernel.
 Bruce> I've searched through all the device tree files that come with
 Bruce> the kernel 

 Bruce> and I can't find any that explicitly show an external device
 Bruce> as a child node to a SoC I2C controller but it sure seems to
 Bruce> me that the purpose of the device tree is to describe to the
 Bruce> kernel all the hardware in the system.  Therefore it seems to
 Bruce> me that there should be something like the following in the
 Bruce> device tree:

 Bruce> <snip>
 Bruce> i2c@3000 {
 Bruce>         device_type = "i2c";
 Bruce>         compatible = "fsl-i2c";
 Bruce>         reg = <3000 100>;
 Bruce>         interrupts = <e 8>;
 Bruce>         interrupt-parent = < &ipic >;
 Bruce>         dfsrr;

You need to add #address/size-cells to the I2C node, E.G.:
+			#address-cells = <1>;
+			#size-cells = <0>;

 Bruce>         rtc@54 {
 Bruce>                 device_type = "rtc";
 Bruce>                 something;
 Bruce>                 something;
 Bruce>                 something;
 Bruce>         }
 Bruce> }
 Bruce> <snip>

You need to set compatible and reg, E.G.
			rtc@54 {
				device_type = "rtc";
				compatible = "stm,m41t00";
				reg = <54>;
			};

And it should get picked up automatically by
fsl_soc.c:of_find_i2c_driver().

Notice that you will need to use galak's git tree
(git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git) or
apply the following patch:

http://ozlabs.org/pipermail/linuxppc-dev/2007-September/042896.html

As it isn't in mainline yet.

-- 
Bye, Peter Korsgaard

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: linux ethernet problem
  2007-10-04  0:59   ` linux ethernet problem jxnuxdy
@ 2007-10-04 11:45     ` Valentine Barshak
  0 siblings, 0 replies; 12+ messages in thread
From: Valentine Barshak @ 2007-10-04 11:45 UTC (permalink / raw)
  To: jxnuxdy; +Cc: linuxppc-embedded

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=x-gbk; format=flowed, Size: 976 bytes --]

jxnuxdy wrote:
> Hi,
>  
>    I use the 440epx CPU and bcm5241 PHY in my system, the ehternet works 
> fine in u-boot, however I can't use the ethernet in linux if I didn't 
> active the ehernet in u-boot(such as 'ping'... or 'tftp'...).
>  
>    Is there anyone even encounter such problem? is the issue due to my 
> u-boot or linux?

What kernel version do you use?
Please, make sure that phy is initialized by linux and the phy mode is 
correct.
IIRC, bcm5241 is connected to the ZMII bridge and works in SMII mode.
Thanks,
Valentine.

>  
>  
> ,Regards
> - Denny
> 
> 
> Íø Ò× Yeah.net Ãâ ·Ñ ÓÊ Ïä È« Р¸Ä °æ£¬Õä ²Ø ÕÊ ºÅ ¿ª ·Å£¬¿ì À´ ÇÀ ×¢ 
>  >> < http://event.mail.163.com/chanel/click.htm?from=NO_16&domain=163>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-04  9:29   ` Device tree and external RTC Guennadi Liakhovetski
@ 2007-10-04 18:17     ` Bruce_Leonard
  2007-10-04 19:52       ` Guennadi Liakhovetski
  0 siblings, 1 reply; 12+ messages in thread
From: Bruce_Leonard @ 2007-10-04 18:17 UTC (permalink / raw)
  To: Guennadi Liakhovetski; +Cc: linuxppc-embedded

Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06 
AM:

> > CONFIG_SENSORS_M41T00=y
> 
> It shall not hurt, but do you really have this one?

I turned this on because my clock is a SMT M41T00.  Not sure why it's 
called a sensor in the .config.
 
> First, this might be either a userspace or a kernel problem. Do you have 

> the correct device nodes? Are you using udev? Should be something like 

Ultimatly it was my own stupididty that did me in.  You are absolutly 
correct, I didn't have the right device nodes and because we're limited on 
space we don't want to use udev.  Once I created the rtc0 device and 
linked rtc to it, hwclock started working correctly.

> > When I dump out ppc_md, all the RTC functions (i.e., get_rtc_time, 
> > read_rtc_val, etc.) are all NULL.
> 
> Don't think you need those. Those are for powerpc platforms not using 
> the generic rtc driver. 

Right.

> you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the 
> i2c_devices array. I think, patch at 
> http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you 
> need. 

I'll give this a try.  I'd really prefer to be using the device tree for 
this, but I guess as long as I have it working using configuration options 
in the kernel it doesn't really matter.  Either way I don't have to write 
any special board support code for the kernel.

Thanks for all the information and pointers.  It's been a big help!

Bruce

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-04 11:21 ` Peter Korsgaard
@ 2007-10-04 18:25   ` Bruce_Leonard
  2007-10-05 10:45     ` Guennadi Liakhovetski
  0 siblings, 1 reply; 12+ messages in thread
From: Bruce_Leonard @ 2007-10-04 18:25 UTC (permalink / raw)
  To: Peter Korsgaard; +Cc: Peter Korsgaard, linuxppc-embedded

Peter,

Peter Korsgaard <jacmet@gmail.com> wrote on 10/04/2007 04:21:10 AM:

> >>>>> "Bruce" == Bruce Leonard <Bruce_Leonard@selinc.com> writes:
> 
> 
> You need to add #address/size-cells to the I2C node, E.G.:
> +         #address-cells = <1>;
> +         #size-cells = <0>;
> 
> 
> You need to set compatible and reg, E.G.
>          rtc@54 {
>             device_type = "rtc";
>             compatible = "stm,m41t00";
>             reg = <54>;
>          };
> 
> And it should get picked up automatically by
> fsl_soc.c:of_find_i2c_driver().
> 
> Notice that you will need to use galak's git tree

Thanks for the info.  It's this sort of thing that isn't clearly 
documented anywhere, and until I'm REALLY familiar with the kernel knowing 
where to look is a challenge.

A follow on question though.  I've looked at the patch and it seems to be 
just adding 6 lines to an existing array in fsl_soc.c.  However, I can't 
seem to find any array in fsl_soc.c that contains lines that the patch 
indicates should already be there (i.e., there's nothing in fsl_soc.c that 
has the word "ricoh" in it which the patch indicates it should).  Is my 
fsl_soc.c already out of date?  Will the patch apply?  I've got 2.6.22.

Bruce

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-04 18:17     ` Bruce_Leonard
@ 2007-10-04 19:52       ` Guennadi Liakhovetski
  0 siblings, 0 replies; 12+ messages in thread
From: Guennadi Liakhovetski @ 2007-10-04 19:52 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: linuxppc-embedded

On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/04/2007 02:29:06 
> AM:
> 
> > > CONFIG_SENSORS_M41T00=y
> > 
> > It shall not hurt, but do you really have this one?
> 
> I turned this on because my clock is a SMT M41T00.  Not sure why it's 
> called a sensor in the .config.

It is the deprecated driver for the same rtc chip. But maybe it is this 
one that makes your RTC work ATM, see below.

> > First, this might be either a userspace or a kernel problem. Do you have 
> 
> > the correct device nodes? Are you using udev? Should be something like 
> 
> Ultimatly it was my own stupididty that did me in.  You are absolutly 
> correct, I didn't have the right device nodes and because we're limited on 
> space we don't want to use udev.  Once I created the rtc0 device and 
> linked rtc to it, hwclock started working correctly.

It shouldn't. It probably does thanks to the m41t00 driver, but you don't 
want it, instead...

> > you need suitable entries in arch/powerpc/sysdev/fsl_soc.c in the 
> > i2c_devices array. I think, patch at 
> > http://patchwork.ozlabs.org/linuxppc/patch?id=13624 is exactly what you 
> > need. 
> 
> I'll give this a try.  I'd really prefer to be using the device tree for 
> this, but I guess as long as I have it working using configuration options 
> in the kernel it doesn't really matter.  Either way I don't have to write 
> any special board support code for the kernel.

you need this patch to get ds1307 attach to your rtc chip.

And, besides, linuxppc-embedded is deprecated, linuxppc-dev should be used 
instead:-)

Thanks
Guennadi
---
Guennadi Liakhovetski

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-04 18:25   ` Bruce_Leonard
@ 2007-10-05 10:45     ` Guennadi Liakhovetski
  2007-10-05 19:37       ` Bruce_Leonard
  0 siblings, 1 reply; 12+ messages in thread
From: Guennadi Liakhovetski @ 2007-10-05 10:45 UTC (permalink / raw)
  To: Bruce_Leonard; +Cc: Peter Korsgaard, linuxppc-embedded

On Thu, 4 Oct 2007 Bruce_Leonard@selinc.com wrote:

> A follow on question though.  I've looked at the patch and it seems to be 
> just adding 6 lines to an existing array in fsl_soc.c.  However, I can't 
> seem to find any array in fsl_soc.c that contains lines that the patch 
> indicates should already be there (i.e., there's nothing in fsl_soc.c that 
> has the word "ricoh" in it which the patch indicates it should).  Is my 
> fsl_soc.c already out of date?  Will the patch apply?  I've got 2.6.22.

Ok, we both (Peter and myself) have forgotten, that this change has first 
aooeared after 2.6.22. So, best try 2.6.23-rc9, or use one of the 
git-trees (from Linux or from Paulus, or from Kumar Gala, or...) _plus_ 
the patch we both pointed at.

Thanks
Guennadi
---
Guennadi Liakhovetski

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Device tree and external RTC
  2007-10-05 10:45     ` Guennadi Liakhovetski
@ 2007-10-05 19:37       ` Bruce_Leonard
  0 siblings, 0 replies; 12+ messages in thread
From: Bruce_Leonard @ 2007-10-05 19:37 UTC (permalink / raw)
  To: Guennadi Liakhovetski; +Cc: Peter Korsgaard, linuxppc-embedded

Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote on 10/05/2007 03:45:27 
AM:
> Ok, we both (Peter and myself) have forgotten, that this change has 
first 
> aooeared after 2.6.22. So, best try 2.6.23-rc9, or use one of the 
> git-trees (from Linux or from Paulus, or from Kumar Gala, or...) _plus_ 
> the patch we both pointed at.

Thanks Guennadi, that's what I was starting to think, that I was going to 
have to get something newer.  Thanks to both you and Peter for the help. I 
really appreciate it.

Bruce

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2007-10-05 19:37 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-03 21:00 Device tree and external RTC Bruce_Leonard
2007-10-03 23:15 ` Bruce_Leonard
2007-10-03 23:33   ` Jon Smirl
2007-10-04  0:59   ` linux ethernet problem jxnuxdy
2007-10-04 11:45     ` Valentine Barshak
2007-10-04  9:29   ` Device tree and external RTC Guennadi Liakhovetski
2007-10-04 18:17     ` Bruce_Leonard
2007-10-04 19:52       ` Guennadi Liakhovetski
2007-10-04 11:21 ` Peter Korsgaard
2007-10-04 18:25   ` Bruce_Leonard
2007-10-05 10:45     ` Guennadi Liakhovetski
2007-10-05 19:37       ` Bruce_Leonard

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.