* [patch 6/7] ps3: Refactor ps3_repository_find_device()
From: Geert Uytterhoeven @ 2007-11-28 14:31 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Geert Uytterhoeven, Linux kernel mailing list
In-Reply-To: <20071128143142.580732000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2897 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3: Refactor ps3_repository_find_device() to use the existing
ps3_repository_read_bus_id()
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/platforms/ps3/repository.c | 60 +++++++++++---------------------
1 files changed, 22 insertions(+), 38 deletions(-)
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -445,50 +445,34 @@ int __devinit ps3_repository_find_device
pr_debug(" -> %s:%d: find bus_type %u\n", __func__, __LINE__, bus_type);
- for (repo.bus_index = 0; repo.bus_index < 10; repo.bus_index++) {
+ repo.bus_type = bus_type;
+ result = ps3_repository_find_bus(repo.bus_type, 0, &repo.bus_index);
+ if (result) {
+ pr_debug(" <- %s:%u: bus not found\n", __func__, __LINE__);
+ return result;
+ }
- result = ps3_repository_read_bus_type(repo.bus_index,
- &repo.bus_type);
+ result = ps3_repository_read_bus_id(repo.bus_index, &repo.bus_id);
+ if (result) {
+ pr_debug("%s:%d read_bus_id(%u) failed\n", __func__, __LINE__,
+ repo.bus_index);
+ return result;
+ }
- if (result) {
- pr_debug("%s:%d read_bus_type(%u) failed\n",
- __func__, __LINE__, repo.bus_index);
+ for (repo.dev_index = 0; ; repo.dev_index++) {
+ result = ps3_repository_find_device(&repo);
+ if (result == -ENODEV) {
+ result = 0;
+ break;
+ } else if (result)
break;
- }
-
- if (repo.bus_type != bus_type) {
- pr_debug("%s:%d: skip, bus_type %u\n", __func__,
- __LINE__, repo.bus_type);
- continue;
- }
-
- result = ps3_repository_read_bus_id(repo.bus_index,
- &repo.bus_id);
+ result = callback(&repo);
if (result) {
- pr_debug("%s:%d read_bus_id(%u) failed\n",
- __func__, __LINE__, repo.bus_index);
- continue;
- }
-
- for (repo.dev_index = 0; ; repo.dev_index++) {
- result = ps3_repository_find_device(&repo);
-
- if (result == -ENODEV) {
- result = 0;
- break;
- } else if (result)
- break;
-
- result = callback(&repo);
-
- if (result) {
- pr_debug("%s:%d: abort at callback\n", __func__,
- __LINE__);
- break;
- }
+ pr_debug("%s:%d: abort at callback\n", __func__,
+ __LINE__);
+ break;
}
- break;
}
pr_debug(" <- %s:%d\n", __func__, __LINE__);
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 5/7] ps3: Kill unused ps3_repository_bump_device()
From: Geert Uytterhoeven @ 2007-11-28 14:31 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Geert Uytterhoeven, Linux kernel mailing list
In-Reply-To: <20071128143142.580732000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
ps3: Kill unused ps3_repository_bump_device()
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/platforms/ps3/platform.h | 6 ------
1 files changed, 6 deletions(-)
--- a/arch/powerpc/platforms/ps3/platform.h
+++ b/arch/powerpc/platforms/ps3/platform.h
@@ -144,12 +144,6 @@ struct ps3_repository_device {
u64 dev_id;
};
-static inline struct ps3_repository_device *ps3_repository_bump_device(
- struct ps3_repository_device *repo)
-{
- repo->dev_index++;
- return repo;
-}
int ps3_repository_find_device(struct ps3_repository_device *repo);
int ps3_repository_find_device_by_id(struct ps3_repository_device *repo,
u64 bus_id, u64 dev_id);
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [patch 7/7] ps3: denoise arch/powerpc/platforms/ps3/repository.c
From: Geert Uytterhoeven @ 2007-11-28 14:31 UTC (permalink / raw)
To: Linux/PPC Development; +Cc: Geert Uytterhoeven, Linux kernel mailing list
In-Reply-To: <20071128143142.580732000@pademelon.sonytel.be>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8580 bytes --]
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
arch/powerpc/platforms/ps3/repository.c: sparse and checkpatch denoising
Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
---
arch/powerpc/platforms/ps3/repository.c | 64 ++++++++++++++++----------------
1 files changed, 32 insertions(+), 32 deletions(-)
--- a/arch/powerpc/platforms/ps3/repository.c
+++ b/arch/powerpc/platforms/ps3/repository.c
@@ -33,7 +33,7 @@ enum ps3_lpar_id {
};
#define dump_field(_a, _b) _dump_field(_a, _b, __func__, __LINE__)
-static void _dump_field(const char *hdr, u64 n, const char* func, int line)
+static void _dump_field(const char *hdr, u64 n, const char *func, int line)
{
#if defined(DEBUG)
char s[16];
@@ -50,8 +50,8 @@ static void _dump_field(const char *hdr,
#define dump_node_name(_a, _b, _c, _d, _e) \
_dump_node_name(_a, _b, _c, _d, _e, __func__, __LINE__)
-static void _dump_node_name (unsigned int lpar_id, u64 n1, u64 n2, u64 n3,
- u64 n4, const char* func, int line)
+static void _dump_node_name(unsigned int lpar_id, u64 n1, u64 n2, u64 n3,
+ u64 n4, const char *func, int line)
{
pr_debug("%s:%d: lpar: %u\n", func, line, lpar_id);
_dump_field("n1: ", n1, func, line);
@@ -63,7 +63,7 @@ static void _dump_node_name (unsigned in
#define dump_node(_a, _b, _c, _d, _e, _f, _g) \
_dump_node(_a, _b, _c, _d, _e, _f, _g, __func__, __LINE__)
static void _dump_node(unsigned int lpar_id, u64 n1, u64 n2, u64 n3, u64 n4,
- u64 v1, u64 v2, const char* func, int line)
+ u64 v1, u64 v2, const char *func, int line)
{
pr_debug("%s:%d: lpar: %u\n", func, line, lpar_id);
_dump_field("n1: ", n1, func, line);
@@ -165,7 +165,7 @@ int ps3_repository_read_bus_str(unsigned
make_first_field("bus", bus_index),
make_field(bus_str, 0),
0, 0,
- value, 0);
+ value, NULL);
}
int ps3_repository_read_bus_id(unsigned int bus_index, u64 *bus_id)
@@ -190,7 +190,7 @@ int ps3_repository_read_bus_type(unsigne
make_first_field("bus", bus_index),
make_field("type", 0),
0, 0,
- &v1, 0);
+ &v1, NULL);
*bus_type = v1;
return result;
}
@@ -205,7 +205,7 @@ int ps3_repository_read_bus_num_dev(unsi
make_first_field("bus", bus_index),
make_field("num_dev", 0),
0, 0,
- &v1, 0);
+ &v1, NULL);
*num_dev = v1;
return result;
}
@@ -218,7 +218,7 @@ int ps3_repository_read_dev_str(unsigned
make_field("dev", dev_index),
make_field(dev_str, 0),
0,
- value, 0);
+ value, NULL);
}
int ps3_repository_read_dev_id(unsigned int bus_index, unsigned int dev_index,
@@ -231,7 +231,7 @@ int ps3_repository_read_dev_id(unsigned
make_field("dev", dev_index),
make_field("id", 0),
0,
- dev_id, 0);
+ dev_id, NULL);
return result;
}
@@ -246,14 +246,14 @@ int ps3_repository_read_dev_type(unsigne
make_field("dev", dev_index),
make_field("type", 0),
0,
- &v1, 0);
+ &v1, NULL);
*dev_type = v1;
return result;
}
int ps3_repository_read_dev_intr(unsigned int bus_index,
unsigned int dev_index, unsigned int intr_index,
- enum ps3_interrupt_type *intr_type, unsigned int* interrupt_id)
+ enum ps3_interrupt_type *intr_type, unsigned int *interrupt_id)
{
int result;
u64 v1;
@@ -282,7 +282,7 @@ int ps3_repository_read_dev_reg_type(uns
make_field("dev", dev_index),
make_field("reg", reg_index),
make_field("type", 0),
- &v1, 0);
+ &v1, NULL);
*reg_type = v1;
return result;
}
@@ -588,7 +588,7 @@ int ps3_repository_read_stor_dev_port(un
make_first_field("bus", bus_index),
make_field("dev", dev_index),
make_field("port", 0),
- 0, port, 0);
+ 0, port, NULL);
}
int ps3_repository_read_stor_dev_blk_size(unsigned int bus_index,
@@ -598,7 +598,7 @@ int ps3_repository_read_stor_dev_blk_siz
make_first_field("bus", bus_index),
make_field("dev", dev_index),
make_field("blk_size", 0),
- 0, blk_size, 0);
+ 0, blk_size, NULL);
}
int ps3_repository_read_stor_dev_num_blocks(unsigned int bus_index,
@@ -608,7 +608,7 @@ int ps3_repository_read_stor_dev_num_blo
make_first_field("bus", bus_index),
make_field("dev", dev_index),
make_field("n_blocks", 0),
- 0, num_blocks, 0);
+ 0, num_blocks, NULL);
}
int ps3_repository_read_stor_dev_num_regions(unsigned int bus_index,
@@ -621,7 +621,7 @@ int ps3_repository_read_stor_dev_num_reg
make_first_field("bus", bus_index),
make_field("dev", dev_index),
make_field("n_regs", 0),
- 0, &v1, 0);
+ 0, &v1, NULL);
*num_regions = v1;
return result;
}
@@ -638,7 +638,7 @@ int ps3_repository_read_stor_dev_region_
make_field("dev", dev_index),
make_field("region", region_index),
make_field("id", 0),
- &v1, 0);
+ &v1, NULL);
*region_id = v1;
return result;
}
@@ -651,7 +651,7 @@ int ps3_repository_read_stor_dev_region_
make_field("dev", dev_index),
make_field("region", region_index),
make_field("size", 0),
- region_size, 0);
+ region_size, NULL);
}
int ps3_repository_read_stor_dev_region_start(unsigned int bus_index,
@@ -662,7 +662,7 @@ int ps3_repository_read_stor_dev_region_
make_field("dev", dev_index),
make_field("region", region_index),
make_field("start", 0),
- region_start, 0);
+ region_start, NULL);
}
int ps3_repository_read_stor_dev_info(unsigned int bus_index,
@@ -718,7 +718,7 @@ int ps3_repository_read_rm_size(unsigned
make_field("pu", 0),
ppe_id,
make_field("rm_size", 0),
- rm_size, 0);
+ rm_size, NULL);
}
int ps3_repository_read_region_total(u64 *region_total)
@@ -727,7 +727,7 @@ int ps3_repository_read_region_total(u64
make_first_field("bi", 0),
make_field("rgntotal", 0),
0, 0,
- region_total, 0);
+ region_total, NULL);
}
/**
@@ -763,7 +763,7 @@ int ps3_repository_read_num_spu_reserved
make_first_field("bi", 0),
make_field("spun", 0),
0, 0,
- &v1, 0);
+ &v1, NULL);
*num_spu_reserved = v1;
return result;
}
@@ -782,7 +782,7 @@ int ps3_repository_read_num_spu_resource
make_first_field("bi", 0),
make_field("spursvn", 0),
0, 0,
- &v1, 0);
+ &v1, NULL);
*num_resource_id = v1;
return result;
}
@@ -795,7 +795,7 @@ int ps3_repository_read_num_spu_resource
*/
int ps3_repository_read_spu_resource_id(unsigned int res_index,
- enum ps3_spu_resource_type* resource_type, unsigned int *resource_id)
+ enum ps3_spu_resource_type *resource_type, unsigned int *resource_id)
{
int result;
u64 v1;
@@ -812,14 +812,14 @@ int ps3_repository_read_spu_resource_id(
return result;
}
-int ps3_repository_read_boot_dat_address(u64 *address)
+static int ps3_repository_read_boot_dat_address(u64 *address)
{
return read_node(PS3_LPAR_ID_CURRENT,
make_first_field("bi", 0),
make_field("boot_dat", 0),
make_field("address", 0),
0,
- address, 0);
+ address, NULL);
}
int ps3_repository_read_boot_dat_size(unsigned int *size)
@@ -832,7 +832,7 @@ int ps3_repository_read_boot_dat_size(un
make_field("boot_dat", 0),
make_field("size", 0),
0,
- &v1, 0);
+ &v1, NULL);
*size = v1;
return result;
}
@@ -847,7 +847,7 @@ int ps3_repository_read_vuart_av_port(un
make_field("vir_uart", 0),
make_field("port", 0),
make_field("avset", 0),
- &v1, 0);
+ &v1, NULL);
*port = v1;
return result;
}
@@ -862,7 +862,7 @@ int ps3_repository_read_vuart_sysmgr_por
make_field("vir_uart", 0),
make_field("port", 0),
make_field("sysmgr", 0),
- &v1, 0);
+ &v1, NULL);
*port = v1;
return result;
}
@@ -893,7 +893,7 @@ int ps3_repository_read_num_be(unsigned
0,
0,
0,
- &v1, 0);
+ &v1, NULL);
*num_be = v1;
return result;
}
@@ -905,7 +905,7 @@ int ps3_repository_read_be_node_id(unsig
0,
0,
0,
- node_id, 0);
+ node_id, NULL);
}
int ps3_repository_read_tb_freq(u64 node_id, u64 *tb_freq)
@@ -915,7 +915,7 @@ int ps3_repository_read_tb_freq(u64 node
node_id,
make_field("clock", 0),
0,
- tb_freq, 0);
+ tb_freq, NULL);
}
int ps3_repository_read_be_tb_freq(unsigned int be_index, u64 *tb_freq)
--
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: Xilinx devicetrees
From: Jon Loeliger @ 2007-11-28 14:33 UTC (permalink / raw)
To: John Williams; +Cc: Stephen Neuendorffer, Michal Simek, linuxppc-embedded
In-Reply-To: <474CBBDE.9010007@itee.uq.edu.au>
John Williams wrote:
> Well, copying multiple configuration files into the kernel is not ideal.
Well, some advances in the DTC are being developed to help
mitigate the proliferation of DTS files there. It's still
slow going, but we're working on it...
> Surely a little perl or python script would do the trick? DTS syntax
> is pretty clean,
Are you looking at the same DTS I am? :-)
> Another thing I suggested to Michal recently, perhaps we need
> kernel/lib/libof to store common OF / DT handling code. Much better
> than duplicating it accross microblaze and PPC, and maybe other arch's
> would also see the light..
Not sure exactly what you mean here, but there are libfdt
efforts in the DTC source repo already. That code is being
used in U-Boot. There is also already a shared library of
OF/DT handling code in the kernel that is being used by
both PowerPC and SPARC today. I believe there are plans to
head it towards the same libfdt as well.
> That would also add a claim for the DTC to
> go in scripts/
Which, for the record, I'm not really convinced is the
right thing to do yet.
> John
Thanks,
jdl
^ permalink raw reply
* Init hangs on Xilinx4
From: schardt @ 2007-11-28 15:24 UTC (permalink / raw)
To: Linux PPC Linux PPC
Hi all,
i still have some problems booting linux from flash and don't know how
to debug.
i have a xilinx4-ppc with 64MB Ram and 4MB Flash, U-Boot works fine,
kernel is booting, but my little hello world program runs as init, died
after printing "He" (intead of "Hello World"). i tried initramfs with
build in cpio-image and jffs2 rootfs
Is there a log-buffer to look at ?
Should i try another compiler version ? (btw. booting from systemace
works with the version i use).
---------------------------
famous last words :
[ 50.476641] VFS: Mounted root (jffs2 filesystem).
[ 50.533581] Freeing unused kernel memory: 68k init
He
---------------------------
regards
Georg
-------------------------------------------------------------------
-------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe
Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Dr. Sebastian M. Schmidt
-------------------------------------------------------------------
-------------------------------------------------------------------
^ permalink raw reply
* [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Kumar Gala @ 2007-11-28 15:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Take from u-boot whitespace fixup of the file
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
libfdt/fdt.h | 32 ++++++++++++++++----------------
1 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/libfdt/fdt.h b/libfdt/fdt.h
index e00559a..48ccfd9 100644
--- a/libfdt/fdt.h
+++ b/libfdt/fdt.h
@@ -4,22 +4,22 @@
#ifndef __ASSEMBLY__
struct fdt_header {
- uint32_t magic; /* magic word FDT_MAGIC */
- uint32_t totalsize; /* total size of DT block */
- uint32_t off_dt_struct; /* offset to structure */
- uint32_t off_dt_strings; /* offset to strings */
- uint32_t off_mem_rsvmap; /* offset to memory reserve map */
- uint32_t version; /* format version */
- uint32_t last_comp_version; /* last compatible version */
-
- /* version 2 fields below */
- uint32_t boot_cpuid_phys; /* Which physical CPU id we're
+ uint32_t magic; /* magic word FDT_MAGIC */
+ uint32_t totalsize; /* total size of DT block */
+ uint32_t off_dt_struct; /* offset to structure */
+ uint32_t off_dt_strings; /* offset to strings */
+ uint32_t off_mem_rsvmap; /* offset to memory reserve map */
+ uint32_t version; /* format version */
+ uint32_t last_comp_version; /* last compatible version */
+
+ /* version 2 fields below */
+ uint32_t boot_cpuid_phys; /* Which physical CPU id we're
booting on */
/* version 3 fields below */
- uint32_t size_dt_strings; /* size of the strings block */
+ uint32_t size_dt_strings; /* size of the strings block */
/* version 17 fields below */
- uint32_t size_dt_struct; /* size of the structure block */
+ uint32_t size_dt_struct; /* size of the structure block */
};
struct fdt_reserve_entry {
@@ -41,12 +41,12 @@ struct fdt_property {
#endif /* !__ASSEMBLY */
-#define FDT_MAGIC 0xd00dfeed /* 4: version, 4: total size */
+#define FDT_MAGIC 0xd00dfeed /* 4: version, 4: total size */
#define FDT_TAGSIZE sizeof(uint32_t)
-#define FDT_BEGIN_NODE 0x1 /* Start node: full name */
-#define FDT_END_NODE 0x2 /* End node */
-#define FDT_PROP 0x3 /* Property: name off,
+#define FDT_BEGIN_NODE 0x1 /* Start node: full name */
+#define FDT_END_NODE 0x2 /* End node */
+#define FDT_PROP 0x3 /* Property: name off,
size, content */
#define FDT_NOP 0x4 /* nop */
#define FDT_END 0x9
--
1.5.3.4
^ permalink raw reply related
* Re: SPI driver for spi_mpc83xx
From: fabio777 @ 2007-11-28 15:41 UTC (permalink / raw)
To: Ben Warren; +Cc: linuxppc-embedded
In-Reply-To: <474C70EF.4040800@qstreams.com>
Thanks Ben
works.
Ben Warren wrote:
> Fabio,
>
> Note: I've changed the e-mail subject back to the original. In the
> future, please ensure that it remains intact.
>
> fabio777 wrote:
>> Thanks Ben,
>>
>> Here it is
>>
>> static struct fsl_spi_platform_data k_platform_data = {
>> .initial_spmode = 0,
>> .bus_num = 1,
> Probably should be bus_num = 0
>> .max_chipselect = 1,
>> /* board specific information */
>> .activate_cs = k_cs_activate,
>> .deactivate_cs = k_cs_deactivate,
>> .sysclk = 266,
>> };
>>
>> static struct spi_board_info spi_board_info[] __initdata = { {
>> .modalias = "kplus",
>> .platform_data = &k_platform_data,
>> .max_speed_hz = 120000,
>> .bus_num = 1,
> Again, bus_num probably should be 0
>> .chip_select = 0,
>> },
>> };
>>
>>
>> struct platform_device k_plus = {
>> .name = "kplus",
> name should be "mpc83xx_spi". At initialization, the SPI controller
> driver searches the registered platform devices (models of board
> hardware) for a match. Without a match, it gives up.
>
>> .id = 1,
>> .dev = {
>> .platform_data = &k_platform_data,
>> },
>> };
>>
>> platform_device_register(&k_plus);
>>
> Do you add the SPI controller's resources (base address and IRQ?)
> You'll need to in order for this to work. On my board, I use
> 'platform_device_register_simple()', passing the name and the two
> resources, then call 'platform_add_data()', passing in the platform
> data structure.
>> spi_register_board_info(spi_board_info, ARRAY_SIZE(spi_board_info))
>>
> Good
>> and then calls spi_register_driver(&k_driver);
> I don't think this last call is needed.
>>
>> I can't get the into the *probe functions.
>> Thanks
>>
> regards,
> Ben
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Anton Vorontsov @ 2007-11-28 15:49 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, linux-ide
In-Reply-To: <200711272233.00456.arnd@arndb.de>
On Tue, Nov 27, 2007 at 10:32:58PM +0100, Arnd Bergmann wrote:
> On Tuesday 27 November 2007, Olof Johansson wrote:
> > On Tue, Nov 27, 2007 at 06:39:08PM +0300, Anton Vorontsov wrote:
> > > This driver nicely wraps around pata_platform library functions,
> > > and provides OF platform bus bindings to the PATA devices.
> >
> > > +static struct of_device_id pata_of_platform_match[] = {
> > > + { .compatible = "pata-platform", },
> > > +};
> >
> > "pata-platform" really means nothing outside of linux. A more
> > generic label would be useful.
Agreed.
> Maybe the name of the standards it supports? Could be
> "ata-4", "ata-5" and the like, or the exact transfer mode, like
> "pata-udma-5", "pata-pio-3", "sata-150", etc.
You're quite optimistic about pata_platform capabilities. ;-)
As far as I know it is [obviously] supports PIO modes only. And so
far I was able to get max 5.28 MB/s read transfers. Which looks like
ideal case for PIO1 (CF I'm testing on is 3.0, max. PIO4).
I've modified pio_mask appropriately, plus I've tried to comment
out .set_mode = pata_platform_set_mode, and now it says:
ata5: PATA max PIO4 mmio cmd 0xf0000000 ctl 0xf000020c irq 24
ata5.00: CFA: TOSHIBA THNCF512MQG, 3.00, max PIO4
ata5.00: configured for PIO4
ata5.00: configured for PIO4
That looks good, but speed is the same. Oh well, it's another
matter.
Back to dts, I think pata-pio-X is good scheme. That way we can
pass pio_mask via device tree. Sounds reasonable?
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Jon Loeliger @ 2007-11-28 15:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0711280938440.3013@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> Take from u-boot whitespace fixup of the file
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-28 16:11 UTC (permalink / raw)
To: avorontsov; +Cc: Olof Johansson, linuxppc-dev, Arnd Bergmann, linux-ide
In-Reply-To: <20071128154904.GA20722@localhost.localdomain>
Anton Vorontsov wrote:
>>>>This driver nicely wraps around pata_platform library functions,
>>>>and provides OF platform bus bindings to the PATA devices.
>>>>+static struct of_device_id pata_of_platform_match[] = {
>>>>+ { .compatible = "pata-platform", },
>>>>+};
>>>"pata-platform" really means nothing outside of linux. A more
>>>generic label would be useful.
> Agreed.
Now you're quick to agree. :-)
>>Maybe the name of the standards it supports? Could be
>>"ata-4", "ata-5" and the like, or the exact transfer mode, like
>>"pata-udma-5", "pata-pio-3", "sata-150", etc.
> You're quite optimistic about pata_platform capabilities. ;-)
Indeed. :-)
> As far as I know it is [obviously] supports PIO modes only. And so
> far I was able to get max 5.28 MB/s read transfers. Which looks like
> ideal case for PIO1 (CF I'm testing on is 3.0, max. PIO4).
Believe me, it's a great speed even for PIO4. Most systems only show 3+
MiB/s in this mode according to hdparm.
> I've modified pio_mask appropriately, plus I've tried to comment
> out .set_mode = pata_platform_set_mode, and now it says:
> ata5: PATA max PIO4 mmio cmd 0xf0000000 ctl 0xf000020c irq 24
> ata5.00: CFA: TOSHIBA THNCF512MQG, 3.00, max PIO4
> ata5.00: configured for PIO4
> ata5.00: configured for PIO4
> That looks good, but speed is the same. Oh well, it's another
> matter.
> Back to dts, I think pata-pio-X is good scheme. That way we can
> pass pio_mask via device tree. Sounds reasonable?
Grumble. Can't we pass this via some property other than "compatible"? I'm
opposed to "ata-5" and the like in there as well cause it's not clear what
information this would provide. Why people so love to make things complex WRT
the "compatible" property -- instead of making the task of selecting a proper
driver more simple, they tend to make it mode complex by trying to specify
values that have quite little to do with the device's programming interface
itself...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Mel Gorman @ 2007-11-28 16:12 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <200711280826.46820.arnd@arndb.de>
On (28/11/07 08:26), Arnd Bergmann didst pronounce:
> On Wednesday 28 November 2007, Jon Tollefson wrote:
> > This patch adds the hugepagesz boot-time parameter for ppc64 that lets
> > you pick the size for your huge pages. The choices available are 64K
> > and 16M. It defaults to 16M (previously the only choice) if nothing or
> > an invalid choice is specified. Tested 64K huge pages with the
> > libhugetlbfs 1.2 release with its 'make func' and 'make stress' test
> > invocations.
>
> How hard would it be to add the 1MB page size that some CPUs support
> as well? On systems with small physical memory like the PS3, that
> sounds very useful to me.
>
Does the PS3 support 1M pages in hardware? When I last looked, the magic
ibm,segment-page-sizes file that described the supported pagesizes was
missing from the device tree. In this situation, the default sizes
become 4K and 16M because no other ones are advertised.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* [PATCH][DTC] Add an option to pad the blob that is generated
From: Kumar Gala @ 2007-11-28 16:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
There are times when we need extra space in the blob and just want
to have it added on w/o know the exact size to make it.
The padding and min size options are mutually exclusive.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
dtc.c | 14 +++++++++++++-
dtc.h | 1 +
flattree.c | 20 +++++++++++++-------
3 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/dtc.c b/dtc.c
index 602b296..cf9a6a9 100644
--- a/dtc.c
+++ b/dtc.c
@@ -29,6 +29,7 @@
int quiet; /* Level of quietness */
int reservenum; /* Number of memory reservation slots */
int minsize; /* Minimum blob size */
+int padsize; /* Additional padding to blob */
char *join_path(char *path, char *name)
{
@@ -97,6 +98,8 @@ static void __attribute__ ((noreturn)) usage(void)
fprintf(stderr, "\t\tMake space for <number> reserve map entries (relevant for \n\t\tdtb and asm output only)\n");
fprintf(stderr, "\t-S <bytes>\n");
fprintf(stderr, "\t\tMake the blob at least <bytes> long (extra space)\n");
+ fprintf(stderr, "\t-p <bytes>\n");
+ fprintf(stderr, "\t\tAdd padding to the blob of <bytes> long (extra space)\n");
fprintf(stderr, "\t-b <number>\n");
fprintf(stderr, "\t\tSet the physical boot cpu\n");
fprintf(stderr, "\t-f\n");
@@ -124,8 +127,9 @@ int main(int argc, char *argv[])
quiet = 0;
reservenum = 0;
minsize = 0;
+ padsize = 0;
- while ((opt = getopt(argc, argv, "hI:O:o:V:R:S:fcqb:v")) != EOF) {
+ while ((opt = getopt(argc, argv, "hI:O:o:V:R:S:p:fcqb:v")) != EOF) {
switch (opt) {
case 'I':
inform = optarg;
@@ -145,6 +149,9 @@ int main(int argc, char *argv[])
case 'S':
minsize = strtol(optarg, NULL, 0);
break;
+ case 'p':
+ padsize = strtol(optarg, NULL, 0);
+ break;
case 'f':
force = 1;
break;
@@ -173,6 +180,11 @@ int main(int argc, char *argv[])
else
arg = argv[optind];
+ /* minsize and padsize are mutually exclusive */
+ if ((minsize) && (padsize)) {
+ die("Can't set both -p and -S\n");
+ }
+
fprintf(stderr, "DTC: %s->%s on file \"%s\"\n",
inform, outform, arg);
diff --git a/dtc.h b/dtc.h
index d080153..0100ad1 100644
--- a/dtc.h
+++ b/dtc.h
@@ -43,6 +43,7 @@
extern int quiet; /* Level of quietness */
extern int reservenum; /* Number of memory reservation slots */
extern int minsize; /* Minimum blob size */
+extern int padsize; /* Additional padding to blob */
static inline void __attribute__((noreturn)) die(char * str, ...)
{
diff --git a/flattree.c b/flattree.c
index 5889900..3c13566 100644
--- a/flattree.c
+++ b/flattree.c
@@ -366,7 +366,7 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
struct data dtbuf = empty_data;
struct data strbuf = empty_data;
struct fdt_header fdt;
- int padlen;
+ int padlen = 0;
for (i = 0; i < ARRAY_SIZE(version_table); i++) {
if (version_table[i].version == version)
@@ -387,16 +387,17 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
/*
* If the user asked for more space than is used, adjust the totalsize.
*/
- padlen = minsize - be32_to_cpu(fdt.totalsize);
- if (padlen > 0) {
- fdt.totalsize = cpu_to_be32(minsize);
- } else {
- if ((minsize > 0) && (quiet < 1))
+ if (minsize > 0) {
+ padlen = minsize - be32_to_cpu(fdt.totalsize);
+ if ((padlen < 0) && (quiet < 1))
fprintf(stderr,
"Warning: blob size %d >= minimum size %d\n",
be32_to_cpu(fdt.totalsize), minsize);
}
+ if (padsize > 0)
+ padlen = padsize;
+
/*
* Assemble the blob: start with the header, add with alignment
* the reserve buffer, add the reserve map terminating zeroes,
@@ -413,8 +414,10 @@ void dt_to_blob(FILE *f, struct boot_info *bi, int version,
* If the user asked for more space than is used, pad out the blob.
*/
if (padlen > 0) {
+ int tsize = be32_to_cpu(fdt.totalsize);
+ tsize += padlen;
blob = data_append_zeroes(blob, padlen);
- fdt.totalsize = cpu_to_be32(minsize);
+ fdt.totalsize = cpu_to_be32(tsize);
}
fwrite(blob.val, blob.len, 1, f);
@@ -544,6 +547,9 @@ void dt_to_asm(FILE *f, struct boot_info *bi, int version, int boot_cpuid_phys)
fprintf(f, "\t.space\t%d - (_%s_blob_end - _%s_blob_start), 0\n",
minsize, symprefix, symprefix);
}
+ if (padsize > 0) {
+ fprintf(f, "\t.space\t%d, 0\n", padsize);
+ }
emit_label(f, symprefix, "blob_abs_end");
data_free(strbuf);
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 2/3] [libata] pata_of_platform: OF-Platform PATA device driver
From: Sergei Shtylyov @ 2007-11-28 16:29 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, linuxppc-dev, linux-ide
In-Reply-To: <200711272233.00456.arnd@arndb.de>
Hello.
Arnd Bergmann wrote:
>>>This driver nicely wraps around pata_platform library functions,
>>>and provides OF platform bus bindings to the PATA devices.
>>>+static struct of_device_id pata_of_platform_match[] = {
>>>+ { .compatible = "pata-platform", },
>>>+};
>>"pata-platform" really means nothing outside of linux. A more
>>generic label would be useful.
> Maybe the name of the standards it supports? Could be
> "ata-4", "ata-5" and the like,
It's not clear what info this would provide.
> or the exact transfer mode, like
> "pata-udma-5", "pata-pio-3", "sata-150", etc.
I think this info should follow from the compatible property value
implicitly, or maybe this info should be conveyed in some optional properties.
It doesn't make sense to the generic platform driver anyway since it has no
notion about the mode programming specifics. I think that as the device being
driven is assumed to be a generic IDE device, the "compatible" property should
contain "generic" or something alike (as well as usual board's and chip's names).
> Arnd <><
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: add hugepagesz boot-time parameter
From: Arnd Bergmann @ 2007-11-28 16:30 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, kniht, Linux Memory Management List
In-Reply-To: <20071128161201.GA10916@csn.ul.ie>
On Wednesday 28 November 2007, Mel Gorman wrote:
> On (28/11/07 08:26), Arnd Bergmann didst pronounce:
> > On Wednesday 28 November 2007, Jon Tollefson wrote:
> > > This patch adds the hugepagesz boot-time parameter for ppc64 that let=
s=20
> > > you pick the size for your huge pages. =A0The choices available are 6=
4K=20
> > > and 16M. =A0It defaults to 16M (previously the only choice) if nothin=
g or=20
> > > an invalid choice is specified. =A0Tested 64K huge pages with the=20
> > > libhugetlbfs 1.2 release with its 'make func' and 'make stress' test=
=20
> > > invocations.
> >=20
> > How hard would it be to add the 1MB page size that some CPUs support
> > as well? On systems with small physical memory like the PS3, that
> > sounds very useful to me.
> >=20
>=20
> Does the PS3 support 1M pages in hardware? When I last looked, the magic
> ibm,segment-page-sizes file that described the supported pagesizes was
> missing from the device tree. In this situation, the default sizes
> become 4K and 16M because no other ones are advertised.
I think you can select the page size using a hypercall on the PS3.
The CPU supports any two of (64k, 1M, 16M) simultaneously.
Arnd <><
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Scott Wood @ 2007-11-28 16:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <Pine.LNX.4.64.0711280938440.3013@blarg.am.freescale.net>
On Wed, Nov 28, 2007 at 09:39:08AM -0600, Kumar Gala wrote:
> Take from u-boot whitespace fixup of the file
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> libfdt/fdt.h | 32 ++++++++++++++++----------------
> 1 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/libfdt/fdt.h b/libfdt/fdt.h
> index e00559a..48ccfd9 100644
> --- a/libfdt/fdt.h
> +++ b/libfdt/fdt.h
> @@ -4,22 +4,22 @@
> #ifndef __ASSEMBLY__
>
> struct fdt_header {
> - uint32_t magic; /* magic word FDT_MAGIC */
> - uint32_t totalsize; /* total size of DT block */
> - uint32_t off_dt_struct; /* offset to structure */
> - uint32_t off_dt_strings; /* offset to strings */
> - uint32_t off_mem_rsvmap; /* offset to memory reserve map */
> - uint32_t version; /* format version */
> - uint32_t last_comp_version; /* last compatible version */
> -
> - /* version 2 fields below */
> - uint32_t boot_cpuid_phys; /* Which physical CPU id we're
> + uint32_t magic; /* magic word FDT_MAGIC */
> + uint32_t totalsize; /* total size of DT block */
> + uint32_t off_dt_struct; /* offset to structure */
> + uint32_t off_dt_strings; /* offset to strings */
> + uint32_t off_mem_rsvmap; /* offset to memory reserve map */
> + uint32_t version; /* format version */
> + uint32_t last_comp_version; /* last compatible version */
I don't think this is an improvement... tabs are great for indentation, but
they suck for alignment.
-Scott
^ permalink raw reply
* Re: The question about the high memory support on MPC8360?
From: Scott Wood @ 2007-11-28 16:57 UTC (permalink / raw)
To: vijay baskar; +Cc: 郭劲, linuxppc-embedded
In-Reply-To: <474CE85A.1020902@gdatech.co.in>
vijay baskar wrote:
> Hi, "The kernel also allows hardcoded mapping of IO regions into its
> virtual address space through the io_block_mapping interface."
>
> Can u tell me how this is in current arch/powerpc.
Everything is explicitly ioremapped.
> Also does it mean that whatever be the size of the ram > 768 MB there
> is not going to be much improvement in performance in kernel space
> irrespective of invoking CONFIG_HIGHMEM or not?
Well, the kernel can use highmem for cache... I'm not sure what you
mean by "in kernel space".
> Also do you think this low mem be enough if i have lots of kernel
> space processes each invoking lots of kmallocs.
That depends on what you mean by "lots". :-)
You'll have 768MB of lowmem, and kmallocs can only use lowmem.
> Will there be bottle necks?? Also what alternative do we have if low
> mem of 768 MB is not enough??
You'll need to change the user/kernel split, and deal with anything that
breaks in the process.
Or get a 64-bit chip. :-)
-Scott
^ permalink raw reply
* Re: [PATCH][DTC] Fix whitespace in libfdt/fdt.h
From: Jon Loeliger @ 2007-11-28 17:09 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20071128165335.GA4597@loki.buserror.net>
So, like, the other day Scott Wood mumbled:
> On Wed, Nov 28, 2007 at 09:39:08AM -0600, Kumar Gala wrote:
> > Take from u-boot whitespace fixup of the file
> >
> > Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
[snip]
> I don't think this is an improvement... tabs are great for indentation, but
> they suck for alignment.
>
> -Scott
The issue was consistency with U-Boot for update reasons.
I'm fine with it....
jdl
^ permalink raw reply
* RE: Xilinx devicetrees
From: Stephen Neuendorffer @ 2007-11-28 17:28 UTC (permalink / raw)
To: John Williams; +Cc: Michal Simek, linuxppc-embedded
In-Reply-To: <474CBBDE.9010007@itee.uq.edu.au>
=20
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
> =20
> [mailto:linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@oz
labs.org] On Behalf Of John Williams
> Sent: Tuesday, November 27, 2007 4:53 PM
> To: Stephen Neuendorffer
> Cc: Michal Simek; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>=20
> Stephen Neuendorffer wrote:
>=20
> >>From: John Williams [mailto:jwilliams@itee.uq.edu.au]=20
>=20
> >>MicroBlaze is a highly configurable CPU in terms of its=20
> >>instruction set,=20
> >>features and so on. To make use of this, it is essential that each=20
> >>kernel image be compiled to match the CPU configuration. While a=20
> >>generic kernel, making use of no features (MUL, DIV, Shift,=20
> >>MSR ops etc)=20
> >>would run on any CPU, performance would be abysmal.
> >=20
> > I think the userspace is actually much more critical than=20
> the kernel for
> > most of these things (with the exception of msrset/msrclr, and the
> > barrel shifter perhaps). Unfortunately, even if you implement an
> > alternatives-style mechanism for the kernel, you're still hosed for
> > userspace. =20
>=20
> I haven't benchmarks each option on the kernel - you are right that=20
> shift is a big one, but mul I think is also important, given=20
> that every=20
> array access generates an integer multiply,
Good point.
>=20
> Once I a big enough system, it's just unfeasible to
> > recompile everything anyway. I think this is where=20
> autoconfig starts to
> > break down.
>=20
> I'm not sure I agree, here, given that most people building=20
> MicroBlaze=20
> systems are doing so with uClinux-dist (or PetaLinux), you=20
> can do a full=20
> rebuilt, kernel libs apps, in a couple of minutes. Much shorter than=20
> sythnesis and P&R, that's for sure (and runtime is linear in size,=20
> unlike P&R :)
Let's not bash the P&R guys too much... You try working on a problem
that is known to be insolvable, and where no matter how many people you
make happier, you'll always get bashed by the guy whose design no longer
meets timing. :)
> > It's not nice, I agree. I think the key principle should be that I
> > should be able to get a system working as quickly as possible, and I
> > might optimize things later. One thing that device trees=20
> will allow is
> > for *all* the drivers to get compiled in to the kernel, and=20
> only as a
> > late stage operation does a designer need to start throwing=20
> things away.
> > Using traps I can easily start with a 'kitchen sink'=20
> design, and start
> > discarding processor features, relying on the traps. When I get low
> > enough down on the performance curve, I can uas an autoconfig-type
> > mechanism to regain a little of what I lost by optimizing=20
> away the trap
> > overhead.=20
>=20
> OK, but now we have a kernel dependent on *3* files - a DTS, a=20
> Kconfig.auto, and (indirectly) the bitstream itself.
The kernel might be generated from them, but it is not *dependent* on
them. The same kernel can run on other hardware, with other dts's. If
there was a traps mechanism (or alternatives), then it could also run on
other designs with different processor features.
> Another thing I suggested to Michal recently, perhaps we need=20
> kernel/lib/libof to store common OF / DT handling code. Much better=20
> than duplicating it accross microblaze and PPC, and maybe=20
> other arch's=20
> would also see the light.. That would also add a claim for=20
> the DTC to=20
> go in scripts/
There's some shared code in 2.6.24-rc in drivers/of. Now that things
are settling down in terms of bugs, I'll probably transition to pushing
a 2.6.24-rc branch soon. However, the few brief conversations I've had
suggest that what microblaze might need or want has very little
influence until it is visible in mainline. Once that happens, I think
it will be easy to justify putting code like libfdt and some of the
kernel of/dt code in a common place. =20
So, John: would you care to make a goal (for say 2.6.25 or 26) of
working with me to get the microblaze into mainline? I think the
community exists to keep things maintained, but I'm guessing that it
would help to have an existing LKMLer or two take a look over the code.
Given the move towards device trees, getting someone from powerpc would
seem to be natural. Anybody interested?
Steve
^ permalink raw reply
* Re: [PATCH] Fix buglets in mpc5200 FEC code that are corrupting memory.
From: David Woodhouse @ 2007-11-28 18:04 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list, Jeff Garzik, Domen Puncer, netdev
In-Reply-To: <9e4733910711181749p1d2744b1md8ea92fdca60d6d6@mail.gmail.com>
On Sun, 2007-11-18 at 20:49 -0500, Jon Smirl wrote:
> On 11/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On 11/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > > On 09/11/07 00:31 -0500, Jon Smirl wrote:
> > > > This is the reason I couldn't get user space started or connect to my
> > > > nfs server. Patch is against current linus git.
> > > >
> > > > mpc5200 fec driver is corrupting memory. This patch fixes two bugs
> > > > where the wrong skb buffer was being referenced.
> > > >
> > > > Signed-off-by: Jon Smirl <jonsmirl@gmail.com>
> > >
> > > Acked-by: Domen Puncer <domen.puncer@telargo.com>
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > Jeff, can you please pick this up for .24?
>
> This is didn't make it into rc3. Without this patch this driver is broken.
Jeff?
--
dwmw2
^ permalink raw reply
* [PATCH] SET_NETDEV_DEV() in fec_mpc52xx.c
From: David Woodhouse @ 2007-11-28 18:04 UTC (permalink / raw)
To: jgarzik; +Cc: linuxppc-dev, Domen Puncer, netdev
This helps to allow the Fedora installer to use the built-in Ethernet on
the Efika for a network install.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -971,6 +971,8 @@ mpc52xx_fec_probe(struct of_device *op, const struct of_device_id *match)
mpc52xx_fec_reset_stats(ndev);
+ SET_NETDEV_DEV(ndev, &op->dev);
+
/* Register the new network device */
rv = register_netdev(ndev);
if (rv < 0)
--
dwmw2
^ permalink raw reply
* Re: Xilinx devicetrees
From: Grant Likely @ 2007-11-28 18:12 UTC (permalink / raw)
To: Stephen Neuendorffer; +Cc: linuxppc-embedded, Michal Simek
In-Reply-To: <20071128172713.AA7D835004D@mail53-sin.bigfish.com>
On 11/28/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> So, John: would you care to make a goal (for say 2.6.25 or 26) of
> working with me to get the microblaze into mainline? I think the
> community exists to keep things maintained, but I'm guessing that it
> would help to have an existing LKMLer or two take a look over the code.
> Given the move towards device trees, getting someone from powerpc would
> seem to be natural. Anybody interested?
I'll provide as much support as I can, given that I'm not very
familiar with microblaze.
Cheers,
g
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* DS1337 RTC on I2C broken.
From: Clemens Koller @ 2007-11-28 18:25 UTC (permalink / raw)
To: linuxppc-embedded, rtc-linux, a.zummo
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
^ permalink raw reply
* Re: DS1337 RTC on I2C broken.
From: Alessandro Zummo @ 2007-11-28 18:43 UTC (permalink / raw)
To: Clemens Koller; +Cc: rtc-linux, linuxppc-embedded
In-Reply-To: <474DB27C.7020909@anagramm.de>
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
^ permalink raw reply
* Re: 2.6.24-rc3-mm2 - Build Failure on powerpc timerfd() undeclared
From: Andrew Morton @ 2007-11-28 18:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michael Kerrisk, linux-kernel, Kamalesh Babulal, linuxppc-dev,
Paul Mackerras, Davide Libenzi, Balbir Singh
In-Reply-To: <200711281432.09178.arnd@arndb.de>
On Wed, 28 Nov 2007 14:32:07 +0100 Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 28 November 2007, Kamalesh Babulal wrote:
> > Kernel build fails, with build error
> >
> > CC arch/powerpc/platforms/cell/spu_callbacks.o
> > In file included from arch/powerpc/platforms/cell/spu_callbacks.c:49:
> > include/asm/systbl.h:312: error: ‘sys_timerfd’ undeclared here (not in a function)
> > make[2]: *** [arch/powerpc/platforms/cell/spu_callbacks.o] Error 1
> > make[1]: *** [arch/powerpc/platforms/cell] Error 2
> > make: *** [arch/powerpc/platforms] Error 2
> >
>
> I guess all architectures except x86 are currently broken because they
> reference the old sys_timerfd function.
None of them were broken in my testing and I'm unsure why powerpc broke
here.
> This patch should add the missing
> bits to powerpc.
>
Because the patches in -mm left the stubs in place in sys_ni.c and powerpc
_should_ have (incorrectly) picked those up.
Odd.
>
> ---
>
> Disclaimer: Not tested at all, just applied common sense.
> Disclaimer2: conflicts with the sys_indirect kernel implementation
> sent by paulus last week.
>
> diff --git a/include/asm-powerpc/systbl.h b/include/asm-powerpc/systbl.h
> index 11d5383..b029368 100644
> --- a/include/asm-powerpc/systbl.h
> +++ b/include/asm-powerpc/systbl.h
> @@ -309,7 +309,9 @@ SYSCALL_SPU(getcpu)
> COMPAT_SYS(epoll_pwait)
> COMPAT_SYS_SPU(utimensat)
> COMPAT_SYS_SPU(signalfd)
> -COMPAT_SYS_SPU(timerfd)
> +COMPAT_SYS_SPU(timerfd_create)
> SYSCALL_SPU(eventfd)
> COMPAT_SYS_SPU(sync_file_range2)
> COMPAT_SYS(fallocate)
> +COMPAT_SYS_SPU(sys_timerfd_settime)
> +COMPAT_SYS_SPU(sys_timerfd_gettime)
> diff --git a/include/asm-powerpc/unistd.h b/include/asm-powerpc/unistd.h
> index 97d82b6..4ba2d20 100644
> --- a/include/asm-powerpc/unistd.h
> +++ b/include/asm-powerpc/unistd.h
> @@ -328,14 +328,16 @@
> #define __NR_epoll_pwait 303
> #define __NR_utimensat 304
> #define __NR_signalfd 305
> -#define __NR_timerfd 306
> +#define __NR_timerfd_create 306
> #define __NR_eventfd 307
> #define __NR_sync_file_range2 308
> #define __NR_fallocate 309
> +#define __NR_sys_timerfd_settime 310
> +#define __NR_sys_timerfd_gettime 311
>
> #ifdef __KERNEL__
>
> -#define __NR_syscalls 310
> +#define __NR_syscalls 312
>
> #define __NR__exit __NR_exit
> #define NR_syscalls __NR_syscalls
^ permalink raw reply
* RE: [PATCH] e1000: Fix for 32 bits platforms with 64 bits resources
From: Brandeburg, Jesse @ 2007-11-28 18:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kok, Auke-jan H; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20071116073821.548CCDDDF4@ozlabs.org>
Benjamin Herrenschmidt wrote:
> The e1000 driver stores the content of the PCI resources into
> unsigned long's before ioremapping. This breaks on 32 bits
> platforms that support 64 bits MMIO resources such as ppc 44x.
>=20
> This fixes it by removing those temporary variables and passing
> directly the result of pci_resource_start/len to ioremap.
the patch is mostly fine, but looking through the tree, doesn't every
driver that has 64 bit capable resources have this problem?
in fact, skeleton module has this problem, if I'm not mistaken. e1000
isn't the only one. :-)
=20
> The side effect is that I removed the assignments to the netdev
> fields mem_start, mem_end and base_addr, which are totally useless
> for PCI devices.
also, concerning this, ifconfig shows the output of these variables, I
don't think we want to blatantly remove them, as it is actually removing
information that is, if not used, at least displayed to user space.
eth6 Link encap:Ethernet HWaddr 00:0E:01:0C:02:03
inet addr:134.134.3.121 Bcast:134.134.3.255
Mask:255.255.255.0
inet6 addr: fe80::20e:1ff:fe0c:203/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9022519 errors:0 dropped:0 overruns:0 frame:0
TX packets:1303701 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4044613454 (3857.2 Mb) TX bytes:118365109 (112.8 Mb)
Base address:0xf000 Memory:feac0000-feae0000
^^^^^^^^^^^^^^^^^
^ 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