On Tue, Apr 27, 2010 at 2:46 PM, Timur Tabi wrote:
> Grant Likely wrote:
>
>> So, the current 86xx device tree binding assumes a simple layout with
>> a node describing an DAI controller, and another node describing the
>> codec with a single phandle (pointer) from the DAI to the codec. In
>> thi
Hi Sergey and Steven,
On Tue, Apr 27, 2010 at 8:29 PM, Steven J. Magnani
wrote:
> On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
>> This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
>>
>> Changelog v2:
>> * Changed the functions and struct definition prefix from sdma_
On Tue, 2010-04-27 at 14:10 -0700, a...@linux-foundation.org wrote:
> From: Peter Zijlstra
>
> The powerpc page table freeing relies on the fact that IRQs hold off an
> RCU grace period, this is currently true for all existing RCU
> implementations but is not an assumption Paul wants to support.
On Tue, 2010-04-27 at 21:59 +0100, Mark Brown wrote:
> It's entirely possible that if the board designer intended the verious
> SSIs to be used in concert they've done something like cross wire the
> clocks which creates a board-specific interrelationship that needs to
> be dealt with.
In which c
On Tue, 2010-04-27 at 15:04 -0500, Timur Tabi wrote:
> What I need is something like a hashing function that can convert a
> "struct device_node *" into an "int". I'm going to have two functions
> that independently parse the device tree and locate a specific node.
> Both functions will "register
On Tue, 2010-04-27 at 13:15 -0600, Grant Likely wrote:
>
> Can you not dynamically assign an id? If alsa soc needs a unique id
> number, then just create a lookup function. Something like
> of_asoc_phandle_to_codec_id() that will either return a previously
> assigned id, or will assign a new id.
On Wed, 2010-04-28 at 13:29 +1000, Nick Piggin wrote:
> I think I nacked this because the rest of the powerpc code also
> assumes irq disables provide an rcu critical section. The plan was
> to convert powerpc pagetable code to use call_rcu_sched.
Right, on my todo list.
Cheers,
Ben.
__
On Tue, 2010-04-27 at 23:29 +0100, Mark Brown wrote:
>
> On the other hand from a pragmatic point of view it's just much less
> hassle to just only provide the mechanism for instantiating a machine
> with custom code and use that for everything.
Right, that's the balance to find. A too descriptiv
On Tue, Apr 27, 2010 at 02:10:47PM -0700, Andrew Morton wrote:
> From: Peter Zijlstra
>
> The powerpc page table freeing relies on the fact that IRQs hold off an
> RCU grace period, this is currently true for all existing RCU
> implementations but is not an assumption Paul wants to support.
>
>
On Wed, 2010-04-28 at 02:06 +0400, Sergey Temerkhanov wrote:
> This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
>
> Changelog v2:
> * Changed the functions and struct definition prefix from sdma_ to xllsdma_
> * Platform bus bindings and various changes by Steven J. Magnani.
> * Mo
On Tue, Apr 27, 2010 at 4:29 PM, Mark Brown
wrote:
> On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
>
>> However, as you and Mark rightly point out, it completely fails to
>> represent complex sound devices with weird clocking and strange
>> routes. Something like this is probably
Hi Anton,
On Tue, 27 Apr 2010 11:32:34 +1000 Anton Blanchard wrote:
>
> - old_mask = current->cpus_allowed;
> - set_cpus_allowed(current, cpumask_of_cpu(boot_cpuid));
> -
> + alloc_cpumask_var(&old_mask, GFP_NOWAIT);
You should probably put an explicit include of linux/gfp.h in
On Tue, Apr 27, 2010 at 02:24:34PM -0600, Grant Likely wrote:
> However, as you and Mark rightly point out, it completely fails to
> represent complex sound devices with weird clocking and strange
> routes. Something like this is probably more appropriate:
>
> [...]
> codec1
This is the 2nd version of Xilinx MPMC LocalLink SDMA subsystem
Changelog v2:
* Changed the functions and struct definition prefix from sdma_ to xllsdma_
* Platform bus bindings and various changes by Steven J. Magnani.
* Moved source files from arch/powerpc/sysdev to global locations and added
On Tue, 2010-04-27 at 16:56 -0500, Tseng-Hui (Frank) Lin wrote:
> icswx is a PowerPC co-processor instruction to send data to a
> co-processor. On Book-S processors the LPAR_ID and process ID (PID) of
> the owning process are registered in the window context of the
> co-processor at initial time
On Sat, 2010-04-24 at 10:55 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-04-23 at 17:04 -0500, Tseng-Hui (Frank) Lin wrote:
> > Add Power7 icswx co-processor instruction support.
>
> Please provide a -much- more detailed explanation of what it is, what it
> does and why it requires hooking
From: Peter Zijlstra
The powerpc page table freeing relies on the fact that IRQs hold off an
RCU grace period, this is currently true for all existing RCU
implementations but is not an assumption Paul wants to support.
Therefore, also take the RCU read lock along with disabling IRQs to ensure
th
On Tue, Apr 27, 2010 at 04:03:27PM -0500, Timur Tabi wrote:
[Reflowing the text into 80 columns again]
> Mark Brown wrote:
> > It's entirely possible that if the board designer intended the verious
> > SSIs to be used in concert they've done something like cross wire the
> > clocks which creates
Mark Brown wrote:
> It's entirely possible that if the board designer intended the verious
> SSIs to be used in concert they've done something like cross wire the
> clocks which creates a board-specific interrelationship that needs to be
> dealt with.
Fine, but I don't see how that can be handled
On Tue, Apr 27, 2010 at 03:46:04PM -0500, Timur Tabi wrote:
[Reflowed into 80 columns; please fix your mail client.]
> > (I've omitted the DMA nodes and some irrelevant details) This is
> > enough information for a simplistic driver registration that probably
> > makes a lot of assumptions. Suc
Mark Brown wrote:
> Hrm, the only issue that's been raised upstream is multi-CODEC (there
> are one or two other things that boil down to multi-CODEC, but nothing
> else I'm aware of). If you schedule something please announce it here,
> I believe that UDS generally has arrangements for remote par
On Tue, Apr 27, 2010 at 02:27:42PM -0600, Grant Likely wrote:
> On Tue, Apr 27, 2010 at 4:09 AM, Benjamin Herrenschmidt
> > I don't have bandwidth to contribute much in this discussion right now,
> > at least not to lead it, so I'm happy to let others do so, but I'm happy
> > to provide feedback f
Grant Likely wrote:
> So, the current 86xx device tree binding assumes a simple layout with
> a node describing an DAI controller, and another node describing the
> codec with a single phandle (pointer) from the DAI to the codec. In
> this configuration, it is completely reasonable for the DAI no
On Tue, Apr 27, 2010 at 03:04:33PM -0500, Timur Tabi wrote:
[Reflowed into 80 columns]
> At least, that's the way ASoC likes to operate. AsoC takes a fixed
> string plus a unique integer. I could technically create a unique
> string for each DMA device, and have the integer always be 0.
This s
On Tue, Apr 27, 2010 at 4:09 AM, Benjamin Herrenschmidt
wrote:
> On Tue, 2010-04-27 at 10:54 +0100, Mark Brown wrote:
>> I'd just like to add that I *really* want to see you guys come to some
>> sort of firm and documented conclusion about the way to handle
>> situations like this. Some variant o
On Tue, Apr 27, 2010 at 2:07 AM, Liam Girdwood wrote:
> On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote:
>> > An upcoming change in the architecture of ALSA SoC (ASoC) will require the
>> > MPC8610 HPCD's ASoC fabric driver to
Grant Likely wrote:
>> + /* Register the platform device for the ASoC fabric driver */
>> > + platform_device_register_simple("snd-soc-mpc8610-hpcd", 0, NULL,
>> > 0);
>> > +
> Since this is a temporary measure, this device registration is
> probably best put into the .probe() hook of
Grant Likely wrote:
> Can you not dynamically assign an id? If alsa soc needs a unique id
> number, then just create a lookup function.
What I need is something like a hashing function that can convert a "struct
device_node *" into an "int". I'm going to have two functions that
independently
I'm trying to get 834x/TSEC gianfar.c working with 2.6.33/RT.
when PREEMPT is disabled gianfar driver worked well.
if PREEMPT is enabled, especially when PREEMPT_RT is enabled,
network(gianfar) will be disconnected in about 2-3 minutes under
iperf.
In an older version (2.6.18-rt) where NAPI is d
On Mon, Apr 26, 2010 at 2:49 PM, Timur Tabi wrote:
> An upcoming change in the architecture of ALSA SoC (ASoC) will require the
> MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver.
> Therefore, we need to call platform_device_register_simple() from the board's
> platform
On Tue, Apr 27, 2010 at 12:32 PM, Timur Tabi wrote:
> Liam Girdwood wrote:
>
>>> I would need some way for fsl_dma_open() to get a pointer to private,
>>> DMA-specific data. I'm not sure how I can do that.
>>
>> In multi-component we now have platform_data and device private data
>> (from the reg
Liam Girdwood wrote:
>> I would need some way for fsl_dma_open() to get a pointer to private,
>> DMA-specific data. I'm not sure how I can do that.
>
> In multi-component we now have platform_data and device private data
> (from the regular driver model).
In that case, I still have the same pro
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin wrote:
> Platform specific code for MPC5121 USB Host support.
>
> The patch also contains changes to FSL EHCI platform driver
> needed to support MPC5121 USB controllers. MPC5121 Rev 2.0
> silicon EHCI registers are in big endian format. The
> a
Hi Anatolij,
I haven't looked deeply, but I've written a couple of minor comments below.
g.
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin wrote:
> Adds Freescale USB OTG driver and extends Freescale
> USB SoC Device Controller driver and FSL EHCI driver
> to support OTG operation on MPC5
On Tue, Apr 27, 2010 at 10:11 AM, Anatolij Gustschin wrote:
> Factor out common code for registering a FSL EHCI platform
> device into new fsl_usb2_register_device() function. This
> is done to avoid code duplication while adding code for
> instantiating of MPC5121 dual role USB platform devices.
On Tue, 2010-04-27 at 10:28 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
>
> > Iirc, the SSI and DMA controllers on your SoC mean that each DMA device
> > can only do one direction (either Playback or Capture). So I'm thinking
> > we create two DAI link entries for your sound card (one for play
Implement hardware breakpoint interfaces for PowerPC BookE processors
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |2
arch/powerpc/include/asm/cputable.h|4
arch/powerpc/include/asm/hw_breakpoint_booke.h | 42 +++
arch/powerpc/kernel/Makefil
Hi All,
Please find a patch that implements hardware-breakpoint interfaces for
BookE processors. The patches are under continuous development and are sent
to receive early comments. For the moment, they are (only) compile tested (with
ppc64e_defconfig), further testing will accompany the on
On Tuesday 20 April 2010 20:29:55 Steven J. Magnani wrote:
> Hi Sergey,
>
> I've only just started using this in earnest, sorry for not getting back
> to you sooner. It's a nice encapsulation of the MPMC/SDMA functionality,
> thanks for posting it.
>
> In order to integrate this into my system, I
USB Device Controller driver and OTG driver allow
configuration of controller register accessors.
Enable default big-endian register accessors for
Rev.2 SoC.
Signed-off-by: Anatolij Gustschin
Cc: Grant Likely
---
arch/powerpc/platforms/512x/Kconfig |8
1 files changed, 8 insertions
Factor out common code for registering a FSL EHCI platform
device into new fsl_usb2_register_device() function. This
is done to avoid code duplication while adding code for
instantiating of MPC5121 dual role USB platform devices.
Then, the subsequent patch can use
for_each_compatible_node(np, NULL,
Platform specific code for MPC5121 USB Host support.
The patch also contains changes to FSL EHCI platform driver
needed to support MPC5121 USB controllers. MPC5121 Rev 2.0
silicon EHCI registers are in big endian format. The
appropriate flags are set using the information in the
platform data stru
Anatolij Gustschin (4):
powerpc/fsl_soc.c: prepare for addition of mpc5121 USB code
powerpc/mpc5121: add USB host support
USB: add USB OTG support for MPC5121 SoC
powerpc/mpc5121: select options for USB OTG support
Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 +
arch/powerpc/incl
On Tue, Apr 27, 2010 at 10:28 AM, Timur Tabi wrote:
> I can say for certain whether that will actually work.
Ugh, I meant to write, "I can't say for certain".
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev
Liam Girdwood wrote:
> Iirc, the SSI and DMA controllers on your SoC mean that each DMA device
> can only do one direction (either Playback or Capture). So I'm thinking
> we create two DAI link entries for your sound card (one for playback and
> the other for capture) and they both use the same SS
On Tue, 2010-04-27 at 09:52 -0500, Timur Tabi wrote:
> Liam Girdwood wrote:
>
> > Now I don't know the mechanics of adding an ASoC sound card to the
> > device tree, but the device tree should be able to define an ASoC sound
> > card and also represent the relationships between the sound card and
Liam Girdwood wrote:
> I think one of the difficulties encountered here is that the device tree
> root for sound in this case is the SSI (Digital Audio Interface)
> controller and not the sound card as in ASoC. So maybe the problem is
> how do we represent an ASoC sound card in the device tree ?
Hi Josh,
On Monday 26 April 2010 20:28:29 Josh Boyer wrote:
> On Mon, Apr 26, 2010 at 03:39:01PM +0200, Stefan Roese wrote:
> >By setting "reset_type" to one of the following values, the default
> >software reset mechanism may be overidden. Here the possible values of
>
> >"reset_type":
> NEAT!
On Thu, 22 Apr 2010, Guillaume Knispel wrote:
> When the critical section in handle_edge_irq() is executed after
> IRQ_DISABLED has been set in the one in disable_irq(), the interrupt is
in the one ? -ENOPARSE
> acked and masked at controller level and IRQ_PENDING is set.
> ---
> arch/arm/Kco
On Tue, 2010-04-27 at 12:48 +0200, Heiko Schocher wrote:
> Hello Benjamin,
>
> Benjamin Herrenschmidt wrote:
> > Hi Linus !
> >
> > PowerPC has been a bit quiet this time around :-) That is until Kumar
> > woke me up with a few fixes and defconfig updates for the freescale
> > embedded platforms.
Hello Benjamin,
Benjamin Herrenschmidt wrote:
> Hi Linus !
>
> PowerPC has been a bit quiet this time around :-) That is until Kumar
> woke me up with a few fixes and defconfig updates for the freescale
> embedded platforms.
I got no comments for the following patch:
http://lists.ozlabs.org/pip
On Tue, Apr 27, 2010 at 08:09:15PM +1000, Benjamin Herrenschmidt wrote:
> I think the main deal is to decide who gets to be the "master" node
> which contains the various properties doing the linkage. My gut feeling
> is that it could be the main transport, ie, the i2s or ac97, but people
> with m
On Tue, 2010-04-27 at 10:54 +0100, Mark Brown wrote:
> I'd just like to add that I *really* want to see you guys come to some
> sort of firm and documented conclusion about the way to handle
> situations like this. Some variant of this seems to come up every
> single time anyone tries to do anythi
On Tue, Apr 27, 2010 at 04:36:08PM +1000, Benjamin Herrenschmidt wrote:
> Gross. Loses the linkage to device-tree etc... which is useful for audio
> especially. You should at least make sure the device node follows for
> the target driver to be able to use it :-) I'd like you to sync with
> Grant
On Tue, 27 Apr 2010 17:05:21 +1000
Benjamin Herrenschmidt wrote:
> On Fri, 2010-04-02 at 15:50 +0900, FUJITA Tomonori wrote:
>
> > Thanks, here's the patch in the proper format.
> >
> > =
> > From: FUJITA Tomonori
> > Subject: [PATCH] ibmvscsi: fix DMA API misuse
> >
> > ibmvscsi uses dma_unm
Most things mentioned are either obsolete (platform-support) or wrong (device
numbering, DCD spport) these days. The remaining rest is obvious.
Signed-off-by: Wolfram Sang
Cc: Grant Likely
---
drivers/serial/mpc52xx_uart.c | 33 -
1 files changed, 0 insertions(
Currently the parsing of the device tree in
arch/powerpc/include/asm/parport.h assumes that the interrupt provided in
the parallel port node is a valid virtual irq. The values for the
interrupts provided in the device tree should have meaning in the context
of the driver for the specific interrupt
On Tue, 2010-04-27 at 16:36 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2010-04-26 at 15:49 -0500, Timur Tabi wrote:
> > An upcoming change in the architecture of ALSA SoC (ASoC) will require the
> > MPC8610 HPCD's ASoC fabric driver to register as a standard platform driver.
> > Therefore, we n
On Tue, 2010-04-27 at 09:42 +0200, Wim Van Sebroeck wrote:
> Hi Ben,
>
> > > commit 42747d712de56cf2087b702d2ad90af114c53138 ("[WATCHDOG]
> > > watchdog_info constify") introduced the following build failure:
> > >
> > >CC booke_wdt.o
> > > booke_wdt.c: In function 'booke_wdt_init':
> >
On Tue, 2010-04-27 at 09:12 +0200, Wolfram Sang wrote:
> > Oops... forgot those. Applied, will show up in -next soon.
>
> Ah, thanks. I also asked Ben Dooks to pick them up, but better twice
> than never
> ;)
Ok, Ben, are you taking them or do you want me to ?
Cheers,
Ben.
Hi Ben,
> > commit 42747d712de56cf2087b702d2ad90af114c53138 ("[WATCHDOG]
> > watchdog_info constify") introduced the following build failure:
> >
> >CC booke_wdt.o
> > booke_wdt.c: In function 'booke_wdt_init':
> > booke_wdt.c:220: error: assignment of read-only variable 'ident'
> >
>
Am 27.04.2010 um 02:30 schrieb Ian Munsie :
I'm using 32 bit userland and 64 bit kernel on a PowerPC box and
it's working for me.
Are you building perf from the tip tree?
I'm using kvm.git which is pretty close to tip. The version says
something 2.6.34-rc3'ish. Has anything significantly
On Tue, Apr 27, 2010 at 05:06:14PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2010-04-02 at 02:17 +0200, Wolfram Sang wrote:
> > Drop NO_IRQ as 0 is the preferred way to describe 'no irq'
> > (http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is
> > only used on powerpc,
On Fri, 2010-04-02 at 02:17 +0200, Wolfram Sang wrote:
> Drop NO_IRQ as 0 is the preferred way to describe 'no irq'
> (http://lkml.org/lkml/2005/11/21/221). This change is safe, as the driver is
> only used on powerpc, where NO_IRQ is 0 anyhow.
Oops... forgot those. Applied, will show up in -next
On Fri, 2010-04-02 at 15:50 +0900, FUJITA Tomonori wrote:
> Thanks, here's the patch in the proper format.
>
> =
> From: FUJITA Tomonori
> Subject: [PATCH] ibmvscsi: fix DMA API misuse
>
> ibmvscsi uses dma_unmap_single() for buffers mapped via
> dma_map_sg(). It works however it's the API viol
65 matches
Mail list logo
