All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/3] MIPS: Move cache sizes to Kconfig
Date: Sat, 28 May 2016 14:03:39 +0200	[thread overview]
Message-ID: <5749891B.1060308@denx.de> (raw)
In-Reply-To: <57486B39.9060206@gmail.com>

On 05/27/2016 05:43 PM, Daniel Schwierzeck wrote:
> 
> 
> Am 27.05.2016 um 16:40 schrieb Marek Vasut:
>> On 05/27/2016 04:34 PM, Paul Burton wrote:
>>> On Fri, May 27, 2016 at 04:32:26PM +0200, Marek Vasut wrote:
>>>> On 05/27/2016 12:36 PM, Paul Burton wrote:
>>>>> On Thu, May 26, 2016 at 06:10:38PM +0200, Marek Vasut wrote:
>>>>>>> diff --git a/arch/mips/lib/cache.c b/arch/mips/lib/cache.c
>>>>>>> index 7482005..7695325 100644
>>>>>>> --- a/arch/mips/lib/cache.c
>>>>>>> +++ b/arch/mips/lib/cache.c
>>>>>>> @@ -9,7 +9,7 @@
>>>>>>>  #include <asm/cacheops.h>
>>>>>>>  #include <asm/mipsregs.h>
>>>>>>>  
>>>>>>> -#ifdef CONFIG_SYS_CACHELINE_SIZE
>>>>>>> +#if CONFIG_SYS_CACHELINE_SIZE != 0
>>>>>>
>>>>>> Wouldn't it make more sense to introduce something like
>>>>>> CONFIG_HAVE_CACHE_SUPPORT instead , so you don't need this
>>>>>> #if CONFIG_FOO != 0 construct all over the place ?
>>>>>
>>>>> Hi Marek,
>>>>>
>>>>> It's not about whether cache support is present (we always build cache
>>>>> support), it's about whether we are hardcoding the sizes of the caches
>>>>> or detecting them at runtime. The latter is especially useful on
>>>>> FPGA-based platforms like Malta where the CPU (& caches) can change. I
>>>>> suppose I could add something like CONFIG_SYS_CACHE_SIZE_AUTO, but I
>>>>> still think it would be cleanest to have that default to a value based
>>>>> upon whether a board has set a non-zero size for any of the caches.
>>>>
>>>> Auto-detecting cacheline size is cool, but that'd need much more work.
>>>> Just grep through drivers/ for CONFIG_SYS_CACHELINE_SIZE and you'll
>>>> see a lot of code depends on non-zero value in it. Setting it to zero
>>>> will just bite you at some point in a nasty way.
>>>
>>> Hi Marek,
>>
>> Hi!
>>
>>> We're already using the cache size auto-detection on Malta, and on 2
>>> other FPGA-based boards internally. I've submitted v2 which preserves
>>> CONFIG_SYS_CACHELINE_SIZE as a synonym of ARCH_DMA_MINALIGN for the
>>> drivers that are still using it.
>>
>> That's a good workaround for now. Would you be interested in fixing this
>> runtime cache configuration properly ?
>>
> 
> there is no runtime configuration for ARCH_DMA_MINALIGN. This value is
> defined at compile-time by Kconfig option MIPS_L1_CACHE_SHIFT. This is
> similar to what Linux is doing.
> 
So the DMA_MINALIGN is always a multiple of cacheline size on MIPS ?

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2016-05-28 12:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-26 15:58 [U-Boot] [PATCH 0/3] MIPS cache cleanups Paul Burton
2016-05-26 15:58 ` [U-Boot] [PATCH 1/3] MIPS: Move cache sizes to Kconfig Paul Burton
2016-05-26 16:10   ` Marek Vasut
2016-05-27 10:36     ` Paul Burton
2016-05-27 14:32       ` Marek Vasut
2016-05-27 14:34         ` Paul Burton
2016-05-27 14:40           ` Marek Vasut
2016-05-27 14:54             ` Paul Burton
2016-05-28 12:18               ` Marek Vasut
2016-05-27 15:43             ` Daniel Schwierzeck
2016-05-28 12:03               ` Marek Vasut [this message]
2016-05-31 16:21             ` Zubair Lutfullah Kakakhel
2016-05-31  8:00   ` Daniel Schwierzeck
2016-05-26 15:58 ` [U-Boot] [PATCH 2/3] MIPS: Split I & D cache line size config Paul Burton
2016-05-26 16:12   ` Marek Vasut
2016-05-27 11:21     ` Daniel Schwierzeck
2016-05-31  8:01   ` Daniel Schwierzeck
2016-05-26 15:58 ` [U-Boot] [PATCH 3/3] MIPS: Abstract cache op loops with a macro Paul Burton
2016-05-26 16:13   ` Marek Vasut
2016-05-27 10:30     ` Paul Burton
2016-05-27 14:36       ` Marek Vasut
2016-05-27 14:48         ` Paul Burton
2016-05-28 12:27           ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5749891B.1060308@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.