On Wed, Aug 14, 2013 at 01:30:17PM +0800, Nicolin Chen wrote:
Hi Shwan,
On Wed, Aug 14, 2013 at 11:27:00AM +0800, Shawn Guo wrote:
I do not think we need this general compatible string. Device tree
compatible should be specific.
So I should just use 'fsl,chip-spdif and list all
Add function to support get voltage from device-tree.
If there are voltage-range specified in device-tree node, this function
will parse it and return the available voltage mask.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
changes for v5:
- add binding spec for this device
On Wed, Aug 14, 2013 at 02:39:33PM +0800, Shawn Guo wrote:
We only need to maintain those versions that require different
programming model in the list. For example, if S/PDIF on Vybrid
is completely compatible with imx6q one and uses the exactly same
programming model, we do not need to
On Mon, Aug 12, 2013 at 08:05:27PM +0800, Nicolin Chen wrote:
This patch add S/PDIF controller driver for Freescale SoC.
Signed-off-by: Nicolin Chen b42...@freescale.com
+
+Required properties:
+
+ - compatible : Compatible list, contains fsl,chip-spdif. Using general
+ fsl,fsl-spdif
On Wed, Aug 14, 2013 at 02:34:45PM +0800, Nicolin Chen wrote:
On Wed, Aug 14, 2013 at 02:39:33PM +0800, Shawn Guo wrote:
We only need to maintain those versions that require different
programming model in the list. For example, if S/PDIF on Vybrid
is completely compatible with imx6q one
On 13/08/13 19:37, Michal Simek wrote:
On 08/13/2013 05:40 PM, Sudeep KarkadaNagesha wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sudeep KarkadaNagesha wrote:
The following changes since commit
Hi Sascha,
On Wed, Aug 14, 2013 at 09:50:17AM +0200, Sascha Hauer wrote:
+ - tx-clksrc-names : The names for all available clock sources for tx,
which
+ is also being listed in SoC reference manual, ClkSrc_Sel bit of
SPDIF_SRPC.
+ And the name list would be different between
This reverts commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9.
As the tests PPC64 (powernv platform) show, IOMMU pages are leaking
when transferring big amount of small packets (=64 bytes),
ping -f and waiting for 15 seconds is the simplest way to confirm the bug.
Cc: Linus Torvalds
On 13/08/13 20:45, Rafael J. Wysocki wrote:
On Tuesday, August 13, 2013 01:44:23 PM Rob Herring wrote:
On Tue, Aug 13, 2013 at 10:40 AM, Sudeep KarkadaNagesha
sudeep.karkadanage...@arm.com wrote:
Adding PowerPC list
On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically
On Wed, Aug 14, 2013 at 04:48:02PM +0800, Nicolin Chen wrote:
Hi Sascha,
On Wed, Aug 14, 2013 at 09:50:17AM +0200, Sascha Hauer wrote:
+ - tx-clksrc-names : The names for all available clock sources for tx,
which
+ is also being listed in SoC reference manual, ClkSrc_Sel bit of
-Original Message-
From: Linuxppc-dev [mailto:linuxppc-dev-
bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Alexey
Kardashevskiy
Sent: Wednesday, August 14, 2013 2:55 PM
To: linuxppc-dev@lists.ozlabs.org
Cc: Alexey Kardashevskiy; Paul Mackerras;
On Mon, Jul 15, 2013 at 10:20:55AM +0530, Varun Sethi wrote:
Add an iommu domain pointer to device (powerpc) archdata. Devices
are attached to iommu domains and this pointer provides a mechanism
to correlate between a device and the associated iommu domain. This
field is set when a device is
On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
I don't understand completely the use of ibm,ppc-interrupt-server#s and
its implications on generic of_get_cpu_node implementation.
I see the PPC specific definition of
Hi,
On Wed, Aug 14, 2013 at 11:56:52AM +0200, Sascha Hauer wrote:
I think I should first explain to you what this part is doing:
The driver needs to set Clk_source bit for TX/RX to select the
clock from a clock mux. The names listed above are those of the
clocks connecting to the mux,
On Mon, Aug 12, 2013 at 06:49:37PM -0300, Marcelo Cerri wrote:
The NX driver uses the transformation context to store several fields
containing data related to the state of the operations in progress.
Since a single tfm can be used by different kernel threads at the same
time, we need to
On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote:
Yes this doesn't cover the historical ibm,ppc-interrupt-server#s,
for
which we can have PPC specific wrapper above the generic one i.e. get
the cpu node and then parse for thread id under custom property.
A wrapper is wrong. I
On PowerPC, when CPUs enter deep idle states, their local timers are
switched off. The responsibility of waking them up at their next timer event,
needs to be handed over to an external device. On PowerPC, we do not have an
external device equivalent to HPET, which is currently done on
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
For scalability and performance reasons, we want the broadcast timer
interrupts to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function
From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE
map to a common implementation - generic_smp_call_function_single_interrupt().
So, we can consolidate them and save one of the IPI message slots, (which are
precious,
On ppc, in deep idle states, the local clock event device of CPUs gets
switched off. On PowerPC, the local clock event device is called the
decrementer. Make use of the broadcast framework to issue interrupts to
cpus in deep idle states on their timer events, except that on ppc, we
do not have an
This patch hooks into the existing broadcast framework along with the support
that this patchset introduces for ppc, and the cpuidle driver backend
for powernv(posted out by Deepthi Dharwar:https://lkml.org/lkml/2013/7/23/128)
to add sleep state as one of the deep idle states, in which the
In the current design of the timer offload framework for powerpc, there is a
dedicated broadcast CPU, which is the boot CPU. But this is not good because:
a.It disallows this CPU from being hotplugged out.
b.Overburdening this CPU with the broadcast duty can take
a toll on the performance, which
In the current design we were depending on the timer interrupt on the
bc_cpu to trigger broadcast handling. In tickless idle, timer interrupts
could be many ticks away which could result in missed wakeups on CPUs in deep
idle states. Disabling tickless idle on the bc_cpu is not good for
Am Mittwoch, den 14.08.2013, 16:48 +0800 schrieb Nicolin Chen:
Hi Sascha,
On Wed, Aug 14, 2013 at 09:50:17AM +0200, Sascha Hauer wrote:
+ - tx-clksrc-names : The names for all available clock sources for tx,
which
+ is also being listed in SoC reference manual, ClkSrc_Sel bit of
On Wed, Aug 14, 2013 at 06:23:46PM +0800, Nicolin Chen wrote:
Hi,
Surely, if I misunderstand your point, please correct me. And
if you have any sage idea, please guide me.
Something like this:
clocks = clks 197, clks 3, clks 197, clks 107, clks
SPDIF_EXT,
clks 118,
On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
I don't understand completely the use of ibm,ppc-interrupt-server#s and
its implications on generic of_get_cpu_node
On 14/08/13 12:37, Benjamin Herrenschmidt wrote:
On Wed, 2013-08-14 at 11:01 +0100, Sudeep KarkadaNagesha wrote:
Yes this doesn't cover the historical ibm,ppc-interrupt-server#s,
for
which we can have PPC specific wrapper above the generic one i.e. get
the cpu node and then parse for thread
On 14/08/13 13:53, Rob Herring wrote:
On 08/14/2013 05:01 AM, Sudeep KarkadaNagesha wrote:
On 13/08/13 22:07, Benjamin Herrenschmidt wrote:
On Tue, 2013-08-13 at 19:29 +0100, Sudeep KarkadaNagesha wrote:
I don't understand completely the use of ibm,ppc-interrupt-server#s and
its implications
On 08/14/2013 02:14 AM, Shawn Guo wrote:
On Wed, Aug 14, 2013 at 02:34:45PM +0800, Nicolin Chen wrote:
On Wed, Aug 14, 2013 at 02:39:33PM +0800, Shawn Guo wrote:
We only need to maintain those versions that require different
programming model in the list. For example, if S/PDIF on Vybrid
is
Hi,
I have to struggle with a broadcast video decoder with an unknown PPC Linux. I
would like to compile
a new module, but I need a build environment. Here some infos about the system:
Linux version 2.6.14-gemppc-iolite
processor : 0
cpu : 405GPr
clock : 399MHz
On Wed, Aug 14, 2013 at 09:56:11AM +, Sethi Varun-B16395 wrote:
Please find the .config file attached with this mail.
Fantastic, thanks. The build works fine, I'll include the driver into my
next-branch. I also have two minor clean-up patches on-top, just if you
where wondering.
Thanks Joerg.
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
Sent: Wednesday, August 14, 2013 9:45 PM
To: Sethi Varun-B16395
Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
linux-ker...@vger.kernel.org; b...@kernel.crashing.org;
On Wed, 2013-08-14 at 14:18 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote:
powerpc/e500: Update compilation flags with core specific
options
This breaks the build for my FSL test configs. For some reason gcc 4.7.3
doesn't know about
On 08/14/2013 07:36 AM, Libo Chen wrote:
We can use the wrapper functions platform_{get,set}_drvdata() instead of
dev_{get,set}_drvdata() with pdev-dev, it is convenient for user.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after
On Wed, 2013-08-14 at 12:02 -0500, Scott Wood wrote:
On Wed, 2013-08-14 at 14:18 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2013-08-08 at 17:45 -0500, Scott Wood wrote:
powerpc/e500: Update compilation flags with core specific
options
This breaks the build for my FSL test
On 08/14/2013 02:19 AM, Alexey Kardashevskiy wrote:
This reverts commit f83331bab149e29fa2c49cf102c0cd8c3f1ce9f9.
As the tests PPC64 (powernv platform) show, IOMMU pages are leaking
when transferring big amount of small packets (=64 bytes),
ping -f and waiting for 15 seconds is the simplest way
On Wed, 2013-08-14 at 14:21 +0100, Sudeep KarkadaNagesha wrote:
IMO moving of handling ibm,ppc-interrupt-server#s to generic code
under
#ifdef CONFIG_PPC seems to be cleaner approach than weak definitation.
As per my understanding each thread is a different logical cpu.
Each logical cpu is
This patch fixes a bug in the nx-aes-gcm implementation.
Corrected the code so that the authtag is always verified after
decrypting and not just when there is associated data included.
Also, corrected the code to retrieve the input authtag from src
instead of dst.
Reviewed-by: Fionnuala Gunter
On Wed, Aug 14, 2013 at 04:52:53PM -0500, Seth Jennings wrote:
On Wed, Aug 14, 2013 at 02:37:26PM -0700, Yinghai Lu wrote:
On Wed, Aug 14, 2013 at 1:35 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Wed, Aug 14, 2013 at 01:05:33PM -0700, Dave Hansen wrote:
On 08/14/2013
Hi Stephen,
On Wed, Aug 14, 2013 at 09:47:19AM -0600, Stephen Warren wrote:
If the clock source name list is different, then it needs a different
compatible value, so that each compatible value can specify which clock
names are required.
Also, the compatible value itself should always
Hi Philipp,
Thank again for the comments.
On Wed, Aug 14, 2013 at 02:06:24PM +0200, Philipp Zabel wrote:
==
From i.MX53 reference manual:
if (DPLL Locked) SPDIF_RxClk else extal
0001 if (DPLL Locked) SPDIF_RxClk else
On Wed, Aug 14, 2013 at 02:19:37PM +0200, Sascha Hauer wrote:
Yes, since the clk names are not an API. Exposing them to the devicetree
is not an option. The fact that the names are defined in
arch/arm/mach-imx/clk-imx6q.c and are used in the spdif driver makes
this really clear.
The spdif
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically
People have been dropping things in here without updating the index, do
it for them.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
Documentation/powerpc/00-INDEX | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/powerpc/00-INDEX
The spec says it may be problematic if CPU x registers the VPA of
CPU y. Add a warning in case we ever do that.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/platforms/pseries/lpar.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
We haven't updated these for a while it seems, it's nice to have in the
oops output.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/xmon/xmon.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index
The symbols that name some of our exception trampolines are ahead of the
location they name. In most cases this is OK because the code is tightly
packed, but in some cases it means the symbol floats ahead of the
correct location, eg:
cea0 performance_monitor_pSeries_1:
...
This makes back traces and profiles easier to read.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/kernel/exceptions-64s.S | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
In the program check handler we handle some causes with interrupts off
and others with interrupts on.
We need to enable interrupts to handle the emulation cases, because they
access userspace memory and might sleep.
For faults in the kernel we don't want to do any emulation, and
The rc variable is initially used to store the return code from the
ibm,update-properties rtas call which returns 0 or 1 on success. A return
code of 1 indicates that ibm,update-properties must be called again for the
node. However, the rc variable is overwritten by a call to update_dt_prop
which
The update_dt_prop helper function fails to set the IN/OUT parameter prop to
NULL after a complete property has been parsed from the work area returned by
the ibm,update-properties rtas function. This results in the property list of
the device node being updated is corrupted and becomes a loop
The work area buffer returned by the ibm,update-properties rtas call contains
20 bytes of header information prior to the property value descriptor data.
Currently update_dt_node tries to advance over this header using sizeof(upwa).
The update_props_workarea struct contains 20 bytes worth of
The node to be detached is retrieved via its phandle by a call to
of_find_node_by_phandle which increments the ref count. We need a matching
call to of_node_put to decrement the ref count and ensure the node is
actually freed.
Signed-off-by: Tyrel Datwyler tyr...@linux.vnet.ibm.com
---
Currently we still perform updating of the device tree after a suspend or
migration from drmgr in userspace through the ugly /proc/ppc64/ofdt interface.
Code exists to do this update from within the kernel, but testing revealed it
to be severely broken to the point that the system hardlocks up
Currently the device nodes created in the device subtree returned by a call to
dlpar_configure_connector are all named in the root node. This is because the
the node name in the work area returned by ibm,configure-connector rtas call
only contains the node name and not the entire node path.
Currently the OF_DYNAMIC and kref initialization for a node happens in
dlpar_attach_node. However, a node passed to dlpar_attach_node may be a tree
containing child nodes, and no initialization traversal is done on the
tree. Since the children never get their kref initialized or the OF_DYNAMIC
Calls to dlpar_detach_node do not iterate over child nodes detaching them as
well. By iterating and detaching the child nodes we ensure that they have the
OF_DETACHED flag set and that their reference counts are decremented such that
the node will be freed from memory by of_node_release.
Alexey,
On Thu, Aug 15, 2013 at 12:57:19PM +1000, Alexey Kardashevskiy wrote:
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to
59 matches
Mail list logo
