* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Benoit Cousson @ 2012-10-26 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210261750430.7573@utopia.booyaka.com>
Hi Paul,
On 10/26/2012 07:54 PM, Paul Walmsley wrote:
> On Fri, 26 Oct 2012, Benoit Cousson wrote:
>
>> On 10/26/2012 05:16 PM, Roger Quadros wrote:
>>
>>> I still can't get musb to work on 3.7-rc2. Apparently it is still
>>> missing the patches from Benoit's for_3.7/dts_part2.
>>>
>>> Maybe I just need to wait for it to be merged?
>>
>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding
>> ctrl_module address in the USB data was rejected and thus I'm not sure
>> it will work without that.
>
> For v3.7-rc timeframe, looks like it's waiting on an ack from you:
>
> http://www.spinics.net/lists/arm-kernel/msg201028.html
Oups, I missed that one. But I thought Roger was mentioning the DT patch
and not that one.
Anyway, I will answer to Tony. Thanks for the reminder Paul.
Regards,
Benoit
^ permalink raw reply
* [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
From: Tony Lindgren @ 2012-10-26 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK=WgbY2-Ajm-2OSheOgLCd4589WKDSqqKjzHkE5Ogyp4puJ3g@mail.gmail.com>
* Ohad Ben-Cohen <ohad@wizery.com> [121026 02:56]:
> Hi Laurent,
>
> On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> > That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2,
> > adding DT support, moving to the common clock framework (when that will be
> > available for the OMAP3), supporting missing V4L2 features, ... All this in my
> > spare time of course, otherwise it wouldn't be fun, would it ? ;-)
>
> Hmm, seems like a short to-do list ;)
Sounds Laurent will take care of it :)
> > I would also like to move the tidspbridge to the DMA API, but I think we'll
> > need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an
> > intermediate step would allow splitting patches in reviewable chunks. I know
> > it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a
> > temporary nuisance to make the leap easier.
>
> Since tidspbridge is in staging I guess it's not a problem, though it
> sounds to me like using the correct API in the first place is going to
> make less churn.
Not related to these patches, but also sounds like we may need to drop
some staging/tidspbridge code to be able to move forward with the
ARM common zImage plans. See the "[GIT PULL] omap plat header removal
for v3.8 merge window, part1" thread for more info.
Regards,
Tony
^ permalink raw reply
* [PATCH] arm: kirkwood: add support for ZyXEL NSA310
From: Jason Cooper @ 2012-10-26 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.02.1210261857100.20029@mirri>
Hi Tero,
On Fri, Oct 26, 2012 at 08:25:52PM +0300, Tero Jaasko wrote:
> > hmmm, there probably won't be any conflicts when I go to apply this, but
> > in the future, please base against a tag in Linus' tree. eg v3.6
>
> I see and did that on the new submission attached to Andrew's mail.
Just to clarify, -rc's are fine as well, no need to change for this
patch.
> > > + model = "ZyXEL NSA310";
> > > + compatible = "zyxel,nsa310", "marvell,kirkwood-88f6281", "marvell,kirkwood";
> >
> > Is there only one variant of the nsa310? eg did they change flash types
> > or ram size during a production run? Whether they did or not, we prefer
> > to be as specific as possible here, eg "zyxel,nsa310-PRODNUM" If you can
> > locate a PRODNUM that will most likely change if they change the BOM,
> > etc. Please add this string in addition to what you currently have.i
>
> I have no idea what product number or other id this device has.
> On http://zyxel.nas-central.org/wiki/Category:NSA-310 it is
> said that there is at least a sister model under "TDC Homedisk" label.
> The TDC variant seems to have different amount of leds and at least
> the NAND partition configuration is also different. And also some
> variant exists on some sources somewhere which might not have been
> sold at all.
>
> The device I have looks like the one described on previous link
> as a "genuine". It does not have even the NSA310 printed in it,
> just "ZyXEL" and two printed stickers, one with ethernet MAC
> address and one with a long number which might be a serial number.
> Or not. It is formatted as S111M32xxxxxx, x being a number.
> The string itself is unknown to google, hence it might be a unique id.
>
> What should we do? Add better device id if/when somebody from
> Denmark comes up with a TDC device that requires different DT?
Thanks for the explaination, let's leave it the way it is. If we get
a hold of the TDC Homedisk, we can make it "zyxel,TDC-Homedisk".
> > > +config MACH_NSA310_DT
> > > + bool "ZyXEL NSA-310 (Flattened Device Tree)"
> > > + select ARCH_KIRKWOOD_DT
> > > + select ARM_APPENDED_DTB
> > > + select ARM_ATAG_DTB_COMPAT
> >
> > I would prefer not to enable APPENDED_DTB by default.
>
> Ok, I removed that. I just believe it is needed to be actually
> boot the device with stock uBoot. Or is there other/better way to bundle the
> DT blob into uImage?
My understanding of the Kernel policy is that APPENDED_DTB defeats the
purpose of having devicetree (one kernel zImage capable of booting on
any ARM board when provided the dtb). The sole reason I am aware of for
APPENDED_DTB existing in the kernel is to assist end users who are
unable to upgrade their bootloader.
Kirkwood doesn't really have this problem as a lot of the boards have
JTAG access, and those that don't can load a u-boot image over serial
via kwboot.
If you find a kirkwood board that doesn't work with kwboot, please let
us and the u-boot community know so we can fix kwboot.
> The uBoot my device is dated as "U-Boot 1.1.4 (Feb 22 2011 - 10:31:35)
> Marvell version: 3.4.1", and as far as I know, it does not have the DT
> support. I have not tried with a more recent uBoot. After having bricked
> one Buffalo Ls-xhl with a failed uBoot update, I will not do another
> before populating the JTAG pins on PCB and verifying that the plan
> B works;-)
Have you tried kwboot to rescue it? It doesn't require any bootloader
to work. It's in the u-boot git tree under tools/, since v2012.07.
> > > diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
> > > new file mode 100644
> > > index 0000000..4d20841
> > > --- /dev/null
> > > +++ b/arch/arm/mach-kirkwood/board-nsa310.c
> > > @@ -0,0 +1,166 @@
> > > +/*
> > > + * arch/arm/mach-kirkwood/board-nsa310.c
> > > + *
> > > + * ZyXEL NSA-310 Setup
> >
> > Copyright?
>
> ..is not really mine at least. I have just deleted ~60% of
> the code taken from openwrt.org's tree (commit at
> https://dev.openwrt.org/browser/trunk/target/linux/kirkwood/
> patches-3.3/202-zyxel-nsa-310.patch?rev=31673) and replaced
> it with the dt definitions.
Then please add this information to the commit log so that we can have a
good history of where it came from.
> > > +static unsigned int nsa310_mpp_config[] __initdata = {
> > > + MPP12_GPIO, /* led esata green */
> > > + MPP13_GPIO, /* led esata red */
> >
> > There is a patch series to convert all kirkwood DT boards over to DT
> > init of MPP is under review currently. If things go well, I'd like to
> > see this use it as well.
>
> That will be really a good improvement for all the boards and
> conversion would be easy too. After this, ehci and pcie conversion,
> the board-nsa310.c would be something like 70-80 lines instead of
> ~270 lines at original nsa-310-setup.c. Sweet.
even more than that since the gpio functionality will get wrapped up in
there as well. ;-)
> > > +
> > > +static void nsa310_power_off(void)
> > > +{
> > > + gpio_set_value(NSA310_GPIO_POWER_OFF, 1);
> > > +}
> > > +
> > > +static int __init nsa310_gpio_request(unsigned int gpio, unsigned long flags,
> > > + const char *label)
> > > +{
> > > + int err;
> > > +
> > > + err = gpio_request_one(gpio, flags, label);
> > > + if (err)
> > > + pr_err("NSA-310: can't setup GPIO%u (%s), err=%d\n",
> > > + gpio, label, err);
> > > +
> > > + return err;
> > > +}
> > > +
> > > +static void __init nsa310_gpio_init(void)
> > > +{
> > > + int err;
> > > +
> > > + err = nsa310_gpio_request(NSA310_GPIO_POWER_OFF, GPIOF_OUT_INIT_LOW,
> > > + "Power Off");
> > > + if (!err)
> > > + pm_power_off = nsa310_power_off;
> >
> > This doesn't smell right.
>
> What do you mean? The wrapper for gpio_request_one() that merely
> serves as a source for debug messages? I can replace it with
> a silent version if wanted. Is there a driver for shutting down device
> by some gpio pin defined in DT?
Sorry, I couldn't quite put my finger on it, and didn't want to delay
feedback to you. Basically, I was referring to the entire gpio_* block
of code. No one else needs this much code to accomplish the task,
however, it should all dissappear with the pinctrl conversion. Let's
leave it as is on the condition that we'll get rid it with the conversion
to DT pinctrl/gpio.
> > > + kirkwood_pcie_id(&dev, &rev);
> >
> > Does this board actually use pcie? If so, we've been looking for one to
> > test on. Just an fyi, we'll probably be hitting you up later for pcie
> > DT binding testing. ;-)
>
> If you point to a tree or patches somewhere, I am willing to test it and/or
> modify the nsa310 code to use it.
Cool, thanks! We'll hit you up when we get there. Everyone is pretty
much task saturated atm.
thx,
Jason.
^ permalink raw reply
* [PATCH 0/8] clk: ux500: Fixup smp_twd clk for clk notifiers
From: Mike Turquette @ 2012-10-26 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYdzvdJc=+gnRDEue1uZApGTc-P2pQfLAJXc_uBZLSPkQ@mail.gmail.com>
Quoting Linus Walleij (2012-10-26 01:57:49)
> On Fri, Oct 26, 2012 at 10:19 AM, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> > Samuel, a kind reminder on this, trying to collect acks to be able to
> > advise Mike to take this series through his clk tree. There are two
> > mfd patches.
> > [PATCH 2/8] mfd: db8500: Provide cpufreq table as platform data
> > [PATCH 5/8] mfd: db8500: Connect ARMSS clk to ARM OPP
>
> Two weeks of slack for review is good enough, involved
> subsystem maintainers have been Cc:ed.
>
> Mike T, can you just apply the patches please.
>
Would be better to get ACKs but enough time has passed. I'll take these
into clk-next (which will get built while I fly to Copenhagen for LCE).
Expect to see a new clk-next on Monday.
Regards,
Mike
> Yours,
> Linus Walleij
^ permalink raw reply
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Michael Walle @ 2012-10-26 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025094343.58015440@skate>
Hi Thomas
Am Donnerstag 25 Oktober 2012, 09:43:43 schrieb Thomas Petazzoni:
> Regardless of those GPIOs, did you solve the hang that happened even
> when you removed the gpio_set_value() calls? Or is it still a problem
> currently?
quick update, i found out, that my board loops in the mvebu interrupt handler
mvebu_gpio_irq_handler(). maybe this is also the lockup Jamie Lentin sees.
are interrupts always enabled, now? is there a way to control them? maybe
there is something missing in the dts, now.
--
michael
^ permalink raw reply
* Fwd: [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Tony Lindgren @ 2012-10-26 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EB4B4C7@DBDE01.ent.ti.com>
* Hiremath, Vaibhav <hvaibhav@ti.com> [121026 01:24]:
> On Fri, Oct 19, 2012 at 21:30:41, Tony Lindgren wrote:
> > * Richard Cochran <richardcochran@gmail.com> [121018 23:18]:
> > > On Fri, Oct 19, 2012 at 02:18:29AM +0530, Vaibhav Hiremath wrote:
> > > >
> > > > Another important point is, this driver is also required and used for
> > > > Davinci family of devices (arch/mach/mach-davinci/).
> > >
> > > That is really beside the point. If the code isn't ready yet, then
> > > don't merge it.
> > >
> > > When I asked about the beaglebone, I was given the impression that it
> > > will be ready for v3.7-rc1. But, as I know realize, at the current
> > > rate, it might not even be ready for v3.8.
> > >
> > > I don't mind waiting, but please make sure that whatever lands into a
> > > release is really, truly working.
> >
> > Indeed. This has been a problem with many of the TI patches in
> > general. People are working on separate product trees and then produce
> > patches for the mainline kernel that are poorly tested.
> >
>
> Tony,
>
> It may not be true always, as we always work simultaneously and there are
> high chances that some patches/development is dependent on others from
> functionality perspective (especially baseport), but still they are
> independent modules (may be for other devices).
>
> Lets take a example of AM33xx and OMAP5 here, we started submitting baseport
> patches to the list (almost 6-8 months now), not all the patches gets
> accepted together in one shot.
> As you know, when we started pushing AM33xx and OMAP5 baseport patches, we
> were at the stage where both DT and hwmod was required. First attempt for
> board file submission did not went through, since we decided to force all
> new devices migrate to DT, right?
I think you guys have done a pretty good job with the am33xx patches
in general to get the core omap changes merged.
> So the criteria initially was, build should not break and submit patches
> step-by-step.
>
> Now, with baseport patches submitted to list, individual developer can also
> start submitting patches to the respective driver's list, making sure that,
> driver doesn't change irrespective of platform. I do not see anything wrong
> with this, as we always consider driver independent.
>
> In this particular case, note that, all the patches Richard posted recently
> are AM33xx SoC integration specific patches only.
Yes now the core omap patches are merged, and people want to use
the devices with mainline kernel. That's usually good news :)
Regards,
Tony
^ permalink raw reply
* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Benoit Cousson @ 2012-10-26 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508ACF0B.60808@ti.com>
On 10/26/2012 07:57 PM, Benoit Cousson wrote:
> Hi Paul,
>
> On 10/26/2012 07:54 PM, Paul Walmsley wrote:
>> On Fri, 26 Oct 2012, Benoit Cousson wrote:
>>
>>> On 10/26/2012 05:16 PM, Roger Quadros wrote:
>>>
>>>> I still can't get musb to work on 3.7-rc2. Apparently it is still
>>>> missing the patches from Benoit's for_3.7/dts_part2.
>>>>
>>>> Maybe I just need to wait for it to be merged?
>>>
>>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding
>>> ctrl_module address in the USB data was rejected and thus I'm not sure
>>> it will work without that.
>>
>> For v3.7-rc timeframe, looks like it's waiting on an ack from you:
>>
>> http://www.spinics.net/lists/arm-kernel/msg201028.html
>
> Oups, I missed that one. But I thought Roger was mentioning the DT patch
> and not that one.
>
> Anyway, I will answer to Tony. Thanks for the reminder Paul.
Well, in fact, I cannot even find the original email in my mailbox :-(
I was banned again from linux-omap around that time, so that might be
the reason.
Tony,
So please take that hacky patch if it prevents the regression.
Thanks,
Benoit
^ permalink raw reply
* [PATCH 3/5] ARM: omap: vc: .get_voltage callback
From: Kevin Hilman @ 2012-10-26 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349313365-5262-4-git-send-email-mturquette@ti.com>
Mike Turquette <mturquette@ti.com> writes:
> From: Mike Turquette <mturquette@linaro.org>
>
> Implement the voltdm->get_voltage callback for the voltage controller
> driver.
nit: since it's not actually used in this series, it should say
Impelment the function that will be used as the ->get_voltage()
callback...
> This reads the DATA field corresponding to each VC and returns
> the voltage, after converting it from vsel format.
>
> If DATA is zero (the reset value) then the caller must interpret this as
> the PMIC running at the default power-on voltage. In such a case DT
> data for the PMIC is necessary to know the voltage.
>
> Signed-off-by: Mike Turquette <mturquette@ti.com>
> Signed-off-by: Mike Turquette <mturquette@linaro.org>
> ---
> arch/arm/mach-omap2/vc.c | 21 +++++++++++++++++++++
> arch/arm/mach-omap2/vc.h | 1 +
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
> index 2bcac64..90a9ea6 100644
> --- a/arch/arm/mach-omap2/vc.c
> +++ b/arch/arm/mach-omap2/vc.c
> @@ -101,6 +101,27 @@ static int omap_vc_config_channel(struct voltagedomain *voltdm)
> }
>
> /* Voltage scale and accessory APIs */
> +unsigned long omap_vc_get_bypass_data(struct voltagedomain *voltdm)
> +{
> + struct omap_vc_channel *vc = voltdm->vc;
> + u32 vc_bypass_value;
> + u8 vsel;
> + unsigned long volt;
> +
> + /* sanity */
> + if (!voltdm->pmic || !voltdm->pmic->vsel_to_uv ||
> + !voltdm->read || !voltdm->write)
> + return 0;
> +
> + vc_bypass_value = voltdm->read(vc->common->bypass_val_reg);
> + vc_bypass_value &= vc->common->data_mask;
> + vsel = vc_bypass_value >> __ffs(vc->common->data_mask);
Ah, now I see where the data_mask is used. :)
Kevin
> + volt = voltdm->pmic->vsel_to_uv(vsel);
> +
> + return volt;
> +}
> +
> int omap_vc_pre_scale(struct voltagedomain *voltdm,
> unsigned long target_volt,
> u8 *target_vsel, u8 *current_vsel)
> diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
> index 84a61b1..e7d4719 100644
> --- a/arch/arm/mach-omap2/vc.h
> +++ b/arch/arm/mach-omap2/vc.h
> @@ -112,6 +112,7 @@ extern struct omap_vc_channel omap4_vc_iva;
> extern struct omap_vc_channel omap4_vc_core;
>
> void omap_vc_init_channel(struct voltagedomain *voltdm);
> +unsigned long omap_vc_get_bypass_data(struct voltagedomain *voltdm);
> int omap_vc_pre_scale(struct voltagedomain *voltdm,
> unsigned long target_volt,
> u8 *target_vsel, u8 *current_vsel);
^ permalink raw reply
* [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
From: Kevin Hilman @ 2012-10-26 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349313365-5262-1-git-send-email-mturquette@ti.com>
Hi Mike,
Mike Turquette <mturquette@ti.com> writes:
> From: Mike Turquette <mturquette@linaro.org>
>
> This series creates a new callback for struct voltagedomain,
> .get_voltage. This fetches the voltage from hardware, if possible, and
> returns it to the caller. We use this call to populate
> voltdm->nominal_volt at boot time.
I pointed out a couple nitpicky things on individual patches, but
otherwise this direction and motiviation for this series looks OK by me.
Just some minor comments about the structure of the series. I tend to
prefer combining the introduction of a new function with it's usage. It
makes review and understanding much easier, IMO. If there are reasons
to keep them separate, that's fine too. Just describe the reasons in
the cover letter.
Thanks,
Kevin
^ permalink raw reply
* [PATCH 0/6] Initial Calxeda ECX-2000 support
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
From: Rob Herring <rob.herring@calxeda.com>
This series adds initial support for Calxeda A15 based ECX-2000 SOC. Most
of the changes are shuffling of dts files to share common parts between
highbank (ECX-1000) and ECX-2000 and abstracting out or removing SCU
accesses as the A15 has no SCU registers.
Although the highbank name really refers to 1st gen SOC, the highbank
name in the kernel is now referring to both SOCs.
Rob
Rob Herring (6):
ARM: highbank: disable unused sdhci and gpio in dts
ARM: highbank: enable coherent DMA for xgmac in dts
ARM: dts: Add Calxeda ECX-2000 support
ARM: smp_twd: don't warn on no DT node
ARM: highbank: abstract out SCU usage
ARM: highbank: Add initial ECX-2000 support
Documentation/devicetree/bindings/arm/calxeda.txt | 13 +-
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/ecx-2000.dts | 104 +++++++++
arch/arm/boot/dts/ecx-common.dtsi | 237 +++++++++++++++++++++
arch/arm/boot/dts/highbank.dts | 212 +-----------------
arch/arm/kernel/smp_twd.c | 6 +-
arch/arm/mach-highbank/Kconfig | 2 +-
arch/arm/mach-highbank/highbank.c | 27 +--
arch/arm/mach-highbank/hotplug.c | 6 +-
arch/arm/mach-highbank/platsmp.c | 7 +-
arch/arm/mach-highbank/pm.c | 3 -
arch/arm/mach-highbank/sysregs.h | 19 ++
arch/arm/mach-highbank/system.c | 2 -
13 files changed, 394 insertions(+), 247 deletions(-)
create mode 100644 arch/arm/boot/dts/ecx-2000.dts
create mode 100644 arch/arm/boot/dts/ecx-common.dtsi
--
1.7.10.4
^ permalink raw reply
* [PATCH 1/6] ARM: highbank: disable unused sdhci and gpio in dts
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
These peripherals are not enabled in current systems, so turn them off.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/boot/dts/highbank.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index 0c6fc34..28d5872 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -132,6 +132,7 @@
reg = <0xffe0e000 0x1000>;
interrupts = <0 90 4>;
clocks = <&eclk>;
+ status = "disabled";
};
memory-controller at fff00000 {
@@ -156,6 +157,7 @@
interrupts = <0 14 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
+ status = "disabled";
};
gpiof: gpio at fff31000 {
@@ -166,6 +168,7 @@
interrupts = <0 15 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
+ status = "disabled";
};
gpiog: gpio at fff32000 {
@@ -176,6 +179,7 @@
interrupts = <0 16 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
+ status = "disabled";
};
gpioh: gpio at fff33000 {
@@ -186,6 +190,7 @@
interrupts = <0 17 4>;
clocks = <&pclk>;
clock-names = "apb_pclk";
+ status = "disabled";
};
timer {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/6] ARM: highbank: enable coherent DMA for xgmac in dts
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Enable the xgmac to use the coherent DMA path in highbank.dts
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/boot/dts/highbank.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index 28d5872..e39a79a 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -308,12 +308,14 @@
compatible = "calxeda,hb-xgmac";
reg = <0xfff50000 0x1000>;
interrupts = <0 77 4 0 78 4 0 79 4>;
+ dma-coherent;
};
ethernet at fff51000 {
compatible = "calxeda,hb-xgmac";
reg = <0xfff51000 0x1000>;
interrupts = <0 80 4 0 81 4 0 82 4>;
+ dma-coherent;
};
combophy0: combo-phy at fff58000 {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/6] ARM: dts: Add Calxeda ECX-2000 support
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Separate out common dts pieces from highbank dts and add support for
Calxeda ECX-2000 (Midway) SOC.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
Documentation/devicetree/bindings/arm/calxeda.txt | 13 +-
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/ecx-2000.dts | 104 +++++++++
arch/arm/boot/dts/ecx-common.dtsi | 237 +++++++++++++++++++++
arch/arm/boot/dts/highbank.dts | 219 +------------------
5 files changed, 356 insertions(+), 220 deletions(-)
create mode 100644 arch/arm/boot/dts/ecx-2000.dts
create mode 100644 arch/arm/boot/dts/ecx-common.dtsi
diff --git a/Documentation/devicetree/bindings/arm/calxeda.txt b/Documentation/devicetree/bindings/arm/calxeda.txt
index 4755caa..25fcf96 100644
--- a/Documentation/devicetree/bindings/arm/calxeda.txt
+++ b/Documentation/devicetree/bindings/arm/calxeda.txt
@@ -1,8 +1,15 @@
-Calxeda Highbank Platforms Device Tree Bindings
+Calxeda Platforms Device Tree Bindings
-----------------------------------------------
-Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following
-properties.
+Boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC shall have the
+following properties.
Required root node properties:
- compatible = "calxeda,highbank";
+
+
+Boards with Calxeda Cortex-A15 based ECX-2000 SOC shall have the following
+properties.
+
+Required root node properties:
+ - compatible = "calxeda,ecx-2000";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f37cf9f..5cc9566 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -24,7 +24,8 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
exynos4210-trats.dtb \
exynos5250-smdk5250.dtb
-dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
+ ecx-2000.dtb
dtb-$(CONFIG_ARCH_INTEGRATOR) += integratorap.dtb \
integratorcp.dtb
dtb-$(CONFIG_ARCH_LPC32XX) += ea3250.dtb phy3250.dtb
diff --git a/arch/arm/boot/dts/ecx-2000.dts b/arch/arm/boot/dts/ecx-2000.dts
new file mode 100644
index 0000000..46477ac
--- /dev/null
+++ b/arch/arm/boot/dts/ecx-2000.dts
@@ -0,0 +1,104 @@
+/*
+ * Copyright 2011-2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/dts-v1/;
+
+/* First 4KB has pen for secondary cores. */
+/memreserve/ 0x00000000 0x0001000;
+
+/ {
+ model = "Calxeda ECX-2000";
+ compatible = "calxeda,ecx-2000";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ clock-ranges;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu at 0 {
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clocks = <&a9pll>;
+ clock-names = "cpu";
+ };
+
+ cpu at 1 {
+ compatible = "arm,cortex-a15";
+ reg = <1>;
+ clocks = <&a9pll>;
+ clock-names = "cpu";
+ };
+
+ cpu at 2 {
+ compatible = "arm,cortex-a15";
+ reg = <2>;
+ clocks = <&a9pll>;
+ clock-names = "cpu";
+ };
+
+ cpu at 3 {
+ compatible = "arm,cortex-a15";
+ reg = <3>;
+ clocks = <&a9pll>;
+ clock-names = "cpu";
+ };
+ };
+
+ memory at 0 {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x00000000 0x00000000 0x00000000 0xff800000>;
+ };
+
+ memory at 200000000 {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x00000002 0x00000000 0x00000003 0x00000000>;
+ };
+
+ soc {
+ ranges = <0x00000000 0x00000000 0x00000000 0xffffffff>;
+
+ timer {
+ compatible = "arm,cortex-a15-timer", "arm,armv7-timer"; interrupts = <1 13 0xf08>,
+ <1 14 0xf08>,
+ <1 11 0xf08>,
+ <1 10 0xf08>;
+ };
+
+ intc: interrupt-controller at fff11000 {
+ compatible = "arm,cortex-a15-gic";
+ #interrupt-cells = <3>;
+ #size-cells = <0>;
+ #address-cells = <1>;
+ interrupt-controller;
+ interrupts = <1 9 0xf04>;
+ reg = <0xfff11000 0x1000>,
+ <0xfff12000 0x1000>,
+ <0xfff14000 0x2000>,
+ <0xfff16000 0x2000>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a9-pmu";
+ interrupts = <0 76 4 0 75 4 0 74 4 0 73 4>;
+ };
+ };
+};
+
+/include/ "ecx-common.dtsi"
diff --git a/arch/arm/boot/dts/ecx-common.dtsi b/arch/arm/boot/dts/ecx-common.dtsi
new file mode 100644
index 0000000..d61b535
--- /dev/null
+++ b/arch/arm/boot/dts/ecx-common.dtsi
@@ -0,0 +1,237 @@
+/*
+ * Copyright 2011-2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+/ {
+ chosen {
+ bootargs = "console=ttyAMA0";
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&intc>;
+
+ sata at ffe08000 {
+ compatible = "calxeda,hb-ahci";
+ reg = <0xffe08000 0x10000>;
+ interrupts = <0 83 4>;
+ dma-coherent;
+ calxeda,port-phys = <&combophy5 0 &combophy0 0
+ &combophy0 1 &combophy0 2
+ &combophy0 3>;
+ };
+
+ sdhci at ffe0e000 {
+ compatible = "calxeda,hb-sdhci";
+ reg = <0xffe0e000 0x1000>;
+ interrupts = <0 90 4>;
+ clocks = <&eclk>;
+ status = "disabled";
+ };
+
+ memory-controller at fff00000 {
+ compatible = "calxeda,hb-ddr-ctrl";
+ reg = <0xfff00000 0x1000>;
+ interrupts = <0 91 4>;
+ };
+
+ ipc at fff20000 {
+ compatible = "arm,pl320", "arm,primecell";
+ reg = <0xfff20000 0x1000>;
+ interrupts = <0 7 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ };
+
+ gpioe: gpio at fff30000 {
+ #gpio-cells = <2>;
+ compatible = "arm,pl061", "arm,primecell";
+ gpio-controller;
+ reg = <0xfff30000 0x1000>;
+ interrupts = <0 14 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpiof: gpio at fff31000 {
+ #gpio-cells = <2>;
+ compatible = "arm,pl061", "arm,primecell";
+ gpio-controller;
+ reg = <0xfff31000 0x1000>;
+ interrupts = <0 15 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpiog: gpio at fff32000 {
+ #gpio-cells = <2>;
+ compatible = "arm,pl061", "arm,primecell";
+ gpio-controller;
+ reg = <0xfff32000 0x1000>;
+ interrupts = <0 16 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ gpioh: gpio at fff33000 {
+ #gpio-cells = <2>;
+ compatible = "arm,pl061", "arm,primecell";
+ gpio-controller;
+ reg = <0xfff33000 0x1000>;
+ interrupts = <0 17 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ status = "disabled";
+ };
+
+ timer at fff34000 {
+ compatible = "arm,sp804", "arm,primecell";
+ reg = <0xfff34000 0x1000>;
+ interrupts = <0 18 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ };
+
+ rtc at fff35000 {
+ compatible = "arm,pl031", "arm,primecell";
+ reg = <0xfff35000 0x1000>;
+ interrupts = <0 19 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ };
+
+ serial at fff36000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xfff36000 0x1000>;
+ interrupts = <0 20 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ };
+
+ smic at fff3a000 {
+ compatible = "ipmi-smic";
+ device_type = "ipmi";
+ reg = <0xfff3a000 0x1000>;
+ interrupts = <0 24 4>;
+ reg-size = <4>;
+ reg-spacing = <4>;
+ };
+
+ sregs at fff3c000 {
+ compatible = "calxeda,hb-sregs";
+ reg = <0xfff3c000 0x1000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ osc: oscillator {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <33333000>;
+ };
+
+ ddrpll: ddrpll {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-pll-clock";
+ clocks = <&osc>;
+ reg = <0x108>;
+ };
+
+ a9pll: a9pll {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-pll-clock";
+ clocks = <&osc>;
+ reg = <0x100>;
+ };
+
+ a9periphclk: a9periphclk {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-a9periph-clock";
+ clocks = <&a9pll>;
+ reg = <0x104>;
+ };
+
+ a9bclk: a9bclk {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-a9bus-clock";
+ clocks = <&a9pll>;
+ reg = <0x104>;
+ };
+
+ emmcpll: emmcpll {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-pll-clock";
+ clocks = <&osc>;
+ reg = <0x10C>;
+ };
+
+ eclk: eclk {
+ #clock-cells = <0>;
+ compatible = "calxeda,hb-emmc-clock";
+ clocks = <&emmcpll>;
+ reg = <0x114>;
+ };
+
+ pclk: pclk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <150000000>;
+ };
+ };
+ };
+
+ dma at fff3d000 {
+ compatible = "arm,pl330", "arm,primecell";
+ reg = <0xfff3d000 0x1000>;
+ interrupts = <0 92 4>;
+ clocks = <&pclk>;
+ clock-names = "apb_pclk";
+ };
+
+ ethernet at fff50000 {
+ compatible = "calxeda,hb-xgmac";
+ reg = <0xfff50000 0x1000>;
+ interrupts = <0 77 4 0 78 4 0 79 4>;
+ dma-coherent;
+ };
+
+ ethernet at fff51000 {
+ compatible = "calxeda,hb-xgmac";
+ reg = <0xfff51000 0x1000>;
+ interrupts = <0 80 4 0 81 4 0 82 4>;
+ dma-coherent;
+ };
+
+ combophy0: combo-phy at fff58000 {
+ compatible = "calxeda,hb-combophy";
+ #phy-cells = <1>;
+ reg = <0xfff58000 0x1000>;
+ phydev = <5>;
+ };
+
+ combophy5: combo-phy at fff5d000 {
+ compatible = "calxeda,hb-combophy";
+ #phy-cells = <1>;
+ reg = <0xfff5d000 0x1000>;
+ phydev = <31>;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/highbank.dts b/arch/arm/boot/dts/highbank.dts
index e39a79a..a9ae5d3 100644
--- a/arch/arm/boot/dts/highbank.dts
+++ b/arch/arm/boot/dts/highbank.dts
@@ -69,16 +69,8 @@
reg = <0x00000000 0xff900000>;
};
- chosen {
- bootargs = "console=ttyAMA0";
- };
-
soc {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "simple-bus";
- interrupt-parent = <&intc>;
- ranges;
+ ranges = <0x00000000 0x00000000 0xffffffff>;
timer at fff10600 {
compatible = "arm,cortex-a9-twd-timer";
@@ -117,178 +109,6 @@
interrupts = <0 76 4 0 75 4 0 74 4 0 73 4>;
};
- sata at ffe08000 {
- compatible = "calxeda,hb-ahci";
- reg = <0xffe08000 0x10000>;
- interrupts = <0 83 4>;
- calxeda,port-phys = <&combophy5 0 &combophy0 0
- &combophy0 1 &combophy0 2
- &combophy0 3>;
- dma-coherent;
- };
-
- sdhci at ffe0e000 {
- compatible = "calxeda,hb-sdhci";
- reg = <0xffe0e000 0x1000>;
- interrupts = <0 90 4>;
- clocks = <&eclk>;
- status = "disabled";
- };
-
- memory-controller at fff00000 {
- compatible = "calxeda,hb-ddr-ctrl";
- reg = <0xfff00000 0x1000>;
- interrupts = <0 91 4>;
- };
-
- ipc at fff20000 {
- compatible = "arm,pl320", "arm,primecell";
- reg = <0xfff20000 0x1000>;
- interrupts = <0 7 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- };
-
- gpioe: gpio at fff30000 {
- #gpio-cells = <2>;
- compatible = "arm,pl061", "arm,primecell";
- gpio-controller;
- reg = <0xfff30000 0x1000>;
- interrupts = <0 14 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- status = "disabled";
- };
-
- gpiof: gpio at fff31000 {
- #gpio-cells = <2>;
- compatible = "arm,pl061", "arm,primecell";
- gpio-controller;
- reg = <0xfff31000 0x1000>;
- interrupts = <0 15 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- status = "disabled";
- };
-
- gpiog: gpio at fff32000 {
- #gpio-cells = <2>;
- compatible = "arm,pl061", "arm,primecell";
- gpio-controller;
- reg = <0xfff32000 0x1000>;
- interrupts = <0 16 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- status = "disabled";
- };
-
- gpioh: gpio at fff33000 {
- #gpio-cells = <2>;
- compatible = "arm,pl061", "arm,primecell";
- gpio-controller;
- reg = <0xfff33000 0x1000>;
- interrupts = <0 17 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- status = "disabled";
- };
-
- timer {
- compatible = "arm,sp804", "arm,primecell";
- reg = <0xfff34000 0x1000>;
- interrupts = <0 18 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- };
-
- rtc at fff35000 {
- compatible = "arm,pl031", "arm,primecell";
- reg = <0xfff35000 0x1000>;
- interrupts = <0 19 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- };
-
- serial at fff36000 {
- compatible = "arm,pl011", "arm,primecell";
- reg = <0xfff36000 0x1000>;
- interrupts = <0 20 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- };
-
- smic at fff3a000 {
- compatible = "ipmi-smic";
- device_type = "ipmi";
- reg = <0xfff3a000 0x1000>;
- interrupts = <0 24 4>;
- reg-size = <4>;
- reg-spacing = <4>;
- };
-
- sregs at fff3c000 {
- compatible = "calxeda,hb-sregs";
- reg = <0xfff3c000 0x1000>;
-
- clocks {
- #address-cells = <1>;
- #size-cells = <0>;
-
- osc: oscillator {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <33333000>;
- };
-
- ddrpll: ddrpll {
- #clock-cells = <0>;
- compatible = "calxeda,hb-pll-clock";
- clocks = <&osc>;
- reg = <0x108>;
- };
-
- a9pll: a9pll {
- #clock-cells = <0>;
- compatible = "calxeda,hb-pll-clock";
- clocks = <&osc>;
- reg = <0x100>;
- };
-
- a9periphclk: a9periphclk {
- #clock-cells = <0>;
- compatible = "calxeda,hb-a9periph-clock";
- clocks = <&a9pll>;
- reg = <0x104>;
- };
-
- a9bclk: a9bclk {
- #clock-cells = <0>;
- compatible = "calxeda,hb-a9bus-clock";
- clocks = <&a9pll>;
- reg = <0x104>;
- };
-
- emmcpll: emmcpll {
- #clock-cells = <0>;
- compatible = "calxeda,hb-pll-clock";
- clocks = <&osc>;
- reg = <0x10C>;
- };
-
- eclk: eclk {
- #clock-cells = <0>;
- compatible = "calxeda,hb-emmc-clock";
- clocks = <&emmcpll>;
- reg = <0x114>;
- };
-
- pclk: pclk {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <150000000>;
- };
- };
- };
sregs at fff3c200 {
compatible = "calxeda,hb-sregs-l2-ecc";
@@ -296,40 +116,7 @@
interrupts = <0 71 4 0 72 4>;
};
- dma at fff3d000 {
- compatible = "arm,pl330", "arm,primecell";
- reg = <0xfff3d000 0x1000>;
- interrupts = <0 92 4>;
- clocks = <&pclk>;
- clock-names = "apb_pclk";
- };
-
- ethernet at fff50000 {
- compatible = "calxeda,hb-xgmac";
- reg = <0xfff50000 0x1000>;
- interrupts = <0 77 4 0 78 4 0 79 4>;
- dma-coherent;
- };
-
- ethernet at fff51000 {
- compatible = "calxeda,hb-xgmac";
- reg = <0xfff51000 0x1000>;
- interrupts = <0 80 4 0 81 4 0 82 4>;
- dma-coherent;
- };
-
- combophy0: combo-phy at fff58000 {
- compatible = "calxeda,hb-combophy";
- #phy-cells = <1>;
- reg = <0xfff58000 0x1000>;
- phydev = <5>;
- };
-
- combophy5: combo-phy at fff5d000 {
- compatible = "calxeda,hb-combophy";
- #phy-cells = <1>;
- reg = <0xfff5d000 0x1000>;
- phydev = <31>;
- };
};
};
+
+/include/ "ecx-common.dtsi"
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/6] ARM: smp_twd: don't warn on no DT node
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
Not having a TWD is valid if we have multiple platforms with different
cores, so remove the warning message.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/kernel/smp_twd.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index e1f9069..e52e80a 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -366,10 +366,8 @@ void __init twd_local_timer_of_register(void)
int err;
np = of_find_matching_node(NULL, twd_of_match);
- if (!np) {
- err = -ENODEV;
- goto out;
- }
+ if (!np)
+ return -ENODEV;
twd_ppi = irq_of_parse_and_map(np, 0);
if (!twd_ppi) {
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/6] ARM: highbank: abstract out SCU usage
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
In preparation for A15 support on ECX-2000, the direct calls to SCU
registers must be conditional. The SCU power mode register is replaced by
a custom register on ECX-2000.
Rather than read the number of cores from the SCU, just hardcode it to 4.
This removes one use of SCU and removes the need for the SCU to be
statically mapped. The cpu initialization will ultimately come from DT.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/mach-highbank/highbank.c | 21 +++++----------------
arch/arm/mach-highbank/hotplug.c | 6 ++----
arch/arm/mach-highbank/platsmp.c | 7 +++----
arch/arm/mach-highbank/pm.c | 3 ---
arch/arm/mach-highbank/sysregs.h | 19 +++++++++++++++++++
arch/arm/mach-highbank/system.c | 2 --
6 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 40e36a5..3da921a 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -28,30 +28,19 @@
#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
-#include <asm/smp_scu.h>
#include <asm/smp_twd.h>
#include <asm/hardware/arm_timer.h>
#include <asm/hardware/timer-sp.h>
#include <asm/hardware/gic.h>
#include <asm/hardware/cache-l2x0.h>
#include <asm/mach/arch.h>
-#include <asm/mach/map.h>
#include <asm/mach/time.h>
#include "core.h"
#include "sysregs.h"
void __iomem *sregs_base;
-
-#define HB_SCU_VIRT_BASE 0xfee00000
-void __iomem *scu_base_addr = ((void __iomem *)(HB_SCU_VIRT_BASE));
-
-static struct map_desc scu_io_desc __initdata = {
- .virtual = HB_SCU_VIRT_BASE,
- .pfn = 0, /* run-time */
- .length = SZ_4K,
- .type = MT_DEVICE,
-};
+void __iomem *scu_base_addr;
static void __init highbank_scu_map_io(void)
{
@@ -60,13 +49,11 @@ static void __init highbank_scu_map_io(void)
/* Get SCU base */
asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
- scu_io_desc.pfn = __phys_to_pfn(base);
- iotable_init(&scu_io_desc, 1);
+ scu_base_addr = ioremap(base, SZ_4K);
}
static void __init highbank_map_io(void)
{
- highbank_scu_map_io();
highbank_lluart_map_io();
}
@@ -99,6 +86,9 @@ static void __init highbank_init_irq(void)
{
of_irq_init(irq_match);
+ if (of_find_compatible_node(NULL, NULL, "arm,cortex-a9"))
+ highbank_scu_map_io();
+
#ifdef CONFIG_CACHE_L2X0
/* Enable PL310 L2 Cache controller */
highbank_smc1(0x102, 0x1);
@@ -145,7 +135,6 @@ static struct sys_timer highbank_timer = {
static void highbank_power_off(void)
{
hignbank_set_pwr_shutdown();
- scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
while (1)
cpu_do_idle();
diff --git a/arch/arm/mach-highbank/hotplug.c b/arch/arm/mach-highbank/hotplug.c
index 2c1b8c3..7b60fac 100644
--- a/arch/arm/mach-highbank/hotplug.c
+++ b/arch/arm/mach-highbank/hotplug.c
@@ -14,13 +14,11 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <linux/kernel.h>
-#include <linux/errno.h>
-#include <linux/smp.h>
-#include <asm/smp_scu.h>
#include <asm/cacheflush.h>
#include "core.h"
+#include "sysregs.h"
extern void secondary_startup(void);
@@ -33,7 +31,7 @@ void __ref highbank_cpu_die(unsigned int cpu)
flush_cache_all();
highbank_set_cpu_jump(cpu, secondary_startup);
- scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
+ highbank_set_core_pwr();
cpu_do_idle();
diff --git a/arch/arm/mach-highbank/platsmp.c b/arch/arm/mach-highbank/platsmp.c
index fa9560e..1129957 100644
--- a/arch/arm/mach-highbank/platsmp.c
+++ b/arch/arm/mach-highbank/platsmp.c
@@ -42,9 +42,7 @@ static int __cpuinit highbank_boot_secondary(unsigned int cpu, struct task_struc
*/
static void __init highbank_smp_init_cpus(void)
{
- unsigned int i, ncores;
-
- ncores = scu_get_core_count(scu_base_addr);
+ unsigned int i, ncores = 4;
/* sanity check */
if (ncores > NR_CPUS) {
@@ -65,7 +63,8 @@ static void __init highbank_smp_prepare_cpus(unsigned int max_cpus)
{
int i;
- scu_enable(scu_base_addr);
+ if (scu_base_addr)
+ scu_enable(scu_base_addr);
/*
* Write the address of secondary startup into the jump table
diff --git a/arch/arm/mach-highbank/pm.c b/arch/arm/mach-highbank/pm.c
index de866f2..74aa135 100644
--- a/arch/arm/mach-highbank/pm.c
+++ b/arch/arm/mach-highbank/pm.c
@@ -19,7 +19,6 @@
#include <linux/suspend.h>
#include <asm/proc-fns.h>
-#include <asm/smp_scu.h>
#include <asm/suspend.h>
#include "core.h"
@@ -35,8 +34,6 @@ static int highbank_pm_enter(suspend_state_t state)
{
hignbank_set_pwr_suspend();
highbank_set_cpu_jump(0, cpu_resume);
-
- scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
cpu_suspend(0, highbank_suspend_finish);
return 0;
diff --git a/arch/arm/mach-highbank/sysregs.h b/arch/arm/mach-highbank/sysregs.h
index 0e91338..e13e8ea 100644
--- a/arch/arm/mach-highbank/sysregs.h
+++ b/arch/arm/mach-highbank/sysregs.h
@@ -17,6 +17,10 @@
#define _MACH_HIGHBANK__SYSREGS_H_
#include <linux/io.h>
+#include <linux/smp.h>
+#include <asm/smp_plat.h>
+#include <asm/smp_scu.h>
+#include "core.h"
extern void __iomem *sregs_base;
@@ -29,24 +33,39 @@ extern void __iomem *sregs_base;
#define HB_PWR_HARD_RESET 2
#define HB_PWR_SHUTDOWN 3
+#define SREG_CPU_PWR_CTRL(c) (0x200 + ((c) * 4))
+
+static inline void highbank_set_core_pwr(void)
+{
+ int cpu = cpu_logical_map(smp_processor_id());
+ if (scu_base_addr)
+ scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
+ else
+ writel_relaxed(1, sregs_base + SREG_CPU_PWR_CTRL(cpu));
+}
+
static inline void hignbank_set_pwr_suspend(void)
{
writel(HB_PWR_SUSPEND, sregs_base + HB_SREG_A9_PWR_REQ);
+ highbank_set_core_pwr();
}
static inline void hignbank_set_pwr_shutdown(void)
{
writel(HB_PWR_SHUTDOWN, sregs_base + HB_SREG_A9_PWR_REQ);
+ highbank_set_core_pwr();
}
static inline void hignbank_set_pwr_soft_reset(void)
{
writel(HB_PWR_SOFT_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
+ highbank_set_core_pwr();
}
static inline void hignbank_set_pwr_hard_reset(void)
{
writel(HB_PWR_HARD_RESET, sregs_base + HB_SREG_A9_PWR_REQ);
+ highbank_set_core_pwr();
}
#endif
diff --git a/arch/arm/mach-highbank/system.c b/arch/arm/mach-highbank/system.c
index 82c2723..194a5bb 100644
--- a/arch/arm/mach-highbank/system.c
+++ b/arch/arm/mach-highbank/system.c
@@ -14,7 +14,6 @@
* this program. If not, see <http://www.gnu.org/licenses/>.
*/
#include <linux/io.h>
-#include <asm/smp_scu.h>
#include <asm/proc-fns.h>
#include "core.h"
@@ -27,7 +26,6 @@ void highbank_restart(char mode, const char *cmd)
else
hignbank_set_pwr_soft_reset();
- scu_power_mode(scu_base_addr, SCU_PM_POWEROFF);
cpu_do_idle();
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/6] ARM: highbank: Add initial ECX-2000 support
From: Rob Herring @ 2012-10-26 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351276988-28382-1-git-send-email-robherring2@gmail.com>
From: Rob Herring <rob.herring@calxeda.com>
And initial Calxeda ECX-2000 SOC support. This adds Cortex-A15 peripherals
and machine DT match name.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
arch/arm/mach-highbank/Kconfig | 2 +-
arch/arm/mach-highbank/highbank.c | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-highbank/Kconfig b/arch/arm/mach-highbank/Kconfig
index 0e1d0a4..551c97e 100644
--- a/arch/arm/mach-highbank/Kconfig
+++ b/arch/arm/mach-highbank/Kconfig
@@ -1,5 +1,5 @@
config ARCH_HIGHBANK
- bool "Calxeda ECX-1000 (Highbank)" if ARCH_MULTI_V7
+ bool "Calxeda ECX-1000/2000 (Highbank/Midway)" if ARCH_MULTI_V7
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_GIC
diff --git a/arch/arm/mach-highbank/highbank.c b/arch/arm/mach-highbank/highbank.c
index 3da921a..3e60e57 100644
--- a/arch/arm/mach-highbank/highbank.c
+++ b/arch/arm/mach-highbank/highbank.c
@@ -26,6 +26,7 @@
#include <linux/smp.h>
#include <linux/amba/bus.h>
+#include <asm/arch_timer.h>
#include <asm/cacheflush.h>
#include <asm/smp_plat.h>
#include <asm/smp_twd.h>
@@ -70,6 +71,7 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
}
const static struct of_device_id irq_match[] = {
+ { .compatible = "arm,cortex-a15-gic", .data = gic_of_init, },
{ .compatible = "arm,cortex-a9-gic", .data = gic_of_init, },
{}
};
@@ -126,6 +128,9 @@ static void __init highbank_timer_init(void)
sp804_clockevents_init(timer_base, irq, "timer0");
twd_local_timer_of_register();
+
+ arch_timer_of_register();
+ arch_timer_sched_clock_init();
}
static struct sys_timer highbank_timer = {
@@ -200,6 +205,7 @@ static void __init highbank_init(void)
static const char *highbank_match[] __initconst = {
"calxeda,highbank",
+ "calxeda,ecx-2000",
NULL,
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/9] ARM: Kirkwood: Convert to pinctrl
From: Thomas Petazzoni @ 2012-10-26 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210262006.15968.michael@walle.cc>
Dear Michael Walle,
On Fri, 26 Oct 2012 20:06:15 +0200, Michael Walle wrote:
> Am Donnerstag 25 Oktober 2012, 09:43:43 schrieb Thomas Petazzoni:
> > Regardless of those GPIOs, did you solve the hang that happened even
> > when you removed the gpio_set_value() calls? Or is it still a
> > problem currently?
>
> quick update, i found out, that my board loops in the mvebu interrupt
> handler mvebu_gpio_irq_handler(). maybe this is also the lockup Jamie
> Lentin sees.
>
> are interrupts always enabled, now? is there a way to control them?
> maybe there is something missing in the dts, now.
Ah, this is interesting. It is not entirely surprising, since the gpio
driver is new. Even though it re-uses most of the previous gpio driver,
it is by far not impossible that there will be a few regressions.
Could you add a few debug prints to see if you're looping *inside* the
function (which I find pretty unlikely), or if the function gets called
over and over again? Could it be that the hang occurs during the
initialization of the gpio-leds or gpio-keys drivers?
Also, even though I'm pretty sure it isn't going to fix your problem,
note the following mvebu-gpio fix:
http://article.gmane.org/gmane.linux.ports.arm.kernel/195018
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH V2] gpiolib: provide provision for gpiolib to register pin range
From: Viresh Kumar @ 2012-10-26 18:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Shiraz Hashim <shiraz.hashim@st.com>
pinctrl subsystem needs gpio chip base to prepare set of gpio pin ranges, which
a given pinctrl driver can handle. This is important to handle pinctrl gpio
request calls in order to program a given pin properly for gpio operation.
As gpio base is allocated dynamically during gpiochip registration, presently
there exists no clean way to pass this information to the pinctrl subsystem.
After few discussions from [1], it was concluded that may be gpio controller
reporting the pin range it supports, is a better way than pinctrl subsystem
directly registering it.
[1] http://comments.gmane.org/gmane.linux.ports.arm.kernel/184816
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Shiraz Hashim <shiraz.hashim@st.com>
---
Hi Linus,
Its been almost two months when this stuff was last discussed. Here is another
attempt to fix open issues in it.
V1->V2:
------
- Add non-DT routines to register gpio ranges
- Update Documentation/gpio.txt
- of_gpiochip_add_pin_range() rearranged a bit
- use devm_kzalloc() instead of kzalloc()
- few other minor fixes
Bad part is, this code doesn't compile currently :(
It depends on a routine: pinctrl_remove_gpio_range() which was recently removed
by another patch, thinking that there might not be any more users of that
routine. It was removed as the removal of ranges was done in unregister of
pinctrl.
But because we are registering stuff from gpiolib now, we may remove and insert
a gpio module multiple times. So, we need that again. I will add that patch to
this series once you are okay with this one.
I know you might be attending connect now, please review it if you have some
spare time.
Documentation/devicetree/bindings/gpio/gpio.txt | 36 ++++++++++++++++
Documentation/gpio.txt | 26 ++++++++++++
drivers/gpio/gpiolib-of.c | 56 +++++++++++++++++++++++++
drivers/gpio/gpiolib.c | 43 +++++++++++++++++++
drivers/pinctrl/core.c | 13 ++++++
drivers/pinctrl/devicetree.c | 13 ++++++
include/asm-generic/gpio.h | 23 ++++++++++
include/linux/gpio.h | 3 ++
include/linux/pinctrl/pinctrl.h | 16 +++++++
9 files changed, 229 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 4e16ba4..a336287 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -75,4 +75,40 @@ Example of two SOC GPIO banks defined as gpio-controller nodes:
gpio-controller;
};
+2.1) gpio-controller and pinctrl subsystem
+------------------------------------------
+gpio-controller on a SOC might be tightly coupled with the pinctrl
+subsystem, in the sense that the pins can be used by other functions
+together with optional gpio feature.
+
+While the pin allocation is totally managed by the pin ctrl subsystem,
+gpio (under gpiolib) is still maintained by gpio drivers. It may happen
+that different pin ranges in a SoC is managed by different gpio drivers.
+
+This makes it logical to let gpio drivers announce their pin ranges to
+the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
+request the corresponding pin before any gpio usage.
+
+For this, the gpio controller can use a pinctrl phandle and pins to
+announce the pinrange to the pin ctrl subsystem. For example,
+
+ qe_pio_e: gpio-controller at 1460 {
+ #gpio-cells = <2>;
+ compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+ reg = <0x1460 0x18>;
+ gpio-controller;
+ gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
+
+ }
+
+where,
+ &pinctrl1 and &pinctrl2 is the phandle to the pinctrl DT node.
+
+ Next values specify the base pin and number of pins for the range
+ handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
+ pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
+ by this gpio controller.
+
+The pinctrl node must have "#gpio-range-cells" property to show number of
+arguments to pass with phandle from gpio controllers node.
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt
index e08a883..77f233c 100644
--- a/Documentation/gpio.txt
+++ b/Documentation/gpio.txt
@@ -439,6 +439,32 @@ slower clock delays the rising edge of SCK, and the I2C master adjusts its
signaling rate accordingly.
+gpio-controller and pinctrl subsystem
+------------------------------------------
+
+gpio-controller on a SOC might be tightly coupled with the pinctrl
+subsystem, in the sense that the pins can be used by other functions
+together with optional gpio feature.
+
+While the pin allocation is totally managed by the pin ctrl subsystem,
+gpio (under gpiolib) is still maintained by gpio drivers. It may happen
+that different pin ranges in a SoC is managed by different gpio drivers.
+
+This makes it logical to let gpio drivers announce their pin ranges to
+the pin ctrl subsystem and call 'pinctrl_request_gpio' in order to
+request the corresponding pin before any gpio usage.
+
+For this, the gpio controller can register its pin range with pinctrl subsystem.
+There are two ways of doing it currently with or without DT.
+
+For with DT support refer to Documentation/devicetree/bindings/gpio/gpio.txt.
+
+For non-DT support, user can call gpiochip_add_pin_range() with appropriate
+parameters to register a range of gpio pins with a pinctrl driver. For this
+exact name string of pinctrl device has to be passed as one of the argument to
+this routine.
+
+
What do these conventions omit?
===============================
One of the biggest things these conventions omit is pin multiplexing, since
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c
index f1a4599..a5b90c8 100644
--- a/drivers/gpio/gpiolib-of.c
+++ b/drivers/gpio/gpiolib-of.c
@@ -19,6 +19,7 @@
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_gpio.h>
+#include <linux/pinctrl/pinctrl.h>
#include <linux/slab.h>
/* Private data structure for of_gpiochip_find_and_xlate */
@@ -216,6 +217,58 @@ err0:
}
EXPORT_SYMBOL(of_mm_gpiochip_add);
+#ifdef CONFIG_PINCTRL
+void of_gpiochip_add_pin_range(struct gpio_chip *chip)
+{
+ struct device_node *np = chip->of_node;
+ struct gpio_pin_range *pin_range;
+ struct of_phandle_args pinspec;
+ int index = 0, ret;
+
+ if (!np)
+ return;
+
+ do {
+ ret = of_parse_phandle_with_args(np, "gpio-ranges",
+ "#gpio-range-cells", index, &pinspec);
+ if (ret)
+ break;
+
+ pin_range = devm_kzalloc(chip->dev, sizeof(*pin_range),
+ GFP_KERNEL);
+ if (!pin_range) {
+ pr_err("%s: GPIO chip: failed to allocate pin ranges\n",
+ chip->label);
+ break;
+ }
+
+ pin_range->range.name = chip->label;
+ pin_range->range.base = chip->base;
+ pin_range->range.pin_base = pinspec.args[0];
+ pin_range->range.npins = pinspec.args[1];
+ pin_range->pctldev = of_pinctrl_add_gpio_range(pinspec.np,
+ &pin_range->range);
+
+ list_add_tail(&pin_range->node, &chip->pin_ranges);
+
+ } while (index++);
+}
+
+void of_gpiochip_remove_pin_range(struct gpio_chip *chip)
+{
+ struct gpio_pin_range *pin_range, *tmp;
+
+ list_for_each_entry_safe(pin_range, tmp, &chip->pin_ranges, node) {
+ list_del(&pin_range->node);
+ pinctrl_remove_gpio_range(pin_range->pctldev,
+ &pin_range->range);
+ }
+}
+#else
+void of_gpiochip_add_pin_range(struct gpio_chip *chip) {}
+void of_gpiochip_remove_pin_range(struct gpio_chip *chip) {}
+#endif
+
void of_gpiochip_add(struct gpio_chip *chip)
{
if ((!chip->of_node) && (chip->dev))
@@ -229,11 +282,14 @@ void of_gpiochip_add(struct gpio_chip *chip)
chip->of_xlate = of_gpio_simple_xlate;
}
+ of_gpiochip_add_pin_range(chip);
of_node_get(chip->of_node);
}
void of_gpiochip_remove(struct gpio_chip *chip)
{
+ of_gpiochip_remove_pin_range(chip);
+
if (chip->of_node)
of_node_put(chip->of_node);
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d5f9742..6456bc0 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1088,6 +1088,10 @@ int gpiochip_add(struct gpio_chip *chip)
}
}
+#ifdef CONFIG_PINCTRL
+ INIT_LIST_HEAD(&chip->pin_ranges);
+#endif
+
of_gpiochip_add(chip);
unlock:
@@ -1185,6 +1189,45 @@ struct gpio_chip *gpiochip_find(void *data,
}
EXPORT_SYMBOL_GPL(gpiochip_find);
+#ifdef CONFIG_PINCTRL
+void gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int pin_base, unsigned int npins)
+{
+ struct gpio_pin_range *pin_range;
+
+ pin_range = devm_kzalloc(chip->dev, sizeof(*pin_range), GFP_KERNEL);
+ if (!pin_range) {
+ pr_err("%s: GPIO chip: failed to allocate pin ranges\n",
+ chip->label);
+ return;
+ }
+
+ pin_range->range.name = chip->label;
+ pin_range->range.base = chip->base;
+ pin_range->range.pin_base = pin_base;
+ pin_range->range.npins = npins;
+ pin_range->pctldev = find_pinctrl_and_add_gpio_range(pinctl_name,
+ &pin_range->range);
+
+ list_add_tail(&pin_range->node, &chip->pin_ranges);
+}
+
+void gpiochip_remove_pin_ranges(struct gpio_chip *chip)
+{
+ struct gpio_pin_range *pin_range, *tmp;
+
+ list_for_each_entry_safe(pin_range, tmp, &chip->pin_ranges, node) {
+ list_del(&pin_range->node);
+ pinctrl_remove_gpio_range(pin_range->pctldev,
+ &pin_range->range);
+ }
+}
+#else
+void gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int pin_base, unsigned int npins) {}
+void gpiochip_remove_pin_ranges(struct gpio_chip *chip) {}
+#endif
+
/* These "optional" allocation calls help prevent drivers from stomping
* on each other, and help provide better diagnostics in debugfs.
* They're called even less than the "set direction" calls.
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index cec6072..620259e 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/core.c
@@ -345,6 +345,19 @@ void pinctrl_add_gpio_ranges(struct pinctrl_dev *pctldev,
}
EXPORT_SYMBOL_GPL(pinctrl_add_gpio_ranges);
+struct pinctrl_dev *find_pinctrl_and_add_gpio_range(const char *devname,
+ struct pinctrl_gpio_range *range)
+{
+ struct pinctrl_dev *pctldev = get_pinctrl_dev_from_devname(devname);
+
+ if (!pctldev)
+ return NULL;
+
+ pinctrl_add_gpio_range(pctldev, range);
+ return pctldev;
+}
+EXPORT_SYMBOL_GPL(find_pinctrl_and_add_gpio_range);
+
/**
* pinctrl_get_group_selector() - returns the group selector for a group
* @pctldev: the pin controller handling the group
diff --git a/drivers/pinctrl/devicetree.c b/drivers/pinctrl/devicetree.c
index fcb1de4..6728ec7 100644
--- a/drivers/pinctrl/devicetree.c
+++ b/drivers/pinctrl/devicetree.c
@@ -106,6 +106,19 @@ static struct pinctrl_dev *find_pinctrl_by_of_node(struct device_node *np)
return NULL;
}
+struct pinctrl_dev *of_pinctrl_add_gpio_range(struct device_node *np,
+ struct pinctrl_gpio_range *range)
+{
+ struct pinctrl_dev *pctldev;
+
+ pctldev = find_pinctrl_by_of_node(np);
+ if (!pctldev)
+ return NULL;
+
+ pinctrl_add_gpio_range(pctldev, range);
+ return pctldev;
+}
+
static int dt_to_map_one_config(struct pinctrl *p, const char *statename,
struct device_node *np_config)
{
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index a9432fc..77eb1c1 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -5,6 +5,7 @@
#include <linux/types.h>
#include <linux/errno.h>
#include <linux/of.h>
+#include <linux/pinctrl/pinctrl.h>
#ifdef CONFIG_GPIOLIB
@@ -48,6 +49,19 @@ struct module;
struct device_node;
/**
+ * struct gpio_pin_range - pin range controlled by a gpio chip
+ * @head: list for maintaining set of pin ranges, used internally
+ * @pctldev: pinctrl device which handles corresponding pins
+ * @range: actual range of pins controlled by a gpio controller
+ */
+
+struct gpio_pin_range {
+ struct list_head node;
+ struct pinctrl_dev *pctldev;
+ struct pinctrl_gpio_range range;
+};
+
+/**
* struct gpio_chip - abstract a GPIO controller
* @label: for diagnostics
* @dev: optional device providing the GPIOs
@@ -134,6 +148,15 @@ struct gpio_chip {
int (*of_xlate)(struct gpio_chip *gc,
const struct of_phandle_args *gpiospec, u32 *flags);
#endif
+#ifdef CONFIG_PINCTRL
+ /*
+ * If CONFIG_PINCTRL is enabled, then gpio controllers can optionally
+ * describe the actual pin range which they serve in an SoC. This
+ * information would be used by pinctrl subsystem to configure
+ * corresponding pins for gpio usage.
+ */
+ struct list_head pin_ranges;
+#endif
};
extern const char *gpiochip_is_requested(struct gpio_chip *chip,
diff --git a/include/linux/gpio.h b/include/linux/gpio.h
index 2e31e8b..a284459 100644
--- a/include/linux/gpio.h
+++ b/include/linux/gpio.h
@@ -231,6 +231,9 @@ static inline int irq_to_gpio(unsigned irq)
return -EINVAL;
}
+void gpiochip_add_pin_range(struct gpio_chip *chip, const char *pinctl_name,
+ unsigned int pin_base, unsigned int npins);
+void gpiochip_remove_pin_ranges(struct gpio_chip *chip);
#endif
#endif /* __LINUX_GPIO_H */
diff --git a/include/linux/pinctrl/pinctrl.h b/include/linux/pinctrl/pinctrl.h
index 7d087f0..273df69 100644
--- a/include/linux/pinctrl/pinctrl.h
+++ b/include/linux/pinctrl/pinctrl.h
@@ -134,6 +134,22 @@ extern void pinctrl_add_gpio_range(struct pinctrl_dev *pctldev,
extern void pinctrl_add_gpio_ranges(struct pinctrl_dev *pctldev,
struct pinctrl_gpio_range *ranges,
unsigned nranges);
+extern struct pinctrl_dev *find_pinctrl_and_add_gpio_range(const char *devname,
+ struct pinctrl_gpio_range *range);
+
+#ifdef CONFIG_OF
+extern struct pinctrl_dev *of_pinctrl_add_gpio_range(struct device_node *np,
+ struct pinctrl_gpio_range *range);
+#else
+static inline
+struct pinctrl_dev *of_pinctrl_add_gpio_range(struct device_node *np,
+ struct pinctrl_gpio_range *range)
+{
+ return NULL;
+}
+
+#endif /* CONFIG_OF */
+
extern const char *pinctrl_dev_get_name(struct pinctrl_dev *pctldev);
extern void *pinctrl_dev_get_drvdata(struct pinctrl_dev *pctldev);
#else
--
1.7.12.rc2.18.g61b472e
^ permalink raw reply related
* [PATCH v2 0/9] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: David Miller @ 2012-10-26 18:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508AAB54.9010506@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Fri, 26 Oct 2012 17:25:08 +0200
> David,
>
> On 09/19/2012 01:55 PM, Nicolas Ferre :
>> This is an enhancement work that began several years ago. I try to catchup with
>> some performance improvement that has been implemented then by Havard.
>> The ring index logic and the TX error path modification are the biggest changes
>> but some cleanup/debugging have been added along the way.
>> The GEM revision will benefit from the Gigabit support.
>>
>> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
>> flavors.
>>
>> v2: - modify the tx error handling: now uses a workqueue
>> - information provided by ethtool -i were not accurate: removed
>
> I am about to re-send this patch series. Should I rebase it on top of
> Joachim's recent modifications? I mean, I plan to rebase them on top of
> net-next, is it the proper thing to do?
You should always base your patch on whatever tree you want your patches
applied to.
If you have a dependency on something not in that tree (for example, you
need something in the 'net' tree) you have to tell me.
^ permalink raw reply
* [PATCH 2/5] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
From: Tony Lindgren @ 2012-10-26 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508AD1E7.3080101@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121026 11:11]:
> On 10/26/2012 07:57 PM, Benoit Cousson wrote:
> > Hi Paul,
> >
> > On 10/26/2012 07:54 PM, Paul Walmsley wrote:
> >> On Fri, 26 Oct 2012, Benoit Cousson wrote:
> >>
> >>> On 10/26/2012 05:16 PM, Roger Quadros wrote:
> >>>
> >>>> I still can't get musb to work on 3.7-rc2. Apparently it is still
> >>>> missing the patches from Benoit's for_3.7/dts_part2.
> >>>>
> >>>> Maybe I just need to wait for it to be merged?
> >>>
> >>> They are now in a for_3.8/dts. Unfortunately, one patch that was adding
> >>> ctrl_module address in the USB data was rejected and thus I'm not sure
> >>> it will work without that.
> >>
> >> For v3.7-rc timeframe, looks like it's waiting on an ack from you:
> >>
> >> http://www.spinics.net/lists/arm-kernel/msg201028.html
> >
> > Oups, I missed that one. But I thought Roger was mentioning the DT patch
> > and not that one.
> >
> > Anyway, I will answer to Tony. Thanks for the reminder Paul.
>
> Well, in fact, I cannot even find the original email in my mailbox :-(
> I was banned again from linux-omap around that time, so that might be
> the reason.
>
> So please take that hacky patch if it prevents the regression.
OK yes it seems like that's the only option we have until
omap4 is device tree only.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: remove duplicated declaration of omap4430_init_late
From: Tony Lindgren @ 2012-10-26 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351272589-9885-1-git-send-email-const@MakeLinux.com>
* Constantine Shulyupin <const@MakeLinux.com> [121026 10:31]:
> From: Constantine Shulyupin <const@MakeLinux.com>
>
> Problem:
> Function omap4430_init_late is declared twice in arch/arm/mach-omap2/common.h.
> Fix: remove out of order declaration, assuming all functions ordered accordingly processor number.
>
>
> Signed-off-by: Constantine Shulyupin <const@MakeLinux.com>
Thanks, applying into omap-for-v3.7-rc2/fixes-part2-take3.
Regards,
Tony
> ---
> arch/arm/mach-omap2/common.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index 7045e4d..45478d1 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -152,7 +152,6 @@ void am33xx_init_early(void);
> void omap4430_init_early(void);
> void omap5_init_early(void);
> void omap3_init_late(void); /* Do not use this one */
> -void omap4430_init_late(void);
> void omap2420_init_late(void);
> void omap2430_init_late(void);
> void omap3430_init_late(void);
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH v3] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Jon Hunter @ 2012-10-26 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <508A273E.3020500@ti.com>
On 10/26/2012 01:01 AM, Santosh Shilimkar wrote:
> Jon,
>
> On Friday 26 October 2012 04:22 AM, Jon Hunter wrote:
>> Hi Kevin,
>>
>> On 10/25/2012 11:34 AM, Kevin Hilman wrote:
>>> From: Kevin Hilman <khilman@ti.com>
>>>
>
> [...]
>
>>> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>>> index 94cbc84..ce1da19 100644
>>> --- a/drivers/gpio/gpio-omap.c
>>> +++ b/drivers/gpio/gpio-omap.c
>>> @@ -539,6 +539,8 @@ static void _reset_gpio(struct gpio_bank *bank,
>>> int gpio)
>>> _set_gpio_irqenable(bank, gpio, 0);
>>> _clear_gpio_irqstatus(bank, gpio);
>>> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
>>> + bank->dbck_enable_mask &= ~(GPIO_BIT(bank, gpio));
>>> + _gpio_dbck_disable(bank);
>>
>> We can't use _gpio_dbck_disable() here. This has been specifically
>> implemented
>> for the suspend path and is designed to disable the debounce clock while
>> debounce is enabled (which makes sense). Yes this needs to be cleaned up.
>>
> I thought this bit was clear on v2 discussion list that debounce
> clock disable needs to be conditional based on debounce mask.
Yes that part was crystal clear ;-)
However, what I had overlooked was how _gpio_dbck_disable() was
implemented and is intended to work. Hence, I do not call this new in
the _gpio_clear_debounce() function.
>> From 33812f3bd4f7aab1154e7194b7f11fba700a5086 Mon Sep 17 00:00:00 2001
>> From: Jon Hunter <jon-hunter@ti.com>
>> Date: Thu, 25 Oct 2012 16:00:51 -0500
>> Subject: [PATCH] gpio/omap: fix clearing of debounce settings on gpio
>> free/reset
>>
>> When a GPIO is freed or shutdown, we need to ensure that any debounce
>> settings
>> are cleared and if the GPIO is the only GPIO in the bank that is
>> currently
>> using debounce, then disable the debounce clock as well to save power.
>>
>> Therefore, introduce a new function called _clear_gpio_debounce() to
>> clear
>> any debounce settings when the GPIO is freed or shutdown.
>>
>> Please note that we cannot use _gpio_dbck_disable() to disable the
>> debounce
>> clock because this has been specifically created for the gpio suspend
>> path
>> and is intended to shutdown the debounce clock while debounce is enabled.
>>
>> This has been unit tested on an OMAP3430 Beagle board, by requesting a
>> gpio,
>> enabling debounce and then freeing the gpio and checking the register
>> contents,
>> the saved register context and the debounce clock state.
>>
>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>> ---
> Now that we are aligned, so we can take this patch forward. Feel free
> to add my ack in case you plan to refresh it.
>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Thanks!
Jon
^ permalink raw reply
* [PATCH] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Jon Hunter @ 2012-10-26 19:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset". The title has been updated slightly to
reflect (what should be) the final fix.
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.
Currently, the debounce settings are not cleared on a GPIO free or shutdown and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank->context.debounce*)
leading to mismatch state between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If that GPIO
bank is subsequently used with off-mode enabled, bogus state would be restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.
Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.
Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.
Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
enabling debounce and then freeing the gpio and checking the register
contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
ads7846 touchscreen in its board file using the above sequence, and so was
failing off-mode tests in dynamic idle. Verified that off-mode tests are
passing with this patch.
Reported-by: Paul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
drivers/gpio/gpio-omap.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..d335af1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
}
}
+/**
+ * _clear_gpio_debounce - clear debounce settings for a gpio
+ * @bank: the gpio bank we're acting upon
+ * @gpio: the gpio number on this @gpio
+ *
+ * If a gpio is using debounce, then clear the debounce enable bit and if
+ * this is the only gpio in this bank using debounce, then clear the debounce
+ * time too. The debounce clock will also be disabled when calling this function
+ * if this is the only gpio in the bank using debounce.
+ */
+static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
+{
+ u32 gpio_bit = GPIO_BIT(bank, gpio);
+
+ if (!bank->dbck_flag)
+ return;
+
+ if (!(bank->dbck_enable_mask & gpio_bit))
+ return;
+
+ bank->dbck_enable_mask &= ~gpio_bit;
+ bank->context.debounce_en &= ~gpio_bit;
+ __raw_writel(bank->context.debounce_en,
+ bank->base + bank->regs->debounce_en);
+
+ if (!bank->dbck_enable_mask) {
+ bank->context.debounce = 0;
+ __raw_writel(bank->context.debounce, bank->base +
+ bank->regs->debounce);
+ clk_disable(bank->dbck);
+ bank->dbck_enabled = false;
+ }
+}
+
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
unsigned trigger)
{
@@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
_set_gpio_irqenable(bank, gpio, 0);
_clear_gpio_irqstatus(bank, gpio);
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
+ _clear_gpio_debounce(bank, gpio);
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
--
1.7.9.5
^ permalink raw reply related
* [RESEND][PATCH v4] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Jon Hunter @ 2012-10-26 19:20 UTC (permalink / raw)
To: linux-arm-kernel
From: Kevin Hilman <khilman@ti.com>
This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
clock enable mask on free/reset". The title has been updated slightly to
reflect (what should be) the final fix.
When a GPIO is freed or shutdown, we need to ensure that any debounce settings
are cleared and if the GPIO is the only GPIO in the bank that is currently
using debounce, then disable the debounce clock as well to save power.
Currently, the debounce settings are not cleared on a GPIO free or shutdown and
so during a context restore on subsequent off-mode transition, the previous
debounce values are restored from the shadow copies (bank->context.debounce*)
leading to mismatch state between driver state and hardware state.
This was discovered when board code was doing
gpio_request_one()
gpio_set_debounce()
gpio_free()
which was leaving the GPIO debounce settings in a confused state. If that GPIO
bank is subsequently used with off-mode enabled, bogus state would be restored,
leaving GPIO debounce enabled which then prevented the CORE powerdomain from
transitioning.
To fix this, introduce a new function called _clear_gpio_debounce() to clear
any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
last debounce-enabled GPIO in the bank, the debounce will also be cut.
Please note that we cannot use _gpio_dbck_disable() to disable the debounce
clock because this has been specifically created for the gpio suspend path
and is intended to shutdown the debounce clock while debounce is enabled.
Special thanks to Kevin Hilman for root causing the bug. This fix is a
collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
Santosh Shilimkar.
Testing:
- This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
enabling debounce and then freeing the gpio and checking the register
contents, the saved register context and the debounce clock state.
- Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
ads7846 touchscreen in its board file using the above sequence, and so was
failing off-mode tests in dynamic idle. Verified that off-mode tests are
passing with this patch.
Reported-by: Paul Walmsley <paul@pwsan.com>
Cc: Igor Grinberg <grinberg@compulab.co.il>
Cc: Grazvydas Ignotas <notasas@gmail.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
drivers/gpio/gpio-omap.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index 94cbc84..d335af1 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
}
}
+/**
+ * _clear_gpio_debounce - clear debounce settings for a gpio
+ * @bank: the gpio bank we're acting upon
+ * @gpio: the gpio number on this @gpio
+ *
+ * If a gpio is using debounce, then clear the debounce enable bit and if
+ * this is the only gpio in this bank using debounce, then clear the debounce
+ * time too. The debounce clock will also be disabled when calling this function
+ * if this is the only gpio in the bank using debounce.
+ */
+static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
+{
+ u32 gpio_bit = GPIO_BIT(bank, gpio);
+
+ if (!bank->dbck_flag)
+ return;
+
+ if (!(bank->dbck_enable_mask & gpio_bit))
+ return;
+
+ bank->dbck_enable_mask &= ~gpio_bit;
+ bank->context.debounce_en &= ~gpio_bit;
+ __raw_writel(bank->context.debounce_en,
+ bank->base + bank->regs->debounce_en);
+
+ if (!bank->dbck_enable_mask) {
+ bank->context.debounce = 0;
+ __raw_writel(bank->context.debounce, bank->base +
+ bank->regs->debounce);
+ clk_disable(bank->dbck);
+ bank->dbck_enabled = false;
+ }
+}
+
static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
unsigned trigger)
{
@@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
_set_gpio_irqenable(bank, gpio, 0);
_clear_gpio_irqstatus(bank, gpio);
_set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
+ _clear_gpio_debounce(bank, gpio);
}
/* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
--
1.7.9.5
^ permalink raw reply related
* [RESEND][PATCH v4] gpio/omap: fix off-mode bug: clear debounce settings on free/reset
From: Jon Hunter @ 2012-10-26 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351279246-3923-1-git-send-email-jon-hunter@ti.com>
Sorry, ignore these ...
On 10/26/2012 02:20 PM, Jon Hunter wrote:
> From: Kevin Hilman <khilman@ti.com>
... forgot to change the author from Kevin to me. Will re-post.
Jon
> This change was originally titled "gpio/omap: fix off-mode bug: clear debounce
> clock enable mask on free/reset". The title has been updated slightly to
> reflect (what should be) the final fix.
>
> When a GPIO is freed or shutdown, we need to ensure that any debounce settings
> are cleared and if the GPIO is the only GPIO in the bank that is currently
> using debounce, then disable the debounce clock as well to save power.
>
> Currently, the debounce settings are not cleared on a GPIO free or shutdown and
> so during a context restore on subsequent off-mode transition, the previous
> debounce values are restored from the shadow copies (bank->context.debounce*)
> leading to mismatch state between driver state and hardware state.
>
> This was discovered when board code was doing
>
> gpio_request_one()
> gpio_set_debounce()
> gpio_free()
>
> which was leaving the GPIO debounce settings in a confused state. If that GPIO
> bank is subsequently used with off-mode enabled, bogus state would be restored,
> leaving GPIO debounce enabled which then prevented the CORE powerdomain from
> transitioning.
>
> To fix this, introduce a new function called _clear_gpio_debounce() to clear
> any debounce settings when the GPIO is freed or shutdown. If this GPIO is the
> last debounce-enabled GPIO in the bank, the debounce will also be cut.
>
> Please note that we cannot use _gpio_dbck_disable() to disable the debounce
> clock because this has been specifically created for the gpio suspend path
> and is intended to shutdown the debounce clock while debounce is enabled.
>
> Special thanks to Kevin Hilman for root causing the bug. This fix is a
> collaborative effort with inputs from Kevin Hilman, Grazvydas Ignotas and
> Santosh Shilimkar.
>
> Testing:
> - This has been unit tested on an OMAP3430 Beagle board, by requesting a gpio,
> enabling debounce and then freeing the gpio and checking the register
> contents, the saved register context and the debounce clock state.
> - Kevin Hilman tested on 37xx/EVM board which configures GPIO debounce for the
> ads7846 touchscreen in its board file using the above sequence, and so was
> failing off-mode tests in dynamic idle. Verified that off-mode tests are
> passing with this patch.
>
> Reported-by: Paul Walmsley <paul@pwsan.com>
> Cc: Igor Grinberg <grinberg@compulab.co.il>
> Cc: Grazvydas Ignotas <notasas@gmail.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> Reviewed-by: Kevin Hilman <khilman@ti.com>
> Tested-by: Kevin Hilman <khilman@ti.com>
> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> drivers/gpio/gpio-omap.c | 35 +++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index 94cbc84..d335af1 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -251,6 +251,40 @@ static void _set_gpio_debounce(struct gpio_bank *bank, unsigned gpio,
> }
> }
>
> +/**
> + * _clear_gpio_debounce - clear debounce settings for a gpio
> + * @bank: the gpio bank we're acting upon
> + * @gpio: the gpio number on this @gpio
> + *
> + * If a gpio is using debounce, then clear the debounce enable bit and if
> + * this is the only gpio in this bank using debounce, then clear the debounce
> + * time too. The debounce clock will also be disabled when calling this function
> + * if this is the only gpio in the bank using debounce.
> + */
> +static void _clear_gpio_debounce(struct gpio_bank *bank, unsigned gpio)
> +{
> + u32 gpio_bit = GPIO_BIT(bank, gpio);
> +
> + if (!bank->dbck_flag)
> + return;
> +
> + if (!(bank->dbck_enable_mask & gpio_bit))
> + return;
> +
> + bank->dbck_enable_mask &= ~gpio_bit;
> + bank->context.debounce_en &= ~gpio_bit;
> + __raw_writel(bank->context.debounce_en,
> + bank->base + bank->regs->debounce_en);
> +
> + if (!bank->dbck_enable_mask) {
> + bank->context.debounce = 0;
> + __raw_writel(bank->context.debounce, bank->base +
> + bank->regs->debounce);
> + clk_disable(bank->dbck);
> + bank->dbck_enabled = false;
> + }
> +}
> +
> static inline void set_gpio_trigger(struct gpio_bank *bank, int gpio,
> unsigned trigger)
> {
> @@ -539,6 +573,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio)
> _set_gpio_irqenable(bank, gpio, 0);
> _clear_gpio_irqstatus(bank, gpio);
> _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE);
> + _clear_gpio_debounce(bank, gpio);
> }
>
> /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */
>
^ 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