ARM: sunxi: Enable syscon for the system controller
Subsystems (3)
cover ARM: sunxi: Enable syscon for the system controller
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.
Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Carlo Caione (2):
ARM: sunxi: dts: Enable syscon in DTSI
ARM: sunxi: Add syscon support in defconfig
arch/arm/boot/dts/sun6i-a31.dtsi | 5 +++++ arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++++ arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/sunxi_defconfig | 1 + 4 files changed, 12 insertions(+)
Signature · 1 line
1.8.3.2
PATCH 1/2 ARM: sunxi: dts: Enable syscon in DTSI
This patch adds the proper nodes in the DTSI files for Allwinner A20 and A31.
--- arch/arm/boot/dts/sun6i-a31.dtsi | 5 +++++ arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++++ 2 files changed, 10 insertions(+)
arch/arm/boot/dts/sun6i-a31.dtsi +5 -0
@@ -237,6 +237,11 @@ #size-cells = <1>; ranges; + syscon: syscon at 01c00000 { + compatible = "syscon"; + reg = <0x01c00000 0x27>; + }; + nmi_intc: interrupt-controller at 01f00c0c { compatible = "allwinner,sun6i-a31-sc-nmi"; interrupt-controller;
arch/arm/boot/dts/sun7i-a20.dtsi +5 -0
@@ -401,6 +401,11 @@ #size-cells = <1>; ranges; + syscon: syscon at 01c00000 { + compatible = "syscon"; + reg = <0x01c00000 0x27>; + }; + nmi_intc: interrupt-controller at 01c00030 { compatible = "allwinner,sun7i-a20-sc-nmi"; interrupt-controller;
Signature · 1 line
1.8.3.2
PATCH 2/2 ARM: sunxi: Add syscon support in defconfig
In reply to Carlo Caione--- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/sunxi_defconfig | 1 + 2 files changed, 2 insertions(+)
arch/arm/configs/multi_v7_defconfig +1 -0
@@ -343,3 +343,4 @@ CONFIG_DEBUG_FS=y CONFIG_MAGIC_SYSRQ=y CONFIG_LOCKUP_DETECTOR=y CONFIG_CRYPTO_DEV_TEGRA_AES=y +CONFIG_MFD_SYSCON=y
arch/arm/configs/sunxi_defconfig +1 -0
@@ -69,3 +69,4 @@ CONFIG_NFS_FS=y CONFIG_ROOT_NFS=y CONFIG_NLS=y CONFIG_PRINTK_TIME=y +CONFIG_MFD_SYSCON=y
Signature · 1 line
1.8.3.2
cover ARM: sunxi: Enable syscon for the system controller
In reply to Carlo CaioneQuoted 11 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140505/94cab0bb/attachment.sig>
Hi,
Quoted 9 lines · Maxime Ripard
Quoted 8 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.
Quoted 8 lines
Quoted 3 lines
Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
I believe this will be used for toggling the SRAM mappings. (Am I right?) The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
There should be something similar, as does the A23. There is no overlap AFAIK.
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
The MUSB glue layer driver must toggle this.
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
Cheers
ChenYu
Quoted 1 line · Chen-Yu Tsai
Hi,
Hi,
Quoted 11 lines
Quoted 9 lines · Maxime Ripard
Quoted 8 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
This is what I meant with that phrase. NMI controller doesn't use the syscon but we can use it for several other drivers. In fact the registers for NMI controller are excluded from the range of syscon registers.
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Not yet :)
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_map
Quoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
Quoted 7 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
Quoted 6 lines
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e. SRAM_CTL1_CFG is used for USB, EMAC, etc...)
Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
Thanks,
Signature · 1 line
Carlo Caione
Quoted 37 lines · Carlo Caione
Quoted 1 line · Chen-Yu Tsai
Hi,
Hi,
Quoted 11 lines
Quoted 9 lines · Maxime Ripard
Quoted 8 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
This is what I meant with that phrase. NMI controller doesn't use the syscon but we can use it for several other drivers. In fact the registers for NMI controller are excluded from the range of syscon registers.
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Quoted 8 lines
Not yet :)
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_map
I think the wiki hasn't been updated with much A31/A23 specifics yet.
Quoted 3 lines
Quoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
I will try to find time to update the wiki tonight.
Quoted 12 lines
Quoted 12 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
Quoted 8 lines
Quoted 1 line
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e.
SRAM_CTL1_CFGis used for USB, EMAC, etc...)
I came to the same conclusion, though I somehow forgot to update my tree on github. Here it is:
https://github.com/wens/linux/tree/wip/sunxi-musb
This also has the bit definitions:
https://github.com/wens/linux/commit/3db9c184df5e5b3e1ddef59926e88fc2d03b4de9
Beware musb in my tree doesn't work. I was focused on getting the phy driver and port controller correct.
Quoted 3 lines
Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
Cheers
ChenYu
On Tue, May 6, 2014 at 10:27 AM, Chen-Yu Tsai <[email protected]> wrote:
<snip>
Quoted 8 lines
I came to the same conclusion, though I somehow forgot to update my tree on github. Here it is:
https://github.com/wens/linux/tree/wip/sunxi-musb
This also has the bit definitions:
https://github.com/wens/linux/commit/3db9c184df5e5b3e1ddef59926e88fc2d03b4de9
Oh, I missed that wip branch. I'll add your SoB also and I'll add the bit definitions in v2 (if Maxime ACKs it)
Quoted 2 lines
Beware musb in my tree doesn't work. I was focused on getting the phy driver and port controller correct.
No prob, still scouting around :)
Thanks,
Signature · 1 line
Carlo Caione
Quoted 20 lines · Carlo Caione
Quoted 1 line · Chen-Yu Tsai
Hi,
Hi,
Quoted 15 lines
Quoted 13 lines · Maxime Ripard
Quoted 11 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
This is what I meant with that phrase. NMI controller doesn't use the syscon but we can use it for several other drivers.
I'm sorry, but I believe this should be more handled by the soon-to-be drivers/soc "framework".
Quoted 2 lines
In fact the registers for NMI controller are excluded from the range of syscon registers.
Then you are lying in the DT :)
Quoted 8 lines
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Not yet :)
I wonder how other SoCs are actually handling this mapping between CPU & DMA vs device of some SRAMs. Did you look at this?
Quoted 23 lines
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_mapQuoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
Quoted 12 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
Quoted 12 lines
Quoted 1 line
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e.
SRAM_CTL1_CFGis used for USB, EMAC, etc...)Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
I agree with that.
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140506/ff272595/attachment.sig>
Quoted 23 lines · Maxime Ripard
Quoted 22 lines · Carlo Caione
Quoted 1 line · Chen-Yu Tsai
Hi,
Hi,
Quoted 17 lines
Quoted 15 lines · Maxime Ripard
Quoted 11 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
This is what I meant with that phrase. NMI controller doesn't use the syscon but we can use it for several other drivers.
I'm sorry, but I believe this should be more handled by the soon-to-be
drivers/soc"framework".
Oh, didn't know of this framework. Is it supposed to replace syscon?
Quoted 4 lines
Quoted 2 lines
In fact the registers for NMI controller are excluded from the range of syscon registers.
Then you are lying in the DT :)
Uhm, in DT I have:
reg = <0x01c00000 0x27>;
that is I'm mapping the first three registers: SRAM_CTRL_REG0, SRAM_CTRL_REG1, VER_REG, leaving out the three register (from offset 0x30) of the NMI controller.
I'm not lying :)
Quoted 11 lines
Quoted 8 lines
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Not yet :)
I wonder how other SoCs are actually handling this mapping between CPU & DMA vs device of some SRAMs. Did you look at this?
It seems quite a few grepping for syscon
Quoted 32 lines
Quoted 32 lines
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_mapQuoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
Quoted 7 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
Quoted 6 lines
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e.
SRAM_CTL1_CFGis used for USB, EMAC, etc...)
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
I agree with that.
So do you suggest to drop the syscon idea waiting for the new soc framework?
Thanks,
Signature · 1 line
Carlo Caione
Quoted 28 lines · Carlo Caione
Quoted 26 lines · Maxime Ripard
Quoted 25 lines · Carlo Caione
Quoted 1 line · Chen-Yu Tsai
Hi,
Hi,
Quoted 19 lines
Quoted 17 lines · Maxime Ripard
Quoted 11 lines · Carlo Caione
The so called "system controller" in Allwinner A20 and A31 SoCs is multi-purpose controller that tries to add misc functionality to one memory region.
In these SoCs it controls the internal SRAM partitioning but it also includes registers for chip versioning and NMI control.
This patch adds the proper nodes in the DTS files and enable the syscon in the defconfig files.Even though the system controller includes also register for managing the NMI controller, these register are not mapped in the syscon since they are directly used and mapped by the NMI controller itself.
Hmmm, what exactly do you want to achieve with this?
The NMI controller won't be able to use it, since it's initialized much earlier than syscon and regmap.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
This is what I meant with that phrase. NMI controller doesn't use the syscon but we can use it for several other drivers.
I'm sorry, but I believe this should be more handled by the soon-to-be
drivers/soc"framework".Oh, didn't know of this framework. Is it supposed to replace syscon?
It's supposed to be a framework to handle all the weird things the SoCs have, that have to be enabled soon, and don't really fit into any of the existing frameworks, or multiple of them. Which looks pretty much like what we are experiencing here.
Quoted 5 lines
Quoted 4 lines
Quoted 2 lines
In fact the registers for NMI controller are excluded from the range of syscon registers.
Then you are lying in the DT :)
Quoted 8 lines
Uhm, in DT I have:
reg = <
0x01c000000x27>;that is I'm mapping the first three registers:
SRAM_CTRL_REG0,SRAM_CTRL_REG1,VER_REG, leaving out the three register (from offset0x30) of the NMI controller.
I'm not lying :)
Then you want to set 0x30 as a base. And ok, you're splitting this in two.
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Quoted 6 lines
Quoted 4 lines
Quoted 1 line
Not yet :)
I wonder how other SoCs are actually handling this mapping between CPU & DMA vs device of some SRAMs. Did you look at this?
It seems quite a few grepping for syscon
??
What do you mean?
I wasn't really talking about syscon itself, just how other SoCs usually deals with this kind of remapping usually.
Quoted 32 lines
Quoted 32 lines
Quoted 32 lines
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_mapQuoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
Quoted 7 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
Quoted 6 lines
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e.
SRAM_CTL1_CFGis used for USB, EMAC, etc...)
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
I agree with that.
So do you suggest to drop the syscon idea waiting for the new soc framework?
To be honest, I don't really know what to think of it. I'd need to see some code that uses this. Maybe we can just postpone the decision to whenever we will actually have some code submitted that make any use of this?
If it's easier for you to keep the syscon at the moment for whateever driver you're working on before submitting it, I'm fine with it, but I'm not going to merge it right now either.
Thanks,
Maxime
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140507/de687b1d/attachment.sig>
On Thu, May 8, 2014 at 5:04 AM, Maxime Ripard
<[email protected]> wrote:
<snip>
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines
Quoted 8 lines
Quoted 1 line
I believe this will be used for toggling the SRAM mappings. (Am I right?)
Definitely right.
Quoted 2 lines
The second register toggles mappings for MUSB FIFO, EMAC, and a few of the other IP blocks we currently don't support.
Not yet :)
I wonder how other SoCs are actually handling this mapping between CPU & DMA vs device of some SRAMs. Did you look at this?
Quoted 8 lines
Quoted 1 line
It seems quite a few grepping for syscon
??
What do you mean?
I wasn't really talking about syscon itself, just how other SoCs usually deals with this kind of remapping usually.
Ho, sorry. In general for what I have seen the drivers use syscon or just map directly the register they need to use.
Probably there is something smarter that I'm not aware of.
Quoted 41 lines
Quoted 32 lines
Quoted 32 lines
Quoted 32 lines
Quoted 2 lines
Quoted 2 lines
Moreover, the A31 doesn't seem to have this system controller, or at least this overlap.
I admit that I didn't check the A31 manual but I trusted the wiki page at http://linux-sunxi.org/SRAM_Controller and
http://linux-sunxi.org/A31/Memory_mapQuoted 1 line
There should be something similar, as does the A23. There is no overlap AFAIK.
I agree and will check also A23.
Quoted 7 lines
Quoted 3 lines
And since on the A20, registers seem to have one usage only, so I guess we can just split this IP into several nodes, just like we did with the NMI.
As stated above, the second register toggles SRAM mappings for at most 4 SRAM blocks (for EMAC, MUSB, ACE, ISP).
Quoted 6 lines
syscon would be a good way to share this register among the various drivers. We do not toggle it in the current EMAC driver. The driver seems to assume it is setup by the bootloader, and on the A20, it seems to be mapped to EMAC by default.
The MUSB glue layer driver must toggle this.
This is exactly why I wrote these patches. I started hacking / studying your MUSB driver and I think that using syscon is a better way to manage these registers instead of mapping them in several drivers also because most of the time a single register has to be used by multiple drivers (i.e.
SRAM_CTL1_CFGis used for USB, EMAC, etc...)Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
I think this approach is better than all the individual drivers mapping the registers and toggling a single bit. In fact I did something similar when working on preliminary musb support.
I agree with that.
So do you suggest to drop the syscon idea waiting for the new soc framework?
Quoted 8 lines
To be honest, I don't really know what to think of it. I'd need to see some code that uses this. Maybe we can just postpone the decision to whenever we will actually have some code submitted that make any use of this?
If it's easier for you to keep the syscon at the moment for whateever driver you're working on before submitting it, I'm fine with it, but I'm not going to merge it right now either.
It's fine with me.
Thank you for your review,
Signature · 1 line
Carlo Caione