* [PATCH] irq-gic: remove file name from heading comment
From: Sergei Shtylyov @ 2013-12-13 22:24 UTC (permalink / raw)
To: linux-arm-kernel
File names in the heading comments fell out of favor long ago, and this one
weren't even changed when the driver was moved from arch/arm/common/, so remove
it at last...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
The patch is against the 'irq/core' branch of the 'tip.git' repo.
drivers/irqchip/irq-gic.c | 2 --
1 file changed, 2 deletions(-)
Index: tip/drivers/irqchip/irq-gic.c
=================================--- tip.orig/drivers/irqchip/irq-gic.c
+++ tip/drivers/irqchip/irq-gic.c
@@ -1,6 +1,4 @@
/*
- * linux/arch/arm/common/gic.c
- *
* Copyright (C) 2002 ARM Limited, All Rights Reserved.
*
* This program is free software; you can redistribute it and/or modify
^ permalink raw reply
* Re: [PATCH] sh: Add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
From: Andrew Morton @ 2013-12-13 20:59 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1386893438-23573-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Fri, 13 Dec 2013 09:51:00 +0100 Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Note that Ralf decided to fix it differently, by uninlining virt_addr_valid:
geeze, what a mess this is.
I suppose that the proposed sh patch is reasonable - it's the sh
implementation of virt_addr_valid() whcih chooses to use these symbols
so sh should export them to support that implementation.
^ permalink raw reply
* Re: [PATCH] mtd: sh_flctl: Use devm_* managed allocators
From: Brian Norris @ 2013-12-13 18:23 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: David Woodhouse, linux-mtd, linux-sh
In-Reply-To: <1385548064-27234-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Wed, Nov 27, 2013 at 11:27:44AM +0100, Laurent Pinchart wrote:
> This simplifies error and cleanup code paths.
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linux-mtd@lists.infradead.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
This patch has been in l2-mtd.git, but I forgot to warn you. Thanks for
the patch!
Brian
^ permalink raw reply
* Re: [PATCH v2] mtd: sh_flctl: Fix warnings due to improper casts
From: Brian Norris @ 2013-12-13 18:22 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: David Woodhouse, linux-mtd, linux-sh
In-Reply-To: <1385547448-13747-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Wed, Nov 27, 2013 at 11:17:28AM +0100, Laurent Pinchart wrote:
> Cast pointers to uintptr_t instead of unsigned int. This fixes warnings
> on platforms where pointers have a different size than int.
>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: linux-mtd@lists.infradead.org
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/mtd/nand/sh_flctl.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Changes compared to v1:
>
> - Cast to uintptr_t instead of unsigned long
This patch has been in l2-mtd.git, but I forgot to alert you. Thanks for
the patch!
Brian
^ permalink raw reply
* Re: [PATCH 09/15] mtd: sh_flctl: Enable driver compilation with COMPILE_TEST
From: Brian Norris @ 2013-12-13 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3651259.U0RP9jvU5Q@avalon>
On Wed, Dec 11, 2013 at 01:48:50PM +0100, Laurent Pinchart wrote:
> Hi David,
>
> Could you please pick this patch up for v3.14 ?
I'm not David, but I pushed your patch over a week ago. I guess I forgot
to warn you. Sorry!
> On Wednesday 27 November 2013 02:18:31 Laurent Pinchart wrote:
> > This helps increasing build testing coverage.
> >
> > Cc: David Woodhouse <dwmw2@infradead.org>
> > Cc: linux-mtd@lists.infradead.org
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > Acked-by: Simon Horman <horms@verge.net.au>
This patch is in l2-mtd.git. Thanks!
Brian
^ permalink raw reply
* Re: [PATCH] PCI: rcar: fix return value check in rcar_pci_probe()
From: Bjorn Helgaas @ 2013-12-13 17:00 UTC (permalink / raw)
To: Valentine
Cc: Simon Horman, Jingoo Han, Wei Yongjun, Wei Yongjun,
linux-pci@vger.kernel.org, Magnus Damm, Kuninori Morimoto,
linux-sh
In-Reply-To: <52AAF85E.80206@cogentembedded.com>
On Fri, Dec 13, 2013 at 5:06 AM, Valentine
<valentine.barshak@cogentembedded.com> wrote:
> On 12/11/2013 06:30 AM, Simon Horman wrote:
>>
>> On Mon, Dec 09, 2013 at 10:46:17AM +0900, Jingoo Han wrote:
>>>
>>> On Sunday, December 08, 2013 7:50 AM, Bjorn Helgaas wrote:
>>>> For drivers/pci/host/*, I normally look for an ack from the responsible
>>>> person, but this patch is trivial enough that I'm fine taking it
>>>> without
>>>> that. But for more significant changes, I don't have any notes about
>>>> who
>>>> should own pci-rcar-gen2.c. Valentine could be a candidate since he
>>>> added
>>>> it in the first place? Or Jingoo?
>
>
> Sorry, I didn't ack since I thought it was not really needed for a trivial
> change like this one that had already been reviewed by Jingoo.
To be honest, I'm just trying to save myself some work by looking for
an ack. I want to have an indication that at least one person besides
the author approves, and if nobody else looks at it, I have to do it
myself :)
>> I will let Valentine volunteer himself if he wants to.
>
>
> I'll try to track the e-mails related to this driver as well.
>
> Not sure if I want myself in the MAINTAINERS though, since it would probably
> mean that "try to" should be changed to "have to" in my statement above.
Fair enough, thanks! Let me know if anything changes here.
Bjorn
^ permalink raw reply
* Re: [PATCH V2] gpio: rcar: Fix level interrupt handling
From: Magnus Damm @ 2013-12-13 12:31 UTC (permalink / raw)
To: Linus Walleij
Cc: Valentine Barshak, linux-sh@vger.kernel.org,
linux-gpio@vger.kernel.org, Simon Horman, Laurent Pinchart
In-Reply-To: <CACRpkdbeT8fp4i-ahpzZN2MnC7uYAcuLH7SOgJnpL54XBaoTqw@mail.gmail.com>
On Fri, Dec 13, 2013 at 4:54 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Nov 29, 2013 at 7:04 PM, Valentine Barshak
> <valentine.barshak@cogentembedded.com> wrote:
>
>> According to the manual, if a port is set for level detection using
>> the corresponding bit in the edge/level select register and an external
>> level interrupt signal is asserted, the corresponding bit in INTDT
>> does not use the FF to hold the input.
>> Thus, writing 1 to the corresponding bits in INTCLR cannot clear the
>> corresponding bits in the INTDT register. Instead, when an external
>> input signal is stopped, the corresponding bit in INTDT is cleared
>> automatically.
>>
>> Since the INTDT bit cannot be cleared for the level interrupts until
>> the interrupt signal is stopped, we end up with the infinite loop
>> when using deferred (threaded) IRQ handling.
>>
>> Since a deferred interrupt is disabled by the low-level handler and
>> re-enabled only when the deferred handler is completed, Fix the issue
>> by dropping disabled interrupts from the pending mask as suggested by
>> Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>>
>> Changes in V2:
>> * Drop disabled interrupts from pending mask altogether instead of
>> dropping level interrupts one by one once they get handled.
>>
>> Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
>
> This v2 version applied to fixes with Laurent's and Magnus' ACKs,
> tell me if it also need to go into -stable.
Thanks for your help, Linus! I don't think there is any need to involve -stable.
Cheers,
/ magnus
^ permalink raw reply
* Re: [PATCH] PCI: rcar: fix return value check in rcar_pci_probe()
From: Valentine @ 2013-12-13 12:06 UTC (permalink / raw)
To: Simon Horman, Jingoo Han
Cc: 'Bjorn Helgaas', 'Wei Yongjun',
'Wei Yongjun', linux-pci, 'Magnus Damm',
'Kuninori Morimoto', linux-sh
In-Reply-To: <20131211023006.GN19992@verge.net.au>
On 12/11/2013 06:30 AM, Simon Horman wrote:
> On Mon, Dec 09, 2013 at 10:46:17AM +0900, Jingoo Han wrote:
>> On Sunday, December 08, 2013 7:50 AM, Bjorn Helgaas wrote:
>>> On Tue, Nov 19, 2013 at 11:40:28AM +0800, Wei Yongjun wrote:
>>>> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>>>>
>>>> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
>>>> and never returns NULL. The NULL test in the return value check should
>>>> be replaced with IS_ERR().
>>>>
>>>> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>>>
>>> Applied with Jingoo's reviewed-by to pci/host-rcar for v3.14, thanks!
>>>
>>> For drivers/pci/host/*, I normally look for an ack from the responsible
>>> person, but this patch is trivial enough that I'm fine taking it without
>>> that. But for more significant changes, I don't have any notes about who
>>> should own pci-rcar-gen2.c. Valentine could be a candidate since he added
>>> it in the first place? Or Jingoo?
Sorry, I didn't ack since I thought it was not really needed for a trivial
change like this one that had already been reviewed by Jingoo.
>>
>> (+cc Simon Horman, Magnus Damm, Kuninori Morimoto, linux-sh mailing-list)
>>
>> Hi Bjorn,
>>
>> I think that Valentine could be a candidate, because he is an author.
>> However, pci-rcar-gen2.c is working on Renesas SoC, so, it may be
>> necessary to get ACK from Renesas people such as Simon Horman,
>> Magnus Damm, and Kuninori Morimoto.
>>
>> Simon Horman, Magnus Damm, and Kuninori Morimoto,
>> Who is a proper person responsible for RCar Gen PCIe driver?
>> (drivers/pci/host/pci-rcar-gen2.c)
>
> Good question.
>
> My feeling is that as it relates to Renesas ARM SoCs that
> responsibility at least in part defaults to the Renesas ARM SoC
> maintainers, Magnus and myself.
>
> So I think it would be best if the following were CCed on any patches
> to this driver:
>
> Simon Horman <horms@verge.net.au>
> Magnus Damm <magnus.damm@gmail.com>
> linux-sh@vger.kernel.org
I agree.
>
> I would not be opposed for there being a MAINTAINERS file entry to that effect.
>
> I will let Valentine volunteer himself if he wants to.
I'll try to track the e-mails related to this driver as well.
Not sure if I want myself in the MAINTAINERS though, since it would probably
mean that "try to" should be changed to "have to" in my statement above.
Thanks,
Val.
>
>>
>> Best regards,
>> Jingoo Han
>>
>>>
>>> Bjorn
>>>
>>>> ---
>>>> drivers/pci/host/pci-rcar-gen2.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/host/pci-rcar-gen2.c b/drivers/pci/host/pci-rcar-gen2.c
>>>> index cbaa5c4..96d1182 100644
>>>> --- a/drivers/pci/host/pci-rcar-gen2.c
>>>> +++ b/drivers/pci/host/pci-rcar-gen2.c
>>>> @@ -276,8 +276,8 @@ static int __init rcar_pci_probe(struct platform_device *pdev)
>>>>
>>>> cfg_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>>> reg = devm_ioremap_resource(&pdev->dev, cfg_res);
>>>> - if (!reg)
>>>> - return -ENODEV;
>>>> + if (IS_ERR(reg))
>>>> + return PTR_ERR(reg);
>>>>
>>>> mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
>>>> if (!mem_res || !mem_res->start)
>>>>
>>
^ permalink raw reply
* [PATCH 2/2] arm: shmobile: r8a7790: Add SATA clock support
From: Valentine Barshak @ 2013-12-13 11:52 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <c223d986b953a4686f2540091f82e44030a50daa.1377652063.git.horms+renesas@verge.net.au>
This adds SATA 0/1 clock support. External 100MHz SATA 0/1
reference clock is supposed to be applied to the following pins:
CICREFP0_SATA/CICREFP1_SATA;
CICREFN0_SATA/CICREFN1_SATA.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
---
arch/arm/mach-shmobile/clock-r8a7790.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index 3e27200..c4b567b 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -73,6 +73,18 @@ static struct clk extal_clk = {
.mapping = &cpg_mapping,
};
+/* External SATA0 reference clock: 100MHz fixed */
+static struct clk sata0_clk = {
+ .rate = 100000000,
+ .mapping = &cpg_mapping,
+};
+
+/* External SATA1 reference clock: 100MHz fixed */
+static struct clk sata1_clk = {
+ .rate = 100000000,
+ .mapping = &cpg_mapping,
+};
+
static struct sh_clk_ops followparent_clk_ops = {
.recalc = followparent_recalc,
};
@@ -140,6 +152,8 @@ static struct clk *main_clks[] = {
&ddr_clk,
&mp_clk,
&cp_clk,
+ &sata0_clk,
+ &sata1_clk,
};
/* SDHI (DIV4) clock */
@@ -187,6 +201,7 @@ enum {
MSTP1009, MSTP1008, MSTP1007, MSTP1006, MSTP1005,
MSTP931, MSTP930, MSTP929, MSTP928,
MSTP917,
+ MSTP815, MSTP814,
MSTP813,
MSTP726, MSTP725, MSTP724, MSTP723, MSTP722, MSTP721, MSTP720,
MSTP717, MSTP716,
@@ -215,6 +230,8 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP929] = SH_CLK_MSTP32(&p_clk, SMSTPCR9, 29, 0), /* I2C2 */
[MSTP928] = SH_CLK_MSTP32(&p_clk, SMSTPCR9, 28, 0), /* I2C3 */
[MSTP917] = SH_CLK_MSTP32(&qspi_clk, SMSTPCR9, 17, 0), /* QSPI */
+ [MSTP815] = SH_CLK_MSTP32(&sata0_clk, SMSTPCR8, 15, 0), /* SATA0 */
+ [MSTP814] = SH_CLK_MSTP32(&sata1_clk, SMSTPCR8, 14, 0), /* SATA1 */
[MSTP813] = SH_CLK_MSTP32(&p_clk, SMSTPCR8, 13, 0), /* Ether */
[MSTP726] = SH_CLK_MSTP32(&zx_clk, SMSTPCR7, 26, 0), /* LVDS0 */
[MSTP725] = SH_CLK_MSTP32(&zx_clk, SMSTPCR7, 25, 0), /* LVDS1 */
@@ -321,6 +338,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("pci-rcar-gen2.0", &mstp_clks[MSTP703]),
CLKDEV_DEV_ID("pci-rcar-gen2.1", &mstp_clks[MSTP703]),
CLKDEV_DEV_ID("pci-rcar-gen2.2", &mstp_clks[MSTP703]),
+ CLKDEV_DEV_ID("sata-r8a7790.0", &mstp_clks[MSTP815]),
+ CLKDEV_DEV_ID("sata-r8a7790.1", &mstp_clks[MSTP814]),
/* ICK */
CLKDEV_ICK_ID("usbhs", "usb_phy_rcar_gen2", &mstp_clks[MSTP704]),
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/2] arm: shmobile: r8a7790: Add PCI USB host clock support
From: Valentine Barshak @ 2013-12-13 11:52 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1368173119-27345-2-git-send-email-horms+renesas@verge.net.au>
This adds internal PCI USB host clock support.
Signed-off-by: Valentine Barshak <valentine.barshak@cogentembedded.com>
---
arch/arm/mach-shmobile/clock-r8a7790.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/clock-r8a7790.c b/arch/arm/mach-shmobile/clock-r8a7790.c
index c5c60ec..3e27200 100644
--- a/arch/arm/mach-shmobile/clock-r8a7790.c
+++ b/arch/arm/mach-shmobile/clock-r8a7790.c
@@ -190,7 +190,7 @@ enum {
MSTP813,
MSTP726, MSTP725, MSTP724, MSTP723, MSTP722, MSTP721, MSTP720,
MSTP717, MSTP716,
- MSTP704,
+ MSTP704, MSTP703,
MSTP522,
MSTP315, MSTP314, MSTP313, MSTP312, MSTP311, MSTP305, MSTP304,
MSTP216, MSTP207, MSTP206, MSTP204, MSTP203, MSTP202,
@@ -226,6 +226,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP717] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 17, 0), /* HSCIF0 */
[MSTP716] = SH_CLK_MSTP32(&zs_clk, SMSTPCR7, 16, 0), /* HSCIF1 */
[MSTP704] = SH_CLK_MSTP32(&mp_clk, SMSTPCR7, 4, 0), /* HSUSB */
+ [MSTP703] = SH_CLK_MSTP32(&mp_clk, SMSTPCR7, 3, 0), /* EHCI */
[MSTP522] = SH_CLK_MSTP32(&extal_clk, SMSTPCR5, 22, 0), /* Thermal */
[MSTP315] = SH_CLK_MSTP32(&div6_clks[DIV6_MMC0], SMSTPCR3, 15, 0), /* MMC0 */
[MSTP314] = SH_CLK_MSTP32(&div4_clks[DIV4_SD0], SMSTPCR3, 14, 0), /* SDHI0 */
@@ -317,6 +318,9 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("sh_cmt.0", &mstp_clks[MSTP124]),
CLKDEV_DEV_ID("qspi.0", &mstp_clks[MSTP917]),
CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP704]),
+ CLKDEV_DEV_ID("pci-rcar-gen2.0", &mstp_clks[MSTP703]),
+ CLKDEV_DEV_ID("pci-rcar-gen2.1", &mstp_clks[MSTP703]),
+ CLKDEV_DEV_ID("pci-rcar-gen2.2", &mstp_clks[MSTP703]),
/* ICK */
CLKDEV_ICK_ID("usbhs", "usb_phy_rcar_gen2", &mstp_clks[MSTP704]),
--
1.8.3.1
^ permalink raw reply related
* [PATCH 0/2] arm: shmobile: r8a7790: Add SATA and PCI USB clocks
From: Valentine Barshak @ 2013-12-13 11:52 UTC (permalink / raw)
To: linux-sh
This adds SATA and PCI USB clocks to R8A7790 SoC.
Valentine Barshak (2):
arm: shmobile: r8a7790: Add PCI USB host clock support
arm: shmobile: r8a7790: Add SATA clock
arch/arm/mach-shmobile/clock-r8a7790.c | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH] ARM: shmobile: r8a7790 - fix shdi resource sies
From: Ben Dooks @ 2013-12-13 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANqRtoT86xdh-c73f-_59sD3E=90yW1wOp5Bobmi4qJywA72uA@mail.gmail.com>
On 13/12/13 10:56, Magnus Damm wrote:
> Hey Morimoto-san,
>
> On Fri, Dec 13, 2013 at 11:37 AM, Kuninori Morimoto
> <kuninori.morimoto.gx@gmail.com> wrote:
>>
>> Hi Ben
>>
>> Thank you for your patch
>>
>>> The r8a7790.dtsi file has three sdhi nodes which all have the wrong resource
>>> size for their register block. This causes the sh_modbile_sdhi driver to
>>> fail to communicate with card at-all.
>>>
>>> Change each sdhi node size from 0x100 to 0x200 to correct this.
>>>
>>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>>> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
>>> Cc: Magnus Damm <magnus.damm@gmail.com>
>>> Cc: Simon Horman <horms@verge.net.au>
>>> Cc: Linux SH <linux-sh@vger.kernel.org>
>>> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
>>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>>> Tested-by: William Towle <william.towle@codethink.co.uk>
>>> ---
>>
>> Unfortunately, sdhi resource size 0x100 is corrent on Renesas SDHI.
>> The wrong is SDHI/TMIO driver side, not SoC side.
>> Now, I'm working/sending sh_modbile_sdhi driver fixup patches for R-Car H2,
>> but it need more time (= there is merge timing issue)
>
> Thanks for supporting Ben regarding this SDHI issue.
>
> Would it be possible for you to share a list of patches needed to get
> SDHI working? If some parts are missing then please post them so the
> patches are available on public lists.
>
> I would like to make it possible for Ben to test your patch stack if
> he happens to have time.
Thanks, I think I have all the previous ones that where pushed to the
linux-sh list. If there's a git tree I could pull from that would make
our job easier.
We have got SDHI0 and SDHI2 working with device tree, but we're
currently seeing less than a megabyte a second when direcly dd-ing
blocks from the card. Is this a noted issue? We got ~11MiB without
DMA on the 3.4-ltsi series.
As a note, I will be away from the 20th December untill Janurary 6th
and it is likely the rest of the team here will be away from 21st.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* Re: [PATCH] ARM: shmobile: r8a7790 - fix shdi resource sies
From: Magnus Damm @ 2013-12-13 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871u1hsd44.wl%kuninori.morimoto.gx@gmail.com>
Hey Morimoto-san,
On Fri, Dec 13, 2013 at 11:37 AM, Kuninori Morimoto
<kuninori.morimoto.gx@gmail.com> wrote:
>
> Hi Ben
>
> Thank you for your patch
>
>> The r8a7790.dtsi file has three sdhi nodes which all have the wrong resource
>> size for their register block. This causes the sh_modbile_sdhi driver to
>> fail to communicate with card at-all.
>>
>> Change each sdhi node size from 0x100 to 0x200 to correct this.
>>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: Simon Horman <horms@verge.net.au>
>> Cc: Linux SH <linux-sh@vger.kernel.org>
>> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> Tested-by: William Towle <william.towle@codethink.co.uk>
>> ---
>
> Unfortunately, sdhi resource size 0x100 is corrent on Renesas SDHI.
> The wrong is SDHI/TMIO driver side, not SoC side.
> Now, I'm working/sending sh_modbile_sdhi driver fixup patches for R-Car H2,
> but it need more time (= there is merge timing issue)
Thanks for supporting Ben regarding this SDHI issue.
Would it be possible for you to share a list of patches needed to get
SDHI working? If some parts are missing then please post them so the
patches are available on public lists.
I would like to make it possible for Ben to test your patch stack if
he happens to have time.
My plan is to try out r8a7791 SDHI early next week.
Cheers,
/ magnus
^ permalink raw reply
* Re: [PATCH v4 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
From: Magnus Damm @ 2013-12-13 10:12 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-kernel, Kevin Hilman, Arnd Bergmann, SH-Linux,
Daniel Lezcano, Simon Horman [Horms], John Stultz,
Thomas Gleixner
In-Reply-To: <20131212010503.GI21531@quad.lixom.net>
Hi Olof,
On Thu, Dec 12, 2013 at 10:05 AM, Olof Johansson <olof@lixom.net> wrote:
> Hi,
>
> A couple of small comments below.
Thanks for your feedback!
> On Thu, Dec 12, 2013 at 08:56:26AM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm@opensource.se>
>>
>> Add Kconfig entries for CMT, MTU2, TMU and STI to
>> drivers/clocksource/Kconfig. This will allow us to
>> get rid of duplicated entires in architecture code
>> such as arch/sh and arch/arm/mach-shmobile.
>>
>> Signed-off-by: Magnus Damm <damm@opensource.se>
>> ---
>>
>> drivers/clocksource/Kconfig | 44 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 44 insertions(+)
>>
>> --- 0001/drivers/clocksource/Kconfig
>> +++ work/drivers/clocksource/Kconfig 2013-12-12 08:41:55.000000000 +0900
>> @@ -134,3 +134,47 @@ config VF_PIT_TIMER
>> bool
>> help
>> Support for Period Interrupt Timer on Freescale Vybrid Family SoCs.
>> +
>> +config SYS_SUPPORTS_CMT
>> + bool
>> +
>> +config SYS_SUPPORTS_TMU
>> + bool
>> +
>> +config SYS_SUPPORTS_MTU2
>> + bool
>> +
>> +config SYS_SUPPORTS_STI
>> + bool
>
> Maybe a prefix to avoid namespace collissions here?
Sure, that is fine with me. I based the ones above on already existing
ones used by SH but I don't mind reworking those.
How about SYS_SUPPORTS_CLKSRC_xxx?
>> +config SH_TIMER_CMT
>> + bool "Renesas CMT timer driver" if COMPILE_TEST
>> + default SYS_SUPPORTS_CMT
>
> It might be useful to have an explicit depends on ARCH_SH || ARCH_SHMOBILE
> || COMPILE_TEST on these, just to make it easier for someone reading
> the code later on.
I have any strong feelings one way or the other about that myself, but
I got the impression that John Stultz preferred to not allow manual
selection at all, and my compromise here is to allow it only when
COMPILE_TEST is selected.
Would you be ok to keep it as-is for now? If needed then we can add an
incremental patch later to enable more flexible selection.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH] sh: Add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
From: Geert Uytterhoeven @ 2013-12-13 8:51 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1386893438-23573-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Fri, Dec 13, 2013 at 8:56 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 13 Dec 2013 09:10:38 +0900 Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> wrote:
>
>> Min_low_pfn and max_low_pfn were used in pfn_valid macro if defined
>> CONFIG_FLATMEM. When the functions that use the pfn_valid is used in driver
>> module, max_low_pfn and min_low_pfn is to undefined, and fail to build.
>>
>> ----
>> ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
>> ERROR: "max_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
>
> This could be a sign that the aoe driver is doing something which it
> shouldn't be doing.
>
> z:/usr/src/25> grep pfn drivers/block/aoe/*.[ch]
> z:/usr/src/25>
>
> Confused. Can you please work out precisely where in AOE this
> reference is occurring?
From my patch for mips, it's due to virt_addr_valid(), which calls pfn_valid()
on most architectures, cfr.
http://marc.info/?l=linux-kernel&m\x135672726823050&w=1.
Note that Ralf decided to fix it differently, by uninlining virt_addr_valid:
commit d3ce88431892b703b04769566338a89eda6b0477
Author: Ralf Baechle <ralf@linux-mips.org>
Date: Fri Dec 28 15:34:40 2012 +0100
MIPS: Fix modpost error in modules attepting to use virt_addr_valid().
ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
Fixed by moving the implementation of virt_addr_valid() into the kernel
proper and exporting it which removes the pains of an inline or macro
implementation.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
diff --git a/arch/mips/include/asm/page.h b/arch/mips/include/asm/page.h
index bf84e48ad669..dbaec94046da 100644
--- a/arch/mips/include/asm/page.h
+++ b/arch/mips/include/asm/page.h
@@ -198,7 +198,10 @@ typedef struct { unsigned long pgprot; } pgprot_t;
#endif
#define virt_to_page(kaddr) pfn_to_page(PFN_DOWN(virt_to_phys(kaddr)))
-#define virt_addr_valid(kaddr) pfn_valid(PFN_DOWN(virt_to_phys(kaddr)))
+
+extern int __virt_addr_valid(const volatile void *kaddr);
+#define virt_addr_valid(kaddr) \
+ __virt_addr_valid((const volatile void *) (kaddr))
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC)
diff --git a/arch/mips/mm/ioremap.c b/arch/mips/mm/ioremap.c
index cacfd31e8ec9..7657fd21cd3f 100644
--- a/arch/mips/mm/ioremap.c
+++ b/arch/mips/mm/ioremap.c
@@ -190,3 +190,9 @@ void __iounmap(const volatile void __iomem *addr)
EXPORT_SYMBOL(__ioremap);
EXPORT_SYMBOL(__iounmap);
+
+int __virt_addr_valid(const volatile void *kaddr)
+{
+ return pfn_valid(PFN_DOWN(virt_to_phys(kaddr)));
+}
+EXPORT_SYMBOL_GPL(__virt_addr_valid);
BTW, ia64 exports both min_low_pfn and max_low_pfn,
metag exports min_low_pfn.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* RE: pinctrl - detailed gpio-mode pinconf design
From: kevin.bracey @ 2013-12-13 8:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbzGokHHhR3GhLvF7KCFdAV=b0VHwUE4eHVfNFEGhx_Jg@mail.gmail.com>
Linus Walleij wrote:
> On Thu, Dec 5, 2013 at 11:15 AM, <kevin.bracey@broadcom.com> wrote:
>> Laurent Pinchart wrote:
>>> On Tuesday 03 December 2013 11:04:48 Linus Walleij wrote:
>
>>> Controlling GPIO through pinconf seems to be very twisted.
>>> Usually it is the other way around.
>>
>> By my understanding of the general pinctrl concept, we should be converting that to the lovely:
>>
>> resume:
>> pinctrl_pm_select_default_state(dev);
>> suspend:
>> pinctrl_pm_select_sleep_state(dev);
> This observation is correct, and I agree with this reasoning. The PM states
> are quite new and may take some time before they "sink in" in the kernel though,
> but ideally people should be using them like that (atleast IMO).
I strongly approve of the PM state concept, having seen the alternative. It slots in very nicely. I'm working on 3.10-based systems, but the pinctrl_pm_select is being cherry-picked in because it makes life so much easier.
>>> > This looks messy. The intention with the pin config subsystem is to
>>> > break things apart and make them understandable that way, and to
>>> > handle electronic stuff in pin config whereas driving a line
>>> > high/low happens in the GPIO subsystem.
>>
>> Which is basically an argument against ever using PIN_CONFIG_OUTPUT 0,
>> and the whole of "GPIO mode pitfalls" in pinctrl.txt, isn't it? It
>> means we can't specify idle pinctrl states that drive lines. We have to do the GPIO/function shuffle.
>
> Well maybe. My point was that it is OK to drive GPIO lines as part of
> a state which is only relevant for a device driver, and where using the
> GPIO API in top would only bloat and make things hard to follow.
In practice, this is the case for the majority of the code I'm looking at. We have a large number of function drivers which have to be told their pins' GPIO numbers in platform data, solely for their suspend setting. Otherwise the pins would be entirely driven as a function, and no need for the GPIO API.
> > In my initial prototype, PIN_CONFIG_OUTPUT is only available if the
> > gpio-mode function has been selected.
> That is even more careful code than most drivers write, so sounds very nice.
> > But maybe this could be made hidden and implicit, as per the GPIO API.
> > Eg PIN_CONFIG_OUTPUT/PIN_CONFIG_LOW_POWER_MODE
> > implicitly selects the GPIO mux (for output/input), and
> > PIN_CONFIG_DRIVE_PUSH_PULL/PIN_CONFIG_BIAS_HIGH_IMPEDANCE
> > restores the previously requested?
>
> I'd recommend trying to keep as close to the semantics descrived in <linux/pinctrl/pinconf-generic.h> and not add any implicit semantics.
Yeah, but the catch is that the semantics described are on the assumption that pinconf is totally orthogonal to pinmux. That's not true on this platform, and on many others. I think we need some sort of general policy on how to handle conflicting requests.
Personally, I can see the merits of both approaches -
a) pinconf settings forcing mux to achieve the requested pin state - working to emulate orthogonality on non-orthogonal hardware;
b) pinconf settings requiring an appropriate mux to be explicitly set for them to be available - machines/DT need to know about the mux/conf interactions.
Main problem with (a) - how do you get back to "normal" mux, and is emulation just obfuscation?
Main problem with (b) - can you guarantee mux/conf ordering?
It sounds like you prefer (b), and that is what my prototype does. It's what I originally decided, but I wasn't totally certain about how much pinconf-generic.h was intended to be a framework/language whose usage is always going to be very pin-driver-dependent, versus trying to make it an API trying to produce consistent behaviour.
>>> > This must be some misunderstanding. DT does not specify
>>> > application/ordering semantics. It does not define sequences at all.
>>> > The device driver parsing out whatever is in the device tree has to
>>> > take care of ordering stuff and driving the hardware.
>
>> Well, the pinctrl core does process its tables in order. So in the
>> case where a pinconf setting may interact with a pinmux setting, the
>> ordering that the
>> pinconf+pinmux entries get processed could be significant. Eg if
>> PIN_CONFIG_OUTPUT requires the "gpio-mode" function selected first.
> OK so we solved the similar situation where configs had to be applied in some certain order for the pin config API by passing the array of configs down to the driver and let is handle this.
Well, ordering is already preserved by the pinctrl core. As far as I can see, when you're given a table of settings through pinctrl_register_map, you keep the ordering, and when that state is selected, the settings are passed down to the driver one-by-one in original order.
If that can be guaranteed, then we may not need to be do anything else.
> So can we think of an API that gives the drivers the freedom to express or behave differently here?
I don't think it's necessary.
For DT, the driver can control ordering in its parse routines. The sh-pfc driver does already put a node's function request first in its dt_node_to_map(), which is what gpio-mode needs. If the core preserves that order, we're sorted.
For non-DT, I think it's acceptable to require that the tables should be ordered correctly by the board to meet the documented requirements of the driver - so sh-pfc board files would be required to put gpio-mode mux selections before PIN_CONFIG_OUTPUT/PIN_BIAS_CONFIG_HIGH_IMPEDANCE selections.
And either way, for glitch-free-handover, I'm also requiring that the configs always be specified - the mux won't be switched by the driver unless/until a config has been parsed and set. So in the driver - first pinmux "gpio-mode" primes it, and makes the output/high-impedance pinconfs legal. Then the pinconfs set the IE/OE/DATA bits in the GPIO registers and flip to GPIO mux.
Now, going back to the pinconfs. The naming of the configs still throws me a little. Particularly all the "bias" settings. "BIAS_HIGH_IMPEDANCE" doesn't feel like a "bias" to me. What does it mean to "BIAS_DISABLE" a "BIAS_HIGH_IMPEDANCE"? Should "BIAS_HIGH_IMPEDANCE" turn off "BIAS_PULL_UP"?
My feeling is that it would be better named just "CONFIG_HIGH_IMPEDANCE", making it a separate thing from all the other biases, akin to CONFIG_DRIVE_* and CONFIG_OUTPUT.
In summary, I think the two independent exclusive Boolean sets in the configs seem to be:
(BIAS_DISABLE | BIAS_BUS_HOLD | BIAS_PULL_DOWN | BIAS_PULL_UP | BIAS_PULL_PIN_DEFAULT)
([BIAS_]HIGH_IMPEDANCE | DRIVE_PUSH_PULL | DRIVE_OPEN_DRAIN | DRIVE_OPEN_SOURCE | LOW_POWER_MODE | OUTPUT)
And that's effectively how I'm treating them, for the 5 I'm handling for our hardware (BIAS_DISABLE|BIAS_PULL_DOWN|BIAS_PULL_UP)+(BIAS_HIGH_IMPEDANCE|OUTPUT).
Does that make sense? Maybe it's hardware specific, but at least for our case, where the pulls are non-muxed and the drives are muxed, that separation seems logical.
Regards,
Kevin
^ permalink raw reply
* Re: [PATCH] ARM: shmobile: r8a7790 - fix shdi resource sies
From: Ben Dooks @ 2013-12-13 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <871u1hsd44.wl%kuninori.morimoto.gx@gmail.com>
On 13/12/13 02:37, Kuninori Morimoto wrote:
>
> Hi Ben
>
> Thank you for your patch
>
>> The r8a7790.dtsi file has three sdhi nodes which all have the wrong resource
>> size for their register block. This causes the sh_modbile_sdhi driver to
>> fail to communicate with card at-all.
>>
>> Change each sdhi node size from 0x100 to 0x200 to correct this.
>>
>> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Cc: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>
>> Cc: Magnus Damm <magnus.damm@gmail.com>
>> Cc: Simon Horman <horms@verge.net.au>
>> Cc: Linux SH <linux-sh@vger.kernel.org>
>> Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>
>> Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>> Tested-by: William Towle <william.towle@codethink.co.uk>
>> ---
>
> Unfortunately, sdhi resource size 0x100 is corrent on Renesas SDHI.
> The wrong is SDHI/TMIO driver side, not SoC side.
> Now, I'm working/sending sh_modbile_sdhi driver fixup patches for R-Car H2,
> but it need more time (= there is merge timing issue)
Ok, thanks. We will keep this in our tree until the SDHI driver
is sorted out.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
^ permalink raw reply
* Re: [PATCH] sh: Add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
From: Andrew Morton @ 2013-12-13 7:56 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1386893438-23573-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
On Fri, 13 Dec 2013 09:10:38 +0900 Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> wrote:
> Min_low_pfn and max_low_pfn were used in pfn_valid macro if defined
> CONFIG_FLATMEM. When the functions that use the pfn_valid is used in driver
> module, max_low_pfn and min_low_pfn is to undefined, and fail to build.
>
> ----
> ERROR: "min_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
> ERROR: "max_low_pfn" [drivers/block/aoe/aoe.ko] undefined!
This could be a sign that the aoe driver is doing something which it
shouldn't be doing.
z:/usr/src/25> grep pfn drivers/block/aoe/*.[ch]
z:/usr/src/25>
Confused. Can you please work out precisely where in AOE this
reference is occurring?
^ permalink raw reply
* RE: [PATCH] MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers
From: Hong-Xing.Zhu @ 2013-12-13 6:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131213053922.GP18380@S2101-09.ap.freescale.net>
Hi Bjorn:
> -----Original Message-----
> From: Shawn Guo [mailto:shawn.guo@linaro.org]
> Sent: Friday, December 13, 2013 1:39 PM
> To: Bjorn Helgaas
> Cc: linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm; linux-
> tegra@vger.kernel.org; linux-sh@vger.kernel.org; linux-samsung-
> soc@vger.kernel.org; Jingoo Han; Jason Cooper; Thierry Reding; Simon Horman;
> Magnus Damm; Valentine Barshak; Wei Yongjun; Wei Yongjun; Kuninori Morimoto;
> Zhu Richard-R65037
> Subject: Re: [PATCH] MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI
> host maintainers
>
> On Thu, Dec 12, 2013 at 01:29:00PM -0700, Bjorn Helgaas wrote:
> > On Thu, Dec 12, 2013 at 12:00 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > Hi Bjorn,
> > >
> > > On Wed, Dec 11, 2013 at 11:32:37AM -0700, Bjorn Helgaas wrote:
> > >> +PCI DRIVER FOR IMX6
> > >> +M: Shawn Guo <shawn.guo@linaro.org>
> > >
> > > Thanks for the nomination. But I think a better person for this
> > > position would be Richard Zhu <r65037@freescale.com> (copied). He
> > > knows the driver and controller much better than myself, and most
> > > importantly he is the driver owner for Freescale kernel and he has
> > > the contact to Freescale PCIe hardware people.
> >
> > Richard, are you OK with being listed here?
>
> Richard is on leave these two days. Hope he will be back to online soon.
[Richard] I went to hospital in the past two days.
Thanks, I'm ok with being listed here.
>
> > Shawn, do you want to be
> > listed here in addition, if only to make sure you're copied on changes
> > to pci-imx6.c?
>
> Okay, thanks, Bjorn.
>
> Shawn
Best Regards
Richard Zhu
^ permalink raw reply
* Re: [PATCH] sh: Add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
From: Nobuhiro Iwamatsu @ 2013-12-13 6:25 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1386893438-23573-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
Hi,
(2013/12/13 12:17), Kuninori Morimoto wrote:
>
> Hi
>
>
>>> EXPORT_SYMBOL() on arch/sh/kernel/sh_ksyms_32.c
>>> seems strange for me.
>>
>> Handling of these depends on CPUs.
>> And in SH32, it may be referred to from modules.
>> Therefore, I have feeling that it is not amusing that sh_ksyms_32.c defines these using EXPORT_SYMBOL.
>>
>> Would you explain the reason that you thought to be strange?
>
> I think EXPORT_SYMBOL() should be called
> from ${LINUX}/mm/[no]bootmem.c, not sh_ksyms_32.c
The usage of max_low_pfn and min_low_pfn depend on the architecture as I have described above.
You do not need to set as EXPORT_SYMBOL these all architectures.
Best regards,
Nobuhiro
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers
From: Shawn Guo @ 2013-12-13 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAErSpo5O1nSkKmWfHGGZiuVdvRxFjNNDS-8BWKFhnCgwVSdr8A@mail.gmail.com>
On Thu, Dec 12, 2013 at 01:29:00PM -0700, Bjorn Helgaas wrote:
> On Thu, Dec 12, 2013 at 12:00 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > Hi Bjorn,
> >
> > On Wed, Dec 11, 2013 at 11:32:37AM -0700, Bjorn Helgaas wrote:
> >> +PCI DRIVER FOR IMX6
> >> +M: Shawn Guo <shawn.guo@linaro.org>
> >
> > Thanks for the nomination. But I think a better person for this
> > position would be Richard Zhu <r65037@freescale.com> (copied). He knows
> > the driver and controller much better than myself, and most importantly
> > he is the driver owner for Freescale kernel and he has the contact to
> > Freescale PCIe hardware people.
>
> Richard, are you OK with being listed here?
Richard is on leave these two days. Hope he will be back to online
soon.
> Shawn, do you want to be
> listed here in addition, if only to make sure you're copied on changes
> to pci-imx6.c?
Okay, thanks, Bjorn.
Shawn
^ permalink raw reply
* Re: [PATCH v2] MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers
From: Magnus Damm @ 2013-12-13 5:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131212204610.GK4699@google.com>
On Fri, Dec 13, 2013 at 5:46 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> [+cc Thomas]
>
> On Wed, Dec 11, 2013 at 11:32:37AM -0700, Bjorn Helgaas wrote:
>> If this looks reasonable, I'll merge it via the PCI tree for v3.13.
>
> OK, here's another try. I'm not actually trying to nominate anybody; I
> just tried to write down the list we came up with in an earlier discussion [1].
>
> I'd like confirmation from the following people that they approve of being
> listed here:
>
> Richard Zhu (IMX6)
> Thomas Petazzoni (MVEBU)
> Magnus Damm (R-CAR)
Hi Bjorn,
Thanks for making this list. I actually have had very little to do
with this particular driver, so I prefer to be omitted since Simon
Horman already is listed and I trust his judgement.
Cheers,
/ magnus
^ permalink raw reply
* Re: [GIT PULL FOR v3.14] Renesas R-Car Gen 2 Common Clock Framework
From: Mike Turquette @ 2013-12-13 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2317239.Qa6C04GgRQ@avalon>
On Thu, Dec 12, 2013 at 7:15 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Mike,
>
> On Thursday 12 December 2013 19:10:46 Mike Turquette wrote:
>> Quoting Laurent Pinchart (2013-12-04 13:29:07)
>>
>> > Hi Mike,
>> >
>> > As nobody replied to the last version of the patches I will assume that
>> > either they're perfect, or I've managed to make all reviewers hibernate
>> > from boredom. Both cases call for a pull request.
>> >
>> > Could you please pull the following three patches for v3.14 ? They have no
>> > extra compile-time or runtime dependency, but subsequent platform patches
>> > will depend on them. Could you thus please provide a stable branch that
>> > Simon can merge in his tree ?
>> >
>> > Changes compared to v4:
>> >
>> > - Rebased on top of the latest clk-next branch
>> > - Revert to ARCH_SHMOBILE_MULTI (as in v3) for drivers/clk/Makefile
>> >
>> > The following changes since commit
> cdf64eeeb0d762585e2126f3024458d199c2635d:
>> > clk: exynos5420: fix cpll clock register offsets (2013-12-04 10:46:45
>> > -0800)>
>> > are available in the git repository at:
>> > git://linuxtv.org/pinchartl/fbdev.git clocks/ccf/rcar-gen2-mainline
>> >
>> > for you to fetch changes up to 7135ea019305179dd6f6a99ea7c1e78773eca166:
>> > clk: shmobile: Add MSTP clock support (2013-12-04 22:18:36 +0100)
>>
>> Thanks for the pull request. This is a nicely formatted series. Very
>> easy to review.
>>
>> Taken into clk-next.
>
> Thank you.
>
> Simon will need a stable branch with these three patches that he can merge in
> his tree. If you could apply the patches to a branch directly on top of a
> mainline tag (I think you're currently based on v3.13-rc1) and merge that to
> clk-next that would be perfect as it would minimize the amount of changes
> merged by Simon.
Done. Please see:
git://git.linaro.org/people/mike.turquette/linux.git clk-next-shmobile
Which I've merged into clk-next:
https://git.linaro.org/people/mike.turquette/linux.git/commit/7535d8f9307072f71d13a0c7e235166310e2a020
Regards,
Mike
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* Re: [PATCH] sh: Add EXPORT_SYMBOL(min_low_pfn) and EXPORT_SYMBOL(max_low_pfn) to sh_ksyms_32.c
From: Kuninori Morimoto @ 2013-12-13 3:17 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1386893438-23573-1-git-send-email-nobuhiro.iwamatsu.yj@renesas.com>
Hi
> > EXPORT_SYMBOL() on arch/sh/kernel/sh_ksyms_32.c
> > seems strange for me.
>
> Handling of these depends on CPUs.
> And in SH32, it may be referred to from modules.
> Therefore, I have feeling that it is not amusing that sh_ksyms_32.c defines these using EXPORT_SYMBOL.
>
> Would you explain the reason that you thought to be strange?
I think EXPORT_SYMBOL() should be called
from ${LINUX}/mm/[no]bootmem.c, not sh_ksyms_32.c
Best regards
---
Kuninori Morimoto
^ permalink raw reply
* Re: [GIT PULL FOR v3.14] Renesas R-Car Gen 2 Common Clock Framework
From: Laurent Pinchart @ 2013-12-13 3:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131213031046.11981.97127@quantum>
Hi Mike,
On Thursday 12 December 2013 19:10:46 Mike Turquette wrote:
> Quoting Laurent Pinchart (2013-12-04 13:29:07)
>
> > Hi Mike,
> >
> > As nobody replied to the last version of the patches I will assume that
> > either they're perfect, or I've managed to make all reviewers hibernate
> > from boredom. Both cases call for a pull request.
> >
> > Could you please pull the following three patches for v3.14 ? They have no
> > extra compile-time or runtime dependency, but subsequent platform patches
> > will depend on them. Could you thus please provide a stable branch that
> > Simon can merge in his tree ?
> >
> > Changes compared to v4:
> >
> > - Rebased on top of the latest clk-next branch
> > - Revert to ARCH_SHMOBILE_MULTI (as in v3) for drivers/clk/Makefile
> >
> > The following changes since commit
cdf64eeeb0d762585e2126f3024458d199c2635d:
> > clk: exynos5420: fix cpll clock register offsets (2013-12-04 10:46:45
> > -0800)>
> > are available in the git repository at:
> > git://linuxtv.org/pinchartl/fbdev.git clocks/ccf/rcar-gen2-mainline
> >
> > for you to fetch changes up to 7135ea019305179dd6f6a99ea7c1e78773eca166:
> > clk: shmobile: Add MSTP clock support (2013-12-04 22:18:36 +0100)
>
> Thanks for the pull request. This is a nicely formatted series. Very
> easy to review.
>
> Taken into clk-next.
Thank you.
Simon will need a stable branch with these three patches that he can merge in
his tree. If you could apply the patches to a branch directly on top of a
mainline tag (I think you're currently based on v3.13-rc1) and merge that to
clk-next that would be perfect as it would minimize the amount of changes
merged by Simon.
--
Regards,
Laurent Pinchart
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox