* Re: Build failure on treeboot-walnut.c
From: Timur Tabi @ 2007-10-09 14:44 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <E83F8EDA-95EF-4116-A214-D008BA70135D@kernel.crashing.org>
Kumar Gala wrote:
> What's the actual compile line? Want to see the flags to assembler of
> -Wa to the compiler.
How do I modify the makefiles to spit out that command line?
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Build failure on treeboot-walnut.c
From: Geert Uytterhoeven @ 2007-10-09 14:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <470B93CC.6090400@freescale.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 840 bytes --]
On Tue, 9 Oct 2007, Timur Tabi wrote:
> Kumar Gala wrote:
>
> > What's the actual compile line? Want to see the flags to assembler of
> > -Wa to the compiler.
>
> How do I modify the makefiles to spit out that command line?
make V=1
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: Build failure on treeboot-walnut.c
From: Kumar Gala @ 2007-10-09 14:51 UTC (permalink / raw)
To: Timur Tabi; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <470B93CC.6090400@freescale.com>
On Oct 9, 2007, at 9:44 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> What's the actual compile line? Want to see the flags to
>> assembler of -Wa to the compiler.
>
> How do I modify the makefiles to spit out that command line?
try
$ make V=1
- k
^ permalink raw reply
* Re: Build failure on treeboot-walnut.c
From: Timur Tabi @ 2007-10-09 14:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: PowerPC dev list, Paul Mackerras
In-Reply-To: <E5596C2A-8304-4158-B580-CFF9F86F814E@kernel.crashing.org>
Kumar Gala wrote:
> $ make V=1
make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
arch/powerpc/boot/uImage powerpc-unknown-linux-gnu-gcc -m32
-Wp,-MD,arch/powerpc/boot/.treeboot-walnut.o.d -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -Os -msoft-float -pipe
-fomit-frame-pointer -fno-builtin -fPIC -nostdinc -isystem
/_TOOLS_/.dist0/gnu-gcc-4.0.2-binutils-2.16.1-glibc-2.3.6-e300c2-powerpc-unknown-linux-gnu/i686-pc-linux2.4/bin/../lib/gcc/powerpc-unknown-linux-gnu/4.0.2/include
-Iarch/powerpc/boot -I/temp/kumar.484/arch/powerpc/boot -mcpu=405 -c -o
arch/powerpc/boot/treeboot-walnut.o arch/powerpc/boot/treeboot-walnut.c
Assembler messages:
Error: Internal assembler error for instruction icbt
Internal error, aborting at
/tmp/crosstool/crosstool-0.42/build/powerpc-unknown-linux-gnu/gcc-4.0.2_e300-enabled-glibc-2.3.6/binutils-2.16.1-complete/gas/config/tc-ppc.c
line 1314 in ppc_setup_opcodes
Please report this bug.
make[1]: *** [arch/powerpc/boot/treeboot-walnut.o] Error 2
make: *** [uImage] Error 2
ARCH=ppc64? WTF? I specifically said ARCH=powerpc on the make command line.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 15:53 UTC (permalink / raw)
To: linuxppc-dev, galak; +Cc: Timur Tabi
Add function qe_clock_source() which takes a string containing the name of a
QE clock source (as is typically found in device trees) and returns the
matching enum qe_clock value.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
This patch applies to Kumar's for-2.6.24 branch.
arch/powerpc/sysdev/qe_lib/qe.c | 65 +++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/qe.h | 3 ++
2 files changed, 68 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index 3d57d38..da68534 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -199,6 +199,71 @@ void qe_setbrg(unsigned int brg, unsigned int rate, unsigned int multiplier)
out_be32(&qe_immr->brg.brgc[brg - 1], tempval);
}
+/* Convert a string to a QE clock source enum
+ *
+ * This function takes a string, typically from a property in the device
+ * tree, and returns the corresponding "enum qe_clock" value.
+*/
+enum qe_clock qe_clock_source(const char *source)
+{
+ /* This structure is designed so that it's 8 bytes in size */
+ static struct {
+ const char name[6];
+ u16 num;
+ } __attribute__((packed)) sources[QE_CLK_DUMMY] =
+ {
+ {"none", QE_CLK_NONE},
+ {"brg1", QE_BRG1},
+ {"brg2", QE_BRG2},
+ {"brg3", QE_BRG3},
+ {"brg4", QE_BRG4},
+ {"brg5", QE_BRG5},
+ {"brg6", QE_BRG6},
+ {"brg7", QE_BRG7},
+ {"brg8", QE_BRG8},
+ {"brg9", QE_BRG9},
+ {"brg10", QE_BRG10},
+ {"brg11", QE_BRG11},
+ {"brg12", QE_BRG12},
+ {"brg13", QE_BRG13},
+ {"brg14", QE_BRG14},
+ {"brg15", QE_BRG15},
+ {"brg16", QE_BRG16},
+ {"clk1", QE_CLK1},
+ {"clk2", QE_CLK2},
+ {"clk3", QE_CLK3},
+ {"clk4", QE_CLK4},
+ {"clk5", QE_CLK5},
+ {"clk6", QE_CLK6},
+ {"clk7", QE_CLK7},
+ {"clk8", QE_CLK8},
+ {"clk9", QE_CLK9},
+ {"clk10", QE_CLK10},
+ {"clk11", QE_CLK11},
+ {"clk12", QE_CLK12},
+ {"clk13", QE_CLK13},
+ {"clk14", QE_CLK14},
+ {"clk15", QE_CLK15},
+ {"clk16", QE_CLK16},
+ {"clk17", QE_CLK17},
+ {"clk18", QE_CLK18},
+ {"clk19", QE_CLK19},
+ {"clk20", QE_CLK20},
+ {"clk21", QE_CLK21},
+ {"clk22", QE_CLK22},
+ {"clk23", QE_CLK23},
+ {"clk24", QE_CLK24}
+ };
+ unsigned int i;
+
+ for (i = 0; i < QE_CLK_DUMMY; i++)
+ if (strcasecmp(source, sources[i].name) == 0)
+ return (enum qe_clock) sources[i].num;
+
+ return QE_CLK_DUMMY;
+}
+EXPORT_SYMBOL(qe_clock_source);
+
/* Initialize SNUMs (thread serial numbers) according to
* QE Module Control chapter, SNUM table
*/
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index 0dabe46..d28bc85 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -175,6 +175,9 @@ enum qe_clock {
QE_CLK_DUMMY,
};
+/* Convert a string to a QE clock source enum */
+enum qe_clock qe_clock_source(const char *source);
+
/* QE CMXUCR Registers.
* There are two UCCs represented in each of the four CMXUCR registers.
* These values are for the UCC in the LSBs
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 15:56 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <1191945199488-git-send-email-timur@freescale.com>
On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
> Add function qe_clock_source() which takes a string containing the
> name of a
> QE clock source (as is typically found in device trees) and returns
> the
> matching enum qe_clock value.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
>
> This patch applies to Kumar's for-2.6.24 branch.
>
> arch/powerpc/sysdev/qe_lib/qe.c | 65 ++++++++++++++++++++++++++++
> +++++++++++
> include/asm-powerpc/qe.h | 3 ++
> 2 files changed, 68 insertions(+), 0 deletions(-)
I'm sure its asking to much of the QE HW for BRGs or CLKs to be
sequential.
- k
^ permalink raw reply
* Re: [PATCH 00/15] [POWERPC] TQM5200, CM5200 and Motion-PRO support
From: Kumar Gala @ 2007-10-09 15:57 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Marian Balakowicz
In-Reply-To: <fa686aa40710090738s748c17cdn6fa29cc6aea433d9@mail.gmail.com>
On Oct 9, 2007, at 9:38 AM, Grant Likely wrote:
> On 10/9/07, Marian Balakowicz <m8@semihalf.com> wrote:
>>
>> All,
>>
>> Thanks for the review, will process all the comments and resend
>> updated patches soon.
>
> Make sure you take a look at the 6 patches I posted yesterday. They
> will probably go in before your changes and will cause conflicts.
>
> Kumar, once I respin the ROOT_DEV patch, how does it look for merging
> my patch set?
most likely, however I think the patchset should go via paul since
you're touching things all over arch/powerpc (52xx, 4xx, cell,
pseries, generic code, etc)
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <B8D11E08-7AC5-4B21-9C40-1068B29B058B@kernel.crashing.org>
Kumar Gala wrote:
>
> On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
>
>> Add function qe_clock_source() which takes a string containing the
>> name of a
>> QE clock source (as is typically found in device trees) and returns the
>> matching enum qe_clock value.
>>
>> Signed-off-by: Timur Tabi <timur@freescale.com>
>> ---
>>
>> This patch applies to Kumar's for-2.6.24 branch.
>>
>> arch/powerpc/sysdev/qe_lib/qe.c | 65
>> +++++++++++++++++++++++++++++++++++++++
>> include/asm-powerpc/qe.h | 3 ++
>> 2 files changed, 68 insertions(+), 0 deletions(-)
>
> I'm sure its asking to much of the QE HW for BRGs or CLKs to be sequential.
Well, this patch doesn't really address that anomaly. Its purpose is to help
get rid of stuff like this in the device tree:
ucc@2200 {
...
rx-clock = <19>;
tx-clock = <1a>;
19 and 1a are the integer equivalents of enum qe_clock. As you can imagine,
that's error prone.
If this patch is accepted, I got another patch that changes qe_setbrg() to
accept a qe_clock enum.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: Timur Tabi @ 2007-10-09 16:06 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071009030729.GI12499@localhost.localdomain>
David Gibson wrote:
> Policy. Compiling everything means build bugs - like this one - can
> be found by everybody, not just those building for the specific
> obscure platform.
Is this a new policy? Modules in the kernel are not built unless you want
them. Even in arch/powerpc/platforms, only the specific platform file I'm
targeting is built. So I don't really understand why you claim it's normal
for platform-specific files to be built, regardless of the actual platform.
And frankly, I don't like this "policy". Build bugs for 4xx should not
interfere in my 83xx development. I can't build any kernels now because of
this bug!
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: Build failure on treeboot-walnut.cg
From: Scott Wood @ 2007-10-09 16:06 UTC (permalink / raw)
To: David Gibson; +Cc: Paul Mackerras, linuxppc-dev, Timur Tabi
In-Reply-To: <20071009030729.GI12499@localhost.localdomain>
On Tue, Oct 09, 2007 at 01:07:29PM +1000, David Gibson wrote:
> On Mon, Oct 08, 2007 at 04:33:24PM -0500, Timur Tabi wrote:
> > Question: I'm building a kernel for the 8610. Why is treeboot-walnut.c
> > being compiled at all?
>
> Policy. Compiling everything means build bugs - like this one - can
> be found by everybody, not just those building for the specific
> obscure platform.
Of course, it also introduces bugs that wouldn't have been an issue if we
didn't try to build everything with the same toolchain. :-P
I'm also somewhat worried what it'll do to build time as platforms
accumulate.
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 16:18 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BA5DF.5060206@freescale.com>
On Oct 9, 2007, at 11:01 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> On Oct 9, 2007, at 10:53 AM, Timur Tabi wrote:
>>> Add function qe_clock_source() which takes a string containing
>>> the name of a
>>> QE clock source (as is typically found in device trees) and
>>> returns the
>>> matching enum qe_clock value.
>>>
>>> Signed-off-by: Timur Tabi <timur@freescale.com>
>>> ---
>>>
>>> This patch applies to Kumar's for-2.6.24 branch.
>>>
>>> arch/powerpc/sysdev/qe_lib/qe.c | 65 ++++++++++++++++++++++++++
>>> +++++++++++++
>>> include/asm-powerpc/qe.h | 3 ++
>>> 2 files changed, 68 insertions(+), 0 deletions(-)
>> I'm sure its asking to much of the QE HW for BRGs or CLKs to be
>> sequential.
>
> Well, this patch doesn't really address that anomaly. Its purpose
> is to help get rid of stuff like this in the device tree:
>
> ucc@2200 {
> ...
> rx-clock = <19>;
> tx-clock = <1a>;
>
> 19 and 1a are the integer equivalents of enum qe_clock. As you can
> imagine, that's error prone.
>
> If this patch is accepted, I got another patch that changes
> qe_setbrg() to accept a qe_clock enum.
is 19 the actual value you'd end up using from the HW? or is it
related to some random enum value?
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <2E830F97-ADAE-43CA-9BD3-BEBFEFBE1D5C@kernel.crashing.org>
Kumar Gala wrote:
> is 19 the actual value you'd end up using from the HW? or is it related
> to some random enum value?
Random enum value. Here's the code in ucc_geth:
prop = of_get_property(np, "rx-clock", NULL);
ug_info->uf_info.rx_clock = *prop;
Here's the data type:
struct ucc_fast_info {
int ucc_num;
enum qe_clock rx_clock;
enum qe_clock tx_clock;
...
As you can see, it doesn't even validate the property.
My uart driver has this:
rx-clock-source = "BRG5";
tx-clock-source = "BRG6";
sprop = of_get_property(np, "rx-clock-source", NULL);
if (!sprop) {
printk(KERN_ERR
"ucc-uart: missing rx-clock-source in device tree\n");
kfree(qe_port);
return -ENODEV;
}
qe_port->us_info.rx_clock = of_clock_source(sprop);
if ((qe_port->us_info.rx_clock < QE_BRG1) ||
(qe_port->us_info.rx_clock > QE_BRG16)) {
printk(KERN_ERR
"ucc-uart: rx-clock-source must be a BRG for UART\n");
kfree(qe_port);
return -ENODEV;
}
I will be submitting patches to ucc_geth to fix this problem.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 16:38 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BAAA2.30400@freescale.com>
Ok, I went and looked at how rx-clock & tx-clock are spec'd in
booting-without-of.txt
Why dont we fix this so we have a property that says "BRG" or "CLK"
and another that has ID = [1.16] for BRG and [1..24] for CLK.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <8D4AA8EB-812F-4E58-A13C-CE3BA72037F3@kernel.crashing.org>
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK" and
> another that has ID = [1.16] for BRG and [1..24] for CLK.
Because sometimes you can use both BRGs and CLKs. Some operations can be done
only on one or the other, and some can be done on both. The enum itself is
fine, I think. I'd rather not split up the two, just report an error if you
specify a clock source that's not support for that particular purpose.
UART, for instance, can use a CLK signal, but I wrote the driver to only
support BRGs because there are plenty of them and it's a lot simpler. But
someone, for instance, could wire up his board to want to use external clocks
for some UARTs, and so he'd need to modify the driver.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <8D4AA8EB-812F-4E58-A13C-CE3BA72037F3@kernel.crashing.org>
Kumar Gala wrote:
> Ok, I went and looked at how rx-clock & tx-clock are spec'd in
> booting-without-of.txt
>
> Why dont we fix this so we have a property that says "BRG" or "CLK"
> and another that has ID = [1.16] for BRG and [1..24] for CLK.
Or we could keep it as it is, check the beginning of the string for
"BRG" or "CLK", and binarize the number that follows.
Or we could just stop putting CLK information in the device tree. :-)
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:47 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470BB055.6050602@freescale.com>
Scott Wood wrote:
> Or we could just stop putting CLK information in the device tree. :-)
If we had a BRG/CLK manager, we probably could do that. But we don't have
something like that now.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:47 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BAFA8.1060408@freescale.com>
Timur Tabi wrote:
> UART, for instance, can use a CLK signal, but I wrote the driver to only
> support BRGs because there are plenty of them and it's a lot simpler. But
> someone, for instance, could wire up his board to want to use external clocks
> for some UARTs, and so he'd need to modify the driver.
In the absence of a BRG, the driver should just not support changing the
baud rate -- it shouldn't fail to function.
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Scott Wood @ 2007-10-09 16:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BB087.7080607@freescale.com>
Timur Tabi wrote:
> Scott Wood wrote:
>
>> Or we could just stop putting CLK information in the device tree. :-)
>
> If we had a BRG/CLK manager, we probably could do that. But we don't
> have something like that now.
I didn't say stop putting BRG information in there -- just CLKs, which
are static setup that can be done in firmware or the board file. This
works fine on CPM1/2.
-Scott
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 16:48 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <470BB09D.7060304@freescale.com>
Scott Wood wrote:
> In the absence of a BRG, the driver should just not support changing the
> baud rate -- it shouldn't fail to function.
Since I don't have hardware that can test external clocks, I can't guarantee
that any such code will work.
I'm sure there are a dozen things I could do to improve the driver as it
stands, but I need to draw the line somewhere.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [patch v2] PS3: Add os-area database routines
From: Linas Vepstas @ 2007-10-09 17:15 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <470AD44C.5080305@am.sony.com>
On Mon, Oct 08, 2007 at 06:07:24PM -0700, Geoff Levand wrote:
> Subject: PS3: Add os-area database routines
>
> Add support for a simple tagged database in the PS3 flash rom
> os-area. The database allows the flash rom os-area to be shared
> between a bootloader and installed operating systems. The
> application ps3-flash-util or the library libps3-utils from the
> ps3-utils package can be used for userspace database operations.
Perhaps I missed the discussion; but .. out of general curiosity,
what is the relation between this and the ppc_md.nvram_* system?
I note that pseries, powermac, chrp, celleb implement the nvram calls,
but cell and ps3 do not. So clearly, whatever this is, its not
layered on top of nvram?
FWIW, I don't quite understand the nvram system; it seems to have
partitions; one part is an "os area", and a chuck of it is set
up as a file system.
So I'm wondering -- wouldn't the DB os-area be "generically
interesting" to other ppowerpc platforms? Maybe even other arches?
And why isn't this built on top of the nvram structure? ... etc?
--linas
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
From: Grant Likely @ 2007-10-09 17:39 UTC (permalink / raw)
To: Antonino A. Daplas
Cc: linuxppc, akonovalov, linux-fbdev-devel, linux-kernel,
Paul Mackerras
In-Reply-To: <1191906242.6083.7.camel@daplas>
On 10/8/07, Antonino A. Daplas <adaplas@gmail.com> wrote:
> On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote:
> > BTW, what path do framebuffer patches take to get into Linus' tree?
> > Does he pull your tree directly, or do they go through someone else's
> > tree?
>
> They all go to -mm tree, unless it's a needed fix, then to Linus's.
>
> Tony
Ah, okay.
Since the XilinxFB is a powerpc-only device, is it okay with you if I
get Paul Mackerras to merge them into his tree instead (that way the
changes go in with the platform code which requires these changes)
Paulus, is that okay by you?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 18:10 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BB0E6.4050801@freescale.com>
On Oct 9, 2007, at 11:48 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> In the absence of a BRG, the driver should just not support
>> changing the baud rate -- it shouldn't fail to function.
>
> Since I don't have hardware that can test external clocks, I can't
> guarantee that any such code will work.
>
> I'm sure there are a dozen things I could do to improve the driver
> as it stands, but I need to draw the line somewhere.
I guess my point is it appears the patch is related to how we
represent the RX/TX clock information in the device tree.
I'm suggesting that we do something like:
rx-clock-type = "brg" or "clk"
rx-clock-id = 3
I don't see how this doesn't cover what you need in the device tree.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 18:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <EF1344B5-5A53-4CC1-A51E-59EB9024B0C5@kernel.crashing.org>
Kumar Gala wrote:
> rx-clock-type = "brg" or "clk"
> rx-clock-id = 3
>
> I don't see how this doesn't cover what you need in the device tree.
That just looks more complicated than what my patch proposes. Why have two
properties when one will suffice? I still need to have a look-up table that
will convert "3" to QE_BRG3, since the latter is an enum.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Kumar Gala @ 2007-10-09 18:15 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <470BC484.3060702@freescale.com>
On Oct 9, 2007, at 1:12 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> rx-clock-type = "brg" or "clk"
>> rx-clock-id = 3
>> I don't see how this doesn't cover what you need in the device tree.
>
> That just looks more complicated than what my patch proposes. Why
> have two properties when one will suffice? I still need to have a
> look-up table that will convert "3" to QE_BRG3, since the latter is
> an enum.
But that's a function of linux' use. Remember decouple the device
tree from how linux does things.
- k
^ permalink raw reply
* Re: [PATCH] qe: add function qe_clock_source
From: Timur Tabi @ 2007-10-09 18:17 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <91CB543F-A0F2-42A4-AA5C-6F8FC99F9EC3@kernel.crashing.org>
Kumar Gala wrote:
> But that's a function of linux' use. Remember decouple the device tree
> from how linux does things.
Ok, I just understand what your point is. I'm proposing that we just put the
name of the clock source in the device tree, and have a function which
converts that into an internal representation. The clock is called "BRG3".
It's not called BRG, #3 or something like that. Same thing with the CLK sources.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ 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