DS1337 RTC on I2C broken.

DS1337 RTC on I2C broken.

[Clemens Koller]

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

Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Wed, 28 Nov 2007 19:25:00 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
> on my MPC8540(ads like) PowerPC working properly on
> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
> as well as a 2.6.22-rc6-gb75ae860 is working fine.
> (mainstream's console is broken, so cannot test these, yet.)
> 
> 
> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
> and it also breaks the deprecated SENSORS_DS1337. :-(

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

> Here is a snippet from my .config which is similar among my kernels.
> CONFIG_GEN_RTC=y

 this one must be deselected.

> CONFIG_SENSORS_DS1337=y
> CONFIG_SENSORS_DS1374=y

 ditto.

> DEV: registering device: ID = '0-0068'
> bus i2c: add device 0-0068
> bound device '0-0068' to driver 'ds1337'

 maybe the wrong driver is kicking in here.
 the fact that there is no rtc class
 related output in dmesg should and that
 there is no /dev/rtc0 could be a sign that the whole class
 is not going in.

 do you have full dmesg? 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Alessandro!

Thank you for your quick response... I'll just follow your
ideas and provide you with the dmesg output ASAP.

If you are online for some more time, I will accelerate
this debugging session... Just let me know.

Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
> 
>  mmm. I've been told it should work ;)

> 
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
> 
>  this one must be deselected.
> 
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
> 
>  ditto.

Will do.

> 
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
> 
>  maybe the wrong driver is kicking in here.
>  the fact that there is no rtc class
>  related output in dmesg should and that
>  there is no /dev/rtc0 could be a sign that the whole class
>  is not going in.
> 
>  do you have full dmesg? 

Not a full one from the 2.6.24 right now...
But I'll disable above stuff and get you a full one.
(in 5..10 minutes).

Regards,

Clemens Koller
__________________________________
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

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

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

Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(
> 
>  mmm. I've been told it should work ;)
> 
>> Here is a snippet from my .config which is similar among my kernels.
>> CONFIG_GEN_RTC=y
> 
>  this one must be deselected.
> 
>> CONFIG_SENSORS_DS1337=y
>> CONFIG_SENSORS_DS1374=y
> 
>  ditto.
> 
>> DEV: registering device: ID = '0-0068'
>> bus i2c: add device 0-0068
>> bound device '0-0068' to driver 'ds1337'
> 
>  maybe the wrong driver is kicking in here.
>  the fact that there is no rtc class
>  related output in dmesg should and that
>  there is no /dev/rtc0 could be a sign that the whole class
>  is not going in.
> 
>  do you have full dmesg? 

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

Regards,

Clemens Koller
__________________________________
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

[-- Attachment #2: dmesg-fail.txt --]
[-- Type: text/plain, Size: 15334 bytes --]

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

[-- Attachment #3: .config --]
[-- Type: application/x-config, Size: 27428 bytes --]

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Wed, 28 Nov 2007 20:36:06 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

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

 one more test, please. can you try compiling rtc-ds1307 as 
 a module and then kick it in via modprobe?


-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hello, Allessandro!

Alessandro Zummo schrieb:
 > On Wed, 28 Nov 2007 19:25:00 +0100
 > Clemens Koller <clemens.koller@anagramm.de> wrote:
 >
 >> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
 >> on my MPC8540(ads like) PowerPC working properly on
 >> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
 >> as well as a 2.6.22-rc6-gb75ae860 is working fine.
 >> (mainstream's console is broken, so cannot test these, yet.)

Just to give you an update: The latest paulus.git as of today
(Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday.

Regards,

Clemens Koller
__________________________________
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

Re: DS1337 RTC on I2C broken.

[raul.moreno]

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 <clemens.koller@anagramm.de>
Clemens Koller
Enviado por:
linuxppc-embedded-bounces+raul.moreno=3Dtelvent.abengoa.com@ozlabs.org
29/11/2007 12:24
                                                                       =
                                                
 Para:   Alessandro Zummo <alessandro.zummo@towertech.it>              =
                                                
                                                                       =
                                                
 cc:     rtc-linux@googlegroups.com, linuxppc-embedded@ozlabs.org      =
                                                
                                                                       =
                                                
 Asunto: Re: DS1337 RTC on I2C broken.                                 =
                                                
                                                                       =
                                                





Hello, Allessandro!

Alessandro Zummo schrieb:
 > On Wed, 28 Nov 2007 19:25:00 +0100
 > Clemens Koller <clemens.koller@anagramm.de> wrote:
 >
 >> Well, as already mentioned, I have problems to get my DS1337 RTC on=
 I2C
 >> on my MPC8540(ads like) PowerPC working properly on
 >> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee=
4cc
 >> as well as a 2.6.22-rc6-gb75ae860 is working fine.
 >> (mainstream's console is broken, so cannot test these, yet.)

Just to give you an update: The latest paulus.git as of today
(Linux-2.6.24-rc3-g0b47759d) is still broken. Same story as yesterday.

Regards,

Clemens Koller
__________________________________
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
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
=

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hello, Raul!

raul.moreno@telvent.abengoa.com schrieb:
 > I am trying to use some devices on i2c protocol, one of them is the DS1337
 > RTC, but I don't know too much about how.
 > I am using the Linux kernel 2.6.15 and a mpc866 processor.

I don't remember too much about these old kernels.
And, please notice, that
- I am on an mpc8540 which is quite different from your mpc866 processor.
- I am on the latest kernels which are also very different from the old
ones regarding the RTC subsystem.

Usually you have to configure the kernel using the right i2c interface
for your processor (if supported). I am using the 'fsl-i2c' driver
enabled by: I2C-support -> I2C Hardware Bus support -> MPC107/824x/85xx/52xx/86xx
which will be:
CONFIG_I2C_MPC=y

Then, you might have to enable the (now deprecated)
Misc I2C Chip Support -> Dallas DS1337 and ... Real Time Clock support
which gives you:
CONFIG_SENSORS_DS1337=y

 > I've seen there
 > is a cpm i2c interface for these processors (for a rpx board).

the fsl-i2c might be the right place

 > However the
 > corresponding code (i2c-algo8xx) doesn't appear in the sources. The
 > i2c-rpx.c just initializes the ioports, the adapter struct and the isr.
 > Maybe I am not understanding the i2c driver right.
 > I am a bit confused about it. Could you give me some help about how it
 > works or what should I have to do?

I would suggest - despite the current problems - to use a current
kernel and check your mileage there.
I don't want to ride dead horses anymore.

Regards,

Clemens Koller
__________________________________
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

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi There!

> Clemens Koller <clemens.koller@anagramm.de> wrote:
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is working fine.
>> (mainstream's console is broken, so cannot test these, yet.)
>>
>>
>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
>> and it also breaks the deprecated SENSORS_DS1337. :-(

One more update:
I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to
verify that the problem with the RTC still persists.

I startet to bisect, but ran quickly into other crashes.
(no console on 2.6.23-rc2 and 2.6.23)
So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and
and 2.6.24-rc2-ge6a5c27f.

Regards,

Clemens Koller
__________________________________
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

Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Thu, 29 Nov 2007 21:03:49 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

> >> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
> >> and it also breaks the deprecated SENSORS_DS1337. :-(
> 
> One more update:
> I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to
> verify that the problem with the RTC still persists.
> 
> I startet to bisect, but ran quickly into other crashes.
> (no console on 2.6.23-rc2 and 2.6.23)
> So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and
> and 2.6.24-rc2-ge6a5c27f.

 did you tried compiling it modular? you might even check with
 i2cdetect if the chip is there

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: DS1337 RTC on I2C broken.

[Clemens Koller]

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

Hi, Alessandro!

Alessandro Zummo schrieb:
 > On Thu, 29 Nov 2007 21:03:49 +0100
 > Clemens Koller <clemens.koller@anagramm.de> wrote:
 >
 >>>> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
 >>>> and it also breaks the deprecated SENSORS_DS1337. :-(
 >> One more update:
 >> I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da to
 >> verify that the problem with the RTC still persists.
 >>
 >> I startet to bisect, but ran quickly into other crashes.
 >> (no console on 2.6.23-rc2 and 2.6.23)
 >> So, I just can tell that it broke in between 2.6.22-rc6-gb75ae860 and
 >> and 2.6.24-rc2-ge6a5c27f.
 >
 >  did you tried compiling it modular? you might even check with
 >  i2cdetect if the chip is there

A kernel upgrade doesn't make the chip to disappear ;-)
The I2C bus is/was basically working fine all the time... see below.

Modular doesn't make sense to me, because the filesystem check starts
to complain when last mount time was way to far in the past or in
the future. But I will try...

I can:

$ uname -a
Linux fox_1 2.6.24-rc3-g09f345da #1 Thu Nov 29 21:21:39 CET 2007 ppc e500 GNU/Linux
$ i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- --
50: UU -- -- -- -- -- -- UU -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

At 0x68 is the DS1337,
at 0x48 I have an LM75
at 0x50 and 0x57 there is some EEPROM attached

$ i2cdump 0 0x68 b
Error: Could not set address to 0x68: Device or resource busy

That would tell me AFAICT that the ds1307 driver claimed that
address already... But...
Well, I've attached the config again.
(Note, I enabled the SENSORS_x during my manual bisecting again to
find where it doesn't work anymore. Disabling them didn't work for
sure, but will retry now...)

Regards,
-- 
Clemens Koller
__________________________________
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


[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 6922 bytes --]

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Fri, 30 Nov 2007 12:04:00 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

> A kernel upgrade doesn't make the chip to disappear ;-)
> The I2C bus is/was basically working fine all the time... see below.

 you never know those pesky chips ;)
 
> Modular doesn't make sense to me, because the filesystem check starts
> to complain when last mount time was way to far in the past or in
> the future. But I will try...

 It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
 it should work anyway, but who knows...
 

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

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

Hello, Alessandro!

Alessandro Zummo schrieb:
 >  It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
 >  it should work anyway, but who knows...

Here comes more debugging output:

Please note that I have now _two_ almost identical systems up and running with the
latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another one (fox_1)
with an DS1337. Both RTCs work, but the kernel doesn't get the time right.
I have now the SENSORS_*=n as you said and the (new) RTC configured.
The kernel configuration (attached) is identical for both machines. Can you please
check that again?!
Which CONFIG do I have to enable that I get /dev/rtc and/or /dev/rtc0 devices?
Note that I don't get any /dev/rtc* entry right now despite RTC_INTF_DRV=Y

Here are the outputs of the two hosts:
====================================================
HOST ECAM

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


[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 6919 bytes --]

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Fri, 30 Nov 2007 15:12:31 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

> Hello, Alessandro!
> 
> Alessandro Zummo schrieb:
>  >  It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
>  >  it should work anyway, but who knows...  
> 
> Here comes more debugging output:


 [..]

 your .config is right, the drivers are loaded
 but they are not bound to the chips as they are supposed to do.

 can you check that i2c_board_info structures / i2c_register_board_info
 are used by your platform?

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Olof Johansson]

On Fri, Nov 30, 2007 at 03:12:31PM +0100, Clemens Koller wrote:
> Hello, Alessandro!
>
> Alessandro Zummo schrieb:
> >  It's just to see if there's any timing issue like 
> module-coming-up-before-bus-and/or-rtc.
> >  it should work anyway, but who knows...
>
> Here comes more debugging output:
>
> Please note that I have now _two_ almost identical systems up and running 
> with the
> latest kernel. One machine (ecam) with an pcf8563 RTC on I2C and another 
> one (fox_1)
> with an DS1337. Both RTCs work, but the kernel doesn't get the time right.

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



-Olof

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Alessandro!

Alessandro Zummo schrieb:
> On Fri, 30 Nov 2007 12:04:00 +0100
> Clemens Koller <clemens.koller@anagramm.de> wrote:
> 
>> Modular doesn't make sense to me, because the filesystem check starts
>> to complain when last mount time was way to far in the past or in
>> the future. But I will try...
> 
>  It's just to see if there's any timing issue like module-coming-up-before-bus-and/or-rtc.
>  it should work anyway, but who knows...

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

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Alessandro Zummo]

On Fri, 30 Nov 2007 19:12:01 +0100
Clemens Koller <clemens.koller@anagramm.de> wrote:

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

 what is dmesg saying at this time?

 you might want to add some debug statements in the driver
 to see where it halts.. i guess the driver is not bound
 to the chip for some reason.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Alessandro, Hi, Olof!

Olof Johansson wrote:
 > ds1307 requires you to register i2c_board_info for it to probe properly.
 > Does your platform do so?

I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
is just never called despite the module gets loaded.

Regards,

Clemens Koller
__________________________________
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

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Bartlomiej Sieka]

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

Clemens Koller wrote:
> Hi, Alessandro, Hi, Olof!
> 
> Olof Johansson wrote:
>  > ds1307 requires you to register i2c_board_info for it to probe properly.
>  > Does your platform do so?
> 
> I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
> is just never called despite the module gets loaded.

Hello Clemens,

Do you have rtc node in your dts file (I'm assuming arch/powerpc
situation)? If not, you'll have to add it - for example similarly to
what's being done in the attached patch (68 is the I2C address of the
RTC chip - a DS1339 in my case).

HTH,
Bartlomiej Sieka

[-- Attachment #2: motionpro_i2c_rtc_dts.diff --]
[-- Type: text/plain, Size: 603 bytes --]

diff --git a/arch/powerpc/boot/dts/motionpro.dts b/arch/powerpc/boot/dts/motionpro.dts
index 112279b..ab39d61 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -329,10 +329,17 @@
 			device_type = "i2c";
 			compatible = "mpc5200b-i2c\0mpc5200-i2c\0fsl-i2c";
 			cell-index = <1>;
+			#cell-size = <0>;
 			reg = <3d40 40>;
 			interrupts = <2 10 0>;
 			interrupt-parent = <&mpc5200_pic>;
 			fsl5200-clocking;
+			rtc@68 {
+				device_type = "rtc";
+				compatible = "dallas,ds1339";
+				reg = <68>;
+			};
+
 		};
 		sram@8000 {
 			device_type = "sram";

Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Bartlomiej!

Bartlomiej Sieka schrieb:
 > Do you have rtc node in your dts file (I'm assuming arch/powerpc
 > situation)? If not, you'll have to add it - for example similarly to
 > what's being done in the attached patch (68 is the I2C address of the
 > RTC chip - a DS1339 in my case).

Thank you also for your hint... that was indeed the problem here.
Simple but not really obvious.

Is it possible to have a maximum generic .dts configuration where the
kernel is told to include any device it propably finds?

I guess the failing reset since 2.6.22 is also just an entry in
my .dts... ?

Regards,
-- 
Clemens Koller
__________________________________
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

solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hello, Olof!

Clemens Koller schrieb:
> Hi, Alessandro, Hi, Olof!
> 
> Olof Johansson wrote:
>  > ds1307 requires you to register i2c_board_info for it to probe properly.
>  > Does your platform do so?
> 
> I started to add some pr_debug()s. It seems that rtc-ds1307's ds1307_init()
> is just never called despite the module gets loaded.

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

Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood]

Clemens Koller wrote:
> [OT+sarcasm on]
> 
> So, the time is over, where you just enable a driver in the kernel config and
> the device gets probed and - if it's probed successfully - it usually works.

The problem is the "probed successfully" bit -- i2c can't be 
automatically detected like PCI can, and the probing that was being done 
before was very error-prone.

Thus, there needs to be something describing what hardware is actually 
there, not just what the kernel supports.

> Now, the way is like this:
> 
> - enable the desired driver in the kernel.

As always.

> - check that the platform driver fsl_soc.c (in my case) defines the
>    desired rtc-chip in the i2c_board_info

Once the glue code gets consolidated, it'll just be a one-time thing for 
any given chip to be added to the OF I2C table.

I don't know why it was ever done in platform-specific code.

> - check that the rtc is included in the device tree.

This is the substitute for probing.

> - embed the device tree to the kernel (cuImage)

Or get it from the firmware.

> - boot'n'pray.
> 
> That looks really groundbreaking!
> 
> Now, I cannot use one kernel for two almost identical hardware revisions
> anymore because the rtc's on i2c are different? This must be a joke!

Not at all true.  The kernel just needs to know, at runtime, what 
hardware you actually have.  It uses the device tree for this.

With cuImage, you're limited to one device tree in a given build, though 
you can invoke the wrapper manually to create multiple images.  However, 
cuImage is a compatibility measure; if you use a newer u-boot with 
device tree support, the tree does not need to be statically wrapped in 
the kernel image.

> It seems like I first need to have full device tree support included in
> the boot-loader to be able to duplicate my configuration work to allow
> one kernel to boot on both hardware.

That's the simplest way, but not the only way.  You could also have a 
wrapper platform that chooses the proper device tree based on something 
you detect.

> Hmmm... this just s****!

There are some growing pains, but the old method of blindly poking at 
i2c addresses and hoping that the first driver to ask for a port that 
something responds to is actually the right driver for that port is just 
shit.

-Scott

OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hello, Scott!

Scott Wood schrieb:
 > Clemens Koller wrote:
 >> [OT+sarcasm on]
 >>
 >> So, the time is over, where you just enable a driver in the kernel
 >> config and
 >> the device gets probed and - if it's probed successfully - it usually
 >> works.
 >
 > The problem is the "probed successfully" bit -- i2c can't be
 > automatically detected like PCI can, and the probing that was being done
 > before was very error-prone.

I think I understood the original purpose of device trees, or it's
intended advantage but don't see much of this yet.

Before (2.6.22) everything was working fine just by enabling the proper
kernel config. But in it's current implementation I primarily see the
an additional, duplicate, badly documented configuration step for
these - in my case - stupid, usually trivial to handle RTC chips.

 > That's the simplest way, but not the only way.  You could also have a
 > wrapper platform that chooses the proper device tree based on something
 > you detect.

Here is the problem:
something it detects = probing (what we planned to avoid)
something I detect = configurating (currently duplicated work).
This wrapper platform doesn't really exist yet in practice.

 >> Hmmm... this just s****!
 >
 > There are some growing pains, but the old method of blindly poking at
 > i2c addresses and hoping that the first driver to ask for a port that
 > something responds to is actually the right driver for that port is just
 > shit.

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

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

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

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

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood]

Clemens Koller wrote:
> Scott Wood schrieb:
>  > The problem is the "probed successfully" bit -- i2c can't be
>  > automatically detected like PCI can, and the probing that was being done
>  > before was very error-prone.
> 
> I think I understood the original purpose of device trees, or it's
> intended advantage but don't see much of this yet.
> 
> Before (2.6.22) everything was working fine just by enabling the proper
> kernel config.

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

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

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

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

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

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

-Scott

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hello, Scott!

Scott Wood schrieb:
 >> Here, the next idea which comes to my mind:
 >> Maybe we should think about a kernel-config -> dts compiler for
 >> the future where the enabled drivers generate their default dts
 >> entries automagically?
 >
 > Sorry, there's just not enough information in .config for that.

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

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

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

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

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Grant Likely]

On 12/3/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
>  >> Here, the next idea which comes to my mind:
>  >> Maybe we should think about a kernel-config -> dts compiler for
>  >> the future where the enabled drivers generate their default dts
>  >> entries automagically?
>  >
>  > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs) to .config, it might be an idea to
> extend the current structure for this use instead of duplicating
> and maintaining a second repository.
>
> And regarding the DS1337 (or the PCF8563 and similar RTCs):
> It's address (0x68) is immutable fixed by the manufacturer
> of that device. So, why do we include it in the DT, when we
> already told the kernel what driver we want to use?

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

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

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

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

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

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

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

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

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood]

On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote:
> Hello, Scott!
>
> Scott Wood schrieb:
> >> Here, the next idea which comes to my mind:
> >> Maybe we should think about a kernel-config -> dts compiler for
> >> the future where the enabled drivers generate their default dts
> >> entries automagically?
> >
> > Sorry, there's just not enough information in .config for that.
>
> If there is really the need to put more information (which I don't
> see in the case of the RTCs)

It's not uncommon for RTCs to have an alarm IRQ.  It's not uncommon for
multiple not-quite-compatible RTC chips to be driven by the same driver,
which needs to know what it's dealing with.

> to .config, it might be an idea to extend the current structure for this
> use instead of duplicating and maintaining a second repository.

.config is not nearly as flexible in describing hardware as the device tree
is.  Sorry, but even apart from the multiplatform issue, it's the wrong tool
for the job.

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

You did not tell the kernel what driver you wanted to use; you told the
driver which address the chip will be on.  There are other chips that also
use address 0x68, such as DS1374, which is completely incompatible with
DS1337 and uses a different driver.

> Even if I have an eeprom which can have varying addresses,
> I can simply tell the driver/the kernel .config what address
> it should use...

That's precisely what we do, via the device tree.  It is not practical to do
it with kconfig.  Again putting aside multiplatform kernels for the moment,
what would you do in kconfig to describe the addresses of multiple chips
without having a fixed-size list of possibilities?  How would you tell the
kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus
0, and a "bar" chip at address 0x68 on i2c bus 1?

-Scott

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Scott!

Scott Wood schrieb:
> On Mon, Dec 03, 2007 at 08:35:29PM +0100, Clemens Koller wrote:
>> Even if I have an eeprom which can have varying addresses,
>> I can simply tell the driver/the kernel .config what address
>> it should use...
> 
> That's precisely what we do, via the device tree.  It is not practical to do
> it with kconfig.

It's propably not practical to do it with kconfig right now, but
creating a separate configuration repository with strong relation
to the kernel config is IMO the wrong way to do it.

 > Again putting aside multiplatform kernels for the moment,
> what would you do in kconfig to describe the addresses of multiple chips
> without having a fixed-size list of possibilities?

I don't see

 > How would you tell the
> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c bus
> 0, and a "bar" chip at address 0x68 on i2c bus 1?

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

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

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

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

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

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

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

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

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

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

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

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood]

On Tue, Dec 04, 2007 at 12:42:41PM +0100, Clemens Koller wrote:
> Scott Wood schrieb:
>> That's precisely what we do, via the device tree.  It is not practical to
>> do it with kconfig.
>
> It's propably not practical to do it with kconfig right now,

It's not practical at all.  It forces you to support one and only one target
per kernel image, and the basic structure of it is not nearly flexible
enough.

> but creating a separate configuration repository with strong relation to
> the kernel config is IMO the wrong way to do it.

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

> > Again putting aside multiplatform kernels for the moment,
>> what would you do in kconfig to describe the addresses of multiple chips
>> without having a fixed-size list of possibilities?
>
> I don't see

?

> > How would you tell the
>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c 
>> bus
>> 0, and a "bar" chip at address 0x68 on i2c bus 1?
>
> I would prefer to not tell the driver for 'foo' that it should attach to 
> 0-0068
> because it should attach to the first i2c bus (0) it finds per default.

Absolutely wrong.  What if foo is on bus 1?

> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?

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

> The 0068 is already redundant in the case of these RTCs because they are 
> fixed.

How do you know I'm even talking about RTCs?  Those chips at 0x68 could be
anything.  There are many chips that don't have a single fixed address.

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

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

> The structure for this already present in kconfig, 

It is not.

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

Please, feel free to make a patch that does this.  You may find it to be a
bit more difficult than you thought. :-)

And again, there's the multiplatform issue.

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

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

> Example:
> I need to use the PCF8563 on the MPC8540' I2C as well (*) - it
> was just working in 2.6.22. Now, somebody
>
> a) has to enable it in the kernel config
> b) then add it to the i2c_driver_device struct in fsl_soc.c
> c) then add it to the DTS.
>
> Step b and c are not difficult at all, but completely non-obvious
> and undocumented for non-developers. You actually have to dig in
> the code to find out that you need it and this s****.

Step b is something that only needs to be done once per chip, and step c is
something that only needs to be done once per board.  Why is it unreasonable
for it to be done by a developer?

We really should try to get the table populated with names for all of the
new-style drivers in the kernel, though.

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

Uh, did you try grepping for "i2c"?

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

The transition could have been done more smoothly if the i2c driver model
allowed a driver to be both new-style and old-style at the same time
(subject to a config option to shut off old-style if it's screwing things
up), I'll agree with that much.  But please, try to understand that the
device tree really does help.

-Scott

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Scott!

Scott Wood schrieb:
 >>> How would you tell the
 >>> kernel, using kconfig, that there's a "foo" chip at address 0x68 on i2c
 >>> bus
 >>> 0, and a "bar" chip at address 0x68 on i2c bus 1?
 >>
 >> I would prefer to not tell the driver for 'foo' that it should attach to
 >> 0-0068
 >> because it should attach to the first i2c bus (0) it finds per default.
 >
 > Absolutely wrong.

Hmm... Why?

 > What if foo is on bus 1?

Then I would need to tell the driver 'foo' that it should attach
to 1-0068. Sorry, I really don't understand your problem here.
If we have 'foo' on both busses, I need of course tell it
to attach to 0-0068 as well as 1-0068.

Propably you should see the bigger picture here:
We just need to tell what we have, if it's not some default...
statically (kconfig) or dynamically (of/dt) to get it right
because we cannot probe for sure what we have (in contrast to PCI).

I just don't want to be pushed into configuring things twice or on
two different places because that's error prone.

 >> Then I would need to tell 'bar' to attach to 1-0068. Where is the problem?
 >
 > OK, now say there's another foo on bus 2, and a pair of bars on buses 3 and
 > 4?

Okay, let's play that game:
foo -> connect an instance to 0-0068 and 2-0068
bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068

If i.e. bar is a 8-page eeprom which hw-configurable addresses nailed
down to 0x50 and 0x58 to have a contigous eeprom area from 0x50 to 0x5f
it can also look like:
bar -> connect an instance to 1-0050 and 1-0058

I still don't see a conflict here.

You cannot connect more than one device to an address, that would
violate the I2C Spec. If you have different devices with the same
address, you have to nail down which ones belong together.

 >> The 0068 is already redundant in the case of these RTCs because they are
 >> fixed.
 >
 > How do you know I'm even talking about RTCs?

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

 >  Those chips at 0x68 could be
 > anything.  There are many chips that don't have a single fixed address.

Sure. Just to make sure

 >> There is already an example in the kernel for a very similar configuration
 >> issue: see CONFIG_RTC_HCTOSYS_DEVICE.
 >
 > That's not remotely the same.  That's telling a kernel init procedure what
 > kernel device to use, not describing the layout of hardware.

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

 >>> The structure for this already present in kconfig,
 >
 > It is not.

Okay, our point of view is different here.

 > We really should try to get the table populated with names for all of the
 > new-style drivers in the kernel, though.

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

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

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

 >> The configuration process is away from KISS - I would simply
 >> state: it's broken - or - it's a regression from 2.6.22.
 >
 > The transition could have been done more smoothly if the i2c driver model
 > allowed a driver to be both new-style and old-style at the same time
 > (subject to a config option to shut off old-style if it's screwing things
 > up), I'll agree with that much.
 >  But please, try to understand that the
 > device tree really does help.

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

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

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

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Scott Wood]

Clemens Koller wrote:
> Scott Wood schrieb:
>  >> I would prefer to not tell the driver for 'foo' that it should attach to
>  >> 0-0068
>  >> because it should attach to the first i2c bus (0) it finds per default.
>  >
>  > Absolutely wrong.
> 
> Hmm... Why?

It's error prone.

>  > What if foo is on bus 1?
> 
> Then I would need to tell the driver 'foo' that it should attach
> to 1-0068.

So we're back to the situation where drivers that aren't explicitly told 
where to look are making assumptions that are possibly incorrect.  You 
should be able to enable drivers without harm, even if the hardware 
isn't there.

> Propably you should see the bigger picture here:

Pot, meet kettle. :-)

> We just need to tell what we have, if it's not some default...
> statically (kconfig) or dynamically (of/dt) to get it right
> because we cannot probe for sure what we have (in contrast to PCI).
> 
> I just don't want to be pushed into configuring things twice or on
> two different places because that's error prone.

The new system is far less error prone than the old system.  You seem to 
be suggesting a third system, with a radically different kconfig format 
and no multiplatform support (again, this was one of your complaints in 
your original e-mail -- why do you ignore it now?).  Please show us the 
code, or at least some description of how you would change kconfig to 
get it up to the task, and how you would handle multiplatform kernels.

>  >> Then I would need to tell 'bar' to attach to 1-0068. Where is the 
> problem?
>  >
>  > OK, now say there's another foo on bus 2, and a pair of bars on buses 
> 3 and
>  > 4?
> 
> Okay, let's play that game:
> foo -> connect an instance to 0-0068 and 2-0068
> bar -> connect an instance to 1-0068 and and 3-0068 and 4-0068

That doesn't resemble kconfig in the least -- and even if you transform 
it into some sort of runtime-parsable textual list, what do those bus 
numbers mean, anyway?  How do you associate those with various i2c 
buses, potentially coming from different i2c drivers?  How do you 
specify IRQs?  How do you specify device variants among those the driver 
supports?  By the time you fix all of that, you'll basically have the 
device tree.

The device tree provides a hierarchy that is well suited to handling 
this sort of problem, and it also logically separates what the kernel 
supports from what the hardware has (which is *necessary* for 
multiplatform support).

>  >> The 0068 is already redundant in the case of these RTCs because they 
> are
>  >> fixed.
>  >
>  > How do you know I'm even talking about RTCs?
> 
> Well, the subject is about RTCs.

Not really, it's about a change in the i2c subsystem (I noticed you 
didn't include the i2c list or linuxppc-dev... you'd get a larger 
audience of the people that actually made the change that way).  That it 
happens to be an RTC chip you're using on the i2c bus is an 
inconsequential detail.

>  >> linux-2.6/Documentation/powerpc$ grep "rtc" *
>  >> only gives on hit in the mpc52xx-device-tree-bindings.txt (from Grant,
>  >> btw.).
>  >> which could give a clue what's going on here.
>  >> linux-2.6/Documentation/powerpc$ grep "fsl_soc" *
>  >> - nothing -
>  >
>  > Uh, did you try grepping for "i2c"?
> 
> No, I've just read the whole file from time to time.

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

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

I agree there's been excessive roughness in the transition -- but in 
this case, it's largely due to the i2c subsystem change, whereby a 
driver can't be new-style and old-style at the same time.  Thus, once 
the driver is converted, all platforms have to register the device.  On 
powerpc, we happen to do it using the device tree (though you could do 
it with board-specific platform code the way other arches do if you 
really wanted).

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

BTW, there were patches posted recently by Jon Smirl to convert that 
driver to new-style, and to change the i2c subsystem to have the OF 
matches in the driver itself.

-Scott

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Hi, Scott!

 >> Well, the subject is about RTCs.
 >
 > Not really, it's about a change in the i2c subsystem (I noticed you
 > didn't include the i2c list or linuxppc-dev... you'd get a larger
 > audience of the people that actually made the change that way).  That it
 > happens to be an RTC chip you're using on the i2c bus is an
 > inconsequential detail.

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

 >> Well... let's take it easy. I'll dig into the pcf8563 code now.
 >
 > BTW, there were patches posted recently by Jon Smirl to convert that
 > driver to new-style, and to change the i2c subsystem to have the OF
 > matches in the driver itself.

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

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

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Jon Smirl]

On 12/4/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
> That was discussed already in detail in several threads and there
> were already decisions made that the DT went into the kernel - no problem
> with that.
> I just don't see that it 'really does help' in it's current state if
> things are broken in a way they are hard to fix for non DT-familiar
> developers, almost impossible to fix for users which just need to
> compile their own kernel to achieve their project goal.
>
> Well... let's take it easy. I'll dig into the pcf8563 code now.

Most of this is addressed in the patch series starting with this message:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html

The pcf8563 driver is converted to the new format and is modified to
pick up it's address from the device tree.

This patch series is being held waiting for an ok on the low level
changes to the i2c subsystem. Hopefully it will go into 2.6.25


-- 
Jon Smirl
jonsmirl@gmail.com

Re: OT: Re: solved: Re: [rtc-linux] Re: DS1337 RTC on I2C broken.

[Clemens Koller]

Jon Smirl schrieb:
> On 12/4/07, Clemens Koller <clemens.koller@anagramm.de> wrote:
>> That was discussed already in detail in several threads and there
>> were already decisions made that the DT went into the kernel - no problem
>> with that.
>> I just don't see that it 'really does help' in it's current state if
>> things are broken in a way they are hard to fix for non DT-familiar
>> developers, almost impossible to fix for users which just need to
>> compile their own kernel to achieve their project goal.
>>
>> Well... let's take it easy. I'll dig into the pcf8563 code now.
> 
> Most of this is addressed in the patch series starting with this message:
> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/047382.html
> 
> The pcf8563 driver is converted to the new format and is modified to
> pick up it's address from the device tree.
> 
> This patch series is being held waiting for an ok on the low level
> changes to the i2c subsystem. Hopefully it will go into 2.6.25

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

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