On Thu, Aug 23, 2018 at 9:37 AM, Christoph Hellwig wrote:
> On Wed, Aug 22, 2018 at 08:54:51PM +0530, Anup Patel wrote:
>> IMHO, rather than waiting for new CPU ON/OFF methods to come-up we
>> can keep the cpu_operations ready. Also, we are not re-inventing anything
>> here which we might have to
On Wed, Aug 22, 2018 at 08:54:51PM +0530, Anup Patel wrote:
> IMHO, rather than waiting for new CPU ON/OFF methods to come-up we
> can keep the cpu_operations ready. Also, we are not re-inventing anything
> here which we might have to discard later because cpu_operations are
> already tried and har
On 8/22/18 8:54 PM, Anup Patel wrote:
On Wed, Aug 22, 2018 at 11:33 AM, Christoph Hellwig wrote:
On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
The cpu_operations is certainly required because SOC vendors will add
vendor-specific mechanism to selectively bringing-up CPUs/HARTs ins
On Tue, 21 Aug 2018 23:03:53 PDT (-0700), Christoph Hellwig wrote:
On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
The cpu_operations is certainly required because SOC vendors will add
vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
of all CPUs entering Linux
On Wed, Aug 22, 2018 at 11:33 AM, Christoph Hellwig wrote:
> On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
>> The cpu_operations is certainly required because SOC vendors will add
>> vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
>> of all CPUs entering Linux
On Tue, Aug 21, 2018 at 10:34:38PM +0530, Anup Patel wrote:
> The cpu_operations is certainly required because SOC vendors will add
> vendor-specific mechanism to selectively bringing-up CPUs/HARTs instead
> of all CPUs entering Linux kernel simultaneously. In fact, we might also
> end-up
> having
On Tue, Aug 21, 2018 at 1:18 PM, Christoph Hellwig wrote:
> On Thu, Aug 16, 2018 at 11:51:03AM +0530, Anup Patel wrote:
>> Having thought about this more, I think cpu_ops should be an pointer array
>> of NR_CPUS size. This means its not necessary to have have same ops for
>> all CPUs. The ARM64 im
On Thu, Aug 16, 2018 at 11:51:03AM +0530, Anup Patel wrote:
> Having thought about this more, I think cpu_ops should be an pointer array
> of NR_CPUS size. This means its not necessary to have have same ops for
> all CPUs. The ARM64 implementation of CPU operations also allows separate
> CPU operat
On 8/15/18 11:21 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra wrote:
On 8/15/18 10:02 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexib
On Thu, Aug 16, 2018 at 11:10 AM, Atish Patra wrote:
> On 8/15/18 10:02 PM, Anup Patel wrote:
>>
>> On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
>>>
>>> Defining cpu_operations now helps adding cpu hotplug
>>> support in proper manner. Moreover, it provides flexibility
>>> in supporting ot
On 8/15/18 10:02 PM, Anup Patel wrote:
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexibility
in supporting other cpu enable/boot methods can be
supported in future. This patch has been
On Thu, Aug 16, 2018 at 5:26 AM, Atish Patra wrote:
> Defining cpu_operations now helps adding cpu hotplug
> support in proper manner. Moreover, it provides flexibility
> in supporting other cpu enable/boot methods can be
> supported in future. This patch has been largely inspired from
> ARM64. Ho
Defining cpu_operations now helps adding cpu hotplug
support in proper manner. Moreover, it provides flexibility
in supporting other cpu enable/boot methods can be
supported in future. This patch has been largely inspired from
ARM64. However, a default boot method is defined for RISC-V unlike
ARM64
13 matches
Mail list logo
