On 20/09/13 18:23, Sebastian Hesselbarth wrote:
On 09/20/2013 06:51 AM, Tony Prisk wrote:
On 20/09/13 07:12, Sebastian Hesselbarth wrote:
On 09/19/2013 09:02 PM, Tony Prisk wrote:
On 19/09/13 05:53, Sebastian Hesselbarth wrote:
Currently, clock providers for vt8500 depend on machine_init
prov
On 09/20/2013 06:51 AM, Tony Prisk wrote:
On 20/09/13 07:12, Sebastian Hesselbarth wrote:
On 09/19/2013 09:02 PM, Tony Prisk wrote:
On 19/09/13 05:53, Sebastian Hesselbarth wrote:
Currently, clock providers for vt8500 depend on machine_init providing
pmc_base address before calling of_clk_init
On 20/09/13 07:12, Sebastian Hesselbarth wrote:
On 09/19/2013 09:02 PM, Tony Prisk wrote:
On 19/09/13 05:53, Sebastian Hesselbarth wrote:
Currently, clock providers for vt8500 depend on machine_init providing
pmc_base address before calling of_clk_init. With upcoming arch-wide
.time_init callin
On 19/09/13 05:53, Sebastian Hesselbarth wrote:
Currently, clock providers for vt8500 depend on machine_init providing
pmc_base address before calling of_clk_init. With upcoming arch-wide
.time_init calling of_clk_init, we should make clock providers independent
of mach code. This adds a pmc_base
On 09/19/2013 09:02 PM, Tony Prisk wrote:
On 19/09/13 05:53, Sebastian Hesselbarth wrote:
Currently, clock providers for vt8500 depend on machine_init providing
pmc_base address before calling of_clk_init. With upcoming arch-wide
.time_init calling of_clk_init, we should make clock providers
ind
Currently, clock providers for vt8500 depend on machine_init providing
pmc_base address before calling of_clk_init. With upcoming arch-wide
.time_init calling of_clk_init, we should make clock providers independent
of mach code. This adds a pmc_base parsing helper to current clock provider
that get
6 matches
Mail list logo