diff mbox

[v2,5/6] ARM: mxc: all three imx51 TOs use TO1 version of sdma script

Message ID 1308032407-3860-1-git-send-email-shawn.guo@linaro.org
State New
Headers show

Commit Message

Shawn Guo June 14, 2011, 6:20 a.m. UTC 
Though there are three TOs of imx51 soc, the sdma script never
changes since TO1, which means all three TOs of imx51 uses TO1
version of sdma script.

The current code passes TO number to imx-sdma driver to load

Comments

Sascha Hauer June 14, 2011, 8:38 p.m. UTC | #1 
On Tue, Jun 14, 2011 at 02:20:07PM +0800, Shawn Guo wrote:
> Though there are three TOs of imx51 soc, the sdma script never
> changes since TO1, which means all three TOs of imx51 uses TO1
> version of sdma script.
> 
> The current code passes TO number to imx-sdma driver to load
> different firmware for different TO.  That means we have to prepare
> 3 identical firmwares, sdma-imx51-to1.bin sdma-imx51-to2.bin and
> sdma-imx51-to3.bin, to have the kernel capable of running on all
> three TOs.  This just makes no sense.
> 
> The patch removes the TO number passing and get the default TO1
> version of sdma firmware work for all TOs.

I don't agree to this approach. The SDMA firmware has been different on
all TO versions of earlier i.MXs. For the linearity of the universe we
should keep this. What about providing a link in userspace?

Sascha

> 
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> Changes since v1:
>  * fix typo in imx51 firmware name caught by Fabio Estevam
> 
>  arch/arm/plat-mxc/devices/platform-imx-dma.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> index c64f015..2091540 100644
> --- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
> +++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
> @@ -196,8 +196,6 @@ static int __init imxXX_add_imx_dma(void)
>  
>  #if defined(CONFIG_SOC_IMX51)
>  	if (cpu_is_mx51()) {
> -		int to_version = mx51_revision() >> 4;
> -		imx51_imx_sdma_data.pdata.to_version = to_version;
>  		imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51;
>  		ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
>  	} else
> -- 
> 1.7.4.1
> 
>
Shawn Guo June 15, 2011, 4:29 a.m. UTC | #2 
On Tue, Jun 14, 2011 at 10:38:09PM +0200, Sascha Hauer wrote:
> On Tue, Jun 14, 2011 at 02:20:07PM +0800, Shawn Guo wrote:
> > Though there are three TOs of imx51 soc, the sdma script never
> > changes since TO1, which means all three TOs of imx51 uses TO1
> > version of sdma script.
> > 
> > The current code passes TO number to imx-sdma driver to load
> > different firmware for different TO.  That means we have to prepare
> > 3 identical firmwares, sdma-imx51-to1.bin sdma-imx51-to2.bin and
> > sdma-imx51-to3.bin, to have the kernel capable of running on all
> > three TOs.  This just makes no sense.
> > 
> > The patch removes the TO number passing and get the default TO1
> > version of sdma firmware work for all TOs.
> 
> I don't agree to this approach. The SDMA firmware has been different on
> all TO versions of earlier i.MXs. For the linearity of the universe we
> should keep this. What about providing a link in userspace?
> 
The fact is that mx31 and mx35 are the only two SoCs (relatively old
ones) that have different SDMA firmwares on different TOs.  The
relatively new ones, mx25 (TO1, TO1.1), mx50 (TO1, TO1.1), mx51
(TO1, TO2, TO3) and mx53 (TO1, TO2) all have one version SDMA
firmware for different TOs.  I do not see the mx31/35 case is a
linearity of the universe.  Do we really want to bother ourselves
with userspace link on so many latest SoCs?
Sascha Hauer June 16, 2011, 7:30 a.m. UTC | #3 
On Wed, Jun 15, 2011 at 12:29:49PM +0800, Shawn Guo wrote:
> On Tue, Jun 14, 2011 at 10:38:09PM +0200, Sascha Hauer wrote:
> > On Tue, Jun 14, 2011 at 02:20:07PM +0800, Shawn Guo wrote:
> > > Though there are three TOs of imx51 soc, the sdma script never
> > > changes since TO1, which means all three TOs of imx51 uses TO1
> > > version of sdma script.
> > > 
> > > The current code passes TO number to imx-sdma driver to load
> > > different firmware for different TO.  That means we have to prepare
> > > 3 identical firmwares, sdma-imx51-to1.bin sdma-imx51-to2.bin and
> > > sdma-imx51-to3.bin, to have the kernel capable of running on all
> > > three TOs.  This just makes no sense.
> > > 
> > > The patch removes the TO number passing and get the default TO1
> > > version of sdma firmware work for all TOs.
> > 
> > I don't agree to this approach. The SDMA firmware has been different on
> > all TO versions of earlier i.MXs. For the linearity of the universe we
> > should keep this. What about providing a link in userspace?
> > 
> The fact is that mx31 and mx35 are the only two SoCs (relatively old
> ones) that have different SDMA firmwares on different TOs.  The
> relatively new ones, mx25 (TO1, TO1.1), mx50 (TO1, TO1.1), mx51
> (TO1, TO2, TO3) and mx53 (TO1, TO2) all have one version SDMA
> firmware for different TOs.  I do not see the mx31/35 case is a
> linearity of the universe.  Do we really want to bother ourselves
> with userspace link on so many latest SoCs?

Ok, then let's do it differently. Let's go away from "sdma-%s-to%d.bin"
in the sdma driver and pass the string from platform data instead.
Then we can pass the TO version where it's relevant and skip it where
only one firmware exists. Using a sdma-imx51-to1.bin for to2 and to3
is confusing.

Sascha
Shawn Guo June 16, 2011, 11:51 a.m. UTC | #4 
On Thu, Jun 16, 2011 at 09:30:18AM +0200, Sascha Hauer wrote:
> On Wed, Jun 15, 2011 at 12:29:49PM +0800, Shawn Guo wrote:
> > On Tue, Jun 14, 2011 at 10:38:09PM +0200, Sascha Hauer wrote:
> > > On Tue, Jun 14, 2011 at 02:20:07PM +0800, Shawn Guo wrote:
> > > > Though there are three TOs of imx51 soc, the sdma script never
> > > > changes since TO1, which means all three TOs of imx51 uses TO1
> > > > version of sdma script.
> > > > 
> > > > The current code passes TO number to imx-sdma driver to load
> > > > different firmware for different TO.  That means we have to prepare
> > > > 3 identical firmwares, sdma-imx51-to1.bin sdma-imx51-to2.bin and
> > > > sdma-imx51-to3.bin, to have the kernel capable of running on all
> > > > three TOs.  This just makes no sense.
> > > > 
> > > > The patch removes the TO number passing and get the default TO1
> > > > version of sdma firmware work for all TOs.
> > > 
> > > I don't agree to this approach. The SDMA firmware has been different on
> > > all TO versions of earlier i.MXs. For the linearity of the universe we
> > > should keep this. What about providing a link in userspace?
> > > 
> > The fact is that mx31 and mx35 are the only two SoCs (relatively old
> > ones) that have different SDMA firmwares on different TOs.  The
> > relatively new ones, mx25 (TO1, TO1.1), mx50 (TO1, TO1.1), mx51
> > (TO1, TO2, TO3) and mx53 (TO1, TO2) all have one version SDMA
> > firmware for different TOs.  I do not see the mx31/35 case is a
> > linearity of the universe.  Do we really want to bother ourselves
> > with userspace link on so many latest SoCs?
> 
> Ok, then let's do it differently. Let's go away from "sdma-%s-to%d.bin"
> in the sdma driver and pass the string from platform data instead.
> Then we can pass the TO version where it's relevant and skip it where
> only one firmware exists. Using a sdma-imx51-to1.bin for to2 and to3

That means the sdma firmware dose not change since to1, confusing?
But I'm fine with your idea, so okay, drop the patch from the series,
and let's address this issue with another patch.

Other patches look good to be applied?

> is confusing.
>
Fabio Estevam June 17, 2011, 1:59 a.m. UTC | #5 
On Thu, Jun 16, 2011 at 8:51 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
...
> That means the sdma firmware dose not change since to1, confusing?
> But I'm fine with your idea, so okay, drop the patch from the series,
> and let's address this issue with another patch.
>
> Other patches look good to be applied?

The other SDMA patches you sent are already in imx-for-2.6.40 now:
http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-for-2.6.40

I think it would be nice if Sascha could reply with a 'applied' email
so we know that the patches we sent were accepted.

Regards,

Fabio Estevam
Shawn Guo June 17, 2011, 2:27 a.m. UTC | #6 
On Thu, Jun 16, 2011 at 10:59:41PM -0300, Fabio Estevam wrote:
> On Thu, Jun 16, 2011 at 8:51 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> ...
> > That means the sdma firmware dose not change since to1, confusing?
> > But I'm fine with your idea, so okay, drop the patch from the series,
> > and let's address this issue with another patch.
> >
> > Other patches look good to be applied?
> 
> The other SDMA patches you sent are already in imx-for-2.6.40 now:
> http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-for-2.6.40
> 
Ah, thanks.  I have been keeping my eyes on branch imx-for-3.0, so
really did not check imx-for-2.6.40.  But patch #6 which is the main
initiative of the whole patch set is still not applied yet.  I
suppose it will go through imx-for-3.0.

Speaking of the branch name imx-for-3.0, I'm a little confused here.
Shouldn't it be imx-for-3.1, if it targets the next merge window?
I'm wrong?

> I think it would be nice if Sascha could reply with a 'applied' email
> so we know that the patches we sent were accepted.
> 
+1.  It would be even better with the branch info.
Sascha Hauer June 20, 2011, 7:20 a.m. UTC | #7 
On Fri, Jun 17, 2011 at 10:27:18AM +0800, Shawn Guo wrote:
> On Thu, Jun 16, 2011 at 10:59:41PM -0300, Fabio Estevam wrote:
> > On Thu, Jun 16, 2011 at 8:51 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
> > ...
> > > That means the sdma firmware dose not change since to1, confusing?
> > > But I'm fine with your idea, so okay, drop the patch from the series,
> > > and let's address this issue with another patch.
> > >
> > > Other patches look good to be applied?
> > 
> > The other SDMA patches you sent are already in imx-for-2.6.40 now:
> > http://git.pengutronix.de/?p=imx/linux-2.6.git;a=shortlog;h=refs/heads/imx-for-2.6.40
> > 
> Ah, thanks.  I have been keeping my eyes on branch imx-for-3.0, so
> really did not check imx-for-2.6.40.  But patch #6 which is the main
> initiative of the whole patch set is still not applied yet.  I
> suppose it will go through imx-for-3.0.
> 
> Speaking of the branch name imx-for-3.0, I'm a little confused here.
> Shouldn't it be imx-for-3.1, if it targets the next merge window?
> I'm wrong?
> 
> > I think it would be nice if Sascha could reply with a 'applied' email
> > so we know that the patches we sent were accepted.
> > 
> +1.  It would be even better with the branch info. 

+1. Wait, I am Sascha. Will do in the future.

Sascha
diff mbox

Patch

different firmware for different TO.  That means we have to prepare
3 identical firmwares, sdma-imx51-to1.bin sdma-imx51-to2.bin and
sdma-imx51-to3.bin, to have the kernel capable of running on all
three TOs.  This just makes no sense.

The patch removes the TO number passing and get the default TO1
version of sdma firmware work for all TOs.

Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
---
Changes since v1:
 * fix typo in imx51 firmware name caught by Fabio Estevam

 arch/arm/plat-mxc/devices/platform-imx-dma.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/arm/plat-mxc/devices/platform-imx-dma.c b/arch/arm/plat-mxc/devices/platform-imx-dma.c
index c64f015..2091540 100644
--- a/arch/arm/plat-mxc/devices/platform-imx-dma.c
+++ b/arch/arm/plat-mxc/devices/platform-imx-dma.c
@@ -196,8 +196,6 @@  static int __init imxXX_add_imx_dma(void)
 
 #if defined(CONFIG_SOC_IMX51)
 	if (cpu_is_mx51()) {
-		int to_version = mx51_revision() >> 4;
-		imx51_imx_sdma_data.pdata.to_version = to_version;
 		imx51_imx_sdma_data.pdata.script_addrs = &addr_imx51;
 		ret = imx_add_imx_sdma(&imx51_imx_sdma_data);
 	} else