On Tuesday 31 July 2012, Tomoya MORINAGA wrote:
>
> On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann wrote:
> > What I think should work better here would be to use the clk API,
> > so that the phub driver registers a 'struct clk' using
> > (I assume) clk_register_divider_table().
> > The UART
On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann wrote:
> What I think should work better here would be to use the clk API,
> so that the phub driver registers a 'struct clk' using
> (I assume) clk_register_divider_table().
> The UART driver would then call clk_get() to find that clk for
> the
On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann a...@arndb.de wrote:
What I think should work better here would be to use the clk API,
so that the phub driver registers a 'struct clk' using
(I assume) clk_register_divider_table().
The UART driver would then call clk_get() to find that clk for
On Tuesday 31 July 2012, Tomoya MORINAGA wrote:
On Wed, Jul 25, 2012 at 10:31 PM, Arnd Bergmann a...@arndb.de wrote:
What I think should work better here would be to use the clk API,
so that the phub driver registers a 'struct clk' using
(I assume) clk_register_divider_table().
The UART
Hi Tomoya,
On Tuesday 24 July 2012, Tomoya MORINAGA wrote:
> Let me know this patch status.
> If you have still any concern, let me know.
Sorry for the late reply.
> BTW, now I remember, Did you take part in LinuxConJapan last month ?
> I also took part in this event as volunteer staff.
>
Hi Tomoya,
On Tuesday 24 July 2012, Tomoya MORINAGA wrote:
Let me know this patch status.
If you have still any concern, let me know.
Sorry for the late reply.
BTW, now I remember, Did you take part in LinuxConJapan last month ?
I also took part in this event as volunteer staff.
Hi Arnd,
Let me know this patch status.
If you have still any concern, let me know.
BTW, now I remember, Did you take part in LinuxConJapan last month ?
I also took part in this event as volunteer staff.
Additionally, I took charge of your session as time keeper.
Thanks in advance.
--
ROHM
Hi Arnd,
Let me know this patch status.
If you have still any concern, let me know.
BTW, now I remember, Did you take part in LinuxConJapan last month ?
I also took part in this event as volunteer staff.
Additionally, I took charge of your session as time keeper.
Thanks in advance.
--
ROHM
On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann wrote:
> This looks like a rather nonscalable solution if you get to systems
> with lots of clocks.
This "clock" is internal clock, not external clock.
This PacketHub provides clock to the UART module
Both the PacketHub and the UART is in 1 chip LSI
On Wednesday 11 July 2012, Tomoya MORINAGA wrote:
> Currently, when a user wants to change UART clock,
> needs to modify this source code by hand.
> This patch enables changing UART clock by specifying UART clock
> as module parameter.
>
> Signed-off-by: Tomoya MORINAGA
This looks like a rather
Currently, when a user wants to change UART clock,
needs to modify this source code by hand.
This patch enables changing UART clock by specifying UART clock
as module parameter.
Signed-off-by: Tomoya MORINAGA
---
drivers/misc/pch_phub.c | 45 +
1
Currently, when a user wants to change UART clock,
needs to modify this source code by hand.
This patch enables changing UART clock by specifying UART clock
as module parameter.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com
---
drivers/misc/pch_phub.c | 45
On Wednesday 11 July 2012, Tomoya MORINAGA wrote:
Currently, when a user wants to change UART clock,
needs to modify this source code by hand.
This patch enables changing UART clock by specifying UART clock
as module parameter.
Signed-off-by: Tomoya MORINAGA tomoya.r...@gmail.com
This
On Wed, Jul 11, 2012 at 7:45 PM, Arnd Bergmann a...@arndb.de wrote:
This looks like a rather nonscalable solution if you get to systems
with lots of clocks.
This clock is internal clock, not external clock.
This PacketHub provides clock to the UART module
Both the PacketHub and the UART is in 1
14 matches
Mail list logo
