vijay sharma wrote:
> Linux/PowerPC load:
> Finalizing device tree... flat tree at 0x2f65300 <== Beyond this point no
> output is available.
I have found that on my MPC8272 system running 2.6.28 & cuImage, the
/chosen/linux,stdout-path node is respected by the boot wrapper, but the
main kernel alw
Daniel Ng wrote:
>> Now, I'm seeing these boot messages:
>>
>> f0010d40:00 not found
>> eth0: Could not attach to PHY
Daniel,
These messages are typical of having the wrong GPIO pins in the mdio
node or the wrong MDIO address (reg property) in the ethernet-phy node.
>> Currently, our PHY
>> attr
Timur Tabi wrote:
> However, it appears that this is not common behavior for I2C driver. In
> fact, only these six drivers ever call wait_event_interruptible_timeout():
>
> i2c-cpm.c
I don't know about the others, but in i2c-cpm.c the use of interruptible
wait seems incorrect. Maybe it could be
Daniel Ng wrote:
> Should the device just be available as 'eth2', so that I can do
> 'ifconfig eth2 192.168.1.33'?
It will be eth0 if you have no other network devices.
> // FCC2-
> reg = <0x11320 0x20 0x8500 0x100 0x113b0 0x1>;
> fsl,cpm-command = <0x12000300>;
That's n
Jocke,
> The I2C_CHIP_ERRATA is mine and refers to mpc8xx, mpc860 in my case. The
> driver was adapted by me some years ago in 2.4 and now someone has
> ported it to 2.6 it seems.
Thanks for the background info. Any idea which particular errata it
was meant to fix? I took a quick look at MPC860
Hi, Laurent,
> While the problem seems to be similar to CPM98, I don't understand how it
> could happen on the first character of the first I2C transfer.
I agree, that is hard to explain given that i2c-cpm keeps the controller
shut off until the very moment of the first transfer. Can you check
(replying to myself again)
I wrote:
> But the key difference is that we see a persistent failure, while the
> erratum only mentions a problem with "the next transaction".
I think the timeout recovery code is not adequate for these CPM errors,
and that is why a transient error becomes a persistent
I wrote:
> Our production equipment is using Linux 2.6 with the out-of-tree
> i2c-algo-8260.c by Dan Malek and Brad Parker.
Oops, I meant to say Linux 2.4.20 (MontaVista).
-=] Mike [=-
___
Linuxppc-dev mailing lis
Laurent Pinchart <[EMAIL PROTECTED]> wrote:
> Transmission timeout after one second. The first TX buffer descriptor status
> hasn't been modified by the CPM. The CPM state dump shows that processing of
...
This sounds very similar to a problem I have seen on MPC8247 and
MPC8248.
It could be a v
ned-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
This patch is against 2.6.27.
To use the full range of I2C clock frequencies supported by the
Freescale CPM I2C controller, it is necessary to choose an appropriate
predivider value. The choice is affected by whether the SCL signal
digital filter
[including extra context because some of the thread went to the
wrong I2C list]
David Gibson wrote:
> On Wed, Nov 05, 2008 at 04:35:03PM -0800, Mike Ditto wrote:
>> David Gibson wrote:
>> > What does worry me, however, is the description says it's about
>> > wh
David Gibson wrote:
> What does worry me, however, is the description says it's about
> whether the driver "should" enable the filter. Generally the device
> tree doesn't attempt to say what users "should" do with the hardware,
> just what the characteristics of the hardware are.
>
> What's the un
Ben Dooks wrote:
When reading from a device that is not present or declines to respond
to, e.g., a non-existent register address, CPM immediately reports a
NAK condition in the TxBD, but the driver kept waiting until a timeout,
which takes 1 second and causes an ugly console error message.
hmm,
Make the driver report an ENXIO error immediately upon NAK instead of
waiting for another interrupt and getting a timeout.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
When reading from a device that is not present or declines to respond
to, e.g., a non-existent register addres
[redirecting again to the new i2c mailing list]
Jochen Friedrich wrote:
> What needs to be done though is to document this change in
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt.
How about the below?
I'll wait for David to comment on the property name and for any suggestions
on th
Jochen Friedrich wrote:
> What needs to be done though is to document this change in
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt.
How about the below?
I'll wait for David to comment on the property name and for any suggestions
on the documentation below, then I'll submit a new pat
This patch adds the ability to enable the digital filter in the device
tree (with the "clock-filter" boolean property) and automates the
predivider selection according to the clock-frequency and clock-filter
properties.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
Resend
This patch adds the ability to enable the digital filter in the device
tree (with the "clock-filter" boolean property) and automates the
predivider selection according to the clock-frequency and clock-filter
properties.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
This
If something goes wrong attaching to phy driver, we weren't freeing
the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
Reposting to CC netdev list. (Thanks, Kumar)
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_enet-main.c
NEW/drivers/net/fs_enet/fs_enet-main.c
--- 2.6.28-
If something goes wrong attaching to phy driver, we weren't freeing the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
I just noticed this file has already been touched in -rc1 so here is the
patch again, adjusted accordingly.
diff -r -upN 2.6.28-rc1/drivers/net/fs_enet/fs_
If something goes wrong attaching to phy driver, we weren't freeing the IRQ.
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
cvs diff -r linux-2_6_27 -upN linux/drivers/net/fs_enet/fs_enet-main.c
Index: linux/drivers/net/fs_enet/fs_
Benjamin Herrenschmidt wrote:
> I've fixed it up manually so no need to re-submit, but you'll know next
> time :-)
Thanks!
-=] Mike [=-
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailm
Reposting in proper format...
Some platforms have variants that can share most of a flat device tree but need
a few devices selectively pruned at boot time. This adds del_node() to ops.h
to allow access to the existing fdt_del_node().
Signed-off-by: Mike Ditto <[EMAIL PROTECTED]>
---
David Gibson wrote:
> Deleting the irrelevant parts or picking a device tree to pass to
> fdt_init() are both reasonable solutions. libfdt which is included in
> the bootwrapper has functions for removing unwanted nodes: either
> fdt_nop_node() or fdt_del_node() will suffice. There isn't currentl
I noticed, when trying to use, e.g.,
node = find_node_by_prop_value(prev, "booleanprop", "", 0))
to search for all nodes with a certain boolean property, that memcmp()
returns garbage when comparing zero bytes. It should return zero.
Index: arch/powerpc/boot/string.S
=
I'm building a kernel that can run on a handful of hardware
configurations, all using OF-unaware U-Boot. I know how to make a
static device tree (dts file) that works on one of these hardware
variations, and how to add nodes and modify properties in the platform
init code. But I don't see a nice
26 matches
Mail list logo
