Jon Smirl schrieb:
> On 12/4/07, Clemens Koller <[EMAIL PROTECTED]> wrote:
>> That was discussed already in detail in several threads and there
>> were already decisions made that the DT went into the kernel - no problem
>> with that.
>> I just don't see that it 'really does help' in it's current s
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 yo
On 12/4/07, Clemens Koller <[EMAIL PROTECTED]> wrote:
> That was discussed already in detail in several threads and there
> were already decisions made that the DT went into the kernel - no problem
> with that.
> I just don't see that it 'really does help' in it's current state if
> things are brok
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
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
>> be
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 su
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.
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
> >> ent
On 12/3/07, Clemens Koller <[EMAIL PROTECTED]> 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 a
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 .
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
> int
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 successfull
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 ca
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
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
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
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,
Clem
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:
>
>
On Fri, 30 Nov 2007 15:12:31 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> Hello, Alessandro!
>
> Alessandro Zummo schrieb:
> > It's just to see if there's any timing issue like
> module-coming-up-before-bus-and/or-rtc.
> > it should work anyway, but who knows...
>
> Here comes more d
On Fri, 30 Nov 2007 19:12:01 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:/lib/modules/2.6.24-rc3-ge1cca7e8/kernel/drivers/rtc$
> modprobe rtc-ds1307
what is dmesg saying at this time?
you might want to add some debug statements in the driver
to see where it halts.. i
Hi, Alessandro!
Alessandro Zummo schrieb:
> On Fri, 30 Nov 2007 12:04:00 +0100
> Clemens Koller <[EMAIL PROTECTED]> wrote:
>
>> Modular doesn't make sense to me, because the filesystem check starts
>> to complain when last mount time was way to far in the past or in
>> the future. But I will try.
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
On Fri, 30 Nov 2007 12:04:00 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> A kernel upgrade doesn't make the chip to disappear ;-)
> The I2C bus is/was basically working fine all the time... see below.
you never know those pesky chips ;)
> Modular doesn't make sense to me, because the file
Hi, Alessandro!
Alessandro Zummo schrieb:
> On Thu, 29 Nov 2007 21:03:49 +0100
> Clemens Koller <[EMAIL PROTECTED]> wrote:
>
My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
and it also breaks the deprecated SENSORS_DS1337. :-(
>> One more update:
>> I am back t
On Thu, 29 Nov 2007 21:03:49 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> >> My guess is that the new rtc-lib's RTC_DRV_DS1307 support is still broken
> >> and it also breaks the deprecated SENSORS_DS1337. :-(
>
> One more update:
> I am back to mainline (linus' .git) on 2.6.24-rc3-g09f345da
Hi There!
> Clemens Koller <[EMAIL PROTECTED]> wrote:
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
>> as well as a 2.6.22-rc6-gb75ae860 is
Hello, Raul!
[EMAIL PROTECTED] schrieb:
> I am trying to use some devices on i2c protocol, one of them is the DS1337
> RTC, but I don't know too much about how.
> I am using the Linux kernel 2.6.15 and a mpc866 processor.
I don't remember too much about these old kernels.
And, please notice, t
inuxppc-embedded@ozlabs.org
Asunto: R
Hello, Allessandro!
Alessandro Zummo schrieb:
> On Wed, 28 Nov 2007 19:25:00 +0100
> Clemens Koller <[EMAIL PROTECTED]> wrote:
>
>> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
>> on my MPC8540(ads like) PowerPC working properly on
>> latest 2.6.24-rc2-ge6a5c27f ke
On Wed, 28 Nov 2007 20:36:06 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> My current
> .config as well as the dmesg is attached with your
> suggested changes.
one more test, please. can you try compiling rtc-ds1307 as
a module and then kick it in via modprobe?
--
Best regards,
Ales
On Wed, 28 Nov 2007 19:25:00 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
> Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
> on my MPC8540(ads like) PowerPC working properly on
> latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4cc
> as well as a 2.6.2
Alessandro Zummo schrieb:
On Wed, 28 Nov 2007 19:25:00 +0100
Clemens Koller <[EMAIL PROTECTED]> wrote:
Well, as already mentioned, I have problems to get my DS1337 RTC on I2C
on my MPC8540(ads like) PowerPC working properly on
latest 2.6.24-rc2-ge6a5c27f kernels. A paulus.git 2.6.21-rc5-g9a5ee4
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
> Clemen
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-
34 matches
Mail list logo
