* [PATCH] ARM: dts: sun7i: add pin muxing options for UART2
From: Maxime Ripard @ 2014-01-15 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389710990-16384-1-git-send-email-wens@csie.org>
On Tue, Jan 14, 2014 at 10:49:50PM +0800, Chen-Yu Tsai wrote:
> UART2 is used on CubieTruck to connect to the Bluetooth module.
> Add the pin set used in this case.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Queued for 3.15, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140115/93282b61/attachment.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH] pinctrl: sunxi: Honor GPIO output initial vaules
From: Maxime Ripard @ 2014-01-15 10:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64hs1B=5Ss40AD6K=GTOiYqJrG_vCOxrPzWmjjVgFGvXg@mail.gmail.com>
Hi Chen-Yu,
Nice catch :)
On Wed, Jan 15, 2014 at 04:21:12PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Wed, Jan 15, 2014 at 8:37 AM, Ma Haijun <mahaijuns@gmail.com> wrote:
> > Hi,
> >
> > I think it is better to set the output value first to avoid glitch.
>
> If I understand the user manual correctly, setting the output value
> before changing the pin to output function first will have no effect.
I just tested it on my A31, and it is working as expected (the output
value isn't output until the direction is changed).
It would be great if you could test this as well on your device, and
change it like suggested.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140115/b83fc452/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] clk: exynos4: Fix spacing related checkpatch errors
From: Sachin Kamat @ 2014-01-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389780070-4959-1-git-send-email-sachin.kamat@linaro.org>
Silences the following type of checkpatch errors:
ERROR: space prohibited after that open parenthesis '('
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/clk/samsung/clk-exynos4.c | 50 ++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 25 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c b/drivers/clk/samsung/clk-exynos4.c
index 12a9f28f9f17..3f412b4ef3e3 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -945,13 +945,13 @@ static struct of_device_id ext_clk_match[] __initdata = {
static struct samsung_pll_rate_table exynos4210_apll_rates[] __initdata = {
PLL_45XX_RATE(1200000000, 150, 3, 1, 28),
PLL_45XX_RATE(1000000000, 250, 6, 1, 28),
- PLL_45XX_RATE( 800000000, 200, 6, 1, 28),
- PLL_45XX_RATE( 666857142, 389, 14, 1, 13),
- PLL_45XX_RATE( 600000000, 100, 4, 1, 13),
- PLL_45XX_RATE( 533000000, 533, 24, 1, 5),
- PLL_45XX_RATE( 500000000, 250, 6, 2, 28),
- PLL_45XX_RATE( 400000000, 200, 6, 2, 28),
- PLL_45XX_RATE( 200000000, 200, 6, 3, 28),
+ PLL_45XX_RATE(800000000, 200, 6, 1, 28),
+ PLL_45XX_RATE(666857142, 389, 14, 1, 13),
+ PLL_45XX_RATE(600000000, 100, 4, 1, 13),
+ PLL_45XX_RATE(533000000, 533, 24, 1, 5),
+ PLL_45XX_RATE(500000000, 250, 6, 2, 28),
+ PLL_45XX_RATE(400000000, 200, 6, 2, 28),
+ PLL_45XX_RATE(200000000, 200, 6, 3, 28),
{ /* sentinel */ }
};
@@ -959,10 +959,10 @@ static struct samsung_pll_rate_table exynos4210_epll_rates[] __initdata = {
PLL_4600_RATE(192000000, 48, 3, 1, 0, 0),
PLL_4600_RATE(180633605, 45, 3, 1, 10381, 0),
PLL_4600_RATE(180000000, 45, 3, 1, 0, 0),
- PLL_4600_RATE( 73727996, 73, 3, 3, 47710, 1),
- PLL_4600_RATE( 67737602, 90, 4, 3, 20762, 1),
- PLL_4600_RATE( 49151992, 49, 3, 3, 9961, 0),
- PLL_4600_RATE( 45158401, 45, 3, 3, 10381, 0),
+ PLL_4600_RATE(73727996, 73, 3, 3, 47710, 1),
+ PLL_4600_RATE(67737602, 90, 4, 3, 20762, 1),
+ PLL_4600_RATE(49151992, 49, 3, 3, 9961, 0),
+ PLL_4600_RATE(45158401, 45, 3, 3, 10381, 0),
{ /* sentinel */ }
};
@@ -971,7 +971,7 @@ static struct samsung_pll_rate_table exynos4210_vpll_rates[] __initdata = {
PLL_4650_RATE(324000000, 53, 2, 1, 1024, 1, 1, 1),
PLL_4650_RATE(259617187, 63, 3, 1, 1950, 0, 20, 1),
PLL_4650_RATE(110000000, 53, 3, 2, 2048, 0, 17, 0),
- PLL_4650_RATE( 55360351, 53, 3, 3, 2417, 0, 17, 0),
+ PLL_4650_RATE(55360351, 53, 3, 3, 2417, 0, 17, 0),
{ /* sentinel */ }
};
@@ -982,14 +982,14 @@ static struct samsung_pll_rate_table exynos4x12_apll_rates[] __initdata = {
PLL_35XX_RATE(1200000000, 200, 4, 0),
PLL_35XX_RATE(1100000000, 275, 6, 0),
PLL_35XX_RATE(1000000000, 125, 3, 0),
- PLL_35XX_RATE( 900000000, 150, 4, 0),
- PLL_35XX_RATE( 800000000, 100, 3, 0),
- PLL_35XX_RATE( 700000000, 175, 3, 1),
- PLL_35XX_RATE( 600000000, 200, 4, 1),
- PLL_35XX_RATE( 500000000, 125, 3, 1),
- PLL_35XX_RATE( 400000000, 100, 3, 1),
- PLL_35XX_RATE( 300000000, 200, 4, 2),
- PLL_35XX_RATE( 200000000, 100, 3, 2),
+ PLL_35XX_RATE(900000000, 150, 4, 0),
+ PLL_35XX_RATE(800000000, 100, 3, 0),
+ PLL_35XX_RATE(700000000, 175, 3, 1),
+ PLL_35XX_RATE(600000000, 200, 4, 1),
+ PLL_35XX_RATE(500000000, 125, 3, 1),
+ PLL_35XX_RATE(400000000, 100, 3, 1),
+ PLL_35XX_RATE(300000000, 200, 4, 2),
+ PLL_35XX_RATE(200000000, 100, 3, 2),
{ /* sentinel */ }
};
@@ -997,10 +997,10 @@ static struct samsung_pll_rate_table exynos4x12_epll_rates[] __initdata = {
PLL_36XX_RATE(192000000, 48, 3, 1, 0),
PLL_36XX_RATE(180633605, 45, 3, 1, 10381),
PLL_36XX_RATE(180000000, 45, 3, 1, 0),
- PLL_36XX_RATE( 73727996, 73, 3, 3, 47710),
- PLL_36XX_RATE( 67737602, 90, 4, 3, 20762),
- PLL_36XX_RATE( 49151992, 49, 3, 3, 9961),
- PLL_36XX_RATE( 45158401, 45, 3, 3, 10381),
+ PLL_36XX_RATE(73727996, 73, 3, 3, 47710),
+ PLL_36XX_RATE(67737602, 90, 4, 3, 20762),
+ PLL_36XX_RATE(49151992, 49, 3, 3, 9961),
+ PLL_36XX_RATE(45158401, 45, 3, 3, 10381),
{ /* sentinel */ }
};
@@ -1011,7 +1011,7 @@ static struct samsung_pll_rate_table exynos4x12_vpll_rates[] __initdata = {
PLL_36XX_RATE(266000000, 133, 3, 2, 0),
PLL_36XX_RATE(160000000, 160, 3, 3, 0),
PLL_36XX_RATE(106031250, 53, 3, 2, 1024),
- PLL_36XX_RATE( 53015625, 53, 3, 3, 1024),
+ PLL_36XX_RATE(53015625, 53, 3, 3, 1024),
{ /* sentinel */ }
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] clk: samsung: pll: Fix checkpatch errors
From: Sachin Kamat @ 2014-01-15 10:01 UTC (permalink / raw)
To: linux-arm-kernel
Fixes the following type of checkpatch errors:
ERROR: return is not a function, parentheses are not required
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/clk/samsung/clk-pll.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/samsung/clk-pll.c b/drivers/clk/samsung/clk-pll.c
index 529e11dc2c6b..f2372fca0136 100644
--- a/drivers/clk/samsung/clk-pll.c
+++ b/drivers/clk/samsung/clk-pll.c
@@ -99,7 +99,7 @@ static inline bool samsung_pll35xx_mp_change(
old_mdiv = (pll_con >> PLL35XX_MDIV_SHIFT) & PLL35XX_MDIV_MASK;
old_pdiv = (pll_con >> PLL35XX_PDIV_SHIFT) & PLL35XX_PDIV_MASK;
- return (rate->mdiv != old_mdiv || rate->pdiv != old_pdiv);
+ return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv;
}
static int samsung_pll35xx_set_rate(struct clk_hw *hw, unsigned long drate,
@@ -207,8 +207,8 @@ static inline bool samsung_pll36xx_mpk_change(
old_pdiv = (pll_con0 >> PLL36XX_PDIV_SHIFT) & PLL36XX_PDIV_MASK;
old_kdiv = (pll_con1 >> PLL36XX_KDIV_SHIFT) & PLL36XX_KDIV_MASK;
- return (rate->mdiv != old_mdiv || rate->pdiv != old_pdiv ||
- rate->kdiv != old_kdiv);
+ return rate->mdiv != old_mdiv || rate->pdiv != old_pdiv ||
+ rate->kdiv != old_kdiv;
}
static int samsung_pll36xx_set_rate(struct clk_hw *hw, unsigned long drate,
@@ -320,8 +320,8 @@ static bool samsung_pll45xx_mp_change(u32 pll_con0, u32 pll_con1,
old_pdiv = (pll_con0 >> PLL45XX_PDIV_SHIFT) & PLL45XX_PDIV_MASK;
old_afc = (pll_con1 >> PLL45XX_AFC_SHIFT) & PLL45XX_AFC_MASK;
- return (old_mdiv != rate->mdiv || old_pdiv != rate->pdiv
- || old_afc != rate->afc);
+ return old_mdiv != rate->mdiv || old_pdiv != rate->pdiv
+ || old_afc != rate->afc;
}
static int samsung_pll45xx_set_rate(struct clk_hw *hw, unsigned long drate,
@@ -467,8 +467,8 @@ static bool samsung_pll46xx_mpk_change(u32 pll_con0, u32 pll_con1,
old_pdiv = (pll_con0 >> PLL46XX_PDIV_SHIFT) & PLL46XX_PDIV_MASK;
old_kdiv = (pll_con1 >> PLL46XX_KDIV_SHIFT) & PLL46XX_KDIV_MASK;
- return (old_mdiv != rate->mdiv || old_pdiv != rate->pdiv
- || old_kdiv != rate->kdiv);
+ return old_mdiv != rate->mdiv || old_pdiv != rate->pdiv
+ || old_kdiv != rate->kdiv;
}
static int samsung_pll46xx_set_rate(struct clk_hw *hw, unsigned long drate,
--
1.7.9.5
^ permalink raw reply related
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: David Laight @ 2014-01-15 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87bnzekz5l.fsf@natisbad.org>
From: Arnaud Ebalard
> Sent: 14 January 2014 21:54
> To: Sarah Sharp
> Cc: linux-usb at vger.kernel.org; linux-arm-kernel at lists.infradead.org; Bj?rn Mork
> Subject: Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
>
> Hi Sarah,
>
> Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
>
> >> I can add the following:
> >>
> >> 2) I just tested the copy of the small files using the ICY DOCK
> >> MB981U3S-1S connected to my ReadyNAS 102 *on a 3.11.7 kernel*
> >> and it completed successfully.
> >
> > Please try a 3.13-rc7 kernel after running `git revert 35773dac5f86`.
>
> I tried current 3.13.0-rc8 w/ 35773dac5f86 reverted and the result is
> the same:
That patch only affects an error code and stops the fs code retrying for ever.
Does everything work if you comment out the code in xhci-ring.c that adds
NOP TRBs to the ring end in order to stop the LINK TRB appearing in the middle
of a TB.
The ethernet code needs it, but the disk transfers are (probably) aligned
such that they don't.
If that all works I'll look at writing a patch that either doesn't use NOPs
or checks the alignment of all the fragments.
David
^ permalink raw reply
* [RFC PATCH V2 3/4] dt-bindings: pci: xgene pcie device tree bindings
From: Arnd Bergmann @ 2014-01-15 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389742458-7693-4-git-send-email-tinamdar@apm.com>
On Wednesday 15 January 2014, Tanmay Inamdar wrote:
> This patch adds the bindings for X-Gene PCIe driver. The driver resides
> under 'drivers/pci/host/pci-xgene.c' file.
>
> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com>
> ---
> .../devicetree/bindings/pci/xgene-pcie.txt | 45 ++++++++++++++++++++
> 1 file changed, 45 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/xgene-pcie.txt
>
> diff --git a/Documentation/devicetree/bindings/pci/xgene-pcie.txt b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
> new file mode 100644
> index 0000000..19b9c28
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/xgene-pcie.txt
> @@ -0,0 +1,45 @@
> +* AppliedMicro X-Gene PCIe interface
> +
> +Required properties:
> +- status: Either "ok" or "disabled".
"status" isn't normally a required property. The default interpretation is
that a node without a status property is active.
> +- device_type: set to "pci"
> +- compatible: should contain "xgene,pcie" to identify the core.
> +- reg: base addresses and lengths of the pcie controller configuration
> + space register.
Doesn't match the code or example: You only list one area here, but
you actually need to register sets.
Looks good otherwise now.
Arnd
^ permalink raw reply
* [PATCH v2 06/12] at91: smc: Adds helper functions to validate and clip the smc timings.
From: Jean-Jacques Hiblot @ 2014-01-15 9:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D65880.10301@atmel.com>
2014/1/15 Nicolas Ferre <nicolas.ferre@atmel.com>:
> On 09/01/2014 13:31, Jean-Jacques Hiblot :
>> This patchs implememnts 2 functions to help with the configuration of a
>> chip-select's timing:
>> * sam9_smc_check_cs_configuration : checks that the values would fit in the
>> registers.
>> * sam9_smc_clip_cs_configuration : clip the values to their maximum.
>>
>> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
>> ---
>> arch/arm/mach-at91/include/mach/at91sam9_smc.h | 2 +
>> arch/arm/mach-at91/sam9_smc.c | 77 ++++++++++++++++++++++++++
>> 2 files changed, 79 insertions(+)
>>
>> diff --git a/arch/arm/mach-at91/include/mach/at91sam9_smc.h b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>> index c3e29311..615ac56 100644
>> --- a/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>> +++ b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
>> @@ -47,6 +47,8 @@ extern void sam9_smc_read_mode(int id, int cs, struct sam9_smc_config *config);
>> extern void sam9_smc_write_mode(int id, int cs, struct sam9_smc_config *config);
>> extern void sam9_smc_cs_read(void __iomem *, struct sam9_smc_config *config);
>> extern void sam9_smc_cs_configure(void __iomem *, struct sam9_smc_config *cfg);
>> +extern int sam9_smc_check_cs_configuration(struct sam9_smc_config *config);
>> +extern void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config);
>> #endif
>>
>> #define AT91_SMC_SETUP 0x00 /* Setup Register for CS n */
>> diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
>> index d7a6156..fe3c492 100644
>> --- a/arch/arm/mach-at91/sam9_smc.c
>> +++ b/arch/arm/mach-at91/sam9_smc.c
>> @@ -23,6 +23,83 @@
>>
>> static void __iomem *smc_base_addr[2];
>>
>> +static int count_trailing_zeroes(u32 x)
>
> Don't we have something generic for this?
>
> Check include/asm-generic/bitops/count_zeros.h
I wonder how I could have missed this one :o)
>
>> +{
>> + int ret = 0;
>> + if (!(x & 0xFFFF)) {
>> + ret += 16;
>> + x = x >> 16;
>> + }
>> + if (!(x & 0xFF)) {
>> + ret += 8;
>> + x = x >> 8;
>> + }
>> + if (!(x & 0xF)) {
>> + ret += 4;
>> + x = x >> 4;
>> + }
>> + if (!(x & 0x3)) {
>> + ret += 2;
>> + x = x >> 2;
>> + }
>> + if (!(x & 0x1)) {
>> + ret += 1;
>> + x = x >> 1;
>> + }
>> + if (!(x & 0x1))
>> + ret += 1;
>> +
>> + return ret;
>> +}
>> +
>> +
>> +#define __CHECK_CFG(config, x, y) do {\
>> + if (x##_(config->y) > x) {\
>> + pr_debug("error: %s (0x%x) is out of range\n", #y,\
>> + config->y >> count_trailing_zeroes(x));\
>> + return -EINVAL;\
>> + } \
>> + } while (0)
>
> I do not like the use of macro for this. You can convert them to
> functions and it would increase readability. I am pretty confident that
> gcc will optimize it so that is won't impact performance.
It's not a matter of performance. I wanted to use the stringification
for the debug message.
>
>> +int sam9_smc_check_cs_configuration(struct sam9_smc_config *config)
>> +{
>> + __CHECK_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
>> + __CHECK_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
>> + __CHECK_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
>> + __CHECK_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
>> + __CHECK_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
>> + __CHECK_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
>> + __CHECK_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
>> + __CHECK_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
>> + __CHECK_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
>> + __CHECK_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
>> + __CHECK_CFG(config, AT91_SMC_TDF, tdf_cycles);
>> + return 0;
>> +}
>> +
>> +#define __CLIP_CFG(config, x, y) do {\
>> + if (x##_(config->y) > x) {\
>> + config->y = x >> count_trailing_zeroes(x);\
>> + pr_debug("clipping %s to %d\n", #y, config->y);\
>> + } \
>> + } while (0)
>
> Ditto.
>
>> +
>> +void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config)
>> +{
>> + __CLIP_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
>> + __CLIP_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
>> + __CLIP_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
>> + __CLIP_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
>> + __CLIP_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
>> + __CLIP_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
>> + __CLIP_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
>> + __CLIP_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
>> + __CLIP_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
>> + __CLIP_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
>> + __CLIP_CFG(config, AT91_SMC_TDF, tdf_cycles);
>> +
>> +}
>> +
>> static void sam9_smc_cs_write_mode(void __iomem *base,
>> struct sam9_smc_config *config)
>> {
>>
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* [RFC 2/2] arm: Get rid of meminfo
From: Russell King - ARM Linux @ 2014-01-15 9:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389765322-28582-3-git-send-email-lauraa@codeaurora.org>
On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
The reason I never killed meminfo was that for some of the functions here
is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be
specified as a separate bank of memory, even if it is contiguous with the
previous block. This is so that the functions which walk the page arrays
can do so efficiently (without having to convert from a PFN to a struct
page for every page in the system, which is very inefficient.)
Memblock appends contiguous blocks together, so it reports only one block.
This means that if we take the struct page for the start of the block, and
the struct page for the end of the block, these may be different struct
page arrays, and we can't walk it by just incrementing the struct page
pointer.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH V6 6/8] Add EFI stub for ARM
From: Ard Biesheuvel @ 2014-01-15 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFECyb9jbVHjM7--tRgbjfS9_MaAAvOhR3qXEKPKS6eW23V9Kg@mail.gmail.com>
On 15 January 2014 03:16, Roy Franz <roy.franz@linaro.org> wrote:
> On Tue, Jan 14, 2014 at 5:47 PM, Roy Franz <roy.franz@linaro.org> wrote:
>> On Tue, Jan 14, 2014 at 1:05 AM, Ard Biesheuvel
>> <ard.biesheuvel@linaro.org> wrote:
>>> On 10 January 2014 17:30, Roy Franz <roy.franz@linaro.org> wrote:
>>>> This patch adds EFI stub support for the ARM Linux kernel. The EFI stub
>>>> operates similarly to the x86 stub: it is a shim between the EFI firmware
>>>> and the normal zImage entry point, and sets up the environment that the
>>>> zImage is expecting. This includes loading the initrd (optionaly) and
>>>> device tree from the system partition based on the kernel command line.
>>>> The stub updates the device tree as necessary, adding entries for EFI
>>>> runtime services. The PE/COFF "MZ" header at offset 0 results in the
>>>> first instruction being an add that corrupts r5, which is not used by
>>>> the zImage interface.
>>>>
>>>> Signed-off-by: Roy Franz <roy.franz@linaro.org>
>>>> Acked-by: Grant Likely <grant.likely@linaro.org>
>>>> ---
>>>
>>> [...]
>>>
>>>> diff --git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
>>>> new file mode 100644
>>>> index 0000000..dbb7101
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/compressed/efi-header.S
>>>> @@ -0,0 +1,117 @@
>>>> +@ Copyright (C) 2013 Linaro Ltd; <roy.franz@linaro.org>
>>>> +@
>>>> +@ This file contains the PE/COFF header that is part of the
>>>> +@ EFI stub.
>>>> +@
>>>> +
>>>> + .org 0x3c
>>>> + @
>>>> + @ The PE header can be anywhere in the file, but for
>>>> + @ simplicity we keep it together with the MSDOS header
>>>> + @ The offset to the PE/COFF header needs to be at offset
>>>> + @ 0x3C in the MSDOS header.
>>>> + @ The only 2 fields of the MSDOS header that are used are this
>>>> + @ PE/COFF offset, and the "MZ" bytes at offset 0x0.
>>>> + @
>>>> + .long pe_header @ Offset to the PE header.
>>>> +
>>>> + .align 3
Btw you also have a whitespace error here.
>>>> +pe_header:
>>>> + .ascii "PE"
>>>> + .short 0
>>>> +
>>>> +coff_header:
>>>> + .short 0x01c2 @ ARM or Thumb
>>>
>>> Could you explain why you are using 0x1c2 (Thumb) here and not 0x1c0 (ARM) ?
>>>
>>> Cheers,
>>> Ard.
>>
>> Nope. It should be 0x1c0.
>>
>> Roy
>
> OK, now I resolved the nagging feeling that I had already fixed
> this... Right now, the EDK2 UEFI implementation
> requires the machine type for ARM to be "0x1c2". I don't think that
> this is correct, but correcting this in EDK2 slipped through
> the cracks, but is now back on my todo list.
>
> I think that for now we should leave this as 0x1c2 so that the
> unpatched EDK2 builds will boot it, and some time after EDK2 is
> updated
> this can be changed. I'll work on a patch for EDK2 and get the
> discussion going on that list to resolve this in EDK2.
>
OK. I have updated sbsigntool (Linaro's version) so it supports
either, but I agree that using the ARM constant is the correct way.
--
Ard.
^ permalink raw reply
* imx6dl/imx6q fec rmii mode with external ref_clk
From: Philippe De Muyter @ 2014-01-15 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115073536.GD1914@S2101-09.ap.freescale.net>
On Wed, Jan 15, 2014 at 03:35:40PM +0800, Shawn Guo wrote:
> On Tue, Jan 14, 2014 at 04:30:12PM +0100, Philippe De Muyter wrote:
> > Hi,
> >
> > On the custom board we are developping (imx6q and imx6dl), we have connected
> > the fec to a switch chip using rmii mode, and we let the switch provide the
> > reference clock to gpio_16.
> >
> > I work currently with 3.13-rc8 and
> >
> > - I do not have ethernet access working (tx timeout)
> > - I do not find in the dtb files a description of the pad settings for the
> > RMII mode
> > - when searching about the setting for bit 21 ing GPR1, which seems to
> > be important for my setting to work, I found the following mail:
> > http://www.spinics.net/lists/devicetree/msg06450.html
>
> Just for testing your hardware, does the following change make the
> Ethernet work for you?
>
> Shawn
>
> diff --git a/arch/arm/mach-imx/mach-imx6q.c
> b/arch/arm/mach-imx/mach-imx6q.c
> index e51e3da..be8d074 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -188,7 +188,7 @@ static void __init imx6q_1588_init(void)
> if (!IS_ERR(gpr))
> regmap_update_bits(gpr, IOMUXC_GPR1,
> IMX6Q_GPR1_ENET_CLK_SEL_MASK,
> - IMX6Q_GPR1_ENET_CLK_SEL_ANATOP);
> + 0);
> else
> pr_err("failed to find fsl,imx6q-iomux-gpr regmap\n");
>
I tried your patch (above mine, see below), and here is what I get :
[ 180.015659] fec 2188000.ethernet eth0: Freescale FEC PHY driver [Generic PHY] (mii_bus:phy_addr=2188000.ethernet:01, irq=-1)
[ 180.015861] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 182.013790] libphy: 2188000.ethernet:01 - Link is Up - 100/Full
[ 182.014134] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 226.001667] ------------[ cut here ]------------
[ 226.001740] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x27c/0x2a0()
[ 226.001758] NETDEV WATCHDOG: eth0 (fec): transmit queue 0 timed out
Here are my patches (I have called my board imx6dl-p6-2094):
Do I need to replace the hex value after MX6QDL_PAD_GPIO_16__ENET_REF_CLK
by something else ?
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d57c1a6..bc115f7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -136,6 +136,7 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx53-mba53.dtb \
imx53-qsb.dtb \
imx53-smd.dtb \
+ imx6dl-p6-2094.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
imx6dl-wandboard.dtb \
diff --git a/arch/arm/boot/dts/imx6dl-p6-2094.dts b/arch/arm/boot/dts/imx6dl-p6-2094.dts
new file mode 100644
index 0000000..526e83a
--- /dev/null
+++ b/arch/arm/boot/dts/imx6dl-p6-2094.dts
@@ -0,0 +1,35 @@
+/*
+ * Copyright (C) 2013 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include "imx6qdl-sabresd.dtsi"
+
+&usdhc4 {
+ non-removable;
+#if 0
+ vmmc-supply = <®_3p3v>;
+#endif
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc4_1>;
+ bus-width = <8>;
+ status = "okay";
+};
+
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet_4>;
+ phy-mode = "rmii";
+ status = "okay";
+};
+
+/ {
+ model = "Macq i.MX6 DualLite P6-2094 Board";
+ compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index e75e11b..d850ff1 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -181,7 +181,9 @@
MX6QDL_PAD_NANDF_CLE__GPIO6_IO07 0x80000000
MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000
MX6QDL_PAD_EIM_D22__GPIO3_IO22 0x80000000
+#if 0 /* conflicts with pinctrl_enet_4:MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN */
MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x80000000
+#endif
>;
};
};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..7a0b341 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -729,6 +729,22 @@
MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0
>;
};
+
+ pinctrl_enet_4: enetgrp-4 {
+ fsl,pins = <
+ MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
+ MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
+ MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x1b0b0 /* RMII */
+ MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_RX_ER__ENET_RX_ER 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN 0x1b0b0 /* MII/RMII */
+ MX6QDL_PAD_GPIO_19__ENET_TX_ER 0x1b0b0 /* MII/RMII */
+ >;
+ };
};
esai {
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply related
* [PATCH v2 06/12] at91: smc: Adds helper functions to validate and clip the smc timings.
From: Nicolas Ferre @ 2014-01-15 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389270709-32662-7-git-send-email-jjhiblot@traphandler.com>
On 09/01/2014 13:31, Jean-Jacques Hiblot :
> This patchs implememnts 2 functions to help with the configuration of a
> chip-select's timing:
> * sam9_smc_check_cs_configuration : checks that the values would fit in the
> registers.
> * sam9_smc_clip_cs_configuration : clip the values to their maximum.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com>
> ---
> arch/arm/mach-at91/include/mach/at91sam9_smc.h | 2 +
> arch/arm/mach-at91/sam9_smc.c | 77 ++++++++++++++++++++++++++
> 2 files changed, 79 insertions(+)
>
> diff --git a/arch/arm/mach-at91/include/mach/at91sam9_smc.h b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
> index c3e29311..615ac56 100644
> --- a/arch/arm/mach-at91/include/mach/at91sam9_smc.h
> +++ b/arch/arm/mach-at91/include/mach/at91sam9_smc.h
> @@ -47,6 +47,8 @@ extern void sam9_smc_read_mode(int id, int cs, struct sam9_smc_config *config);
> extern void sam9_smc_write_mode(int id, int cs, struct sam9_smc_config *config);
> extern void sam9_smc_cs_read(void __iomem *, struct sam9_smc_config *config);
> extern void sam9_smc_cs_configure(void __iomem *, struct sam9_smc_config *cfg);
> +extern int sam9_smc_check_cs_configuration(struct sam9_smc_config *config);
> +extern void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config);
> #endif
>
> #define AT91_SMC_SETUP 0x00 /* Setup Register for CS n */
> diff --git a/arch/arm/mach-at91/sam9_smc.c b/arch/arm/mach-at91/sam9_smc.c
> index d7a6156..fe3c492 100644
> --- a/arch/arm/mach-at91/sam9_smc.c
> +++ b/arch/arm/mach-at91/sam9_smc.c
> @@ -23,6 +23,83 @@
>
> static void __iomem *smc_base_addr[2];
>
> +static int count_trailing_zeroes(u32 x)
Don't we have something generic for this?
Check include/asm-generic/bitops/count_zeros.h
> +{
> + int ret = 0;
> + if (!(x & 0xFFFF)) {
> + ret += 16;
> + x = x >> 16;
> + }
> + if (!(x & 0xFF)) {
> + ret += 8;
> + x = x >> 8;
> + }
> + if (!(x & 0xF)) {
> + ret += 4;
> + x = x >> 4;
> + }
> + if (!(x & 0x3)) {
> + ret += 2;
> + x = x >> 2;
> + }
> + if (!(x & 0x1)) {
> + ret += 1;
> + x = x >> 1;
> + }
> + if (!(x & 0x1))
> + ret += 1;
> +
> + return ret;
> +}
> +
> +
> +#define __CHECK_CFG(config, x, y) do {\
> + if (x##_(config->y) > x) {\
> + pr_debug("error: %s (0x%x) is out of range\n", #y,\
> + config->y >> count_trailing_zeroes(x));\
> + return -EINVAL;\
> + } \
> + } while (0)
I do not like the use of macro for this. You can convert them to
functions and it would increase readability. I am pretty confident that
gcc will optimize it so that is won't impact performance.
> +int sam9_smc_check_cs_configuration(struct sam9_smc_config *config)
> +{
> + __CHECK_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
> + __CHECK_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
> + __CHECK_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
> + __CHECK_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
> + __CHECK_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
> + __CHECK_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
> + __CHECK_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
> + __CHECK_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
> + __CHECK_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
> + __CHECK_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
> + __CHECK_CFG(config, AT91_SMC_TDF, tdf_cycles);
> + return 0;
> +}
> +
> +#define __CLIP_CFG(config, x, y) do {\
> + if (x##_(config->y) > x) {\
> + config->y = x >> count_trailing_zeroes(x);\
> + pr_debug("clipping %s to %d\n", #y, config->y);\
> + } \
> + } while (0)
Ditto.
> +
> +void sam9_smc_clip_cs_configuration(struct sam9_smc_config *config)
> +{
> + __CLIP_CFG(config, AT91_SMC_NWESETUP, nwe_setup);
> + __CLIP_CFG(config, AT91_SMC_NCS_WRSETUP, ncs_write_setup);
> + __CLIP_CFG(config, AT91_SMC_NRDSETUP, nrd_setup);
> + __CLIP_CFG(config, AT91_SMC_NCS_RDSETUP, ncs_read_setup);
> + __CLIP_CFG(config, AT91_SMC_NWEPULSE, nwe_pulse);
> + __CLIP_CFG(config, AT91_SMC_NCS_WRPULSE, ncs_write_pulse);
> + __CLIP_CFG(config, AT91_SMC_NRDPULSE, nrd_pulse);
> + __CLIP_CFG(config, AT91_SMC_NCS_RDPULSE, ncs_read_pulse);
> + __CLIP_CFG(config, AT91_SMC_NWECYCLE, write_cycle);
> + __CLIP_CFG(config, AT91_SMC_NRDCYCLE, read_cycle);
> + __CLIP_CFG(config, AT91_SMC_TDF, tdf_cycles);
> +
> +}
> +
> static void sam9_smc_cs_write_mode(void __iomem *base,
> struct sam9_smc_config *config)
> {
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: S3C[24|64]xx: move includes back under <mach/> scope
From: Arnd Bergmann @ 2014-01-15 9:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHbNUh29qGSt-isqOAdVVO3x0w2mDTVnKeH+Sc_rkfkOiXc_mA@mail.gmail.com>
On Wednesday 15 January 2014 14:41:01 Tushar Behera wrote:
> > diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c
> > index c4efa1c2a5d1..a9f7a37c4173 100644
> > --- a/arch/arm/plat-samsung/pm-gpio.c
> > +++ b/arch/arm/plat-samsung/pm-gpio.c
> > @@ -19,12 +19,7 @@
> > #include <linux/io.h>
> > #include <linux/gpio.h>
> >
> > -#ifdef CONFIG_ARCH_S3C24XX
> > -#include <linux/platform_data/gpio-samsung-s3c24xx.h>
> > -#endif
> > -#ifdef CONFIG_ARCH_S3C64XX
> > -#include <linux/platform_data/gpio-samsung-s3c64xx.h>
> > -#endif
> > +#include <mach/gpio-samsung.h>
>
> This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX
> || CONFIG_ARCH_S3C64XX. Currently generating build errors for
> s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
> next-20140115.
>
I noticed the same problem, but I think a better solution would
be to do the same change for s5p that Linus has done for s3c,
which is to move the nonstandard contents of mach/gpio.h to
mach/gpio-samsung.h.
Arnd
^ permalink raw reply
* [PATCH] ARM: sunxi: change the AllWinner A1X to sunxi
From: Arnd Bergmann @ 2014-01-15 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115091006.GF3377@lukather>
On Wednesday 15 January 2014 10:10:06 Maxime Ripard wrote:
> On Thu, Jan 09, 2014 at 04:34:04PM +0100, Gerardo Di Iorio wrote:
> > Change the AllWinner A1X SOCs to Allwinner Sunxi SOCs
> >
> > Signed-off-by: Gerardo Di Iorio <arete74@gmail.com>
> > ---
> > arch/arm/mach-sunxi/Kconfig | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > index 547004c..adb2574 100644
> > --- a/arch/arm/mach-sunxi/Kconfig
> > +++ b/arch/arm/mach-sunxi/Kconfig
> > @@ -1,5 +1,5 @@
> > config ARCH_SUNXI
> > - bool "Allwinner A1X SOCs" if ARCH_MULTI_V7
> > + bool "Allwinner Sunxi SOCs" if ARCH_MULTI_V7
>
> I wonder if the sunxi (apart the weird letter case) is actually
> needed. Maybe we can just put "Allwinner SoCs" (it would be great if
> you could fix the SoCs case too).
If you want to have exact naming, try to find something that excludes the
old Sun3i (F20) and earlier chips (unless someone is already planning
to work on them). Maybe also mention the "Boxchip" name, although that
seems to be falling out of use these days.
Arnd
^ permalink raw reply
* [PATCH v4 2/4] pinctrl: Add pinctrl binding for Broadcom Capri SoCs
From: Linus Walleij @ 2014-01-15 9:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D5896B.6000209@broadcom.com>
On Tue, Jan 14, 2014 at 8:00 PM, Sherman Yin <syin@broadcom.com> wrote:
> Great! Is there anything else you would like to see changed before this
> patchset can be accepted?
I'd like some sign of life from the DT binding maintainers.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
From: Mike Turquette @ 2014-01-15 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D4B502.3080409@codeaurora.org>
Quoting Saravana Kannan (2014-01-13 19:54:42)
> On 01/08/2014 05:51 PM, Mike Turquette wrote:
> > Quoting Stephen Boyd (2013-12-23 17:12:26)
> >> Add support to the clock core so that drivers can pass in a
> >> regmap. If no regmap is specified try to query the device that's
> >> registering the clock for its regmap. This should allow drivers
> >> to use the core regmap helpers. This is based on a similar design
> >> in the regulator framework.
> >>
> >> Cc: Mark Brown <broonie@kernel.org>
> >> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >> ---
> >> drivers/clk/clk.c | 8 ++++++++
> >> include/linux/clk-provider.h | 7 +++++++
> >> 2 files changed, 15 insertions(+)
> >>
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index 9ad7b71..5e71f5c 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -20,6 +20,7 @@
> >> #include <linux/device.h>
> >> #include <linux/init.h>
> >> #include <linux/sched.h>
> >> +#include <linux/regmap.h>
> >>
> >> static DEFINE_SPINLOCK(enable_lock);
> >> static DEFINE_MUTEX(prepare_lock);
> >> @@ -1834,6 +1835,13 @@ static int _clk_register(struct device *dev, struct clk_hw *hw, struct clk *clk)
> >> clk->num_parents = hw->init->num_parents;
> >> hw->clk = clk;
> >>
> >> + if (hw->init->regmap)
> >> + hw->regmap = hw->init->regmap;
> >
> > Hi Stephen,
> >
> > The whole series looks good to me except for the placement of the regmap
> > details inside struct clk_hw. That structure exists only to hide struct
> > clk from the hardware-specific clock structure and I'd not like to set
> > the precedent of shoving per-clock data into it.
> >
> > As an alternative, how about finding a way to put these per-clock regmap
> > details into the hardware-specific clock structure? I understand that
> > you want to make these ops available to others, which is why they are in
> > the public struct clk_hw. I'm just wondering if that is the right way to
> > do it...
> >
> > Patch #3 illustrates the sort of struct-member-creep that worries me.
> > What is to stop someone from putting "unsigned int divider_reg" or
> > "unsigned int mux_reg", and then the thing just keeps growing.
>
> I agree with Mike here. This definitely encourages struct field creep if
> more people want to use it.
>
> I talked to Stephen is person and my recommendation is to not have any
> new fields other than struct regmap in clk_hw and remove the above 2
> lines of code.
>
> >> + else if (dev && dev_get_regmap(dev, NULL))
> >> + hw->regmap = dev_get_regmap(dev, NULL);
>
> Move "struct regmap *regmap" into struct clk_hw (since it's truly
> reusable across clock types and is technically purely HW related) and
> update it from the device's regmap like above.
Hi Saravana,
Thanks for your comments. In the paragraph above you mean "struct
clk_hw" or do you mean the hardware-specific structure(s) defined in a
clock driver?
>
> We can then provide __clk_regmap_enable(regmap, offset, enable_mask)
> helper functions. Then clock specific functions can use the helper. We
> can even a simple macro to generate these wrappers.
>
> #define DEFINE_REGMAP_EN_DIS(clktype) \
>
> int clk_type##_enable(clktype *c, ....) { }
> int clk_type##_disable(clktype *c, ....) { }
>
>
> That to me seems like a reasonable compromise.
Providing common functions for the basic case (e.g. read-modify-write on
a register using a known mask) is reasonable. But that is exactly what
the existing basic clock types do (sans regmap) and they have all become
pretty ugly over time. And the clk-composite implementation just makes
me a sad panda.
I'm not opposed to providing public implementations of clk_ops callbacks
that use regmap, but I will be very mindful of any feature creep in the
future.
I am still unconvinced that adding struct regmap to struct clk_hw is a
good idea. The regmap data is a function of hardware-specific details
and those details always have and always will belong in the clock
driver.
Regards,
Mike
>
> Thanks,
> Saravana
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
^ permalink raw reply
* [PATCH v5 net-next 1/4] sh_eth: Use bool as return type of sh_eth_is_gether()
From: Joe Perches @ 2014-01-15 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389766341-14001-2-git-send-email-horms+renesas@verge.net.au>
On Wed, 2014-01-15 at 15:12 +0900, Simon Horman wrote:
> Return a boolean and use true and false.
[]
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
[]
> @@ -310,12 +310,12 @@ static const u16 sh_eth_offset_fast_sh3_sh2[SH_ETH_MAX_REGISTER_OFFSET] = {
> [TSU_ADRL31] = 0x01fc,
> };
>
> -static int sh_eth_is_gether(struct sh_eth_private *mdp)
> +static bool sh_eth_is_gether(struct sh_eth_private *mdp)
> {
> if (mdp->reg_offset == sh_eth_offset_gigabit)
> - return 1;
> + return true;
> else
> - return 0;
> + return false;
> }
Or maybe:
static bool sh_eth_is_gether(struct sh_eth_private *mdp)
{
return mdp->reg_offset == sh_eth_offset_gigabit;
}
^ permalink raw reply
* [PATCH 1/2] clk: hisilicon: add hi3620_mmc_clks
From: Haojian Zhuang @ 2014-01-15 9:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115082908.4167.34040@quantum>
On 01/15/2014 04:29 PM, Mike Turquette wrote:
> Quoting Haojian Zhuang (2014-01-14 21:59:40)
>> On 01/15/2014 11:53 AM, Mike Turquette wrote:
>>> Quoting zhangfei (2014-01-14 17:40:25)
>>>> Dear Mike
>>>>
>>>> On 01/15/2014 04:17 AM, Mike Turquette wrote:
>>>>> Quoting Zhangfei Gao (2014-01-13 01:14:28)
>>>>>> Suggest by Arnd: abstract mmc tuning as clock behavior,
>>>>>> also because different soc have different tuning method and registers.
>>>>>> hi3620_mmc_clks is added to handle mmc clock specifically on hi3620.
>>>>>>
>>>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>>>>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>>>>>> Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
>>>>> Patch looks good to me with one exception. I do not have
>>>>> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt in the
>>>>> clk-next branch. Is there a stable branch I can pull in as a dependency?
>>>> Mach-hisi just have been uploaeded.
>>>> Have tried next-20140114, the patch can be applied successfully.
>>>> While v3.13-rc8 still can not.
>>>>
>>>> Is this fine?
>>> Can you give me a link to the branch that introduces
>>> Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt?
>>>
>>> I guess the patch introducing it is going through arm-soc. Is this going
>>> in for 3.14? If so then perhaps the clk tree and the arm-soc tree can
>>> share a stable branch that introduces it.
>>>
>>> Regards,
>>> Mike
>>>
>> Some patches are merged into arm-soc, and others are in clk tree.
>> If sharing a stable branch between arm-soc and clk tree, it only means
>> that we need to revert all commits that are in arm-soc and clk tree.
>> I think it's too complex.
> I'm suggesting reverting any patches that are applied to arm-soc. I'm
> only suggesting that there might be a common branch that both the clk
> and arm-soc trees can depend on to fix this problem.
>
>> How about split the patch? The patch on document should enter in arm-soc.
> That is one approach. You might want to run it past the arm-soc folks
> first to see if they will take in the binding definition for 3.14.
>
> Regards,
> Mike
>
Yes, so I already made Kevin in this loop. Let's see whether he has
any comments on it.
Regards
Haojian
^ permalink raw reply
* [PATCH v4 02/15] clk: Allow drivers to pass in a regmap
From: Mike Turquette @ 2014-01-15 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140110070517.GE14405@codeaurora.org>
Quoting Stephen Boyd (2014-01-09 23:05:17)
> On 01/09, Mike Turquette wrote:
> > If we're going to use these wrappers, why make it regmap specific? The
> > struct clk_desc patches[1][2] can achieve this, but in a more generic
> > way.
> >
>
> I think you're suggesting a way to avoid adding a
> clk_register_regmap() function? But won't we need to write the
> same code:
>
> if (dev && dev_get_regmap(dev, NULL))
> [clk_type]->regmap = dev_get_regmap(dev, NULL);
> else if (dev && dev->parent)
> [clk_type]->regmap = dev_get_regmap(dev->parent, NULL);
>
> everytime we want to assign the regmap pointer to a different clock type?
> A macro might work for this little snippet, but it wouldn't have
> any type safety.
Hi Stephen,
Avoiding a new clk_register_regmap() function is one thing worth doing.
But additionally I think that this regmap infrastructure in the core
code still is not the right way forward.
Looking at patch #3 I can already see how those helper functions will
grow just like the basic clock type implementations. Take a look at
drivers/clk/clk-divider.c and check out the HIWORD_MASK stuff. That
really shouldn't belong there, but multiple platforms are using the
Designware IP that needs this so in the Name Of Consolidation it was
done. Basically that code is gross.
A more relevant example: look at the gate clock with a busy bit
implementation in arch/arm/mach-imx/clk-gate2.c. The same could be done
for your clk_enable_regmap() function: someone could subclass it and add
a busy bit or status bit to poll on. But should they? The extra layer of
indirection buys us nothing and takes a clean piece of code and
complicates it.
I'd rather your .enable, .disable and .is_enabled implementations live
in drivers/clk/msm/ so that we can avoid this sort of feature creep in
the future. It's perfectly fine if others implement the same code in
their clock drivers.
With all of that said, then there is no point in keeping struct regmap
*regmap inside of struct clk_hw. It can be moved inside of your struct
clk_rcg, struct clk_branch and struct clk_pll definitions.
>
> > >
> > >
> > > 2) Interfaces: Add a void *data in struct clk_hw that can point to
> > > whatever I want and still have the same clk_regmap_register() and
> > > devm_clk_regmap_register()
> > >
> > > Example:
> > >
> > > struct clk_hw {
> > > struct clk *clk;
> > > const struct clk_init_data *init;
> > > void *data;
> > > };
> > >
> > > struct clk_regmap {
> > > struct regmap *regmap;
> > > unsigned int enable_reg;
> > > unsigned int enable_mask;
> > > bool enable_is_inverted;
> > > };
> > >
> > > struct clk_branch {
> > > u32 hwcg_reg;
> > > u32 halt_reg;
> > > u8 hwcg_bit;
> > > u8 halt_bit;
> > > u8 halt_check;
> > >
> > > struct clk_hw;
> > > };
> > >
> > > static struct clk_branch gsbi1_uart_clk = {
> > > .halt_reg = 0x2fcc,
> > > .halt_bit = 10,
> > > .hw = {
> > > .data = &(struct clk_regmap){
> > > .enable_reg = 0x29d4,
> > > .enable_mask = BIT(9),
> > > };
> > > .init = &(struct clk_init_data){
> > > .name = "gsbi1_uart_clk",
> > > .parent_names = (const char *[]){
> > > "gsbi1_uart_src",
> > > },
> > > .num_parents = 1,
> > > .ops = &clk_branch_ops,
> > > .flags = CLK_SET_RATE_PARENT,
> > > },
> > > },
> > > };
> > >
> > > I guess option 2 is less likely given your comment about clk_hw being
> > > nothing more than a traversal mechanism.
> >
> > Instead of private data, how about a .register() callback function that
> > can point to anything you like? The clk_desc patches implement this and
> > it would suffice for registering regmap ops or anything else, without
> > polluting struct clk_hw.
> >
> > [1] http://www.spinics.net/lists/linux-omap/msg101822.html
> > [2] http://www.spinics.net/lists/linux-omap/msg101698.html
> >
> > So you could statically define gsbi1_uart_clk with:
> >
> > static struct clk_branch_desc gsbi1_uart_clk_desc = {
> > .halt_reg = 0x2fcc,
> > .halt_bit = 10,
> > .enable_reg = 0x29d4,
> > .enable_mask = BIT(9),
> > .desc = {
> > .name = "gsbi1_uart_clk",
> > .parent_names = (const char *[]){
> > "gsbi1_uart_src",
> > },
> > .num_parents = 1,
> > .ops = &clk_branch_ops,
> > .flags = CLK_SET_RATE_PARENT,
> > },
> > };
> >
> > And then register it with:
> >
> > clk_register_desc(NULL, &gsbi1_uart_clk_desc.desc);
> >
> > This is very analogous to the way that you use use &gsbi1_uart_clk.hw
> > but it is more generic and also doesn't pollute clk_hw any further. I
> > also think your static data is quite a bit prettier using this method.
> >
> > Thoughts?
>
> Is the plan to allocate a struct clk_branch at runtime and then
> copy all the fields over one by one? I'm trying to avoid that
> because it takes more time and more runtime memory. If I had to
> go the descriptor route I would probably avoid copying any fields
> and just point to the descriptor from struct clk_branch, i.e.
>
> struct clk_branch {
> struct clk_branch_desc *desc;
> struct clk_hw;
> };
>
> but that still seems wasteful to allocate a bunch of little
> pointer wrappers when I could have just embedded the clk_hw
> struct inside the clk_branch struct from the start.
>
The pointer copy stuff was done so that every instance of struct
clk_init_data could be marked as __initdata.
> It feels another key point is being missed though. The regmap
> pointer and the enable_reg/enable_mask is embedded in clk_hw to
> allow the same code to be used by different types of surrounding
> structs. Each struct: clk_pll, clk_rcg, and clk_branch in this
> series use the regmap interface to enable/disable the clock and
> they can easily do so by passing something that's always
> available from struct clk_hw (be it via a wrapper struct, private
> data member, or addition of new fields to clk_hw). If the regmap
> members move into each specific type of clock we can't just pass
> a single pointer to the enable/disable regmap functions anymore.
> This is the reason why I suggested a driver data pointer or
> container struct so that everything regmap related is contained
> within one type.
I get understand the goal of reuse and I applaud it. But even if we did
pack the regmap data into struct clk_hw it would start to grow out of
control as I mentioned in a previous email. In order for this to work
you have to package more than just struct regmap *regmap into struct
clk_hw. You need the register offset as well as any relevant masks and
bit field values. And then you need more stuff for muxes and dividers.
And hey now you need busy/poll register values and another platform
needs to program shadow registers before flipping the Go Bit ... the
list goes on and on.
So in summary: consolidation is over-rated. You can put your regmap
functions into drivers/clk/msm/ and not convert over to struct clk_desc
by the way, just to remove any confusion on that point.
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
^ permalink raw reply
* v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
From: Ian Campbell @ 2014-01-15 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D651CD.5020307@gmail.com>
On Wed, 2014-01-15 at 10:15 +0100, Sebastian Hesselbarth wrote:
> On 01/15/14 09:40, Ian Campbell wrote:
> > The bootlogs are below or in the bug. It stops after "Console: colour
> > dummy device 80x30", I think next would normally be the
> > BogoMIPS/calibrate_delay output.
>
> That would indicate the timer (clocksource) or irq (irqchip) is not
> running correctly. Again, that could be non-DT and DT fighting for it.
> I'll investigate that.
That seems logical.
> In the meantime, can you recompile your kernel and set
> CONFIG_ARCH_KIRKWOOD_DT=n ?
I can confirm that v3.13-rc8 with CONFIG_ARCH_KIRKWOOD_DT=n works.
Thanks,
Ian.
^ permalink raw reply
* [PATCH v3 2/2] serial: fsl_lpuart: add DMA support
From: Arnd Bergmann @ 2014-01-15 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389763265-27300-3-git-send-email-yao.yuan@freescale.com>
On Wednesday 15 January 2014, Yuan Yao wrote:
> Add dma support for lpuart. This function depend on DMA driver.
> You can turn on it by SERIAL_FSL_LPUART_DMA=y. And It works if dts node has dma properties.
>
> Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
Most of the changes you did look good, but I have to say I'm not a fan of
the #ifdef you added. I don't think you actually need to have the compile-time
selection, and it would be best to just drop that part.
If you have a good reason to keep it, please change the code to
more readable "if (IS_ENABLED(CONFIG_FSL_LPUART_DMA))" constructs.
If you decide to do this, you will find that you need far fewer
such conditionals because a lot of the code will automatically
get dropped by the compiler.
> uart0: serial at 40027000 {
> - compatible = "fsl,vf610-lpuart";
> - reg = <0x40027000 0x1000>;
> - interrupts = <0 61 0x00>;
> - };
> + compatible = "fsl,vf610-lpuart";
> + reg = <0x40027000 0x1000>;
> + interrupts = <0 61 0x00>;
> + clocks = <&clks VF610_CLK_UART0>;
> + clock-names = "ipg";
> + dma-names = "lpuart-tx","lpuart-rx";
> + dmas = <&edma0 0 VF610_EDMA_MUXID0_UART0_TX>,
> + <&edma0 0 VF610_EDMA_MUXID0_UART0_RX>;
> + };
You still haven't addressed my comment about removing the VF610_EDMA_MUXID0_UART0_TX
macros.
>
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> +#define DMA_MAXBURST 16
> +#define DMA_MAXBURST_MASK (DMA_MAXBURST - 1)
> +#define FSL_UART_RX_DMA_BUFFER_SIZE 64
> +#endif
For this part there was no need for the #ifdef to start with.
> #define DRIVER_NAME "fsl-lpuart"
> #define DEV_NAME "ttyLP"
> #define UART_NR 6
> @@ -121,6 +132,26 @@ struct lpuart_port {
> struct clk *clk;
> unsigned int txfifo_size;
> unsigned int rxfifo_size;
> +
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> + bool lpuart_dma_use;
> + struct dma_chan *dma_tx_chan;
> + struct dma_chan *dma_rx_chan;
> + struct dma_async_tx_descriptor *dma_tx_desc;
> + struct dma_async_tx_descriptor *dma_rx_desc;
> + dma_addr_t dma_tx_buf_bus;
> + dma_addr_t dma_rx_buf_bus;
> + dma_cookie_t dma_tx_cookie;
> + dma_cookie_t dma_rx_cookie;
> + unsigned char *dma_tx_buf_virt;
> + unsigned char *dma_rx_buf_virt;
> + unsigned int dma_tx_bytes;
> + unsigned int dma_rx_bytes;
> + int dma_tx_in_progress;
> + int dma_rx_in_progress;
> + unsigned int dma_rx_timeout;
> + struct timer_list lpuart_timer;
> +#endif
> };
This part will result in a slight increase in data size even if
dma support is turned off at compile time.
>
> temp = readb(port->membase + UARTCR2);
> writeb(temp | UARTCR2_TIE, port->membase + UARTCR2);
>
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> + if (sport->lpuart_dma_use) {
> + if (!uart_circ_empty(xmit) && !sport->dma_tx_in_progress)
> + lpuart_prepare_tx(sport);
> + } else {
> + if (readb(port->membase + UARTSR1) & UARTSR1_TDRE)
> + lpuart_transmit_buffer(sport);
> + }
> +#else
> if (readb(port->membase + UARTSR1) & UARTSR1_TDRE)
> lpuart_transmit_buffer(sport);
> +#endif
> }
So this can simply become
+ if (IS_ENABLED(CONFIG_SERIAL_FSL_LPUART_DMA) && sport->lpuart_dma_use) {
+ if (!uart_circ_empty(xmit) && !sport->dma_tx_in_progress)
+ lpuart_prepare_tx(sport);
+ } else {
+ if (readb(port->membase + UARTSR1) & UARTSR1_TDRE)
+ lpuart_trans mit_buffer(sport);
+ }
and the compiler will silently drop the lpuart_prepare_tx() function and everything
it calls that isn't used elsewhere.
> +
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> + struct platform_device *pdev = to_platform_device(port->dev);
> + struct device_node *np = pdev->dev.of_node;
> +
> + if (of_get_property(np, "dmas", NULL)) {
> + sport->lpuart_dma_use = true;
> + lpuart_dma_tx_request(port);
> + lpuart_dma_rx_request(port);
> + temp = readb(port->membase + UARTCR5);
> + writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
> + } else
> + sport->lpuart_dma_use = false;
> +#endif
Same here.
> @@ -854,6 +1291,10 @@ static int __init lpuart_serial_init(void)
>
> pr_info("serial: Freescale lpuart driver\n");
>
> +#ifdef CONFIG_SERIAL_FSL_LPUART_DMA
> + pr_info("serial: Freescale lpuart dma support\n");
> +#endif
> +
This message is not helpful in the long run, I'd rather see you drop the
other one as well. Note that this function is called on *all* platforms
when the driver is enabled, not just on those that actually have the uart.
Arnd
^ permalink raw reply
* [PATCH] ARM: imx: clk-imx6sl: Suppress duplicate const sparse warning
From: Joe Perches @ 2014-01-15 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115065851.GC1914@S2101-09.ap.freescale.net>
On Wed, 2014-01-15 at 14:58 +0800, Shawn Guo wrote:
> On Wed, Jan 15, 2014 at 02:19:34PM +0800, Liu Ying wrote:
> > There should be no duplicate const specifiers for those static
> > constant character string arrays defined for clock mux options.
> > Also, the arrays are only taken as the 5th argument for the
> > imx_clk_mux() function, which is in the type of 'const char
> > **parents'. So, let's remove the 2nd const specifier right
> > after 'char'.
> >
> > This patch fixes these sparse warnings:
> > arch/arm/mach-imx/clk-imx6sl.c:21:25: warning: duplicate const
[]
> > diff --git a/arch/arm/mach-imx/clk-imx6sl.c b/arch/arm/mach-imx/clk-imx6sl.c
[]
> > @@ -18,27 +18,27 @@
> > #include "clk.h"
> > #include "common.h"
> >
> > -static const char const *step_sels[] = { "osc", "pll2_pfd2", };
> ...
> > +static const char *step_sels[] = { "osc", "pll2_pfd2", };
>
> So now we're getting the following checkpatch warning:
>
> WARNING: static const char * array should probably be static const char * const
>
> It was added into checkpatch.pl by commit cb710ec (scripts/checkpatch.pl:
> add warnings for static char that could be static const char). I'm not
> sure which warning we should ignore, the sparse or the checkpatch one.
>
> Joe, comments?
Maybe the const **parents argument could be const * const *
That could change a lot of declarations through.
You could also ignore checkpatch.
^ permalink raw reply
* v3.12 regression from "ARM: kirkwood: convert to DT irqchip and clocksource" on non-DT kirkwood platforms
From: Sebastian Hesselbarth @ 2014-01-15 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389775235.10695.51.camel@dagon.hellion.org.uk>
On 01/15/14 09:40, Ian Campbell wrote:
> Debian kernel's have been suffering a hang on boot on kirkwood platforms
> since 3.12, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735172.
>
> The issue has been seen on various QNAP TS platforms, mine is a TS-419
> but TS-119 and TS-212's have also been seen to fail. In all cases this
> is using the legacy board file based support not the DT support (which
> is only for TS-219 so far in any case AFAIK, I am not using Andrew
> Lunn's DT patches for TS-41x).
Ian,
thanks for the detailed report below. I quickly checked your .config and
saw you have CONFIG_ARCH_KIRKWOOD_DT=y although I understand you are not
booting DT here.
There may be some interference with both non-DT/DT compiled in, I'll
check that later.
> The bootlogs are below or in the bug. It stops after "Console: colour
> dummy device 80x30", I think next would normally be the
> BogoMIPS/calibrate_delay output.
That would indicate the timer (clocksource) or irq (irqchip) is not
running correctly. Again, that could be non-DT and DT fighting for it.
I'll investigate that.
In the meantime, can you recompile your kernel and set
CONFIG_ARCH_KIRKWOOD_DT=n ?
Sebastian
> I bisected it down to:
> commit 2326f04321a9aec591c1d159b3a9d12c2bf89438
> Author: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Date: Tue Jul 2 15:15:07 2013 +0200
>
> ARM: kirkwood: convert to DT irqchip and clocksource
>
> With recent support for true irqchip and clocksource drivers for Orion
> SoCs, now make use of it on DT enabled Kirkwood boards.
>
> This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
> where old code is moved out to and polishes DT board file a little bit.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>
> and reverting this on top of v3.12 allows the platform to boot
> successfully. I've also reproduced with v3.13-rc8 and the revert was not
> so trivial there, but I think I've done it right and it corrects the
> problem.
^ permalink raw reply
* [PATCH V3 1/5] pinctrl: sh-pfc: r7s72100: Add RSPI support
From: Linus Walleij @ 2014-01-15 9:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389523723-2288-2-git-send-email-geert@linux-m68k.org>
On Sun, Jan 12, 2014 at 11:48 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> ---
> V2:
> - No changes
> V3:
> - No changes
I'm expecting Laurent to queue this patch when he's happy with it
(maybe he already said so in some other mail).
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: S3C[24|64]xx: move includes back under <mach/> scope
From: Tushar Behera @ 2014-01-15 9:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389707618-17011-1-git-send-email-linus.walleij@linaro.org>
On 14 January 2014 19:23, Linus Walleij <linus.walleij@linaro.org> wrote:
> When refactoring and breaking out the includes for the
> machine-specific GPIO configuration, two files were created
> in <linux/platform_data/gpio-samsung-s3c[24|64]xx.h>, but as
> that namespace shall be used for defining data exchanged
> between machines and drivers, using it for these broad macros
> and config settings is wrong.
>
> Move the headers back into the machine-local
> <mach/gpio-samsung.h> file and think about the next step.
>
<snip>
> diff --git a/arch/arm/plat-samsung/pm-gpio.c b/arch/arm/plat-samsung/pm-gpio.c
> index c4efa1c2a5d1..a9f7a37c4173 100644
> --- a/arch/arm/plat-samsung/pm-gpio.c
> +++ b/arch/arm/plat-samsung/pm-gpio.c
> @@ -19,12 +19,7 @@
> #include <linux/io.h>
> #include <linux/gpio.h>
>
> -#ifdef CONFIG_ARCH_S3C24XX
> -#include <linux/platform_data/gpio-samsung-s3c24xx.h>
> -#endif
> -#ifdef CONFIG_ARCH_S3C64XX
> -#include <linux/platform_data/gpio-samsung-s3c64xx.h>
> -#endif
> +#include <mach/gpio-samsung.h>
This inclusion should be protected by a check for CONFIG_ARCH_S3C24XX
|| CONFIG_ARCH_S3C64XX. Currently generating build errors for
s5p64x0_defconfig, s5pc100_defconfig and s5pv210_defconfig on
next-20140115.
--
Tushar Behera
^ permalink raw reply
* [PATCH] ARM: sunxi: change the AllWinner A1X to sunxi
From: Maxime Ripard @ 2014-01-15 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140109153404.GA21055@kvmhost>
On Thu, Jan 09, 2014 at 04:34:04PM +0100, Gerardo Di Iorio wrote:
> Change the AllWinner A1X SOCs to Allwinner Sunxi SOCs
>
> Signed-off-by: Gerardo Di Iorio <arete74@gmail.com>
> ---
> arch/arm/mach-sunxi/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> index 547004c..adb2574 100644
> --- a/arch/arm/mach-sunxi/Kconfig
> +++ b/arch/arm/mach-sunxi/Kconfig
> @@ -1,5 +1,5 @@
> config ARCH_SUNXI
> - bool "Allwinner A1X SOCs" if ARCH_MULTI_V7
> + bool "Allwinner Sunxi SOCs" if ARCH_MULTI_V7
I wonder if the sunxi (apart the weird letter case) is actually
needed. Maybe we can just put "Allwinner SoCs" (it would be great if
you could fix the SoCs case too).
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140115/fce18948/attachment-0001.sig>
^ 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