All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Jon Hunter <jon-hunter@ti.com>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Subject: Re: [PATCH 05/10] omap1: Fix DSP public peripherals support for ams-delta
Date: Fri, 23 Oct 2009 12:19:40 -0700	[thread overview]
Message-ID: <20091023191939.GJ16230@atomide.com> (raw)
In-Reply-To: <4AE0E938.7080305@ti.com>

* Jon Hunter <jon-hunter@ti.com> [091022 16:22]:
>
> Tony Lindgren wrote:
>> From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>>
>> DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?)
>> machines as long as old dspgateway code were present in the l-o tree. For
>> several months it is no longer included, breaking support for McBSP1 based
>> audio on Amstrad Delta, for example.
>>
>> This patch, derived from the old dspgateway code, corrects the problem for the
>> board by simply taking the DSP out of reset state, I guess. That way, things
>> should not break when a new dsp code is added to the tree, and the change can
>> be reverted then.
>
> A minor comment/correction here. Although this bit is called "DSP_RST"  
> this does not actually release the DSP from reset. This bit actually  
> releases the reset for the "priority registers (TIPB module), EMIF  
> configuration registers, and the MPUI control logic (partially) in the  
> DSP", thus allowing you to access the DSP peripherals via the MPUI. Bit  
> 1 of the same register, called "DSP_EN", actually releases the DSP reset.

Thanks for clarifying that.

>> If there are any reports on McBSP1 or other DSP public peripherals not working
>> for other OMAP1 machines (I've not heard of any for now), I can prepare a more
>> general patch providing an extra include file with a helper function defined.
>
> This would be necessary for all OMAP15xx based devices that use McBSP1  
> (or McBSP3 for that matter). However, I am not sure if it is common for  
> other boards to use McBSP1 for audio.

Yeah, I guess currently only board-ams-delta.c needs this for audio.
But that could of course change once there are more 15xx boards using ASoC.

Regards,

Tony

WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 05/10] omap1: Fix DSP public peripherals support for ams-delta
Date: Fri, 23 Oct 2009 12:19:40 -0700	[thread overview]
Message-ID: <20091023191939.GJ16230@atomide.com> (raw)
In-Reply-To: <4AE0E938.7080305@ti.com>

* Jon Hunter <jon-hunter@ti.com> [091022 16:22]:
>
> Tony Lindgren wrote:
>> From: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>
>>
>> DSP public peripherals used to work on OMAP1510 based (or all OMAP1 class?)
>> machines as long as old dspgateway code were present in the l-o tree. For
>> several months it is no longer included, breaking support for McBSP1 based
>> audio on Amstrad Delta, for example.
>>
>> This patch, derived from the old dspgateway code, corrects the problem for the
>> board by simply taking the DSP out of reset state, I guess. That way, things
>> should not break when a new dsp code is added to the tree, and the change can
>> be reverted then.
>
> A minor comment/correction here. Although this bit is called "DSP_RST"  
> this does not actually release the DSP from reset. This bit actually  
> releases the reset for the "priority registers (TIPB module), EMIF  
> configuration registers, and the MPUI control logic (partially) in the  
> DSP", thus allowing you to access the DSP peripherals via the MPUI. Bit  
> 1 of the same register, called "DSP_EN", actually releases the DSP reset.

Thanks for clarifying that.

>> If there are any reports on McBSP1 or other DSP public peripherals not working
>> for other OMAP1 machines (I've not heard of any for now), I can prepare a more
>> general patch providing an extra include file with a helper function defined.
>
> This would be necessary for all OMAP15xx based devices that use McBSP1  
> (or McBSP3 for that matter). However, I am not sure if it is common for  
> other boards to use McBSP1 for audio.

Yeah, I guess currently only board-ams-delta.c needs this for audio.
But that could of course change once there are more 15xx boards using ASoC.

Regards,

Tony

  reply	other threads:[~2009-10-23 19:19 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-22 22:11 [PATCH 00/10] omap fixes for v2.6.32-rc5 Tony Lindgren
2009-10-22 22:11 ` Tony Lindgren
2009-10-22 22:11 ` [PATCH 01/10] omap: Fix omap-keypad by restoring old keypad.h without breaking omap2 boards that use matrix_keypad Tony Lindgren
2009-10-22 22:11   ` Tony Lindgren
2009-10-22 22:11 ` [PATCH 02/10] omap: SDMA: Fix omap_stop_dma() API for channel linking Tony Lindgren
2009-10-22 22:11   ` Tony Lindgren
2009-10-22 22:11   ` Tony Lindgren
2009-10-22 22:11 ` [PATCH 03/10] omap: iommu: fix wrong condition check for SUPERSECTION Tony Lindgren
2009-10-22 22:11   ` Tony Lindgren
2009-10-22 22:12 ` [PATCH 04/10] omap1: Fix redundant UARTs pin muxing that can break other hardware support Tony Lindgren
2009-10-22 22:12   ` Tony Lindgren
2009-10-22 22:12 ` [PATCH 05/10] omap1: Fix DSP public peripherals support for ams-delta Tony Lindgren
2009-10-22 22:12   ` Tony Lindgren
2009-10-22 23:22   ` Jon Hunter
2009-10-22 23:22     ` Jon Hunter
2009-10-23 19:19     ` Tony Lindgren [this message]
2009-10-23 19:19       ` Tony Lindgren
2009-10-23 23:11       ` Janusz Krzysztofik
2009-10-23 23:11         ` Janusz Krzysztofik
2009-10-23 23:11         ` Janusz Krzysztofik
2009-10-22 22:12 ` [PATCH 06/10] omap: Fix detection of n8x0 Tony Lindgren
2009-10-22 22:12   ` Tony Lindgren
2009-10-22 22:12 ` [PATCH 07/10] omap2: Fix console serial port number for n8x0 Tony Lindgren
2009-10-22 22:12   ` Tony Lindgren
2009-10-22 22:12 ` [PATCH 08/10] omap3: PM: enable UART3 module wakeups Tony Lindgren
2009-10-22 22:12   ` Tony Lindgren
2009-10-22 22:13 ` [PATCH 09/10] omap4: Allow omap_serial_early_init() for OMAP4430 board Tony Lindgren
2009-10-22 22:13   ` Tony Lindgren
2009-10-22 22:13 ` [PATCH 10/10] omap4: Fix UART4 platform data on omap4 Tony Lindgren
2009-10-22 22:13   ` Tony Lindgren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091023191939.GJ16230@atomide.com \
    --to=tony@atomide.com \
    --cc=jkrzyszt@tis.icnet.pl \
    --cc=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.