* Re: MMCIF support on sh7757lcr
From: Guennadi Liakhovetski @ 2012-01-11 8:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1201101646050.530@axis700.grange>
On Wed, 11 Jan 2012, Shimoda, Yoshihiro wrote:
> Hello Guennadi-san,
>
> Thank you for your review.
>
> 2012/01/11 0:55, Guennadi Liakhovetski wrote:
> > Hello Shimoda-san
> >
> > While reviewing MMCIF platform bindings, I came across your commit
> >
> > commit 65f63eab38626a79f8a54d13686680a1ea898f72
> > Author: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> > Date: Fri Feb 25 07:40:27 2011 +0000
> >
> > sh: add platform_device of tmio_mmc and sh_mmcif to sh7757lcr
> >
> > There you only specify MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA
> > capabilities for MMCIF. The MMCIF controller does not have any native
> > support for card hotplug detection, therefore it must either be polled, or
> > the card has to be marked non-removable. For polling it is also desired to
> > provide a .get_cd() method. Neither of these is done for sh7757lcr. Is the
> > MMC card on it removable? If so, is there any way to detect card presence
> > in the slot?
>
> This board doesn't have the MMC card slot. A MMC chip is on the board,
> so we cannot remove the chip.
> In the linux-3.2-rc7, the sh7757lcr can detect the MMC chip and
> I can see the "mmcblk" device.
Right, it is detected upon driver initialisation, but id it were a normal
slot, card ejects and inserts wouldn't be recognised. In this case we have
to specify MMC_CAP_NONREMOVABLE among controller sapabilities:
static struct sh_mmcif_plat_data sh_mmcif_plat = {
...
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
MMC_CAP_NONREMOVABLE,
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH v4 2/6] sh: add a resource name for shdma
From: Guennadi Liakhovetski @ 2012-01-11 9:05 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39F5.90208@renesas.com>
Unrelated to your patch, just something that caught my eye:
On Wed, 11 Jan 2012, Shimoda, Yoshihiro wrote:
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> about v4:
> - use defination macros for IRQ resource
>
> arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 3 +++
> arch/sh/kernel/cpu/sh4a/setup-sh7724.c | 6 ++++++
> arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 16 ++++++++++++++++
> arch/sh/kernel/cpu/sh4a/setup-sh7780.c | 2 ++
> arch/sh/kernel/cpu/sh4a/setup-sh7785.c | 2 ++
> arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 2 ++
> 6 files changed, 31 insertions(+), 0 deletions(-)
[snip]
> diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7780.c b/arch/sh/kernel/cpu/sh4a/setup-sh7780.c
> index 3d4d207..cd8d1e9 100644
> --- a/arch/sh/kernel/cpu/sh4a/setup-sh7780.c
> +++ b/arch/sh/kernel/cpu/sh4a/setup-sh7780.c
> @@ -322,6 +322,7 @@ static struct resource sh7780_dmae0_resources[] = {
> },
> {
> /* Real DMA error IRQ is 38, and channel IRQs are 34-37, 44-45 */
> + .name = SH_DMA_IRQ_ERROR,
> .start = 34,
> .end = 34,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_SHAREABLE,
> @@ -338,6 +339,7 @@ static struct resource sh7780_dmae1_resources[] = {
> /* DMAC1 has no DMARS */
> {
> /* Real DMA error IRQ is 38, and channel IRQs are 46-47, 92-95 */
> + .name = SH_DMA_IRQ_ERROR,
> .start = 46,
> .end = 46,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_SHAREABLE,
> diff --git a/arch/sh/kernel/cpu/sh4a/setup-sh7785.c b/arch/sh/kernel/cpu/sh4a/setup-sh7785.c
> index b29e634..1cdb9ec 100644
> --- a/arch/sh/kernel/cpu/sh4a/setup-sh7785.c
> +++ b/arch/sh/kernel/cpu/sh4a/setup-sh7785.c
> @@ -376,6 +376,7 @@ static struct resource sh7785_dmae0_resources[] = {
> },
> {
> /* Real DMA error IRQ is 39, and channel IRQs are 33-38 */
> + .name = SH_DMA_IRQ_ERROR,
> .start = 33,
> .end = 33,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_SHAREABLE,
> @@ -392,6 +393,7 @@ static struct resource sh7785_dmae1_resources[] = {
> /* DMAC1 has no DMARS */
> {
> /* Real DMA error IRQ is 58, and channel IRQs are 52-57 */
> + .name = SH_DMA_IRQ_ERROR,
> .start = 52,
> .end = 52,
> .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_SHAREABLE,
The above two platforms seem incorrect. Back then, as I switched sh_dma.c
to use resources for interrupts [1], I just reproduced the behaviour of
the original driver, but a verification with the header or the datasheet
shows, that sh7780 and sh7785 have separate interrupts per channel, so, if
anyone cares about those platforms, they might need a fix.
Thanks
Guennadi
[1] http://thread.gmane.org/gmane.linux.ports.sh.devel/7269/focusr70
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: MMCIF support on sh7757lcr
From: Shimoda, Yoshihiro @ 2012-01-12 0:41 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1201101646050.530@axis700.grange>
Hello Guennadi-san,
2012/01/11 17:24, Guennadi Liakhovetski wrote:
> Right, it is detected upon driver initialisation, but id it were a normal
> slot, card ejects and inserts wouldn't be recognised. In this case we have
> to specify MMC_CAP_NONREMOVABLE among controller sapabilities:
>
> static struct sh_mmcif_plat_data sh_mmcif_plat = {
> ...
> .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA |
> MMC_CAP_NONREMOVABLE,
Thank you very much for your point.
I will write a patch for this.
Best regards,
Yoshihiro Shimoda
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
^ permalink raw reply
* Re: [PATCH v4 1/6] dmaengine: shdma: add IRQ resource name definition macros
From: Paul Mundt @ 2012-01-12 1:04 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39E7.4020102@renesas.com>
On Wed, Jan 11, 2012 at 04:27:35PM +0900, Shimoda, Yoshihiro wrote:
> The SH DMAC has an ERROR IRQ and channel IRQs. So, the defination
> macros are used as the resource name, and the resource name will be
> used to detect each IRQ by the driver.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> about v4:
> - add defination macros for IRQ resource first.
>
> include/linux/sh_dma.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index cb2dd11..a6c82cc 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -13,6 +13,10 @@
> #include <linux/list.h>
> #include <linux/dmaengine.h>
>
> +/* resource name of IORESOURCE_IRQ */
> +#define SH_DMA_IRQ_ERROR "error"
> +#define SH_DMA_IRQ_CHANNEL "channel"
> +
Why? This is just pointless churn, there's nothing wrong with using the
strings open-coded like the vast majority of other drivers/platforms do
without issue. If you can't spell it properly, too bad.
^ permalink raw reply
* Re: [PATCH v4 2/6] sh: add a resource name for shdma
From: Shimoda, Yoshihiro @ 2012-01-12 1:09 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39F5.90208@renesas.com>
2012/01/11 18:05, Guennadi Liakhovetski wrote:
> Unrelated to your patch, just something that caught my eye:
>
[ snip ]
>
> The above two platforms seem incorrect. Back then, as I switched sh_dma.c
> to use resources for interrupts [1], I just reproduced the behaviour of
> the original driver, but a verification with the header or the datasheet
> shows, that sh7780 and sh7785 have separate interrupts per channel, so, if
> anyone cares about those platforms, they might need a fix.
The interrupts of SH7780 DMAC and Sh7785 DMAC are strange.
Would you check the commit bdaa6e8062 "sh: multiple vectors per irq - base"?
- The SH7780 and SH7785 have separate INTEVT per channel, but the INT2MSKR
for the DMAC has one bit.
-- In this case, the commit log says:
"If multiple vectors shar the same enum then only the
first vector will be avilable as a linux irq."
- I think that the DMTE4_IRQ of SH7780 and SH7785 in
the "arch/sh/include/cpu-sh4/cpu/dma-sh4a.h" is breaking.
But, the old DMA API driver doesn't use this actually because the get_dmte_irq()
in dma-sh.c will change the IRQ number...
Best regards,
Yoshihiro Shimoda
> Thanks
> Guennadi
>
> [1] http://thread.gmane.org/gmane.linux.ports.sh.devel/7269/focusr70
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
>
--
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
EC No.
^ permalink raw reply
* Re: [PATCH v4 3/6] arm: mach-shmobile: add a resource name for shdma
From: Paul Mundt @ 2012-01-12 1:11 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39FE.1090900@renesas.com>
On Wed, Jan 11, 2012 at 04:27:58PM +0900, Shimoda, Yoshihiro wrote:
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> about v4:
> - use defination macros for IRQ resource
>
> arch/arm/mach-shmobile/setup-sh7372.c | 8 ++++++++
> arch/arm/mach-shmobile/setup-sh73a0.c | 2 ++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
I'll just be applying the original two with the strings written out, you
can figure out how you want to deal with the rest of the series on top of
that.
^ permalink raw reply
* Re: [PATCH v4 1/6] dmaengine: shdma: add IRQ resource name definition macros
From: Shimoda, Yoshihiro @ 2012-01-12 1:54 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39E7.4020102@renesas.com>
2012/01/12 10:04, Paul Mundt wrote:
> On Wed, Jan 11, 2012 at 04:27:35PM +0900, Shimoda, Yoshihiro wrote:
>> The SH DMAC has an ERROR IRQ and channel IRQs. So, the defination
>> macros are used as the resource name, and the resource name will be
>> used to detect each IRQ by the driver.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> ---
>> about v4:
>> - add defination macros for IRQ resource first.
>>
>> include/linux/sh_dma.h | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
>> index cb2dd11..a6c82cc 100644
>> --- a/include/linux/sh_dma.h
>> +++ b/include/linux/sh_dma.h
>> @@ -13,6 +13,10 @@
>> #include <linux/list.h>
>> #include <linux/dmaengine.h>
>>
>> +/* resource name of IORESOURCE_IRQ */
>> +#define SH_DMA_IRQ_ERROR "error"
>> +#define SH_DMA_IRQ_CHANNEL "channel"
>> +
> Why? This is just pointless churn, there's nothing wrong with using the
> strings open-coded like the vast majority of other drivers/platforms do
> without issue. If you can't spell it properly, too bad.
>
Thank you for your point.
I read your comment, I thought that it is good.
I am mixed up about the shdma driver patch for the Error IRQ registration...
I am thinking that the v3 patches are good because they have Paul's "Acked-by".
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH v4 1/6] dmaengine: shdma: add IRQ resource name definition macros
From: Paul Mundt @ 2012-01-12 1:57 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39E7.4020102@renesas.com>
On Thu, Jan 12, 2012 at 10:54:49AM +0900, Shimoda, Yoshihiro wrote:
> 2012/01/12 10:04, Paul Mundt wrote:
> > On Wed, Jan 11, 2012 at 04:27:35PM +0900, Shimoda, Yoshihiro wrote:
> >> The SH DMAC has an ERROR IRQ and channel IRQs. So, the defination
> >> macros are used as the resource name, and the resource name will be
> >> used to detect each IRQ by the driver.
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> ---
> >> about v4:
> >> - add defination macros for IRQ resource first.
> >>
> >> include/linux/sh_dma.h | 4 ++++
> >> 1 files changed, 4 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> >> index cb2dd11..a6c82cc 100644
> >> --- a/include/linux/sh_dma.h
> >> +++ b/include/linux/sh_dma.h
> >> @@ -13,6 +13,10 @@
> >> #include <linux/list.h>
> >> #include <linux/dmaengine.h>
> >>
> >> +/* resource name of IORESOURCE_IRQ */
> >> +#define SH_DMA_IRQ_ERROR "error"
> >> +#define SH_DMA_IRQ_CHANNEL "channel"
> >> +
> > Why? This is just pointless churn, there's nothing wrong with using the
> > strings open-coded like the vast majority of other drivers/platforms do
> > without issue. If you can't spell it properly, too bad.
> >
>
> Thank you for your point.
> I read your comment, I thought that it is good.
>
> I am mixed up about the shdma driver patch for the Error IRQ registration...
> I am thinking that the v3 patches are good because they have Paul's "Acked-by".
>
Yes, the v3 patches are fine. There's no particular need for stop-gap
transition patches as we'll have these error string patches in place for
the relevant platforms long before these patches hit mainline, and
anything out of tree obviously doesn't matter.
^ permalink raw reply
* Re: [PATCH v4 3/6] arm: mach-shmobile: add a resource name for shdma
From: Shimoda, Yoshihiro @ 2012-01-12 2:02 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D39FE.1090900@renesas.com>
2012/01/12 10:11, Paul Mundt wrote:
> On Wed, Jan 11, 2012 at 04:27:58PM +0900, Shimoda, Yoshihiro wrote:
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> ---
>> about v4:
>> - use defination macros for IRQ resource
>>
>> arch/arm/mach-shmobile/setup-sh7372.c | 8 ++++++++
>> arch/arm/mach-shmobile/setup-sh73a0.c | 2 ++
>> 2 files changed, 10 insertions(+), 0 deletions(-)
>>
> I'll just be applying the original two with the strings written out, you
> can figure out how you want to deal with the rest of the series on top of
> that.
>
I understood it.
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH v4 4/6] dmaengine: shdma: modify the DMAC Address Error registration
From: Paul Mundt @ 2012-01-12 2:06 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D3A04.4030209@renesas.com>
On Wed, Jan 11, 2012 at 04:28:04PM +0900, Shimoda, Yoshihiro wrote:
> The USB-DMAC/SUDMAC don't have the interrupt of DMAC Address Error.
> So, only if the IRQ resource has a name of SH_DMA_IRQ_ERROR, the driver
> calls request_irq() for DMAC Address Error.
>
> This patch is also useful for the generic DMAC which doesn't have
> DMAC Address Error. So, we can get rid of the "CPU_SH4 || ARCH_SHMOBILE"
> ifdefs.
> This patch also changes the IRQF_DISABLED to 0.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> about v4:
> - use defination macros for IRQ resource
>
> drivers/dma/shdma.c | 73 +++++++++++++++++++++++++--------------------------
> 1 files changed, 36 insertions(+), 37 deletions(-)
>
I do like the idea of the _byname() variants for the channel and error
resource at least, but they are separate patches. I don't particularly
like mixing the channel stuff in with the DMA address error changes,
since they are fundamentally different changes.
If we go with the v3 patches for fixing up the address error case then
you should be able to trivially layer on the channel resource cleanup on
top of that, which in turn will require another string patch for ARM/sh
naming the channel resources explicitly.
^ permalink raw reply
* Re: [PATCH] sh: also without PM_RUNTIME pm_runtime.o must be built
From: Paul Mundt @ 2012-01-12 3:24 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <Pine.LNX.4.64.1201101559450.530@axis700.grange>
On Tue, Jan 10, 2012 at 04:04:11PM +0100, Guennadi Liakhovetski wrote:
> When CONFIG_PM_RUNTIME is off, drivers/sh/pm_runtime.o still has to be
> built on sh platforms, because then it provides means to statically
> switch on device PM clocks.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3] sh: sh2a: Improve cache flush/invalidate functions
From: Paul Mundt @ 2012-01-12 4:11 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1326125327-30189-1-git-send-email-phil.edworthy@renesas.com>
On Mon, Jan 09, 2012 at 04:08:47PM +0000, Phil Edworthy wrote:
> The cache functions lock out interrupts for long periods; this patch
> reduces the impact when operating on large address ranges. In such
> cases it will:
> - Invalidate the entire cache rather than individual addresses.
> - Do nothing when flushing the operand cache in write-through mode.
> - When flushing the operand cache in write-back mdoe, index the
> search for matching addresses on the cache entires instead of the
> addresses to flush
>
> Note: sh2a__flush_purge_region was only invalidating the operand
> cache, this adds flush.
>
> Signed-off-by: Phil Edworthy <phil.edworthy@renesas.com>
> ---
> v3:
> 1. Refactored code to make it readable and correct formatting.
> 2. Added code to handle flushing large address ranges in
> write-back mode.
>
Looks good. Applied, thanks Phil.
^ permalink raw reply
* [GIT PULL] sh updates for 3.3-rc1
From: Paul Mundt @ 2012-01-12 6:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-sh, linux-kernel
Here goes my attempt at a merge request by way of signed tag, hopefully
I've not botched anything too terribly.
I noticed some people using 3.3 in their signed tags and others with a
single for-linus one that seems like it will be overwritten on each
subsequent merge. I've opted for the latter as presumably verification is
only of interest at the time of merging, but can switch to the former if
that's the preferred way going forward.
Ideally this should be pulled prior to the rmobile updates, which build
on top of some of the changes in here.
The following changes since commit e343a895a9f342f239c5e3c5ffc6c0b1707e6244:
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost (2012-01-10 18:04:27 -0800)
are available in the git repository at:
git://github.com/pmundt/linux-sh sh-for-linus
for you to fetch changes up to 1c1744cc7cee83b96e3a89c1b9853fc033bafb9c:
sh: magicpanelr2: Update for parse_mtd_partitions() fallout. (2012-01-12 13:49:05 +0900)
----------------------------------------------------------------
SuperH updates for 3.3 merge window.
----------------------------------------------------------------
Guennadi Liakhovetski (5):
sh: sh7724: use runtime PM implementation, common with arm/mach-shmobile
sh: sh7722: use runtime PM implementation, common with arm/mach-shmobile
sh: sh7723: use runtime PM implementation, common with arm/mach-shmobile
sh: sh7722: fix Oops: remove empty clock entries
sh: also without PM_RUNTIME pm_runtime.o must be built
Kuninori Morimoto (7):
sh: sh7724.h: bugfix: remove unused clock index
sh: sh7723.h: bugfix: remove unused clock index
sh: clkfwk: setup clock parent from current register value
sh: clock-sh7723: add CLKDEV_ICK_ID for cleanup
sh: clkfwk: clock-sh7724: all div6_clks use SH_CLK_DIV6_EXT()
sh: clkfwk: clock-sh73a0: all div6_clks use SH_CLK_DIV6_EXT()
sh: clkfwk: sh_clk_init_parent() should be called after clk_register()
Magnus Damm (5):
sh: extend clock struct with mapped_reg member
sh: use ioread32/iowrite32 and mapped_reg for mstp32
sh: use ioread32/iowrite32 and mapped_reg for div4
sh: use ioread32/iowrite32 and mapped_reg for div6
sh: pfc: ioremap() support
Paul Mundt (24):
sh: Kill off remaining private runtime PM bits.
sh: cpuidle: Migrate off of hwblk API.
sh: hwblk: Kill off hwblk_id from pdev archdata.
sh: hwblk: Kill off remaining bits of hwblk API.
serial: sh-sci: Fix up SCFCR handling.
serial: sh-sci: Support icount statistics for error cases.
serial: sh-sci: Clarify enable_ms/break_ctl comments.
serial: sh-sci: Fix up modem control handling.
serial: sh-sci: Add support for loopback mode.
serial: sh-sci: per-port modem control.
serial: sh-sci: Avoid FIFO clear for MCE toggle.
serial: sh-sci: Handle GPIO function requests.
Merge branches 'common/clkfwk', 'common/pfc' and 'common/serial-rework' into sh-latest
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux into sh-latest
Merge branch 'common/clkfwk' into sh-latest
sh: Fix up store queue code for subsys_interface changes.
sh: Ensure IRQs are enabled across do_notify_resume().
sh: Remove redundant try_to_freeze() invocations.
Merge branch 'sh/urgent' into sh-latest
Merge branch 'sh/pm-runtime' into sh-latest
Merge branch 'sh/hwblk' into sh-latest
Merge branch 'sh/nommu' into sh-latest
sh: mach-rsk: Update for parse_mtd_partitions() fallout.
sh: magicpanelr2: Update for parse_mtd_partitions() fallout.
Phil Edworthy (1):
sh: sh2a: Improve cache flush/invalidate functions
Shimoda, Yoshihiro (3):
sh: modify clock-sh7757 for renesas_usbhs
sh: add platform_device for renesas_usbhs in board-sh7757lcr
sh: add a resource name for shdma
arch/arm/mach-shmobile/clock-sh7372.c | 6 +-
arch/arm/mach-shmobile/clock-sh73a0.c | 140 ++++++++++--
arch/arm/mach-shmobile/include/mach/common.h | 2 +
arch/sh/boards/board-magicpanelr2.c | 34 +---
arch/sh/boards/board-sh7757lcr.c | 39 +++
arch/sh/boards/mach-ap325rxa/setup.c | 12 -
arch/sh/boards/mach-ecovec24/setup.c | 36 ---
arch/sh/boards/mach-kfr2r09/setup.c | 12 -
arch/sh/boards/mach-migor/setup.c | 12 -
arch/sh/boards/mach-rsk/setup.c | 43 +---
arch/sh/boards/mach-se/7722/setup.c | 3 -
arch/sh/boards/mach-se/7724/setup.c | 30 ---
arch/sh/include/asm/device.h | 10 -
arch/sh/include/asm/hwblk.h | 70 ------
arch/sh/include/cpu-sh4/cpu/sh7722.h | 13 +-
arch/sh/include/cpu-sh4/cpu/sh7723.h | 3 +-
arch/sh/include/cpu-sh4/cpu/sh7724.h | 4 +-
arch/sh/kernel/cpu/Makefile | 2 +-
arch/sh/kernel/cpu/hwblk.c | 159 -------------
arch/sh/kernel/cpu/sh4/sq.c | 8 +-
arch/sh/kernel/cpu/sh4a/Makefile | 6 +-
arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 77 ++++---
arch/sh/kernel/cpu/sh4a/clock-sh7723.c | 209 +++++++----------
arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 201 +++++++++--------
arch/sh/kernel/cpu/sh4a/clock-sh7757.c | 2 +-
arch/sh/kernel/cpu/sh4a/hwblk-sh7722.c | 106 ---------
arch/sh/kernel/cpu/sh4a/hwblk-sh7723.c | 117 ----------
arch/sh/kernel/cpu/sh4a/hwblk-sh7724.c | 121 ----------
arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 38 +---
arch/sh/kernel/cpu/sh4a/setup-sh7723.c | 39 ---
arch/sh/kernel/cpu/sh4a/setup-sh7724.c | 64 +-----
arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 7 +-
arch/sh/kernel/cpu/sh4a/setup-sh7780.c | 2 +
arch/sh/kernel/cpu/sh4a/setup-sh7785.c | 2 +
arch/sh/kernel/cpu/sh4a/setup-sh7786.c | 2 +-
arch/sh/kernel/cpu/shmobile/Makefile | 1 -
arch/sh/kernel/cpu/shmobile/cpuidle.c | 3 +-
arch/sh/kernel/cpu/shmobile/pm_runtime.c | 319 --------------------------
arch/sh/kernel/entry-common.S | 1 +
arch/sh/kernel/signal_32.c | 4 -
arch/sh/kernel/signal_64.c | 4 -
arch/sh/kernel/time.c | 2 -
arch/sh/mm/cache-sh2a.c | 123 +++++++---
drivers/sh/Makefile | 9 +-
drivers/sh/clk/core.c | 9 +-
drivers/sh/clk/cpg.c | 79 +++++--
drivers/sh/pfc.c | 137 +++++++++--
drivers/tty/serial/sh-sci.c | 183 +++++++++++++--
include/linux/serial_sci.h | 22 ++
include/linux/sh_clk.h | 10 +-
include/linux/sh_pfc.h | 11 +
51 files changed, 897 insertions(+), 1651 deletions(-)
delete mode 100644 arch/sh/include/asm/hwblk.h
delete mode 100644 arch/sh/kernel/cpu/hwblk.c
delete mode 100644 arch/sh/kernel/cpu/sh4a/hwblk-sh7722.c
delete mode 100644 arch/sh/kernel/cpu/sh4a/hwblk-sh7723.c
delete mode 100644 arch/sh/kernel/cpu/sh4a/hwblk-sh7724.c
delete mode 100644 arch/sh/kernel/cpu/shmobile/pm_runtime.c
^ permalink raw reply
* [GIT PULL] rmobile updates for 3.3-rc1
From: Paul Mundt @ 2012-01-12 6:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-sh, linux-kernel
The diffstat here is a bit misleading since it also includes some changes
that were pulled in from one of the sh topic branches which will have
already made their way upstream via the sh merge. This mostly applies to
clock framework and pfc changes that were needed in both trees. Thus,
most of the arch/sh and drivers/sh stuff can just be factored out when
looking at the net impact.
I could have simply made the pull request based on top of the last change
from the sh topic branch in question, but that seemed to be misleading
too, so I've just done it this way instead.
The following changes since commit a0e86bd4252519321b0d102dc4ed90557aa7bee9:
audit: always follow va_copy() with va_end() (2012-01-08 14:15:21 -0800)
are available in the git repository at:
git://github.com/pmundt/linux-sh rmobile-for-linus
for you to fetch changes up to e64e1b11b14d363ac70fd13ab809969a6d7e42a8:
Merge branch 'rmobile/smp' into rmobile-latest (2012-01-12 12:20:18 +0900)
----------------------------------------------------------------
SH/R-Mobile updates for 3.3 merge window.
----------------------------------------------------------------
Kuninori Morimoto (16):
ARM: mach-shmobile: R-Mobile A1 support.
ARM: mach-shmobile: r8a7740: add PFC support.
ARM: mach-shmobile: r8a7740: add i2c support
ARM: mach-shmobile: r8a7740: add INTC support
ARM: mach-shmobile: add bonito board support.
ARM: mach-shmobile: bonito: Add dip-switch selector
ARM: mach-shmobile: bonito: add PMIC settings
ARM: mach-shmobile: bonito: Add LCDC0 support
ARM: mach-shmobile: bonito: add FPGA irq demux
ARM: mach-shmobile: bonito: add SMSC9221 support
sh: clkfwk: setup clock parent from current register value
sh: clock-sh7723: add CLKDEV_ICK_ID for cleanup
sh: clkfwk: clock-sh7724: all div6_clks use SH_CLK_DIV6_EXT()
sh: clkfwk: clock-sh73a0: all div6_clks use SH_CLK_DIV6_EXT()
ARM: mach-shmobile: clock-r8a7779: add DIV4 clock support
ARM: mach-shmobile: clock-r8a7779: clkz/clkzs support
Magnus Damm (20):
sh: extend clock struct with mapped_reg member
sh: use ioread32/iowrite32 and mapped_reg for mstp32
sh: use ioread32/iowrite32 and mapped_reg for div4
sh: use ioread32/iowrite32 and mapped_reg for div6
sh: pfc: ioremap() support
sh: pfc: Add gpio_read_bit() for data register access
sh: pfc: Convert index to field and value pair
sh: pfc: Add config_reg_helper() function
sh: pfc: Variable bitfield width config register support
sh: pfc: Unlock register support
ARM: mach-shmobile: r8a7779 and Marzen base support V2
ARM: mach-shmobile: r8a7779 PFC GPIO-only support V2
ARM: mach-shmobile: Marzen SCIF2/SCIF4 support
ARM: mach-shmobile: Marzen LAN89218 support
ARM: mach-shmobile: Fix headsmp.S code to use CPUINIT
ARM: mach-shmobile: Allow SoC specific CPU kill code
ARM: mach-shmobile: Flush caches in platform_cpu_die()
ARM: mach-shmobile: r8a7779 PFC function support
ARM: mach-shmobile: r8a7779 power domain support V2
ARM: mach-shmobile: r8a7779 SMP support V3
Paul Mundt (12):
ARM: mach-shmobile: Unset initramfs source in bonito defconfig.
Merge branch 'rmobile/a1' into rmobile-latest
Merge branch 'rmobile-fixes-for-linus' into rmobile-latest
Merge branch 'master' of git://git.kernel.org/.../torvalds/linux into rmobile-latest
Merge branches 'common/pfc' and 'common/clkfwk' into rmobile/marzen
Merge branch 'rmobile/core' into rmobile/marzen
ARM: mach-shmobile: Fix up marzen build for recent GIC changes.
Merge branch 'rmobile/bonito' into rmobile-latest
ARM: mach-shmobile: Add marzen defconfig.
ARM: mach-shmobile: Add kota2 defconfig.
Merge branches 'rmobile/kota2' and 'rmobile/marzen' into rmobile-latest
Merge branch 'rmobile/smp' into rmobile-latest
Shimoda, Yoshihiro (1):
arm: mach-shmobile: add a resource name for shdma
arch/arm/configs/bonito_defconfig | 72 +
arch/arm/configs/kota2_defconfig | 122 ++
arch/arm/configs/marzen_defconfig | 87 +
arch/arm/mach-shmobile/Kconfig | 27 +-
arch/arm/mach-shmobile/Makefile | 9 +
arch/arm/mach-shmobile/board-bonito.c | 522 +++++
arch/arm/mach-shmobile/board-marzen.c | 157 ++
arch/arm/mach-shmobile/clock-r8a7740.c | 382 ++++
arch/arm/mach-shmobile/clock-r8a7779.c | 176 ++
arch/arm/mach-shmobile/clock-sh7372.c | 6 +-
arch/arm/mach-shmobile/clock-sh73a0.c | 140 ++-
arch/arm/mach-shmobile/headsmp.S | 2 +-
arch/arm/mach-shmobile/hotplug.c | 32 +-
arch/arm/mach-shmobile/include/mach/common.h | 22 +
arch/arm/mach-shmobile/include/mach/r8a7740.h | 584 ++++++
arch/arm/mach-shmobile/include/mach/r8a7779.h | 363 ++++
arch/arm/mach-shmobile/intc-r8a7740.c | 631 ++++++
arch/arm/mach-shmobile/intc-r8a7779.c | 58 +
arch/arm/mach-shmobile/pfc-r8a7740.c | 2562 ++++++++++++++++++++++++
arch/arm/mach-shmobile/pfc-r8a7779.c | 2645 +++++++++++++++++++++++++
arch/arm/mach-shmobile/platsmp.c | 21 +
arch/arm/mach-shmobile/pm-r8a7779.c | 249 +++
arch/arm/mach-shmobile/setup-r8a7740.c | 352 ++++
arch/arm/mach-shmobile/setup-r8a7779.c | 239 +++
arch/arm/mach-shmobile/setup-sh7372.c | 6 +-
arch/arm/mach-shmobile/setup-sh73a0.c | 2 +-
arch/arm/mach-shmobile/smp-r8a7779.c | 153 ++
arch/sh/include/cpu-sh4/cpu/sh7724.h | 1 +
arch/sh/kernel/cpu/sh4a/clock-sh7723.c | 76 +-
arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 44 +-
drivers/sh/clk/core.c | 9 +-
drivers/sh/clk/cpg.c | 77 +-
drivers/sh/pfc.c | 273 ++-
drivers/tty/serial/sh-sci.h | 4 +-
include/linux/sh_clk.h | 10 +-
include/linux/sh_pfc.h | 22 +-
36 files changed, 9910 insertions(+), 227 deletions(-)
create mode 100644 arch/arm/configs/bonito_defconfig
create mode 100644 arch/arm/configs/kota2_defconfig
create mode 100644 arch/arm/configs/marzen_defconfig
create mode 100644 arch/arm/mach-shmobile/board-bonito.c
create mode 100644 arch/arm/mach-shmobile/board-marzen.c
create mode 100644 arch/arm/mach-shmobile/clock-r8a7740.c
create mode 100644 arch/arm/mach-shmobile/clock-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7740.h
create mode 100644 arch/arm/mach-shmobile/include/mach/r8a7779.h
create mode 100644 arch/arm/mach-shmobile/intc-r8a7740.c
create mode 100644 arch/arm/mach-shmobile/intc-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/pfc-r8a7740.c
create mode 100644 arch/arm/mach-shmobile/pfc-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/pm-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/setup-r8a7740.c
create mode 100644 arch/arm/mach-shmobile/setup-r8a7779.c
create mode 100644 arch/arm/mach-shmobile/smp-r8a7779.c
^ permalink raw reply
* Re: [GIT PULL] sh updates for 3.3-rc1
From: Linus Torvalds @ 2012-01-12 7:29 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-sh, linux-kernel
In-Reply-To: <20120112065144.GA24051@linux-sh.org>
On Wed, Jan 11, 2012 at 10:51 PM, Paul Mundt <lethal@linux-sh.org> wrote:
> Here goes my attempt at a merge request by way of signed tag, hopefully
> I've not botched anything too terribly.
Looks fine. Except your key isn't actually signed by anybody I
recognize, so it's kind of worthless that way.
(And it seems to be just a 1024 bit key, which could be improved too)
But the signing part looks technically fine.
> I noticed some people using 3.3 in their signed tags and others with a
> single for-linus one that seems like it will be overwritten on each
> subsequent merge. I've opted for the latter as presumably verification is
> only of interest at the time of merging, but can switch to the former if
> that's the preferred way going forward.
I don't think it matters. Even naming them "3.3" doesn't really make
it any more unique if there are multiple pulls, so I say "whatever
makes sense as a name". If people want to make it clear that it's the
merge pull for the 3.3 release, that's fine. And if they don't, that's
fine too.
You put the "3.3 merge window" in the signed tag itself, and that's
fine too, although that is actually an excellent place to talk about
some high-level details about what that merge brings in. Because the
tag message gets included as part of the merge message (although I can
also edit it), so if you want to talk about the highlights, that's a
great way to do it.
But if there are no real highlights, that's fine too ;)
Linus
^ permalink raw reply
* Re: [GIT PULL] sh updates for 3.3-rc1
From: Linus Torvalds @ 2012-01-12 7:35 UTC (permalink / raw)
To: Paul Mundt; +Cc: linux-sh, linux-kernel
In-Reply-To: <CA+55aFzTJe_VwDxiBKyB3dNCJfm=HXxib4Y4fGihhoBFvXiOTw@mail.gmail.com>
On Wed, Jan 11, 2012 at 11:29 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> Looks fine. Except your key isn't actually signed by anybody I
> recognize, so it's kind of worthless that way.
I take that back. I can follow the chain through Magnus Damm to Greg
KH and Rafael Wysocki, I just had to go through that extra step.
Looking good. Pushed out, and if you have current git and want to see
what it all looks like when I pull your signed tag, you can use "git
log --show-signature" to see it revalidate your signature ;)
Linus
^ permalink raw reply
* Re: [PATCH v4 6/6] dmaengine: shdma: add support for SUDMAC
From: Guennadi Liakhovetski @ 2012-01-12 16:29 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D3A10.7000708@renesas.com>
Hello Shimoda-san
On Wed, 11 Jan 2012, Shimoda, Yoshihiro wrote:
> The SH7757's USB module has SUDMAC. The SUDMAC's registers are imcompatible
> with SH DMAC. However, since the SUDMAC is a very simple module, we can
> reuse the shdma driver for SUDMAC by a few modification.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
I'm quite happy with patches 1-5 of this series! So, if you wanted, you
could add my ack for them, but Paul prefers v3. Well, I agree, that having
strings in the header is not crucial. As long as we make sure to update
platforms before the driver - nothing will break. That said, I would find
it nicer to see those patches in this series - just for completeness.
As for either converting both error and channel IRQs to named resources in
one or separate patches - I don't have a strong preference there either,
so, I can live with v3 too:-) Actually, there's a slight problem with
using named IRQs for channels: since we can have several resources with
channel IRQ ranges or with single IRQs per device, we cannot use
platform_get_resource_byname() for all of them - only for the first one,
which kind of makes this effort of converting all channel IRQ resources to
named ones - pointless...
Now, what concerns this patch. It is hard for me to judge, since I don't
have an sh7757 datasheet, but from the patch and from your comment "The
SUDMAC's registers are imcompatible with SH DMAC" I really begin to doubt,
whether it makes sense to combine them in one driver. AFAICS, the hardware
handling is indeed completely different. The only things, that you reuse
in the driver, are the dmaengine API implementation, which is pretty
standard, and the transfer descriptor list management, which is indeed a
bit tricky. My suggestion would be to split the current shdma.c driver
into two parts - hardware specific and the logic, and reuse the latter for
your new sudmac driver, which would then become a separate file. I'd have
to think a bit, what's the best way to do this: either
1. keep the main part of the driver with the logic as now, extracting
hardware-specific parts in a separate file and linking respective
functions to the main module via function pointers in an operations
struct, or
2. extract only the most essential and complicated logic functions into a
helper library and use it for both shdma and sudmac drivers.
What do you think? I'd need some time to think about this and come up with
a patch.
Thanks
Guennadi
> ---
> about v4:
> - No change
>
> drivers/dma/shdma.c | 102 +++++++++++++++++++++++++++++++++++++++++++-----
> include/linux/sh_dma.h | 46 +++++++++++++++++++++
> 2 files changed, 138 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma/shdma.c b/drivers/dma/shdma.c
> index 0f9d5f2..eb5ca48 100644
> --- a/drivers/dma/shdma.c
> +++ b/drivers/dma/shdma.c
> @@ -58,6 +58,11 @@ static unsigned long sh_dmae_slave_used[BITS_TO_LONGS(SH_DMA_SLAVE_NUMBER)];
>
> static void sh_dmae_chan_ld_cleanup(struct sh_dmae_chan *sh_chan, bool all);
>
> +static int sh_dmae_is_sudmac(struct sh_dmae_device *shdev)
> +{
> + return shdev->pdata->sudmac;
> +}
> +
> static void sh_dmae_writel(struct sh_dmae_chan *sh_dc, u32 data, u32 reg)
> {
> __raw_writel(data, sh_dc->base + reg / sizeof(u32));
> @@ -68,6 +73,39 @@ static u32 sh_dmae_readl(struct sh_dmae_chan *sh_dc, u32 reg)
> return __raw_readl(sh_dc->base + reg / sizeof(u32));
> }
>
> +static void sh_dmae_sudmac_chcr_write(struct sh_dmae_chan *sh_dc, u32 data)
> +{
> + struct sh_dmae_device *shdev = to_sh_dev(sh_dc);
> +
> + if (!(data & CHCR_TE)) /* clear interrupt status only */
> + sh_dmae_writel(sh_dc, CH0ENDC, DINTSTSCLR);
> +
> + if (data & shdev->chcr_ie_bit)
> + sh_dmae_writel(sh_dc, CH0ENDE, DINTCTRL);
> + else
> + sh_dmae_writel(sh_dc, 0, DINTCTRL);
> +
> + if (data & CHCR_DE)
> + sh_dmae_writel(sh_dc, DEN, CH0DEN);
> + else
> + sh_dmae_writel(sh_dc, 0, CH0DEN);
> +}
> +
> +static u32 sh_dmae_sudmac_chcr_read(struct sh_dmae_chan *sh_dc)
> +{
> + struct sh_dmae_device *shdev = to_sh_dev(sh_dc);
> + u32 chcr = 0;
> +
> + if (sh_dmae_readl(sh_dc, DINTSTS) & CH0ENDS)
> + chcr |= CHCR_TE;
> + if (sh_dmae_readl(sh_dc, DINTCTRL) & CH0ENDE)
> + chcr |= shdev->chcr_ie_bit;
> + if (sh_dmae_readl(sh_dc, CH0DEN) & DEN)
> + chcr |= CHCR_DE;
> +
> + return chcr;
> +}
> +
> static u16 dmaor_read(struct sh_dmae_device *shdev)
> {
> u32 __iomem *addr = shdev->chan_reg + DMAOR / sizeof(u32);
> @@ -92,14 +130,20 @@ static void chcr_write(struct sh_dmae_chan *sh_dc, u32 data)
> {
> struct sh_dmae_device *shdev = to_sh_dev(sh_dc);
>
> - sh_dmae_writel(sh_dc, data, shdev->chcr_offset);
> + if (sh_dmae_is_sudmac(shdev))
> + sh_dmae_sudmac_chcr_write(sh_dc, data);
> + else
> + sh_dmae_writel(sh_dc, data, shdev->chcr_offset);
> }
>
> static u32 chcr_read(struct sh_dmae_chan *sh_dc)
> {
> struct sh_dmae_device *shdev = to_sh_dev(sh_dc);
>
> - return sh_dmae_readl(sh_dc, shdev->chcr_offset);
> + if (sh_dmae_is_sudmac(shdev))
> + return sh_dmae_sudmac_chcr_read(sh_dc);
> + else
> + return sh_dmae_readl(sh_dc, shdev->chcr_offset);
> }
>
> /*
> @@ -112,6 +156,9 @@ static void sh_dmae_ctl_stop(struct sh_dmae_device *shdev)
> unsigned short dmaor;
> unsigned long flags;
>
> + if (sh_dmae_is_sudmac(shdev))
> + return;
> +
> spin_lock_irqsave(&sh_dmae_lock, flags);
>
> dmaor = dmaor_read(shdev);
> @@ -125,6 +172,9 @@ static int sh_dmae_rst(struct sh_dmae_device *shdev)
> unsigned short dmaor;
> unsigned long flags;
>
> + if (sh_dmae_is_sudmac(shdev))
> + return 0;
> +
> spin_lock_irqsave(&sh_dmae_lock, flags);
>
> dmaor = dmaor_read(shdev) & ~(DMAOR_NMIF | DMAOR_AE | DMAOR_DME);
> @@ -159,6 +209,9 @@ static unsigned int calc_xmit_shift(struct sh_dmae_chan *sh_chan, u32 chcr)
> int cnt = ((chcr & pdata->ts_low_mask) >> pdata->ts_low_shift) |
> ((chcr & pdata->ts_high_mask) >> pdata->ts_high_shift);
>
> + if (sh_dmae_is_sudmac(shdev))
> + return 0;
> +
> if (cnt >= pdata->ts_shift_num)
> cnt = 0;
>
> @@ -171,6 +224,9 @@ static u32 log2size_to_chcr(struct sh_dmae_chan *sh_chan, int l2size)
> struct sh_dmae_pdata *pdata = shdev->pdata;
> int i;
>
> + if (sh_dmae_is_sudmac(shdev))
> + return 0;
> +
> for (i = 0; i < pdata->ts_shift_num; i++)
> if (pdata->ts_shift[i] = l2size)
> break;
> @@ -184,9 +240,17 @@ static u32 log2size_to_chcr(struct sh_dmae_chan *sh_chan, int l2size)
>
> static void dmae_set_reg(struct sh_dmae_chan *sh_chan, struct sh_dmae_regs *hw)
> {
> - sh_dmae_writel(sh_chan, hw->sar, SAR);
> - sh_dmae_writel(sh_chan, hw->dar, DAR);
> - sh_dmae_writel(sh_chan, hw->tcr >> sh_chan->xmit_shift, TCR);
> + struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> +
> + if (sh_dmae_is_sudmac(shdev)) {
> + sh_dmae_writel(sh_chan, LBA_WAIT | RCVENDM, CH0CFG);
> + sh_dmae_writel(sh_chan, hw->sar, CH0BA);
> + sh_dmae_writel(sh_chan, hw->tcr, CH0BBC);
> + } else {
> + sh_dmae_writel(sh_chan, hw->sar, SAR);
> + sh_dmae_writel(sh_chan, hw->dar, DAR);
> + sh_dmae_writel(sh_chan, hw->tcr >> sh_chan->xmit_shift, TCR);
> + }
> }
>
> static void dmae_start(struct sh_dmae_chan *sh_chan)
> @@ -493,6 +557,7 @@ static struct sh_desc *sh_dmae_add_desc(struct sh_dmae_chan *sh_chan,
> unsigned long flags, dma_addr_t *dest, dma_addr_t *src, size_t *len,
> struct sh_desc **first, enum dma_data_direction direction)
> {
> + struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> struct sh_desc *new;
> size_t copy_size;
>
> @@ -508,7 +573,14 @@ static struct sh_desc *sh_dmae_add_desc(struct sh_dmae_chan *sh_chan,
>
> copy_size = min(*len, (size_t)SH_DMA_TCR_MAX + 1);
>
> - new->hw.sar = *src;
> + /*
> + * SUDMAC has a CHnBA register only. So, the driver uses "hw.sar"
> + * even if transfer direction is DMA_FROM_DEVICE.
> + */
> + if (sh_dmae_is_sudmac(shdev) && direction = DMA_FROM_DEVICE)
> + new->hw.sar = *dest;
> + else
> + new->hw.sar = *src;
> new->hw.dar = *dest;
> new->hw.tcr = copy_size;
>
> @@ -701,8 +773,10 @@ static int sh_dmae_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
> /* Record partial transfer */
> struct sh_desc *desc = list_entry(sh_chan->ld_queue.next,
> struct sh_desc, node);
> - desc->partial = (desc->hw.tcr - sh_dmae_readl(sh_chan, TCR)) <<
> - sh_chan->xmit_shift;
> + struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> + if (!sh_dmae_is_sudmac(shdev))
> + desc->partial = (desc->hw.tcr - sh_dmae_readl(sh_chan,
> + TCR)) << sh_chan->xmit_shift;
> }
> spin_unlock_irqrestore(&sh_chan->desc_lock, flags);
>
> @@ -989,9 +1063,17 @@ static irqreturn_t sh_dmae_err(int irq, void *data)
> static void dmae_do_tasklet(unsigned long data)
> {
> struct sh_dmae_chan *sh_chan = (struct sh_dmae_chan *)data;
> + struct sh_dmae_device *shdev = to_sh_dev(sh_chan);
> struct sh_desc *desc;
> - u32 sar_buf = sh_dmae_readl(sh_chan, SAR);
> - u32 dar_buf = sh_dmae_readl(sh_chan, DAR);
> + u32 sar_buf, dar_buf;
> +
> + if (sh_dmae_is_sudmac(shdev)) {
> + sar_buf = sh_dmae_readl(sh_chan, CH0CA);
> + dar_buf = sh_dmae_readl(sh_chan, CH0CA);
> + } else {
> + sar_buf = sh_dmae_readl(sh_chan, SAR);
> + dar_buf = sh_dmae_readl(sh_chan, DAR);
> + }
>
> spin_lock_irq(&sh_chan->desc_lock);
> list_for_each_entry(desc, &sh_chan->ld_queue, node) {
> diff --git a/include/linux/sh_dma.h b/include/linux/sh_dma.h
> index a6c82cc..46be54f 100644
> --- a/include/linux/sh_dma.h
> +++ b/include/linux/sh_dma.h
> @@ -72,6 +72,7 @@ struct sh_dmae_pdata {
> unsigned int dmaor_is_32bit:1;
> unsigned int needs_tend_set:1;
> unsigned int no_dmars:1;
> + unsigned int sudmac:1;
> };
>
> /* DMA register */
> @@ -111,4 +112,49 @@ struct sh_dmae_pdata {
> #define CHCR_TE 0x00000002
> #define CHCR_IE 0x00000004
>
> +/* SUDMAC register */
> +#define CH0CFG 0x00
> +#define CH1CFG 0x04
> +#define CH0BA 0x10
> +#define CH1BA 0x14
> +#define CH0BBC 0x18
> +#define CH1BBC 0x1C
> +#define CH0CA 0x20
> +#define CH1CA 0x24
> +#define CH0CBC 0x28
> +#define CH1CBC 0x2C
> +#define CH0DEN 0x30
> +#define CH1DEN 0x34
> +#define DSTSCLR 0x38
> +#define DBUFCTRL 0x3C
> +#define DINTCTRL 0x40
> +#define DINTSTS 0x44
> +#define DINTSTSCLR 0x48
> +#define CH0SHCTRL 0x50
> +#define CH1SHCTRL 0x54
> +
> +/* Definitions for the SUDMAC */
> +#define SENDBUFM 0x1000 /* b12: Transmit Buffer Mode */
> +#define RCVENDM 0x0100 /* b8: Receive Data Transfer End Mode */
> +#define LBA_WAIT 0x0030 /* b5-4: Local Bus Access Wait */
> +#define DEN 0x0001 /* b0: DMA Transfer Enable */
> +#define CH1STCLR 0x0002 /* b1: Ch1 DMA Status Clear */
> +#define CH0STCLR 0x0001 /* b0: Ch0 DMA Status Clear */
> +#define CH1BUFW 0x0200 /* b9: Ch1 DMA Buffer Data Transfer Enable */
> +#define CH0BUFW 0x0100 /* b8: Ch0 DMA Buffer Data Transfer Enable */
> +#define CH1BUFS 0x0002 /* b1: Ch1 DMA Buffer Data Status */
> +#define CH0BUFS 0x0001 /* b0: Ch0 DMA Buffer Data Status */
> +#define CH1ERRE 0x0200 /* b9: Ch1 SHwy Res Err Detect Int Enable */
> +#define CH0ERRE 0x0100 /* b8: Ch0 SHwy Res Err Detect Int Enable */
> +#define CH1ENDE 0x0002 /* b1: Ch1 DMA Transfer End Int Enable */
> +#define CH0ENDE 0x0001 /* b0: Ch0 DMA Transfer End Int Enable */
> +#define CH1ERRS 0x0200 /* b9: Ch1 SHwy Res Err Detect Int Status */
> +#define CH0ERRS 0x0100 /* b8: Ch0 SHwy Res Err Detect Int Status */
> +#define CH1ENDS 0x0002 /* b1: Ch1 DMA Transfer End Int Status */
> +#define CH0ENDS 0x0001 /* b0: Ch0 DMA Transfer End Int Status */
> +#define CH1ERRC 0x0200 /* b9: Ch1 SHwy Res Err Detect Int Stat Clear */
> +#define CH0ERRC 0x0100 /* b8: Ch0 SHwy Res Err Detect Int Stat Clear */
> +#define CH1ENDC 0x0002 /* b1: Ch1 DMA Transfer End Int Stat Clear */
> +#define CH0ENDC 0x0001 /* b0: Ch0 DMA Transfer End Int Stat Clear */
> +
> #endif
> --
> 1.7.1
>
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [GIT PULL] sh updates for 3.3-rc1
From: Ted Ts'o @ 2012-01-12 16:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mundt, linux-sh, linux-kernel
In-Reply-To: <CA+55aFxjHamzRteKAXLGuBt4LH-ZkJ+PJxZS5kWST-umhK8Zow@mail.gmail.com>
On Wed, Jan 11, 2012 at 11:35:32PM -0800, Linus Torvalds wrote:
>
> Looking good. Pushed out, and if you have current git and want to see
> what it all looks like when I pull your signed tag, you can use "git
> log --show-signature" to see it revalidate your signature ;)
Public service announcement --- note that you need to update to git
1.7.9-rc0 or lateer for git log --show-signature to work.
- Ted
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: fix A3SP suspend method
From: Rafael J. Wysocki @ 2012-01-12 23:48 UTC (permalink / raw)
To: linux-sh
On Thursday, January 12, 2012, Guennadi Liakhovetski wrote:
> Fix the reverted condition in sh7372_a3sp_suspend().
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
> index 77b8fc1..43baa97 100644
> --- a/arch/arm/mach-shmobile/pm-sh7372.c
> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
> @@ -276,7 +276,7 @@ static int sh7372_a3sp_suspend(void)
> * Serial consoles make use of SCIF hardware located in A3SP,
> * keep such power domain on if "no_console_suspend" is set.
> */
> - return console_suspend_enabled ? -EBUSY : 0;
> + return console_suspend_enabled ? 0 : -EBUSY;
> }
>
> struct sh7372_pm_domain sh7372_a3sp = {
Magnus, the patch is correct, but I need your ACK here.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH v4 6/6] dmaengine: shdma: add support for SUDMAC
From: Shimoda, Yoshihiro @ 2012-01-13 8:03 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D3A10.7000708@renesas.com>
Hello Guennadi-san,
Thank you very much for your comment!
2012/01/13 1:29, Guennadi Liakhovetski wrote:
> Hello Shimoda-san
>
> On Wed, 11 Jan 2012, Shimoda, Yoshihiro wrote:
>
>> The SH7757's USB module has SUDMAC. The SUDMAC's registers are imcompatible
>> with SH DMAC. However, since the SUDMAC is a very simple module, we can
>> reuse the shdma driver for SUDMAC by a few modification.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>
> I'm quite happy with patches 1-5 of this series! So, if you wanted, you
> could add my ack for them, but Paul prefers v3. Well, I agree, that having
> strings in the header is not crucial. As long as we make sure to update
> platforms before the driver - nothing will break. That said, I would find
> it nicer to see those patches in this series - just for completeness.
>
> As for either converting both error and channel IRQs to named resources in
> one or separate patches - I don't have a strong preference there either,
> so, I can live with v3 too:-) Actually, there's a slight problem with
> using named IRQs for channels: since we can have several resources with
> channel IRQ ranges or with single IRQs per device, we cannot use
> platform_get_resource_byname() for all of them - only for the first one,
> which kind of makes this effort of converting all channel IRQ resources to
> named ones - pointless...
I think so. The v4 patches use platform_get_resource_byname() for the channels,
but it also use platform_get_resource() later...
> Now, what concerns this patch. It is hard for me to judge, since I don't
> have an sh7757 datasheet, but from the patch and from your comment "The
> SUDMAC's registers are imcompatible with SH DMAC" I really begin to doubt,
> whether it makes sense to combine them in one driver. AFAICS, the hardware
> handling is indeed completely different. The only things, that you reuse
> in the driver, are the dmaengine API implementation, which is pretty
> standard, and the transfer descriptor list management, which is indeed a
> bit tricky. My suggestion would be to split the current shdma.c driver
> into two parts - hardware specific and the logic, and reuse the latter for
> your new sudmac driver, which would then become a separate file. I'd have
> to think a bit, what's the best way to do this: either
>
> 1. keep the main part of the driver with the logic as now, extracting
> hardware-specific parts in a separate file and linking respective
> functions to the main module via function pointers in an operations
> struct, or
>
> 2. extract only the most essential and complicated logic functions into a
> helper library and use it for both shdma and sudmac drivers.
>
> What do you think? I'd need some time to think about this and come up with
> a patch.
Umm, at the moment, I cannot judge which is good. I also need more time...
Best regards,
Yoshihiro Shimoda
> Thanks
> Guennadi
^ permalink raw reply
* Re: [PATCH v4 6/6] dmaengine: shdma: add support for SUDMAC
From: Paul Mundt @ 2012-01-13 8:14 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D3A10.7000708@renesas.com>
On Thu, Jan 12, 2012 at 05:29:06PM +0100, Guennadi Liakhovetski wrote:
> As for either converting both error and channel IRQs to named resources in
> one or separate patches - I don't have a strong preference there either,
> so, I can live with v3 too:-) Actually, there's a slight problem with
> using named IRQs for channels: since we can have several resources with
> channel IRQ ranges or with single IRQs per device, we cannot use
> platform_get_resource_byname() for all of them - only for the first one,
> which kind of makes this effort of converting all channel IRQ resources to
> named ones - pointless...
>
Can you point to an example on the platform data side that you're
thinking about? The IRQ range thing doesn't strike me as being inherently
unsupportable by way of _byname(), but you are correct that _byname()
assumes one matching resource and doesn't support iterating (although we
could presumably extend the API for this if necessary).
> Now, what concerns this patch. It is hard for me to judge, since I don't
> have an sh7757 datasheet, but from the patch and from your comment "The
> SUDMAC's registers are imcompatible with SH DMAC" I really begin to doubt,
> whether it makes sense to combine them in one driver. AFAICS, the hardware
> handling is indeed completely different. The only things, that you reuse
> in the driver, are the dmaengine API implementation, which is pretty
> standard, and the transfer descriptor list management, which is indeed a
> bit tricky. My suggestion would be to split the current shdma.c driver
> into two parts - hardware specific and the logic, and reuse the latter for
> your new sudmac driver, which would then become a separate file. I'd have
> to think a bit, what's the best way to do this: either
>
> 1. keep the main part of the driver with the logic as now, extracting
> hardware-specific parts in a separate file and linking respective
> functions to the main module via function pointers in an operations
> struct, or
>
> 2. extract only the most essential and complicated logic functions into a
> helper library and use it for both shdma and sudmac drivers.
>
> What do you think? I'd need some time to think about this and come up with
> a patch.
>
Yes, I agree that this is probably the best way to go. The SUDMAC
layering on top of the shdma driver is pretty nasty, as it's largely
bypassing all of the hardware-specific bits anyways, suggesting that it
is really better off being split out.
My initial concern was whether breaking it out would make sense or not
given that we don't know what other DMACs will end up looking like, but
it looks like the SUDMAC case already does a good enough job of bypassing
all of the SH DMAC hardware bits that we more or less need a full
abstraction for the hardware side already, making the point moot.
Splitting out the logic functions in to a helper library looks to be the
cleanest way forward. The SUDMAC bits aren't going to make it in for 3.3
anyways, so we do have some time/wiggle room to get this done
cleanly/properly for 3.4.
^ permalink raw reply
* Re: [PATCH v4 6/6] dmaengine: shdma: add support for SUDMAC
From: Guennadi Liakhovetski @ 2012-01-13 8:35 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <4F0D3A10.7000708@renesas.com>
On Fri, 13 Jan 2012, Paul Mundt wrote:
> On Thu, Jan 12, 2012 at 05:29:06PM +0100, Guennadi Liakhovetski wrote:
> > As for either converting both error and channel IRQs to named resources in
> > one or separate patches - I don't have a strong preference there either,
> > so, I can live with v3 too:-) Actually, there's a slight problem with
> > using named IRQs for channels: since we can have several resources with
> > channel IRQ ranges or with single IRQs per device, we cannot use
> > platform_get_resource_byname() for all of them - only for the first one,
> > which kind of makes this effort of converting all channel IRQ resources to
> > named ones - pointless...
> >
> Can you point to an example on the platform data side that you're
> thinking about?
E.g. arch/sh/kernel/cpu/sh4a/setup-sh7724.c::sh7724_dmae0_resources, dmae1
is similar, same for sh7722.
> The IRQ range thing doesn't strike me as being inherently
> unsupportable by way of _byname(),
Hm, you don't mean adding extra names for each such case?...
> but you are correct that _byname()
> assumes one matching resource and doesn't support iterating (although we
> could presumably extend the API for this if necessary).
That would be a good option, yes. But whether it's worth it for this one
case...
> > Now, what concerns this patch. It is hard for me to judge, since I don't
> > have an sh7757 datasheet, but from the patch and from your comment "The
> > SUDMAC's registers are imcompatible with SH DMAC" I really begin to doubt,
> > whether it makes sense to combine them in one driver. AFAICS, the hardware
> > handling is indeed completely different. The only things, that you reuse
> > in the driver, are the dmaengine API implementation, which is pretty
> > standard, and the transfer descriptor list management, which is indeed a
> > bit tricky. My suggestion would be to split the current shdma.c driver
> > into two parts - hardware specific and the logic, and reuse the latter for
> > your new sudmac driver, which would then become a separate file. I'd have
> > to think a bit, what's the best way to do this: either
> >
> > 1. keep the main part of the driver with the logic as now, extracting
> > hardware-specific parts in a separate file and linking respective
> > functions to the main module via function pointers in an operations
> > struct, or
> >
> > 2. extract only the most essential and complicated logic functions into a
> > helper library and use it for both shdma and sudmac drivers.
> >
> > What do you think? I'd need some time to think about this and come up with
> > a patch.
> >
> Yes, I agree that this is probably the best way to go. The SUDMAC
> layering on top of the shdma driver is pretty nasty, as it's largely
> bypassing all of the hardware-specific bits anyways, suggesting that it
> is really better off being split out.
>
> My initial concern was whether breaking it out would make sense or not
> given that we don't know what other DMACs will end up looking like, but
> it looks like the SUDMAC case already does a good enough job of bypassing
> all of the SH DMAC hardware bits that we more or less need a full
> abstraction for the hardware side already, making the point moot.
>
> Splitting out the logic functions in to a helper library looks to be the
> cleanest way forward. The SUDMAC bits aren't going to make it in for 3.3
> anyways, so we do have some time/wiggle room to get this done
> cleanly/properly for 3.4.
Yeah... A library would probably be cleaner, but hardware-specific
callbacks, like OHCI and some other drivers do it, is likely easier:-)
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* Re: [PATCH] ARM: mach-shmobile: fix A3SP suspend method
From: Magnus Damm @ 2012-01-13 9:45 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <201201130048.09751.rjw@sisk.pl>
On Fri, Jan 13, 2012 at 8:48 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Thursday, January 12, 2012, Guennadi Liakhovetski wrote:
>> Fix the reverted condition in sh7372_a3sp_suspend().
>>
>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> ---
>> diff --git a/arch/arm/mach-shmobile/pm-sh7372.c b/arch/arm/mach-shmobile/pm-sh7372.c
>> index 77b8fc1..43baa97 100644
>> --- a/arch/arm/mach-shmobile/pm-sh7372.c
>> +++ b/arch/arm/mach-shmobile/pm-sh7372.c
>> @@ -276,7 +276,7 @@ static int sh7372_a3sp_suspend(void)
>> * Serial consoles make use of SCIF hardware located in A3SP,
>> * keep such power domain on if "no_console_suspend" is set.
>> */
>> - return console_suspend_enabled ? -EBUSY : 0;
>> + return console_suspend_enabled ? 0 : -EBUSY;
>> }
>>
>> struct sh7372_pm_domain sh7372_a3sp = {
>
> Magnus, the patch is correct, but I need your ACK here.
Yes, it indeed seems like a correct fix.
Acked-by: Magnus Damm <damm@opensource.se>
Thanks to you and Guennadi for fixing this.
Cheers,
/ magnus
^ permalink raw reply
* [RFC PATCH 00/10] Make mach/irqs.h optional
From: Rob Herring @ 2012-01-13 16:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
This series removes the include of mach/irqs.h from asm/irq.h when
SPARSE_IRQ is selected. Platforms which select SPARSE_IRQ have been
updated.
This breaks platforms where SPARSE_IRQ is user selectable. This is on
purpose so that SPARSE_IRQ gets properly supported. We could push
HAVE_SPARSE_IRQ option down to the platforms that select it if that is
preferred. But as recent experience has shown, perhaps breaking platforms
is the only way to get some platforms updated.
Platforms either need to set nr_irqs in their machine desc or all irqchips
used by a platform need to allocate their irq_descs. There cannot be a
mixture. Once this is done, the platforms can select SPARSE_IRQ. shmobile
does the latter, and mnp and pxa do the former.
I've built all defconfigs, but don't have any of the affected platforms to
boot test. I think shmobile is the main platform that needs testing here.
This series is available here:
git://sources.calxeda.com/kernel/linux.git sparse_irq
Rob
Rob Herring (10):
rtc: sa1100: include mach/irqs.h instead of asm/irq.h
sound: pxa2xx-ac97: include mach/irqs.h directly
ARM: mc146818rtc: remove unnecessary include of mach/irqs.h
ARM: it8152: explicitly include mach/irqs.h
sh: intc: remove dependency on NR_IRQS
ARM: mmp: remove NR_IRQS
ARM: pxa: remove NR_IRQS
ARM: shmobile: remove NR_IRQS
ARM: only include mach/irqs.h for !SPARSE_IRQ
ARM: highbank: select SPARSE_IRQ and remove irqs.h
arch/arm/Kconfig | 1 +
arch/arm/include/asm/hardware/it8152.h | 3 +++
arch/arm/include/asm/irq.h | 8 ++++++--
arch/arm/include/asm/mc146818rtc.h | 1 -
arch/arm/mach-highbank/highbank.c | 1 -
arch/arm/mach-highbank/include/mach/irqs.h | 6 ------
arch/arm/mach-mmp/avengers_lite.c | 1 +
arch/arm/mach-mmp/include/mach/irqs.h | 2 --
arch/arm/mach-mmp/irq-mmp2.c | 1 +
arch/arm/mach-mmp/jasper.c | 1 +
arch/arm/mach-mmp/tavorevb.c | 1 +
arch/arm/mach-pxa/capc7117.c | 1 +
arch/arm/mach-pxa/cm-x300.c | 1 +
arch/arm/mach-pxa/colibri-pxa270.c | 2 ++
arch/arm/mach-pxa/colibri-pxa300.c | 1 +
arch/arm/mach-pxa/colibri-pxa320.c | 1 +
arch/arm/mach-pxa/corgi.c | 3 +++
arch/arm/mach-pxa/csb726.c | 1 +
arch/arm/mach-pxa/devices.c | 1 +
arch/arm/mach-pxa/em-x270.c | 2 ++
arch/arm/mach-pxa/gumstix.c | 1 +
arch/arm/mach-pxa/h5000.c | 1 +
arch/arm/mach-pxa/himalaya.c | 1 +
arch/arm/mach-pxa/icontrol.c | 1 +
arch/arm/mach-pxa/idp.c | 1 +
arch/arm/mach-pxa/include/mach/irqs.h | 2 +-
arch/arm/mach-pxa/mioa701.c | 1 +
arch/arm/mach-pxa/mp900.c | 1 +
arch/arm/mach-pxa/palmld.c | 1 +
arch/arm/mach-pxa/palmt5.c | 1 +
arch/arm/mach-pxa/palmtc.c | 1 +
arch/arm/mach-pxa/palmte2.c | 1 +
arch/arm/mach-pxa/palmtreo.c | 2 ++
arch/arm/mach-pxa/palmtx.c | 1 +
arch/arm/mach-pxa/palmz72.c | 1 +
arch/arm/mach-pxa/raumfeld.c | 3 +++
arch/arm/mach-pxa/saar.c | 1 +
arch/arm/mach-pxa/spitz.c | 3 +++
arch/arm/mach-pxa/stargate2.c | 1 +
arch/arm/mach-pxa/tavorevb.c | 1 +
arch/arm/mach-pxa/time.c | 1 +
arch/arm/mach-pxa/trizeps4.c | 2 ++
arch/arm/mach-pxa/viper.c | 1 +
arch/arm/mach-pxa/vpac270.c | 1 +
arch/arm/mach-pxa/xcep.c | 1 +
arch/arm/mach-pxa/z2.c | 1 +
arch/arm/mach-shmobile/board-g3evm.c | 1 +
arch/arm/mach-shmobile/board-g4evm.c | 1 +
arch/arm/mach-shmobile/board-kota2.c | 1 +
arch/arm/mach-shmobile/board-mackerel.c | 1 +
arch/arm/mach-shmobile/include/mach/irqs.h | 2 --
arch/arm/mach-shmobile/intc-sh7367.c | 1 +
arch/arm/mach-shmobile/intc-sh7372.c | 1 +
arch/arm/mach-shmobile/intc-sh7377.c | 1 +
arch/arm/mach-shmobile/intc-sh73a0.c | 1 +
arch/arm/mach-shmobile/setup-sh7367.c | 1 +
arch/arm/mach-shmobile/setup-sh7372.c | 1 +
arch/arm/mach-shmobile/setup-sh7377.c | 1 +
arch/arm/mach-shmobile/setup-sh73a0.c | 1 +
drivers/rtc/rtc-sa1100.c | 2 +-
drivers/sh/intc/balancing.c | 2 +-
drivers/sh/intc/core.c | 2 +-
drivers/sh/intc/handle.c | 2 +-
drivers/sh/intc/internals.h | 9 +++++++++
drivers/sh/intc/virq.c | 2 +-
sound/arm/pxa2xx-ac97-lib.c | 2 +-
66 files changed, 86 insertions(+), 21 deletions(-)
delete mode 100644 arch/arm/mach-highbank/include/mach/irqs.h
--
1.7.5.4
^ permalink raw reply
* [RFC PATCH 01/10] rtc: sa1100: include mach/irqs.h instead of asm/irq.h
From: Rob Herring @ 2012-01-13 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1326472451-9002-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Since asm/irq.h may not include mach/irqs.h, include mach/irqs.h directly.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
drivers/rtc/rtc-sa1100.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-sa1100.c b/drivers/rtc/rtc-sa1100.c
index 4595d3e..144fa06 100644
--- a/drivers/rtc/rtc-sa1100.c
+++ b/drivers/rtc/rtc-sa1100.c
@@ -33,7 +33,7 @@
#include <linux/io.h>
#include <mach/hardware.h>
-#include <asm/irq.h>
+#include <mach/irqs.h>
#define RTC_DEF_DIVIDER (32768 - 1)
#define RTC_DEF_TRIM 0
--
1.7.5.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox