On Oct 9, 2007, at 2:18 PM, Timur Tabi wrote:
> Kumar Gala wrote:
>
>> Ok. I guess I'm not in favor of changing the device tree to
>> address this issue. I think it would be solved if "dtc" had
>> #define support.
>
> Not really. The #defines would then need to match the enum, and
> that
Kumar Gala wrote:
> Ok. I guess I'm not in favor of changing the device tree to address
> this issue. I think it would be solved if "dtc" had #define support.
Not really. The #defines would then need to match the enum, and that's dual
maintenance. This method is better because you can use t
On Oct 9, 2007, at 1:17 PM, Timur Tabi wrote:
> 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 dev
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 i
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
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
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
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
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
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 t
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
___
Linuxpp
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
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.
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
___
Linuxppc-dev mailing list
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:
str
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
>>> matchin
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 <[
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 <[EMAIL PROTECTED]>
> ---
>
18 matches
Mail list logo
