Re: NFS Caching broken in 4.19.37

[Timo Rothenpieler]

On 26.02.2021 16:40, Anton Ivanov wrote:
These are two different clients, then what you see is possible on NFS 
with client side caching. If you have multiple clients reading/writing 
to the same files you usually need to tune the caching options and/or 
use locking. I suspect that if you leave it for a while (until the cache 
expires) it will sort itself out.


Yes, letting the client sit for just a few minutes (without interacting 
with file or directory in question) gets it back in sync with the server.


In my test-case it is just one client, it missed a file deletion and 
nothing short of an unmount and remount fixes that. I have waited for 30 
mins+. It does not seem to refresh or expire. I also see the opposite 
behavior - the bug shows up on 4.x up to at least 5.4. I do not see it 
on 5.10.


Yeah, that's indeed different, though still looks somewhat similar.
Makes me wonder if what fixed that issue is what's causing mine.

The primarily broken use case here is users starting their SLURM jobs, 
and then observing them via "tail -f slurm.out", which has worked 
perfectly fine in the past, prior to the update from 5.4 to 5.10.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: NFS Caching broken in 4.19.37

[Timo Rothenpieler]

I think I can reproduce this, or something that at least looks very 
similar to this, on 5.10. Namely on 5.10.17 (On both Client and Server).


We are running slurm, and since a while now (coincides with updating 
from 5.4 to 5.10, but a whole bunch of other stuff was updated at the 
same time, so it took me a while to correlate this) the logs it writes 
have been truncated, but only while they're being observed on the 
client, using tail -f or something like that.


Looks like this then:

On Server:

store01 /srv/export/home/users/timo/TestRun # ls -l slurm-41101.out
-rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out
store01 /srv/export/home/users/timo/TestRun # wc -l slurm-41101.out
61 slurm-41101.out


On Client:

timo@login01 ~/TestRun $ ls -l slurm-41101.out
-rw-r--r-- 1 timo timo 1931 Feb 26 15:46 slurm-41101.out
timo@login01 ~/TestRun $ wc -l slurm-41101.out
24 slurm-41101.out


See https://gist.github.com/BtbN/b9eb4fc08ccc53bb20087bce0bf9f826 for 
the respective file-contents.


If I run the same test job, wait until its done, and then look at its 
slurm.out file, it matches between NFS Client and Server.
If I tail -f the slurm.out on an NFS client, the file stops getting 
updated on the client, but keeps getting more logs written to it on the 
NFS server.


The slurm.out file is being written to by another NFS client, which is 
running on one of the compute nodes of the system. It's being reads from 
a login node.




Timo


On 21.02.2021 16:53, Anton Ivanov wrote:

Client side. This seems to be an entirely client side issue.

A variety of kernels on the clients starting from 4.9 and up to 5.10 
using 4.19 servers. I have observed it on a 4.9 client versus 4.9 server 
earlier.


4.9 fails, 4.19 fails, 5.2 fails, 5.4 fails, 5.10 works.

At present the server is at 4.19.67 in all tests.

Linux jain 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) 
x86_64 GNU/Linux


I can set-up a couple of alternative servers during the week, but so far 
everything is pointing towards a client fs cache issue, not a server one.


Brgds,






smime.p7s
Description: S/MIME Cryptographic Signature

[PATCH] platform/x86: acer-wmi: add automatic keyboard background light toggle key as KEY_LIGHTS_TOGGLE

[Timo Witte]

Got a dmesg message on my AMD Renoir based Acer laptop:
"acer_wmi: Unknown key number - 0x84" when toggling keyboard
background light

Signed-off-by: Timo Witte 
---
 drivers/platform/x86/acer-wmi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 60c18f21588d..87797f785d6a 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -111,6 +111,7 @@ static const struct key_entry acer_wmi_keymap[] __initconst 
= {
{KE_KEY, 0x64, {KEY_SWITCHVIDEOMODE} }, /* Display Switch */
{KE_IGNORE, 0x81, {KEY_SLEEP} },
{KE_KEY, 0x82, {KEY_TOUCHPAD_TOGGLE} }, /* Touch Pad Toggle */
+   {KE_IGNORE, 0x84, {KEY_LIGHTS_TOGGLE} }, /* Automatic Keyboard 
background light toggle */
{KE_KEY, KEY_TOUCHPAD_ON, {KEY_TOUCHPAD_ON} },
{KE_KEY, KEY_TOUCHPAD_OFF, {KEY_TOUCHPAD_OFF} },
{KE_IGNORE, 0x83, {KEY_TOUCHPAD_TOGGLE} },
-- 
2.27.0

[PATCH] perf core: apply calculated padding to PERF_SAMPLE_RAW output

[Timo Beckers]

Zero the amount of padding bytes determined in perf_prepare_sample().
This prevents garbage being read from the ring buffer after it has wrapped
the page boundary at least once.

Signed-off-by: Timo Beckers 
---
 kernel/events/core.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 80cf996a7f19..d4e0b003ece0 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6807,8 +6807,16 @@ void perf_output_sample(struct perf_output_handle 
*handle,
break;
frag = frag->next;
} while (1);
-   if (frag->pad)
-   __output_skip(handle, NULL, frag->pad);
+   /*
+* The padding value is determined in
+* perf_prepare_sample() and is not
+* expected to exceed u64.
+*/
+   if (frag->pad) {
+   u64 zero = 0;
+
+   __output_copy(handle, , frag->pad);
+   }
} else {
struct {
u32 size;
-- 
2.26.2

Re: [ALSA patch] [PATCH] ALSA: pcm: Enable MMAP status and control for ARMv7 and ARMv8

[Timo Wischer]

Hello all,

it would be great if someone from Renesas or someone else could 
acknowledge the patch.
I think it is a good improvement especially when using ALSA plugins like 
dmix.


Feel free to forward if you know someone who is aware of the cache 
coherency of ARM architectures.


Best regards
*Timo Wischer*
Engineering Software Multimedia (ADITG/ESM)

Tel. +49 5121 49 6938
On 4/17/19 11:40 AM, Takashi Iwai wrote:

On Wed, 17 Apr 2019 11:30:10 +0200,
Timo Wischer wrote:

On 4/17/19 11:21, Takashi Iwai wrote:

On Wed, 17 Apr 2019 10:46:11 +0200,
 wrote:

From: Timo Wischer 

Since ARMv7 hardware cache coherence is supported.
"The SCU maintains coherency between the individual data caches in the
Cortex-A5 MPCore processor using a variation of the MOESI protocol" [1].

Therefore this patch enables the MMAP access to the status and control
structures. This avoids HWSYYNC ioctl calls and therefore lowers the CPU
usage.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0434c/
BABJECBF.html

Interesting...  I thought it would never work properly on ARM.
If it really works like that, I'd happily apply the change.
But I'd like to hear a confirmation from ARM people before merging
such an intensive change.

Hi Takashi,

do I need to send this patch to any other mailing list or do you think
some corresponding guy is already on the lists I have used?

Well, maybe we need to ping ARM people if no one on the lists you
Cc'ed give comments.  Let's see.


Takashi



thanks,

Takashi


Signed-off-by: Timo Wischer 
---
   sound/core/pcm_native.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 1d84529..b8019ef 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3225,7 +3225,8 @@ static __poll_t snd_pcm_poll(struct file *file, 
poll_table *wait)
* Only on coherent architectures, we can mmap the status and the control 
records
* for effcient data transfer.  On others, we have to use HWSYNC ioctl...
*/
-#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA)
+#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) || \
+   (defined(CONFIG_ARM) && defined(CONFIG_CPU_V7)) || defined(CONFIG_ARM64)
   /*
* mmap status record
*/
--
2.7.4

___
Patch mailing list
pa...@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/patch

Re: [ALSA patch] [PATCH] ALSA: pcm: Enable MMAP status and control for ARMv7 and ARMv8

[Timo Wischer]

On 4/17/19 11:21, Takashi Iwai wrote:

On Wed, 17 Apr 2019 10:46:11 +0200,
 wrote:

From: Timo Wischer 

Since ARMv7 hardware cache coherence is supported.
"The SCU maintains coherency between the individual data caches in the
Cortex-A5 MPCore processor using a variation of the MOESI protocol" [1].

Therefore this patch enables the MMAP access to the status and control
structures. This avoids HWSYYNC ioctl calls and therefore lowers the CPU
usage.

[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0434c/
BABJECBF.html

Interesting...  I thought it would never work properly on ARM.
If it really works like that, I'd happily apply the change.
But I'd like to hear a confirmation from ARM people before merging
such an intensive change.


Hi Takashi,

do I need to send this patch to any other mailing list or do you think 
some corresponding guy is already on the lists I have used?





thanks,

Takashi


Signed-off-by: Timo Wischer 
---
  sound/core/pcm_native.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 1d84529..b8019ef 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -3225,7 +3225,8 @@ static __poll_t snd_pcm_poll(struct file *file, 
poll_table *wait)
   * Only on coherent architectures, we can mmap the status and the control 
records
   * for effcient data transfer.  On others, we have to use HWSYNC ioctl...
   */
-#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA)
+#if defined(CONFIG_X86) || defined(CONFIG_PPC) || defined(CONFIG_ALPHA) || \
+   (defined(CONFIG_ARM) && defined(CONFIG_CPU_V7)) || defined(CONFIG_ARM64)
  /*
   * mmap status record
   */
--
2.7.4

___
Patch mailing list
pa...@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/patch

Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()

[Timo Wischer]

On 3/27/19 10:38, Takashi Iwai wrote:

On Wed, 27 Mar 2019 10:26:56 +0100,
Timo Wischer wrote:

On 3/27/19 10:11, Takashi Iwai wrote:

On Wed, 27 Mar 2019 09:34:40 +0100,
Timo Wischer wrote:

On 3/26/19 17:00, Takashi Iwai wrote:

On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:

On 3/26/19 15:23, Takashi Iwai wrote:

On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:

On 3/26/19 09:35, Takashi Iwai wrote:

On Tue, 26 Mar 2019 08:49:33 +0100,
 wrote:
 From: Timo Wischer 
 snd_pcm_link() can be called by the user as long
as the device is not
yet started. Therefore currently a driver which wants to iterate 
over
the linked substreams has to do this at the start trigger. But the 
start
trigger should not block for a long time. Therefore there is no 
callback
which can be used to iterate over the linked substreams without 
delaying
the start trigger.
This patch introduces a new callback function which will be called 
after
the linked substream list was updated by snd_pcm_link(). This 
callback
function is allowed to block for a longer time without interfering 
the
synchronized start up of linked substreams.
 Signed-off-by: Timo Wischer

 Well, the idea appears interesting, but I'm afraid
that the
implementation is still racy.  The place you're calling the new
callback isn't protected, hence the stream can be triggered while
calling it.  That is, even during operating your loopback link_changed
callback, another thread is able to start the stream.
Hi Takashi,

As far as I got you mean the following scenario:

  * snd_pcm_link() is called for a HW sound card
  + loopback_snd_timer_link_changed()

The start may happen at this point.

In this case the last link status will be used and aloop will print a
warning "Another sound timer was requested but at least one device is
already running...".

Without this patch set a similar issue already exists. When calling
snd_pcm_start() before snd_pcm_link() was done the additional device
linked by the snd_pcm_link() will not be started.
Therefore the application has already to take care about the order of
the calls.

Yes, but it doesn't matter for now, just because other drivers do care
the PCM links only for trigger callback.  Now you're trying to add
something new but in an incomplete manner.


  + loopback_snd_timer_open()
  + spin_lock_irqsave(>cable->lock, flags);
  * snd_pcm_start() called for aloop sound card
  + loopback_trigger()
  + spin_lock(>lock) -> has to wait till 
loopback_snd_timer_open()
calls spin_unlock_irqrestore()

So far snd_pcm_start() has to wait for loopback_snd_timer_open().

  * loopback_snd_timer_open() will continue with
  + dpcm->cable->snd_timer.instance = NULL;
  + spin_unlock_irqrestore()
  * loopback_trigger() can enter the lock
  + loopback_snd_timer_start() will fail with -EINVAL due to
(loopback_trigger == NULL)

At least this will not result into memory corruption due to race or any other
wired behavior.

I don't expect the memory corruption, but my point is that dealing
with linked streams is still tricky.  It was considered for the
lightweight coupled start/stop operation, and something intensively
depending on the linked status was out of the original design...


But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw)
is only called by the application calling snd_pcm_start(aloop)
because the same aloop device cannot be opened by multiple applications at the
same time.

Do you see an use case where one application would call snd_pcm_start() in
parallel with snd_pcm_link() (somehow configuring the device)?

It's not about the actual application usages but rather against the
malicious attacks.  Especially aloop is a virtual device that is
available allover the places, it may be deployed / attacked easily.

The attack we are identifying here can only be done by the application
opening the aloop device.
An application allowed to open the aloop device is anyway able to
manipulate the audio streaming.

Right, and if it such a racy access may lead to a driver misbehavior,
it's a big concern.  The proposed callback usage is racy, so some
other implementation might be broken easily in future.


Or do you see an attack which would influence any other device/stream
not opened by this application?


May be we should add an additional synchronization mechanism in pcm_native.c
to avoid call of snd_pcm_link() in parallel with snd_pcm_start().

If it really matters...  Honestly speaking, I'm not fully convinced
whether we want to deal with this using the PCM link mechanism.

What's the motivation for using the linked streams at the first place?
That'

Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()

[Timo Wischer]

On 3/27/19 10:11, Takashi Iwai wrote:

On Wed, 27 Mar 2019 09:34:40 +0100,
Timo Wischer wrote:

On 3/26/19 17:00, Takashi Iwai wrote:

On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:

On 3/26/19 15:23, Takashi Iwai wrote:

On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:

On 3/26/19 09:35, Takashi Iwai wrote:

   On Tue, 26 Mar 2019 08:49:33 +0100,
wrote:
From: Timo Wischer 
snd_pcm_link() can be called by the user as long
as the device is not
   yet started. Therefore currently a driver which wants to iterate over
   the linked substreams has to do this at the start trigger. But the 
start
   trigger should not block for a long time. Therefore there is no 
callback
   which can be used to iterate over the linked substreams without 
delaying
   the start trigger.
   This patch introduces a new callback function which will be called 
after
   the linked substream list was updated by snd_pcm_link(). This 
callback
   function is allowed to block for a longer time without interfering 
the
   synchronized start up of linked substreams.
Signed-off-by: Timo Wischer

Well, the idea appears interesting, but I'm afraid
that the
   implementation is still racy.  The place you're calling the new
   callback isn't protected, hence the stream can be triggered while
   calling it.  That is, even during operating your loopback link_changed
   callback, another thread is able to start the stream.
   Hi Takashi,

As far as I got you mean the following scenario:

 * snd_pcm_link() is called for a HW sound card
 + loopback_snd_timer_link_changed()

The start may happen at this point.

In this case the last link status will be used and aloop will print a
warning "Another sound timer was requested but at least one device is
already running...".

Without this patch set a similar issue already exists. When calling
snd_pcm_start() before snd_pcm_link() was done the additional device
linked by the snd_pcm_link() will not be started.
Therefore the application has already to take care about the order of
the calls.

Yes, but it doesn't matter for now, just because other drivers do care
the PCM links only for trigger callback.  Now you're trying to add
something new but in an incomplete manner.


 + loopback_snd_timer_open()
 + spin_lock_irqsave(>cable->lock, flags);
 * snd_pcm_start() called for aloop sound card
 + loopback_trigger()
 + spin_lock(>lock) -> has to wait till loopback_snd_timer_open()
   calls spin_unlock_irqrestore()

So far snd_pcm_start() has to wait for loopback_snd_timer_open().

 * loopback_snd_timer_open() will continue with
 + dpcm->cable->snd_timer.instance = NULL;
 + spin_unlock_irqrestore()
 * loopback_trigger() can enter the lock
 + loopback_snd_timer_start() will fail with -EINVAL due to
   (loopback_trigger == NULL)

At least this will not result into memory corruption due to race or any other
wired behavior.

I don't expect the memory corruption, but my point is that dealing
with linked streams is still tricky.  It was considered for the
lightweight coupled start/stop operation, and something intensively
depending on the linked status was out of the original design...


But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw)
is only called by the application calling snd_pcm_start(aloop)
because the same aloop device cannot be opened by multiple applications at the
same time.

Do you see an use case where one application would call snd_pcm_start() in
parallel with snd_pcm_link() (somehow configuring the device)?

It's not about the actual application usages but rather against the
malicious attacks.  Especially aloop is a virtual device that is
available allover the places, it may be deployed / attacked easily.

The attack we are identifying here can only be done by the application
opening the aloop device.
An application allowed to open the aloop device is anyway able to
manipulate the audio streaming.

Right, and if it such a racy access may lead to a driver misbehavior,
it's a big concern.  The proposed callback usage is racy, so some
other implementation might be broken easily in future.


Or do you see an attack which would influence any other device/stream
not opened by this application?


May be we should add an additional synchronization mechanism in pcm_native.c
to avoid call of snd_pcm_link() in parallel with snd_pcm_start().

If it really matters...  Honestly speaking, I'm not fully convinced
whether we want to deal with this using the PCM link mechanism.

What's the motivation for using the linked streams at the first place?
That's one of the biggest missing piece in the whole picture.

In general when the user uses snd_pcm_link() it expects that the
linked devi

Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()

[Timo Wischer]

On 3/26/19 17:00, Takashi Iwai wrote:

On Tue, 26 Mar 2019 16:16:54 +0100,
Timo Wischer wrote:

On 3/26/19 15:23, Takashi Iwai wrote:

On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:

On 3/26/19 09:35, Takashi Iwai wrote:

  On Tue, 26 Mar 2019 08:49:33 +0100,
   wrote:
   From: Timo Wischer 
   snd_pcm_link() can be called by the user as long
as the device is not
  yet started. Therefore currently a driver which wants to iterate over
  the linked substreams has to do this at the start trigger. But the 
start
  trigger should not block for a long time. Therefore there is no 
callback
  which can be used to iterate over the linked substreams without 
delaying
  the start trigger.
  This patch introduces a new callback function which will be called 
after
  the linked substream list was updated by snd_pcm_link(). This callback
  function is allowed to block for a longer time without interfering the
  synchronized start up of linked substreams.
   Signed-off-by: Timo Wischer

   Well, the idea appears interesting, but I'm afraid
that the
  implementation is still racy.  The place you're calling the new
  callback isn't protected, hence the stream can be triggered while
  calling it.  That is, even during operating your loopback link_changed
  callback, another thread is able to start the stream.
  Hi Takashi,

As far as I got you mean the following scenario:

* snd_pcm_link() is called for a HW sound card
+ loopback_snd_timer_link_changed()

The start may happen at this point.

In this case the last link status will be used and aloop will print a
warning "Another sound timer was requested but at least one device is
already running...".

Without this patch set a similar issue already exists. When calling
snd_pcm_start() before snd_pcm_link() was done the additional device
linked by the snd_pcm_link() will not be started.
Therefore the application has already to take care about the order of
the calls.

Yes, but it doesn't matter for now, just because other drivers do care
the PCM links only for trigger callback.  Now you're trying to add
something new but in an incomplete manner.


+ loopback_snd_timer_open()
+ spin_lock_irqsave(>cable->lock, flags);
* snd_pcm_start() called for aloop sound card
+ loopback_trigger()
+ spin_lock(>lock) -> has to wait till loopback_snd_timer_open()
  calls spin_unlock_irqrestore()

So far snd_pcm_start() has to wait for loopback_snd_timer_open().

* loopback_snd_timer_open() will continue with
+ dpcm->cable->snd_timer.instance = NULL;
+ spin_unlock_irqrestore()
* loopback_trigger() can enter the lock
+ loopback_snd_timer_start() will fail with -EINVAL due to
  (loopback_trigger == NULL)

At least this will not result into memory corruption due to race or any other
wired behavior.

I don't expect the memory corruption, but my point is that dealing
with linked streams is still tricky.  It was considered for the
lightweight coupled start/stop operation, and something intensively
depending on the linked status was out of the original design...


But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw)
is only called by the application calling snd_pcm_start(aloop)
because the same aloop device cannot be opened by multiple applications at the
same time.

Do you see an use case where one application would call snd_pcm_start() in
parallel with snd_pcm_link() (somehow configuring the device)?

It's not about the actual application usages but rather against the
malicious attacks.  Especially aloop is a virtual device that is
available allover the places, it may be deployed / attacked easily.

The attack we are identifying here can only be done by the application
opening the aloop device.
An application allowed to open the aloop device is anyway able to
manipulate the audio streaming.

Right, and if it such a racy access may lead to a driver misbehavior,
it's a big concern.  The proposed callback usage is racy, so some
other implementation might be broken easily in future.


Or do you see an attack which would influence any other device/stream
not opened by this application?


May be we should add an additional synchronization mechanism in pcm_native.c
to avoid call of snd_pcm_link() in parallel with snd_pcm_start().

If it really matters...  Honestly speaking, I'm not fully convinced
whether we want to deal with this using the PCM link mechanism.

What's the motivation for using the linked streams at the first place?
That's one of the biggest missing piece in the whole picture.

In general when the user uses snd_pcm_link() it expects that the
linked devices are somehow synchronized.
Any applications already using snd_pcm_link() do not need to be
adapted to use the new feature of alo

Re: [PATCH 09/10] ALSA: pcm: Add snd_pcm_ops for snd_pcm_link()

[Timo Wischer]

On 3/26/19 15:23, Takashi Iwai wrote:

On Tue, 26 Mar 2019 12:25:37 +0100,
Timo Wischer wrote:

On 3/26/19 09:35, Takashi Iwai wrote:

 On Tue, 26 Mar 2019 08:49:33 +0100,
  wrote:
 
 From: Timo Wischer 
 
 snd_pcm_link() can be called by the user as long as the device is not

 yet started. Therefore currently a driver which wants to iterate over
 the linked substreams has to do this at the start trigger. But the 
start
 trigger should not block for a long time. Therefore there is no 
callback
 which can be used to iterate over the linked substreams without 
delaying
 the start trigger.
 This patch introduces a new callback function which will be called 
after
 the linked substream list was updated by snd_pcm_link(). This callback
 function is allowed to block for a longer time without interfering the
 synchronized start up of linked substreams.
 
 Signed-off-by: Timo Wischer 
 
 Well, the idea appears interesting, but I'm afraid that the

 implementation is still racy.  The place you're calling the new
 callback isn't protected, hence the stream can be triggered while
 calling it.  That is, even during operating your loopback link_changed
 callback, another thread is able to start the stream.
 
Hi Takashi,


As far as I got you mean the following scenario:

   * snd_pcm_link() is called for a HW sound card
   + loopback_snd_timer_link_changed()

The start may happen at this point.


In this case the last link status will be used and aloop will print a 
warning "Another sound timer was requested but at least one device is 
already running...".


Without this patch set a similar issue already exists. When calling 
snd_pcm_start() before snd_pcm_link() was done the additional device 
linked by the snd_pcm_link() will not be started.
Therefore the application has already to take care about the order of 
the calls.





   + loopback_snd_timer_open()
   + spin_lock_irqsave(>cable->lock, flags);
   * snd_pcm_start() called for aloop sound card
   + loopback_trigger()
   + spin_lock(>lock) -> has to wait till loopback_snd_timer_open()
 calls spin_unlock_irqrestore()

So far snd_pcm_start() has to wait for loopback_snd_timer_open().

   * loopback_snd_timer_open() will continue with
   + dpcm->cable->snd_timer.instance = NULL;
   + spin_unlock_irqrestore()
   * loopback_trigger() can enter the lock
   + loopback_snd_timer_start() will fail with -EINVAL due to
 (loopback_trigger == NULL)

At least this will not result into memory corruption due to race or any other
wired behavior.

I don't expect the memory corruption, but my point is that dealing
with linked streams is still tricky.  It was considered for the
lightweight coupled start/stop operation, and something intensively
depending on the linked status was out of the original design...


But my expectation is that snd_pcm_link(hw, aloop) or snd_pcm_link(aloop, hw)
is only called by the application calling snd_pcm_start(aloop)
because the same aloop device cannot be opened by multiple applications at the
same time.

Do you see an use case where one application would call snd_pcm_start() in
parallel with snd_pcm_link() (somehow configuring the device)?

It's not about the actual application usages but rather against the
malicious attacks.  Especially aloop is a virtual device that is
available allover the places, it may be deployed / attacked easily.
The attack we are identifying here can only be done by the application 
opening the aloop device.
An application allowed to open the aloop device is anyway able to 
manipulate the audio streaming.
Or do you see an attack which would influence any other device/stream 
not opened by this application?



May be we should add an additional synchronization mechanism in pcm_native.c
to avoid call of snd_pcm_link() in parallel with snd_pcm_start().

If it really matters...  Honestly speaking, I'm not fully convinced
whether we want to deal with this using the PCM link mechanism.

What's the motivation for using the linked streams at the first place?
That's one of the biggest missing piece in the whole picture.
In general when the user uses snd_pcm_link() it expects that the linked 
devices are somehow synchronized.
Any applications already using snd_pcm_link() do not need to be adapted 
to use the new feature of aloop (for example JACK or ALSA multi plugin)


But when linking a HW sound card and aloop without this patch set, both 
devices will be started in sync but
the snd_pcm_period_eleapsed() calls of the different devices will drift. 
To avoid this the aloop plugin can automatically use the right timer.
If this feature is not implemented the user has to use snd_pcm_link() to 
trigger snd_pcm_start() in sync but also has to configure the aloop 
plugin to use the right sound timer.
May be

Re: [PATCH 04/10] ALSA: aloop: Use always spin_lock_irqsave() for cable->lock

[Timo Wischer]

On 3/25/19 17:58, Takashi Iwai wrote:

On Mon, 25 Mar 2019 17:40:23 +0100,
Timo Wischer wrote:

Best regards
Timo Wischer
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6938
On 3/25/19 17:07, Takashi Iwai wrote:

 On Mon, 25 Mar 2019 17:00:38 +0100,
  wrote:
 
 From: Timo Wischer 
 
 to allow the usage of timer callbacks from interrupt context.

 For example the sound timer.
 
 The trigger callback is already irq-disabled.  And, open/close must

 not be irq-disabled OTOH.  So these changes must be superfluous.
 
Hello Takashi,


could you explain why open/close must not be irq-disabled?

The open/close callbacks get called always in sleepable context where
you can use mutex & co gracefully.  The only non-sleepable (atomic)
context is pointer and trigger callbacks.  So it's safe to use
spin_lock() without irq in these callbacks.
OTOH, the rest (open, close,hw_params, hw_free, prepare) callbacks are
always sleepable, hence it's safe to use spin_lock_irq() (not
save/restore) variant.

When a driver declares as non-atomic via PCM flag, all callbacks
become sleepable, but this isn't the case for aloop driver.


I see a potential deadlock in case of free_cable() uses only spin_lock()
instead of spin_lock_irqsave().
For example the following will be executed:

loopback_close()
free_cable()
spin_lock(>cable->lock)

Which spin_lock() call?  The free_cable() calls spin_lock_irq().


Interrupted by jiffies timer IRQ before calling spin_unlock()

loopback_jiffies_timer_function()
spin_lock_irqsave(>cable->lock)

DEADLOCK due to dpcm->cable->lock is already locked

Do you also see this deadlock or do you see any reason why this could not
happen?

If spin_lock_irq() is used in free_cable(), it must be OK.


Takashi

Thanks for the detailed explanation.

@all:
Please simple ignore this patch.

Best regards

Timo





Best regards

Timo

 thanks,
 
 Takashi


     Signed-off-by: Timo Wischer 
 ---
  sound/drivers/aloop.c | 33 +++--
  1 file changed, 19 insertions(+), 14 deletions(-)
 
 diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c

 index 11e8ed6..c6217c4 100644
 --- a/sound/drivers/aloop.c
 +++ b/sound/drivers/aloop.c
 @@ -272,6 +272,7 @@ static int loopback_trigger(struct 
snd_pcm_substream *substream, int cmd)
   struct loopback_pcm *dpcm = runtime->private_data;
   struct loopback_cable *cable = dpcm->cable;
   int err = 0, stream = 1 << substream->stream;
 + unsigned long flags;
  
   switch (cmd) {

   case SNDRV_PCM_TRIGGER_START:
 @@ -281,39 +282,39 @@ static int loopback_trigger(struct 
snd_pcm_substream *substream, int cmd)
 dpcm->last_jiffies = jiffies;
 dpcm->pcm_rate_shift = 0;
 dpcm->last_drift = 0;
 -   spin_lock(>lock);
 +   spin_lock_irqsave(>lock, flags);
 cable->running |= stream;
 cable->pause &= ~stream;
 err = loopback_timer_start(dpcm);
 -   spin_unlock(>lock);
 +   spin_unlock_irqrestore(>lock, 
flags);
 if (substream->stream == 
SNDRV_PCM_STREAM_PLAYBACK)
   
loopback_active_notify(dpcm);
 break;
   case SNDRV_PCM_TRIGGER_STOP:
 -   spin_lock(>lock);
 +   spin_lock_irqsave(>lock, flags);
 cable->running &= ~stream;
 cable->pause &= ~stream;
 err = loopback_timer_stop(dpcm);
 -   spin_unlock(>lock);
 +   spin_unlock_irqrestore(>lock, 
flags);
 if (substream->stream == 
SNDRV_PCM_STREAM_PLAYBACK)
   
loopback_active_notify(dpcm);
 break;
   case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
   case SNDRV_PCM_TRIGGER_SUSPEND:
 -   spin_lock(>lock);
 +   spin_lock_irqsave(>lock, flags);
 cable->pause |= stream;
 err = loopback_timer_stop(dpcm);
 -   spin_unlock(>lock);
 +

Re: [RFC PATCH v2 6/7] i2c: tegra-bpmp: convert to use new atomic callbacks

[Timo Alho]

On 2.3.2019 15.47, Wolfram Sang wrote:

The driver did handle this internally, convert it to use the new
callbacks.

Signed-off-by: Wolfram Sang 
---
  drivers/i2c/busses/i2c-tegra-bpmp.c | 27 ++-
  1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-tegra-bpmp.c 
b/drivers/i2c/busses/i2c-tegra-bpmp.c
index f6cd35d0a2ac..02b78ba5b23b 100644
--- a/drivers/i2c/busses/i2c-tegra-bpmp.c
+++ b/drivers/i2c/busses/i2c-tegra-bpmp.c
@@ -207,7 +207,8 @@ static int tegra_bpmp_i2c_msg_len_check(struct i2c_msg 
*msgs, unsigned int num)
  
  static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c *i2c,

   struct mrq_i2c_request *request,
-  struct mrq_i2c_response *response)
+  struct mrq_i2c_response *response,
+  bool atomic)
  {
struct tegra_bpmp_message msg;
int err;
@@ -222,7 +223,7 @@ static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c 
*i2c,
msg.rx.data = response;
msg.rx.size = sizeof(*response);
  
-	if (irqs_disabled())

+   if (atomic)
err = tegra_bpmp_transfer_atomic(i2c->bpmp, );
else
err = tegra_bpmp_transfer(i2c->bpmp, );
@@ -230,8 +231,9 @@ static int tegra_bpmp_i2c_msg_xfer(struct tegra_bpmp_i2c 
*i2c,
return err;
  }
  
-static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,

-  struct i2c_msg *msgs, int num)
+static int tegra_bpmp_i2c_xfer_common(struct i2c_adapter *adapter,
+ struct i2c_msg *msgs, int num,
+ bool atomic)
  {
struct tegra_bpmp_i2c *i2c = i2c_get_adapdata(adapter);
struct mrq_i2c_response response;
@@ -253,7 +255,7 @@ static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
return err;
}
  
-	err = tegra_bpmp_i2c_msg_xfer(i2c, , );

+   err = tegra_bpmp_i2c_msg_xfer(i2c, , , atomic);
if (err < 0) {
dev_err(i2c->dev, "failed to transfer message: %d\n", err);
return err;
@@ -268,6 +270,20 @@ static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,
return num;
  }
  
+static int tegra_bpmp_i2c_xfer(struct i2c_adapter *adapter,

+  struct i2c_msg *msgs, int num)
+
+{
+   return tegra_bpmp_i2c_xfer_common(adapter, msgs, num, false);
+}
+
+static int tegra_bpmp_i2c_xfer_atomic(struct i2c_adapter *adapter,
+ struct i2c_msg *msgs, int num)
+
+{
+   return tegra_bpmp_i2c_xfer_common(adapter, msgs, num, true);
+}
+
  static u32 tegra_bpmp_i2c_func(struct i2c_adapter *adapter)
  {
return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_10BIT_ADDR |
@@ -276,6 +292,7 @@ static u32 tegra_bpmp_i2c_func(struct i2c_adapter *adapter)
  
  static const struct i2c_algorithm tegra_bpmp_i2c_algo = {

.master_xfer = tegra_bpmp_i2c_xfer,
+   .master_xfer_atomic = tegra_bpmp_i2c_xfer_atomic,
.functionality = tegra_bpmp_i2c_func,
  };
  



Looks good to me.

Reviewed-by: Timo Alho 

Re: [PATCH] firmware: tegra-bpmp: mark PM function as __maybe_unused

[Timo Alho]

On 03.10.2018 11:26, Jonathan Hunter wrote:


On 02/10/18 22:21, Arnd Bergmann wrote:

The newly added tegra_bpmp_resume function is unused when CONFIG_PM
is disabled:

drivers/firmware/tegra/bpmp.c:847:12: error: 'tegra_bpmp_resume' defined but 
not used [-Werror=unused-function]
  static int tegra_bpmp_resume(struct device *dev)

Mark it as __maybe_unused to avoid the warning and let the compiler
drop it silently.

Fixes: cd40f6ff124c ("firmware: tegra: bpmp: Implement suspend/resume support")
Signed-off-by: Arnd Bergmann 
---
  drivers/firmware/tegra/bpmp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 41448ba78be9..a3d5b518c10e 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -844,7 +844,7 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
return err;
  }
  
-static int tegra_bpmp_resume(struct device *dev)

+static int __maybe_unused tegra_bpmp_resume(struct device *dev)
  {
struct tegra_bpmp *bpmp = dev_get_drvdata(dev);
unsigned int i;


Arnd, is this seen with 32-bit ARM configs?

Timo, does it make sense to make BPMP dependent on ARCH_TEGRA_186_SOC
and ARCH_TEGRA_194_SOC instead of just ARCH_TEGRA? For 64-bit Tegra we
have a dependency on PM so this should not be seen for 64-bit Tegra.


Jon, there will be eventually a BPMP driver for ARCH_TEGRA_210_SOC as 
well. So it is probably more appropriate to make BPMP dependent on ARM64 
& ARCH_TEGRA.


-Timo

Re: [PATCH] firmware: tegra-bpmp: mark PM function as __maybe_unused

[Timo Alho]

On 03.10.2018 11:26, Jonathan Hunter wrote:


On 02/10/18 22:21, Arnd Bergmann wrote:

The newly added tegra_bpmp_resume function is unused when CONFIG_PM
is disabled:

drivers/firmware/tegra/bpmp.c:847:12: error: 'tegra_bpmp_resume' defined but 
not used [-Werror=unused-function]
  static int tegra_bpmp_resume(struct device *dev)

Mark it as __maybe_unused to avoid the warning and let the compiler
drop it silently.

Fixes: cd40f6ff124c ("firmware: tegra: bpmp: Implement suspend/resume support")
Signed-off-by: Arnd Bergmann 
---
  drivers/firmware/tegra/bpmp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 41448ba78be9..a3d5b518c10e 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -844,7 +844,7 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
return err;
  }
  
-static int tegra_bpmp_resume(struct device *dev)

+static int __maybe_unused tegra_bpmp_resume(struct device *dev)
  {
struct tegra_bpmp *bpmp = dev_get_drvdata(dev);
unsigned int i;


Arnd, is this seen with 32-bit ARM configs?

Timo, does it make sense to make BPMP dependent on ARCH_TEGRA_186_SOC
and ARCH_TEGRA_194_SOC instead of just ARCH_TEGRA? For 64-bit Tegra we
have a dependency on PM so this should not be seen for 64-bit Tegra.


Jon, there will be eventually a BPMP driver for ARCH_TEGRA_210_SOC as 
well. So it is probably more appropriate to make BPMP dependent on ARM64 
& ARCH_TEGRA.


-Timo

Re: [PATCH V2] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Jon, thanks for reviewing

On 03.10.2017 13:55, Jonathan Hunter wrote:

+static int create_debugfs_mirror(struct tegra_bpmp *bpmp, void *buf,
+size_t bufsize, struct dentry *root)
+{
+   struct seqbuf seqbuf;
+   int err;
+
+   bpmp->debugfs_mirror = debugfs_create_dir("debug", root);
+   if (!bpmp->debugfs_mirror)
+   return -ENOMEM;


Is this extra level needed? Do you plan to have other sub-directories
under the main bpmp directory?


Yes, the downstream driver has few files under main directory (e.g. 
'ping' to check that firmware is alive, or 'tag' to read the firmware 
version).


BR,
Timo

Re: [PATCH V2] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Jon, thanks for reviewing

On 03.10.2017 13:55, Jonathan Hunter wrote:

+static int create_debugfs_mirror(struct tegra_bpmp *bpmp, void *buf,
+size_t bufsize, struct dentry *root)
+{
+   struct seqbuf seqbuf;
+   int err;
+
+   bpmp->debugfs_mirror = debugfs_create_dir("debug", root);
+   if (!bpmp->debugfs_mirror)
+   return -ENOMEM;


Is this extra level needed? Do you plan to have other sub-directories
under the main bpmp directory?


Yes, the downstream driver has few files under main directory (e.g. 
'ping' to check that firmware is alive, or 'tag' to read the firmware 
version).


BR,
Timo

[PATCH V2] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).

Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
Changes in v2:
 - Address Jonathan's review feedback
  * restructure error printing and what error codes passed to higher
layers
  * don't use IS_ERR_OR_NULL()
  * avoid overwriting last-character of filename in one corner case
(name length = 255)
  
 drivers/firmware/tegra/Makefile   |   4 +-
 drivers/firmware/tegra/bpmp.c |   4 +
 drivers/firmware/tegra/bpmp_debugfs.c | 444 ++
 include/soc/tegra/bpmp.h  |  14 ++
 4 files changed, 465 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c

diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP)   += bpmp.o
+tegra-bpmp-y   = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS)  += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP)   += tegra-bpmp.o
 obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..d29c593 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,10 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
+   err = tegra_bpmp_init_debugfs(bpmp);
+   if (err < 0)
+   dev_err(>dev, "debugfs initialization failed: %d\n", err);
+
return 0;
 
 free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c 
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..f7f6a0a
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,444 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct seqbuf {
+   char *buf;
+   size_t pos;
+   size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+   seqbuf->buf = buf;
+   seqbuf->size = size;
+   seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+   nbyte = min(nbyte, seqbuf_avail(seqbuf));
+   memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+   seqbuf->pos += nbyte;
+   return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+   int err;
+
+   err = seqbuf_read(seqbuf, v, 4);
+   *v = le32_to_cpu(*v);
+   return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+   *str = seqbuf->buf + seqbuf->pos;
+   seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+   seqbuf->pos++;
+   return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+   seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+   const struct file *file, char *buf, int size)
+{
+   char root_path_buf[512];
+   const char *root_path;
+   const char *filename;
+   size_t root_len;
+
+   root_path = dentry_path(bpmp->debugfs_mirror, root_path_buf,
+   sizeof(root_path_buf));
+   if (IS_ERR(root_path))
+   return NULL;
+
+   root_len =

[PATCH V2] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).

Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.

Signed-off-by: Timo Alho 
---
Changes in v2:
 - Address Jonathan's review feedback
  * restructure error printing and what error codes passed to higher
layers
  * don't use IS_ERR_OR_NULL()
  * avoid overwriting last-character of filename in one corner case
(name length = 255)
  
 drivers/firmware/tegra/Makefile   |   4 +-
 drivers/firmware/tegra/bpmp.c |   4 +
 drivers/firmware/tegra/bpmp_debugfs.c | 444 ++
 include/soc/tegra/bpmp.h  |  14 ++
 4 files changed, 465 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c

diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP)   += bpmp.o
+tegra-bpmp-y   = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS)  += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP)   += tegra-bpmp.o
 obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..d29c593 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,10 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
+   err = tegra_bpmp_init_debugfs(bpmp);
+   if (err < 0)
+   dev_err(>dev, "debugfs initialization failed: %d\n", err);
+
return 0;
 
 free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c 
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..f7f6a0a
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,444 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct seqbuf {
+   char *buf;
+   size_t pos;
+   size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+   seqbuf->buf = buf;
+   seqbuf->size = size;
+   seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+   nbyte = min(nbyte, seqbuf_avail(seqbuf));
+   memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+   seqbuf->pos += nbyte;
+   return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+   int err;
+
+   err = seqbuf_read(seqbuf, v, 4);
+   *v = le32_to_cpu(*v);
+   return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+   *str = seqbuf->buf + seqbuf->pos;
+   seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+   seqbuf->pos++;
+   return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+   seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+   const struct file *file, char *buf, int size)
+{
+   char root_path_buf[512];
+   const char *root_path;
+   const char *filename;
+   size_t root_len;
+
+   root_path = dentry_path(bpmp->debugfs_mirror, root_path_buf,
+   sizeof(root_path_buf));
+   if (IS_ERR(root_path))
+   return NULL;
+
+   root_len = strlen(root_pa

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

On 29.09.2017 17:53, Jonathan Hunter wrote:


On 29/09/17 14:46, Timo Alho wrote:

Hi Jon,

On 21.09.2017 14:21, Jonathan Hunter wrote:



On 07/09/17 10:31, Timo Alho wrote:

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
   drivers/clk/tegra/clk-bpmp.c | 15 ++-
   1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
   struct {
   void *data;
   size_t size;
+    int ret;
   } rx;
   };
   @@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
   struct mrq_clk_request request;
   struct tegra_bpmp_message msg;
   void *req = 
+    int err;
     memset(, 0, sizeof(request));
   request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
   msg.rx.data = clk->rx.data;
   msg.rx.size = clk->rx.size;
   -    return tegra_bpmp_transfer(bpmp, );
+    err = tegra_bpmp_transfer(bpmp, );
+    if (err < 0)
+    return err;
+    else if (msg.rx.ret < 0)
+    return -EINVAL;


I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?


The error codes are not 1:1 match with Linux. Unfortunately, printing
message for debug is not either viable as during clock probing we are
expecting many of the calls to return -BPMP_EINVAL to indicate that
particular clock ID is unused.


OK. Could it return other errors other than BPMP_EINVAL? I am just
wondering if we need to differentiate between unused and an actual
error? Maybe that is not possible here?


Other error codes are possible (though they are not explicitly 
documented in abi header). It's not easy to differentiate the error code 
at this level: -BPMP_EINVAL is "expected" condition with 
CMD_CLK_GET_ALL_INFO, whereas -BPMP_EINVAL is true error on other commands.

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

On 29.09.2017 17:53, Jonathan Hunter wrote:


On 29/09/17 14:46, Timo Alho wrote:

Hi Jon,

On 21.09.2017 14:21, Jonathan Hunter wrote:



On 07/09/17 10:31, Timo Alho wrote:

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho 
---
   drivers/clk/tegra/clk-bpmp.c | 15 ++-
   1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
   struct {
   void *data;
   size_t size;
+    int ret;
   } rx;
   };
   @@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
   struct mrq_clk_request request;
   struct tegra_bpmp_message msg;
   void *req = 
+    int err;
     memset(, 0, sizeof(request));
   request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct
tegra_bpmp *bpmp,
   msg.rx.data = clk->rx.data;
   msg.rx.size = clk->rx.size;
   -    return tegra_bpmp_transfer(bpmp, );
+    err = tegra_bpmp_transfer(bpmp, );
+    if (err < 0)
+    return err;
+    else if (msg.rx.ret < 0)
+    return -EINVAL;


I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?


The error codes are not 1:1 match with Linux. Unfortunately, printing
message for debug is not either viable as during clock probing we are
expecting many of the calls to return -BPMP_EINVAL to indicate that
particular clock ID is unused.


OK. Could it return other errors other than BPMP_EINVAL? I am just
wondering if we need to differentiate between unused and an actual
error? Maybe that is not possible here?


Other error codes are possible (though they are not explicitly 
documented in abi header). It's not easy to differentiate the error code 
at this level: -BPMP_EINVAL is "expected" condition with 
CMD_CLK_GET_ALL_INFO, whereas -BPMP_EINVAL is true error on other commands.

Re: [PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

On 29.09.2017 17:58, Jonathan Hunter wrote:

+static int bpmp_populate_dir(struct tegra_bpmp *bpmp, struct seqbuf
*seqbuf,
+ struct dentry *parent, uint32_t depth)


Do we need to use uint32_t here?


+{
+    int err;
+    uint32_t d, t;


And here?


It's part of the BPMP ABI that the data passed is 32 bit unsigned
integer. I wanted to emphasise that with the choice of integer type. Or
did you mean why I did not use u32?


Yes why not just u32?



No other reason than just a personal bias to use standard C99 integer 
types. The downstream driver was using a mix of both so wanted to 
standardize to just one.

Re: [PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

On 29.09.2017 17:58, Jonathan Hunter wrote:

+static int bpmp_populate_dir(struct tegra_bpmp *bpmp, struct seqbuf
*seqbuf,
+ struct dentry *parent, uint32_t depth)


Do we need to use uint32_t here?


+{
+    int err;
+    uint32_t d, t;


And here?


It's part of the BPMP ABI that the data passed is 32 bit unsigned
integer. I wanted to emphasise that with the choice of integer type. Or
did you mean why I did not use u32?


Yes why not just u32?



No other reason than just a personal bias to use standard C99 integer 
types. The downstream driver was using a mix of both so wanted to 
standardize to just one.

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

Hi Jon,

On 21.09.2017 14:21, Jonathan Hunter wrote:



On 07/09/17 10:31, Timo Alho wrote:

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
  drivers/clk/tegra/clk-bpmp.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
  };
  
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,

struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = 
+   int err;
  
  	memset(, 0, sizeof(request));

request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
  
-	return tegra_bpmp_transfer(bpmp, );

+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;


I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?


The error codes are not 1:1 match with Linux. Unfortunately, printing 
message for debug is not either viable as during clock probing we are 
expecting many of the calls to return -BPMP_EINVAL to indicate that 
particular clock ID is unused.


-Timo

Re: [PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

Hi Jon,

On 21.09.2017 14:21, Jonathan Hunter wrote:



On 07/09/17 10:31, Timo Alho wrote:

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho 
---
  drivers/clk/tegra/clk-bpmp.c | 15 ++-
  1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
  };
  
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,

struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = 
+   int err;
  
  	memset(, 0, sizeof(request));

request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
  
-	return tegra_bpmp_transfer(bpmp, );

+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;


I assume that the error codes returned do not correlated to the Linux
error codes here. Is that correct? If not we could just return the
actual error code. Otherwise would it be useful to print a message with
the bpmp error code for debug?


The error codes are not 1:1 match with Linux. Unfortunately, printing 
message for debug is not either viable as during clock probing we are 
expecting many of the calls to return -BPMP_EINVAL to indicate that 
particular clock ID is unused.


-Timo

Re: [PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

p, seqbuf, dentry, depth+1);
+   if (err < 0)
+   return err;


Do we need to remove the directory created here? Or is that handled by
the recursive removal below?


Recursive removal will take care of it.


+static int mrq_is_supported(struct tegra_bpmp *bpmp, unsigned int mrq)
+{
+   struct mrq_query_abi_request req = { .mrq = cpu_to_le32(mrq) };
+   struct mrq_query_abi_response resp;
+   struct tegra_bpmp_message msg = {
+   .mrq = MRQ_QUERY_ABI,
+   .tx = {
+   .data = ,
+   .size = sizeof(req),
+   },
+   .rx = {
+   .data = ,
+   .size = sizeof(resp),
+   },
+   };
+   int ret;
+
+   ret = tegra_bpmp_transfer(bpmp, );
+   /* something went wrong; assume not supported */
+   if (ret < 0)


dev_warn?


Will add.


+
+   virt = dma_alloc_coherent(bpmp->dev, sz, ,
+ GFP_KERNEL | GFP_DMA32);
+   if (!virt) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   ret = mrq_debugfs_dumpdir(bpmp, phys, sz, );
+   if (ret < 0)
+   goto free;
+
+   ret = create_debugfs_mirror(bpmp, virt, nbytes, root);
+   if (ret < 0)
+   dev_err(bpmp->dev, "create_debugfs_mirror failed (%d)\n", ret);
+
+free:
+   dma_free_coherent(bpmp->dev, sz, virt, phys);
+out:
+   if (ret < 0)
+   debugfs_remove(root);


Should we have a generic warning message here? Looks like it could fail
silently.


I'll add a warning to call site (bpmp.c) if this fails.

-Timo

Re: [PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

p, seqbuf, dentry, depth+1);
+   if (err < 0)
+   return err;


Do we need to remove the directory created here? Or is that handled by
the recursive removal below?


Recursive removal will take care of it.


+static int mrq_is_supported(struct tegra_bpmp *bpmp, unsigned int mrq)
+{
+   struct mrq_query_abi_request req = { .mrq = cpu_to_le32(mrq) };
+   struct mrq_query_abi_response resp;
+   struct tegra_bpmp_message msg = {
+   .mrq = MRQ_QUERY_ABI,
+   .tx = {
+   .data = ,
+   .size = sizeof(req),
+   },
+   .rx = {
+   .data = ,
+   .size = sizeof(resp),
+   },
+   };
+   int ret;
+
+   ret = tegra_bpmp_transfer(bpmp, );
+   /* something went wrong; assume not supported */
+   if (ret < 0)


dev_warn?


Will add.


+
+   virt = dma_alloc_coherent(bpmp->dev, sz, ,
+ GFP_KERNEL | GFP_DMA32);
+   if (!virt) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   ret = mrq_debugfs_dumpdir(bpmp, phys, sz, );
+   if (ret < 0)
+   goto free;
+
+   ret = create_debugfs_mirror(bpmp, virt, nbytes, root);
+   if (ret < 0)
+   dev_err(bpmp->dev, "create_debugfs_mirror failed (%d)\n", ret);
+
+free:
+   dma_free_coherent(bpmp->dev, sz, virt, phys);
+out:
+   if (ret < 0)
+   debugfs_remove(root);


Should we have a generic warning message here? Looks like it could fail
silently.


I'll add a warning to call site (bpmp.c) if this fails.

-Timo

[PATCH 3/4] reset: tegra: check BPMP response return code

[Timo Alho]

Add checks for return code in BPMP response message.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/reset/tegra/reset-bpmp.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/tegra/reset-bpmp.c b/drivers/reset/tegra/reset-bpmp.c
index 5daf2ee..fac2db6 100644
--- a/drivers/reset/tegra/reset-bpmp.c
+++ b/drivers/reset/tegra/reset-bpmp.c
@@ -23,6 +23,7 @@ static int tegra_bpmp_reset_common(struct 
reset_controller_dev *rstc,
struct tegra_bpmp *bpmp = to_tegra_bpmp(rstc);
struct mrq_reset_request request;
struct tegra_bpmp_message msg;
+   int err;
 
memset(, 0, sizeof(request));
request.cmd = command;
@@ -33,7 +34,13 @@ static int tegra_bpmp_reset_common(struct 
reset_controller_dev *rstc,
msg.tx.data = 
msg.tx.size = sizeof(request);
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_reset_module(struct reset_controller_dev *rstc,
-- 
2.7.4

[PATCH 3/4] reset: tegra: check BPMP response return code

[Timo Alho]

Add checks for return code in BPMP response message.

Signed-off-by: Timo Alho 
---
 drivers/reset/tegra/reset-bpmp.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/tegra/reset-bpmp.c b/drivers/reset/tegra/reset-bpmp.c
index 5daf2ee..fac2db6 100644
--- a/drivers/reset/tegra/reset-bpmp.c
+++ b/drivers/reset/tegra/reset-bpmp.c
@@ -23,6 +23,7 @@ static int tegra_bpmp_reset_common(struct 
reset_controller_dev *rstc,
struct tegra_bpmp *bpmp = to_tegra_bpmp(rstc);
struct mrq_reset_request request;
struct tegra_bpmp_message msg;
+   int err;
 
memset(, 0, sizeof(request));
request.cmd = command;
@@ -33,7 +34,13 @@ static int tegra_bpmp_reset_common(struct 
reset_controller_dev *rstc,
msg.tx.data = 
msg.tx.size = sizeof(request);
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_reset_module(struct reset_controller_dev *rstc,
-- 
2.7.4

[PATCH 1/4] firmware: tegra: propagate error code to caller

[Timo Alho]

Response messages from Tegra BPMP firmware contain an error return
code as the first word of payload. The error code is used to indicate
incorrectly formatted request message or use of non-existing resource
(clk, reset, powergate) identifier. Current implementation of
tegra_bpmp_transfer() ignores this code and does not pass it to
caller. Fix this by adding an extra struct member to
tegra_bpmp_message and populate that with return code.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/firmware/tegra/bpmp.c | 22 --
 include/soc/tegra/bpmp.h  |  1 +
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..33683b5 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -194,16 +194,24 @@ static int tegra_bpmp_wait_master_free(struct 
tegra_bpmp_channel *channel)
 }
 
 static ssize_t __tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
-void *data, size_t size)
+void *data, size_t size, int *ret)
 {
+   int err;
+
if (data && size > 0)
memcpy(data, channel->ib->data, size);
 
-   return tegra_ivc_read_advance(channel->ivc);
+   err = tegra_ivc_read_advance(channel->ivc);
+   if (err < 0)
+   return err;
+
+   *ret = channel->ib->code;
+
+   return 0;
 }
 
 static ssize_t tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
-  void *data, size_t size)
+  void *data, size_t size, int *ret)
 {
struct tegra_bpmp *bpmp = channel->bpmp;
unsigned long flags;
@@ -217,7 +225,7 @@ static ssize_t tegra_bpmp_channel_read(struct 
tegra_bpmp_channel *channel,
}
 
spin_lock_irqsave(>lock, flags);
-   err = __tegra_bpmp_channel_read(channel, data, size);
+   err = __tegra_bpmp_channel_read(channel, data, size, ret);
clear_bit(index, bpmp->threaded.allocated);
spin_unlock_irqrestore(>lock, flags);
 
@@ -337,7 +345,8 @@ int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp,
if (err < 0)
return err;
 
-   return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+   return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+>rx.ret);
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_transfer_atomic);
 
@@ -371,7 +380,8 @@ int tegra_bpmp_transfer(struct tegra_bpmp *bpmp,
if (err == 0)
return -ETIMEDOUT;
 
-   return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+   return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+  >rx.ret);
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_transfer);
 
diff --git a/include/soc/tegra/bpmp.h b/include/soc/tegra/bpmp.h
index 9ba6522..57519f4 100644
--- a/include/soc/tegra/bpmp.h
+++ b/include/soc/tegra/bpmp.h
@@ -110,6 +110,7 @@ struct tegra_bpmp_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
 };
 
-- 
2.7.4

[PATCH 1/4] firmware: tegra: propagate error code to caller

[Timo Alho]

Response messages from Tegra BPMP firmware contain an error return
code as the first word of payload. The error code is used to indicate
incorrectly formatted request message or use of non-existing resource
(clk, reset, powergate) identifier. Current implementation of
tegra_bpmp_transfer() ignores this code and does not pass it to
caller. Fix this by adding an extra struct member to
tegra_bpmp_message and populate that with return code.

Signed-off-by: Timo Alho 
---
 drivers/firmware/tegra/bpmp.c | 22 --
 include/soc/tegra/bpmp.h  |  1 +
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..33683b5 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -194,16 +194,24 @@ static int tegra_bpmp_wait_master_free(struct 
tegra_bpmp_channel *channel)
 }
 
 static ssize_t __tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
-void *data, size_t size)
+void *data, size_t size, int *ret)
 {
+   int err;
+
if (data && size > 0)
memcpy(data, channel->ib->data, size);
 
-   return tegra_ivc_read_advance(channel->ivc);
+   err = tegra_ivc_read_advance(channel->ivc);
+   if (err < 0)
+   return err;
+
+   *ret = channel->ib->code;
+
+   return 0;
 }
 
 static ssize_t tegra_bpmp_channel_read(struct tegra_bpmp_channel *channel,
-  void *data, size_t size)
+  void *data, size_t size, int *ret)
 {
struct tegra_bpmp *bpmp = channel->bpmp;
unsigned long flags;
@@ -217,7 +225,7 @@ static ssize_t tegra_bpmp_channel_read(struct 
tegra_bpmp_channel *channel,
}
 
spin_lock_irqsave(>lock, flags);
-   err = __tegra_bpmp_channel_read(channel, data, size);
+   err = __tegra_bpmp_channel_read(channel, data, size, ret);
clear_bit(index, bpmp->threaded.allocated);
spin_unlock_irqrestore(>lock, flags);
 
@@ -337,7 +345,8 @@ int tegra_bpmp_transfer_atomic(struct tegra_bpmp *bpmp,
if (err < 0)
return err;
 
-   return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+   return __tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+>rx.ret);
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_transfer_atomic);
 
@@ -371,7 +380,8 @@ int tegra_bpmp_transfer(struct tegra_bpmp *bpmp,
if (err == 0)
return -ETIMEDOUT;
 
-   return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size);
+   return tegra_bpmp_channel_read(channel, msg->rx.data, msg->rx.size,
+  >rx.ret);
 }
 EXPORT_SYMBOL_GPL(tegra_bpmp_transfer);
 
diff --git a/include/soc/tegra/bpmp.h b/include/soc/tegra/bpmp.h
index 9ba6522..57519f4 100644
--- a/include/soc/tegra/bpmp.h
+++ b/include/soc/tegra/bpmp.h
@@ -110,6 +110,7 @@ struct tegra_bpmp_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
 };
 
-- 
2.7.4

[PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/clk/tegra/clk-bpmp.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
 };
 
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = 
+   int err;
 
memset(, 0, sizeof(request));
request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_clk_prepare(struct clk_hw *hw)
@@ -414,11 +422,8 @@ static int tegra_bpmp_probe_clocks(struct tegra_bpmp *bpmp,
struct tegra_bpmp_clk_info *info = [count];
 
err = tegra_bpmp_clk_get_info(bpmp, id, info);
-   if (err < 0) {
-   dev_err(bpmp->dev, "failed to query clock %u: %d\n",
-   id, err);
+   if (err < 0)
continue;
-   }
 
if (info->num_parents >= U8_MAX) {
dev_err(bpmp->dev,
-- 
2.7.4

[PATCH 2/4] clk: tegra: check BPMP response return code

[Timo Alho]

Check return code in BPMP response message(s). The typical error case
is when clock operation is attempted with invalid clock identifier.

Also remove error print from call to clk_get_info() as the
implementation loops through range of all possible identifier, but the
operation is expected error out when the clock id is unused.

Signed-off-by: Timo Alho 
---
 drivers/clk/tegra/clk-bpmp.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/tegra/clk-bpmp.c b/drivers/clk/tegra/clk-bpmp.c
index 638ace6..a896692 100644
--- a/drivers/clk/tegra/clk-bpmp.c
+++ b/drivers/clk/tegra/clk-bpmp.c
@@ -55,6 +55,7 @@ struct tegra_bpmp_clk_message {
struct {
void *data;
size_t size;
+   int ret;
} rx;
 };
 
@@ -64,6 +65,7 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
struct mrq_clk_request request;
struct tegra_bpmp_message msg;
void *req = 
+   int err;
 
memset(, 0, sizeof(request));
request.cmd_and_id = (clk->cmd << 24) | clk->id;
@@ -84,7 +86,13 @@ static int tegra_bpmp_clk_transfer(struct tegra_bpmp *bpmp,
msg.rx.data = clk->rx.data;
msg.rx.size = clk->rx.size;
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_clk_prepare(struct clk_hw *hw)
@@ -414,11 +422,8 @@ static int tegra_bpmp_probe_clocks(struct tegra_bpmp *bpmp,
struct tegra_bpmp_clk_info *info = [count];
 
err = tegra_bpmp_clk_get_info(bpmp, id, info);
-   if (err < 0) {
-   dev_err(bpmp->dev, "failed to query clock %u: %d\n",
-   id, err);
+   if (err < 0)
continue;
-   }
 
if (info->num_parents >= U8_MAX) {
dev_err(bpmp->dev,
-- 
2.7.4

[PATCH 0/4] firmware: tegra: add checks for BPMP error return code

[Timo Alho]

Hi Thierry,

There is a bug in the BPMP driver as error code in response message is
not being checked.

Patch 1 adds the error code as part of tegra_bpmp_message struct and
propagates that code to callers

Patches 2 through 4 add code to client drivers to check the error code
appropriately

BR,
Timo

Timo Alho (4):
  firmware: tegra: propagate error code to caller
  clk: tegra: check BPMP response return code
  reset: tegra: check BPMP response return code
  soc/tegra: bpmp: check BPMP response return code

 drivers/clk/tegra/clk-bpmp.c   | 15 ++-
 drivers/firmware/tegra/bpmp.c  | 22 --
 drivers/reset/tegra/reset-bpmp.c   |  9 -
 drivers/soc/tegra/powergate-bpmp.c | 15 +--
 include/soc/tegra/bpmp.h   |  1 +
 5 files changed, 48 insertions(+), 14 deletions(-)

-- 
2.7.4

[PATCH 4/4] soc/tegra: bpmp: check BPMP response return code

[Timo Alho]

Add checks for return code in BPMP response message.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/soc/tegra/powergate-bpmp.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/tegra/powergate-bpmp.c 
b/drivers/soc/tegra/powergate-bpmp.c
index 8fc3560..82c7e27 100644
--- a/drivers/soc/tegra/powergate-bpmp.c
+++ b/drivers/soc/tegra/powergate-bpmp.c
@@ -42,6 +42,7 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp 
*bpmp,
 {
struct mrq_pg_request request;
struct tegra_bpmp_message msg;
+   int err;
 
memset(, 0, sizeof(request));
request.cmd = CMD_PG_SET_STATE;
@@ -53,7 +54,13 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp 
*bpmp,
msg.tx.data = 
msg.tx.size = sizeof(request);
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_powergate_get_state(struct tegra_bpmp *bpmp,
@@ -80,6 +87,8 @@ static int tegra_bpmp_powergate_get_state(struct tegra_bpmp 
*bpmp,
err = tegra_bpmp_transfer(bpmp, );
if (err < 0)
return PG_STATE_OFF;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
 
return response.get_state.state;
 }
@@ -106,6 +115,8 @@ static int tegra_bpmp_powergate_get_max_id(struct 
tegra_bpmp *bpmp)
err = tegra_bpmp_transfer(bpmp, );
if (err < 0)
return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
 
return response.get_max_id.max_id;
 }
@@ -132,7 +143,7 @@ static char *tegra_bpmp_powergate_get_name(struct 
tegra_bpmp *bpmp,
msg.rx.size = sizeof(response);
 
err = tegra_bpmp_transfer(bpmp, );
-   if (err < 0)
+   if (err < 0 || msg.rx.ret < 0)
return NULL;
 
return kstrdup(response.get_name.name, GFP_KERNEL);
-- 
2.7.4

[PATCH 0/4] firmware: tegra: add checks for BPMP error return code

[Timo Alho]

Hi Thierry,

There is a bug in the BPMP driver as error code in response message is
not being checked.

Patch 1 adds the error code as part of tegra_bpmp_message struct and
propagates that code to callers

Patches 2 through 4 add code to client drivers to check the error code
appropriately

BR,
Timo

Timo Alho (4):
  firmware: tegra: propagate error code to caller
  clk: tegra: check BPMP response return code
  reset: tegra: check BPMP response return code
  soc/tegra: bpmp: check BPMP response return code

 drivers/clk/tegra/clk-bpmp.c   | 15 ++-
 drivers/firmware/tegra/bpmp.c  | 22 --
 drivers/reset/tegra/reset-bpmp.c   |  9 -
 drivers/soc/tegra/powergate-bpmp.c | 15 +--
 include/soc/tegra/bpmp.h   |  1 +
 5 files changed, 48 insertions(+), 14 deletions(-)

-- 
2.7.4

[PATCH 4/4] soc/tegra: bpmp: check BPMP response return code

[Timo Alho]

Add checks for return code in BPMP response message.

Signed-off-by: Timo Alho 
---
 drivers/soc/tegra/powergate-bpmp.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/tegra/powergate-bpmp.c 
b/drivers/soc/tegra/powergate-bpmp.c
index 8fc3560..82c7e27 100644
--- a/drivers/soc/tegra/powergate-bpmp.c
+++ b/drivers/soc/tegra/powergate-bpmp.c
@@ -42,6 +42,7 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp 
*bpmp,
 {
struct mrq_pg_request request;
struct tegra_bpmp_message msg;
+   int err;
 
memset(, 0, sizeof(request));
request.cmd = CMD_PG_SET_STATE;
@@ -53,7 +54,13 @@ static int tegra_bpmp_powergate_set_state(struct tegra_bpmp 
*bpmp,
msg.tx.data = 
msg.tx.size = sizeof(request);
 
-   return tegra_bpmp_transfer(bpmp, );
+   err = tegra_bpmp_transfer(bpmp, );
+   if (err < 0)
+   return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
+
+   return 0;
 }
 
 static int tegra_bpmp_powergate_get_state(struct tegra_bpmp *bpmp,
@@ -80,6 +87,8 @@ static int tegra_bpmp_powergate_get_state(struct tegra_bpmp 
*bpmp,
err = tegra_bpmp_transfer(bpmp, );
if (err < 0)
return PG_STATE_OFF;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
 
return response.get_state.state;
 }
@@ -106,6 +115,8 @@ static int tegra_bpmp_powergate_get_max_id(struct 
tegra_bpmp *bpmp)
err = tegra_bpmp_transfer(bpmp, );
if (err < 0)
return err;
+   else if (msg.rx.ret < 0)
+   return -EINVAL;
 
return response.get_max_id.max_id;
 }
@@ -132,7 +143,7 @@ static char *tegra_bpmp_powergate_get_name(struct 
tegra_bpmp *bpmp,
msg.rx.size = sizeof(response);
 
err = tegra_bpmp_transfer(bpmp, );
-   if (err < 0)
+   if (err < 0 || msg.rx.ret < 0)
return NULL;
 
return kstrdup(response.get_name.name, GFP_KERNEL);
-- 
2.7.4

[PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).

Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/firmware/tegra/Makefile   |   4 +-
 drivers/firmware/tegra/bpmp.c |   2 +
 drivers/firmware/tegra/bpmp_debugfs.c | 446 ++
 include/soc/tegra/bpmp.h  |  14 ++
 4 files changed, 465 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c

diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP)   += bpmp.o
+tegra-bpmp-y   = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS)  += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP)   += tegra-bpmp.o
 obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..bf2a376 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
+   (void)tegra_bpmp_init_debugfs(bpmp);
+
return 0;
 
 free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c 
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..4d0279d
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct seqbuf {
+   char *buf;
+   size_t pos;
+   size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+   seqbuf->buf = buf;
+   seqbuf->size = size;
+   seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+   nbyte = min(nbyte, seqbuf_avail(seqbuf));
+   memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+   seqbuf->pos += nbyte;
+   return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+   int err;
+
+   err = seqbuf_read(seqbuf, v, 4);
+   *v = le32_to_cpu(*v);
+   return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+   *str = seqbuf->buf + seqbuf->pos;
+   seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+   seqbuf->pos++;
+   return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+   seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+   const struct file *file, char *buf, int size)
+{
+   char root_path_buf[512];
+   const char *root_path;
+   const char *filename;
+   size_t root_len;
+
+   root_path = dentry_path_raw(bpmp->debugfs_mirror, root_path_buf,
+   sizeof(root_path_buf));
+   if (IS_ERR_OR_NULL(root_path))
+   return NULL;
+
+   root_len = strlen(root_path);
+
+   filename = dentry_path(file->f_path.dentry, buf, size);
+   if (IS_ERR_OR_NULL(filename))
+   return NULL;
+
+   if (strlen(filename) < root_len ||
+   strncmp(filename, root_path, root_len))
+   return NULL;
+
+   filename += root_len;
+
+   return filename;
+}

[PATCH] firmware: tegra: add BPMP debugfs support

[Timo Alho]

Tegra power management firmware running on co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).

Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.

Signed-off-by: Timo Alho 
---
 drivers/firmware/tegra/Makefile   |   4 +-
 drivers/firmware/tegra/bpmp.c |   2 +
 drivers/firmware/tegra/bpmp_debugfs.c | 446 ++
 include/soc/tegra/bpmp.h  |  14 ++
 4 files changed, 465 insertions(+), 1 deletion(-)
 create mode 100644 drivers/firmware/tegra/bpmp_debugfs.c

diff --git a/drivers/firmware/tegra/Makefile b/drivers/firmware/tegra/Makefile
index e34a2f7..0314568 100644
--- a/drivers/firmware/tegra/Makefile
+++ b/drivers/firmware/tegra/Makefile
@@ -1,2 +1,4 @@
-obj-$(CONFIG_TEGRA_BPMP)   += bpmp.o
+tegra-bpmp-y   = bpmp.o
+tegra-bpmp-$(CONFIG_DEBUG_FS)  += bpmp_debugfs.o
+obj-$(CONFIG_TEGRA_BPMP)   += tegra-bpmp.o
 obj-$(CONFIG_TEGRA_IVC)+= ivc.o
diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index 73ca55b..bf2a376 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -824,6 +824,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
+   (void)tegra_bpmp_init_debugfs(bpmp);
+
return 0;
 
 free_mrq:
diff --git a/drivers/firmware/tegra/bpmp_debugfs.c 
b/drivers/firmware/tegra/bpmp_debugfs.c
new file mode 100644
index 000..4d0279d
--- /dev/null
+++ b/drivers/firmware/tegra/bpmp_debugfs.c
@@ -0,0 +1,446 @@
+/*
+ * Copyright (c) 2017, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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.
+ *
+ */
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct seqbuf {
+   char *buf;
+   size_t pos;
+   size_t size;
+};
+
+static void seqbuf_init(struct seqbuf *seqbuf, void *buf, size_t size)
+{
+   seqbuf->buf = buf;
+   seqbuf->size = size;
+   seqbuf->pos = 0;
+}
+
+static size_t seqbuf_avail(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos < seqbuf->size ? seqbuf->size - seqbuf->pos : 0;
+}
+
+static size_t seqbuf_status(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos <= seqbuf->size ? 0 : -EOVERFLOW;
+}
+
+static int seqbuf_eof(struct seqbuf *seqbuf)
+{
+   return seqbuf->pos >= seqbuf->size;
+}
+
+static int seqbuf_read(struct seqbuf *seqbuf, void *buf, size_t nbyte)
+{
+   nbyte = min(nbyte, seqbuf_avail(seqbuf));
+   memcpy(buf, seqbuf->buf + seqbuf->pos, nbyte);
+   seqbuf->pos += nbyte;
+   return seqbuf_status(seqbuf);
+}
+
+static int seqbuf_read_u32(struct seqbuf *seqbuf, uint32_t *v)
+{
+   int err;
+
+   err = seqbuf_read(seqbuf, v, 4);
+   *v = le32_to_cpu(*v);
+   return err;
+}
+
+static int seqbuf_read_str(struct seqbuf *seqbuf, const char **str)
+{
+   *str = seqbuf->buf + seqbuf->pos;
+   seqbuf->pos += strnlen(*str, seqbuf_avail(seqbuf));
+   seqbuf->pos++;
+   return seqbuf_status(seqbuf);
+}
+
+static void seqbuf_seek(struct seqbuf *seqbuf, ssize_t offset)
+{
+   seqbuf->pos += offset;
+}
+
+/* map filename in Linux debugfs to corresponding entry in BPMP */
+static const char *get_filename(struct tegra_bpmp *bpmp,
+   const struct file *file, char *buf, int size)
+{
+   char root_path_buf[512];
+   const char *root_path;
+   const char *filename;
+   size_t root_len;
+
+   root_path = dentry_path_raw(bpmp->debugfs_mirror, root_path_buf,
+   sizeof(root_path_buf));
+   if (IS_ERR_OR_NULL(root_path))
+   return NULL;
+
+   root_len = strlen(root_path);
+
+   filename = dentry_path(file->f_path.dentry, buf, size);
+   if (IS_ERR_OR_NULL(filename))
+   return NULL;
+
+   if (strlen(filename) < root_len ||
+   strncmp(filename, root_path, root_len))
+   return NULL;
+
+   filename += root_len;
+
+   return filename;
+}
+
+static int mrq_d

[PATCH] mmc: tegra: suppress errors when probe is deferred

[Timo Alho]

Don't print error message when clk_get() returns -EPROBE_DEFER. On
recent Tegra chips (t186 onwards), the clocks are provided by
auxiliary microprocessor (bpmp) and until the driver for it is probed
clocks are not available.

While at it, change the real error message more meaningful.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/mmc/host/sdhci-tegra.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index f668a6f..cdde9ff 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -501,8 +501,10 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
 
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
-   dev_err(mmc_dev(host->mmc), "clk err\n");
rc = PTR_ERR(clk);
+   if (rc != -EPROBE_DEFER)
+   dev_err(>dev,
+   "failed to get controller clock: %d\n", rc);
goto err_clk_get;
}
clk_prepare_enable(clk);
-- 
2.7.4

[PATCH] mmc: tegra: suppress errors when probe is deferred

[Timo Alho]

Don't print error message when clk_get() returns -EPROBE_DEFER. On
recent Tegra chips (t186 onwards), the clocks are provided by
auxiliary microprocessor (bpmp) and until the driver for it is probed
clocks are not available.

While at it, change the real error message more meaningful.

Signed-off-by: Timo Alho 
---
 drivers/mmc/host/sdhci-tegra.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index f668a6f..cdde9ff 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -501,8 +501,10 @@ static int sdhci_tegra_probe(struct platform_device *pdev)
 
clk = devm_clk_get(mmc_dev(host->mmc), NULL);
if (IS_ERR(clk)) {
-   dev_err(mmc_dev(host->mmc), "clk err\n");
rc = PTR_ERR(clk);
+   if (rc != -EPROBE_DEFER)
+   dev_err(>dev,
+   "failed to get controller clock: %d\n", rc);
goto err_clk_get;
}
clk_prepare_enable(clk);
-- 
2.7.4

[PATCH] firmware: tegra: set drvdata earlier

[Timo Alho]

Subdevices of bpmp, such as bpmp-i2c, require the bpmp device's
drvdata to be set during their probe. Currently this is not always the
case. Fix this by calling platform_set_drvdata() earlier during bpmp's
probe.

Signed-off-by: Timo Alho <ta...@nvidia.com>
---
 drivers/firmware/tegra/bpmp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index b251795..73ca55b 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -806,6 +806,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
 
dev_info(>dev, "firmware: %s\n", tag);
 
+   platform_set_drvdata(pdev, bpmp);
+
err = of_platform_default_populate(pdev->dev.of_node, NULL, >dev);
if (err < 0)
goto free_mrq;
@@ -822,8 +824,6 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
-   platform_set_drvdata(pdev, bpmp);
-
return 0;
 
 free_mrq:
-- 
2.7.4

[PATCH] firmware: tegra: set drvdata earlier

[Timo Alho]

Subdevices of bpmp, such as bpmp-i2c, require the bpmp device's
drvdata to be set during their probe. Currently this is not always the
case. Fix this by calling platform_set_drvdata() earlier during bpmp's
probe.

Signed-off-by: Timo Alho 
---
 drivers/firmware/tegra/bpmp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/tegra/bpmp.c b/drivers/firmware/tegra/bpmp.c
index b251795..73ca55b 100644
--- a/drivers/firmware/tegra/bpmp.c
+++ b/drivers/firmware/tegra/bpmp.c
@@ -806,6 +806,8 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
 
dev_info(>dev, "firmware: %s\n", tag);
 
+   platform_set_drvdata(pdev, bpmp);
+
err = of_platform_default_populate(pdev->dev.of_node, NULL, >dev);
if (err < 0)
goto free_mrq;
@@ -822,8 +824,6 @@ static int tegra_bpmp_probe(struct platform_device *pdev)
if (err < 0)
goto free_mrq;
 
-   platform_set_drvdata(pdev, bpmp);
-
return 0;
 
 free_mrq:
-- 
2.7.4

[PATCH] staging: wlang-ng: Fix block comments style warnings in prism2sta.h

[Timo Schmid]

This patch fixes the following checkpatch.pl warning in prism2sta.h:
WARNING: Block comments should align the * on each line

No more warnings block comments warnings for this file.

Signed-off-by: Timo Schmid <timo.sch...@gmail.com>
---
 drivers/staging/wlan-ng/prism2sta.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index e1b4a94..1a6ea1f 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1859,24 +1859,24 @@ void prism2sta_ev_alloc(struct wlandevice *wlandev)
 }
 
 /*
-* create_wlan
-*
-* Called at module init time.  This creates the struct wlandevice structure
-* and initializes it with relevant bits.
-*
-* Arguments:
-*  none
-*
-* Returns:
-*  the created struct wlandevice structure.
-*
-* Side effects:
-*  also allocates the priv/hw structures.
-*
-* Call context:
-*  process thread
-*
-*/
+ * create_wlan
+ *
+ * Called at module init time.  This creates the struct wlandevice structure
+ * and initializes it with relevant bits.
+ *
+ * Arguments:
+ * none
+ *
+ * Returns:
+ * the created struct wlandevice structure.
+ *
+ * Side effects:
+ * also allocates the priv/hw structures.
+ *
+ * Call context:
+ * process thread
+ *
+ */
 static struct wlandevice *create_wlan(void)
 {
struct wlandevice *wlandev = NULL;
-- 
2.7.4

[PATCH] staging: wlang-ng: Fix block comments style warnings in prism2sta.h

[Timo Schmid]

This patch fixes the following checkpatch.pl warning in prism2sta.h:
WARNING: Block comments should align the * on each line

No more warnings block comments warnings for this file.

Signed-off-by: Timo Schmid 
---
 drivers/staging/wlan-ng/prism2sta.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/wlan-ng/prism2sta.c 
b/drivers/staging/wlan-ng/prism2sta.c
index e1b4a94..1a6ea1f 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -1859,24 +1859,24 @@ void prism2sta_ev_alloc(struct wlandevice *wlandev)
 }
 
 /*
-* create_wlan
-*
-* Called at module init time.  This creates the struct wlandevice structure
-* and initializes it with relevant bits.
-*
-* Arguments:
-*  none
-*
-* Returns:
-*  the created struct wlandevice structure.
-*
-* Side effects:
-*  also allocates the priv/hw structures.
-*
-* Call context:
-*  process thread
-*
-*/
+ * create_wlan
+ *
+ * Called at module init time.  This creates the struct wlandevice structure
+ * and initializes it with relevant bits.
+ *
+ * Arguments:
+ * none
+ *
+ * Returns:
+ * the created struct wlandevice structure.
+ *
+ * Side effects:
+ * also allocates the priv/hw structures.
+ *
+ * Call context:
+ * process thread
+ *
+ */
 static struct wlandevice *create_wlan(void)
 {
struct wlandevice *wlandev = NULL;
-- 
2.7.4

Re: [PATCH] builddeb: Update a few outdated and hardcoded strings

[Timo Sigurdsson]

Hi,

Riku Voipio schrieb am 13.09.2016 10:22:

> On 5 September 2016 at 02:43, Timo Sigurdsson
> <public_tim...@silentcreek.de> wrote:
>> The builddeb script has some hardcoded references to linux version 2.6
>> which is ancient. Use a variable instead in order to keep in sync with
>> new releases and avoid the need to manually update this. In addition,
>> change the copyright notice to include the year 2016.
> 
> I think we can just drop all the "Provides" lines, the official debian
> packages don't provide
> anything, and nothing depends on these provided virtual packages either.

As far as Debian is concerned, that's true. However, Ubuntu's linux
packages have these "Provides" lines. But as I haven't used Ubuntu in a
while, I don't know if these are actually required for anything on Ubuntu
systems.

I'd be fine with any decision (keep or drop), I just don't wanna make the
call to drop them as I'm not aware about the implications on other Debian
based distributions.

Regards,

Timo

Re: [PATCH] builddeb: Update a few outdated and hardcoded strings

[Timo Sigurdsson]

Hi,

Riku Voipio schrieb am 13.09.2016 10:22:

> On 5 September 2016 at 02:43, Timo Sigurdsson
>  wrote:
>> The builddeb script has some hardcoded references to linux version 2.6
>> which is ancient. Use a variable instead in order to keep in sync with
>> new releases and avoid the need to manually update this. In addition,
>> change the copyright notice to include the year 2016.
> 
> I think we can just drop all the "Provides" lines, the official debian
> packages don't provide
> anything, and nothing depends on these provided virtual packages either.

As far as Debian is concerned, that's true. However, Ubuntu's linux
packages have these "Provides" lines. But as I haven't used Ubuntu in a
while, I don't know if these are actually required for anything on Ubuntu
systems.

I'd be fine with any decision (keep or drop), I just don't wanna make the
call to drop them as I'm not aware about the implications on other Debian
based distributions.

Regards,

Timo

[PATCH] builddeb: Update a few outdated and hardcoded strings

[Timo Sigurdsson]

The builddeb script has some hardcoded references to linux version 2.6
which is ancient. Use a variable instead in order to keep in sync with
new releases and avoid the need to manually update this. In addition,
change the copyright notice to include the year 2016.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
 scripts/package/builddeb | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..d85120c 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -84,6 +84,7 @@ set_debarch() {
 
 # Some variables and settings used throughout the script
 version=$KERNELRELEASE
+majorversion=$VERSION.$PATCHLEVEL
 revision=$(cat .version)
 if [ -n "$KDEB_PKGVERSION" ]; then
packageversion=$KDEB_PKGVERSION
@@ -265,7 +266,7 @@ This is a packacked upstream version of the Linux kernel.
 The sources may be found at most Linux ftp sites, including:
 ftp://ftp.kernel.org/pub/linux/kernel
 
-Copyright: 1991 - 2015 Linus Torvalds and others.
+Copyright: 1991 - 2016 Linus Torvalds and others.
 
 The git repository for mainline kernel development is at:
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
@@ -296,7 +297,7 @@ if [ "$ARCH" = "um" ]; then
cat <> debian/control
 
 Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
 Architecture: any
 Description: User Mode Linux kernel, version $version
  User-mode Linux is a port of the Linux kernel to its own system call
@@ -313,7 +314,7 @@ else
cat <> debian/control
 
 Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
 Suggests: $fwpackagename
 Architecture: any
 Description: Linux kernel, version $version
@@ -346,7 +347,7 @@ rm -f "$objtree/debian/hdrsrcfiles" 
"$objtree/debian/hdrobjfiles"
 cat <> debian/control
 
 Package: $kernel_headers_packagename
-Provides: linux-headers, linux-headers-2.6
+Provides: linux-headers, linux-headers-$majorversion
 Architecture: any
 Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This package provides kernel header files for $KERNELRELEASE on 
\${kernel:debarch}
-- 
2.1.4

[PATCH] builddeb: Update a few outdated and hardcoded strings

[Timo Sigurdsson]

The builddeb script has some hardcoded references to linux version 2.6
which is ancient. Use a variable instead in order to keep in sync with
new releases and avoid the need to manually update this. In addition,
change the copyright notice to include the year 2016.

Signed-off-by: Timo Sigurdsson 
---
 scripts/package/builddeb | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/scripts/package/builddeb b/scripts/package/builddeb
index 8ea9fd2..d85120c 100755
--- a/scripts/package/builddeb
+++ b/scripts/package/builddeb
@@ -84,6 +84,7 @@ set_debarch() {
 
 # Some variables and settings used throughout the script
 version=$KERNELRELEASE
+majorversion=$VERSION.$PATCHLEVEL
 revision=$(cat .version)
 if [ -n "$KDEB_PKGVERSION" ]; then
packageversion=$KDEB_PKGVERSION
@@ -265,7 +266,7 @@ This is a packacked upstream version of the Linux kernel.
 The sources may be found at most Linux ftp sites, including:
 ftp://ftp.kernel.org/pub/linux/kernel
 
-Copyright: 1991 - 2015 Linus Torvalds and others.
+Copyright: 1991 - 2016 Linus Torvalds and others.
 
 The git repository for mainline kernel development is at:
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
@@ -296,7 +297,7 @@ if [ "$ARCH" = "um" ]; then
cat <> debian/control
 
 Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
 Architecture: any
 Description: User Mode Linux kernel, version $version
  User-mode Linux is a port of the Linux kernel to its own system call
@@ -313,7 +314,7 @@ else
cat <> debian/control
 
 Package: $packagename
-Provides: linux-image, linux-image-2.6, linux-modules-$version
+Provides: linux-image, linux-image-$majorversion, linux-modules-$version
 Suggests: $fwpackagename
 Architecture: any
 Description: Linux kernel, version $version
@@ -346,7 +347,7 @@ rm -f "$objtree/debian/hdrsrcfiles" 
"$objtree/debian/hdrobjfiles"
 cat <> debian/control
 
 Package: $kernel_headers_packagename
-Provides: linux-headers, linux-headers-2.6
+Provides: linux-headers, linux-headers-$majorversion
 Architecture: any
 Description: Linux kernel headers for $KERNELRELEASE on \${kernel:debarch}
  This package provides kernel header files for $KERNELRELEASE on 
\${kernel:debarch}
-- 
2.1.4

[PATCH for 4.4-rc8] ARM: Fix broken USB support in multi_v7_defconfig for sunxi devices

[Timo Sigurdsson]

Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a
new driver for the USB power supply used on various Allwinner based SBCs.
However, the driver was not added to multi_v7_defconfig which breaks USB
support for some boards (e.g. LeMaker BananaPi) as the kernel will now
turn off the USB power supply during boot by default if the driver isn't
present. (This was not the case in linux 4.3 or lower where the USB power
was always left on.)

Hence, add the driver to multi_v7_defconfig in order to keep USB support
working on those boards that require it.

Signed-off-by: Timo Sigurdsson 
Tested-by: Timo Sigurdsson 
Acked-by: Maxime Ripard 
---
Notes:

I chose to add AXP20X_POWER as a module here, since linux-next already
has it this way, see commit 83e9e1f84074 ("ARM: multi_v7_defconfig:
Enable RSB and AXP20X related drivers as modules").
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..cd7b198 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -366,6 +366,7 @@ CONFIG_BATTERY_MAX17042=m
 CONFIG_CHARGER_MAX14577=m
 CONFIG_CHARGER_MAX77693=m
 CONFIG_CHARGER_TPS65090=y
+CONFIG_AXP20X_POWER=m
 CONFIG_POWER_RESET_AS3722=y
 CONFIG_POWER_RESET_GPIO=y
 CONFIG_POWER_RESET_GPIO_RESTART=y
-- 
2.1.4

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

Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Hi Arnd,

Arnd Bergmann schrieb am 31.12.2015 16:46:

> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this   
>> could make it into 4.4 in order to avoid unpleasent surprises (and
>> subsequent questions) with builds based on sunxi_defconfig. At the moment,
>> some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
>> as a newly added driver is required to power them.
> 
> It's a bit confusing to send a patch to so many recipients, that usually
> leads to nobody applying it. I can put it into the fixes branch in arm-soc
> but need an Ack from the sunxi maintainer(s).

Sorry, I didn't know any better. Almost all recipients came from the
get-maintainers script (which I thought were mandatory to include). What's
the recommended way in such cases?

I already prepared and tested a patch for multi_v7_defconfig which I'll
send to the same recipients as before just for the sake of not shutting
out people that were previously addressed in this conversation.

Thanks and Happy New Year,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 31.12.2015 17:00:

> Hi Arnd,
> 
> On Thu, Dec 31, 2015 at 04:46:01PM +0100, Arnd Bergmann wrote:
>> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> > Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this  
>> >  
>> > could make it into 4.4 in order to avoid unpleasent surprises (and
>> > subsequent questions) with builds based on sunxi_defconfig. At the moment,
>> > some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
>> > as a newly added driver is required to power them.
>> 
>> It's a bit confusing to send a patch to so many recipients, that usually
>> leads to nobody applying it. I can put it into the fixes branch in arm-soc
>> but need an Ack from the sunxi maintainer(s).
> 
> You have mine
> 
> Acked-by: Maxime Ripard 
> 
> Timo, don't we need the same thing for multi_v7?

Yes, we do. I thought I saw it already in there as a module, but that must
have been on linux-next... Anyway, patch will come right away. I take it
your question implies an ack for the multi_v7 patch, too.


Thanks and Happy New Year,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Hi Arnd,

Arnd Bergmann schrieb am 31.12.2015 16:46:

> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this   
>> could make it into 4.4 in order to avoid unpleasent surprises (and
>> subsequent questions) with builds based on sunxi_defconfig. At the moment,
>> some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
>> as a newly added driver is required to power them.
> 
> It's a bit confusing to send a patch to so many recipients, that usually
> leads to nobody applying it. I can put it into the fixes branch in arm-soc
> but need an Ack from the sunxi maintainer(s).

Sorry, I didn't know any better. Almost all recipients came from the
get-maintainers script (which I thought were mandatory to include). What's
the recommended way in such cases?

I already prepared and tested a patch for multi_v7_defconfig which I'll
send to the same recipients as before just for the sake of not shutting
out people that were previously addressed in this conversation.

Thanks and Happy New Year,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 31.12.2015 17:00:

> Hi Arnd,
> 
> On Thu, Dec 31, 2015 at 04:46:01PM +0100, Arnd Bergmann wrote:
>> On Tuesday 29 December 2015 02:47:32 Timo Sigurdsson wrote:
>> > Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this  
>> >  
>> > could make it into 4.4 in order to avoid unpleasent surprises (and
>> > subsequent questions) with builds based on sunxi_defconfig. At the moment,
>> > some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
>> > as a newly added driver is required to power them.
>> 
>> It's a bit confusing to send a patch to so many recipients, that usually
>> leads to nobody applying it. I can put it into the fixes branch in arm-soc
>> but need an Ack from the sunxi maintainer(s).
> 
> You have mine
> 
> Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com>
> 
> Timo, don't we need the same thing for multi_v7?

Yes, we do. I thought I saw it already in there as a module, but that must
have been on linux-next... Anyway, patch will come right away. I take it
your question implies an ack for the multi_v7 patch, too.


Thanks and Happy New Year,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH for 4.4-rc8] ARM: Fix broken USB support in multi_v7_defconfig for sunxi devices

[Timo Sigurdsson]

Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a
new driver for the USB power supply used on various Allwinner based SBCs.
However, the driver was not added to multi_v7_defconfig which breaks USB
support for some boards (e.g. LeMaker BananaPi) as the kernel will now
turn off the USB power supply during boot by default if the driver isn't
present. (This was not the case in linux 4.3 or lower where the USB power
was always left on.)

Hence, add the driver to multi_v7_defconfig in order to keep USB support
working on those boards that require it.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
Tested-by: Timo Sigurdsson <public_tim...@silentcreek.de>
Acked-by: Maxime Ripard <maxime.rip...@free-electrons.com>
---
Notes:

I chose to add AXP20X_POWER as a module here, since linux-next already
has it this way, see commit 83e9e1f84074 ("ARM: multi_v7_defconfig:
Enable RSB and AXP20X related drivers as modules").
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..cd7b198 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -366,6 +366,7 @@ CONFIG_BATTERY_MAX17042=m
 CONFIG_CHARGER_MAX14577=m
 CONFIG_CHARGER_MAX77693=m
 CONFIG_CHARGER_TPS65090=y
+CONFIG_AXP20X_POWER=m
 CONFIG_POWER_RESET_AS3722=y
 CONFIG_POWER_RESET_GPIO=y
 CONFIG_POWER_RESET_GPIO_RESTART=y
-- 
2.1.4

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

[PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this   
could make it into 4.4 in order to avoid unpleasent surprises (and
subsequent questions) with builds based on sunxi_defconfig. At the moment,
some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
as a newly added driver is required to power them.

Timo Sigurdsson (1):
  ARM: Fix broken USB support in sunxi_defconfig

 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
2.1.4

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

[PATCH 1/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a new
driver for the USB power supply used on various Allwinner based SBCs. However,
the driver was not added to sunxi_defconfig which breaks USB support for some
boards (e.g. LeMaker BananaPi) as the kernel will now turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)

Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.

Signed-off-by: Timo Sigurdsson 
Reported-by: David Tulloh 
Tested-by: David Tulloh 
Tested-by: Timo Sigurdsson 
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..b503a89 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -84,6 +84,7 @@ CONFIG_SPI_SUN4I=y
 CONFIG_SPI_SUN6I=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_POWER_SUPPLY=y
+CONFIG_AXP20X_POWER=y
 CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
-- 
2.1.4

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

[PATCH 1/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Commit 69fb4dcada77 ("power: Add an axp20x-usb-power driver") introduced a new
driver for the USB power supply used on various Allwinner based SBCs. However,
the driver was not added to sunxi_defconfig which breaks USB support for some
boards (e.g. LeMaker BananaPi) as the kernel will now turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)

Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
Reported-by: David Tulloh <da...@tulloh.id.au>
Tested-by: David Tulloh <da...@tulloh.id.au>
Tested-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..b503a89 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -84,6 +84,7 @@ CONFIG_SPI_SUN4I=y
 CONFIG_SPI_SUN6I=y
 CONFIG_GPIO_SYSFS=y
 CONFIG_POWER_SUPPLY=y
+CONFIG_AXP20X_POWER=y
 CONFIG_THERMAL=y
 CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
-- 
2.1.4

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

[PATCH 0/1 for 4.4-rc8] ARM: Fix broken USB support in sunxi_defconfig

[Timo Sigurdsson]

Here is a late patch aimed for 4.4-rc8 (or 4.4). It would be nice if this   
could make it into 4.4 in order to avoid unpleasent surprises (and
subsequent questions) with builds based on sunxi_defconfig. At the moment,
some boards (e.g. LeMaker BananaPi) are left with non-functional USB ports
as a newly added driver is required to power them.

Timo Sigurdsson (1):
  ARM: Fix broken USB support in sunxi_defconfig

 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

-- 
2.1.4

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

Re: [PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Sorry, I probably shouldn't send patches at an hour I should rather be
sleeping... As a result, I forgot to add the patch history.

Here it is:

Changes in v2:
- Move the extra cleanup work for sunxi_defconfig to a separate patch
- Add another patch to meet the dependencies of
  CONFIG_KEYBOARD_SUN4I_LRADC and not have it removed while cleaning up


Good night,

Timo

Am Freitag, den 20.11.2015, 02:46 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
> 
> Signed-off-by: Timo Sigurdsson 
> ---
>  arch/arm/configs/sunxi_defconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..0bbc2ee 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
>  # CONFIG_WIRELESS is not set
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_AHCI_SUNXI=y
> @@ -123,6 +122,8 @@ CONFIG_PWM=y
>  CONFIG_PWM_SUN4I=y
>  CONFIG_PHY_SUN4I_USB=y
>  CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y


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

[PATCH v2 2/3] ARM: sunxi: Really enable LRADC keys in sunxi_defconfig

[Timo Sigurdsson]

Commit be8becb81bdc ("ARM: sunxi_defconfig: Enable LRADC keys
(KEYBOARD_SUN4I_LRADC)") added CONFIG_KEYBOARD_SUN4I_LRADC=y to
sunxi_defconfig. However, it depends on CONFIG_KEYBOARD which is
explicitly disabled in sunxi_defconfig. Hence, the LRADC keys were
never actually enabled. Remove the line disabling CONFIG_KEYBOARD in
order to really enable KEYBOARD_SUN4I_LRADC.

Signed-off-by: Timo Sigurdsson 
---
 arch/arm/configs/sunxi_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 0bbc2ee..90252ca 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -60,7 +60,6 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_AXP20X_PEK=y
-- 
2.1.4

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

[PATCH v2 3/3] ARM: sunxi: Clean up sunxi_defconfig

[Timo Sigurdsson]

Clean up sunxi_defconfig by generating a fresh file via
  make sunxi_defconfig
  make savedefconfig

While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes. The resulting .config is
identical before and after this patch.

Signed-off-by: Timo Sigurdsson 
---
 arch/arm/configs/sunxi_defconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 90252ca..95b51fc 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_VFP=y
 CONFIG_NEON=y
-CONFIG_PM=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -60,12 +58,12 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_KEYBOARD_SUN4I_LRADC=y
 # CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
 CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
-- 
2.1.4

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

[PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.

Signed-off-by: Timo Sigurdsson 
---
 arch/arm/configs/sunxi_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..0bbc2ee 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -123,6 +122,8 @@ CONFIG_PWM=y
 CONFIG_PWM_SUN4I=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.1.4

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Sorry, sent out the reply first to Maxime only and forgot to include the
rest of the bunch. So, here we go again...


Hi Maxime,

Am Freitag, den 20.11.2015, 00:43 +0100 schrieb Maxime Ripard:
> Hi,
> 
> On Thu, Nov 19, 2015 at 10:48:35PM +0100, Timo Sigurdsson wrote:
> > Hi Maxime,
> > Hi Chen-Yu,
> > 
> > Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> > > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the
nvmem
> > > framework") moved the the sunxi SID driver to a new framework, but
left
> > > sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the
driver
> > > in sunxi_defconfig.
> > > 
> > > While at it, clean up sunxi_defconfig by generating a fresh file
via
> > >   make sunxi_defconfig
> > >   make savedefconfig
> > > While this moves around a few lines and removes unnecessary
symbols,
> > > it doesn't introduce any functional changes.
> > > 
> > > Signed-off-by: Timo Sigurdsson 
> > > 
> > > diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
> > > index 3c36e16..904ea52 100644
> > > --- a/arch/arm/configs/sunxi_defconfig
> > > +++ b/arch/arm/configs/sunxi_defconfig
> > > @@ -11,14 +11,12 @@ CONFIG_SMP=y
> > >  CONFIG_NR_CPUS=8
> > >  CONFIG_AEABI=y
> > >  CONFIG_HIGHMEM=y
> > > -CONFIG_HIGHPTE=y
> > >  CONFIG_ARM_APPENDED_DTB=y
> > >  CONFIG_ARM_ATAG_DTB_COMPAT=y
> > >  CONFIG_CPU_FREQ=y
> > >  CONFIG_CPUFREQ_DT=y
> > >  CONFIG_VFP=y
> > >  CONFIG_NEON=y
> > > -CONFIG_PM=y
> > >  CONFIG_NET=y
> > >  CONFIG_PACKET=y
> > >  CONFIG_UNIX=y
> > > @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> > >  # CONFIG_WIRELESS is not set
> > >  CONFIG_DEVTMPFS=y
> > >  CONFIG_DEVTMPFS_MOUNT=y
> > > -CONFIG_EEPROM_SUNXI_SID=y
> > >  CONFIG_BLK_DEV_SD=y
> > >  CONFIG_ATA=y
> > >  CONFIG_AHCI_SUNXI=y
> > > @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> > >  # CONFIG_INPUT_MOUSEDEV is not set
> > >  # CONFIG_INPUT_KEYBOARD is not set
> > >  # CONFIG_INPUT_MOUSE is not set
> > > -CONFIG_INPUT_MISC=y
> > > -CONFIG_INPUT_AXP20X_PEK=y
> > >  CONFIG_INPUT_TOUCHSCREEN=y
> > > -CONFIG_KEYBOARD_SUN4I_LRADC=y
> > >  CONFIG_TOUCHSCREEN_SUN4I=y
> > > +CONFIG_INPUT_MISC=y
> > > +CONFIG_INPUT_AXP20X_PEK=y
> > >  CONFIG_SERIAL_8250=y
> > >  CONFIG_SERIAL_8250_CONSOLE=y
> > >  CONFIG_SERIAL_8250_NR_UARTS=8
> > > @@ -123,6 +119,8 @@ CONFIG_PWM=y
> > >  CONFIG_PWM_SUN4I=y
> > >  CONFIG_PHY_SUN4I_USB=y
> > >  CONFIG_PHY_SUN9I_USB=y
> > > +CONFIG_NVMEM=y
> > > +CONFIG_NVMEM_SUNXI_SID=y
> > >  CONFIG_EXT4_FS=y
> > >  CONFIG_VFAT_FS=y
> > >  CONFIG_TMPFS=y
> > 
> > Would you also prefer to see this patch split up into two patches
(one
> > for re-enabling the SID driver and one for the extra cleanup of
> > sunxi_defconfg) as I was asked to do for my other patch for
> > multi_v7_defconfig?
> 
> Yes, please do.

Ok.

> 
> Also why CONFIG_PM CONFIG_KEYBOARD_SUN4I_LRADC and CONFIG_HIGHPTE got
> removed ?

CONFIG_HIGHPTE defaults to yes since 4.4-rc1 in arch/arm/Kconfig, so we
don't need it in sunxi_defconfig anymore. CONFIG_PM is already selected
by CONFIG_ARCH_MULTI_V7, so also no need to set that explicitly.

What's interesting is CONFIG_KEYBOARD_SUN4I_LRADC, because that actually
does _NOT_ get enabled by sunxi_defconfig. I didn't notice earlier,
because before and after my patch, the resulting .config was identical.

The problem with CONFIG_KEYBOARD_SUN4I_LRADC is that keyboard support is
explicitly disabled in sunxi_defconfig which is why
CONFIG_KEYBOARD_SUN4I_LRADC is simply ignored.
So, we need to remove the line
# CONFIG_INPUT_KEYBOARD is not set
in order to actually have CONFIG_KEYBOARD_SUN4I_LRADC enabled.

I'll write another patch for it.

Regards,

Timo
> 
> Thanks,
> Maxime
> 



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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Hi Maxime,
Hi Chen-Yu,

Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
> 
> While at it, clean up sunxi_defconfig by generating a fresh file via
>   make sunxi_defconfig
>   make savedefconfig
> While this moves around a few lines and removes unnecessary symbols,
> it doesn't introduce any functional changes.
> 
> Signed-off-by: Timo Sigurdsson 
> 
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..904ea52 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -11,14 +11,12 @@ CONFIG_SMP=y
>  CONFIG_NR_CPUS=8
>  CONFIG_AEABI=y
>  CONFIG_HIGHMEM=y
> -CONFIG_HIGHPTE=y
>  CONFIG_ARM_APPENDED_DTB=y
>  CONFIG_ARM_ATAG_DTB_COMPAT=y
>  CONFIG_CPU_FREQ=y
>  CONFIG_CPUFREQ_DT=y
>  CONFIG_VFP=y
>  CONFIG_NEON=y
> -CONFIG_PM=y
>  CONFIG_NET=y
>  CONFIG_PACKET=y
>  CONFIG_UNIX=y
> @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
>  # CONFIG_WIRELESS is not set
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_AHCI_SUNXI=y
> @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
>  # CONFIG_INPUT_MOUSEDEV is not set
>  # CONFIG_INPUT_KEYBOARD is not set
>  # CONFIG_INPUT_MOUSE is not set
> -CONFIG_INPUT_MISC=y
> -CONFIG_INPUT_AXP20X_PEK=y
>  CONFIG_INPUT_TOUCHSCREEN=y
> -CONFIG_KEYBOARD_SUN4I_LRADC=y
>  CONFIG_TOUCHSCREEN_SUN4I=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_AXP20X_PEK=y
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
>  CONFIG_SERIAL_8250_NR_UARTS=8
> @@ -123,6 +119,8 @@ CONFIG_PWM=y
>  CONFIG_PWM_SUN4I=y
>  CONFIG_PHY_SUN4I_USB=y
>  CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y

Would you also prefer to see this patch split up into two patches (one
for re-enabling the SID driver and one for the extra cleanup of
sunxi_defconfg) as I was asked to do for my other patch for
multi_v7_defconfig?


Thanks,

Timo

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

[PATCH v2] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.

Signed-off-by: Timo Sigurdsson 
---
Changes in v2:
- Move the extra cleanup work for multi_v7_defconfig to a separate
  patch (to be submitted at a later point to avoid conflicts with
  another patch waiting to be merged)
---
 arch/arm/configs/multi_v7_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index eefcab1..59d3d3a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -188,7 +188,6 @@ CONFIG_ATMEL_SSC=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
 CONFIG_SCSI_MULTI_LUN=y
@@ -714,6 +713,8 @@ CONFIG_PHY_STIH407_USB=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
 CONFIG_PHY_SAMSUNG_USB2=m
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_AUTOFS4_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.1.4

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

[PATCH v2 3/3] ARM: sunxi: Clean up sunxi_defconfig

[Timo Sigurdsson]

Clean up sunxi_defconfig by generating a fresh file via
  make sunxi_defconfig
  make savedefconfig

While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes. The resulting .config is
identical before and after this patch.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
 arch/arm/configs/sunxi_defconfig | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 90252ca..95b51fc 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_VFP=y
 CONFIG_NEON=y
-CONFIG_PM=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -60,12 +58,12 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
+CONFIG_KEYBOARD_SUN4I_LRADC=y
 # CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
 CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
-- 
2.1.4

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

[PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
 arch/arm/configs/sunxi_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..0bbc2ee 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -123,6 +122,8 @@ CONFIG_PWM=y
 CONFIG_PWM_SUN4I=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.1.4

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

[PATCH v2 2/3] ARM: sunxi: Really enable LRADC keys in sunxi_defconfig

[Timo Sigurdsson]

Commit be8becb81bdc ("ARM: sunxi_defconfig: Enable LRADC keys
(KEYBOARD_SUN4I_LRADC)") added CONFIG_KEYBOARD_SUN4I_LRADC=y to
sunxi_defconfig. However, it depends on CONFIG_KEYBOARD which is
explicitly disabled in sunxi_defconfig. Hence, the LRADC keys were
never actually enabled. Remove the line disabling CONFIG_KEYBOARD in
order to really enable KEYBOARD_SUN4I_LRADC.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
 arch/arm/configs/sunxi_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 0bbc2ee..90252ca 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -60,7 +60,6 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_NET_VENDOR_WIZNET is not set
 # CONFIG_WLAN is not set
 # CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_AXP20X_PEK=y
-- 
2.1.4

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Sorry, sent out the reply first to Maxime only and forgot to include the
rest of the bunch. So, here we go again...


Hi Maxime,

Am Freitag, den 20.11.2015, 00:43 +0100 schrieb Maxime Ripard:
> Hi,
> 
> On Thu, Nov 19, 2015 at 10:48:35PM +0100, Timo Sigurdsson wrote:
> > Hi Maxime,
> > Hi Chen-Yu,
> > 
> > Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> > > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the
nvmem
> > > framework") moved the the sunxi SID driver to a new framework, but
left
> > > sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the
driver
> > > in sunxi_defconfig.
> > > 
> > > While at it, clean up sunxi_defconfig by generating a fresh file
via
> > >   make sunxi_defconfig
> > >   make savedefconfig
> > > While this moves around a few lines and removes unnecessary
symbols,
> > > it doesn't introduce any functional changes.
> > > 
> > > Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> > > 
> > > diff --git a/arch/arm/configs/sunxi_defconfig
b/arch/arm/configs/sunxi_defconfig
> > > index 3c36e16..904ea52 100644
> > > --- a/arch/arm/configs/sunxi_defconfig
> > > +++ b/arch/arm/configs/sunxi_defconfig
> > > @@ -11,14 +11,12 @@ CONFIG_SMP=y
> > >  CONFIG_NR_CPUS=8
> > >  CONFIG_AEABI=y
> > >  CONFIG_HIGHMEM=y
> > > -CONFIG_HIGHPTE=y
> > >  CONFIG_ARM_APPENDED_DTB=y
> > >  CONFIG_ARM_ATAG_DTB_COMPAT=y
> > >  CONFIG_CPU_FREQ=y
> > >  CONFIG_CPUFREQ_DT=y
> > >  CONFIG_VFP=y
> > >  CONFIG_NEON=y
> > > -CONFIG_PM=y
> > >  CONFIG_NET=y
> > >  CONFIG_PACKET=y
> > >  CONFIG_UNIX=y
> > > @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
> > >  # CONFIG_WIRELESS is not set
> > >  CONFIG_DEVTMPFS=y
> > >  CONFIG_DEVTMPFS_MOUNT=y
> > > -CONFIG_EEPROM_SUNXI_SID=y
> > >  CONFIG_BLK_DEV_SD=y
> > >  CONFIG_ATA=y
> > >  CONFIG_AHCI_SUNXI=y
> > > @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
> > >  # CONFIG_INPUT_MOUSEDEV is not set
> > >  # CONFIG_INPUT_KEYBOARD is not set
> > >  # CONFIG_INPUT_MOUSE is not set
> > > -CONFIG_INPUT_MISC=y
> > > -CONFIG_INPUT_AXP20X_PEK=y
> > >  CONFIG_INPUT_TOUCHSCREEN=y
> > > -CONFIG_KEYBOARD_SUN4I_LRADC=y
> > >  CONFIG_TOUCHSCREEN_SUN4I=y
> > > +CONFIG_INPUT_MISC=y
> > > +CONFIG_INPUT_AXP20X_PEK=y
> > >  CONFIG_SERIAL_8250=y
> > >  CONFIG_SERIAL_8250_CONSOLE=y
> > >  CONFIG_SERIAL_8250_NR_UARTS=8
> > > @@ -123,6 +119,8 @@ CONFIG_PWM=y
> > >  CONFIG_PWM_SUN4I=y
> > >  CONFIG_PHY_SUN4I_USB=y
> > >  CONFIG_PHY_SUN9I_USB=y
> > > +CONFIG_NVMEM=y
> > > +CONFIG_NVMEM_SUNXI_SID=y
> > >  CONFIG_EXT4_FS=y
> > >  CONFIG_VFAT_FS=y
> > >  CONFIG_TMPFS=y
> > 
> > Would you also prefer to see this patch split up into two patches
(one
> > for re-enabling the SID driver and one for the extra cleanup of
> > sunxi_defconfg) as I was asked to do for my other patch for
> > multi_v7_defconfig?
> 
> Yes, please do.

Ok.

> 
> Also why CONFIG_PM CONFIG_KEYBOARD_SUN4I_LRADC and CONFIG_HIGHPTE got
> removed ?

CONFIG_HIGHPTE defaults to yes since 4.4-rc1 in arch/arm/Kconfig, so we
don't need it in sunxi_defconfig anymore. CONFIG_PM is already selected
by CONFIG_ARCH_MULTI_V7, so also no need to set that explicitly.

What's interesting is CONFIG_KEYBOARD_SUN4I_LRADC, because that actually
does _NOT_ get enabled by sunxi_defconfig. I didn't notice earlier,
because before and after my patch, the resulting .config was identical.

The problem with CONFIG_KEYBOARD_SUN4I_LRADC is that keyboard support is
explicitly disabled in sunxi_defconfig which is why
CONFIG_KEYBOARD_SUN4I_LRADC is simply ignored.
So, we need to remove the line
# CONFIG_INPUT_KEYBOARD is not set
in order to actually have CONFIG_KEYBOARD_SUN4I_LRADC enabled.

I'll write another patch for it.

Regards,

Timo
> 
> Thanks,
> Maxime
> 



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

Re: [PATCH v2 1/3] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Sorry, I probably shouldn't send patches at an hour I should rather be
sleeping... As a result, I forgot to add the patch history.

Here it is:

Changes in v2:
- Move the extra cleanup work for sunxi_defconfig to a separate patch
- Add another patch to meet the dependencies of
  CONFIG_KEYBOARD_SUN4I_LRADC and not have it removed while cleaning up


Good night,

Timo

Am Freitag, den 20.11.2015, 02:46 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
> 
> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> ---
>  arch/arm/configs/sunxi_defconfig | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..0bbc2ee 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -37,7 +37,6 @@ CONFIG_CAN_SUN4I=y
>  # CONFIG_WIRELESS is not set
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_AHCI_SUNXI=y
> @@ -123,6 +122,8 @@ CONFIG_PWM=y
>  CONFIG_PWM_SUN4I=y
>  CONFIG_PHY_SUN4I_USB=y
>  CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y


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

[PATCH v2] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbol NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
Changes in v2:
- Move the extra cleanup work for multi_v7_defconfig to a separate
  patch (to be submitted at a later point to avoid conflicts with
  another patch waiting to be merged)
---
 arch/arm/configs/multi_v7_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index eefcab1..59d3d3a 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -188,7 +188,6 @@ CONFIG_ATMEL_SSC=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
 CONFIG_SCSI_MULTI_LUN=y
@@ -714,6 +713,8 @@ CONFIG_PHY_STIH407_USB=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
 CONFIG_PHY_SAMSUNG_USB2=m
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_AUTOFS4_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.1.4

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Hi Maxime,
Hi Chen-Yu,

Am Dienstag, den 17.11.2015, 02:42 +0100 schrieb Timo Sigurdsson:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> in sunxi_defconfig.
> 
> While at it, clean up sunxi_defconfig by generating a fresh file via
>   make sunxi_defconfig
>   make savedefconfig
> While this moves around a few lines and removes unnecessary symbols,
> it doesn't introduce any functional changes.
> 
> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> 
> diff --git a/arch/arm/configs/sunxi_defconfig 
> b/arch/arm/configs/sunxi_defconfig
> index 3c36e16..904ea52 100644
> --- a/arch/arm/configs/sunxi_defconfig
> +++ b/arch/arm/configs/sunxi_defconfig
> @@ -11,14 +11,12 @@ CONFIG_SMP=y
>  CONFIG_NR_CPUS=8
>  CONFIG_AEABI=y
>  CONFIG_HIGHMEM=y
> -CONFIG_HIGHPTE=y
>  CONFIG_ARM_APPENDED_DTB=y
>  CONFIG_ARM_ATAG_DTB_COMPAT=y
>  CONFIG_CPU_FREQ=y
>  CONFIG_CPUFREQ_DT=y
>  CONFIG_VFP=y
>  CONFIG_NEON=y
> -CONFIG_PM=y
>  CONFIG_NET=y
>  CONFIG_PACKET=y
>  CONFIG_UNIX=y
> @@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
>  # CONFIG_WIRELESS is not set
>  CONFIG_DEVTMPFS=y
>  CONFIG_DEVTMPFS_MOUNT=y
> -CONFIG_EEPROM_SUNXI_SID=y
>  CONFIG_BLK_DEV_SD=y
>  CONFIG_ATA=y
>  CONFIG_AHCI_SUNXI=y
> @@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
>  # CONFIG_INPUT_MOUSEDEV is not set
>  # CONFIG_INPUT_KEYBOARD is not set
>  # CONFIG_INPUT_MOUSE is not set
> -CONFIG_INPUT_MISC=y
> -CONFIG_INPUT_AXP20X_PEK=y
>  CONFIG_INPUT_TOUCHSCREEN=y
> -CONFIG_KEYBOARD_SUN4I_LRADC=y
>  CONFIG_TOUCHSCREEN_SUN4I=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_AXP20X_PEK=y
>  CONFIG_SERIAL_8250=y
>  CONFIG_SERIAL_8250_CONSOLE=y
>  CONFIG_SERIAL_8250_NR_UARTS=8
> @@ -123,6 +119,8 @@ CONFIG_PWM=y
>  CONFIG_PWM_SUN4I=y
>  CONFIG_PHY_SUN4I_USB=y
>  CONFIG_PHY_SUN9I_USB=y
> +CONFIG_NVMEM=y
> +CONFIG_NVMEM_SUNXI_SID=y
>  CONFIG_EXT4_FS=y
>  CONFIG_VFAT_FS=y
>  CONFIG_TMPFS=y

Would you also prefer to see this patch split up into two patches (one
for re-enabling the SID driver and one for the extra cleanup of
sunxi_defconfg) as I was asked to do for my other patch for
multi_v7_defconfig?


Thanks,

Timo

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Krzysztof Kozlowski schrieb am 17.11.2015 09:21:

[...]

>>> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
>>> >  CONFIG_MEDIA_CONTROLLER=y
>>> >  CONFIG_VIDEO_V4L2_SUBDEV_API=y
>>> >  CONFIG_MEDIA_USB_SUPPORT=y
>>> > -CONFIG_USB_VIDEO_CLASS=y
>>> > -CONFIG_USB_GSPCA=y
>>> > +CONFIG_USB_VIDEO_CLASS=m
>>> >  CONFIG_V4L_PLATFORM_DRIVERS=y
>>> >  CONFIG_SOC_CAMERA=m
>>> >  CONFIG_SOC_CAMERA_PLATFORM=m
>>> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
>>> >  CONFIG_DRM_I2C_ADV7511=m
>>> >  # CONFIG_DRM_I2C_CH7006 is not set
>>> >  # CONFIG_DRM_I2C_SIL164 is not set
>>> > -CONFIG_DRM_NXP_PTN3460=m
>>> > -CONFIG_DRM_PARADE_PS8622=m
>>> >  CONFIG_DRM_NOUVEAU=m
>>> >  CONFIG_DRM_EXYNOS=m
>>> > -CONFIG_DRM_EXYNOS_DSI=y
>>> >  CONFIG_DRM_EXYNOS_FIMD=y
>>> > -CONFIG_DRM_EXYNOS_HDMI=y
>>>
>>> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
>>> but we are fixing it in:
>>> http://www.spinics.net/lists/dri-devel/msg93299.html
>>
>> I think the problem here is that I don't see this patch in linux-next
>> yet.
>>
> 
> Indeed... and I don't know when it will go there so actually maybe it
> should be removed... but in the same time removing DRM_EXYNOS_HDMI
> will probably make some conflicts because mentioned patch will go
> through Exynos DRM tree or Samsung SoC.

Since you suggested to split my patch into two, I might as well just
hold off the "cleanup" patch until Andrzejs patch hits linux-next.
Is that ok?


Regards,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Lee Jones schrieb am 17.11.2015 09:07:

> On Tue, 17 Nov 2015, Timo Sigurdsson wrote:
> 
>> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
>> framework") moved the the sunxi SID driver to a new framework, but left
>> multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
>> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
>> in multi_v7_defconfig.
>> 
>> While at it, clean up multi_v7_defconfig by generating a fresh file via
>>   make multi_v7_defconfig
>>   make savedefconfig
>> While this moves around a few lines and removes unnecessary symbols,
>> it doesn't introduce any functional changes.
>> 
>> Signed-off-by: Timo Sigurdsson 
> 
> Please either use Git to submit your changes, or add a diffstat in
> manually.  They *are* helpful.

I do use git. But I guess I messed up the command somehow so the diffstat
wasn't included. Sorry about that. I'll make sure it's there next time.


Thanks,

Timo


[...]

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Am Dienstag, den 17.11.2015, 11:10 +0900 schrieb Krzysztof Kozlowski:
> On 17.11.2015 10:49, Timo Sigurdsson wrote:
> > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> > framework") moved the the sunxi SID driver to a new framework, but left
> > multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> > in multi_v7_defconfig.
> > 
> > While at it, clean up multi_v7_defconfig by generating a fresh file via
> >   make multi_v7_defconfig
> >   make savedefconfig
> > While this moves around a few lines and removes unnecessary symbols,
> > it doesn't introduce any functional changes.
> 
> Split it per change. One change is savedefconfig and second is removing
> or enabling other drivers.
Ok, I can do that.

> 
> On which tree you generated the defconfig? There is a minor nit below
> (at least for Exynos platform, I did not checked the others).

The patch was based on torvalds/master (at v4.4-rc1), but I checked
and it applies on linux-next/master just fine.

> 
> > 
> > Signed-off-by: Timo Sigurdsson 
> > 
> > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > b/arch/arm/configs/multi_v7_defconfig
> > index 69a22fd..f712ea3 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> 
> (...)
> 
> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
> >  CONFIG_MEDIA_CONTROLLER=y
> >  CONFIG_VIDEO_V4L2_SUBDEV_API=y
> >  CONFIG_MEDIA_USB_SUPPORT=y
> > -CONFIG_USB_VIDEO_CLASS=y
> > -CONFIG_USB_GSPCA=y
> > +CONFIG_USB_VIDEO_CLASS=m
> >  CONFIG_V4L_PLATFORM_DRIVERS=y
> >  CONFIG_SOC_CAMERA=m
> >  CONFIG_SOC_CAMERA_PLATFORM=m
> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
> >  CONFIG_DRM_I2C_ADV7511=m
> >  # CONFIG_DRM_I2C_CH7006 is not set
> >  # CONFIG_DRM_I2C_SIL164 is not set
> > -CONFIG_DRM_NXP_PTN3460=m
> > -CONFIG_DRM_PARADE_PS8622=m
> >  CONFIG_DRM_NOUVEAU=m
> >  CONFIG_DRM_EXYNOS=m
> > -CONFIG_DRM_EXYNOS_DSI=y
> >  CONFIG_DRM_EXYNOS_FIMD=y
> > -CONFIG_DRM_EXYNOS_HDMI=y
> 
> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
> but we are fixing it in:
> http://www.spinics.net/lists/dri-devel/msg93299.html

I think the problem here is that I don't see this patch in linux-next
yet.

Regards,

Timo


[...]




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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Lee Jones schrieb am 17.11.2015 09:07:

> On Tue, 17 Nov 2015, Timo Sigurdsson wrote:
> 
>> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
>> framework") moved the the sunxi SID driver to a new framework, but left
>> multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
>> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
>> in multi_v7_defconfig.
>> 
>> While at it, clean up multi_v7_defconfig by generating a fresh file via
>>   make multi_v7_defconfig
>>   make savedefconfig
>> While this moves around a few lines and removes unnecessary symbols,
>> it doesn't introduce any functional changes.
>> 
>> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> 
> Please either use Git to submit your changes, or add a diffstat in
> manually.  They *are* helpful.

I do use git. But I guess I messed up the command somehow so the diffstat
wasn't included. Sorry about that. I'll make sure it's there next time.


Thanks,

Timo


[...]

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

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Krzysztof Kozlowski schrieb am 17.11.2015 09:21:

[...]

>>> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
>>> >  CONFIG_MEDIA_CONTROLLER=y
>>> >  CONFIG_VIDEO_V4L2_SUBDEV_API=y
>>> >  CONFIG_MEDIA_USB_SUPPORT=y
>>> > -CONFIG_USB_VIDEO_CLASS=y
>>> > -CONFIG_USB_GSPCA=y
>>> > +CONFIG_USB_VIDEO_CLASS=m
>>> >  CONFIG_V4L_PLATFORM_DRIVERS=y
>>> >  CONFIG_SOC_CAMERA=m
>>> >  CONFIG_SOC_CAMERA_PLATFORM=m
>>> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
>>> >  CONFIG_DRM_I2C_ADV7511=m
>>> >  # CONFIG_DRM_I2C_CH7006 is not set
>>> >  # CONFIG_DRM_I2C_SIL164 is not set
>>> > -CONFIG_DRM_NXP_PTN3460=m
>>> > -CONFIG_DRM_PARADE_PS8622=m
>>> >  CONFIG_DRM_NOUVEAU=m
>>> >  CONFIG_DRM_EXYNOS=m
>>> > -CONFIG_DRM_EXYNOS_DSI=y
>>> >  CONFIG_DRM_EXYNOS_FIMD=y
>>> > -CONFIG_DRM_EXYNOS_HDMI=y
>>>
>>> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
>>> but we are fixing it in:
>>> http://www.spinics.net/lists/dri-devel/msg93299.html
>>
>> I think the problem here is that I don't see this patch in linux-next
>> yet.
>>
> 
> Indeed... and I don't know when it will go there so actually maybe it
> should be removed... but in the same time removing DRM_EXYNOS_HDMI
> will probably make some conflicts because mentioned patch will go
> through Exynos DRM tree or Samsung SoC.

Since you suggested to split my patch into two, I might as well just
hold off the "cleanup" patch until Andrzejs patch hits linux-next.
Is that ok?


Regards,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Hi,

Am Dienstag, den 17.11.2015, 11:10 +0900 schrieb Krzysztof Kozlowski:
> On 17.11.2015 10:49, Timo Sigurdsson wrote:
> > Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> > framework") moved the the sunxi SID driver to a new framework, but left
> > multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> > instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> > in multi_v7_defconfig.
> > 
> > While at it, clean up multi_v7_defconfig by generating a fresh file via
> >   make multi_v7_defconfig
> >   make savedefconfig
> > While this moves around a few lines and removes unnecessary symbols,
> > it doesn't introduce any functional changes.
> 
> Split it per change. One change is savedefconfig and second is removing
> or enabling other drivers.
Ok, I can do that.

> 
> On which tree you generated the defconfig? There is a minor nit below
> (at least for Exynos platform, I did not checked the others).

The patch was based on torvalds/master (at v4.4-rc1), but I checked
and it applies on linux-next/master just fine.

> 
> > 
> > Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
> > 
> > diff --git a/arch/arm/configs/multi_v7_defconfig 
> > b/arch/arm/configs/multi_v7_defconfig
> > index 69a22fd..f712ea3 100644
> > --- a/arch/arm/configs/multi_v7_defconfig
> > +++ b/arch/arm/configs/multi_v7_defconfig
> 
> (...)
> 
> > @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
> >  CONFIG_MEDIA_CONTROLLER=y
> >  CONFIG_VIDEO_V4L2_SUBDEV_API=y
> >  CONFIG_MEDIA_USB_SUPPORT=y
> > -CONFIG_USB_VIDEO_CLASS=y
> > -CONFIG_USB_GSPCA=y
> > +CONFIG_USB_VIDEO_CLASS=m
> >  CONFIG_V4L_PLATFORM_DRIVERS=y
> >  CONFIG_SOC_CAMERA=m
> >  CONFIG_SOC_CAMERA_PLATFORM=m
> > @@ -465,28 +445,25 @@ CONFIG_DRM=y
> >  CONFIG_DRM_I2C_ADV7511=m
> >  # CONFIG_DRM_I2C_CH7006 is not set
> >  # CONFIG_DRM_I2C_SIL164 is not set
> > -CONFIG_DRM_NXP_PTN3460=m
> > -CONFIG_DRM_PARADE_PS8622=m
> >  CONFIG_DRM_NOUVEAU=m
> >  CONFIG_DRM_EXYNOS=m
> > -CONFIG_DRM_EXYNOS_DSI=y
> >  CONFIG_DRM_EXYNOS_FIMD=y
> > -CONFIG_DRM_EXYNOS_HDMI=y
> 
> I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
> but we are fixing it in:
> http://www.spinics.net/lists/dri-devel/msg93299.html

I think the problem here is that I don't see this patch in linux-next
yet.

Regards,

Timo


[...]




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

[PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.

While at it, clean up multi_v7_defconfig by generating a fresh file via
  make multi_v7_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson 

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..f712ea3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,7 +12,6 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -20,6 +19,7 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_39X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_AT91=y
 CONFIG_SOC_SAMA5D2=y
 CONFIG_SOC_SAMA5D3=y
@@ -27,9 +27,9 @@ CONFIG_SOC_SAMA5D4=y
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM_CYGNUS=y
 CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
 CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_MACH_BERLIN_BG2=y
@@ -39,9 +39,9 @@ CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_KEYSTONE=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MXC=y
@@ -53,8 +53,9 @@ CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_IMX6SX=y
 CONFIG_SOC_IMX6UL=y
 CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
 CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
@@ -62,7 +63,6 @@ CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_SOC_DRA7XX=y
 CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
 CONFIG_ARCH_MSM8974=y
@@ -94,30 +94,22 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_KEYSTONE=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_MVEBU=y
 CONFIG_PCI_TEGRA=y
 CONFIG_PCI_RCAR_GEN2=y
 CONFIG_PCI_RCAR_GEN2_PCIE=y
-CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_KEYSTONE=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
 CONFIG_CMA=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -125,12 +117,12 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
 CONFIG_CPU_IDLE=y
 CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
 CONFIG_ARM_ZYNQ_CPUIDLE=y
 CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -148,13 +140,10 @@ CONFIG_IPV6_MIP6=m
 CONFIG_IPV6_TUNNEL=m
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
 CONFIG_CAN_AT91=m
+CONFIG_CAN_SUN4I=y
 CONFIG_CAN_XILINXCAN=y
 CONFIG_CAN_MCP251X=y
-CONFIG_CAN_SUN4I=y
 CONFIG_BT=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m
@@ -188,10 +177,8 @@ CONFIG_ATMEL_SSC=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
 CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -202,10 +189,10 @@ CONFIG_SATA_HIGHBANK=y
 CONFIG_SATA_MV=y
 CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
-CONFIG_HIX5HD2_GMAC=y
 CONFIG_SUN4I_EMAC=y
 CONFIG_MACB=y
 CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_HIX5HD2_GMAC=y
 CONFIG_IGB=y
 CONFIG_MV643XX_ETH=y
 CONFIG_MVNETA=y
@@ -223,7 +210,6 @@ CONFIG_SMSC_PHY=y
 CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
 CONFIG_USB_PEGASUS=y
 CONFIG_USB_RTL8152=m
 CONFIG_USB_USBNET=y
@@ -239,18 +225,18 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_QT1070=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_MOUSE_CYAPA=m
 CONFIG_MOUSE_ELAN_I2C=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=y
+CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_TOUCHSCREEN_ST1232=m
 CONFIG_TOUCHSCREEN_STMPE=y
 CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
 CONFIG_INPUT_AXP20X_PEK=y
@@ -295,

[PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.

While at it, clean up sunxi_defconfig by generating a fresh file via
  make sunxi_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson 

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..904ea52 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_VFP=y
 CONFIG_NEON=y
-CONFIG_PM=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
 CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
@@ -123,6 +119,8 @@ CONFIG_PWM=y
 CONFIG_PWM_SUN4I=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.1.4

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

[PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.

While at it, clean up sunxi_defconfig by generating a fresh file via
  make sunxi_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..904ea52 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_VFP=y
 CONFIG_NEON=y
-CONFIG_PM=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
 CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
@@ -123,6 +119,8 @@ CONFIG_PWM=y
 CONFIG_PWM_SUN4I=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.1.4

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

[PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.

While at it, clean up multi_v7_defconfig by generating a fresh file via
  make multi_v7_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..f712ea3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,7 +12,6 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -20,6 +19,7 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_39X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_AT91=y
 CONFIG_SOC_SAMA5D2=y
 CONFIG_SOC_SAMA5D3=y
@@ -27,9 +27,9 @@ CONFIG_SOC_SAMA5D4=y
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM_CYGNUS=y
 CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
 CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_MACH_BERLIN_BG2=y
@@ -39,9 +39,9 @@ CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_KEYSTONE=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MXC=y
@@ -53,8 +53,9 @@ CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_IMX6SX=y
 CONFIG_SOC_IMX6UL=y
 CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
 CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
@@ -62,7 +63,6 @@ CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_SOC_DRA7XX=y
 CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
 CONFIG_ARCH_MSM8974=y
@@ -94,30 +94,22 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_KEYSTONE=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_MVEBU=y
 CONFIG_PCI_TEGRA=y
 CONFIG_PCI_RCAR_GEN2=y
 CONFIG_PCI_RCAR_GEN2_PCIE=y
-CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_KEYSTONE=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
 CONFIG_CMA=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -125,12 +117,12 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
 CONFIG_CPU_IDLE=y
 CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
 CONFIG_ARM_ZYNQ_CPUIDLE=y
 CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -148,13 +140,10 @@ CONFIG_IPV6_MIP6=m
 CONFIG_IPV6_TUNNEL=m
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
 CONFIG_CAN_AT91=m
+CONFIG_CAN_SUN4I=y
 CONFIG_CAN_XILINXCAN=y
 CONFIG_CAN_MCP251X=y
-CONFIG_CAN_SUN4I=y
 CONFIG_BT=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m
@@ -188,10 +177,8 @@ CONFIG_ATMEL_SSC=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
 CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -202,10 +189,10 @@ CONFIG_SATA_HIGHBANK=y
 CONFIG_SATA_MV=y
 CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
-CONFIG_HIX5HD2_GMAC=y
 CONFIG_SUN4I_EMAC=y
 CONFIG_MACB=y
 CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_HIX5HD2_GMAC=y
 CONFIG_IGB=y
 CONFIG_MV643XX_ETH=y
 CONFIG_MVNETA=y
@@ -223,7 +210,6 @@ CONFIG_SMSC_PHY=y
 CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
 CONFIG_USB_PEGASUS=y
 CONFIG_USB_RTL8152=m
 CONFIG_USB_USBNET=y
@@ -239,18 +225,18 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_QT1070=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_MOUSE_CYAPA=m
 CONFIG_MOUSE_ELAN_I2C=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=y
+CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_TOUCHSCREEN_ST1232=m
 CONFIG_TOUCHSCREEN_STMPE=y
 CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
 CONFIG_INPUT_AXP20X_PEK=y
@@

[PATCH v3] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.

Signed-off-by: Timo Sigurdsson 
---
Changes since v2:

- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+   operating-points = <
+   /* kHzuV */
+   96  140
+   912000  140
+   864000  135
+   72  125
+   528000  115
+   312000  110
+   144000  105
+   >;
+};
+
  {
status = "okay";
 };
@@ -119,13 +133,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
};
 };
 
@@ -182,6 +192,33 @@
};
 };
 
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 _usb1_vbus {
status = "okay";
 };
-- 
2.1.4

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

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 07.10.2015 19:49:

> Hi Timo,
> 
> On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
>> Hi Kevin,
>> Hi Maxime,
>> 
>> Kevin Hilman schrieb am 07.10.2015 16:36:
>> 
>> > "Timo Sigurdsson"  writes:
>> >> I still think that the lower voltages may be the cause of your problem
>> >> with that specific board, so could you please test the attached patch on
>> >> top of my patch that you first experienced the problem with? Please let 
>> >> us know whether this solves your issue or whether we need to dig deeper.
>> > 
>> > Thanks for the patch.  Looks like it's the OPPs.
>> > 
>> > I went back to next-20150923 and verified it still fails.  Then, I
>> > applied your patch and saw that it boots just fine.
>> 
>> Good. Then we can easily fix this, I guess.
>> 
>> @Maxime: How should we handle this? In its current form, the patch applies
>> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
>> In an earlier discussion, it was said that this can be done, even though it
>> might not be the most elegant approach. But then again, I think it
>> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
>> boards since this is - to my knowledge - the first and only report that an
>> A20 board has stability issues at the lower voltages (although not too many
>> boards use voltage scaling yet).
> 
> If you count only the number of boards, indeed, but if you count the
> number of devices actually used in the field, we cover already a
> significant portion of them.
> 
>> So, would you prefer to keep this as a patch for BananaPi only, or
>> change the dtsi for all A20 devices instead?
> 
> Yeah, we probably can keep that for bananapi only at the moment, and
> try to generalize that afterwards.

Ok.

> 
>> In case we keep it as it is, what is the correct commit to point to as
>> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
>> that's where these voltages were defined. But then again, if we don't
>> change the dtsi, should I point to my regulator patch instead?
> 
> I don't think it fixes anything at this point. We droped your commit
> that was using the A20 OPPs, so in the history so far we don't have
> anything to fix, just enable cpufreq again.

Ok. I'll send a third version of the regulator patch then with the
updated opp included.

Thanks,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,
Hi Maxime,

Kevin Hilman schrieb am 07.10.2015 16:36:

> "Timo Sigurdsson"  writes:
>> I still think that the lower voltages may be the cause of your problem
>> with that specific board, so could you please test the attached patch on
>> top of my patch that you first experienced the problem with? Please let 
>> us know whether this solves your issue or whether we need to dig deeper.
> 
> Thanks for the patch.  Looks like it's the OPPs.
> 
> I went back to next-20150923 and verified it still fails.  Then, I
> applied your patch and saw that it boots just fine.

Good. Then we can easily fix this, I guess.

@Maxime: How should we handle this? In its current form, the patch applies
only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
In an earlier discussion, it was said that this can be done, even though it
might not be the most elegant approach. But then again, I think it
shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
boards since this is - to my knowledge - the first and only report that an
A20 board has stability issues at the lower voltages (although not too many
boards use voltage scaling yet). So, would you prefer to keep this as a
patch for BananaPi only, or change the dtsi for all A20 devices instead?

In case we keep it as it is, what is the correct commit to point to as
"Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
that's where these voltages were defined. But then again, if we don't
change the dtsi, should I point to my regulator patch instead?


Thanks and regards,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt. Also
add board-specific OPP to use slightly higher voltages at lower
frequencies since Kevin Hilman reported that not all BananaPi boards run
stable at the default voltages inherited by sun7i-a20.dtsi.

Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
---
Changes since v2:

- (Re)Added board-specific OPP after Kevin Hilman reported problems with
the default voltages at lower frequencies
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 45 +---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,20 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+   operating-points = <
+   /* kHzuV */
+   96  140
+   912000  140
+   864000  135
+   72  125
+   528000  115
+   312000  110
+   144000  105
+   >;
+};
+
  {
status = "okay";
 };
@@ -119,13 +133,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
};
 };
 
@@ -182,6 +192,33 @@
};
 };
 
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 _usb1_vbus {
status = "okay";
 };
-- 
2.1.4

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

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,
Hi Maxime,

Kevin Hilman schrieb am 07.10.2015 16:36:

> "Timo Sigurdsson" <public_tim...@silentcreek.de> writes:
>> I still think that the lower voltages may be the cause of your problem
>> with that specific board, so could you please test the attached patch on
>> top of my patch that you first experienced the problem with? Please let 
>> us know whether this solves your issue or whether we need to dig deeper.
> 
> Thanks for the patch.  Looks like it's the OPPs.
> 
> I went back to next-20150923 and verified it still fails.  Then, I
> applied your patch and saw that it boots just fine.

Good. Then we can easily fix this, I guess.

@Maxime: How should we handle this? In its current form, the patch applies
only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
In an earlier discussion, it was said that this can be done, even though it
might not be the most elegant approach. But then again, I think it
shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
boards since this is - to my knowledge - the first and only report that an
A20 board has stability issues at the lower voltages (although not too many
boards use voltage scaling yet). So, would you prefer to keep this as a
patch for BananaPi only, or change the dtsi for all A20 devices instead?

In case we keep it as it is, what is the correct commit to point to as
"Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
that's where these voltages were defined. But then again, if we don't
change the dtsi, should I point to my regulator patch instead?


Thanks and regards,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 07.10.2015 19:49:

> Hi Timo,
> 
> On Wed, Oct 07, 2015 at 05:49:18PM +0200, Timo Sigurdsson wrote:
>> Hi Kevin,
>> Hi Maxime,
>> 
>> Kevin Hilman schrieb am 07.10.2015 16:36:
>> 
>> > "Timo Sigurdsson" <public_tim...@silentcreek.de> writes:
>> >> I still think that the lower voltages may be the cause of your problem
>> >> with that specific board, so could you please test the attached patch on
>> >> top of my patch that you first experienced the problem with? Please let 
>> >> us know whether this solves your issue or whether we need to dig deeper.
>> > 
>> > Thanks for the patch.  Looks like it's the OPPs.
>> > 
>> > I went back to next-20150923 and verified it still fails.  Then, I
>> > applied your patch and saw that it boots just fine.
>> 
>> Good. Then we can easily fix this, I guess.
>> 
>> @Maxime: How should we handle this? In its current form, the patch applies
>> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
>> In an earlier discussion, it was said that this can be done, even though it
>> might not be the most elegant approach. But then again, I think it
>> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
>> boards since this is - to my knowledge - the first and only report that an
>> A20 board has stability issues at the lower voltages (although not too many
>> boards use voltage scaling yet).
> 
> If you count only the number of boards, indeed, but if you count the
> number of devices actually used in the field, we cover already a
> significant portion of them.
> 
>> So, would you prefer to keep this as a patch for BananaPi only, or
>> change the dtsi for all A20 devices instead?
> 
> Yeah, we probably can keep that for bananapi only at the moment, and
> try to generalize that afterwards.

Ok.

> 
>> In case we keep it as it is, what is the correct commit to point to as
>> "Fixes commit ..."? I'd say it fixes the initial opp commit for A20, since
>> that's where these voltages were defined. But then again, if we don't
>> change the dtsi, should I point to my regulator patch instead?
> 
> I don't think it fixes anything at this point. We droped your commit
> that was using the A20 OPPs, so in the history so far we don't have
> anything to fix, just enable cpufreq again.

Ok. I'll send a third version of the regulator patch then with the
updated opp included.

Thanks,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html

following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.

I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let 
us know whether this solves your issue or whether we need to dig deeper.

Has anybody else been able to reproduce Kevin's issue?

Kind regards,

Timodiff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
 
  {
 	cpu-supply = <_dcdc2>;
+	operating-points = <
+		/* kHz	  uV */
+		96	140
+		912000	140
+		864000	135
+		72	125
+		528000	115
+		312000	110
+		144000	105
+		>;
 };
 
  {
-- 
2.1.4

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 24.09.2015 19:57:
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html

following up on my last email: I'm back from my vacation and I tried to
reproduce your problem, but my board doesn't seem to be affected, so I
cannot trigger it.

I still think that the lower voltages may be the cause of your problem
with that specific board, so could you please test the attached patch on
top of my patch that you first experienced the problem with? Please let 
us know whether this solves your issue or whether we need to dig deeper.

Has anybody else been able to reproduce Kevin's issue?

Kind regards,

Timodiff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 74382f3..39b6b67b 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -94,6 +94,16 @@
 
  {
 	cpu-supply = <_dcdc2>;
+	operating-points = <
+		/* kHz	  uV */
+		96	140
+		912000	140
+		864000	135
+		72	125
+		528000	115
+		312000	110
+		144000	105
+		>;
 };
 
  {
-- 
2.1.4

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 25. Sept 2015 01:57:

> On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard
>  wrote:
>> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote:
>>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209
>>> PMU
>>> driver, so add them to allow for voltage-scaling with cpufreq-dt.
>>>
>>> Signed-off-by: Timo Sigurdsson 
>>
>> Queued, thanks!
>> Maxime
> 
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
> 

Thanks for your feedback. I'm traveling at the moment, so I can't do any 
testing but just guess wildly. I know, though, that I used dmesg frequently 
when I did my own testing before submitting the patch and could not see such 
behavior.

Before this commit, the CPU of your BananaPi runs at 1.4 volts constantly. With 
this commit applied, the CPU voltage should vary between 1.0-1.4 volts 
depending on the frequency and defined operating points. Hence, one of my 
guesses would be that your CPU is not stable at the lower voltages. Could you 
modify the voltages for the defined frequencies in sun7i-a20.dtsi and test if 
that solves your issue? Say, raise the voltage by 0.1 volts for each operating 
point (but no higher than 1.4). I actually had a different patch that applied 
slightly higher voltages taken from the original fex for by LeMaker, but the 
feedback was, unless there are actual reports about boards not running stable 
at the current settings, we just keep them instead. So, I'm curious if you 
happen to have a board that requires slightly higher voltages to run stable.

Regards, 

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 25. Sept 2015 01:57:

> On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard
> <maxime.rip...@free-electrons.com> wrote:
>> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote:
>>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209
>>> PMU
>>> driver, so add them to allow for voltage-scaling with cpufreq-dt.
>>>
>>> Signed-off-by: Timo Sigurdsson <public_tim...@silentcreek.de>
>>
>> Queued, thanks!
>> Maxime
> 
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
> 

Thanks for your feedback. I'm traveling at the moment, so I can't do any 
testing but just guess wildly. I know, though, that I used dmesg frequently 
when I did my own testing before submitting the patch and could not see such 
behavior.

Before this commit, the CPU of your BananaPi runs at 1.4 volts constantly. With 
this commit applied, the CPU voltage should vary between 1.0-1.4 volts 
depending on the frequency and defined operating points. Hence, one of my 
guesses would be that your CPU is not stable at the lower voltages. Could you 
modify the voltages for the defined frequencies in sun7i-a20.dtsi and test if 
that solves your issue? Say, raise the voltage by 0.1 volts for each operating 
point (but no higher than 1.4). I actually had a different patch that applied 
slightly higher voltages taken from the original fex for by LeMaker, but the 
feedback was, unless there are actual reports about boards not running stable 
at the current settings, we just keep them instead. So, I'm curious if you 
happen to have a board that requires slightly higher voltages to run stable.

Regards, 

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications

[Timo Sigurdsson]

sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum
CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise
the voltage for the lowest operating point to 1.0 volts in order to stay
within the SoC specifications. It is an undervolted setting that isn't
stable across all SoCs and boards out there.

Signed-off-by: Timo Sigurdsson 
---
Changes since v1:

- Fixed checkpatch warnings
- Changed the commit message and title to clarify that this is not a 
board-specific issue, but rather a limitation by the SoC  
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6a63f30..f5f384c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -107,7 +107,7 @@
72  120
528000  110
312000  100
-   144000  90
+   144000  100
>;
#cooling-cells = <2>;
cooling-min-level = <0>;
-- 
2.1.4

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

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:47:
> What regulator provides the 3.3V regulator used in the rest of this DT
> then (MMC, GMAC) ?

For GMAC, there is a reg_gmac_3v3 defined in sun7i-a20-bananapi.dts [1].
MMC uses reg_vcc3v3 included from sunxi-common-regulators.dtsi. Am I
missing something? Is this not sufficient?


Thanks,

Timo

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=v4.2-rc5#n78
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:34:

> On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
>> Julian Calaby schrieb am 03.08.2015 06:22:
>> > My only real objection here is are there boards that can go down to
>> > 0.9v and if so, won't this change make them less power efficient in
>> > the almost-idle case? And are those power savings enough to justify
>> > not accepting this patch?
>> 
>> It will probably make those boards less power efficient, yes. On the
>> other hand, boards that have their CPU regulator set to min. 1.0V might
>> also draw more power because the lowest frequency is not available, 
>> even though the savings due to frequency are likely to be lower than
>> the savings due to voltage.
> 
> Guys, isn't this whole discussion a bit moot? We're not doing any kind
> of power management but cpufreq, so maybe there's a lot more to do
> before we actually can have these kind of arguments?
> 
> Plus this OPP has never been used anyway, so this patch is not going
> to increase the power consumption either.

You are right. When I wrote that, I was under the impression that the
Olinuxino Lime 2 board at least used this setting since it has has a cpu
regulator defined to go as low as 0.7V. But now I checked again and see
the regulator is not referenced in the cpu node, so I guess cpufreq
doesn't use it. So, this discussion was really hypothetical and more
importantly, as you mentioned, it's an out-of-spec opp that shouldn't
be supported anyway.

Thanks,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:13:
> On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
>> boards
>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise 
>> the
>> voltage for the lowest operating point to 1.0V so all boards can actually use
>> it.
> 
> This is not a property of a board, but is the actual limit documented
> by Allwinner for the A20. Some individual SoCs might have wider
> tolerances, but that's not a property of a board, it's really a
> property of a single SoC, and we cannot make any assumption on the
> board.

Thanks for the clarification. That was a misunderstanding on my side. I can 
update the commit message in a second version of the patch, but the actual
code change can be kept as is then, I guess.

> (and please make sure to run checkpatch before sending your patches)

Sorry about that. Will do when I post a second version of the patch.

Thanks,

Timo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:13:
 On Sun, Aug 02, 2015 at 09:23:06PM +0200, Timo Sigurdsson wrote:
 sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20
 boards
 (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise 
 the
 voltage for the lowest operating point to 1.0V so all boards can actually use
 it.
 
 This is not a property of a board, but is the actual limit documented
 by Allwinner for the A20. Some individual SoCs might have wider
 tolerances, but that's not a property of a board, it's really a
 property of a single SoC, and we cannot make any assumption on the
 board.

Thanks for the clarification. That was a misunderstanding on my side. I can 
update the commit message in a second version of the patch, but the actual
code change can be kept as is then, I guess.

 (and please make sure to run checkpatch before sending your patches)

Sorry about that. Will do when I post a second version of the patch.

Thanks,

Timo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:34:

 On Mon, Aug 03, 2015 at 11:03:52AM +0200, Timo Sigurdsson wrote:
 Julian Calaby schrieb am 03.08.2015 06:22:
  My only real objection here is are there boards that can go down to
  0.9v and if so, won't this change make them less power efficient in
  the almost-idle case? And are those power savings enough to justify
  not accepting this patch?
 
 It will probably make those boards less power efficient, yes. On the
 other hand, boards that have their CPU regulator set to min. 1.0V might
 also draw more power because the lowest frequency is not available, 
 even though the savings due to frequency are likely to be lower than
 the savings due to voltage.
 
 Guys, isn't this whole discussion a bit moot? We're not doing any kind
 of power management but cpufreq, so maybe there's a lot more to do
 before we actually can have these kind of arguments?
 
 Plus this OPP has never been used anyway, so this patch is not going
 to increase the power consumption either.

You are right. When I wrote that, I was under the impression that the
Olinuxino Lime 2 board at least used this setting since it has has a cpu
regulator defined to go as low as 0.7V. But now I checked again and see
the regulator is not referenced in the cpu node, so I guess cpufreq
doesn't use it. So, this discussion was really hypothetical and more
importantly, as you mentioned, it's an out-of-spec opp that shouldn't
be supported anyway.

Thanks,

Timo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Maxime,

Maxime Ripard schrieb am 03.08.2015 11:47:
 What regulator provides the 3.3V regulator used in the rest of this DT
 then (MMC, GMAC) ?

For GMAC, there is a reg_gmac_3v3 defined in sun7i-a20-bananapi.dts [1].
MMC uses reg_vcc3v3 included from sunxi-common-regulators.dtsi. Am I
missing something? Is this not sufficient?


Thanks,

Timo

[1] 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=v4.2-rc5#n78
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to meet SoC specifications

[Timo Sigurdsson]

sun7i-a20.dtsi contains a cpufreq operating point at 0.9 volts. The minimum
CPU voltage for the Allwinner A20 SoC, however, is 1.0 volts. Thus, raise
the voltage for the lowest operating point to 1.0 volts in order to stay
within the SoC specifications. It is an undervolted setting that isn't
stable across all SoCs and boards out there.

Signed-off-by: Timo Sigurdsson public_tim...@silentcreek.de
---
Changes since v1:

- Fixed checkpatch warnings
- Changed the commit message and title to clarify that this is not a 
board-specific issue, but rather a limitation by the SoC  
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6a63f30..f5f384c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -107,7 +107,7 @@
72  120
528000  110
312000  100
-   144000  90
+   144000  100
;
#cooling-cells = 2;
cooling-min-level = 0;
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/