Re: [PATCH v5 00/11] ARM: OMAP2+: AM43x PRCM basic support
On Tuesday 01 October 2013 12:34 PM, Afzal Mohammed wrote: > Hi Paul, Benoit, Tony, > > This series adds PRCM support (except clock tree) for AM43x SoC's. > Please consider this for inclusion in the coming merge window. > > Patch 02/11 "ARM: OMAP2+: hwmod: AM335x/AM43x: move common data" may > not reach mailing lists due to bigger size, this series is also present > @git://gitorious.org/x0148406-public/linux-kernel.git tags/am43x-prcm-v5 > > Compared to v4, only change is in fixing the powerdomain data. > > Major changes compared to rfc v3: > 1. All register offsets properly taken care for AM43x (with rfc v3, a >couple of issues was detected while testing on pre-silicon) > 2. There were two patches for common hwmod data movement (one for >interconnect and other for ip block data), both were combined to have >a cleaner series that is bisectable. > 3. Cleaner seperation of common data > > Major changes compared to v2 (v3 was only an rfc for current approach): > 1. omap_hwmod_33xx_43xx_interconnect_data.c has the common interconnect >ocp's structs shared between AM335x and AM43x > 2. omap_hwmod_33xx_43xx_ipblock_data.c has the common hwmod structs >shared between AM335x and AM43x This split and reuse looks much better and readable now. For the complete series, Acked-by: Rajendra Nayak > 3. Instances where clock domain or clock topology has changed in the few >cases, have separate structures for AM335x and AM43x > 4. To handle scenarios where register offsets are different, they are >dynamically init-ed in omap_hwmod_33xx_43xx_ipblock_data.c > 5. Register offsets for hwmod's that are present either in AM335x or >AM43x are updated statically in omap_hwmod_33xx_data.c or >omap_hwmod_43xx_data.c as that was cleaner. > 6. Remove the change that re-introduces SW_SLEEP for OMAP4, this will >be taken care separately. > > This series has been boot tested on pre-silicon platform with the help > of Tero's DT clock tree conversion series. This series has been tested > on AM335x-EVM too. > > Additional details: > AM43x reuses most of the IP's from AM335x, as that is the case, much of > the AM335x hwmod data is reused. As AM43x PRCM register layout differs > from AM335x and is similar to OMAP4, power domain, clock domain & hwmod > operations are reused from OMAP4. Currently there is no public TRM > available for AM43x. > > Changes based on: v3.12-rc2 > > Regards > Afzal > > > Afzal Mohammed (7): > ARM: OMAP2+: hwmod: AM335x/AM43x: move common data > ARM: OMAP2+: hwmod: AM335x: runtime register update > ARM: OMAP2+: hwmod: AM335x: remove static register offs > ARM: OMAP2+: PRCM: AM43x definitions > ARM: OMAP2+: hwmod: AM43x support > ARM: OMAP2+: hwmod: AM43x operations > ARM: OMAP2+: AM43x: PRCM kbuild > > Ambresh K (3): > ARM: OMAP2+: PM: AM43x powerdomain data > ARM: OMAP2+: CM: AM43x clockdomain data > ARM: OMAP2+: AM43x PRCM init > > Ankur Kishore (1): > ARM: OMAP2+: CM: cm_inst offset s16->u16 > > arch/arm/mach-omap2/Makefile |9 +- > arch/arm/mach-omap2/clockdomain.h |4 +- > arch/arm/mach-omap2/clockdomains43xx_data.c| 196 ++ > arch/arm/mach-omap2/cm33xx.c | 16 +- > arch/arm/mach-omap2/cm33xx.h | 12 +- > arch/arm/mach-omap2/cminst44xx.c | 29 +- > arch/arm/mach-omap2/cminst44xx.h | 26 +- > arch/arm/mach-omap2/io.c |6 + > arch/arm/mach-omap2/omap_hwmod.c |8 + > arch/arm/mach-omap2/omap_hwmod.h |1 + > .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 163 ++ > .../omap_hwmod_33xx_43xx_interconnect_data.c | 643 +++ > .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1456 +++ > arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 1966 > +--- > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 622 +++ > arch/arm/mach-omap2/powerdomain.h |1 + > arch/arm/mach-omap2/powerdomains43xx_data.c| 136 ++ > arch/arm/mach-omap2/prcm43xx.h | 141 ++ > 18 files changed, 3432 insertions(+), 2003 deletions(-) > create mode 100644 arch/arm/mach-omap2/clockdomains43xx_data.c > create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_common_data.h > create mode 100644 > arch/arm/mach-omap2/omap_hwmod_33xx_43xx_interconnect_data.c > create mode 100644 arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c > create mode 100644 arch/arm/mach-omap2/omap_hwmod_43xx_data.c > create mode 100644 arch/arm/mach-omap2/powerdomains43xx_data.c > create mode 100644 arch/arm/mach-omap2/prcm43xx.h > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/9] ARM: dts: DT data for OMAP platforms for v3.13
On 10/03/2013 08:25 AM, Benoit Cousson wrote: > + DT list and DT maintainers. > > Hi Joel, > > Thanks for the update. It looks good to me. > > For the new bindings added below; > >> .../devicetree/bindings/crypto/omap-aes.txt| 34 ++ >> .../devicetree/bindings/crypto/omap-sham.txt | 31 + > > I will need the acked-by from one of the DT maintainers. Sure. To help with giving Ack for this, I'd like to also mention these patches were due for long time and reposted. The supporting code is already in the kernel. Also bindings were reviewed by Mark Rutland comments in the following thread were addressed: http://www.spinics.net/lists/arm-kernel/msg269006.html Mark, could you give Ack for these patches if they look OK? thanks, -Joel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mfd: twl6030: Fix endianness problem in IRQ handler
From: Danke Xie
The current TWL 6030 IRQ handler assumes little endianness.
This change makes it endian-neutral.
Signed-off-by: Danke Xie
Signed-off-by: Taras Kondratiuk
---
v2: fixed sparse warning
v1: https://patchwork.kernel.org/patch/2974331/
drivers/mfd/twl6030-irq.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 517eda8..18a607e 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -176,8 +176,9 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
int i, ret;
union {
u8 bytes[4];
- u32 int_sts;
+ __le32 int_sts;
} sts;
+ u32 int_sts; /* sts.int_sts converted to CPU endianness */
struct twl6030_irq *pdata = data;
/* read INT_STS_A, B and C in one shot using a burst read */
@@ -196,8 +197,9 @@ static irqreturn_t twl6030_irq_thread(int irq, void *data)
if (sts.bytes[2] & 0x10)
sts.bytes[2] |= 0x08;
- for (i = 0; sts.int_sts; sts.int_sts >>= 1, i++)
- if (sts.int_sts & 0x1) {
+ int_sts = le32_to_cpu(sts.int_sts);
+ for (i = 0; int_sts; int_sts >>= 1, i++)
+ if (int_sts & 0x1) {
int module_irq =
irq_find_mapping(pdata->irq_domain,
pdata->irq_mapping_tbl[i]);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ARM: Flush L2 cache on soft_restart
On 2 October 2013 20:31, Will Deacon wrote:
> On Wed, Oct 02, 2013 at 06:19:30PM +0100, Taras Kondratiuk wrote:
>> On 2 October 2013 15:49, Will Deacon wrote:
>> > On Wed, Oct 02, 2013 at 12:34:16PM +0100, Taras Kondratiuk wrote:
>> >> diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
>> >> index 94f6b05..e359b62 100644
>> >> --- a/arch/arm/kernel/process.c
>> >> +++ b/arch/arm/kernel/process.c
>> >> @@ -103,9 +103,11 @@ void soft_restart(unsigned long addr)
>> >> local_irq_disable();
>> >> local_fiq_disable();
>> >>
>> >> - /* Disable the L2 if we're the last man standing. */
>> >> - if (num_online_cpus() == 1)
>> >> + /* Flush and disable the L2 if we're the last man standing. */
>> >> + if (num_online_cpus() == 1) {
>> >> + outer_flush_all();
>> >> outer_disable();
>> >
>> > l2x0_disable already contains a flush, so this doesn't change anything.
>>
>> Unfortunately not everybody uses l2x0_disable().
>> SoC's that use SMC calls for L2 cache maintenance have its own implementation
>> of outer_cache.disable which usually doesn't flush cache implicitly.
>
> In which case, we should probably fix the disabling code to make a flush
> then update callers not to bother with redundant flushing. The flushing
> during the disable code is likely required anyway if there's any
> synchronisation going on.
It makes sense, but a history of the current code looks a bit confusing.
Implicit flush was added in l2x0_disable() as a "side effect" of
commit 38a8914f9ac2379293944f613e6ca24b61373de8
"ARM: 6987/1: l2x0: fix disabling function to avoid deadlock",
while initially disable was just a disable.
Maybe it worth to explicitly document that .disable callback must flush cache?
--
Regards,
Taras Kondratiuk
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Nishanth Menon writes: > fixing Benoit's mail ID. > On 10/03/2013 11:43 AM, Kevin Hilman wrote: >> Hi Nishanth, >> >> Nishanth Menon writes: >> >>> The following version 5 of the series arose from trying to use >>> BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. >>> This series enables the generic cpufreq-cpu0 driver to be used in >>> device tree enabled boot while maintaining support of the legacy >>> omap-cpufreq driver when used in non device tree enabled boot. >> >> What's the status of this series? Is it still waiting on the clock DT >> changes? > > yes - i do have a new series lined up at the moment here[1] - trying > to ensure everything is dandy before public post. ofcourse, we'd like > to ensure we have feedback on tero's series[2]. I am now working on > ensuring ABB regulator[3](again depends on Tero's series) fits on top > of Mike's voltage notifier series[4] > > So, yep, everything is blocked due to lack of feedback on Tero's > series [2]. OK, thanks for the update. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
looking for loan
Do you have a firm or company that need loan to start up a business or need,personal loan, Debt consolidation? For more information,Contact us now for a guarantee loan with low interest rate. We will provide you with loan to meet your needs. For more information contact us with the following information's. Full name: country: Address: Phone Number: Amount needed: Duration of loan: sg.loan...@outlook.com Kind regards -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAPDSS: HDMI: Correctly compare timings
There is currently a copy and paste error where the hdmi vsync timings are not
compared correctly, this patch fixes this.
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 82a9640..e3ea2d5 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -391,7 +391,7 @@ static bool hdmi_timings_compare(struct omap_video_timings
*timing1,
timing2_hsync = timing2->hfp + timing2->hsw + timing2->hbp;
timing1_hsync = timing1->hfp + timing1->hsw + timing1->hbp;
timing2_vsync = timing2->vfp + timing2->vsw + timing2->vbp;
- timing1_vsync = timing2->vfp + timing2->vsw + timing2->vbp;
+ timing1_vsync = timing1->vfp + timing1->vsw + timing1->vbp;
DSSDBG("timing1_hsync = %d timing1_vsync = %d"\
"timing2_hsync = %d timing2_vsync = %d\n",
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap1: fix incorrect placement of __initdata tag
* Bartlomiej Zolnierkiewicz [130930 06:13]: > __initdata tag should be placed between the variable name and equal > sign for the variable to be placed in the intended .init.data section. Thanks applying into omap-for-v3.13/fixes-not-urgent. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
* Suman Anna [131003 11:25]: > Tony, > > On 10/03/2013 01:05 PM, Tony Lindgren wrote: > > * Suman Anna [130903 11:00]: > >> HwSpinlock IP is present only on OMAP4 and other newer SoCs, > >> which are all device-tree boot only. This patch adds the > >> base support for parsing the DT nodes, and removes the code > >> dealing with the traditional platform device instantiation. > > > > Great, this should be safe for Ohad to queue: > > > > Acked-by: Tony Lindgren > > > > There is a v2 of this series [1] that adds additional SoC support as > well. It currently has some comments [2] & [3] from Mark Rutland on the > DT bindings. I am looking into that at the moment and it may change this > patch as well (the DT parse portion of it in > drivers/hwspinlock/omap_hwspinlock). OK, yeah I noticed there's some pending comments. Feel free to keep my ack for the arch/arm/mach-omap2 removal parts, those won't likely change. Regards, Tony > [1] http://marc.info/?l=linux-omap&m=137944644112727&w=2 > [2] http://marc.info/?t=13794463645&r=1&w=2 > [3] http://marc.info/?t=13794463644&r=1&w=2 > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/2] ARM: dts: Add initial support for IGEP AQUILA
* Javier Martinez Canillas [130925 06:18]: > On Tue, Sep 10, 2013 at 4:55 PM, Enric Balletbo i Serra > wrote: > > From: Enric Balletbo i Serra > > > > Hi all, > > > > These two patches introduces initial support for the IGEP AM335x-based > > platforms. The first patch add support for IGEP COM AQUILA products, and the > > second patch add support for the development board. > > > > These patches apply on top of bcousson/for_3.12/dts repository. > > > > Changes since v2: > > * Make it compatible with "isee,am335x-base0033", "isee,am335x-igep0033", > > "ti,am33xx" since these boards are manufactured by ISEE not TI. (Javier) > > Changes since v1: > > * Use &node to reference the nodes already defined in dtsi files. (Javier) > > > > Best regards, > > > > Enric Balletbo i Serra (2): > > ARM: dts: AM33XX: Add support for IGEP COM AQUILA > > ARM: dts: AM33XX: Add support for IGEP AQUILA EXPANSION board. > > > > arch/arm/boot/dts/Makefile | 1 + > > arch/arm/boot/dts/am335x-base0033.dts | 16 ++ > > arch/arm/boot/dts/am335x-igep0033.dtsi | 265 > > + > > 3 files changed, 282 insertions(+) > > create mode 100644 arch/arm/boot/dts/am335x-base0033.dts > > create mode 100644 arch/arm/boot/dts/am335x-igep0033.dtsi > > > > -- > > 1.8.1.2 > > > > Hi Benoit and Tony, > > Any comments on this series? I had already reviewed previous versions > of the DT and it looks good to me now. > > It would be great if this can make it for 3.13. Looks good to me, I would assume Benoit will be looking at this shortly. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
Tony, On 10/03/2013 01:05 PM, Tony Lindgren wrote: > * Suman Anna [130903 11:00]: >> HwSpinlock IP is present only on OMAP4 and other newer SoCs, >> which are all device-tree boot only. This patch adds the >> base support for parsing the DT nodes, and removes the code >> dealing with the traditional platform device instantiation. > > Great, this should be safe for Ohad to queue: > > Acked-by: Tony Lindgren > There is a v2 of this series [1] that adds additional SoC support as well. It currently has some comments [2] & [3] from Mark Rutland on the DT bindings. I am looking into that at the moment and it may change this patch as well (the DT parse portion of it in drivers/hwspinlock/omap_hwspinlock). regards Suman [1] http://marc.info/?l=linux-omap&m=137944644112727&w=2 [2] http://marc.info/?t=13794463645&r=1&w=2 [3] http://marc.info/?t=13794463644&r=1&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: remove deprecated IRQF_DISABLED
* Michael Opdenacker [130907 00:27]: > This patch proposes to remove the IRQF_DISABLED flag from OMAP code > It's a NOOP since 2.6.35, and will be removed one day. Thanks, applying into omap-for-v3.13/fixes-not-urgent. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: omap2: throw the die id into the entropy pool
* Linus Walleij [130910 01:28]: > On Mon, Sep 9, 2013 at 9:14 PM, Paul Walmsley wrote: > > > Heh, that function name "add_device_randomness()" is a bit misleading. > > It's not actually intended to add "randomness": from > > drivers/char/random.c: > > Yeah you're right... > > Tony feel free to edit the commit message when applying. > > > * None of this adds any entropy, it is meant to avoid the > > * problem of the nonblocking pool having similar initial state > > * across largely identical devices. > > It's noble enough, just a few years back I ran into the problem where > all boards in a test farm came up with the same ethernet MAC > address due to the initialization of the nonblocking pool being > constant. Thanks, I'll apply this into omap-for-v3.13/fixes-not-urgent with updated comments. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] hwspinlock/omap: add support for dt nodes
* Suman Anna [130903 11:00]: > HwSpinlock IP is present only on OMAP4 and other newer SoCs, > which are all device-tree boot only. This patch adds the > base support for parsing the DT nodes, and removes the code > dealing with the traditional platform device instantiation. Great, this should be safe for Ohad to queue: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: TI816X: add clock domain support for TI816x
* Aida Mynzhasova [130918 09:50]: > > So, is there is somebody who wants to review my changes? :) Maybe resend with Tero and Paul in Cc so they can coordinate how it should be handled? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT
* Aaro Koskinen [131001 14:41]: > Hi, > > Any comments about the below patch? If my analysis is correct, this issue > needs to be fixed before any boards that set ONENAND_SYNC_READWRITE can > be converted to DT. So the fix should be applied preferably during the > current rc-cycle. Thanks I'll apply it into omap-for-v3.12/fixes. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Tony Lindgren [131002 22:51]:
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> +/**
> + * pcs_irq_set() - enables or disables an interrupt
> + *
> + * Note that this currently assumes one interrupt per pinctrl
> + * register that is typically used for wake-up events.
> + */
> +static inline void pcs_irq_set(struct pcs_soc_data *pcs_soc,
> +int irq, const bool enable)
> +{
> + struct pcs_device *pcs;
> + struct list_head *pos;
> + unsigned mask;
> +
> + pcs = container_of(pcs_soc, struct pcs_device, socdata);
> + list_for_each(pos, &pcs->irqs) {
> + struct pcs_interrupt *pcswi;
> + unsigned soc_mask;
> +
> + pcswi = list_entry(pos, struct pcs_interrupt, node);
> + if (irq != pcswi->hwirq)
> + continue;
Oops, this should be pcswi->irq instead, otherwise this will
never match. And it just happened to work for me as I had
the wake-up flags set from the bootloader..
> + soc_mask = pcs_soc->irq_enable_mask;
> + raw_spin_lock(&pcs->lock);
> + mask = pcs->read(pcswi->reg);
> + if (enable)
> + mask &= ~soc_mask;
> + else
> + mask |= soc_mask;
> + pcs->write(mask, pcswi->reg);
> + raw_spin_unlock(&pcs->lock);
> + }
> +}
And then the if (enable) mask needs to be swapped around for
this to work when the wake up events are not set by the
bootloader :)
> +static void pcs_irq_chain_handler(unsigned int irq, struct irq_desc *desc)
> +{
> + struct pcs_soc_data *pcs_soc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip;
> + int res;
> +
> + chip = irq_get_chip(irq);
> + chained_irq_enter(chip, desc);
> + res = pcs_irq_handle(pcs_soc);
> + if (!res)
> + handle_bad_irq(irq, desc);
> + chained_irq_exit(chip, desc);
> +
> + return;
> +}
Looks like handle_bad_irq is not exported for modules, so I've
just made it into a comment for now.
> + /* FIXME: Test rmmod */
And this can be removed now, I've briefly tested it as a
loadable module by not claiming any pins.
Updated patch below,
Tony
8<-
From: Tony Lindgren
Date: Wed, 2 Oct 2013 21:39:40 -0700
Subject: [PATCH] pinctrl: single: Add support for wake-up interrupts
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The pin control registers can have interrupts for example
for device wake-up. These interrupts can be treated as a
chained interrupt controller as suggested earlier by
Linus Walleij .
This patch adds support for interrupts in a way that
should be pretty generic, and works for the omaps that
support wake-up interrupts. On omaps, there's an
interrupt enable and interrupt status bit for each pin.
The two pinctrl domains on omaps share a single interrupt
from the PRM chained interrupt handler. Support for
other similar hardware should be easy to add.
Note that this patch does not attempt to handle the
wake-up interrupts automatically unlike the earlier
patches. This patch allows the device drivers to do
a request_irq() on the wake-up pins as needed. I'll
try to do also a separate generic patch for handling
the wake-up events automatically.
Also note that as this patch makes the pinctrl-single
an irq controller, the current bindings need some
extra trickery to use interrupts from two different
interrupt controllers for the same driver. So it
might be worth waiting a little on the patches
enabling the wake-up interrupts from drivers as there
should be a generic way to handle it coming. And also
there's been discussion of interrupts-extended binding
for using interrupts from multiple interrupt controllers.
In any case, this patch should be ready to go allowing
handling the wake-up interrupts in a generic way, or
separately from the device drivers.
Cc: Peter Ujfalusi
Cc: Grygorii Strashko
Cc: Prakash Manjunathappa
Cc: Roger Quadros
Cc: Haojian Zhuang
Cc: Linus Walleij
Cc: linux-ker...@vger.kernel.org
Cc: Benoît Cousson
Cc: devicet...@vger.kernel.org
Signed-off-by: Tony Lindgren
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..7069a0b 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
/* pin base, nr pins & gpio function */
pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+- interrupt-controller : standard interrupt controller binding if using
+ interrupts for wake-up events for example. In this case pinctrl-single
+ is set up as a chained interrupt controller and the wake-up interrupts
+ can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt
Re: [PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
fixing Benoit's mail ID. On 10/03/2013 11:43 AM, Kevin Hilman wrote: > Hi Nishanth, > > Nishanth Menon writes: > >> The following version 5 of the series arose from trying to use >> BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. >> This series enables the generic cpufreq-cpu0 driver to be used in >> device tree enabled boot while maintaining support of the legacy >> omap-cpufreq driver when used in non device tree enabled boot. > > What's the status of this series? Is it still waiting on the clock DT > changes? yes - i do have a new series lined up at the moment here[1] - trying to ensure everything is dandy before public post. ofcourse, we'd like to ensure we have feedback on tero's series[2]. I am now working on ensuring ABB regulator[3](again depends on Tero's series) fits on top of Mike's voltage notifier series[4] So, yep, everything is blocked due to lack of feedback on Tero's series [2]. [1] https://github.com/nmenon/linux-2.6-playground/commits/devel/cpufreq-cpu0 [2] http://marc.info/?t=13800989941&r=1&w=2 [3] https://github.com/nmenon/linux-2.6-playground/commits/push/abb-regulator-dts [4] http://git.linaro.org/gitweb?p=people/mturquette/linux.git;a=shortlog;h=refs/heads/clk-next-volt -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: hwmod: check for module address space during init
The hwmod init sequence involves initializing and idling all the
hwmods during bootup. If a module class has sysconfig, the init
sequence utilizes the module register base for performing any
sysc configuration.
The module address space is being removed from hwmod database and
retrieved from the property of the corresponding DT node.
If a hwmod does not have its corresponding DT node defined and the
memory address space is not defined in the corresponding
omap_hwmod_ocp_if, then the module register target address space
would be NULL and any sysc programming would result in a NULL
pointer dereference and a kernel boot hang.
Handle this scenario by checking for a valid module address space
during the _init of each hwmod, and leaving it in the registered
state if no module register address base is defined in either of
the hwmod data or the DT data.
Signed-off-by: Suman Anna
---
This patch helps break the dependencies between hwmod entries and
corresponding DT entries (especially on OMAP5, where most of the
address spaces are already cleaned up and the current data files
have minimal entries) and fixes any boot issues due to missing
addresses. See for reference,
http://marc.info/?t=13800542143&r=1&w=2
Tested on BeagleXM, Panda4, BeagleBone Black and Panda5 using
Tero's v7 clk DT patches and Benoit's for-3.13/dts on top of
3.12-rc3
arch/arm/mach-omap2/omap_hwmod.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index d9ee0ff..1d9edb3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2361,21 +2361,23 @@ static struct device_node *of_dev_hwmod_lookup(struct
device_node *np,
* Cache the virtual address used by the MPU to access this IP block's
* registers. This address is needed early so the OCP registers that
* are part of the device's address space can be ioremapped properly.
- * No return value.
+ *
+ * Returns 0 on success, -EINVAL if an invalid hwmod is passed, and
+ * -ENOMEM on absent or invalid register target address space.
*/
-static void __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
+static int __init _init_mpu_rt_base(struct omap_hwmod *oh, void *data)
{
struct omap_hwmod_addr_space *mem;
void __iomem *va_start = NULL;
struct device_node *np;
if (!oh)
- return;
+ return -EINVAL;
_save_mpu_port_index(oh);
if (oh->_int_flags & _HWMOD_NO_MPU_PORT)
- return;
+ return -ENOMEM;
mem = _find_mpu_rt_addr_space(oh);
if (!mem) {
@@ -2384,7 +2386,7 @@ static void __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data)
/* Extract the IO space from device tree blob */
if (!of_have_populated_dt())
- return;
+ return -ENOMEM;
np = of_dev_hwmod_lookup(of_find_node_by_name(NULL, "ocp"), oh);
if (np)
@@ -2395,13 +2397,14 @@ static void __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data)
if (!va_start) {
pr_err("omap_hwmod: %s: Could not ioremap\n", oh->name);
- return;
+ return -ENOMEM;
}
pr_debug("omap_hwmod: %s: MPU register target at va %p\n",
oh->name, va_start);
oh->_mpu_rt_va = va_start;
+ return 0;
}
/**
@@ -2414,8 +2417,8 @@ static void __init _init_mpu_rt_base(struct omap_hwmod
*oh, void *data)
* registered at this point. This is the first of two phases for
* hwmod initialization. Code called here does not touch any hardware
* registers, it simply prepares internal data structures. Returns 0
- * upon success or if the hwmod isn't registered, or -EINVAL upon
- * failure.
+ * upon success or if the hwmod isn't registered or if the hwmod's
+ * address space is not defined, or -EINVAL upon failure.
*/
static int __init _init(struct omap_hwmod *oh, void *data)
{
@@ -2424,8 +2427,14 @@ static int __init _init(struct omap_hwmod *oh, void
*data)
if (oh->_state != _HWMOD_STATE_REGISTERED)
return 0;
- if (oh->class->sysc)
- _init_mpu_rt_base(oh, NULL);
+ if (oh->class->sysc) {
+ r = _init_mpu_rt_base(oh, NULL);
+ if (r < 0) {
+ WARN(1, "omap_hwmod: %s: doesn't have mpu register
target base\n",
+ oh->name);
+ return 0;
+ }
+ }
r = _init_clocks(oh, NULL);
if (r < 0) {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: check for module address space during init
On Thursday 03 October 2013 12:59 PM, Suman Anna wrote: > The hwmod init sequence involves initializing and idling all the > hwmods during bootup. If a module class has sysconfig, the init > sequence utilizes the module register base for performing any > sysc configuration. > > The module address space is being removed from hwmod database and > retrieved from the property of the corresponding DT node. > If a hwmod does not have its corresponding DT node defined and the > memory address space is not defined in the corresponding > omap_hwmod_ocp_if, then the module register target address space > would be NULL and any sysc programming would result in a NULL > pointer dereference and a kernel boot hang. > > Handle this scenario by checking for a valid module address space > during the _init of each hwmod, and leaving it in the registered > state if no module register address base is defined in either of > the hwmod data or the DT data. > > Signed-off-by: Suman Anna > --- > This patch helps break the dependencies between hwmod entries and > corresponding DT entries (especially on OMAP5, where most of the > address spaces are already cleaned up and the current data files > have minimal entries) and fixes any boot issues due to missing > addresses. See for reference, > http://marc.info/?t=13800542143&r=1&w=2 > > Tested on BeagleXM, Panda4, BeagleBone Black and Panda5 using > Tero's v7 clk DT patches and Benoit's for-3.13/dts on top of > 3.12-rc3 > Good to break that dts/hwmod dependency. FWIW, Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 0/6] ARM: OMAP3+: support cpufreq-cpu0 for device tree boot
Hi Nishanth, Nishanth Menon writes: > The following version 5 of the series arose from trying to use > BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. > This series enables the generic cpufreq-cpu0 driver to be used in > device tree enabled boot while maintaining support of the legacy > omap-cpufreq driver when used in non device tree enabled boot. What's the status of this series? Is it still waiting on the clock DT changes? Kevin > However, in order to enable complete SoC entitlement for OMAP > platforms, with this series, key features are still pending on device > tree adaptation for OMAP: > A) clock framework data transition to DT - this series provides an > driver to allow device tree definition of clock node. > B) On processors that use voltage controller, voltage processor > (VC/VP hardware loop using I2C_SR path) - we have started work on > transitioning them to regulator framework driven by DT. > C) Adaptive Body Bias[2] and SmartReflex AVS conversion to DT. > > Note: Common Clock Framework(CCF) could also control regulators[3] and > AVS to ensure proper sequencing required for full DVFS sequencing. > Once these conversions are complete, there might be minimal cleanup > work to switch to the new data structure changes. > > Key benefit of the series is to allow all relevant TI platforms now to > use a single cpufreq driver and equivalent frameworks in addition be > part of the transition to device tree. > > NOTE on this series: > 1. omap-cpufreq will be used only in non device tree boot scenario. we > should delete this driver once the 100% DT conversion is complete. > 2. Generic cpufreq-cpu0 will be used only in device tree boot scenario > boot systems > 3. clock data movement as approached by Tero in [4] is not the > objective of this series > 4. meant for post 3.10-rc1 tag > > Key changes in version 5 since version 4: > - rebase with master for 3.10-rc1 intermediate > - review comments incorporated > > version 4 of the series: > http://marc.info/?l=linux-arm-kernel&m=136580742724210&w=2 > available at: > > https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v4 > > version 3 of the series: > http://marc.info/?l=linux-pm&m=136450759315742&w=2 > available at: > > https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v3 > > version 2 of the series: > http://marc.info/?t=13637157023&r=1&w=2 > available at: > > https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v2 > > version 1 of the series: > http://marc.info/?t=13632948545&r=1&w=2 > available at: > > https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v1 > > [1] Original discussion thread which triggered this series: > http://marc.info/?l=linux-pm&m=136304313700602&w=2 > https://patchwork.kernel.org/patch/2251841/ > https://patchwork.kernel.org/patch/2251851/ > [2] ABB series: http://marc.info/?l=linux-omap&m=136751559523901&w=2 (ABB DTS > merge pending) > [3] CCF DVFS patches: > https://patchwork.kernel.org/patch/2195431/ > https://patchwork.kernel.org/patch/2195421/ > https://patchwork.kernel.org/patch/2195451/ > https://patchwork.kernel.org/patch/2195441/ > https://patchwork.kernel.org/patch/2195461/ > [4] http://marc.info/?t=13638874501&r=1&w=2 > > Version 5 is now based on master since all requisite for-next branches have > been merged. > master 5af43c2 Merge branch 'akpm' (incoming from Andrew) > > Version 4 is also available at: > > https://github.com/nmenon/linux-2.6-playground/commits/push/cpufreq-cpu0-omap-all-v5 > git link: git://github.com/nmenon/linux-2.6-playground.git > branch: cpufreq-cpu0-omap-all-v5 > > Test coverage: > test script: http://pastebin.com/GsavxiDe > (note - to allow testing, I followed the suggestion in > https://lkml.org/lkml/2013/5/8/19 ) > > Platforms verified: > beaglebone(rev A6a) - AM33xx compatible - http://pastebin.com/zANKsYBp > beagleboard (rev C1D) - OMAP3430 compatible > - DT enabled boot: http://pastebin.com/q4qZYVaK > - No DT enabled boot: http://pastebin.com/c1CbQmV5 > omap3-beagle-xm -OMAP3630 compatible - http://pastebin.com/ibUABcA0 > SDP4430 -(OMAP4430 ES2.2) - http://pastebin.com/wYwUc3fU > Pandaboard-ES -(OMAP4460 ES1.1) - http://pastebin.com/FB2RiFp2 > > Nishanth Menon (6): > clk: OMAP: introduce device tree binding to kernel clock data > [Clk driver probably belongs to mike's tree?] > ARM: dts: OMAP3: add clock nodes for CPU > ARM: dts: OMAP4: add clock nodes for CPU > ARM: dts: AM33XX: add clock nodes for CPU > [The above probably belong to Benoit's tree] > ARM: OMAP2+: AM33XX: add lateinit hook for calling pm late init > ARM: OMAP3+: use cpu0-cpufreq driver in device tree supported boot > [The above probably belong to Kev
Re: [PATCH v7 09/10] usb: dwc3: omap: manage "usb_otg_ss_refclk960m" clock
On Thu, Oct 03, 2013 at 05:54:14PM +0300, Roger Quadros wrote: > On 10/03/2013 03:29 PM, Felipe Balbi wrote: > > Hi, > > > > On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote: > >> On 10/02/2013 04:11 PM, Felipe Balbi wrote: > >>> On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote: > Hi Felipe, > > On 09/18/2013 03:49 PM, Roger Quadros wrote: > > "usb_otg_ss_refclk960m" is an optional functional clock to the > > UBS_OTG_SS module. So manage it in the driver. > > > > Just realized that "usb_otg_ss_refclk960m" is in fact functional clock > to the > PHY and not USB_OTG_SS module. The name is misleading. > > So please ignore patch 9 and 10. > >>> > >>> ignored. All others are fine, right ? > >>> > >> Yes. But I might have to rebase this on top of Phy framework stuff. > > > > alright, Greg already took the PHY framework, so maybe we need to just > > give him my Acked-by and he takes the patches directly as I don't have > > PYH framework. > > > OK. I'll resend this series to Greg in a while. It looks like you did, but forgot Felipe's ack :( -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/8][RESEND] phy: omap-usb: Support multiple instances and new types
Hi Greg, I was initially pushing this series through Felipe, but now that PHY framework is in your usb-next tree, Felipe has asked me to send it to you. We need this for 3.13. There are more patches related to USB support for TI's DRA7 SoC and SATA support for OMAP5 that depend on this series. This patchset does the following: * Get rid of omap_control_usb platform data as we support DT only. * Restructure and add support for new PHY types. We now support the following four types TYPE_OTGHS - if it has otghs_control mailbox register (e.g. on OMAP4) TYPE_USB2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY TYPE_PIPE3 - if it has DPLL and individual Rx & Tx power control. e.g. USB3 PHY or SATA PHY TYPE_DRA7USB2 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7 * Get rid of "ti,type" DT property and introduce compatible strings for each type. * Have only one power control API "omap_control_usb_phy_power()" instead of a different one for each PHY type. * Get rid of omap_get_control_dev() so that we can support multiple instances of the control device. We take advantage of the fact that omap control USB device is only present on OMAP4 onwards and hence only supports DT boot. The users of control USB device can get a reference to it from the device node's phandle. Patches are based on greg/usb-next. *NOTE: Patches 7 and 8 need to go through Benoit Cousson's OMAP DTS tree. You can also find the patches in branch usb-control-module in git tree git://github.com/rogerq/linux.git v8: - Rebased on top of greg/usb-next to avoid conflicts - Removed patches 9 and 10 as they are not applicable v7: - Rebased on v3.12-rc1 - Updated DT compatibility ID for better readability - Renamed TYPE_OMAP4 to TYPE_OTGHS, TYPE_USB3 to TYPE_PIPE3 and TYPE_DRA7 to TYPE_DRA7USB2 v6: - addressed review comment about usage of control_usb before allocation. v5: - fixed whitespace alignment issues. v4: - removed "ti,has-mailbox" from omap-usb binding document example. v3: - return -EINVAL instead of -ENODEV on probe failure. - pass device type data through of_device_id table. - get rid of "ti,mailbox" property and "has_mailbox" from musb platform data. v2: - get rid of "ti,type" property and introduce compatible strings for each device type. cheers, -roger Roger Quadros (8): usb: phy: omap-control: Get rid of platform data usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power() usb: phy: omap-usb2: Don't use omap_get_control_dev() usb: phy: omap-usb3: Don't use omap_get_control_dev() usb: musb: omap2430: Don't use omap_get_control_dev() ARM: dts: omap4: update omap-control-usb nodes usb: phy: omap: get rid of omap_get_control_dev() ARM: dts: omap5: update omap-control-usb node Documentation/devicetree/bindings/usb/omap-usb.txt | 34 ++-- arch/arm/boot/dts/omap4.dtsi | 20 ++- arch/arm/boot/dts/omap5.dtsi | 20 ++- drivers/phy/phy-omap-usb2.c| 31 +++- drivers/usb/musb/omap2430.c| 25 ++- drivers/usb/phy/phy-omap-control.c | 208 ++- drivers/usb/phy/phy-omap-usb3.c| 32 +++- include/linux/usb/musb.h |2 - include/linux/usb/omap_control_usb.h | 33 ++-- 9 files changed, 220 insertions(+), 185 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-usb3.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 0824be4..0c6ba29 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
@@ -196,8 +197,14 @@ static int omap_usb3_init(struct usb_phy *x)
static int omap_usb3_probe(struct platform_device *pdev)
{
- struct omap_usb *phy;
- struct resource *res;
+ struct omap_usb *phy;
+ struct resource *res;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -EINVAL;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
- return -ENODEV;
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -EINVAL;
+ }
+
+ phy->control_dev = &control_pdev->dev;
omap_control_usb_phy_power(phy->control_dev, 0);
usb_add_phy_dev(&phy->phy);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/8] usb: phy: omap-usb2: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
---
drivers/phy/phy-omap-usb2.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 4d7b4e5..bfc5c33 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -145,10 +146,16 @@ static struct phy_ops ops = {
static int omap_usb2_probe(struct platform_device *pdev)
{
- struct omap_usb *phy;
- struct phy *generic_phy;
- struct usb_otg *otg;
- struct phy_provider *phy_provider;
+ struct omap_usb *phy;
+ struct phy *generic_phy;
+ struct phy_provider *phy_provider;
+ struct usb_otg *otg;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -EINVAL;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -175,12 +182,20 @@ static int omap_usb2_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
- return -ENODEV;
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -EINVAL;
+ }
+
+ phy->control_dev = &control_pdev->dev;
+
phy->is_suspended = 1;
omap_control_usb_phy_power(phy->control_dev, 0);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/8] usb: phy: omap-control: Get rid of platform data
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 12 +++-
include/linux/usb/omap_control_usb.h |4
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..9772592 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,6 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev->dev.of_node;
- struct omap_control_usb_platform_data *pdata =
- dev_get_platdata(&pdev->dev);
control_usb = devm_kzalloc(&pdev->dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,14 +205,10 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- if (np) {
+ if (np)
of_property_read_u32(np, "ti,type", &control_usb->type);
- } else if (pdata) {
- control_usb->type = pdata->type;
- } else {
- dev_err(&pdev->dev, "no pdata present\n");
- return -EINVAL;
- }
+ else
+ return -EINVAL; /* We only support DT boot */
control_usb->dev= &pdev->dev;
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..e2416b4 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -31,10 +31,6 @@ struct omap_control_usb {
u32 type;
};
-struct omap_control_usb_platform_data {
- u8 type;
-};
-
enum omap_control_usb_mode {
USB_MODE_UNDEFINED = 0,
USB_MODE_HOST,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 8/8] ARM: dts: omap5: update omap-control-usb node
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..c0ec6dc 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,12 +626,16 @@
hw-caps-temp-alert;
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a002370 0x4>;
- reg-names = "control_dev_conf", "phy_power_usb";
- ti,type = <2>;
+ omap_control_usb2phy: control-phy@4a002300 {
+ compatible = "ti,control-phy-usb2";
+ reg = <0x4a002300 0x4>;
+ reg-names = "power";
+ };
+
+ omap_control_usb3phy: control-phy@4a002370 {
+ compatible = "ti,control-phy-pipe3";
+ reg = <0x4a002370 0x4>;
+ reg-names = "power";
};
omap_dwc3@4a02 {
@@ -662,7 +666,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb2phy>;
};
usb3_phy: usb3phy@4a084400 {
@@ -671,7 +675,7 @@
<0x4a084800 0x64>,
<0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb3phy>;
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Add support for new device types and in the process rid of "ti,type"
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types OTGHS, USB2, PIPE3 (e.g. USB3) and DRA7USB2.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 30 ++--
drivers/usb/phy/phy-omap-control.c | 173 +++
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
4 files changed, 130 insertions(+), 103 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 661cb06..9add35c 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -83,22 +83,22 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be "ti,omap-control-usb"
+ - compatible: Should be one of
+ "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
+ "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
+ DRA7 platform.
- reg : Address and length of the register set for the device. It contains
- the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in "reg".
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
- phy power.
+ the address of "otghs_control" for control-phy-otghs or "power" register
+ for other types.
+ - reg-names: should be "otghs_control" control-phy-otghs and "power" for
+ other types.
omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
- reg-names = "control_dev_conf", "otghs_control";
- ti,type = <1>;
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 9772592..1c8a7c5 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,61 +47,70 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
u32 val;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb->type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err("%s: invalid device\n", __func__);
return;
+ }
- rate = clk_get_rate(control_usb->sys_clk);
- rate = rate/100;
-
- val = readl(control_usb->phy_power);
-
- if (on) {
- val &= ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON <<
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
- val |= rate << OMAP_CTRL_USB_PWRCTL_CLK_FREQ_SHIFT;
- } else {
- val &= ~OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK;
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWEROFF <<
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, "%s: invalid control usb device\n", __func__);
+ return
[PATCH v8 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Also get rid of "ti,has-mailbox" property as it is redundant and
we can determine that from whether "ctrl-module" property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ---
drivers/usb/musb/omap2430.c| 25 +++
include/linux/usb/musb.h |2 -
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 9add35c..090e5e2 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
- ti,hwmods : must be "usb_otg_hs"
- - ti,has-mailbox : to specify that omap uses an external mailbox
- (in control module) to communicate with the musb core during device connect
- and disconnect.
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num-eps : Specifies the number of endpoints. This is also a
@@ -31,7 +28,6 @@ SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
ti,hwmods = "usb_otg_hs";
- ti,has-mailbox;
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d0fc4d9..9eab645 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
#include "omap2430.h"
@@ -524,8 +525,12 @@ static int omap2430_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->musb = musb;
glue->status= OMAP_MUSB_UNKNOWN;
+ glue->control_otghs = ERR_PTR(-ENODEV);
if (np) {
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
dev_err(&pdev->dev,
@@ -554,22 +559,20 @@ static int omap2430_probe(struct platform_device *pdev)
of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits);
of_property_read_u32(np, "power", (u32 *)&pdata->power);
config->multipoint = of_property_read_bool(np, "multipoint");
- pdata->has_mailbox = of_property_read_bool(np,
- "ti,has-mailbox");
pdata->board_data = data;
pdata->config = config;
- }
- if (pdata->has_mailbox) {
- glue->control_otghs = omap_get_control_dev();
- if (IS_ERR(glue->control_otghs)) {
- dev_vdbg(&pdev->dev, "Failed to get control device\n");
- ret = PTR_ERR(glue->control_otghs);
- goto err2;
+ control_node = of_parse_phandle(np, "ctrl-module", 0);
+ if (control_node) {
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control
device\n");
+ ret = -EINVAL;
+ goto err2;
+ }
+ glue->control_otghs = &control_pdev->dev;
}
- } else {
- glue->control_otghs = ERR_PTR(-ENODEV);
}
pdata->platform_ops = &omap2430_ops;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..eb50525 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,8 +99,6 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
- u8 has_mailbox:1;
-
/* for clk_get() */
const char *clock;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 6/8] usb: phy: omap: get rid of omap_get_control_dev()
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linux/usb/omap_control_usb.h |5 -
2 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 1c8a7c5..09c5ace 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -26,26 +26,6 @@
#include
#include
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
- if (!control_usb)
- return ERR_PTR(-ENODEV);
-
- return control_usb->dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
/**
* omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
@@ -182,11 +162,19 @@ void omap_control_usb_set_mode(struct device *dev,
{
struct omap_control_usb *ctrl_usb;
- if (IS_ERR(dev) || control_usb->type != OMAP_CTRL_TYPE_OTGHS)
+ if (IS_ERR(dev) || !dev)
return;
ctrl_usb = dev_get_drvdata(dev);
+ if (!ctrl_usb) {
+ dev_err(dev, "Invalid control usb device\n");
+ return;
+ }
+
+ if (ctrl_usb->type != OMAP_CTRL_TYPE_OTGHS)
+ return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -237,6 +225,7 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
const struct of_device_id *of_id;
+ struct omap_control_usb *control_usb;
of_id = of_match_device(of_match_ptr(omap_control_usb_id_table),
&pdev->dev);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 61b889a..596b019 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -65,15 +65,10 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev(void)
-{
- return ERR_PTR(-ENODEV);
-}
static inline void omap_control_usb_phy_power(struct device *dev, int on)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 7/8] ARM: dts: omap4: update omap-control-usb nodes
Split otghs_ctrl and USB2 PHY power-down into separate
omap-control-usb nodes. Get rid of "ti,type" property.
Also get rid of "ti,has-mailbox" property from usb_otg_hs
node and provide the ctrl-module phandle.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 1e8e2fe..ea4054b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb2phy>;
#phy-cells = <0>;
};
};
@@ -644,12 +644,16 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
- reg-names = "control_dev_conf", "otghs_control";
- ti,type = <1>;
+ omap_control_usb2phy: control-phy@4a002300 {
+ compatible = "ti,control-phy-usb2";
+ reg = <0x4a002300 0x4>;
+ reg-names = "power";
+ };
+
+ omap_control_usbotg: control-phy@4a00233c {
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -664,7 +668,7 @@
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
- ti,has-mailbox;
+ ctrl-module = <&omap_control_usbotg>;
};
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 09/10] usb: dwc3: omap: manage "usb_otg_ss_refclk960m" clock
On 10/03/2013 03:29 PM, Felipe Balbi wrote: > Hi, > > On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote: >> On 10/02/2013 04:11 PM, Felipe Balbi wrote: >>> On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote: Hi Felipe, On 09/18/2013 03:49 PM, Roger Quadros wrote: > "usb_otg_ss_refclk960m" is an optional functional clock to the > UBS_OTG_SS module. So manage it in the driver. > Just realized that "usb_otg_ss_refclk960m" is in fact functional clock to the PHY and not USB_OTG_SS module. The name is misleading. So please ignore patch 9 and 10. >>> >>> ignored. All others are fine, right ? >>> >> Yes. But I might have to rebase this on top of Phy framework stuff. > > alright, Greg already took the PHY framework, so maybe we need to just > give him my Acked-by and he takes the patches directly as I don't have > PYH framework. > OK. I'll resend this series to Greg in a while. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM33XX: add ethernet alias's for am33xx
Hi Dan, On 03/10/2013 01:39, Mugunthan V N wrote: On Wednesday 02 October 2013 12:58 PM, Dan Murphy wrote: Set the alias for ethernet0 and ethernet1 so that uBoot can set the MAC address appropriately. Currently uBoot cannot find the alias and there for does not set the MAC address. Signed-off-by: Dan Murphy Tested this with beagle bone black. Tested-by: Mugunthan V N Regards Mugunthan V N Thanks, pulled in my for_3.13/dts branch. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/15] scripts/dtc: fix most memory leaks in dtc
Looping back the mailing-lists.
On Thu, Oct 3, 2013 at 4:23 PM, Fabien Parent wrote:
>
> Hi David,
>
>
> On Wed, Oct 2, 2013 at 2:59 PM, David Gibson
> wrote:
>>
>> On Tue, Sep 24, 2013 at 06:52:07PM +0200, Benoit Cousson wrote:
>> > From: Fabien Parent
>>
>> As noted elsewhere, please write patches against upstream dtc, not the
>> version in the kernel. git://git.kernel.org/pub/scm/utils/dtc/dtc.git
>>
>> > There are a few memory leaks in dtc which until now were not that important
>> > since they were all in the parser and only one instance of the parser was
>> > run
>> > per instance of dtc. The following commits will add a validation of dts
>> > through
>> > schema which have the same syntax as dts, i.e. the parser of dts will be
>> > reused
>> > to parse schema. The consequence is that instead of having the parser
>> > running
>> > only one time for an instance of the dtc process, the parser will run
>> > many many times and thus the leak that were not important until now becomes
>> > urgent to fix.
>>
>> Hrm, yeah. I'm aware that I haven't been very careful with memory
>> leaks within the parser. Essentially, I've been treating the process
>> as a pool allocator with exactly one pool - I've even considered
>> getting rid of those free()s we do have.
>>
>> If the parser's going to be invoked repeatedly, then, yes, that
>> certainly needs fixing. Whether individually fixing each leak or
>> using a explicit pool allocator is a better option is less clear.
>
>
> I've chosen the path of using free()s since it was removing most (all?)
> memory leaks from
> the parser and wasn't adding much more complexity to it. I don't think a pool
> allocator would
> be useful to DTC in its current state, but it's true that with schemas which
> are using
> the DTS syntax it could make a lot of sense to switch to a pool allocator.
>
> I guess I will wait until the discussion about this proposal has progressed
> and see
> whether this patch should be rewritten using a pool allocator or not.
>
>>
>> > dtc-lexer: Do not duplicate the string which contains literals because the
>> > string is directly converted afterward to an integer and is never used
>> > again.
>> > livetree: Add a bunch of free helper functions to clean properly the
>> > dt.
>>
>> This is no good. Making this assumption is a layering violation - if
>> the parser was changed so that this literal wasn't converted until
>> after another token was read, the yytext value copied in here would no
>> longer be valid and would break horribly.
>>
>
> Right, I've been lazy on this one and I took the easy road.
>
>
>>
>> >
>> > Signed-off-by: Fabien Parent
>> > Signed-off-by: Benoit Cousson
>> > ---
>> > scripts/dtc/dtc-lexer.l | 2 +-
>> > scripts/dtc/dtc-lexer.lex.c_shipped | 2 +-
>> > scripts/dtc/dtc.c | 1 +
>> > scripts/dtc/dtc.h | 1 +
>> > scripts/dtc/livetree.c | 108
>> > +---
>> > 5 files changed, 105 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
>> > index 3b41bfc..4f63fbf 100644
>> > --- a/scripts/dtc/dtc-lexer.l
>> > +++ b/scripts/dtc/dtc-lexer.l
>> > @@ -146,7 +146,7 @@ static int pop_input_file(void);
>> > }
>> >
>> > ([0-9]+|0[xX][0-9a-fA-F]+)(U|L|UL|LL|ULL)? {
>> > - yylval.literal = xstrdup(yytext);
>> > + yylval.literal = yytext;
>> > DPRINT("Literal: '%s'\n", yylval.literal);
>> > return DT_LITERAL;
>> > }
>> > diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped
>> > b/scripts/dtc/dtc-lexer.lex.c_shipped
>> > index 2d30f41..5c0d27c 100644
>> > --- a/scripts/dtc/dtc-lexer.lex.c_shipped
>> > +++ b/scripts/dtc/dtc-lexer.lex.c_shipped
>> > @@ -1054,7 +1054,7 @@ case 10:
>> > YY_RULE_SETUP
>> > #line 148 "dtc-lexer.l"
>> > {
>> > - yylval.literal = xstrdup(yytext);
>> > + yylval.literal = yytext;
>> > DPRINT("Literal: '%s'\n", yylval.literal);
>> > return DT_LITERAL;
>> > }
>> > diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
>> > index a375683..215ae92 100644
>> > --- a/scripts/dtc/dtc.c
>> > +++ b/scripts/dtc/dtc.c
>> > @@ -256,5 +256,6 @@ int main(int argc, char *argv[])
>> > die("Unknown output format \"%s\"\n", outform);
>> > }
>> >
>> > + free_dt(bi);
>> > exit(0);
>> > }
>> > diff --git a/scripts/dtc/dtc.h b/scripts/dtc/dtc.h
>> > index 3e42a07..9c45fd2 100644
>> > --- a/scripts/dtc/dtc.h
>> > +++ b/scripts/dtc/dtc.h
>> > @@ -245,6 +245,7 @@ struct boot_info {
>> > struct boot_info *build_boot_info(struct reserve_info *reservelist,
>> > struct node *tree, uint32_t
>> > boot_cpuid_phys);
>> > void sort_tree(struct boot_info *bi);
>> > +void free_dt(struct boot_info *bi);
>> >
>> > /* Checks *
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 15:58, Roger Quadros wrote:
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming consistent
Could you rebase it?
Looks like it was already applied before. Could you please skip that and use
the rest?
I've checked that the remaining patches apply fine on top of your for_3.13/dts
branch.
Indeed, it was already there :-)
Sorry for the noise.
Benoit
cheers,
-roger
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
Hi Benoit,
On 10/03/2013 04:44 PM, Benoit Cousson wrote:
> On 03/10/2013 14:05, Benoit Cousson wrote:
>> Hi Roger,
>>
>> Yes, I will. I've been waiting for these ones for so long :-)
>
> In fact it does not apply correctly on my for_3.13/dts branch :-(
>
> error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
> Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming
> consistent
>
> Could you rebase it?
Looks like it was already applied before. Could you please skip that and use
the rest?
I've checked that the remaining patches apply fine on top of your for_3.13/dts
branch.
cheers,
-roger
>>
>> On 03/10/2013 12:34, Roger Quadros wrote:
>>> Hi Benoit,
>>>
>>> Could you please take the device tree related patches [5 to 10] in
>>> this series?
>>> Thanks.
>>>
>>> cheers,
>>> -roger
>>>
>>> On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Device Tree schemas and validation
Hi David,
On 02/10/2013 16:29, David Gibson wrote:
On Tue, Oct 01, 2013 at 04:22:24PM -0600, Stephen Warren wrote:
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
Sorry, this is probably going to sound a bit negative. Hopefully you
find it constructive though.
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
I'm not convinced that's a good decision.
DT is a language for representing data.
The validation checks described by schemas are rules, or code, and not
static data.
So, while I'm sure it's possible to shoe-horn at least some reasonable
subset of DT validation into DT syntax itself, I feel it's unlikely to
yield something that's scalable enough.
I tend to agree.
For example, it's easy to specify that a property must be 2 cells long.
What if it could be any multiple of two? That's a lot of numbers to
explicitly enumerate as data. Sure, you can then invent syntax to
represent that specific rule (parameterized by 2), but what about the
next similar-but-different rule? The only approach I can think of to
that is to allow the schema to contain arbitrary expressions, which
would likely need to morph into arbitary statements not just
expressions. Once you're there, I think the schema would be better
represented as a programming language rather than as a data structure
that could have code hooked into it.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the "compatible" properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = "ti,omap3430-timer";
...
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = "ti,omap[0-9]+-timer";
What about DT nodes that don't have a compatible value? We certainly
have some of those already like /memory and /chosen. We should be able
to validate their schema too. This probably doesn't invalidate being
able to look things up by compatible value though; it just means we need
some additional mechanisms too.
More to the point, what about the properties of a node whose format is
defined not by this node's binding but by some other nodes binding.
e.g. the exact format of reg and ranges is at least partially
determined by the parent bus's binding, and interrupts is defined
partially by the interrupt parent's binding. gpio properties are
defined by a combination of a global binding and the gpio parent,
IIRC.
Yeah, that's a general concern that Stephen raised several time as well.
We need to figure out some way to handle that.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property "ti,hwmods" of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = "ti,omap[0-9]+-timer";
ti,hwmods {
...
};
compatible and ti,hwmods are both properties in the DT file. However, in
the schema above, one appears as a property, and one as a node. I don't
like that inconsistency. It'd be better if compatible was a node too.
Essentially what's going on here is that to describe the constraint on
a property, a node with corresponding name is defined to encode the
parameters of that constraint. It kind of works, but it's forced. It
also hits problems since nodes and properties are technically in
different namespaces, although they rarely collide in real cases.
OK, so would you suggest keeping mapping between node / attribute in DTS
and in the schema?
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = "abc";
def {
name = "def[0-9]";
Isn't it valid to have a property named "name" within the node itself?
How do you differentiate between specifying the node name and the name
property?
Or to look at it another way, how do you differentiate between nodes
representing encoded constraints for a property, and nodes
representing nodes directly.
What if the node name needs more validation than just a regex. For
example, suppose we want to validate the
unit-name-must-match-reg-address rule. We need to write some complex
expression using data extracted from reg to calculate the unit address.
Equally
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
On 03/10/2013 14:05, Benoit Cousson wrote:
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
In fact it does not apply correctly on my for_3.13/dts branch :-(
error: arch/arm/boot/dts/omap3-beagle.dts: patch does not apply
Patch failed at 0004 ARM: dts: omap3-beagle: Make USB host pin naming
consistent
Could you rebase it?
Thanks,
Benoit
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in
this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
-/* HS USB Port 2 RESET */
-hsusb2_reset: hsusb2_reset_reg {
-compatible = "regulator-fixed";
-regulator-name = "hsusb2_reset";
-regulator-min-microvolt = <330>;
-regulator-max-microvolt = <330>;
-gpio = <&gpio5 19 0>;/* gpio_147 */
-startup-delay-us = <7>;
-enable-active-high;
-};
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
-reset-supply = <&hsusb2_reset>;
+reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DTS: DRA7: Add TPS659038 PMIC nodes
Hi Keerthy,
On 11/09/2013 07:30, Keerthy wrote:
> On Tuesday 10 September 2013 12:51 AM, Nishanth Menon wrote:
>> On 08/26/2013 12:36 AM, Keerthy wrote:
>>> The Patch adds nodes for TPS659038 PMIC for DRA7 boards.
>>>
>>> It is based on top of:
>>> http://comments.gmane.org/gmane.linux.ports.arm.omap/102459.
>>>
>>> Documentation:Documentation/devicetree/bindings/mfd/palmas.txt
>>> Documentation/devicetree/bindings/regulator/palmas-pmic.txt
>>>
>>> Boot Tested on DRA7 d1 Board.
>>>
>>> Signed-off-by: Keerthy
>>> ---
>>> arch/arm/boot/dts/dra7-evm.dts | 118
>>>
>>> 1 file changed, 118 insertions(+)
>>>
>>> Index: linux/arch/arm/boot/dts/dra7-evm.dts
>>> ===
>>> --- linux.orig/arch/arm/boot/dts/dra7-evm.dts2013-08-26
>>> 09:57:52.496173554 +0530
>>> +++ linux/arch/arm/boot/dts/dra7-evm.dts2013-08-26
>>> 10:38:44.995414695 +0530
>>> @@ -93,6 +93,119 @@
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&i2c1_pins>;
>>> clock-frequency = <40>;
>>> +
>>> +tps659038: tps659038@58 {
>>> +compatible = "ti,tps659038";
>>> +reg = <0x58>;
>>> +
>>> +tps659038_pmic {
>>> +compatible = "ti,tps659038-pmic";
>>> +
>>> +regulators {
>>> +smps123_reg: smps123 {
>>> +/* VDD_MPU */
>>> +regulator-name = "smps123";
>>> +regulator-min-microvolt = < 85>;
>>> +regulator-max-microvolt = <125>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +smps45_reg: smps45 {
>>> +/* VDD_DSPEVE */
>>> +regulator-name = "smps45";
>>> +regulator-min-microvolt = < 85>;
>>> +regulator-max-microvolt = <115>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +smps6_reg: smps6 {
>>> +/* VDD_GPU - over VDD_SMPS6 */
>>> +regulator-name = "smps6";
>>> +regulator-min-microvolt = <85>;
>>> +regulator-max-microvolt = <1250>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +smps7_reg: smps7 {
>>> +/* CORE_VDD */
>>> +regulator-name = "smps7";
>>> +regulator-min-microvolt = <85>;
>>> +regulator-max-microvolt = <103>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +smps8_reg: smps8 {
>>> +/* VDD_IVAHD */
>>> +regulator-name = "smps8";
>>> +regulator-min-microvolt = < 85>;
>>> +regulator-max-microvolt = <125>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +smps9_reg: smps9 {
>>> +/* VDDS1V8 */
>>> +regulator-name = "smps9";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-always-on;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo1_reg: ldo1 {
>>> +/* LDO1_OUT --> SDIO */
>>> +regulator-name = "ldo1";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo2_reg: ldo2 {
>>> +/* VDD_RTCIO */
>>> +/* LDO2 -> VDDSHV5, LDO2 also goes to
>>> CAN_PHY_3V3 */
>>> +regulator-name = "ldo2";
>>> +regulator-min-microvolt = <330>;
>>> +regulator-max-microvolt = <330>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo3_reg: ldo3 {
>>> +/* VDDA_1V8_PHY */
>>> +regulator-name = "ldo3";
>>> +regulator-min-microvolt = <180>;
>>> +regulator-max-microvolt = <180>;
>>> +regulator-boot-on;
>>> +};
>>> +
>>> +ldo9_reg: ldo9 {
>>> +/* VDD_RTC */
>>> +regulator-name = "ldo9";
>>> +regulator-min-microvolt = <105>;
>>> +
Re: [PATCH v2 0/9] ARM: dts: DT data for OMAP platforms for v3.13
+ DT list and DT maintainers. Hi Joel, Thanks for the update. It looks good to me. For the new bindings added below; > .../devicetree/bindings/crypto/omap-aes.txt| 34 ++ > .../devicetree/bindings/crypto/omap-sham.txt | 31 + I will need the acked-by from one of the DT maintainers. Regards, Benoit On 30/09/2013 17:12, Joel Fernandes wrote: Following series is a collection of dts patches for the below features: crypto: aes, sha on am335x aes, des on am437x aes, des on omap4 display: beaglebone black HDMI am335x-evm panel Series is based on Benoit Cousson's for_3.13/dts branch (commit sha 45646cd) Available at: g...@github.com:joelagnel/linux-kernel.git (branch for-benoit) v2 changes: - Fixed hex capitalization - Dropped interrupt-parent property and use macros Benoit Parrot (1): ARM: dts: AM33XX: Add LCDC info into am335x-evm Darren Etheridge (1): dts: boneblack: add pinmux and hdmi node to enable display Joel Fernandes (5): omap4: dts: Add node for AES omap4: dts: Add node for DES3DES module am33xx: dts: Fix AES interrupt number ARM: am437x: dts: Add AES node for am437x ARM: am437x: dts: Add DES node for am437x Mark A. Greer (2): ARM: dts: Add SHAM data and documentation for AM33XX ARM: dts: Add AES data and documentation for AM33XX .../devicetree/bindings/crypto/omap-aes.txt| 34 ++ .../devicetree/bindings/crypto/omap-sham.txt | 31 + arch/arm/boot/dts/am335x-bone.dts | 8 +++ arch/arm/boot/dts/am335x-boneblack.dts | 48 + arch/arm/boot/dts/am335x-evm.dts | 79 ++ arch/arm/boot/dts/am335x-evmsk.dts | 8 +++ arch/arm/boot/dts/am33xx.dtsi | 28 arch/arm/boot/dts/am4372.dtsi | 14 arch/arm/boot/dts/omap4.dtsi | 18 + 9 files changed, 268 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/15] Device Tree schemas and validation
Hi Stephen,
On 02/10/2013 00:22, Stephen Warren wrote:
On 09/24/2013 10:52 AM, Benoit Cousson wrote:
Hi All,
Following the discussion that happened during LCE-2013 and the email
thread started by Tomasz few months ago [1], here is a first attempt
to introduce:
- a schema language to define the bindings accurately
- DTS validation during device tree compilation in DTC itself
Sorry, this is probably going to sound a bit negative. Hopefully you
find it constructive though.
Well, I hope so too, let's see at the end of the email :-)
The syntax for a schema is the same as the one for dts. This choice has
been made to simplify its development, to maximize the code reuse and
finally because the format is human-readable.
I'm not convinced that's a good decision.
Me neither :-), but I gave the current rational...
DT is a language for representing data.
The validation checks described by schemas are rules, or code, and not
static data.
I will not be that strict with what DTS is supposed to do. In that
aspect DTS is just a way to represent information in a structured
hierarchical way.
It is for my point of view no different than XML. I know that everybody
hate XML, including me, but that shows at least what is doable with such
language. The fact that we like it or not is a different topic.
So, while I'm sure it's possible to shoe-horn at least some reasonable
subset of DT validation into DT syntax itself, I feel it's unlikely to
yield something that's scalable enough.
I don't think we have any limit with such representation. My concern
will be more the readability.
To be honest, a language choice is by nature completely subjective, and
nobody will have the same taste. So we can spend weeks arguing about
that :-)
For example, it's easy to specify that a property must be 2 cells long.
What if it could be any multiple of two? That's a lot of numbers to
explicitly enumerate as data. Sure, you can then invent syntax to
represent that specific rule (parameterized by 2), but what about the
next similar-but-different rule? The only approach I can think of to
that is to allow the schema to contain arbitrary expressions, which
would likely need to morph into arbitary statements not just
expressions. Once you're there, I think the schema would be better
represented as a programming language rather than as a data structure
that could have code hooked into it.
Sure, but how many complex cases like that do we have? I guess, we can
handle all the use-cases required by Rob with the current syntax.
Let's assume we cover 99% of the use-cases with such language, do we
really want to have a super complex language just for the corner cases?
Potentially, writing a C extension to DTC is still possible for that
specific case.
Not ideal, I do agree, but we have to be pragmatic as well.
We really need to understand how scalable we have to be before deciding
that the current representation is not good enough.
How to:
* Associate a schema to one or several nodes
As said earlier a schema can be used to validate one or several nodes
from a dts. To do this the "compatible" properties from the nodes which
should be validated must be present in the schema.
timer1: timer@4a318000 {
compatible = "ti,omap3430-timer";
...
To write a schema which will validate OMAP Timers like the one above,
one may write the following schema:
/dts-v1/;
/ {
compatible = "ti,omap[0-9]+-timer";
What about DT nodes that don't have a compatible value? We certainly
have some of those already like /memory and /chosen. We should be able
to validate their schema too. This probably doesn't invalidate being
able to look things up by compatible value though; it just means we need
some additional mechanisms too.
Yes, that's a good point and easy to add as well.
* Define constraints on properties
To define constraints on a property one has to create a node in a schema
which has as name the name of the property that one want to validate.
To specify constraints on the property "ti,hwmods" of OMAP Timers one
can write this schema:
/dts-v1/;
/ {
compatible = "ti,omap[0-9]+-timer";
ti,hwmods {
...
};
compatible and ti,hwmods are both properties in the DT file. However, in
the schema above, one appears as a property, and one as a node. I don't
like that inconsistency. It'd be better if compatible was a node too.
That's already possible, you can check the timer.schema. The point is to
simplify the representation for simple case and use a attribute instead
of a node. But that will make 2 different representation for the same
case, which might not be that good.
If one want to use a regular as property name one can write this schema:
/dts-v1/;
/ {
compatible = "abc";
def {
name = "def[0-9]";
Isn't it val
Re: [PATCH v7 09/10] usb: dwc3: omap: manage "usb_otg_ss_refclk960m" clock
Hi, On Wed, Oct 02, 2013 at 04:41:53PM +0300, Roger Quadros wrote: > On 10/02/2013 04:11 PM, Felipe Balbi wrote: > > On Mon, Sep 23, 2013 at 04:11:30PM +0300, Roger Quadros wrote: > >> Hi Felipe, > >> > >> On 09/18/2013 03:49 PM, Roger Quadros wrote: > >>> "usb_otg_ss_refclk960m" is an optional functional clock to the > >>> UBS_OTG_SS module. So manage it in the driver. > >>> > >> > >> Just realized that "usb_otg_ss_refclk960m" is in fact functional clock to > >> the > >> PHY and not USB_OTG_SS module. The name is misleading. > >> > >> So please ignore patch 9 and 10. > > > > ignored. All others are fine, right ? > > > Yes. But I might have to rebase this on top of Phy framework stuff. alright, Greg already took the PHY framework, so maybe we need to just give him my Acked-by and he takes the patches directly as I don't have PYH framework. -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
Hi Roger,
Yes, I will. I've been waiting for these ones for so long :-)
Thanks,
Benoit
On 03/10/2013 12:34, Roger Quadros wrote:
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
We no longer need to model the RESET line as a regulator since
the USB phy-nop driver accepts "reset-gpios" property.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3-beagle.dts | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index dfd8310..71bde47 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -44,17 +44,6 @@
};
};
- /* HS USB Port 2 RESET */
- hsusb2_reset: hsusb2_reset_reg {
- compatible = "regulator-fixed";
- regulator-name = "hsusb2_reset";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 19 0>; /* gpio_147 */
- startup-delay-us = <7>;
- enable-active-high;
- };
-
/* HS USB Port 2 Power */
hsusb2_power: hsusb2_power_reg {
compatible = "regulator-fixed";
@@ -68,7 +57,7 @@
/* HS USB Host PHY on PORT 2 */
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
- reset-supply = <&hsusb2_reset>;
+ reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>;/* gpio_147 */
vcc-supply = <&hsusb2_power>;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 05/10] ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset
Hi Benoit,
Could you please take the device tree related patches [5 to 10] in this series?
Thanks.
cheers,
-roger
On 09/24/2013 11:53 AM, Roger Quadros wrote:
> We no longer need to model the RESET line as a regulator since
> the USB phy-nop driver accepts "reset-gpios" property.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 13 +
> 1 files changed, 1 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts
> b/arch/arm/boot/dts/omap3-beagle.dts
> index dfd8310..71bde47 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -44,17 +44,6 @@
> };
> };
>
> - /* HS USB Port 2 RESET */
> - hsusb2_reset: hsusb2_reset_reg {
> - compatible = "regulator-fixed";
> - regulator-name = "hsusb2_reset";
> - regulator-min-microvolt = <330>;
> - regulator-max-microvolt = <330>;
> - gpio = <&gpio5 19 0>; /* gpio_147 */
> - startup-delay-us = <7>;
> - enable-active-high;
> - };
> -
> /* HS USB Port 2 Power */
> hsusb2_power: hsusb2_power_reg {
> compatible = "regulator-fixed";
> @@ -68,7 +57,7 @@
> /* HS USB Host PHY on PORT 2 */
> hsusb2_phy: hsusb2_phy {
> compatible = "usb-nop-xceiv";
> - reset-supply = <&hsusb2_reset>;
> + reset-gpios = <&gpio5 19 GPIO_ACTIVE_LOW>; /* gpio_147 */
> vcc-supply = <&hsusb2_power>;
> };
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] USB: phy: phy-nop: Manage RESET GPIO in the driver
Hi, On 09/24/2013 11:53 AM, Roger Quadros wrote: > Hi, > > Modelling the RESET line as a regulator supply wasn't a good idea > as it abuses the regulator framework and makes adaptation > code/data more complex. > > Instead, manage the RESET gpio line directly in the driver. > > This also makes us easy to migrate to a dedicated GPIO RESET controller > whenever it becomes available. > > Apart from RESET line changes this series also adds USB host support > fro beagle-xm and fixes USB OTG port on beagle. > > The full series is avilable at > git://github.com/rogerq/linux.git > in branch > phy-reset The branch is now updated based on v3.12-rc3. cheers, -roger > > *NOTE:* As there are changes to platform data, Patch 1 needs to be shared > between the arm-soc tree and usb tree. > > Patch 1 is available at repo > git://github.com/rogerq/linux.git > in branch > phy-reset-common > > Patch 2 contains the phy-nop driver changes > Patches 3 and 4 adapt legacy boot code to the phy-nop driver changes. > Patches 5, 6 and 7 adapt DT data to the binding changes. > Patch 8 is cleanup of omap3-beagle DT. > Patch 9 adds USB host support to omap3-beagle-xm using the new binding. > Patch 10 fixes USB OTG port on beagle. > > Patches are based on v3.12-rc1 > > Tested leacy boot on omap3-beagle and omap3-beagle-xm > Tested DT boot on omap3-beagle, omap3-beagle-xm and omap4-panda-es > > v3: > - Fix the Initial state of RESET line at probe time. > - Update hsusb3_reset line on omap5-uevm as well. > - Add patch 10 that fixes USB OTG port on beagle. > > v2: > - Added RESET GPIO polarity feature > - Changed to gpio_set_value_cansleep() > > cheers, > -roger > > Roger Quadros (10): > usb: phy: generic: Add gpio_reset to platform data > usb: phy: generic: Don't use regulator framework for RESET line > ARM: OMAP2+: omap-usb-host: Get rid of platform_data from struct > usbhs_phy_data > ARM: OMAP2+: usb-host: Adapt to USB phy-nop RESET line changes > ARM: dts: omap3-beagle: Use reset-gpios for hsusb2_reset > ARM: dts: omap4-panda: Use reset-gpios for hsusb1_reset > ARM: dts: omap5-uevm: Use reset-gpios for hsusb2/3_reset > ARM: dts: omap3-beagle: Make USB host pin naming consistent > ARM: dts: omap3-beagle-xm: Add USB Host support > ARM: dts: omap3-beagle: Add USB OTG PHY details > > .../devicetree/bindings/usb/usb-nop-xceiv.txt |7 +- > arch/arm/boot/dts/omap3-beagle-xm.dts | 65 +-- > arch/arm/boot/dts/omap3-beagle.dts | 44 +-- > arch/arm/boot/dts/omap4-panda-common.dtsi | 18 + > arch/arm/boot/dts/omap5-uevm.dts | 26 +-- > arch/arm/mach-omap2/board-omap3beagle.c|6 -- > arch/arm/mach-omap2/usb-host.c | 18 ++-- > arch/arm/mach-omap2/usb.h |1 - > drivers/usb/phy/phy-am335x.c |2 +- > drivers/usb/phy/phy-generic.c | 84 > +--- > drivers/usb/phy/phy-generic.h |6 +- > include/linux/usb/usb_phy_gen_xceiv.h |3 +- > 12 files changed, 153 insertions(+), 127 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
Hi Tony,
On Wednesday 18 September 2013 09:32 PM, Sricharan R wrote:
> The realtime counter called master counter, produces the count
> used by the private timer peripherals in the MPU_CLUSTER. The
> CNTFRQ per cpu register is used to denote the frequency of the counter.
> Currently the frequency value is passed from the
> DT file, but this is not scalable when we have other non-DT guest
> OS. This register must be set to the right value by the
> secure rom code. Setting this register helps in propagating the right
> frequency value across OSes.
>
> More discussions and the reason for adding this in a non-DT
> way can be seen from below.
> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93832.html
>
> So configuring this secure register for all the cpus here.
>
> While here, removing the clock-frequency DT entry for omap5 as
> it is no more needed after this patch.
>
> Cc: Santosh Shilimkar
> Cc: Nishanth Menon
> Cc: Rajendra Nayak
> Cc: Marc Zyngier
> Cc: Mark Rutland
> Tested-by: Nishanth Menon
> Acked-by: Santosh Shilimkar
> Signed-off-by: Sricharan R
> ---
> [V4] Updated commit log, removed the redundant entry in OMAP5.dtsi and
> a unnecessary newline in timer.c
>
> arch/arm/boot/dts/omap5.dtsi |1 -
> arch/arm/mach-omap2/omap-secure.h |2 ++
> arch/arm/mach-omap2/omap-smp.c|9 +
> arch/arm/mach-omap2/timer.c |5 +
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index 07be2cd..8a45512 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -52,7 +52,6 @@
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>,
> IRQ_TYPE_LEVEL_LOW)>;
> - clock-frequency = <6144000>;
> };
>
> gic: interrupt-controller@48211000 {
> diff --git a/arch/arm/mach-omap2/omap-secure.h
> b/arch/arm/mach-omap2/omap-secure.h
> index 0e72917..5f88824 100644
> --- a/arch/arm/mach-omap2/omap-secure.h
> +++ b/arch/arm/mach-omap2/omap-secure.h
> @@ -42,6 +42,8 @@
> #define OMAP4_MON_L2X0_AUXCTRL_INDEX 0x109
> #define OMAP4_MON_L2X0_PREFETCH_INDEX0x113
>
> +#define OMAP5_DRA7_MON_SET_CNTFRQ_INDEX 0x109
> +
> /* Secure PPA(Primary Protected Application) APIs */
> #define OMAP4_PPA_L2_POR_INDEX 0x23
> #define OMAP4_PPA_CPU_ACTRL_SMP_INDEX0x25
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 8708b2a..5a3c8d3 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -41,6 +41,8 @@
>
> u16 pm44xx_errata;
>
> +extern unsigned long arch_timer_freq;
> +
> /* SCU base address */
> static void __iomem *scu_base;
>
> @@ -66,6 +68,13 @@ static void omap4_secondary_init(unsigned int cpu)
> 4, 0, 0, 0, 0, 0);
>
> /*
> + * Configure the CNTFRQ register for the secondary cpu's which
> + * indicates the frequency of the cpu local timers.
> + */
> + if (soc_is_omap54xx() || soc_is_dra7xx())
> + omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
> +
> + /*
>* Synchronise with the boot thread.
>*/
> spin_lock(&boot_lock);
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index fa74a06..d0af9b2 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -55,6 +55,7 @@
> #include "soc.h"
> #include "common.h"
> #include "powerdomain.h"
> +#include "omap-secure.h"
>
> #define REALTIME_COUNTER_BASE0x48243200
> #define INCREMENTER_NUMERATOR_OFFSET 0x10
> @@ -65,6 +66,7 @@
>
> static struct omap_dm_timer clkev;
> static struct clock_event_device clockevent_gpt;
> +unsigned long arch_timer_freq;
>
> static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id)
> {
> @@ -542,6 +544,9 @@ static void __init realtime_counter_init(void)
> reg |= den;
> __raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
>
> + arch_timer_freq = (rate / den) * num;
> + omap_smc1(OMAP5_DRA7_MON_SET_CNTFRQ_INDEX, arch_timer_freq);
> +
> iounmap(base);
> }
> #else
Are you planning to pull this patch and the below $subject patch as well? They
are
acked and tested.
ARM: DRA7: realtime_counter: Add ratio registers for 20MHZ sys-clk frequency
http://www.spinics.net/lists/linux-omap/msg97281.html
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 2/8] usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power()
Add support for new device types and in the process rid of "ti,type"
device tree property. The correct type of device will be determined
from the compatible string instead.
Introduce a compatible string for each device type. At the moment
we support 4 types OTGHS, USB2, PIPE3 (e.g. USB3) and DRA7USB2.
Update DT binding information to reflect these changes.
Also get rid of omap_control_usb3_phy_power(). Just one function
i.e. omap_control_usb_phy_power() will now take care of all PHY types.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 30 ++--
drivers/usb/phy/phy-omap-control.c | 173 +++
drivers/usb/phy/phy-omap-usb3.c|6 +-
include/linux/usb/omap_control_usb.h | 24 ++--
4 files changed, 130 insertions(+), 103 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 661cb06..9add35c 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -83,22 +83,22 @@ omap_dwc3 {
OMAP CONTROL USB
Required properties:
- - compatible: Should be "ti,omap-control-usb"
+ - compatible: Should be one of
+ "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
+ "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
+ e.g. USB2_PHY on OMAP5.
+ "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
+ e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
+ DRA7 platform.
- reg : Address and length of the register set for the device. It contains
- the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
- depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the
registers
- filled in "reg".
- - ti,type: This is used to differentiate whether the control module has
- usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
- notify events to the musb core and omap5 has usb3 phy power register to
- power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
- phy power.
+ the address of "otghs_control" for control-phy-otghs or "power" register
+ for other types.
+ - reg-names: should be "otghs_control" control-phy-otghs and "power" for
+ other types.
omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
- reg-names = "control_dev_conf", "otghs_control";
- ti,type = <1>;
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
};
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 9772592..1c8a7c5 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,61 +47,70 @@ struct device *omap_get_control_dev(void)
EXPORT_SYMBOL_GPL(omap_get_control_dev);
/**
- * omap_control_usb3_phy_power - power on/off the serializer using control
- * module
+ * omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
- * @on: 0 to off and 1 to on based on powering on or off the PHY
- *
- * usb3 PHY driver should call this API to power on or off the PHY.
+ * @on: 0 or 1, based on powering on or off the PHY
*/
-void omap_control_usb3_phy_power(struct device *dev, bool on)
+void omap_control_usb_phy_power(struct device *dev, int on)
{
u32 val;
unsigned long rate;
- struct omap_control_usb *control_usb = dev_get_drvdata(dev);
+ struct omap_control_usb *control_usb;
- if (control_usb->type != OMAP_CTRL_DEV_TYPE2)
+ if (IS_ERR(dev) || !dev) {
+ pr_err("%s: invalid device\n", __func__);
return;
+ }
- rate = clk_get_rate(control_usb->sys_clk);
- rate = rate/100;
-
- val = readl(control_usb->phy_power);
-
- if (on) {
- val &= ~(OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK |
- OMAP_CTRL_USB_PWRCTL_CLK_FREQ_MASK);
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWERON <<
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
- val |= rate << OMAP_CTRL_USB_PWRCTL_CLK_FREQ_SHIFT;
- } else {
- val &= ~OMAP_CTRL_USB_PWRCTL_CLK_CMD_MASK;
- val |= OMAP_CTRL_USB3_PHY_TX_RX_POWEROFF <<
- OMAP_CTRL_USB_PWRCTL_CLK_CMD_SHIFT;
+ control_usb = dev_get_drvdata(dev);
+ if (!control_usb) {
+ dev_err(dev, "%s: invalid control usb device\n", __func__);
+ return
[PATCH v8 5/8] usb: musb: omap2430: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
Also get rid of "ti,has-mailbox" property as it is redundant and
we can determine that from whether "ctrl-module" property is present
or not. Get rid of has_mailbox from musb_hdrc_platform_data as well.
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/omap-usb.txt |4 ---
drivers/usb/musb/omap2430.c| 25 +++
include/linux/usb/musb.h |2 -
3 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 9add35c..090e5e2 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
OMAP MUSB GLUE
- compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
- ti,hwmods : must be "usb_otg_hs"
- - ti,has-mailbox : to specify that omap uses an external mailbox
- (in control module) to communicate with the musb core during device connect
- and disconnect.
- multipoint : Should be "1" indicating the musb controller supports
multipoint. This is a MUSB configuration-specific setting.
- num-eps : Specifies the number of endpoints. This is also a
@@ -31,7 +28,6 @@ SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
compatible = "ti,omap4-musb";
ti,hwmods = "usb_otg_hs";
- ti,has-mailbox;
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index d0fc4d9..9eab645 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include "musb_core.h"
#include "omap2430.h"
@@ -524,8 +525,12 @@ static int omap2430_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->musb = musb;
glue->status= OMAP_MUSB_UNKNOWN;
+ glue->control_otghs = ERR_PTR(-ENODEV);
if (np) {
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata) {
dev_err(&pdev->dev,
@@ -554,22 +559,20 @@ static int omap2430_probe(struct platform_device *pdev)
of_property_read_u32(np, "ram-bits", (u32 *)&config->ram_bits);
of_property_read_u32(np, "power", (u32 *)&pdata->power);
config->multipoint = of_property_read_bool(np, "multipoint");
- pdata->has_mailbox = of_property_read_bool(np,
- "ti,has-mailbox");
pdata->board_data = data;
pdata->config = config;
- }
- if (pdata->has_mailbox) {
- glue->control_otghs = omap_get_control_dev();
- if (IS_ERR(glue->control_otghs)) {
- dev_vdbg(&pdev->dev, "Failed to get control device\n");
- ret = PTR_ERR(glue->control_otghs);
- goto err2;
+ control_node = of_parse_phandle(np, "ctrl-module", 0);
+ if (control_node) {
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control
device\n");
+ ret = -EINVAL;
+ goto err2;
+ }
+ glue->control_otghs = &control_pdev->dev;
}
- } else {
- glue->control_otghs = ERR_PTR(-ENODEV);
}
pdata->platform_ops = &omap2430_ops;
diff --git a/include/linux/usb/musb.h b/include/linux/usb/musb.h
index 053c268..eb50525 100644
--- a/include/linux/usb/musb.h
+++ b/include/linux/usb/musb.h
@@ -99,8 +99,6 @@ struct musb_hdrc_platform_data {
/* MUSB_HOST, MUSB_PERIPHERAL, or MUSB_OTG */
u8 mode;
- u8 has_mailbox:1;
-
/* for clk_get() */
const char *clock;
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 4/8] usb: phy: omap-usb3: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-usb3.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-usb3.c b/drivers/usb/phy/phy-omap-usb3.c
index 0824be4..0c6ba29 100644
--- a/drivers/usb/phy/phy-omap-usb3.c
+++ b/drivers/usb/phy/phy-omap-usb3.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#definePLL_STATUS 0x0004
#definePLL_GO 0x0008
@@ -196,8 +197,14 @@ static int omap_usb3_init(struct usb_phy *x)
static int omap_usb3_probe(struct platform_device *pdev)
{
- struct omap_usb *phy;
- struct resource *res;
+ struct omap_usb *phy;
+ struct resource *res;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -EINVAL;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -239,11 +246,18 @@ static int omap_usb3_probe(struct platform_device *pdev)
return -EINVAL;
}
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
- return -ENODEV;
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -EINVAL;
+ }
+
+ phy->control_dev = &control_pdev->dev;
omap_control_usb_phy_power(phy->control_dev, 0);
usb_add_phy_dev(&phy->phy);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 3/8] usb: phy: omap-usb2: Don't use omap_get_control_dev()
omap_get_control_dev() is being deprecated as it doesn't support
multiple instances. As control device is present only from OMAP4
onwards which supports DT only, we use phandles to get the
reference to the control device.
As we don't support non-DT boot, we just bail out on probe
if device node is not present.
Signed-off-by: Roger Quadros
---
drivers/phy/phy-omap-usb2.c | 31 +++
1 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 4d7b4e5..bfc5c33 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
/**
* omap_usb2_set_comparator - links the comparator present in the sytem with
@@ -145,10 +146,16 @@ static struct phy_ops ops = {
static int omap_usb2_probe(struct platform_device *pdev)
{
- struct omap_usb *phy;
- struct phy *generic_phy;
- struct usb_otg *otg;
- struct phy_provider *phy_provider;
+ struct omap_usb *phy;
+ struct phy *generic_phy;
+ struct phy_provider *phy_provider;
+ struct usb_otg *otg;
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *control_node;
+ struct platform_device *control_pdev;
+
+ if (!node)
+ return -EINVAL;
phy = devm_kzalloc(&pdev->dev, sizeof(*phy), GFP_KERNEL);
if (!phy) {
@@ -175,12 +182,20 @@ static int omap_usb2_probe(struct platform_device *pdev)
if (IS_ERR(phy_provider))
return PTR_ERR(phy_provider);
- phy->control_dev = omap_get_control_dev();
- if (IS_ERR(phy->control_dev)) {
- dev_dbg(&pdev->dev, "Failed to get control device\n");
- return -ENODEV;
+ control_node = of_parse_phandle(node, "ctrl-module", 0);
+ if (!control_node) {
+ dev_err(&pdev->dev, "Failed to get control device phandle\n");
+ return -EINVAL;
}
+ control_pdev = of_find_device_by_node(control_node);
+ if (!control_pdev) {
+ dev_err(&pdev->dev, "Failed to get control device\n");
+ return -EINVAL;
+ }
+
+ phy->control_dev = &control_pdev->dev;
+
phy->is_suspended = 1;
omap_control_usb_phy_power(phy->control_dev, 0);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/8] usb: phy: omap-control: Get rid of platform data
omap-control device is present from OMAP4 onwards which
support device tree boots only. So get rid of platform data.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 12 +++-
include/linux/usb/omap_control_usb.h |4
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index a4dda8e..9772592 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -197,8 +197,6 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
struct device_node *np = pdev->dev.of_node;
- struct omap_control_usb_platform_data *pdata =
- dev_get_platdata(&pdev->dev);
control_usb = devm_kzalloc(&pdev->dev, sizeof(*control_usb),
GFP_KERNEL);
@@ -207,14 +205,10 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
return -ENOMEM;
}
- if (np) {
+ if (np)
of_property_read_u32(np, "ti,type", &control_usb->type);
- } else if (pdata) {
- control_usb->type = pdata->type;
- } else {
- dev_err(&pdev->dev, "no pdata present\n");
- return -EINVAL;
- }
+ else
+ return -EINVAL; /* We only support DT boot */
control_usb->dev= &pdev->dev;
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 27b5b8c..e2416b4 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -31,10 +31,6 @@ struct omap_control_usb {
u32 type;
};
-struct omap_control_usb_platform_data {
- u8 type;
-};
-
enum omap_control_usb_mode {
USB_MODE_UNDEFINED = 0,
USB_MODE_HOST,
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 6/8] ARM: dts: omap4: update omap-control-usb nodes
Split otghs_ctrl and USB2 PHY power-down into separate
omap-control-usb nodes. Get rid of "ti,type" property.
Also get rid of "ti,has-mailbox" property from usb_otg_hs
node and provide the ctrl-module phandle.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 1e8e2fe..ea4054b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -519,7 +519,7 @@
usb2_phy: usb2phy@4a0ad080 {
compatible = "ti,omap-usb2";
reg = <0x4a0ad080 0x58>;
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb2phy>;
#phy-cells = <0>;
};
};
@@ -644,12 +644,16 @@
};
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a00233c 0x4>;
- reg-names = "control_dev_conf", "otghs_control";
- ti,type = <1>;
+ omap_control_usb2phy: control-phy@4a002300 {
+ compatible = "ti,control-phy-usb2";
+ reg = <0x4a002300 0x4>;
+ reg-names = "power";
+ };
+
+ omap_control_usbotg: control-phy@4a00233c {
+ compatible = "ti,control-phy-otghs";
+ reg = <0x4a00233c 0x4>;
+ reg-names = "otghs_control";
};
usb_otg_hs: usb_otg_hs@4a0ab000 {
@@ -664,7 +668,7 @@
multipoint = <1>;
num-eps = <16>;
ram-bits = <12>;
- ti,has-mailbox;
+ ctrl-module = <&omap_control_usbotg>;
};
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 7/8] usb: phy: omap: get rid of omap_get_control_dev()
This function was preventing us from supporting multiple
instances. Get rid of it. Since we support DT boots only,
users can get the control device phandle from the DT node.
Signed-off-by: Roger Quadros
---
drivers/usb/phy/phy-omap-control.c | 31 ++-
include/linux/usb/omap_control_usb.h |5 -
2 files changed, 10 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-control.c
b/drivers/usb/phy/phy-omap-control.c
index 1c8a7c5..09c5ace 100644
--- a/drivers/usb/phy/phy-omap-control.c
+++ b/drivers/usb/phy/phy-omap-control.c
@@ -26,26 +26,6 @@
#include
#include
-static struct omap_control_usb *control_usb;
-
-/**
- * omap_get_control_dev - returns the device pointer for this control device
- *
- * This API should be called to get the device pointer for this control
- * module device. This device pointer should be used for called other
- * exported API's in this driver.
- *
- * To be used by PHY driver and glue driver.
- */
-struct device *omap_get_control_dev(void)
-{
- if (!control_usb)
- return ERR_PTR(-ENODEV);
-
- return control_usb->dev;
-}
-EXPORT_SYMBOL_GPL(omap_get_control_dev);
-
/**
* omap_control_usb_phy_power - power on/off the phy using control module reg
* @dev: the control module device
@@ -182,11 +162,19 @@ void omap_control_usb_set_mode(struct device *dev,
{
struct omap_control_usb *ctrl_usb;
- if (IS_ERR(dev) || control_usb->type != OMAP_CTRL_TYPE_OTGHS)
+ if (IS_ERR(dev) || !dev)
return;
ctrl_usb = dev_get_drvdata(dev);
+ if (!ctrl_usb) {
+ dev_err(dev, "Invalid control usb device\n");
+ return;
+ }
+
+ if (ctrl_usb->type != OMAP_CTRL_TYPE_OTGHS)
+ return;
+
switch (mode) {
case USB_MODE_HOST:
omap_control_usb_host_mode(ctrl_usb);
@@ -237,6 +225,7 @@ static int omap_control_usb_probe(struct platform_device
*pdev)
{
struct resource *res;
const struct of_device_id *of_id;
+ struct omap_control_usb *control_usb;
of_id = of_match_device(of_match_ptr(omap_control_usb_id_table),
&pdev->dev);
diff --git a/include/linux/usb/omap_control_usb.h
b/include/linux/usb/omap_control_usb.h
index 61b889a..596b019 100644
--- a/include/linux/usb/omap_control_usb.h
+++ b/include/linux/usb/omap_control_usb.h
@@ -65,15 +65,10 @@ enum omap_control_usb_mode {
#define OMAP_CTRL_USB2_PHY_PD BIT(28)
#if IS_ENABLED(CONFIG_OMAP_CONTROL_USB)
-extern struct device *omap_get_control_dev(void);
extern void omap_control_usb_phy_power(struct device *dev, int on);
extern void omap_control_usb_set_mode(struct device *dev,
enum omap_control_usb_mode mode);
#else
-static inline struct device *omap_get_control_dev(void)
-{
- return ERR_PTR(-ENODEV);
-}
static inline void omap_control_usb_phy_power(struct device *dev, int on)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 8/8] ARM: dts: omap5: update omap-control-usb node
Split USB2 PHY and USB3 PHY into separate omap-control-usb
nodes. Get rid of "ti,type" property.
CC: Benoit Cousson
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 20
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 7cdea1b..c0ec6dc 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -626,12 +626,16 @@
hw-caps-temp-alert;
};
- omap_control_usb: omap-control-usb@4a002300 {
- compatible = "ti,omap-control-usb";
- reg = <0x4a002300 0x4>,
- <0x4a002370 0x4>;
- reg-names = "control_dev_conf", "phy_power_usb";
- ti,type = <2>;
+ omap_control_usb2phy: control-phy@4a002300 {
+ compatible = "ti,control-phy-usb2";
+ reg = <0x4a002300 0x4>;
+ reg-names = "power";
+ };
+
+ omap_control_usb3phy: control-phy@4a002370 {
+ compatible = "ti,control-phy-pipe3";
+ reg = <0x4a002370 0x4>;
+ reg-names = "power";
};
omap_dwc3@4a02 {
@@ -662,7 +666,7 @@
usb2_phy: usb2phy@4a084000 {
compatible = "ti,omap-usb2";
reg = <0x4a084000 0x7c>;
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb2phy>;
};
usb3_phy: usb3phy@4a084400 {
@@ -671,7 +675,7 @@
<0x4a084800 0x64>,
<0x4a084c00 0x40>;
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
- ctrl-module = <&omap_control_usb>;
+ ctrl-module = <&omap_control_usb3phy>;
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/8] phy: omap-usb: Support multiple instances and new types
Hi, This patchset does the following: * Get rid of omap_control_usb platform data as we support DT only. * Restructure and add support for new PHY types. We now support the following four types TYPE_OTGHS - if it has otghs_control mailbox register (e.g. on OMAP4) TYPE_USB2 - if it has Power down bit in control_dev_conf register. e.g. USB2 PHY TYPE_PIPE3 - if it has DPLL and individual Rx & Tx power control. e.g. USB3 PHY or SATA PHY TYPE_DRA7USB2 - if it has both power down and power aux registers. e.g. USB2 PHY on DRA7 * Get rid of "ti,type" DT property and introduce compatible strings for each type. * Have only one power control API "omap_control_usb_phy_power()" instead of a different one for each PHY type. * Get rid of omap_get_control_dev() so that we can support multiple instances of the control device. We take advantage of the fact that omap control USB device is only present on OMAP4 onwards and hence only supports DT boot. The users of control USB device can get a reference to it from the device node's phandle. Patches are based on greg/usb-next. Smoke tested on OMAP4 panda with MUSB in gadget mode (g_zero). You can find the patches in branch usb-control-module in git tree git://github.com/rogerq/linux.git v8: - Rebased on top of greg/usb-next to avoid conflicts - Removed patches 9 and 10 as they are not applicable v7: - Rebased on v3.12-rc1 - Updated DT compatibility ID for better readability - Renamed TYPE_OMAP4 to TYPE_OTGHS, TYPE_USB3 to TYPE_PIPE3 and TYPE_DRA7 to TYPE_DRA7USB2 v6: - addressed review comment about usage of control_usb before allocation. v5: - fixed whitespace alignment issues. v4: - removed "ti,has-mailbox" from omap-usb binding document example. v3: - return -EINVAL instead of -ENODEV on probe failure. - pass device type data through of_device_id table. - get rid of "ti,mailbox" property and "has_mailbox" from musb platform data. v2: - get rid of "ti,type" property and introduce compatible strings for each device type. cheers, -roger Roger Quadros (8): usb: phy: omap-control: Get rid of platform data usb: phy: omap: Add new device types and remove omap_control_usb3_phy_power() usb: phy: omap-usb2: Don't use omap_get_control_dev() usb: phy: omap-usb3: Don't use omap_get_control_dev() usb: musb: omap2430: Don't use omap_get_control_dev() ARM: dts: omap4: update omap-control-usb nodes usb: phy: omap: get rid of omap_get_control_dev() ARM: dts: omap5: update omap-control-usb node Documentation/devicetree/bindings/usb/omap-usb.txt | 34 ++-- arch/arm/boot/dts/omap4.dtsi | 20 ++- arch/arm/boot/dts/omap5.dtsi | 20 ++- drivers/phy/phy-omap-usb2.c| 31 +++- drivers/usb/musb/omap2430.c| 25 ++- drivers/usb/phy/phy-omap-control.c | 208 ++- drivers/usb/phy/phy-omap-usb3.c| 32 +++- include/linux/usb/musb.h |2 - include/linux/usb/omap_control_usb.h | 33 ++-- 9 files changed, 220 insertions(+), 185 deletions(-) -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
