After more and more experimenting I now tried this config:

$ fgrep I2C kernel/.config
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
# I2C Algorithms
# CONFIG_I2C_ALGOBIT is not set
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
# I2C Hardware Bus support
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# Miscellaneous I2C Chip support
CONFIG_I2C_DEBUG_CORE=y
CONFIG_I2C_DEBUG_ALGO=y
CONFIG_I2C_DEBUG_BUS=y
CONFIG_I2C_DEBUG_CHIP=y

There is no I2C algoritm enabled and no Hardware Bus support.
With that the only i2c related messages I see in dmesg:

i2c-core: driver [pcf8563] registered
i2c-core: driver [pcf8583] registered

and the

Write I2C device 0x13 failed.

Finally,

/sys/bus/i2c/devices

exists but is completely empty.

Finally, i2cdump reports:

Error: No I2C busses found!

So I now think that the I2C chip driver is not working or not enabled.

Does anyone know where to look for this? How does the JZ4730 I2C interface work? Do we need to do some board-configuration for initialization/registration?

BR,
Nikolaus

Am 02.05.2010 um 13:55 schrieb Dr. H. Nikolaus Schaller:

Hi Steve,
the thread is getting longer and longer.

Am 02.05.2010 um 02:10 schrieb Steve Arnold:

On Sat, 1 May 2010 21:18:38 +0200
"Dr. H. Nikolaus Schaller" <h...@computer.org> wrote:

By looking into source file: this means
rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE) returns NULL.
CONFIG_RTC_HCTOSYS_DEVICE is "rtc0".

The "normal" or standard devices you should get with udev are:

lrwxrwxrwx 1 root root      4 2010-05-01 07:29 /dev/rtc -> rtc0
crw-rw---- 1 root root 254, 0 2010-05-01 07:29 /dev/rtc0

What I see is

crw-rw---- 1 root audio  10, 135 Jan  1  1970  /dev/rtc

and no link. This means that the "old" driver is active.

But this is all consistent with /sys/class/misc/rtc/dev or .../uevent


assuming you have the actual device driver(s) loaded.

So I think there are two possibilities for the rtc0 device not
showing up: 1) the i2c dependency is not being met, or 2) maybe
udev is having trouble creating the device.


$ fgrep RTC .config
# CONFIG_RTC is not set
CONFIG_RTC_PCF8563=y
# CONFIG_RTC_JZ is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_RTC_INTF_PROC is not set
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 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# 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=y
# CONFIG_RTC_DRV_M41T80 is not set
# SPI RTC drivers
# Platform RTC drivers
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_V3020 is not set
# on-CPU RTC drivers

Hm. Finally I had an idea:

$ find /sys -name '*rtc*'
/sys/class/misc/rtc
/sys/class/rtc
/sys/module/rtc_pcf8583

So it may be as simple as changing

CONFIG_RTC_HCTOSYS_DEVICE="rtc0"

to

CONFIG_RTC_HCTOSYS_DEVICE="rtc"

This was too optimistic... Does not change anything (except that "rtc" appears in the error message instead of "rtc0").


It looks like you have two Phillips drivers enabled; I would
disable one of them.  Have you tried the RTC_JZ driver yet?  Or is
it just a stub?

In general, I think the rtc0 device stuff in dmesg really depends on
what gets created under /dev rather than what you see under /sys.
If the right device appears in /sys then you should get something
under /dev (with an appropriate udev rule).

I have compared the udev rules with an i386 lenny - it is the same

/etc/udev/rules.d/50-udev.rules (here it says SUBSYSTEM=="rtc", DRIVERS=="rtc_cmos", SYMLINK+="rtc") /etc/udev/rules.d/90-permissions.rules (this is where the root:audio comes from)


And by old and new rtc drivers I meant the (old) ones under:

Device Drivers  --->
Character devices  --->
 Enhanced Real Time Clock Support (legacy PC RTC driver)

this is disabled

 Generic /dev/rtc emulation
 ...
 HPET Timer  <= this one works with both
 ...

does not show up.
But there is an entry

[*] Philips PCF8563 Real Time CLock (I2C Bus)

I will try to disable this as well.

vs. the ones under:

Device Drivers  --->
Real Time Clock  --->
 /sys/class/rtc/rtcN (sysfs)

[*]

 /proc/driver/rtc (procfs for rtc0)

[ ]

 /dev/rtcN (character devices)

[*]

 ...

and then, I find: <*>   Philips PCF8583

Hm. I think I did read at

http://projects.kwaak.net/twiki/bin/view/Epc700/HardwareLayout

that we have an PCF8563 and not a PCF8583 inside?


The first two options under the (old) Char device section only
appear if the (newer) Real Time Clock section is disabled.  There
are lots of device-specific drivers in the latter section
(including the Phillips drivers) but not the JZ driver (at least in
the vanilla kernel).  Question: does RTC_JZ appear under the bottom
section "on-CPU RTC drivers"?

No.


It looks to me like your "CONFIG_RTC_PCF8563=y" is an older driver,
while the newer one is dsiabled (along with the RTC_JZ driver).

What happens if you disable the first one and enable the second one?

What happens if you enable "CONFIG_RTC_DRV_PCF8563" instead?

My $.02 would be to make sure the (old) ones are disabled and only
enable stuff under the new Real Time Clock section.  Not sure about
HPET in this context; I guess you can try it both ways and see...

Here's what I get on an embedded powerpc board with an older 2.6.15
kernel and udev-079-r1 install:

lrwxrwxrwx 1 root root 8 Apr 18 13:15 /dev/rtc -> misc/rtc

so I guess the version of the kernel and/or udev is old enough that
it doesn't even create the rtc0 device (or a symlink). Do you see
anything under /sys/devices like this:

/sys/devices/pnp0/00:05/rtc
/sys/devices/pnp0/00:05/rtc/rtc0

No. Just usb, serial, cpu, lcd and other stuff but not rtc.


On the above embedded board I only see this:

/sys/class/misc/rtc

After changing the config, I find /sys/class/rtc and /sys/modules/ rtc_pcf8563 but they are empty.



Anyway, hope this helps somehow...

Definitively!

But changing the config did not make it work.

I have now added some printk() to the hcttosys functions and

struct rtc_device *rtc_class_open(char *name)
{
        struct device *dev;
        struct rtc_device *rtc = NULL;
        printk(KERN_EMERG "rtc_class_open(name=%s)\n", name);

        down(&rtc_class->sem);
        list_for_each_entry(dev, &rtc_class->devices, node) {
                printk(KERN_EMERG "dev->bus_id=%s name=%s\n", dev->bus_id, 
name);
                if (strncmp(dev->bus_id, name, BUS_ID_SIZE) == 0) {
                        dev = get_device(dev);
                        if (dev)
                                rtc = to_rtc_device(dev);
                        break;
                }
        }

        if (rtc) {
                if (!try_module_get(rtc->owner)) {
                        put_device(dev);
                        rtc = NULL;
                }
        }
        up(&rtc_class->sem);

        return rtc;
}

shows that list_for_each_entry(dev, &rtc_class->devices, node) { } does not loop. I.e. the rtc_class->devices appears to be empty.

Additional printk() have shown that rtc_init is called, the class_create() is successful and both rtc_sysfs_init() and rtc_dev_init() are called. Both are included in the .config. Disabling the CONFIG_RTC_INTF_DEV had no visible effect (except removing my printk message).

So, something is wrong with the initialization of these kernel structures. So the question is where rtc_class->devices should be initialized/populated.

Finally I have studied http://www.mjmwired.net/kernel/Documentation/rtc.txt and accodting to that document /sys/class/rtc should not be an empty directory but show rtc0...

BR,
Nikolaus

_______________________________________________
Mipsbook-devel mailing list
Mipsbook-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel


_______________________________________________
Mipsbook-devel mailing list
Mipsbook-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/mipsbook-devel

Reply via email to