* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Bo Shen @ 2012-11-16 6:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353045837-19474-1-git-send-email-voice.shen@atmel.com>
Add pinctrl consumer for atmel ssc peripheral
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Resend:
Split one patch into two.
- one add pinctrl nodes
- one add pinctrl consumer
---
drivers/misc/atmel-ssc.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c
index a769719..3b3d0e0 100644
--- a/drivers/misc/atmel-ssc.c
+++ b/drivers/misc/atmel-ssc.c
@@ -19,6 +19,7 @@
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/pinctrl/consumer.h>
/* Serialize access to ssc_list and user count */
static DEFINE_SPINLOCK(user_lock);
@@ -131,6 +132,13 @@ static int ssc_probe(struct platform_device *pdev)
struct resource *regs;
struct ssc_device *ssc;
const struct atmel_ssc_platform_data *plat_dat;
+ struct pinctrl *pinctrl;
+
+ pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(pinctrl)) {
+ dev_err(&pdev->dev, "Failed to request pinctrl\n");
+ return PTR_ERR(pinctrl);
+ }
ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL);
if (!ssc) {
--
1.7.9.5
^ permalink raw reply related
* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Mark Brown @ 2012-11-16 6:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353045837-19474-2-git-send-email-voice.shen@atmel.com>
On Fri, Nov 16, 2012 at 02:03:57PM +0800, Bo Shen wrote:
> Add pinctrl consumer for atmel ssc peripheral
>
> Signed-off-by: Bo Shen <voice.shen@atmel.com>
> ---
> Resend:
> Split one patch into two.
> - one add pinctrl nodes
> - one add pinctrl consumer
No, this isn't what was meant - the idea is to send only the addition of
pinctrl data as one patch, based off the ASoC branch instead of -next.
-------------- 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/20121116/c57f0c06/attachment.sig>
^ permalink raw reply
* [PATCH 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: AnilKumar, Chimata @ 2012-11-16 6:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433EC04226@DBDE01.ent.ti.com>
On Mon, Nov 12, 2012 at 15:17:48, AnilKumar, Chimata wrote:
> On Tue, Nov 06, 2012 at 11:15:34, Bedia, Vaibhav wrote:
> > On Mon, Nov 05, 2012 at 15:12:27, AnilKumar, Chimata wrote:
> > [...]
> > >
> > > +#define SHUTDOWN_TIME_SEC 2
> > > +#define SECS_IN_MIN 60
> > > +#define WAIT_AFTER (SECS_IN_MIN - SHUTDOWN_TIME_SEC)
> > > +#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
> > > +
> > > static void __iomem *rtc_base;
> > >
> > [...]
> > > +
> > > + /* Wait few seconds instead of rollover */
> > > + do {
> > > + omap_rtc_read_time(NULL, &tm);
> > > + if (WAIT_AFTER <= tm.tm_sec)
> > > + mdelay(WAIT_TIME_MS);
> > > + } while (WAIT_AFTER <= tm.tm_sec);
> >
> > This hardcoded wait for rollover doesn't look good. I see some
> > helper functions in rtc-lib.c which probably could be used for
> > converting the current time to elapsed seconds, add the delay and
> > then convert it back to the time to be programmed in RTC without
> > worrying about rollover. Why not use that?
>
> I am not aware of those APIs, can you point some?
I have gone through rtc-lib.c, these are the API's I am seeing
in the library
1. rtc_time_to_tm: Convert seconds since 01-01-1970 00:00:00 to
Gregorian date
2. rtc_tm_to_time: Convert Gregorian date to seconds since
01-01-1970 00:00:00
Steps I followed:-
================
1: unsigned long time;
2: omap_rtc_read_time(NULL, &tm);
3: rtc_tm_to_time(tm, &time);
4: pr_info("Time 1 %lu\n", time);
5: time += 2; /* (2sec) */
6: rtc_time_to_tm(time, tm);
7: rtc_tm_to_time(tm, &time); /* Only for printing time value */
8: pr_info("Time 2 %lu\n", time);
With the above steps I am seeing completely two different time
values at step4 and step8
Thanks
AnilKumar
^ permalink raw reply
* [PATCH 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: AnilKumar, Chimata @ 2012-11-16 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121114102452.GI7407@opensource.wolfsonmicro.com>
On Wed, Nov 14, 2012 at 15:54:53, Mark Brown wrote:
> On Wed, Nov 14, 2012 at 11:08:49AM +0100, Benoit Cousson wrote:
>
> > I was wondering that, because exposing a pin to control the whole PMIC
> > low power mode seems to be something that should be generic enough to be
> > handled by the regulator framework.
>
> Having something that's controlled by software is really not at all
> generic - suspending a PMIC from a GPIO is generally tied in very
> closely with the CPU power sequencing which means it's typically some
> combination of very hard coded things that we can't control or part of
> much wider control of sequencing.
>
> > In the current situation we do have a pwr_en pin that can be controlled
> > by a GPIO or whatever signal from the SoC.
> > That's very similar, at PMIC level, to the fixedregulator that allow a
> > GPIO binding to enable it.
>
> > Don't you think that should deserve a support in the fmwk?
>
> I'm not seeing a coherent description of a feature here - what exactly
> are you proposing that we do? When and how would this GPIO be set for
> example?
It would be better if these patches are going in like this till the
framework exists. We can change/move this portion once the framework
is defined for this kind.
Thanks
AnilKumar
^ permalink raw reply
* [PATCH 7/8] ata: highbank: mark ahci_highbank_probe as __devinit
From: Fabio Estevam @ 2012-11-16 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A5C4C7.4090309@pobox.com>
Hi Jeff,
On Fri, Nov 16, 2012 at 2:44 AM, Jeff Garzik <jgarzik@pobox.com> wrote:
> On 11/06/2012 04:55 PM, Arnd Bergmann wrote:
>>
>> The ahci_highbank_probe function is incorrectly marked as __init,
>> which means it can get discarded at boot time, which might be
>> a problem if for some reason the device only becomes operational
>> after loading another module.
>>
>> Using __devinit instead avoids seeing this warning for every build:
>>
>> WARNING: vmlinux.o(.data+0xf7b0): Section mismatch in reference from the
>> variable ahci_highbank_driver to the function
>> .init.text:ahci_highbank_probe()
>> The variable ahci_highbank_driver references
>> the function __init ahci_highbank_probe()
>> If the reference is valid then annotate the
>> variable with __init* or __refdata (see linux/init.h) or name the
>> variable:
>> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
>>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> Cc: Mark Langsdorf <mark.langsdorf@calxeda.com>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Cc: Jeff Garzik <jgarzik@redhat.com>
>> ---
>> drivers/ata/sata_highbank.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> applied
I have also sent the same fix:
https://patchwork.kernel.org/patch/1562141/
^ permalink raw reply
* [PATCH 01/10] ARM: imx6q: print silicon version on boot
From: Dirk Behme @ 2012-11-16 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116022346.GA2941@S2100-06.ap.freescale.net>
Am 16.11.2012 03:23, schrieb Shawn Guo:
> On Thu, Nov 15, 2012 at 06:09:31PM +0000, Moseley, Drew wrote:
>> On Oct 23, 2012, at 11:22 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
>>> i.MX6Q has 3 revisions 1.0, 1.1 and 1.2. Print revision on boot.
>>>
>>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>>> ---
>>> arch/arm/mach-imx/mach-imx6q.c | 28 ++++++++++++++++++++++++++++
>>> 1 file changed, 28 insertions(+)
>>>
>>
>> Hi Shawn,
>>
>> An addition to this patch to add some error checking. Thoughts?
>>
> It looks good. I just squashed the changes into the original patch
> with your sob added. Thanks.
Just a small note on the whole series:
We picked the two patches
ARM: imx6q: print silicon version on boot
ARM: imx6q: select ARM and PL310 errata
because they look generic and generally useful. Not only for the
cpuidle feature.
Maybe it makes sense to apply these two patches independent from the
cpuidle series as general improvements?
Best regards
Dirk
> Note, the patch series will probably postponed to 3.9 due to the
> dependency on other tree and the fact that I wait for a TO1.2 hardware
> to test the power gating state.
>
> Shawn
>
>> Drew
>>
>>
>>
>>
>> Add error checking to imx6q_revision()
>>
>> Signed-off-by: Drew Moseley <drew_moseley@mentor.com>
>> ---
>> arch/arm/mach-imx/mach-imx6q.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
>> index 265c311..072e32a 100644
>> --- a/arch/arm/mach-imx/mach-imx6q.c
>> +++ b/arch/arm/mach-imx/mach-imx6q.c
>> @@ -54,9 +54,16 @@ static int imx6q_revision(void)
>>
>> if (!rev) {
>> np = of_find_compatible_node(NULL, NULL, "fsl,imx6q-anatop");
>> + if (!np)
>> + return IMX_CHIP_REVISION_UNKNOWN;
>> base = of_iomap(np, 0);
>> + if (!base) {
>> + of_node_put(np);
>> + return IMX_CHIP_REVISION_UNKNOWN;
>> + }
>> rev = readl_relaxed(base + IMX6Q_ANALOG_DIGPROG);
>> iounmap(base);
>> + of_node_put(np);
>> }
>>
>> switch (rev & 0xff) {
>> --
>> 1.8.0
>>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Bo Shen @ 2012-11-16 6:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116061250.GP4387@opensource.wolfsonmicro.com>
Hi Mark,
On 11/16/2012 14:12, Mark Brown wrote:
> On Fri, Nov 16, 2012 at 02:03:57PM +0800, Bo Shen wrote:
>> Add pinctrl consumer for atmel ssc peripheral
>>
>> Signed-off-by: Bo Shen <voice.shen@atmel.com>
>> ---
>> Resend:
>> Split one patch into two.
>> - one add pinctrl nodes
>> - one add pinctrl consumer
>
> No, this isn't what was meant - the idea is to send only the addition of
> pinctrl data as one patch, based off the ASoC branch instead of -next.
What is the pinctrl data? (This patch can be applied on
sound/topic/atmel branch without any conflicts)
The other one add pinctrl nodes, must based on -next, or else I don't
know where should I add the pinctrl nodes.
Best Regards,
Bo Shen
^ permalink raw reply
* [PATCH 01/10] ARM: imx6q: print silicon version on boot
From: Shawn Guo @ 2012-11-16 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116022346.GA2941@S2100-06.ap.freescale.net>
On Fri, Nov 16, 2012 at 10:23:54AM +0800, Shawn Guo wrote:
> On Thu, Nov 15, 2012 at 06:09:31PM +0000, Moseley, Drew wrote:
> > On Oct 23, 2012, at 11:22 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > i.MX6Q has 3 revisions 1.0, 1.1 and 1.2. Print revision on boot.
> > >
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > ---
> > > arch/arm/mach-imx/mach-imx6q.c | 28 ++++++++++++++++++++++++++++
> > > 1 file changed, 28 insertions(+)
> > >
> >
> > Hi Shawn,
> >
> > An addition to this patch to add some error checking. Thoughts?
> >
> It looks good. I just squashed the changes into the original patch
> with your sob added. Thanks.
>
> Note, the patch series will probably postponed to 3.9 due to the
> dependency on other tree and the fact that I wait for a TO1.2 hardware
> to test the power gating state.
>
It seems this particular patch is useful regardless of the cpuidle
support, so I will send this one for 3.8 anyway.
Shawn
^ permalink raw reply
* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Mark Brown @ 2012-11-16 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A5DE4E.80206@atmel.com>
On Fri, Nov 16, 2012 at 02:33:50PM +0800, Bo Shen wrote:
> On 11/16/2012 14:12, Mark Brown wrote:
> >No, this isn't what was meant - the idea is to send only the addition of
> >pinctrl data as one patch, based off the ASoC branch instead of -next.
> What is the pinctrl data? (This patch can be applied on
The data you're adding in the device tree!
> sound/topic/atmel branch without any conflicts)
That's not helpful to anyone doing bisection if there's nothing defining
the pin states, it means that the system won't be able to start the
driver as the API call will fail.
> The other one add pinctrl nodes, must based on -next, or else I
> don't know where should I add the pinctrl nodes.
What makes you say this?
-------------- 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/20121116/60a95485/attachment.sig>
^ permalink raw reply
* [PATCH 17/17] mtd: m25p80: change the m25p80_read to reading page to page
From: Yang, Wenyou @ 2012-11-16 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112091239.GA8518@sapphire.tkos.co.il>
Hi Baruch,
Thanks a lot for your feedback.
I looked through the drive code carefully again, I think I should fix this bug inside my driver.
I will fix in the next version.
Best Regards
Wenyou Yang
> -----Original Message-----
> From: Baruch Siach [mailto:baruch at tkos.co.il]
> Sent: 2012?11?12? 17:13
> To: Yang, Wenyou
> Cc: linux-arm-kernel at lists.infradead.org; dwmw2 at infradead.org; Lin, JM; Ferre,
> Nicolas; linux-mtd at lists.infradead.org
> Subject: Re: [PATCH 17/17] mtd: m25p80: change the m25p80_read to reading page
> to page
>
> Hi Wenyou Yang,
>
> On Mon, Nov 12, 2012 at 04:52:37PM +0800, Wenyou Yang wrote:
> > When run "flashcp /bin/busybox /dev/mtdX", it arised a OOPS. changing to fix the
> [BUG].
>
> Please post the BUG printout, and include it with the commit log.
>
> baruch
>
> > Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
> > Cc: dwmw2 at infradead.org
> > Cc: linux-mtd at lists.infradead.org
> > ---
> > drivers/mtd/devices/m25p80.c | 44
> +++++++++++++++++++++++++++++++++++++++---
> > 1 file changed, 41 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> > index 03838ba..73e5fea 100644
> > --- a/drivers/mtd/devices/m25p80.c
> > +++ b/drivers/mtd/devices/m25p80.c
> > @@ -340,6 +340,7 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
> size_t len,
> > size_t *retlen, u_char *buf)
> > {
> > struct m25p *flash = mtd_to_m25p(mtd);
> > + u32 page_offset, page_size;
> > struct spi_transfer t[2];
> > struct spi_message m;
> >
> > @@ -358,7 +359,6 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
> size_t len,
> > spi_message_add_tail(&t[0], &m);
> >
> > t[1].rx_buf = buf;
> > - t[1].len = len;
> > spi_message_add_tail(&t[1], &m);
> >
> > mutex_lock(&flash->lock);
> > @@ -379,9 +379,47 @@ static int m25p80_read(struct mtd_info *mtd, loff_t from,
> size_t len,
> > flash->command[0] = OPCODE_READ;
> > m25p_addr2cmd(flash, from, flash->command);
> >
> > - spi_sync(flash->spi, &m);
> > + page_offset = from & (flash->page_size - 1);
> > +
> > + /* do all the bytes fit onto one page? */
> > + if (page_offset + len <= flash->page_size) {
> > + t[1].len = len;
> > +
> > + spi_sync(flash->spi, &m);
> > +
> > + *retlen = m.actual_length - m25p_cmdsz(flash)
> > + - FAST_READ_DUMMY_BYTE;
> > +
> > + } else {
> > + u32 i;
> > +
> > + /* the size of data remaining on the first page */
> > + page_size = flash->page_size - page_offset;
> > +
> > + t[1].len = page_size;
> > + spi_sync(flash->spi, &m);
> > +
> > + *retlen = m.actual_length - m25p_cmdsz(flash)
> > + - FAST_READ_DUMMY_BYTE;
> > +
> > + /* write everything in flash->page_size chunks */
> > + for (i = page_size; i < len; i += page_size) {
> > + page_size = len - i;
> > + if (page_size > flash->page_size)
> > + page_size = flash->page_size;
> > +
> > + /* write the next page to flash */
> > + m25p_addr2cmd(flash, from + i, flash->command);
> > +
> > + t[1].rx_buf = buf + i;
> > + t[1].len = page_size;
> > +
> > + spi_sync(flash->spi, &m);
> >
> > - *retlen = m.actual_length - m25p_cmdsz(flash) - FAST_READ_DUMMY_BYTE;
> > + *retlen += m.actual_length - m25p_cmdsz(flash)
> > + - FAST_READ_DUMMY_BYTE;
> > + }
> > + }
> >
> > mutex_unlock(&flash->lock);
> >
> > --
> > 1.7.9.5
>
> --
> http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH 01/10] ARM: imx6q: print silicon version on boot
From: Shawn Guo @ 2012-11-16 6:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A5DC5A.3040603@gmail.com>
On Fri, Nov 16, 2012 at 07:25:30AM +0100, Dirk Behme wrote:
> Just a small note on the whole series:
>
> We picked the two patches
>
> ARM: imx6q: print silicon version on boot
> ARM: imx6q: select ARM and PL310 errata
>
> because they look generic and generally useful. Not only for the
> cpuidle feature.
>
> Maybe it makes sense to apply these two patches independent from the
> cpuidle series as general improvements?
>
Ok, will send both patch for 3.8.
Shawn
^ permalink raw reply
* [Resend v6 PATCH 2/2] ASoC: atmel-ssc: add pinctrl consumer
From: Bo Shen @ 2012-11-16 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121116064113.GQ4387@opensource.wolfsonmicro.com>
On 11/16/2012 14:41, Mark Brown wrote:
> On Fri, Nov 16, 2012 at 02:33:50PM +0800, Bo Shen wrote:
>> On 11/16/2012 14:12, Mark Brown wrote:
>
>>> No, this isn't what was meant - the idea is to send only the addition of
>>> pinctrl data as one patch, based off the ASoC branch instead of -next.
>
>> What is the pinctrl data? (This patch can be applied on
>
> The data you're adding in the device tree!
>
>> sound/topic/atmel branch without any conflicts)
>
> That's not helpful to anyone doing bisection if there's nothing defining
> the pin states, it means that the system won't be able to start the
> driver as the API call will fail.
>
>> The other one add pinctrl nodes, must based on -next, or else I
>> don't know where should I add the pinctrl nodes.
>
> What makes you say this?
For example, if I want to add pinctrl node
---<8---
ssc0 {
pinctrl_ssc0_tx: ssc0_tx-0 {
atmel,pins = <1 16 0x1 0x0 /* PB16 periph A */
1 17 0x1 0x0 /* PB17 periph A */
1 18 0x1 0x0>; /* PB18 periph A */
};
--->8---
This should be add into dtsi file as following
---<8---
ahb {
apb {
pinctrl {
ssc0 {
pinctrl_ssc0_tx
}
}
}
}
--->8---
In the ASoC branch tree, I don't see any pinctrl related information.
So, I say I don't know where should I add the pinctrl nodes.
May be I misunderstanding, do you mean I should only add as followign
based on ASoC tree? And the upper go into pinctrl tree?
---<8---
ssc0: ssc@fffbc000 {
compatible = "atmel,at91rm9200-ssc";
reg = <0xfffbc000 0x4000>;
interrupts = <14 4 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ssc0_tx &pinctrl_ssc0_rx>;
status = "disable";
};
--->8---
Best Regards
Bo Shen
^ permalink raw reply
* [PATCH 1/2] ARM: dts: support pinctrl single in aspenite
From: Haojian Zhuang @ 2012-11-16 7:02 UTC (permalink / raw)
To: linux-arm-kernel
Support pinctrl-single driver in aspenite DTS file.
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
---
arch/arm/boot/dts/pxa168-aspenite.dts | 109 +++++++++++++++++++++++++++++++++
arch/arm/boot/dts/pxa168.dtsi | 109 +++++++++++++++++++++++++++++++++
2 files changed, 218 insertions(+)
diff --git a/arch/arm/boot/dts/pxa168-aspenite.dts b/arch/arm/boot/dts/pxa168-aspenite.dts
index e762fac..6955242 100644
--- a/arch/arm/boot/dts/pxa168-aspenite.dts
+++ b/arch/arm/boot/dts/pxa168-aspenite.dts
@@ -24,7 +24,116 @@
soc {
apb at d4000000 {
+ pmx: pinmux at d401e000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <ðer_pins>;
+
+ ether_pins: pinmux_ether_pins {
+ pinctrl-single,pins = <
+ 0x094 0x3 /* GPIO18_SMC_nCS0 */
+ 0x0a8 0x0 /* GPIO23_SMC_nLUA */
+ 0x0b0 0x0 /* GPIO25_SMC_nLLA */
+ 0x0b8 0x0 /* GPIO27_GPIO as irq */
+ 0x0bc 0x0 /* GPIO28_SMC_RDY */
+ 0x0c0 0x0 /* GPIO29_SMC_SCLK */
+ 0x0d4 0x2 /* GPIO34_SMC_nCS1 */
+ 0x0d8 0x2 /* GPIO35_SMC_BE1 */
+ 0x0dc 0x2 /* GPIO36_SMC_BE2 */
+ >;
+ pinctrl-single,power-source = <0x0c00 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ 0x1ac 0x2 /* GPIO107_UART1_RXD */
+ 0x1b0 0x2 /* GPIO108_UART1_TXD */
+ >;
+ pinctrl-single,power-source = <0x0c00 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ nand_pins: pinmux_nand_pins {
+ pinctrl-single,pins = <
+ 0x04c 0x0 /* ND_IO15 */
+ 0x050 0x0 /* ND_IO14 */
+ 0x054 0x0 /* ND_IO13 */
+ 0x058 0x0 /* ND_IO12 */
+ 0x05c 0x0 /* ND_IO11 */
+ 0x060 0x0 /* ND_IO10 */
+ 0x064 0x0 /* ND_IO9 */
+ 0x068 0x0 /* ND_IO8 */
+ 0x06c 0x0 /* ND_IO7 */
+ 0x070 0x0 /* ND_IO6 */
+ 0x074 0x0 /* ND_IO5 */
+ 0x078 0x0 /* ND_IO4 */
+ 0x07c 0x0 /* ND_IO3 */
+ 0x080 0x0 /* ND_IO2 */
+ 0x084 0x0 /* ND_IO1 */
+ 0x088 0x0 /* ND_IO0 */
+ >;
+ pinctrl-single,power-source = <0x0800 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ ssp1_pins: pinmux_ssp1_pins {
+ pinctrl-single,pins = <
+ 0x1c4 0x6 /* GPIO113_I2S_MCLK */
+ 0x1c8 0x1 /* GPIO114_I2S_FRM */
+ 0x1cc 0x1 /* GPIO115_I2S_BCLK */
+ 0x120 0x2 /* GPIO116_I2S_RXD */
+ 0x124 0x2 /* GPIO117_I2S_TXD */
+ >;
+ pinctrl-single,power-source = <0x0800 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ keypad_pins: pinmux_keypad_pins {
+ pinctrl-single,pins = <
+ 0x1b4 0x7 /* GPIO109_KP_MKIN1 */
+ 0x1b8 0x7 /* GPIO110_KP_MKIN0 */
+ 0x1bc 0x7 /* GPIO111_KP_MKOUT7 */
+ 0x1c0 0x7 /* GPIO112_KP_MKOUT6 */
+ 0x1e4 0x7 /* GPIO121_MK_MKIN4 */
+ >;
+ pinctrl-single,power-source = <0x0800 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ lcd_pins: pinmux_lcd_pins {
+ pinctrl-single,pins = <
+ 0x0e0 0x1 /* GPIO56_LCD_FCLK_RD */
+ 0x0e4 0x1 /* GPIO57_LCD_LCLK_A0 */
+ 0x0e8 0x1 /* GPIO58_LCD_ACLK_WR */
+ 0x0ec 0x1 /* GPIO59_LCD_DENA_BIAS */
+ 0x0f0 0x1 /* GPIO60_LCD_DD0 */
+ 0x0f4 0x1 /* GPIO60_LCD_DD1 */
+ 0x0f8 0x1 /* GPIO60_LCD_DD2 */
+ 0x0fc 0x1 /* GPIO60_LCD_DD3 */
+ 0x100 0x1 /* GPIO60_LCD_DD4 */
+ 0x104 0x1 /* GPIO60_LCD_DD5 */
+ 0x108 0x1 /* GPIO60_LCD_DD6 */
+ 0x10c 0x1 /* GPIO60_LCD_DD7 */
+ 0x110 0x1 /* GPIO60_LCD_DD8 */
+ 0x114 0x1 /* GPIO60_LCD_DD9 */
+ 0x118 0x1 /* GPIO60_LCD_DD10 */
+ 0x11c 0x1 /* GPIO60_LCD_DD11 */
+ 0x120 0x1 /* GPIO60_LCD_DD12 */
+ 0x124 0x1 /* GPIO60_LCD_DD13 */
+ 0x128 0x1 /* GPIO60_LCD_DD14 */
+ 0x12c 0x1 /* GPIO60_LCD_DD15 */
+ 0x130 0x1 /* GPIO60_LCD_DD16 */
+ 0x134 0x1 /* GPIO60_LCD_DD17 */
+ 0x138 0x1 /* GPIO60_LCD_DD18 */
+ 0x13c 0x1 /* GPIO60_LCD_DD19 */
+ 0x140 0x1 /* GPIO60_LCD_DD20 */
+ 0x144 0x1 /* GPIO60_LCD_DD21 */
+ 0x148 0x1 /* GPIO60_LCD_DD22 */
+ 0x14c 0x1 /* GPIO60_LCD_DD23 */
+ >;
+ pinctrl-single,power-source = <0x0800 0x0c00>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ };
+ };
+
uart1: uart at d4017000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
status = "okay";
};
twsi1: i2c at d4011000 {
diff --git a/arch/arm/boot/dts/pxa168.dtsi b/arch/arm/boot/dts/pxa168.dtsi
index 31a7186..f91c3f3 100644
--- a/arch/arm/boot/dts/pxa168.dtsi
+++ b/arch/arm/boot/dts/pxa168.dtsi
@@ -49,6 +49,115 @@
reg = <0xd4000000 0x00200000>;
ranges;
+ pmx: pinmux at d401e000 {
+ compatible = "pinconf-single";
+ reg = <0xd401e000 0x020c>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <7>;
+
+ range0: range at d401e04c {
+ /* GPIO0 ~ GPIO15 */
+ reg = <0xd401e04c 0x40>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <0 5>;
+ };
+
+ range1: range at d401e08c {
+ /* GPIO16 */
+ reg = <0xd401e08c 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <16 0>;
+ };
+
+ range2: range at d401e090 {
+ /* GPIO17 */
+ reg = <0xd401e090 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <17 5>;
+ };
+
+ range3: range at d401e094 {
+ /* GPIO18 */
+ reg = <0xd401e094 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <18 0>;
+ };
+
+ range4: range at d401e098 {
+ /* GPIO19 */
+ reg = <0xd401e098 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <19 5>;
+ };
+
+ range5: range at d401e09c {
+ /* GPIO20 */
+ reg = <0xd401e09c 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <20 0>;
+ };
+
+ range6: range at d401e0a0 {
+ /* GPIO21 */
+ reg = <0xd401e0a0 0x14>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <21 5>;
+ };
+
+ range7: range at d401e0b4 {
+ /* GPIO26 */
+ reg = <0xd401e0b4 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <26 0>;
+ };
+
+ range8: range at d401e0b8 {
+ /* GPIO27 */
+ reg = <0xd401e0b8 0x1c>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <27 5>;
+ };
+
+ range9: range at d401e0d4 {
+ /* GPIO34 ~ GPIO36 */
+ reg = <0xd401e0d4 0x0c>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <34 0>;
+ };
+
+ range10: range at d401e000 {
+ /* GPIO37 ~ GPIO55 */
+ reg = <0xd401e000 0x4c>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <37 0>;
+ };
+
+ range11: range at d401e0e0 {
+ /* GPIO56 ~ GPIO85 */
+ reg = <0xd401e0e0 0x78>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <56 0>;
+ };
+
+ range12: range at d401e158 {
+ /* GPIO86 ~ GPIO106 */
+ reg = <0xd401e158 0x54>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <86 0>;
+ };
+
+ range13: range at d401e1ac {
+ /* GPIO107 ~ GPIO122 */
+ reg = <0xd401e1ac 0x40>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <107 0>;
+ };
+ };
+
timer0: timer at d4014000 {
compatible = "mrvl,mmp-timer";
reg = <0xd4014000 0x100>;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] ARM: mmp: support pinctrl single in brownstone
From: Haojian Zhuang @ 2012-11-16 7:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353049345-6954-1-git-send-email-haojian.zhuang@gmail.com>
Support pinctrl-single driver in brownstone platform with DT.
Signed-off-by: Haojian Zhuang <haojian.zhuang@gmail.com>
---
arch/arm/boot/dts/mmp2-brownstone.dts | 173 +++++++++++++++++++++++++++-
arch/arm/boot/dts/mmp2.dtsi | 204 +++++++++++++++++++++++++++++++++
2 files changed, 376 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/mmp2-brownstone.dts b/arch/arm/boot/dts/mmp2-brownstone.dts
index c9b4f27..d328d0f 100644
--- a/arch/arm/boot/dts/mmp2-brownstone.dts
+++ b/arch/arm/boot/dts/mmp2-brownstone.dts
@@ -15,7 +15,7 @@
compatible = "mrvl,mmp2-brownstone", "mrvl,mmp2";
chosen {
- bootargs = "console=ttyS2,38400 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
+ bootargs = "console=ttyS2,38400 root=/dev/nfs nfsroot=192.168.1.100:/nfsroot/ ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on earlyprintk";
};
memory {
@@ -24,10 +24,181 @@
soc {
apb at d4000000 {
+ pmx: pinmux at d401e000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&board_pins>;
+
+ board_pins: pinmux_board_pins {
+ pinctrl-single,pins = <
+ 0x010 0x0 /* GPIO125_GPIO as version:0 */
+ 0x014 0x0 /* GPIO126_GPIO as version:1 */
+ 0x018 0x0 /* GPIO127_GPIO as version:2 */
+ 0x01c 0x0 /* GPIO128_GPIO as version:3 */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+
+ uart1_pins: pinmux_uart1_pins {
+ pinctrl-single,pins = <
+ 0x0c8 0x1 /* GPIO29_UART1_RXD */
+ 0x0cc 0x1 /* GPIO30_UART1_TXD */
+ >;
+ /* power source, mask */
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ /* bias, mask, disable, pull down, pull up */
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ /* input schmitt, mask, disable */
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ uart2_pins: pinmux_uart2_pins {
+ pinctrl-single,pins = <
+ 0x110 0x1 /* GPIO47_UART2_RXD */
+ 0x114 0x1 /* GPIO48_UART2_TXD */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ uart3_pins: pinmux_uart3_pins {
+ pinctrl-single,pins = <
+ 0x120 0x1 /* GPIO51_UART3_RXD */
+ 0x124 0x1 /* GPIO52_UART3_TXD */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi1_pins: pinmux_twsi1_pins {
+ pinctrl-single,pins = <
+ 0x140 0x0 /* TWSI_SCL */
+ 0x144 0x0 /* TWSI_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi2_pins: pinmux_twsi2_pins {
+ pinctrl-single,pins = <
+ 0x100 0x1 /* GPIO43_TWSI2_SCL */
+ 0x104 0x1 /* GPIO44_TWSI2_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi3_pins: pinmux_twsi3_pins {
+ pinctrl-single,pins = <
+ 0x2b0 0x1 /* GPIO71_TWSI3_SCL */
+ 0x2b4 0x1 /* GPIO72_TWSI3_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi4_pins: pinmux_twsi4_pins {
+ pinctrl-single,pins = <
+ 0x2bc 0x0 /* TWSI4_SCL */
+ 0x2c0 0x0 /* TWSI4_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi5_pins: pinmux_twsi5_pins {
+ pinctrl-single,pins = <
+ 0x1d4 0x4 /* GPIO99_TWSI5_SCL */
+ 0x1d8 0x4 /* GPIO100_TWSI5_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ twsi6_pins: pinmux_twsi6_pins {
+ pinctrl-single,pins = <
+ 0x1cc 0x2 /* GPIO97_TWSI6_SCL */
+ 0x1d0 0x2 /* GPIO98_TWSI6_SDA */
+ >;
+ pinctrl-single,power-source = <0x0800 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ sspa1_pins: pinmux_sspa1_pins {
+ pinctrl-single,pins = <
+ 0x0b0 0x0 /* GPIO23_GPIO */
+ 0x0b4 0x1 /* GPIO24_I2S_SYSCLK */
+ 0x0b8 0x1 /* GPIO25_I2S_BITCLK */
+ 0x0bc 0x1 /* GPIO26_I2S_SYNC */
+ 0x0c0 0x1 /* GPIO27_I2S_DATA_OUT */
+ 0x0c4 0x1 /* GPIO28_I2S_SDATA_IN */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ sspa2_pins: pinmux_sspa2_pins {
+ pinctrl-single,pins = <
+ 0x0d8 0x1 /* GPIO33_SSPA2_CLK */
+ 0x0dc 0x1 /* GPIO34_SSPA2_FRM */
+ 0x0e0 0x1 /* GPIO35_SSPA2_TXD */
+ 0x0e4 0x1 /* GPIO36_SSPA2_RXD */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ nand_pins: pinmux_nand_pins {
+ pinctrl-single,pins = <
+ 0x1e0 0x0 /* GPIO168_DFI_D0 */
+ 0x1e4 0x0 /* GPIO167_DFI_D1 */
+ 0x1e8 0x0 /* GPIO166_DFI_D2 */
+ 0x1ec 0x0 /* GPIO165_DFI_D3 */
+ 0x1f0 0x0 /* GPIO107_DFI_D4 */
+ 0x1f4 0x0 /* GPIO106_DFI_D5 */
+ 0x1f8 0x0 /* GPIO105_DFI_D6 */
+ 0x1fc 0x0 /* GPIO104_DFI_D7 */
+ 0x200 0x0 /* GPIO111_DFI_D8 */
+ 0x204 0x0 /* GPIO164_DFI_D9 */
+ 0x208 0x0 /* GPIO163_DFI_D10 */
+ 0x20c 0x0 /* GPIO162_DFI_D11 */
+ 0x210 0x0 /* GPIO161_DFI_D12 */
+ 0x214 0x0 /* GPIO110_DFI_D13 */
+ 0x218 0x0 /* GPIO109_DFI_D14 */
+ 0x21c 0x0 /* GPIO108_DFI_D15 */
+ 0x220 0x0 /* GPIO143_ND_nCS0 */
+ 0x224 0X0 /* GPIO144_ND_nCS1 */
+ 0x230 0x0 /* GPIO147_ND_nWE */
+ 0x234 0x0 /* GPIO148_ND_nRE */
+ 0x238 0x0 /* GPIO149_ND_CLE */
+ 0x23c 0x0 /* GPIO150_ND_ALE */
+ 0x244 0x0 /* GPIO112_ND_RDY0 */
+ 0x250 0x0 /* GPIO160_ND_RDY1 */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ keypad_pins: pinmux_keypad_pins {
+ pinctrl-single,pins = <
+ 0x094 0x1 /* GPIO16_KP_DKIN0 */
+ 0x098 0X1 /* GPIO17_KP_DKIN1 */
+ 0x09c 0x1 /* GPIO18_KP_DKIN2 */
+ 0x0a0 0x1 /* GPIO19_KP_DKIN3 */
+ >;
+ pinctrl-single,power-source = <0x1000 0x1800>;
+ pinctrl-single,bias = <0xc000 0xe000 0 0xa000 0xc000>;
+ pinctrl-single,input-schmitt = <0x40 0x70 0x40>;
+ };
+ };
uart3: uart at d4018000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins>;
status = "okay";
};
twsi1: i2c at d4011000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&twsi1_pins>;
status = "okay";
};
rtc: rtc at d4010000 {
diff --git a/arch/arm/boot/dts/mmp2.dtsi b/arch/arm/boot/dts/mmp2.dtsi
index 0514fb4..1f28a1c 100644
--- a/arch/arm/boot/dts/mmp2.dtsi
+++ b/arch/arm/boot/dts/mmp2.dtsi
@@ -125,6 +125,210 @@
reg = <0xd4000000 0x00200000>;
ranges;
+ pmx: pinmux at d401e000 {
+ compatible = "pinconf-single";
+ reg = <0xd401e000 0x02c4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <7>;
+
+ range0: range at d401e054 {
+ /* GPIO0 ~ GPIO58 */
+ reg = <0xd401e054 0xec>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <0 0>;
+ };
+ range1: range at d401e280 {
+ /* GPIO59 ~ GPIO73 */
+ reg = <0xd401e280 0x40>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <59 0>;
+ };
+ range2: range at d401e170 {
+ /* GPIO74 ~ GPIO101 */
+ reg = <0xd401e170 0x70>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <74 0>;
+ };
+ range3: range at d401e000 {
+ /* GPIO102 ~ GPIO103 */
+ reg = <0xd401e000 0x08>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <0 1>;
+ };
+ range4: range at d401e1fc {
+ /* GPIO104 */
+ reg = <0xd401e1fc 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <104 1>;
+ };
+ range5: range at d401e1f8 {
+ /* GPIO105 */
+ reg = <0xd401e1f8 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <105 1>;
+ };
+ range6: range at d401e1f4 {
+ /* GPIO106 */
+ reg = <0xd401e1f4 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <106 1>;
+ };
+ range7: range at d401e1f0 {
+ /* GPIO107 */
+ reg = <0xd401e1f0 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <107 1>;
+ };
+ range8: range at d401e21c {
+ /* GPIO108 */
+ reg = <0xd401e21c 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <108 1>;
+ };
+ range9: range at d401e218 {
+ /* GPIO109 */
+ reg = <0xd401e218 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <109 1>;
+ };
+ range10: range at d401e214 {
+ /* GPIO110 */
+ reg = <0xd401e214 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <110 1>;
+ };
+ range11: range at d401e200 {
+ /* GPIO111 */
+ reg = <0xd401e200 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <111 1>;
+ };
+ range12: range at d401e244 {
+ /* GPIO112 */
+ reg = <0xd401e244 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <112 1>;
+ };
+ range13: range at d401e25c {
+ /* GPIO113 */
+ reg = <0xd401e25c 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <113 1>;
+ };
+ range14: range at d401e164 {
+ /* GPIO114 */
+ reg = <0xd401e164 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <114 0>;
+ };
+ range15: range at d401e260 {
+ /* GPIO115 ~ GPIO122 */
+ reg = <0xd401e260 0x20>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <115 0>;
+ };
+ range16: range at d401e148 {
+ /* GPIO123 */
+ reg = <0xd401e148 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <123 0>;
+ };
+ range17: range at d401e00c {
+ /* GPIO124 ~ GPIO141 */
+ reg = <0xd401e00c 0x48>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <124 0>;
+ };
+ range18: range at d401e008 {
+ /* GPIO142 */
+ reg = <0xd401e008 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <142 1>;
+ };
+ range19: range at d401e220 {
+ /* GPIO143 ~ GPIO151 */
+ reg = <0xd401e220 0x24>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <143 1>;
+ };
+ range20: range at d401e248 {
+ /* GPIO152 ~ GPIO153 */
+ reg = <0xd401e248 0x08>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <152 1>;
+ };
+ range21: range at d401e254 {
+ /* GPIO154 ~ GPIO155 */
+ reg = <0xd401e254 0x08>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <154 1>;
+ };
+ range22: range at d401e14c {
+ /* GPIO156 ~ GPIO159 */
+ reg = <0xd401e14c 0x10>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <156 1>;
+ };
+ range23: range at d401e250 {
+ /* GPIO160 */
+ reg = <0xd401e250 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <160 1>;
+ };
+ range24: range at d401e210 {
+ /* GPIO161 */
+ reg = <0xd401e210 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <161 1>;
+ };
+ range25: range at d401e20c {
+ /* GPIO162 */
+ reg = <0xd401e20c 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <162 1>;
+ };
+ range26: range at d401e208 {
+ /* GPIO163 */
+ reg = <0xd401e208 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <163 1>;
+ };
+ range27: range at d401e204 {
+ /* GPIO164 */
+ reg = <0xd401e204 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <164 1>;
+ };
+ range28: range at d401e1ec {
+ /* GPIO165 */
+ reg = <0xd401e1ec 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <165 1>;
+ };
+ range29: range at d401e1e8 {
+ /* GPIO166 */
+ reg = <0xd401e1e8 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <166 1>;
+ };
+ range30: range at d401e1e4 {
+ /* GPIO167 */
+ reg = <0xd401e1e4 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <167 1>;
+ };
+ range31: range at d401e1e0 {
+ /* GPIO168 */
+ reg = <0xd401e1e0 0x04>;
+ /* gpio base & gpio func */
+ pinctrl-single,gpio = <168 1>;
+ };
+ };
+
timer0: timer at d4014000 {
compatible = "mrvl,mmp-timer";
reg = <0xd4014000 0x100>;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
From: Tomi Valkeinen @ 2012-11-16 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121112225037.GU6801@atomide.com>
On 2012-11-13 00:50, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [121112 02:27]:
>> Hi,
>>
>> This series changes omapfb to use standard dma_alloc funcs instead of omap
>> specific vram allocator. This let's us remove the omap vram allocator, making
>> omapfb platform independent.
>>
>> However, note that using standard dma funcs causes the following downsides:
>>
>> 1) dma_alloc_attrs doesn't let us allocate at certain physical address.
>> However, this should not be a problem as this feature of vram allocator
>> is only used when reserving the framebuffer that was initialized by the
>> bootloader, and we don't currently support "passing" a framebuffer from
>> the bootloader to the kernel anyway.
>>
>> 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
>> we don't need the ioremap when using VRFB. This patch uses
>> DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
>> not operational.
>>
>> 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
>> changed the ioctl to return 64M for all the values, which, I hope, the
>> applications will interpret as "there's enough vram".
>>
>> 4) "vram" kernel parameter to define how much ram to reserve for video use no
>> longer works. The user needs to enable CMA and use "cma" parameter.
>
> Great, thanks for fixing these. Could you please queue these into
> a separate branch against v3.7-rc5 that I can also merge into
> omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3?
>
> Feel free to add my Acked-by: Tony Lindgren <tony@atomide.com> to the
> arch/arm/*omap*/* parts.
I added your acks, and pushed:
git://gitorious.org/linux-omap-dss2/linux.git 3.8/vram-conversion
It's based on -rc4 as my other branches are based on that.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/826d1247/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] ARM: dts: imx: add imx5x phy-mode entries
From: Shawn Guo @ 2012-11-16 7:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352988014-14769-5-git-send-email-m.grzeschik@pengutronix.de>
On Thu, Nov 15, 2012 at 03:00:14PM +0100, Michael Grzeschik wrote:
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> ---
> arch/arm/boot/dts/imx51.dtsi | 2 ++
> arch/arm/boot/dts/imx53.dtsi | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
> index 366b8d3..ffc6bc8 100644
> --- a/arch/arm/boot/dts/imx51.dtsi
> +++ b/arch/arm/boot/dts/imx51.dtsi
> @@ -145,6 +145,7 @@
> compatible = "fsl,imx51-usb", "fsl,imx27-usb";
> reg = <0x73f80200 0x0200>;
> interrupts = <14>;
> + phy-mode = "utmiw";
I tried to grep "phy-mode" and "utmiw" on linux-next and found nothing.
So it's not something we can take for 3.8, right?
PS. Instead, I found something like phy_type = "utmi_wide" in
fsl-usb.txt and fsl-mph-dr-of.c. Should these be consolidated into
a common binding?
Shawn
> status = "disabled";
> };
>
> @@ -152,6 +153,7 @@
> compatible = "fsl,imx51-usb", "fsl,imx27-usb";
> reg = <0x73f80400 0x0200>;
> interrupts = <16>;
> + phy-mode = "utmi";
> status = "disabled";
> };
>
> diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
> index 2faa193..1da8e12 100644
> --- a/arch/arm/boot/dts/imx53.dtsi
> +++ b/arch/arm/boot/dts/imx53.dtsi
> @@ -143,6 +143,7 @@
> compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> reg = <0x53f80000 0x0200>;
> interrupts = <18>;
> + phy-mode = "utmiw";
> status = "disabled";
> };
>
> @@ -150,6 +151,7 @@
> compatible = "fsl,imx53-usb", "fsl,imx27-usb";
> reg = <0x53f80200 0x0200>;
> interrupts = <14>;
> + phy-mode = "utmi";
> status = "disabled";
> };
>
> --
> 1.7.10.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/6] Add basic support for Allwinner A1X SoCs
From: Stefan Roese @ 2012-11-16 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353019586-21043-1-git-send-email-maxime.ripard@free-electrons.com>
Hi Maxime,
On 11/15/2012 11:46 PM, Maxime Ripard wrote:
> You'll find in this patchset the initial support for Allwinner A10 and A13 SoCs
> from Allwinner. Since the internal name of these SoCs are sun4i and sun5i, the
> mach- directory is named sunxi.
>
> You can find these SoCs in the Cubieboard, the A13-olinuxino or the Melee
> A1000.
>
> Both SoCs should work fine, as the A13 is a trimmed down version of the A10,
> but it has only been tested on a A13-OlinuXino from Olimex.
>
> Support is quite minimal for now, since it only includes timer and IRQ
> controller drivers, so we can only boot to userspace through initramfs. Support
> for the other peripherals on these SoCs will come eventually.
Great, thanks!
I've been working on upstreaming sunxi support as well in the last days.
You were a bit faster. :) Here is my latest port, for review on the
linux-sunxi list:
https://groups.google.com/forum/#!topic/linux-sunxi/H4ct05OmYtQ
(sorry about this google list)
I'll review your patches soon and send some comments.
Thanks,
Stefan
^ permalink raw reply
* Configure the USB device/host on sam9g25 module
From: Martin Peevski @ 2012-11-16 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cc2fa961-1156-48b8-b805-6583df35e126@email.android.com>
Hi,
the evaluation kit sam9x5-ek is supplied with micro USB connector, I
think it's impossible to connect mini USB on that?
On 15/11/12 18:56, Zhong Li wrote:
> It is a hardware configuration problem. You must use a type-A mini USB
> cable.
>
> Martin Peevski <martin@ronetix.at> wrote:
>
> Hi,
>
> I'm working with sam9g25 module placed on sam9x5-ek. sam9g25 has 2
> host USB's and 1 device/host USB (on the micro USB of sam9x5-ek). Both
> USB hosts accept mass storage devices and works correct. It was
> impossible to do 2 things with the USB device/host (placed on the micro
> USB of sam9x5-ek):
>
> 1. Put in it mass storage device - the kernel want not to
> enumerate it and give it an name (for example sda, sdb, ...). What I
> must do in the config file of kernel to be recognized the inserted mass
> storage device?
>
> 2. Connect cable from the micro USB to any of the host USB's and
> detect USB serial gadget.
>
> I tryed to make some configs for both problems in the kernel but it
> don't works. Can you, please, help me solve these problems?
>
> ------------------------------------------------------------------------
>
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121116/704df9b1/attachment-0001.html>
^ permalink raw reply
* [GIT PULL] imx device tree changes for 3.8
From: Shawn Guo @ 2012-11-16 7:31 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 68b25325a7fd290b5e472bba0df9cbe8c1a81d8f:
ARM: imx: select HAVE_IMX_SRC when SMP is enabled (2012-10-23 15:37:51 +0800)
are available in the git repository at:
git://git.linaro.org/people/shawnguo/linux-2.6.git tags/imx-dt-3.8
for you to fetch changes up to 96efb44e471250592ee865ce5b870bc6f860921f:
ARM: imx6q: select ARM and PL310 errata (2012-11-16 14:52:29 +0800)
----------------------------------------------------------------
It's based on imx/multiplatform branch. Most of them are dts changes.
There are also a few imx6 improvement patches in there.
----------------------------------------------------------------
Fabio Estevam (3):
ARM: dts: imx53-qsb: Use pinctrl for gpio-led
ARM: dts: imx53-qsb: Make DA9053 regulator functional
ARM: dts: imx6q-sabreauto: Add basic support
Liu Ying (1):
ARM: dts: imx6q-sabresd: add volume up/down gpio keys
Roland Stigge (1):
ARM: dts: imx53: pinctl update
Sascha Hauer (2):
ARM i.MX dtsi: Add default bus-width property for esdhc controller
ARM i.MX dts: Consistently add labels to devicenodes
Shawn Guo (5):
ARM: imx6q: let users input debug uart port number
ARM: dts: imx6q: enable snvs lp rtc
ARM: imx: enable cpufreq for imx6q
ARM: imx6q: print silicon version on boot
ARM: imx6q: select ARM and PL310 errata
Documentation/devicetree/bindings/arm/fsl.txt | 4 +
arch/arm/Kconfig.debug | 26 +++---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx27.dtsi | 5 +-
arch/arm/boot/dts/imx51.dtsi | 43 +++++-----
arch/arm/boot/dts/imx53-qsb.dts | 62 ++++++++++----
arch/arm/boot/dts/imx53.dtsi | 92 +++++++++++++++-----
arch/arm/boot/dts/imx6q-sabreauto.dts | 64 ++++++++++++++
arch/arm/boot/dts/imx6q-sabresd.dts | 18 ++++
arch/arm/boot/dts/imx6q.dtsi | 114 +++++++++++++++----------
arch/arm/include/debug/imx.S | 20 ++++-
arch/arm/mach-imx/Kconfig | 11 +++
arch/arm/mach-imx/clk-imx6q.c | 1 +
arch/arm/mach-imx/lluart.c | 28 +++---
arch/arm/mach-imx/mach-imx6q.c | 35 ++++++++
arch/arm/mach-imx/mx6q.h | 4 -
16 files changed, 389 insertions(+), 139 deletions(-)
create mode 100644 arch/arm/boot/dts/imx6q-sabreauto.dts
^ permalink raw reply
* [PATCH 0/7] core, cpu and gated clocks for mvebu
From: Andrew Lunn @ 2012-11-16 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121115225425.6230f370@skate>
> I had a quick look and made a few comments, but overall, it looks
> really great. I really hope we can get this in 3.8.
Hi Thomas
Thanks for the quick feedback.
It looks like i squashed some patches from Sebastian in the wrong
place. I will fix this and your other comments. I will probably send
out a new version tomorrow to give others chance to comment.
Andrew
^ permalink raw reply
* [PATCH 2/6] irqchip: sunxi: Add irq controller driver
From: Stefan Roese @ 2012-11-16 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353019586-21043-3-git-send-email-maxime.ripard@free-electrons.com>
On 11/15/2012 11:46 PM, Maxime Ripard wrote:
<snip>
> diff --git a/drivers/irqchip/irq-sunxi.c b/drivers/irqchip/irq-sunxi.c
> new file mode 100644
> index 0000000..9dcb323
> --- /dev/null
> +++ b/drivers/irqchip/irq-sunxi.c
> @@ -0,0 +1,173 @@
> +/*
> + * Allwinner A1X SoCs IRQ chip driver.
> + *
> + * Copyright (C) 2012 Maxime Ripard
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * Based on code from
> + * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
> + * Benn Huang <benn@allwinnertech.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/io.h>
> +#include <linux/irq.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +
> +#include <linux/irqchip/sunxi.h>
> +
> +#define SUNXI_IRQ_PROTECTION_REG 0x08
> +#define SUNXI_IRQ_NMI_CTRL_REG 0x0c
> +#define SUNXI_IRQ_PENDING_REG(x) (0x10 + 0x4 * x)
> +#define SUNXI_IRQ_FIQ_PENDING_REG(x) (0x20 + 0x4 * x)
> +#define SUNXI_IRQ_ENABLE_REG(x) (0x40 + 0x4 * x)
> +#define SUNXI_IRQ_MASK_REG(x) (0x50 + 0x4 * x)
> +
> +static void __iomem *sunxi_irq_base;
> +static struct irq_domain *sunxi_irq_domain;
> +
> +void sunxi_irq_ack(struct irq_data *irqd)
> +{
> + unsigned int irq = irqd_to_hwirq(irqd);
> + unsigned int irq_off = irq % 32;
> + int reg = irq / 32;
> + u32 val;
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> + writel(val & ~(1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
> + writel(val | (1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_PENDING_REG(reg));
> + writel(val | (1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_PENDING_REG(reg));
Are you sure that you need to touch all those 23registers to ack the
interrupt? I know that the original code provided by Allwinner does
exactly this. My tests have shown though, that writing to the pending
reg is enough.
> +}
> +
> +static void sunxi_irq_mask(struct irq_data *irqd)
> +{
> + unsigned int irq = irqd_to_hwirq(irqd);
> + unsigned int irq_off = irq % 32;
> + int reg = irq / 32;
> + u32 val;
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> + writel(val & ~(1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
> + writel(val | (1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
I unmasked all interrupts in the mask register in the init function.
Then only using the enable register for masking/unmasking seems to be
enough. What do you think?
> +}
> +
> +static void sunxi_irq_unmask(struct irq_data *irqd)
> +{
> + unsigned int irq = irqd_to_hwirq(irqd);
> + unsigned int irq_off = irq % 32;
> + int reg = irq / 32;
> + u32 val;
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> + writel(val | (1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(reg));
> +
> + val = readl(sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
> + writel(val & ~(1 << irq_off),
> + sunxi_irq_base + SUNXI_IRQ_MASK_REG(reg));
> +
> + /* Must clear pending bit when enabled */
> + if (irq == 0)
> + writel(1, sunxi_irq_base + SUNXI_IRQ_PENDING_REG(0));
Again. Might be that one register is enough here.
> +}
> +
> +static struct irq_chip sunxi_irq_chip = {
> + .name = "sunxi_irq",
> + .irq_ack = sunxi_irq_ack,
> + .irq_mask = sunxi_irq_mask,
> + .irq_unmask = sunxi_irq_unmask,
> +};
> +
> +static int sunxi_irq_map(struct irq_domain *d, unsigned int virq,
> + irq_hw_number_t hw)
> +{
> + irq_set_chip(virq, &sunxi_irq_chip);
> + irq_set_handler(virq, handle_level_irq);
irq_set_chip_and_handler()
> + set_irq_flags(virq, IRQF_VALID | IRQF_PROBE);
> +
> + return 0;
> +}
> +
> +static struct irq_domain_ops sunxi_irq_ops = {
> + .map = sunxi_irq_map,
> + .xlate = irq_domain_xlate_onecell,
> +};
> +
> +static int __init sunxi_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + sunxi_irq_base = of_iomap(node, 0);
> + if (!sunxi_irq_base)
> + panic("%s: unable to map IC registers\n",
> + node->full_name);
> +
> + /* Disable all interrupts */
> + writel(0, sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(0));
> + writel(0, sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(1));
> + writel(0, sunxi_irq_base + SUNXI_IRQ_ENABLE_REG(2));
> +
> + /* Mask all the interrupts */
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_MASK_REG(0));
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_MASK_REG(1));
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_MASK_REG(2));
Here is where I wrote 0 to the mask registers.
> + /* Clear all the pending interrupts */
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_PENDING_REG(0));
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_PENDING_REG(1));
> + writel(0xffffffff, sunxi_irq_base + SUNXI_IRQ_PENDING_REG(2));
> +
> + /* Enable protection mode */
> + writel(0x01, sunxi_irq_base + SUNXI_IRQ_PROTECTION_REG);
> +
> + /* Configure the external interrupt source type */
> + writel(0x00, sunxi_irq_base + SUNXI_IRQ_NMI_CTRL_REG);
> +
> + sunxi_irq_domain = irq_domain_add_linear(node, 3 * 32,
> + &sunxi_irq_ops, NULL);
> + if (!sunxi_irq_domain)
> + panic("%s: unable to create IRQ domain\n", node->full_name);
> +
> + return 0;
> +}
> +
> +static struct of_device_id sunxi_irq_dt_ids[] __initconst = {
> + { .compatible = "allwinner,sunxi-ic", .data = sunxi_of_init }
> +};
> +
> +void __init sunxi_init_irq(void)
> +{
> + of_irq_init(sunxi_irq_dt_ids);
> +}
> +
> +asmlinkage void __exception_irq_entry sunxi_handle_irq(struct pt_regs *regs)
> +{
> + u32 irq, reg;
> + int i;
> +
> + for (i = 0; i < 3; i++) {
> + reg = readl(sunxi_irq_base + SUNXI_IRQ_PENDING_REG(i));
> + if (reg == 0)
> + continue;
> + irq = ilog2(reg);
> + break;
> + }
> + irq = irq_find_mapping(sunxi_irq_domain, irq);
> + handle_IRQ(irq, regs);
Why don't you use the interrupt-vector register to get the active
interrupt source? Here is my version:
asmlinkage void __exception_irq_entry sunxi_handle_irq(struct pt_regs *regs)
{
u32 irq;
irq = readl(int_base + SW_INT_VECTOR_REG) >> 2;
irq = irq_find_mapping(sunxi_vic_domain, irq);
handle_IRQ(irq, regs);
}
I suggest you give it a try.
Cheers,
Stefan
^ permalink raw reply
* [PATCH 3/6] ARM: sunxi: Add basic support for Allwinner A1x SoCs
From: Stefan Roese @ 2012-11-16 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353019586-21043-4-git-send-email-maxime.ripard@free-electrons.com>
On 11/15/2012 11:46 PM, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Looks good. Thanks.
Acked-by: Stefan Roese <sr@denx.de>
I'll add cubieboard support once this series has stabilized.
Thanks,
Stefan
^ permalink raw reply
* [PATCH 4/6] ARM: sunxi: Add earlyprintk support
From: Stefan Roese @ 2012-11-16 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353019586-21043-5-git-send-email-maxime.ripard@free-electrons.com>
On 11/15/2012 11:46 PM, Maxime Ripard wrote:
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
> arch/arm/Kconfig.debug | 8 ++++++++
> arch/arm/include/debug/sunxi.S | 22 ++++++++++++++++++++++
> 2 files changed, 30 insertions(+)
> create mode 100644 arch/arm/include/debug/sunxi.S
>
> diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
> index b0f3857..6672b02 100644
> --- a/arch/arm/Kconfig.debug
> +++ b/arch/arm/Kconfig.debug
> @@ -345,6 +345,13 @@ choice
> Say Y here if you want kernel low-level debugging support
> on SOCFPGA based platforms.
>
> + config DEBUG_SUNXI_UART
> + bool "Kernel low-level debugging messages via sunXi UART"
> + depends on ARCH_SUNXI
> + help
> + Say Y here if you want kernel low-level debugging support
> + on Allwinner A1X based platforms.
>
> config DEBUG_VEXPRESS_UART0_DETECT
> bool "Autodetect UART0 on Versatile Express Cortex-A core tiles"
> depends on ARCH_VEXPRESS && CPU_CP15_MMU
> @@ -416,6 +423,7 @@ config DEBUG_LL_INCLUDE
> default "debug/mvebu.S" if DEBUG_MVEBU_UART
> default "debug/picoxcell.S" if DEBUG_PICOXCELL_UART
> default "debug/socfpga.S" if DEBUG_SOCFPGA_UART
> + default "debug/sunxi.S" if DEBUG_SUNXI_UART
> default "debug/vexpress.S" if DEBUG_VEXPRESS_UART0_DETECT || \
> DEBUG_VEXPRESS_UART0_CA9 || DEBUG_VEXPRESS_UART0_RS1
> default "mach/debug-macro.S"
> diff --git a/arch/arm/include/debug/sunxi.S b/arch/arm/include/debug/sunxi.S
> new file mode 100644
> index 0000000..ffd101f
> --- /dev/null
> +++ b/arch/arm/include/debug/sunxi.S
> @@ -0,0 +1,22 @@
> +/*
> + * Early serial output macro for Allwinner A1X SoCs
> + *
> + * Copyright (C) 2012 Maxime Ripard
> + *
> + * Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * 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.
> +*/
> +
> +#define SUNXI_UART1_PHYS_BASE 0x01c28400
> +#define SUNXI_UART1_VIRT_BASE 0xf1c28400
> +
> + .macro addruart, rp, rv, tmp
> + ldr \rp, =SUNXI_UART1_PHYS_BASE
> + ldr \rv, =SUNXI_UART1_VIRT_BASE
> + .endm
> +
> +#define UART_SHIFT 2
> +#include <asm/hardware/debug-8250.S>
A10 (cubieboard) has debug the UART on UART0 instead of UART1 as on A13.
So we need support this here as well. I suggest that I add support debug
on UART0 with my cubieboard patches.
So:
Acked-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
^ permalink raw reply
* OMAP baseline test results for v3.7-rc5
From: Richard Cochran @ 2012-11-16 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50A26FC6.4070201@gmail.com>
On Tue, Nov 13, 2012 at 08:05:26PM +0400, Igor Mazanov wrote:
> Paul Walmsley wrote:
> >
> >* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
> > - May be fixed now, pending retest:
> > - http://marc.info/?l=linux-omap&m=135082257727502&w=2
> > - Not yet part of the automated test suite
> > * May be due to an old U-boot with FDT support problems used here?
> > Pending local investigation and re-test
>
> I have the same result with omap2plus_defconfig and kernel 3.7.0-rc5. I dumped
> the kernel log buffer via JTAG and can send this log if it could be useful.
I just got my BeagleBone replaced via RMA, and so I could try a fresh
build of 3.7.0-rc5 with omap2plus_defconfig. It works just fine for me.
A few details:
U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20)
setenv ipaddr 192.168.0.77
setenv serverip 192.168.0.12
setenv netmask 255.255.255.0
setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x82000000,16MB ramdisk_size=16384 earlyprintk=serial
tftp 81000000 uImage
tftp 82000000 beaglebone-initrd.gz
tftp 80000000 am335x-bone.dtb
bootm 81000000 - 80000000
So I guess just using a recent u-boot will fix whatever issues you are
seeing.
Thanks,
Richard
^ permalink raw reply
* [PATCH 0/6] Add basic support for Allwinner A1X SoCs
From: Arnd Bergmann @ 2012-11-16 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1353019586-21043-1-git-send-email-maxime.ripard@free-electrons.com>
On Thursday 15 November 2012, Maxime Ripard wrote:
> You'll find in this patchset the initial support for Allwinner A10 and A13 SoCs
> from Allwinner. Since the internal name of these SoCs are sun4i and sun5i, the
> mach- directory is named sunxi.
>
> You can find these SoCs in the Cubieboard, the A13-olinuxino or the Melee
> A1000.
>
> Both SoCs should work fine, as the A13 is a trimmed down version of the A10,
> but it has only been tested on a A13-OlinuXino from Olimex.
>
> Support is quite minimal for now, since it only includes timer and IRQ
> controller drivers, so we can only boot to userspace through initramfs. Support
> for the other peripherals on these SoCs will come eventually.
Hi Maxime,
Thanks for sending these, I'm pretty excited we actually get this far
for 3.8. All patches look good for inclusion from my side, but I'll let
Stefan and others comment first and then take your second version. We
are getting closer to the merge window already, so I'd like to pull
it in rather soon and maybe add some fixups later.
I've also ordered a Cubieboard myself now, so hopefully I'll also find
some time to play with this.
Arnd
^ 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