Xilinx Zynq changes for v3.15

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch from the second pull request.
I have kept OCM patch in this branch because it depends on slcr changes done here. If you want to send another pull request just for this OCM patch based on this branch, please let me know.

Thanks,
Michal

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git-dev/group/ssw/linux-xlnx.git tags/zynq-cleanup-for-3.15

for you to fetch changes up to e9aa3e3a5bb2d64515648537100e5cf9b863e01a:

ARM: zynq: Add support for SOC_BUS (2014-02-20 16:08:47 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add OCM driver
- Add SOC_BUS support

----------------------------------------------------------------
Michal Simek (8):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Add OCM driver
ARM: zynq: Move of_clk_init from clock driver
ARM: zynq: Add waituart implementation
ARM: zynq: Add support for SOC_BUS

Steffen Trumtrar (3):
ARM: zynq: Move clock_init from slcr to common
ARM: zynq: Hang iomapped slcr address on device_node
ARM: zynq: Make zynq_slcr_base static

 Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocm.txt |  17 +++++
 Documentation/devicetree/bindings/clock/zynq-7000.txt        |   4 +-
 arch/arm/boot/dts/zynq-7000.dtsi                             |  56 +++++++++------
 arch/arm/include/debug/zynq.S                                |   3 +
 arch/arm/mach-zynq/Kconfig                                   |   3 +
 arch/arm/mach-zynq/Makefile                                  |   2 +-
 arch/arm/mach-zynq/common.c                                  |  80 ++++++++++++++++++++-
 arch/arm/mach-zynq/common.h                                  |   4 +-
 arch/arm/mach-zynq/slcr.c                                    | 138 ++++++++++++++++++++++++++++++++----
 arch/arm/mach-zynq/zynq_ocm.c                                | 243 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/clk/zynq/clkc.c                                      |  89 ++++++++++++++++--------
 include/linux/clk/zynq.h                                     |   2 +-
 12 files changed, 570 insertions(+), 71 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/zynq/xlnx,zynq-ocm.txt
 create mode 100644 arch/arm/mach-zynq/zynq_ocm.c

Any update on this one?

Quoted 1 line

git://git-dev/group/ssw/linux-xlnx.git tags/zynq-cleanup-for-3.15

Quoted 1 line · Michal Simek

Any update on this one?

Hi,

Looks like it fell between chairs, but the bigger problem is the fetch URL:

Quoted 1 line

Quoted 1 line

git://git-dev/group/ssw/linux-xlnx.git tags/zynq-cleanup-for-3.15

Care to send a fresh pull request with a publicly accessible repo URL? :)

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch from the second pull request.
I have kept OCM patch in this branch because it depends on slcr changes done here. If you want to send another pull request just for this OCM patch based on this branch, please let me know.

Changes in v2: Fix incorrect git repo url

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.15

for you to fetch changes up to e9aa3e3a5bb2d64515648537100e5cf9b863e01a:

ARM: zynq: Add support for SOC_BUS (2014-02-20 16:08:47 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add OCM driver
- Add SOC_BUS support

----------------------------------------------------------------
Michal Simek (8):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Add OCM driver

Quoted 9 lines · Michal Simek

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch from the second pull request.
I have kept OCM patch in this branch because it depends on slcr changes done here. If you want to send another pull request just for this OCM patch based on this branch, please let me know.

Changes in v2: Fix incorrect git repo url

Thanks!

Quoted 20 lines

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.15

for you to fetch changes up to e9aa3e3a5bb2d64515648537100e5cf9b863e01a:

ARM: zynq: Add support for SOC_BUS (2014-02-20 16:08:47 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add OCM driver
- Add SOC_BUS support

Quoted 7 lines

----------------------------------------------------------------
Michal Simek (8):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Add OCM driver

Looking at the patches in the branch, this is the one I have most concern with. I think it will require more work to get it in shape to get merged, as per those comments.

I think it's worth to merge the other stuff though, so can you rebuild the branch without the OCM driver so we can get the rest in for 3.15 even if the OCM piece ends up taking longer?

Quoted 45 lines · Olof Johansson

Quoted 9 lines · Michal Simek

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch from the second pull request.
I have kept OCM patch in this branch because it depends on slcr changes done here. If you want to send another pull request just for this OCM patch based on this branch, please let me know.

Changes in v2: Fix incorrect git repo url

Thanks!

Quoted 20 lines

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.15

for you to fetch changes up to e9aa3e3a5bb2d64515648537100e5cf9b863e01a:

ARM: zynq: Add support for SOC_BUS (2014-02-20 16:08:47 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add OCM driver
- Add SOC_BUS support

Quoted 7 lines

----------------------------------------------------------------
Michal Simek (8):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Add OCM driver

Looking at the patches in the branch, this is the one I have most concern with. I think it will require more work to get it in shape to get merged, as per those comments.

Quoted 3 lines

I think it's worth to merge the other stuff though, so can you rebuild the branch without the OCM driver so we can get the rest in for 3.15 even if the OCM piece ends up taking longer?

No problem to do it. I will just wait one more day till we finish that discussions. Or is there any time pressure?

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch.
Based on my discussion with Olof I have removed zynq-ocm driver from this pull request and we will investigate different solution

Changes in v3: Remove OCM driver from pull request Changes in v2: Fix incorrect git repo url

Thanks,
Michal

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.15-v2

for you to fetch changes up to bffc3b8d2197f5e0622a6f0afb30bffeb326f942:

ARM: zynq: Add support for SOC_BUS (2014-03-17 15:13:25 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add SOC_BUS support

----------------------------------------------------------------
Michal Simek (7):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Move of_clk_init from clock driver
ARM: zynq: Add waituart implementation
ARM: zynq: Add support for SOC_BUS

Steffen Trumtrar (3):
ARM: zynq: Move clock_init from slcr to common
ARM: zynq: Hang iomapped slcr address on device_node
ARM: zynq: Make zynq_slcr_base static

 Documentation/devicetree/bindings/clock/zynq-7000.txt |   4 ++-
 arch/arm/boot/dts/zynq-7000.dtsi                      |  49 ++++++++++++++-------------
 arch/arm/include/debug/zynq.S                         |   3 ++
 arch/arm/mach-zynq/Kconfig                            |   2 ++
 arch/arm/mach-zynq/common.c                           |  80 ++++++++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-zynq/common.h                           |   3 +-
 arch/arm/mach-zynq/slcr.c                             | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 drivers/clk/zynq/clkc.c                               |  89 ++++++++++++++++++++++++++++++++++---------------
 include/linux/clk/zynq.h                              |   2 +-
 9 files changed, 285 insertions(+), 70 deletions(-)

Quoted 48 lines · Michal Simek

Hi,

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch.
Based on my discussion with Olof I have removed zynq-ocm driver from this pull request and we will investigate different solution

Changes in v3: Remove OCM driver from pull request Changes in v2: Fix incorrect git repo url

Thanks,
Michal

The following changes since commit 3795e91d2abb25164dda5687ca680a7ab940c447:

arm: dt: zynq: Add fclk-enable property to clkc node (2014-02-03 17:00:24 +0100)

are available in the git repository at:

git://git.xilinx.com/linux-xlnx.git tags/zynq-cleanup-for-3.15-v2

for you to fetch changes up to bffc3b8d2197f5e0622a6f0afb30bffeb326f942:

ARM: zynq: Add support for SOC_BUS (2014-03-17 15:13:25 +0100)

----------------------------------------------------------------
arm: Xilinx Zynq cleanup patches for v3.15

- Redesign SLCR initialization to enable
driver developing which targets SLCR space
- Add SOC_BUS support

----------------------------------------------------------------
Michal Simek (7):
ARM: zynq: Split slcr in two parts
ARM: zynq: Map I/O memory on clkc init
ARM: zynq: Add and use zynq_slcr_read/write() helper functions
ARM: zynq: Introduce zynq_slcr_unlock()
ARM: zynq: Move of_clk_init from clock driver
ARM: zynq: Add waituart implementation
ARM: zynq: Add support for SOC_BUS

Steffen Trumtrar (3):
ARM: zynq: Move clock_init from slcr to common
ARM: zynq: Hang iomapped slcr address on device_node
ARM: zynq: Make zynq_slcr_base static

Quoted 10 lines

 Documentation/devicetree/bindings/clock/zynq-7000.txt |   4 ++-
 arch/arm/boot/dts/zynq-7000.dtsi                      |  49 ++++++++++++++-------------
 arch/arm/include/debug/zynq.S                         |   3 ++
 arch/arm/mach-zynq/Kconfig                            |   2 ++
 arch/arm/mach-zynq/common.c                           |  80 ++++++++++++++++++++++++++++++++++++++++++--
 arch/arm/mach-zynq/common.h                           |   3 +-
 arch/arm/mach-zynq/slcr.c                             | 123 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------
 drivers/clk/zynq/clkc.c                               |  89 ++++++++++++++++++++++++++++++++++---------------
 include/linux/clk/zynq.h                              |   2 +-
 9 files changed, 285 insertions(+), 70 deletions(-)

We are getting closer and closer to 3.14 and haven't got any reply on this one.
Olof: Any update?

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch.
Based on my discussion with Olof I have removed zynq-ocm driver from this pull request and we will investigate different solution

Changes in v3: Remove OCM driver from pull request Changes in v2: Fix incorrect git repo url

Quoted 5 lines · Michal Simek

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch.
Based on my discussion with Olof I have removed zynq-ocm driver from this pull request and we will investigate different solution

Quoted 2 lines

Changes in v3: Remove OCM driver from pull request Changes in v2: Fix incorrect git repo url

I have pulled it into the next/cleanup2 branch now, sorry for the delay. Unfortunately I noticed one more thing I didn't like and did not pull the final patch of the branch, but only the other patches.

The problem I noticed is the soc-bus support: I noticed that you are populating the entire device tree under the soc node, including any top-level devices, and that the "xlnx,zynq-devcfg-1.00.a" node is part of that.

I think what you should try instead is to have only the amba bus and its children as part of the soc-bus, but other top-level devices (e.g. board clocks) outside of the soc node. Also, it would make sense to merge the devcfg stuff with the amba node, since it's really what makes up the soc. Does that make sense to you, or do you have reason to believe it won't work?

Quoted 6 lines · Arnd Bergmann

Quoted 5 lines · Michal Simek

please pull these changes to your arm-soc tree. This branch is based on zynq/dt branch.
Based on my discussion with Olof I have removed zynq-ocm driver from this pull request and we will investigate different solution

Quoted 6 lines

Quoted 2 lines

Changes in v3: Remove OCM driver from pull request Changes in v2: Fix incorrect git repo url

I have pulled it into the next/cleanup2 branch now, sorry for the delay. Unfortunately I noticed one more thing I didn't like and did not pull the final patch of the branch, but only the other patches.

ok. thanks for pulling.

Quoted 5 lines

The problem I noticed is the soc-bus support: I noticed that you are populating the entire device tree under the soc node, including any top-level devices, and that the "xlnx,zynq-devcfg-1.00.a" node is part of that.

Quoted 7 lines

I think what you should try instead is to have only the amba bus and its children as part of the soc-bus, but other top-level devices (e.g. board clocks) outside of the soc node. Also, it would make sense to merge the devcfg stuff with the amba node, since it's really what makes up the soc. Does that make sense to you, or do you have reason to believe it won't work?

No problem to postpone to the next release and discuss it more.

Currently all devices listed in dts/dtsi are all hard IPs inside PS silicon that's why I think they should be the part of SoC. (zynq-devcfg is also hard IP present all the time in SoC I will use different compatible string in the next version xlnx,zynq-devcfg-1.0).

For devices in PL is situation different because only axi-axi bridge is present in PS that's why I think that new bus type should be used. Also this bridge provides some resets which can be provided through this bus bridge driver.

Current code do this:

root at zynq:~# cat /sys/bus/soc/devices/soc0/revision 0x0
root at zynq:~# cat /sys/bus/soc/devices/soc0/soc_id 0x7
root at zynq:~# cat /sys/bus/soc/devices/soc0/family Xilinx Zynq
root at zynq:~# ls /sys/bus/soc/devices/soc0/

amba.0        f8891000.pmu  power         soc_id        uevent
amba.1        family        revision      subsystem

amba.0 is the bus present in zynq-7000.dtsi amba.1 is bus I have added myself just locally which is axi2axi bridge mentioned above.

All devices which will be in PL will be connected to this amba.1 bus.

Regarding clk driver in slcr node is not listed there.

root at zynq:~# ls /sys/bus/soc/devices/soc0/amba.0/f8000000.slcr/
driver/ modalias power/ subsystem/ uevent

Then we have also ACP (accelerator coherency port) which is the same case as axi2axi bridge. It means it is fixed hardware in SoC part and devices can be connect to it
(It looks like arm-cci bus type).

I know that others SoC are using soc {} node for adding soc IPs but that's not our case at least for now.

If you think that SOC bus should just contain SoC specific things then we can call of_platform_populate without SoC bus parent to ensure that these devices are not listed there.

Please correct me if something doesn't fit.

Thanks,
Michal

Quoted 5 lines

The problem I noticed is the soc-bus support: I noticed that you are populating the entire device tree under the soc node, including any top-level devices, and that the "xlnx,zynq-devcfg-1.00.a" node is part of that.

Quoted 7 lines

I think what you should try instead is to have only the amba bus and its children as part of the soc-bus, but other top-level devices (e.g. board clocks) outside of the soc node. Also, it would make sense to merge the devcfg stuff with the amba node, since it's really what makes up the soc. Does that make sense to you, or do you have reason to believe it won't work?

No problem to postpone to the next release and discuss it more.

Currently all devices listed in dts/dtsi are all hard IPs inside PS silicon that's why I think they should be the part of SoC. (zynq-devcfg is also hard IP present all the time in SoC I will use different compatible string in the next version xlnx,zynq-devcfg-1.0).

For devices in PL is situation different because only axi-axi bridge is present in PS that's why I think that new bus type should be used. Also this bridge provides some resets which can be provided through this bus bridge driver.

Current code do this:

root at zynq:~# cat /sys/bus/soc/devices/soc0/revision 0x0
root at zynq:~# cat /sys/bus/soc/devices/soc0/soc_id 0x7
root at zynq:~# cat /sys/bus/soc/devices/soc0/family Xilinx Zynq
root at zynq:~# ls /sys/bus/soc/devices/soc0/

amba.0        f8891000.pmu  power         soc_id        uevent
amba.1        family        revision      subsystem

amba.0 is the bus present in zynq-7000.dtsi amba.1 is bus I have added myself just locally which is axi2axi bridge mentioned above.

All devices which will be in PL will be connected to this amba.1 bus.

Regarding clk driver in slcr node is not listed there.

root at zynq:~# ls /sys/bus/soc/devices/soc0/amba.0/f8000000.slcr/
driver/ modalias power/ subsystem/ uevent

Then we have also ACP (accelerator coherency port) which is the same case as axi2axi bridge. It means it is fixed hardware in SoC part and devices can be connect to it
(It looks like arm-cci bus type).

I know that others SoC are using soc {} node for adding soc IPs but that's not our case at least for now.

If you think that SOC bus should just contain SoC specific things then we can call of_platform_populate without SoC bus parent to ensure that these devices are not listed there.

Please correct me if something doesn't fit.

Quoted 63 lines · Michal Simek

Quoted 5 lines

The problem I noticed is the soc-bus support: I noticed that you are populating the entire device tree under the soc node, including any top-level devices, and that the "xlnx,zynq-devcfg-1.00.a" node is part of that.

Quoted 7 lines

I think what you should try instead is to have only the amba bus and its children as part of the soc-bus, but other top-level devices (e.g. board clocks) outside of the soc node. Also, it would make sense to merge the devcfg stuff with the amba node, since it's really what makes up the soc. Does that make sense to you, or do you have reason to believe it won't work?

No problem to postpone to the next release and discuss it more.

Currently all devices listed in dts/dtsi are all hard IPs inside PS silicon that's why I think they should be the part of SoC. (zynq-devcfg is also hard IP present all the time in SoC I will use different compatible string in the next version xlnx,zynq-devcfg-1.0).

For devices in PL is situation different because only axi-axi bridge is present in PS that's why I think that new bus type should be used. Also this bridge provides some resets which can be provided through this bus bridge driver.

Current code do this:

root at zynq:~# cat /sys/bus/soc/devices/soc0/revision 0x0
root at zynq:~# cat /sys/bus/soc/devices/soc0/soc_id 0x7
root at zynq:~# cat /sys/bus/soc/devices/soc0/family Xilinx Zynq
root at zynq:~# ls /sys/bus/soc/devices/soc0/

amba.0        f8891000.pmu  power         soc_id        uevent
amba.1        family        revision      subsystem

amba.0 is the bus present in zynq-7000.dtsi amba.1 is bus I have added myself just locally which is axi2axi bridge mentioned above.

All devices which will be in PL will be connected to this amba.1 bus.

Regarding clk driver in slcr node is not listed there.

root at zynq:~# ls /sys/bus/soc/devices/soc0/amba.0/f8000000.slcr/
driver/ modalias power/ subsystem/ uevent

Then we have also ACP (accelerator coherency port) which is the same case as axi2axi bridge. It means it is fixed hardware in SoC part and devices can be connect to it
(It looks like arm-cci bus type).

I know that others SoC are using soc {} node for adding soc IPs but that's not our case at least for now.

If you think that SOC bus should just contain SoC specific things then we can call of_platform_populate without SoC bus parent to ensure that these devices are not listed there.

Quoted 1 line

Please correct me if something doesn't fit.

I don't have a strong opinion on things that are defined in FPGA logic, they could be below soc0, in a separate soc1 node or in some other top-level bus.

What I was mostly thinking of is board-level devices that are not part of the soc address hierarchy, such as external clocks or leds that just use GPIO lines.

Quoted 5 lines · Arnd Bergmann

On Thursday 27 March 2014, Michal Simek wrote:

What I was mostly thinking of is board-level devices that are not part of the soc address hierarchy, such as external clocks or leds that just use GPIO lines.

Then let's discuss this based on our zynq dtsi.
GIC, PL310, (OCM controller - we will discuss this later), UARTS, CADENCE GEM, ARASAN MMC, A9 global timer, TTC timer, SCUTIMER
- all of these are just the part of the soc address hierarchy and shouldn't be any problem with them to be under soc0 - all of them are in silicon.

DEVCFG - it is the part of first group - it is hard IP which can program programmable logic. Address is FIXED just wanted to list it separately.

I2C - I have just sent pull request for adding it there.
i2c childs/devices are added to the i2c node based on binding that's why this should be fine.

PMU - Currently I have it in root but maybe better location should be used.

SLCR - which is our system controller where everything is together.

There is just ps-clk-frequency which is user setup and come externally. The part of this is clock driver which is probably that problematic one but on the other hand it is targetting exact register addresses which are used by this driver to describe internal clk description.

I have looked at ux500 platform which has also SOC_BUS and based your thinking for example cpufreq-cooling, regulator-gpio shouldn't be there and probably more than this. Regarding clock description there is even not register range specified that's why it should be easily moved out of soc bus.

If you have any example how this should be done, please send it to me. I would like to have this in good shape.

From all I can tell, all the nodes you have today actually make sense being

Quoted 4 lines

There is just ps-clk-frequency which is user setup and come externally. The part of this is clock driver which is probably that problematic one but on the other hand it is targetting exact register addresses which are used by this driver to describe internal clk description.

If you just have a 'ps-clk-frequency' property, that should still keep the node inside of the SoC. If this had been modeled as a fixed-rate clock node as the clock parent of the xlnx,ps7-clkc node, that one should have been outside.

I don't think it's worth changing it now, just something to keep in mind.

Quoted 2 lines

If you have any example how this should be done, please send it to me. I would like to have this in good shape.

From all I can tell, all the nodes you have today actually make sense being part of the soc device hierarchy. The only problem is that there is no way to add nodes outside of it if that becomes necessary.

Generally speaking, the hierarchy should reflect the actual hardware layout, which usually has multiple levels of nested buses, starting with an AXI bus that contains the high-speed devices along with bridges to lower-speed buses. You probably have access to documentation that describes the real layout, so try to match that to the degree that you can, and move the pmu into whatever bus you need.

Then change the code to match the top-level bus node with the soc0 device.