DS1337 RTC on I2C broken.

Hi, there!

(Only subscribed to linuxppc-embedded and lkml; otherwise, please CC)

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. :-(

Before I start bisecting and digging in the code (I'm booting from flash, so it isn't fun to change kernels on the fly), I just want to verify that my configuration is correct.

I am using hwclock-2.31 from Bryan Henderson since the one which comes with util-linux doesn't support to choose another rtc device than /dev/rtc.

Here is a snippet from my .config which is similar among my kernels. CONFIG_GEN_RTC=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_I2C_MPC=y
CONFIG_SENSORS_DS1337=y
CONFIG_SENSORS_DS1374=y
CONFIG_SENSORS_EEPROM=y
CONFIG_SENSORS_M41T00=y
CONFIG_HWMON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DEBUG=y
CONFIG_RTC_DRV_DS1307=y
CONFIG_RTC_DRV_PCF8563=y
CONFIG_RTC_DRV_TEST=m
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_LIB=y

So, I enabled both, the new rtc-lib DS1307 (which is compatible to the DS1337) and the deprecated SENSORS_DS1337.
Deselecting SENSORS_* doesn't help.

My /etc/udev/rules.d/50-udev-default.rules contains the line:
KERNEL=="rtc[0-9]*", MODE="0666"

When the RTC is working, I get the following:

dmesg:
------
i2c /dev entries driver
ds1307 0-0068: rtc core: registered ds1307 as rtc0
ds1307 0-0068: setting the system clock to 2007-11-28 18:56:33 (1196276193)

and I get:

root@fox_1:/dev$ l rtc*
crw-r--r-- 1 root root  10, 135 Jan  1  2000 rtc
crw-rw---- 1 root root 239,   0 Jan  1  2000 rtc0
(Jan 1 2000 is the default date when the rtc chip was powered down, so the
rtc was read successfully.)

$hwclock --systohc --rtc /dev/rtc0
is working properly...

When it's NOT working (2.6.24-rc2-git with some debugging enabled) I get:

dmesg:
------
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c bus i2c: add driver ds1337
DEV: registering device: ID = '0-0068'
bus i2c: add device 0-0068
bound device '0-0068' to driver 'ds1337'
bus i2c: add driver lm75
DEV: registering device: ID = '0-0048'
bus i2c: add device 0-0048
bound device '0-0048' to driver 'lm75'
DEV: registering device: ID = 'hwmon0'
bus i2c: add driver max6650

$ ls /dev/rt*
crw-r--r-- 1 root root  10, 135 Jan  1  1970 rtc

and

$ cat /proc/driver/rtc
rtc_time        : 00:00:570426440
rtc_date        : 269131772-01-00
rtc_epoch       : 1900
alarm           : 00:00:00
DST_enable      : no
BCD             : yes
24hr            : yes
square_wave     : no
alarm_IRQ       : no
update_IRQ      : no
periodic_IRQ    : no
periodic_freq   : 0
batt_status     : okay

shows up but these values never seem to get an update. (==stable among reboots) :-(

My /etc/udev/50-udev-default.rules
contains
KERNEL=="rtc", MODE="0644"

Any ideas to debug?

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

mmm. I've been told it should work ;)

this one must be deselected.

ditto.

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

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.

Will do.

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

My current
.config as well as the dmesg is attached with your suggested changes.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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 device 'fsl-gianfar.2' to driver 'fsl-gianfar'
platform: Bound Device fsl-gianfar.2 to Driver fsl-gianfar
bus mdio_bus: add driver Marvell 88E1101
bus mdio_bus: add driver Marvell 88E1112
bus mdio_bus: add driver Marvell 88E1111
mdio_bus: Matched Device e0024520:00 with Driver Marvell 88E1111
mdio_bus: Probing driver Marvell 88E1111 with device e0024520:00
bound device 'e0024520:00' to driver 'Marvell 88E1111'
mdio_bus: Bound Device e0024520:00 to Driver Marvell 88E1111
bus mdio_bus: add driver Marvell 88E1145
bus mdio_bus: add driver Marvell 88E1240
bus mdio_bus: add driver LXT970
bus mdio_bus: add driver LXT971
DEV: registering device: ID = 'dummy0'
device class 'scsi_disk': registering
bus scsi: add driver sd
bus pci: add driver sata_promise
pci: Matched Device 0000:00:12.0 with Driver sata_promise
pci: Probing driver sata_promise with device 0000:00:12.0
sata_promise 0000:00:12.0: version 2.11
scsi0 : sata_promise
DEV: registering device: ID = 'host0'
CLASS: registering class device: ID = 'host0'
class_uevent - name = host0
scsi1 : sata_promise
DEV: registering device: ID = 'host1'
CLASS: registering class device: ID = 'host1'
class_uevent - name = host1
scsi2 : sata_promise
DEV: registering device: ID = 'host2'
CLASS: registering class device: ID = 'host2'
class_uevent - name = host2
ata1: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000200 irq 18
ata2: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000280 irq 18
ata3: PATA max UDMA/133 mmio m4096@0x80000000 port 0x80000300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
DEV: registering device: ID = 'target0:0:0'
scsi 0:0:0:0: Direct-Access ATA FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
DEV: registering device: ID = '0:0:0:0'
bus scsi: add device 0:0:0:0
scsi: Matched Device 0:0:0:0 with Driver sd
scsi: Probing driver sd with device 0:0:0:0
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
bound device '0:0:0:0' to driver 'sd'
scsi: Bound Device 0:0:0:0 to Driver sd
CLASS: registering class device: ID = '0:0:0:0'
class_uevent - name = 0:0:0:0
bound device '0000:00:12.0' to driver 'sata_promise'
pci: Bound Device 0000:00:12.0 to Driver sata_promise
bus pci: add driver pata_pdc2027x
usbmon: debugfs is not available
bus pci: add driver ehci_hcd
pci: Matched Device 0000:00:14.2 with Driver ehci_hcd
pci: Probing driver ehci_hcd with device 0000:00:14.2
ehci_hcd 0000:00:14.2: EHCI Host Controller
CLASS: registering class device: ID = 'usb_host1'
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
ehci_hcd 0000:00:14.2: new USB bus registered, assigned bus number 1 ehci_hcd 0000:00:14.2: irq 20, io mem 0x81202000
ehci_hcd 0000:00:14.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
DEV: registering device: ID = 'usb1'
bus usb: add device usb1
usb: Matched Device usb1 with Driver usb
usb: Probing driver usb with device usb1
device class 'usb_endpoint': registering
DEV: registering device: ID = 'usbdev1.1_ep00'
usb usb1: configuration #1 chosen from 1 choice
DEV: registering device: ID = '1-0:1.0'
bus usb: add device 1-0:1.0
usb: Matched Device 1-0:1.0 with Driver hub
usb: Probing driver hub with device 1-0:1.0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
bound device '1-0:1.0' to driver 'hub'
usb: Bound Device 1-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev1.1_ep81'
DEV: registering device: ID = 'usbdev1.1'
bound device 'usb1' to driver 'usb'
usb: Bound Device usb1 to Driver usb
bound device '0000:00:14.2' to driver 'ehci_hcd'
pci: Bound Device 0000:00:14.2 to Driver ehci_hcd
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
bus of_platform: add driver ppc-of-ohci
bus pci: add driver ohci_hcd
pci: Matched Device 0000:00:14.0 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.0
ohci_hcd 0000:00:14.0: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host2'
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
ohci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:14.0: irq 20, io mem 0x81200000
DEV: registering device: ID = 'usb2'
bus usb: add device usb2
usb: Matched Device usb2 with Driver usb
usb: Probing driver usb with device usb2
DEV: registering device: ID = 'usbdev2.1_ep00'
usb usb2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '2-0:1.0'
bus usb: add device 2-0:1.0
usb: Matched Device 2-0:1.0 with Driver hub
usb: Probing driver hub with device 2-0:1.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
bound device '2-0:1.0' to driver 'hub'
usb: Bound Device 2-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev2.1_ep81'
DEV: registering device: ID = 'usbdev2.1'
bound device 'usb2' to driver 'usb'
usb: Bound Device usb2 to Driver usb
bound device '0000:00:14.0' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.0 to Driver ohci_hcd
pci: Matched Device 0000:00:14.1 with Driver ohci_hcd
pci: Probing driver ohci_hcd with device 0000:00:14.1
ohci_hcd 0000:00:14.1: OHCI Host Controller
CLASS: registering class device: ID = 'usb_host3'
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
ohci_hcd 0000:00:14.1: new USB bus registered, assigned bus number 3 ohci_hcd 0000:00:14.1: irq 20, io mem 0x81201000
DEV: registering device: ID = 'usb3'
bus usb: add device usb3
usb: Matched Device usb3 with Driver usb
usb: Probing driver usb with device usb3
DEV: registering device: ID = 'usbdev3.1_ep00'
usb usb3: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-0:1.0'
bus usb: add device 3-0:1.0
usb: Matched Device 3-0:1.0 with Driver hub
usb: Probing driver hub with device 3-0:1.0
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
bound device '3-0:1.0' to driver 'hub'
usb: Bound Device 3-0:1.0 to Driver hub
DEV: registering device: ID = 'usbdev3.1_ep81'
DEV: registering device: ID = 'usbdev3.1'
bound device 'usb3' to driver 'usb'
usb: Bound Device usb3 to Driver usb
bound device '0000:00:14.1' to driver 'ohci_hcd'
pci: Bound Device 0000:00:14.1 to Driver ohci_hcd
Initializing USB Mass Storage driver...
bus usb: add driver usb-storage
usb 3-2: new low speed USB device using ohci_hcd and address 2
DEV: registering device: ID = '3-2'
bus usb: add device 3-2
usb: Matched Device 3-2 with Driver usb
usb: Probing driver usb with device 3-2
DEV: registering device: ID = 'usbdev3.2_ep00'
usb 3-2: configuration #1 chosen from 1 choice
DEV: registering device: ID = '3-2:1.0'
bus usb: add device 3-2:1.0
DEV: registering device: ID = 'usbdev3.2_ep81'
DEV: registering device: ID = 'usbdev3.2'
bound device '3-2' to driver 'usb'
usb: Bound Device 3-2 to Driver usb
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
bus type 'usb-serial' registered
bus usb: add driver usbserial
usbcore: registered new interface driver usbserial
bus usb-serial: add driver generic
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic bus usb: add driver usbserial_generic
usb: Matched Device 3-2:1.0 with Driver usbserial_generic
usb: Probing driver usbserial_generic with device 3-2:1.0
usbcore: registered new interface driver usbserial_generic drivers/usb/serial/usb-serial.c: USB Serial Driver core
bus usb-serial: add driver ftdi_sio
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device bus usb: add driver ftdi_sio
usbcore: registered new interface driver ftdi_sio drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
bus usb-serial: add driver pl2303
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303 bus usb: add driver pl2303
usbcore: registered new interface driver pl2303 drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
DEV: registering device: ID = 'mice'
DEV: registering device: ID = 'psaux'
mice: PS/2 mouse device common for all mice
bus usb: add driver usbtouchscreen
usb: Matched Device 3-2:1.0 with Driver usbtouchscreen
usb: Probing driver usbtouchscreen with device 3-2:1.0
DEV: registering device: ID = 'input0'
input: TSC-10 DM as /devices/pci0000:00/0000:00:14.1/usb3/3-2/3-2:1.0/input/input0
DEV: registering device: ID = 'mouse0'
DEV: registering device: ID = 'event0'
bound device '3-2:1.0' to driver 'usbtouchscreen'
usb: Bound Device 3-2:1.0 to Driver usbtouchscreen
usbcore: registered new interface driver usbtouchscreen
bus i2c: add driver rtc-ds1307
i2c /dev entries driver
device class 'i2c-dev': registering
bus i2c: add driver dev_driver
bus platform: add driver fsl-i2c
platform: Matched Device fsl-i2c.0 with Driver fsl-i2c
platform: Probing driver fsl-i2c with device fsl-i2c.0
DEV: registering device: ID = 'i2c-0'
DEV: registering device: ID = 'i2c-0'
bound device 'fsl-i2c.0' to driver 'fsl-i2c'
platform: Bound Device fsl-i2c.0 to Driver fsl-i2c
bus usb: add driver usbhid
usbcore: registered new interface driver usbhid drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
DEV: registering device: ID = 'sit0'
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
driver_probe_done: probe_count = 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 120k init
class_uevent - name = 0000:00
class_uevent - name = 0:0:0:0
class_uevent - name = 0:0:0:0
class_uevent - name = host0
class_uevent - name = host1
class_uevent - name = host2
class_uevent - name = usb_host1
class_device_create_uevent called for usb_host1
class_uevent - name = usb_host2
class_device_create_uevent called for usb_host2
class_uevent - name = usb_host3
class_device_create_uevent called for usb_host3
EXT3 FS on sda1, internal journal
Adding 2939884k swap on /dev/sda2. Priority:-1 extents:1 across:2939884k
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: Unregistering device. ID = 'vcs1'
device_create_release called for vcs1
DEV: Unregistering device. ID = 'vcsa1'
device_create_release called for vcsa1
DEV: registering device: ID = 'vcs1'
DEV: registering device: ID = 'vcsa1'
DEV: registering device: ID = 'vcs2'
DEV: registering device: ID = 'vcsa2'
DEV: registering device: ID = 'vcs3'
DEV: registering device: ID = 'vcsa3'
DEV: registering device: ID = 'vcs5'
DEV: registering device: ID = 'vcsa5'
DEV: registering device: ID = 'vcs6'
DEV: registering device: ID = 'vcsa6'
DEV: registering device: ID = 'vcs4'
DEV: registering device: ID = 'vcsa4'
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present

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

Hello, Allessandro!

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Hello all,

I am trying to use some devices on i2c protocol, one of them is the DS1= 337
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 th= ere
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=FAl Moreno

Clemens Koller <[email protected]>
Clemens Koller
Enviado por:
linuxppc-embedded-bounces+raul.moreno=3Dtelvent.abengoa.com@ozlabs.org 29/11/2007 12:24

                                                                       =

Para: Alessandro Zummo <[email protected]> =

                                                                       =

                                                                       =

Asunto: Re: DS1337 RTC on I2C broken. =

                                                                       =

Hello, Allessandro!

I2C

4cc

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Stra=DFe 45/1
Linhof Werksgel=E4nde
D-81379 M=FCnchen
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=

Hello, Raul!

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

the fsl-i2c might be the right place

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Hi There!

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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

Hi, Alessandro!

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

you never know those pesky chips ;)

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

Hello, Alessandro!

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

root@ecam:~$ dmesg
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.24-rc3-g09f345da (clemens@ecam) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:38 CET 2007
Found legacy serial port 0 for /soc8540@e0000000/serial@4500
  mem=e0004500, taddr=e0004500, irq=0, clk=330000000, speed=0
Found legacy serial port 1 for /soc8540@e0000000/serial@4600
  mem=e0004600, taddr=e0004600, irq=0, clk=330000000, speed=0
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
Top of RAM: 0x10000000, Total RAM: 0x10000000
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 e0040000, 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.250000 MHz
time_init: processor frequency   = 825.000000 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 0000:00:12.0
PCI: Cannot allocate resource region 1 of device 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.0
PCI: Cannot allocate resource region 3 of device 0000:00:12.0
PCI: Cannot allocate resource region 4 of device 0000:00:12.0
PCI: Cannot allocate resource region 0 of device 0000:00:14.0
PCI: Cannot allocate resource region 2 of device 0000: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 0000:00:14.0: version 2.11
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0x80004000 port 0x80004200 irq 19
ata2: SATA max UDMA/133 mmio m4096@0x80004000 port 0x80004280 irq 19
ata3: PATA max UDMA/133 mmio m4096@0x80004000 port 0x80004300 irq 19
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
pata_pdc2027x 0000:00:12.0: version 1.0
pata_pdc2027x 0000:00:12.0: PLL input clock 32997 kHz
scsi3 : pata_pdc2027x
scsi4 : pata_pdc2027x
ata4: PATA max UDMA/133 mmio m16384@0x80000000 cmd 0x800017c0 irq 18
ata5: PATA max UDMA/133 mmio m16384@0x80000000 cmd 0x800015c0 irq 18
ata4.00: ATA-7: Maxtor 6B120P0, BAH41BM0, max UDMA/133
ata4.00: 240121728 sectors, multi 0: LBA
ata4.00: limited to UDMA/33 due to 40-wire cable
ata4.00: configured for UDMA/33
scsi 3:0:0:0: Direct-Access     ATA      Maxtor 6B120P0   BAH4 PQ: 0 ANSI: 5
sd 3:0:0:0: [sdb] 240121728 512-byte hardware sectors (122942 MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sdb] 240121728 512-byte hardware sectors (122942 MB)
sd 3:0:0:0: [sdb] Write Protect is off
sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 >
sd 3:0:0:0: [sdb] Attached SCSI disk
usbmon: debugfs is not available
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
usbcore: registered new interface driver usbtouchscreen
i2c-core: driver [rtc-ds1307] registered
i2c-core: driver [pcf8563] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-adapter i2c-0: adapter [MPC adapter] registered
i2c-dev: adapter [MPC adapter] registered as minor 0
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k init
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sdb3, internal journal
ReiserFS: sdb6: found reiserfs format "3.6" with standard journal
ReiserFS: sdb6: using ordered data mode
ReiserFS: sdb6: journal params: device sdb6, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: sdb6: checking transaction log (sdb6)
ReiserFS: sdb6: Using r5 hash to sort names
Adding 500432k swap on /dev/sdb5.  Priority:-1 extents:1 across:500432k
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present

root@ecam:~$ 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: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- 51 -- -- -- -- -- -- 58 59 5a 5b 5c 5d 5e 5f
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@ecam:~$ i2cdump 0 0x51 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x51, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
10: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
20: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
30: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
40: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
50: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
60: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
70: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
80: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
90: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
a0: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b0 33 00    ..3@?05??w????3.
b0: 00 00 33 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00    ..3@?05??w????7.
c0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00    ..4@?05??w????7.
d0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00    ..4@?05??w????7.
e0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00    ..4@?05??w????7.
f0: 00 00 34 40 13 30 35 b1 07 77 c0 c0 c0 b4 37 00    ..4@?05??w????7.
root@ecam:~$ i2cdump 0 0x51 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x51, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
10: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
20: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
30: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
40: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
50: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
60: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
70: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
80: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
90: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
a0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
b0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
c0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
d0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
e0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
f0: 00 40 44 40 53 70 45 d1 07 77 c0 c0 c0 c4 47 00    .@D@SpE??w????G.
root@ecam:~$

PCF8563 is ticking...

====================================================
HOST FOX_1

root@fox_1:~$ dmesg
Using MPC85xx ADS machine description
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.24-rc3-g09f345da (clemens@fox_1) (gcc version 4.2.2 (ckcore)) #2 Fri Nov 30 13:06:37 CET 2007
Found legacy serial port 0 for /soc8540@e0000000/serial@4500
  mem=e0004500, taddr=e0004500, irq=0, clk=333333330, speed=0
Found legacy serial port 1 for /soc8540@e0000000/serial@4600
  mem=e0004600, taddr=e0004600, irq=0, clk=333333330, speed=0
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Found FSL PCI host bridge at 0x00000000e0008000.Firmware bus number: 0->0
Top of RAM: 0x10000000, Total RAM: 0x10000000
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/sda1 ro console=ttyS0,115200
mpic: Setting up MPIC " OpenPIC  " version 1.2 at e0040000, 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.666666 MHz
time_init: processor frequency   = 833.333325 MHz
clocksource: timebase mult[6000002] shift[22] registered
clockevent: decrementer mult[aaa] 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... 83.20 BogoMIPS (lpj=166400)
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 0000:00:12.0
PCI: Cannot allocate resource region 2 of device 0000:00:12.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:d0:93:0e:4e:c4
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
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
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
sata_promise 0000:00:12.0: version 2.11
scsi0 : sata_promise
scsi1 : sata_promise
scsi2 : sata_promise
ata1: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000200 irq 18
ata2: SATA max UDMA/133 mmio m4096@0x80000000 port 0x80000280 irq 18
ata3: PATA max UDMA/133 mmio m4096@0x80000000 port 0x80000300 irq 18
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: FUJITSU MHW2100BH, 00000012, max UDMA/100
ata1.00: 195371568 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/100
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      FUJITSU MHW2100B 0000 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 195371568 512-byte hardware sectors (100030 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
usbmon: debugfs is not available
ehci_hcd 0000:00:14.2: EHCI Host Controller
ehci_hcd 0000:00:14.2: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:14.2: irq 20, io mem 0x81202000
ehci_hcd 0000:00:14.2: USB 2.0 started, EHCI 0.95, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:14.0: OHCI Host Controller
ohci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
ohci_hcd 0000:00:14.0: irq 20, io mem 0x81200000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ohci_hcd 0000:00:14.1: OHCI Host Controller
ohci_hcd 0000:00:14.1: new USB bus registered, assigned bus number 3
ohci_hcd 0000:00:14.1: irq 20, io mem 0x81201000
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 3-2: new low speed USB device using ohci_hcd and address 2
usb 3-2: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver
drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
usbcore: registered new interface driver pl2303
drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
mice: PS/2 mouse device common for all mice
input: TSC-10 DM as /devices/pci0000:00/0000:00:14.1/usb3/3-2/3-2:1.0/input/input0
usbcore: registered new interface driver usbtouchscreen
i2c-core: driver [rtc-ds1307] registered
i2c-core: driver [pcf8563] registered
i2c /dev entries driver
i2c-core: driver [dev_driver] registered
i2c-adapter i2c-0: adapter [MPC adapter] registered
i2c-dev: adapter [MPC adapter] registered as minor 0
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
NET: Registered protocol family 17
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 124k init
EXT3 FS on sda1, internal journal
Adding 2939884k swap on /dev/sda2.  Priority:-1 extents:1 across:2939884k
PHY: e0024520:00 - Link is Up - 100/Half
eth0: no IPv6 routers present

root@fox_1:~$ 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: 50 -- -- -- -- -- -- 57 -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
root@fox_1:~$ i2cdump 0 0x68 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x68, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 55 00 15 06 30 11 07 00 00 00 00 00 00 00 00 00    U.??0??.........
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
root@fox_1:~$ i2cdump 0 0x68 b
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0, address 0x68, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 03 01 15 06 30 11 07 00 00 00 00 00 00 00 00 00    ????0??.........
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX    XXXXXXXXXXXXXXXX
root@fox_1:~$

DS1337 is also working.

=====================================================

Alessandro, if you cannot help me here right now, can you please give me some pointers to documentation and to the desired calling tree of the kernel's new RTC stuff to get me started with debugging?

My next step is to try it all modular... hence that won't be a solution for me. (I don't wan't modules at all.)

Thank you a lot,
best regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Hi, Alessandro!

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module                  Size  Used by

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307

root@fox_1:/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)!

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc

root@fox_1:/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:

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ lsmod
Module                  Size  Used by

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe i2c-mpc

root@fox_1:/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

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$ modprobe rtc-ds1307

root@fox_1:/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

root@fox_1:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/i2c/busses$ cd /dev

root@fox_1:/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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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

[..]

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

ds1307 requires you to register i2c_board_info for it to probe properly. Does your platform do so?

-Olof

Hi, Alessandro, Hi, Olof!

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Hello, Olof!

Finally, it works! *sigh* - Thank your for your hint to i2c_board_info!

My platform includes i2c_board_info with some i2c-devices but only uses them if the device-tree includes the devices.

[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. Now, the way is like this:

- enable the desired driver in the kernel.
- check that the platform driver fsl_soc.c (in my case) defines the desired rtc-chip in the i2c_board_info
- check that the rtc is included in the device tree.
- embed the device tree to the kernel (cuImage)
- 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!

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. Hmmm... this just s****!

[OT+sarcasm off]

Thank you,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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

index 112279b..ab39d61 100644
@@ -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;
+			rtc@68 {
+				device_type = "rtc";
+				compatible = "dallas,ds1339";
+				reg = <68>;
+			};
+
 		};
 		sram@8000 {
 			device_type = "sram";

Hi, Bartlomiej!

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
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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.

As always.

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.

This is the substitute for probing.

Or get it from the firmware.

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.

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.

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

Hello, Scott!

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.

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.

That's not a good example: Of course, blindly poking is bad... therefore there is the (kernel.)configuration step to have only the relevant drivers enabled:
The Philips PCF8563 is on address 0x51 and the DS13x7 on 0x68. The drivers don't touch foreign addresses at all and they are fixed. No issues there... proved by 2.6.22.

Well, I don't want to start a flamewar on this since we have had already enough pro & contra Device Tree discussions. I just want to point out that the current situation doesn't really follow the KISS principle at all in my eyes.

Here, the next idea which comes to my mind:
Maybe we should think about a kernel-config -> dts compiler for the future where the enabled drivers generate their default dts entries automagically?

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Just because it worked fine *for you* doesn't mean it worked fine in general.

1. This means that you can't use the same kernel with different hardware, which is precisely what you were complaining that you couldn't do.
2. What if you have two i2c devices at the same address on different buses? Or if you have two devices, these devices can reside on a variety of ports, and the driver for one tries to probe the port of the other? .config doesn't help you now.
3. What if you need to pass in extra information to the driver, such as the exact chip type when more than one is handled by the same driver, or the IRQ line if the chip uses one, etc?

It should be as simple as it can be and still work, but no simpler. Before, it was too simple to work.

Sorry, there's just not enough information in .config for that.

-Scott

Hello, Scott!

If there is really the need to put more information (which I don't see in the case of the RTCs) to .config, it might be an idea to extend the current structure for this use instead of duplicating and maintaining a second repository.

And regarding the DS1337 (or the PCF8563 and similar RTCs):
It's address (0x68) is immutable fixed by the manufacturer of that device. So, why do we include it in the DT, when we already told the kernel what driver we want to use?

Even if I have an eeprom which can have varying addresses, I can simply tell the driver/the kernel .config what address it should use... If I want to be able to alter that address for whatever reason by OF, I still don't want to touch a separate file in the kernel tree.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

I2C is an odd bus in that it is only partially probeable; you can probe for presence, but you can't trust that you know what is there. The device tree approach sidesteps that uncertainty by just mandating that you specify that address and type of each device. This is neither hard or onerous on the developer to do.

If we *could* trust the i2c probing (like we can on PCI), then i2c devices would *not* need to be in the device tree.

Kconfig was never designed for that type of board level detail and it would be awkward to shoehorn that in (not to mention that it doesn't solve the problem of one kernel running on many boards.)

Historically we solved the config problem with board specific code in .c files. A solution I'm sure you'll agree might work, but it's not sustainable in the long run.

As for modifying the device tree; you've got many choices; choose what works best for you.

For example, you could:
a. write a separate .dts file per board varient, or
b. write single .dts files which only contains the common properties and the bootloader populates the board specific ones, or c. write a single .dts file which contains all possible nodes and the bootloader deletes the nodes which are irrelevant.

Regardless of what method you choose, you just need to make sure that the device tree that the kernel receives is an accurate representation of the hardware (ie. no nodes for non-present devices)

Cheers,
g.

Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
[email protected]
(403) 399-0195

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.

.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.

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.

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

Hi, Scott!

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.

I don't see

I would prefer to not tell the driver for 'foo' that it should attach to 0-0068 because it should attach to the first i2c bus (0) it finds per default. Then I would need to tell 'bar' to attach to 1-0068. Where is the problem? The 0068 is already redundant in the case of these RTCs because they are fixed.

There is already an example in the kernel for a very similar configuration
issue: see CONFIG_RTC_HCTOSYS_DEVICE.

The structure for this already present in kconfig, and I don't see any road block not to be able to use it. If later on, we want to have OF to be able to reconfigure it in the form of a DT structure, we could still feed a tool like the dtc with the .config and generate one.

Just let me make the point clear, why I got so upset here:
Having two different non-independent repositories make the configuration much more error-prone, especially if the second one (the DT) is partially redundant and not sufficiently documented.

Example:
I need to use the PCF8563 on the MPC8540' I2C as well (*) - it was just working in 2.6.22. Now, somebody

a) has to enable it in the kernel config
b) then add it to the i2c_driver_device struct in fsl_soc.c
c) then add it to the DTS.

Step b and c are not difficult at all, but completely non-obvious and undocumented for non-developers. You actually have to dig in the code to find out that you need it and this s****.

linux-2.6/Documentation/powerpc$ grep "rtc" *
only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant, btw.). which could give a clue what's going on here. linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
- nothing -

The configuration process is away from KISS - I would simply
state: it's broken - or - it's a regression from 2.6.22.

(*) Patch will follow, let me see if I guess it right. :-)

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

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.

It has a weak relation to the kernel config, not a strong one.

?

Absolutely wrong. What if foo is on bus 1?

OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and 4?

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.

That's not remotely the same. That's telling a kernel init procedure what kernel device to use, not describing the layout of hardware.

It is not.

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.

The device tree is not a configuration repository, it is a description of the hardware.

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.

Uh, did you try grepping for "i2c"?

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

Hi, Scott!

Hmm... Why?

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.

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.

Well, the subject is about RTCs.
But still the same applys for other i2c devices.

Sure. Just to make sure

I was trying to tell you that the structure to embed above information is already there.

Okay, our point of view is different here.

Yes. That's what's really necessary to put usability back in.

No, I've just read the whole file from time to time.

That was discussed already in detail in several threads and there were already decisions made that the DT went into the kernel - no problem with that.
I just don't see that it 'really does help' in it's current state if things are broken in a way they are hard to fix for non DT-familiar developers, almost impossible to fix for users which just need to compile their own kernel to achieve their project goal.

Well... let's take it easy. I'll dig into the pcf8563 code now.

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

It's error prone.

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.

Pot, meet kettle. :-)

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.

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).

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.

OK, it seems the description of i2c devices didn't make it into that file. I'm not sure why.

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).

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

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]

Hi, Scott!

Looks like I wasn't subscribed to the list anymore, so I missed lots of DT related discussions - my bad. :-(

That looks promising. I really didn't expect to find rtc driver names in fsl_soc.c...

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com

Thanks Jon, thanks Scott for the pointers, this works for me. (Patches have some whitespace damage, you propably want to run it thru checkpatch.pl before pushing upstream.)

Regards,

Clemens Koller
__________________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com