Re: [PATCH 1/2] memory: brcmstb_dpfe: Simplify with dev_err_probe()

2020-08-28 Thread Markus Mayer
On Fri, 28 Aug 2020 at 08:37, Krzysztof Kozlowski  wrote:
>
> Common pattern of handling deferred probe can be simplified with
> dev_err_probe().  Less code and the error value gets printed.
>
> Signed-off-by: Krzysztof Kozlowski 

Acked-by: Markus Mayer 

> ---
>  drivers/memory/brcmstb_dpfe.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index dcf50bb8dd69..f43ba69fbb3e 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -901,11 +901,8 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
> }
>
> ret = brcmstb_dpfe_download_firmware(priv);
> -   if (ret) {
> -   if (ret != -EPROBE_DEFER)
> -   dev_err(dev, "Couldn't download firmware -- %d\n", 
> ret);
> -   return ret;
> -   }
> +   if (ret)
> +   return dev_err_probe(dev, ret, "Couldn't download 
> firmware\n");
>
> ret = sysfs_create_groups(>dev.kobj, 
> priv->dpfe_api->sysfs_attrs);
> if (!ret)
> --
> 2.17.1
>


[PATCH v3] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-22 Thread Markus Mayer
We would overrun the error_text array if we hit a TIMEOUT condition,
because we were using the error code "ETIMEDOUT" (which is 110) as an
array index.

We fix the problem by correcting the array index and by providing a
function to retrieve error messages rather than accessing the array
directly. The function includes a bounds check that prevents the array
from being overrun.

This patch was prepared in response to
https://lkml.org/lkml/2020/8/18/505.

Signed-off-by: Markus Mayer 
Acked-by: Florian Fainelli 
Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Reported-by: Colin Ian King 
---

Changes since v2:
- Added "Fixes:" and "Reported-by:"
- Fixed "From" address
- No changes to the code

Changes since v1:
- Added link of the coverity report to the commit message.
- Added Florian's ack.
- Removed second "const" from get_error_text() return type
  (thanks to the kernel test robot).

 drivers/memory/brcmstb_dpfe.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index e08528b12cbd..dcf50bb8dd69 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -188,11 +188,6 @@ struct brcmstb_dpfe_priv {
struct mutex lock;
 };
 
-static const char * const error_text[] = {
-   "Success", "Header code incorrect", "Unknown command or argument",
-   "Incorrect checksum", "Malformed command", "Timed out",
-};
-
 /*
  * Forward declaration of our sysfs attribute functions, so we can declare the
  * attribute data structures early.
@@ -307,6 +302,20 @@ static const struct dpfe_api dpfe_api_v3 = {
},
 };
 
+static const char *get_error_text(unsigned int i)
+{
+   static const char * const error_text[] = {
+   "Success", "Header code incorrect",
+   "Unknown command or argument", "Incorrect checksum",
+   "Malformed command", "Timed out", "Unknown error",
+   };
+
+   if (unlikely(i >= ARRAY_SIZE(error_text)))
+   i = ARRAY_SIZE(error_text) - 1;
+
+   return error_text[i];
+}
+
 static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
 {
u32 val;
@@ -445,7 +454,7 @@ static int __send_command(struct brcmstb_dpfe_priv *priv, 
unsigned int cmd,
}
if (resp != 0) {
mutex_unlock(>lock);
-   return -ETIMEDOUT;
+   return -ffs(DCPU_RET_ERR_TIMEDOUT);
}
 
/* Compute checksum over the message */
@@ -695,7 +704,7 @@ static ssize_t generic_show(unsigned int command, u32 
response[],
 
ret = __send_command(priv, command, response);
if (ret < 0)
-   return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
+   return sprintf(buf, "ERROR: %s\n", get_error_text(-ret));
 
return 0;
 }
-- 
2.17.1



Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-22 Thread Markus Mayer
On Sat, 22 Aug 2020 at 13:46, Krzysztof Kozlowski  wrote:
>
> On Sat, Aug 22, 2020 at 01:21:47PM -0700, Florian Fainelli wrote:
> >
> >
> > On 8/22/2020 1:14 PM, Markus Mayer wrote:
> > > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski  wrote:
> > > >
> > > > On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote:
> > > > > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski  
> > > > > wrote:
> > > > > >
> > > > > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote:
> > > > > > > We would overrun the error_text array if we hit a TIMEOUT 
> > > > > > > condition,
> > > > > > > because we were using the error code "ETIMEDOUT" (which is 110) 
> > > > > > > as an
> > > > > > > array index.
> > > > > > >
> > > > > > > We fix the problem by correcting the array index and by providing 
> > > > > > > a
> > > > > > > function to retrieve error messages rather than accessing the 
> > > > > > > array
> > > > > > > directly. The function includes a bounds check that prevents the 
> > > > > > > array
> > > > > > > from being overrun.
> > > > > > >
> > > > > > > This patch was prepared in response to
> > > > > > >  https://lkml.org/lkml/2020/8/18/505.
> > > > > > >
> > > > > > > Signed-off-by: Markus Mayer 
> > > > > >
> > > > > > Your Signed-off-by does not match From field. Please run
> > > > > > scripts/checkpatch on every patch you send.
> > > > > >
> > > > > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email
> > > > > > address.
> > > > >
> > > > > No. I have always been using mma...@broadcom.com since it is shorter.
> > > > > That's also what's in the MAINTAINERS file. Please change it back. I
> > > > > accidentally used the long form for one of my e-mail replies which is
> > > > > where the confusion must have originated.
> > > >
> > > > I'll drop the patch then. You need to resend with SoB matching email.
> > >
> > > Oh, I am starting to see what's happening here. This is new and
> > > apparently due to some changes with the mail server setup on our end.
> > >
> > > I have this in my patch file:
> > >
> > > $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch
> > >  From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001
> > > From: Markus Mayer 
> > > Date: Fri, 21 Aug 2020 08:56:52 -0700
>
> Which means your patch actually passed checkpatch on your computer so my
> comment about running it was not smart... :)

It did pass, yes. :-)

> > > Sending patches like this used to work. Clearly our SMTP server has
> > > now taken it upon itself to rewrite the sender e-mail address. I
> > > wasn't expecting that. Let me look into it. Sorry for the hassle. It
> > > was not intentional.
> >
> > Yes, if you used to use the SMTP relay server which did not require
> > authentication for internal hosts, and now you use smtp.gmail.com with your
> > broadcom.com username, the SMTP server will rewrite the From: to match the
> > username used to authenticate with the server.
>
> Markus' patch did not go via GMail.  It was the Broadcom server which
> mangled the things.  The email headers:

Indeed.

>   Received: by mail.kernel.org (Postfix)
>   Received: from rnd-relay.smtp.broadcom.com (rnd-relay.smtp.broadcom.com 
> [192.19.229.170])
>   by mail.kernel.org (Postfix) with ESMTPS id D5B3B20702
>   Received: from mail-irv-17.broadcom.com (mail-irv-17.lvn.broadcom.net 
> [10.75.242.48])
>   Received: from lbrmn-mmayer.ric.broadcom.net (lbrmn-mmayer.ric.broadcom.net 
> [10.136.28.150])
>   From: Markus Mayer 
>
> Neither kernel.org nor my final server (Gmail) cares about usernames in
> From fields of some specific domain.
>
> I guess you could try configure you git send email to use email of
> "markus.mayer" while keeping Author "mmayer".  You have to configure git
> send email for this and such configuration results in proper two "From"
> fields which maybe smtp broadcom won't change.

Yep. I think I've got it set up now. Stay tuned.

> Best regards,
> Krzysztof


Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-22 Thread Markus Mayer
On Sat, 22 Aug 2020 at 13:21, Florian Fainelli  wrote:
>
> On 8/22/2020 1:14 PM, Markus Mayer wrote:
> > On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski  wrote:
> >>
> >> On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote:
> >>> On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski  wrote:
> >>>>
> >>>> On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote:
> >>>>> We would overrun the error_text array if we hit a TIMEOUT condition,
> >>>>> because we were using the error code "ETIMEDOUT" (which is 110) as an
> >>>>> array index.
> >>>>>
> >>>>> We fix the problem by correcting the array index and by providing a
> >>>>> function to retrieve error messages rather than accessing the array
> >>>>> directly. The function includes a bounds check that prevents the array
> >>>>> from being overrun.
> >>>>>
> >>>>> This patch was prepared in response to
> >>>>>  https://lkml.org/lkml/2020/8/18/505.
> >>>>>
> >>>>> Signed-off-by: Markus Mayer 
> >>>>
> >>>> Your Signed-off-by does not match From field. Please run
> >>>> scripts/checkpatch on every patch you send.
> >>>>
> >>>> I fixed it up, assuming markus.ma...@broadcom.com is the valid email
> >>>> address.
> >>>
> >>> No. I have always been using mma...@broadcom.com since it is shorter.
> >>> That's also what's in the MAINTAINERS file. Please change it back. I
> >>> accidentally used the long form for one of my e-mail replies which is
> >>> where the confusion must have originated.
> >>
> >> I'll drop the patch then. You need to resend with SoB matching email.
> >
> > Oh, I am starting to see what's happening here. This is new and
> > apparently due to some changes with the mail server setup on our end.
> >
> > I have this in my patch file:
> >
> > $ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch
> >  From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001
> > From: Markus Mayer 
> > Date: Fri, 21 Aug 2020 08:56:52 -0700
> >
> > Sending patches like this used to work. Clearly our SMTP server has
> > now taken it upon itself to rewrite the sender e-mail address. I
> > wasn't expecting that. Let me look into it. Sorry for the hassle. It
> > was not intentional.
>
> Yes, if you used to use the SMTP relay server which did not require
> authentication for internal hosts, and now you use smtp.gmail.com with
> your broadcom.com username, the SMTP server will rewrite the From: to
> match the username used to authenticate with the server.

Actually, it was the other way around. Connecting to smtp.gmail.com
does allow the "From:" header to be customized. The envelope sender,
i.e. the "From " line at the very beginning of the e-mail, might still
get rewritten, but that's okay since the "From:" header is left alone.
The internal SMTP server, however, which does not require
authentication, unexpectedly rewrites the "From:" header in the middle
of the e-mail header.

Got it set up now in a way that should work. At least it did in my
test. I'll send out v3 of the patch momentarily, and then we'll know
for sure.

Regards,
-Markus


Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-22 Thread Markus Mayer
On Sat, 22 Aug 2020 at 09:46, Krzysztof Kozlowski  wrote:
>
> On Sat, Aug 22, 2020 at 09:40:59AM -0700, Markus Mayer wrote:
> > On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski  wrote:
> > >
> > > On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote:
> > > > We would overrun the error_text array if we hit a TIMEOUT condition,
> > > > because we were using the error code "ETIMEDOUT" (which is 110) as an
> > > > array index.
> > > >
> > > > We fix the problem by correcting the array index and by providing a
> > > > function to retrieve error messages rather than accessing the array
> > > > directly. The function includes a bounds check that prevents the array
> > > > from being overrun.
> > > >
> > > > This patch was prepared in response to
> > > > https://lkml.org/lkml/2020/8/18/505.
> > > >
> > > > Signed-off-by: Markus Mayer 
> > >
> > > Your Signed-off-by does not match From field. Please run
> > > scripts/checkpatch on every patch you send.
> > >
> > > I fixed it up, assuming markus.ma...@broadcom.com is the valid email
> > > address.
> >
> > No. I have always been using mma...@broadcom.com since it is shorter.
> > That's also what's in the MAINTAINERS file. Please change it back. I
> > accidentally used the long form for one of my e-mail replies which is
> > where the confusion must have originated.
>
> I'll drop the patch then. You need to resend with SoB matching email.

Oh, I am starting to see what's happening here. This is new and
apparently due to some changes with the mail server setup on our end.

I have this in my patch file:

$ head 0001-memory-brcmstb_dpfe-fix-array-index-out-of-bounds.patch
>From 6b424772d4c84fa56474b2522d0d3ed6b2b2b360 Mon Sep 17 00:00:00 2001
From: Markus Mayer 
Date: Fri, 21 Aug 2020 08:56:52 -0700

Sending patches like this used to work. Clearly our SMTP server has
now taken it upon itself to rewrite the sender e-mail address. I
wasn't expecting that. Let me look into it. Sorry for the hassle. It
was not intentional.

Regards,
-Markus

> Best regards,
> Krzysztof


Re: [PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-22 Thread Markus Mayer
On Sat, 22 Aug 2020 at 04:56, Krzysztof Kozlowski  wrote:
>
> On Fri, Aug 21, 2020 at 09:52:21AM -0700, Markus Mayer wrote:
> > We would overrun the error_text array if we hit a TIMEOUT condition,
> > because we were using the error code "ETIMEDOUT" (which is 110) as an
> > array index.
> >
> > We fix the problem by correcting the array index and by providing a
> > function to retrieve error messages rather than accessing the array
> > directly. The function includes a bounds check that prevents the array
> > from being overrun.
> >
> > This patch was prepared in response to
> > https://lkml.org/lkml/2020/8/18/505.
> >
> > Signed-off-by: Markus Mayer 
>
> Your Signed-off-by does not match From field. Please run
> scripts/checkpatch on every patch you send.
>
> I fixed it up, assuming markus.ma...@broadcom.com is the valid email
> address.

No. I have always been using mma...@broadcom.com since it is shorter.
That's also what's in the MAINTAINERS file. Please change it back. I
accidentally used the long form for one of my e-mail replies which is
where the confusion must have originated.

> > Acked-by: Florian Fainelli 
> > ---
> >
> > Changes since v1:
> > - Added link of the coverity report to the commit message.
> > - Added Florian's ack.
> > - Removed second "const" from get_error_text() return type
>
> Florian was so kind to provide you with necessary tags - Fixes and
> Reported-by. Always include them on resubmit of patches.

I missed those. Thanks for catching it.

Regards,
-Markus



> Thanks, applied.
>
> Best regards,
> Krzysztof
>


[PATCH v2] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-21 Thread Markus Mayer
We would overrun the error_text array if we hit a TIMEOUT condition,
because we were using the error code "ETIMEDOUT" (which is 110) as an
array index.

We fix the problem by correcting the array index and by providing a
function to retrieve error messages rather than accessing the array
directly. The function includes a bounds check that prevents the array
from being overrun.

This patch was prepared in response to
https://lkml.org/lkml/2020/8/18/505.

Signed-off-by: Markus Mayer 
Acked-by: Florian Fainelli 
---

Changes since v1:
- Added link of the coverity report to the commit message.
- Added Florian's ack.
- Removed second "const" from get_error_text() return type
  (thanks to the kernel test robot).

 drivers/memory/brcmstb_dpfe.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index e08528b12cbd..dcf50bb8dd69 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -188,11 +188,6 @@ struct brcmstb_dpfe_priv {
struct mutex lock;
 };
 
-static const char * const error_text[] = {
-   "Success", "Header code incorrect", "Unknown command or argument",
-   "Incorrect checksum", "Malformed command", "Timed out",
-};
-
 /*
  * Forward declaration of our sysfs attribute functions, so we can declare the
  * attribute data structures early.
@@ -307,6 +302,20 @@ static const struct dpfe_api dpfe_api_v3 = {
},
 };
 
+static const char *get_error_text(unsigned int i)
+{
+   static const char * const error_text[] = {
+   "Success", "Header code incorrect",
+   "Unknown command or argument", "Incorrect checksum",
+   "Malformed command", "Timed out", "Unknown error",
+   };
+
+   if (unlikely(i >= ARRAY_SIZE(error_text)))
+   i = ARRAY_SIZE(error_text) - 1;
+
+   return error_text[i];
+}
+
 static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
 {
u32 val;
@@ -445,7 +454,7 @@ static int __send_command(struct brcmstb_dpfe_priv *priv, 
unsigned int cmd,
}
if (resp != 0) {
mutex_unlock(>lock);
-   return -ETIMEDOUT;
+   return -ffs(DCPU_RET_ERR_TIMEDOUT);
}
 
/* Compute checksum over the message */
@@ -695,7 +704,7 @@ static ssize_t generic_show(unsigned int command, u32 
response[],
 
ret = __send_command(priv, command, response);
if (ret < 0)
-   return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
+   return sprintf(buf, "ERROR: %s\n", get_error_text(-ret));
 
return 0;
 }
-- 
2.17.1



Re: [PATCH] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-21 Thread Markus Mayer
On Thu, 20 Aug 2020 at 22:40, Krzysztof Kozlowski  wrote:
>
> On Thu, Aug 20, 2020 at 06:03:33PM -0700, Markus Mayer wrote:
> > We would overrun the error_text array if we hit a TIMEOUT condition,
> > because we were using the error code "ETIMEDOUT" (which is 110) as an
> > array index.
> >
> > We fix the problem by correcting the array index and by providing a
> > function to retrieve error messages rather than accessing the array
> > directly. The function includes a bounds check that prevents the array
> > from being overrun.
> >
> > Signed-off-by: Markus Mayer 
> > ---
> >
> > This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505.
> >
> >  drivers/memory/brcmstb_dpfe.c | 23 ---
> >  1 file changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> > index 81abc4a98a27..a986a849f58e 100644
> > --- a/drivers/memory/brcmstb_dpfe.c
> > +++ b/drivers/memory/brcmstb_dpfe.c
> > @@ -190,11 +190,6 @@ struct brcmstb_dpfe_priv {
> >   struct mutex lock;
> >  };
> >
> > -static const char * const error_text[] = {
> > - "Success", "Header code incorrect", "Unknown command or argument",
> > - "Incorrect checksum", "Malformed command", "Timed out",
> > -};
> > -
> >  /*
> >   * Forward declaration of our sysfs attribute functions, so we can declare 
> > the
> >   * attribute data structures early.
> > @@ -307,6 +302,20 @@ static const struct dpfe_api dpfe_api_v3 = {
> >   },
> >  };
> >
> > +static const char * const get_error_text(unsigned int i)
>
> The pointer itself is returned by value and you cannot return a const
> value. I mean, you can but it does not have an effect. Only pointed
> memory should be const (const const char*).

v2 is on the way.

Regards,
-Markus

> > +{
> > + static const char * const error_text[] = {
> > + "Success", "Header code incorrect",
> > + "Unknown command or argument", "Incorrect checksum",
> > + "Malformed command", "Timed out", "Unknown error",
> > + };
> > +
> > + if (unlikely(i >= ARRAY_SIZE(error_text)))
> > + i = ARRAY_SIZE(error_text) - 1;
> > +
> > + return error_text[i];
> > +}
> > +
> >  static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
> >  {
> >   u32 val;
> > @@ -446,7 +455,7 @@ static int __send_command(struct brcmstb_dpfe_priv 
> > *priv, unsigned int cmd,
> >   }
> >   if (resp != 0) {
> >   mutex_unlock(>lock);
> > - return -ETIMEDOUT;
> > + return -ffs(DCPU_RET_ERR_TIMEDOUT);
> >   }
> >
> >   /* Compute checksum over the message */
> > @@ -695,7 +704,7 @@ static ssize_t generic_show(unsigned int command, u32 
> > response[],
> >
> >   ret = __send_command(priv, command, response);
> >   if (ret < 0)
> > - return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
> > + return sprintf(buf, "ERROR: %s\n", get_error_text(-ret));
> >
> >   return 0;
> >  }
> > --
> > 2.17.1
> >


Re: out of bounds access on array error_text[] because of -ETIMEDOUT return from __send_command()

2020-08-20 Thread Markus Mayer
On Thu, 20 Aug 2020 at 10:23, Markus Mayer  wrote:
>
> On Wed, 19 Aug 2020 at 11:34, Florian Fainelli  wrote:
> >
> > On 8/18/20 5:21 AM, Colin Ian King wrote:
> > > Hi,
> > >
> > > static analysis with coverity has found a buffer overflow issue with the
> > > brcmstb driver, I believe it may have been introduced with the following
> > > commit:
> > >
> > > commit a7c25759d8d84b64c437a78f05df7314b02934e5
> > > Author: Markus Mayer 
> > > Date:   Tue Apr 2 16:01:00 2019 -0700
> > >
> > > memory: brcmstb: dpfe: wait for DCPU to be ready
> > >
> > > The static analysis is as follows for the source file
> > > /drivers/memory/brcmstb_dpfe.c :
> > >
> > > 684 static ssize_t generic_show(unsigned int command, u32 response[],
> > > 685struct brcmstb_dpfe_priv *priv, char *buf)
> > > 686 {
> > > 687int ret;
> > > 688
> > >1. Condition !priv, taking false branch.
> > >
> > > 689if (!priv)
> > > 690return sprintf(buf, "ERROR: driver private data not
> > > set\n");
> > > 691
> > >2. return_constant: Function call __send_command(priv, command,
> > > response) may return -110.
> > >3. assignment: Assigning: ret = __send_command(priv, command,
> > > response). The value of ret is now -110.
> > >
> > > 692ret = __send_command(priv, command, response);
> > >4. Condition ret < 0, taking true branch.
> > >
> > > 693if (ret < 0)
> > >
> > > Out-of-bounds read (OVERRUN)
> > >5. overrun-local: Overrunning array error_text of 6 8-byte elements
> > > at element index 110 (byte offset 887) using index -ret (which evaluates
> > > to 110).
> > > 694return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
> > > 695
> > > 696return 0;
> > > 697 }
> > >
> > >
> > > Function __send_command() can return -ETIMEDOUT and this causes an
> > > out-of-bounds access on error_text[].
> >
> > Markus, what do you think of this:
> >
> > diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> > index 60e8633b1175..b41c6251ddc3 100644
> > --- a/drivers/memory/brcmstb_dpfe.c
> > +++ b/drivers/memory/brcmstb_dpfe.c
> > @@ -445,7 +445,7 @@ static int __send_command(struct brcmstb_dpfe_priv
> > *priv, unsigned int cmd,
> > }
> > if (resp != 0) {
> > mutex_unlock(>lock);
> > -   return -ETIMEDOUT;
> > +   return -ffs(DCPU_RET_ERR_TIMEDOUT);
> > }
> >
> > /* Compute checksum over the message */
> >
> > That way we only return DCPU-style error code from __send_command and we
> > de-reference error_text accordingly? Or we could just introduce a proper
> > lookup with a function instead of a direct array de-reference.
>
> Let me do some experiments. What you are proposing should work and is
> in line with the current code. A lookup function might be cleaner,
> though.

I submitted a patch for review. See https://lkml.org/lkml/2020/8/20/2291.

Regards,
-Markus


[PATCH] memory: brcmstb_dpfe: fix array index out of bounds

2020-08-20 Thread Markus Mayer
We would overrun the error_text array if we hit a TIMEOUT condition,
because we were using the error code "ETIMEDOUT" (which is 110) as an
array index.

We fix the problem by correcting the array index and by providing a
function to retrieve error messages rather than accessing the array
directly. The function includes a bounds check that prevents the array
from being overrun.

Signed-off-by: Markus Mayer 
---

This patch was prepared in response to https://lkml.org/lkml/2020/8/18/505.

 drivers/memory/brcmstb_dpfe.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 81abc4a98a27..a986a849f58e 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -190,11 +190,6 @@ struct brcmstb_dpfe_priv {
struct mutex lock;
 };
 
-static const char * const error_text[] = {
-   "Success", "Header code incorrect", "Unknown command or argument",
-   "Incorrect checksum", "Malformed command", "Timed out",
-};
-
 /*
  * Forward declaration of our sysfs attribute functions, so we can declare the
  * attribute data structures early.
@@ -307,6 +302,20 @@ static const struct dpfe_api dpfe_api_v3 = {
},
 };
 
+static const char * const get_error_text(unsigned int i)
+{
+   static const char * const error_text[] = {
+   "Success", "Header code incorrect",
+   "Unknown command or argument", "Incorrect checksum",
+   "Malformed command", "Timed out", "Unknown error",
+   };
+
+   if (unlikely(i >= ARRAY_SIZE(error_text)))
+   i = ARRAY_SIZE(error_text) - 1;
+
+   return error_text[i];
+}
+
 static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
 {
u32 val;
@@ -446,7 +455,7 @@ static int __send_command(struct brcmstb_dpfe_priv *priv, 
unsigned int cmd,
}
if (resp != 0) {
mutex_unlock(>lock);
-   return -ETIMEDOUT;
+   return -ffs(DCPU_RET_ERR_TIMEDOUT);
}
 
/* Compute checksum over the message */
@@ -695,7 +704,7 @@ static ssize_t generic_show(unsigned int command, u32 
response[],
 
ret = __send_command(priv, command, response);
if (ret < 0)
-   return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
+   return sprintf(buf, "ERROR: %s\n", get_error_text(-ret));
 
return 0;
 }
-- 
2.17.1



Re: [PATCH v2] memory: brcmstb_dpfe: Fix memory leak

2020-08-20 Thread Markus Mayer
On Thu, 20 Aug 2020 at 10:21, Alex Dewar  wrote:
>
> In brcmstb_dpfe_download_firmware(), memory is allocated to variable fw by
> firmware_request_nowarn(), but never released. Fix up to release fw on
> all return paths.

Thanks for the fix!

Acked-by: Markus Mayer 

> Signed-off-by: Alex Dewar 
> ---
> v2: Don't assign ret unnecessarily (Krzysztof)
> ---
>  drivers/memory/brcmstb_dpfe.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 60e8633b1175..e08528b12cbd 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -647,8 +647,10 @@ static int brcmstb_dpfe_download_firmware(struct 
> brcmstb_dpfe_priv *priv)
> return (ret == -ENOENT) ? -EPROBE_DEFER : ret;
>
> ret = __verify_firmware(, fw);
> -   if (ret)
> -   return -EFAULT;
> +   if (ret) {
> +   ret = -EFAULT;
> +   goto release_fw;
> +   }
>
> __disable_dcpu(priv);
>
> @@ -667,18 +669,20 @@ static int brcmstb_dpfe_download_firmware(struct 
> brcmstb_dpfe_priv *priv)
>
> ret = __write_firmware(priv->dmem, dmem, dmem_size, is_big_endian);
> if (ret)
> -   return ret;
> +   goto release_fw;
> ret = __write_firmware(priv->imem, imem, imem_size, is_big_endian);
> if (ret)
> -   return ret;
> +   goto release_fw;
>
> ret = __verify_fw_checksum(, priv, header, init.chksum);
> if (ret)
> -   return ret;
> +   goto release_fw;
>
> __enable_dcpu(priv);
>
> -   return 0;
> +release_fw:
> +   release_firmware(fw);
> +   return ret;
>  }
>
>  static ssize_t generic_show(unsigned int command, u32 response[],
> --
> 2.28.0
>


Re: out of bounds access on array error_text[] because of -ETIMEDOUT return from __send_command()

2020-08-20 Thread Markus Mayer
On Wed, 19 Aug 2020 at 11:34, Florian Fainelli  wrote:
>
> On 8/18/20 5:21 AM, Colin Ian King wrote:
> > Hi,
> >
> > static analysis with coverity has found a buffer overflow issue with the
> > brcmstb driver, I believe it may have been introduced with the following
> > commit:
> >
> > commit a7c25759d8d84b64c437a78f05df7314b02934e5
> > Author: Markus Mayer 
> > Date:   Tue Apr 2 16:01:00 2019 -0700
> >
> > memory: brcmstb: dpfe: wait for DCPU to be ready
> >
> > The static analysis is as follows for the source file
> > /drivers/memory/brcmstb_dpfe.c :
> >
> > 684 static ssize_t generic_show(unsigned int command, u32 response[],
> > 685struct brcmstb_dpfe_priv *priv, char *buf)
> > 686 {
> > 687int ret;
> > 688
> >1. Condition !priv, taking false branch.
> >
> > 689if (!priv)
> > 690return sprintf(buf, "ERROR: driver private data not
> > set\n");
> > 691
> >2. return_constant: Function call __send_command(priv, command,
> > response) may return -110.
> >3. assignment: Assigning: ret = __send_command(priv, command,
> > response). The value of ret is now -110.
> >
> > 692ret = __send_command(priv, command, response);
> >4. Condition ret < 0, taking true branch.
> >
> > 693if (ret < 0)
> >
> > Out-of-bounds read (OVERRUN)
> >5. overrun-local: Overrunning array error_text of 6 8-byte elements
> > at element index 110 (byte offset 887) using index -ret (which evaluates
> > to 110).
> > 694return sprintf(buf, "ERROR: %s\n", error_text[-ret]);
> > 695
> > 696return 0;
> > 697 }
> >
> >
> > Function __send_command() can return -ETIMEDOUT and this causes an
> > out-of-bounds access on error_text[].
>
> Markus, what do you think of this:
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 60e8633b1175..b41c6251ddc3 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -445,7 +445,7 @@ static int __send_command(struct brcmstb_dpfe_priv
> *priv, unsigned int cmd,
> }
> if (resp != 0) {
> mutex_unlock(>lock);
> -   return -ETIMEDOUT;
> +   return -ffs(DCPU_RET_ERR_TIMEDOUT);
> }
>
> /* Compute checksum over the message */
>
> That way we only return DCPU-style error code from __send_command and we
> de-reference error_text accordingly? Or we could just introduce a proper
> lookup with a function instead of a direct array de-reference.

Let me do some experiments. What you are proposing should work and is
in line with the current code. A lookup function might be cleaner,
though.

Thanks,
-Markus

> --
> Florian


Build error caused by "arm64: dts: agilex: add nand clocks"

2020-08-04 Thread Markus Mayer
Hi,

I don't know if anybody else is seeing this, but for me the commit
"arm64: dts: agilex: add nand clocks"[1] is causing a build error
while generating DTS files for ARM64.

The error goes away when I drop the commit.

$ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig dtbs
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX scripts/kconfig/lexer.lex.c
  YACCscripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'defconfig'
[...]
  DTC arch/arm64/boot/dts/freescale/imx8mq-pico-pi.dtb
  DTC arch/arm64/boot/dts/freescale/imx8mq-thor96.dtb
  DTC arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-rmb3.dtb
  DTC arch/arm64/boot/dts/freescale/imx8mq-zii-ultra-zest.dtb
  DTC arch/arm64/boot/dts/freescale/imx8qxp-ai_ml.dtb
  DTC arch/arm64/boot/dts/freescale/imx8qxp-colibri-eval-v3.dtb
  DTC arch/arm64/boot/dts/freescale/imx8qxp-mek.dtb
  DTC arch/arm64/boot/dts/freescale/s32v234-evb.dtb
  DTC arch/arm64/boot/dts/hisilicon/hi3660-hikey960.dtb
  DTC arch/arm64/boot/dts/hisilicon/hi3670-hikey970.dtb
  DTC arch/arm64/boot/dts/hisilicon/hi3798cv200-poplar.dtb
  DTC arch/arm64/boot/dts/hisilicon/hi6220-hikey.dtb
  DTC arch/arm64/boot/dts/hisilicon/hip05-d02.dtb
  DTC arch/arm64/boot/dts/hisilicon/hip06-d03.dtb
  DTC arch/arm64/boot/dts/hisilicon/hip07-d05.dtb
  DTC arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dtb
Error: arch/arm64/boot/dts/intel/socfpga_agilex.dtsi:313.15-16 syntax error
FATAL ERROR: Unable to parse input tree
make[3]: *** [scripts/Makefile.lib:309:
arch/arm64/boot/dts/intel/socfpga_agilex_socdk.dtb] Error 1
make[2]: *** [scripts/Makefile.build:497: arch/arm64/boot/dts/intel] Error 2
make[1]: *** [Makefile:1306: dtbs] Error 2
make: *** [Makefile:336: __build_one_by_one] Error 2

Regards,
-Markus

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d4ae4dd346cd49302d157b129ead2f60d3a82534


Re: [PATCH 16/23] memory: brcmstb_dpfe: Constify the contents of string

2020-07-23 Thread Markus Mayer
On Thu, 23 Jul 2020 at 10:11, Florian Fainelli  wrote:
>
> On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> > The string itself can be made const for safety.
> >
> > Signed-off-by: Krzysztof Kozlowski 
>
> Acked-by: Florian Fainelli 

Acked-by: Markus Mayer 


Re: [PATCH 17/23] memory: brcmstb_dpfe: Remove unneeded braces

2020-07-23 Thread Markus Mayer
On Thu, 23 Jul 2020 at 10:11, Florian Fainelli  wrote:
>
> On 7/23/20 12:37 AM, Krzysztof Kozlowski wrote:
> > Single statement blocks don't need braces.  Fixes checkpatch warning:
> >
> > WARNING: braces {} are not necessary for single statement blocks
> >
> > Signed-off-by: Krzysztof Kozlowski 
>
> Acked-by: Florian Fainelli 

Acked-by: Markus Mayer 


[PATCH] tools/thermal: tmon: include pthread and time headers in tmon.h

2020-06-17 Thread Markus Mayer
Include sys/time.h and pthread.h in tmon.h, so that types
"pthread_mutex_t" and "struct timeval tv" are known when tmon.h
references them.

Without these headers, compiling tmon against musl-libc will fail with
these errors:

In file included from sysfs.c:31:0:
tmon.h:47:8: error: unknown type name 'pthread_mutex_t'
 extern pthread_mutex_t input_lock;
^~~
make[3]: *** [: sysfs.o] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from tui.c:31:0:
tmon.h:54:17: error: field 'tv' has incomplete type
  struct timeval tv;
 ^~
make[3]: *** [: tui.o] Error 1
make[2]: *** [Makefile:83: tmon] Error 2

Signed-off-by: Markus Mayer 
---

The issue was discovered cross-compiling tmon for aarch64 with musl-libc.
The build succeeds with glibc, because the required headers are included
implicitly. This is not the case with musl-libc.

 tools/thermal/tmon/tmon.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/thermal/tmon/tmon.h b/tools/thermal/tmon/tmon.h
index c9066ec104dd..44d16d778f04 100644
--- a/tools/thermal/tmon/tmon.h
+++ b/tools/thermal/tmon/tmon.h
@@ -27,6 +27,9 @@
 #define NR_LINES_TZDATA 1
 #define TMON_LOG_FILE "/var/tmp/tmon.log"
 
+#include 
+#include 
+
 extern unsigned long ticktime;
 extern double time_elapsed;
 extern unsigned long target_temp_user;
-- 
2.17.1



[PATCH 3/3] cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS

2020-05-28 Thread Markus Mayer
On suspend we send AVS_CMD_S2_ENTER and on resume AVS_CMD_S2_EXIT.
These are best effort calls, so we don't check the return code or take
any action if either of the calls fails.

Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 79a0538a531a..3e31e5d28b79 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -506,7 +506,14 @@ static int brcm_avs_suspend(struct cpufreq_policy *policy)
 * AVS co-processor, not necessarily the P-state we are running at now.
 * So, we get the current P-state explicitly.
 */
-   return brcm_avs_get_pstate(priv, >pmap.state);
+   ret = brcm_avs_get_pstate(priv, >pmap.state);
+   if (ret)
+   return ret;
+
+   /* This is best effort. Nothing to do if it fails. */
+   (void)__issue_avs_command(priv, AVS_CMD_S2_ENTER, 0, 0, NULL);
+
+   return 0;
 }
 
 static int brcm_avs_resume(struct cpufreq_policy *policy)
@@ -514,6 +521,9 @@ static int brcm_avs_resume(struct cpufreq_policy *policy)
struct private_data *priv = policy->driver_data;
int ret;
 
+   /* This is best effort. Nothing to do if it fails. */
+   (void)__issue_avs_command(priv, AVS_CMD_S2_EXIT, 0, 0, NULL);
+
ret = brcm_avs_set_pmap(priv, >pmap);
if (ret == -EEXIST) {
struct platform_device *pdev  = cpufreq_get_driver_data();
-- 
2.17.1



[PATCH 2/3] cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware

2020-05-28 Thread Markus Mayer
From: Florian Fainelli 

In case the interrupt towards the host is never raised, yet the AVS
firmware responds correctly within the alloted time, allow supporting a
polling mode.

Signed-off-by: Florian Fainelli 
Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 47 +++
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index c8b754694a5e..79a0538a531a 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -42,6 +42,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -178,6 +179,7 @@ struct private_data {
struct completion done;
struct semaphore sem;
struct pmap pmap;
+   int host_irq;
 };
 
 static void __iomem *__map_region(const char *name)
@@ -195,12 +197,36 @@ static void __iomem *__map_region(const char *name)
return ptr;
 }
 
+static unsigned long wait_for_avs_command(struct private_data *priv,
+ unsigned long timeout)
+{
+   unsigned long time_left = 0;
+   u32 val;
+
+   /* Event driven, wait for the command interrupt */
+   if (priv->host_irq >= 0)
+   return wait_for_completion_timeout(>done,
+  msecs_to_jiffies(timeout));
+
+   /* Polling for command completion */
+   do {
+   time_left = timeout;
+   val = readl(priv->base + AVS_MBOX_STATUS);
+   if (val)
+   break;
+
+   usleep_range(1000, 2000);
+   } while (--timeout);
+
+   return time_left;
+}
+
 static int __issue_avs_command(struct private_data *priv, unsigned int cmd,
   unsigned int num_in, unsigned int num_out,
   u32 args[])
 {
-   unsigned long time_left = msecs_to_jiffies(AVS_TIMEOUT);
void __iomem *base = priv->base;
+   unsigned long time_left;
unsigned int i;
int ret;
u32 val;
@@ -238,7 +264,7 @@ static int __issue_avs_command(struct private_data *priv, 
unsigned int cmd,
writel(AVS_CPU_L2_INT_MASK, priv->avs_intr_base + AVS_CPU_L2_SET0);
 
/* Wait for AVS co-processor to finish processing the command. */
-   time_left = wait_for_completion_timeout(>done, time_left);
+   time_left = wait_for_avs_command(priv, AVS_TIMEOUT);
 
/*
 * If the AVS status is not in the expected range, it means AVS didn't
@@ -509,7 +535,7 @@ static int brcm_avs_prepare_init(struct platform_device 
*pdev)
 {
struct private_data *priv;
struct device *dev;
-   int host_irq, ret;
+   int ret;
 
dev = >dev;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -536,19 +562,14 @@ static int brcm_avs_prepare_init(struct platform_device 
*pdev)
goto unmap_base;
}
 
-   host_irq = platform_get_irq_byname(pdev, BRCM_AVS_HOST_INTR);
-   if (host_irq < 0) {
-   dev_err(dev, "Couldn't find interrupt %s -- %d\n",
-   BRCM_AVS_HOST_INTR, host_irq);
-   ret = host_irq;
-   goto unmap_intr_base;
-   }
+   priv->host_irq = platform_get_irq_byname(pdev, BRCM_AVS_HOST_INTR);
 
-   ret = devm_request_irq(dev, host_irq, irq_handler, IRQF_TRIGGER_RISING,
+   ret = devm_request_irq(dev, priv->host_irq, irq_handler,
+  IRQF_TRIGGER_RISING,
   BRCM_AVS_HOST_INTR, priv);
-   if (ret) {
+   if (ret && priv->host_irq >= 0) {
dev_err(dev, "IRQ request failed: %s (%d) -- %d\n",
-   BRCM_AVS_HOST_INTR, host_irq, ret);
+   BRCM_AVS_HOST_INTR, priv->host_irq, ret);
goto unmap_intr_base;
}
 
-- 
2.17.1



[PATCH 1/3] cpufreq: brcmstb-avs-cpufreq: more flexible interface for __issue_avs_command()

2020-05-28 Thread Markus Mayer
We are changing how parameters are passed to __issue_avs_command(), so we
can pass input *and* output arguments with the same command, rather than
just one or the other.

Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 30 +--
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 4f86ce2db34f..c8b754694a5e 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -195,7 +195,8 @@ static void __iomem *__map_region(const char *name)
return ptr;
 }
 
-static int __issue_avs_command(struct private_data *priv, int cmd, bool 
is_send,
+static int __issue_avs_command(struct private_data *priv, unsigned int cmd,
+  unsigned int num_in, unsigned int num_out,
   u32 args[])
 {
unsigned long time_left = msecs_to_jiffies(AVS_TIMEOUT);
@@ -225,11 +226,9 @@ static int __issue_avs_command(struct private_data *priv, 
int cmd, bool is_send,
/* Clear status before we begin. */
writel(AVS_STATUS_CLEAR, base + AVS_MBOX_STATUS);
 
-   /* We need to send arguments for this command. */
-   if (args && is_send) {
-   for (i = 0; i < AVS_MAX_CMD_ARGS; i++)
-   writel(args[i], base + AVS_MBOX_PARAM(i));
-   }
+   /* Provide input parameters */
+   for (i = 0; i < num_in; i++)
+   writel(args[i], base + AVS_MBOX_PARAM(i));
 
/* Protect from spurious interrupts. */
reinit_completion(>done);
@@ -256,11 +255,9 @@ static int __issue_avs_command(struct private_data *priv, 
int cmd, bool is_send,
goto out;
}
 
-   /* This command returned arguments, so we read them back. */
-   if (args && !is_send) {
-   for (i = 0; i < AVS_MAX_CMD_ARGS; i++)
-   args[i] = readl(base + AVS_MBOX_PARAM(i));
-   }
+   /* Process returned values */
+   for (i = 0; i < num_out; i++)
+   args[i] = readl(base + AVS_MBOX_PARAM(i));
 
/* Clear status to tell AVS co-processor we are done. */
writel(AVS_STATUS_CLEAR, base + AVS_MBOX_STATUS);
@@ -338,7 +335,7 @@ static int brcm_avs_get_pmap(struct private_data *priv, 
struct pmap *pmap)
u32 args[AVS_MAX_CMD_ARGS];
int ret;
 
-   ret = __issue_avs_command(priv, AVS_CMD_GET_PMAP, false, args);
+   ret = __issue_avs_command(priv, AVS_CMD_GET_PMAP, 0, 4, args);
if (ret || !pmap)
return ret;
 
@@ -359,7 +356,7 @@ static int brcm_avs_set_pmap(struct private_data *priv, 
struct pmap *pmap)
args[2] = pmap->p2;
args[3] = pmap->state;
 
-   return __issue_avs_command(priv, AVS_CMD_SET_PMAP, true, args);
+   return __issue_avs_command(priv, AVS_CMD_SET_PMAP, 4, 0, args);
 }
 
 static int brcm_avs_get_pstate(struct private_data *priv, unsigned int *pstate)
@@ -367,7 +364,7 @@ static int brcm_avs_get_pstate(struct private_data *priv, 
unsigned int *pstate)
u32 args[AVS_MAX_CMD_ARGS];
int ret;
 
-   ret = __issue_avs_command(priv, AVS_CMD_GET_PSTATE, false, args);
+   ret = __issue_avs_command(priv, AVS_CMD_GET_PSTATE, 0, 1, args);
if (ret)
return ret;
*pstate = args[0];
@@ -381,7 +378,8 @@ static int brcm_avs_set_pstate(struct private_data *priv, 
unsigned int pstate)
 
args[0] = pstate;
 
-   return __issue_avs_command(priv, AVS_CMD_SET_PSTATE, true, args);
+   return __issue_avs_command(priv, AVS_CMD_SET_PSTATE, 1, 0, args);
+
 }
 
 static u32 brcm_avs_get_voltage(void __iomem *base)
@@ -593,7 +591,7 @@ static int brcm_avs_cpufreq_init(struct cpufreq_policy 
*policy)
/* All cores share the same clock and thus the same policy. */
cpumask_setall(policy->cpus);
 
-   ret = __issue_avs_command(priv, AVS_CMD_ENABLE, false, NULL);
+   ret = __issue_avs_command(priv, AVS_CMD_ENABLE, 0, 0, NULL);
if (!ret) {
unsigned int pstate;
 
-- 
2.17.1



[PATCH 0/3] brcmstb-avs-cpufreq updates

2020-05-28 Thread Markus Mayer
Hi all,

Here is a collection of little, independent improvements to the
brcmstb-avs-cpufreq driver.

- more flexible interface for __issue_avs_command()
  This change makes the function more versatile as it can handle input
  and output parameters at the same time.
- Support polling AVS firmware
  This change allows the driver to use polling if interrupt driven mode
  doesn't work for some reason.
- send S2_ENTER / S2_EXIT commands to AVS
  Let the AVS firmware know when we are about to enter, or have just
  exited, S2 mode.

Regards,
-Markus

Florian Fainelli (1):
  cpufreq: brcmstb-avs-cpufreq: Support polling AVS firmware

Markus Mayer (2):
  cpufreq: brcmstb-avs-cpufreq: more flexible interface for
__issue_avs_command()
  cpufreq: brcmstb-avs-cpufreq: send S2_ENTER / S2_EXIT commands to AVS

 drivers/cpufreq/brcmstb-avs-cpufreq.c | 89 ++-
 1 file changed, 59 insertions(+), 30 deletions(-)

-- 
2.17.1



[PATCH 4/8] memory: brcmstb: dpfe: move init_data into brcmstb_dpfe_download_firmware()

2019-10-15 Thread Markus Mayer
Rather than declaring our init_data in several places and passing it as
parameter into brcmstb_dpfe_download_firmware(), we declare it inside
brcmstb_dpfe_download_firmware() instead.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index c10c24a76729..3b61e7108912 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -582,8 +582,7 @@ static int __write_firmware(u32 __iomem *mem, const u32 *fw,
return 0;
 }
 
-static int brcmstb_dpfe_download_firmware(struct platform_device *pdev,
- struct init_data *init)
+static int brcmstb_dpfe_download_firmware(struct platform_device *pdev)
 {
const struct dpfe_firmware_header *header;
unsigned int dmem_size, imem_size;
@@ -592,6 +591,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
struct brcmstb_dpfe_priv *priv;
const struct firmware *fw;
const u32 *dmem, *imem;
+   struct init_data init;
const void *fw_blob;
int ret;
 
@@ -622,15 +622,15 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
if (ret)
return ret;
 
-   ret = __verify_firmware(init, fw);
+   ret = __verify_firmware(, fw);
if (ret)
return -EFAULT;
 
__disable_dcpu(priv);
 
-   is_big_endian = init->is_big_endian;
-   dmem_size = init->dmem_len;
-   imem_size = init->imem_len;
+   is_big_endian = init.is_big_endian;
+   dmem_size = init.dmem_len;
+   imem_size = init.imem_len;
 
/* At the beginning of the firmware blob is a header. */
header = (struct dpfe_firmware_header *)fw->data;
@@ -648,7 +648,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
if (ret)
return ret;
 
-   ret = __verify_fw_checksum(init, priv, header, init->chksum);
+   ret = __verify_fw_checksum(, priv, header, init.chksum);
if (ret)
return ret;
 
@@ -811,16 +811,13 @@ static ssize_t show_dram(struct device *dev, struct 
device_attribute *devattr,
 
 static int brcmstb_dpfe_resume(struct platform_device *pdev)
 {
-   struct init_data init;
-
-   return brcmstb_dpfe_download_firmware(pdev, );
+   return brcmstb_dpfe_download_firmware(pdev);
 }
 
 static int brcmstb_dpfe_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct brcmstb_dpfe_priv *priv;
-   struct init_data init;
struct resource *res;
int ret;
 
@@ -864,7 +861,7 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   ret = brcmstb_dpfe_download_firmware(pdev, );
+   ret = brcmstb_dpfe_download_firmware(pdev);
if (ret) {
dev_err(dev, "Couldn't download firmware -- %d\n", ret);
return ret;
-- 
2.17.1



[PATCH 5/8] memory: brcmstb: dpfe: pass *priv as argument to brcmstb_dpfe_download_firmware()

2019-10-15 Thread Markus Mayer
Rather than passing a (struct platform_device *) to
brcmstb_dpfe_download_firmware(), we pass a (struct private_data *).
This is the more sensible thing to do.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 3b61e7108912..f905a0076db7 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -582,21 +582,18 @@ static int __write_firmware(u32 __iomem *mem, const u32 
*fw,
return 0;
 }
 
-static int brcmstb_dpfe_download_firmware(struct platform_device *pdev)
+static int brcmstb_dpfe_download_firmware(struct brcmstb_dpfe_priv *priv)
 {
const struct dpfe_firmware_header *header;
unsigned int dmem_size, imem_size;
-   struct device *dev = >dev;
+   struct device *dev = priv->dev;
bool is_big_endian = false;
-   struct brcmstb_dpfe_priv *priv;
const struct firmware *fw;
const u32 *dmem, *imem;
struct init_data init;
const void *fw_blob;
int ret;
 
-   priv = platform_get_drvdata(pdev);
-
/*
 * Skip downloading the firmware if the DCPU is already running and
 * responding to commands.
@@ -811,7 +808,9 @@ static ssize_t show_dram(struct device *dev, struct 
device_attribute *devattr,
 
 static int brcmstb_dpfe_resume(struct platform_device *pdev)
 {
-   return brcmstb_dpfe_download_firmware(pdev);
+   struct brcmstb_dpfe_priv *priv = platform_get_drvdata(pdev);
+
+   return brcmstb_dpfe_download_firmware(priv);
 }
 
 static int brcmstb_dpfe_probe(struct platform_device *pdev)
@@ -861,7 +860,7 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
return -ENOENT;
}
 
-   ret = brcmstb_dpfe_download_firmware(pdev);
+   ret = brcmstb_dpfe_download_firmware(priv);
if (ret) {
dev_err(dev, "Couldn't download firmware -- %d\n", ret);
return ret;
-- 
2.17.1



[PATCH 7/8] memory: brcmstb: dpfe: Compute checksum at __send_command() time

2019-10-15 Thread Markus Mayer
From: Florian Fainelli 

Instead of pre-computing the checksum, do it at the time we send the
command, this reduces the possibility of introducing errors as well as
limits the amount of code necessary while adding new commands and/or new
API versions. The MSG_CHKSUM enumeration value is no longer necessary
and is removed.

Signed-off-by: Florian Fainelli 
Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index cf320302d2c0..7c6e85ad25a7 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -127,7 +127,6 @@ enum dpfe_msg_fields {
MSG_COMMAND,
MSG_ARG_COUNT,
MSG_ARG0,
-   MSG_CHKSUM,
MSG_FIELD_MAX   = 16 /* Max number of arguments */
 };
 
@@ -243,21 +242,18 @@ static const struct dpfe_api dpfe_api_v2 = {
[MSG_COMMAND] = 1,
[MSG_ARG_COUNT] = 1,
[MSG_ARG0] = 1,
-   [MSG_CHKSUM] = 4,
},
[DPFE_CMD_GET_REFRESH] = {
[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
[MSG_COMMAND] = 2,
[MSG_ARG_COUNT] = 1,
[MSG_ARG0] = 1,
-   [MSG_CHKSUM] = 5,
},
[DPFE_CMD_GET_VENDOR] = {
[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
[MSG_COMMAND] = 2,
[MSG_ARG_COUNT] = 1,
[MSG_ARG0] = 2,
-   [MSG_CHKSUM] = 6,
},
}
 };
@@ -273,18 +269,11 @@ static const struct dpfe_api dpfe_api_v3 = {
[MSG_COMMAND] = 0x0101,
[MSG_ARG_COUNT] = 1,
[MSG_ARG0] = 1,
-   [MSG_CHKSUM] = 0x104,
},
[DPFE_CMD_GET_REFRESH] = {
[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
[MSG_COMMAND] = 0x0202,
[MSG_ARG_COUNT] = 0,
-   /*
-* This is a bit ugly. Without arguments, the checksum
-* follows right after the argument count and not at
-* offset MSG_CHKSUM.
-*/
-   [MSG_ARG0] = 0x203,
},
/* There's no GET_VENDOR command in API v3. */
},
@@ -432,9 +421,17 @@ static int __send_command(struct brcmstb_dpfe_priv *priv, 
unsigned int cmd,
return -ETIMEDOUT;
}
 
+   /* Compute checksum over the message */
+   chksum_idx = msg[MSG_ARG_COUNT] + MSG_ARG_COUNT + 1;
+   chksum = get_msg_chksum(msg, chksum_idx);
+
/* Write command and arguments to message area */
-   for (i = 0; i < MSG_FIELD_MAX; i++)
-   writel_relaxed(msg[i], regs + DCPU_MSG_RAM(i));
+   for (i = 0; i < MSG_FIELD_MAX; i++) {
+   if (i == chksum_idx)
+   writel_relaxed(chksum, regs + DCPU_MSG_RAM(i));
+   else
+   writel_relaxed(msg[i], regs + DCPU_MSG_RAM(i));
+   }
 
/* Tell DCPU there is a command waiting */
writel_relaxed(1, regs + REG_TO_DCPU_MBOX);
-- 
2.17.1



[PATCH 8/8] memory: brcmstb: dpfe: Fixup API version/commands for 7211

2019-10-15 Thread Markus Mayer
From: Florian Fainelli 

7211 uses a newer version of API v2 which is half way between what was
defined as API v3 and what used to be called API v2 but was used with
DPFE firmwares with major versions 1.x.x.x. Starting with **the new**
API v2, we are no longer getting loadable firmware images, so the
capability to load it is removed (like v3).

To avoid spreading more confusion, map 7268/7271/7278 to the old DPFE
API version 2, 7211 to the new API v2 and introduce the specific
commands for that, and leave newer versions to map to API v3.

Signed-off-by: Florian Fainelli 
Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 44 ---
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 7c6e85ad25a7..82b415be18d1 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -231,9 +231,13 @@ static struct attribute *dpfe_v3_attrs[] = {
 };
 ATTRIBUTE_GROUPS(dpfe_v3);
 
-/* API v2 firmware commands */
-static const struct dpfe_api dpfe_api_v2 = {
-   .version = 2,
+/*
+ * Old API v2 firmware commands, as defined in the rev 0.61 specification, we
+ * use a version set to 1 to denote that it is not compatible with the new API
+ * v2 and onwards.
+ */
+static const struct dpfe_api dpfe_api_old_v2 = {
+   .version = 1,
.fw_name = "dpfe.bin",
.sysfs_attrs = dpfe_v2_groups,
.command = {
@@ -258,6 +262,30 @@ static const struct dpfe_api dpfe_api_v2 = {
}
 };
 
+/*
+ * API v2 firmware commands, as defined in the rev 0.8 specification, named new
+ * v2 here
+ */
+static const struct dpfe_api dpfe_api_new_v2 = {
+   .version = 2,
+   .fw_name = NULL, /* We expect the firmware to have been downloaded! */
+   .sysfs_attrs = dpfe_v2_groups,
+   .command = {
+   [DPFE_CMD_GET_INFO] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 0x101,
+   },
+   [DPFE_CMD_GET_REFRESH] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 0x201,
+   },
+   [DPFE_CMD_GET_VENDOR] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 0x202,
+   },
+   }
+};
+
 /* API v3 firmware commands */
 static const struct dpfe_api dpfe_api_v3 = {
.version = 3,
@@ -390,7 +418,7 @@ static void __finalize_command(struct brcmstb_dpfe_priv 
*priv)
 * It depends on the API version which MBOX register we have to write to
 * to signal we are done.
 */
-   release_mbox = (priv->dpfe_api->version < 3)
+   release_mbox = (priv->dpfe_api->version < 2)
? REG_TO_HOST_MBOX : REG_TO_DCPU_MBOX;
writel_relaxed(0, priv->regs + release_mbox);
 }
@@ -886,10 +914,10 @@ static int brcmstb_dpfe_remove(struct platform_device 
*pdev)
 
 static const struct of_device_id brcmstb_dpfe_of_match[] = {
/* Use legacy API v2 for a select number of chips */
-   { .compatible = "brcm,bcm7268-dpfe-cpu", .data = _api_v2 },
-   { .compatible = "brcm,bcm7271-dpfe-cpu", .data = _api_v2 },
-   { .compatible = "brcm,bcm7278-dpfe-cpu", .data = _api_v2 },
-   { .compatible = "brcm,bcm7211-dpfe-cpu", .data = _api_v2 },
+   { .compatible = "brcm,bcm7268-dpfe-cpu", .data = _api_old_v2 },
+   { .compatible = "brcm,bcm7271-dpfe-cpu", .data = _api_old_v2 },
+   { .compatible = "brcm,bcm7278-dpfe-cpu", .data = _api_old_v2 },
+   { .compatible = "brcm,bcm7211-dpfe-cpu", .data = _api_new_v2 },
/* API v3 is the default going forward */
{ .compatible = "brcm,dpfe-cpu", .data = _api_v3 },
{}
-- 
2.17.1



[PATCH 6/8] memory: brcmstb: dpfe: support for deferred firmware download

2019-10-15 Thread Markus Mayer
We add support for deferred downloading of the DPFE firmware. It may be
necessary to do this if the root file system containing the firmware
image is not yet available at the time the driver's probe function is
being called.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index f905a0076db7..cf320302d2c0 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -614,10 +614,13 @@ static int brcmstb_dpfe_download_firmware(struct 
brcmstb_dpfe_priv *priv)
if (!priv->dpfe_api->fw_name)
return -ENODEV;
 
-   ret = request_firmware(, priv->dpfe_api->fw_name, dev);
-   /* request_firmware() prints its own error messages. */
+   ret = firmware_request_nowarn(, priv->dpfe_api->fw_name, dev);
+   /*
+* Defer the firmware download if the firmware file couldn't be found.
+* The root file system may not be available yet.
+*/
if (ret)
-   return ret;
+   return (ret == -ENOENT) ? -EPROBE_DEFER : ret;
 
ret = __verify_firmware(, fw);
if (ret)
@@ -862,7 +865,8 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
 
ret = brcmstb_dpfe_download_firmware(priv);
if (ret) {
-   dev_err(dev, "Couldn't download firmware -- %d\n", ret);
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Couldn't download firmware -- %d\n", ret);
return ret;
}
 
-- 
2.17.1



[PATCH 3/8] memory: brcmstb: dpfe: add locking around DCPU enable/disable

2019-10-15 Thread Markus Mayer
To ensure consistency, we add locking primitives inside the DCPU enable
and disable routines.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 2ef3e365c1b5..c10c24a76729 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -290,32 +290,41 @@ static const struct dpfe_api dpfe_api_v3 = {
},
 };
 
-static bool is_dcpu_enabled(void __iomem *regs)
+static bool is_dcpu_enabled(struct brcmstb_dpfe_priv *priv)
 {
u32 val;
 
-   val = readl_relaxed(regs + REG_DCPU_RESET);
+   mutex_lock(>lock);
+   val = readl_relaxed(priv->regs + REG_DCPU_RESET);
+   mutex_unlock(>lock);
 
return !(val & DCPU_RESET_MASK);
 }
 
-static void __disable_dcpu(void __iomem *regs)
+static void __disable_dcpu(struct brcmstb_dpfe_priv *priv)
 {
u32 val;
 
-   if (!is_dcpu_enabled(regs))
+   if (!is_dcpu_enabled(priv))
return;
 
+   mutex_lock(>lock);
+
/* Put DCPU in reset if it's running. */
-   val = readl_relaxed(regs + REG_DCPU_RESET);
+   val = readl_relaxed(priv->regs + REG_DCPU_RESET);
val |= (1 << DCPU_RESET_SHIFT);
-   writel_relaxed(val, regs + REG_DCPU_RESET);
+   writel_relaxed(val, priv->regs + REG_DCPU_RESET);
+
+   mutex_unlock(>lock);
 }
 
-static void __enable_dcpu(void __iomem *regs)
+static void __enable_dcpu(struct brcmstb_dpfe_priv *priv)
 {
+   void __iomem *regs = priv->regs;
u32 val;
 
+   mutex_lock(>lock);
+
/* Clear mailbox registers. */
writel_relaxed(0, regs + REG_TO_DCPU_MBOX);
writel_relaxed(0, regs + REG_TO_HOST_MBOX);
@@ -329,6 +338,8 @@ static void __enable_dcpu(void __iomem *regs)
val = readl_relaxed(regs + REG_DCPU_RESET);
val &= ~(1 << DCPU_RESET_SHIFT);
writel_relaxed(val, regs + REG_DCPU_RESET);
+
+   mutex_unlock(>lock);
 }
 
 static unsigned int get_msg_chksum(const u32 msg[], unsigned int max)
@@ -590,7 +601,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
 * Skip downloading the firmware if the DCPU is already running and
 * responding to commands.
 */
-   if (is_dcpu_enabled(priv->regs)) {
+   if (is_dcpu_enabled(priv)) {
u32 response[MSG_FIELD_MAX];
 
ret = __send_command(priv, DPFE_CMD_GET_INFO, response);
@@ -615,7 +626,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
if (ret)
return -EFAULT;
 
-   __disable_dcpu(priv->regs);
+   __disable_dcpu(priv);
 
is_big_endian = init->is_big_endian;
dmem_size = init->dmem_len;
@@ -641,7 +652,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
if (ret)
return ret;
 
-   __enable_dcpu(priv->regs);
+   __enable_dcpu(priv);
 
return 0;
 }
-- 
2.17.1



[PATCH 1/8] memory: brcmstb: dpfe: rename struct private_data

2019-10-15 Thread Markus Mayer
To avoid potential (future) conflicts with other data structures we
rename "struct private_data" to "struct brcmstb_dpfe_priv".

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 6827ed484750..0c4c01d2bf48 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -180,7 +180,7 @@ struct dpfe_api {
 };
 
 /* Things we need for as long as we are active. */
-struct private_data {
+struct brcmstb_dpfe_priv {
void __iomem *regs;
void __iomem *dmem;
void __iomem *imem;
@@ -343,7 +343,7 @@ static unsigned int get_msg_chksum(const u32 msg[], 
unsigned int max)
return sum;
 }
 
-static void __iomem *get_msg_ptr(struct private_data *priv, u32 response,
+static void __iomem *get_msg_ptr(struct brcmstb_dpfe_priv *priv, u32 response,
 char *buf, ssize_t *size)
 {
unsigned int msg_type;
@@ -382,7 +382,7 @@ static void __iomem *get_msg_ptr(struct private_data *priv, 
u32 response,
return ptr;
 }
 
-static void __finalize_command(struct private_data *priv)
+static void __finalize_command(struct brcmstb_dpfe_priv *priv)
 {
unsigned int release_mbox;
 
@@ -395,7 +395,7 @@ static void __finalize_command(struct private_data *priv)
writel_relaxed(0, priv->regs + release_mbox);
 }
 
-static int __send_command(struct private_data *priv, unsigned int cmd,
+static int __send_command(struct brcmstb_dpfe_priv *priv, unsigned int cmd,
  u32 result[])
 {
const u32 *msg = priv->dpfe_api->command[cmd];
@@ -517,7 +517,7 @@ static int __verify_firmware(struct init_data *init,
 
 /* Verify checksum by reading back the firmware from co-processor RAM. */
 static int __verify_fw_checksum(struct init_data *init,
-   struct private_data *priv,
+   struct brcmstb_dpfe_priv *priv,
const struct dpfe_firmware_header *header,
u32 checksum)
 {
@@ -578,7 +578,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
unsigned int dmem_size, imem_size;
struct device *dev = >dev;
bool is_big_endian = false;
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
const struct firmware *fw;
const u32 *dmem, *imem;
const void *fw_blob;
@@ -647,7 +647,7 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
 }
 
 static ssize_t generic_show(unsigned int command, u32 response[],
-   struct private_data *priv, char *buf)
+   struct brcmstb_dpfe_priv *priv, char *buf)
 {
int ret;
 
@@ -665,7 +665,7 @@ static ssize_t show_info(struct device *dev, struct 
device_attribute *devattr,
 char *buf)
 {
u32 response[MSG_FIELD_MAX];
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
unsigned int info;
ssize_t ret;
 
@@ -688,7 +688,7 @@ static ssize_t show_refresh(struct device *dev,
 {
u32 response[MSG_FIELD_MAX];
void __iomem *info;
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
u8 refresh, sr_abort, ppre, thermal_offs, tuf;
u32 mr4;
ssize_t ret;
@@ -721,7 +721,7 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
  const char *buf, size_t count)
 {
u32 response[MSG_FIELD_MAX];
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
void __iomem *info;
unsigned long val;
int ret;
@@ -747,7 +747,7 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
   char *buf)
 {
u32 response[MSG_FIELD_MAX];
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
void __iomem *info;
ssize_t ret;
u32 mr5, mr6, mr7, mr8, err;
@@ -778,7 +778,7 @@ static ssize_t show_dram(struct device *dev, struct 
device_attribute *devattr,
 char *buf)
 {
u32 response[MSG_FIELD_MAX];
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
ssize_t ret;
u32 mr4, mr5, mr6, mr7, mr8, err;
 
@@ -808,7 +808,7 @@ static int brcmstb_dpfe_resume(struct platform_device *pdev)
 static int brcmstb_dpfe_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct private_data *priv;
+   struct brcmstb_dpfe_priv *priv;
struct init_data init;
struct resource *res;
int ret;
@@ -867,7 +867,7 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
 
 static int brcmstb_dpfe_remove(struct platform_device *p

[PATCH 2/8] memory: brcmstb: dpfe: initialize priv->dev

2019-10-15 Thread Markus Mayer
Add missing initialization of priv->dev. It is only used in an
emergency error message that is very unlikely to ever occur, which is
how this has remained unnoticed.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 0c4c01d2bf48..2ef3e365c1b5 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -817,6 +817,8 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
+   priv->dev = dev;
+
mutex_init(>lock);
platform_set_drvdata(pdev, priv);
 
-- 
2.17.1



[PATCH 0/8] memory: brcmstb: dpfe: introduce DPFE API v2.5

2019-10-15 Thread Markus Mayer
Here are a few changes for the DPFE driver for Broadcom STB.

The changes and enhancements fall into a few categories:

- some code cleanup
- support for deferring firmware download if the rootfs isn't yet available
- introduce a "new v2 API", which is half way between the existing APIs
  v2 (now called "old v2") and v3

Florian Fainelli (2):
  memory: brcmstb: dpfe: Compute checksum at __send_command() time
  memory: brcmstb: dpfe: Fixup API version/commands for 7211

Markus Mayer (6):
  memory: brcmstb: dpfe: rename struct private_data
  memory: brcmstb: dpfe: initialize priv->dev
  memory: brcmstb: dpfe: add locking around DCPU enable/disable
  memory: brcmstb: dpfe: move init_data into
brcmstb_dpfe_download_firmware()
  memory: brcmstb: dpfe: pass *priv as argument to
brcmstb_dpfe_download_firmware()
  memory: brcmstb: dpfe: support for deferred firmware download

 drivers/memory/brcmstb_dpfe.c | 164 +-
 1 file changed, 101 insertions(+), 63 deletions(-)

-- 
2.17.1



Re: [PATCH 0/2] cpufreq: brcmstb-avs-cpufreq: Couple fixes

2019-06-03 Thread Markus Mayer
On Wed, 29 May 2019 at 10:02, Florian Fainelli  wrote:
>
> On 5/27/19 3:51 AM, Rafael J. Wysocki wrote:
> > On Wednesday, May 22, 2019 8:45:45 PM CEST Florian Fainelli wrote:
> >> Hi Rafael, Viresh,
> >>
> >> These patch series contains two minor fixes for the brcmstb-avs-cpufreq
> >> driver.
> >>
> >> Florian Fainelli (2):
> >>   cpufreq: brcmstb-avs-cpufreq: Fix initial command check
> >>   cpufreq: brcmstb-avs-cpufreq: Fix types for voltage/frequency

To both of these

Acked-by: Markus Mayer 

My apologies for the delay.

> >>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 12 ++--
> >>  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > These look straightforward enough to me, but it would be good to get an ACK 
> > from the
> > driver maintainer for them.
>
> Adding Markus' other email address.
> --
> Florian


[PATCH 4/6] memory: brcmstb: dpfe: prepare support for multiple API versions

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

Extend the driver, so it can handle different API versions for
interacting with the DCPU. This is in preparation for the upcoming API
v3.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 87 ---
 1 file changed, 59 insertions(+), 28 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index f8d05a8266c3..9ad5ea08c134 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -35,10 +35,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define DRVNAME"brcmstb-dpfe"
-#define FIRMWARE_NAME  "dpfe.bin"
 
 /* DCPU register offsets */
 #define REG_DCPU_RESET 0x0
@@ -164,12 +164,20 @@ struct init_data {
bool is_big_endian;
 };
 
+/* API version and corresponding commands */
+struct dpfe_api {
+   int version;
+   const char *fw_name;
+   u32 command[DPFE_CMD_MAX][MSG_FIELD_MAX];
+};
+
 /* Things we need for as long as we are active. */
 struct private_data {
void __iomem *regs;
void __iomem *dmem;
void __iomem *imem;
struct device *dev;
+   const struct dpfe_api *dpfe_api;
struct mutex lock;
 };
 
@@ -178,29 +186,33 @@ static const char *error_text[] = {
"Incorrect checksum", "Malformed command", "Timed out",
 };
 
-/* List of supported firmware commands */
-static const u32 dpfe_commands[DPFE_CMD_MAX][MSG_FIELD_MAX] = {
-   [DPFE_CMD_GET_INFO] = {
-   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
-   [MSG_COMMAND] = 1,
-   [MSG_ARG_COUNT] = 1,
-   [MSG_ARG0] = 1,
-   [MSG_CHKSUM] = 4,
-   },
-   [DPFE_CMD_GET_REFRESH] = {
-   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
-   [MSG_COMMAND] = 2,
-   [MSG_ARG_COUNT] = 1,
-   [MSG_ARG0] = 1,
-   [MSG_CHKSUM] = 5,
-   },
-   [DPFE_CMD_GET_VENDOR] = {
-   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
-   [MSG_COMMAND] = 2,
-   [MSG_ARG_COUNT] = 1,
-   [MSG_ARG0] = 2,
-   [MSG_CHKSUM] = 6,
-   },
+/* API v2 firmware commands */
+static const struct dpfe_api dpfe_api_v2 = {
+   .version = 2,
+   .fw_name = "dpfe.bin",
+   .command = {
+   [DPFE_CMD_GET_INFO] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 1,
+   [MSG_ARG_COUNT] = 1,
+   [MSG_ARG0] = 1,
+   [MSG_CHKSUM] = 4,
+   },
+   [DPFE_CMD_GET_REFRESH] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 2,
+   [MSG_ARG_COUNT] = 1,
+   [MSG_ARG0] = 1,
+   [MSG_CHKSUM] = 5,
+   },
+   [DPFE_CMD_GET_VENDOR] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 2,
+   [MSG_ARG_COUNT] = 1,
+   [MSG_ARG0] = 2,
+   [MSG_CHKSUM] = 6,
+   },
+   }
 };
 
 static bool is_dcpu_enabled(void __iomem *regs)
@@ -293,7 +305,7 @@ static void __iomem *get_msg_ptr(struct private_data *priv, 
u32 response,
 static int __send_command(struct private_data *priv, unsigned int cmd,
  u32 result[])
 {
-   const u32 *msg = dpfe_commands[cmd];
+   const u32 *msg = priv->dpfe_api->command[cmd];
void __iomem *regs = priv->regs;
unsigned int i, chksum;
int ret = 0;
@@ -492,7 +504,15 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
return 0;
}
 
-   ret = request_firmware(, FIRMWARE_NAME, dev);
+   /*
+* If the firmware filename is NULL it means the boot firmware has to
+* download the DCPU firmware for us. If that didn't work, we have to
+* bail, since downloading it ourselves wouldn't work either.
+*/
+   if (!priv->dpfe_api->fw_name)
+   return -ENODEV;
+
+   ret = request_firmware(, priv->dpfe_api->fw_name, dev);
/* request_firmware() prints its own error messages. */
if (ret)
return ret;
@@ -714,6 +734,16 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
return -ENOENT;
}
 
+   priv->dpfe_api = of_device_get_match_data(dev);
+   if (unlikely(!priv->dpfe_api)) {
+   /*
+* It should be impossible to end up here, but to be safe we
+* check anyway.
+*/
+   dev_err(dev, "Couldn't determine API\n");
+   return -ENOENT;
+   }
+
ret = brcmstb_dpfe_download_firm

[PATCH 5/6] memory: brcmstb: dpfe: prepare for API-dependent sysfs attributes

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

Prepare the driver so that sysfs attributes can differ based on the API
version.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 47 +--
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 9ad5ea08c134..43a53246abb3 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -168,6 +168,7 @@ struct init_data {
 struct dpfe_api {
int version;
const char *fw_name;
+   const struct attribute_group **sysfs_attrs;
u32 command[DPFE_CMD_MAX][MSG_FIELD_MAX];
 };
 
@@ -186,10 +187,39 @@ static const char *error_text[] = {
"Incorrect checksum", "Malformed command", "Timed out",
 };
 
+/*
+ * Forward declaration of our sysfs attribute functions, so we can declare the
+ * attribute data structures early.
+ */
+static ssize_t show_info(struct device *, struct device_attribute *, char *);
+static ssize_t show_refresh(struct device *, struct device_attribute *, char 
*);
+static ssize_t store_refresh(struct device *, struct device_attribute *,
+ const char *, size_t);
+static ssize_t show_vendor(struct device *, struct device_attribute *, char *);
+
+/*
+ * Declare our attributes early, so they can be referenced in the API data
+ * structure. We need to do this, because the attributes depend on the API
+ * version.
+ */
+static DEVICE_ATTR(dpfe_info, 0444, show_info, NULL);
+static DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh);
+static DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL);
+
+/* API v2 sysfs attributes */
+static struct attribute *dpfe_v2_attrs[] = {
+   _attr_dpfe_info.attr,
+   _attr_dpfe_refresh.attr,
+   _attr_dpfe_vendor.attr,
+   NULL
+};
+ATTRIBUTE_GROUPS(dpfe_v2);
+
 /* API v2 firmware commands */
 static const struct dpfe_api dpfe_api_v2 = {
.version = 2,
.fw_name = "dpfe.bin",
+   .sysfs_attrs = dpfe_v2_groups,
.command = {
[DPFE_CMD_GET_INFO] = {
[MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
@@ -687,17 +717,6 @@ static int brcmstb_dpfe_resume(struct platform_device 
*pdev)
return brcmstb_dpfe_download_firmware(pdev, );
 }
 
-static DEVICE_ATTR(dpfe_info, 0444, show_info, NULL);
-static DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh);
-static DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL);
-static struct attribute *dpfe_attrs[] = {
-   _attr_dpfe_info.attr,
-   _attr_dpfe_refresh.attr,
-   _attr_dpfe_vendor.attr,
-   NULL
-};
-ATTRIBUTE_GROUPS(dpfe);
-
 static int brcmstb_dpfe_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -750,7 +769,7 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
return ret;
}
 
-   ret = sysfs_create_groups(>dev.kobj, dpfe_groups);
+   ret = sysfs_create_groups(>dev.kobj, priv->dpfe_api->sysfs_attrs);
if (!ret)
dev_info(dev, "registered with API v%d.\n",
 priv->dpfe_api->version);
@@ -760,7 +779,9 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
 
 static int brcmstb_dpfe_remove(struct platform_device *pdev)
 {
-   sysfs_remove_groups(>dev.kobj, dpfe_groups);
+   struct private_data *priv = dev_get_drvdata(>dev);
+
+   sysfs_remove_groups(>dev.kobj, priv->dpfe_api->sysfs_attrs);
 
return 0;
 }
-- 
2.17.1



[PATCH 1/6] memory: brcmstb: dpfe: remove unused code and fix formatting

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

Remove an unused struct and fix source code formatting in a few areas.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index fae3ac3d65c6..f143e40e528b 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -131,14 +131,6 @@ enum dpfe_commands {
DPFE_CMD_MAX /* Last entry */
 };
 
-struct dpfe_msg {
-   u32 header;
-   u32 command;
-   u32 arg_count;
-   u32 arg0;
-   u32 chksum; /* This is the sum of all other entries. */
-};
-
 /*
  * Format of the binary firmware file:
  *
@@ -585,7 +577,7 @@ static ssize_t show_refresh(struct device *dev,
return ret;
 
mr4 = (readl_relaxed(info + DRAM_INFO_MR4) >> DRAM_INFO_MR4_SHIFT) &
- DRAM_INFO_MR4_MASK;
+  DRAM_INFO_MR4_MASK;
 
refresh = (mr4 >> DRAM_MR4_REFRESH) & DRAM_MR4_REFRESH_MASK;
sr_abort = (mr4 >> DRAM_MR4_SR_ABORT) & DRAM_MR4_SR_ABORT_MASK;
@@ -612,7 +604,6 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
return -EINVAL;
 
priv = dev_get_drvdata(dev);
-
ret = __send_command(priv, DPFE_CMD_GET_REFRESH, response);
if (ret)
return ret;
@@ -627,7 +618,7 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
 }
 
 static ssize_t show_vendor(struct device *dev, struct device_attribute 
*devattr,
-char *buf)
+  char *buf)
 {
u32 response[MSG_FIELD_MAX];
struct private_data *priv;
-- 
2.17.1



[PATCH 0/6] memory: brcmstb: dpfe: introduce DPFE API v3

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

This series introduces a new API for communicating with the DCPU. 
It will be used as the default going forward.

Before adding the new API, there is also some code cleanup and
hardening.

This series is based on drivers/next of
https://github.com/Broadcom/stblinux.git, since it builds on top of
recently upstreamed changes that are present in this branch.

Markus Mayer (6):
  memory: brcmstb: dpfe: remove unused code and fix formatting
  memory: brcmstb: dpfe: report firmware loading error
  memory: brcmstb: dpfe: wait for DCPU to be ready
  memory: brcmstb: dpfe: prepare support for multiple API versions
  memory: brcmstb: dpfe: prepare for API-dependent sysfs attributes
  memory: brcmstb: dpfe: introduce DPFE API v3

 drivers/memory/brcmstb_dpfe.c | 273 ++
 1 file changed, 213 insertions(+), 60 deletions(-)

-- 
2.17.1



[PATCH 6/6] memory: brcmstb: dpfe: introduce DPFE API v3

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

Introduce code to handle DPFE API v3. We also change the driver to
default to v3 by default and use API v2 only for select chips.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 114 +++---
 1 file changed, 105 insertions(+), 9 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 43a53246abb3..bc6bf263c859 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -76,7 +76,7 @@
 #define DRAM_MR4_TH_OFFS_MASK  0x3
 #define DRAM_MR4_TUF_MASK  0x1
 
-/* DRAM Vendor Offsets & Masks */
+/* DRAM Vendor Offsets & Masks (API v2) */
 #define DRAM_VENDOR_MR50x0
 #define DRAM_VENDOR_MR60x4
 #define DRAM_VENDOR_MR70x8
@@ -85,6 +85,15 @@
 #define DRAM_VENDOR_MASK   0xff
 #define DRAM_VENDOR_SHIFT  24  /* We need to look at byte 3 */
 
+/* DRAM Information Offsets & Masks (API v3) */
+#define DRAM_DDR_INFO_MR4  0x0
+#define DRAM_DDR_INFO_MR5  0x4
+#define DRAM_DDR_INFO_MR6  0x8
+#define DRAM_DDR_INFO_MR7  0xc
+#define DRAM_DDR_INFO_MR8  0x10
+#define DRAM_DDR_INFO_ERROR0x14
+#define DRAM_DDR_INFO_MASK 0xff
+
 /* Reset register bits & masks */
 #define DCPU_RESET_SHIFT   0x0
 #define DCPU_RESET_MASK0x1
@@ -121,7 +130,7 @@ enum dpfe_msg_fields {
MSG_ARG_COUNT,
MSG_ARG0,
MSG_CHKSUM,
-   MSG_FIELD_MAX /* Last entry */
+   MSG_FIELD_MAX   = 16 /* Max number of arguments */
 };
 
 enum dpfe_commands {
@@ -196,6 +205,7 @@ static ssize_t show_refresh(struct device *, struct 
device_attribute *, char *);
 static ssize_t store_refresh(struct device *, struct device_attribute *,
  const char *, size_t);
 static ssize_t show_vendor(struct device *, struct device_attribute *, char *);
+static ssize_t show_dram(struct device *, struct device_attribute *, char *);
 
 /*
  * Declare our attributes early, so they can be referenced in the API data
@@ -205,6 +215,7 @@ static ssize_t show_vendor(struct device *, struct 
device_attribute *, char *);
 static DEVICE_ATTR(dpfe_info, 0444, show_info, NULL);
 static DEVICE_ATTR(dpfe_refresh, 0644, show_refresh, store_refresh);
 static DEVICE_ATTR(dpfe_vendor, 0444, show_vendor, NULL);
+static DEVICE_ATTR(dpfe_dram, 0444, show_dram, NULL);
 
 /* API v2 sysfs attributes */
 static struct attribute *dpfe_v2_attrs[] = {
@@ -215,6 +226,14 @@ static struct attribute *dpfe_v2_attrs[] = {
 };
 ATTRIBUTE_GROUPS(dpfe_v2);
 
+/* API v3 sysfs attributes */
+static struct attribute *dpfe_v3_attrs[] = {
+   _attr_dpfe_info.attr,
+   _attr_dpfe_dram.attr,
+   NULL
+};
+ATTRIBUTE_GROUPS(dpfe_v3);
+
 /* API v2 firmware commands */
 static const struct dpfe_api dpfe_api_v2 = {
.version = 2,
@@ -245,6 +264,34 @@ static const struct dpfe_api dpfe_api_v2 = {
}
 };
 
+/* API v3 firmware commands */
+static const struct dpfe_api dpfe_api_v3 = {
+   .version = 3,
+   .fw_name = NULL, /* We expect the firmware to have been downloaded! */
+   .sysfs_attrs = dpfe_v3_groups,
+   .command = {
+   [DPFE_CMD_GET_INFO] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 0x0101,
+   [MSG_ARG_COUNT] = 1,
+   [MSG_ARG0] = 1,
+   [MSG_CHKSUM] = 0x104,
+   },
+   [DPFE_CMD_GET_REFRESH] = {
+   [MSG_HEADER] = DPFE_MSG_TYPE_COMMAND,
+   [MSG_COMMAND] = 0x0202,
+   [MSG_ARG_COUNT] = 0,
+   /*
+* This is a bit ugly. Without arguments, the checksum
+* follows right after the argument count and not at
+* offset MSG_CHKSUM.
+*/
+   [MSG_ARG0] = 0x203,
+   },
+   /* There's no GET_VENDOR command in API v3. */
+   },
+};
+
 static bool is_dcpu_enabled(void __iomem *regs)
 {
u32 val;
@@ -286,13 +333,13 @@ static void __enable_dcpu(void __iomem *regs)
writel_relaxed(val, regs + REG_DCPU_RESET);
 }
 
-static unsigned int get_msg_chksum(const u32 msg[])
+static unsigned int get_msg_chksum(const u32 msg[], unsigned int max)
 {
unsigned int sum = 0;
unsigned int i;
 
/* Don't include the last field in the checksum. */
-   for (i = 0; i < MSG_FIELD_MAX - 1; i++)
+   for (i = 0; i < max; i++)
sum += msg[i];
 
return sum;
@@ -305,6 +352,11 @@ static void __iomem *get_msg_ptr(struct private_data 
*priv, u32 response,
unsigned int offset;
void __iomem *ptr = NULL;
 
+   /* There is no need to use this function for API v3 or later. */
+   if (unlikely(priv->dpfe_api->version >= 3)) {
+   return NULL;
+   }

[PATCH 3/6] memory: brcmstb: dpfe: wait for DCPU to be ready

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

We wait for the DCPU to be ready before sending a command.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index c67774a4fe8b..f8d05a8266c3 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -304,6 +304,18 @@ static int __send_command(struct private_data *priv, 
unsigned int cmd,
 
mutex_lock(>lock);
 
+   /* Wait for DCPU to become ready */
+   for (i = 0; i < DELAY_LOOP_MAX; i++) {
+   resp = readl_relaxed(regs + REG_TO_HOST_MBOX);
+   if (resp == 0)
+   break;
+   msleep(1);
+   }
+   if (resp != 0) {
+   mutex_unlock(>lock);
+   return -ETIMEDOUT;
+   }
+
/* Write command and arguments to message area */
for (i = 0; i < MSG_FIELD_MAX; i++)
writel_relaxed(msg[i], regs + DCPU_MSG_RAM(i));
-- 
2.17.1



[PATCH 2/6] memory: brcmstb: dpfe: report firmware loading error

2019-04-02 Thread Markus Mayer
From: Markus Mayer 

Print an error message if the DCPU firmware couldn't be downloaded.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index f143e40e528b..c67774a4fe8b 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -703,8 +703,10 @@ static int brcmstb_dpfe_probe(struct platform_device *pdev)
}
 
ret = brcmstb_dpfe_download_firmware(pdev, );
-   if (ret)
+   if (ret) {
+   dev_err(dev, "Couldn't download firmware -- %d\n", ret);
return ret;
+   }
 
ret = sysfs_create_groups(>dev.kobj, dpfe_groups);
if (!ret)
-- 
2.17.1



[PATCH 1/3] soc: brcmstb: dpfe: use msleep() over udelay()

2019-02-11 Thread Markus Mayer
From: Markus Mayer 

To be more "scheduler friendly", we use msleep() rather than udelay()
while we wait for the DCPU to respond.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 04599eccd604..8e1ccdb0e59d 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -111,7 +111,7 @@
 #define DPFE_MSG_TYPE_COMMAND  1
 #define DPFE_MSG_TYPE_RESPONSE 2
 
-#define DELAY_LOOP_MAX 20
+#define DELAY_LOOP_MAX 1000
 
 enum dpfe_msg_fields {
MSG_HEADER,
@@ -323,7 +323,7 @@ static int __send_command(struct private_data *priv, 
unsigned int cmd,
resp = readl_relaxed(regs + REG_TO_HOST_MBOX);
if (resp > 0)
break;
-   udelay(5);
+   msleep(1);
}
 
if (i == DELAY_LOOP_MAX) {
-- 
2.17.1



[PATCH 0/3] Some minor updates and fixes for the BRCMSTB DPFE driver

2019-02-11 Thread Markus Mayer
From: Markus Mayer 

This series contains three unrelated improvements or fixes for the
BRCMSTB DPFE driver:

* use msleep() over udelay() to be more scheduler friendly
* optimize generic_show()
* work around a firmware issue by reading byte 3 instead of byte 0

Markus Mayer (3):
  soc: brcmstb: dpfe: use msleep() over udelay()
  soc: brcmstb: dpfe: optimize generic_show()
  soc: brcmstb: dpfe: use byte 3 of registers MR4-MR8

 drivers/memory/brcmstb_dpfe.c | 46 ---
 1 file changed, 26 insertions(+), 20 deletions(-)

-- 
2.17.1



[PATCH 3/3] soc: brcmstb: dpfe: use byte 3 of registers MR4-MR8

2019-02-11 Thread Markus Mayer
From: Markus Mayer 

For dual-rank LPDDR4, result data for any command is placed in byte 0
and byte 3 of the corresponding MR register by the firmware.
Single-rank RAM was supposed to work the same way. However, due to a
firmware bug, result values are only placed in byte 3 of the
corresponding MR register.

Since byte 3 works for single-rank and dual-rank setups, we change the
Linux driver to always use byte 3, thus returning the correct value in
either case.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 1095c1d95df4..fae3ac3d65c6 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -61,6 +61,7 @@
 #define DRAM_INFO_MR4  0x4
 #define DRAM_INFO_ERROR0x8
 #define DRAM_INFO_MR4_MASK 0xff
+#define DRAM_INFO_MR4_SHIFT24  /* We need to look at byte 3 */
 
 /* DRAM MR4 Offsets & Masks */
 #define DRAM_MR4_REFRESH   0x0 /* Refresh rate */
@@ -82,6 +83,7 @@
 #define DRAM_VENDOR_MR80xc
 #define DRAM_VENDOR_ERROR  0x10
 #define DRAM_VENDOR_MASK   0xff
+#define DRAM_VENDOR_SHIFT  24  /* We need to look at byte 3 */
 
 /* Reset register bits & masks */
 #define DCPU_RESET_SHIFT   0x0
@@ -582,7 +584,8 @@ static ssize_t show_refresh(struct device *dev,
if (!info)
return ret;
 
-   mr4 = readl_relaxed(info + DRAM_INFO_MR4) & DRAM_INFO_MR4_MASK;
+   mr4 = (readl_relaxed(info + DRAM_INFO_MR4) >> DRAM_INFO_MR4_SHIFT) &
+ DRAM_INFO_MR4_MASK;
 
refresh = (mr4 >> DRAM_MR4_REFRESH) & DRAM_MR4_REFRESH_MASK;
sr_abort = (mr4 >> DRAM_MR4_SR_ABORT) & DRAM_MR4_SR_ABORT_MASK;
@@ -630,6 +633,7 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
struct private_data *priv;
void __iomem *info;
ssize_t ret;
+   u32 mr5, mr6, mr7, mr8, err;
 
priv = dev_get_drvdata(dev);
ret = generic_show(DPFE_CMD_GET_VENDOR, response, priv, buf);
@@ -640,13 +644,17 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
if (!info)
return ret;
 
-   return sprintf(buf, "%#x %#x %#x %#x %#x\n",
-  readl_relaxed(info + DRAM_VENDOR_MR5) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_MR6) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_MR7) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_MR8) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_ERROR) &
-DRAM_VENDOR_MASK);
+   mr5 = (readl_relaxed(info + DRAM_VENDOR_MR5) >> DRAM_VENDOR_SHIFT) &
+   DRAM_VENDOR_MASK;
+   mr6 = (readl_relaxed(info + DRAM_VENDOR_MR6) >> DRAM_VENDOR_SHIFT) &
+   DRAM_VENDOR_MASK;
+   mr7 = (readl_relaxed(info + DRAM_VENDOR_MR7) >> DRAM_VENDOR_SHIFT) &
+   DRAM_VENDOR_MASK;
+   mr8 = (readl_relaxed(info + DRAM_VENDOR_MR8) >> DRAM_VENDOR_SHIFT) &
+   DRAM_VENDOR_MASK;
+   err = readl_relaxed(info + DRAM_VENDOR_ERROR) & DRAM_VENDOR_MASK;
+
+   return sprintf(buf, "%#x %#x %#x %#x %#x\n", mr5, mr6, mr7, mr8, err);
 }
 
 static int brcmstb_dpfe_resume(struct platform_device *pdev)
-- 
2.17.1



[PATCH 2/3] soc: brcmstb: dpfe: optimize generic_show()

2019-02-11 Thread Markus Mayer
From: Markus Mayer 

We can pass a (struct priv_data *) to generic_show() rather than a
(struct device *). For two of the three callers of this function, the
change means one less call to dev_get_drvdata(). For the third caller,
it makes no difference.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 8e1ccdb0e59d..1095c1d95df4 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -527,12 +527,10 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
 }
 
 static ssize_t generic_show(unsigned int command, u32 response[],
-   struct device *dev, char *buf)
+   struct private_data *priv, char *buf)
 {
-   struct private_data *priv;
int ret;
 
-   priv = dev_get_drvdata(dev);
if (!priv)
return sprintf(buf, "ERROR: driver private data not set\n");
 
@@ -547,10 +545,12 @@ static ssize_t show_info(struct device *dev, struct 
device_attribute *devattr,
 char *buf)
 {
u32 response[MSG_FIELD_MAX];
+   struct private_data *priv;
unsigned int info;
ssize_t ret;
 
-   ret = generic_show(DPFE_CMD_GET_INFO, response, dev, buf);
+   priv = dev_get_drvdata(dev);
+   ret = generic_show(DPFE_CMD_GET_INFO, response, priv, buf);
if (ret)
return ret;
 
@@ -573,12 +573,11 @@ static ssize_t show_refresh(struct device *dev,
u32 mr4;
ssize_t ret;
 
-   ret = generic_show(DPFE_CMD_GET_REFRESH, response, dev, buf);
+   priv = dev_get_drvdata(dev);
+   ret = generic_show(DPFE_CMD_GET_REFRESH, response, priv, buf);
if (ret)
return ret;
 
-   priv = dev_get_drvdata(dev);
-
info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
if (!info)
return ret;
@@ -632,12 +631,11 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
void __iomem *info;
ssize_t ret;
 
-   ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
+   priv = dev_get_drvdata(dev);
+   ret = generic_show(DPFE_CMD_GET_VENDOR, response, priv, buf);
if (ret)
return ret;
 
-   priv = dev_get_drvdata(dev);
-
info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
if (!info)
return ret;
-- 
2.17.1



[PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

2018-05-15 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

Most CPUfreq drivers (at least on ARM) seem to be sorting the available
frequencies from lowest to highest. To match this behaviour, we reverse
the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
highest.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b07559b9ed99..7dac3205d3eb 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
 {
struct cpufreq_frequency_table *table;
unsigned int pstate;
-   int i, ret;
+   int p, i, ret;
 
/* Remember P-state for later */
ret = brcm_avs_get_pstate(priv, );
@@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
if (!table)
return ERR_PTR(-ENOMEM);
 
-   for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
-   ret = brcm_avs_set_pstate(priv, i);
+   for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
+   ret = brcm_avs_set_pstate(priv, p);
if (ret)
return ERR_PTR(ret);
table[i].frequency = brcm_avs_get_frequency(priv->base);
-   table[i].driver_data = i;
+   /* Store the corresponding P-state with each frequency */
+   table[i].driver_data = p;
}
table[i].frequency = CPUFREQ_TABLE_END;
 
-- 
2.7.4



[PATCH] cpufreq: brcmstb-avs-cpufreq: sort frequencies in ascending order

2018-05-15 Thread Markus Mayer
From: Markus Mayer 

Most CPUfreq drivers (at least on ARM) seem to be sorting the available
frequencies from lowest to highest. To match this behaviour, we reverse
the sorting order in brcmstb-avs-cpufreq, so it is now also lowest to
highest.

Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b07559b9ed99..7dac3205d3eb 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -403,7 +403,7 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
 {
struct cpufreq_frequency_table *table;
unsigned int pstate;
-   int i, ret;
+   int p, i, ret;
 
/* Remember P-state for later */
ret = brcm_avs_get_pstate(priv, );
@@ -415,12 +415,13 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
if (!table)
return ERR_PTR(-ENOMEM);
 
-   for (i = AVS_PSTATE_P0; i <= AVS_PSTATE_MAX; i++) {
-   ret = brcm_avs_set_pstate(priv, i);
+   for (p = AVS_PSTATE_MAX, i = 0; p >= 0; p--, i++) {
+   ret = brcm_avs_set_pstate(priv, p);
if (ret)
return ERR_PTR(ret);
table[i].frequency = brcm_avs_get_frequency(priv->base);
-   table[i].driver_data = i;
+   /* Store the corresponding P-state with each frequency */
+   table[i].driver_data = p;
}
table[i].frequency = CPUFREQ_TABLE_END;
 
-- 
2.7.4



Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

2018-04-19 Thread Markus Mayer
On 18 April 2018 at 09:37, Florian Fainelli <f.faine...@gmail.com> wrote:
> On 04/18/2018 08:56 AM, Markus Mayer wrote:
>> From: Jim Quinlan <jim2101...@gmail.com>
>>
>> If the SCMI cpufreq driver is supported, we bail, so that the new
>> approach can be used.
>>
>> Signed-off-by: Jim Quinlan <jim2101...@gmail.com>
>> Signed-off-by: Markus Mayer <mma...@broadcom.com>
>> ---
>>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
>> b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..b4861a730162 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -164,6 +164,8 @@
>>  #define BRCM_AVS_CPU_INTR"brcm,avs-cpu-l2-intr"
>>  #define BRCM_AVS_HOST_INTR   "sw_intr"
>>
>> +#define ARM_SCMI_COMPAT  "arm,scmi"
>> +
>>  struct pmap {
>>   unsigned int mode;
>>   unsigned int p1;
>> @@ -511,6 +513,20 @@ static int brcm_avs_prepare_init(struct platform_device 
>> *pdev)
>>   struct device *dev;
>>   int host_irq, ret;
>>
>> + /*
>> +  * If the SCMI cpufreq driver is supported, we bail, so that the more
>> +  * modern approach can be used.
>> +  */
>> + if (IS_ENABLED(CONFIG_ARM_SCMI_PROTOCOL)) {
>> + struct device_node *np;
>> +
>> + np = of_find_compatible_node(NULL, NULL, ARM_SCMI_COMPAT);
>> + if (np) {
>> + of_node_put(np);
>> + return -ENXIO;
>> + }
>
> We would probably want to make sure that the node is also enabled (that
> is, does not have a status = "disabled" property) otherwise the check
> can be defeated. Something like:
>
> if (np && of_device_is_available(np))

Would we want something like this instead?

 if (np) {
  bool bail_early =
(of_device_is_available(np) > 0);

  of_node_put(np);
  if (bail_early)
  return -ENXIO;
 }

To ensure of_node_put() is called?

> should be good for that.
>
> Thanks!
> --
> Florian


Re: [PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

2018-04-19 Thread Markus Mayer
On 18 April 2018 at 09:37, Florian Fainelli  wrote:
> On 04/18/2018 08:56 AM, Markus Mayer wrote:
>> From: Jim Quinlan 
>>
>> If the SCMI cpufreq driver is supported, we bail, so that the new
>> approach can be used.
>>
>> Signed-off-by: Jim Quinlan 
>> Signed-off-by: Markus Mayer 
>> ---
>>  drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
>> b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> index b07559b9ed99..b4861a730162 100644
>> --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
>> @@ -164,6 +164,8 @@
>>  #define BRCM_AVS_CPU_INTR"brcm,avs-cpu-l2-intr"
>>  #define BRCM_AVS_HOST_INTR   "sw_intr"
>>
>> +#define ARM_SCMI_COMPAT  "arm,scmi"
>> +
>>  struct pmap {
>>   unsigned int mode;
>>   unsigned int p1;
>> @@ -511,6 +513,20 @@ static int brcm_avs_prepare_init(struct platform_device 
>> *pdev)
>>   struct device *dev;
>>   int host_irq, ret;
>>
>> + /*
>> +  * If the SCMI cpufreq driver is supported, we bail, so that the more
>> +  * modern approach can be used.
>> +  */
>> + if (IS_ENABLED(CONFIG_ARM_SCMI_PROTOCOL)) {
>> + struct device_node *np;
>> +
>> + np = of_find_compatible_node(NULL, NULL, ARM_SCMI_COMPAT);
>> + if (np) {
>> + of_node_put(np);
>> + return -ENXIO;
>> + }
>
> We would probably want to make sure that the node is also enabled (that
> is, does not have a status = "disabled" property) otherwise the check
> can be defeated. Something like:
>
> if (np && of_device_is_available(np))

Would we want something like this instead?

 if (np) {
  bool bail_early =
(of_device_is_available(np) > 0);

  of_node_put(np);
  if (bail_early)
  return -ENXIO;
 }

To ensure of_node_put() is called?

> should be good for that.
>
> Thanks!
> --
> Florian


[PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

2018-04-18 Thread Markus Mayer
From: Jim Quinlan <jim2101...@gmail.com>

If the SCMI cpufreq driver is supported, we bail, so that the new
approach can be used.

Signed-off-by: Jim Quinlan <jim2101...@gmail.com>
Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b07559b9ed99..b4861a730162 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -164,6 +164,8 @@
 #define BRCM_AVS_CPU_INTR  "brcm,avs-cpu-l2-intr"
 #define BRCM_AVS_HOST_INTR "sw_intr"
 
+#define ARM_SCMI_COMPAT"arm,scmi"
+
 struct pmap {
unsigned int mode;
unsigned int p1;
@@ -511,6 +513,20 @@ static int brcm_avs_prepare_init(struct platform_device 
*pdev)
struct device *dev;
int host_irq, ret;
 
+   /*
+* If the SCMI cpufreq driver is supported, we bail, so that the more
+* modern approach can be used.
+*/
+   if (IS_ENABLED(CONFIG_ARM_SCMI_PROTOCOL)) {
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, ARM_SCMI_COMPAT);
+   if (np) {
+   of_node_put(np);
+   return -ENXIO;
+   }
+   }
+
dev = >dev;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
-- 
2.7.4



[PATCH 2/2] cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

2018-04-18 Thread Markus Mayer
From: Jim Quinlan 

If the SCMI cpufreq driver is supported, we bail, so that the new
approach can be used.

Signed-off-by: Jim Quinlan 
Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index b07559b9ed99..b4861a730162 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -164,6 +164,8 @@
 #define BRCM_AVS_CPU_INTR  "brcm,avs-cpu-l2-intr"
 #define BRCM_AVS_HOST_INTR "sw_intr"
 
+#define ARM_SCMI_COMPAT"arm,scmi"
+
 struct pmap {
unsigned int mode;
unsigned int p1;
@@ -511,6 +513,20 @@ static int brcm_avs_prepare_init(struct platform_device 
*pdev)
struct device *dev;
int host_irq, ret;
 
+   /*
+* If the SCMI cpufreq driver is supported, we bail, so that the more
+* modern approach can be used.
+*/
+   if (IS_ENABLED(CONFIG_ARM_SCMI_PROTOCOL)) {
+   struct device_node *np;
+
+   np = of_find_compatible_node(NULL, NULL, ARM_SCMI_COMPAT);
+   if (np) {
+   of_node_put(np);
+   return -ENXIO;
+   }
+   }
+
dev = >dev;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
-- 
2.7.4



[PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support

2018-04-18 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This debug code was helpful while developing the driver, but it isn't
being used for anything anymore.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/cpufreq/Kconfig.arm   |  10 --
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 323 +-
 2 files changed, 1 insertion(+), 332 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7f56fe5183f2..de55c7d57438 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -71,16 +71,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ
 
  Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
 
-config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-   bool "Broadcom STB AVS CPUfreq driver sysfs debug capability"
-   depends on ARM_BRCMSTB_AVS_CPUFREQ
-   help
- Enabling this option turns on debug support via sysfs under
- /sys/kernel/debug/brcmstb-avs-cpufreq. It is possible to read all and
- write some AVS mailbox registers through sysfs entries.
-
- If in doubt, say N.
-
 config ARM_EXYNOS5440_CPUFREQ
tristate "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 6cdac1aaf23c..b07559b9ed99 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -49,13 +49,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-#include 
-#include 
-#include 
-#include 
-#endif
-
 /* Max number of arguments AVS calls take */
 #define AVS_MAX_CMD_ARGS   4
 /*
@@ -182,88 +175,11 @@ struct private_data {
void __iomem *base;
void __iomem *avs_intr_base;
struct device *dev;
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-   struct dentry *debugfs;
-#endif
struct completion done;
struct semaphore sem;
struct pmap pmap;
 };
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-
-enum debugfs_format {
-   DEBUGFS_NORMAL,
-   DEBUGFS_FLOAT,
-   DEBUGFS_REV,
-};
-
-struct debugfs_data {
-   struct debugfs_entry *entry;
-   struct private_data *priv;
-};
-
-struct debugfs_entry {
-   char *name;
-   u32 offset;
-   fmode_t mode;
-   enum debugfs_format format;
-};
-
-#define DEBUGFS_ENTRY(name, mode, format)  { \
-   #name, AVS_MBOX_##name, mode, format \
-}
-
-/*
- * These are used for debugfs only. Otherwise we use AVS_MBOX_PARAM() directly.
- */
-#define AVS_MBOX_PARAM1AVS_MBOX_PARAM(0)
-#define AVS_MBOX_PARAM2AVS_MBOX_PARAM(1)
-#define AVS_MBOX_PARAM3AVS_MBOX_PARAM(2)
-#define AVS_MBOX_PARAM4AVS_MBOX_PARAM(3)
-
-/*
- * This table stores the name, access permissions and offset for each hardware
- * register and is used to generate debugfs entries.
- */
-static struct debugfs_entry debugfs_entries[] = {
-   DEBUGFS_ENTRY(COMMAND, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(STATUS, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(VOLTAGE0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(TEMP0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PV0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(MV0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PARAM1, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM2, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM3, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM4, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(REVISION, 0, DEBUGFS_REV),
-   DEBUGFS_ENTRY(PSTATE, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(HEARTBEAT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(MAGIC, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(SIGMA_HVT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(SIGMA_SVT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(VOLTAGE1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(TEMP1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PV1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(MV1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(FREQUENCY, 0, DEBUGFS_NORMAL),
-};
-
-static int brcm_avs_target_index(struct cpufreq_policy *, unsigned int);
-
-static char *__strtolower(char *s)
-{
-   char *p;
-
-   for (p = s; *p; p++)
-   *p = tolower(*p);
-
-   return s;
-}
-
-#endif /* CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG */
-
 static void __iomem *__map_region(const char *name)
 {
struct device_node *np;
@@ -516,238 +432,6 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
return table;
 }
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-
-#define MANT(x)(unsigned int)(abs((x)) / 1000)
-#define FRAC(x)(unsigned int)(abs((x)) - abs((x)) / 1000 * 1000)
-
-static int brcm_avs_debug_show(struct seq_file *s, void *data)
-{
-   struct debugfs_data *dbgfs = s->private;
-   void __iomem *base;
-   u32 val, offset;
-
-   if (!dbgfs) {
-   seq_puts(s, "No devi

[PATCH 0/2] brcmstb-avs-cpufreq changes

2018-04-18 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

These changes are based on v4.17-rc1. The two patches are unrelated.

Patch 1/2 removes unused code that was only useful during driver
development and that has been disabled by default for a long time.

Patch 2/2 allows the driver to detect if the system supports SCMI cpufreq

Jim Quinlan (1):
  cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

Markus Mayer (1):
  cpufreq: brcmstb-avs-cpufreq: remove development debug support

 drivers/cpufreq/Kconfig.arm   |  10 -
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 339 ++
 2 files changed, 17 insertions(+), 332 deletions(-)

-- 
2.7.4



[PATCH 1/2] cpufreq: brcmstb-avs-cpufreq: remove development debug support

2018-04-18 Thread Markus Mayer
From: Markus Mayer 

This debug code was helpful while developing the driver, but it isn't
being used for anything anymore.

Signed-off-by: Markus Mayer 
---
 drivers/cpufreq/Kconfig.arm   |  10 --
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 323 +-
 2 files changed, 1 insertion(+), 332 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 7f56fe5183f2..de55c7d57438 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -71,16 +71,6 @@ config ARM_BRCMSTB_AVS_CPUFREQ
 
  Say Y, if you have a Broadcom SoC with AVS support for DFS or DVFS.
 
-config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-   bool "Broadcom STB AVS CPUfreq driver sysfs debug capability"
-   depends on ARM_BRCMSTB_AVS_CPUFREQ
-   help
- Enabling this option turns on debug support via sysfs under
- /sys/kernel/debug/brcmstb-avs-cpufreq. It is possible to read all and
- write some AVS mailbox registers through sysfs entries.
-
- If in doubt, say N.
-
 config ARM_EXYNOS5440_CPUFREQ
tristate "SAMSUNG EXYNOS5440"
depends on SOC_EXYNOS5440
diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c 
b/drivers/cpufreq/brcmstb-avs-cpufreq.c
index 6cdac1aaf23c..b07559b9ed99 100644
--- a/drivers/cpufreq/brcmstb-avs-cpufreq.c
+++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c
@@ -49,13 +49,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-#include 
-#include 
-#include 
-#include 
-#endif
-
 /* Max number of arguments AVS calls take */
 #define AVS_MAX_CMD_ARGS   4
 /*
@@ -182,88 +175,11 @@ struct private_data {
void __iomem *base;
void __iomem *avs_intr_base;
struct device *dev;
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-   struct dentry *debugfs;
-#endif
struct completion done;
struct semaphore sem;
struct pmap pmap;
 };
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-
-enum debugfs_format {
-   DEBUGFS_NORMAL,
-   DEBUGFS_FLOAT,
-   DEBUGFS_REV,
-};
-
-struct debugfs_data {
-   struct debugfs_entry *entry;
-   struct private_data *priv;
-};
-
-struct debugfs_entry {
-   char *name;
-   u32 offset;
-   fmode_t mode;
-   enum debugfs_format format;
-};
-
-#define DEBUGFS_ENTRY(name, mode, format)  { \
-   #name, AVS_MBOX_##name, mode, format \
-}
-
-/*
- * These are used for debugfs only. Otherwise we use AVS_MBOX_PARAM() directly.
- */
-#define AVS_MBOX_PARAM1AVS_MBOX_PARAM(0)
-#define AVS_MBOX_PARAM2AVS_MBOX_PARAM(1)
-#define AVS_MBOX_PARAM3AVS_MBOX_PARAM(2)
-#define AVS_MBOX_PARAM4AVS_MBOX_PARAM(3)
-
-/*
- * This table stores the name, access permissions and offset for each hardware
- * register and is used to generate debugfs entries.
- */
-static struct debugfs_entry debugfs_entries[] = {
-   DEBUGFS_ENTRY(COMMAND, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(STATUS, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(VOLTAGE0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(TEMP0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PV0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(MV0, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PARAM1, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM2, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM3, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(PARAM4, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(REVISION, 0, DEBUGFS_REV),
-   DEBUGFS_ENTRY(PSTATE, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(HEARTBEAT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(MAGIC, S_IWUSR, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(SIGMA_HVT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(SIGMA_SVT, 0, DEBUGFS_NORMAL),
-   DEBUGFS_ENTRY(VOLTAGE1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(TEMP1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(PV1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(MV1, 0, DEBUGFS_FLOAT),
-   DEBUGFS_ENTRY(FREQUENCY, 0, DEBUGFS_NORMAL),
-};
-
-static int brcm_avs_target_index(struct cpufreq_policy *, unsigned int);
-
-static char *__strtolower(char *s)
-{
-   char *p;
-
-   for (p = s; *p; p++)
-   *p = tolower(*p);
-
-   return s;
-}
-
-#endif /* CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG */
-
 static void __iomem *__map_region(const char *name)
 {
struct device_node *np;
@@ -516,238 +432,6 @@ brcm_avs_get_freq_table(struct device *dev, struct 
private_data *priv)
return table;
 }
 
-#ifdef CONFIG_ARM_BRCMSTB_AVS_CPUFREQ_DEBUG
-
-#define MANT(x)(unsigned int)(abs((x)) / 1000)
-#define FRAC(x)(unsigned int)(abs((x)) - abs((x)) / 1000 * 1000)
-
-static int brcm_avs_debug_show(struct seq_file *s, void *data)
-{
-   struct debugfs_data *dbgfs = s->private;
-   void __iomem *base;
-   u32 val, offset;
-
-   if (!dbgfs) {
-   seq_puts(s, "No device pointer\n");
-   return 0;
-   }
-

[PATCH 0/2] brcmstb-avs-cpufreq changes

2018-04-18 Thread Markus Mayer
From: Markus Mayer 

These changes are based on v4.17-rc1. The two patches are unrelated.

Patch 1/2 removes unused code that was only useful during driver
development and that has been disabled by default for a long time.

Patch 2/2 allows the driver to detect if the system supports SCMI cpufreq

Jim Quinlan (1):
  cpufreq: brcmstb-avs-cpufreq: prefer SCMI cpufreq if supported

Markus Mayer (1):
  cpufreq: brcmstb-avs-cpufreq: remove development debug support

 drivers/cpufreq/Kconfig.arm   |  10 -
 drivers/cpufreq/brcmstb-avs-cpufreq.c | 339 ++
 2 files changed, 17 insertions(+), 332 deletions(-)

-- 
2.7.4



Re: [PATCH] memory: brcmstb: dpfe: Remove need for dpfe_dev

2018-03-27 Thread Markus Mayer
On 27 March 2018 at 16:40, Florian Fainelli <f.faine...@gmail.com> wrote:
> We can hook sysfs objects to the parent platform device that we are
> created from, no need to have a synthetic dpfe_dev just for that. This
> incidentally removes the need for having an index, since we are
> guaranteed to have an unique path in the sysfs hiearchy.
>
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>

Looks good. Thanks.

Acked-by: Markus Mayer <mma...@broadcom.com>

> ---
>  drivers/memory/brcmstb_dpfe.c | 42 ++
>  1 file changed, 10 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 0a7bdbed3a6f..5f8d5aff6040 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -168,7 +168,6 @@ struct private_data {
> void __iomem *dmem;
> void __iomem *imem;
> struct device *dev;
> -   unsigned int index;
> struct mutex lock;
>  };
>
> @@ -628,10 +627,8 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
>  {
> struct device *dev = >dev;
> struct private_data *priv;
> -   struct device *dpfe_dev;
> struct init_data init;
> struct resource *res;
> -   u32 index;
> int ret;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -641,11 +638,6 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
> mutex_init(>lock);
> platform_set_drvdata(pdev, priv);
>
> -   /* Cell index is optional; default to 0 if not present. */
> -   ret = of_property_read_u32(dev->of_node, "cell-index", );
> -   if (ret)
> -   index = 0;
> -
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dpfe-cpu");
> priv->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(priv->regs)) {
> @@ -669,35 +661,20 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
>
> ret = brcmstb_dpfe_download_firmware(pdev, );
> if (ret)
> -   goto err;
> -
> -   dpfe_dev = devm_kzalloc(dev, sizeof(*dpfe_dev), GFP_KERNEL);
> -   if (!dpfe_dev) {
> -   ret = -ENOMEM;
> -   goto err;
> -   }
> -
> -   priv->dev = dpfe_dev;
> -   priv->index = index;
> +   return ret;
>
> -   dpfe_dev->parent = dev;
> -   dpfe_dev->groups = dpfe_groups;
> -   dpfe_dev->of_node = dev->of_node;
> -   dev_set_drvdata(dpfe_dev, priv);
> -   dev_set_name(dpfe_dev, "dpfe%u", index);
> +   ret = sysfs_create_groups(>dev.kobj, dpfe_groups);
> +   if (!ret)
> +   dev_info(dev, "registered.\n");
>
> -   ret = device_register(dpfe_dev);
> -   if (ret)
> -   goto err;
> +   return ret;
> +}
>
> -   dev_info(dev, "registered.\n");
> +static int brcmstb_dpfe_remove(struct platform_device *pdev)
> +{
> +   sysfs_remove_groups(>dev.kobj, dpfe_groups);
>
> return 0;
> -
> -err:
> -   dev_err(dev, "failed to initialize -- error %d\n", ret);
> -
> -   return ret;
>  }
>
>  static const struct of_device_id brcmstb_dpfe_of_match[] = {
> @@ -712,6 +689,7 @@ static struct platform_driver brcmstb_dpfe_driver = {
> .of_match_table = brcmstb_dpfe_of_match,
> },
> .probe = brcmstb_dpfe_probe,
> +   .remove = brcmstb_dpfe_remove,
> .resume = brcmstb_dpfe_resume,
>  };
>
> --
> 2.14.1
>


Re: [PATCH] memory: brcmstb: dpfe: Remove need for dpfe_dev

2018-03-27 Thread Markus Mayer
On 27 March 2018 at 16:40, Florian Fainelli  wrote:
> We can hook sysfs objects to the parent platform device that we are
> created from, no need to have a synthetic dpfe_dev just for that. This
> incidentally removes the need for having an index, since we are
> guaranteed to have an unique path in the sysfs hiearchy.
>
> Signed-off-by: Florian Fainelli 

Looks good. Thanks.

Acked-by: Markus Mayer 

> ---
>  drivers/memory/brcmstb_dpfe.c | 42 ++
>  1 file changed, 10 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
> index 0a7bdbed3a6f..5f8d5aff6040 100644
> --- a/drivers/memory/brcmstb_dpfe.c
> +++ b/drivers/memory/brcmstb_dpfe.c
> @@ -168,7 +168,6 @@ struct private_data {
> void __iomem *dmem;
> void __iomem *imem;
> struct device *dev;
> -   unsigned int index;
> struct mutex lock;
>  };
>
> @@ -628,10 +627,8 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
>  {
> struct device *dev = >dev;
> struct private_data *priv;
> -   struct device *dpfe_dev;
> struct init_data init;
> struct resource *res;
> -   u32 index;
> int ret;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -641,11 +638,6 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
> mutex_init(>lock);
> platform_set_drvdata(pdev, priv);
>
> -   /* Cell index is optional; default to 0 if not present. */
> -   ret = of_property_read_u32(dev->of_node, "cell-index", );
> -   if (ret)
> -   index = 0;
> -
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dpfe-cpu");
> priv->regs = devm_ioremap_resource(dev, res);
> if (IS_ERR(priv->regs)) {
> @@ -669,35 +661,20 @@ static int brcmstb_dpfe_probe(struct platform_device 
> *pdev)
>
> ret = brcmstb_dpfe_download_firmware(pdev, );
> if (ret)
> -   goto err;
> -
> -   dpfe_dev = devm_kzalloc(dev, sizeof(*dpfe_dev), GFP_KERNEL);
> -   if (!dpfe_dev) {
> -   ret = -ENOMEM;
> -   goto err;
> -   }
> -
> -   priv->dev = dpfe_dev;
> -   priv->index = index;
> +   return ret;
>
> -   dpfe_dev->parent = dev;
> -   dpfe_dev->groups = dpfe_groups;
> -   dpfe_dev->of_node = dev->of_node;
> -   dev_set_drvdata(dpfe_dev, priv);
> -   dev_set_name(dpfe_dev, "dpfe%u", index);
> +   ret = sysfs_create_groups(>dev.kobj, dpfe_groups);
> +   if (!ret)
> +   dev_info(dev, "registered.\n");
>
> -   ret = device_register(dpfe_dev);
> -   if (ret)
> -   goto err;
> +   return ret;
> +}
>
> -   dev_info(dev, "registered.\n");
> +static int brcmstb_dpfe_remove(struct platform_device *pdev)
> +{
> +   sysfs_remove_groups(>dev.kobj, dpfe_groups);
>
> return 0;
> -
> -err:
> -   dev_err(dev, "failed to initialize -- error %d\n", ret);
> -
> -   return ret;
>  }
>
>  static const struct of_device_id brcmstb_dpfe_of_match[] = {
> @@ -712,6 +689,7 @@ static struct platform_driver brcmstb_dpfe_driver = {
> .of_match_table = brcmstb_dpfe_of_match,
> },
> .probe = brcmstb_dpfe_probe,
> +   .remove = brcmstb_dpfe_remove,
> .resume = brcmstb_dpfe_resume,
>  };
>
> --
> 2.14.1
>


[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

2018-02-13 Thread Markus Mayer
The DCPU can now send message data in two ways:
  - via the data RAM, as before (this is now message type 0)
  - via the message RAM (this is message type 1)

In order to support both methods, we check the message type of the
response (bits 31:28) and then treat the offset (bits 27:0)
accordingly.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 65 ---
 1 file changed, 55 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 2013a91217a9..e9c1485c32b9 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -45,8 +45,16 @@
 #define REG_TO_DCPU_MBOX   0x10
 #define REG_TO_HOST_MBOX   0x14
 
+/* Macros to process offsets returned by the DCPU */
+#define DRAM_MSG_ADDR_OFFSET   0x0
+#define DRAM_MSG_TYPE_OFFSET   0x1c
+#define DRAM_MSG_ADDR_MASK ((1UL << DRAM_MSG_TYPE_OFFSET) - 1)
+#define DRAM_MSG_TYPE_MASK ((1UL << \
+(BITS_PER_LONG - DRAM_MSG_TYPE_OFFSET)) - 1)
+
 /* Message RAM */
-#define DCPU_MSG_RAM(x)(0x100 + (x) * sizeof(u32))
+#define DCPU_MSG_RAM_START 0x100
+#define DCPU_MSG_RAM(x)(DCPU_MSG_RAM_START + (x) * sizeof(u32))
 
 /* DRAM Info Offsets & Masks */
 #define DRAM_INFO_INTERVAL 0x0
@@ -255,6 +263,40 @@ static unsigned int get_msg_chksum(const u32 msg[])
return sum;
 }
 
+static void __iomem *get_msg_ptr(struct private_data *priv, u32 response,
+char *buf, ssize_t *size)
+{
+   unsigned int msg_type;
+   unsigned int offset;
+   void __iomem *ptr = NULL;
+
+   msg_type = (response >> DRAM_MSG_TYPE_OFFSET) & DRAM_MSG_TYPE_MASK;
+   offset = (response >> DRAM_MSG_ADDR_OFFSET) & DRAM_MSG_ADDR_MASK;
+
+   /*
+* msg_type == 1: the offset is relative to the message RAM
+* msg_type == 0: the offset is relative to the data RAM (this is the
+*previous way of passing data)
+* msg_type is anything else: there's critical hardware problem
+*/
+   switch (msg_type) {
+   case 1:
+   ptr = priv->regs + DCPU_MSG_RAM_START + offset;
+   break;
+   case 0:
+   ptr = priv->dmem + offset;
+   break;
+   default:
+   dev_emerg(priv->dev, "invalid message reply from DCPU: %#x\n",
+   response);
+   if (buf && size)
+   *size = sprintf(buf,
+   "FATAL: communication error with DCPU\n");
+   }
+
+   return ptr;
+}
+
 static int __send_command(struct private_data *priv, unsigned int cmd,
  u32 result[])
 {
@@ -528,7 +570,6 @@ static ssize_t show_refresh(struct device *dev,
u32 response[MSG_FIELD_MAX];
void __iomem *info;
struct private_data *priv;
-   unsigned int offset;
u8 refresh, sr_abort, ppre, thermal_offs, tuf;
u32 mr4;
ssize_t ret;
@@ -538,8 +579,10 @@ static ssize_t show_refresh(struct device *dev,
return ret;
 
priv = dev_get_drvdata(dev);
-   offset = response[MSG_ARG0];
-   info = priv->dmem + offset;
+
+   info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
+   if (!info)
+   return ret;
 
mr4 = readl_relaxed(info + DRAM_INFO_MR4) & DRAM_INFO_MR4_MASK;
 
@@ -561,7 +604,6 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
u32 response[MSG_FIELD_MAX];
struct private_data *priv;
void __iomem *info;
-   unsigned int offset;
unsigned long val;
int ret;
 
@@ -574,8 +616,10 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
if (ret)
return ret;
 
-   offset = response[MSG_ARG0];
-   info = priv->dmem + offset;
+   info = get_msg_ptr(priv, response[MSG_ARG0], NULL, NULL);
+   if (!info)
+   return -EIO;
+
writel_relaxed(val, info + DRAM_INFO_INTERVAL);
 
return count;
@@ -587,16 +631,17 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
u32 response[MSG_FIELD_MAX];
struct private_data *priv;
void __iomem *info;
-   unsigned int offset;
ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
if (ret)
return ret;
 
-   offset = response[MSG_ARG0];
priv = dev_get_drvdata(dev);
-   info = priv->dmem + offset;
+
+   info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
+   if (!info)
+   return ret;
 
return sprintf(buf, "%#x %#x %#x %#x %#x\n",
   readl_relaxed(info + DRAM_VENDOR_MR5) & DRAM_VENDOR_MASK,
-- 
2.7.4



[PATCH 3/3] memory: brcmstb: dpfe: support new way of passing data from the DCPU

2018-02-13 Thread Markus Mayer
The DCPU can now send message data in two ways:
  - via the data RAM, as before (this is now message type 0)
  - via the message RAM (this is message type 1)

In order to support both methods, we check the message type of the
response (bits 31:28) and then treat the offset (bits 27:0)
accordingly.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 65 ---
 1 file changed, 55 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 2013a91217a9..e9c1485c32b9 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -45,8 +45,16 @@
 #define REG_TO_DCPU_MBOX   0x10
 #define REG_TO_HOST_MBOX   0x14
 
+/* Macros to process offsets returned by the DCPU */
+#define DRAM_MSG_ADDR_OFFSET   0x0
+#define DRAM_MSG_TYPE_OFFSET   0x1c
+#define DRAM_MSG_ADDR_MASK ((1UL << DRAM_MSG_TYPE_OFFSET) - 1)
+#define DRAM_MSG_TYPE_MASK ((1UL << \
+(BITS_PER_LONG - DRAM_MSG_TYPE_OFFSET)) - 1)
+
 /* Message RAM */
-#define DCPU_MSG_RAM(x)(0x100 + (x) * sizeof(u32))
+#define DCPU_MSG_RAM_START 0x100
+#define DCPU_MSG_RAM(x)(DCPU_MSG_RAM_START + (x) * sizeof(u32))
 
 /* DRAM Info Offsets & Masks */
 #define DRAM_INFO_INTERVAL 0x0
@@ -255,6 +263,40 @@ static unsigned int get_msg_chksum(const u32 msg[])
return sum;
 }
 
+static void __iomem *get_msg_ptr(struct private_data *priv, u32 response,
+char *buf, ssize_t *size)
+{
+   unsigned int msg_type;
+   unsigned int offset;
+   void __iomem *ptr = NULL;
+
+   msg_type = (response >> DRAM_MSG_TYPE_OFFSET) & DRAM_MSG_TYPE_MASK;
+   offset = (response >> DRAM_MSG_ADDR_OFFSET) & DRAM_MSG_ADDR_MASK;
+
+   /*
+* msg_type == 1: the offset is relative to the message RAM
+* msg_type == 0: the offset is relative to the data RAM (this is the
+*previous way of passing data)
+* msg_type is anything else: there's critical hardware problem
+*/
+   switch (msg_type) {
+   case 1:
+   ptr = priv->regs + DCPU_MSG_RAM_START + offset;
+   break;
+   case 0:
+   ptr = priv->dmem + offset;
+   break;
+   default:
+   dev_emerg(priv->dev, "invalid message reply from DCPU: %#x\n",
+   response);
+   if (buf && size)
+   *size = sprintf(buf,
+   "FATAL: communication error with DCPU\n");
+   }
+
+   return ptr;
+}
+
 static int __send_command(struct private_data *priv, unsigned int cmd,
  u32 result[])
 {
@@ -528,7 +570,6 @@ static ssize_t show_refresh(struct device *dev,
u32 response[MSG_FIELD_MAX];
void __iomem *info;
struct private_data *priv;
-   unsigned int offset;
u8 refresh, sr_abort, ppre, thermal_offs, tuf;
u32 mr4;
ssize_t ret;
@@ -538,8 +579,10 @@ static ssize_t show_refresh(struct device *dev,
return ret;
 
priv = dev_get_drvdata(dev);
-   offset = response[MSG_ARG0];
-   info = priv->dmem + offset;
+
+   info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
+   if (!info)
+   return ret;
 
mr4 = readl_relaxed(info + DRAM_INFO_MR4) & DRAM_INFO_MR4_MASK;
 
@@ -561,7 +604,6 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
u32 response[MSG_FIELD_MAX];
struct private_data *priv;
void __iomem *info;
-   unsigned int offset;
unsigned long val;
int ret;
 
@@ -574,8 +616,10 @@ static ssize_t store_refresh(struct device *dev, struct 
device_attribute *attr,
if (ret)
return ret;
 
-   offset = response[MSG_ARG0];
-   info = priv->dmem + offset;
+   info = get_msg_ptr(priv, response[MSG_ARG0], NULL, NULL);
+   if (!info)
+   return -EIO;
+
writel_relaxed(val, info + DRAM_INFO_INTERVAL);
 
return count;
@@ -587,16 +631,17 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
u32 response[MSG_FIELD_MAX];
struct private_data *priv;
void __iomem *info;
-   unsigned int offset;
ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
if (ret)
return ret;
 
-   offset = response[MSG_ARG0];
priv = dev_get_drvdata(dev);
-   info = priv->dmem + offset;
+
+   info = get_msg_ptr(priv, response[MSG_ARG0], buf, );
+   if (!info)
+   return ret;
 
return sprintf(buf, "%#x %#x %#x %#x %#x\n",
   readl_relaxed(info + DRAM_VENDOR_MR5) & DRAM_VENDOR_MASK,
-- 
2.7.4



[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

2018-02-13 Thread Markus Mayer
In some functions, variable "ret" should be ssize_t, so we fix it.

Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 088153760e52..2013a91217a9 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -507,7 +507,7 @@ static ssize_t show_info(struct device *dev, struct 
device_attribute *devattr,
 {
u32 response[MSG_FIELD_MAX];
unsigned int info;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_INFO, response, dev, buf);
if (ret)
@@ -531,7 +531,7 @@ static ssize_t show_refresh(struct device *dev,
unsigned int offset;
u8 refresh, sr_abort, ppre, thermal_offs, tuf;
u32 mr4;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_REFRESH, response, dev, buf);
if (ret)
@@ -588,7 +588,7 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
struct private_data *priv;
void __iomem *info;
unsigned int offset;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
if (ret)
-- 
2.7.4



[PATCH 2/3] memory: brcmstb: dpfe: fix type declaration of variable "ret"

2018-02-13 Thread Markus Mayer
In some functions, variable "ret" should be ssize_t, so we fix it.

Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 088153760e52..2013a91217a9 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -507,7 +507,7 @@ static ssize_t show_info(struct device *dev, struct 
device_attribute *devattr,
 {
u32 response[MSG_FIELD_MAX];
unsigned int info;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_INFO, response, dev, buf);
if (ret)
@@ -531,7 +531,7 @@ static ssize_t show_refresh(struct device *dev,
unsigned int offset;
u8 refresh, sr_abort, ppre, thermal_offs, tuf;
u32 mr4;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_REFRESH, response, dev, buf);
if (ret)
@@ -588,7 +588,7 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
struct private_data *priv;
void __iomem *info;
unsigned int offset;
-   int ret;
+   ssize_t ret;
 
ret = generic_show(DPFE_CMD_GET_VENDOR, response, dev, buf);
if (ret)
-- 
2.7.4



[PATCH 0/3] Update for the Broadcom STB DPFE driver

2018-02-13 Thread Markus Mayer
This series primarily introduces a new way of passing information from
the DCPU to the host CPU.

Previously, all communication was via the DCPU data RAM. This
communication mode is still supported. In addition, we now support
passing data via the message RAM. The driver will dynamically detect
which method to use upon receiving a reply.

The series also contains two fixes to the driver that have no direct
relation with the new communication feature.

Markus Mayer (3):
  memory: brcmstb: dpfe: properly mask vendor error bits
  memory: brcmstb: dpfe: fix type declaration of variable "ret"
  memory: brcmstb: dpfe: support new way of passing data from the DCPU

 drivers/memory/brcmstb_dpfe.c | 74 +++
 1 file changed, 60 insertions(+), 14 deletions(-)

-- 
2.7.4



[PATCH 0/3] Update for the Broadcom STB DPFE driver

2018-02-13 Thread Markus Mayer
This series primarily introduces a new way of passing information from
the DCPU to the host CPU.

Previously, all communication was via the DCPU data RAM. This
communication mode is still supported. In addition, we now support
passing data via the message RAM. The driver will dynamically detect
which method to use upon receiving a reply.

The series also contains two fixes to the driver that have no direct
relation with the new communication feature.

Markus Mayer (3):
  memory: brcmstb: dpfe: properly mask vendor error bits
  memory: brcmstb: dpfe: fix type declaration of variable "ret"
  memory: brcmstb: dpfe: support new way of passing data from the DCPU

 drivers/memory/brcmstb_dpfe.c | 74 +++
 1 file changed, 60 insertions(+), 14 deletions(-)

-- 
2.7.4



[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

2018-02-13 Thread Markus Mayer
We were printing the entire 32 bit register rather than just the lower
8 bits. Anything above bit 7 is reserved and may be any random value.

Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 0a7bdbed3a6f..088153760e52 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -603,7 +603,8 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
   readl_relaxed(info + DRAM_VENDOR_MR6) & DRAM_VENDOR_MASK,
   readl_relaxed(info + DRAM_VENDOR_MR7) & DRAM_VENDOR_MASK,
   readl_relaxed(info + DRAM_VENDOR_MR8) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_ERROR));
+  readl_relaxed(info + DRAM_VENDOR_ERROR) &
+DRAM_VENDOR_MASK);
 }
 
 static int brcmstb_dpfe_resume(struct platform_device *pdev)
-- 
2.7.4



[PATCH 1/3] memory: brcmstb: dpfe: properly mask vendor error bits

2018-02-13 Thread Markus Mayer
We were printing the entire 32 bit register rather than just the lower
8 bits. Anything above bit 7 is reserved and may be any random value.

Fixes: 2f330caff577 ("memory: brcmstb: Add driver for DPFE")
Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 0a7bdbed3a6f..088153760e52 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -603,7 +603,8 @@ static ssize_t show_vendor(struct device *dev, struct 
device_attribute *devattr,
   readl_relaxed(info + DRAM_VENDOR_MR6) & DRAM_VENDOR_MASK,
   readl_relaxed(info + DRAM_VENDOR_MR7) & DRAM_VENDOR_MASK,
   readl_relaxed(info + DRAM_VENDOR_MR8) & DRAM_VENDOR_MASK,
-  readl_relaxed(info + DRAM_VENDOR_ERROR));
+  readl_relaxed(info + DRAM_VENDOR_ERROR) &
+DRAM_VENDOR_MASK);
 }
 
 static int brcmstb_dpfe_resume(struct platform_device *pdev)
-- 
2.7.4



Re: 4.14.0-rc7: cpufreq interface in sysfs removed ?

2017-11-01 Thread Markus Mayer
On 1 November 2017 at 10:06, Jörg Otte  wrote:
> In 4.14.0-rc7-9-g287683d cpufreq directory under
> /sys/devices/system/cpu/cpufreq
> is empty. Also link /sys/devices/system/cpu/cpu0/cpufreq is missing.

It is looking fine on my system.

# dmesg | grep cpufreq
<6>[1.313374] brcmstb-avs-cpufreq f04c4000.avs-cpu-data-mem: registered

# find /sys -name \*cpufreq\*
/sys/devices/system/cpu/cpu3/cpufreq
/sys/devices/system/cpu/cpu1/cpufreq
/sys/devices/system/cpu/cpufreq
/sys/devices/system/cpu/cpu2/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq
/sys/bus/platform/drivers/cpufreq-dt
/sys/bus/platform/drivers/brcmstb-avs-cpufreq
/sys/module/cpufreq

# uname -a
Linux (none) 4.14.0-rc7 #1 SMP Wed Nov 1 10:34:11 PDT 2017 armv7l GNU/Linux

> Is this change intentional?

This sounds more like your cpufreq driver didn't load. It is probably
worth investigating in that direction.

Also, you didn't mention anything about your hardware or your configuration.

> Jörg


Re: 4.14.0-rc7: cpufreq interface in sysfs removed ?

2017-11-01 Thread Markus Mayer
On 1 November 2017 at 10:06, Jörg Otte  wrote:
> In 4.14.0-rc7-9-g287683d cpufreq directory under
> /sys/devices/system/cpu/cpufreq
> is empty. Also link /sys/devices/system/cpu/cpu0/cpufreq is missing.

It is looking fine on my system.

# dmesg | grep cpufreq
<6>[1.313374] brcmstb-avs-cpufreq f04c4000.avs-cpu-data-mem: registered

# find /sys -name \*cpufreq\*
/sys/devices/system/cpu/cpu3/cpufreq
/sys/devices/system/cpu/cpu1/cpufreq
/sys/devices/system/cpu/cpufreq
/sys/devices/system/cpu/cpu2/cpufreq
/sys/devices/system/cpu/cpu0/cpufreq
/sys/bus/platform/drivers/cpufreq-dt
/sys/bus/platform/drivers/brcmstb-avs-cpufreq
/sys/module/cpufreq

# uname -a
Linux (none) 4.14.0-rc7 #1 SMP Wed Nov 1 10:34:11 PDT 2017 armv7l GNU/Linux

> Is this change intentional?

This sounds more like your cpufreq driver didn't load. It is probably
worth investigating in that direction.

Also, you didn't mention anything about your hardware or your configuration.

> Jörg


Re: [PATCH 0/3] tools/thermal: tmon: Makefile improvements

2017-10-13 Thread Markus Mayer
On 27 September 2017 at 16:02, Markus Mayer <c...@mmayer.net> wrote:
> From: Markus Mayer <mma...@broadcom.com>
>
> This series introduces a number of improvements to tmon's Makefile. The
> changes are meant to make it easier to cross-compile tmon on a greater
> number of platforms by giving more control to the person performing the
> build.
>
> At the same time, sensible defaults are retained so that building tmon
> will continue to work without any customizations on platforms on which
> it currently builds.

Rui, is there any chance you would be able to take this?

Thanks,
-Markus

> Markus Mayer (3):
>   tools/thermal: tmon: use "-fstack-protector" only if supported
>   tools/thermal: tmon: allow $(CC) to be defined externally
>   tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
> pkg-config
>
>  tools/thermal/tmon/Makefile | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> --
> 2.7.4
>


Re: [PATCH 0/3] tools/thermal: tmon: Makefile improvements

2017-10-13 Thread Markus Mayer
On 27 September 2017 at 16:02, Markus Mayer  wrote:
> From: Markus Mayer 
>
> This series introduces a number of improvements to tmon's Makefile. The
> changes are meant to make it easier to cross-compile tmon on a greater
> number of platforms by giving more control to the person performing the
> build.
>
> At the same time, sensible defaults are retained so that building tmon
> will continue to work without any customizations on platforms on which
> it currently builds.

Rui, is there any chance you would be able to take this?

Thanks,
-Markus

> Markus Mayer (3):
>   tools/thermal: tmon: use "-fstack-protector" only if supported
>   tools/thermal: tmon: allow $(CC) to be defined externally
>   tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
> pkg-config
>
>  tools/thermal/tmon/Makefile | 18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
>
> --
> 2.7.4
>


[PATCH 2/2] memory: brcmstb: dpfe: skip downloading firmware when possible

2017-10-02 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

We want to skip downloading the DPFE firmware from Linux if it was
already downloaded by the boot loader.

The driver now checks if the DCPU is already running and, if so,
whether it can process commands. If the DCPU processes commands
successfully, the driver skips the firmware download step.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 3516ee8..0a7bdbe 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -431,13 +431,25 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
const void *fw_blob;
int ret;
 
+   priv = platform_get_drvdata(pdev);
+
+   /*
+* Skip downloading the firmware if the DCPU is already running and
+* responding to commands.
+*/
+   if (is_dcpu_enabled(priv->regs)) {
+   u32 response[MSG_FIELD_MAX];
+
+   ret = __send_command(priv, DPFE_CMD_GET_INFO, response);
+   if (!ret)
+   return 0;
+   }
+
ret = request_firmware(, FIRMWARE_NAME, dev);
/* request_firmware() prints its own error messages. */
if (ret)
return ret;
 
-   priv = platform_get_drvdata(pdev);
-
ret = __verify_firmware(init, fw);
if (ret)
return -EFAULT;
-- 
2.7.4



[PATCH 2/2] memory: brcmstb: dpfe: skip downloading firmware when possible

2017-10-02 Thread Markus Mayer
From: Markus Mayer 

We want to skip downloading the DPFE firmware from Linux if it was
already downloaded by the boot loader.

The driver now checks if the DCPU is already running and, if so,
whether it can process commands. If the DCPU processes commands
successfully, the driver skips the firmware download step.

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 3516ee8..0a7bdbe 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -431,13 +431,25 @@ static int brcmstb_dpfe_download_firmware(struct 
platform_device *pdev,
const void *fw_blob;
int ret;
 
+   priv = platform_get_drvdata(pdev);
+
+   /*
+* Skip downloading the firmware if the DCPU is already running and
+* responding to commands.
+*/
+   if (is_dcpu_enabled(priv->regs)) {
+   u32 response[MSG_FIELD_MAX];
+
+   ret = __send_command(priv, DPFE_CMD_GET_INFO, response);
+   if (!ret)
+   return 0;
+   }
+
ret = request_firmware(, FIRMWARE_NAME, dev);
/* request_firmware() prints its own error messages. */
if (ret)
return ret;
 
-   priv = platform_get_drvdata(pdev);
-
ret = __verify_firmware(init, fw);
if (ret)
return -EFAULT;
-- 
2.7.4



[PATCH 1/2] memory: brcmstb: dpfe: introduce is_dcpu_enabled()

2017-10-02 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

In order to check whether or not the DCPU is running, we introduce
a function called is_dcpu_enabled().

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/memory/brcmstb_dpfe.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 21242c4..3516ee8 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -202,17 +202,26 @@ static const u32 
dpfe_commands[DPFE_CMD_MAX][MSG_FIELD_MAX] = {
},
 };
 
+static bool is_dcpu_enabled(void __iomem *regs)
+{
+   u32 val;
+
+   val = readl_relaxed(regs + REG_DCPU_RESET);
+
+   return !(val & DCPU_RESET_MASK);
+}
+
 static void __disable_dcpu(void __iomem *regs)
 {
u32 val;
 
-   /* Check if DCPU is running */
+   if (!is_dcpu_enabled(regs))
+   return;
+
+   /* Put DCPU in reset if it's running. */
val = readl_relaxed(regs + REG_DCPU_RESET);
-   if (!(val & DCPU_RESET_MASK)) {
-   /* Put DCPU in reset */
-   val |= (1 << DCPU_RESET_SHIFT);
-   writel_relaxed(val, regs + REG_DCPU_RESET);
-   }
+   val |= (1 << DCPU_RESET_SHIFT);
+   writel_relaxed(val, regs + REG_DCPU_RESET);
 }
 
 static void __enable_dcpu(void __iomem *regs)
-- 
2.7.4



[PATCH 1/2] memory: brcmstb: dpfe: introduce is_dcpu_enabled()

2017-10-02 Thread Markus Mayer
From: Markus Mayer 

In order to check whether or not the DCPU is running, we introduce
a function called is_dcpu_enabled().

Signed-off-by: Markus Mayer 
---
 drivers/memory/brcmstb_dpfe.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
index 21242c4..3516ee8 100644
--- a/drivers/memory/brcmstb_dpfe.c
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -202,17 +202,26 @@ static const u32 
dpfe_commands[DPFE_CMD_MAX][MSG_FIELD_MAX] = {
},
 };
 
+static bool is_dcpu_enabled(void __iomem *regs)
+{
+   u32 val;
+
+   val = readl_relaxed(regs + REG_DCPU_RESET);
+
+   return !(val & DCPU_RESET_MASK);
+}
+
 static void __disable_dcpu(void __iomem *regs)
 {
u32 val;
 
-   /* Check if DCPU is running */
+   if (!is_dcpu_enabled(regs))
+   return;
+
+   /* Put DCPU in reset if it's running. */
val = readl_relaxed(regs + REG_DCPU_RESET);
-   if (!(val & DCPU_RESET_MASK)) {
-   /* Put DCPU in reset */
-   val |= (1 << DCPU_RESET_SHIFT);
-   writel_relaxed(val, regs + REG_DCPU_RESET);
-   }
+   val |= (1 << DCPU_RESET_SHIFT);
+   writel_relaxed(val, regs + REG_DCPU_RESET);
 }
 
 static void __enable_dcpu(void __iomem *regs)
-- 
2.7.4



[PATCH 0/2] memory: brcmstb: dpfe: skip downloading firmware

2017-10-02 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This series lets the DPFE driver skip the DPFE firmware download if the
DCPU is already running. If it's running by the time Linux comes up, it
means the boot loader already downloaded the DPFE firmware.

Markus Mayer (2):
  memory: brcmstb: dpfe: introduce is_dcpu_enabled()
  memory: brcmstb: dpfe: skip downloading firmware when possible

 drivers/memory/brcmstb_dpfe.c | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

-- 
2.7.4



[PATCH 0/2] memory: brcmstb: dpfe: skip downloading firmware

2017-10-02 Thread Markus Mayer
From: Markus Mayer 

This series lets the DPFE driver skip the DPFE firmware download if the
DCPU is already running. If it's running by the time Linux comes up, it
means the boot loader already downloaded the DPFE firmware.

Markus Mayer (2):
  memory: brcmstb: dpfe: introduce is_dcpu_enabled()
  memory: brcmstb: dpfe: skip downloading firmware when possible

 drivers/memory/brcmstb_dpfe.c | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

-- 
2.7.4



[PATCH 3/3] tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding pkg-config

2017-09-27 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

To ease cross-compiling, make use of the $(PKG_CONFIG) variable rather
than hard-coding calls to pkg-config.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 tools/thermal/tmon/Makefile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 581da71..1e11bd3 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -9,6 +9,7 @@ CFLAGS+= -O1 ${WARNFLAGS}
 # Add "-fstack-protector" only if toolchain supports it.
 CFLAGS+= $(call cc-option,-fstack-protector)
 CC?= $(CROSS_COMPILE)gcc
+PKG_CONFIG?= pkg-config
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
 LDFLAGS+=
@@ -23,12 +24,12 @@ STATIC := --static
 endif
 
 TMON_LIBS=-lm -lpthread
-TMON_LIBS += $(shell pkg-config --libs $(STATIC) panelw ncursesw 2> /dev/null 
|| \
-pkg-config --libs $(STATIC) panel ncurses 2> /dev/null || \
+TMON_LIBS += $(shell $(PKG_CONFIG) --libs $(STATIC) panelw ncursesw 2> 
/dev/null || \
+$(PKG_CONFIG) --libs $(STATIC) panel ncurses 2> /dev/null 
|| \
 echo -lpanel -lncurses)
 
-CFLAGS+= $(shell pkg-config --cflags $(STATIC) panelw ncursesw 2> 
/dev/null || \
-pkg-config --cflags $(STATIC) panel ncurses 2> /dev/null)
+CFLAGS+= $(shell $(PKG_CONFIG) --cflags $(STATIC) panelw ncursesw 2> 
/dev/null || \
+$(PKG_CONFIG) --cflags $(STATIC) panel ncurses 2> 
/dev/null)
 
 OBJS = tmon.o tui.o sysfs.o pid.o
 OBJS +=
-- 
2.7.4



[PATCH 3/3] tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding pkg-config

2017-09-27 Thread Markus Mayer
From: Markus Mayer 

To ease cross-compiling, make use of the $(PKG_CONFIG) variable rather
than hard-coding calls to pkg-config.

Signed-off-by: Markus Mayer 
---
 tools/thermal/tmon/Makefile | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 581da71..1e11bd3 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -9,6 +9,7 @@ CFLAGS+= -O1 ${WARNFLAGS}
 # Add "-fstack-protector" only if toolchain supports it.
 CFLAGS+= $(call cc-option,-fstack-protector)
 CC?= $(CROSS_COMPILE)gcc
+PKG_CONFIG?= pkg-config
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
 LDFLAGS+=
@@ -23,12 +24,12 @@ STATIC := --static
 endif
 
 TMON_LIBS=-lm -lpthread
-TMON_LIBS += $(shell pkg-config --libs $(STATIC) panelw ncursesw 2> /dev/null 
|| \
-pkg-config --libs $(STATIC) panel ncurses 2> /dev/null || \
+TMON_LIBS += $(shell $(PKG_CONFIG) --libs $(STATIC) panelw ncursesw 2> 
/dev/null || \
+$(PKG_CONFIG) --libs $(STATIC) panel ncurses 2> /dev/null 
|| \
 echo -lpanel -lncurses)
 
-CFLAGS+= $(shell pkg-config --cflags $(STATIC) panelw ncursesw 2> 
/dev/null || \
-pkg-config --cflags $(STATIC) panel ncurses 2> /dev/null)
+CFLAGS+= $(shell $(PKG_CONFIG) --cflags $(STATIC) panelw ncursesw 2> 
/dev/null || \
+$(PKG_CONFIG) --cflags $(STATIC) panel ncurses 2> 
/dev/null)
 
 OBJS = tmon.o tui.o sysfs.o pid.o
 OBJS +=
-- 
2.7.4



[PATCH 2/3] tools/thermal: tmon: allow $(CC) to be defined externally

2017-09-27 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

It can be helpful, especially when using a build system, to set the C
compiler externally.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 tools/thermal/tmon/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 5777bc7..581da71 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -8,7 +8,7 @@ WARNFLAGS=-Wall -Wshadow -W -Wformat 
-Wimplicit-function-declaration -Wimplicit-
 CFLAGS+= -O1 ${WARNFLAGS}
 # Add "-fstack-protector" only if toolchain supports it.
 CFLAGS+= $(call cc-option,-fstack-protector)
-CC=$(CROSS_COMPILE)gcc
+CC?= $(CROSS_COMPILE)gcc
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
 LDFLAGS+=
-- 
2.7.4



[PATCH 1/3] tools/thermal: tmon: use "-fstack-protector" only if supported

2017-09-27 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

Most, but not all, toolchains support the "-fstack-protector" flag. We
check if the compiler supports the flag before using it. This allows
tmon to be compiled for more environments.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 tools/thermal/tmon/Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 3a961e9..5777bc7 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -1,8 +1,13 @@
+# We need this for the "cc-option" macro.
+include ../../../scripts/Kbuild.include
+
 VERSION = 1.0
 
 BINDIR=usr/bin
 WARNFLAGS=-Wall -Wshadow -W -Wformat -Wimplicit-function-declaration 
-Wimplicit-int
-CFLAGS+= -O1 ${WARNFLAGS} -fstack-protector
+CFLAGS+= -O1 ${WARNFLAGS}
+# Add "-fstack-protector" only if toolchain supports it.
+CFLAGS+= $(call cc-option,-fstack-protector)
 CC=$(CROSS_COMPILE)gcc
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
-- 
2.7.4



[PATCH 2/3] tools/thermal: tmon: allow $(CC) to be defined externally

2017-09-27 Thread Markus Mayer
From: Markus Mayer 

It can be helpful, especially when using a build system, to set the C
compiler externally.

Signed-off-by: Markus Mayer 
---
 tools/thermal/tmon/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 5777bc7..581da71 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -8,7 +8,7 @@ WARNFLAGS=-Wall -Wshadow -W -Wformat 
-Wimplicit-function-declaration -Wimplicit-
 CFLAGS+= -O1 ${WARNFLAGS}
 # Add "-fstack-protector" only if toolchain supports it.
 CFLAGS+= $(call cc-option,-fstack-protector)
-CC=$(CROSS_COMPILE)gcc
+CC?= $(CROSS_COMPILE)gcc
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
 LDFLAGS+=
-- 
2.7.4



[PATCH 1/3] tools/thermal: tmon: use "-fstack-protector" only if supported

2017-09-27 Thread Markus Mayer
From: Markus Mayer 

Most, but not all, toolchains support the "-fstack-protector" flag. We
check if the compiler supports the flag before using it. This allows
tmon to be compiled for more environments.

Signed-off-by: Markus Mayer 
---
 tools/thermal/tmon/Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/thermal/tmon/Makefile b/tools/thermal/tmon/Makefile
index 3a961e9..5777bc7 100644
--- a/tools/thermal/tmon/Makefile
+++ b/tools/thermal/tmon/Makefile
@@ -1,8 +1,13 @@
+# We need this for the "cc-option" macro.
+include ../../../scripts/Kbuild.include
+
 VERSION = 1.0
 
 BINDIR=usr/bin
 WARNFLAGS=-Wall -Wshadow -W -Wformat -Wimplicit-function-declaration 
-Wimplicit-int
-CFLAGS+= -O1 ${WARNFLAGS} -fstack-protector
+CFLAGS+= -O1 ${WARNFLAGS}
+# Add "-fstack-protector" only if toolchain supports it.
+CFLAGS+= $(call cc-option,-fstack-protector)
 CC=$(CROSS_COMPILE)gcc
 
 CFLAGS+=-D VERSION=\"$(VERSION)\"
-- 
2.7.4



[PATCH 0/3] tools/thermal: tmon: Makefile improvements

2017-09-27 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This series introduces a number of improvements to tmon's Makefile. The
changes are meant to make it easier to cross-compile tmon on a greater
number of platforms by giving more control to the person performing the
build.

At the same time, sensible defaults are retained so that building tmon
will continue to work without any customizations on platforms on which
it currently builds.

Markus Mayer (3):
  tools/thermal: tmon: use "-fstack-protector" only if supported
  tools/thermal: tmon: allow $(CC) to be defined externally
  tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
pkg-config

 tools/thermal/tmon/Makefile | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.7.4



[PATCH 0/3] tools/thermal: tmon: Makefile improvements

2017-09-27 Thread Markus Mayer
From: Markus Mayer 

This series introduces a number of improvements to tmon's Makefile. The
changes are meant to make it easier to cross-compile tmon on a greater
number of platforms by giving more control to the person performing the
build.

At the same time, sensible defaults are retained so that building tmon
will continue to work without any customizations on platforms on which
it currently builds.

Markus Mayer (3):
  tools/thermal: tmon: use "-fstack-protector" only if supported
  tools/thermal: tmon: allow $(CC) to be defined externally
  tools/thermal: tmon: use $(PKG_CONFIG) instead of hard-coding
pkg-config

 tools/thermal/tmon/Makefile | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.7.4



Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
On 26 September 2017 at 14:32, Scott Branden <scott.bran...@broadcom.com> wrote:
> Hi Markus,
>
>
> On 17-09-26 02:27 PM, Markus Mayer wrote:
>>
>> From: Brian Norris <computersforpe...@gmail.com>
>>
>> The AVS TMON core provides temperature readings, a pair of configurable
>> high- and low-temperature threshold interrupts, and an emergency
>> over-temperature chip reset. The driver utilizes the first two to
>> provide temperature readings and high-temperature notifications to
>> applications. The over-temperature reset is not exposed to
>> applications; this reset threshold is critical to the system and should
>> be set with care within the bootloader.
>>
>> Applications may choose to utilize the notification mechanism, the
>> temperature reading mechanism (e.g., through polling), or both.
>>
>> Signed-off-by: Brian Norris <computersforpe...@gmail.com>
>> Signed-off-by: Doug Berger <open...@gmail.com>
>> Signed-off-by: Markus Mayer <mma...@broadcom.com>
>> ---
>>   drivers/thermal/Kconfig|   2 +-
>>   drivers/thermal/broadcom/Kconfig   |   7 +
>>   drivers/thermal/broadcom/Makefile  |   1 +
>>   drivers/thermal/broadcom/brcmstb_thermal.c | 387
>> +
>>   4 files changed, 396 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 07002df..96774a7 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -408,7 +408,7 @@ config MTK_THERMAL
>>   controller present in Mediatek SoCs
>> menu "Broadcom thermal drivers"
>> -depends on ARCH_BCM || COMPILE_TEST
>> +depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
>
> No need for this additional depends.  ARCH_BCM is always defined before
> ARCH_BRCMSTB can be selected.

ARCH_BCM does not exist in arch/arm64/configs/defconfig. ARCH_BRCMSTB
does. So, we do need both or the driver won't be built on ARM64.
(After internal discussions we went with that approach rather than
defining ARCH_BCM on ARM64.)

>>   source "drivers/thermal/broadcom/Kconfig"
>>   endmenu
>>   diff --git a/drivers/thermal/broadcom/Kconfig
>> b/drivers/thermal/broadcom/Kconfig
>> index 42c098e..c106a15 100644
>> --- a/drivers/thermal/broadcom/Kconfig
>> +++ b/drivers/thermal/broadcom/Kconfig
>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>> help
>>   Support for thermal sensors on Broadcom bcm2835 SoCs.
>>   +config BRCMSTB_THERMAL
>> +   tristate "Broadcom STB AVS TMON thermal driver"
>> +   depends on ARCH_BRCMSTB || COMPILE_TEST
>> +   help
>> + Enable this driver if you have a Broadcom STB SoC and would like
>> + thermal framework support.
>> +
>>   config BCM_NS_THERMAL
>> tristate "Northstar thermal driver"
>> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> diff --git a/drivers/thermal/broadcom/Makefile
>> b/drivers/thermal/broadcom/Makefile
>> index c6f62e4..fae10ec 100644
>> --- a/drivers/thermal/broadcom/Makefile
>> +++ b/drivers/thermal/broadcom/Makefile
>> @@ -1,2 +1,3 @@
>>   obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
>> +obj-$(CONFIG_BRCMSTB_THERMAL)  += brcmstb_thermal.o
>>   obj-$(CONFIG_BCM_NS_THERMAL)  += ns-thermal.o
>> diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c
>> b/drivers/thermal/broadcom/brcmstb_thermal.c
>> new file mode 100644
>> index 000..1919f91
>> --- /dev/null
>> +++ b/drivers/thermal/broadcom/brcmstb_thermal.c
>> @@ -0,0 +1,387 @@
>>
>> +/*
>> + * Broadcom STB AVS TMON thermal sensor driver
>> + *
>> + * Copyright (c) 2015-2017 Broadcom
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#define DRV_NAME   "brcmstb_thermal"
>> +
>> +#define pr_fmt(fmt)DRV_NAME ": " fmt
>> +
>> +#include 
>> +#include 
&g

Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
On 26 September 2017 at 14:32, Scott Branden  wrote:
> Hi Markus,
>
>
> On 17-09-26 02:27 PM, Markus Mayer wrote:
>>
>> From: Brian Norris 
>>
>> The AVS TMON core provides temperature readings, a pair of configurable
>> high- and low-temperature threshold interrupts, and an emergency
>> over-temperature chip reset. The driver utilizes the first two to
>> provide temperature readings and high-temperature notifications to
>> applications. The over-temperature reset is not exposed to
>> applications; this reset threshold is critical to the system and should
>> be set with care within the bootloader.
>>
>> Applications may choose to utilize the notification mechanism, the
>> temperature reading mechanism (e.g., through polling), or both.
>>
>> Signed-off-by: Brian Norris 
>> Signed-off-by: Doug Berger 
>> Signed-off-by: Markus Mayer 
>> ---
>>   drivers/thermal/Kconfig|   2 +-
>>   drivers/thermal/broadcom/Kconfig   |   7 +
>>   drivers/thermal/broadcom/Makefile  |   1 +
>>   drivers/thermal/broadcom/brcmstb_thermal.c | 387
>> +
>>   4 files changed, 396 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 07002df..96774a7 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -408,7 +408,7 @@ config MTK_THERMAL
>>   controller present in Mediatek SoCs
>> menu "Broadcom thermal drivers"
>> -depends on ARCH_BCM || COMPILE_TEST
>> +depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
>
> No need for this additional depends.  ARCH_BCM is always defined before
> ARCH_BRCMSTB can be selected.

ARCH_BCM does not exist in arch/arm64/configs/defconfig. ARCH_BRCMSTB
does. So, we do need both or the driver won't be built on ARM64.
(After internal discussions we went with that approach rather than
defining ARCH_BCM on ARM64.)

>>   source "drivers/thermal/broadcom/Kconfig"
>>   endmenu
>>   diff --git a/drivers/thermal/broadcom/Kconfig
>> b/drivers/thermal/broadcom/Kconfig
>> index 42c098e..c106a15 100644
>> --- a/drivers/thermal/broadcom/Kconfig
>> +++ b/drivers/thermal/broadcom/Kconfig
>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>> help
>>   Support for thermal sensors on Broadcom bcm2835 SoCs.
>>   +config BRCMSTB_THERMAL
>> +   tristate "Broadcom STB AVS TMON thermal driver"
>> +   depends on ARCH_BRCMSTB || COMPILE_TEST
>> +   help
>> + Enable this driver if you have a Broadcom STB SoC and would like
>> + thermal framework support.
>> +
>>   config BCM_NS_THERMAL
>> tristate "Northstar thermal driver"
>> depends on ARCH_BCM_IPROC || COMPILE_TEST
>> diff --git a/drivers/thermal/broadcom/Makefile
>> b/drivers/thermal/broadcom/Makefile
>> index c6f62e4..fae10ec 100644
>> --- a/drivers/thermal/broadcom/Makefile
>> +++ b/drivers/thermal/broadcom/Makefile
>> @@ -1,2 +1,3 @@
>>   obj-$(CONFIG_BCM2835_THERMAL) += bcm2835_thermal.o
>> +obj-$(CONFIG_BRCMSTB_THERMAL)  += brcmstb_thermal.o
>>   obj-$(CONFIG_BCM_NS_THERMAL)  += ns-thermal.o
>> diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c
>> b/drivers/thermal/broadcom/brcmstb_thermal.c
>> new file mode 100644
>> index 000..1919f91
>> --- /dev/null
>> +++ b/drivers/thermal/broadcom/brcmstb_thermal.c
>> @@ -0,0 +1,387 @@
>>
>> +/*
>> + * Broadcom STB AVS TMON thermal sensor driver
>> + *
>> + * Copyright (c) 2015-2017 Broadcom
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#define DRV_NAME   "brcmstb_thermal"
>> +
>> +#define pr_fmt(fmt)DRV_NAME ": " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#incl

Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
On 25 September 2017 at 23:17, Zhang, Rui <rui.zh...@intel.com> wrote:
> Hi, Florian,
>
>> -Original Message-
>> From: Florian Fainelli [mailto:f.faine...@gmail.com]
>> Sent: Tuesday, September 26, 2017 12:14 PM
>> To: Zhang, Rui <rui.zh...@intel.com>; Rafal Milecki <ra...@milecki.pl>
>> Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin
>> <edubez...@gmail.com>; Rob Herring <robh...@kernel.org>; Mark Rutland
>> <mark.rutl...@arm.com>; Doug Berger <open...@gmail.com>; Brian
>> Norris <computersforpe...@gmail.com>; Gregory Fong
>> <gregory.0...@gmail.com>; Russell King <li...@armlinux.org.uk>; Catalin
>> Marinas <catalin.mari...@arm.com>; Will Deacon <will.dea...@arm.com>;
>> Arnd Bergmann <a...@arndb.de>; Olof Johansson <o...@lixom.net>;
>> Broadcom Kernel List <bcm-kernel-feedback-l...@broadcom.com>; Power
>> Management List <linux...@vger.kernel.org>; Device Tree List
>> <devicet...@vger.kernel.org>; ARM Kernel List > ker...@lists.infradead.org>; Linux Kernel Mailing List > ker...@vger.kernel.org>; Markus Mayer <mma...@broadcom.com>
>> Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
>> Importance: High
>>
>> On 09/25/2017 08:02 PM, Zhang, Rui wrote:
>> > Hi, Florian,
>> >
>> > This patch set was dropped in the last minute because of this
>> > discussion https://patchwork.kernel.org/patch/9936325/
>> > as I don’t want to rebase the patch before sending the pull request.
>>
>> Ah, you wanted to squash that patch into the initial submission?
>>
>> >
>> > I don’t think we can make it for 4.14.
>> > Eduardo will be back and pick the soc patches for 4.15.
>>
>> I assume you would want to get that particular patch squashed into a clean
>> submission targeting 4.15 now, right?
>>
> Yes. As the patch in this thread has not been in upstream yet, I'd prefer the
> fix/cleanup meld into the original patch before sending upstream.

I sent out v5 a few minutes ago. See https://lkml.org/lkml/2017/9/26/746.

Regards,
-Markus

> Thanks,
> Rui
>
>> Thanks
>>
>> >
>> > Thanks,
>> > rui
>> >
>> >
>> >
>> > -Original Message-
>> > From: Florian Fainelli [mailto:f.faine...@gmail.com]
>> > Sent: Monday, September 25, 2017 5:11 AM
>> > To: Zhang, Rui <rui.zh...@intel.com>; Rafał Miłecki <ra...@milecki.pl>
>> > Cc: Markus Mayer <c...@mmayer.net>; Eduardo Valentin
>> > <edubez...@gmail.com>; Rob Herring <robh...@kernel.org>; Mark
>> Rutland
>> > <mark.rutl...@arm.com>; Doug Berger <open...@gmail.com>; Brian
>> Norris
>> > <computersforpe...@gmail.com>; Gregory Fong
>> <gregory.0...@gmail.com>;
>> > Russell King <li...@armlinux.org.uk>; Catalin Marinas
>> > <catalin.mari...@arm.com>; Will Deacon <will.dea...@arm.com>; Arnd
>> > Bergmann <a...@arndb.de>; Olof Johansson <o...@lixom.net>;
>> Broadcom
>> > Kernel List <bcm-kernel-feedback-l...@broadcom.com>; Power
>> Management
>> > List <linux...@vger.kernel.org>; Device Tree List
>> > <devicet...@vger.kernel.org>; ARM Kernel List
>> > <linux-arm-ker...@lists.infradead.org>; Linux Kernel Mailing List
>> > <linux-kernel@vger.kernel.org>; Markus Mayer <mma...@broadcom.com>
>> > Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
>> > Importance: High
>> >
>> > Le 08/14/17 à 23:48, Zhang Rui a écrit :
>> >> On Tue, 2017-08-15 at 08:42 +0200, Rafał Miłecki wrote:
>> >>> On 2017-08-15 08:08, Zhang Rui wrote:
>> >>>>
>> >>>>>
>> >>>>> diff --git a/drivers/thermal/broadcom/Kconfig
>> >>>>> b/drivers/thermal/broadcom/Kconfig
>> >>>>> index 42c098e..c106a15 100644
>> >>>>> --- a/drivers/thermal/broadcom/Kconfig
>> >>>>> +++ b/drivers/thermal/broadcom/Kconfig
>> >>>>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>> >>>>> help
>> >>>>>   Support for thermal sensors on Broadcom bcm2835 SoCs.
>> >>>>>
>> >>>>> +config BRCMSTB_THERMAL
>> >>>>> +   tristate "Broadcom STB AVS TMON thermal driver"
>> >>>>> +   depends on ARCH_BRCMSTB || COMPILE_TEST
>> >>>>> +   help
>> >>>>> + Enable this driver if you have a Broadcom STB SoC and
>> >>>>> would like
>> >>>>> + thermal framework support.
>> >>>>> +
>> >>>> I don't understand why I got the following checkpatch warning
>> >>>>
>> >>>> WARNING: please write a paragraph that describes the config symbol
>> >>>> fully
>> >>>> #73: FILE: drivers/thermal/broadcom/Kconfig:9:
>> >>>> +config BRCMSTB_THERMAL
>> >>>>
>> >>>> I didn't see this for other Kconfig changes.
>> >>> It's because your help message is only 2 lines long (instead of 3).
>> >>>
>> >>> Some (many?) maintainers aren't pedantic about that, a common sense
>> >>> should be applied ;)
>> >>
>> >> thanks for explaining.
>> >> Patch 1 and 2 queued for next merge window.
>> >
>> > Humm, I don't see this driver in your latest 4.14 pull request to Linus, so
>> what happened here exactly? Can we expect this driver to be submitted for
>> 4.14 or we just happened to have missed this window now?
>> > --
>> > Florian
>> >
>>
>> --
>> Florian


Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
On 25 September 2017 at 23:17, Zhang, Rui  wrote:
> Hi, Florian,
>
>> -Original Message-
>> From: Florian Fainelli [mailto:f.faine...@gmail.com]
>> Sent: Tuesday, September 26, 2017 12:14 PM
>> To: Zhang, Rui ; Rafal Milecki 
>> Cc: Markus Mayer ; Eduardo Valentin
>> ; Rob Herring ; Mark Rutland
>> ; Doug Berger ; Brian
>> Norris ; Gregory Fong
>> ; Russell King ; Catalin
>> Marinas ; Will Deacon ;
>> Arnd Bergmann ; Olof Johansson ;
>> Broadcom Kernel List ; Power
>> Management List ; Device Tree List
>> ; ARM Kernel List > ker...@lists.infradead.org>; Linux Kernel Mailing List > ker...@vger.kernel.org>; Markus Mayer 
>> Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
>> Importance: High
>>
>> On 09/25/2017 08:02 PM, Zhang, Rui wrote:
>> > Hi, Florian,
>> >
>> > This patch set was dropped in the last minute because of this
>> > discussion https://patchwork.kernel.org/patch/9936325/
>> > as I don’t want to rebase the patch before sending the pull request.
>>
>> Ah, you wanted to squash that patch into the initial submission?
>>
>> >
>> > I don’t think we can make it for 4.14.
>> > Eduardo will be back and pick the soc patches for 4.15.
>>
>> I assume you would want to get that particular patch squashed into a clean
>> submission targeting 4.15 now, right?
>>
> Yes. As the patch in this thread has not been in upstream yet, I'd prefer the
> fix/cleanup meld into the original patch before sending upstream.

I sent out v5 a few minutes ago. See https://lkml.org/lkml/2017/9/26/746.

Regards,
-Markus

> Thanks,
> Rui
>
>> Thanks
>>
>> >
>> > Thanks,
>> > rui
>> >
>> >
>> >
>> > -Original Message-
>> > From: Florian Fainelli [mailto:f.faine...@gmail.com]
>> > Sent: Monday, September 25, 2017 5:11 AM
>> > To: Zhang, Rui ; Rafał Miłecki 
>> > Cc: Markus Mayer ; Eduardo Valentin
>> > ; Rob Herring ; Mark
>> Rutland
>> > ; Doug Berger ; Brian
>> Norris
>> > ; Gregory Fong
>> ;
>> > Russell King ; Catalin Marinas
>> > ; Will Deacon ; Arnd
>> > Bergmann ; Olof Johansson ;
>> Broadcom
>> > Kernel List ; Power
>> Management
>> > List ; Device Tree List
>> > ; ARM Kernel List
>> > ; Linux Kernel Mailing List
>> > ; Markus Mayer 
>> > Subject: Re: [PATCH v4 2/4] thermal: add brcmstb AVS TMON driver
>> > Importance: High
>> >
>> > Le 08/14/17 à 23:48, Zhang Rui a écrit :
>> >> On Tue, 2017-08-15 at 08:42 +0200, Rafał Miłecki wrote:
>> >>> On 2017-08-15 08:08, Zhang Rui wrote:
>> >>>>
>> >>>>>
>> >>>>> diff --git a/drivers/thermal/broadcom/Kconfig
>> >>>>> b/drivers/thermal/broadcom/Kconfig
>> >>>>> index 42c098e..c106a15 100644
>> >>>>> --- a/drivers/thermal/broadcom/Kconfig
>> >>>>> +++ b/drivers/thermal/broadcom/Kconfig
>> >>>>> @@ -6,6 +6,13 @@ config BCM2835_THERMAL
>> >>>>> help
>> >>>>>   Support for thermal sensors on Broadcom bcm2835 SoCs.
>> >>>>>
>> >>>>> +config BRCMSTB_THERMAL
>> >>>>> +   tristate "Broadcom STB AVS TMON thermal driver"
>> >>>>> +   depends on ARCH_BRCMSTB || COMPILE_TEST
>> >>>>> +   help
>> >>>>> + Enable this driver if you have a Broadcom STB SoC and
>> >>>>> would like
>> >>>>> + thermal framework support.
>> >>>>> +
>> >>>> I don't understand why I got the following checkpatch warning
>> >>>>
>> >>>> WARNING: please write a paragraph that describes the config symbol
>> >>>> fully
>> >>>> #73: FILE: drivers/thermal/broadcom/Kconfig:9:
>> >>>> +config BRCMSTB_THERMAL
>> >>>>
>> >>>> I didn't see this for other Kconfig changes.
>> >>> It's because your help message is only 2 lines long (instead of 3).
>> >>>
>> >>> Some (many?) maintainers aren't pedantic about that, a common sense
>> >>> should be applied ;)
>> >>
>> >> thanks for explaining.
>> >> Patch 1 and 2 queued for next merge window.
>> >
>> > Humm, I don't see this driver in your latest 4.14 pull request to Linus, so
>> what happened here exactly? Can we expect this driver to be submitted for
>> 4.14 or we just happened to have missed this window now?
>> > --
>> > Florian
>> >
>>
>> --
>> Florian


[PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
From: Brian Norris <computersforpe...@gmail.com>

The AVS TMON core provides temperature readings, a pair of configurable
high- and low-temperature threshold interrupts, and an emergency
over-temperature chip reset. The driver utilizes the first two to
provide temperature readings and high-temperature notifications to
applications. The over-temperature reset is not exposed to
applications; this reset threshold is critical to the system and should
be set with care within the bootloader.

Applications may choose to utilize the notification mechanism, the
temperature reading mechanism (e.g., through polling), or both.

Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Signed-off-by: Doug Berger <open...@gmail.com>
Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 drivers/thermal/Kconfig|   2 +-
 drivers/thermal/broadcom/Kconfig   |   7 +
 drivers/thermal/broadcom/Makefile  |   1 +
 drivers/thermal/broadcom/brcmstb_thermal.c | 387 +
 4 files changed, 396 insertions(+), 1 deletion(-)
 create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 07002df..96774a7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -408,7 +408,7 @@ config MTK_THERMAL
  controller present in Mediatek SoCs
 
 menu "Broadcom thermal drivers"
-depends on ARCH_BCM || COMPILE_TEST
+depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
 source "drivers/thermal/broadcom/Kconfig"
 endmenu
 
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index 42c098e..c106a15 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -6,6 +6,13 @@ config BCM2835_THERMAL
help
  Support for thermal sensors on Broadcom bcm2835 SoCs.
 
+config BRCMSTB_THERMAL
+   tristate "Broadcom STB AVS TMON thermal driver"
+   depends on ARCH_BRCMSTB || COMPILE_TEST
+   help
+ Enable this driver if you have a Broadcom STB SoC and would like
+ thermal framework support.
+
 config BCM_NS_THERMAL
tristate "Northstar thermal driver"
depends on ARCH_BCM_IPROC || COMPILE_TEST
diff --git a/drivers/thermal/broadcom/Makefile 
b/drivers/thermal/broadcom/Makefile
index c6f62e4..fae10ec 100644
--- a/drivers/thermal/broadcom/Makefile
+++ b/drivers/thermal/broadcom/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_BCM2835_THERMAL)  += bcm2835_thermal.o
+obj-$(CONFIG_BRCMSTB_THERMAL)  += brcmstb_thermal.o
 obj-$(CONFIG_BCM_NS_THERMAL)   += ns-thermal.o
diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
new file mode 100644
index 000..1919f91
--- /dev/null
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -0,0 +1,387 @@
+/*
+ * Broadcom STB AVS TMON thermal sensor driver
+ *
+ * Copyright (c) 2015-2017 Broadcom
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define DRV_NAME   "brcmstb_thermal"
+
+#define pr_fmt(fmt)DRV_NAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AVS_TMON_STATUS0x00
+ #define AVS_TMON_STATUS_valid_msk BIT(11)
+ #define AVS_TMON_STATUS_data_msk  GENMASK(10, 1)
+ #define AVS_TMON_STATUS_data_shift1
+
+#define AVS_TMON_EN_OVERTEMP_RESET 0x04
+ #define AVS_TMON_EN_OVERTEMP_RESET_mskBIT(0)
+
+#define AVS_TMON_RESET_THRESH  0x08
+ #define AVS_TMON_RESET_THRESH_msk GENMASK(10, 1)
+ #define AVS_TMON_RESET_THRESH_shift   1
+
+#define AVS_TMON_INT_IDLE_TIME 0x10
+
+#define AVS_TMON_EN_TEMP_INT_SRCS  0x14
+ #define AVS_TMON_EN_TEMP_INT_SRCS_highBIT(1)
+ #define AVS_TMON_EN_TEMP_INT_SRCS_low BIT(0)
+
+#define AVS_TMON_INT_THRESH0x18
+ #define AVS_TMON_INT_THRESH_high_msk  GENMASK(26, 17)
+ #define AVS_TMON_INT_THRESH_high_shift17
+ #define AVS_TMON_INT_THRESH_low_msk   GENMASK(10, 1)
+ #define AVS_TMON_INT_THRESH_low_shift 1
+
+#define AVS_TMON_TEMP_INT_CODE 0x1c
+#define AVS_TMON_TP_TEST_ENABLE0x20
+
+/* Default coefficients */
+#define AVS_TMON_TEMP_SLOPE-487
+#define AVS_TMON_TEMP_OFFSET   410040
+
+/* HW related temperature constants */
+#define AVS_TMON_TEMP_MAX  0x3ff
+#define AVS_TMON_TEMP_MIN  -88161
+#define AVS_TMON_TEMP_MASK  

[PATCH v5 2/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
From: Brian Norris 

The AVS TMON core provides temperature readings, a pair of configurable
high- and low-temperature threshold interrupts, and an emergency
over-temperature chip reset. The driver utilizes the first two to
provide temperature readings and high-temperature notifications to
applications. The over-temperature reset is not exposed to
applications; this reset threshold is critical to the system and should
be set with care within the bootloader.

Applications may choose to utilize the notification mechanism, the
temperature reading mechanism (e.g., through polling), or both.

Signed-off-by: Brian Norris 
Signed-off-by: Doug Berger 
Signed-off-by: Markus Mayer 
---
 drivers/thermal/Kconfig|   2 +-
 drivers/thermal/broadcom/Kconfig   |   7 +
 drivers/thermal/broadcom/Makefile  |   1 +
 drivers/thermal/broadcom/brcmstb_thermal.c | 387 +
 4 files changed, 396 insertions(+), 1 deletion(-)
 create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 07002df..96774a7 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -408,7 +408,7 @@ config MTK_THERMAL
  controller present in Mediatek SoCs
 
 menu "Broadcom thermal drivers"
-depends on ARCH_BCM || COMPILE_TEST
+depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST
 source "drivers/thermal/broadcom/Kconfig"
 endmenu
 
diff --git a/drivers/thermal/broadcom/Kconfig b/drivers/thermal/broadcom/Kconfig
index 42c098e..c106a15 100644
--- a/drivers/thermal/broadcom/Kconfig
+++ b/drivers/thermal/broadcom/Kconfig
@@ -6,6 +6,13 @@ config BCM2835_THERMAL
help
  Support for thermal sensors on Broadcom bcm2835 SoCs.
 
+config BRCMSTB_THERMAL
+   tristate "Broadcom STB AVS TMON thermal driver"
+   depends on ARCH_BRCMSTB || COMPILE_TEST
+   help
+ Enable this driver if you have a Broadcom STB SoC and would like
+ thermal framework support.
+
 config BCM_NS_THERMAL
tristate "Northstar thermal driver"
depends on ARCH_BCM_IPROC || COMPILE_TEST
diff --git a/drivers/thermal/broadcom/Makefile 
b/drivers/thermal/broadcom/Makefile
index c6f62e4..fae10ec 100644
--- a/drivers/thermal/broadcom/Makefile
+++ b/drivers/thermal/broadcom/Makefile
@@ -1,2 +1,3 @@
 obj-$(CONFIG_BCM2835_THERMAL)  += bcm2835_thermal.o
+obj-$(CONFIG_BRCMSTB_THERMAL)  += brcmstb_thermal.o
 obj-$(CONFIG_BCM_NS_THERMAL)   += ns-thermal.o
diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
new file mode 100644
index 000..1919f91
--- /dev/null
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -0,0 +1,387 @@
+/*
+ * Broadcom STB AVS TMON thermal sensor driver
+ *
+ * Copyright (c) 2015-2017 Broadcom
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define DRV_NAME   "brcmstb_thermal"
+
+#define pr_fmt(fmt)DRV_NAME ": " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AVS_TMON_STATUS0x00
+ #define AVS_TMON_STATUS_valid_msk BIT(11)
+ #define AVS_TMON_STATUS_data_msk  GENMASK(10, 1)
+ #define AVS_TMON_STATUS_data_shift1
+
+#define AVS_TMON_EN_OVERTEMP_RESET 0x04
+ #define AVS_TMON_EN_OVERTEMP_RESET_mskBIT(0)
+
+#define AVS_TMON_RESET_THRESH  0x08
+ #define AVS_TMON_RESET_THRESH_msk GENMASK(10, 1)
+ #define AVS_TMON_RESET_THRESH_shift   1
+
+#define AVS_TMON_INT_IDLE_TIME 0x10
+
+#define AVS_TMON_EN_TEMP_INT_SRCS  0x14
+ #define AVS_TMON_EN_TEMP_INT_SRCS_highBIT(1)
+ #define AVS_TMON_EN_TEMP_INT_SRCS_low BIT(0)
+
+#define AVS_TMON_INT_THRESH0x18
+ #define AVS_TMON_INT_THRESH_high_msk  GENMASK(26, 17)
+ #define AVS_TMON_INT_THRESH_high_shift17
+ #define AVS_TMON_INT_THRESH_low_msk   GENMASK(10, 1)
+ #define AVS_TMON_INT_THRESH_low_shift 1
+
+#define AVS_TMON_TEMP_INT_CODE 0x1c
+#define AVS_TMON_TP_TEST_ENABLE0x20
+
+/* Default coefficients */
+#define AVS_TMON_TEMP_SLOPE-487
+#define AVS_TMON_TEMP_OFFSET   410040
+
+/* HW related temperature constants */
+#define AVS_TMON_TEMP_MAX  0x3ff
+#define AVS_TMON_TEMP_MIN  -88161
+#define AVS_TMON_TEMP_MASK AVS_TMON_TEMP_MAX
+
+enum avs_tmon_trip_type {
+   TMON_TRIP_TYPE_LOW = 0,
+   TMON_TRIP_TYPE_HIGH,
+   TMO

[PATCH v5 1/2] Documentation: devicetree: add binding for Broadcom STB AVS TMON

2017-09-26 Thread Markus Mayer
From: Brian Norris <computersforpe...@gmail.com>

Add binding for Broadcom STB thermal.

Signed-off-by: Brian Norris <computersforpe...@gmail.com>
Acked-by: Rob Herring <r...@kernel.org>
Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 .../devicetree/bindings/thermal/brcm,avs-tmon.txt| 20 
 MAINTAINERS  |  8 
 2 files changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt

diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt 
b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
new file mode 100644
index 000..9d43553
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
@@ -0,0 +1,20 @@
+* Broadcom STB thermal management
+
+Thermal management core, provided by the AVS TMON hardware block.
+
+Required properties:
+- compatible: must be "brcm,avs-tmon" and/or "brcm,avs-tmon-bcm7445"
+- reg: address range for the AVS TMON registers
+- interrupts: temperature monitor interrupt, for high/low threshold triggers
+- interrupt-names: should be "tmon"
+- interrupt-parent: the parent interrupt controller
+
+Example:
+
+   thermal@f04d1500 {
+   compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon";
+   reg = <0xf04d1500 0x28>;
+   interrupts = <0x6>;
+   interrupt-names = "tmon";
+   interrupt-parent = <_host_l2_intc>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2281af4..46c592b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2955,6 +2955,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
 F: drivers/cpufreq/brcmstb*
 
+BROADCOM STB AVS TMON DRIVER
+M: Markus Mayer <mma...@broadcom.com>
+M: bcm-kernel-feedback-l...@broadcom.com
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
+F: drivers/thermal/broadcom/brcmstb*
+
 BROADCOM STB NAND FLASH DRIVER
 M: Brian Norris <computersforpe...@gmail.com>
 M: Kamal Dasu <kdasu.k...@gmail.com>
-- 
2.7.4



[PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This series adds the brcmstb AVS TMON driver.

The driver was originally written by Brian Norris.

Changes since v4:
- disable trip points properly when needed; there was code left-over
  from an older iteration of this driver that used long ints, which
  resulted in code that was incorrect now that we are using ints
- rebased on v4.14-rc1
- patches 3 & 4 (turning on CONFIG_BRCMSTB_THERMAL for arm/arm64) are no
  longer part of the series, because they were already picked up for 4.14

Changes since v3:
- Rebased on v4.13-rc3 to resolve conflicts in the MAINTAINERS file

Changes since v2:
- replaced calls to pr_debug() with calls to dev_dbg() [PATCH 2/4 only]
- all other patches are unchanged from v2

Changes since v1:
- Fixed wording in binding document
- Fixed lincensing to consistently mention GPL v2
- Use thermal_zone_get_slope() and thermal_zone_get_offset()
- Some minor clean-ups

Brian Norris (2):
  Documentation: devicetree: add binding for Broadcom STB AVS TMON
  thermal: add brcmstb AVS TMON driver

 .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 ++
 MAINTAINERS|   8 +
 drivers/thermal/Kconfig|   2 +-
 drivers/thermal/broadcom/Kconfig   |   7 +
 drivers/thermal/broadcom/Makefile  |   1 +
 drivers/thermal/broadcom/brcmstb_thermal.c | 387 +
 6 files changed, 424 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
 create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c

-- 
2.7.4



[PATCH v5 1/2] Documentation: devicetree: add binding for Broadcom STB AVS TMON

2017-09-26 Thread Markus Mayer
From: Brian Norris 

Add binding for Broadcom STB thermal.

Signed-off-by: Brian Norris 
Acked-by: Rob Herring 
Signed-off-by: Markus Mayer 
---
 .../devicetree/bindings/thermal/brcm,avs-tmon.txt| 20 
 MAINTAINERS  |  8 
 2 files changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt

diff --git a/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt 
b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
new file mode 100644
index 000..9d43553
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
@@ -0,0 +1,20 @@
+* Broadcom STB thermal management
+
+Thermal management core, provided by the AVS TMON hardware block.
+
+Required properties:
+- compatible: must be "brcm,avs-tmon" and/or "brcm,avs-tmon-bcm7445"
+- reg: address range for the AVS TMON registers
+- interrupts: temperature monitor interrupt, for high/low threshold triggers
+- interrupt-names: should be "tmon"
+- interrupt-parent: the parent interrupt controller
+
+Example:
+
+   thermal@f04d1500 {
+   compatible = "brcm,avs-tmon-bcm7445", "brcm,avs-tmon";
+   reg = <0xf04d1500 0x28>;
+   interrupts = <0x6>;
+   interrupt-names = "tmon";
+   interrupt-parent = <_host_l2_intc>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index 2281af4..46c592b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2955,6 +2955,14 @@ S:   Maintained
 F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt
 F: drivers/cpufreq/brcmstb*
 
+BROADCOM STB AVS TMON DRIVER
+M: Markus Mayer 
+M: bcm-kernel-feedback-l...@broadcom.com
+L: linux...@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
+F: drivers/thermal/broadcom/brcmstb*
+
 BROADCOM STB NAND FLASH DRIVER
 M: Brian Norris 
 M: Kamal Dasu 
-- 
2.7.4



[PATCH v5 0/2] thermal: add brcmstb AVS TMON driver

2017-09-26 Thread Markus Mayer
From: Markus Mayer 

This series adds the brcmstb AVS TMON driver.

The driver was originally written by Brian Norris.

Changes since v4:
- disable trip points properly when needed; there was code left-over
  from an older iteration of this driver that used long ints, which
  resulted in code that was incorrect now that we are using ints
- rebased on v4.14-rc1
- patches 3 & 4 (turning on CONFIG_BRCMSTB_THERMAL for arm/arm64) are no
  longer part of the series, because they were already picked up for 4.14

Changes since v3:
- Rebased on v4.13-rc3 to resolve conflicts in the MAINTAINERS file

Changes since v2:
- replaced calls to pr_debug() with calls to dev_dbg() [PATCH 2/4 only]
- all other patches are unchanged from v2

Changes since v1:
- Fixed wording in binding document
- Fixed lincensing to consistently mention GPL v2
- Use thermal_zone_get_slope() and thermal_zone_get_offset()
- Some minor clean-ups

Brian Norris (2):
  Documentation: devicetree: add binding for Broadcom STB AVS TMON
  thermal: add brcmstb AVS TMON driver

 .../devicetree/bindings/thermal/brcm,avs-tmon.txt  |  20 ++
 MAINTAINERS|   8 +
 drivers/thermal/Kconfig|   2 +-
 drivers/thermal/broadcom/Kconfig   |   7 +
 drivers/thermal/broadcom/Makefile  |   1 +
 drivers/thermal/broadcom/brcmstb_thermal.c | 387 +
 6 files changed, 424 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/thermal/brcm,avs-tmon.txt
 create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c

-- 
2.7.4



Re: [PATCH] thermal: brcmstb: disable trip points properly when needed

2017-09-14 Thread Markus Mayer
On 14 September 2017 at 16:19, Markus Mayer <c...@mmayer.net> wrote:
> From: Markus Mayer <mma...@broadcom.com>
>
> The code checking for low and high temperature points was still based
> on an earlier implementation of the driver. It wasn't working properly
> with the data types currently being used.
>
> We fix this by disabling the high trip point if our high temperature is
> INT_MAX and disabling the low trip point if our low temperature is -INT_MAX
> (or lower).
>
> Signed-off-by: Markus Mayer <mma...@broadcom.com>
> ---
>
> Here is my patch for the issue described. Please let me know if I should be
> squashing this into the driver patch and re-submit the entire series.

Looks like my attempt at adding this patch to the existing thread may
not have worked out so well.

Here's a link: https://marc.info/?l=linux-pm=150472721929919=2

>  drivers/thermal/broadcom/brcmstb_thermal.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
> b/drivers/thermal/broadcom/brcmstb_thermal.c
> index 87b8e7a..1919f91 100644
> --- a/drivers/thermal/broadcom/brcmstb_thermal.c
> +++ b/drivers/thermal/broadcom/brcmstb_thermal.c
> @@ -277,22 +277,23 @@ static int brcmstb_set_trips(void *data, int low, int 
> high)
>
> dev_dbg(priv->dev, "set trips %d <--> %d\n", low, high);
>
> -   if (low) {
> -   if (low > INT_MAX)
> -   low = INT_MAX;
> +   /*
> +* Disable low-temp if "low" is too small. As per thermal framework
> +* API, we use -INT_MAX rather than INT_MIN.
> +*/
> +   if (low <= -INT_MAX) {
> +   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
> +   } else {
> avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_LOW, low);
> avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 1);
> -   } else {
> -   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
> }
>
> -   if (high < ULONG_MAX) {
> -   if (high > INT_MAX)
> -   high = INT_MAX;
> +   /* Disable high-temp if "high" is too big. */
> +   if (high == INT_MAX) {
> +   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
> +   } else {
> avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_HIGH, high);
> avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 1);
> -   } else {
> -   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
> }
>
> return 0;
> --
> 2.7.4
>


Re: [PATCH] thermal: brcmstb: disable trip points properly when needed

2017-09-14 Thread Markus Mayer
On 14 September 2017 at 16:19, Markus Mayer  wrote:
> From: Markus Mayer 
>
> The code checking for low and high temperature points was still based
> on an earlier implementation of the driver. It wasn't working properly
> with the data types currently being used.
>
> We fix this by disabling the high trip point if our high temperature is
> INT_MAX and disabling the low trip point if our low temperature is -INT_MAX
> (or lower).
>
> Signed-off-by: Markus Mayer 
> ---
>
> Here is my patch for the issue described. Please let me know if I should be
> squashing this into the driver patch and re-submit the entire series.

Looks like my attempt at adding this patch to the existing thread may
not have worked out so well.

Here's a link: https://marc.info/?l=linux-pm=150472721929919=2

>  drivers/thermal/broadcom/brcmstb_thermal.c | 21 +++--
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
> b/drivers/thermal/broadcom/brcmstb_thermal.c
> index 87b8e7a..1919f91 100644
> --- a/drivers/thermal/broadcom/brcmstb_thermal.c
> +++ b/drivers/thermal/broadcom/brcmstb_thermal.c
> @@ -277,22 +277,23 @@ static int brcmstb_set_trips(void *data, int low, int 
> high)
>
> dev_dbg(priv->dev, "set trips %d <--> %d\n", low, high);
>
> -   if (low) {
> -   if (low > INT_MAX)
> -   low = INT_MAX;
> +   /*
> +* Disable low-temp if "low" is too small. As per thermal framework
> +* API, we use -INT_MAX rather than INT_MIN.
> +*/
> +   if (low <= -INT_MAX) {
> +   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
> +   } else {
> avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_LOW, low);
> avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 1);
> -   } else {
> -   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
> }
>
> -   if (high < ULONG_MAX) {
> -   if (high > INT_MAX)
> -   high = INT_MAX;
> +   /* Disable high-temp if "high" is too big. */
> +   if (high == INT_MAX) {
> +   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
> +   } else {
> avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_HIGH, high);
> avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 1);
> -   } else {
> -   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
> }
>
> return 0;
> --
> 2.7.4
>


[PATCH] thermal: brcmstb: disable trip points properly when needed

2017-09-14 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

The code checking for low and high temperature points was still based
on an earlier implementation of the driver. It wasn't working properly
with the data types currently being used.

We fix this by disabling the high trip point if our high temperature is
INT_MAX and disabling the low trip point if our low temperature is -INT_MAX
(or lower).

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---

Here is my patch for the issue described. Please let me know if I should be
squashing this into the driver patch and re-submit the entire series.

 drivers/thermal/broadcom/brcmstb_thermal.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
index 87b8e7a..1919f91 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -277,22 +277,23 @@ static int brcmstb_set_trips(void *data, int low, int 
high)
 
dev_dbg(priv->dev, "set trips %d <--> %d\n", low, high);
 
-   if (low) {
-   if (low > INT_MAX)
-   low = INT_MAX;
+   /*
+* Disable low-temp if "low" is too small. As per thermal framework
+* API, we use -INT_MAX rather than INT_MIN.
+*/
+   if (low <= -INT_MAX) {
+   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
+   } else {
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_LOW, low);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 1);
-   } else {
-   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
}
 
-   if (high < ULONG_MAX) {
-   if (high > INT_MAX)
-   high = INT_MAX;
+   /* Disable high-temp if "high" is too big. */
+   if (high == INT_MAX) {
+   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
+   } else {
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_HIGH, high);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 1);
-   } else {
-   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
}
 
return 0;
-- 
2.7.4



[PATCH] thermal: brcmstb: disable trip points properly when needed

2017-09-14 Thread Markus Mayer
From: Markus Mayer 

The code checking for low and high temperature points was still based
on an earlier implementation of the driver. It wasn't working properly
with the data types currently being used.

We fix this by disabling the high trip point if our high temperature is
INT_MAX and disabling the low trip point if our low temperature is -INT_MAX
(or lower).

Signed-off-by: Markus Mayer 
---

Here is my patch for the issue described. Please let me know if I should be
squashing this into the driver patch and re-submit the entire series.

 drivers/thermal/broadcom/brcmstb_thermal.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/thermal/broadcom/brcmstb_thermal.c 
b/drivers/thermal/broadcom/brcmstb_thermal.c
index 87b8e7a..1919f91 100644
--- a/drivers/thermal/broadcom/brcmstb_thermal.c
+++ b/drivers/thermal/broadcom/brcmstb_thermal.c
@@ -277,22 +277,23 @@ static int brcmstb_set_trips(void *data, int low, int 
high)
 
dev_dbg(priv->dev, "set trips %d <--> %d\n", low, high);
 
-   if (low) {
-   if (low > INT_MAX)
-   low = INT_MAX;
+   /*
+* Disable low-temp if "low" is too small. As per thermal framework
+* API, we use -INT_MAX rather than INT_MIN.
+*/
+   if (low <= -INT_MAX) {
+   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
+   } else {
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_LOW, low);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 1);
-   } else {
-   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_LOW, 0);
}
 
-   if (high < ULONG_MAX) {
-   if (high > INT_MAX)
-   high = INT_MAX;
+   /* Disable high-temp if "high" is too big. */
+   if (high == INT_MAX) {
+   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
+   } else {
avs_tmon_set_trip_temp(priv, TMON_TRIP_TYPE_HIGH, high);
avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 1);
-   } else {
-   avs_tmon_trip_enable(priv, TMON_TRIP_TYPE_HIGH, 0);
}
 
return 0;
-- 
2.7.4



[PATCH v3 2/2] memory: brcmstb: Add driver for DPFE

2017-08-24 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This driver allows access to DRAM properties, such as the refresh rate,
via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
used as indirect indicator of the DRAM temperature.

The driver also allows setting of the sampling interval.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 MAINTAINERS   |   8 +
 drivers/memory/Makefile   |   1 +
 drivers/memory/brcmstb_dpfe.c | 701 ++
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/memory/brcmstb_dpfe.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..dcafdca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2935,6 +2935,14 @@ S:   Maintained
 F: drivers/bcma/
 F: include/linux/bcma/
 
+BROADCOM STB DPFE DRIVER
+M: Markus Mayer <mma...@broadcom.com>
+M: bcm-kernel-feedback-l...@broadcom.com
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
+F: drivers/memory/brcmstb_dpfe.c
+
 BROADCOM SYSTEMPORT ETHERNET DRIVER
 M: Florian Fainelli <f.faine...@gmail.com>
 L: net...@vger.kernel.org
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e88097fb..9cb8b61 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -8,6 +8,7 @@ endif
 obj-$(CONFIG_ARM_PL172_MPMC)   += pl172.o
 obj-$(CONFIG_ATMEL_SDRAMC) += atmel-sdramc.o
 obj-$(CONFIG_ATMEL_EBI)+= atmel-ebi.o
+obj-$(CONFIG_ARCH_BRCMSTB) += brcmstb_dpfe.o
 obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
 obj-$(CONFIG_TI_EMIF)  += emif.o
 obj-$(CONFIG_OMAP_GPMC)+= omap-gpmc.o
diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
new file mode 100644
index 000..21242c4
--- /dev/null
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -0,0 +1,701 @@
+/*
+ * DDR PHY Front End (DPFE) driver for Broadcom set top box SoCs
+ *
+ * Copyright (c) 2017 Broadcom
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/*
+ * This driver provides access to the DPFE interface of Broadcom STB SoCs.
+ * The firmware running on the DCPU inside the DDR PHY can provide current
+ * information about the system's RAM, for instance the DRAM refresh rate.
+ * This can be used as an indirect indicator for the DRAM's temperature.
+ * Slower refresh rate means cooler RAM, higher refresh rate means hotter
+ * RAM.
+ *
+ * Throughout the driver, we use readl_relaxed() and writel_relaxed(), which
+ * already contain the appropriate le32_to_cpu()/cpu_to_le32() calls.
+ *
+ * Note regarding the loading of the firmware image: we use be32_to_cpu()
+ * and le_32_to_cpu(), so we can support the following four cases:
+ * - LE kernel + LE firmware image (the most common case)
+ * - LE kernel + BE firmware image
+ * - BE kernel + LE firmware image
+ * - BE kernel + BE firmware image
+ *
+ * The DPCU always runs in big endian mode. The firwmare image, however, can
+ * be in either format. Also, communication between host CPU and DCPU is
+ * always in little endian.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME"brcmstb-dpfe"
+#define FIRMWARE_NAME  "dpfe.bin"
+
+/* DCPU register offsets */
+#define REG_DCPU_RESET 0x0
+#define REG_TO_DCPU_MBOX   0x10
+#define REG_TO_HOST_MBOX   0x14
+
+/* Message RAM */
+#define DCPU_MSG_RAM(x)(0x100 + (x) * sizeof(u32))
+
+/* DRAM Info Offsets & Masks */
+#define DRAM_INFO_INTERVAL 0x0
+#define DRAM_INFO_MR4  0x4
+#define DRAM_INFO_ERROR0x8
+#define DRAM_INFO_MR4_MASK 0xff
+
+/* DRAM MR4 Offsets & Masks */
+#define DRAM_MR4_REFRESH   0x0 /* Refresh rate */
+#define DRAM_MR4_SR_ABORT  0x3 /* Self Refresh Abort */
+#define DRAM_MR4_PPRE  0x4 /* Post-package repair entry/exit */
+#define DRAM_MR4_TH_OFFS   0x5 /* Thermal Offset; vendor specific */
+#define DRAM_MR4_TUF   0x7 /* Temperature Update Flag */
+
+#define DRAM_MR4_REFRESH_MASK  0x7
+#define DRAM_MR4_SR_ABORT_MASK 0x1
+#define DRAM_MR4_PPRE_MASK 0x1
+#define DRAM_MR4_TH_OFFS_MASK  0x3
+#define DRAM_MR4_TUF_MASK  0x1
+
+/* DRAM Vendor Offsets & Masks */
+#define DRAM_VENDOR_MR50x0
+#define DRAM_VENDOR_MR60x4
+#define DRAM_VENDOR_MR70x8
+#define DRAM_VENDOR_MR80xc
+#define DRAM_VENDOR_ERROR  0x10
+#define DRAM_VENDOR_MASK   0xff
+
+/* Reset register bits & masks */
+#define DCPU_RESET_SHIFT   0x0
+#define DCPU_RESET_MASK0x1
+#define DCPU_CLK_DISABLE_SHIFT 0x2
+
+/* DCPU return codes */
+#define DCPU_RET_ERROR_BIT BIT(31)
+#define DCPU_RET_SUCCESS   0x1
+#define DCPU_RET_ERR_HEADER 

[PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

2017-08-24 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).

Signed-off-by: Markus Mayer <mma...@broadcom.com>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt 
b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
new file mode 100644
index 000..82d923e
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
@@ -0,0 +1,27 @@
+DDR PHY Front End (DPFE) for Broadcom STB
+=
+
+DPFE and the DPFE firmware provide an interface for the host CPU to
+communicate with the DCPU, which resides inside the DDR PHY.
+
+There are three memory regions for interacting with the DCPU. These are
+specified in a single reg property.
+
+Required properties:
+  - compatible: must be "brcm,bcm7271-dpfe-cpu", "brcm,bcm7268-dpfe-cpu"
+or "brcm,dpfe-cpu"
+  - reg: must reference three register ranges
+  - start address and length of the DCPU register space
+  - start address and length of the DCPU data memory space
+  - start address and length of the DCPU instruction memory space
+  - reg-names: must contain "dpfe-cpu", "dpfe-dmem", and "dpfe-imem";
+they must be in the same order as the register declarations
+
+Example:
+   dpfe_cpu0: dpfe-cpu@f1132000 {
+   compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu";
+   reg =  <0xf1132000 0x180
+   0xf1134000 0x1000
+   0xf1138000 0x4000>;
+   reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem";
+   };
-- 
2.7.4



[PATCH v3 2/2] memory: brcmstb: Add driver for DPFE

2017-08-24 Thread Markus Mayer
From: Markus Mayer 

This driver allows access to DRAM properties, such as the refresh rate,
via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
used as indirect indicator of the DRAM temperature.

The driver also allows setting of the sampling interval.

Signed-off-by: Markus Mayer 
---
 MAINTAINERS   |   8 +
 drivers/memory/Makefile   |   1 +
 drivers/memory/brcmstb_dpfe.c | 701 ++
 3 files changed, 710 insertions(+)
 create mode 100644 drivers/memory/brcmstb_dpfe.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..dcafdca 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2935,6 +2935,14 @@ S:   Maintained
 F: drivers/bcma/
 F: include/linux/bcma/
 
+BROADCOM STB DPFE DRIVER
+M: Markus Mayer 
+M: bcm-kernel-feedback-l...@broadcom.com
+L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
+F: drivers/memory/brcmstb_dpfe.c
+
 BROADCOM SYSTEMPORT ETHERNET DRIVER
 M: Florian Fainelli 
 L: net...@vger.kernel.org
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index e88097fb..9cb8b61 100644
--- a/drivers/memory/Makefile
+++ b/drivers/memory/Makefile
@@ -8,6 +8,7 @@ endif
 obj-$(CONFIG_ARM_PL172_MPMC)   += pl172.o
 obj-$(CONFIG_ATMEL_SDRAMC) += atmel-sdramc.o
 obj-$(CONFIG_ATMEL_EBI)+= atmel-ebi.o
+obj-$(CONFIG_ARCH_BRCMSTB) += brcmstb_dpfe.o
 obj-$(CONFIG_TI_AEMIF) += ti-aemif.o
 obj-$(CONFIG_TI_EMIF)  += emif.o
 obj-$(CONFIG_OMAP_GPMC)+= omap-gpmc.o
diff --git a/drivers/memory/brcmstb_dpfe.c b/drivers/memory/brcmstb_dpfe.c
new file mode 100644
index 000..21242c4
--- /dev/null
+++ b/drivers/memory/brcmstb_dpfe.c
@@ -0,0 +1,701 @@
+/*
+ * DDR PHY Front End (DPFE) driver for Broadcom set top box SoCs
+ *
+ * Copyright (c) 2017 Broadcom
+ *
+ * Released under the GPLv2 only.
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/*
+ * This driver provides access to the DPFE interface of Broadcom STB SoCs.
+ * The firmware running on the DCPU inside the DDR PHY can provide current
+ * information about the system's RAM, for instance the DRAM refresh rate.
+ * This can be used as an indirect indicator for the DRAM's temperature.
+ * Slower refresh rate means cooler RAM, higher refresh rate means hotter
+ * RAM.
+ *
+ * Throughout the driver, we use readl_relaxed() and writel_relaxed(), which
+ * already contain the appropriate le32_to_cpu()/cpu_to_le32() calls.
+ *
+ * Note regarding the loading of the firmware image: we use be32_to_cpu()
+ * and le_32_to_cpu(), so we can support the following four cases:
+ * - LE kernel + LE firmware image (the most common case)
+ * - LE kernel + BE firmware image
+ * - BE kernel + LE firmware image
+ * - BE kernel + BE firmware image
+ *
+ * The DPCU always runs in big endian mode. The firwmare image, however, can
+ * be in either format. Also, communication between host CPU and DCPU is
+ * always in little endian.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRVNAME"brcmstb-dpfe"
+#define FIRMWARE_NAME  "dpfe.bin"
+
+/* DCPU register offsets */
+#define REG_DCPU_RESET 0x0
+#define REG_TO_DCPU_MBOX   0x10
+#define REG_TO_HOST_MBOX   0x14
+
+/* Message RAM */
+#define DCPU_MSG_RAM(x)(0x100 + (x) * sizeof(u32))
+
+/* DRAM Info Offsets & Masks */
+#define DRAM_INFO_INTERVAL 0x0
+#define DRAM_INFO_MR4  0x4
+#define DRAM_INFO_ERROR0x8
+#define DRAM_INFO_MR4_MASK 0xff
+
+/* DRAM MR4 Offsets & Masks */
+#define DRAM_MR4_REFRESH   0x0 /* Refresh rate */
+#define DRAM_MR4_SR_ABORT  0x3 /* Self Refresh Abort */
+#define DRAM_MR4_PPRE  0x4 /* Post-package repair entry/exit */
+#define DRAM_MR4_TH_OFFS   0x5 /* Thermal Offset; vendor specific */
+#define DRAM_MR4_TUF   0x7 /* Temperature Update Flag */
+
+#define DRAM_MR4_REFRESH_MASK  0x7
+#define DRAM_MR4_SR_ABORT_MASK 0x1
+#define DRAM_MR4_PPRE_MASK 0x1
+#define DRAM_MR4_TH_OFFS_MASK  0x3
+#define DRAM_MR4_TUF_MASK  0x1
+
+/* DRAM Vendor Offsets & Masks */
+#define DRAM_VENDOR_MR50x0
+#define DRAM_VENDOR_MR60x4
+#define DRAM_VENDOR_MR70x8
+#define DRAM_VENDOR_MR80xc
+#define DRAM_VENDOR_ERROR  0x10
+#define DRAM_VENDOR_MASK   0xff
+
+/* Reset register bits & masks */
+#define DCPU_RESET_SHIFT   0x0
+#define DCPU_RESET_MASK0x1
+#define DCPU_CLK_DISABLE_SHIFT 0x2
+
+/* DCPU return codes */
+#define DCPU_RET_ERROR_BIT BIT(31)
+#define DCPU_RET_SUCCESS   0x1
+#define DCPU_RET_ERR_HEADER(DCPU_RET_ERROR_BIT | BIT(0))
+#define DCPU_RET_ERR_INVAL (DCPU_RET_ERROR_BIT | BIT(1))
+#define DCPU_RET_ERR_C

[PATCH v3 1/2] dt/bindings: Add bindings for Broadcom STB DRAM Sensors

2017-08-24 Thread Markus Mayer
From: Markus Mayer 

Provide bindings for the Broadcom STB DDR PHY Front End (DPFE).

Signed-off-by: Markus Mayer 
Acked-by: Rob Herring 
---
 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  | 27 ++
 1 file changed, 27 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt

diff --git 
a/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt 
b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
new file mode 100644
index 000..82d923e
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
@@ -0,0 +1,27 @@
+DDR PHY Front End (DPFE) for Broadcom STB
+=
+
+DPFE and the DPFE firmware provide an interface for the host CPU to
+communicate with the DCPU, which resides inside the DDR PHY.
+
+There are three memory regions for interacting with the DCPU. These are
+specified in a single reg property.
+
+Required properties:
+  - compatible: must be "brcm,bcm7271-dpfe-cpu", "brcm,bcm7268-dpfe-cpu"
+or "brcm,dpfe-cpu"
+  - reg: must reference three register ranges
+  - start address and length of the DCPU register space
+  - start address and length of the DCPU data memory space
+  - start address and length of the DCPU instruction memory space
+  - reg-names: must contain "dpfe-cpu", "dpfe-dmem", and "dpfe-imem";
+they must be in the same order as the register declarations
+
+Example:
+   dpfe_cpu0: dpfe-cpu@f1132000 {
+   compatible = "brcm,bcm7271-dpfe-cpu", "brcm,dpfe-cpu";
+   reg =  <0xf1132000 0x180
+   0xf1134000 0x1000
+   0xf1138000 0x4000>;
+   reg-names = "dpfe-cpu", "dpfe-dmem", "dpfe-imem";
+   };
-- 
2.7.4



[PATCH v3 0/2] SoC driver for Broadcom STB DPFE

2017-08-24 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

This series introduces a driver to interact with the Broadcom STB DDR
PHY Front End (DPFE), specifically to communicate with the DCPU that is
part of the DDR PHY and which is running its own firmware.

The DCPU provides information such as DRAM refresh rate, which can be
used as indirect indicator for the DRAM temperature (the higher the
refresh rate, the hotter the RAM).

The series was previously submitted as HWMON driver[1]. It has been
removed from that subsystem, because it doesn't provide any standard
HWMON data due to hardware design properties, and is now implemented as
SoC driver.

Changes since v2:
  - moved driver from drivers/soc/bcm/brcmstb to drivers/memory
  - renamed the driver from dpfe.c to brcmstb_dpfe.c
  - added le32_to_cpu() in a few places (where be32_to_cpu() calls
already existed)
  - added a little blurb what the le32_to_cpu()/be32_to_cpu() business
is all about

Changes since v1:
  - binding simplified to use one node with three memory regions
instead of three nodes with one region
  - no longer part of the HWMON subsystem
  - better error handling and error reporting to userland
  - uses [readl|writel]_relaxed() directly, since there is no need for
wrappers doing endian conversion
  - re-download firmware upon "resume"
  - minor changes to improve clarity

[1] https://lkml.org/lkml/2017/4/18/640

Markus Mayer (2):
  dt/bindings: Add bindings for Broadcom STB DRAM Sensors
  memory: brcmstb: Add driver for DPFE

 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  |  27 +
 MAINTAINERS|   8 +
 drivers/memory/Makefile|   1 +
 drivers/memory/brcmstb_dpfe.c  | 701 +
 4 files changed, 737 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
 create mode 100644 drivers/memory/brcmstb_dpfe.c

-- 
2.7.4



[PATCH v3 0/2] SoC driver for Broadcom STB DPFE

2017-08-24 Thread Markus Mayer
From: Markus Mayer 

This series introduces a driver to interact with the Broadcom STB DDR
PHY Front End (DPFE), specifically to communicate with the DCPU that is
part of the DDR PHY and which is running its own firmware.

The DCPU provides information such as DRAM refresh rate, which can be
used as indirect indicator for the DRAM temperature (the higher the
refresh rate, the hotter the RAM).

The series was previously submitted as HWMON driver[1]. It has been
removed from that subsystem, because it doesn't provide any standard
HWMON data due to hardware design properties, and is now implemented as
SoC driver.

Changes since v2:
  - moved driver from drivers/soc/bcm/brcmstb to drivers/memory
  - renamed the driver from dpfe.c to brcmstb_dpfe.c
  - added le32_to_cpu() in a few places (where be32_to_cpu() calls
already existed)
  - added a little blurb what the le32_to_cpu()/be32_to_cpu() business
is all about

Changes since v1:
  - binding simplified to use one node with three memory regions
instead of three nodes with one region
  - no longer part of the HWMON subsystem
  - better error handling and error reporting to userland
  - uses [readl|writel]_relaxed() directly, since there is no need for
wrappers doing endian conversion
  - re-download firmware upon "resume"
  - minor changes to improve clarity

[1] https://lkml.org/lkml/2017/4/18/640

Markus Mayer (2):
  dt/bindings: Add bindings for Broadcom STB DRAM Sensors
  memory: brcmstb: Add driver for DPFE

 .../bindings/memory-controllers/brcm,dpfe-cpu.txt  |  27 +
 MAINTAINERS|   8 +
 drivers/memory/Makefile|   1 +
 drivers/memory/brcmstb_dpfe.c  | 701 +
 4 files changed, 737 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/memory-controllers/brcm,dpfe-cpu.txt
 create mode 100644 drivers/memory/brcmstb_dpfe.c

-- 
2.7.4



[PATCH v4 4/4] arm64: defconfig: add CONFIG_BRCMSTB_THERMAL

2017-08-09 Thread Markus Mayer
From: Markus Mayer <mma...@broadcom.com>

Turn on CONFIG_BRCMSTB_THERMAL as module.

Signed-off-by: Markus Mayer <mma...@broadcom.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 6c7d147..2449064 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -304,6 +304,7 @@ CONFIG_SENSORS_INA2XX=m
 CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
 CONFIG_CPU_THERMAL=y
 CONFIG_THERMAL_EMULATION=y
+CONFIG_BRCMSTB_THERMAL=m
 CONFIG_EXYNOS_THERMAL=y
 CONFIG_ROCKCHIP_THERMAL=m
 CONFIG_WATCHDOG=y
-- 
2.7.4



  1   2   3   4   5   6   7   >