Re: [RFC PATCH v2 17/25] smp, sh: kill SMP single function call interrupt
On Thu, Sep 12, 2013 at 12:07:21AM +0800, Jiang Liu wrote: > From: Jiang Liu > > Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic > similar to smp_call_function_single()" has unified the way to handle > single and multiple cross-CPU function calls. Now only one interrupt > is needed for architecture specific code to support generic SMP function > call interfaces, so kill the redundant single function call interrupt. > > Signed-off-by: Jiang Liu > Cc: Jiang Liu Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 17/25] smp, sh: kill SMP single function call interrupt
On Thu, Sep 12, 2013 at 12:07:21AM +0800, Jiang Liu wrote: From: Jiang Liu jiang@huawei.com Commit 9a46ad6d6df3b54 smp: make smp_call_function_many() use logic similar to smp_call_function_single() has unified the way to handle single and multiple cross-CPU function calls. Now only one interrupt is needed for architecture specific code to support generic SMP function call interfaces, so kill the redundant single function call interrupt. Signed-off-by: Jiang Liu jiang@huawei.com Cc: Jiang Liu liu...@gmail.com Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/26] sh: Don't use create_proc_read_entry() [RFC]
On Tue, Apr 16, 2013 at 07:28:42AM +0100, Al Viro wrote: > On Tue, Apr 16, 2013 at 03:11:13PM +0900, Simon Horman wrote: > > On Thu, Apr 11, 2013 at 02:30:09PM +0100, David Howells wrote: > > > Don't use create_proc_read_entry() as that is deprecated, but rather use > > > proc_create_data() and seq_file instead. > > > > Paul, do you want me to handle this? > > FWIW, I can pick that stuff via vfs.git - not a problem and I've already got > shitloads of procfs-related patches in that queue... That works for me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/26] sh: Don't use create_proc_read_entry() [RFC]
On Tue, Apr 16, 2013 at 07:28:42AM +0100, Al Viro wrote: On Tue, Apr 16, 2013 at 03:11:13PM +0900, Simon Horman wrote: On Thu, Apr 11, 2013 at 02:30:09PM +0100, David Howells wrote: Don't use create_proc_read_entry() as that is deprecated, but rather use proc_create_data() and seq_file instead. Paul, do you want me to handle this? FWIW, I can pick that stuff via vfs.git - not a problem and I've already got shitloads of procfs-related patches in that queue... That works for me. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] sh: cpufreq: move cpufreq driver to drivers/cpufreq
On Mon, Mar 25, 2013 at 10:24:42PM +0530, Viresh Kumar wrote: > This patch moves cpufreq driver of SUPERH architecture to drivers/cpufreq. > > Cc: Paul Mundt > Cc: linux...@vger.kernel.org > Signed-off-by: Viresh Kumar Looks ok to me. Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] sh: cpufreq: move cpufreq driver to drivers/cpufreq
On Mon, Mar 25, 2013 at 10:24:42PM +0530, Viresh Kumar wrote: This patch moves cpufreq driver of SUPERH architecture to drivers/cpufreq. Cc: Paul Mundt let...@linux-sh.org Cc: linux...@vger.kernel.org Signed-off-by: Viresh Kumar viresh.ku...@linaro.org Looks ok to me. Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memblock: kill "config MAX_ACTIVE_REGIONS"
On Thu, Mar 21, 2013 at 10:27:56AM +0100, Paul Bolle wrote:
> The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit
> 0ee332c1451869963626bf9cac88f165a90990e1 ("memblock: Kill
> early_node_map[]") removed the only place were it was actually used. But
> it did not remove its Kconfig entries (for powerpc and sh).
>
> Remove those two entries (and the entry for metag, that popped up in
> v3.9-rc1).
>
> Signed-off-by: Paul Bolle
> ---
> 0) Eyeball tested again.
>
> 1) It felt silly to split this clean up patch into three patches. But if
> the maintainers involved disagree I'm happy to split and resend it.
>
Given that it's unused now it doesn't really matter how it gets applied,
it looks fine to me.
Acked-by: Paul Mundt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memblock: kill config MAX_ACTIVE_REGIONS
On Thu, Mar 21, 2013 at 10:27:56AM +0100, Paul Bolle wrote: The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit 0ee332c1451869963626bf9cac88f165a90990e1 (memblock: Kill early_node_map[]) removed the only place were it was actually used. But it did not remove its Kconfig entries (for powerpc and sh). Remove those two entries (and the entry for metag, that popped up in v3.9-rc1). Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) Eyeball tested again. 1) It felt silly to split this clean up patch into three patches. But if the maintainers involved disagree I'm happy to split and resend it. Given that it's unused now it doesn't really matter how it gets applied, it looks fine to me. Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] mm/hugetlb: add more arch-defined huge_pte_xxx functions
On Tue, Mar 12, 2013 at 07:48:25PM +0100, Gerald Schaefer wrote: > This patch introduces those huge_pte_xxx functions and their > implementation on all architectures supporting hugetlbfs. This change > will be a no-op for all architectures other than s390. > .. > arch/ia64/include/asm/hugetlb.h| 36 > arch/mips/include/asm/hugetlb.h| 36 > arch/powerpc/include/asm/hugetlb.h | 36 > arch/s390/include/asm/hugetlb.h| 56 > +- > arch/s390/include/asm/pgtable.h| 20 -- > arch/s390/mm/hugetlbpage.c | 2 +- > arch/sh/include/asm/hugetlb.h | 36 > arch/sparc/include/asm/hugetlb.h | 36 > arch/tile/include/asm/hugetlb.h| 36 > arch/x86/include/asm/hugetlb.h | 36 > mm/hugetlb.c | 23 > 11 files changed, 320 insertions(+), 33 deletions(-) > None of these wrappers are doing anything profound for most platforms, so this would be a good candidate for an asm-generic/hugetlb.h (after which s390 can continue to be special and no one else has to care). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 09/17] sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
On Tue, Mar 12, 2013 at 07:43:43PM +0900, Alex Courbot wrote: > On 03/12/2013 07:35 PM, Paul Mundt wrote: > >On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote: > >>SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected > >>through CONFIG_GPIOLIB, yet some compilation units depended on > >>CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it > >>is more accurate and prepares us for the future removal of > >>CONFIG_GENERIC_GPIO. > >> > >>Signed-off-by: Alexandre Courbot > > > >Note that the bulk of the GENERIC_GPIO use for SH has shifted to > >drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the > >Kconfig/Makefile bits there ought to be refactored too. > > Yes, that is the case for many other drivers actually. This series > just makes sure that GENERIC_GPIO is set through GPIOLIB *only*, > thus making both options equivalent. If nobody shoots me for this, I > will refactor individual drivers and ultimately remove GENERIC_GPIO > completely. > Ok, just wanted to make sure you were aware of this. I don't have any strong opinions on this one way or the other, the entire GPIO Kconfig mess is too ugly for words, so any effort to clean that up is probably worth the added bloat. Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 09/17] sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote: > SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected > through CONFIG_GPIOLIB, yet some compilation units depended on > CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it > is more accurate and prepares us for the future removal of > CONFIG_GENERIC_GPIO. > > Signed-off-by: Alexandre Courbot Note that the bulk of the GENERIC_GPIO use for SH has shifted to drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the Kconfig/Makefile bits there ought to be refactored too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sh: remove references to CPU_SUBTYPE_SH7764
On Mon, Mar 11, 2013 at 12:55:40PM +0100, Paul Bolle wrote: > Since release v2.6.29 the tree has a few references to the Kconfig > symbol CPU_SUBTYPE_SH7764 and the Kconfig macro > CONFIG_CPU_SUBTYPE_SH7764. But the actual symbol CPU_SUBTYPE_SH7764 was > never added to the tree. Perhaps no one noticed because these references > were never used alone. Anyhow, these references serve no purpose and > can be removed. > > Signed-off-by: Paul Bolle Looks fine, I suspect Iwamatsu-san let this trickle in from some vendor branch given that these are all his drivers. I'll queue it up, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sh: remove references to CPU_SUBTYPE_SH7764
On Mon, Mar 11, 2013 at 12:55:40PM +0100, Paul Bolle wrote: Since release v2.6.29 the tree has a few references to the Kconfig symbol CPU_SUBTYPE_SH7764 and the Kconfig macro CONFIG_CPU_SUBTYPE_SH7764. But the actual symbol CPU_SUBTYPE_SH7764 was never added to the tree. Perhaps no one noticed because these references were never used alone. Anyhow, these references serve no purpose and can be removed. Signed-off-by: Paul Bolle pebo...@tiscali.nl Looks fine, I suspect Iwamatsu-san let this trickle in from some vendor branch given that these are all his drivers. I'll queue it up, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 09/17] sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote: SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected through CONFIG_GPIOLIB, yet some compilation units depended on CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it is more accurate and prepares us for the future removal of CONFIG_GENERIC_GPIO. Signed-off-by: Alexandre Courbot acour...@nvidia.com Note that the bulk of the GENERIC_GPIO use for SH has shifted to drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the Kconfig/Makefile bits there ought to be refactored too. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 09/17] sh: replace CONFIG_GENERIC_GPIO by CONFIG_GPIOLIB
On Tue, Mar 12, 2013 at 07:43:43PM +0900, Alex Courbot wrote: On 03/12/2013 07:35 PM, Paul Mundt wrote: On Tue, Mar 12, 2013 at 07:12:22PM +0900, Alexandre Courbot wrote: SH GPIO drivers all use gpiolib and CONFIG_GENERIC_GPIO is only selected through CONFIG_GPIOLIB, yet some compilation units depended on CONFIG_GENERIC_GPIO. Make them depend on CONFIG_GPIOLIB instead since it is more accurate and prepares us for the future removal of CONFIG_GENERIC_GPIO. Signed-off-by: Alexandre Courbot acour...@nvidia.com Note that the bulk of the GENERIC_GPIO use for SH has shifted to drivers/pinctrl/sh-pfc/. If GPIOLIB is forced then a good chunk of the Kconfig/Makefile bits there ought to be refactored too. Yes, that is the case for many other drivers actually. This series just makes sure that GENERIC_GPIO is set through GPIOLIB *only*, thus making both options equivalent. If nobody shoots me for this, I will refactor individual drivers and ultimately remove GENERIC_GPIO completely. Ok, just wanted to make sure you were aware of this. I don't have any strong opinions on this one way or the other, the entire GPIO Kconfig mess is too ugly for words, so any effort to clean that up is probably worth the added bloat. Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/1] mm/hugetlb: add more arch-defined huge_pte_xxx functions
On Tue, Mar 12, 2013 at 07:48:25PM +0100, Gerald Schaefer wrote: This patch introduces those huge_pte_xxx functions and their implementation on all architectures supporting hugetlbfs. This change will be a no-op for all architectures other than s390. .. arch/ia64/include/asm/hugetlb.h| 36 arch/mips/include/asm/hugetlb.h| 36 arch/powerpc/include/asm/hugetlb.h | 36 arch/s390/include/asm/hugetlb.h| 56 +- arch/s390/include/asm/pgtable.h| 20 -- arch/s390/mm/hugetlbpage.c | 2 +- arch/sh/include/asm/hugetlb.h | 36 arch/sparc/include/asm/hugetlb.h | 36 arch/tile/include/asm/hugetlb.h| 36 arch/x86/include/asm/hugetlb.h | 36 mm/hugetlb.c | 23 11 files changed, 320 insertions(+), 33 deletions(-) None of these wrappers are doing anything profound for most platforms, so this would be a good candidate for an asm-generic/hugetlb.h (after which s390 can continue to be special and no one else has to care). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 21/33] mm/SH: use common help functions to free reserved pages
On Tue, Mar 05, 2013 at 10:55:04PM +0800, Jiang Liu wrote: > Use common help functions to free reserved pages. > > Signed-off-by: Jiang Liu > Cc: Paul Mundt Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v1 21/33] mm/SH: use common help functions to free reserved pages
On Tue, Mar 05, 2013 at 10:55:04PM +0800, Jiang Liu wrote: Use common help functions to free reserved pages. Signed-off-by: Jiang Liu jiang@huawei.com Cc: Paul Mundt let...@linux-sh.org Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/24] rtc: rtc-sh: use module_platform_driver_probe()
On Mon, Mar 04, 2013 at 05:05:34PM +0900, Jingoo Han wrote: > This patch uses module_platform_driver_probe() macro which makes > the code smaller and simpler. > > Signed-off-by: Jingoo Han Not sure I see the point, but: Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
> Adding a function irq_create_mapping_many() which can associate
> multiple MSIs to a continous irq mapping.
>
> This is needed to enable multiple MSI support for pSeries.
>
> +int irq_create_mapping_many(struct irq_domain *domain,
> + irq_hw_number_t hwirq_base, int count)
> +{
Other than the other review comments already made, I think you can
simplify this considerably by simply doing what irq_create_strict_mappings()
does,
and relaxing the irq_base requirements.
In any event, as you are creating a new interface, I don't think you want
to carry around half of the legacy crap that irq_create_mapping() has to
deal with. We made the decision to avoid this with irq_create_strict_mappings()
intentionally, too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] irq: Add hw continuous IRQs map to virtual continuous IRQs support
On Tue, Jan 15, 2013 at 03:38:55PM +0800, Mike Qiu wrote:
Adding a function irq_create_mapping_many() which can associate
multiple MSIs to a continous irq mapping.
This is needed to enable multiple MSI support for pSeries.
+int irq_create_mapping_many(struct irq_domain *domain,
+ irq_hw_number_t hwirq_base, int count)
+{
Other than the other review comments already made, I think you can
simplify this considerably by simply doing what irq_create_strict_mappings()
does,
and relaxing the irq_base requirements.
In any event, as you are creating a new interface, I don't think you want
to carry around half of the legacy crap that irq_create_mapping() has to
deal with. We made the decision to avoid this with irq_create_strict_mappings()
intentionally, too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/24] rtc: rtc-sh: use module_platform_driver_probe()
On Mon, Mar 04, 2013 at 05:05:34PM +0900, Jingoo Han wrote: This patch uses module_platform_driver_probe() macro which makes the code smaller and simpler. Signed-off-by: Jingoo Han jg1@samsung.com Not sure I see the point, but: Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] metag: Inhibit NUMA balancing.
The metag NUMA implementation follows the SH model, using different nodes for memories with different latencies. As such, we ensure that automated balancing between nodes is inhibited, by way of the new ARCH_WANT_VARIABLE_LOCALITY. Signed-off-by: Paul Mundt --- diff --git a/arch/metag/mm/Kconfig b/arch/metag/mm/Kconfig index cd7f2f2..975f2f4 100644 --- a/arch/metag/mm/Kconfig +++ b/arch/metag/mm/Kconfig @@ -40,6 +40,7 @@ endchoice config NUMA bool "Non Uniform Memory Access (NUMA) Support" + select ARCH_WANT_NUMA_VARIABLE_LOCALITY help Some Meta systems have MMU-mappable on-chip memories with lower latencies than main memory. This enables support for -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] metag: Inhibit NUMA balancing.
The metag NUMA implementation follows the SH model, using different nodes for memories with different latencies. As such, we ensure that automated balancing between nodes is inhibited, by way of the new ARCH_WANT_VARIABLE_LOCALITY. Signed-off-by: Paul Mundt let...@linux-sh.org --- diff --git a/arch/metag/mm/Kconfig b/arch/metag/mm/Kconfig index cd7f2f2..975f2f4 100644 --- a/arch/metag/mm/Kconfig +++ b/arch/metag/mm/Kconfig @@ -40,6 +40,7 @@ endchoice config NUMA bool Non Uniform Memory Access (NUMA) Support + select ARCH_WANT_NUMA_VARIABLE_LOCALITY help Some Meta systems have MMU-mappable on-chip memories with lower latencies than main memory. This enables support for -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Wed, Feb 27, 2013 at 06:52:51PM +0900, Magnus Damm wrote: > As you know, the INTC code that you are referring to is a full > interrupt controller designed to work directly with CPU cores like SH > and ARM. Newer ARM cores like Cortex-A9 all include the GIC both for > IPI purpose in case of SMP and they also implement SPI functionality > for I/O device interrupts. So the need for vendor-specific interrupt > controller IP is almost down to nothing these days. > Yes, I'm aware of that. > With that in mind I do really doubt that we end up reimplementing > sh_intc. The upcoming designs that I am aware of do not change their > external IRQ pin hardware to force us to update this driver. What > happens after that I'm afraid I can't say. =) > While I don't expect you would end up with a full reimplmentation, my concern is more that it would just be reproducing stuff that's already in place. IOW, perhaps it's less work to put sh_intc on a diet, and tie the core functionality that you need for external IRQ pins in to an irqchip there -- with the core of the old code adapted in to some sort of common base library, rather than coming up with a new lightweight irqchip driver and having to incrementally pile stuff on top of it later. > I mainly wrote this driver to support the r8a7779 SoC which can't be > driven by the existing INTC code base. During development I decided to > try to share the driver between multiple GIC-based SoCs like r8a7779 > and sh73a0. The reason behind trying to share this driver between > multiple SoCs is to remove SoC-specific hacks that can't be dealt with > by the existing INTC code. > Ok, fair enough. > I don't really understand why you would want to use a generic table > driven driver when you have the possibility of using a > hardware-specific driver. For the same reason sh_intc was written in the first place, every CPU subtype more or less had a similar set of interrupt controllers with minor deviations. Those deviations were sufficient enough to make the code pretty hairy in places, and what we have now is really more of a subsystem than an irqchip driver. Having to reproduce 90% of the code when you're adding new CPUs at the rate of 2 a month hardly makes an SoC-specific driver realistic, especially as you just end up with identical features being broken in subtly differnt ways on different SoCs. That being said, a lot of that is legacy stuff and a result of no CPU team talking to any other CPU team ever, and it seems like things have improved enough in that regard that perhaps a hardware-specific driver won't be a complete throw-away disaster like it was before. It's a risk either way, I just hope your lightweight solution remains lightweight and consistent long enough that we don't have multiple copies of slightly different drivers doing exactly same thing spiralling out of control and turning in to a maintenance nightmare. If sh_intc doesn't deal with the needs of the new GIC-backed SoCs then that's of course something that has to be addressed regardless (whether that be hacking up sh_intc or adding new hardware-specific irqchips). > I suppose you are wondering why no one seems to be working on INTC DT > support at this point. The truth is that we got very little feedback > and development support with interrupts in general last autumn and on > top of that our developers went their own way instead of following > advice. > I assumed it was either being rewritten or had already been merged, so I was simply surprised to hear otherwise. I will dig through the archives a bit later and see about getting caught up. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Wed, Feb 27, 2013 at 05:35:51PM +0900, Magnus Damm wrote: > On Wed, Feb 27, 2013 at 5:23 PM, Paul Mundt wrote: > > So how exactly does this interact with the existing sh_intc code? Or is > > there some reason why you have opted to bypass it in order to implement a > > simplified reduced-functionality version of INTC support focused only on > > external pins? If both are used together this is going to be a nightmare > > for locking, and it's also non-obvious how the IRQ domains on both sides > > will interact. > > > > This needs a lot more explanation. > > Recent GIC-based SoCs do not make use of INTC for any on-chip I/O > devices. This driver is meant to be used as a layer between the actual > IRQ pin and the GIC. Anything else needs the full driver. The existing > non-DT INTC driver can happily coexist with this driver like it does > in the case of sh73a0 here: > > [PATCH 02/03] ARM: shmobile: INTC External IRQ pin driver on sh73a0 > Ok, thanks for clarifying. I suppose the main concern is how quickly this will simply turn in to a deviated partial implementation of the full driver as newer SoCs begin deviating from your simplified case, and we basically end up reimplementing sh_intc anyways. > The driver is not meant to be used with INTC-only based systems like > sh7372 and the SH architecture. I would be very happy if someone could > get their shit together and fix up DT support for the common INTC > code. This has not happened yet though. So if you know anyone with > time to spare then feel free to suggest them to work together with > Iwamatsu-san to get the DT version of the code reviewed together with > Linaro. > I haven't heard or seen anything new on that in some time, so I assumed the work had stalled. I'm not sure why there wasn't more effort put in to DT support for the INTC code rather than simply coming up with a temporary bypass shim, and I'm not sure why you think this work is blocked by anyone (unless you're just referring to a general lack of resources). In any event, I'm not sure what the best option for the interim is. I suppose we can merge the irqchips until the INTC stuff catches up, but then we are probaby going to run in to a situation where they either have to co-exist, or the irqchips are removed and the sh_intc code has to carry a compat shim to deal with those DT bindings. Neither of those options seem particularly appealing to me. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Mon, Feb 18, 2013 at 11:28:34PM +0900, Magnus Damm wrote: > From: Magnus Damm > > This patch adds a driver for external IRQ pins connected > to the INTC block on recent SoCs from Renesas. > So how exactly does this interact with the existing sh_intc code? Or is there some reason why you have opted to bypass it in order to implement a simplified reduced-functionality version of INTC support focused only on external pins? If both are used together this is going to be a nightmare for locking, and it's also non-obvious how the IRQ domains on both sides will interact. This needs a lot more explanation. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Mon, Feb 18, 2013 at 11:28:34PM +0900, Magnus Damm wrote: From: Magnus Damm d...@opensource.se This patch adds a driver for external IRQ pins connected to the INTC block on recent SoCs from Renesas. So how exactly does this interact with the existing sh_intc code? Or is there some reason why you have opted to bypass it in order to implement a simplified reduced-functionality version of INTC support focused only on external pins? If both are used together this is going to be a nightmare for locking, and it's also non-obvious how the IRQ domains on both sides will interact. This needs a lot more explanation. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Wed, Feb 27, 2013 at 05:35:51PM +0900, Magnus Damm wrote: On Wed, Feb 27, 2013 at 5:23 PM, Paul Mundt let...@linux-sh.org wrote: So how exactly does this interact with the existing sh_intc code? Or is there some reason why you have opted to bypass it in order to implement a simplified reduced-functionality version of INTC support focused only on external pins? If both are used together this is going to be a nightmare for locking, and it's also non-obvious how the IRQ domains on both sides will interact. This needs a lot more explanation. Recent GIC-based SoCs do not make use of INTC for any on-chip I/O devices. This driver is meant to be used as a layer between the actual IRQ pin and the GIC. Anything else needs the full driver. The existing non-DT INTC driver can happily coexist with this driver like it does in the case of sh73a0 here: [PATCH 02/03] ARM: shmobile: INTC External IRQ pin driver on sh73a0 Ok, thanks for clarifying. I suppose the main concern is how quickly this will simply turn in to a deviated partial implementation of the full driver as newer SoCs begin deviating from your simplified case, and we basically end up reimplementing sh_intc anyways. The driver is not meant to be used with INTC-only based systems like sh7372 and the SH architecture. I would be very happy if someone could get their shit together and fix up DT support for the common INTC code. This has not happened yet though. So if you know anyone with time to spare then feel free to suggest them to work together with Iwamatsu-san to get the DT version of the code reviewed together with Linaro. I haven't heard or seen anything new on that in some time, so I assumed the work had stalled. I'm not sure why there wasn't more effort put in to DT support for the INTC code rather than simply coming up with a temporary bypass shim, and I'm not sure why you think this work is blocked by anyone (unless you're just referring to a general lack of resources). In any event, I'm not sure what the best option for the interim is. I suppose we can merge the irqchips until the INTC stuff catches up, but then we are probaby going to run in to a situation where they either have to co-exist, or the irqchips are removed and the sh_intc code has to carry a compat shim to deal with those DT bindings. Neither of those options seem particularly appealing to me. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] irqchip: Renesas INTC External IRQ pin driver
On Wed, Feb 27, 2013 at 06:52:51PM +0900, Magnus Damm wrote: As you know, the INTC code that you are referring to is a full interrupt controller designed to work directly with CPU cores like SH and ARM. Newer ARM cores like Cortex-A9 all include the GIC both for IPI purpose in case of SMP and they also implement SPI functionality for I/O device interrupts. So the need for vendor-specific interrupt controller IP is almost down to nothing these days. Yes, I'm aware of that. With that in mind I do really doubt that we end up reimplementing sh_intc. The upcoming designs that I am aware of do not change their external IRQ pin hardware to force us to update this driver. What happens after that I'm afraid I can't say. =) While I don't expect you would end up with a full reimplmentation, my concern is more that it would just be reproducing stuff that's already in place. IOW, perhaps it's less work to put sh_intc on a diet, and tie the core functionality that you need for external IRQ pins in to an irqchip there -- with the core of the old code adapted in to some sort of common base library, rather than coming up with a new lightweight irqchip driver and having to incrementally pile stuff on top of it later. I mainly wrote this driver to support the r8a7779 SoC which can't be driven by the existing INTC code base. During development I decided to try to share the driver between multiple GIC-based SoCs like r8a7779 and sh73a0. The reason behind trying to share this driver between multiple SoCs is to remove SoC-specific hacks that can't be dealt with by the existing INTC code. Ok, fair enough. I don't really understand why you would want to use a generic table driven driver when you have the possibility of using a hardware-specific driver. For the same reason sh_intc was written in the first place, every CPU subtype more or less had a similar set of interrupt controllers with minor deviations. Those deviations were sufficient enough to make the code pretty hairy in places, and what we have now is really more of a subsystem than an irqchip driver. Having to reproduce 90% of the code when you're adding new CPUs at the rate of 2 a month hardly makes an SoC-specific driver realistic, especially as you just end up with identical features being broken in subtly differnt ways on different SoCs. That being said, a lot of that is legacy stuff and a result of no CPU team talking to any other CPU team ever, and it seems like things have improved enough in that regard that perhaps a hardware-specific driver won't be a complete throw-away disaster like it was before. It's a risk either way, I just hope your lightweight solution remains lightweight and consistent long enough that we don't have multiple copies of slightly different drivers doing exactly same thing spiralling out of control and turning in to a maintenance nightmare. If sh_intc doesn't deal with the needs of the new GIC-backed SoCs then that's of course something that has to be addressed regardless (whether that be hacking up sh_intc or adding new hardware-specific irqchips). I suppose you are wondering why no one seems to be working on INTC DT support at this point. The truth is that we got very little feedback and development support with interrupts in general last autumn and on top of that our developers went their own way instead of following advice. I assumed it was either being rewritten or had already been merged, so I was simply surprised to hear otherwise. I will dig through the archives a bit later and see about getting caught up. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] ARM: smp: Remove local timer API
On Fri, Feb 22, 2013 at 11:15:45AM +, Mark Rutland wrote: > One thing that struck me when I was fiddling with the broadcast mechanism was > that it should be possible to have a generic dummy timer implementation. As > long as the architecture calls notifiers at the appropriate times, it should > look like any other timer driver (apart from not touching any hardware). It > just > needs to depend on ARCH_HAS_TICK_BROADCAST. > > I believe it shouldn't be too difficult to implement, though I may be blind to > some problems. > It would be nice to have a generic dummy timer driver, quite a few architectures could use it directly already. If no one beats me to it, I'll give it a go as I convert the SH stuff over to using ARCH_HAS_TICK_BROADCAST and killing off the local timer API there. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 8/8] ARM: smp: Remove local timer API
On Fri, Feb 22, 2013 at 11:15:45AM +, Mark Rutland wrote: One thing that struck me when I was fiddling with the broadcast mechanism was that it should be possible to have a generic dummy timer implementation. As long as the architecture calls notifiers at the appropriate times, it should look like any other timer driver (apart from not touching any hardware). It just needs to depend on ARCH_HAS_TICK_BROADCAST. I believe it shouldn't be too difficult to implement, though I may be blind to some problems. It would be nice to have a generic dummy timer driver, quite a few architectures could use it directly already. If no one beats me to it, I'll give it a go as I convert the SH stuff over to using ARCH_HAS_TICK_BROADCAST and killing off the local timer API there. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] gpiolib: use descriptors internally
On Tue, Feb 12, 2013 at 01:29:10PM +0100, Linus Walleij wrote: > On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren wrote: > > On 02/11/2013 07:09 AM, Linus Walleij wrote: > > >> However if you take this all the way to the descriptor API > >> it will make the consumer (driver) API for GPIO descriptors deviate > >> from what is today used for clocks, regulators and pins. > >> > >> With all the resulting confusion for users. > >> I've seen worse subsystem deviations though. > > > > Sorry I haven't looked at the specific APIs this discussion refers to, > > but clients of the GPIO descriptor API are going to need to distinguish > > "fail" from "deferred probe", so at least some initial get-like API will > > need to pass back some error detail... > > Right, so in some other patch I stated that this would lead > to a GPIO descriptor fetch interface such as this: > > int gpiod_get(struct gpiod_desc **gpiod, struct device *dev, const char > *name); > > Rather than the more established: > > struct gpio_desc *gpiod_get(struct device *dev, const char *name); > > And I'm worried about the lack of consistency. > > While I do get the point... I chatted with Grant about it and > I want to talk to some toolchain people about this to see if > pointers containing potential error codes can somehow be > "flagged" by the compiler so we can enforce error checking on > them. (It may sound a bit utopic...) > At the very least you can __must_check annotate, although that's probably still a bit coarser grained than what you're after. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] gpiolib: use descriptors internally
On Tue, Feb 12, 2013 at 01:29:10PM +0100, Linus Walleij wrote: On Mon, Feb 11, 2013 at 6:39 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 02/11/2013 07:09 AM, Linus Walleij wrote: However if you take this all the way to the descriptor API it will make the consumer (driver) API for GPIO descriptors deviate from what is today used for clocks, regulators and pins. With all the resulting confusion for users. I've seen worse subsystem deviations though. Sorry I haven't looked at the specific APIs this discussion refers to, but clients of the GPIO descriptor API are going to need to distinguish fail from deferred probe, so at least some initial get-like API will need to pass back some error detail... Right, so in some other patch I stated that this would lead to a GPIO descriptor fetch interface such as this: int gpiod_get(struct gpiod_desc **gpiod, struct device *dev, const char *name); Rather than the more established: struct gpio_desc *gpiod_get(struct device *dev, const char *name); And I'm worried about the lack of consistency. While I do get the point... I chatted with Grant about it and I want to talk to some toolchain people about this to see if pointers containing potential error codes can somehow be flagged by the compiler so we can enforce error checking on them. (It may sound a bit utopic...) At the very least you can __must_check annotate, although that's probably still a bit coarser grained than what you're after. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] gpiolib: use descriptors internally
On Mon, Feb 11, 2013 at 03:09:21PM +0100, Linus Walleij wrote: > On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely > wrote: > > > The ERR_PTR()/IS_ERR() is a horrible pattern for code > > readability because it breaks the expectations that programmers have for > > what is and is not a bad pointer. There are decades of history where the > > test for a bad pointer is 'if (!ptr)'. Not only does ERR_PTR make make > > that test not work, but the compiler won't tell you when you get it > > wrong. > > > > There are places where ERR_PTR makes sense. Particularly when > > communicating with userspace where error codes have very specific > > meanings, but I don't want it in the GPIO subsystem. > > OK I disagree but you get to decide. > > However if you take this all the way to the descriptor API > it will make the consumer (driver) API for GPIO descriptors deviate > from what is today used for clocks, regulators and pins. > > With all the resulting confusion for users. > I've seen worse subsystem deviations though. > I've always considered it to be more of a complexity issue. If an interface can fail for half a dozen different reasons, it's useful to be able to encapsulate this and pass it down the line to the consumer (particularly in cases where no useful debug output is provided, and the first thing someone is going to do is go and instrument the registration path with printks to figure out where things went wrong). In the case where the work to do is relatively straightforward and there's not much complexity, NULL is clearly the way to go. There are already quite a few cases today converting NULLs over to arbitrary ERR_PTR values or IS_ERR cases wrapping back to NULL, so it's clear that both have to be supported interacting with one another regardless. Then there's that whole IS_ERR_OR_NULL case which everyone seems to get wrong, but that's another issue entirely. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/9] gpiolib: use descriptors internally
On Mon, Feb 11, 2013 at 03:09:21PM +0100, Linus Walleij wrote: On Sat, Feb 9, 2013 at 10:17 AM, Grant Likely grant.lik...@secretlab.ca wrote: The ERR_PTR()/IS_ERR() is a horrible pattern for code readability because it breaks the expectations that programmers have for what is and is not a bad pointer. There are decades of history where the test for a bad pointer is 'if (!ptr)'. Not only does ERR_PTR make make that test not work, but the compiler won't tell you when you get it wrong. There are places where ERR_PTR makes sense. Particularly when communicating with userspace where error codes have very specific meanings, but I don't want it in the GPIO subsystem. OK I disagree but you get to decide. However if you take this all the way to the descriptor API it will make the consumer (driver) API for GPIO descriptors deviate from what is today used for clocks, regulators and pins. With all the resulting confusion for users. I've seen worse subsystem deviations though. I've always considered it to be more of a complexity issue. If an interface can fail for half a dozen different reasons, it's useful to be able to encapsulate this and pass it down the line to the consumer (particularly in cases where no useful debug output is provided, and the first thing someone is going to do is go and instrument the registration path with printks to figure out where things went wrong). In the case where the work to do is relatively straightforward and there's not much complexity, NULL is clearly the way to go. There are already quite a few cases today converting NULLs over to arbitrary ERR_PTR values or IS_ERR cases wrapping back to NULL, so it's clear that both have to be supported interacting with one another regardless. Then there's that whole IS_ERR_OR_NULL case which everyone seems to get wrong, but that's another issue entirely. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver
On Mon, Feb 04, 2013 at 12:32:16PM +0100, Philipp Zabel wrote: > This driver requests and remaps a memory region as configured in the > device tree. It serves memory from this region via the genalloc API. > It optionally enables the SRAM clock. > > Other drivers can retrieve the genalloc pool from a phandle pointing > to this drivers' device node in the device tree. > > The allocation granularity is hard-coded to 32 bytes for now, > to make the SRAM driver useful for the 6502 remoteproc driver. > There is overhead for bigger SRAMs, where only a much coarser > allocation granularity is needed: At 32 bytes minimum allocation > size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. > > Signed-off-by: Philipp Zabel > Reviewed-by: Shawn Guo How exactly is this "generic" if you have randomly hard-coded an allocation granularity that is larger than half of the in-tree SRAM pool users today can even support? Did you even bother to look at in-tree SRAM pool users other than the one you are working on? There also doesn't seem to be any real reason for the hard-coding either, this information could easily be fetched via platform data or the device tree, and the driver in question would simply need to be able to determine whether the size is suitable for it or not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
On Mon, Feb 04, 2013 at 10:09:43AM +, James Hogan wrote:
> The IRQ_PER_CPU Kconfig symbol was removed in the following commit:
>
> Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 ("genirq: Remove
> CONFIG_IRQ_PER_CPU") merged in v2.6.39-rc1.
>
> But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig
> files where it was defined or selected. It's completely unused so remove
> the remaining references.
>
> Signed-off-by: James Hogan
> Cc: Thomas Gleixner
> Cc: Mike Frysinger
> Cc: Fenghua Yu
> Cc: Ralf Baechle
> Cc: "James E.J. Bottomley"
> Cc: Helge Deller
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Paul Mundt
> Acked-by: Tony Luck
> Acked-by: Richard Kuo
Acked-by: Paul Mundt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 1/1] arch Kconfig: remove references to IRQ_PER_CPU
On Mon, Feb 04, 2013 at 10:09:43AM +, James Hogan wrote: The IRQ_PER_CPU Kconfig symbol was removed in the following commit: Commit 6a58fb3bad099076f36f0f30f44507bc3275cdb6 (genirq: Remove CONFIG_IRQ_PER_CPU) merged in v2.6.39-rc1. But IRQ_PER_CPU wasn't removed from any of the architecture Kconfig files where it was defined or selected. It's completely unused so remove the remaining references. Signed-off-by: James Hogan james.ho...@imgtec.com Cc: Thomas Gleixner t...@linutronix.de Cc: Mike Frysinger vap...@gentoo.org Cc: Fenghua Yu fenghua...@intel.com Cc: Ralf Baechle r...@linux-mips.org Cc: James E.J. Bottomley j...@parisc-linux.org Cc: Helge Deller del...@gmx.de Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Paul Mundt let...@linux-sh.org Acked-by: Tony Luck tony.l...@intel.com Acked-by: Richard Kuo r...@codeaurora.org Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver
On Mon, Feb 04, 2013 at 12:32:16PM +0100, Philipp Zabel wrote: This driver requests and remaps a memory region as configured in the device tree. It serves memory from this region via the genalloc API. It optionally enables the SRAM clock. Other drivers can retrieve the genalloc pool from a phandle pointing to this drivers' device node in the device tree. The allocation granularity is hard-coded to 32 bytes for now, to make the SRAM driver useful for the 6502 remoteproc driver. There is overhead for bigger SRAMs, where only a much coarser allocation granularity is needed: At 32 bytes minimum allocation size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. Signed-off-by: Philipp Zabel p.za...@pengutronix.de Reviewed-by: Shawn Guo shawn@linaro.org How exactly is this generic if you have randomly hard-coded an allocation granularity that is larger than half of the in-tree SRAM pool users today can even support? Did you even bother to look at in-tree SRAM pool users other than the one you are working on? There also doesn't seem to be any real reason for the hard-coding either, this information could easily be fetched via platform data or the device tree, and the driver in question would simply need to be able to determine whether the size is suitable for it or not. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740
On Fri, Feb 01, 2013 at 02:56:33PM +0100, Joerg Roedel wrote: > On Mon, Jan 21, 2013 at 07:54:25PM +0900, Hideki EIRAKU wrote: > > Hideki EIRAKU (4): > > iommu/shmobile: Add iommu driver for Renesas IPMMU modules > > ARM: mach-shmobile: sh7372: Add IPMMU device > > ARM: mach-shmobile: sh73a0: Add IPMMU device > > ARM: mach-shmobile: r8a7740: Add IPMMU device > > Paul, Magnus, any opinions on patches 2-4? Can you ACK them when they > are ok for you? > No strong opinions one way or the other, patches 2-4 don't really do anything of significance. Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 0/4] Renesas IPMMU driver for sh7372, sh73a0 and r8a7740
On Fri, Feb 01, 2013 at 02:56:33PM +0100, Joerg Roedel wrote: On Mon, Jan 21, 2013 at 07:54:25PM +0900, Hideki EIRAKU wrote: Hideki EIRAKU (4): iommu/shmobile: Add iommu driver for Renesas IPMMU modules ARM: mach-shmobile: sh7372: Add IPMMU device ARM: mach-shmobile: sh73a0: Add IPMMU device ARM: mach-shmobile: r8a7740: Add IPMMU device Paul, Magnus, any opinions on patches 2-4? Can you ACK them when they are ok for you? No strong opinions one way or the other, patches 2-4 don't really do anything of significance. Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 28/76] ARC: I/O and DMA Mappings
On Fri, Jan 18, 2013 at 03:55:43PM +, Arnd Bergmann wrote: > On Friday 18 January 2013, Vineet Gupta wrote: > > TBD: Do we need early ioremap support like openrisc > > > > Signed-off-by: Vineet Gupta > > Can you explain why early ioremap is necessary for you? > > I wasn't aware that openrisc has it. In a lot of cases, > you can use fixmap as a replacement. > The two don't need to be mutually exclusive, either. sh implements early ioremap transparently via fixmaps for example: arch/sh/mm/ioremap.c arch/sh/mm/ioremap_fixed.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 28/76] ARC: I/O and DMA Mappings
On Fri, Jan 18, 2013 at 03:55:43PM +, Arnd Bergmann wrote: On Friday 18 January 2013, Vineet Gupta wrote: TBD: Do we need early ioremap support like openrisc Signed-off-by: Vineet Gupta vgu...@synopsys.com Can you explain why early ioremap is necessary for you? I wasn't aware that openrisc has it. In a lot of cases, you can use fixmap as a replacement. The two don't need to be mutually exclusive, either. sh implements early ioremap transparently via fixmaps for example: arch/sh/mm/ioremap.c arch/sh/mm/ioremap_fixed.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.8-rc4
The following changes since commit 254adaa465c40151df11fc1f88f93e6e86eb61d4: seq_file: fix new kernel-doc warnings (2013-01-10 14:35:24 -0800) are available in the git repository at: git://github.com/pmundt/linux-sh.git tags/sh-for-linus for you to fetch changes up to 035688d9c64c61957dd272a1e773f27b0143704d: sh: ecovec: add sample amixer settings (2013-01-16 18:30:44 +0900) SuperH fixes for 3.8-rc4 Kuninori Morimoto (3): sh: define TASK_UNMAPPED_BASE as a page aligned constant sh: clkfwk: bugfix: sh_clk_div_enable() care sh_clk_div_set_rate() if div6 sh: ecovec: add sample amixer settings Paul Mundt (2): sh: wire up finit_module syscall. sh: Fix up stack debugging build. Thomas Schwinge (1): sh: Fix FDPIC binary loader arch/sh/boards/mach-ecovec24/setup.c | 10 ++ arch/sh/include/asm/elf.h|4 ++-- arch/sh/include/asm/processor_32.h |2 +- arch/sh/include/asm/processor_64.h |2 +- arch/sh/include/uapi/asm/unistd_32.h |3 ++- arch/sh/include/uapi/asm/unistd_64.h |3 ++- arch/sh/kernel/syscalls_32.S |1 + arch/sh/kernel/syscalls_64.S |1 + arch/sh/lib/mcount.S |2 ++ drivers/sh/clk/cpg.c |6 ++ 10 files changed, 28 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.8-rc4
The following changes since commit 254adaa465c40151df11fc1f88f93e6e86eb61d4: seq_file: fix new kernel-doc warnings (2013-01-10 14:35:24 -0800) are available in the git repository at: git://github.com/pmundt/linux-sh.git tags/sh-for-linus for you to fetch changes up to 035688d9c64c61957dd272a1e773f27b0143704d: sh: ecovec: add sample amixer settings (2013-01-16 18:30:44 +0900) SuperH fixes for 3.8-rc4 Kuninori Morimoto (3): sh: define TASK_UNMAPPED_BASE as a page aligned constant sh: clkfwk: bugfix: sh_clk_div_enable() care sh_clk_div_set_rate() if div6 sh: ecovec: add sample amixer settings Paul Mundt (2): sh: wire up finit_module syscall. sh: Fix up stack debugging build. Thomas Schwinge (1): sh: Fix FDPIC binary loader arch/sh/boards/mach-ecovec24/setup.c | 10 ++ arch/sh/include/asm/elf.h|4 ++-- arch/sh/include/asm/processor_32.h |2 +- arch/sh/include/asm/processor_64.h |2 +- arch/sh/include/uapi/asm/unistd_32.h |3 ++- arch/sh/include/uapi/asm/unistd_64.h |3 ++- arch/sh/kernel/syscalls_32.S |1 + arch/sh/kernel/syscalls_64.S |1 + arch/sh/lib/mcount.S |2 ++ drivers/sh/clk/cpg.c |6 ++ 10 files changed, 28 insertions(+), 6 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk dereference in arch/sh/kernel/cpufreq.c
On Thu, Jan 10, 2013 at 10:31:46AM +0100, Julia Lawall wrote: > On Thu, 10 Jan 2013, Paul Mundt wrote: > > > On Thu, Jan 03, 2013 at 10:40:20AM +0100, Julia Lawall wrote: > > > There has been a discussion recently about how the result of get_clk > > > should be an opaque handle, not a value that can be dereferenced: > > > > > > https://lkml.org/lkml/2012/12/20/105 > > > > > > There is such a dereference in arch/sh/kernel/cpufreq.c, in the function > > > sh_cpufreq_cpu_init: > > > > > > freq_table = cpuclk->nr_freqs ? cpuclk->freq_table : NULL; > > > > > > It was not obvious to me, however, what API function should be used > > > instead, so I am just reporting the (potential) problem. > > > > > In this case we would have to add some new API for fetching the frequency > > table associated with the struct clk, which is reasonably > > straightforward. It's not obvious how a private API vs deref of a type we > > have a private definition for is any better or worse, though. This code > > is not aimed at the common struct clk in any event. > > OK, maybe it should just be left as is? > That would be in line with my intentions. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk dereference in arch/sh/kernel/cpufreq.c
On Thu, Jan 03, 2013 at 10:40:20AM +0100, Julia Lawall wrote: > There has been a discussion recently about how the result of get_clk > should be an opaque handle, not a value that can be dereferenced: > > https://lkml.org/lkml/2012/12/20/105 > > There is such a dereference in arch/sh/kernel/cpufreq.c, in the function > sh_cpufreq_cpu_init: > > freq_table = cpuclk->nr_freqs ? cpuclk->freq_table : NULL; > > It was not obvious to me, however, what API function should be used > instead, so I am just reporting the (potential) problem. > In this case we would have to add some new API for fetching the frequency table associated with the struct clk, which is reasonably straightforward. It's not obvious how a private API vs deref of a type we have a private definition for is any better or worse, though. This code is not aimed at the common struct clk in any event. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk dereference in arch/sh/kernel/cpufreq.c
On Thu, Jan 03, 2013 at 10:40:20AM +0100, Julia Lawall wrote: There has been a discussion recently about how the result of get_clk should be an opaque handle, not a value that can be dereferenced: https://lkml.org/lkml/2012/12/20/105 There is such a dereference in arch/sh/kernel/cpufreq.c, in the function sh_cpufreq_cpu_init: freq_table = cpuclk-nr_freqs ? cpuclk-freq_table : NULL; It was not obvious to me, however, what API function should be used instead, so I am just reporting the (potential) problem. In this case we would have to add some new API for fetching the frequency table associated with the struct clk, which is reasonably straightforward. It's not obvious how a private API vs deref of a type we have a private definition for is any better or worse, though. This code is not aimed at the common struct clk in any event. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: clk dereference in arch/sh/kernel/cpufreq.c
On Thu, Jan 10, 2013 at 10:31:46AM +0100, Julia Lawall wrote: On Thu, 10 Jan 2013, Paul Mundt wrote: On Thu, Jan 03, 2013 at 10:40:20AM +0100, Julia Lawall wrote: There has been a discussion recently about how the result of get_clk should be an opaque handle, not a value that can be dereferenced: https://lkml.org/lkml/2012/12/20/105 There is such a dereference in arch/sh/kernel/cpufreq.c, in the function sh_cpufreq_cpu_init: freq_table = cpuclk-nr_freqs ? cpuclk-freq_table : NULL; It was not obvious to me, however, what API function should be used instead, so I am just reporting the (potential) problem. In this case we would have to add some new API for fetching the frequency table associated with the struct clk, which is reasonably straightforward. It's not obvious how a private API vs deref of a type we have a private definition for is any better or worse, though. This code is not aimed at the common struct clk in any event. OK, maybe it should just be left as is? That would be in line with my intentions. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 03:27:01AM +0100, Laurent Pinchart wrote: > Hi everybody, > > Here's a pretty large patch series that rework pin control and GPIO support > for SH and ARM SH/Renesas Mobile/Car platforms. The patches are based on top > of v3.7-rc6. You can get them from my git tree at > > git://linuxtv.org/pinchartl/fbdev.git pinmux > > The idea behind these patches is to move SoC-specific pin control code from > arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the > pin control device. This is required to add device tree support for the pin > control device. > > The code has been compile-tested on all modified platforms except SH7264 and > SH7269, and runtime tested on SH7372 (Mackerel), SH73A0 (KZM-A9-GT) and > R8A7740 (Armadillo) so far. I will runtime test it on R8A7779 (Marzen). > > The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't > be compiled for them. As the currently implemented arch-level pinmux support > also depends on generic GPIO, we're moving from a situation where the code > isn't used to a different situation where the code isn't used. I don't > consider that as a regression. > > Sorry for the numerous checkpatch warnings, patches that move code around or > rename files don't modify the content to make review easier, and thus carry > warnings from the existing code. > > Currently missing from this series are DT bindings. I will send patches for > those a bit later. As they will build on top of this series I would appreciate > reviews (and hopefilly ack's). > I've only given it a quick look, but in general it looks good! For the series: Acked-by: Paul Mundt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/42] SH pin control and GPIO rework
On Wed, Nov 21, 2012 at 03:27:01AM +0100, Laurent Pinchart wrote: Hi everybody, Here's a pretty large patch series that rework pin control and GPIO support for SH and ARM SH/Renesas Mobile/Car platforms. The patches are based on top of v3.7-rc6. You can get them from my git tree at git://linuxtv.org/pinchartl/fbdev.git pinmux The idea behind these patches is to move SoC-specific pin control code from arch/ to drivers/pinctrl/ and use the Linux device model to instantiate the pin control device. This is required to add device tree support for the pin control device. The code has been compile-tested on all modified platforms except SH7264 and SH7269, and runtime tested on SH7372 (Mackerel), SH73A0 (KZM-A9-GT) and R8A7740 (Armadillo) so far. I will runtime test it on R8A7779 (Marzen). The SH7264 and SH7269 platforms have no gpiolib support so the PFC code can't be compiled for them. As the currently implemented arch-level pinmux support also depends on generic GPIO, we're moving from a situation where the code isn't used to a different situation where the code isn't used. I don't consider that as a regression. Sorry for the numerous checkpatch warnings, patches that move code around or rename files don't modify the content to make review easier, and thus carry warnings from the existing code. Currently missing from this series are DT bindings. I will send patches for those a bit later. As they will build on top of this series I would appreciate reviews (and hopefilly ack's). I've only given it a quick look, but in general it looks good! For the series: Acked-by: Paul Mundt let...@linux-sh.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 027/193] arch/sh: remove CONFIG_EXPERIMENTAL
On Tue, Oct 23, 2012 at 01:01:40PM -0700, Kees Cook wrote: > This config item has not carried much meaning for a while now and is > almost always enabled by default. As agreed during the Linux kernel > summit, remove it. > > CC: Paul Mundt > CC: Tejun Heo > Signed-off-by: Kees Cook While there are cases where it is largely superfluous, we also have plenty of cases in here that are genuinely experimental features and generally shouldn't be enabled unless someone is prepared for some hacking. We can of course replace this with an arch-specific option if needed, but I disagree with suddenly making experimental features suddenly appear to be anything other than what they are. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 027/193] arch/sh: remove CONFIG_EXPERIMENTAL
On Tue, Oct 23, 2012 at 01:01:40PM -0700, Kees Cook wrote: This config item has not carried much meaning for a while now and is almost always enabled by default. As agreed during the Linux kernel summit, remove it. CC: Paul Mundt let...@linux-sh.org CC: Tejun Heo t...@kernel.org Signed-off-by: Kees Cook keesc...@chromium.org While there are cases where it is largely superfluous, we also have plenty of cases in here that are genuinely experimental features and generally shouldn't be enabled unless someone is prepared for some hacking. We can of course replace this with an arch-specific option if needed, but I disagree with suddenly making experimental features suddenly appear to be anything other than what they are. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.7-rc2
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://github.com/pmundt/linux-sh tags/sh-for-linus
for you to fetch changes up to 0dd4d5cbe4c38165dc9b3ad329ebb23f24d74fdb:
sh: Fix up more fallout from pointless ARM __iomem churn. (2012-10-15
14:08:48 +0900)
SuperH updates for 3.7-rc2
David Howells (1):
UAPI: (Scripted) Disintegrate arch/sh/include/asm
Paul Mundt (3):
Merge tag 'disintegrate-sh-20121009' of
git://git.infradead.org/users/dhowells/linux-headers into sh-latest
sh: Wire up kcmp syscall.
sh: Fix up more fallout from pointless ARM __iomem churn.
arch/sh/include/asm/Kbuild | 11
arch/sh/include/asm/hw_breakpoint.h | 4 +-
arch/sh/include/asm/posix_types.h | 8 ---
arch/sh/include/asm/ptrace.h| 34 +--
arch/sh/include/asm/ptrace_32.h | 75 +---
arch/sh/include/asm/ptrace_64.h | 12 +---
arch/sh/include/asm/setup.h | 5 +-
arch/sh/include/asm/types.h | 5 +-
arch/sh/include/asm/unistd.h| 9 +--
arch/sh/include/uapi/asm/Kbuild | 22 +++
arch/sh/include/{ => uapi}/asm/auxvec.h | 0
arch/sh/include/{ => uapi}/asm/byteorder.h | 0
arch/sh/include/{ => uapi}/asm/cachectl.h | 0
arch/sh/include/{ => uapi}/asm/cpu-features.h | 0
arch/sh/include/{ => uapi}/asm/ioctls.h | 0
arch/sh/include/uapi/asm/posix_types.h | 7 +++
arch/sh/include/{ => uapi}/asm/posix_types_32.h | 0
arch/sh/include/{ => uapi}/asm/posix_types_64.h | 0
arch/sh/include/uapi/asm/ptrace.h | 34 +++
arch/sh/include/uapi/asm/ptrace_32.h| 77 +
arch/sh/include/uapi/asm/ptrace_64.h| 14 +
arch/sh/include/uapi/asm/setup.h| 1 +
arch/sh/include/{ => uapi}/asm/sigcontext.h | 0
arch/sh/include/{ => uapi}/asm/signal.h | 0
arch/sh/include/{ => uapi}/asm/sockios.h| 0
arch/sh/include/{ => uapi}/asm/stat.h | 0
arch/sh/include/{ => uapi}/asm/swab.h | 0
arch/sh/include/uapi/asm/types.h| 1 +
arch/sh/include/uapi/asm/unistd.h | 7 +++
arch/sh/include/{ => uapi}/asm/unistd_32.h | 3 +-
arch/sh/include/{ => uapi}/asm/unistd_64.h | 3 +-
arch/sh/kernel/syscalls_32.S| 1 +
arch/sh/kernel/syscalls_64.S| 1 +
drivers/sh/intc/access.c| 45 +--
drivers/sh/intc/chip.c | 4 +-
drivers/tty/serial/sh-sci.c | 3 +-
36 files changed, 210 insertions(+), 176 deletions(-)
rename arch/sh/include/{ => uapi}/asm/auxvec.h (100%)
rename arch/sh/include/{ => uapi}/asm/byteorder.h (100%)
rename arch/sh/include/{ => uapi}/asm/cachectl.h (100%)
rename arch/sh/include/{ => uapi}/asm/cpu-features.h (100%)
create mode 100644 arch/sh/include/uapi/asm/hw_breakpoint.h
rename arch/sh/include/{ => uapi}/asm/ioctls.h (100%)
create mode 100644 arch/sh/include/uapi/asm/posix_types.h
rename arch/sh/include/{ => uapi}/asm/posix_types_32.h (100%)
rename arch/sh/include/{ => uapi}/asm/posix_types_64.h (100%)
create mode 100644 arch/sh/include/uapi/asm/ptrace.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_32.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_64.h
create mode 100644 arch/sh/include/uapi/asm/setup.h
rename arch/sh/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/sh/include/{ => uapi}/asm/signal.h (100%)
rename arch/sh/include/{ => uapi}/asm/sockios.h (100%)
rename arch/sh/include/{ => uapi}/asm/stat.h (100%)
rename arch/sh/include/{ => uapi}/asm/swab.h (100%)
create mode 100644 arch/sh/include/uapi/asm/types.h
create mode 100644 arch/sh/include/uapi/asm/unistd.h
rename arch/sh/include/{ => uapi}/asm/unistd_32.h (99%)
rename arch/sh/include/{ => uapi}/asm/unistd_64.h (99%)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.7-rc2
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://github.com/pmundt/linux-sh tags/sh-for-linus
for you to fetch changes up to 0dd4d5cbe4c38165dc9b3ad329ebb23f24d74fdb:
sh: Fix up more fallout from pointless ARM __iomem churn. (2012-10-15
14:08:48 +0900)
SuperH updates for 3.7-rc2
David Howells (1):
UAPI: (Scripted) Disintegrate arch/sh/include/asm
Paul Mundt (3):
Merge tag 'disintegrate-sh-20121009' of
git://git.infradead.org/users/dhowells/linux-headers into sh-latest
sh: Wire up kcmp syscall.
sh: Fix up more fallout from pointless ARM __iomem churn.
arch/sh/include/asm/Kbuild | 11
arch/sh/include/asm/hw_breakpoint.h | 4 +-
arch/sh/include/asm/posix_types.h | 8 ---
arch/sh/include/asm/ptrace.h| 34 +--
arch/sh/include/asm/ptrace_32.h | 75 +---
arch/sh/include/asm/ptrace_64.h | 12 +---
arch/sh/include/asm/setup.h | 5 +-
arch/sh/include/asm/types.h | 5 +-
arch/sh/include/asm/unistd.h| 9 +--
arch/sh/include/uapi/asm/Kbuild | 22 +++
arch/sh/include/{ = uapi}/asm/auxvec.h | 0
arch/sh/include/{ = uapi}/asm/byteorder.h | 0
arch/sh/include/{ = uapi}/asm/cachectl.h | 0
arch/sh/include/{ = uapi}/asm/cpu-features.h | 0
arch/sh/include/{ = uapi}/asm/ioctls.h | 0
arch/sh/include/uapi/asm/posix_types.h | 7 +++
arch/sh/include/{ = uapi}/asm/posix_types_32.h | 0
arch/sh/include/{ = uapi}/asm/posix_types_64.h | 0
arch/sh/include/uapi/asm/ptrace.h | 34 +++
arch/sh/include/uapi/asm/ptrace_32.h| 77 +
arch/sh/include/uapi/asm/ptrace_64.h| 14 +
arch/sh/include/uapi/asm/setup.h| 1 +
arch/sh/include/{ = uapi}/asm/sigcontext.h | 0
arch/sh/include/{ = uapi}/asm/signal.h | 0
arch/sh/include/{ = uapi}/asm/sockios.h| 0
arch/sh/include/{ = uapi}/asm/stat.h | 0
arch/sh/include/{ = uapi}/asm/swab.h | 0
arch/sh/include/uapi/asm/types.h| 1 +
arch/sh/include/uapi/asm/unistd.h | 7 +++
arch/sh/include/{ = uapi}/asm/unistd_32.h | 3 +-
arch/sh/include/{ = uapi}/asm/unistd_64.h | 3 +-
arch/sh/kernel/syscalls_32.S| 1 +
arch/sh/kernel/syscalls_64.S| 1 +
drivers/sh/intc/access.c| 45 +--
drivers/sh/intc/chip.c | 4 +-
drivers/tty/serial/sh-sci.c | 3 +-
36 files changed, 210 insertions(+), 176 deletions(-)
rename arch/sh/include/{ = uapi}/asm/auxvec.h (100%)
rename arch/sh/include/{ = uapi}/asm/byteorder.h (100%)
rename arch/sh/include/{ = uapi}/asm/cachectl.h (100%)
rename arch/sh/include/{ = uapi}/asm/cpu-features.h (100%)
create mode 100644 arch/sh/include/uapi/asm/hw_breakpoint.h
rename arch/sh/include/{ = uapi}/asm/ioctls.h (100%)
create mode 100644 arch/sh/include/uapi/asm/posix_types.h
rename arch/sh/include/{ = uapi}/asm/posix_types_32.h (100%)
rename arch/sh/include/{ = uapi}/asm/posix_types_64.h (100%)
create mode 100644 arch/sh/include/uapi/asm/ptrace.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_32.h
create mode 100644 arch/sh/include/uapi/asm/ptrace_64.h
create mode 100644 arch/sh/include/uapi/asm/setup.h
rename arch/sh/include/{ = uapi}/asm/sigcontext.h (100%)
rename arch/sh/include/{ = uapi}/asm/signal.h (100%)
rename arch/sh/include/{ = uapi}/asm/sockios.h (100%)
rename arch/sh/include/{ = uapi}/asm/stat.h (100%)
rename arch/sh/include/{ = uapi}/asm/swab.h (100%)
create mode 100644 arch/sh/include/uapi/asm/types.h
create mode 100644 arch/sh/include/uapi/asm/unistd.h
rename arch/sh/include/{ = uapi}/asm/unistd_32.h (99%)
rename arch/sh/include/{ = uapi}/asm/unistd_64.h (99%)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for sh [ver #2]
On Tue, Oct 09, 2012 at 10:15:57AM +0100, David Howells wrote: > Can you merge the following branch into the sh tree please. > > This is to complete part of the UAPI disintegration for which the preparatory > patches were pulled recently. > > Now that the fixups and the asm-generic chunk have been merged, I've > regenerated the patches to get rid of those dependencies and to take account > of > any changes made so far in the merge window. If you have already pulled the > older version of the branch aimed at you, then please feel free to ignore this > request. > > The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: > > Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) > > are available in the git repository at: > > > git://git.infradead.org/users/dhowells/linux-headers.git > tags/disintegrate-sh-20121009 > Pulled, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Disintegrate UAPI for sh [ver #2]
On Tue, Oct 09, 2012 at 10:15:57AM +0100, David Howells wrote: Can you merge the following branch into the sh tree please. This is to complete part of the UAPI disintegration for which the preparatory patches were pulled recently. Now that the fixups and the asm-generic chunk have been merged, I've regenerated the patches to get rid of those dependencies and to take account of any changes made so far in the merge window. If you have already pulled the older version of the branch aimed at you, then please feel free to ignore this request. The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) are available in the git repository at: git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-sh-20121009 Pulled, thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] irqdomain: augment add_simple() to allocate descs
On Thu, Sep 27, 2012 at 03:13:45PM +0200, Linus Walleij wrote:
> + if (first_irq > 0) {
> + int irq_base;
> +
> + irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());
> + if (irq_base < 0) {
> + WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming
> pre-allocated\n",
> + first_irq);
> + irq_base = first_irq;
> + }
> + return irq_domain_add_legacy(of_node, size, irq_base, 0,
>ops, host_data);
If first_irq is specified you presumably want irq_alloc_desc_at()
behaviour, so you should use irq_alloc_descs(first_irq, first_irq, ...),
similar to what irq_create_strict_mappings() does.
Also don't use numa_node_id() for this, of_node_to_nid() handles both the
OF and non-OF cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] irqdomain: augment add_simple() to allocate descs
On Thu, Sep 27, 2012 at 03:13:45PM +0200, Linus Walleij wrote:
+ if (first_irq 0) {
+ int irq_base;
+
+ irq_base = irq_alloc_descs(first_irq, 0, size, numa_node_id());
+ if (irq_base 0) {
+ WARN(1, Cannot allocate irq_descs @ IRQ%d, assuming
pre-allocated\n,
+ first_irq);
+ irq_base = first_irq;
+ }
+ return irq_domain_add_legacy(of_node, size, irq_base, 0,
ops, host_data);
If first_irq is specified you presumably want irq_alloc_desc_at()
behaviour, so you should use irq_alloc_descs(first_irq, first_irq, ...),
similar to what irq_create_strict_mappings() does.
Also don't use numa_node_id() for this, of_node_to_nid() handles both the
OF and non-OF cases.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.6-final
One last minute regression fix.. The following changes since commit 56d27adcb536b7430d5f8a6240df8ad261eb00bd: Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2012-09-24 16:17:17 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 16d74ebeb1b056dfc80e69b44cc3a26515db1925: sh: pfc: Fix up GPIO mux type reconfig case. (2012-09-25 11:51:05 +0900) SuperH fixes for 3.6-final Paul Mundt (1): sh: pfc: Fix up GPIO mux type reconfig case. drivers/sh/pfc/pinctrl.c | 2 ++ 1 file changed, 2 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.6-final
One last minute regression fix.. The following changes since commit 56d27adcb536b7430d5f8a6240df8ad261eb00bd: Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2012-09-24 16:17:17 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 16d74ebeb1b056dfc80e69b44cc3a26515db1925: sh: pfc: Fix up GPIO mux type reconfig case. (2012-09-25 11:51:05 +0900) SuperH fixes for 3.6-final Paul Mundt (1): sh: pfc: Fix up GPIO mux type reconfig case. drivers/sh/pfc/pinctrl.c | 2 ++ 1 file changed, 2 insertions(+) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.6-rc7
The following changes since commit 6dab7ede9390d4d937cb89feca932e4fd575d2da: Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm (2012-08-18 16:20:05 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 5e071e2b4b82599f07cce5e1d2d272feb462950c: sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING handling. (2012-09-18 17:04:37 +0900) SuperH fixes for 3.6-rc7 Al Viro (1): sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING handling. Laurent Pinchart (1): sh: pfc: Release spinlock in sh_pfc_gpio_request_enable() error path Paul Mundt (1): sh: intc: Fix up multi-evt irq association. arch/sh/kernel/cpu/sh5/entry.S | 2 +- arch/sh/kernel/entry-common.S | 2 +- drivers/sh/intc/core.c | 2 +- drivers/sh/pfc/pinctrl.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/24] ARM: shmobile: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:29PM +0200, Arnd Bergmann wrote:
> ARM is moving to stricter checks on readl/write functions,
> so we need to use the correct types everywhere.
>
> This patch is a bit ugly for shmobile, which is the only platform
> that just uses integer literals all over the place, but I can't
> see a better way to do this.
>
If you want to crap up the ARM side with this stuff, that's fine, but
leave sh-sci out of it.
So, NAK on this part:
> diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
> index eb763ad..d323290 100644
> --- a/include/linux/serial_sci.h
> +++ b/include/linux/serial_sci.h
> @@ -150,7 +150,7 @@ struct plat_sci_port {
> int overrun_bit;
> unsigned interror_mask;
>
> - int port_reg;
> + void __iomem *port_reg;
> unsigned char regshift;
> unsigned char regtype;
>
but I don't mind if you cast the callsite in drivers/tty/serial/sh-sci.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/24] sh: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:47PM +0200, Arnd Bergmann wrote: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > I'm not completely sure about this patch, and it will > probably require some arch/sh changes to go along with it, > but it's clear that something has to be done to avoid > getting hundreds of new warnings on each shmobile build > in v3.7. > Please see this as a prototype. > I have no intention of making this change for arch/sh. The __raw variants already accept both __iomem pointers and integer addresses, which was largely intentional. New code could use the __iomem annotations while older code could continue to use the integer addresses without issue. If you wish to go through the kernel and audit every single __raw user, you're certainly welcome to, but until then such a change is premature. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 19/24] sh: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:47PM +0200, Arnd Bergmann wrote: ARM is moving to stricter checks on readl/write functions, so we need to use the correct types everywhere. I'm not completely sure about this patch, and it will probably require some arch/sh changes to go along with it, but it's clear that something has to be done to avoid getting hundreds of new warnings on each shmobile build in v3.7. Please see this as a prototype. I have no intention of making this change for arch/sh. The __raw variants already accept both __iomem pointers and integer addresses, which was largely intentional. New code could use the __iomem annotations while older code could continue to use the integer addresses without issue. If you wish to go through the kernel and audit every single __raw user, you're certainly welcome to, but until then such a change is premature. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/24] ARM: shmobile: use __iomem pointers for MMIO
On Fri, Sep 14, 2012 at 11:34:29PM +0200, Arnd Bergmann wrote:
ARM is moving to stricter checks on readl/write functions,
so we need to use the correct types everywhere.
This patch is a bit ugly for shmobile, which is the only platform
that just uses integer literals all over the place, but I can't
see a better way to do this.
If you want to crap up the ARM side with this stuff, that's fine, but
leave sh-sci out of it.
So, NAK on this part:
diff --git a/include/linux/serial_sci.h b/include/linux/serial_sci.h
index eb763ad..d323290 100644
--- a/include/linux/serial_sci.h
+++ b/include/linux/serial_sci.h
@@ -150,7 +150,7 @@ struct plat_sci_port {
int overrun_bit;
unsigned interror_mask;
- int port_reg;
+ void __iomem *port_reg;
unsigned char regshift;
unsigned char regtype;
but I don't mind if you cast the callsite in drivers/tty/serial/sh-sci.c
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.6-rc7
The following changes since commit 6dab7ede9390d4d937cb89feca932e4fd575d2da: Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm (2012-08-18 16:20:05 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 5e071e2b4b82599f07cce5e1d2d272feb462950c: sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING handling. (2012-09-18 17:04:37 +0900) SuperH fixes for 3.6-rc7 Al Viro (1): sh: Fix up TIF_NOTIFY_RESUME sans TIF_SIGPENDING handling. Laurent Pinchart (1): sh: pfc: Release spinlock in sh_pfc_gpio_request_enable() error path Paul Mundt (1): sh: intc: Fix up multi-evt irq association. arch/sh/kernel/cpu/sh5/entry.S | 2 +- arch/sh/kernel/entry-common.S | 2 +- drivers/sh/intc/core.c | 2 +- drivers/sh/pfc/pinctrl.c | 3 ++- 4 files changed, 5 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can not get output of command line on SH
On Mon, Sep 03, 2012 at 11:56:59AM +0900, Nobuhiro Iwamatsu wrote: > On Fri, Aug 31, 2012 at 10:10 PM, Al Viro wrote: > > Smells like broken TIF_NOTIFY_RESUME hookup on sh... Arrrgh. Looks like > > while it is in the relevant masks *and* checked in do_notify_resume() both > > on 32bit and 64bit variants since commit > > ab99c733ae73cce31f2a2434f7099564e5a73d95 > > Author: Paul Mundt > > Date: Wed Jul 30 19:55:30 2008 +0900 > > > > sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME. > > > > they are actually *not* reached without simulataneous SIGPENDING, since the > > actual glue in the callers had not been updated back then and still checks > > for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume() > > or not. Looks like the following ought to fix that: > > Thanks for your reply and explanation. > I confirmed that revise this problem with your patch. > > > > > Signed-off-by: Al Viro > Tested-by: Nobuhiro Iwamatsu > I'll queue it up, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can not get output of command line on SH
On Mon, Sep 03, 2012 at 11:56:59AM +0900, Nobuhiro Iwamatsu wrote: On Fri, Aug 31, 2012 at 10:10 PM, Al Viro v...@zeniv.linux.org.uk wrote: Smells like broken TIF_NOTIFY_RESUME hookup on sh... Arrrgh. Looks like while it is in the relevant masks *and* checked in do_notify_resume() both on 32bit and 64bit variants since commit ab99c733ae73cce31f2a2434f7099564e5a73d95 Author: Paul Mundt let...@linux-sh.org Date: Wed Jul 30 19:55:30 2008 +0900 sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME. they are actually *not* reached without simulataneous SIGPENDING, since the actual glue in the callers had not been updated back then and still checks for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume() or not. Looks like the following ought to fix that: Thanks for your reply and explanation. I confirmed that revise this problem with your patch. Signed-off-by: Al Viro v...@zeniv.linux.org.uk Tested-by: Nobuhiro Iwamatsu nobuhiro.iwamatsu...@renesas.com I'll queue it up, thanks! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Wed, Aug 08, 2012 at 11:23:04AM +0200, Rafael J. Wysocki wrote: > On Tuesday, August 07, 2012, Paul Mundt wrote: > > On Sun, Aug 05, 2012 at 12:02:43AM +0200, Rafael J. Wysocki wrote: > > > On Wednesday, August 01, 2012, Paul Mundt wrote: > > > > Turns out we can just collapse the probe/init stuff anyways, so this > > > > ought to fix it. I've verified that it fixes Morimoto-san's issue, my > > > > expectation is that the mackerel case is likewise getting tripped up but > > > > no one bothered implementing any error detecting logic for > > > > gpio_request() > > > > failing, so it doesn't fail gracefully. > > > > > > > > I'll be pushing this out to Linus shortly: > > > > > > Thanks, this helped. Resume works correctly on Mackerel with 3.6-rc1. > > > > > > However, I'm now seeing a different problem related to system suspend on > > > that, > > > board which is that sh7372_enter_a3sm_common() returns immediately, as > > > though > > > at least one of the wakeup signals was permanently asserted. This hadn't > > > happened before your last pull request was merged, so I suspect that one > > > of the irqdomain patches might introduce this behavior. > > > > > Ok, I'll back off the irqdomain selection until we have a chance to test > > it more on the other platforms. > > If you mean removing the select from drivers/sh/intc/Kconfig, that alone > doesn't > help. Reverting commit 1d6a21b0a672fb29b01ccf397d478e0541e17716 > (sh: intc: initial irqdomain support.) helps, though. > Yeah, I see what happened now. I inadvertently trampled the -EEXIST behaviour. I've taken care of it now, so hopefully you'll have better luck with -rc2! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc2
The following changes since commit f4ba394c1b02e7fc2179fda8d3941a5b3b65efb6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-08-08 20:06:43 +0300) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to fa75ce649ee2600b117631f8794e0e7dbedb1d68: Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest (2012-08-09 13:21:13 +0900) SuperH fixes for 3.6-rc2 Mike Frysinger (1): sh: dma: fix request_irq usage Paul Mundt (2): sh: intc: Handle domain association for sparseirq pre-allocated vectors. Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest Phil Edworthy (1): sh: sh7269: Fix LCD pinmux arch/sh/drivers/dma/dma-sh.c| 2 +- arch/sh/include/cpu-sh2a/cpu/sh7269.h | 36 -- arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 195 +++- drivers/sh/intc/core.c | 27 - 4 files changed, 165 insertions(+), 95 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc2
The following changes since commit f4ba394c1b02e7fc2179fda8d3941a5b3b65efb6: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2012-08-08 20:06:43 +0300) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to fa75ce649ee2600b117631f8794e0e7dbedb1d68: Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest (2012-08-09 13:21:13 +0900) SuperH fixes for 3.6-rc2 Mike Frysinger (1): sh: dma: fix request_irq usage Paul Mundt (2): sh: intc: Handle domain association for sparseirq pre-allocated vectors. Merge branches 'sh/urgent' and 'sh/gpiolib' into sh-latest Phil Edworthy (1): sh: sh7269: Fix LCD pinmux arch/sh/drivers/dma/dma-sh.c| 2 +- arch/sh/include/cpu-sh2a/cpu/sh7269.h | 36 -- arch/sh/kernel/cpu/sh2a/pinmux-sh7269.c | 195 +++- drivers/sh/intc/core.c | 27 - 4 files changed, 165 insertions(+), 95 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Wed, Aug 08, 2012 at 11:23:04AM +0200, Rafael J. Wysocki wrote: On Tuesday, August 07, 2012, Paul Mundt wrote: On Sun, Aug 05, 2012 at 12:02:43AM +0200, Rafael J. Wysocki wrote: On Wednesday, August 01, 2012, Paul Mundt wrote: Turns out we can just collapse the probe/init stuff anyways, so this ought to fix it. I've verified that it fixes Morimoto-san's issue, my expectation is that the mackerel case is likewise getting tripped up but no one bothered implementing any error detecting logic for gpio_request() failing, so it doesn't fail gracefully. I'll be pushing this out to Linus shortly: Thanks, this helped. Resume works correctly on Mackerel with 3.6-rc1. However, I'm now seeing a different problem related to system suspend on that, board which is that sh7372_enter_a3sm_common() returns immediately, as though at least one of the wakeup signals was permanently asserted. This hadn't happened before your last pull request was merged, so I suspect that one of the irqdomain patches might introduce this behavior. Ok, I'll back off the irqdomain selection until we have a chance to test it more on the other platforms. If you mean removing the select from drivers/sh/intc/Kconfig, that alone doesn't help. Reverting commit 1d6a21b0a672fb29b01ccf397d478e0541e17716 (sh: intc: initial irqdomain support.) helps, though. Yeah, I see what happened now. I inadvertently trampled the -EEXIST behaviour. I've taken care of it now, so hopefully you'll have better luck with -rc2! -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sun, Aug 05, 2012 at 12:02:43AM +0200, Rafael J. Wysocki wrote: > On Wednesday, August 01, 2012, Paul Mundt wrote: > > Turns out we can just collapse the probe/init stuff anyways, so this > > ought to fix it. I've verified that it fixes Morimoto-san's issue, my > > expectation is that the mackerel case is likewise getting tripped up but > > no one bothered implementing any error detecting logic for gpio_request() > > failing, so it doesn't fail gracefully. > > > > I'll be pushing this out to Linus shortly: > > Thanks, this helped. Resume works correctly on Mackerel with 3.6-rc1. > > However, I'm now seeing a different problem related to system suspend on that, > board which is that sh7372_enter_a3sm_common() returns immediately, as though > at least one of the wakeup signals was permanently asserted. This hadn't > happened before your last pull request was merged, so I suspect that one > of the irqdomain patches might introduce this behavior. > Ok, I'll back off the irqdomain selection until we have a chance to test it more on the other platforms. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sun, Aug 05, 2012 at 12:02:43AM +0200, Rafael J. Wysocki wrote: On Wednesday, August 01, 2012, Paul Mundt wrote: Turns out we can just collapse the probe/init stuff anyways, so this ought to fix it. I've verified that it fixes Morimoto-san's issue, my expectation is that the mackerel case is likewise getting tripped up but no one bothered implementing any error detecting logic for gpio_request() failing, so it doesn't fail gracefully. I'll be pushing this out to Linus shortly: Thanks, this helped. Resume works correctly on Mackerel with 3.6-rc1. However, I'm now seeing a different problem related to system suspend on that, board which is that sh7372_enter_a3sm_common() returns immediately, as though at least one of the wakeup signals was permanently asserted. This hadn't happened before your last pull request was merged, so I suspect that one of the irqdomain patches might introduce this behavior. Ok, I'll back off the irqdomain selection until we have a chance to test it more on the other platforms. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc1, round 2.
The following changes since commit 2d534926205db9ffce4bbbde67cb9b2cee4b835c: Merge tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux-2.6 (2012-07-31 20:44:03 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 08298f0612e5e369d1da89b92cac5d2c71ddb9af: sh: explicitly include sh_dma.h in setup-sh7722.c (2012-08-02 15:37:26 +0900) SuperH fixes for 3.6-rc1 merge window Guennadi Liakhovetski (17): sh: add fixed voltage regulators to apsh4a3a sh: add fixed voltage regulators to apsh4ad0a sh: add fixed voltage regulators to magicpanelr2 sh: add fixed voltage regulators to polaris sh: add fixed voltage regulators to sh2007 sh: add fixed voltage regulators to sh7757lcr sh: add fixed voltage regulators to ap325rxa sh: add fixed voltage regulators to kfr2r09 sh: add fixed voltage regulators to migor sh: add fixed voltage regulators to rsk sh: add fixed voltage regulators to sdk7786 sh: add fixed voltage regulators to se7724 sh: ecovec: switch MMC power control to regulators sh: select the fixed regulator driver on several boards dmaengine: shdma: restore partial transfer calculation serial: sh-sci: fix compilation breakage, when DMA is enabled sh: explicitly include sh_dma.h in setup-sh7722.c Kuninori Morimoto (2): sh: sh7724: fixup renesas_usbhs clock settings sh: ecovec: care CN5 VBUS if USB host mode Paul Mundt (8): sh: pfc: Build fix for pinctrl_remove_gpio_range() changes. sh: Fix up recursive fault in oops with unset TTB. Merge branches 'sh/urgent' and 'sh/regulator' into sh-latest Merge branch 'sh/dmaengine' into sh-latest sh: pfc: Fix up init ordering mess. Merge branch 'common/pinctrl' into sh-latest sh: intc: initial irqdomain support. Merge branch 'common/irqdomain' into sh-latest Shimoda, Yoshihiro (1): sh: modify the sh_dmae_slave_config for RSPI in setup-sh7757 arch/sh/boards/Kconfig | 13 arch/sh/boards/board-apsh4a3a.c| 10 +++ arch/sh/boards/board-apsh4ad0a.c | 10 +++ arch/sh/boards/board-magicpanelr2.c| 10 +++ arch/sh/boards/board-polaris.c | 10 +++ arch/sh/boards/board-sh2007.c | 12 arch/sh/boards/board-sh7757lcr.c | 14 arch/sh/boards/mach-ap325rxa/setup.c | 21 ++ arch/sh/boards/mach-ecovec24/setup.c | 125 - arch/sh/boards/mach-kfr2r09/setup.c| 12 arch/sh/boards/mach-migor/setup.c | 13 arch/sh/boards/mach-rsk/setup.c| 10 +++ arch/sh/boards/mach-sdk7786/setup.c| 10 +++ arch/sh/boards/mach-se/7724/setup.c| 15 arch/sh/include/cpu-sh4/cpu/sh7757.h | 2 + arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 4 +- arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 1 + arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 14 arch/sh/mm/fault.c | 8 ++- drivers/dma/sh/shdma-base.c| 9 +++ drivers/dma/sh/shdma.c | 12 drivers/sh/intc/Kconfig| 4 ++ drivers/sh/intc/Makefile | 2 +- drivers/sh/intc/core.c | 11 +-- drivers/sh/intc/internals.h| 5 ++ drivers/sh/intc/irqdomain.c| 68 ++ drivers/sh/pfc/pinctrl.c | 34 - drivers/tty/serial/sh-sci.c| 5 +- include/linux/shdma-base.h | 2 + 29 files changed, 419 insertions(+), 47 deletions(-) create mode 100644 drivers/sh/intc/irqdomain.c -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc1, round 2.
The following changes since commit 2d534926205db9ffce4bbbde67cb9b2cee4b835c: Merge tag 'irqdomain-for-linus' of git://git.secretlab.ca/git/linux-2.6 (2012-07-31 20:44:03 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 08298f0612e5e369d1da89b92cac5d2c71ddb9af: sh: explicitly include sh_dma.h in setup-sh7722.c (2012-08-02 15:37:26 +0900) SuperH fixes for 3.6-rc1 merge window Guennadi Liakhovetski (17): sh: add fixed voltage regulators to apsh4a3a sh: add fixed voltage regulators to apsh4ad0a sh: add fixed voltage regulators to magicpanelr2 sh: add fixed voltage regulators to polaris sh: add fixed voltage regulators to sh2007 sh: add fixed voltage regulators to sh7757lcr sh: add fixed voltage regulators to ap325rxa sh: add fixed voltage regulators to kfr2r09 sh: add fixed voltage regulators to migor sh: add fixed voltage regulators to rsk sh: add fixed voltage regulators to sdk7786 sh: add fixed voltage regulators to se7724 sh: ecovec: switch MMC power control to regulators sh: select the fixed regulator driver on several boards dmaengine: shdma: restore partial transfer calculation serial: sh-sci: fix compilation breakage, when DMA is enabled sh: explicitly include sh_dma.h in setup-sh7722.c Kuninori Morimoto (2): sh: sh7724: fixup renesas_usbhs clock settings sh: ecovec: care CN5 VBUS if USB host mode Paul Mundt (8): sh: pfc: Build fix for pinctrl_remove_gpio_range() changes. sh: Fix up recursive fault in oops with unset TTB. Merge branches 'sh/urgent' and 'sh/regulator' into sh-latest Merge branch 'sh/dmaengine' into sh-latest sh: pfc: Fix up init ordering mess. Merge branch 'common/pinctrl' into sh-latest sh: intc: initial irqdomain support. Merge branch 'common/irqdomain' into sh-latest Shimoda, Yoshihiro (1): sh: modify the sh_dmae_slave_config for RSPI in setup-sh7757 arch/sh/boards/Kconfig | 13 arch/sh/boards/board-apsh4a3a.c| 10 +++ arch/sh/boards/board-apsh4ad0a.c | 10 +++ arch/sh/boards/board-magicpanelr2.c| 10 +++ arch/sh/boards/board-polaris.c | 10 +++ arch/sh/boards/board-sh2007.c | 12 arch/sh/boards/board-sh7757lcr.c | 14 arch/sh/boards/mach-ap325rxa/setup.c | 21 ++ arch/sh/boards/mach-ecovec24/setup.c | 125 - arch/sh/boards/mach-kfr2r09/setup.c| 12 arch/sh/boards/mach-migor/setup.c | 13 arch/sh/boards/mach-rsk/setup.c| 10 +++ arch/sh/boards/mach-sdk7786/setup.c| 10 +++ arch/sh/boards/mach-se/7724/setup.c| 15 arch/sh/include/cpu-sh4/cpu/sh7757.h | 2 + arch/sh/kernel/cpu/sh4a/clock-sh7724.c | 4 +- arch/sh/kernel/cpu/sh4a/setup-sh7722.c | 1 + arch/sh/kernel/cpu/sh4a/setup-sh7757.c | 14 arch/sh/mm/fault.c | 8 ++- drivers/dma/sh/shdma-base.c| 9 +++ drivers/dma/sh/shdma.c | 12 drivers/sh/intc/Kconfig| 4 ++ drivers/sh/intc/Makefile | 2 +- drivers/sh/intc/core.c | 11 +-- drivers/sh/intc/internals.h| 5 ++ drivers/sh/intc/irqdomain.c| 68 ++ drivers/sh/pfc/pinctrl.c | 34 - drivers/tty/serial/sh-sci.c| 5 +- include/linux/shdma-base.h | 2 + 29 files changed, 419 insertions(+), 47 deletions(-) create mode 100644 drivers/sh/intc/irqdomain.c -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] irqdomain changes for v3.6
On Tue, Jul 31, 2012 at 09:41:03PM -0600, Grant Likely wrote: > Grant Likely (11): > irqdomain: Support for static IRQ mapping and association. .. Looks like author attribution for this one got mangled. Oh well, at least it's upstream now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sat, Jul 28, 2012 at 12:53:11AM +0200, Rafael J. Wysocki wrote:
> Unfortunately, your commit
>
> commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73
> Author: Paul Mundt
> Date: Tue Jul 10 12:08:14 2012 +0900
>
> sh: pfc: Rudimentary pinctrl-backed GPIO support.
>
> breaks system suspend on the Mackerel board (.config attached). The system
> simply doesn't suspend and instead it hangs somewhere while suspending
> devices (apparently before running the "late" callbacks).
>
> If the above commit is reverted, system suspend works normally.
On Tue, Jul 31, 2012 at 08:57:02PM -0700, kuninori.morimoto...@renesas.com
wrote:
> gpio: sh7724_pfc handling gpio 0 -> 486
> core: sh7724_pfc support registered
> HW Breakpoints: SH-4A UBC support registered
> autorequest GPIO-53
> [ cut here ]
> WARNING: at
> /opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/drivers/gpio/gpiolib.3
> Modules linked in:
>
> Pid : 1, Comm: swapper
> CPU : 0 Not tainted (3.5.0-rc6+ #1407)
>
> PC is at gpio_ensure_requested+0x30/0x78
> PR is at gpio_ensure_requested+0x30/0x78
Morimoto-san's logs off-list made it clear what happened. Both of these
platforms are going gpio_request() calls at arch_initcall() time which
completely screwed up the ordering of the pfc core. We seem to -ENODEV
out in one place due to missing a pfc pointer initialization elsewhere
resulting in -EPROBE_DEFER from gpiolib.
Turns out we can just collapse the probe/init stuff anyways, so this
ought to fix it. I've verified that it fixes Morimoto-san's issue, my
expectation is that the mackerel case is likewise getting tripped up but
no one bothered implementing any error detecting logic for gpio_request()
failing, so it doesn't fail gracefully.
I'll be pushing this out to Linus shortly:
---
commit 1e32dfe323d156d5d7b25b9feffe015d19713db2
Author: Paul Mundt
Date: Wed Aug 1 16:27:38 2012 +0900
sh: pfc: Fix up init ordering mess.
Commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73 ("sh: pfc: Rudimentary
pinctrl-backed GPIO support.") introduced a regression for platforms that
were doing early GPIO API calls (from arch_initcall() or earlier),
leading to a situation where our two-stage registration logic would trip
itself up and we'd -ENODEV out of the pinctrl registration path,
resulting in endless -EPROBE_DEFER errors. Further lack of checking any
sort of errors from gpio_request() resulted in boot time warnings,
tripping on the FLAG_REQUESTED test-and-set in gpio_ensure_requested().
As it turns out there's no particular need to bother with the two-stage
registration, as the platform bus is already available at the point that
we have to start caring. As such, it's easiest to simply fold these
together in to a single init path, the ordering of which is ensured
through the platform's mux registration, as usual.
Reported-by: Rafael J. Wysocki
Reported-by: Kuninori Morimoto
Signed-off-by: Paul Mundt
diff --git a/drivers/sh/pfc/pinctrl.c b/drivers/sh/pfc/pinctrl.c
index 814b292..2804eaa 100644
--- a/drivers/sh/pfc/pinctrl.c
+++ b/drivers/sh/pfc/pinctrl.c
@@ -325,20 +325,6 @@ static struct pinctrl_desc sh_pfc_pinctrl_desc = {
.confops= _pfc_pinconf_ops,
};
-int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
-{
- sh_pfc_pmx = kzalloc(sizeof(struct sh_pfc_pinctrl), GFP_KERNEL);
- if (unlikely(!sh_pfc_pmx))
- return -ENOMEM;
-
- spin_lock_init(_pfc_pmx->lock);
-
- sh_pfc_pmx->pfc = pfc;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(sh_pfc_register_pinctrl);
-
static inline void __devinit sh_pfc_map_one_gpio(struct sh_pfc *pfc,
struct sh_pfc_pinctrl *pmx,
struct pinmux_gpio *gpio,
@@ -505,7 +491,7 @@ static struct platform_device sh_pfc_pinctrl_device = {
.id = -1,
};
-static int __init sh_pfc_pinctrl_init(void)
+static int sh_pfc_pinctrl_init(void)
{
int rc;
@@ -519,10 +505,22 @@ static int __init sh_pfc_pinctrl_init(void)
return rc;
}
+int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
+{
+ sh_pfc_pmx = kzalloc(sizeof(struct sh_pfc_pinctrl), GFP_KERNEL);
+ if (unlikely(!sh_pfc_pmx))
+ return -ENOMEM;
+
+ spin_lock_init(_pfc_pmx->lock);
+
+ sh_pfc_pmx->pfc = pfc;
+
+ return sh_pfc_pinctrl_init();
+}
+EXPORT_SYMBOL_GPL(sh_pfc_register_pinctrl);
+
static void __exit sh_pfc_pinctrl_exit(void)
{
platform_driver_unregister(_pfc_pinctrl_driver);
}
-
-subsys_initcall(sh_pfc_pinctrl_init);
module_exit(sh_pfc_pinctrl_exit);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sat, Jul 28, 2012 at 12:53:11AM +0200, Rafael J. Wysocki wrote:
Unfortunately, your commit
commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73
Author: Paul Mundt let...@linux-sh.org
Date: Tue Jul 10 12:08:14 2012 +0900
sh: pfc: Rudimentary pinctrl-backed GPIO support.
breaks system suspend on the Mackerel board (.config attached). The system
simply doesn't suspend and instead it hangs somewhere while suspending
devices (apparently before running the late callbacks).
If the above commit is reverted, system suspend works normally.
On Tue, Jul 31, 2012 at 08:57:02PM -0700, kuninori.morimoto...@renesas.com
wrote:
gpio: sh7724_pfc handling gpio 0 - 486
core: sh7724_pfc support registered
HW Breakpoints: SH-4A UBC support registered
autorequest GPIO-53
[ cut here ]
WARNING: at
/opt/usr/src/WORK/morimoto/gitlinux/linux-2.6/drivers/gpio/gpiolib.3
Modules linked in:
Pid : 1, Comm: swapper
CPU : 0 Not tainted (3.5.0-rc6+ #1407)
PC is at gpio_ensure_requested+0x30/0x78
PR is at gpio_ensure_requested+0x30/0x78
Morimoto-san's logs off-list made it clear what happened. Both of these
platforms are going gpio_request() calls at arch_initcall() time which
completely screwed up the ordering of the pfc core. We seem to -ENODEV
out in one place due to missing a pfc pointer initialization elsewhere
resulting in -EPROBE_DEFER from gpiolib.
Turns out we can just collapse the probe/init stuff anyways, so this
ought to fix it. I've verified that it fixes Morimoto-san's issue, my
expectation is that the mackerel case is likewise getting tripped up but
no one bothered implementing any error detecting logic for gpio_request()
failing, so it doesn't fail gracefully.
I'll be pushing this out to Linus shortly:
---
commit 1e32dfe323d156d5d7b25b9feffe015d19713db2
Author: Paul Mundt let...@linux-sh.org
Date: Wed Aug 1 16:27:38 2012 +0900
sh: pfc: Fix up init ordering mess.
Commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73 (sh: pfc: Rudimentary
pinctrl-backed GPIO support.) introduced a regression for platforms that
were doing early GPIO API calls (from arch_initcall() or earlier),
leading to a situation where our two-stage registration logic would trip
itself up and we'd -ENODEV out of the pinctrl registration path,
resulting in endless -EPROBE_DEFER errors. Further lack of checking any
sort of errors from gpio_request() resulted in boot time warnings,
tripping on the FLAG_REQUESTED test-and-set in gpio_ensure_requested().
As it turns out there's no particular need to bother with the two-stage
registration, as the platform bus is already available at the point that
we have to start caring. As such, it's easiest to simply fold these
together in to a single init path, the ordering of which is ensured
through the platform's mux registration, as usual.
Reported-by: Rafael J. Wysocki r...@sisk.pl
Reported-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
Signed-off-by: Paul Mundt let...@linux-sh.org
diff --git a/drivers/sh/pfc/pinctrl.c b/drivers/sh/pfc/pinctrl.c
index 814b292..2804eaa 100644
--- a/drivers/sh/pfc/pinctrl.c
+++ b/drivers/sh/pfc/pinctrl.c
@@ -325,20 +325,6 @@ static struct pinctrl_desc sh_pfc_pinctrl_desc = {
.confops= sh_pfc_pinconf_ops,
};
-int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
-{
- sh_pfc_pmx = kzalloc(sizeof(struct sh_pfc_pinctrl), GFP_KERNEL);
- if (unlikely(!sh_pfc_pmx))
- return -ENOMEM;
-
- spin_lock_init(sh_pfc_pmx-lock);
-
- sh_pfc_pmx-pfc = pfc;
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(sh_pfc_register_pinctrl);
-
static inline void __devinit sh_pfc_map_one_gpio(struct sh_pfc *pfc,
struct sh_pfc_pinctrl *pmx,
struct pinmux_gpio *gpio,
@@ -505,7 +491,7 @@ static struct platform_device sh_pfc_pinctrl_device = {
.id = -1,
};
-static int __init sh_pfc_pinctrl_init(void)
+static int sh_pfc_pinctrl_init(void)
{
int rc;
@@ -519,10 +505,22 @@ static int __init sh_pfc_pinctrl_init(void)
return rc;
}
+int sh_pfc_register_pinctrl(struct sh_pfc *pfc)
+{
+ sh_pfc_pmx = kzalloc(sizeof(struct sh_pfc_pinctrl), GFP_KERNEL);
+ if (unlikely(!sh_pfc_pmx))
+ return -ENOMEM;
+
+ spin_lock_init(sh_pfc_pmx-lock);
+
+ sh_pfc_pmx-pfc = pfc;
+
+ return sh_pfc_pinctrl_init();
+}
+EXPORT_SYMBOL_GPL(sh_pfc_register_pinctrl);
+
static void __exit sh_pfc_pinctrl_exit(void)
{
platform_driver_unregister(sh_pfc_pinctrl_driver);
}
-
-subsys_initcall(sh_pfc_pinctrl_init);
module_exit(sh_pfc_pinctrl_exit);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Re: [GIT PULL] irqdomain changes for v3.6
On Tue, Jul 31, 2012 at 09:41:03PM -0600, Grant Likely wrote: Grant Likely (11): irqdomain: Support for static IRQ mapping and association. .. Looks like author attribution for this one got mangled. Oh well, at least it's upstream now. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] serial: sh-sci: fix compilation breakage (3.6)
On Mon, Jul 30, 2012 at 09:28:18PM +0200, Guennadi Liakhovetski wrote: > Hi all > > as has been reported in this > > http://thread.gmane.org/gmane.linux.kernel/1294256/focus=16001 > > thread, currently sh-sci doesn't comiple in the mainline and in -next if > CONFIG_SERIAL_SH_SCI_DMA is enabled. This patch series fixes this > breakage. > Looks alright to me. Vinod, how do you want to handle this? I can roll both of these patches in to my tree with your Acked-by, or I can provide you with mine for the sh-sci bits if you want to take it via yours. I'm planning on sending my next round of updates to Linus in the next couple of days. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] serial: sh-sci: fix compilation breakage (3.6)
On Mon, Jul 30, 2012 at 09:28:18PM +0200, Guennadi Liakhovetski wrote: Hi all as has been reported in this http://thread.gmane.org/gmane.linux.kernel/1294256/focus=16001 thread, currently sh-sci doesn't comiple in the mainline and in -next if CONFIG_SERIAL_SH_SCI_DMA is enabled. This patch series fixes this breakage. Looks alright to me. Vinod, how do you want to handle this? I can roll both of these patches in to my tree with your Acked-by, or I can provide you with mine for the sh-sci bits if you want to take it via yours. I'm planning on sending my next round of updates to Linus in the next couple of days. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sat, Jul 28, 2012 at 12:53:11AM +0200, Rafael J. Wysocki wrote: > Hi Paul, > > Unfortunately, your commit > > commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73 > Author: Paul Mundt > Date: Tue Jul 10 12:08:14 2012 +0900 > > sh: pfc: Rudimentary pinctrl-backed GPIO support. > > breaks system suspend on the Mackerel board (.config attached). The system > simply doesn't suspend and instead it hangs somewhere while suspending > devices (apparently before running the "late" callbacks). > > If the above commit is reverted, system suspend works normally. > Ok, I'll take a look at it on Monday, thanks for reporting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sh: pfc: Fix build issues in pinctrl.c
On Sat, Jul 28, 2012 at 12:07:04AM +0200, Rafael J. Wysocki wrote: > > First off, drivers/sh/pfc/pinctrl.c doesn't build after commit > 5d589b0 (pinctrl: remove pinctrl_remove_gpio_range), because > sh_pfc_pinctrl_remove() uses the function that has been removed by > that commit. Fix this by removing the pinctrl_remove_gpio_range() > call, which is not necessary any more, from sh_pfc_pinctrl_remove(). > > Second, the compiler complains correctly that there's an unused > local variable in sh_pfc_pinconf_set(). Fix this by removing the > definition of that variable. > > Signed-off-by: Rafael J. Wysocki Already fixed in my tree, as pointed out when Iwamatsu-san sent the same patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sh: pfc: Fix build issues in pinctrl.c
On Sat, Jul 28, 2012 at 12:07:04AM +0200, Rafael J. Wysocki wrote: First off, drivers/sh/pfc/pinctrl.c doesn't build after commit 5d589b0 (pinctrl: remove pinctrl_remove_gpio_range), because sh_pfc_pinctrl_remove() uses the function that has been removed by that commit. Fix this by removing the pinctrl_remove_gpio_range() call, which is not necessary any more, from sh_pfc_pinctrl_remove(). Second, the compiler complains correctly that there's an unused local variable in sh_pfc_pinconf_set(). Fix this by removing the definition of that variable. Signed-off-by: Rafael J. Wysocki r...@sisk.pl Already fixed in my tree, as pointed out when Iwamatsu-san sent the same patch. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression, post-3.5] System suspend broken on the Mackerel board
On Sat, Jul 28, 2012 at 12:53:11AM +0200, Rafael J. Wysocki wrote: Hi Paul, Unfortunately, your commit commit ca5481c68e9fbcea62bb3c78ae6cccf99ca8fb73 Author: Paul Mundt let...@linux-sh.org Date: Tue Jul 10 12:08:14 2012 +0900 sh: pfc: Rudimentary pinctrl-backed GPIO support. breaks system suspend on the Mackerel board (.config attached). The system simply doesn't suspend and instead it hangs somewhere while suspending devices (apparently before running the late callbacks). If the above commit is reverted, system suspend works normally. Ok, I'll take a look at it on Monday, thanks for reporting. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Thu, Jul 26, 2012 at 12:19:21PM +0530, Vinod Koul wrote: > On Wed, 2012-07-25 at 12:59 +0900, Paul Mundt wrote: > > On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: > > > The shdma base library has originally been extracted from the shdma > > > driver, > > > which now can be converted to actually use it. > > > > > > Signed-off-by: Guennadi Liakhovetski > > > --- > > > drivers/dma/sh/shdma.c | 1122 > > > > > > drivers/dma/sh/shdma.h | 44 +- > > > include/linux/sh_dma.h | 33 +- > > > 3 files changed, 302 insertions(+), 897 deletions(-) > > > > > Now that this has hit mainline, the sh-sci with DMA enabled build is > > broken: > > > > CC drivers/tty/serial/sh-sci.o > > drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': > > drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to > > incomplete type > > drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in > > declaration of '__mptr' > > drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from > > incompatible pointer type > > drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined type > > 'struct sh_desc' > > drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to > > incomplete type > > drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to > > incomplete type > > drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to > > incomplete type > This was in -next for quite some time :( > It seems we don't have any configs that have this default-enabled under -next, so it wasn't noticed before. Still, as Guennadi wrote this code I'm surprised it was overlooked. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Thu, Jul 26, 2012 at 12:19:21PM +0530, Vinod Koul wrote: On Wed, 2012-07-25 at 12:59 +0900, Paul Mundt wrote: On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: The shdma base library has originally been extracted from the shdma driver, which now can be converted to actually use it. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/dma/sh/shdma.c | 1122 drivers/dma/sh/shdma.h | 44 +- include/linux/sh_dma.h | 33 +- 3 files changed, 302 insertions(+), 897 deletions(-) Now that this has hit mainline, the sh-sci with DMA enabled build is broken: CC drivers/tty/serial/sh-sci.o drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in declaration of '__mptr' drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from incompatible pointer type drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined type 'struct sh_desc' drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to incomplete type This was in -next for quite some time :( It seems we don't have any configs that have this default-enabled under -next, so it wasn't noticed before. Still, as Guennadi wrote this code I'm surprised it was overlooked. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: > The shdma base library has originally been extracted from the shdma driver, > which now can be converted to actually use it. > > Signed-off-by: Guennadi Liakhovetski > --- > drivers/dma/sh/shdma.c | 1122 > > drivers/dma/sh/shdma.h | 44 +- > include/linux/sh_dma.h | 33 +- > 3 files changed, 302 insertions(+), 897 deletions(-) > Now that this has hit mainline, the sh-sci with DMA enabled build is broken: CC drivers/tty/serial/sh-sci.o drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in declaration of '__mptr' drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from incompatible pointer type drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined type 'struct sh_desc' drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to incomplete type -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 9/9 v3] dma: shdma: convert to the shdma base library
On Wed, May 09, 2012 at 05:09:21PM +0200, Guennadi Liakhovetski wrote: The shdma base library has originally been extracted from the shdma driver, which now can be converted to actually use it. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- drivers/dma/sh/shdma.c | 1122 drivers/dma/sh/shdma.h | 44 +- include/linux/sh_dma.h | 33 +- 3 files changed, 302 insertions(+), 897 deletions(-) Now that this has hit mainline, the sh-sci with DMA enabled build is broken: CC drivers/tty/serial/sh-sci.o drivers/tty/serial/sh-sci.c: In function 'work_fn_rx': drivers/tty/serial/sh-sci.c:1413:67: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1413:81: warning: type defaults to 'int' in declaration of '__mptr' drivers/tty/serial/sh-sci.c:1413:90: warning: initialization from incompatible pointer type drivers/tty/serial/sh-sci.c:1413:161: error: invalid use of undefined type 'struct sh_desc' drivers/tty/serial/sh-sci.c:1419:83: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1419:101: error: dereferencing pointer to incomplete type drivers/tty/serial/sh-sci.c:1423:42: error: dereferencing pointer to incomplete type -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh updates for 3.6-rc1
The following changes since commit 2437fccfbfc83bcb868ccc7fdfe2b5310bf07835: Merge tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator (2012-07-09 13:43:02 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 9ff561fdf73493d757bbc74aa58627e1381650fb: Merge branch 'common/pinctrl' into sh-latest (2012-07-20 16:42:59 +0900) SuperH updates for 3.6-rc1 merge window - Migration off of old-style dynamic IRQ API. - irqdomain and generic irq chip propagation. - div4/6 clock consolidation, another step towards co-existing with the common struct clk infrastructure. - Extensive PFC rework - Decoupling GPIO from pin state. - Initial pinctrl support to facilitate incremental migration off of legacy pinmux. - gpiolib support made optional, and made pinctrl-backed. Paul Mundt (45): sh: mach-se: Migrate 7724SE off of deprecated dynamic IRQ API. sh: hd64461: Migrate off of deprecated dynamic IRQ API. sh: dreamcast: Migrate off of deprecated dynamic IRQ API. sh: Kill off now unused arch_probe_nr_irqs(). sh64: Convert to unwinder API. sh64: Ensure KALLSYMS is enabled for unwinder use. sh: mach-x3proto: Migrate to linear irq domain. sh: se722: Move FPGA IRQs to irqdomain and generic irq chip. sh: se7343: Move CPLD IRQs to irqdomain and generic irq chip. sh: intc: Kill off deprecated dynamic IRQ API. sh: clkfwk: Move to common clk_div_table accessors for div4/div6. sh: clkfwk: Introduce a div_mask for variable div types. sh: clkfwk: Use shared sh_clk_div_recalc(). sh: clkfwk: Use shared sh_clk_div_set_rate() sh: clkfwk: Use shared sh_clk_div_enable/disable(). sh: clkfwk: Consolidate div6/div4 clk_ops definitions. sh: clkfwk: Consolidate div clk registration helper. sh: intc: Allocate subgroup virq backing desc directly. Merge branch 'sh/multi-unwinders' into sh-latest Merge branch 'sh/dynamic-irq-cleanup' into sh-latest Merge branch 'sh/genirq' into sh-latest sh64: Use generic unaligned access control/counters. sh64: Kill off old exception debugging helpers. sh: Consolidate die definitions for trap handlers. sh64: Attempt to make reserved insn trap handler resemble C. sh64: Fix up section mismatch warnings. Merge branch 'sh/clkfwk' into sh-latest sh: pfc: Split out gpio chip support. sh: pfc: Make gpio chip support optional where possible. sh: pfc: Kill off unused pinmux bias flags. sh: pfc: Verify pin type encoding size at build time. Merge branch 'common/pfc' into sh-latest sh: pfc: Shuffle PFC support core. Merge branch 'common/pfc' into common/pinctrl sh: pfc: Dumb GPIO stringification. sh: pfc: Rudimentary pinctrl-backed GPIO support. sh: pfc: pinctrl legacy function support. sh: pfc: Make pr_fmt consistent across pfc drivers. sh: pfc: Error out on pinctrl init resolution failure. sh: pfc: Export pinctrl binding init symbol. sh: pfc: Ignore pinmux GPIOs with invalid enum IDs. sh: pfc: pinctrl legacy group support. sh: pfc: Prefer DRV_NAME over KBUILD_MODNAME. sh: pfc: pin config get/set support. Merge branch 'common/pinctrl' into sh-latest arch/sh/Kconfig | 1 + arch/sh/boards/Kconfig| 5 + arch/sh/boards/mach-dreamcast/irq.c | 32 +- arch/sh/boards/mach-se/7343/irq.c | 129 -- arch/sh/boards/mach-se/7343/setup.c | 10 +- arch/sh/boards/mach-se/7722/irq.c | 131 +++--- arch/sh/boards/mach-se/7722/setup.c | 6 +- arch/sh/boards/mach-se/7724/irq.c | 36 +- arch/sh/boards/mach-x3proto/gpio.c| 57 +-- arch/sh/cchips/hd6446x/hd64461.c | 33 +- arch/sh/include/asm/bug.h | 4 + arch/sh/include/asm/kdebug.h | 2 + arch/sh/include/mach-se/mach/se7343.h | 7 +- arch/sh/include/mach-se/mach/se7722.h | 10 +- arch/sh/kernel/cpu/sh5/unwind.c | 63 ++- arch/sh/kernel/dumpstack.c| 58 +++ arch/sh/kernel/irq.c | 10 - arch/sh/kernel/traps.c| 71 arch/sh/kernel/traps_32.c | 121 -- arch/sh/kernel/traps_64.c | 589 +++ arch/sh/lib64/Makefile| 2 +- arch/sh/lib64/dbg.c | 248 arch/sh/mm/tlb-sh5.c | 2 +- drivers/sh/Kconfig| 1 + drivers/sh/Makefile | 3 +- drivers/sh/clk/cpg.c | 333 +++ drivers/sh/intc/Makefile | 2 +- drivers/sh/intc/dynamic.c | 57 --- drivers/sh/intc/virq.c| 4 +- drivers/sh/pfc.c
[GIT PULL] sh updates for 3.6-rc1
The following changes since commit 2437fccfbfc83bcb868ccc7fdfe2b5310bf07835: Merge tag 'regulator-3.5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator (2012-07-09 13:43:02 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh tags/sh-for-linus for you to fetch changes up to 9ff561fdf73493d757bbc74aa58627e1381650fb: Merge branch 'common/pinctrl' into sh-latest (2012-07-20 16:42:59 +0900) SuperH updates for 3.6-rc1 merge window - Migration off of old-style dynamic IRQ API. - irqdomain and generic irq chip propagation. - div4/6 clock consolidation, another step towards co-existing with the common struct clk infrastructure. - Extensive PFC rework - Decoupling GPIO from pin state. - Initial pinctrl support to facilitate incremental migration off of legacy pinmux. - gpiolib support made optional, and made pinctrl-backed. Paul Mundt (45): sh: mach-se: Migrate 7724SE off of deprecated dynamic IRQ API. sh: hd64461: Migrate off of deprecated dynamic IRQ API. sh: dreamcast: Migrate off of deprecated dynamic IRQ API. sh: Kill off now unused arch_probe_nr_irqs(). sh64: Convert to unwinder API. sh64: Ensure KALLSYMS is enabled for unwinder use. sh: mach-x3proto: Migrate to linear irq domain. sh: se722: Move FPGA IRQs to irqdomain and generic irq chip. sh: se7343: Move CPLD IRQs to irqdomain and generic irq chip. sh: intc: Kill off deprecated dynamic IRQ API. sh: clkfwk: Move to common clk_div_table accessors for div4/div6. sh: clkfwk: Introduce a div_mask for variable div types. sh: clkfwk: Use shared sh_clk_div_recalc(). sh: clkfwk: Use shared sh_clk_div_set_rate() sh: clkfwk: Use shared sh_clk_div_enable/disable(). sh: clkfwk: Consolidate div6/div4 clk_ops definitions. sh: clkfwk: Consolidate div clk registration helper. sh: intc: Allocate subgroup virq backing desc directly. Merge branch 'sh/multi-unwinders' into sh-latest Merge branch 'sh/dynamic-irq-cleanup' into sh-latest Merge branch 'sh/genirq' into sh-latest sh64: Use generic unaligned access control/counters. sh64: Kill off old exception debugging helpers. sh: Consolidate die definitions for trap handlers. sh64: Attempt to make reserved insn trap handler resemble C. sh64: Fix up section mismatch warnings. Merge branch 'sh/clkfwk' into sh-latest sh: pfc: Split out gpio chip support. sh: pfc: Make gpio chip support optional where possible. sh: pfc: Kill off unused pinmux bias flags. sh: pfc: Verify pin type encoding size at build time. Merge branch 'common/pfc' into sh-latest sh: pfc: Shuffle PFC support core. Merge branch 'common/pfc' into common/pinctrl sh: pfc: Dumb GPIO stringification. sh: pfc: Rudimentary pinctrl-backed GPIO support. sh: pfc: pinctrl legacy function support. sh: pfc: Make pr_fmt consistent across pfc drivers. sh: pfc: Error out on pinctrl init resolution failure. sh: pfc: Export pinctrl binding init symbol. sh: pfc: Ignore pinmux GPIOs with invalid enum IDs. sh: pfc: pinctrl legacy group support. sh: pfc: Prefer DRV_NAME over KBUILD_MODNAME. sh: pfc: pin config get/set support. Merge branch 'common/pinctrl' into sh-latest arch/sh/Kconfig | 1 + arch/sh/boards/Kconfig| 5 + arch/sh/boards/mach-dreamcast/irq.c | 32 +- arch/sh/boards/mach-se/7343/irq.c | 129 -- arch/sh/boards/mach-se/7343/setup.c | 10 +- arch/sh/boards/mach-se/7722/irq.c | 131 +++--- arch/sh/boards/mach-se/7722/setup.c | 6 +- arch/sh/boards/mach-se/7724/irq.c | 36 +- arch/sh/boards/mach-x3proto/gpio.c| 57 +-- arch/sh/cchips/hd6446x/hd64461.c | 33 +- arch/sh/include/asm/bug.h | 4 + arch/sh/include/asm/kdebug.h | 2 + arch/sh/include/mach-se/mach/se7343.h | 7 +- arch/sh/include/mach-se/mach/se7722.h | 10 +- arch/sh/kernel/cpu/sh5/unwind.c | 63 ++- arch/sh/kernel/dumpstack.c| 58 +++ arch/sh/kernel/irq.c | 10 - arch/sh/kernel/traps.c| 71 arch/sh/kernel/traps_32.c | 121 -- arch/sh/kernel/traps_64.c | 589 +++ arch/sh/lib64/Makefile| 2 +- arch/sh/lib64/dbg.c | 248 arch/sh/mm/tlb-sh5.c | 2 +- drivers/sh/Kconfig| 1 + drivers/sh/Makefile | 3 +- drivers/sh/clk/cpg.c | 333 +++ drivers/sh/intc/Makefile | 2 +- drivers/sh/intc/dynamic.c | 57 --- drivers/sh/intc/virq.c| 4 +- drivers/sh/pfc.c
Re: Boot breaks in -next from LEGACY to LINEAR conversion
On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote: > -next fails to boot for me today on my s3c64xx based systems. Walking > back to the last time I tried and bisecting likely branches I find that > commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one > that introduces the build break. Unfortunately the boot fails before I > get a console which makes diagnosis somewhat more tricky than would be > ideal. Any ideas? Does http://www.spinics.net/lists/linux-sh/msg11995.html fix it for you? I did Cc you on the legacy -> linear thread, but perhaps you missed it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot breaks in -next from LEGACY to LINEAR conversion
On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote: -next fails to boot for me today on my s3c64xx based systems. Walking back to the last time I tried and bisecting likely branches I find that commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one that introduces the build break. Unfortunately the boot fails before I get a console which makes diagnosis somewhat more tricky than would be ideal. Any ideas? Does http://www.spinics.net/lists/linux-sh/msg11995.html fix it for you? I did Cc you on the legacy - linear thread, but perhaps you missed it. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] sh fixes for 3.5-rc7
The following changes since commit ca24a145573124732152daff105ba68cc9a2b545: Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm (2012-07-01 11:02:25 -0700) are available in the git repository at: git://github.com/pmundt/linux-sh.git tags/sh-for-linus for you to fetch changes up to 44033109e99cf584d6285226ed521098f5ef7250: SH: Convert out[bwl] macros to inline functions (2012-07-12 13:12:13 +0900) SuperH fixes for 3.5-rc7 Corey Minyard (1): SH: Convert out[bwl] macros to inline functions Paul Mundt (1): sh: Fix up se7721 GPIOLIB=y build warnings. arch/sh/include/asm/io_noioport.h | 17 ++--- arch/sh/kernel/cpu/sh3/serial-sh7720.c | 2 +- 2 files changed, 15 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] SH: Convert out[bwl] macros to inline functions
On Mon, Jul 09, 2012 at 03:35:20PM -0500, miny...@acm.org wrote: > From: Corey Minyard > > The macros just called BUG(), but that results in unused variable > warnings all over the place, like in the IPMI driver. The build > regression emails were annoying me, so here's the fix. I have > not even compile tested this, but it's rather obvious. > > Signed-off-by: Corey Minyard Builds fine, I've switched the port type to unsigned long, but it looks good otherwise. Will queue it up for -rc7, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private
On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote: > Hi Guennadi, > > [CC Paul] > > On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski > wrote: > > This patch extends the sh dmaengine driver to support the preferred channel > > selection and configuration method, instead of using the "private" field > > from struct dma_chan. We add a standard filter function to be used by > > slave drivers instead of implementing their own ones, and add support for > > the DMA_SLAVE_CONFIG control operation, which must accompany the new > > channel selection method. We still support the legacy .private channel > > allocation method to cater for a smooth driver migration. > > > > Signed-off-by: Guennadi Liakhovetski > > --- > > Thanks for your efforts on this. Something that caught my eye in this > patch is this portion: > > +bool shdma_chan_filter(struct dma_chan *chan, void *arg); > > If we would use this function in our DMA Engine slave drivers (MMCIF, > SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict > dependency on this symbol provided by this particular DMA Engine > driver implementation for the DMAC hardware (that your patch > modifies)? > > And what do we do if we want to use the same DMA Engine slave driver > with a different DMA Engine driver implementation? > > From my point of view, there must be some better way to not have such > tight dependencies between the DMA Engine slave consumer and the DMA > Engine driver. Not sure what that looks like though. This symbol > dependency is pretty far from great IMO. > I vaguely recall this coming up before, and it wasn't acceptable then either. We will by no means be adding driver-specific hooks in to other drivers that really couldn't care less what the underlying DMA engine driving them is. We already have CPUs with different DMA engines that can be used by the same drivers. As I said the last time, this needs to be fixed in the dmaengine framework, period. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] dma: sh: provide a migration path for slave drivers to stop using .private
On Thu, Jul 12, 2012 at 06:55:32AM +0900, Magnus Damm wrote: Hi Guennadi, [CC Paul] On Thu, Jul 5, 2012 at 1:17 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: This patch extends the sh dmaengine driver to support the preferred channel selection and configuration method, instead of using the private field from struct dma_chan. We add a standard filter function to be used by slave drivers instead of implementing their own ones, and add support for the DMA_SLAVE_CONFIG control operation, which must accompany the new channel selection method. We still support the legacy .private channel allocation method to cater for a smooth driver migration. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Thanks for your efforts on this. Something that caught my eye in this patch is this portion: +bool shdma_chan_filter(struct dma_chan *chan, void *arg); If we would use this function in our DMA Engine slave drivers (MMCIF, SDHI, SCIF, FSI, SIU and so on) then wouldn't we add a strict dependency on this symbol provided by this particular DMA Engine driver implementation for the DMAC hardware (that your patch modifies)? And what do we do if we want to use the same DMA Engine slave driver with a different DMA Engine driver implementation? From my point of view, there must be some better way to not have such tight dependencies between the DMA Engine slave consumer and the DMA Engine driver. Not sure what that looks like though. This symbol dependency is pretty far from great IMO. I vaguely recall this coming up before, and it wasn't acceptable then either. We will by no means be adding driver-specific hooks in to other drivers that really couldn't care less what the underlying DMA engine driving them is. We already have CPUs with different DMA engines that can be used by the same drivers. As I said the last time, this needs to be fixed in the dmaengine framework, period. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
