[PATCH] ARM: dts: keystone: k2l: fix kernel crash when clk_ignore_unused is not in bootargs

[Murali Karicheri]

Currently kernel crash randomly when K2L EVM is booted without
clk_ignore_unused in the bootargs. This workaround is not needed
on other K2 devices such as K2HK and K2E and with this fix, we can
remove the workaround altogether. netcp driver on K2L uses linked
ram on OSR (On chip Static RAM) and requires the clock to this peripheral
enabled for proper functioning. This is the reason for the kernel crash.
So add the clock node to fix this issue.

While at it, remove the workaround documentation as well.

With the fix applied, clk_summary dump shows the clock to OSR enabled.

cat /sys/kernel/debug/clk/clk_summary
 --cut--
   tcp3d-1   00   39936  0 0
   tcp3d-0   00   39936  0 0
   osr   11   39936  0 0
   fftc-000   39936  0 0
 -cut
Signed-off-by: Murali Karicheri 
---
 Applies to Linux 4.4-rc2
 Documentation/arm/keystone/Overview.txt | 18 --
 arch/arm/boot/dts/k2l-netcp.dtsi|  2 +-
 2 files changed, 1 insertion(+), 19 deletions(-)

diff --git a/Documentation/arm/keystone/Overview.txt 
b/Documentation/arm/keystone/Overview.txt
index f17bc4c..400c0c2 100644
--- a/Documentation/arm/keystone/Overview.txt
+++ b/Documentation/arm/keystone/Overview.txt
@@ -49,24 +49,6 @@ specified through DTS. Following are the DTS used:-
 The device tree documentation for the keystone machines are located at
 Documentation/devicetree/bindings/arm/keystone/keystone.txt
 
-Known issues & workaround
--
-
-Some of the device drivers used on keystone are re-used from that from
-DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
-Some of the keystone specific drivers such as netcp uses run time power
-management API instead to enable clock. As this API has limitations on
-keystone, following workaround is needed to boot Linux.
-
-   Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
-   clock frameworks will try to disable clocks that are unused and disable
-   the hardware. This is because netcp related power domain and clock
-   domains are enabled in u-boot as run time power management API currently
-   doesn't enable clocks for netcp due to a limitation. This workaround is
-   expected to be removed in the future when proper API support becomes
-   available. Until then, this work around is needed.
-
-
 Document Author
 ---
 Murali Karicheri 
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 01aef23..5acbd0d 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -137,7 +137,7 @@ netcp: netcp@2600 {
/* NetCP address range */
ranges = <0 0x2600 0x100>;
 
-   clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
+   clocks = <&clkosr>, <&papllclk>, <&clkcpgmac>, <&chipclk12>;
dma-coherent;
 
ti,navigator-dmas = <&dma_gbe 0>,
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

Russell,

On 10/23/2015 02:52 PM, Kishon Vijay Abraham I wrote:

Hi,

On Friday 23 October 2015 08:16 PM, Russell King - ARM Linux wrote:

On Fri, Oct 23, 2015 at 11:17:06AM +0200, Arnd Bergmann wrote:

On Thursday 22 October 2015 15:27:05 Loc Ho wrote:


phy-xgene.c
---


---CUT---


Let me comment on this APM X-Gene driver. This driver is dead and
won't be supported in near or foreseeable future. And someday, it will
be ripped out. Based on experience, this solution (having PHY driver
in Linux) can't be supported across boards and etc as it is just too
much maintenance. And therefore, we followed Arnd B guidance and move
all this into the boot loader. From Linux or OS perspective, it only
cares about the interface in which its interface with. This is just
your reference and may be this will help you as well.


This depends a lot on the use case. If the chip is only used on server
parts that have a real firmware and you can deliver bug fixes for the
firmware if necessary, it's always best to do as much of the setup as
possible there, and let Linux see a simplified view of the hardware.

However, for embedded systems that tend to ship with a minimal binary
bootloader and no way to update that as an end-user, we rely on Linux
to know about all the hardware that requires some form of setup, which
is why we have all sorts of drivers and frameworks in the kernel that
a server can easily ignore.

While keystone can show up in servers that won't use this driver, my
impression is that its main market is actually in embedded space.


That's an interesting point of view - especially as you can't make the
argument that Marvell Armada chips would ever be anything but the
embedded space, but we're so far getting away with having the serdes
setup in u-boot - and even Marvell's BSP doesn't have it in the kernel.

The real question here is:

   Why would we want to statically setup serdes links in the kernel
   according to the DTB, rather than having the boot loader set them up?


Lot of PHYs have HW configure the parameters with default values so the
driver really doesn't have to touch them (like programming the equalizer
and the various digital mode configuration and analog mode
configuration). Then the SW just has to take care of clock programming
and powering on/off the PHY.

Some platforms require the controller core be in reset before powering
on the PHY, so we can't have all the configurations done in bootloader
for all the platforms.

The problem w.r.t code size starts when the drivers starts to configure
the analog and digital components inside the PHY (like equalizer,
attenuation etc..).



Agree. There are also calibration required on the receive side for 10G 
and SRIO that adds to the code size. SRIO is currently not supported, 
but expected to be supported in the future. For 10G, and SRIO, it is 
expected that user may need to tune the coefficients on a per board 
basis and hence we can't afford to have the driver in the boot loader.



While performing all these configurations in bootloader will help reduce
the code size, as Arnd pointed out, it'll cause problems if the PHY
loses the contents after a suspend/resume cycle.




Agree.


For the most part, the choice between the serdes modes is fairly static,
depending on the board wiring.  You wouldn't ever want to configure a
mini-PCIe socket for gigabit ethernet.

This is true for most of the serdes except 10G. 10G would require 
reconfiguration of the SerDes if it has to work in 1G mode. You wouldn't 
want to power cycle the board in case user wants to plug in a 1G link. 
We plan to add 10G support based on this serdes patch and also need to 
handle 1G mode on 10G as well in the future.


10G also has another mode to use a firmware that handles auto 
negotiation. User may use different firmware as well and has to be taken 
care of in the driver. How do we support this if this has to be in boot 
loader?



However, there are cases when you would want to change it, and I'm
aware of these cases:

* Serdes routed to a mini-PCIe socket, which is compatible with mSATA.
   There's an argument here to allow the serdes link to be switched at
   runtime between PCIe and mSATA.  However, the card type can't be
   detected at run time, so this would have to be a manual configuration
   change by the user.

   Since mini-PCIe is not hot-pluggable, this configuration isn't
   something that could be changed without powering the system down.

* Serdes routed to a SFP cage, where the serdes link is configured
   for gigabit (or faster for SFP+) ethernet.  For gigabit only, serdes
   is configured in either 1000base-X or Cisco SGMII mode (SGMII is a
   non-802.3 modification to 1000base-X) depending on the type of
   transceiver plugged in.

   Arguably, there's a third option here, which is SATA as well -  I'm
   aware of one non-standard SFP module on the market which provides a
   SATA connector, 

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

On 10/23/2015 05:17 AM, Arnd Bergmann wrote:

On Thursday 22 October 2015 15:27:05 Loc Ho wrote:


phy-xgene.c
---

Looking at other drivers under drivers/phy, I could find phy-xgene.c which
is close Keystone SerDes driver (. This is called APM X-Gene Multi-Purpose
PHY driver. It defines following mode per the driver code

 MODE_SATA   = 0,/* List them for simple reference */
 MODE_SGMII  = 1,
 MODE_PCIE   = 2,
 MODE_USB= 3,
 MODE_XFI= 4,

But seems to support only MODE_SATA. From the code, it appears, this driver
is expected to be enhanced in the future to support additional modes. I have
copied the author to this email to participate in this discussion.


Let me comment on this APM X-Gene driver. This driver is dead and
won't be supported in near or foreseeable future. And someday, it will
be ripped out. Based on experience, this solution (having PHY driver
in Linux) can't be supported across boards and etc as it is just too
much maintenance. And therefore, we followed Arnd B guidance and move
all this into the boot loader. From Linux or OS perspective, it only
cares about the interface in which its interface with. This is just
your reference and may be this will help you as well.


This depends a lot on the use case. If the chip is only used on server
parts that have a real firmware and you can deliver bug fixes for the
firmware if necessary, it's always best to do as much of the setup as
possible there, and let Linux see a simplified view of the hardware.

However, for embedded systems that tend to ship with a minimal binary
bootloader and no way to update that as an end-user, we rely on Linux
to know about all the hardware that requires some form of setup, which
is why we have all sorts of drivers and frameworks in the kernel that
a server can easily ignore.

While keystone can show up in servers that won't use this driver, my
impression is that its main market is actually in embedded space.
It is in embedded space predominantly. From our experience, this has to 
be a Linux driver and moving this to boot loader doesn't make sense.


Murali


    Arnd




--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

+ Alexandre Torgue  (Owner of phy-miphy28lp.c)
+ Loc Ho  (Owner of phy-miphy28lp.c)

On 10/22/2015 05:56 PM, Murali Karicheri wrote:

On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote:

On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote:

On 10/21/2015 08:56 AM, WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

Cut-


  Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
  drivers/pci/host/pci-keystone.c  |   24 +-
  drivers/pci/host/pci-keystone.h  |1 +
  drivers/phy/Kconfig  |8 +
  drivers/phy/Makefile |1 +
  drivers/phy/phy-keystone-serdes.c| 2366
++
  6 files changed, 2629 insertions(+), 10 deletions(-)
  create mode 100644 drivers/phy/phy-keystone-serdes.c


Kishon, Bjorn

Who will pick this up? Do we have time to get this in 4.4?


I've been avoiding this since my initial comments, but if you're wanting
to get it into v4.4, then I have to say something.

Russell,

I saw you have raised this point earlier against v1 of the patch series.
I have responded as below  (cut-n-pasted from that email)

"The serdes on K2 are re-used on multiple hardware blocks as already
indicated in this thread. It has got multiple lanes, each lane can be
enabled/disabled, shutdown etc. Isn't generic phy framework added to
support this type of hardware block? I see some enhancements needed for
K2 serdes to support monitoring the serdes link and providing a status
to the higher layer device. So I am not clear what different way you
would like to handle serdes drivers? Why do you need a new framework?
"

KISHON VIJAY had responded saying

"The PHY framework (in drivers/phy/) already provides a standard
interface to be used by the controller drivers no?"

But I have not seen your response to these questions from us. v2 and v3
has gone by and since all of the outstanding comments have been
addressed and you have not responded to our questions, I thought this
can be merged for 4.4. Good to see you have responded now :)


Again, there's other SoCs out there which have serdes.  Adding 2.5k of
lines for vendor serdes implementations does not scale - this needs to
be re-thought in a way which reduces the code maintanence burden.

Other SoCs like Marvell Armada have serdes links which can be configured
between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
lines to support their device too?  What happens when we have 10 of
these, and we have 25k lines of code here?

Again, this does not scale.  Please look at what can be done to reduce
the code size when other implementations come along.


Well, per our understanding, this driver is a Generic phy driver and we
have implemented a device driver based on Generic Phy API. This driver
is expected to support all of the 3 peripherals :- PCIe, 1G and 10G
Ethernet.  You have mentioned about Marvell & Armada . Did Marvell post
any patch already? Without seeing their code, how will we be able to
investigate what can be factored out to a generic serdes core driver? By
making this statement, I assume you are still considering using the
Generic Phy driver framework for SerDes drivers. Don't you?

I did a search in the phy folder and these are the top ones that came
out in terms of number of lines of code after Phy-core.c.

ls *.[ch] | xargs wc -l | sort -n

943 phy-core.c
   1279 phy-miphy28lp.c
   1735 phy-xgene.c
   2367 phy-keystone-serdes.c

So focusing on the top 3 drivers (including keystone serdes) under phy.

phy-xgene.c
---

Looking at other drivers under drivers/phy, I could find phy-xgene.c
which is close Keystone SerDes driver (. This is called APM X-Gene
Multi-Purpose PHY driver. It defines following mode per the driver code

 MODE_SATA   = 0,/* List them for simple reference */
 MODE_SGMII  = 1,
 MODE_PCIE   = 2,
 MODE_USB= 3,
 MODE_XFI= 4,

But seems to support only MODE_SATA. From the code, it appears, this
driver is expected to be enhanced in the future to support additional
modes. I have copied the author to this email to participate in this
discussion.

Keystone SerDes supports following modes

 KSERDES_PHY_SGMII,
 KSERDES_PHY_XGE,
 KSERDES_PHY_PCIE,
 KSERDES_PHY_HYPERLINK,
 KSERDES_PHY_SRI

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

On 10/22/2015 01:48 PM, Russell King - ARM Linux wrote:

On Thu, Oct 22, 2015 at 11:05:26AM -0400, Murali Karicheri wrote:

On 10/21/2015 08:56 AM, WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

Cut-


  Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
  drivers/pci/host/pci-keystone.c  |   24 +-
  drivers/pci/host/pci-keystone.h  |1 +
  drivers/phy/Kconfig  |8 +
  drivers/phy/Makefile |1 +
  drivers/phy/phy-keystone-serdes.c| 2366 ++
  6 files changed, 2629 insertions(+), 10 deletions(-)
  create mode 100644 drivers/phy/phy-keystone-serdes.c


Kishon, Bjorn

Who will pick this up? Do we have time to get this in 4.4?


I've been avoiding this since my initial comments, but if you're wanting
to get it into v4.4, then I have to say something.

Russell,

I saw you have raised this point earlier against v1 of the patch series. 
I have responded as below  (cut-n-pasted from that email)


"The serdes on K2 are re-used on multiple hardware blocks as already 
indicated in this thread. It has got multiple lanes, each lane can be 
enabled/disabled, shutdown etc. Isn't generic phy framework added to 
support this type of hardware block? I see some enhancements needed for 
K2 serdes to support monitoring the serdes link and providing a status 
to the higher layer device. So I am not clear what different way you 
would like to handle serdes drivers? Why do you need a new framework?

"

KISHON VIJAY had responded saying

"The PHY framework (in drivers/phy/) already provides a standard
interface to be used by the controller drivers no?"

But I have not seen your response to these questions from us. v2 and v3 
has gone by and since all of the outstanding comments have been 
addressed and you have not responded to our questions, I thought this 
can be merged for 4.4. Good to see you have responded now :)


Again, there's other SoCs out there which have serdes.  Adding 2.5k of
lines for vendor serdes implementations does not scale - this needs to
be re-thought in a way which reduces the code maintanence burden.

Other SoCs like Marvell Armada have serdes links which can be configured
between SATA, PCIe and Gbe.  Should Armada end up adding another 2.5k
lines to support their device too?  What happens when we have 10 of
these, and we have 25k lines of code here?

Again, this does not scale.  Please look at what can be done to reduce
the code size when other implementations come along.


Well, per our understanding, this driver is a Generic phy driver and we 
have implemented a device driver based on Generic Phy API. This driver 
is expected to support all of the 3 peripherals :- PCIe, 1G and 10G 
Ethernet.  You have mentioned about Marvell & Armada . Did Marvell post 
any patch already? Without seeing their code, how will we be able to 
investigate what can be factored out to a generic serdes core driver? By 
making this statement, I assume you are still considering using the 
Generic Phy driver framework for SerDes drivers. Don't you?


I did a search in the phy folder and these are the top ones that came 
out in terms of number of lines of code after Phy-core.c.


ls *.[ch] | xargs wc -l | sort -n

   943 phy-core.c
  1279 phy-miphy28lp.c
  1735 phy-xgene.c
  2367 phy-keystone-serdes.c

So focusing on the top 3 drivers (including keystone serdes) under phy.

phy-xgene.c
---

Looking at other drivers under drivers/phy, I could find phy-xgene.c 
which is close Keystone SerDes driver (. This is called APM X-Gene 
Multi-Purpose PHY driver. It defines following mode per the driver code


MODE_SATA   = 0,/* List them for simple reference */
MODE_SGMII  = 1,
MODE_PCIE   = 2,
MODE_USB= 3,
MODE_XFI= 4,

But seems to support only MODE_SATA. From the code, it appears, this 
driver is expected to be enhanced in the future to support additional 
modes. I have copied the author to this email to participate in this 
discussion.


Keystone SerDes supports following modes

KSERDES_PHY_SGMII,
KSERDES_PHY_XGE,
KSERDES_PHY_PCIE,
KSERDES_PHY_HYPERLINK,
KSERDES_PHY_SRIO

And phy-miphy28lp.c
-

+#define PHY_TYPE_SATA  1
+#define PHY_TYPE_PCIE

Re: [PATCH v3 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

On 10/21/2015 08:56 AM, WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch series provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

As an example of the using the SerDes driver, this patch series also
updates the Keystone PCIe host driver to enable and use its SerDes block.

References:
[1] KeyStone II Architecture Serializer/Deserializer (SerDes) User's Guide
 (http://www.ti.com/lit/ug/spruho3a/spruho3a.pdf)

v3:
- addresses the following review comments
1. https://lkml.org/lkml/2015/10/19/756
-- included sizes.h
2. https://lkml.org/lkml/2015/10/19/781
-- updated base on Fengguang Wu's suggestions.
3. https://lkml.org/lkml/2015/10/15/896
-- clarified here https://lkml.org/lkml/2015/10/20/512
-- nothing to do.

v2:
- addresses the following review comments on v1:
1. https://lkml.org/lkml/2015/10/15/896
-- this does not address the question:
   "The current code does not do this when compiled,
which might be a problem for distributors.
Can you clarify the license?"
-- the question is still under discussion here:
   https://lkml.org/lkml/2015/10/19/471
2. https://lkml.org/lkml/2015/10/15/895

v1:
- addresses the following review comments
1. https://lkml.org/lkml/2015/10/13/803
2. https://lkml.org/lkml/2015/10/14/613
3. https://lkml.org/lkml/2015/10/13/818

- An update to PCIe dts bindings to enable the PCIe SerDes is
  submitted in a separate patch.

WingMan Kwok (2):
   phy: keystone: serdes driver for gbe 10gbe and pcie
   PCI: keystone: update to use generic keystone serdes driver

  Documentation/devicetree/bindings/phy/ti-phy.txt |  239 +++
  drivers/pci/host/pci-keystone.c  |   24 +-
  drivers/pci/host/pci-keystone.h  |1 +
  drivers/phy/Kconfig  |8 +
  drivers/phy/Makefile |1 +
  drivers/phy/phy-keystone-serdes.c| 2366 ++
  6 files changed, 2629 insertions(+), 10 deletions(-)
  create mode 100644 drivers/phy/phy-keystone-serdes.c


Kishon, Bjorn

Who will pick this up? Do we have time to get this in 4.4?
--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Does dt property name in a binding always need a vendor prefix?

[Murali Karicheri]

Experts,

I am looking for guidelines to name a DT property in a bindings. Do we 
need to add a vendor specific prefix always or is it needed only 
specific cases? I know the intent here is to avoid name space collision. 
But by name space I assume, within a specific a device binding. For 
example where device driver has a core framework that also uses DT 
properties, any low level device driver using the framework needs to add 
a vendor specific prefix to avoid collision. Is my understanding 
correct? So standalone device drivers doesn't have to use prefix? Right?


--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Murali Karicheri]

On 10/20/2015 04:24 AM, Arnd Bergmann wrote:

On Monday 19 October 2015 14:50:57 Murali Karicheri wrote:

Arnd, by your statement 'I don't see any code that does this' do you
expect a piece of code that embed the license in the binary image? If
so, that seems weired to me.

Many of the drivers including this patch has the following statement in
the license that is additional company specific license such as BSD that
is applicable.

 Cut and pasted from drivers/crypto/fcrypt.c ===
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in the
   *documentation and/or other materials provided with the distribution.
=
I read this as if the source is compiled and distributed as a binary
either a kernel module ko file or as part of the kernel binary, this
term must apply. Usually this is part of documentation that goes with
the product AFAIK.


Sorry, my fault. This is indeed the standard BSD license, and
I misread this as having to produce the copyright statement
from the binary itself. Please ignore whatever I said on the
subject.

Arnd


Thanks Arnd for the clarification.

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Murali Karicheri]

On 10/19/2015 10:47 AM, Kwok, WingMan wrote:

Hi,


-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: Thursday, October 15, 2015 3:35 PM
To: Karicheri, Muralidharan
Cc: linux-arm-ker...@lists.infradead.org; Kwok, WingMan; robh...@kernel.org;
pawel.m...@arm.com; mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
ga...@codeaurora.org; KISHON VIJAY ABRAHAM; Quadros, Roger;
bhelg...@google.com; ssant...@kernel.org; li...@arm.linux.org.uk;
devicetree@vger.kernel.org; linux-ker...@vger.kernel.org; linux-
p...@vger.kernel.org
Subject: Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and
pcie

On Thursday 15 October 2015 12:01:04 Murali Karicheri wrote:



+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.


The current code does not do this when compiled, which might be a
problem for distributors. Can you clarify the license?


Arnd,

Can you elaborate on this? I did a grep on the string "Redistributions
in binary form must reproduce the above copyright" and I could find
several instance of this. So I am not sure what you mean by "The current
code does not do this when compiled".


You write that the binary form of the code must produce the copyright
notice. I don't see any code that does this. If I was looking in the
wrong place, let me know.

Arnd




Thanks Wingman for the response.

Arnd, by your statement 'I don't see any code that does this' do you 
expect a piece of code that embed the license in the binary image? If 
so, that seems weired to me.


Many of the drivers including this patch has the following statement in 
the license that is additional company specific license such as BSD that 
is applicable.


 Cut and pasted from drivers/crypto/fcrypt.c ===
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
=
I read this as if the source is compiled and distributed as a binary 
either a kernel module ko file or as part of the kernel binary, this 
term must apply. Usually this is part of documentation that goes with 
the product AFAIK.


Murali


For example, we did a grep of the following

mypc:linux(personal/linux/serdes) $ grep -rnI "Redistributions in binary form must 
reproduce the above copyright" ./net/
./net/sunrpc/auth_gss/auth_gss.c:18: *  2. Redistributions in binary form must 
reproduce the above copyright
./net/sunrpc/auth_gss/gss_mech_switch.c:15: *  2. Redistributions in binary 
form must reproduce the above copyright
./net/sunrpc/auth_gss/gss_krb5_mech.c:16: *  2. Redistributions in binary form 
must reproduce the above copyright
./net/bluetooth/ecc.c:10: *  * Redistributions in binary form must reproduce 
the above copyright
./net/bluetooth/ecc.h:10: *  * Redistributions in binary form must reproduce 
the above copyright
./net/can/gw.c:12: * 2. Redistributions in binary form must reproduce the above 
copyright
./net/can/af_can.c:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/can/proc.c:12: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/can/bcm.c:12: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/can/raw.c:12: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/can/af_can.h:10: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/discover.c:13: * 2. Redistributions in binary form must reproduce 
the above copyright
./net/tipc/node.h:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/netlink_compat.c:10: * 2. Redistributions in binary form must 
reproduce the above copyright
./net/tipc/name_distr.h:13: * 2. Redistributions in binary form must reproduce 
the above copyright
./net/tipc/bearer.c:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/name_table.h:13: * 2. Redistributions in binary form must reproduce 
the above copyright
./net/tipc/name_distr.c:13: * 2. Redistributions in binary form must reproduce 
the above copyright
./net/tipc/addr.c:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/subscr.h:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/link.h:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/net.h:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/netlink.c:13: * 2. Redistributions in binary form must reproduce the 
above copyright
./net/tipc/sysctl.c:12: * 2. Redistributions in bin

Re: [PATCH v1 0/2] Common SerDes driver for TI's Keystone Platforms

[Murali Karicheri]

On 10/16/2015 04:02 AM, Russell King - ARM Linux wrote:

On Thu, Oct 15, 2015 at 08:00:41PM -0500, Rob Herring wrote:

On Thu, Oct 15, 2015 at 11:51 AM, Russell King - ARM Linux
 wrote:

On Thu, Oct 15, 2015 at 10:25:43AM -0400, WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethether switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.


Given that serdes is not specific to TI, should this be specific to
TI, or should there be an effort to come up with something which
everyone who has serdes links can make use of?


Russell,

The serdes on K2 are re-used on multiple hardware blocks as already 
indicated in this thread. It has got multiple lanes, each lane can be 
enabled/disabled, shutdown etc. Isn't generic phy framework added to 
support this type of hardware block? I see some enhancements needed for 
K2 serdes to support monitoring the serdes link and providing a status 
to the higher layer device. So I am not clear what different way you 
would like to handle serdes drivers? Why do you need a new framework?


Murali

Serdes comes in multiple different forms: PCIe, 1G SGMII ethernet,
1000base-X ethernet, 10g ethernet, SATA... I'd hate to see a
plethora of SoC specific stuff for this.


The licensed IP I've seen doesn't provide a standard register
interface, but just signals to the IP block. Same with PLL IP. So
we'll probably get to see vendors continue to differentiate on PHY
register design. :)


So what?  Network drivers differ radically in register design, yet we
still have a standardised interface to network drivers.




--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/15/2015 12:21 PM, santosh shilimkar wrote:

On 10/15/2015 9:02 AM, Murali Karicheri wrote:

On 10/14/2015 11:41 AM, santosh shilimkar wrote:

10/14/2015 7:17 AM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs.
Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware
and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot
log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you
please
apply this series to v4.4 next please at your earliest opportunity.


I have picked up the series. Thanks for quick turnaround.


Thanks Santosh. Could you send this pull request for v4.4 next. We want
this merged to our internal release and if this is on next branch it
will help.


It should be already in linux-next and pull request was sent before I
replied yesterday. Its late for the merge window with usual norms
so lets see if it makes it.

Santosh,

I see both driver and DTS. Thanks once again for your support

Regards,

Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 0/3]

[Murali Karicheri]

On 10/14/2015 11:41 AM, santosh shilimkar wrote:

10/14/2015 7:17 AM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs.
Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware
and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot
log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you
please
apply this series to v4.4 next please at your earliest opportunity.


I have picked up the series. Thanks for quick turnaround.


Thanks Santosh. Could you send this pull request for v4.4 next. We want 
this merged to our internal release and if this is on next branch it 
will help.


Thanks

Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] phy: keystone: serdes driver for gbe 10gbe and pcie

[Murali Karicheri]

On 10/15/2015 10:51 AM, Arnd Bergmann wrote:

On Thursday 15 October 2015 10:25:44 WingMan Kwok wrote:

On TI's Keystone platforms, several peripherals such as the
gbe ethernet switch, 10gbe ethernet switch and PCIe controller
require the use of a SerDes for converting SoC parallel data into
serialized data that can be output over a high-speed electrical
interface, and also converting high-speed serial input data
into parallel data that can be processed by the SoC.  The
SerDeses used by those peripherals, though they may be different,
are largely similar in functionality and setup.

This patch provides a SerDes phy driver implementation that can be
used by the above mentioned peripheral drivers to configure their
respective SerDeses.

v1:


cut-


+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the
+ * distribution.


The current code does not do this when compiled, which might be a
problem for distributors. Can you clarify the license?


Arnd,

Can you elaborate on this? I did a grep on the string "Redistributions 
in binary form must reproduce the above copyright" and I could find 
several instance of this. So I am not sure what you mean by "The current 
code does not do this when compiled".


Thanks
--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 0/3]

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v3. Maintainer, could you please
apply this series to v4.4 next please at your earliest opportunity.

Change Log
==
v4
- collected Acked-by from Arnd Bergmann against 1/3
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series per Santosh. Will send the same
  as a separate patch
v2
- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

- Additionally added accumulator queue support optional so that lack
  of firmware in the file system will not cause other queue types not
  available due to driver probe failure.

Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt   | 56 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  3 +-
 drivers/soc/ti/knav_qmss_acc.c | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c   | 67 ++
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/3] soc: ti: add firmware file name as part of the driver

[Murali Karicheri]

Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.

Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.

Signed-off-by: Murali Karicheri 
Acked-by: Arnd Bergmann 
---
 v4: no change from v3
 Documentation/arm/keystone/knav-qmss.txt   | 26 
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  1 -
 drivers/soc/ti/knav_qmss_queue.c   | 47 +-
 4 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
 knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
 allocate descriptor pools, map the descriptors, push/pop to queues etc. For
 details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to 
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem*intd;
u32 __iomem *iram;
-   const char  *firmware;
u32 id;
struct list_headlist;
 };
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
 idx < (kdev)->num_queues_in_use;   \
 idx++, inst = knav_queue_idx_to_inst(kdev, idx))
 
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
 /**
  * knav_queue_noti

[PATCH v4 1/3] Documentation: dt: soc: Add description for knav qmss driver

[Murali Karicheri]

Add a documentation for knav qmss driver.

Signed-off-by: Murali Karicheri 
---
 v4: added Arnd's Acked-by

 Documentation/arm/keystone/knav-qmss.txt | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 3/3] soc: ti: qmss: make acc queue support optional in the driver

[Murali Karicheri]

acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.

Signed-off-by: Murali Karicheri 
---
 v4: no change from v3
 Documentation/arm/keystone/knav-qmss.txt |  6 ++
 drivers/soc/ti/knav_qmss.h   |  2 ++
 drivers/soc/ti/knav_qmss_acc.c   | 10 --
 drivers/soc/ti/knav_qmss_queue.c | 20 +++-
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
  "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
 
 in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_headlist;
+   boolloaded;
+   boolstarted;
 };
 
 struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
  * Return 0 on success or error
  */
 int knav_init_acc_range(struct knav_device *kdev,
-   struct device_node *node,
-   struct knav_range_info *range)
+   struct device_node *node,
+   struct knav_range_info *range)
 {
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
 
+   if (!pdsp->started) {
+   dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+   info->pdsp_id, range->name);
+   return -ENODEV;
+   }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+   pdsp->loaded = false;
+   pdsp->started = false;
return 0;
 }
 
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device 
*kdev)
int ret;
 
knav_queue_stop_pdsps(kdev);
-   /* now load them all */
+   /* now load them all. We return success even if pdsp
+* is not loaded as acc channels are optional on having
+* firmware availability in the system. We set the loaded
+* and stated flag and when initialize the acc range, check
+* it and init the range only if pdsp is started.
+*/
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
-   if (ret < 0)
-   return ret;
+   if (!ret)
+   pdsp->loaded = true;
}
 
for_each_pdsp(kdev, pdsp) {
-   ret = knav_queue_start_pdsp(kdev, pdsp);
-   WARN_ON(ret);
+   if (pdsp->loaded) {
+   ret = knav_queue_start_pdsp(kdev, pdsp);
+   if (!ret)
+   pdsp->started = true;
+   }
}
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] ARM: dts: keystone: enable accumulator channels

[Murali Karicheri]

Add low priority accumulator channel that can monitor multiple QMSS
queues. User for example could use the accumular queue for Netcp
Rx completion. While at it, also add an extra line end of each top
level node in DTS to make it more readable.

Signed-off-by: Murali Karicheri 
---
 - dependent on [PATCH v3} soc: ti: knav_qmss: enable accumulator queue
   support. Maintainer, please send this to v4.4 next after the above is
   merged.
 arch/arm/boot/dts/k2e-netcp.dtsi  | 23 +++
 arch/arm/boot/dts/k2hk-netcp.dtsi | 24 
 arch/arm/boot/dts/k2l-netcp.dtsi  | 23 +++
 3 files changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
index b13b3c9..ac990f6 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -72,7 +72,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +93,19 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2hk-netcp.dtsi 
b/arch/arm/boot/dts/k2hk-netcp.dtsi
index 77a32c3..f86d6dd 100644
--- a/arch/arm/boot/dts/k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/k2hk-netcp.dtsi
@@ -47,6 +47,7 @@ qmss: qmss@2a4 {
"region", "push", "pop";
};
};
+
queue-pools {
qpend {
qpend-0 {
@@ -88,7 +89,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -99,6 +110,19 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 6b95284..01aef23 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -72,7 +72,16 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +92,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = 

[PATCH v3 2/3] soc: ti: add firmware file name as part of the driver

[Murali Karicheri]

Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.

Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.

Signed-off-by: Murali Karicheri 
Acked-by: Arnd Bergmann 
---
 v3: added Acked-by from Arnd Bergmann

 Documentation/arm/keystone/knav-qmss.txt   | 26 
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  1 -
 drivers/soc/ti/knav_qmss_queue.c   | 47 +-
 4 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
 knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
 allocate descriptor pools, map the descriptors, push/pop to queues etc. For
 details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to 
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..d1ce21a 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,6 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem*intd;
u32 __iomem *iram;
-   const char  *firmware;
u32 id;
struct list_headlist;
 };
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
 idx < (kdev)->num_queues_in_use;   \
 idx++, inst = knav_queue_idx_to_inst(kdev, idx))
 
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
 /**
 

[PATCH v3 3/3] soc: ti: qmss: make acc queue support optional in the driver

[Murali Karicheri]

acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.

Signed-off-by: Murali Karicheri 
---
 v3: no change from v2
 v2: new patch
 Documentation/arm/keystone/knav-qmss.txt |  6 ++
 drivers/soc/ti/knav_qmss.h   |  2 ++
 drivers/soc/ti/knav_qmss_acc.c   | 10 --
 drivers/soc/ti/knav_qmss_queue.c | 20 +++-
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
  "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
 
 in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_headlist;
+   boolloaded;
+   boolstarted;
 };
 
 struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
  * Return 0 on success or error
  */
 int knav_init_acc_range(struct knav_device *kdev,
-   struct device_node *node,
-   struct knav_range_info *range)
+   struct device_node *node,
+   struct knav_range_info *range)
 {
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
 
+   if (!pdsp->started) {
+   dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+   info->pdsp_id, range->name);
+   return -ENODEV;
+   }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+   pdsp->loaded = false;
+   pdsp->started = false;
return 0;
 }
 
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device 
*kdev)
int ret;
 
knav_queue_stop_pdsps(kdev);
-   /* now load them all */
+   /* now load them all. We return success even if pdsp
+* is not loaded as acc channels are optional on having
+* firmware availability in the system. We set the loaded
+* and stated flag and when initialize the acc range, check
+* it and init the range only if pdsp is started.
+*/
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
-   if (ret < 0)
-   return ret;
+   if (!ret)
+   pdsp->loaded = true;
}
 
for_each_pdsp(kdev, pdsp) {
-   ret = knav_queue_start_pdsp(kdev, pdsp);
-   WARN_ON(ret);
+   if (pdsp->loaded) {
+   ret = knav_queue_start_pdsp(kdev, pdsp);
+   if (!ret)
+   pdsp->started = true;
+   }
}
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/3] Documentation: dt: soc: Add description for knav qmss driver

[Murali Karicheri]

Add documentation for knav qmss driver.

Signed-off-by: Murali Karicheri 
---
 v3: not removed description from DT document
 Documentation/arm/keystone/knav-qmss.txt | 24 
 1 file changed, 24 insertions(+)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 0/3] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against v2. Maintainer, could you please
apply this series to v4.4 next please.

Change Log
==
v3
- Added Arnd's Acked-by against 2/4
- 1/4 modified not to touch the DT documentation per Rob's comment.
- Removed DTS update from the series. Will send the same as a separate
  patch
v2
- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

Additionally added accumulator queue support optional so that lack of
firmware in the file system will not cause other queue types not available
due to driver probe failure.


Murali Karicheri (3):
  Documentation: dt: soc: Add description for knav qmss driver
  soc: ti: add firmware file name as part of the driver
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt   | 56 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  3 +-
 drivers/soc/ti/knav_qmss_acc.c | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c   | 67 ++
 5 files changed, 109 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/3] ARM: keystone: dts: add PCI serdes driver bindings

[Murali Karicheri]

On 10/13/2015 02:04 PM, WingMan Kwok wrote:

Signed-off-by: WingMan Kwok 
---
  arch/arm/boot/dts/k2e.dtsi  |   24 
  arch/arm/boot/dts/keystone.dtsi |   25 +
  2 files changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 675fb8e..1ba47d8 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -86,6 +86,18 @@
gpio,syscon-dev = <&devctrl 0x240>;
};

+   pcie1_phy: pciephy@2326000 {
+   #phy-cells = <0>;
+   compatible = "ti,keystone-serdes-pcie";
+   reg = <0x02326000 0x4000>;
+   reg-names = "reg_serdes";
+   refclk-khz = <10>;
+   link-rate-kbps = <500>;
+   phy-type = "pcie";
+   max-lanes = <2>;
+   status = "disabled";
+   };
+
pcie1: pcie@2102 {
compatible = "ti,keystone-pcie","snps,dw-pcie";
clocks = <&clkpcie1>;
@@ -130,6 +142,18 @@
,
;
};
+
+   /* PCIE phy */
+   serdeses {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   serdes@0 {
+   reg = <0>;
+   phys = <&pcie1_phy>;
+   status = "disabled";
+   };
+   };
+
};

mdio: mdio@24200f00 {
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 72816d6..5312319 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -275,6 +275,19 @@
ti,syscon-dev = <&devctrl 0x2a0>;
};

+   pcie0_phy: pciephy@232 {
+   #phy-cells = <0>;
+   compatible = "ti,keystone-serdes-pcie";
+   reg = <0x0232 0x4000>;
+   reg-names = "reg_serdes";
+   refclk-khz = <10>;
+   link-rate-kbps = <500>;
+   init-firmware   = "k2_pcie_serdes_init.fw";
+   phy-type = "pcie";
+   max-lanes = <2>;
+   status = "disabled";
+   };
+
pcie0: pcie@2180 {
compatible = "ti,keystone-pcie", "snps,dw-pcie";
clocks = <&clkpcie>;
@@ -319,6 +332,18 @@
,
;
};
+
+   /* PCIE phy */
+   serdeses {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   serdes@0 {
+   reg = <0>;
+   phys = <&pcie0_phy>;
+   status = "disabled";
+   };
+   };
+
};
};
  };


Wingman,

This should be a separate patch and remove the sane from Driver patch. 
i.e. send 1/3 ane 2/3 in one series and 3/3 as a separate patch.


Thanks

Murali

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Documentation: dt: soc: move driver description to a separate document

[Murali Karicheri]

On 10/13/2015 02:01 PM, Rob Herring wrote:

On Tue, Oct 13, 2015 at 12:28 PM, Murali Karicheri  wrote:

On 10/13/2015 10:42 AM, Rob Herring wrote:


On Mon, Oct 12, 2015 at 2:46 PM, Murali Karicheri 
wrote:


Currently the DT bindings have details about the driver as well. This
patch moves this to a separate document for knav qmss driver so that
driver detail update can be done as needed without polluting the DT
bindings description.

Signed-off-by: Murali Karicheri 
---
   Documentation/arm/keystone/knav-qmss.txt   | 24
++
   .../bindings/soc/ti/keystone-navigator-qmss.txt| 20
--
   2 files changed, 28 insertions(+), 16 deletions(-)
   create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data
structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for
accelerating
+management of the packet queues. Packets are queued/de-queued by writing
or
+reading descriptor address to a particular memory mapped location. The
PDSPs
+perform QMSS related functions like accumulation, QoS, or event
management.
+Linking RAM registers are used to link the descriptors which are stored
in
+descriptor RAM. Descriptor RAM is configurable as internal or external
memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss
queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc.
For
+details of the available APIs, please refers to
include/linux/soc/ti/knav_qmss.h
diff --git
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..2cecea1 100644
---
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -1,20 +1,8 @@
-* Texas Instruments Keystone Navigator Queue Management SubSystem driver
-
-The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
-the main hardware sub system which forms the backbone of the Keystone
-multi-core Navigator. QMSS consist of queue managers, packed-data
structure
-processors(PDSP), linking RAM, descriptor pools and infrastructure
-Packet DMA.
-The Queue Manager is a hardware module that is responsible for
accelerating
-management of the packet queues. Packets are queued/de-queued by writing
or
-reading descriptor address to a particular memory mapped location. The
PDSPs
-perform QMSS related functions like accumulation, QoS, or event
management.
-Linking RAM registers are used to link the descriptors which are stored
in
-descriptor RAM. Descriptor RAM is configurable as internal or external
memory.
-The QMSS driver manages the PDSP setups, linking RAM regions,
-queue pool management (allocation, push, pop and notify) and descriptor
-pool management.



Only the last sentence seems to be about the driver and is rather
obvious (a driver manages the h/w). I would leave all this as-is
currently.

Rob


Rob,

I am taking the liberty to add your Ack based on the above. I can remove it
if you disagree.


No, I don't. I don't agree with moving this out of the binding. This
mostly sounds like a description of the h/w to me, so I'd like to keep
it. Most bindings are rather vague in this regard and I'd rather see
more description than less.


Rob,

Sorry, I got you wrong. I will undo the DT documentation change and add 
the update for firmware to driver document.



I also agree with Arnd's comment about not pointing to kernel docs.


Which comment are you talking about? I can't see his comment though 
against 1/4. I see he has acked 2/4. Can you clarify?


Do you have objections against the reference to driver documentation 
from DT Doc? Not sure why there should be any issue with the reference. 
But if you insists, I will remove below reference from the patch.


+For details of the driver, please refer to
+Documentation/arm/keystone/knav-qmss.txt

So here is the summary of what I will do.
1) Don't remove the driver description from DT document
2) remove the reference to driver document as per 1) this becomes redundant.
3) I will keep the driver d

Re: [PATCH 1/4] Documentation: dt: soc: move driver description to a separate document

[Murali Karicheri]

On 10/13/2015 10:42 AM, Rob Herring wrote:

On Mon, Oct 12, 2015 at 2:46 PM, Murali Karicheri  wrote:

Currently the DT bindings have details about the driver as well. This
patch moves this to a separate document for knav qmss driver so that
driver detail update can be done as needed without polluting the DT
bindings description.

Signed-off-by: Murali Karicheri 
---
  Documentation/arm/keystone/knav-qmss.txt   | 24 ++
  .../bindings/soc/ti/keystone-navigator-qmss.txt| 20 --
  2 files changed, 28 insertions(+), 16 deletions(-)
  create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..2cecea1 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -1,20 +1,8 @@
-* Texas Instruments Keystone Navigator Queue Management SubSystem driver
-
-The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
-the main hardware sub system which forms the backbone of the Keystone
-multi-core Navigator. QMSS consist of queue managers, packed-data structure
-processors(PDSP), linking RAM, descriptor pools and infrastructure
-Packet DMA.
-The Queue Manager is a hardware module that is responsible for accelerating
-management of the packet queues. Packets are queued/de-queued by writing or
-reading descriptor address to a particular memory mapped location. The PDSPs
-perform QMSS related functions like accumulation, QoS, or event management.
-Linking RAM registers are used to link the descriptors which are stored in
-descriptor RAM. Descriptor RAM is configurable as internal or external memory.
-The QMSS driver manages the PDSP setups, linking RAM regions,
-queue pool management (allocation, push, pop and notify) and descriptor
-pool management.


Only the last sentence seems to be about the driver and is rather
obvious (a driver manages the h/w). I would leave all this as-is
currently.

Rob


Rob,

I am taking the liberty to add your Ack based on the above. I can remove 
it if you disagree.


Murali


+* Texas Instruments Keystone Navigator (knav) Queue Management SubSystem driver
+  DT bindings

+For details of the driver, please refer to
+Documentation/arm/keystone/knav-qmss.txt

  Required properties:
  - compatible   : Must be "ti,keystone-navigator-qmss";
--
1.9.1







--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

On 10/13/2015 12:21 PM, santosh shilimkar wrote:

On 10/13/2015 9:14 AM, Murali Karicheri wrote:

Santosh,

On 10/13/2015 12:01 PM, santosh shilimkar wrote:

On 10/13/2015 6:56 AM, Murali Karicheri wrote:

On 10/12/2015 03:46 PM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs.



Santosh, Arnd,

Could you please review and let me know if there is any comment. If
looks good, could you please merge to v4.4 next branch?


Please report the series updating the comments from Arnd. Also split
the series into drivers and dts updates.

s/report/repost



The cover letter already summarize this as a comment against v1 even
though it didn't mention Arnd's name. Is it usual to describe the
reviewers name in the change log? I thought we just describe the comment
addressed, not who has commented. Not??


I didn't mean report. sorry. Just repost the series including ack tag.


About splitting the series, it was done so since both is being pulled by
you. If needed, I can do the split. Let me know.


DTS and driver changes goes to different topics so split it, please.

Ok. No issues. I will be posting this right away.

Murali


Regards,
Santosh




--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

Santosh,

On 10/13/2015 12:01 PM, santosh shilimkar wrote:

On 10/13/2015 6:56 AM, Murali Karicheri wrote:

On 10/12/2015 03:46 PM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs.



Santosh, Arnd,

Could you please review and let me know if there is any comment. If
looks good, could you please merge to v4.4 next branch?


Please report the series updating the comments from Arnd. Also split
the series into drivers and dts updates.


The cover letter already summarize this as a comment against v1 even 
though it didn't mention Arnd's name. Is it usual to describe the 
reviewers name in the change log? I thought we just describe the comment 
addressed, not who has commented. Not??


About splitting the series, it was done so since both is being pulled by 
you. If needed, I can do the split. Let me know.


Murali



Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] Documentation: dt: soc: move driver description to a separate document

[Murali Karicheri]

On 10/13/2015 10:42 AM, Rob Herring wrote:

On Mon, Oct 12, 2015 at 2:46 PM, Murali Karicheri  wrote:

Currently the DT bindings have details about the driver as well. This
patch moves this to a separate document for knav qmss driver so that
driver detail update can be done as needed without polluting the DT
bindings description.

Signed-off-by: Murali Karicheri 
---
  Documentation/arm/keystone/knav-qmss.txt   | 24 ++
  .../bindings/soc/ti/keystone-navigator-qmss.txt| 20 --
  2 files changed, 28 insertions(+), 16 deletions(-)
  create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..2cecea1 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -1,20 +1,8 @@
-* Texas Instruments Keystone Navigator Queue Management SubSystem driver
-
-The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
-the main hardware sub system which forms the backbone of the Keystone
-multi-core Navigator. QMSS consist of queue managers, packed-data structure
-processors(PDSP), linking RAM, descriptor pools and infrastructure
-Packet DMA.
-The Queue Manager is a hardware module that is responsible for accelerating
-management of the packet queues. Packets are queued/de-queued by writing or
-reading descriptor address to a particular memory mapped location. The PDSPs
-perform QMSS related functions like accumulation, QoS, or event management.
-Linking RAM registers are used to link the descriptors which are stored in
-descriptor RAM. Descriptor RAM is configurable as internal or external memory.
-The QMSS driver manages the PDSP setups, linking RAM regions,
-queue pool management (allocation, push, pop and notify) and descriptor
-pool management.


Only the last sentence seems to be about the driver and is rather
obvious (a driver manages the h/w). I would leave all this as-is
currently.

Rob


Rob,

I promise I will fix this in my next opportunity. Also there is similar 
clean up needed for knav dma DT documentation and Netcp documentations. 
It is in my TODO list.


Thanks.

Murali

+* Texas Instruments Keystone Navigator (knav) Queue Management SubSystem driver
+  DT bindings

+For details of the driver, please refer to
+Documentation/arm/keystone/knav-qmss.txt

  Required properties:
  - compatible   : Must be "ti,keystone-navigator-qmss";
--
1.9.1







--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

On 10/12/2015 03:46 PM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against above patch set. Key issues
addressed.

- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

Additionally added accumulator queue support optional so that lack of
firmware in the file system will not cause other queue types not available
due to driver probe failure.

Murali Karicheri (4):
   Documentation: dt: soc: move driver description to a separate document
   soc: ti: add firmware file name as part of the driver
   ARM: dts: keystone: enable accumulator channels
   soc: ti: qmss: make acc queue support optional in the driver

  Documentation/arm/keystone/knav-qmss.txt   | 56 ++
  .../bindings/soc/ti/keystone-navigator-qmss.txt| 21 ++-
  arch/arm/boot/dts/k2e-netcp.dtsi   | 23 
  arch/arm/boot/dts/k2hk-netcp.dtsi  | 24 
  arch/arm/boot/dts/k2l-netcp.dtsi   | 23 
  drivers/soc/ti/knav_qmss.h |  3 +-
  drivers/soc/ti/knav_qmss_acc.c | 10 +++-
  drivers/soc/ti/knav_qmss_queue.c   | 67 ++
  8 files changed, 183 insertions(+), 44 deletions(-)
  create mode 100644 Documentation/arm/keystone/knav-qmss.txt


Santosh, Arnd,

Could you please review and let me know if there is any comment. If 
looks good, could you please merge to v4.4 next branch?


Murali
--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Resend: PATCH v2 1/4] Documentation: dt: soc: move driver description to a separate document

[Murali Karicheri]

Currently the DT bindings have details about the driver as well. This
patch moves this to a separate document for knav qmss driver so that
driver detail update can be done as needed without polluting the DT
bindings description.

Signed-off-by: Murali Karicheri 
---
 Documentation/arm/keystone/knav-qmss.txt   | 24 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt| 20 --
 2 files changed, 28 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..2cecea1 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -1,20 +1,8 @@
-* Texas Instruments Keystone Navigator Queue Management SubSystem driver
-
-The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
-the main hardware sub system which forms the backbone of the Keystone
-multi-core Navigator. QMSS consist of queue managers, packed-data structure
-processors(PDSP), linking RAM, descriptor pools and infrastructure
-Packet DMA.
-The Queue Manager is a hardware module that is responsible for accelerating
-management of the packet queues. Packets are queued/de-queued by writing or
-reading descriptor address to a particular memory mapped location. The PDSPs
-perform QMSS related functions like accumulation, QoS, or event management.
-Linking RAM registers are used to link the descriptors which are stored in
-descriptor RAM. Descriptor RAM is configurable as internal or external memory.
-The QMSS driver manages the PDSP setups, linking RAM regions,
-queue pool management (allocation, push, pop and notify) and descriptor
-pool management.
+* Texas Instruments Keystone Navigator (knav) Queue Management SubSystem driver
+  DT bindings
 
+For details of the driver, please refer to
+Documentation/arm/keystone/knav-qmss.txt
 
 Required properties:
 - compatible   : Must be "ti,keystone-navigator-qmss";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Resend: PATCH v2 4/4] soc: ti: qmss: make acc queue support optional in the driver

[Murali Karicheri]

acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.

Signed-off-by: Murali Karicheri 
---
 - v2 : new patch added
 Documentation/arm/keystone/knav-qmss.txt |  6 ++
 drivers/soc/ti/knav_qmss.h   |  2 ++
 drivers/soc/ti/knav_qmss_acc.c   | 10 --
 drivers/soc/ti/knav_qmss_queue.c | 20 +++-
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
  "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
 
 in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_headlist;
+   boolloaded;
+   boolstarted;
 };
 
 struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
  * Return 0 on success or error
  */
 int knav_init_acc_range(struct knav_device *kdev,
-   struct device_node *node,
-   struct knav_range_info *range)
+   struct device_node *node,
+   struct knav_range_info *range)
 {
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
 
+   if (!pdsp->started) {
+   dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+   info->pdsp_id, range->name);
+   return -ENODEV;
+   }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+   pdsp->loaded = false;
+   pdsp->started = false;
return 0;
 }
 
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device 
*kdev)
int ret;
 
knav_queue_stop_pdsps(kdev);
-   /* now load them all */
+   /* now load them all. We return success even if pdsp
+* is not loaded as acc channels are optional on having
+* firmware availability in the system. We set the loaded
+* and stated flag and when initialize the acc range, check
+* it and init the range only if pdsp is started.
+*/
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
-   if (ret < 0)
-   return ret;
+   if (!ret)
+   pdsp->loaded = true;
}
 
for_each_pdsp(kdev, pdsp) {
-   ret = knav_queue_start_pdsp(kdev, pdsp);
-   WARN_ON(ret);
+   if (pdsp->loaded) {
+   ret = knav_queue_start_pdsp(kdev, pdsp);
+   if (!ret)
+   pdsp->started = true;
+   }
}
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/4] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

On 10/12/2015 03:46 PM, Murali Karicheri wrote:

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
  (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
  (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against above patch set. Key issues
addressed.

- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

Additionally added accumulator queue support optional so that lack of
firmware in the file system will not cause other queue types not available
due to driver probe failure.

Murali Karicheri (4):
   Documentation: dt: soc: move driver description to a separate document
   soc: ti: add firmware file name as part of the driver
   ARM: dts: keystone: enable accumulator channels
   soc: ti: qmss: make acc queue support optional in the driver

  Documentation/arm/keystone/knav-qmss.txt   | 56 ++
  .../bindings/soc/ti/keystone-navigator-qmss.txt| 21 ++-
  arch/arm/boot/dts/k2e-netcp.dtsi   | 23 
  arch/arm/boot/dts/k2hk-netcp.dtsi  | 24 
  arch/arm/boot/dts/k2l-netcp.dtsi   | 23 
  drivers/soc/ti/knav_qmss.h |  3 +-
  drivers/soc/ti/knav_qmss_acc.c | 10 +++-
  drivers/soc/ti/knav_qmss_queue.c   | 67 ++
  8 files changed, 183 insertions(+), 44 deletions(-)
  create mode 100644 Documentation/arm/keystone/knav-qmss.txt


Will re-send 1/4 and 4/4 since I have messed up the patch prefix.

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/4] ARM: dts: keystone: enable accumulator channels

[Murali Karicheri]

Add low priority accumulator channel that can monitor multiple QMSS
queues. User for example could use the accumular queue for Netcp
Rx completion. While at it, also add an extra line end of each top
level node in DTS to make it more readable.

Signed-off-by: Murali Karicheri 
---
 - firmware name removed in v2
 arch/arm/boot/dts/k2e-netcp.dtsi  | 23 +++
 arch/arm/boot/dts/k2hk-netcp.dtsi | 24 
 arch/arm/boot/dts/k2l-netcp.dtsi  | 23 +++
 3 files changed, 70 insertions(+)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
index b13b3c9..ac990f6 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -72,7 +72,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +93,19 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2hk-netcp.dtsi 
b/arch/arm/boot/dts/k2hk-netcp.dtsi
index 77a32c3..f86d6dd 100644
--- a/arch/arm/boot/dts/k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/k2hk-netcp.dtsi
@@ -47,6 +47,7 @@ qmss: qmss@2a4 {
"region", "push", "pop";
};
};
+
queue-pools {
qpend {
qpend-0 {
@@ -88,7 +89,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -99,6 +110,19 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 6b95284..01aef23 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -72,7 +72,16 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +92,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+

[PATCH v2 2/4] soc: ti: add firmware file name as part of the driver

[Murali Karicheri]

Currently firmware file name is included in the DTS. This is not scalable
as user has to change the DTS if they need upgrade to a new firmware.
Instead, add the firmware file name in the driver itself. As long as there
is no API change, new firmware upgrade is easy and require no driver
change. User is expected to copy the firmware image to the file system
and add a sym link to the new firmware for doing an upgrade. Driver add
a array of firmware file names to search for the available firmware blobs.
This scheme also prepare the driver for future changes to API if ever
happens. In such case it is assumed that driver needs to change to
accommodate the new firmware and new firmware file name will get added to
the array.

Also update the DT document to remove the firmware attribute and add
description about firmware in the driver documentation.

Signed-off-by: Murali Karicheri 
---
 - v2. Moved firmware file name from DT to driver code.
 Documentation/arm/keystone/knav-qmss.txt   | 26 
 .../bindings/soc/ti/keystone-navigator-qmss.txt|  1 -
 drivers/soc/ti/knav_qmss.h |  1 -
 drivers/soc/ti/knav_qmss_queue.c   | 47 +-
 4 files changed, 54 insertions(+), 21 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index 79946d1..da34a5b 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -22,3 +22,29 @@ pool management.
 knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
 allocate descriptor pools, map the descriptors, push/pop to queues etc. For
 details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
+
+DT documentation is available at
+Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+
+Accumulator QMSS queues using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example in DT documentation) to monitor
+1 or 32 queues per channel. More description on the firmware is available in
+CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under ti-keystone folder of
+firmware.git at
+   git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
+
+To use copy the firmware image to lib/firmware folder of the initramfs or
+ubifs file system and provide a sym link to 
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
+in the file system and boot up the kernel. User would see
+
+ "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
+
+in the boot up log if loading of firmware to PDSP is successful.
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index 2cecea1..aac8c36 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -209,7 +209,6 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index 51da234..c31b8d8 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -135,7 +135,6 @@ struct knav_pdsp_info {
};
void __iomem*intd;
u32 __iomem *iram;
-   const char  *firmware;
u32 id;
struct list_headlist;
 };
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..06d9de8 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -68,6 +68,12 @@ static DEFINE_MUTEX(knav_dev_lock);
 idx < (kdev)->num_queues_in_use;   \
 idx++, inst = knav_queue_idx_to_inst(kdev, idx))
 
+/* All firmware file names end up here. List the firmware file names below.
+ * Newest followed by older ones. Search is done from start of the array
+ * until a firmware file is found.
+ */
+const char *knav_acc_firmwares[] = {"ks2_qmss_pdsp_acc48.bin"};
+
 /**
  * knav_

[PATCH 1/4] Documentation: dt: soc: move driver description to a separate document

[Murali Karicheri]

Currently the DT bindings have details about the driver as well. This
patch moves this to a separate document for knav qmss driver so that
driver detail update can be done as needed without polluting the DT
bindings description.

Signed-off-by: Murali Karicheri 
---
 Documentation/arm/keystone/knav-qmss.txt   | 24 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt| 20 --
 2 files changed, 28 insertions(+), 16 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
new file mode 100644
index 000..79946d1
--- /dev/null
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -0,0 +1,24 @@
+* Texas Instruments Keystone Navigator Queue Management SubSystem driver
+
+Driver source code path
+  drivers/soc/ti/knav_qmss.c
+  drivers/soc/ti/knav_qmss_acc.c
+
+The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
+the main hardware sub system which forms the backbone of the Keystone
+multi-core Navigator. QMSS consist of queue managers, packed-data structure
+processors(PDSP), linking RAM, descriptor pools and infrastructure
+Packet DMA.
+The Queue Manager is a hardware module that is responsible for accelerating
+management of the packet queues. Packets are queued/de-queued by writing or
+reading descriptor address to a particular memory mapped location. The PDSPs
+perform QMSS related functions like accumulation, QoS, or event management.
+Linking RAM registers are used to link the descriptors which are stored in
+descriptor RAM. Descriptor RAM is configurable as internal or external memory.
+The QMSS driver manages the PDSP setups, linking RAM regions,
+queue pool management (allocation, push, pop and notify) and descriptor
+pool management.
+
+knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
+allocate descriptor pools, map the descriptors, push/pop to queues etc. For
+details of the available APIs, please refers to 
include/linux/soc/ti/knav_qmss.h
diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..2cecea1 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -1,20 +1,8 @@
-* Texas Instruments Keystone Navigator Queue Management SubSystem driver
-
-The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
-the main hardware sub system which forms the backbone of the Keystone
-multi-core Navigator. QMSS consist of queue managers, packed-data structure
-processors(PDSP), linking RAM, descriptor pools and infrastructure
-Packet DMA.
-The Queue Manager is a hardware module that is responsible for accelerating
-management of the packet queues. Packets are queued/de-queued by writing or
-reading descriptor address to a particular memory mapped location. The PDSPs
-perform QMSS related functions like accumulation, QoS, or event management.
-Linking RAM registers are used to link the descriptors which are stored in
-descriptor RAM. Descriptor RAM is configurable as internal or external memory.
-The QMSS driver manages the PDSP setups, linking RAM regions,
-queue pool management (allocation, push, pop and notify) and descriptor
-pool management.
+* Texas Instruments Keystone Navigator (knav) Queue Management SubSystem driver
+  DT bindings
 
+For details of the driver, please refer to
+Documentation/arm/keystone/knav-qmss.txt
 
 Required properties:
 - compatible   : Must be "ti,keystone-navigator-qmss";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 0/4] soc: ti: knav_qmss: enable accumulator queue support

[Murali Karicheri]

This patch series enable accumulator queue support for K2 SoCs. Accumulator
queues are a type of qmss queue that is monitored by the PDSP firmware and
accumulated. Host is interrupted by PDSP firmware when packets become
available in a ring buffer shared between the host and PDSP.

There was an issue raised when merging the original patch set at
 (1) https://lkml.org/lkml/2015/9/4/681
[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log
 (2) https://lkml.org/lkml/2015/9/4/680
[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

This series fixes the issues raised against above patch set. Key issues
addressed.

- Remove the firmware filename from DT and add it to the driver.
  Use a name ks2_qmss_pdsp_acc48.bin. The idea is this can be a
  soft link pointing to the real firmware file in file system.

- Move the description of the driver design from DT document to one
  under Documentation/arm/keystone/knav-qmss.txt. Update the this
  document with location of acc firmware available under
  linux-firmware.git.

Additionally added accumulator queue support optional so that lack of
firmware in the file system will not cause other queue types not available
due to driver probe failure.

Murali Karicheri (4):
  Documentation: dt: soc: move driver description to a separate document
  soc: ti: add firmware file name as part of the driver
  ARM: dts: keystone: enable accumulator channels
  soc: ti: qmss: make acc queue support optional in the driver

 Documentation/arm/keystone/knav-qmss.txt   | 56 ++
 .../bindings/soc/ti/keystone-navigator-qmss.txt| 21 ++-
 arch/arm/boot/dts/k2e-netcp.dtsi   | 23 
 arch/arm/boot/dts/k2hk-netcp.dtsi  | 24 
 arch/arm/boot/dts/k2l-netcp.dtsi   | 23 
 drivers/soc/ti/knav_qmss.h |  3 +-
 drivers/soc/ti/knav_qmss_acc.c | 10 +++-
 drivers/soc/ti/knav_qmss_queue.c   | 67 ++
 8 files changed, 183 insertions(+), 44 deletions(-)
 create mode 100644 Documentation/arm/keystone/knav-qmss.txt

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/4] soc: ti: qmss: make acc queue support optional in the driver

[Murali Karicheri]

acc channels are available only if accumulator PDSP is loaded and
running in the SoC. As this requires firmware and user may not have
firmware in the file system, make the accumulator queue support
available in qmss driver optional. To use accumulator queus user needs
to add firmware to the file system and boot up kernel.

Signed-off-by: Murali Karicheri 
---
 - v2 : new patch added
 Documentation/arm/keystone/knav-qmss.txt |  6 ++
 drivers/soc/ti/knav_qmss.h   |  2 ++
 drivers/soc/ti/knav_qmss_acc.c   | 10 --
 drivers/soc/ti/knav_qmss_queue.c | 20 +++-
 4 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/Documentation/arm/keystone/knav-qmss.txt 
b/Documentation/arm/keystone/knav-qmss.txt
index da34a5b..fcdb9fd 100644
--- a/Documentation/arm/keystone/knav-qmss.txt
+++ b/Documentation/arm/keystone/knav-qmss.txt
@@ -48,3 +48,9 @@ in the file system and boot up the kernel. User would see
  "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
 
 in the boot up log if loading of firmware to PDSP is successful.
+
+Use of accumulated queues requires the firmware image to be present in the
+file system. The driver doesn't acc queues to the supported queue range if
+PDSP is not running in the SoC. The API call fails if there is a queue open
+request to an acc queue and PDSP is not running. So make sure to copy firmware
+to file system before using these queue types.
diff --git a/drivers/soc/ti/knav_qmss.h b/drivers/soc/ti/knav_qmss.h
index c31b8d8..6ff936c 100644
--- a/drivers/soc/ti/knav_qmss.h
+++ b/drivers/soc/ti/knav_qmss.h
@@ -137,6 +137,8 @@ struct knav_pdsp_info {
u32 __iomem *iram;
u32 id;
struct list_headlist;
+   boolloaded;
+   boolstarted;
 };
 
 struct knav_qmgr_info {
diff --git a/drivers/soc/ti/knav_qmss_acc.c b/drivers/soc/ti/knav_qmss_acc.c
index b98fe56..d2d48f2 100644
--- a/drivers/soc/ti/knav_qmss_acc.c
+++ b/drivers/soc/ti/knav_qmss_acc.c
@@ -486,8 +486,8 @@ struct knav_range_ops knav_acc_range_ops = {
  * Return 0 on success or error
  */
 int knav_init_acc_range(struct knav_device *kdev,
-   struct device_node *node,
-   struct knav_range_info *range)
+   struct device_node *node,
+   struct knav_range_info *range)
 {
struct knav_acc_channel *acc;
struct knav_pdsp_info *pdsp;
@@ -530,6 +530,12 @@ int knav_init_acc_range(struct knav_device *kdev,
return -EINVAL;
}
 
+   if (!pdsp->started) {
+   dev_err(kdev->dev, "pdsp id %d not started for range %s\n",
+   info->pdsp_id, range->name);
+   return -ENODEV;
+   }
+
info->pdsp = pdsp;
channels = range->num_queues;
if (of_get_property(node, "multi-queue", NULL)) {
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 06d9de8..f3a0b6a 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1504,6 +1504,8 @@ static int knav_queue_stop_pdsp(struct knav_device *kdev,
dev_err(kdev->dev, "timed out on pdsp %s stop\n", pdsp->name);
return ret;
}
+   pdsp->loaded = false;
+   pdsp->started = false;
return 0;
 }
 
@@ -1592,16 +1594,24 @@ static int knav_queue_start_pdsps(struct knav_device 
*kdev)
int ret;
 
knav_queue_stop_pdsps(kdev);
-   /* now load them all */
+   /* now load them all. We return success even if pdsp
+* is not loaded as acc channels are optional on having
+* firmware availability in the system. We set the loaded
+* and stated flag and when initialize the acc range, check
+* it and init the range only if pdsp is started.
+*/
for_each_pdsp(kdev, pdsp) {
ret = knav_queue_load_pdsp(kdev, pdsp);
-   if (ret < 0)
-   return ret;
+   if (!ret)
+   pdsp->loaded = true;
}
 
for_each_pdsp(kdev, pdsp) {
-   ret = knav_queue_start_pdsp(kdev, pdsp);
-   WARN_ON(ret);
+   if (pdsp->loaded) {
+   ret = knav_queue_start_pdsp(kdev, pdsp);
+   if (!ret)
+   pdsp->started = true;
+   }
}
return 0;
 }
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Murali Karicheri]

On 09/25/2015 12:01 PM, Nishanth Menon wrote:

On 09/25/2015 10:18 AM, santosh shilimkar wrote:

On 9/25/2015 7:50 AM, Nishanth Menon wrote:

[...]

But, how about userspace
needing to know which SoC they are on, without needing to depend on
board->soc mapping? How do we help resolve that?
Believe it or not, user space tools that are custom to a specific SoC 
would require such knowledge. So I agree on this front that a SoC 
specific compatibility is cool to have. I think that should have been 
clear in the commit description.


My Acked-By: Murali Karicheri 




Why the user space should care about exact SOC ?


examples vary - trivial one is: debug tools like omapconf[1] or testing
tools like opentest[2] need some standard way to ensure Linux kernel is
functional - trusting the least set of parameters is usually what we
would prefer. while building a generic distro such as debian or yocto,
one prefers NOT to need to do a package build per SoC/perboard - that
never scales. instead, you'd like the same application run on different
systems dynamically.


[1] https://github.com/omapconf/omapconf
[2] http://arago-project.org/wiki/index.php/Opentest




--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Murali Karicheri]

Nishanth,

On 09/24/2015 10:20 AM, Nishanth Menon wrote:

On 09/24/2015 09:05 AM, Murali Karicheri wrote:

On 09/23/2015 02:19 PM, santosh shilimkar wrote:

Nishant,

On 9/22/2015 9:08 AM, Nishanth Menon wrote:

Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms. So, provide
compatible matches for each SoC family by itself.

This allows SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.

Signed-off-by: Nishanth Menon 
---

You need to expand that 'not sufficient' for me. Unless there is
genuine case to support this, I would want to avoid this churn.



I agree. If there are run time check required in code to treat the
variants of Keystone SoC differently, then this change is needed. At
this time, SoC DTS captures these differences. IMHO, If a future
Keystone SoC support required SoC specific compatibility string to
customize SoC specific initialization code, then it can be introduced at
that time. I am not sure why this is introduced with out an example usage.


a) See
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/usage-model.txt#n116
-> all we have today is board, soc generic family. The generic
compatible flag of ti,keystone to mark that this is a keystone2 device
does not identify that what kind of soc it is. which is what this
series introduces.

b) there is no realistic way for user space applications such as a
test framework or other SoC based applications in a generic distro to
detect the right SoC this platform is running on - imagine writing SoC
specific code that depends on board compatible flags - there is never
an end to that story as the number of boards expand.

c) Ideally we will try never to introduce code that will have to
depend on SoC compatible flag based match in kernel - but that is not
a reason not to follow guidelines provided by devicetree documentation
to provide SoC specific compatible flags.



Thanks for pointing out the link which provided me some thing to cross 
check my argument.


The relevant description from the above quoted below for discussion.
= Cut from the above ===

The 'compatible' property contains a sorted list of strings starting
with the exact name of the machine, followed by an optional list of
boards it is compatible with sorted from most compatible to least.  For
example, the root compatible properties for the TI BeagleBoard and its
successor, the BeagleBoard xM board might look like, respectively:

compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";

Where "ti,omap3-beagleboard-xm" specifies the exact model, it also
claims that it compatible with the OMAP 3450 SoC, and the omap3 family
of SoCs in general.  You'll notice that the list is sorted from most
specific (exact board) to least specific (SoC family).

===

So in keystone case, we have

"ti,k2hk-evm","ti,keystone";

IMO, this is consistent with the above description as ti,k2hk-evm 
describes the board exactly and ti,keystone is the optional list which 
is a generic SoC name.


=== Cut from the above==

The reasoning behind this scheme is the observation that in the majority
of cases, a single machine_desc can support a large number of boards
if they all use the same SoC, or same family of SoCs.  However,
invariably there will be some exceptions where a specific board will
require special setup code that is not useful in the generic case.
Special cases could be handled by explicitly checking for the
troublesome board(s) in generic setup code, but doing so very quickly
becomes ugly and/or unmaintainable if it is more than just a couple of
cases.

Instead, the compatible list allows a generic machine_desc to provide
support for a wide common set of boards by specifying "less
compatible" values in the dt_compat list.  In the example above,
generic board support can claim compatibility with "ti,omap3" or
"ti,omap3450".  If a bug was discovered on the original beagleboard
that required special workaround code during early boot, then a new
machine_desc could be added which implements the workarounds and only
matches on "ti,omap3-beagleboard".
===

This is how interpret the above.

ti,omap3 is the family of om

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Murali Karicheri]

On 09/23/2015 02:19 PM, santosh shilimkar wrote:

Nishant,

On 9/22/2015 9:08 AM, Nishanth Menon wrote:

Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms. So, provide
compatible matches for each SoC family by itself.

This allows SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.

Signed-off-by: Nishanth Menon 
---

You need to expand that 'not sufficient' for me. Unless there is
genuine case to support this, I would want to avoid this churn.



I agree. If there are run time check required in code to treat the 
variants of Keystone SoC differently, then this change is needed. At 
this time, SoC DTS captures these differences. IMHO, If a future 
Keystone SoC support required SoC specific compatibility string to 
customize SoC specific initialization code, then it can be introduced at 
that time. I am not sure why this is introduced with out an example usage.



Regards,
Santosh

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Murali Karicheri]

On 09/22/2015 12:08 PM, Nishanth Menon wrote:

Keystone2 devices are used on more platforms than just Texas
Instruments reference evaluation platforms called EVMs. Providing a
generic compatible "ti,keystone" is not sufficient to differentiate
various SoC definitions possible on various platforms. So, provide
compatible matches for each SoC family by itself.

This allows SoC specific logic to be run time handled based on
of_machine_is_compatible("ti,k2hk") or as needed for the dependent
processor instead of needing to use board dependent compatibles that
are needed now.

Signed-off-by: Nishanth Menon 
---
  .../devicetree/bindings/arm/keystone/keystone.txt| 20 +---
  1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt 
b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 59d7a46f85eb..800d2d02e27b 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -9,12 +9,26 @@ Required properties:
 the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
 type UART should use the specified compatible for those devices.

+SoC families:
+
+- Keystone 2 generic SoC:
+   compatible = "ti,keystone"
+
+SoCs:
+
+- Keystone 2 Hawking/Kepler
+   compatible = ti,k2hk", "ti,keystone"
+- Keystone 2 Lamarr
+   compatible = ti,k2l", "ti,keystone"
+- Keystone 2 Edison
+   compatible = ti,k2e", "ti,keystone"
+
  Boards:
  -  Keystone 2 Hawking/Kepler EVM
-   compatible = "ti,k2hk-evm","ti,keystone"
+   compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"

  -  Keystone 2 Lamarr EVM
-   compatible = "ti,k2l-evm","ti,keystone"
+   compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"

  -  Keystone 2 Edison EVM
-   compatible = "ti,k2e-evm","ti,keystone"
+   compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"

DTS takes care of the difference in the hardware and If there SoC 
specific customization required outside this, then it is best to include 
this as part of that change. In the past, I believe we didn't do it due 
to the same reason as above.


Murali

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/15/2015 05:20 PM, santosh shilimkar wrote:

On 9/15/2015 11:14 AM, Murali Karicheri wrote:

On 09/09/2015 12:38 PM, Murali Karicheri wrote:

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right
now I have provided link to ti git repo that has the firmware. I have
the patch ready in case this is required. Do you know?

Murali

Regards,
Santosh






Santosh,

I have checked v4.3-rc1 and I don't see it. Did you send the pull
request?


They are in the queue fo 4.4-rc1. They were too late for 4.3.
You might know already, typically as a rule of thumb followed
on arm-soc, we need to get patches reviewed/acked by rc4 to make
it for next merge window.
Ofcourse genuine bug fixes can make it to the same cycle.
Is there a branch where you have applied the patches that you can 
provide me? I want to send it to internal list for merge.


Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/09/2015 12:38 PM, Murali Karicheri wrote:

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right
now I have provided link to ti git repo that has the firmware. I have
the patch ready in case this is required. Do you know?

Murali

Regards,
Santosh






Santosh,

I have checked v4.3-rc1 and I don't see it. Did you send the pull request?

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/09/2015 01:12 PM, santosh.shilim...@oracle.com wrote:

On 9/9/15 9:38 AM, Murali Karicheri wrote:

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right
now I have provided link to ti git repo that has the firmware. I have
the patch ready in case this is required. Do you know?


Standard distro's will look for linux-firmware.git as a source to get
the firmware files used by kernel so yes, you should add these firmware
files to that repo.

Ok. Will send a patch for this.

Murali


Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

On 09/04/2015 11:53 PM, santosh.shilim...@oracle.com wrote:

On 9/4/15 5:46 PM, Murali Karicheri wrote:

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---


Looks fine. Will pick both the patches.



Thanks Santhosh.

Is there a requirement to add the firmware to linux-firmware.git. Right 
now I have provided link to ti git repo that has the firmware. I have 
the patch ready in case this is required. Do you know?


Murali

Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---
 v1 : fixed firmware file names in documentation
 .../bindings/soc/ti/keystone-navigator-qmss.txt  | 20 +++-
 drivers/soc/ti/knav_qmss_queue.c |  3 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..ca0a1a7 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,7 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
+   firmware = "k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
@@ -230,3 +230,21 @@ qmss: qmss@2a4 {
};
};
 }; /* qmss */
+
+Accumulator QMSS Channel using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example above) to monitor 1 or 32 queues
+per channel. More description on the firmware is available in CPPI/QMSS Low
+Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
+channels. This firmware is available under firmware folder of the above repo
+under the name acc48_le.bin. To use copy the firmware image to lib/firmware
+folder of the initramfs or ubifs file system as
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin and boot up the kernel. User would see
+"firmware file ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin downloaded for PDSP" in
+the boot up log if loading of firmware to PDSP is successful.
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..f26ce99 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1526,6 +1526,9 @@ static int knav_queue_load_pdsp(struct knav_device *kdev,
pdsp->firmware, pdsp->name);
return ret;
}
+   dev_info(kdev->dev, "firmware file %s downloaded for PDSP\n",
+pdsp->firmware);
+
writel_relaxed(pdsp->id + 1, pdsp->command + 0x18);
/* download the firmware */
fwdata = (u32 *)fw->data;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 2/2] ARM: dts: keystone: enable accumulator channels

[Murali Karicheri]

Add low priority accumulator channel that can monitor multiple QMSS
queues. User for example could use the accumular queue for Netcp
Rx completion. While at it, also add an extra line end of each top
level node in DTS to make it more readable.

Signed-off-by: Murali Karicheri 
---
 v1  - No change from initial version
 arch/arm/boot/dts/k2e-netcp.dtsi  | 24 
 arch/arm/boot/dts/k2hk-netcp.dtsi | 25 +
 arch/arm/boot/dts/k2l-netcp.dtsi  | 24 
 3 files changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
index b13b3c9..1818929 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -72,7 +72,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +93,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   firmware = "ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2hk-netcp.dtsi 
b/arch/arm/boot/dts/k2hk-netcp.dtsi
index 77a32c3..b9941b4 100644
--- a/arch/arm/boot/dts/k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/k2hk-netcp.dtsi
@@ -47,6 +47,7 @@ qmss: qmss@2a4 {
"region", "push", "pop";
};
};
+
queue-pools {
qpend {
qpend-0 {
@@ -88,7 +89,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -99,6 +110,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   firmware = "ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 6b95284..8d7ddb3 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -72,7 +72,16 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +92,21 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+

[PATCH 2/2] ARM: dts: keystone: enable accumulator channels

[Murali Karicheri]

Add low priority accumulator channel that can monitor multiple QMSS
queues. User for example could use the accumular queue for Netcp
Rx completion. While at it, also add an extra line end of each top
level node in DTS to make it more readable.

Signed-off-by: Murali Karicheri 
---
 arch/arm/boot/dts/k2e-netcp.dtsi  | 24 
 arch/arm/boot/dts/k2hk-netcp.dtsi | 25 +
 arch/arm/boot/dts/k2l-netcp.dtsi  | 24 
 3 files changed, 73 insertions(+)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-netcp.dtsi
index b13b3c9..1818929 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -72,7 +72,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +93,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   firmware = "ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2hk-netcp.dtsi 
b/arch/arm/boot/dts/k2hk-netcp.dtsi
index 77a32c3..b9941b4 100644
--- a/arch/arm/boot/dts/k2hk-netcp.dtsi
+++ b/arch/arm/boot/dts/k2hk-netcp.dtsi
@@ -47,6 +47,7 @@ qmss: qmss@2a4 {
"region", "push", "pop";
};
};
+
queue-pools {
qpend {
qpend-0 {
@@ -88,7 +89,17 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   qalloc-by-id;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -99,6 +110,20 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pdsp0@0x2a1 {
+   firmware = "ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
+   reg = <0x2a1 0x1000/*iram */
+  0x2a0f000 0x100 /*reg*/
+  0x2a0c000 0x3c8 /*intd */
+  0x2a2 0x4000>;  /*cmd*/
+   id = <0>;
+   };
+   };
 }; /* qmss */
 
 knav_dmas: knav_dmas@0 {
diff --git a/arch/arm/boot/dts/k2l-netcp.dtsi b/arch/arm/boot/dts/k2l-netcp.dtsi
index 6b95284..8d7ddb3 100644
--- a/arch/arm/boot/dts/k2l-netcp.dtsi
+++ b/arch/arm/boot/dts/k2l-netcp.dtsi
@@ -72,7 +72,16 @@ qmss: qmss@2a4 {
qalloc-by-id;
};
};
+   accumulator {
+   acc-low-0 {
+   qrange = <480 32>;
+   accumulator = <0 47 16 2 50>;
+   interrupts = <0 226 0xf01>;
+   multi-queue;
+   };
+   };
};
+
descriptor-regions {
#address-cells = <1>;
#size-cells = <1>;
@@ -83,6 +92,21 @@ qmss: qmss@2a4 {
link-index = <0x4000>;
};
};
+
+   pdsps {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+

[PATCH 1/2] soc: ti: display firmware file name as part of boot log

[Murali Karicheri]

To help the user, print the PDSP file name as part of
knav_queue_load_pdsp(). This will be useful for users to know what
version of the firmware is loaded to PDSP. Also update the
document for the location of the QMSS accumulator PDSP firmware.

Signed-off-by: Murali Karicheri 
---
 .../bindings/soc/ti/keystone-navigator-qmss.txt  | 20 +++-
 drivers/soc/ti/knav_qmss_queue.c |  3 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt 
b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
index d8e8cdb..a91ee0b 100644
--- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
+++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
@@ -221,7 +221,7 @@ qmss: qmss@2a4 {
#size-cells = <1>;
ranges;
pdsp0@0x2a1 {
-   firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw";
+   firmware = "k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin";
reg = <0x2a1 0x1000>,
  <0x2a0f000 0x100>,
  <0x2a0c000 0x3c8>,
@@ -230,3 +230,21 @@ qmss: qmss@2a4 {
};
};
 }; /* qmss */
+
+Accumulator QMSS Channel using PDSP firmware
+
+The QMSS PDSP firmware support accumulator channel that can monitor a single
+queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
+driver that interface with the accumulator PDSP. This configures
+accumulator channels defined in DTS (example above) to monitor 1 or 32 queues
+per channel. More description on the firmware is available in CPPI/QMSS Low
+Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
+   git://git.ti.com/keystone-rtos/qmss-lld.git
+
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.fw firmware supports upto 48 accumulator
+channels. This firmware is available under firmware folder of the above repo
+under the name acc48_le.bin. To use copy the firmware image to lib/firmware
+folder of the initramfs or ubifs file system as
+k2_qmss_pdsp_acc48_k2_le_1_0_0_9.fw and boot up the kernel. User would see
+"firmware file ks2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin downloaded for PDSP" in
+the boot up log if loading of firmware to PDSP is successful.
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index 6d8646d..f26ce99 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -1526,6 +1526,9 @@ static int knav_queue_load_pdsp(struct knav_device *kdev,
pdsp->firmware, pdsp->name);
return ret;
}
+   dev_info(kdev->dev, "firmware file %s downloaded for PDSP\n",
+pdsp->firmware);
+
writel_relaxed(pdsp->id + 1, pdsp->command + 0x18);
/* download the firmware */
fwdata = (u32 *)fw->data;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

[Murali Karicheri]

Tony,
On 09/03/2015 10:26 AM, Tony Lindgren wrote:

* santosh shilimkar  [150902 08:55]:


I suspected the same. I know back then we started with SERDES code
with NETCP but as you already know, its a separate block which
is needed for NIC card to work. Its more of phy and hence its
having different address space is not surprising.


The point Santosh is making here though is that any drivers
tinkering with registers belonging to a separate hardware block
is a recipe for a long term maintenance nightmare with mysterious


That is what we want to avoid as well. If I interpret your statement 
correctly, you don't want SerDes driver update the register of say 
SGMII, right? But we will have to based on the hardware design. So it 
can't be a standalone device driver IMO and it has to be part of the 
respective peripheral device driver.



bugs popping up as things are not clocked or powered properly
or become racy with other drivers.

Each hardware block needs to have it's own driver and then the
drivers can communicate using some Linux generic APIs like clock,
regulator, phy, or mailbox frameworks.


That depends on what your definition of a hardware block is. Inside 
NetCP, there are many hardware blocks that work together to provide the 
NIC functionality, and SerDes is one of them. Where ever possible, we 
have separate drivers :- knav qmss, knav pkt dma, ethss, mdio etc. Ethss 
driver manages Eth subsystem that includes SGMII and SerDes. 
Unfortunately SerDes is tightly integrated with ethss and taking it out 
as a separate driver (Say Phy) is not a good idea. We will posting an 
RFC for this soon and probably we can discuss it more then.


Probably we will fold this into the RFC series to give this a better 
context.


Murali



Regards,

Tony




--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

[Murali Karicheri]

On 09/02/2015 02:25 PM, santosh shilimkar wrote:

9/2/2015 10:58 AM, Murali Karicheri wrote:

On 09/02/2015 01:24 PM, santosh shilimkar wrote:

On 9/2/2015 9:35 AM, Murali Karicheri wrote:

Santosh,



---Cut---


I suspected the same. I know back then we started with SERDES code
with NETCP but as you already know, its a separate block which
is needed for NIC card to work. Its more of phy and hence its
having different address space is not surprising.


Using Phy interface is not acceptable to the subsystem maintainer based
on the communication I had on this. Also the Phy here is tighly coupled
with the hardware block it is working with. So this model is not right
for SerDes driver as it require additional enhancements as described
below if needs to be used.


Thanks for update on that.


The serdes initialization procedure requires checking the status in the
hardware block (PCIe, 1G or 10G) and then taking corrective action.
This
means a Phy driver would require mapping of related hw address space
(PCIe, 1G and 10G) as well which is already mapped by the hardware
driver(PCIe, 1G and 10G). One solution is to treat this as a libray
function that can be called from the respective hardware device driver.
  A device node of h/w device (PCIe or 1G) in such as looks like


Or SerDes driver can embed the status reg address space.
This is read only access so should be fine.


pcie {

 serdes@someaddress {
 reg = ;
 }
}

hw driver will call ks2_serdes_init(node, hw_base_address) to
initialize
the serdes. Other APIs can be added to enable/disable lane or shutdown
etc. The libary will be added to drivers/soc/ti/ and used by various
device drivers to initialize and use the phy. As the serdes is slightly
integrated with the hardware block, IMO, this is a better approach than
using the phy model. The API definitions will be added to
include/linux/soc/ti/ folder.


Serdes Driver with its status register address space might solve this
sharing problem. Library might work but we should try to have driver
considering there is a physical device. I don't have strong opinion
on drivers vs library.



In addition to checking status in the SerDes, it needs to also check the
status of the associated hardware block (PCIe, 1G, 10G etc). So this
means, same needs to be mapped twice, first by the above hardware device
drivers and then by the serdes driver which causes problem. My point is
since they both are tightly coupled, a libary is a better option. That
way the mapped address can be passed to the serdes API to perform the
required task, instead of using Phy API which doesn't allow us to do the
same. If SerDes h/w can be brought up independently, the Phy model fits
well.


As I said, I don't have strong preference and fine with library approach.
I suggest you do a RFC to take this further. Include Arnd on CC for
that.


Sure!

Murali


Regards,
Santosh







--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

[Murali Karicheri]

On 09/02/2015 01:24 PM, santosh shilimkar wrote:

On 9/2/2015 9:35 AM, Murali Karicheri wrote:

Santosh,



---Cut---


I suspected the same. I know back then we started with SERDES code
with NETCP but as you already know, its a separate block which
is needed for NIC card to work. Its more of phy and hence its
having different address space is not surprising.


Using Phy interface is not acceptable to the subsystem maintainer based
on the communication I had on this. Also the Phy here is tighly coupled
with the hardware block it is working with. So this model is not right
for SerDes driver as it require additional enhancements as described
below if needs to be used.


Thanks for update on that.


The serdes initialization procedure requires checking the status in the
hardware block (PCIe, 1G or 10G) and then taking corrective action. This
means a Phy driver would require mapping of related hw address space
(PCIe, 1G and 10G) as well which is already mapped by the hardware
driver(PCIe, 1G and 10G). One solution is to treat this as a libray
function that can be called from the respective hardware device driver.
  A device node of h/w device (PCIe or 1G) in such as looks like


Or SerDes driver can embed the status reg address space.
This is read only access so should be fine.


pcie {

 serdes@someaddress {
 reg = ;
 }
}

hw driver will call ks2_serdes_init(node, hw_base_address) to initialize
the serdes. Other APIs can be added to enable/disable lane or shutdown
etc. The libary will be added to drivers/soc/ti/ and used by various
device drivers to initialize and use the phy. As the serdes is slightly
integrated with the hardware block, IMO, this is a better approach than
using the phy model. The API definitions will be added to
include/linux/soc/ti/ folder.


Serdes Driver with its status register address space might solve this
sharing problem. Library might work but we should try to have driver
considering there is a physical device. I don't have strong opinion
on drivers vs library.



In addition to checking status in the SerDes, it needs to also check the 
status of the associated hardware block (PCIe, 1G, 10G etc). So this 
means, same needs to be mapped twice, first by the above hardware device 
drivers and then by the serdes driver which causes problem. My point is 
since they both are tightly coupled, a libary is a better option. That 
way the mapped address can be passed to the serdes API to perform the 
required task, instead of using Phy API which doesn't allow us to do the 
same. If SerDes h/w can be brought up independently, the Phy model fits 
well.


Murali



The SerDes will use the firmware interface to download and configure the
hardware block to use with PCIe/1G/10G/SRIO. I queried the linux forum
on this and the response was that firmware interface can be used for
this. The patch will be using the firmware interface instead of
embedding magic values in the serdes driver.


Firmware interface usage seems to be correct way.
Thanks for giving the details. It helped me to get better picture.

Regards,
Santosh

Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: keystone: use one to one address translations under netcp

[Murali Karicheri]

Santosh,

On 09/02/2015 11:50 AM, santosh shilimkar wrote:

On 9/2/2015 8:31 AM, Kwok, WingMan wrote:




-Original Message-
From: santosh.shilim...@oracle.com [mailto:santosh.shilim...@oracle.com]
Sent: Tuesday, September 01, 2015 5:19 PM
To: Kwok, WingMan; robh...@kernel.org; pawel.m...@arm.com;
mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
ga...@codeaurora.org;
li...@arm.linux.org.uk; devicetree@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; linux-ker...@vger.kernel.org;
ssant...@kernel.org
Cc: Karicheri, Muralidharan
Subject: Re: [PATCH] ARM: dts: keystone: use one to one address
translations
under netcp

On 9/1/15 1:28 PM, WingMan Kwok wrote:

Network subsystem NetCP in Keystone-2 devices includes some HW blocks
that are memory mapped to ranges outside that of the NetCP itself.
Thus address space of a child node of the NetCP node needs to be
mapped 1:1 onto the parent address space.  Hence empty ranges
should be used under the NetCP node.

Signed-off-by: WingMan Kwok 
---
   arch/arm/boot/dts/k2e-netcp.dtsi  |8 +++-
   arch/arm/boot/dts/k2hk-netcp.dtsi |   14 ++
   arch/arm/boot/dts/k2l-netcp.dtsi  |8 +++-
   3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/k2e-netcp.dtsi b/arch/arm/boot/dts/k2e-

netcp.dtsi

index b13b3c9..e103ed9 100644
--- a/arch/arm/boot/dts/k2e-netcp.dtsi
+++ b/arch/arm/boot/dts/k2e-netcp.dtsi
@@ -111,9 +111,7 @@ netcp: netcp@2400 {
   compatible = "ti,netcp-1.0";
   #address-cells = <1>;
   #size-cells = <1>;
-
-/* NetCP address range */
-ranges = <0 0x2400 0x100>;
+ranges;


What blocks are we talking here. We need to increase the
range if the current range isn't covering entire NETCP
address space. Removing range isn't a solution.



The Serdes.  It is a HW block inside the NetCP but its address
space starts from 0x0232a000.  We can change the base in the
ranges property to include the serdes.  But then offsets of
other HW blocks that are within the NetCP address range will be
relative to this new base and are not as documented in the HW
user guides.


I suspected the same. I know back then we started with SERDES code
with NETCP but as you already know, its a separate block which
is needed for NIC card to work. Its more of phy and hence its
having different address space is not surprising.


Using Phy interface is not acceptable to the subsystem maintainer based 
on the communication I had on this. Also the Phy here is tighly coupled 
with the hardware block it is working with. So this model is not right 
for SerDes driver as it require additional enhancements as described 
below if needs to be used.


The serdes initialization procedure requires checking the status in the 
hardware block (PCIe, 1G or 10G) and then taking corrective action. This 
means a Phy driver would require mapping of related hw address space 
(PCIe, 1G and 10G) as well which is already mapped by the hardware 
driver(PCIe, 1G and 10G). One solution is to treat this as a libray 
function that can be called from the respective hardware device driver. 
 A device node of h/w device (PCIe or 1G) in such as looks like


pcie {

serdes@someaddress {
reg = ;
}
}

hw driver will call ks2_serdes_init(node, hw_base_address) to initialize 
the serdes. Other APIs can be added to enable/disable lane or shutdown 
etc. The libary will be added to drivers/soc/ti/ and used by various 
device drivers to initialize and use the phy. As the serdes is slightly 
integrated with the hardware block, IMO, this is a better approach than 
using the phy model. The API definitions will be added to 
include/linux/soc/ti/ folder.


The SerDes will use the firmware interface to download and configure the 
hardware block to use with PCIe/1G/10G/SRIO. I queried the linux forum 
on this and the response was that firmware interface can be used for 
this. The patch will be using the firmware interface instead of 
embedding magic values in the serdes driver.


Murali



IIRC, there was a plan to consolidate the serdes code together
since the PCIE also needs it. Irrespective of that, I suggest
you model the serdes address space in another node and fetch
it from there if that works for you. Please also add DTS
documentation if you are going ahead with that approach.




Regards,
Santosh








--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio

[Murali Karicheri]

On 08/03/2015 02:30 PM, santosh.shilim...@oracle.com wrote:

On 8/3/15 11:22 AM, Murali Karicheri wrote:

On 08/03/2015 02:11 PM, Murali Karicheri wrote:

Currently the MDIO clock is pointing to clkpa instead of clkcpgmac.
MDIO is part of the ethss and the clock should be clkcpgmac.

Signed-off-by: Murali Karicheri 
---
  arch/arm/boot/dts/keystone.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone.dtsi
b/arch/arm/boot/dts/keystone.dtsi
index e7a6f6d..6245a17 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -273,7 +273,7 @@
  #size-cells = <0>;
  reg= <0x02090300 0x100>;
  status = "disabled";
-clocks = <&clkpa>;
+clocks = <&clkcpgmac>;
  clock-names = "fck";
  bus_freq= <250>;
  };


Santosh,

This is a big fix and needs to go in v4.2-rc. So please review and apply
asap. v4.2 is the first release that has netcp driver fully functional
and I want to fix as many known bugs as possible.


Do you have more fixes ? If yes, please post them so that I can include
them along with these two. I will try to send them up next week.


I think we have got most of the know issues fixed in the netcp driver 
and dts for v4.2-rc. Another lingering issue is the one with multiple 
clock handling not supported in run time pm API causing us to use the 
work around 'clk_ignore_unused'. Probably this needs to be addressed in 
the future as fixing this is not trivial. Generic PD support would 
partially solve the issue for Keystone, but also needs to handle 
multiple clocks for keystone.


Another option is to  fix the NetCP and QMSS/KNAV driver for now in 
v4.0-rc using explicit clock APIs so that we don't have to use 
'clk_ignore_unused'. And then migrate all of the drivers to run time PM 
API later when proper framework is implemented along with K2G support. 
Does this make sense?


Anyways, please submit these patches at your earliest opportunity.

Thanks

Murali



Thanks !!

Regards,
Santosh





--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio

[Murali Karicheri]

On 08/03/2015 02:11 PM, Murali Karicheri wrote:

Currently the MDIO clock is pointing to clkpa instead of clkcpgmac.
MDIO is part of the ethss and the clock should be clkcpgmac.

Signed-off-by: Murali Karicheri 
---
  arch/arm/boot/dts/keystone.dtsi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index e7a6f6d..6245a17 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -273,7 +273,7 @@
#size-cells = <0>;
reg = <0x02090300 0x100>;
status = "disabled";
-   clocks = <&clkpa>;
+   clocks = <&clkcpgmac>;
clock-names = "fck";
bus_freq= <250>;
};


Santosh,

This is a big fix and needs to go in v4.2-rc. So please review and apply 
asap. v4.2 is the first release that has netcp driver fully functional 
and I want to fix as many known bugs as possible.


Thanks.

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: keystone: Fix the mdio bindings by moving it to soc specific file

[Murali Karicheri]

Currently mdio bindings are defined in keystone.dtsi and this results
in incorrect unit address for the node on K2E and K2L SoCs. Fix this
by moving them to SoC specific DTS file.

Signed-off-by: Murali Karicheri 
---
 arch/arm/boot/dts/k2e.dtsi  | 15 +++
 arch/arm/boot/dts/k2hk.dtsi | 11 +++
 arch/arm/boot/dts/k2l.dtsi  | 16 +++-
 arch/arm/boot/dts/keystone.dtsi | 11 ---
 4 files changed, 33 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 1b6494f..675fb8e 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -131,10 +131,17 @@
;
};
};
+
+   mdio: mdio@24200f00 {
+   compatible  = "ti,keystone_mdio", "ti,davinci_mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x24200f00 0x100>;
+   status = "disabled";
+   clocks = <&clkcpgmac>;
+   clock-names = "fck";
+   bus_freq= <250>;
+   };
/include/ "k2e-netcp.dtsi"
};
 };
-
-&mdio {
-   reg = <0x24200f00 0x100>;
-};
diff --git a/arch/arm/boot/dts/k2hk.dtsi b/arch/arm/boot/dts/k2hk.dtsi
index ae64724..d0810a5 100644
--- a/arch/arm/boot/dts/k2hk.dtsi
+++ b/arch/arm/boot/dts/k2hk.dtsi
@@ -98,6 +98,17 @@
#gpio-cells = <2>;
gpio,syscon-dev = <&devctrl 0x25c>;
};
+
+   mdio: mdio@02090300 {
+   compatible  = "ti,keystone_mdio", "ti,davinci_mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x02090300 0x100>;
+   status = "disabled";
+   clocks = <&clkcpgmac>;
+   clock-names = "fck";
+   bus_freq= <250>;
+   };
/include/ "k2hk-netcp.dtsi"
};
 };
diff --git a/arch/arm/boot/dts/k2l.dtsi b/arch/arm/boot/dts/k2l.dtsi
index 0e00748..49fd414 100644
--- a/arch/arm/boot/dts/k2l.dtsi
+++ b/arch/arm/boot/dts/k2l.dtsi
@@ -29,7 +29,6 @@
};
 
soc {
-
/include/ "k2l-clocks.dtsi"
 
uart2: serial@02348400 {
@@ -79,6 +78,17 @@
#gpio-cells = <2>;
gpio,syscon-dev = <&devctrl 0x24c>;
};
+
+   mdio: mdio@26200f00 {
+   compatible  = "ti,keystone_mdio", "ti,davinci_mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x26200f00 0x100>;
+   status = "disabled";
+   clocks = <&clkcpgmac>;
+   clock-names = "fck";
+   bus_freq= <250>;
+   };
/include/ "k2l-netcp.dtsi"
};
 };
@@ -96,7 +106,3 @@
/* Pin muxed. Enabled and configured by Bootloader */
status = "disabled";
 };
-
-&mdio {
-   reg = <0x26200f00 0x100>;
-};
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 6245a17..72816d6 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -267,17 +267,6 @@
  1 0 0x21000A00 0x0100>;
};
 
-   mdio: mdio@02090300 {
-   compatible  = "ti,keystone_mdio", "ti,davinci_mdio";
-   #address-cells = <1>;
-   #size-cells = <0>;
-   reg = <0x02090300 0x100>;
-   status = "disabled";
-   clocks = <&clkcpgmac>;
-   clock-names = "fck";
-   bus_freq= <250>;
-   };
-
kirq0: keystone_irq@26202a0 {
compatible = "ti,keystone-irq";
interrupts = ;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio

[Murali Karicheri]

Currently the MDIO clock is pointing to clkpa instead of clkcpgmac.
MDIO is part of the ethss and the clock should be clkcpgmac.

Signed-off-by: Murali Karicheri 
---
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index e7a6f6d..6245a17 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -273,7 +273,7 @@
#size-cells = <0>;
reg = <0x02090300 0x100>;
status = "disabled";
-   clocks = <&clkpa>;
+   clocks = <&clkcpgmac>;
clock-names = "fck";
bus_freq= <250>;
};
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ARM: dts: keystone: fix dt bindings to use post div register for mainpll

[Murali Karicheri]

On 05/29/2015 12:04 PM, Murali Karicheri wrote:

All of the keystone devices have a separate register to hold post
divider value for main pll clock. Currently the fixed-postdiv
value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
use a value of 2 for this. Now that we have fixed this in the pll
clock driver change the dt bindings for the same.

Signed-off-by: Murali Karicheri 
---
  arch/arm/boot/dts/k2e-clocks.dtsi  | 5 ++---
  arch/arm/boot/dts/k2hk-clocks.dtsi | 5 ++---
  arch/arm/boot/dts/k2l-clocks.dtsi  | 5 ++---
  3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/k2e-clocks.dtsi 
b/arch/arm/boot/dts/k2e-clocks.dtsi
index 4773d6a..d56d68f 100644
--- a/arch/arm/boot/dts/k2e-clocks.dtsi
+++ b/arch/arm/boot/dts/k2e-clocks.dtsi
@@ -13,9 +13,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};

papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2hk-clocks.dtsi 
b/arch/arm/boot/dts/k2hk-clocks.dtsi
index d5adee3..af9b719 100644
--- a/arch/arm/boot/dts/k2hk-clocks.dtsi
+++ b/arch/arm/boot/dts/k2hk-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};

papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2l-clocks.dtsi 
b/arch/arm/boot/dts/k2l-clocks.dtsi
index eb1e3e2..ef8464b 100644
--- a/arch/arm/boot/dts/k2l-clocks.dtsi
+++ b/arch/arm/boot/dts/k2l-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};

papllclk: papllclk@2620358 {


Santosh,

The clk driver update is already merged to v4.2-rc. Could you send this 
DT update as well for 4.2-rc?


Murali

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/2] ARM: keystone: dts: fix dt bindings for PCIe

[Murali Karicheri]

On 07/16/2015 06:43 PM, santosh.shilim...@oracle.com wrote:

On 7/16/15 2:51 PM, Murali Karicheri wrote:

Currently PCIe DT bindings are broken. PCIe driver can't function
without having a SerDes driver that provide the phy configuration.
On K2E EVM, this causes problem since the EVM has Marvell SATA
controller present and with default values in the SerDes register,
it seems to pass the PCIe link check, but causes issues since
the configuration is not correct. The manifestation is that when
EVM is booted with NFS rootfs, the boot hangs. We shouldn't enable
PCIe on this EVM since to work, SerDes driver has to be present as
well. So by default, the PCIe DT binding should be disabled in SoC
specific DTS. It can be enabled in the board specific DTS when the
SerDes device driver is also present.

So fix the status of PCIe DT bindings in the SoC specific DTS to
"disabled". To enable PCIe, the status should be set to "ok" in
the EVM DTS file when SerDes driver support becomes available in
the upstream tree.

Signed-off-by: Murali Karicheri 
---
  - updated commit description to make it clear that it is fix
to be applied to v4.2-rc.


Just sent pull request with both of these patches from the series.

Regards,
Santosh



Thanks Santosh.

regards,

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 1/2] ARM: keystone: dts: fix dt bindings for PCIe

[Murali Karicheri]

Currently PCIe DT bindings are broken. PCIe driver can't function
without having a SerDes driver that provide the phy configuration.
On K2E EVM, this causes problem since the EVM has Marvell SATA
controller present and with default values in the SerDes register,
it seems to pass the PCIe link check, but causes issues since
the configuration is not correct. The manifestation is that when
EVM is booted with NFS rootfs, the boot hangs. We shouldn't enable
PCIe on this EVM since to work, SerDes driver has to be present as
well. So by default, the PCIe DT binding should be disabled in SoC
specific DTS. It can be enabled in the board specific DTS when the
SerDes device driver is also present.

So fix the status of PCIe DT bindings in the SoC specific DTS to
"disabled". To enable PCIe, the status should be set to "ok" in
the EVM DTS file when SerDes driver support becomes available in
the upstream tree.

Signed-off-by: Murali Karicheri 
---
 - updated commit description to make it clear that it is fix
   to be applied to v4.2-rc.
 arch/arm/boot/dts/k2e.dtsi  | 1 +
 arch/arm/boot/dts/keystone.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 50e555e..ecb9cd6 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -96,6 +96,7 @@
ranges = <0x8100 0 0 0x2326 0x4000 0x4000
0x8200 0 0x6000 0x6000 0 
0x1000>;
 
+   status = "disabled";
device_type = "pci";
num-lanes = <2>;
 
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c06542b..0d6be74 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -296,6 +296,7 @@
ranges = <0x8100 0 0 0x2325 0 0x4000
0x8200 0 0x5000 0x5000 0 
0x1000>;
 
+   status = "disabled";
device_type = "pci";
num-lanes = <2>;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 2/2] ARM: keystone: dts: rename pcie nodes to help override status

[Murali Karicheri]

Now that PCIe DT binding is disabled in SoC specific DTS,
we need a way to override it in a board specific DTS. So
rename the PCIe nodes accordingly.

Signed-off-by: Murali Karicheri 
---
 - initial version. Added to the original series
 arch/arm/boot/dts/k2e.dtsi  | 2 +-
 arch/arm/boot/dts/keystone.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index ecb9cd6..1b6494f 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -86,7 +86,7 @@
gpio,syscon-dev = <&devctrl 0x240>;
};
 
-   pcie@2102 {
+   pcie1: pcie@2102 {
compatible = "ti,keystone-pcie","snps,dw-pcie";
clocks = <&clkpcie1>;
clock-names = "pcie";
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 0d6be74..e7a6f6d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -286,7 +286,7 @@
ti,syscon-dev = <&devctrl 0x2a0>;
};
 
-   pcie@2180 {
+   pcie0: pcie@2180 {
compatible = "ti,keystone-pcie", "snps,dw-pcie";
clocks = <&clkpcie>;
clock-names = "pcie";
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] ARM: keystone: dts: disable pcie dt bindings by default

[Murali Karicheri]

Fix the status of PCIe DT bindings in the SoC specific DTS to
"disabled" so that it can be enabled on a specific board by
setting the status to "Ok" in the board specific DTS.

Signed-off-by: Murali Karicheri 
---
 arch/arm/boot/dts/k2e.dtsi  | 1 +
 arch/arm/boot/dts/keystone.dtsi | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/k2e.dtsi b/arch/arm/boot/dts/k2e.dtsi
index 50e555e..ecb9cd6 100644
--- a/arch/arm/boot/dts/k2e.dtsi
+++ b/arch/arm/boot/dts/k2e.dtsi
@@ -96,6 +96,7 @@
ranges = <0x8100 0 0 0x2326 0x4000 0x4000
0x8200 0 0x6000 0x6000 0 
0x1000>;
 
+   status = "disabled";
device_type = "pci";
num-lanes = <2>;
 
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index c06542b..0d6be74 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -296,6 +296,7 @@
ranges = <0x8100 0 0 0x2325 0 0x4000
0x8200 0 0x5000 0x5000 0 
0x1000>;
 
+   status = "disabled";
device_type = "pci";
num-lanes = <2>;
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] clk: keystone: add support for post divider register for main pll

[Murali Karicheri]

On 06/18/2015 06:55 PM, santosh shilimkar wrote:

On 6/18/2015 3:37 PM, Michael Turquette wrote:

Quoting Murali Karicheri (2015-05-29 09:04:12)

Main PLL controller has post divider bits in a separate register in
pll controller. Use the value from this register instead of fixed
divider when available.

Signed-off-by: Murali Karicheri 


Applied to clk-next.


Thanks Mike !!



Thanks Mike.

Regards,

--
Murali Karicheri
Linux Kernel, Keystone

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in

Re: [PATCH 1/2] clk: keystone: add support for post divider register for main pll

[Murali Karicheri]

On 05/29/2015 12:04 PM, Murali Karicheri wrote:

Main PLL controller has post divider bits in a separate register in
pll controller. Use the value from this register instead of fixed
divider when available.

Signed-off-by: Murali Karicheri 
---
  .../devicetree/bindings/clock/keystone-pll.txt   |  8 
  drivers/clk/keystone/pll.c   | 20 ++--
  2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt 
b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 225990f..47570d2 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -15,8 +15,8 @@ Required properties:
  - compatible : shall be "ti,keystone,main-pll-clock" or 
"ti,keystone,pll-clock"
  - clocks : parent clock phandle
  - reg - pll control0 and pll multipler registers
-- reg-names : control and multiplier. The multiplier is applicable only for
-   main pll clock
+- reg-names : control, multiplier and post-divider. The multiplier and
+   post-divider registers are applicable only for main pll clock
  - fixed-postdiv : fixed post divider value. If absent, use clkod register bits
for postdiv

@@ -25,8 +25,8 @@ Example:
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
fixed-postdiv = <2>;
};

diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 0dd8a4b..4a375ea 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -37,7 +37,8 @@
   *Main PLL or any other PLLs in the device such as ARM PLL, DDR PLL
   *or PA PLL available on keystone2. These PLLs are controlled by
   *this register. Main PLL is controlled by a PLL controller.
- * @pllm: PLL register map address
+ * @pllm: PLL register map address for multiplier bits
+ * @pllod: PLL register map address for post divider bits
   * @pll_ctl0: PLL controller map address
   * @pllm_lower_mask: multiplier lower mask
   * @pllm_upper_mask: multiplier upper mask
@@ -53,6 +54,7 @@ struct clk_pll_data {
u32 phy_pllm;
u32 phy_pll_ctl0;
void __iomem *pllm;
+   void __iomem *pllod;
void __iomem *pll_ctl0;
u32 pllm_lower_mask;
u32 pllm_upper_mask;
@@ -102,7 +104,11 @@ static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
/* read post divider from od bits*/
postdiv = ((val & pll_data->clkod_mask) >>
 pll_data->clkod_shift) + 1;
-   else
+   else if (pll_data->pllod) {
+   postdiv = readl(pll_data->pllod);
+   postdiv = ((postdiv & pll_data->clkod_mask) >>
+   pll_data->clkod_shift) + 1;
+   } else
postdiv = pll_data->postdiv;

rate /= (prediv + 1);
@@ -172,12 +178,21 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
/* assume the PLL has output divider register bits */
pll_data->clkod_mask = CLKOD_MASK;
pll_data->clkod_shift = CLKOD_SHIFT;
+
+   /*
+* Check if there is an post-divider register. If not
+* assume od bits are part of control register.
+*/
+   i = of_property_match_string(node, "reg-names",
+"post-divider");
+   pll_data->pllod = of_iomap(node, i);
}

i = of_property_match_string(node, "reg-names", "control");
pll_data->pll_ctl0 = of_iomap(node, i);
if (!pll_data->pll_ctl0) {
pr_err("%s: ioremap failed\n", __func__);
+   iounmap(pll_data->pllod);
goto out;
}

@@ -193,6 +208,7 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
pll_data->pllm = of_iomap(node, i);
if (!pll_data->pllm) {
iounmap(pll_data->pll_ctl0);
+   iounmap(pll_data->pllod);
goto out;
}
}


DT and CLK maintainers,

A gentle reminder to review and provide your comments or acks.

Thanks and regards,

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] clk: keystone: add support for post divider register for main pll

[Murali Karicheri]

On 05/29/2015 12:04 PM, Murali Karicheri wrote:

Main PLL controller has post divider bits in a separate register in
pll controller. Use the value from this register instead of fixed
divider when available.

Signed-off-by: Murali Karicheri 
---
  .../devicetree/bindings/clock/keystone-pll.txt   |  8 
  drivers/clk/keystone/pll.c   | 20 ++--
  2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt 
b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 225990f..47570d2 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -15,8 +15,8 @@ Required properties:
  - compatible : shall be "ti,keystone,main-pll-clock" or 
"ti,keystone,pll-clock"
  - clocks : parent clock phandle
  - reg - pll control0 and pll multipler registers
-- reg-names : control and multiplier. The multiplier is applicable only for
-   main pll clock
+- reg-names : control, multiplier and post-divider. The multiplier and
+   post-divider registers are applicable only for main pll clock
  - fixed-postdiv : fixed post divider value. If absent, use clkod register bits
for postdiv

@@ -25,8 +25,8 @@ Example:
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
fixed-postdiv = <2>;
};

diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 0dd8a4b..4a375ea 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -37,7 +37,8 @@
   *Main PLL or any other PLLs in the device such as ARM PLL, DDR PLL
   *or PA PLL available on keystone2. These PLLs are controlled by
   *this register. Main PLL is controlled by a PLL controller.
- * @pllm: PLL register map address
+ * @pllm: PLL register map address for multiplier bits
+ * @pllod: PLL register map address for post divider bits
   * @pll_ctl0: PLL controller map address
   * @pllm_lower_mask: multiplier lower mask
   * @pllm_upper_mask: multiplier upper mask
@@ -53,6 +54,7 @@ struct clk_pll_data {
u32 phy_pllm;
u32 phy_pll_ctl0;
void __iomem *pllm;
+   void __iomem *pllod;
void __iomem *pll_ctl0;
u32 pllm_lower_mask;
u32 pllm_upper_mask;
@@ -102,7 +104,11 @@ static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
/* read post divider from od bits*/
postdiv = ((val & pll_data->clkod_mask) >>
 pll_data->clkod_shift) + 1;
-   else
+   else if (pll_data->pllod) {
+   postdiv = readl(pll_data->pllod);
+   postdiv = ((postdiv & pll_data->clkod_mask) >>
+   pll_data->clkod_shift) + 1;
+   } else
postdiv = pll_data->postdiv;

rate /= (prediv + 1);
@@ -172,12 +178,21 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
/* assume the PLL has output divider register bits */
pll_data->clkod_mask = CLKOD_MASK;
pll_data->clkod_shift = CLKOD_SHIFT;
+
+   /*
+* Check if there is an post-divider register. If not
+* assume od bits are part of control register.
+*/
+   i = of_property_match_string(node, "reg-names",
+"post-divider");
+   pll_data->pllod = of_iomap(node, i);
}

i = of_property_match_string(node, "reg-names", "control");
pll_data->pll_ctl0 = of_iomap(node, i);
if (!pll_data->pll_ctl0) {
pr_err("%s: ioremap failed\n", __func__);
+   iounmap(pll_data->pllod);
goto out;
}

@@ -193,6 +208,7 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
pll_data->pllm = of_iomap(node, i);
if (!pll_data->pllm) {
    iounmap(pll_data->pll_ctl0);
+   iounmap(pll_data->pllod);
goto out;
}
}


Dear Maintainers?

Any comments please? If not, can this be applied?

--
Murali Karicheri
Linux Kernel, Keystone
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: keystone: fix dt bindings to use post div register for mainpll

[Murali Karicheri]

All of the keystone devices have a separate register to hold post
divider value for main pll clock. Currently the fixed-postdiv
value used for k2hk/l/e SoCs works by sheer luck as u-boot happens to
use a value of 2 for this. Now that we have fixed this in the pll
clock driver change the dt bindings for the same.

Signed-off-by: Murali Karicheri 
---
 arch/arm/boot/dts/k2e-clocks.dtsi  | 5 ++---
 arch/arm/boot/dts/k2hk-clocks.dtsi | 5 ++---
 arch/arm/boot/dts/k2l-clocks.dtsi  | 5 ++---
 3 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/k2e-clocks.dtsi 
b/arch/arm/boot/dts/k2e-clocks.dtsi
index 4773d6a..d56d68f 100644
--- a/arch/arm/boot/dts/k2e-clocks.dtsi
+++ b/arch/arm/boot/dts/k2e-clocks.dtsi
@@ -13,9 +13,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};
 
papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2hk-clocks.dtsi 
b/arch/arm/boot/dts/k2hk-clocks.dtsi
index d5adee3..af9b719 100644
--- a/arch/arm/boot/dts/k2hk-clocks.dtsi
+++ b/arch/arm/boot/dts/k2hk-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};
 
papllclk: papllclk@2620358 {
diff --git a/arch/arm/boot/dts/k2l-clocks.dtsi 
b/arch/arm/boot/dts/k2l-clocks.dtsi
index eb1e3e2..ef8464b 100644
--- a/arch/arm/boot/dts/k2l-clocks.dtsi
+++ b/arch/arm/boot/dts/k2l-clocks.dtsi
@@ -22,9 +22,8 @@ clocks {
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
-   fixed-postdiv = <2>;
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
};
 
papllclk: papllclk@2620358 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] clk: keystone: add support for post divider register for main pll

[Murali Karicheri]

Main PLL controller has post divider bits in a separate register in
pll controller. Use the value from this register instead of fixed
divider when available.

Signed-off-by: Murali Karicheri 
---
 .../devicetree/bindings/clock/keystone-pll.txt   |  8 
 drivers/clk/keystone/pll.c   | 20 ++--
 2 files changed, 22 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt 
b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 225990f..47570d2 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -15,8 +15,8 @@ Required properties:
 - compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
 - clocks : parent clock phandle
 - reg - pll control0 and pll multipler registers
-- reg-names : control and multiplier. The multiplier is applicable only for
-   main pll clock
+- reg-names : control, multiplier and post-divider. The multiplier and
+   post-divider registers are applicable only for main pll clock
 - fixed-postdiv : fixed post divider value. If absent, use clkod register bits
for postdiv
 
@@ -25,8 +25,8 @@ Example:
#clock-cells = <0>;
compatible = "ti,keystone,main-pll-clock";
clocks = <&refclksys>;
-   reg = <0x02620350 4>, <0x02310110 4>;
-   reg-names = "control", "multiplier";
+   reg = <0x02620350 4>, <0x02310110 4>, <0x02310108 4>;
+   reg-names = "control", "multiplier", "post-divider";
fixed-postdiv = <2>;
};
 
diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 0dd8a4b..4a375ea 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -37,7 +37,8 @@
  * Main PLL or any other PLLs in the device such as ARM PLL, DDR PLL
  * or PA PLL available on keystone2. These PLLs are controlled by
  * this register. Main PLL is controlled by a PLL controller.
- * @pllm: PLL register map address
+ * @pllm: PLL register map address for multiplier bits
+ * @pllod: PLL register map address for post divider bits
  * @pll_ctl0: PLL controller map address
  * @pllm_lower_mask: multiplier lower mask
  * @pllm_upper_mask: multiplier upper mask
@@ -53,6 +54,7 @@ struct clk_pll_data {
u32 phy_pllm;
u32 phy_pll_ctl0;
void __iomem *pllm;
+   void __iomem *pllod;
void __iomem *pll_ctl0;
u32 pllm_lower_mask;
u32 pllm_upper_mask;
@@ -102,7 +104,11 @@ static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
/* read post divider from od bits*/
postdiv = ((val & pll_data->clkod_mask) >>
 pll_data->clkod_shift) + 1;
-   else
+   else if (pll_data->pllod) {
+   postdiv = readl(pll_data->pllod);
+   postdiv = ((postdiv & pll_data->clkod_mask) >>
+   pll_data->clkod_shift) + 1;
+   } else
postdiv = pll_data->postdiv;
 
rate /= (prediv + 1);
@@ -172,12 +178,21 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
/* assume the PLL has output divider register bits */
pll_data->clkod_mask = CLKOD_MASK;
pll_data->clkod_shift = CLKOD_SHIFT;
+
+   /*
+* Check if there is an post-divider register. If not
+* assume od bits are part of control register.
+*/
+   i = of_property_match_string(node, "reg-names",
+"post-divider");
+   pll_data->pllod = of_iomap(node, i);
}
 
i = of_property_match_string(node, "reg-names", "control");
pll_data->pll_ctl0 = of_iomap(node, i);
if (!pll_data->pll_ctl0) {
pr_err("%s: ioremap failed\n", __func__);
+   iounmap(pll_data->pllod);
goto out;
}
 
@@ -193,6 +208,7 @@ static void __init _of_pll_clk_init(struct device_node 
*node, bool pllctrl)
pll_data->pllm = of_iomap(node, i);
if (!pll_data->pllm) {
iounmap(pll_data->pll_ctl0);
+   iounmap(pll_data->pllod);
goto out;
}
}
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC] PCI: designware: missing *config* reg space

[Murali Karicheri]

All,

I would like to take action to resolve the following print message 
thrown by PCI designware core driver when kernel boots up on Keystone.


[0.415778] keystone-pcie 21801000.pcie: missing *config* reg space

As per DT documentation introduced by commit 
4dd964df36d0e548e1806ec2ec275b62d4dc46e8 "PCI: designware: Look for 
configuration space in 'reg', not 'ranges'


This is introduced to stop abusing the range property for defining 
resource for config space. However if the device binding doesn't have

reg-name = "config" defined, this throws out an unnecessary log message
at boot which seems to me not right. AFAIK, reg-names is not mandatory.
config space address in Keystone case is defined using index. So for
keystone this needs to be fixed.

I propose to add the following check in the designware code to address
this. Keystone uses an older version of the Designware IP and doesn't 
have the ATU support. So va_cfg0_base and va_cfg1_base are already set 
up in ks_dw_pcie_host_init() before calling dw_pcie_host_init() and 
points to the remote config space address (both same for keystone). I 
think for other DW drivers, these variables are NULL. So add a check and 
avoid this error message for Keystone. Any comments?



--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -348,7 +348,7 @@ int dw_pcie_host_init(struct pcie_port *pp)
struct platform_device *pdev = to_platform_device(pp->dev);
struct of_pci_range range;
struct of_pci_range_parser parser;
-   struct resource *cfg_res;
+   struct resource *cfg_res = NULL;
u32 val, na, ns;
const __be32 *addrp;
int i, index, ret;
@@ -359,7 +359,11 @@ int dw_pcie_host_init(struct pcie_port *pp)
of_property_read_u32(np, "#address-cells", &na);
ns = of_n_size_cells(np);

-   cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
"config");

+   if (!pp->va_cfg0_base && !pp->va_cfg0_base)
+   cfg_res = platform_get_resource_byname(pdev,
+  IORESOURCE_MEM,
+  "config");
+
if (cfg_res) {
pp->cfg0_size = resource_size(cfg_res)/2;
pp->cfg1_size = resource_size(cfg_res)/2;
@@ -372,7 +376,8 @@ int dw_pcie_host_init(struct pcie_port *pp)
pp->cfg0_mod_base = of_read_number(addrp, ns);
pp->cfg1_mod_base = pp->cfg0_mod_base + pp->cfg0_size;
} else {
-   dev_err(pp->dev, "missing *config* reg space\n");
+   if (!pp->va_cfg0_base && !pp->va_cfg1_base)
+   dev_err(pp->dev, "missing *config* reg space\n");
}



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net-next 0/5] NetCP: Add support for version 1.5

[Murali Karicheri]

On 03/20/2015 10:03 PM, David Miller wrote:

From: Murali Karicheri
Date: Fri, 20 Mar 2015 16:11:20 -0400


NetCP 1.5 is used in newer K2 SoCs from Texas Instruments
such as K2E, K2L etc. This patch series add support for Ethss
driver for this version of NetCP. While at it, fix couple of
bugs in the original driver.

One of the earlier patch "net: netcp: select davinci_mdio driver
by default" is folded onto this series.

Please review and let me know your comments.


Series applied to net-next, thanks.

David,

Thanks for applying the series.

Regards,
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] of/pci : fix of_pci_dma_configure parent ptr NULL

[Murali Karicheri]

On 03/19/2015 11:01 AM, Bjorn Helgaas wrote:

On Wed, Mar 11, 2015 at 12:40:03PM -0400, Murali Karicheri wrote:

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri
Acked-by: Rob Herring


Since I hadn't merged the original patch yet, I just folded this fix into
it.  The series is on pci/iommu, and I merged it for "next".  Thanks for
your patience.

Bjorn


Thanks!

Murali



---
  drivers/of/of_pci.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev =&pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);

+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
  }
--
1.7.9.5




--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 1/5] net: netcp: fix forward port number usage for 10G ethss

[Murali Karicheri]

10G switch requires forward port number in the taginfo field,
where as it should be in packet_info field for necp 1.4 Ethss. So
fill this value correctly in the knav dma descriptor.

Also rename dma_psflags field in struct netcp_tx_pipe to switch_to_port
as it contain no flag, but the switch port number for forwarding the
packet. Add a flag to hold the new flag,  SWITCH_TO_PORT_IN_TAGINFO which
will be set for 10G. This can also used in the future for other flags for
the tx_pipe.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 drivers/net/ethernet/ti/netcp.h   |5 -
 drivers/net/ethernet/ti/netcp_core.c  |   23 +++
 drivers/net/ethernet/ti/netcp_ethss.c |   14 ++
 3 files changed, 29 insertions(+), 13 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp.h b/drivers/net/ethernet/ti/netcp.h
index 906e9bc..bbacf5c 100644
--- a/drivers/net/ethernet/ti/netcp.h
+++ b/drivers/net/ethernet/ti/netcp.h
@@ -41,7 +41,10 @@ struct netcp_tx_pipe {
struct netcp_device *netcp_device;
void*dma_queue;
unsigned intdma_queue_id;
-   u8  dma_psflags;
+   /* To port for packet forwarded to switch. Used only by ethss */
+   u8  switch_to_port;
+#defineSWITCH_TO_PORT_IN_TAGINFO   BIT(0)
+   u8  flags;
void*dma_channel;
const char  *dma_chan_name;
 };
diff --git a/drivers/net/ethernet/ti/netcp_core.c 
b/drivers/net/ethernet/ti/netcp_core.c
index a31a8c3..d867636 100644
--- a/drivers/net/ethernet/ti/netcp_core.c
+++ b/drivers/net/ethernet/ti/netcp_core.c
@@ -1098,9 +1098,9 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
struct netcp_tx_pipe *tx_pipe = NULL;
struct netcp_hook_list *tx_hook;
struct netcp_packet p_info;
-   u32 packet_info = 0;
unsigned int dma_sz;
dma_addr_t dma;
+   u32 tmp = 0;
int ret = 0;
 
p_info.netcp = netcp;
@@ -1140,20 +1140,27 @@ static int netcp_tx_submit_skb(struct netcp_intf *netcp,
memmove(p_info.psdata, p_info.psdata + p_info.psdata_len,
p_info.psdata_len);
set_words(psdata, p_info.psdata_len, psdata);
-   packet_info |=
-   (p_info.psdata_len & KNAV_DMA_DESC_PSLEN_MASK) <<
+   tmp |= (p_info.psdata_len & KNAV_DMA_DESC_PSLEN_MASK) <<
KNAV_DMA_DESC_PSLEN_SHIFT;
}
 
-   packet_info |= KNAV_DMA_DESC_HAS_EPIB |
+   tmp |= KNAV_DMA_DESC_HAS_EPIB |
((netcp->tx_compl_qid & KNAV_DMA_DESC_RETQ_MASK) <<
-   KNAV_DMA_DESC_RETQ_SHIFT) |
-   ((tx_pipe->dma_psflags & KNAV_DMA_DESC_PSFLAG_MASK) <<
-   KNAV_DMA_DESC_PSFLAG_SHIFT);
+   KNAV_DMA_DESC_RETQ_SHIFT);
 
-   set_words(&packet_info, 1, &desc->packet_info);
+   if (!(tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO)) {
+   tmp |= ((tx_pipe->switch_to_port & KNAV_DMA_DESC_PSFLAG_MASK) <<
+   KNAV_DMA_DESC_PSFLAG_SHIFT);
+   }
+
+   set_words(&tmp, 1, &desc->packet_info);
set_words((u32 *)&skb, 1, &desc->pad[0]);
 
+   if (tx_pipe->flags & SWITCH_TO_PORT_IN_TAGINFO) {
+   tmp = tx_pipe->switch_to_port;
+   set_words((u32 *)&tmp, 1, &desc->tag_info);
+   }
+
/* submit packet descriptor */
ret = knav_pool_desc_map(netcp->tx_pool, desc, sizeof(*desc), &dma,
 &dma_sz);
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 84f5ce5..2be90a5 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -1472,15 +1472,21 @@ static int gbe_open(void *intf_priv, struct net_device 
*ndev)
GBE_MAJOR_VERSION(reg), GBE_MINOR_VERSION(reg),
GBE_RTL_VERSION(reg), GBE_IDENT(reg));
 
+   /* For 10G use directed to port */
+   if (gbe_dev->ss_version == XGBE_SS_VERSION_10)
+   gbe_intf->tx_pipe.flags = SWITCH_TO_PORT_IN_TAGINFO;
+
if (gbe_dev->enable_ale)
-   gbe_intf->tx_pipe.dma_psflags = 0;
+   gbe_intf->tx_pipe.switch_to_port = 0;
else
-   gbe_intf->tx_pipe.dma_psflags = port_num;
+   gbe_intf->tx_pipe.switch_to_port = port_num;
 
-   dev_dbg(gbe_dev->dev, "opened TX channel %s: %p with psflags %d

[PATCH net-next 2/5] net: netcp: use separate reg region for individual ethss modules

[Murali Karicheri]

Ethss has multiple modules within the sub system
 - switch sub system
 - sgmii
 - mdio
 - switch module

NetCP driver re-uses existing davinci mdio driver. It requires to
have its own register region to map the reg space. So restructure
the code to use separate reg region for the individual modules it
manages. Use range property to define register space of NetCP and
use reg property to define individual reg spaces. So MDIO will have
its own reg space to map. This is a pre-requisite to enable MDIO
driver for NetCP.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 .../devicetree/bindings/net/keystone-netcp.txt |   16 +--
 drivers/net/ethernet/ti/netcp_ethss.c  |  130 ++--
 2 files changed, 102 insertions(+), 44 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt 
b/Documentation/devicetree/bindings/net/keystone-netcp.txt
index f9c0771..8368abd 100644
--- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -49,6 +49,7 @@ Required properties:
 - compatible:  Should be "ti,netcp-1.0"
 - clocks:  phandle to the reference clocks for the subsystem.
 - dma-id:  Navigator packet dma instance id.
+- ranges:  address range of NetCP (includes, Ethernet SS, PA and SA)
 
 Optional properties:
 - reg: register location and the size for the following register
@@ -66,8 +67,10 @@ Required properties:
 - label:   Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
 - reg: register location and the size for the following register
regions in the specified order.
-   - subsystem registers
-   - serdes registers
+   - switch subsystem registers
+   - sgmii port3/4 module registers (only for NetCP 1.4)
+   - switch module registers
+   - serdes registers (only for 10G)
 - tx-channel:  the navigator packet dma channel name for tx.
 - tx-queue:the navigator queue number associated with the tx dma channel.
 - interfaces:  specification for each of the switch port to be registered as a
@@ -120,14 +123,13 @@ Optional properties:
 
 Example binding:
 
-netcp: netcp@209 {
+netcp: netcp@200 {
reg = <0x2620110 0x8>;
reg-names = "efuse";
compatible = "ti,netcp-1.0";
#address-cells = <1>;
#size-cells = <1>;
-   ranges;
-
+   ranges  = <0 0x200 0xf>;
clocks = <&papllclk>, <&clkcpgmac>, <&chipclk12>;
dma-coherent;
/* big-endian; */
@@ -137,9 +139,9 @@ netcp: netcp@209 {
#address-cells = <1>;
#size-cells = <1>;
ranges;
-   gbe@0x209 {
+   gbe@9 {
label = "netcp-gbe";
-   reg = <0x209 0xf00>;
+   reg = <0x9 0x300>, <0x90400 0x400>, <0x90800 0x700>;
/* enable-ale; */
tx-queue = <648>;
tx-channel = <8>;
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 2be90a5..42592b8 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -40,15 +40,18 @@
 #define GBE_MODULE_NAME"netcp-gbe"
 #define GBE_SS_VERSION_14  0x4ed21104
 
+#define GBE_SS_REG_INDEX   0
+#define GBE_SGMII34_REG_INDEX  1
+#define GBE_SM_REG_INDEX   2
+/* offset relative to base of GBE_SS_REG_INDEX */
 #define GBE13_SGMII_MODULE_OFFSET  0x100
-#define GBE13_SGMII34_MODULE_OFFSET0x400
-#define GBE13_SWITCH_MODULE_OFFSET 0x800
-#define GBE13_HOST_PORT_OFFSET 0x834
-#define GBE13_SLAVE_PORT_OFFSET0x860
-#define GBE13_EMAC_OFFSET  0x900
-#define GBE13_SLAVE_PORT2_OFFSET   0xa00
-#define GBE13_HW_STATS_OFFSET  0xb00
-#define GBE13_ALE_OFFSET   0xe00
+/* offset relative to base of GBE_SM_REG_INDEX */
+#define GBE13_HOST_PORT_OFFSET 0x34
+#define GBE13_SLAVE_PORT_OFFSET0x60
+#define GBE13_EMAC_OFFSET  0x100
+#define GBE13_SLAVE_PORT2_OFFSET   0x200
+#define GBE13_HW_STATS_OFFSET  0x300
+#define GBE13_ALE_OFFSET   0x600
 #define GBE13_HOST_PORT_NUM0
 #define GBE13_NUM_SLAVES   4
 #define GBE13_NUM_ALE_PORTS(GBE13_NUM_SLAVES + 1)
@@ -58,14 +61,18 @@
 #define XGBE_MODULE

[PATCH net-next 3/5] net: netcp: select davinci_mdio driver by default

[Murali Karicheri]

Keystone netcp driver re-uses davinci mdio driver. So enable it
by default for keystone netcp driver.

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 drivers/net/ethernet/ti/Kconfig |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index f6a7109..631e0af 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -88,6 +88,7 @@ config TI_CPTS
 config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_CPSW_ALE
+   select TI_DAVINCI_MDIO
depends on OF
depends on KEYSTONE_NAVIGATOR_DMA && KEYSTONE_NAVIGATOR_QMSS
---help---
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 4/5] net: netcp: enclose macros in parentheses

[Murali Karicheri]

Fix following checkpatch error. It seems to have passed checkpatch
last time when original code was introduced.

 ERROR: Macros with complex values should be enclosed in parentheses
 #172: FILE: drivers/net/ethernet/ti/netcp_ethss.c:869:

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 

---
 drivers/net/ethernet/ti/netcp_ethss.c |  523 +
 1 file changed, 272 insertions(+), 251 deletions(-)

diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index 42592b8..f8f3be3 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -482,275 +482,296 @@ struct netcp_ethtool_stat {
int offset;
 };
 
-#define GBE_STATSA_INFO(field) "GBE_A:"#field, GBE_STATSA_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSA_INFO(field) \
+{  \
+   "GBE_A:"#field, GBE_STATSA_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSB_INFO(field) "GBE_B:"#field, GBE_STATSB_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSB_INFO(field) \
+{  \
+   "GBE_B:"#field, GBE_STATSB_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSC_INFO(field) "GBE_C:"#field, GBE_STATSC_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSC_INFO(field) \
+{  \
+   "GBE_C:"#field, GBE_STATSC_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
-#define GBE_STATSD_INFO(field) "GBE_D:"#field, GBE_STATSD_MODULE,\
-   FIELD_SIZEOF(struct gbe_hw_stats, field), \
-   offsetof(struct gbe_hw_stats, field)
+#define GBE_STATSD_INFO(field) \
+{  \
+   "GBE_D:"#field, GBE_STATSD_MODULE,  \
+   FIELD_SIZEOF(struct gbe_hw_stats, field),   \
+   offsetof(struct gbe_hw_stats, field)\
+}
 
 static const struct netcp_ethtool_stat gbe13_et_stats[] = {
/* GBE module A */
-   {GBE_STATSA_INFO(rx_good_frames)},
-   {GBE_STATSA_INFO(rx_broadcast_frames)},
-   {GBE_STATSA_INFO(rx_multicast_frames)},
-   {GBE_STATSA_INFO(rx_pause_frames)},
-   {GBE_STATSA_INFO(rx_crc_errors)},
-   {GBE_STATSA_INFO(rx_align_code_errors)},
-   {GBE_STATSA_INFO(rx_oversized_frames)},
-   {GBE_STATSA_INFO(rx_jabber_frames)},
-   {GBE_STATSA_INFO(rx_undersized_frames)},
-   {GBE_STATSA_INFO(rx_fragments)},
-   {GBE_STATSA_INFO(rx_bytes)},
-   {GBE_STATSA_INFO(tx_good_frames)},
-   {GBE_STATSA_INFO(tx_broadcast_frames)},
-   {GBE_STATSA_INFO(tx_multicast_frames)},
-   {GBE_STATSA_INFO(tx_pause_frames)},
-   {GBE_STATSA_INFO(tx_deferred_frames)},
-   {GBE_STATSA_INFO(tx_collision_frames)},
-   {GBE_STATSA_INFO(tx_single_coll_frames)},
-   {GBE_STATSA_INFO(tx_mult_coll_frames)},
-   {GBE_STATSA_INFO(tx_excessive_collisions)},
-   {GBE_STATSA_INFO(tx_late_collisions)},
-   {GBE_STATSA_INFO(tx_underrun)},
-   {GBE_STATSA_INFO(tx_carrier_sense_errors)},
-   {GBE_STATSA_INFO(tx_bytes)},
-   {GBE_STATSA_INFO(tx_64byte_frames)},
-   {GBE_STATSA_INFO(tx_65_to_127byte_frames)},
-   {GBE_STATSA_INFO(tx_128_to_255byte_frames)},
-   {GBE_STATSA_INFO(tx_256_to_511byte_frames)},
-   {GBE_STATSA_INFO(tx_512_to_1023byte_frames)},
-   {GBE_STATSA_INFO(tx_1024byte_frames)},
-   {GBE_STATSA_INFO(net_bytes)},
-   {GBE

[PATCH net-next 0/5] NetCP: Add support for version 1.5

[Murali Karicheri]

NetCP 1.5 is used in newer K2 SoCs from Texas Instruments
such as K2E, K2L etc. This patch series add support for Ethss
driver for this version of NetCP. While at it, fix couple of
bugs in the original driver.

One of the earlier patch "net: netcp: select davinci_mdio driver
by default" is folded onto this series.

Please review and let me know your comments.

Thanks 

CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 

Murali Karicheri (4):
  net: netcp: fix forward port number usage for 10G ethss
  net: netcp: use separate reg region for individual ethss modules
  net: netcp: select davinci_mdio driver by default
  net: netcp: enclose macros in parentheses

WingMan Kwok (1):
  net: netcp: ethss: enhancement to support NetCP 1.5 ethss

 .../devicetree/bindings/net/keystone-netcp.txt |   34 +-
 drivers/net/ethernet/ti/Kconfig|1 +
 drivers/net/ethernet/ti/netcp.h|5 +-
 drivers/net/ethernet/ti/netcp_core.c   |   23 +-
 drivers/net/ethernet/ti/netcp_ethss.c  | 1581 
 5 files changed, 1303 insertions(+), 341 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH net-next 5/5] net: netcp: ethss: enhancement to support NetCP 1.5 ethss

[Murali Karicheri]

From: WingMan Kwok 

NetCP 1.5 available on newer K2 SoCs such as K2E and K2L introduced 3
variants of the ethss subsystem, 9 port, 5 port and 2 port. These have
one host port towards the CPU and N external slave ports.

To customize the driver for these new ethss sub systems, multiple
compatibility strings are introduced. Currently some of parameters that
are different on different variants such as number of ALE ports, stats
modules and number of ports are defined through constants. These are now
changed to variables in gbe_priv data that get set based on the
compatibility string. This is required as there are no hardware
identification registers available to distinguish among the variants
of NetCP 1.5 ethss. However there is identification register available
to differentiate between NetCP 1.4 vs NetCP 1.5 and the same is made use
of in the code to differentiate them.

For more reading on the details of this peripheral, please refer to the
User Guide available at http://www.ti.com/lit/pdf/spruhz3

Signed-off-by: Murali Karicheri 
Signed-off-by: WingMan Kwok 
CC: "David S. Miller" 
CC: Mugunthan V N 
CC: "Lad, Prabhakar" 
CC: Grygorii Strashko 
CC: Christoph Jaeger 
CC: Lokesh Vutla 
CC: Markus Pargmann 
CC: Kumar Gala 
CC: Ian Campbell 
CC: Mark Rutland 
CC: Pawel Moll 
CC: Rob Herring 
---
 .../devicetree/bindings/net/keystone-netcp.txt |   18 +
 drivers/net/ethernet/ti/netcp_ethss.c  |  920 +++-
 2 files changed, 902 insertions(+), 36 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/keystone-netcp.txt 
b/Documentation/devicetree/bindings/net/keystone-netcp.txt
index 8368abd..d0e6fa3 100644
--- a/Documentation/devicetree/bindings/net/keystone-netcp.txt
+++ b/Documentation/devicetree/bindings/net/keystone-netcp.txt
@@ -65,12 +65,30 @@ NetCP device properties: Device specification for NetCP 
sub-modules.
 1Gb/10Gb (gbe/xgbe) ethernet switch sub-module specifications.
 Required properties:
 - label:   Must be "netcp-gbe" for 1Gb & "netcp-xgbe" for 10Gb.
+- compatible:  Must be one of below:-
+   "ti,netcp-gbe" for 1GbE on NetCP 1.4
+   "ti,netcp-gbe-5" for 1GbE N NetCP 1.5 (N=5)
+   "ti,netcp-gbe-9" for 1GbE N NetCP 1.5 (N=9)
+   "ti,netcp-gbe-2" for 1GbE N NetCP 1.5 (N=2)
+   "ti,netcp-xgbe" for 10 GbE
+
 - reg: register location and the size for the following register
regions in the specified order.
- switch subsystem registers
- sgmii port3/4 module registers (only for NetCP 1.4)
- switch module registers
- serdes registers (only for 10G)
+
+   NetCP 1.4 ethss, here is the order
+   index #0 - switch subsystem registers
+   index #1 - sgmii port3/4 module registers
+   index #2 - switch module registers
+
+   NetCP 1.5 ethss 9 port, 5 port and 2 port
+   index #0 - switch subsystem registers
+   index #1 - switch module registers
+   index #2 - serdes registers
+
 - tx-channel:  the navigator packet dma channel name for tx.
 - tx-queue:the navigator queue number associated with the tx dma channel.
 - interfaces:  specification for each of the switch port to be registered as a
diff --git a/drivers/net/ethernet/ti/netcp_ethss.c 
b/drivers/net/ethernet/ti/netcp_ethss.c
index f8f3be3..2bef655 100644
--- a/drivers/net/ethernet/ti/netcp_ethss.c
+++ b/drivers/net/ethernet/ti/netcp_ethss.c
@@ -53,10 +53,31 @@
 #define GBE13_HW_STATS_OFFSET  0x300
 #define GBE13_ALE_OFFSET   0x600
 #define GBE13_HOST_PORT_NUM0
-#define GBE13_NUM_SLAVES   4
-#define GBE13_NUM_ALE_PORTS(GBE13_NUM_SLAVES + 1)
 #define GBE13_NUM_ALE_ENTRIES  1024
 
+/* 1G Ethernet NU SS defines */
+#define GBENU_MODULE_NAME  "netcp-gbenu"
+#define GBE_SS_ID_NU   0x4ee6
+#define GBE_SS_ID_2U   0x4ee8
+
+#define IS_SS_ID_MU(d) \
+   ((GBE_IDENT((d)->ss_version) == GBE_SS_ID_NU) || \
+(GBE_IDENT((d)->ss_version) == GBE_SS_ID_2U))
+
+#define IS_SS_ID_NU(d) \
+   (GBE_IDENT((d)->ss_version) == GBE_SS_ID_NU)
+
+#define GBENU_SS_REG_INDEX 0
+#define GBENU_SM_REG_INDEX 1
+#define GBENU_SGMII_MODULE_OFFSET  0x100
+#define GBENU_HOST_PORT_OFFSET 0x1000
+#define GBENU_SLAVE_PORT_OFFSET0x2000
+#define GBENU_EMAC_OFFSET  0x2330
+#define GBENU_HW_STATS_OFFSET  0x1a000
+#define GBENU_ALE_OFFSET   0x1e000
+#define GBENU_HOST_PORT_NUM0
+#define GBENU_NUM_ALE_ENTRIES  1024
+
 /* 10G Ethernet SS defines */
 #define XGBE_MODULE_NAME   "netcp-xgbe"
 #define XGBE_SS_VERSIO

Re: [PATCH v1] of/pci : fix of_pci_dma_configure parent ptr NULL

[Murali Karicheri]

On 03/11/2015 12:40 PM, Murali Karicheri wrote:

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri
Acked-by: Rob Herring
---
  drivers/of/of_pci.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev =&pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);

+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
  }


BJorn,

Just wondering if you can apply this to pci/iommu to help provide enough 
baking time for this series to make into next kernel merge window.


As always, thanks for all your help.

Regards,
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1] of/pci : fix of_pci_dma_configure parent ptr NULL

[Murali Karicheri]

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri 
Acked-by: Rob Herring
---
 drivers/of/of_pci.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev = &pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);
 
+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On 03/11/2015 11:59 AM, Rob Herring wrote:

On Wed, Mar 11, 2015 at 10:28 AM, Murali Karicheri  wrote:

On 03/11/2015 08:49 AM, Russell King - ARM Linux wrote:


On Wed, Mar 11, 2015 at 07:35:45AM -0500, Rob Herring wrote:


On Tue, Mar 10, 2015 at 10:25 AM, Murali Karicheri
wrote:


On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()



Wouldn't these arches have OF disabled and call an empty function?
Regardless, we still need this.


Signed-off-by: Murali Karicheri



I'm assuming Bjorn will apply this.



Yes. That is my understanding as well. I missed to answer this in my 
earlier email.



Acked-by: Rob Herring





--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On 03/11/2015 11:59 AM, Rob Herring wrote:

On Wed, Mar 11, 2015 at 10:28 AM, Murali Karicheri  wrote:

On 03/11/2015 08:49 AM, Russell King - ARM Linux wrote:


On Wed, Mar 11, 2015 at 07:35:45AM -0500, Rob Herring wrote:


On Tue, Mar 10, 2015 at 10:25 AM, Murali Karicheri
wrote:


On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()



Wouldn't these arches have OF disabled and call an empty function?
Regardless, we still need this.


Signed-off-by: Murali Karicheri



I'm assuming Bjorn will apply this.

Acked-by: Rob Herring



It might be an idea to read the subject line...

"fix BUG: unable to handle kernel"


Russell,

I will fix the subject as "fix BUG: unable to handle kernel NULL pointer"
and re-send.


Russell's point is the subject applies to every fix for a BUG.
Something like "of/pci: fix of_pci_dma_configure parent ptr NULL
dereference".

Ok. Got it.


Rob



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On 03/11/2015 08:49 AM, Russell King - ARM Linux wrote:

On Wed, Mar 11, 2015 at 07:35:45AM -0500, Rob Herring wrote:

On Tue, Mar 10, 2015 at 10:25 AM, Murali Karicheri  wrote:

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()


Wouldn't these arches have OF disabled and call an empty function?
Regardless, we still need this.


Signed-off-by: Murali Karicheri


I'm assuming Bjorn will apply this.

Acked-by: Rob Herring


It might be an idea to read the subject line...

"fix BUG: unable to handle kernel"

Russell,

I will fix the subject as "fix BUG: unable to handle kernel NULL 
pointer" and re-send.


Thanks

Murali


which is meaningless.  It needs a much better subject line before it can
be committed.




--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On 03/11/2015 08:35 AM, Rob Herring wrote:

On Tue, Mar 10, 2015 at 10:25 AM, Murali Karicheri  wrote:

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()


Wouldn't these arches have OF disabled and call an empty function?

The current patch series does have a empty function if OF is disabled.

Regardless, we still need this.
These archs have OF enabled, but they call  pci_create_root_bus() with 
NULL parent node passed in. That is why the crash happens.


Murali



Signed-off-by: Murali Karicheri


I'm assuming Bjorn will apply this.

Acked-by: Rob Herring


---
  drivers/of/of_pci.c |4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
 struct device *dev =&pci_dev->dev;
 struct device *bridge = pci_get_host_bridge_device(pci_dev);

+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
 of_dma_configure(dev, bridge->parent->of_node);
 pci_put_host_bridge_device(bridge);
  }
--
1.7.9.5


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] pci: of : fix BUG: unable to handle kernel

[Murali Karicheri]

On some platforms such as that based on x86, ia64 etc, root bus is
created with parent node passed in as NULL to pci_create_root_bus().
On these platforms, the patch series "PCI: get DMA configuration from
parent device" when applied causes kernel crash. So add a check for this
in of_pci_dma_configure()

Signed-off-by: Murali Karicheri 
---
 drivers/of/of_pci.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 86d3c38..a8e485c 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -129,6 +129,10 @@ void of_pci_dma_configure(struct pci_dev *pci_dev)
struct device *dev = &pci_dev->dev;
struct device *bridge = pci_get_host_bridge_device(pci_dev);
 
+   /* Some platforms can have bridge->parent set to NULL */
+   if (!bridge->parent)
+   return;
+
of_dma_configure(dev, bridge->parent->of_node);
pci_put_host_bridge_device(bridge);
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use

[Murali Karicheri]

On 03/03/2015 03:53 PM, Bjorn Helgaas wrote:

[+cc linux-pci]

On Tue, Mar 3, 2015 at 11:55 AM, Murali Karicheri  wrote:

On 03/02/2015 10:43 PM, Bjorn Helgaas wrote:


On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri
wrote:


Move of_dma_configure() to device.c so it can be re-used for PCI devices
to
obtain DMA configuration from DT.  Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.

Tested-by: Suravee Suthikulpanit   (AMD
Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
   - Based on the existing patch applied to arm-pci/pci/iommu for pci next
(Bjorn)
   - Fixed the build issue reported on ARCH=x86_64



Hi Murali,

Can you please repost the entire series with fixed patches?  It's
easier for me to reapply the whole thing at once than it is to keep
track of and fiddle with individual patches.

Bjorn


Bjorn,

Ok. I have just posted v8 of the series including all patches.


Thanks, I put them on a pci/murali-v8 branch for now.  I'm assuming
you want them to go through my tree.  In the cover letter, you
mentioned the "arm-pci iommu branch", so if that means you want them
via an ARM tree instead of mine, just let me know.  I assume the build
will be clean and I'll rename it back to pci/iommu.


My bad. It should have beem pci/iommu. My remote was named arm-pci and 
hence the confusion. Please apply it to the pci/iommu branch.


Thanks

Murali


Bjorn



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] of: calculate masks of the device based on dma-range size

[Murali Karicheri]

On 02/25/2015 07:20 PM, Bjorn Helgaas wrote:

[+cc Catalin]

On Wed, Feb 11, 2015 at 12:53:35PM -0500, Murali Karicheri wrote:

This patch update of_dma_configure() API to calculate the
masks (dma_mask and coherent_dma_mask) based on the dma-range
values set in DT for the device. Also limit the mask to lower
of the default mask and mask calculated.

Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit

Signed-off-by: Murali Karicheri


Applied with Catalin's reviewed-by to pci/iommu for v4.1, thanks!

Bjorn,

Could you point me to this? I didn't see it on pci/iommu of your repo below.

arm-pci	git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
(fetch)


a0868495@ula0868495 ~/Project/linux-keystone $ gitlog arm-pci/pci/iommu
dd8a11b0f0d4ed0ad87c8d09e650f354021d7953 arm: dma-mapping: limit IOMMU 
mapping size
2a101e79dcd8733e3a353b0df2fa384980f94e1e PCI: Update DMA configuration 
from DT
3fd29d06e9aa92d9a4513e14b2dd3f0d69d4d2b7 of/pci: Add 
of_pci_dma_configure() to update DMA configuration
8243352097c468f982a9f386cb1f455672b473a2 PCI: Add helper functions 
pci_get[put]_host_bridge_device()
039f346ac880d4f894425ef6c540f3ff5c1b8dcf of: Fix size when dma-range is 
not used
2743a957f6a6317be06d02cc93d78bb2a847e427 of: Move of_dma_configure() to 
device.c to help re-use
f454cd01b5bdffb1bf26a5cddac30439fa5f27a1 of: iommu: Add ptr to OF node 
arg to of_iommu_configure()

c517d838eb7d07bbe9507871fab3931deccff539 Linux 4.0-rc1

Murali



I agree with Catalin's comment about the "size = 1ULL<<  32" line.
I don't see how that will make a difference, so I dropped it.  The
patch I merged is below.  Let me know if you think we do need that
line or any other tweaks.

Bjorn

commit a5a1dd69080dfcf53bfd6e179f3db68e824aeaae
Author: Murali Karicheri
Date:   Wed Feb 25 17:21:04 2015 -0600

 of: Calculate device DMA masks based on DT dma-range size

 Calculate the dma_mask and coherent_dma_mask based on the dma-range values
 set in DT for the device.

 Limit the mask to lower of the default mask and mask calculated.

 Signed-off-by: Murali Karicheri
 Signed-off-by: Bjorn Helgaas
 Reviewed-by: Catalin Marinas
 CC: Joerg Roedel
 CC: Grant Likely
 CC: Rob Herring
 CC: Will Deacon
 CC: Russell King
 CC: Arnd Bergmann
 CC: Suravee Suthikulpanit

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 28e743888402..20c1332a0018 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -90,10 +90,11 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)
struct iommu_ops *iommu;

/*
-* Set default dma-mask to 32 bit.  Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
+* setup the correct supported mask.
 */
-   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+   if (!dev->coherent_dma_mask)
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);

/*
 * Set it to coherent_dma_mask by default if the architecture
@@ -128,6 +129,15 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)

dev->dma_pfn_offset = offset;

+   /*
+* Limit coherent and dma mask based on size and default mask
+* set by the driver.
+*/
+   dev->coherent_dma_mask = min(dev->coherent_dma_mask,
+DMA_BIT_MASK(ilog2(dma_addr + size)));
+   *dev->dma_mask = min((*dev->dma_mask),
+DMA_BIT_MASK(ilog2(dma_addr + size)));
+
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use

[Murali Karicheri]

On 03/02/2015 10:43 PM, Bjorn Helgaas wrote:

On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri  wrote:

Move of_dma_configure() to device.c so it can be re-used for PCI devices to
obtain DMA configuration from DT.  Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
  - Based on the existing patch applied to arm-pci/pci/iommu for pci next 
(Bjorn)
  - Fixed the build issue reported on ARCH=x86_64


Hi Murali,

Can you please repost the entire series with fixed patches?  It's
easier for me to reapply the whole thing at once than it is to keep
track of and fiddle with individual patches.

Bjorn

Bjorn,

Ok. I have just posted v8 of the series including all patches.

FYI.
--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 1/7] of: iommu: Add ptr to OF node arg to of_iommu_configure()

[Murali Karicheri]

of_iommu_configure() is called from of_dma_configure() to setup iommu ops
using DT property.  This API is currently used for platform devices for
which DMA configuration (including IOMMU ops) may come from the device's
parent.  To extend this functionality for PCI devices, this API needs to
take a parent node ptr as an argument instead of assuming device's parent.
This is needed since for PCI, the DMA configuration may be defined in the
DT node of the root bus bridge's parent device.  Currently only dma-range
is used for PCI and IOMMU is not supported.  Return error if the device is
PCI.

Add "parent" parameter (a struct device_node *) to of_iommu_configure().

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Rob Herring 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/iommu/of_iommu.c |   10 --
 drivers/of/platform.c|2 +-
 include/linux/of_iommu.h |6 --
 3 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af1dc6a..43429ab 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct device_node *np)
return ops;
 }
 
-struct iommu_ops *of_iommu_configure(struct device *dev)
+struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *master_np)
 {
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;
 
+   if (dev_is_pci(dev)) {
+   dev_err(dev, "IOMMU is currently not supported for PCI\n");
+   return NULL;
+   }
+
/*
 * We don't currently walk up the tree looking for a parent IOMMU.
 * See the `Notes:' section of
 * Documentation/devicetree/bindings/iommu/iommu.txt
 */
-   while (!of_parse_phandle_with_args(dev->of_node, "iommus",
+   while (!of_parse_phandle_with_args(master_np, "iommus",
   "#iommu-cells", idx,
   &iommu_spec)) {
np = iommu_spec.np;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b189733..667c6f1 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -196,7 +196,7 @@ static void of_dma_configure(struct device *dev)
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");
 
-   iommu = of_iommu_configure(dev);
+   iommu = of_iommu_configure(dev, dev->of_node);
dev_dbg(dev, "device is%sbehind an iommu\n",
iommu ? " " : " not ");
 
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 16c7554..ffbe470 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -12,7 +12,8 @@ extern int of_get_dma_window(struct device_node *dn, const 
char *prefix,
 size_t *size);
 
 extern void of_iommu_init(void);
-extern struct iommu_ops *of_iommu_configure(struct device *dev);
+extern struct iommu_ops *of_iommu_configure(struct device *dev,
+   struct device_node *master_np);
 
 #else
 
@@ -24,7 +25,8 @@ static inline int of_get_dma_window(struct device_node *dn, 
const char *prefix,
 }
 
 static inline void of_iommu_init(void) { }
-static inline struct iommu_ops *of_iommu_configure(struct device *dev)
+static inline struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *master_np)
 {
return NULL;
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 5/7] of/pci: Add of_pci_dma_configure() to update DMA configuration

[Murali Karicheri]

Add of_pci_dma_configure() to allow updating the DMA configuration of the
PCI device using the configuration from DT of the parent of the root bridge
device.  Use the newly added APIs pci_get/put_host_bridge_device() for
implementing this.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Rob Herring 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/of/of_pci.c|   18 ++
 include/linux/of_pci.h |3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 62426d8..86d3c38 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -116,6 +117,23 @@ int of_get_pci_domain_nr(struct device_node *node)
 }
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
+/**
+ * of_pci_dma_configure - Setup DMA configuration
+ * @dev: ptr to pci_dev struct of the pci device
+ *
+ * Function to update PCI devices's DMA configuration using the same
+ * info from the OF node of root host bridge's parent.
+ */
+void of_pci_dma_configure(struct pci_dev *pci_dev)
+{
+   struct device *dev = &pci_dev->dev;
+   struct device *bridge = pci_get_host_bridge_device(pci_dev);
+
+   of_dma_configure(dev, bridge->parent->of_node);
+   pci_put_host_bridge_device(bridge);
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_configure);
+
 #if defined(CONFIG_OF_ADDRESS)
 /**
  * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index ce0e5ab..29fd3fe 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
+void of_pci_dma_configure(struct pci_dev *pci_dev);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -50,6 +51,8 @@ of_get_pci_domain_nr(struct device_node *node)
 {
return -1;
 }
+
+static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 6/7] PCI: Update DMA configuration from DT

[Murali Karicheri]

If there is a DT node available for the root bridge's parent device, use
the DMA configuration from that device node.  For example, Keystone PCI
devices would require dma_pfn_offset to be set correctly in the device
structure of the PCI device in order to have the correct DMA mask.  The DT
node will have dma-ranges defined for this.  Also support using the DT
property dma-coherent to allow coherent DMA operation by the PCI device.

Use the new helper function of_pci_dma_configure() to update the device DMA
configuration.  This fixes DMA on systems where DMA addresses are a
constant offset from CPU physical addresses.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Rob Herring 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/pci/probe.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8d2f400..413c1dd 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus 
*bus)
dev->dev.dma_mask = &dev->dma_mask;
dev->dev.dma_parms = &dev->dma_parms;
dev->dev.coherent_dma_mask = 0xull;
+   of_pci_dma_configure(dev);
 
pci_set_dma_max_seg_size(dev, 65536);
pci_set_dma_seg_boundary(dev, 0x);
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 7/7] arm: dma-mapping: limit IOMMU mapping size

[Murali Karicheri]

arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that
when this is called from the OF code.  So limit the size to
SIZE_MAX.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Rob Herring 
CC: Russell King 
CC: Arnd Bergmann 
---
 arch/arm/mm/dma-mapping.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 170a116..fc81a38 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -2027,6 +2027,13 @@ static bool arm_setup_iommu_dma_ops(struct device *dev, 
u64 dma_base, u64 size,
if (!iommu)
return false;
 
+   /*
+* currently arm_iommu_create_mapping() takes a max of size_t
+* for size param. So check this limit for now.
+*/
+   if (size > SIZE_MAX)
+   return false;
+
mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
if (IS_ERR(mapping)) {
pr_warn("Failed to create %llu-byte IOMMU mapping for device 
%s\n",
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 2/7] of: Move of_dma_configure() to device.c to help re-use

[Murali Karicheri]

Move of_dma_configure() to device.c so it can be re-used for PCI devices to
obtain DMA configuration from DT.  Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
Acked-by: Rob Herring 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/of/device.c   |   59 +
 drivers/of/platform.c |   58 ++--
 include/linux/of_device.h |3 +++
 3 files changed, 64 insertions(+), 56 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 46d6c75c..31a7875 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -2,6 +2,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
return device_add(&ofdev->dev);
 }
 
+/**
+ * of_dma_configure - Setup DMA configuration
+ * @dev:   Device to apply DMA configuration
+ * @np:Pointer to OF node having DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * If platform code needs to use its own special DMA configuration, it
+ * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
+ * to fix up DMA configuration.
+ */
+void of_dma_configure(struct device *dev, struct device_node *np)
+{
+   u64 dma_addr, paddr, size;
+   int ret;
+   bool coherent;
+   unsigned long offset;
+   struct iommu_ops *iommu;
+
+   /*
+* Set default dma-mask to 32 bit.  Drivers are expected to setup
+* the correct supported dma_mask.
+*/
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+   /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+   if (!dev->dma_mask)
+   dev->dma_mask = &dev->coherent_dma_mask;
+
+   ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+   if (ret < 0) {
+   dma_addr = offset = 0;
+   size = dev->coherent_dma_mask;
+   } else {
+   offset = PFN_DOWN(paddr - dma_addr);
+   dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
+   }
+
+   dev->dma_pfn_offset = offset;
+
+   coherent = of_dma_is_coherent(np);
+   dev_dbg(dev, "device is%sdma coherent\n",
+   coherent ? " " : " not ");
+
+   iommu = of_iommu_configure(dev, np);
+   dev_dbg(dev, "device is%sbehind an iommu\n",
+   iommu ? " " : " not ");
+
+   arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+}
+EXPORT_SYMBOL_GPL(of_dma_configure);
+
 int of_device_register(struct platform_device *pdev)
 {
device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 667c6f1..a01f57c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct device_node 
*np,
 }
 EXPORT_SYMBOL(of_device_alloc);
 
-/**
- * of_dma_configure - Setup DMA configuration
- * @dev:   Device to apply DMA configuration
- *
- * Try to get devices's DMA configuration from DT and update it
- * accordingly.
- *
- * In case if platform code need to use own special DMA configuration,it
- * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
- * to fix up DMA configuration.
- */
-static void of_dma_configure(struct device *dev)
-{
-   u64 dma_addr, paddr, size;
-   int ret;
-   bool coherent;
-   unsigned long offset;
-   struct iommu_ops *iommu;
-
-   /*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
-*/
-   dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
-   /*
-* Set it to coherent_dma_mask by default if the architecture
-* code has not set it.
-*/
-   if (!dev->dma_mask)
-   dev->dma_mask = &dev->coherent_dma_mask;
-
-   ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
-   if (ret < 0) {
-   dma_addr = offset = 0;
-   size = dev->coherent_dma_mask;
-   } else {
-   offset = PFN_DOWN(paddr - dma_addr);
-   dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
-   }
-   dev->dma_pfn_offset = offset;
-
-   coherent = of_dma_is_coherent(dev->of_node);
-   

[PATCH v8 4/7] PCI: Add helper functions pci_get[put]_host_bridge_device()

[Murali Karicheri]

Add helper functions to get/put the root bus's host bridge device.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Rob Herring 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/pci/host-bridge.c |   14 ++
 include/linux/pci.h   |3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 39b2dbe..3e5bbf9 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -23,6 +23,20 @@ static struct pci_host_bridge *find_pci_host_bridge(struct 
pci_bus *bus)
return to_pci_host_bridge(root_bus->bridge);
 }
 
+struct device *pci_get_host_bridge_device(struct pci_dev *dev)
+{
+   struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
+   struct device *bridge = root_bus->bridge;
+
+   kobject_get(&bridge->kobj);
+   return bridge;
+}
+
+void  pci_put_host_bridge_device(struct device *dev)
+{
+   kobject_put(&dev->kobj);
+}
+
 void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
 void (*release_fn)(struct pci_host_bridge *),
 void *release_data)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 211e9da..a379513 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -510,6 +510,9 @@ static inline struct pci_dev *pci_upstream_bridge(struct 
pci_dev *dev)
return dev->bus->self;
 }
 
+struct device *pci_get_host_bridge_device(struct pci_dev *dev);
+void pci_put_host_bridge_device(struct device *dev);
+
 #ifdef CONFIG_PCI_MSI
 static inline bool pci_dev_msi_enabled(struct pci_dev *pci_dev)
 {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 3/7] of: Fix size when dma-range is not used

[Murali Karicheri]

Fix the dma-range size when the DT attribute is missing, i.e., set size to
dev->coherent_dma_mask + 1 instead of dev->coherent_dma_mask.  Also add
code to check invalid values of size configured in DT and log error.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Rob Herring 
CC: Russell King 
CC: Arnd Bergmann 
---
 drivers/of/device.c |   17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 31a7875..28e74388 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -105,9 +105,24 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)
ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
if (ret < 0) {
dma_addr = offset = 0;
-   size = dev->coherent_dma_mask;
+   size = dev->coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
+
+   /*
+* Add a work around to treat the size as mask + 1 in case
+* it is defined in DT as a mask.
+*/
+   if (size & 1) {
+   dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
+size);
+   size = size + 1;
+   }
+
+   if (!size) {
+   dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
+   return;
+   }
dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
}
 
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v8 0/7] PCI: get DMA configuration from parent device

[Murali Karicheri]

This series is already applied on arm-pci iommu branch for next, but
kbuild test robot reported build errors on x86_64 and sparc. So I am
sending v8 to help apply on arm-pci iommu branch.
 
Here is the original cover letter of the series.

This patch add an important capability to PCI driver on Keystone. I hope to
have this merged to the upstream branch so that it is available for v3.20.
Also would like thank everyone for the contribution.

PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
add capability to set the dma configuration such as dma-mask, dma_pfn_offset,
and dma ops etc using the information from DT. The prior RFCs and discussions
are available at [1] and [2] below.

[2] : https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg790244.html
[1] : http://www.gossamer-threads.com/lists/linux/kernel/2024591

Change history:
v8 - On request from Bjorn, I am resending the whole series with also
 ack from Rob Herring against 2/7
v7 - Used for re-spinning 2/7 and 6/7. Fixed build issues on x86_64 and
 sparc reported by kbuild test robot
v6 - Rebased to v3.19-v7
   - Addressed some minor comments about node name and DT size 
validation.
   - Pulled out 8/8 of v5 and plan to send a patch for enhancing
 of_dma_configure() to use size to calculate dma mask.
   - Added Acks from reviewers.
v5 - moved the dma_mask update in device from ARM specific API to
 of_dma_configure to allow this across other architecture as well
   - improved sanity check for DT dma-range size in of_dma_configure()
   - moved API to get parent bridge device to PCI (host-bridge.c)
v4 - moved size adjustments in of_iommu_configure() to a separate patch
   - consistent node name comment from Rob
   - patch 6 added for dma_mask adjustment and iommu mapping size
 limiting.
v3 - addressed comments to re-use of_dma_configure() for PCI
   - To help re-use, change of_iommu_configure() function argument
- Move of_dma_configure to of/device.c
- Limit the of_iommu_configure to non pci devices
v2 - update size to coherent_dma_mask + 1 if dma-range info is missing
   - also check the np for null.
v1 - updates based on the comments against initial RFC.
   - Added a helper function to get the OF node of the parent
   - Added an API in of_pci.c to update DMA configuration of the pci
 device.

Cc: Joerg Roedel 
Cc: Grant Likely 
Cc: Rob Herring 
Cc: Bjorn Helgaas 
Cc: Will Deacon 
Cc: Russell King 
Cc: Arnd Bergmann 
Cc: Suravee Suthikulpanit 

Acked-by: Bjorn Helgaas 
Acked-by: Murali Karicheri 

Murali Karicheri (7):
  of: iommu: Add ptr to OF node arg to of_iommu_configure()
  of: Move of_dma_configure() to device.c to help re-use
  of: Fix size when dma-range is not used
  PCI: Add helper functions pci_get[put]_host_bridge_device()
  of/pci: Add of_pci_dma_configure() to update DMA configuration
  PCI: Update DMA configuration from DT
  arm: dma-mapping: limit IOMMU mapping size

 arch/arm/mm/dma-mapping.c |7 +
 drivers/iommu/of_iommu.c  |   10 --
 drivers/of/device.c   |   74 +
 drivers/of/of_pci.c   |   18 +++
 drivers/of/platform.c |   58 ++-
 drivers/pci/host-bridge.c |   14 +
 drivers/pci/probe.c   |2 ++
 include/linux/of_device.h |3 ++
 include/linux/of_iommu.h  |6 ++--
 include/linux/of_pci.h|3 ++
 include/linux/pci.h   |3 ++
 11 files changed, 138 insertions(+), 60 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH - v7] of: Move of_dma_configure() to device.c to help re-use

[Murali Karicheri]

On 03/02/2015 10:43 PM, Bjorn Helgaas wrote:

On Mon, Mar 2, 2015 at 3:59 PM, Murali Karicheri  wrote:

Move of_dma_configure() to device.c so it can be re-used for PCI devices to
obtain DMA configuration from DT.  Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri
Signed-off-by: Bjorn Helgaas
Reviewed-by: Catalin Marinas
Acked-by: Will Deacon
CC: Joerg Roedel
CC: Grant Likely
CC: Rob Herring
CC: Russell King
CC: Arnd Bergmann
---
  - Based on the existing patch applied to arm-pci/pci/iommu for pci next 
(Bjorn)
  - Fixed the build issue reported on ARCH=x86_64


Hi Murali,

Can you please repost the entire series with fixed patches?  It's
easier for me to reapply the whole thing at once than it is to keep
track of and fiddle with individual patches.

Bjorn

Ok Fine. Will post now.

Murali

--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH - V7] of/pci: Add of_pci_dma_configure() to update DMA configuration

[Murali Karicheri]

Add of_pci_dma_configure() to allow updating the DMA configuration of the
PCI device using the configuration from DT of the parent of the root bridge
device.  Use the newly added APIs pci_get/put_host_bridge_device() for
implementing this.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Rob Herring 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Russell King 
CC: Arnd Bergmann 
---
 - Based on the existing patch on arm-pci/pci/iommu for pci next (Bjorn)
 - Fixed build issue seen on ARCH=sparc
 drivers/of/of_pci.c|   18 ++
 include/linux/of_pci.h |3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 62426d8..86d3c38 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -116,6 +117,23 @@ int of_get_pci_domain_nr(struct device_node *node)
 }
 EXPORT_SYMBOL_GPL(of_get_pci_domain_nr);
 
+/**
+ * of_pci_dma_configure - Setup DMA configuration
+ * @dev: ptr to pci_dev struct of the pci device
+ *
+ * Function to update PCI devices's DMA configuration using the same
+ * info from the OF node of root host bridge's parent.
+ */
+void of_pci_dma_configure(struct pci_dev *pci_dev)
+{
+   struct device *dev = &pci_dev->dev;
+   struct device *bridge = pci_get_host_bridge_device(pci_dev);
+
+   of_dma_configure(dev, bridge->parent->of_node);
+   pci_put_host_bridge_device(bridge);
+}
+EXPORT_SYMBOL_GPL(of_pci_dma_configure);
+
 #if defined(CONFIG_OF_ADDRESS)
 /**
  * of_pci_get_host_bridge_resources - Parse PCI host bridge resources from DT
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index ce0e5ab..29fd3fe 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -16,6 +16,7 @@ int of_pci_get_devfn(struct device_node *np);
 int of_irq_parse_and_map_pci(const struct pci_dev *dev, u8 slot, u8 pin);
 int of_pci_parse_bus_range(struct device_node *node, struct resource *res);
 int of_get_pci_domain_nr(struct device_node *node);
+void of_pci_dma_configure(struct pci_dev *pci_dev);
 #else
 static inline int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq)
 {
@@ -50,6 +51,8 @@ of_get_pci_domain_nr(struct device_node *node)
 {
return -1;
 }
+
+static inline void of_pci_dma_configure(struct pci_dev *pci_dev) { }
 #endif
 
 #if defined(CONFIG_OF_ADDRESS)
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH - v7] of: Move of_dma_configure() to device.c to help re-use

[Murali Karicheri]

Move of_dma_configure() to device.c so it can be re-used for PCI devices to
obtain DMA configuration from DT.  Also add a second argument so that for
PCI, the DT node of root bus host bridge can be used to obtain the DMA
configuration for the slave PCI device.

Tested-by: Suravee Suthikulpanit  (AMD Seattle)
Signed-off-by: Murali Karicheri 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Catalin Marinas 
Acked-by: Will Deacon 
CC: Joerg Roedel 
CC: Grant Likely 
CC: Rob Herring 
CC: Russell King 
CC: Arnd Bergmann 
---
 - Based on the existing patch applied to arm-pci/pci/iommu for pci next (Bjorn)
 - Fixed the build issue reported on ARCH=x86_64  
 drivers/of/device.c   |   59 +
 drivers/of/platform.c |   58 ++--
 include/linux/of_device.h |2 ++
 3 files changed, 63 insertions(+), 56 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 46d6c75c..31a7875 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -2,6 +2,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -66,6 +69,62 @@ int of_device_add(struct platform_device *ofdev)
return device_add(&ofdev->dev);
 }
 
+/**
+ * of_dma_configure - Setup DMA configuration
+ * @dev:   Device to apply DMA configuration
+ * @np:Pointer to OF node having DMA configuration
+ *
+ * Try to get devices's DMA configuration from DT and update it
+ * accordingly.
+ *
+ * If platform code needs to use its own special DMA configuration, it
+ * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
+ * to fix up DMA configuration.
+ */
+void of_dma_configure(struct device *dev, struct device_node *np)
+{
+   u64 dma_addr, paddr, size;
+   int ret;
+   bool coherent;
+   unsigned long offset;
+   struct iommu_ops *iommu;
+
+   /*
+* Set default dma-mask to 32 bit.  Drivers are expected to setup
+* the correct supported dma_mask.
+*/
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+
+   /*
+* Set it to coherent_dma_mask by default if the architecture
+* code has not set it.
+*/
+   if (!dev->dma_mask)
+   dev->dma_mask = &dev->coherent_dma_mask;
+
+   ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+   if (ret < 0) {
+   dma_addr = offset = 0;
+   size = dev->coherent_dma_mask;
+   } else {
+   offset = PFN_DOWN(paddr - dma_addr);
+   dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
+   }
+
+   dev->dma_pfn_offset = offset;
+
+   coherent = of_dma_is_coherent(np);
+   dev_dbg(dev, "device is%sdma coherent\n",
+   coherent ? " " : " not ");
+
+   iommu = of_iommu_configure(dev, np);
+   dev_dbg(dev, "device is%sbehind an iommu\n",
+   iommu ? " " : " not ");
+
+   arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+}
+EXPORT_SYMBOL_GPL(of_dma_configure);
+
 int of_device_register(struct platform_device *pdev)
 {
device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 667c6f1..a01f57c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -150,59 +149,6 @@ struct platform_device *of_device_alloc(struct device_node 
*np,
 }
 EXPORT_SYMBOL(of_device_alloc);
 
-/**
- * of_dma_configure - Setup DMA configuration
- * @dev:   Device to apply DMA configuration
- *
- * Try to get devices's DMA configuration from DT and update it
- * accordingly.
- *
- * In case if platform code need to use own special DMA configuration,it
- * can use Platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE event
- * to fix up DMA configuration.
- */
-static void of_dma_configure(struct device *dev)
-{
-   u64 dma_addr, paddr, size;
-   int ret;
-   bool coherent;
-   unsigned long offset;
-   struct iommu_ops *iommu;
-
-   /*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
-*/
-   dev->coherent_dma_mask = DMA_BIT_MASK(32);
-
-   /*
-* Set it to coherent_dma_mask by default if the architecture
-* code has not set it.
-*/
-   if (!dev->dma_mask)
-   dev->dma_mask = &dev->coherent_dma_mask;
-
-   ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
-   if (ret < 0) {
-   dma_addr = offset = 0;
-   size = dev->coherent_dma_mask;
-   } else {
-   offset = PFN_DOWN(paddr - dma_addr);
-   dev_dbg(dev, "dma_pfn_offse

Re: [PATCH v1] of: calculate masks of the device based on dma-range size

[Murali Karicheri]

On 02/25/2015 07:20 PM, Bjorn Helgaas wrote:

[+cc Catalin]

On Wed, Feb 11, 2015 at 12:53:35PM -0500, Murali Karicheri wrote:

This patch update of_dma_configure() API to calculate the
masks (dma_mask and coherent_dma_mask) based on the dma-range
values set in DT for the device. Also limit the mask to lower
of the default mask and mask calculated.

Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit

Signed-off-by: Murali Karicheri


Applied with Catalin's reviewed-by to pci/iommu for v4.1, thanks!

I agree with Catalin's comment about the "size = 1ULL<<  32" line.
I don't see how that will make a difference, so I dropped it.  The
patch I merged is below.  Let me know if you think we do need that
line or any other tweaks.

Bjorn

commit a5a1dd69080dfcf53bfd6e179f3db68e824aeaae
Author: Murali Karicheri
Date:   Wed Feb 25 17:21:04 2015 -0600

 of: Calculate device DMA masks based on DT dma-range size

 Calculate the dma_mask and coherent_dma_mask based on the dma-range values
 set in DT for the device.

 Limit the mask to lower of the default mask and mask calculated.

 Signed-off-by: Murali Karicheri
 Signed-off-by: Bjorn Helgaas
 Reviewed-by: Catalin Marinas
 CC: Joerg Roedel
 CC: Grant Likely
 CC: Rob Herring
 CC: Will Deacon
 CC: Russell King
 CC: Arnd Bergmann
 CC: Suravee Suthikulpanit

diff --git a/drivers/of/device.c b/drivers/of/device.c
index 28e743888402..20c1332a0018 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -90,10 +90,11 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)
struct iommu_ops *iommu;

/*
-* Set default dma-mask to 32 bit.  Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default coherent_dma_mask to 32 bit.  Drivers are expected to
+* setup the correct supported mask.
 */
-   dev->coherent_dma_mask = DMA_BIT_MASK(32);
+   if (!dev->coherent_dma_mask)
+   dev->coherent_dma_mask = DMA_BIT_MASK(32);

/*
 * Set it to coherent_dma_mask by default if the architecture
@@ -128,6 +129,15 @@ void of_dma_configure(struct device *dev, struct 
device_node *np)

dev->dma_pfn_offset = offset;

+   /*
+* Limit coherent and dma mask based on size and default mask
+* set by the driver.
+*/
+   dev->coherent_dma_mask = min(dev->coherent_dma_mask,
+DMA_BIT_MASK(ilog2(dma_addr + size)));
+   *dev->dma_mask = min((*dev->dma_mask),
+DMA_BIT_MASK(ilog2(dma_addr + size)));
+
coherent = of_dma_is_coherent(np);
dev_dbg(dev, "device is%sdma coherent\n",
coherent ? " " : " not ");

Bjorn,

Thanks. Looks good to me.

Murali

--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/7] PCI: update dma configuration from DT

[Murali Karicheri]

On 02/25/2015 11:09 AM, Arnd Bergmann wrote:

On Wednesday 25 February 2015 11:03:02 Murali Karicheri wrote:



(I don't know exactly how these patches all fit together, so that's
probably not accurate, but that's the *sort* of thing I'd like to include.)

If that actually *is* what's going on, I have to wonder why this isn't
implemented as a very simple IOMMU instead of adding dma_pfn_offset,
which is present on all arches but only used on ARM.  In some sense that
offset is parallel but incompatible with an IOMMU: they both translate DMA
addresses into system RAM addresses.


I don't have much history on any previous discussion on the subject you
are referring to. I assume it would have happened when
of_dma_configure() was first introduced. On Keystone, we don't have
IOMMU support and dma_pfn_offset is needed to translate DMA address to
System RAM address and vice-versa. So this has to be supported for
Keystone. There can be enhancement for IOMMU with out impacting this
feature for Keystone.


The direction we are taking with IOMMU in general is opposite to what Bjorn
is suggesting: I believe what he wants to say is that we should use the
traditional approach of having a specialized dma_map_ops implementation
for this, just like we do for IOMMU implementations on x86, IA64 or PowerPC.

However, with the recent explosion of IOMMU implementations on ARM, we
are moving towards having a single dma_map_ops structure for all of them,
and that structure does not work with the keystone hardware. Instead,
the normal ARM dma_map_ops have been changed to handle the offset,
which is the same thing we do on PowerPC.


Arnd,

Thanks for the clarification.

Murali


Arnd



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/7] PCI: update dma configuration from DT

[Murali Karicheri]

On 02/24/2015 08:53 PM, Bjorn Helgaas wrote:

On Thu, Feb 05, 2015 at 04:52:58PM -0500, Murali Karicheri wrote:

If there is a DT node available for the root bridge's parent device,
use the dma configuration from that device node. For example, keystone
PCI devices would require dma_pfn_offset to be set correctly in the
device structure of the pci device in order to have the correct dma mask.
The DT node will have dma-ranges defined for this. Also support using
the DT property dma-coherent to allow coherent DMA operation by the
PCI device.


Hi Murali,

I'm guessing this is the patch that actually fixes things for Keystone.


Yes, but depends on other patches in the series.


And it looks like it should also fix things for other hardware that has
similar characteristics.


This originally started as a patch for Keystone, but modified to apply 
for other platforms as well. Tested by one another platform AFAIK, by 
Suravee Suthikulpanit on AMD Seattle platform w/ PCI Generic Host 
Controller. See the Tested-By from him against this series.


 So I'd like to include some higher-level text

about that here.  For example:

   This fixes DMA on systems where DMA addresses are a constant offset
   from CPU physical addresses.



That is one fix. It also update dma configuration for the device
such as dma operations through a call to of_dma_configure() in 5/7.
You may add the above description in 5/7. I didn't add it in the 
description because of_dma_configure() API call takes care of it already.



(I don't know exactly how these patches all fit together, so that's
probably not accurate, but that's the *sort* of thing I'd like to include.)

If that actually *is* what's going on, I have to wonder why this isn't
implemented as a very simple IOMMU instead of adding dma_pfn_offset,
which is present on all arches but only used on ARM.  In some sense that
offset is parallel but incompatible with an IOMMU: they both translate DMA
addresses into system RAM addresses.


I don't have much history on any previous discussion on the subject you 
are referring to. I assume it would have happened when 
of_dma_configure() was first introduced. On Keystone, we don't have 
IOMMU support and dma_pfn_offset is needed to translate DMA address to 
System RAM address and vice-versa. So this has to be supported for 
Keystone. There can be enhancement for IOMMU with out impacting this 
feature for Keystone.


I know that Will Deacon is working on updates for IOMMU which is 
partially touched by my series (1/7). Probably this can be a question 
when that patches comes up for review or could be a seperate discussion 
topic.


I think it is better this series is applied to the next branch for v4.1 
as soon as possible so that others can add features on top of this 
without breaking the function for Keystone.


I am looking forward for the merge of this series to the next branch at 
the earliest.


Thanks.

Murali


I know you're not adding this, and I assume somebody explored that option
and rejected it for good reasons.  I just missed that discussion.


This patch use the new helper function of_pci_dma_configure() to update
the device dma configuration.

Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit

Acked-by: Bjorn Helgaas
Signed-off-by: Murali Karicheri
---
  drivers/pci/probe.c |2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 23212f8..d7dcd6c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -6,6 +6,7 @@
  #include
  #include
  #include
+#include
  #include
  #include
  #include
@@ -1520,6 +1521,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus 
*bus)
dev->dev.dma_mask =&dev->dma_mask;
dev->dev.dma_parms =&dev->dma_parms;
dev->dev.coherent_dma_mask = 0xull;
+   of_pci_dma_configure(dev);

pci_set_dma_max_seg_size(dev, 65536);
pci_set_dma_seg_boundary(dev, 0x);
--
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



--
Murali Karicheri
Linux Kernel, Texas Instruments
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html