Hi Konrad,
can you send the first patch to Linus for inclusion in 4.15 if you
haven't already done so?
I'm still getting reports from people complaining about the error message.
Thanks,
Christian.
Am 16.01.2018 um 08:53 schrieb Christoph Hellwig:
I've pulled this into the dma-mapping for-ne
On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
> Hi Konrad,
>
> can you send the first patch to Linus for inclusion in 4.15 if you haven't
> already done so?
It's in the 4.16 queue with a cc to stable. I guess we're ok with
a duplicate commit if we have to.
Am 16.01.2018 um 09:28 schrieb Christoph Hellwig:
On Tue, Jan 16, 2018 at 09:22:52AM +0100, Christian König wrote:
Hi Konrad,
can you send the first patch to Linus for inclusion in 4.15 if you haven't
already done so?
It's in the 4.16 queue with a cc to stable. I guess we're ok with
a duplica
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
wrote:
maybe some small blurb here?
> Signed-off-by: Jonathan Neuschäfer
It looks good, very standard bindings.
Yours,
Linus Walleij
On Mon, Jan 15, 2018 at 06:18:10PM -0800, Deepa Dinamani wrote:
> All the current architecture specific defines for these
> are the same. Refactor these common defines to a common
> header file.
>
> The new common linux/compat_time.h is also useful as it
> will eventually be used to hold all the d
In case of TX timeout, fs_timeout() calls phy_stop(), which
triggers the following BUG_ON() as we are in interrupt.
[92708.199889] kernel BUG at drivers/net/phy/mdio_bus.c:482!
[92708.204985] Oops: Exception in kernel mode, sig: 5 [#1]
[92708.210119] PREEMPT
[92708.212107] CMPC885
[92708.214216] C
On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
wrote:
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissi
The recent commit 87590ce6e373 ("sysfs/cpu: Add vulnerability folder")
added a generic folder and set of files for reporting information on
CPU vulnerabilities. One of those was for meltdown:
/sys/devices/system/cpu/vulnerabilities/meltdown
This commit wires up that file for 64-bit Book3S power
Expose the state of the RFI flush (enabled/disabled) via debugfs, and
allow it to be enabled/disabled at runtime.
eg: $ cat /sys/kernel/debug/powerpc/rfi_flush
1
$ echo 0 > /sys/kernel/debug/powerpc/rfi_flush
$ cat /sys/kernel/debug/powerpc/rfi_flush
0
Signed-off-by: Michael Eller
On 12/01/2018 19:18, Matthew Wilcox wrote:
> On Fri, Jan 12, 2018 at 06:26:02PM +0100, Laurent Dufour wrote:
>> There is a deadlock when a CPU is doing a speculative page fault and
>> another one is calling do_unmap().
>>
>> The deadlock occurred because the speculative path try to spinlock the
>>
On Tue, 16 Jan 2018 22:24:31 +1100
Michael Ellerman wrote:
> Expose the state of the RFI flush (enabled/disabled) via debugfs, and
> allow it to be enabled/disabled at runtime.
>
> eg: $ cat /sys/kernel/debug/powerpc/rfi_flush
> 1
> $ echo 0 > /sys/kernel/debug/powerpc/rfi_flush
> $
On 13/01/2018 05:23, Matthew Wilcox wrote:
> On Fri, Jan 12, 2018 at 11:02:51AM -0800, Matthew Wilcox wrote:
>> On Fri, Jan 12, 2018 at 06:26:06PM +0100, Laurent Dufour wrote:
>>> @@ -1354,7 +1354,10 @@ extern int handle_mm_fault(struct vm_area_struct
>>> *vma, unsigned long address,
>>>
On Tue, Jan 16, 2018 at 03:47:51PM +0100, Laurent Dufour wrote:
> On 13/01/2018 05:23, Matthew Wilcox wrote:
> > Of course, we don't need to change them all. Try this:
>
> That would be good candidate for a clean up but I'm not sure this should be
> part of this already too long series.
>
> If y
> When i use mii-tool too Kick the tranceiver... it comes alive.. i can
> ping the eth0 itself
>
> root@X5000LNX:/home/skateman# mii-tool -R eth0
> resetting the transceiver...
> root@X5000LNX:/home/skateman# ping 192.168.22.44
> PING 192.168.22.44 (192.168.22.44) 56(84) bytes of data.
> 64 bytes
On Fri, Jan 12, 2018 at 06:25:44PM +0100, Laurent Dufour wrote:
> --
> Benchmarks results
>
> Base kernel is 4.15-rc6-mmotm-2018-01-04-16-19
> SPF is BASE + this series
Do you have THP=always here? Lack of THP support worries me.
What is performance in the worst case scenario? Li
> Hi, just saw this and thought of a small patch I just wrote for mdio bus, o
> idea
> if it is relevant but here goes:
>
> From fe0b98d54a79779482700676331b4d10a0f3cada Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund
> Date: Sun, 14 Jan 2018 21:27:20 +0100
> Subject: [PATCH] of_mdiobus_regist
On Tue, Jan 16, 2018 at 3:18 AM, Deepa Dinamani wrote:
> The series is a preparation series for individual architectures
> to use 64 bit time_t syscalls in compat and 32 bit emulation modes.
>
> This is a follow up to the series Arnd Bergmann posted:
> https://sourceware.org/ml/libc-alpha/2015-05/
On Mon, 15 Jan 2018 18:18:10 -0800
Deepa Dinamani wrote:
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index 09ad88572746..db25aa15b705 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
Acked-by: Steven Rostedt (VMware)
-- Steve
Christophe Leroy writes:
> When an app has some regular pages allocated (e.g. see below) and tries
> to mmap() a huge page at a hint address covered by the same PMD entry,
> the kernel accepts the hint allthough the 8xx cannot handle different
> page sizes in the same PMD entry.
So that is a bu
Christophe Leroy writes:
> An application running with libhugetlbfs fails to allocate
> additional pages to HEAP due to the hugemap being done
> inconditionally as topdown mapping:
>
> mmap(0x1008, 1572864, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS|0x4, -1, 0) = 0x73e8
> [...
Christophe Leroy writes:
> While the implementation of the "slices" address space allows
> a significant amount of high slices, it limits the number of
> low slices to 16 due to the use of a single u64 low_slices element
> in struct slice_mask.
It is not really slice_mask. it is mm_context_t.low
Christophe Leroy writes:
> On the 8xx, we can have as many slices as PMD entries.
> This means we could have 1024 slices in 4k size pages mode
> and 64 slices in 16k size pages.
>
> However, due to a stack overflow in slice_get_unmapped_area(),
> we limit to 512 slices.
>
> Signed-off-by: Christo
Le 16/01/2018 à 16:53, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
On the 8xx, we can have as many slices as PMD entries.
This means we could have 1024 slices in 4k size pages mode
and 64 slices in 16k size pages.
However, due to a stack overflow in slice_get_unmapped_area(),
we lim
Le 16/01/2018 à 16:49, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the hint allthough the 8xx cannot handle different
page
Le 16/01/2018 à 16:52, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
While the implementation of the "slices" address space allows
a significant amount of high slices, it limits the number of
low slices to 16 due to the use of a single u64 low_slices element
in struct slice_mask.
It
On 01/16/2018 10:01 PM, Christophe LEROY wrote:
diff --git a/arch/powerpc/include/asm/page_64.h
b/arch/powerpc/include/asm/page_64.h
index 56234c6fcd61..a7baef5bbe5f 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/include/asm/page_64.h
@@ -91,30 +91,13 @@ extern u64 ppc64_
On 01/16/2018 10:01 PM, Christophe LEROY wrote:
Le 16/01/2018 à 16:49, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address covered by the same PMD entry,
the kernel accepts the
Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
inconditionally as topdown mapping:
mmap(0x1008, 1572864, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_A
Le 16/01/2018 à 17:43, Aneesh Kumar K.V a écrit :
On 01/16/2018 10:01 PM, Christophe LEROY wrote:
Le 16/01/2018 à 16:49, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
When an app has some regular pages allocated (e.g. see below) and tries
to mmap() a huge page at a hint address c
Le 16/01/2018 à 17:41, Aneesh Kumar K.V a écrit :
On 01/16/2018 10:01 PM, Christophe LEROY wrote:
diff --git a/arch/powerpc/include/asm/page_64.h
b/arch/powerpc/include/asm/page_64.h
index 56234c6fcd61..a7baef5bbe5f 100644
--- a/arch/powerpc/include/asm/page_64.h
+++ b/arch/powerpc/includ
The switch log prints the tv_sec portion of timespec as a 32-bit
number, while overflows in 2106. It also uses the timespec type,
which is safe on 64-bit architectures, but deprecated because
it causes overflows in 2038 elsewhere.
This changes it to timespec64 and printing a 64-bit number for
cons
> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
> On Behalf Of Andrew Lunn
> Sent: Tuesday, January 16, 2018 5:04 PM
> To: mad skateman
> Cc: Christian Zigotzky ; Joakim Tjernlund
> ; linuxppc-dev@lists.ozlabs.org; Madalin-
> cristian Bucur ;
In an effort to remove all instances of 'struct timeval'
from the kernel, I'm changing the powerpc mpic_timer interface
to use plain seconds instead. There is only one user of this
interface, and that doesn't use the microseconds portion, so
the code gets noticeably simpler in the process.
Signed-
> -Original Message-
> From: Darren Stevens [mailto:dar...@stevens-zone.net]
> Sent: Tuesday, January 16, 2018 12:40 AM
> To: Madalin-cristian Bucur
> Cc: Jamie Krueger ; linuxppc-
> d...@lists.ozlabs.org; net...@vger.kernel.org
> Subject: Re: DPAA Ethernet problems with mainstream Linux k
On Thu, 1970-01-01 at 00:00 +, Andrew Lunn wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and know the
> content is safe.
>
>
> > Hi, just saw this and thought of a small patch I just wrote f
Hi Arnd,
> The switch log prints the tv_sec portion of timespec as a 32-bit
> number, while overflows in 2106. It also uses the timespec type,
> which is safe on 64-bit architectures, but deprecated because
> it causes overflows in 2038 elsewhere.
>
> This changes it to timespec64 and printing a
On Tue, Jan 16, 2018 at 8:07 PM, Jeremy Kerr wrote:
> Hi Arnd,
>
>> The switch log prints the tv_sec portion of timespec as a 32-bit
>> number, while overflows in 2106. It also uses the timespec type,
>> which is safe on 64-bit architectures, but deprecated because
>> it causes overflows in 2038 e
From: Markus Elfring
Date: Tue, 16 Jan 2018 21:36:56 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation
Improve a size determination
drivers/macintosh/rack-meter.c | 3 +--
1 file
From: Markus Elfring
Date: Tue, 16 Jan 2018 21:23:36 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/macintosh/rack-meter.c | 1 -
1 file changed, 1 deletion(-)
d
From: Markus Elfring
Date: Tue, 16 Jan 2018 21:26:52 +0100
Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was det
Hi All,
I compiled the RC8 of kernel 4.15 for the X5000 without PAMU support today.
Download: http://www.xenosoft.de/uImage_without_pamu.tar.gz
Please test it on your AmigaOne X5000.
Thanks,
Christian
On 16 January 2018 at 6:33PM, Madalin-cristian Bucur wrote:
The PAMU related errors may be
> > You appear to be using an old kernel. Take a look at:
>
> Not really, I am using 4.14.x and I don't think that is old.
Development for 4.14 stopped somewhere around the beginning of
September. So there has been over 4 months of work since then. We are
clearly interested in fixing bugs in tha
> *Given this if we disable that bit, we get the matching "Universally
> Administered Address" 0100 (Binary), 04 (Hex) -> "04:00:00", hence my
> question:"*
>
> This has something to do with the MAC adresses being locally administered
> .. and since whe can use Uboot and choose any Mac addr we
On Mon, Jan 15, 2018 at 3:16 PM, Nicolin Chen wrote:
> ==Change log==
> v4
> * Reworked the series by taking suggestions from Maciej
> + Added TXBIT0 bit back to play safe in PATCH-14
> + Made bool synchronous exclusive with AC97 mode in PATCH-16
> v3
> * Reworked the series by taking sugges
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see that the Ethernet NICS at least do something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct v
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see using wireshark that the Ethernet NIC at least does something.
ARP BROADCAST traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should
Hi,
I have been looking deeper into my wireshark packet captures and found
something that could be helpfull.
I can see that the Ethernet NIC at least does something. ARP BROADCAST
traffic is seen.
But i also found some packets...which have LG BITs set to 1 .. when i think
0 should be the correct
This makes me really start to wonder if the mainboard producer Varisys/AEON
has Purchased MAC`s for these boards at IEEE
Uboot system info gives for both MAC adresses the value NULL ... and i have
checked the mainboard for any stickers regarding the MAC adresses but there
is none..
I also tried t
On Tue, Jan 16, 2018 at 10:42:54AM +0100, Linus Walleij wrote:
> On Mon, Jan 15, 2018 at 4:13 AM, Jonathan Neuschäfer
> wrote:
>
> > This patch is based on code developed by Albert Herranz and the GameCube
> > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> > available at https
On 16.01.2018 00:16, Nicolin Chen wrote:
> ==Change log==
> v4
> * Reworked the series by taking suggestions from Maciej
> + Added TXBIT0 bit back to play safe in PATCH-14
> + Made bool synchronous exclusive with AC97 mode in PATCH-16
> v3
> * Reworked the series by taking suggestions from Ma
On 16.01.2018 00:16, Nicolin Chen wrote:
> AC97 configures most of registers earlier to start a communication
> with CODECs in order to successfully initialize CODEC. Currently,
> _fsl_ssi_set_dai_fmt() and fsl_ssi_setup_ac97() are called to get
> all SSI registers properly set.
>
> Since now the
On 16.01.2018 00:16, Nicolin Chen wrote:
> This patch cleans up probe() function by moving all Device Tree
> related code into a separate function. It allows the probe() to
> be Device Tree independent. This will be very useful for future
> integration of imx-ssi driver which has similar functional
On Wed, Jan 17, 2018 at 12:38:09AM +0100, Maciej S. Szmigiero wrote:
> > Example of uncovered tests: AC97, PowerPC and FIQ.
>
> I've tested the whole series in the AC'97 mode on an i.MX6 UDOO board
> and everything seems to work fine as long as few small changes are made
> to patches 13 and 16.
On 17.01.2018 00:52, Nicolin Chen wrote:
> On Wed, Jan 17, 2018 at 12:38:09AM +0100, Maciej S. Szmigiero wrote:
>
>>> Example of uncovered tests: AC97, PowerPC and FIQ.
>>
>> I've tested the whole series in the AC'97 mode on an i.MX6 UDOO board
>> and everything seems to work fine as long as few s
Export set_thread_tidr() and clear_thread_tidr() interfaces so they
can be used by external modules.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/kernel/process.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 2010
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/kernel/process.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index f20c1ad..d22055b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1475,6 +
Add a couple of trace points in the VAS driver.
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/vas-trace.h | 112
arch/powerpc/platforms/powernv/vas-window.c | 9 +++
2 files changed, 121 insertions(+)
create mode 100644 arch/powerpc/platfo
The Virtual Accelerator Switchboard (VAS) subsystem in the POWER9 processor
provides a low latency Core-to-core wakeup" mechanism which allows a thread
on one core the processor to efficiently send a message to a thread waiting
on another core.
This Fast thread-wakeup (FTW) driver provides user sp
Remove a bogus line from arch/powerpc/platforms/powernv/Makefile that
was added by commit ece4e51 ("powerpc/vas: Export HVWC to debugfs").
Signed-off-by: Sukadev Bhattiprolu
---
arch/powerpc/platforms/powernv/Makefile | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/platforms/powe
Define the FTW_SETUP ioctl interface for fast thread wakeup (FTW). A
follow-on patch will implement the FTW driver and ioctl.
Thanks to input from Ben Herrenschmidt, Michael Neuling, Michael Ellerman.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v2]
- [Michael Neuling] Use a single V
The Fast Thread Wake-up (FTW) driver provides user space applications an
interface to the low latency Core-to-Core wakeup functionality in POWER9.
This mechanism allows a thread on one core to efficiently send a message
to a "waiting thread" on another core on the same chip, using the Virtual
Acce
Add a couple of trace points in the FTW driver
Signed-off-by: Sukadev Bhattiprolu
---
drivers/misc/ftw/ftw-trace.h | 75
drivers/misc/ftw/ftw.c | 6
2 files changed, 81 insertions(+)
create mode 100644 drivers/misc/ftw/ftw-trace.h
diff -
Document the usage of the VAS Fast thread-wakeup API and add an entry in
MAINTAINERS file.
Thanks for input/comments from Benjamin Herrenschmidt, Michael Neuling,
Michael Ellerman, Robert Blackmore, Ian Munsie, Haren Myneni and Paul
Mackerras.
Signed-off-by: Sukadev Bhattiprolu
---
Changelog[v2
Laurent Dufour writes:
> From: Peter Zijlstra
>
> One of the side effects of speculating on faults (without holding
> mmap_sem) is that we can race with free_pgtables() and therefore we
> cannot assume the page-tables will stick around.
>
> Remove the reliance on the pte pointer.
This needs a l
On 01/16/2018 10:18 PM, Christophe LEROY wrote:
Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
Christophe Leroy writes:
An application running with libhugetlbfs fails to allocate
additional pages to HEAP due to the hugemap being done
inconditionally as topdown mapping:
mmap(0x1008
Christophe LEROY writes:
>>
>>> How should I split in separate patches ? Something like ?
>>> 1/ Slice support for PPC32 > 2/ Activate slice for 8xx
>>
>> Yes something like that. Will you be able to avoid that
>> if (SLICE_NUM_HIGH) from the code? That makes the code ugly. Right now
>> i do
FYI
Sent from my iPhone
> On 17. Jan 2018, at 06:50, Christian Zigotzky wrote:
>
> Hi Skateman,
>
> Fantastic! Many thanks for testing the RC8 of kernel 4.15 without PAMU
> support.
>
> @All
> Further information:
> http://forum.hyperion-entertainment.biz/viewtopic.php?f=58&p=43706#p43706
>
Greeting's
linux-next kernel booted with kernel Oops on powerpc machine.
Machine Type: Power 8 [bare-metal & PowerVM LPAR]
kernel version: 4.15.0-rc7-next-20180115
test: Boot
config: attached
bootlogs:
-
ses 0:0:3:0: Attached Enclosure device
ses 0:0:4:0: Attached Enclosure device
Roundi
Hi,
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 2010e4c..f20c1ad 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1560,6 +1560,7 @@ void clear_thread_tidr(struct task_struct *t)
free_thread_tidr(t->thread.tidr);
[ Maciej, could you please send your Tested-by/Reviewed-by for AC97
once you confirm this series?
And Caleb, this version does not need a test for non-AC97 cases.
Thanks both! ]
==Change log==
v5
* Reworked the series by taking suggestions from Maciej for AC97
+ Fixed SSI lockup issue
The RX and TX macros were defined implicitly and there was
a potential risk if someone changes their values.
Since they were defined to index the array ssi->regvals[2],
this patch moves these two macros to fsl_ssi.c, closer to
its owner ssi->regvals. And it also puts some comments here
to limit th
The hw_params() overwrites i2s_net settings for special cases like
mono-channel support, however, it doesn't update ssi->i2s_net as
set_dai_fmt() does.
This patch removes the local i2s_net variable and directly updates
ssi->i2s_net in the hw_params() so that the driver can simply look
up the ssi->
This patch replaces the register read with ssi->i2s_net for
simplification. It also removes masking SSIEN from scr value
since it's handled later by regmap_update_bits() to set this
scr value back.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 7 ++-
1 fil
Checking TE and RE bits in SCR register doesn't work for AC97 mode
which enables SSIEN, TE and RE in the fsl_ssi_setup_ac97() that's
called during probe().
So when running into the trigger(), it will always get the result
of both TE and RE being enabled already, even if actually there is
no active
The define of fsl_ssi_disable_val is not so clear as it mixes two
steps of calculations together. And those parameter names are also
a bit long to read.
Since it just tries to exclude the shared bits from the regvals of
current stream while the opposite stream is active, it's better to
use somethi
The FIFO clear helper function is just one line of code now.
So it could be cleaned up by removing it and calling regmap
directly.
Meanwhile, FIFO clear could be applied to all use cases, not
confined to AC97. So this patch also moves FIFO clear in the
trigger() to fsl_ssi_config() and removes the
The trigger() calls fsl_ssi_tx_config() and fsl_ssi_rx_config(),
and both of them jump to fsl_ssi_config(). And fsl_ssi_config()
later calls another fsl_ssi_rxtx_config().
However, the whole routine, especially fsl_ssi_config() function,
is too complicated because of the folowing reasons:
1) It ha
The _fsl_ssi_set_dai_fmt() bypasses an undefined format for AC97
mode. However, it's not really necessary if AC97 has its complete
format defined.
So this patch adds a DAIFMT macro of complete format including a
clock direction and polarity.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
--
This patch cleans fsl_ssi_setup_regvals() by following changes:
1) Moving DBG bits to the first lines.
2) Setting SSIE, RE/TE as default and cleaning it for AC97
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 17 ++---
1 file changed, 6 insertions(+
It'd be safer to enable both FIFOs for TX or RX at the same time.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index e5efee2..ba06
Since there is a helper function, use it to help readability.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index ba06e94..e1fe511 100644
The probe() could handle some one-time configurations since
they will not be changed once being configured.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
Changelog
v2
* Moved all to fsl_ssi_hw_init() in platform probe()
sound/soc/fsl/fsl_ssi.c | 39 ++-
AC97 configures most of registers earlier to start a communication
with CODECs in order to successfully initialize CODEC. Currently,
_fsl_ssi_set_dai_fmt() and fsl_ssi_setup_ac97() are called to get
all SSI registers properly set.
Since now the driver has a fsl_ssi_hw_init() to handle all register
The _fsl_ssi_set_dai_fmt() is a helper function being called from
fsl_ssi_set_dai_fmt() as an ASoC operation and fsl_ssi_hw_init()
mainly for AC97 format initialization.
This patch cleans the _fsl_ssi_set_dai_fmt() in following ways:
* Removing *dev pointer in the parameters as it's included in th
Using symmetric_rates in the cpu_dai_drv is a bit implicit,
so this patch adds a bool synchronous instead.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
Changelog
v3
* Removed all cpu_dai_drv changes
sound/soc/fsl/fsl_ssi.c | 13 -
1 file changed, 8 insertions(+), 5 delet
This patch cleans up probe() function by moving all Device Tree
related code into a separate function. It allows the probe() to
be Device Tree independent. This will be very useful for future
integration of imx-ssi driver which has similar functionalities
while exists only because it supports non-D
Since ssi->streams is being updated along with SCR register and
its SSIEN bit, it's simpler to use it instead.
Signed-off-by: Nicolin Chen
Tested-by: Caleb Crome
---
sound/soc/fsl/fsl_ssi.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound
88 matches
Mail list logo
