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 m
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
> +
> +Required properties:
> +
> + - compatible : Compatible list, contains "fsl,-spdif". Using general
> + "fsl,fsl-spdif" will get the de
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
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
d4e4ab86bcba5a7
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 betwe
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
Cc: Santos
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
>> wrote:
>>> Adding PowerPC list
>>>
>>> On 13/08/13 14:00, Rafael J. Wysocki wrote:
On Monday, August 12, 2013 02:27:47 PM Sude
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 the
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
> -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; linux-ker
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
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 of_get
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
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 pr
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.
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 architecture
From: Srivatsa S. Bhat
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 mechanism because the IPI handlers ar
From: Srivatsa S. Bhat
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, since only 4 of those slots are av
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 e
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 decremen
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
powersaving
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_Se
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
> >
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 impl
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 fo
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
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 Vyb
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
revi
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.
Jo
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;
> ga...@kern
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 devi
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
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 w
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 cp
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
R
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
> > wrote:
> > > On Wed, Aug 14, 2013 at 01:05:33PM -0700, Dave Hansen wrote:
> > >> On 08/14/2013 12:43 PM, Greg Kro
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 i
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 el
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 sp
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 the
People have been dropping things in here without updating the index, do
it for them.
Signed-off-by: Michael Ellerman
---
Documentation/powerpc/00-INDEX | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index 05026ce..
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
---
arch/powerpc/platforms/pseries/lpar.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/lpar.c
b/arch/powe
We haven't updated these for a while it seems, it's nice to have in the
oops output.
Signed-off-by: Michael Ellerman
---
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 96bf5bd..9f3655b 100644
--- a/arc
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 :
...
cf00: 7d
This makes back traces and profiles easier to read.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/exceptions-64s.S | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S
index ae902cae..e41
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
emulate_instructi
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 r
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 sinc
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 fields
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
---
arch/powerpc/platforms/pseries/mobi
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 stuc
On the first call to ibm,update-properties for a node the first property
returned is the full node path. Currently this is not parsed correctly by the
update_dt_node function. Commit 2e9b7b0 attempted to fix this, but was
incorrect as it made a wrong assumption about the layout of the first
propert
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. Passing
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
flag
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.
Signed-of
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 adde
58 matches
Mail list logo
