mbox

[GIT,PULL] ARM: dts: aspeed: Changes for 4.14

Message ID CACPK8XerZV+3RbxofpghWioYC68kK531aQQ_Jc8ZYLrjjCUqjQ@mail.gmail.com
State New
Headers show

Pull-request

git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git

Message

Joel Stanley Aug. 24, 2017, 4:14 a.m. UTC
Hi Arnd and Olof,

Here's an Aspeed devicetree change for 4.14.

As with the defconfig pull, this change has been kicking around for a while
now so it is well tested.

The following changes since commit 5771a8c08880cdca3bfb4a3fc6d309d6bba20877:

  Linux v4.13-rc1 (2017-07-15 15:22:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git
tags/aspeed-4.14-devicetree

for you to fetch changes up to bcbd328d3fe765f333642b7cfe384d59dffc2db2:

  ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers
(2017-08-23 16:06:02 +0930)

----------------------------------------------------------------
Aspeed devicetree updates for 4.14

 - fix to expose the full flash windows on ast2400.

----------------------------------------------------------------
Cédric Le Goater (1):
      ARM: dts: aspeed-g4: fix AHB window size of the SMC controllers

 arch/arm/boot/dts/aspeed-g4.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Arnd Bergmann Aug. 24, 2017, 11:13 a.m. UTC | #1
On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote:
> Hi Arnd and Olof,
> Aspeed devicetree updates for 4.14
>
>  - fix to expose the full flash windows on ast2400.
>

Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G
requirement mentioned in the changelog here? Will it stop working with
a normal multiplatform configuration that uses VMSPLIT_3G, or just
have no effect?

      Arnd
Cédric Le Goater Aug. 24, 2017, 3:06 p.m. UTC | #2
On 08/24/2017 01:13 PM, Arnd Bergmann wrote:
> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote:
>> Hi Arnd and Olof,
>> Aspeed devicetree updates for 4.14
>>
>>  - fix to expose the full flash windows on ast2400.
>>
> 
> Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G
> requirement mentioned in the changelog here? Will it stop working with
> a normal multiplatform configuration that uses VMSPLIT_3G, or just
> have no effect?

The kernel will still boot but, without VMSPLIT_2G, the SPI flash 
controller driver will fail to map the memory windows of the flash 
devices. And the system will surely lack a root filesystem. 

C.
Arnd Bergmann Aug. 24, 2017, 9:24 p.m. UTC | #3
On Thu, Aug 24, 2017 at 5:06 PM, Cédric Le Goater <clg@kaod.org> wrote:
> On 08/24/2017 01:13 PM, Arnd Bergmann wrote:
>> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote:
>>> Hi Arnd and Olof,
>>> Aspeed devicetree updates for 4.14
>>>
>>>  - fix to expose the full flash windows on ast2400.
>>>
>>
>> Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G
>> requirement mentioned in the changelog here? Will it stop working with
>> a normal multiplatform configuration that uses VMSPLIT_3G, or just
>> have no effect?
>
> The kernel will still boot but, without VMSPLIT_2G, the SPI flash
> controller driver will fail to map the memory windows of the flash
> devices. And the system will surely lack a root filesystem.

Hmm, why does the flash controller even map the entire area?

IIRC, NOR flash controllers normally have a 'ranges' property that
gets set up to list the available memory ranges, and the chips
attached to them have the 'reg' property that matches the actual
size.

     Arnd
Cédric Le Goater Aug. 28, 2017, 10:13 a.m. UTC | #4
On 08/24/2017 11:24 PM, Arnd Bergmann wrote:
> On Thu, Aug 24, 2017 at 5:06 PM, Cédric Le Goater <clg@kaod.org> wrote:
>> On 08/24/2017 01:13 PM, Arnd Bergmann wrote:
>>> On Thu, Aug 24, 2017 at 6:14 AM, Joel Stanley <joel@jms.id.au> wrote:
>>>> Hi Arnd and Olof,
>>>> Aspeed devicetree updates for 4.14
>>>>
>>>>  - fix to expose the full flash windows on ast2400.
>>>>
>>>
>>> Pulled into next/dt, thanks! Can you explain the CONFIG_VMSPLIT_2G
>>> requirement mentioned in the changelog here? Will it stop working with
>>> a normal multiplatform configuration that uses VMSPLIT_3G, or just
>>> have no effect?
>>
>> The kernel will still boot but, without VMSPLIT_2G, the SPI flash
>> controller driver will fail to map the memory windows of the flash
>> devices. And the system will surely lack a root filesystem.
> 
> Hmm, why does the flash controller even map the entire area?
> 
> IIRC, NOR flash controllers normally have a 'ranges' property that
> gets set up to list the available memory ranges, and the chips
> attached to them have the 'reg' property that matches the actual
> size.

Yes, that is the common scenario. 

The SMC controller of the Aspeed SoC uses a global memory window 
(defined by HW for each controller) on which the chips contents can 
be memory mapped. This is up to the software using 'segment' registers 
to organize how the mapping of each chip is done. There are some HW 
constraints on alignments, overlaps and on the values of the start and 
end addresses of each segment. For instance, the start address of the 
first segment should be equal to the start address of the global window 
and the end address of the last segment should be equal to the end address 
of the global window. 

Also, most of the backplanes (all IBMs) have sockets holding the flash 
devices, so you don't necessarily know which model and how many chips 
are available. Some boards have a couple of flash devices which can 
cover the full window, some have large ones, like the witherspoon
which uses a 128MB chip for the host firmware.

So, the driver does its best to discover the flash layout at probe time,
maps the full area and configures the segment registers accordingly. 
The start address of each segment is then used to send SPI commands 
when the controller is in I/O mode. When the controller is set to use 
memory mode, the full memory range can be used to access the flash 
contents directly.

I agree that we could probably probe the chips, configure the segment 
registers and then only map the required area. Some configurations 
would still need the whole window but there might be room for some 
improvements.
 
C.