Hi Arnd,
On Wed, Mar 28, 2018 at 09:40:49AM +0200, Arnd Bergmann wrote:
> Ok, thanks for the clarification. Obviously if they are mutually incompatible,
> there is no point in using a common kernel, so your current version is
> absolutely fine, and this is similar to how we cannot have a common
Hi Arnd,
On Wed, Mar 28, 2018 at 09:40:49AM +0200, Arnd Bergmann wrote:
> Ok, thanks for the clarification. Obviously if they are mutually incompatible,
> there is no point in using a common kernel, so your current version is
> absolutely fine, and this is similar to how we cannot have a common
On Wed, Mar 28, 2018 at 5:49 AM, Guo Ren wrote:
> Hi Arnd,
>
> On Tue, Mar 27, 2018 at 09:38:56AM +0200, Arnd Bergmann wrote:
>> Usually the way gcc handles this, either each CPU is a strict superset
>> of another
>> one, so you just need to specify the one with the smallest
On Wed, Mar 28, 2018 at 5:49 AM, Guo Ren wrote:
> Hi Arnd,
>
> On Tue, Mar 27, 2018 at 09:38:56AM +0200, Arnd Bergmann wrote:
>> Usually the way gcc handles this, either each CPU is a strict superset
>> of another
>> one, so you just need to specify the one with the smallest instruction set,
>>
Hi Arnd,
On Tue, Mar 27, 2018 at 09:38:56AM +0200, Arnd Bergmann wrote:
> Usually the way gcc handles this, either each CPU is a strict superset
> of another
> one, so you just need to specify the one with the smallest instruction set,
> or you have an option like -mcpu=generic that produces the
Hi Arnd,
On Tue, Mar 27, 2018 at 09:38:56AM +0200, Arnd Bergmann wrote:
> Usually the way gcc handles this, either each CPU is a strict superset
> of another
> one, so you just need to specify the one with the smallest instruction set,
> or you have an option like -mcpu=generic that produces the
On Tue, Mar 27, 2018 at 4:39 AM, Guo Ren wrote:
> On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote:
>> Ok, I understand the part about ck610 being incompatible, but I'm
>> still not sure about the 8xx ones: Do you mean it's impossible to
>> have one kernel that
On Tue, Mar 27, 2018 at 4:39 AM, Guo Ren wrote:
> On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote:
>> Ok, I understand the part about ck610 being incompatible, but I'm
>> still not sure about the 8xx ones: Do you mean it's impossible to
>> have one kernel that runs across all of
On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote:
> Ok, I understand the part about ck610 being incompatible, but I'm
> still not sure about the 8xx ones: Do you mean it's impossible to
> have one kernel that runs across all of them for some other reason,
> or is it something you
On Mon, Mar 26, 2018 at 03:00:00PM +0200, Arnd Bergmann wrote:
> Ok, I understand the part about ck610 being incompatible, but I'm
> still not sure about the 8xx ones: Do you mean it's impossible to
> have one kernel that runs across all of them for some other reason,
> or is it something you
On Wed, Mar 21, 2018 at 1:41 PM, Guo Ren wrote:
> Hi arnd,
>
> On Wed, Mar 21, 2018 at 03:36:43PM +0800, Arnd Bergmann wrote:
>> If the clocksource depends on a driver rather than a feature of the
>> architecture,
>> this may not be worth optimizing though, so maybe leave it as
On Wed, Mar 21, 2018 at 1:41 PM, Guo Ren wrote:
> Hi arnd,
>
> On Wed, Mar 21, 2018 at 03:36:43PM +0800, Arnd Bergmann wrote:
>> If the clocksource depends on a driver rather than a feature of the
>> architecture,
>> this may not be worth optimizing though, so maybe leave it as it is for now.
>>
Hi arnd,
On Wed, Mar 21, 2018 at 03:36:43PM +0800, Arnd Bergmann wrote:
> If the clocksource depends on a driver rather than a feature of the
> architecture,
> this may not be worth optimizing though, so maybe leave it as it is for now.
>
Ok, I'll keep it.
> >> Usually the kernel should allow
Hi arnd,
On Wed, Mar 21, 2018 at 03:36:43PM +0800, Arnd Bergmann wrote:
> If the clocksource depends on a driver rather than a feature of the
> architecture,
> this may not be worth optimizing though, so maybe leave it as it is for now.
>
Ok, I'll keep it.
> >> Usually the kernel should allow
On Tue, Mar 20, 2018 at 9:13 PM, Guo Ren wrote:
> Hi arnd,
>
> On Mon, Mar 19, 2018 at 11:45:23PM +0800, Arnd Bergmann wrote:
>> Does your architecture provide a reliable high-reslution clocksource?
>> If yes, you
>> could use that for the delay, rather than a calibrated loop.
On Tue, Mar 20, 2018 at 9:13 PM, Guo Ren wrote:
> Hi arnd,
>
> On Mon, Mar 19, 2018 at 11:45:23PM +0800, Arnd Bergmann wrote:
>> Does your architecture provide a reliable high-reslution clocksource?
>> If yes, you
>> could use that for the delay, rather than a calibrated loop.
> Currently, all
Hi arnd,
On Mon, Mar 19, 2018 at 11:45:23PM +0800, Arnd Bergmann wrote:
> > + select ARCH_WANT_IPC_PARSE_VERSION
>
> Drop ipc_parse_version here, it's only for old architectures.
>
I will remove it.
> > + select HAVE_OPROFILE
> > + select HAVE_PERF_EVENTS
>
> Do you still
Hi arnd,
On Mon, Mar 19, 2018 at 11:45:23PM +0800, Arnd Bergmann wrote:
> > + select ARCH_WANT_IPC_PARSE_VERSION
>
> Drop ipc_parse_version here, it's only for old architectures.
>
I will remove it.
> > + select HAVE_OPROFILE
> > + select HAVE_PERF_EVENTS
>
> Do you still
On Mon, Mar 19, 2018 at 3:51 AM, Guo Ren wrote:
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> new file mode 100644
> index 000..694c1f8
> --- /dev/null
> +++ b/arch/csky/Kconfig
> @@ -0,0 +1,203 @@
> +config CSKY
> + bool
> + default y
> + select
On Mon, Mar 19, 2018 at 3:51 AM, Guo Ren wrote:
> diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
> new file mode 100644
> index 000..694c1f8
> --- /dev/null
> +++ b/arch/csky/Kconfig
> @@ -0,0 +1,203 @@
> +config CSKY
> + bool
> + default y
> + select
Signed-off-by: Guo Ren
---
arch/csky/Kconfig | 203 ++
arch/csky/Kconfig.debug | 22 +
arch/csky/Makefile| 92 +
arch/csky/abiv1/Makefile | 8 ++
Signed-off-by: Guo Ren
---
arch/csky/Kconfig | 203 ++
arch/csky/Kconfig.debug | 22 +
arch/csky/Makefile| 92 +
arch/csky/abiv1/Makefile | 8 ++
arch/csky/abiv2/Makefile | 3
22 matches
Mail list logo