* Re: [PATCH] ehea: add kexec support
From: Christoph Raisch @ 2007-11-02 10:19 UTC (permalink / raw)
To: michael
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <1193985008.1782.7.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 02.11.2007 07:30:08:
> On Wed, 2007-10-31 at 20:48 +0100, Christoph Raisch wrote:
> > Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
> If that's really the way it works then eHEA is more or less broken for
> kdump I'm afraid.
We think we have a way to workaround this, but let me first try to
explain the base problem.
DD allocates HEA resources and gets firmware_handles for these resources.
To free the resources DD needs to use exactly these handles.
There's no generic firmware call "clean out all resources".
Allocating the same resources twice does not work.
So a new kernel can't free the resources allocated by an old kernel,
because the numeric values of the handles aren't known anymore.
Potential Solution:
Hea driver cleanup function hooks into ppc_md.machine_crash_shutdown
and frees all firmware resources at shutdown time of the crashed kernel.
crash_kexec continues and loads new kernel.
The new kernel restarts the HEA driver within kdump kernel, which will work
because resources have been freed before.
Michael, would this work?
Gruss / Regards
Christoph R.
^ permalink raw reply
* Re: [PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
From: Johannes Berg @ 2007-11-02 10:32 UTC (permalink / raw)
To: Badari Pulavarty
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193849335.17412.33.camel@dyn9047017100.beaverton.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 180 bytes --]
> This patch provides a way for an architecture to provide its
> own walk_memory_resource()
It seems that the patch description "walk_memory_remove()" is wrong?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* RE: The question about the fail at the begin of linux on MPC8360E.
From: Medve Emilian-EMMEDVE1 @ 2007-11-02 12:55 UTC (permalink / raw)
To: 郭劲, linuxppc-embedded
In-Reply-To: <393972917.10298@tsinghua.org.cn>
Hi there,
You need a device tree. The defaut one is =
arch/powerpc/boot/dts/mpc836x_mds.dts. You need the DTC (Device Tree =
Compiler) from here http://jdl.com/git_repos/?p=3Ddtc.git;a=3Dsummary. =
This should be enough to give you some reading pointers.
Cheers,
Emil.
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+emilian.medve=3Dfreescale.com@ozlabs.o
> rg=20
> [mailto:linuxppc-embedded-bounces+emilian.medve=3Dfreescale.com@
> ozlabs.org] On Behalf Of ??
> Sent: Thursday, November 01, 2007 10:09 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: The question about the fail at the begin of linux on=20
> MPC8360E.
>=20
> Hi,friends,
> Thanks.
>=20
> We boot the linux-2.6.22 on MPC8360 board, it failed, follow=20
> is the output
> information. we just only success on linux-2.6.11, but fail=20
> on linux-2.6.19 and
> linux-2.6.22. Both 2.6.19 and 2.6.22 are failed on same=20
> position,please see follow
> information. linux-2.6.19 and linux-2.6.22 are come from BSP=20
> of freescale. I used
> the u-boot-1.2.0 that compiled by myself. We guess that maybe=20
> we did not setup the
> bootargs parameter on u-boot rightly or maybe the DDR-I=20
> hardware circuit design is
> not good enough.
>=20
> If the reason is the bootargs parameter, could you tell me=20
> what is the right
> bootargs for linux-2.6.19 and linux-2.6.22?
>=20
> If the reason is the DDR, I want to boot the linux on my=20
> SDRAM chip,kick off the
> DDR, my SDRAM located on the address of F0000000~F3FFFFFF,=20
> total 64MB. How can I
> modify the source code of linux to re-map it and ramdisk and=20
> others to my SDRAM
> chip space?
>=20
>=20
> Follow is the fail information:
> =3D> bootm 0c000000 0e000000
> ## Booting image at 0c000000 ...
> Image Name: Linux-2.6.22
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1333681 Bytes =3D 1.3 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 0e000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 3589813 Bytes =3D 3.4 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Loading Ramdisk to 0fc3e000, end 0ffaa6b5 ... OK =20
>=20
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* [PATCH 0/2] IB/ehca: Return physical link information, fix static rate calculation
From: Joachim Fenkes @ 2007-11-02 13:32 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
This patchset will fix static rate calculation for the new link speeds
supported by eHCA2. Also, it enables query_port() to return physical link
information instead of constant values, which is needed for the static rate
fix.
[1/2] makes query_port() return actual physical link info where supported
[2/2] fixes static rate calculation based on that info
The patches will apply, in order, on top of Roland's for-2.6.24 branch.
Please review them and apply for 2.6.24-rc2 if you think they're okay.
Thanks and regards,
Joachim
--
Joachim Fenkes -- eHCA Linux Driver Developer and Hardware Tamer
IBM Deutschland Entwicklung GmbH -- Dept. 3627 (I/O Firmware Dev. 2)
Schoenaicher Strasse 220 -- 71032 Boeblingen -- Germany
eMail: fenkes@de.ibm.com
^ permalink raw reply
* [PATCH 1/2] IB/ehca: Return physical link information in query_port()
From: Joachim Fenkes @ 2007-11-02 13:33 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200711021432.50203.fenkes@de.ibm.com>
Newer firmware versions return physical port information to the partition,
so hand that information to the consumer if it's present.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_hca.c | 20 ++++++++++++++------
drivers/infiniband/hw/ehca/hipz_hw.h | 6 +++++-
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_hca.c b/drivers/infiniband/hw/ehca/ehca_hca.c
index 15806d1..5bd7b59 100644
--- a/drivers/infiniband/hw/ehca/ehca_hca.c
+++ b/drivers/infiniband/hw/ehca/ehca_hca.c
@@ -151,7 +151,6 @@ int ehca_query_port(struct ib_device *ibdev,
}
memset(props, 0, sizeof(struct ib_port_attr));
- props->state = rblock->state;
switch (rblock->max_mtu) {
case 0x1:
@@ -188,11 +187,20 @@ int ehca_query_port(struct ib_device *ibdev,
props->subnet_timeout = rblock->subnet_timeout;
props->init_type_reply = rblock->init_type_reply;
- props->active_width = IB_WIDTH_12X;
- props->active_speed = 0x1;
-
- /* at the moment (logical) link state is always LINK_UP */
- props->phys_state = 0x5;
+ if (rblock->state && rblock->phys_width) {
+ props->phys_state = rblock->phys_pstate;
+ props->state = rblock->phys_state;
+ props->active_width = rblock->phys_width;
+ props->active_speed = rblock->phys_speed;
+ } else {
+ /* old firmware releases don't report physical
+ * port info, so use default values
+ */
+ props->phys_state = 5;
+ props->state = rblock->state;
+ props->active_width = IB_WIDTH_12X;
+ props->active_speed = 0x1;
+ }
query_port1:
ehca_free_fw_ctrlblock(rblock);
diff --git a/drivers/infiniband/hw/ehca/hipz_hw.h b/drivers/infiniband/hw/ehca/hipz_hw.h
index d9739e5..485b840 100644
--- a/drivers/infiniband/hw/ehca/hipz_hw.h
+++ b/drivers/infiniband/hw/ehca/hipz_hw.h
@@ -402,7 +402,11 @@ struct hipz_query_port {
u64 max_msg_sz;
u32 max_mtu;
u32 vl_cap;
- u8 reserved2[1900];
+ u32 phys_pstate;
+ u32 phys_state;
+ u32 phys_speed;
+ u32 phys_width;
+ u8 reserved2[1884];
u64 guid_entries[255];
} __attribute__ ((packed));
--
1.5.2
^ permalink raw reply related
* [PATCH 2/2] IB/ehca: Fix static rate calculation
From: Joachim Fenkes @ 2007-11-02 13:41 UTC (permalink / raw)
To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG
Cc: Stefan Roscher, Christoph Raisch
In-Reply-To: <200711021432.50203.fenkes@de.ibm.com>
The IPD formula was a little off and assumed a fixed physical link rate; fix
the formula and query the actual physical link rate, now that we can get it.
Also, refactor the calculation into a common function ehca_calc_ipd() and
use that instead of duplicating code.
Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_av.c | 48 +++++++++++++++++++++++-----
drivers/infiniband/hw/ehca/ehca_classes.h | 1 -
drivers/infiniband/hw/ehca/ehca_iverbs.h | 3 ++
drivers/infiniband/hw/ehca/ehca_main.c | 3 --
drivers/infiniband/hw/ehca/ehca_qp.c | 29 +++++++----------
5 files changed, 54 insertions(+), 30 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_av.c b/drivers/infiniband/hw/ehca/ehca_av.c
index 97d1086..453eb99 100644
--- a/drivers/infiniband/hw/ehca/ehca_av.c
+++ b/drivers/infiniband/hw/ehca/ehca_av.c
@@ -50,6 +50,38 @@
static struct kmem_cache *av_cache;
+int ehca_calc_ipd(struct ehca_shca *shca, int port,
+ enum ib_rate path_rate, u32 *ipd)
+{
+ int path = ib_rate_to_mult(path_rate);
+ int link, ret;
+ struct ib_port_attr pa;
+
+ if (path_rate == IB_RATE_PORT_CURRENT) {
+ *ipd = 0;
+ return 0;
+ }
+
+ if (unlikely(path < 0)) {
+ ehca_err(&shca->ib_device, "Invalid static rate! path_rate=%x",
+ path_rate);
+ return -EINVAL;
+ }
+
+ ret = ehca_query_port(&shca->ib_device, port, &pa);
+ if (unlikely(ret < 0)) {
+ ehca_err(&shca->ib_device, "Failed to query port ret=%i", ret);
+ return ret;
+ }
+
+ link = ib_width_enum_to_int(pa.active_width) * pa.active_speed;
+
+ /* IPD = round((link / path) - 1) */
+ *ipd = ((link + (path >> 1)) / path) - 1;
+
+ return 0;
+}
+
struct ib_ah *ehca_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
{
int ret;
@@ -69,15 +101,13 @@ struct ib_ah *ehca_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
av->av.slid_path_bits = ah_attr->src_path_bits;
if (ehca_static_rate < 0) {
- int ah_mult = ib_rate_to_mult(ah_attr->static_rate);
- int ehca_mult =
- ib_rate_to_mult(shca->sport[ah_attr->port_num].rate );
-
- if (ah_mult >= ehca_mult)
- av->av.ipd = 0;
- else
- av->av.ipd = (ah_mult > 0) ?
- ((ehca_mult - 1) / ah_mult) : 0;
+ u32 ipd;
+ if (ehca_calc_ipd(shca, ah_attr->port_num,
+ ah_attr->static_rate, &ipd)) {
+ ret = -EINVAL;
+ goto create_ah_exit1;
+ }
+ av->av.ipd = ipd;
} else
av->av.ipd = ehca_static_rate;
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 2d660ae..87f12d4 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -95,7 +95,6 @@ struct ehca_sma_attr {
struct ehca_sport {
struct ib_cq *ibcq_aqp1;
struct ib_qp *ibqp_aqp1;
- enum ib_rate rate;
enum ib_port_state port_state;
struct ehca_sma_attr saved_attr;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_iverbs.h b/drivers/infiniband/hw/ehca/ehca_iverbs.h
index dce503b..5485799 100644
--- a/drivers/infiniband/hw/ehca/ehca_iverbs.h
+++ b/drivers/infiniband/hw/ehca/ehca_iverbs.h
@@ -189,6 +189,9 @@ int ehca_mmap(struct ib_ucontext *context, struct vm_area_struct *vma);
void ehca_poll_eqs(unsigned long data);
+int ehca_calc_ipd(struct ehca_shca *shca, int port,
+ enum ib_rate path_rate, u32 *ipd);
+
#ifdef CONFIG_PPC_64K_PAGES
void *ehca_alloc_fw_ctrlblock(gfp_t flags);
void ehca_free_fw_ctrlblock(void *ptr);
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index c6cd38c..90d4334 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -327,9 +327,6 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
shca->hw_level = ehca_hw_level;
ehca_gen_dbg(" ... hardware level=%x", shca->hw_level);
- shca->sport[0].rate = IB_RATE_30_GBPS;
- shca->sport[1].rate = IB_RATE_30_GBPS;
-
shca->hca_cap = rblock->hca_cap_indicators;
ehca_gen_dbg(" ... HCA capabilities:");
for (i = 0; i < ARRAY_SIZE(hca_cap_descr); i++)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index de18264..2e3e654 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -1196,10 +1196,6 @@ static int internal_modify_qp(struct ib_qp *ibqp,
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_QKEY, 1);
}
if (attr_mask & IB_QP_AV) {
- int ah_mult = ib_rate_to_mult(attr->ah_attr.static_rate);
- int ehca_mult = ib_rate_to_mult(shca->sport[my_qp->
- init_attr.port_num].rate);
-
mqpcb->dlid = attr->ah_attr.dlid;
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_DLID, 1);
mqpcb->source_path_bits = attr->ah_attr.src_path_bits;
@@ -1207,11 +1203,12 @@ static int internal_modify_qp(struct ib_qp *ibqp,
mqpcb->service_level = attr->ah_attr.sl;
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_SERVICE_LEVEL, 1);
- if (ah_mult < ehca_mult)
- mqpcb->max_static_rate = (ah_mult > 0) ?
- ((ehca_mult - 1) / ah_mult) : 0;
- else
- mqpcb->max_static_rate = 0;
+ if (ehca_calc_ipd(shca, my_qp->init_attr.port_num,
+ attr->ah_attr.static_rate,
+ &mqpcb->max_static_rate)) {
+ ret = -EINVAL;
+ goto modify_qp_exit2;
+ }
update_mask |= EHCA_BMASK_SET(MQPCB_MASK_MAX_STATIC_RATE, 1);
/*
@@ -1280,10 +1277,6 @@ static int internal_modify_qp(struct ib_qp *ibqp,
(MQPCB_MASK_RDMA_ATOMIC_OUTST_DEST_QP, 1);
}
if (attr_mask & IB_QP_ALT_PATH) {
- int ah_mult = ib_rate_to_mult(attr->alt_ah_attr.static_rate);
- int ehca_mult = ib_rate_to_mult(
- shca->sport[my_qp->init_attr.port_num].rate);
-
if (attr->alt_port_num < 1
|| attr->alt_port_num > shca->num_ports) {
ret = -EINVAL;
@@ -1309,10 +1302,12 @@ static int internal_modify_qp(struct ib_qp *ibqp,
mqpcb->source_path_bits_al = attr->alt_ah_attr.src_path_bits;
mqpcb->service_level_al = attr->alt_ah_attr.sl;
- if (ah_mult > 0 && ah_mult < ehca_mult)
- mqpcb->max_static_rate_al = (ehca_mult - 1) / ah_mult;
- else
- mqpcb->max_static_rate_al = 0;
+ if (ehca_calc_ipd(shca, my_qp->init_attr.port_num,
+ attr->alt_ah_attr.static_rate,
+ &mqpcb->max_static_rate_al)) {
+ ret = -EINVAL;
+ goto modify_qp_exit2;
+ }
/* OpenIB doesn't support alternate retry counts - copy them */
mqpcb->retry_count_al = mqpcb->retry_count;
--
1.5.2
^ permalink raw reply related
* Re: The question about the fail at the begin of linux on MPC8360E.
From: Timur Tabi @ 2007-11-02 13:54 UTC (permalink / raw)
To: ??; +Cc: linuxppc-embedded
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174CCE3@az33exm24.fsl.freescale.net>
Medve Emilian-EMMEDVE1 wrote:
> Hi there,
>
>
> You need a device tree. The defaut one is arch/powerpc/boot/dts/mpc836x_mds.dts. You need the DTC (Device Tree Compiler) from here http://jdl.com/git_repos/?p=dtc.git;a=summary. This should be enough to give you some reading pointers.
And if your U-Boot doesn't support device trees, you'll need to enable cuImage
support in the kernel as well.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: khollan @ 2007-11-02 14:37 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <200711020944.53077.wangbj@lzu.edu.cn>
Wang, Baojun wrote:
>
>
>
> Your kernel don't have kgdb support? then you need a debugger like bdi2000
> to
> debug the kernel.
>
> Wang
>
>
Do I need to add kgdb even if I just want to debug a user application over
serial?
--
View this message in context: http://www.nabble.com/serial-GDBServer-PPC405--problems-tf4732593.html#a13548781
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: serial GDBServer PPC405 problems
From: Grant Likely @ 2007-11-02 14:57 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <13548781.post@talk.nabble.com>
On 11/2/07, khollan <khollan@daktronics.com> wrote:
>
>
> Wang, Baojun wrote:
> >
> >
> >
> > Your kernel don't have kgdb support? then you need a debugger like bdi2000
> > to
> > debug the kernel.
> >
> > Wang
> >
> >
> Do I need to add kgdb even if I just want to debug a user application over
> serial?
No you don't. gdbserver is the right tool.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
From: Badari Pulavarty @ 2007-11-02 15:57 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193999530.25744.3.camel@johannes.berg>
On Fri, 2007-11-02 at 10:32 +0000, Johannes Berg wrote:
> > This patch provides a way for an architecture to provide its
> > own walk_memory_resource()
>
> It seems that the patch description "walk_memory_remove()" is wrong?
>
Yep. Patch title is wrong.
Thanks,
Badari
^ permalink raw reply
* [PATCH] dtc: Fix the install target
From: Emil Medve @ 2007-11-02 15:26 UTC (permalink / raw)
To: jdl, linuxppc-dev; +Cc: Emil Medve
/usr/bin/install: cannot stat `fdt.h': No such file or directory
/usr/bin/install: cannot stat `libfdt.h': No such file or directory
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
Makefile | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 84f0efe..d59554a 100644
--- a/Makefile
+++ b/Makefile
@@ -56,7 +56,7 @@ install: all
$(INSTALL) -d $(DESTDIR)$(LIBDIR)
$(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
$(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
- $(INSTALL) -m 644 $(LIBFDT_INCLUDES) $(DESTDIR)$(INCLUDEDIR)
+ $(INSTALL) -m 644 $(addprefix $(LIBFDT_srcdir)/,$(LIBFDT_INCLUDES)) $(DESTDIR)$(INCLUDEDIR)
#
# Rules for versioning
@@ -136,17 +136,17 @@ endif
#
LIBFDT_objdir = libfdt
LIBFDT_srcdir = libfdt
-include libfdt/Makefile.libfdt
+include $(LIBFDT_srcdir)/Makefile.libfdt
.PHONY: libfdt
libfdt: $(LIBFDT_LIB)
-$(LIBFDT_LIB): $(addprefix libfdt/,$(LIBFDT_OBJS))
+$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
- rm -f $(addprefix libfdt/,$(STD_CLEANFILES))
- rm -f $(addprefix libfdt/,$(LIBFDT_CLEANFILES))
+ rm -f $(addprefix $(LIBFDT_objdir)/,$(STD_CLEANFILES))
+ rm -f $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_CLEANFILES))
ifneq ($(DEPTARGETS),)
-include $(LIBFDT_OBJS:%.o=$(LIBFDT_objdir)/%.d)
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] net: Add 405EX support to new EMAC driver
From: Olof Johansson @ 2007-11-02 16:03 UTC (permalink / raw)
To: Stefan Roese; +Cc: netdev, linuxppc-dev
In-Reply-To: <200711020814.43524.sr@denx.de>
On Fri, Nov 02, 2007 at 08:14:43AM +0100, Stefan Roese wrote:
> This patch adds support for the 405EX to the new EMAC driver. Some as on
> AXON, the 405EX handles the MDIO via the RGMII bridge.
Hi,
This isn't feedback on your patch as much as on "new-emac" in general:
Isn't this the case where there should really be device tree properties
instead? If you had an "ibm,emac-has-axon-stacr" property in the device
node, then you don't have to modify the driver for every new board out
there. Same for the other device properties, of course.
I thought this was what having the device tree was all about. :(
-Olof
^ permalink raw reply
* Regarding Linux 2.4/2.6 for Virtex
From: ramkumarj Ramkumar @ 2007-11-02 16:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
Hi All,
I m new to Linux development on Xilinx Platform and have a basic query. From
where can I download Linux 2.4 Kernel source for Virtex ML-403/300. I tried
using linuxppc_2_4_devel and linuxppc-2.4 since they have the drivers
support already included. But it looks like a build breakage and the last
update shows 2005. It would be really helpful if some one could elaborate on
the source trees available as of today for Xilinx Dev or point some
references to same. I would appreciate if information regarding Linux Kernel
2.6 for Xilinx is also included.
Best Regards,
Ram
[-- Attachment #2: Type: text/html, Size: 648 bytes --]
^ permalink raw reply
* [PATCH] [ML403-AC97CR] Fix capture/periodic overrun bug.
From: Joachim Foerster @ 2007-11-02 17:52 UTC (permalink / raw)
To: linuxppc-embedded, alsa-devel
Cc: Takashi Iwai, Stephen Neuendorffer, Lorenz Kolb
Hi all,
this is a bug fix for my ALSA driver I posted in August. Since then I
hadn't the time to look at it, but some days ago I took some time and
found the reason why there are so many overruns while capturing.
Furthermore, this patch removes the one "heavy" printk for capture
debugging.
From: Joachim Foerster <JOFT@gmx.de>
We have to do fairly accurate counting of the minimal periods, instead
of being lazy and just setting the number to zero as soon as one period
elapses.
Signed-off-by: Joachim Foerster <JOFT@gmx.de>
---
sound/drivers/ml403-ac97cr.c | 6 ++----
sound/drivers/pcm-indirect2.c | 20 ++------------------
2 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/sound/drivers/ml403-ac97cr.c b/sound/drivers/ml403-ac97cr.c
index 2636249..1b16a21 100644
--- a/sound/drivers/ml403-ac97cr.c
+++ b/sound/drivers/ml403-ac97cr.c
@@ -28,11 +28,9 @@
* accesses to a minimum, because after a variable amount of accesses, the AC97
* controller doesn't raise the register access finished bit anymore ...
*
- * - Capture support works - basically, but after ~30s (with rates > ~20kHz)
- * ALSA stops reading captured samples from the intermediate buffer and
- * therefore a overrun happens - ATM I don't know what's wrong.
- *
* - Playback support seems to be pretty stable - no issues here.
+ * - Capture support "works" now, too. Overruns don't happen any longer so often.
+ * But there might still be some ...
*/
#include <sound/driver.h>
diff --git a/sound/drivers/pcm-indirect2.c b/sound/drivers/pcm-indirect2.c
index a36215a..ef74a38 100644
--- a/sound/drivers/pcm-indirect2.c
+++ b/sound/drivers/pcm-indirect2.c
@@ -403,7 +403,7 @@ snd_pcm_indirect2_playback_interrupt(struct snd_pcm_substream *substream,
rec->min_multiple);
rec->mul_elapsed++;
#endif
- rec->min_periods = 0;
+ rec->min_periods = (rec->min_periods % rec->min_multiple);
snd_pcm_period_elapsed(substream);
}
}
@@ -568,24 +568,8 @@ snd_pcm_indirect2_capture_interrupt(struct snd_pcm_substream *substream,
rec->mul_elapsed_real += (rec->min_periods /
rec->min_multiple);
rec->mul_elapsed++;
-
- if (!(rec->mul_elapsed % 4)) {
- struct snd_pcm_runtime *runtime = substream->runtime;
- unsigned int appl_ptr =
- frames_to_bytes(runtime,
- (unsigned int)runtime->control->
- appl_ptr) % rec->sw_buffer_size;
- int diff = rec->sw_data - appl_ptr;
- if (diff < 0)
- diff += rec->sw_buffer_size;
- snd_printk(KERN_DEBUG
- "STAT: mul_elapsed: %d, sw_data: %u, "
- "appl_ptr (bytes): %u, diff: %d\n",
- rec->mul_elapsed, rec->sw_data, appl_ptr,
- diff);
- }
#endif
- rec->min_periods = 0;
+ rec->min_periods = (rec->min_periods % rec->min_multiple);
snd_pcm_period_elapsed(substream);
}
}
--
1.5.2.5
^ permalink raw reply related
* GDB bdi2000 and mpc85xx
From: Stuart Hodgson @ 2007-11-02 17:17 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am attempting to get Kernel debugging working on our mpc8541 based
board via a BDI2000. The various components in use are
kernel - 2.6.19.2
BDI firmware - 1.08
U-Boot - 1.2.0
ppc_85xx-gdb - from eldk4.1 (6.3.0.0-1.21_3rh)
Kernel is configured with `-g` in CFLAGS and not with CONFIG_BDI_SWITCH,
from the information I have read around the subject this seem to be
correct. I also have `MMU XLAT`, and `PTBASE 0xF0` set in by BDI
configuration file. The default value for XLAT of `0xc0000000` matches
the kernel our kernel config.
Steps that I done so far
1. Power on BDI
2. Power on the board
3. BDI> reset run
4. Enter u-boot environment to stop linux booting immediately.
5. BDI> HALT
6. BDI> BREAK HARD
7. BDI> BI 0xc025a51c (this is the address of start_kernel for my build)
8. BDI> GO
9. From U-boot prompt `bootm`, kernel is copied from flash and loading
begins
10. Kernel does not halt at start_kernel and continues to the login
If I attempt to break at an address later in the boot sequence, such as
qmx19_ata_input_data (this is the area that I am trying to investigate)
I get
- TARGET: core #0 has entered debug mode
So from here I attempt to connect to the BDI from gdb
linux> cd ~/linux-2.6.19.2
linux> ppc_85xx-gdb vmlimux
"
GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
The target architecture is set automatically (currently powerpc:603)
"
I noticed here that the last line does not match the e500 core I am
using, but there does not seem to a change if I change this using `set
architecture powerpc:e500`
(gdb) tar rem <bdi_ip>:2001
Remote debugging using <bdi_ip>:2001
0x00000000 in ?? ()
What I don't understand here is why 0x00000000 is shown as the address,
further on the BDI the following error is shown then the connection is made
"
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
"
If I then clear the breakpoint from the BDI
BDI> CI
I can then from gdb set breakpoints
(gdb) b qmx19_ata_input_data
Breakpoint 1 at 0xc014ecb4: file drivers/ide/ppc/qmx19-ide.c, line 139.
(gdb) c
Continuing.
And all seems well with resolving the symbol names and and source files.
When the breakpoint is hit next
"
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000000 in ?? ()
(gdb) where
#0 0x00000000 in ?? ()
#1 0x00000000 in ?? ()
"
But as expected I can not do any debugging since the address's are not
being resolved by GDB/BDI. Trying to single step now results in gdb showing
(gdb) s
Cannot find bounds of current function
and BDI showing
*** MMU: address translation for 0x00000000 failed
*** MMU: address translation for 0xFFFFFFFC failed
So my problem would seem to be with address translation. If I ask the
BDI to translate the address for me it seems fine though
BDI> PHYS 0xc014ecb4
PHYS = 0x0_0014ecb4
So in summary is seem to me that there is a problem with the address
translation to from BDI GDB, most likely the result of a missing
configuration parameter or setting. I should also add that there there
is not an inherent problem with the build of Linux as it boots fine and
is operational but I would like to step though our CF card driver when
the kernel is loading.
I have seen a couple of similar questions asked regarding the mpc85xx
series but not any answers that have shed any light, by all accounts the
steps I have done would seem to just work for other people, such as the
BDI manual.
Does anyone have some insights into this.
thanks
Stuart Hodgson
^ permalink raw reply
* radeon boot "hot-crash"
From: Michael Buesch @ 2007-11-02 18:55 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi,
I'm wondering how we are finally going to fix my radeon
"hot-crash" issue.
Fact is, applying the patch below fixes the issue.
Though, I see that this is not the correct patch to fix it.
Other devices might need the register write which is removed here.
So what about the following:
We add a specialcase for the exact type (and revision and so on)
for my chip here.
How do find out what's my chiprevision?
What exactly should be checked for here, so that only this chip
is affected by the workaround?
Index: wireless-2.6/drivers/video/aty/radeon_i2c.c
===================================================================
--- wireless-2.6.orig/drivers/video/aty/radeon_i2c.c 2007-10-17 18:03:10.000000000 +0200
+++ wireless-2.6/drivers/video/aty/radeon_i2c.c 2007-10-17 18:18:52.000000000 +0200
@@ -137,13 +137,7 @@ void radeon_delete_i2c_busses(struct rad
int radeon_probe_i2c_connector(struct radeonfb_info *rinfo, int conn,
u8 **out_edid)
{
- u32 reg = rinfo->i2c[conn-1].ddc_reg;
- u8 *edid;
-
- OUTREG(reg, INREG(reg) &
- ~(VGA_DDC_DATA_OUTPUT | VGA_DDC_CLK_OUTPUT));
-
- edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
+ u8 *edid = fb_ddc_read(&rinfo->i2c[conn-1].adapter);
if (out_edid)
*out_edid = edid;
--
Greetings Michael.
^ permalink raw reply
* Re: [PATCH] using mii-bitbang on different processor ports
From: Scott Wood @ 2007-10-30 16:32 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev
In-Reply-To: <1193760559.6244.25.camel@p60635-ste.ids.de>
On Tue, Oct 30, 2007 at 05:09:19PM +0100, Sergej Stepanov wrote:
> The patch makes possible to have mdio and mdc pins on different physical ports
> also for CONFIG_PPC_CPM_NEW_BINDING.
> To setup it in the device tree:
> reg = <10d40 14 10d60 14>; // mdc-offset: 0x10d40, mdio-offset: 0x10d60
> or
> reg = <10d40 14>; // mdc and mdio have the same offset 0x10d40
> The approach was taken from older version.
There are some formatting issues in fs_mii_bitbang_init(), but otherwise it
looks good. It'll need to be sent to Jeff Garzik and the netdev list, not
just linuxppc-dev, though.
Also, please update Documentation/powerpc/booting-without-of.txt (probably
in a separate patch, since that one would go through Paul).
> @@ -142,13 +146,27 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
> return -ENODEV;
> mdc_pin = *data;
>
> - bitbang->dir = ioremap(res.start, res.end - res.start + 1);
> - if (!bitbang->dir)
> + bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
> + if (!bitbang->mdc.dir)
> return -ENOMEM;
>
> - bitbang->dat = bitbang->dir + 4;
> - bitbang->mdio_msk = 1 << (31 - mdio_pin);
> - bitbang->mdc_msk = 1 << (31 - mdc_pin);
> + bitbang->mdc.dat = bitbang->mdc.dir + 4;
> + if( !of_address_to_resource(np, 1, &res[1]))
Space before the '(', not after. A newline after the previous line would be
nice, too.
> + {
Brace at the end of the previous line.
> + bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
> + if (!bitbang->mdio.dir)
> + {
Likewise.
You could just use of_iomap() for the second one, since we don't need
the physical address for bus->id.
> + iounmap(bitbang->mdc.dir);
> + return -ENOMEM;
Please use the goto-style error handling that's used elsewhere in the
function.
> + }
> + bitbang->mdio.dat = bitbang->mdio.dir + 4;
> + }
> + else{
} else {
> out_unmap_regs:
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
> out_free_bus:
> kfree(new_bus);
> out_free_priv:
> @@ -238,7 +258,9 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
> free_mdio_bitbang(bus);
> dev_set_drvdata(&ofdev->dev, NULL);
> kfree(bus->irq);
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
> kfree(bitbang);
> kfree(bus);
"if (bitbang", not "if ( bitbang".
-Scott
^ permalink raw reply
* Re: Regarding Linux 2.4/2.6 for Virtex
From: Grant Likely @ 2007-11-02 19:08 UTC (permalink / raw)
To: ramkumarj Ramkumar; +Cc: linuxppc-embedded
In-Reply-To: <4f8c3030711020945p7ca1280nb9bc9db10d8df081@mail.gmail.com>
On 11/2/07, ramkumarj Ramkumar <ramkumarj2000@gmail.com> wrote:
>
>
> Hi All,
>
> I m new to Linux development on Xilinx Platform and have a basic query. From
> where can I download Linux 2.4 Kernel source for Virtex ML-403/300. I tried
> using linuxppc_2_4_devel and linuxppc-2.4 since they have the drivers
> support already included. But it looks like a build breakage and the last
> update shows 2005. It would be really helpful if some one could elaborate on
> the source trees available as of today for Xilinx Dev or point some
> references to same. I would appreciate if information regarding Linux Kernel
> 2.6 for Xilinx is also included.
I recommend going for a 2.6 kernel. The following link provides a bit
of information about it.
http://wiki.secretlab.ca/index.php/Linux_on_Xilinx_Virtex
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 0/3] powerpc eeh: bug fixes for crashes, bad handling
From: Linas Vepstas @ 2007-11-02 20:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
Hi Paul,
Please forward upstream the following three tiny patches
for EEH bugs, including on crash, and one failure to
reset correctly.
(I was planning on blasting you many many more patches,
involving MSI, but have had nothing but broken hardware
for the last few weeks, and so have nothing to show.
Dang, cause I needed the msi fixes for 2.6.24. Oh well.)
--linas
^ permalink raw reply
* [PATCH 1/3] powerpc eeh: cleanup comments
From: Linas Vepstas @ 2007-11-02 20:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20071102201957.GU2183@austin.ibm.com>
Clean up commentary, remove dead code.
Signed-off-by Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:39:18.000000000 -0500
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:46:30.000000000 -0500
@@ -113,9 +113,9 @@ static void eeh_report_error(struct pci_
/**
* eeh_report_mmio_enabled - tell drivers that MMIO has been enabled
*
- * Report an EEH error to each device driver, collect up and
- * merge the device driver responses. Cumulative response
- * passed back in "userdata".
+ * Tells each device driver that IO ports, MMIO and config space I/O
+ * are now enabled. Collects up and merges the device driver responses.
+ * Cumulative response passed back in "userdata".
*/
static void eeh_report_mmio_enabled(struct pci_dev *dev, void *userdata)
@@ -123,8 +123,6 @@ static void eeh_report_mmio_enabled(stru
enum pci_ers_result rc, *res = userdata;
struct pci_driver *driver = dev->driver;
- // dev->error_state = pci_channel_mmio_enabled;
-
if (!driver ||
!driver->err_handler ||
!driver->err_handler->mmio_enabled)
^ permalink raw reply
* [PATCH 2/3]: powerpc eeh: drivers that need reset trump others
From: Linas Vepstas @ 2007-11-02 20:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20071102202555.GA13828@austin.ibm.com>
Bugfix: if a driver controlling one part of a multi-function
pci card has asked for a reset, honor that request above all
othres.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh_driver.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:46:30.000000000 -0500
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh_driver.c 2007-10-16 11:54:27.000000000 -0500
@@ -105,9 +105,10 @@ static void eeh_report_error(struct pci_
return;
rc = driver->err_handler->error_detected (dev, pci_channel_io_frozen);
+
+ /* A driver that needs a reset trumps all others */
+ if (rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
if (*res == PCI_ERS_RESULT_NONE) *res = rc;
- if (*res == PCI_ERS_RESULT_DISCONNECT &&
- rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
}
/**
@@ -129,9 +130,10 @@ static void eeh_report_mmio_enabled(stru
return;
rc = driver->err_handler->mmio_enabled (dev);
+
+ /* A driver that needs a reset trumps all others */
+ if (rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
if (*res == PCI_ERS_RESULT_NONE) *res = rc;
- if (*res == PCI_ERS_RESULT_DISCONNECT &&
- rc == PCI_ERS_RESULT_NEED_RESET) *res = rc;
}
/**
^ permalink raw reply
* [PATCH 3/3]: powerpc eeh: avoid crash on null device.
From: Linas Vepstas @ 2007-11-02 20:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: ppc-dev
In-Reply-To: <20071102202750.GB13828@austin.ibm.com>
Bugfix: avoid crash if there's no pci device for a given
openfirmware node.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
arch/powerpc/platforms/pseries/eeh.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c
===================================================================
--- linux-2.6.23-rc8-mm1.orig/arch/powerpc/platforms/pseries/eeh.c 2007-10-16 13:55:03.000000000 -0500
+++ linux-2.6.23-rc8-mm1/arch/powerpc/platforms/pseries/eeh.c 2007-10-16 14:04:39.000000000 -0500
@@ -186,6 +186,11 @@ static size_t gather_pci_data(struct pci
n += scnprintf(buf+n, len-n, "cmd/stat:%x\n", cfg);
printk(KERN_WARNING "EEH: PCI cmd/status register: %08x\n", cfg);
+ if (!dev) {
+ printk(KERN_WARNING "EEH: no PCI device for this of node\n");
+ return n;
+ }
+
/* Gather bridge-specific registers */
if (dev->class >> 16 == PCI_BASE_CLASS_BRIDGE) {
rtas_read_config(pdn, PCI_SEC_STATUS, 2, &cfg);
@@ -198,7 +203,7 @@ static size_t gather_pci_data(struct pci
}
/* Dump out the PCI-X command and status regs */
- cap = pci_find_capability(pdn->pcidev, PCI_CAP_ID_PCIX);
+ cap = pci_find_capability(dev, PCI_CAP_ID_PCIX);
if (cap) {
rtas_read_config(pdn, cap, 4, &cfg);
n += scnprintf(buf+n, len-n, "pcix-cmd:%x\n", cfg);
@@ -210,7 +215,7 @@ static size_t gather_pci_data(struct pci
}
/* If PCI-E capable, dump PCI-E cap 10, and the AER */
- cap = pci_find_capability(pdn->pcidev, PCI_CAP_ID_EXP);
+ cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
if (cap) {
n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
printk(KERN_WARNING
@@ -222,7 +227,7 @@ static size_t gather_pci_data(struct pci
printk(KERN_WARNING "EEH: PCI-E %02x: %08x\n", i, cfg);
}
- cap = pci_find_ext_capability(pdn->pcidev, PCI_EXT_CAP_ID_ERR);
+ cap = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ERR);
if (cap) {
n += scnprintf(buf+n, len-n, "pci-e AER:\n");
printk(KERN_WARNING
^ permalink raw reply
* Re: [2.6 patch] the scheduled I2C RTC driver removal
From: Jean Delvare @ 2007-11-02 22:12 UTC (permalink / raw)
To: Adrian Bunk; +Cc: linuxppc-dev, linux-kernel, rtc-linux, i2c
In-Reply-To: <20071031230357.GW7227@stusta.de>
Hi Adrian,
On Thu, 1 Nov 2007 00:03:58 +0100, Adrian Bunk wrote:
> This patch contains the scheduled removal of legacy I2C RTC drivers with
> replacement drivers.
I'm adding the rtc list in Cc.
>
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
>
> Documentation/feature-removal-schedule.txt | 7
> arch/powerpc/platforms/83xx/mpc832x_mds.c | 24 -
> arch/powerpc/platforms/83xx/mpc834x_mds.c | 24 -
> arch/powerpc/platforms/83xx/mpc836x_mds.c | 24 -
> arch/ppc/platforms/83xx/mpc834x_sys.c | 20 -
> arch/ppc/platforms/85xx/tqm85xx.c | 21 -
> arch/ppc/platforms/katana.c | 21 -
> drivers/i2c/chips/Kconfig | 38 -
> drivers/i2c/chips/Makefile | 3
> drivers/i2c/chips/ds1337.c | 410 --------------------
> drivers/i2c/chips/ds1374.c | 267 -------------
> drivers/i2c/chips/m41t00.c | 413 ---------------------
> include/linux/m41t00.h | 50 --
> 13 files changed, 1322 deletions(-)
Obviously we're not yet ready to remove the drivers, as some platforms
still use them! The remaining platforms need to be updated to use the
new RTC drivers first. The mapping is as follows:
chip | old driver | new driver |
-----------+------------+--------------+
DS1337 | ds1337 | rtc-ds1307 |
DS1339 | ds1337 | rtc-ds1307 |
DS1374 | ds1374 | rtc-ds1374 |
M41T00 | m41t00 | rtc-ds1307 |
M41T81 | m41t00 | rtc-m41t80 |
M41ST85 | m41t00 | rtc-m41t80 |
So, PPC people, please update your platform code to make use of the new
drivers now, and let me know when you're done. As soon as all platforms
are converted, I'll apply Adrian's patch.
Thanks.
>
> bf858b44b3071082be3aaf71e2d46ddb26415247
> diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
> index 6bb9be5..391f2d1 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-schedule.txt
> @@ -275,13 +275,6 @@ Who: Tejun Heo <htejun@gmail.com>
>
> ---------------------------
>
> -What: Legacy RTC drivers (under drivers/i2c/chips)
> -When: November 2007
> -Why: Obsolete. We have a RTC subsystem with better drivers.
> -Who: Jean Delvare <khali@linux-fr.org>
> -
> ----------------------------
> -
> What: iptables SAME target
> When: 1.1. 2008
> Files: net/ipv4/netfilter/ipt_SAME.c, include/linux/netfilter_ipv4/ipt_SAME.h
> diff --git a/arch/powerpc/platforms/83xx/mpc832x_mds.c b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> index 972fa85..66382df 100644
> --- a/arch/powerpc/platforms/83xx/mpc832x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc832x_mds.c
> @@ -145,30 +145,6 @@ static void __init mpc832x_sys_init_IRQ(void)
> #endif /* CONFIG_QUICC_ENGINE */
> }
>
> -#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
> -extern ulong ds1374_get_rtc_time(void);
> -extern int ds1374_set_rtc_time(ulong);
> -
> -static int __init mpc832x_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - if (!machine_is(mpc832x_mds))
> - return 0;
> -
> - ppc_md.get_rtc_time = ds1374_get_rtc_time;
> - ppc_md.set_rtc_time = ds1374_set_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time) ();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -
> -late_initcall(mpc832x_rtc_hookup);
> -#endif
> -
> /*
> * Called very early, MMU is off, device-tree isn't unflattened
> */
> diff --git a/arch/powerpc/platforms/83xx/mpc834x_mds.c b/arch/powerpc/platforms/83xx/mpc834x_mds.c
> index 00aed7c..a81bb3c 100644
> --- a/arch/powerpc/platforms/83xx/mpc834x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc834x_mds.c
> @@ -106,30 +106,6 @@ static void __init mpc834x_mds_init_IRQ(void)
> ipic_set_default_priority();
> }
>
> -#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
> -extern ulong ds1374_get_rtc_time(void);
> -extern int ds1374_set_rtc_time(ulong);
> -
> -static int __init mpc834x_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - if (!machine_is(mpc834x_mds))
> - return 0;
> -
> - ppc_md.get_rtc_time = ds1374_get_rtc_time;
> - ppc_md.set_rtc_time = ds1374_set_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time) ();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -
> -late_initcall(mpc834x_rtc_hookup);
> -#endif
> -
> /*
> * Called very early, MMU is off, device-tree isn't unflattened
> */
> diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> index 0f3855c..8d87b9c 100644
> --- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
> +++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
> @@ -152,30 +152,6 @@ static void __init mpc836x_mds_init_IRQ(void)
> #endif /* CONFIG_QUICC_ENGINE */
> }
>
> -#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
> -extern ulong ds1374_get_rtc_time(void);
> -extern int ds1374_set_rtc_time(ulong);
> -
> -static int __init mpc8360_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - if (!machine_is(mpc836x_mds))
> - return 0;
> -
> - ppc_md.get_rtc_time = ds1374_get_rtc_time;
> - ppc_md.set_rtc_time = ds1374_set_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time) ();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -
> -late_initcall(mpc8360_rtc_hookup);
> -#endif
> -
> /*
> * Called very early, MMU is off, device-tree isn't unflattened
> */
> diff --git a/arch/ppc/platforms/83xx/mpc834x_sys.c b/arch/ppc/platforms/83xx/mpc834x_sys.c
> index b84f8df..cb0a749 100644
> --- a/arch/ppc/platforms/83xx/mpc834x_sys.c
> +++ b/arch/ppc/platforms/83xx/mpc834x_sys.c
> @@ -224,26 +224,6 @@ mpc834x_sys_init_IRQ(void)
> ipic_set_default_priority();
> }
>
> -#if defined(CONFIG_I2C_MPC) && defined(CONFIG_SENSORS_DS1374)
> -extern ulong ds1374_get_rtc_time(void);
> -extern int ds1374_set_rtc_time(ulong);
> -
> -static int __init
> -mpc834x_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - ppc_md.get_rtc_time = ds1374_get_rtc_time;
> - ppc_md.set_rtc_time = ds1374_set_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time)();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -late_initcall(mpc834x_rtc_hookup);
> -#endif
> static __inline__ void
> mpc834x_sys_set_bat(void)
> {
> diff --git a/arch/ppc/platforms/85xx/tqm85xx.c b/arch/ppc/platforms/85xx/tqm85xx.c
> index 4ee2bd1..27ce389 100644
> --- a/arch/ppc/platforms/85xx/tqm85xx.c
> +++ b/arch/ppc/platforms/85xx/tqm85xx.c
> @@ -258,27 +258,6 @@ int tqm85xx_show_cpuinfo(struct seq_file *m)
> return 0;
> }
>
> -#if defined(CONFIG_I2C) && defined(CONFIG_SENSORS_DS1337)
> -extern ulong ds1337_get_rtc_time(void);
> -extern int ds1337_set_rtc_time(unsigned long nowtime);
> -
> -static int __init
> -tqm85xx_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - ppc_md.set_rtc_time = ds1337_set_rtc_time;
> - ppc_md.get_rtc_time = ds1337_get_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time)();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -late_initcall(tqm85xx_rtc_hookup);
> -#endif
> -
> #ifdef CONFIG_PCI
> /*
> * interrupt routing
> diff --git a/arch/ppc/platforms/katana.c b/arch/ppc/platforms/katana.c
> index 52f63e6..fe6e88c 100644
> --- a/arch/ppc/platforms/katana.c
> +++ b/arch/ppc/platforms/katana.c
> @@ -838,27 +838,6 @@ katana_find_end_of_memory(void)
> return bdp->bi_memsize;
> }
>
> -#if defined(CONFIG_I2C_MV64XXX) && defined(CONFIG_SENSORS_M41T00)
> -extern ulong m41t00_get_rtc_time(void);
> -extern int m41t00_set_rtc_time(ulong);
> -
> -static int __init
> -katana_rtc_hookup(void)
> -{
> - struct timespec tv;
> -
> - ppc_md.get_rtc_time = m41t00_get_rtc_time;
> - ppc_md.set_rtc_time = m41t00_set_rtc_time;
> -
> - tv.tv_nsec = 0;
> - tv.tv_sec = (ppc_md.get_rtc_time)();
> - do_settimeofday(&tv);
> -
> - return 0;
> -}
> -late_initcall(katana_rtc_hookup);
> -#endif
> -
> #if defined(CONFIG_SERIAL_TEXT_DEBUG) && defined(CONFIG_SERIAL_MPSC_CONSOLE)
> static void __init
> katana_map_io(void)
> diff --git a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
> index 2e1c24f..5b8eb02 100644
> --- a/drivers/i2c/chips/Kconfig
> +++ b/drivers/i2c/chips/Kconfig
> @@ -4,32 +4,6 @@
>
> menu "Miscellaneous I2C Chip support"
>
> -config SENSORS_DS1337
> - tristate "Dallas DS1337 and DS1339 Real Time Clock (DEPRECATED)"
> - depends on EXPERIMENTAL
> - help
> - If you say yes here you get support for Dallas Semiconductor
> - DS1337 and DS1339 real-time clock chips.
> -
> - This driver can also be built as a module. If so, the module
> - will be called ds1337.
> -
> - This driver is deprecated and will be dropped soon. Use
> - rtc-ds1307 instead.
> -
> -config SENSORS_DS1374
> - tristate "Dallas DS1374 Real Time Clock (DEPRECATED)"
> - depends on EXPERIMENTAL
> - help
> - If you say yes here you get support for Dallas Semiconductor
> - DS1374 real-time clock chips.
> -
> - This driver can also be built as a module. If so, the module
> - will be called ds1374.
> -
> - This driver is deprecated and will be dropped soon. Use
> - rtc-ds1374 instead.
> -
> config DS1682
> tristate "Dallas DS1682 Total Elapsed Time Recorder with Alarm"
> depends on EXPERIMENTAL
> @@ -116,18 +90,6 @@ config TPS65010
> This driver can also be built as a module. If so, the module
> will be called tps65010.
>
> -config SENSORS_M41T00
> - tristate "ST M41T00 RTC chip (DEPRECATED)"
> - depends on PPC32
> - help
> - If you say yes here you get support for the ST M41T00 RTC chip.
> -
> - This driver can also be built as a module. If so, the module
> - will be called m41t00.
> -
> - This driver is deprecated and will be dropped soon. Use
> - rtc-ds1307 or rtc-m41t80 instead.
> -
> config SENSORS_MAX6875
> tristate "Maxim MAX6875 Power supply supervisor"
> depends on EXPERIMENTAL
> diff --git a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
> index ca924e1..1d5d1a5 100644
> --- a/drivers/i2c/chips/Makefile
> +++ b/drivers/i2c/chips/Makefile
> @@ -2,12 +2,9 @@
> # Makefile for miscellaneous I2C chip drivers.
> #
>
> -obj-$(CONFIG_SENSORS_DS1337) += ds1337.o
> -obj-$(CONFIG_SENSORS_DS1374) += ds1374.o
> obj-$(CONFIG_DS1682) += ds1682.o
> obj-$(CONFIG_SENSORS_EEPROM) += eeprom.o
> obj-$(CONFIG_SENSORS_MAX6875) += max6875.o
> -obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
> obj-$(CONFIG_SENSORS_PCA9539) += pca9539.o
> obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
> obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
> (...)
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] dtc: Fix the install target
From: David Gibson @ 2007-11-03 0:37 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev, jdl
In-Reply-To: <1194017175-25610-1-git-send-email-Emilian.Medve@Freescale.com>
On Fri, Nov 02, 2007 at 10:26:15AM -0500, Emil Medve wrote:
> /usr/bin/install: cannot stat `fdt.h': No such file or directory
> /usr/bin/install: cannot stat `libfdt.h': No such file or directory
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: GDB bdi2000 and mpc85xx
From: Wang, Baojun @ 2007-11-03 3:40 UTC (permalink / raw)
To: Stuart Hodgson; +Cc: linuxppc-embedded
In-Reply-To: <394028554.26200@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 3363 bytes --]
On Saturday 03 November 2007 01:17:48, Stuart Hodgson wrote：
> Hi,
>
> I am attempting to get Kernel debugging working on our mpc8541 based
> board via a BDI2000. The various components in use are
>
> kernel - 2.6.19.2
> BDI firmware - 1.08
> U-Boot - 1.2.0
> ppc_85xx-gdb - from eldk4.1 (6.3.0.0-1.21_3rh)
>
>
> Kernel is configured with `-g` in CFLAGS and not with CONFIG_BDI_SWITCH,
> from the information I have read around the subject this seem to be
> correct. I also have `MMU XLAT`, and `PTBASE 0xF0` set in by BDI
> configuration file. The default value for XLAT of `0xc0000000` matches
> the kernel our kernel config.
>
> Steps that I done so far
>
> 1. Power on BDI
> 2. Power on the board
> 3. BDI> reset run
> 4. Enter u-boot environment to stop linux booting immediately.
> 5. BDI> HALT
> 6. BDI> BREAK HARD
> 7. BDI> BI 0xc025a51c (this is the address of start_kernel for my build)
> 8. BDI> GO
> 9. From U-boot prompt `bootm`, kernel is copied from flash and loading
> begins
> 10. Kernel does not halt at start_kernel and continues to the login
>
> If I attempt to break at an address later in the boot sequence, such as
> qmx19_ata_input_data (this is the area that I am trying to investigate)
> I get
>
> - TARGET: core #0 has entered debug mode
>
> So from here I attempt to connect to the BDI from gdb
>
> linux> cd ~/linux-2.6.19.2
> linux> ppc_85xx-gdb vmlimux
Most of the operation could be done within gdb
BDI> reset
powerpc-unknown-linux-gnu-gdb vmlinux
(gdb) target remote bdi:2001
(gdb) ^C
(gdb) b *0x12345678
(gdb) c
...
> "
> GNU gdb Red Hat Linux (6.3.0.0-1.21_3rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux".
> The target architecture is set automatically (currently powerpc:603)
> "
>
> I noticed here that the last line does not match the e500 core I am
> using, but there does not seem to a change if I change this using `set
> architecture powerpc:e500`
>
>
> (gdb) tar rem <bdi_ip>:2001
> Remote debugging using <bdi_ip>:2001
> 0x00000000 in ?? ()
Which configuration file do you use for mpc85xx? probably is the config file
problem?
> What I don't understand here is why 0x00000000 is shown as the address,
> further on the BDI the following error is shown then the connection is made
>
> "
> *** MMU: address translation for 0x00000000 failed
> Stuart Hodgson
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox