diff for duplicates of <4F5980DE.9050002@freescale.com> diff --git a/a/1.txt b/N1/1.txt index 5e513fd..8af94f3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,36 +17,24 @@ What do you mean by "already tuned". Tuned by whom? >> >> So I'm a little confused by this new binding. I went through a lot of >> work to remove DMA-specific data from the SSI driver, and here you are ->> adding a bunch of it back. What you're doing here -- I'm doing it in the ->> DMA driver where it belongs. -> -> I'm not sure these all belong to DMA driver. These are all -> configurations/parameters of SSI, which are related to DMA though. -> I see fsl_dma are handling these, but I do not fully agree with that, -> because we end up with fsl_dma driver accessing SSI node and -> "struct ccsr_ssi" which should be SSI private data. - -Well, the SSI needs to tell the DMA driver how to program itself. On -PowerPC, the DMA's burst size is based on the SSI's FIFO depth. You're -effectively doing what I already do, except you do more work in the SSI -driver. - -I understand that we need to support old and new bindings, but I already -created an infrastructure that supports passing SSI information to the DMA -driver. It seems that the above code is different only for the sake of -being different, not because it's better. - -This is not really an i.MX vs. PowerPC issue, which is why I'm not sure -this change belong in this patchset. - -> Secondly, this is the way that how imx-ssi and imx-pcm-dma works and -> interacts. If we want to move these stuff into imx-pcm-dma, we need -> a good story to convince imx-ssi users that why it's better than what -> they currently do. - -I don't understand that. You're already rewriting these drivers. Who -else needs to be convinced? - --- -Timur Tabi -Linux kernel developer at Freescale +>> aFrom arnd at arndb.de Mon Mar 12 12:43:25 2012 +From: arnd@arndb.de (Arnd Bergmann) +Date: Mon, 12 Mar 2012 16:43:25 +0000 +Subject: [PATCH 1/2] ARM: kirkwood: Basic support for DNS-320 and DNS-325 +In-Reply-To: <20120312161004.GB5050@titan.lakedaemon.net> +References: <1331476406-9844-1-git-send-email-jm@lentin.co.uk> + <201203120811.23137.arnd@arndb.de> + <20120312161004.GB5050@titan.lakedaemon.net> +Message-ID: <201203121643.26133.arnd@arndb.de> + +On Monday 12 March 2012, Jason Cooper wrote: +> Okay, that's what smelled funny. wdt and intc both only have registers +> in virtual address space defined. Can I assume they map like everything +> else to corresponding physical addresses? +> +> eg wdt at fed20300 -> wdt at f1020300 ? + +Yes, correct. Or just uses 20300 as the address if you remap everything +using the ranges property. + + Arnd diff --git a/a/content_digest b/N1/content_digest index 7e08a18..54a18f4 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,15 +2,10 @@ "ref\01331225990-27308-11-git-send-email-shawn.guo@linaro.org\0" "ref\04F591A69.9060401@freescale.com\0" "ref\020120309031909.GJ2499@S2101-09.ap.freescale.net\0" - "From\0Tabi Timur-B04825 <B04825@freescale.com>\0" - "Subject\0Re: [PATCH v3 10/11] ASoC: fsl: let fsl_ssi work with imx pcm and machine drivers\0" + "From\0B04825@freescale.com (Tabi Timur-B04825)\0" + "Subject\0[PATCH v3 10/11] ASoC: fsl: let fsl_ssi work with imx pcm and machine drivers\0" "Date\0Fri, 9 Mar 2012 04:02:40 +0000\0" - "To\0Shawn Guo <shawn.guo@linaro.org>\0" - "Cc\0alsa-devel@alsa-project.org <alsa-devel@alsa-project.org>" - Mark Brown <broonie@opensource.wolfsonmicro.com> - Tabi Timur-B04825 <B04825@freescale.com> - Sascha Hauer <s.hauer@pengutronix.de> - " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0" + "To\0linux-arm-kernel@lists.infradead.org\0" "\00:1\0" "b\0" "Shawn Guo wrote:\n" @@ -32,38 +27,26 @@ ">>\n" ">> So I'm a little confused by this new binding. I went through a lot of\n" ">> work to remove DMA-specific data from the SSI driver, and here you are\n" - ">> adding a bunch of it back. What you're doing here -- I'm doing it in the\n" - ">> DMA driver where it belongs.\n" - ">\n" - "> I'm not sure these all belong to DMA driver. These are all\n" - "> configurations/parameters of SSI, which are related to DMA though.\n" - "> I see fsl_dma are handling these, but I do not fully agree with that,\n" - "> because we end up with fsl_dma driver accessing SSI node and\n" - "> \"struct ccsr_ssi\" which should be SSI private data.\n" - "\n" - "Well, the SSI needs to tell the DMA driver how to program itself. On \n" - "PowerPC, the DMA's burst size is based on the SSI's FIFO depth. You're \n" - "effectively doing what I already do, except you do more work in the SSI \n" - "driver.\n" - "\n" - "I understand that we need to support old and new bindings, but I already \n" - "created an infrastructure that supports passing SSI information to the DMA \n" - "driver. It seems that the above code is different only for the sake of \n" - "being different, not because it's better.\n" - "\n" - "This is not really an i.MX vs. PowerPC issue, which is why I'm not sure \n" - "this change belong in this patchset.\n" - "\n" - "> Secondly, this is the way that how imx-ssi and imx-pcm-dma works and\n" - "> interacts. If we want to move these stuff into imx-pcm-dma, we need\n" - "> a good story to convince imx-ssi users that why it's better than what\n" - "> they currently do.\n" - "\n" - "I don't understand that. You're already rewriting these drivers. Who \n" - "else needs to be convinced?\n" - "\n" - "-- \n" - "Timur Tabi\n" - Linux kernel developer at Freescale + ">> aFrom arnd at arndb.de Mon Mar 12 12:43:25 2012\n" + "From: arnd@arndb.de (Arnd Bergmann)\n" + "Date: Mon, 12 Mar 2012 16:43:25 +0000\n" + "Subject: [PATCH 1/2] ARM: kirkwood: Basic support for DNS-320 and DNS-325\n" + "In-Reply-To: <20120312161004.GB5050@titan.lakedaemon.net>\n" + "References: <1331476406-9844-1-git-send-email-jm@lentin.co.uk>\n" + " <201203120811.23137.arnd@arndb.de>\n" + " <20120312161004.GB5050@titan.lakedaemon.net>\n" + "Message-ID: <201203121643.26133.arnd@arndb.de>\n" + "\n" + "On Monday 12 March 2012, Jason Cooper wrote:\n" + "> Okay, that's what smelled funny. wdt and intc both only have registers\n" + "> in virtual address space defined. Can I assume they map like everything\n" + "> else to corresponding physical addresses?\n" + "> \n" + "> eg wdt at fed20300 -> wdt at f1020300 ?\n" + "\n" + "Yes, correct. Or just uses 20300 as the address if you remap everything\n" + "using the ranges property.\n" + "\n" + "\tArnd" -917135efda5c7c28a402a3f68016600b0222577256098074704213d17638918c +b8a1d49c884c92d904ba67bfff52b45b138f31c728e10835fd8008756d640de5
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.