Re: [PATCH 0/3] dma: cppi41: more suspend/resume patches
* Daniel Mack | 2013-10-01 15:31:08 [+0200]: >Patch #1 restores more registers on resume time. > >Patch #2 is a cosmetic cleanup that emerged while digging through the >driver and gaining a basic idea of how it's implemented. Nothing fancy. I'm fine with those two. > >Patch #3, however, gives me headaches. I can't fully explain what's >going on, but I can tell for sure that if fixes a problem that I stared >on for many hours. I'm still trying to verify if it breaks something or not. So I haven't forgotten about this. Sebastian -- 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] ARM: omap: edma: add suspend suspend/resume hooks
On Wednesday 09 October 2013 11:33 AM, Fernandes, Joel wrote: > Some temporary issues with my mua so forgive any artifacts in this email. > > On Oct 9, 2013, at 12:14 AM, "Hebbar, Gururaja" > wrote: > >> On Wednesday 09 October 2013 09:58 AM, Joel Fernandes wrote: >>> On 10/01/2013 10:04 AM, Daniel Mack wrote: This patch makes the edma driver resume correctly after suspend. Tested on an AM33xx platform with cyclic audio streams. The code was shamelessly taken from an ancient BSP tree. Signed-off-by: Daniel Mack --- arch/arm/common/edma.c | 133 + 1 file changed, 133 insertions(+) >> >> ..snip.. >> ..snip.. >>> +edma_cc[j]->context.ch_map = +kzalloc((sizeof(unsigned int) * + edma_cc[j]->num_channels), GFP_KERNEL); +edma_cc[j]->context.que_num = +kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL); >>> >>> Can these allocations be moved to the suspend path? For systems that don't >>> suspend/resume even once, I feel we shouldn't allocate memory that we don't >>> use. >>> These allocations are better to do there. >> >> AFAIK, Suspend/resume should be quick. Allocating and deallocating on >> every iterating would be useless and time consuming. > > Nobody said allocate and deallocate on every iteration. Allocate once during > the first suspend call and then don't have to allocate on subsequent calls. I couldn't find any code which allocates parameters inside suspend. Could you show me some code which does this? > > As for suspend resume being quick, that argument can flipped the other way > too, booting should be quick which is far more frequent than suspend/resume. > Apart from the fact that we're not allocating useless memory we would never > use. > >> >> Also this task is one time and quick. > > Exactly. i was referring to allocating in probe call.. > >> >> Are there any systems (Linux based for now) which doesn't >> suspend/resume? I believe the probability is very less. > > Nobody talked about suspend/resume not being supported in Linux so not sure > what your argument is here. I meant linux systems which doesn't go to suspend and resume. Not suspend/resume feature. Also, I was referring to your 1st comment "... For systems that don't suspend/resume even once, " regards Gururaja > > regards, > > -Joel > >> >> regards >> Gururaja >> >>> >>> -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 >> -- 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] ARM: omap: edma: add suspend suspend/resume hooks
Some temporary issues with my mua so forgive any artifacts in this email. On Oct 9, 2013, at 12:14 AM, "Hebbar, Gururaja" wrote: > On Wednesday 09 October 2013 09:58 AM, Joel Fernandes wrote: >> On 10/01/2013 10:04 AM, Daniel Mack wrote: >>> This patch makes the edma driver resume correctly after suspend. Tested >>> on an AM33xx platform with cyclic audio streams. >>> >>> The code was shamelessly taken from an ancient BSP tree. >>> >>> Signed-off-by: Daniel Mack >>> --- >>> arch/arm/common/edma.c | 133 >>> + >>> 1 file changed, 133 insertions(+) > > ..snip.. > ..snip.. >> >>> +edma_cc[j]->context.ch_map = >>> +kzalloc((sizeof(unsigned int) * >>> + edma_cc[j]->num_channels), GFP_KERNEL); >>> +edma_cc[j]->context.que_num = >>> +kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL); >> >> Can these allocations be moved to the suspend path? For systems that don't >> suspend/resume even once, I feel we shouldn't allocate memory that we don't >> use. >> These allocations are better to do there. > > AFAIK, Suspend/resume should be quick. Allocating and deallocating on > every iterating would be useless and time consuming. Nobody said allocate and deallocate on every iteration. Allocate once during the first suspend call and then don't have to allocate on subsequent calls. As for suspend resume being quick, that argument can flipped the other way too, booting should be quick which is far more frequent than suspend/resume. Apart from the fact that we're not allocating useless memory we would never use. > > Also this task is one time and quick. Exactly. > > Are there any systems (Linux based for now) which doesn't > suspend/resume? I believe the probability is very less. Nobody talked about suspend/resume not being supported in Linux so not sure what your argument is here. regards, -Joel > > regards > Gururaja > >> >> -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 > -- 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/1] ARM: OMAP2+: pdata-quirks: add legacy display init for IGEPv2 board
Hi Tony, On 09/10/13 00:11, Tony Lindgren wrote: > * Javier Martinez Canillas [131004 20:00]: >> IGEPv2 board has both an DVI and TFP410 video interfaces but >> DSS support for DeviceTree has not yet landed in mainline so >> is necessary to init the displays using legacy platform code. > > Thanks, applying into omap-for-v3.13/quirk. Can you remove the patch from your branch? It had bug, and I had some questions related to it. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] ARM: OMAP2+: pdata-quirks: add legacy display init for IGEPv2 board
Hi,
On 05/10/13 05:51, Javier Martinez Canillas wrote:
> IGEPv2 board has both an DVI and TFP410 video interfaces but
> DSS support for DeviceTree has not yet landed in mainline so
> is necessary to init the displays using legacy platform code.
>
> Signed-off-by: Javier Martinez Canillas
> ---
> arch/arm/mach-omap2/dss-common.c | 37 +
> arch/arm/mach-omap2/dss-common.h | 1 +
> arch/arm/mach-omap2/pdata-quirks.c | 7 +++
> 3 files changed, 45 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/dss-common.c
> b/arch/arm/mach-omap2/dss-common.c
> index bf89eff..0c1cf2e 100644
> --- a/arch/arm/mach-omap2/dss-common.c
> +++ b/arch/arm/mach-omap2/dss-common.c
> @@ -39,6 +39,7 @@
> #define HDMI_GPIO_HPD 63 /* Hotplug detect */
>
> #define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
> +#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170
>
> /* DVI Connector */
> static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
> @@ -53,6 +54,18 @@ static struct platform_device
> omap4_panda_dvi_connector_device = {
> .dev.platform_data = &omap4_panda_dvi_connector_pdata,
> };
>
> +static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
> + .name = "dvi",
> + .source = "tfp410.0",
> + .i2c_bus_num= 3,
> +};
> +
> +static struct platform_device omap3_igep2_dvi_connector_device = {
> + .name = "connector-dvi",
> + .id = 0,
> + .dev.platform_data = &omap3_igep2_dvi_connector_pdata,
> +};
> +
> /* TFP410 DPI-to-DVI chip */
> static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
> .name = "tfp410.0",
> @@ -67,6 +80,19 @@ static struct platform_device omap4_panda_tfp410_device = {
> .dev.platform_data = &omap4_panda_tfp410_pdata,
> };
>
> +static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = {
> + .name = "tfp410.0",
> + .source = "dpi.0",
> + .data_lines = 24,
> + .power_down_gpio= IGEP2_DVI_TFP410_POWER_DOWN_GPIO,
> +};
> +
> +static struct platform_device omap3_igep2_tfp410_device = {
> + .name = "tfp410",
> + .id = 0,
> + .dev.platform_data = &omap3_igep2_tfp410_pdata,
> +};
> +
I think it would be better to organize the file in sections based on
boards. Not mixing the display devices for different boards like above.
> /* HDMI Connector */
> static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata
> = {
> .name = "hdmi",
> @@ -99,6 +125,10 @@ static struct omap_dss_board_info omap4_panda_dss_data = {
> .default_display_name = "dvi",
> };
>
> +static struct omap_dss_board_info igep2_dss_data = {
> + .default_display_name = "dvi",
> +};
> +
> void __init omap4_panda_display_init_of(void)
> {
> omap_display_init(&omap4_panda_dss_data);
> @@ -110,6 +140,13 @@ void __init omap4_panda_display_init_of(void)
> platform_device_register(&omap4_panda_hdmi_connector_device);
> }
>
> +void __init omap3_igep2_display_init_of(void)
> +{
> + omap_display_init(&igep2_dss_data);
> +
> + platform_device_register(&omap3_igep2_tfp410_device);
> + platform_device_register(&omap3_igep2_dvi_connector_device);
> +}
Wouldn't it be better to remove the display setup from the board file at
the same time as it's added here? Otherwise we'll end up with the same
display setup being in two different files.
> @@ -103,6 +108,8 @@ static struct pdata_init pdata_quirks[] __initdata = {
> #ifdef CONFIG_ARCH_OMAP3
> { "nokia,omap3-n9", hsmmc2_internal_input_clk, },
> { "nokia,omap3-n950", hsmmc2_internal_input_clk, },
> + { "nokia,omap3-n950", hsmmc2_internal_input_clk, },
The above is extra.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFCv3 1/7] ARM: OMAP2+: hwmod-data: Add SSI information
On Sun, 6 Oct 2013, Sebastian Reichel wrote: > This patch adds Synchronous Serial Interface (SSI) hwmod support for > OMAP34xx SoCs. > > Signed-off-by: Sebastian Reichel Thanks, queued this one for v3.13. You can drop it from any future reposts of this series. - Paul -- 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
Hi On Thu, 3 Oct 2013, 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. thanks for doing this. A few comments: 1. The patch adds a warning when checked with 'checkpatch.pl --strict': CHECK: Alignment should match open parenthesis #109: FILE: arch/arm/mach-omap2/omap_hwmod.c:2434: + WARN(1, "omap_hwmod: %s: doesn't have mpu register target base\n", + oh->name); The issue has been fixed in in the local copy, but please don't forget to ensure that your patches don't generate any warnings[*] from 'checkpatch.pl --strict' before sending them. [*] Well, with the possible exception of 80-column violations when necessary. 2. -ENOMEM isn't the right error code to use here - it connotates "out of memory" rather than "missing address space". -ENXIO seems better, so I've changed the patch to use that instead. The patch has been queued provisionally, pending the outcome of testing. - Paul -- 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] ARM: omap: edma: add suspend suspend/resume hooks
On Wednesday 09 October 2013 09:58 AM, Joel Fernandes wrote: > On 10/01/2013 10:04 AM, Daniel Mack wrote: >> This patch makes the edma driver resume correctly after suspend. Tested >> on an AM33xx platform with cyclic audio streams. >> >> The code was shamelessly taken from an ancient BSP tree. >> >> Signed-off-by: Daniel Mack >> --- >> arch/arm/common/edma.c | 133 >> + >> 1 file changed, 133 insertions(+) >> ..snip.. ..snip.. > >> +edma_cc[j]->context.ch_map = >> +kzalloc((sizeof(unsigned int) * >> + edma_cc[j]->num_channels), GFP_KERNEL); >> +edma_cc[j]->context.que_num = >> +kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL); > > Can these allocations be moved to the suspend path? For systems that don't > suspend/resume even once, I feel we shouldn't allocate memory that we don't > use. > These allocations are better to do there. AFAIK, Suspend/resume should be quick. Allocating and deallocating on every iterating would be useless and time consuming. Also this task is one time and quick. Are there any systems (Linux based for now) which doesn't suspend/resume? I believe the probability is very less. regards Gururaja > > -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 > -- 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 3/6] pinctrl: single: Prepare for supporting SoC specific features
On Tue, Oct 8, 2013 at 7:55 PM, Linus Walleij wrote: > On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren wrote: > >> Hi Linus W, >> >> Any comments on the pinctrl patches 3 - 5 in this series? > > I have no problems with this patch #3, as it is just changing syntax, > not semantics. > > The problems start with patch #4. > > I am tormented with mixed feelings about this, because from one point of > view I feel it is breaking the promise of pinctrl-single being a > driver for platforms > where a pin is controlled by a *single* register. > > If this was pinctrl-foo.c I would not have been so much bothered, > but now it is something that was supposed to be self-contained and > simple, pertaining to a single register, starting to look like something > else. > > This is a bit like: "oh yeah just one register controls the pins, but under > some circumstances I also want to mess with this register over here, > and then this register over there ..." etc. > > I'd like Haojian to ACK this to proceed since he's also using this driver > now. Then I feel better on continuing down this road ... > > Then I have a lesser comment on patch #4 since it makes it possible > for this pin controller to support wake-up interrupt, as I don't see how > this plays out with front-end GPIO controllers, but let's discuss that > in the context of that patch. > > Yours, > Linus Walleij > I'm OK on both #3 & #4. So Acked-by: Haojian Zhuang Regards Haojian -- 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] ARM: omap: edma: add suspend suspend/resume hooks
On 10/01/2013 10:04 AM, Daniel Mack wrote:
> This patch makes the edma driver resume correctly after suspend. Tested
> on an AM33xx platform with cyclic audio streams.
>
> The code was shamelessly taken from an ancient BSP tree.
>
> Signed-off-by: Daniel Mack
> ---
> arch/arm/common/edma.c | 133
> +
> 1 file changed, 133 insertions(+)
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index 2a72169..d787f14 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -258,6 +258,20 @@ struct edma {
> void *data);
> void *data;
> } intr_data[EDMA_MAX_DMACH];
> +
> + struct {
> + struct edmacc_param *prm_set;
> + unsigned int *ch_map; /* 64 registers */
> + unsigned int *que_num; /* 8 registers */
This is OK to save.
> + unsigned int sh_esr;
> + unsigned int sh_esrh;
> + unsigned int sh_eesr;
> + unsigned int sh_eesrh;
> + unsigned int sh_iesr;
> + unsigned int sh_iesrh;
Are all these really necessary?
esr and eer- No one should really be setting the esr and should not depend on it
when going to a low power state. I wouldn't expect any driver to suspend between
edma_start and edma_stop. In DMA Engine, this would correspond to the driver
getting a successful callback.
Before suspend, drivers using DMA should anyway be done with using the channel
before they can goto suspend, correct me if I'm wrong. So this seems unnecessary
to do.
Only thing that makes sense to me to save here is the iesr registers.
> + unsigned int que_tc_map;
> + unsigned int que_pri;
This is OK to save.
> + } context;
> };
>
> static struct edma *edma_cc[EDMA_MAX_CC];
> @@ -1655,6 +1669,16 @@ static int edma_probe(struct platform_device *pdev)
> memcpy_toio(edmacc_regs_base[j] + PARM_OFFSET(i),
> &dummy_paramset, PARM_SIZE);
>
> + /* resume context */
> + edma_cc[j]->context.prm_set =
> + kzalloc((sizeof(struct edmacc_param) *
> + edma_cc[j]->num_slots), GFP_KERNEL);
Why should you back-up PaRAM set? I feel this is not necessary. PaRAM set will
be setup again for the transfer after the resume, and there shouldn't be any
pending transfers before the suspend.
Looks like in your audio driver you need to make sure any pending DMA transfers
are completed before suspending (unless you're already doing so).
> + edma_cc[j]->context.ch_map =
> + kzalloc((sizeof(unsigned int) *
> + edma_cc[j]->num_channels), GFP_KERNEL);
> + edma_cc[j]->context.que_num =
> + kzalloc((sizeof(unsigned int) * 8), GFP_KERNEL);
Can these allocations be moved to the suspend path? For systems that don't
suspend/resume even once, I feel we shouldn't allocate memory that we don't use.
These allocations are better to do there.
-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
Re: [PATCH] ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller
Hi Nishanth,
On 08/10/2013 17:43, Nishanth Menon wrote:
On 09/19/2013 02:11 PM, Nishanth Menon wrote:
This allows the palmas pm_power_off to kick in on power off command
and switch off the board.
Signed-off-by: Nishanth Menon
---
Based on: (benoit's for_3.13/dts branch)
https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
This uses the support introduced by:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b81eec09a484c588ead035003ce7555ca8a9963a
arch/arm/boot/dts/omap5-uevm.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index da25a14..8227386 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -271,6 +271,7 @@
reg = <0x48>;
interrupt-controller;
#interrupt-cells = <2>;
+ ti,system-power-controller;
extcon_usb3: palmas_usb {
compatible = "ti,palmas-usb-vid";
Gentle ping.
patchworks link: https://patchwork.kernel.org/patch/2913111/
I've just applied it and pushed it to my branch.
Thanks,
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: [PATCH V4] ARM: OMAP5/DRA7: realtime_counter: Configure CNTFRQ register
On Tuesday 08 October 2013 05:45 PM, Tony Lindgren wrote:
> * Sricharan R [131003 03:27]:
>> On Wednesday 18 September 2013 09:32 PM, Sricharan R wrote:
>>> --- 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 {
>
> Can the above be done later on in a separate clean-up patch?
> If so I can drop that part as that removes a dependency to the
> .dts patches queued by Benoit.
>
This can be applied separately.
>>> --- 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;
>>>
>
> No externs in *.c files please, checkpatch.pl and sparse should warn
> about this.
>
>> 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
>
> The 20MHz patch I've applied, just noticed the above things
> when was about to apply this.
>
Now re-looking at the patch, I think this extern stuff can be and
should be avoided. It needs order change though like below. Not
tested but should work.
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fa74a06..c8d8308 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -631,10 +631,9 @@ void __init omap4_local_timer_init(void)
#ifdef CONFIG_SOC_OMAP5
void __init omap5_realtime_timer_init(void)
{
- omap4_sync32k_timer_init();
realtime_counter_init();
-
clocksource_of_init();
+ omap4_sync32k_timer_init();
}
#endif /* CONFIG_SOC_OMAP5 */
Then, the CNTFREQ programming needs to be moved to
realtime_counter_init(). It should be actually part of that
first place instead of timer_init().
On secondary CPU then a simple asm accessor can
read the CNTFREQ and pass that to SMC.
Sricharan,
Can you try above and see if everything works as expected.
If it does, please post an updated patch based on above.
Regards,
santosh
--
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
[GIT PULL] omap fixes against v3.12-rc3
The following changes since commit 15c03dd4859ab16f9212238f29dd315654aa94f6: Linux 3.12-rc3 (2013-09-29 15:02:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/fixes-against-v3.12-rc3-take2 for you to fetch changes up to d1f1ca36b566aa56effdd7df69750062ec735131: ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config (2013-10-08 11:22:43 -0700) Few fixes for omap3 related hangs and errors that people have noticed now that people are actually using the device tree based booting for omap3. Also one regression fix for timer compile for dra7xx when omap5 is not selected, and a LED regression fix for n900. Aaro Koskinen (1): ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT Nishanth Menon (1): ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree Pali Rohár (1): ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config Simon Barth (1): ARM: mach-omap2: board-generic: fix undefined symbol Tony Lindgren (1): ARM: dts: Fix pinctrl mask for omap3 arch/arm/boot/dts/omap3-beagle-xm.dts| 2 +- arch/arm/boot/dts/omap3.dtsi | 4 ++-- arch/arm/mach-omap2/board-generic.c | 18 ++ arch/arm/mach-omap2/board-rx51-peripherals.c | 9 + arch/arm/mach-omap2/gpmc-onenand.c | 12 +++- arch/arm/mach-omap2/mux.h| 4 +--- arch/arm/mach-omap2/timer.c | 4 ++-- include/dt-bindings/pinctrl/omap.h | 4 +--- 8 files changed, 45 insertions(+), 12 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] ARM: OMAP2+: hwmod: check for module address space during init
Tony, On 10/08/2013 01:09 PM, Tony Lindgren wrote: > * Suman Anna [131003 10:07]: >> 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. > > Hmm so is this needed as a fix for the -rcy cycle? This is a dependency for a successful OMAP5 boot with Tero's clock patches (just the clock patches won't help), but those are not in 3.12-rcy anyway. I will leave it upto you and Paul, it will be one less patch that people need to worry about for booting OMAP5 if it can make the -rcy cycle. regards Suman > > Other than that looks OK to me, Paul should queue or ack this one: > > 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 > -- 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
* Sricharan R [131003 03:27]:
> On Wednesday 18 September 2013 09:32 PM, Sricharan R wrote:
> > --- 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 {
Can the above be done later on in a separate clean-up patch?
If so I can drop that part as that removes a dependency to the
.dts patches queued by Benoit.
> > --- 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;
> >
No externs in *.c files please, checkpatch.pl and sparse should warn
about this.
> 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
The 20MHz patch I've applied, just noticed the above things
when was about to apply this.
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
OMAP baseline test results for v3.12-rc4
Here are some basic OMAP test results for Linux v3.12-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.12-rc4/20131007013715/ Test summary Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 4/ 7): 2430sdp, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 3/ 7): 3530es3beagle, 3730beaglexm, 37xxevm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 5): 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 5): 3530es3beagle, 37xxevm PM: chip off via dynamic idle: FAIL ( 3/ 5): 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 5): 3530es3beagle, 37xxevm vmlinux object size (delta in bytes from test_v3.12-rc3 (15c03dd4859ab16f9212238f29dd315654aa94f6)): text data bsstotal kernel +2349 +400+2389 omap1_defconfig +2313 +400+2353 omap1_defconfig_1510innovator_only +2317 +160+2333 omap1_defconfig_5912osk_only +5734 +240+5758 omap2plus_defconfig +1414 +240+1438 omap2plus_defconfig_2430sdp_only +163800+1638 omap2plus_defconfig_cpupm +63800 +638 omap2plus_defconfig_n800_multi_omap2xxx +60600 +606 omap2plus_defconfig_n800_only_a +1638 -80+1630 omap2plus_defconfig_no_pm +163800+1638 omap2plus_defconfig_omap2_4_only +1638 -80+1630 omap2plus_defconfig_omap3_4_only +13360 -112+1224 rmk_omap3430_ldp_allnoconfig +99400 +994 rmk_omap3430_ldp_oldconfig +12880 -96+1192 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.12-rc3 (15c03dd4859ab16f9212238f29dd315654aa94f6)) avail rsrvd high freed board kconfig -8k 8k . . 2430sdpomap2plus_defconfig -8k 8k . . 3517evmomap2plus_defconfig -8k 8k . . 3530es3beagle omap2plus_defconfig -8k 8k . . 3730beaglexm omap2plus_defconfig -8k 8k . . 37xxevmomap2plus_defconfig -8k 8k . . 4430es2panda omap2plus_defconfig -8k 8k . . 4460pandaesomap2plus_defconfig -8k 8k . . 4460varsomom omap2plus_defconfig -8k 8k . . am335xbonelt omap2plus_defconfig_am33xx_only -- 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: OMAP5: id: Remove ES1.0 support
On Tuesday 08 October 2013 05:31 PM, Tony Lindgren wrote: > * Santosh Shilimkar [130918 07:15]: >> On Wednesday 18 September 2013 10:05 AM, Nishanth Menon wrote: >>> OMAP5 ES1.0 was intended as a test chip and has major register level >>> differences w.r.t ES2.0 revision of the chip. All register defines, >>> dts support has been solely added for ES2.0 version of the chip. >>> Further, all ES1.0 chips and platforms are supposed to have been >>> removed from circulation. Hence, there is no need to further retain >>> any resemblence of ES1.0 support in id detection code. >>> >>> Remove the omap_revision handling and BUG() instead to prevent folks >>> who mistakenly try an older unsupported chip and report bogus errors. >>> >>> Cc: Santosh Shilimkar >>> Signed-off-by: Nishanth Menon >>> --- >>> ref: http://marc.info/?l=linux-omap&m=137951198232339&w=2 >>> based on 3.12-rc1 tag >>> >> That was quick ... >> Acked-by: Santosh Shilimkar > > Heh, it was made, but not supposed to be used, and still merged > to mainline kernel.. > You know the history. At least for this silicon we avoided tons of datafiles merges for ES1.0 which changed completely for ES2.0. At least during that period people had choice to merge the data-files based on the board they have to test out ;-) > I guess this is the way to deal with this issue as we don't have > really any omap5 es1 support in place. So applying into > omap-for-v3.13/soc branch. > Thanks !! Regards, Santosh -- 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: OMAP5: id: Remove ES1.0 support
* Santosh Shilimkar [130918 07:15]: > On Wednesday 18 September 2013 10:05 AM, Nishanth Menon wrote: > > OMAP5 ES1.0 was intended as a test chip and has major register level > > differences w.r.t ES2.0 revision of the chip. All register defines, > > dts support has been solely added for ES2.0 version of the chip. > > Further, all ES1.0 chips and platforms are supposed to have been > > removed from circulation. Hence, there is no need to further retain > > any resemblence of ES1.0 support in id detection code. > > > > Remove the omap_revision handling and BUG() instead to prevent folks > > who mistakenly try an older unsupported chip and report bogus errors. > > > > Cc: Santosh Shilimkar > > Signed-off-by: Nishanth Menon > > --- > > ref: http://marc.info/?l=linux-omap&m=137951198232339&w=2 > > based on 3.12-rc1 tag > > > That was quick ... > Acked-by: Santosh Shilimkar Heh, it was made, but not supposed to be used, and still merged to mainline kernel.. I guess this is the way to deal with this issue as we don't have really any omap5 es1 support in place. So applying into omap-for-v3.13/soc branch. 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: DRA7: realtime_counter: Add ratio registers for 20MHZ sys-clk frequency
* Santosh Shilimkar [130918 06:32]: > On Wednesday 18 September 2013 07:20 AM, Sricharan R wrote: > > The real time counter also called master counter, is a free-running > > counter. It produces the count used by the CPU local timer peripherals > > in the MPU cluster. The timer counts at a rate of 6.144 MHz. > > > > The ratio registers are missing for a sys-clk of 20MHZ which is used > > by DRA7 socs. So because of this, the counter was getting wrongly > > programmed for a sys-clk of 38.4Mhz(default). So adding the ratio > > registers for 20MHZ sys-clk. > > > > Cc: Santosh Shilimkar > > Signed-off-by: Sricharan R > > --- > Acked-by: Santosh Shilimkar Applying into omap-for-v3.13/soc thanks. 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+: wakeupgen: AM43x adaptation
Hi,
Few minor comments below.
* Afzal Mohammed [130905 04:03]:
> AM43x has 224 interrupts and 7 banks, make it as maximum values. Keep
> default values as earlier, if am43x is detected, update interrupts and
> banks to maximum.
>
> Also AM43x has only one cpu, ensure that clearing bitmask at wakeupgen
> is done only for the single existing cpu, existing code assumes that
> there are two cpu's.
>
> If bitmask is cleared in wakeupgen for the nonexistent second cpu,
> an imprecise abort happens as soon as Kernel switches to user space.
> It was rootcaused by Sekhar Nori .
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/omap-wakeupgen.c | 18 +-
> 1 file changed, 13 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-wakeupgen.c
> b/arch/arm/mach-omap2/omap-wakeupgen.c
> index 813c615..899d4946 100644
> --- a/arch/arm/mach-omap2/omap-wakeupgen.c
> +++ b/arch/arm/mach-omap2/omap-wakeupgen.c
> @@ -33,8 +33,11 @@
> #include "omap4-sar-layout.h"
> #include "common.h"
>
> -#define MAX_NR_REG_BANKS 5
> -#define MAX_IRQS 160
> +/* maximum value correspond to that of AM43x */
> +#define MAX_NR_REG_BANKS 7
> +#define MAX_IRQS 224
> +#define DEFAULT_NR_REG_BANKS 5
> +#define DEFAULT_IRQS 160
> #define WKG_MASK_ALL 0x
> #define WKG_UNMASK_ALL 0x
> #define CPU_ENA_OFFSET 0x400
How about define it like this to avoid updating things
in multiple places for new SoCs:
#define AM43X_NR_REG_BANKS 7
#define MAX_NR_REG_BANKSAM43X_NR_REG_BANKS
...
> @@ -402,6 +405,7 @@ int __init omap_wakeupgen_init(void)
> {
> int i;
> unsigned int boot_cpu = smp_processor_id();
> + bool am43x = soc_is_am43xx() ? true : false;
>
> /* Not supported on OMAP4 ES1.0 silicon */
> if (omap_rev() == OMAP4430_REV_ES1_0) {
> @@ -418,12 +422,16 @@ int __init omap_wakeupgen_init(void)
> irq_banks = OMAP4_NR_BANKS;
> max_irqs = OMAP4_NR_IRQS;
> omap_secure_apis = 1;
> + } else if (am43x) {
> + irq_banks = MAX_NR_REG_BANKS;
> + max_irqs = MAX_IRQS;
> }
Then here you can have:
irq_bankse = AM43X_NR_REG_BANKS
...
> /* Clear all IRQ bitmasks at wakeupGen level */
> for (i = 0; i < irq_banks; i++) {
> wakeupgen_writel(0, i, CPU0_ID);
> - wakeupgen_writel(0, i, CPU1_ID);
> + if (!am43x)
> + wakeupgen_writel(0, i, CPU1_ID);
> }
Why not use soc_is_am43xx() directly here?
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 1/1] ARM: OMAP2+: pdata-quirks: add legacy display init for IGEPv2 board
* Javier Martinez Canillas [131004 20:00]: > IGEPv2 board has both an DVI and TFP410 video interfaces but > DSS support for DeviceTree has not yet landed in mainline so > is necessary to init the displays using legacy platform code. Thanks, applying into omap-for-v3.13/quirk. 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 v2 0/4] arm: omap: display: Ensure DRM/FB/V4L devices are created if DSS is available
* Tomi Valkeinen [130916 01:57]: > On 16/09/13 10:18, Archit Taneja wrote: > > Currently, omapdrm, omapfb and omap_vout platform devices are created and > > registered through omap_arch_initcalls. In a multiplatform config. It's > > possible that all the corresponding configs for the above drivers along with > > omapdss config are selected even if the hardware doesn't have a DSS IP. > > > > If the image is booted on a AM33xx platform, the above drm, fb and v4l > > devices > > would be registered throuth the omap_arch_initcalls even if omapdss itself > > isn't > > registered. These platform devices don't cause any harm, but are > > unnecessary. > > > > Move the registration of these devices into omap_display_init(), which > > registers > > omapdss devices and is called only if the platform has DSS hardware. > > > > Also, the first patch prevents creation of a DMM device when omapdrm device > > is > > registered. With the removal of address and irq data from the omap4 hwmods, > > the > > probe of DMM driver fails and omapdrm isn't able to utilize the DMM > > hardware. > > This will be fixed when DMM DT nodes are added for omap4, omap5 and dra7x. > > > > Changes in v2: > > - Move device creation for omapfb and omap_vout to omap_display_init too. > > - Keep the DMM DT conversion as a separate patch series since this series > > does > > something different now. > > > > Archit Taneja (4): > > arm: omap: drm: Don't build device for DMM > > arm: omap: display: Create omapdrm device inside omap_display_init > > arm: omap: display: Create omapvrfb and omapfb devices inside > > omap_display_init > > arm: omap: display: Create omap_vout device inside omap_display_init > > > > arch/arm/mach-omap2/Makefile | 6 +- > > arch/arm/mach-omap2/devices.c | 10 +- > > arch/arm/mach-omap2/display.c | 28 > > arch/arm/mach-omap2/display.h | 4 > > arch/arm/mach-omap2/drm.c | 24 +--- > > arch/arm/mach-omap2/fb.c | 14 +++--- > > 6 files changed, 50 insertions(+), 36 deletions(-) > > Acked-by: Tomi Valkeinen > > Tony, since there are no driver changes here, and it's unlikely that > we'd have a conflict between the dss driver changes and these changes, I > think it's best if this goes through linux-omap. OK applying into omap-for-v3.13/display, thanks. 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
[PATCH v4 10/10] ARM/dts: am335x-evmsk: Audio support
From: Peter Ujfalusi
AM335x EVM-SK have only support for audio playback (stereo jack on the
board) via tlv320aic3106 codec connected to McASP1.
Enable the support for audio playback on the board:
- McASP1 configuration
- tlv320aic3106 configuration
- Machine driver.
Signed-off-by: Peter Ujfalusi
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-evmsk.dts | 51
1 file changed, 51 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evmsk.dts
b/arch/arm/boot/dts/am335x-evmsk.dts
index 4f339fa..27aa42f 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -158,6 +158,15 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+ mcasp1_pins: mcasp1_pins {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_crs.mcasp1_aclkx */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_rxerr.mcasp1_fsx */
+ 0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /*
mii1_col.mcasp1_axr2 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
+ >;
+ };
};
ocp {
@@ -206,6 +215,18 @@
st,max-limit-y = <550>;
st,max-limit-z = <750>;
};
+
+ tlv320aic3106: tlv320aic3106@1b {
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status = "okay";
+
+ /* Regulators */
+ AVDD-supply = <&vaux2_reg>;
+ IOVDD-supply = <&vaux2_reg>;
+ DRVDD-supply = <&vaux2_reg>;
+ DVDD-supply = <&vbat>;
+ };
};
musb: usb@4740 {
@@ -233,6 +254,17 @@
pinctrl-0 = <&ecap2_pins>;
};
};
+
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM335x-EVMSK";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp1>;
+ ti,codec-clock-rate = <24576000>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT";
+ };
};
vbat: fixedregulator@0 {
@@ -419,3 +451,22 @@
phy_id = <&davinci_mdio>, <1>;
phy-mode = "rgmii-txid";
};
+
+&mcasp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp1_pins>;
+
+ status = "okay";
+
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ /* 16 serializer */
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <1>;
+ rx-num-evt = <1>;
+};
--
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
[PATCH v4 04/10] ASoC: davinci-mcasp: Extract DMA channels directly from DT
Extract DMA channels directly from DT as they can not be found from
platform resources anymore. This is a work-around until davinci audio
driver is updated to use dmaengine.
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-mcasp-audio.txt |5 +++
include/linux/platform_data/davinci_asp.h |2 +
sound/soc/davinci/davinci-mcasp.c | 45 ++--
3 files changed, 38 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index c2ab869..c3ccde7 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -18,6 +18,11 @@ Required properties:
- serial-dir : A list of serializer pin mode. The list number should be equal
to "num-serializer" parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
+- dmas: two element list of DMA controller phandles and DMA request line
+ordered pairs.
+- dma-names: identifier string for each DMA request line in the dmas property.
+These strings correspond 1:1 with the ordered pairs in dmas. The
dma
+identifiers must be "rx" and "tx".
Optional properties:
diff --git a/include/linux/platform_data/davinci_asp.h
b/include/linux/platform_data/davinci_asp.h
index 8db5ae0..689a856 100644
--- a/include/linux/platform_data/davinci_asp.h
+++ b/include/linux/platform_data/davinci_asp.h
@@ -84,6 +84,8 @@ struct snd_platform_data {
u8 version;
u8 txnumevt;
u8 rxnumevt;
+ int tx_dma_channel;
+ int rx_dma_channel;
};
enum {
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 7fd37ff..2583802 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1047,6 +1047,7 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
struct snd_platform_data *pdata = NULL;
const struct of_device_id *match =
of_match_device(mcasp_dt_ids, &pdev->dev);
+ struct of_phandle_args dma_spec;
const u32 *of_serial_dir32;
u8 *of_serial_dir;
@@ -1109,6 +1110,28 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
pdata->serial_dir = of_serial_dir;
}
+ ret = of_property_match_string(np, "dma-names", "tx");
+ if (ret < 0)
+ goto nodata;
+
+ ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", ret,
+&dma_spec);
+ if (ret < 0)
+ goto nodata;
+
+ pdata->tx_dma_channel = dma_spec.args[0];
+
+ ret = of_property_match_string(np, "dma-names", "rx");
+ if (ret < 0)
+ goto nodata;
+
+ ret = of_parse_phandle_with_args(np, "dmas", "#dma-cells", ret,
+&dma_spec);
+ if (ret < 0)
+ goto nodata;
+
+ pdata->rx_dma_channel = dma_spec.args[0];
+
ret = of_property_read_u32(np, "tx-num-evt", &val);
if (ret >= 0)
pdata->txnumevt = val;
@@ -1213,15 +1236,11 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_data->sram_size = pdata->sram_size_playback;
dma_data->dma_addr = dat->start + pdata->tx_dma_offset;
- /* first TX, then RX */
res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!res) {
- dev_err(&pdev->dev, "no DMA resource\n");
- ret = -ENODEV;
- goto err_release_clk;
- }
-
- dma_data->channel = res->start;
+ if (res)
+ dma_data->channel = res->start;
+ else
+ dma_data->channel = pdata->tx_dma_channel;
dma_data = &dev->dma_params[SNDRV_PCM_STREAM_CAPTURE];
dma_data->asp_chan_q = pdata->asp_chan_q;
@@ -1231,13 +1250,11 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
dma_data->dma_addr = dat->start + pdata->rx_dma_offset;
res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
- if (!res) {
- dev_err(&pdev->dev, "no DMA resource\n");
- ret = -ENODEV;
- goto err_release_clk;
- }
+ if (res)
+ dma_data->channel = res->start;
+ else
+ dma_data->channel = pdata->rx_dma_channel;
- dma_data->channel = res->start;
dev_set_drvdata(&pdev->dev, dev);
ret = snd_soc_register_component(&pdev->dev, &davinci_mcasp_component,
&davinci_mcasp_dai[pdata->op_mode], 1);
--
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
[PATCH v4 02/10] ASoC: davinci-evm: Add device tree binding
From: "Hebbar, Gururaja"
Device tree support for Davinci Machine driver
When the board boots with device tree, the driver will receive card,
codec, dai interface details (like the card name, DAPM routing map,
phandle for the audio components described in the dts file, codec mclk
speed). The card will be set up based on this information. Since the
routing is provided via DT we can mark the card fully routed so core
can take care of disconnecting the unused pins.
Signed-off-by: Hebbar, Gururaja
Signed-off-by: Darren Etheridge
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-evm-audio.txt | 58 ++
sound/soc/davinci/davinci-evm.c| 120 +++-
2 files changed, 176 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
new file mode 100644
index 000..e6b61ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -0,0 +1,58 @@
+* Texas Instruments SoC audio setups with TLV320AIC3X Codec
+
+Required properties:
+- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- ti,model : The user-visible name of this sound complex.
+- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
+- ti,mcasp-controller : The phandle of the McASP controller
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
+- ti,audio-routing : A list of the connections between audio components.
+ Each entry is a pair of strings, the first being the connection's sink,
+ the second being the connection's source. Valid names for sources and
+ sinks are the codec's pins, and the jacks on the board:
+
+ TLV320AIC3X pins:
+
+ * LLOUT
+ * RLOUT
+ * MONO_LOUT
+ * HPLOUT
+ * HPROUT
+ * HPLCOM
+ * HPRCOM
+ * MIC3L
+ * MIC3R
+ * LINE1L
+ * LINE2L
+ * LINE1R
+ * LINE2R
+
+ Board connectors:
+
+ * Headphone Jack
+ * Line Out
+ * Mic Jack
+ * Line In
+
+
+Example:
+
+sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "DA830 EVM";
+ ti,audio-codec = <&tlv320aic3x>;
+ ti,mcasp-controller = <&mcasp1>;
+ ti,codec-clock-rate = <1200>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "Line Out", "LLOUT",
+ "Line Out", "RLOUT",
+ "MIC3L","Mic Bias 2V",
+ "MIC3R","Mic Bias 2V",
+ "Mic Bias 2V", "Mic Jack",
+ "LINE1L", "Line In",
+ "LINE2L", "Line In",
+ "LINE1R", "Line In",
+ "LINE2R", "Line In";
+};
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 2f8161c..340a68d 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,8 @@
#include
#include
+#include
+
#include "davinci-pcm.h"
#include "davinci-i2s.h"
#include "davinci-mcasp.h"
@@ -121,13 +124,22 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
{
struct snd_soc_codec *codec = rtd->codec;
struct snd_soc_dapm_context *dapm = &codec->dapm;
+ struct device_node *np = codec->card->dev->of_node;
+ int ret;
/* Add davinci-evm specific widgets */
snd_soc_dapm_new_controls(dapm, aic3x_dapm_widgets,
ARRAY_SIZE(aic3x_dapm_widgets));
- /* Set up davinci-evm specific audio path audio_map */
- snd_soc_dapm_add_routes(dapm, audio_map, ARRAY_SIZE(audio_map));
+ if (np) {
+ ret = snd_soc_of_parse_audio_routing(codec->card,
+ "ti,audio-routing");
+ if (ret)
+ return ret;
+ } else {
+ /* Set up davinci-evm specific audio path audio_map */
+ snd_soc_dapm_add_routes(dapm, audio_map, ARRAY_SIZE(audio_map));
+ }
/* not connected */
snd_soc_dapm_disable_pin(dapm, "MONO_LOUT");
@@ -312,6 +324,98 @@ static struct snd_soc_card da850_snd_soc_card = {
.drvdata = &da850_snd_soc_card_drvdata,
};
+#if defined(CONFIG_OF)
+
+/*
+ * The struct is used as place holder. It will be completely
+ * filled with data from dt node.
+ */
+static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
+ .name = "TLV320AIC3X",
+ .stream_name= "AIC3X",
+ .codec_dai_name = "tlv320aic3x-hifi",
+ .ops= &evm_ops,
+ .init = evm_aic3x_init,
+};
+
+static const struct of_device_id davinci_evm_dt_ids[] = {
+ {
+
[PATCH v4 01/10] ASoC: davinci: Fix AM33xx SoC Audio support
SND_DAVINCI_SOC is a platform driver for Davinci and AM33XX SoCs, not a machine driver. Make SND_AM33XX_SOC_EVM dependent of SND_DAVINCI_SOC instead of selecting it and add dependecy to SOC_AM33XX. Signed-off-by: Jyri Sarha --- sound/soc/davinci/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/davinci/Kconfig b/sound/soc/davinci/Kconfig index 6c8e687..95970f5 100644 --- a/sound/soc/davinci/Kconfig +++ b/sound/soc/davinci/Kconfig @@ -2,7 +2,7 @@ config SND_DAVINCI_SOC tristate "SoC Audio for the TI DAVINCI or AM33XX chip" depends on ARCH_DAVINCI || SOC_AM33XX help - Machine driver for DAVINCI audio. + Platform driver for daVinci or AM33xx Say Y or M if you want to add support for codecs attached to the DAVINCI AC97, I2S, or McASP interface. You will also need to select the audio interfaces to support below. @@ -18,7 +18,7 @@ config SND_DAVINCI_SOC_VCIF config SND_AM33XX_SOC_EVM tristate "SoC Audio for the AM33XX chip based boards" - select SND_DAVINCI_SOC + depends on SND_DAVINCI_SOC && SOC_AM33XX select SND_SOC_TLV320AIC3X select SND_DAVINCI_SOC_MCASP help -- 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
[PATCH v4 08/10] ARM/dts: am33xx: mcasp: Add location for data port registers to reg-property
This patch adds a second tuple to reg property. The new property tuple
describes the memory location for data port registers mapped trough
L3 bus on am33xx. The both property tuples are named accordingly in
the reg-names property.
Signed-off-by: Hebbar, Gururaja
Signed-off-by: Darren Etheridge
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am33xx.dtsi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 22659e7..c8ba19e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -671,7 +671,9 @@
mcasp0: mcasp@48038000 {
compatible = "ti,omap2-mcasp-audio";
ti,hwmods = "mcasp0";
- reg = <0x48038000 0x2000>;
+ reg = <0x48038000 0x2000>,
+ <0x4640 0x40>;
+ reg-names = "mpu", "dat";
interrupts = <80>, <81>;
interrupts-names = "tx", "rx";
status = "disabled";
@@ -683,7 +685,9 @@
mcasp1: mcasp@4803C000 {
compatible = "ti,omap2-mcasp-audio";
ti,hwmods = "mcasp1";
- reg = <0x4803C000 0x2000>;
+ reg = <0x4803C000 0x2000>,
+ <0x4640 0x40>;
+ reg-names = "mpu", "dat";
interrupts = <82>, <83>;
interrupts-names = "tx", "rx";
status = "disabled";
--
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
[PATCH v4 00/10] Fix AM335x-evm analog audio support
The v3 version of patches can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066728.html The v2 version of patches can be found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066379.html The RFC version of patches can been found here: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066178.html Changes since v3 - Rebased on top of v3.12-rc4 - Drop already applied patches: - [PATCH v2 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params - [PATCH v2 06/11] ASoC: davinci: Add support for AM33xx SoC Audio - [PATCH v2 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document - [PATCH v2 08/11] ASoC: tlv320aic3x: Add codec pins to DT bindings document - Add: ASoC: davinci: Fix AM33xx SoC Audio support - Contains the fixes from Peter: http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066448.html - Contents of this patch were squashed to "[PATCH v3 06/11] ASoC: davinci: Add support for AM33xx SoC Audio", but since the patch v2 was already applied the changes are here as a separate patch. - Add: ASoC: davinci-mcasp: Remove redundant num-serializer DT parameter - Change: ASoC: davinci-mcasp: Add DMA register locations to DT to: ASoC: davinci-mcasp: Add location for data port registers to DT - Use more accurate name for data port register location - Improve commit message - Change: ASoC: davinci-mcasp: Interrupts property to optional and add interrupt-names to: ASoC: davinci-mcasp: Improve DT bindings document - Remove #address-cells and #size-cells - Bracket named interrupts tuples - Add missing "for" to serial-dir description - Improve tdm-slots description - Improve op-mode description - Add pinctrl-names and pinctrl-0 descriptions - Change: ARM/dts: am335x-evm: Add audio support for am335x-evm.dts - Use board specific name 'AM335x-EVM' for the soundcard. - Use the board specific tlv320aic3106 codec. Use this name instead of generic tlv320aic3x. - Remove num-serializer property from mcasp node - Remove blank lines - Change: ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries - Bracket all named property tuples - Add: ARM/dts: am335x-evmsk: Audio support - The other patches in the set not mentioned here are identical to their earlier version Changes since v2 [PATCH v2 01/11] ASoC: davinci-evm: Move sysclk logic away from evm_hw_params - no change [PATCH v2 02/11] ASoC: davinci-evm: Add device tree binding - no change [PATCH v2 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT - no change [PATCH v2 04/11] ASoC: davinci-mcasp: Extract DMA channels directly from DT - no change [PATCH v2 05/11] ASoC: davinci-mcasp: Remove interrupt property from DT bindin - restore binding but make it optional and add interrupt-names property [PATCH v2 06/11] ASoC: davinci: Add support for AM33xx SoC Audio - SND_DAVINCI_SOC help "Machine driver for ..." -> "Platform driver for ..." - SND_AM33XX_SOC_EVM depends on SND_DAVINCI_SOC && SOC_AM33XX - SND_AM33XX_SOC_EVM does not selcet SND_DAVINCI_SOC [PATCH v2 07/11] ASoC: tlv320aic3x: Add regulators to DT bindings document - no change [PATCH v2 08/11] ASoC: tlv320aic3x: Add codec pins to DT bindings document - no change [PATCH v2 09/11] ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries - restore interrupt property and add interrupt-names property [PATCH v2 10/11] ARM/dts: am33xx: mcasp: Add new dma register location to reg-property - no change [PATCH v2 11/11] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts - no change Changes from RFC to v2 - Dropped out "ASoC: davinci-mcasp: Add pinctrl support" since driver core is taking care of this now. - Cleanup am33xx audio build - Add regulators to tlv320aic3x DT binding document - Remove dm365-voice-codec-audio DT support as it has never been tested an probably does not work - Add output pins and Line In connector to davinci-evm-audio DT binding doc - Remove asp_chan_q and ram_chan_q properties from mcasp DT node in DT mode mcasp is hardcoded to event queue 0 (highest priority) - Add pins to tlv320aic3x DT bindings document. If I misunderstood Marks comment and this patch is not needed, then just leave it out Changes based on TI internal discussions - Move system clock rate logic away from from evm_hw_params soc-op - Remove unnecesary #if defined(CONFIG_OF) from davinci-evm.c - Make dma property DT binding document more exact - Add only "dma" reg location instead of separate "dma-tx" and "dma-rx" - Primarily look for "mpu" reg property, but fall back to index 0 if not found - Remove interrupt property from mcasp DT node as it is not used - Remove #address-cells and #size-cells mcasp properties as they are not needed The patch set depends on following patches: [PATC
[PATCH v4 03/10] ASoC: davinci-mcasp: Add location for data port registers to DT
This patch adds a separate register location for data port registers to
mcasp DT bindings. On am33xx SoCs the McASP registers are mapped
trough L4 interconnect, but data port registers are also mapped trough
L3 bus to a different memory location.
Signed-off-by: Hebbar, Gururaja
Signed-off-by: Darren Etheridge
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-mcasp-audio.txt |8 ++-
sound/soc/davinci/davinci-mcasp.c | 61 +---
2 files changed, 47 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 374e145..c2ab869 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -6,7 +6,11 @@ Required properties:
"ti,da830-mcasp-audio" : for both DA830 & DA850 platforms
"ti,omap2-mcasp-audio" : for OMAP2 platforms (TI81xx, AM33xx)
-- reg : Should contain McASP registers offset and length
+- reg : Should contain reg specifiers for the entries in the reg-names
property.
+- reg-names : Should contain:
+ * "mpu" for the main registers (required). For compatibility with
+ existing software, it is recommended this is the first entry.
+ * "dat" for separate data port register access (optional).
- interrupts : Interrupt number for McASP
- op-mode : I2S/DIT ops mode.
- tdm-slots : Slots for TDM operation.
@@ -15,7 +19,6 @@ Required properties:
to "num-serializer" parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
-
Optional properties:
- ti,hwmods : Must be "mcasp", n is controller instance starting 0
@@ -31,6 +34,7 @@ mcasp0: mcasp0@1d0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x10 0x3000>;
+ reg-names "mpu";
interrupts = <82 83>;
op-mode = <0>; /* MCASP_IIS_MODE */
tdm-slots = <2>;
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 32ddb7f..7fd37ff 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1001,18 +1001,40 @@ static const struct snd_soc_component_driver
davinci_mcasp_component = {
.name = "davinci-mcasp",
};
+/* Some HW specific values and defaults. The rest is filled in from DT. */
+static struct snd_platform_data dm646x_mcasp_pdata = {
+ .tx_dma_offset = 0x400,
+ .rx_dma_offset = 0x400,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_1,
+};
+
+static struct snd_platform_data da830_mcasp_pdata = {
+ .tx_dma_offset = 0x2000,
+ .rx_dma_offset = 0x2000,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_2,
+};
+
+static struct snd_platform_data omap2_mcasp_pdata = {
+ .tx_dma_offset = 0,
+ .rx_dma_offset = 0,
+ .asp_chan_q = EVENTQ_0,
+ .version = MCASP_VERSION_3,
+};
+
static const struct of_device_id mcasp_dt_ids[] = {
{
.compatible = "ti,dm646x-mcasp-audio",
- .data = (void *)MCASP_VERSION_1,
+ .data = &dm646x_mcasp_pdata,
},
{
.compatible = "ti,da830-mcasp-audio",
- .data = (void *)MCASP_VERSION_2,
+ .data = &da830_mcasp_pdata,
},
{
.compatible = "ti,omap2-mcasp-audio",
- .data = (void *)MCASP_VERSION_3,
+ .data = &omap2_mcasp_pdata,
},
{ /* sentinel */ }
};
@@ -1035,20 +1057,13 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
pdata = pdev->dev.platform_data;
return pdata;
} else if (match) {
- pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
- if (!pdata) {
- ret = -ENOMEM;
- goto nodata;
- }
+ pdata = (struct snd_platform_data *) match->data;
} else {
/* control shouldn't reach here. something is wrong */
ret = -EINVAL;
goto nodata;
}
- if (match->data)
- pdata->version = (u8)((int)match->data);
-
ret = of_property_read_u32(np, "op-mode", &val);
if (ret >= 0)
pdata->op_mode = val;
@@ -1124,7 +1139,7 @@ nodata:
static int davinci_mcasp_probe(struct platform_device *pdev)
{
struct davinci_pcm_dma_params *dma_data;
- struct resource *mem, *ioarea, *res;
+ struct resource *mem, *ioarea, *res, *dat;
struct snd_platform_data *pdata;
struct davinci_audio_dev *dev;
int ret;
@@ -1145,10 +1160,15 @@ static int davinci_mcasp_probe(struct platform_device
*pdev)
return -EINVAL;
}
- mem = platform_get_reso
[PATCH v4 07/10] ARM/dts: am33xx: Add mcasp0 and mcasp1 device tree entries
From: Pantelis Antoniou
Add missing mcasp entries in the am33xx.dtsi include file.
Signed-off-by: Pantelis Antoniou
Signed-off-by: Darren Etheridge
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am33xx.dtsi | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 9ce85e5..22659e7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -667,5 +667,30 @@
#size-cells = <1>;
status = "disabled";
};
+
+ mcasp0: mcasp@48038000 {
+ compatible = "ti,omap2-mcasp-audio";
+ ti,hwmods = "mcasp0";
+ reg = <0x48038000 0x2000>;
+ interrupts = <80>, <81>;
+ interrupts-names = "tx", "rx";
+ status = "disabled";
+ dmas = <&edma 8>,
+ <&edma 9>;
+ dma-names = "tx", "rx";
+ };
+
+ mcasp1: mcasp@4803C000 {
+ compatible = "ti,omap2-mcasp-audio";
+ ti,hwmods = "mcasp1";
+ reg = <0x4803C000 0x2000>;
+ interrupts = <82>, <83>;
+ interrupts-names = "tx", "rx";
+ status = "disabled";
+ dmas = <&edma 10>,
+ <&edma 11>;
+ dma-names = "tx", "rx";
+ };
+
};
};
--
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
[PATCH v4 06/10] ASoC: davinci-mcasp: Remove redundant num-serializer DT parameter
From: Peter Ujfalusi
The serial-dir array gives this information so there is no need to have the
num-serializer property in DT description.
Just ignore the property in the driver the DTS files can be updated
separately without regression.
Update the documentation at the same time for davinci-mcasp
Signed-off-by: Peter Ujfalusi
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-mcasp-audio.txt |1 -
sound/soc/davinci/davinci-mcasp.c | 22 +---
2 files changed, 5 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index ab2af66..b350cd9 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -49,7 +49,6 @@ mcasp0: mcasp0@1d0 {
interrupts-names = "tx", "rx";
op-mode = <0>; /* MCASP_IIS_MODE */
tdm-slots = <2>;
- num-serializer = <16>;
serial-dir = <
0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */
0 0 0 0
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index 2583802..03a1199 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -1050,7 +1050,6 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
struct of_phandle_args dma_spec;
const u32 *of_serial_dir32;
- u8 *of_serial_dir;
u32 val;
int i, ret = 0;
@@ -1081,32 +1080,21 @@ static struct snd_platform_data
*davinci_mcasp_set_pdata_from_of(
pdata->tdm_slots = val;
}
- ret = of_property_read_u32(np, "num-serializer", &val);
- if (ret >= 0)
- pdata->num_serializer = val;
-
of_serial_dir32 = of_get_property(np, "serial-dir", &val);
val /= sizeof(u32);
- if (val != pdata->num_serializer) {
- dev_err(&pdev->dev,
- "num-serializer(%d) != serial-dir size(%d)\n",
- pdata->num_serializer, val);
- ret = -EINVAL;
- goto nodata;
- }
-
if (of_serial_dir32) {
- of_serial_dir = devm_kzalloc(&pdev->dev,
- (sizeof(*of_serial_dir) * val),
- GFP_KERNEL);
+ u8 *of_serial_dir = devm_kzalloc(&pdev->dev,
+(sizeof(*of_serial_dir) * val),
+GFP_KERNEL);
if (!of_serial_dir) {
ret = -ENOMEM;
goto nodata;
}
- for (i = 0; i < pdata->num_serializer; i++)
+ for (i = 0; i < val; i++)
of_serial_dir[i] = be32_to_cpup(&of_serial_dir32[i]);
+ pdata->num_serializer = val;
pdata->serial_dir = of_serial_dir;
}
--
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
[PATCH v4 09/10] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts
From: Darren Etheridge
Adds sound, tlv320aic3106, mcasp1, and am335x_evm_audio_pin nodes.
Signed-off-by: Darren Etheridge
Signed-off-by: Peter Ujfalusi
Signed-off-by: Jyri Sarha
---
arch/arm/boot/dts/am335x-evm.dts | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e8ec875..1fbae4c 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -149,6 +149,16 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
>;
};
+
+ am335x_evm_audio_pins: am335x_evm_audio_pins {
+ pinctrl-single,pins = <
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_rx_dv.mcasp1_aclkx */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_txd3.mcasp1_fsx */
+ 0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /*
mii1_col.mcasp1_axr2 */
+ 0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
+ >;
+ };
+
};
ocp {
@@ -244,6 +254,18 @@
compatible = "ti,tmp275";
reg = <0x48>;
};
+
+ tlv320aic3106: tlv320aic3106@1b {
+ compatible = "ti,tlv320aic3106";
+ reg = <0x1b>;
+ status = "okay";
+
+ /* Regulators */
+ AVDD-supply = <&vaux2_reg>;
+ IOVDD-supply = <&vaux2_reg>;
+ DRVDD-supply = <&vaux2_reg>;
+ DVDD-supply = <&vbat>;
+ };
};
elm: elm@4808 {
@@ -340,6 +362,19 @@
};
};
};
+
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM335x-EVM";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp1>;
+ ti,codec-clock-rate = <1200>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "LINE1L", "Line In",
+ "LINE1R", "Line In";
+ };
};
vbat: fixedregulator@0 {
@@ -407,6 +442,25 @@
#include "tps65910.dtsi"
+&mcasp1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&am335x_evm_audio_pins>;
+
+ status = "okay";
+
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ /* 16 serializer */
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <1>;
+ rx-num-evt = <1>;
+};
+
&tps {
vcc1-supply = <&vbat>;
vcc2-supply = <&vbat>;
--
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
[PATCH v4 05/10] ASoC: davinci-mcasp: Improve DT bindings document
Makes interrupts property optional as the interrupts are not currently
used by the driver and adds interrupt-names property to name listed
interrupts. Currently know interrupt names are "tx" and "rx".
- Improve tdm-slots propery description
- Improve op-mode property description
- Add pinctrl-names and pinctrl-0 properties
- Remove #address-cells and #size-cells as they are not needed.
- Bracket named interrupts property tuples for uniformity.
- Add missing "for" to serial-dir prop in DT bindings doc.
Signed-off-by: Jyri Sarha
---
.../bindings/sound/davinci-mcasp-audio.txt | 24
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index c3ccde7..ab2af66 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -11,13 +11,14 @@ Required properties:
* "mpu" for the main registers (required). For compatibility with
existing software, it is recommended this is the first entry.
* "dat" for separate data port register access (optional).
-- interrupts : Interrupt number for McASP
-- op-mode : I2S/DIT ops mode.
-- tdm-slots : Slots for TDM operation.
+- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF,
+ IEC60958-1, and AES-3 formats.
+- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted
+ or received over one serializer.
- num-serializer : Serializers used by McASP.
-- serial-dir : A list of serializer pin mode. The list number should be equal
- to "num-serializer" parameter. Each entry is a number indication
- serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
+- serial-dir : A list of serializer configuration. Each entry is a number
+ indication for serializer pin direction.
+ (0 - INACTIVE, 1 - TX, 2 - RX)
- dmas: two element list of DMA controller phandles and DMA request line
ordered pairs.
- dma-names: identifier string for each DMA request line in the dmas property.
@@ -31,16 +32,21 @@ Optional properties:
- rx-num-evt : FIFO levels.
- sram-size-playback : size of sram to be allocated during playback
- sram-size-capture : size of sram to be allocated during capture
+- interrupts : Interrupt numbers for McASP, currently not used by the driver
+- interrupt-names : Known interrupt names are "tx" and "rx"
+- pinctrl-0: Should specify pin control group used for this controller.
+- pinctrl-names: Should contain only one value - "default", for more details
+please refer to pinctrl-bindings.txt
+
Example:
mcasp0: mcasp0@1d0 {
compatible = "ti,da830-mcasp-audio";
- #address-cells = <1>;
- #size-cells = <0>;
reg = <0x10 0x3000>;
reg-names "mpu";
- interrupts = <82 83>;
+ interrupts = <82>, <83>;
+ interrupts-names = "tx", "rx";
op-mode = <0>; /* MCASP_IIS_MODE */
tdm-slots = <2>;
num-serializer = <16>;
--
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: [PATCH v2 3/3] RX-51: Add support for OMAP3 ROM Random Number Generator
* Pali Rohár [130920 06:33]: > Adding this driver as platform device and only for RX-51 until somebody test > if > it working also on other OMAP3 HS devices and until there will be generic ARM > way to deal with SMC calls. Thanks I'll apply this with the patch #1 clock alias folded in into omap-for-v3.13/n900 branch. 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 v4 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
* Russell King - ARM Linux [131008 01:17]:
> On Tue, Oct 08, 2013 at 09:13:16AM +0200, Ben Dooks wrote:
> > On 08/09/13 09:43, Pali Rohár wrote:
> >> Here is new version (v4) of omap secure part patch:
> >>
> >> Other secure functions omap_smc1() and omap_smc2() calling instruction smc
> >> #0
> >> but Nokia RX-51 board needs to call smc #1 for PPA access.
> >>
> >> Signed-off-by: Ivaylo Dimitrov
> >> Signed-off-by: Pali Rohár
> >> ---
> >> diff --git a/arch/arm/mach-omap2/omap-secure.h
> >> b/arch/arm/mach-omap2/omap-secure.h
> >> index 0e72917..c4586f4 100644
> >> --- a/arch/arm/mach-omap2/omap-secure.h
> >> +++ b/arch/arm/mach-omap2/omap-secure.h
> >> @@ -51,6 +51,7 @@
> >> extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
> >>u32 arg1, u32 arg2, u32 arg3, u32 arg4);
> >> extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
> >> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
> >> extern phys_addr_t omap_secure_ram_mempool_base(void);
> >> extern int omap_secure_ram_reserve_memblock(void);
> >>
> >> diff --git a/arch/arm/mach-omap2/omap-smc.S
> >> b/arch/arm/mach-omap2/omap-smc.S
> >> index f6441c1..fd90125 100644
> >> --- a/arch/arm/mach-omap2/omap-smc.S
> >> +++ b/arch/arm/mach-omap2/omap-smc.S
> >> @@ -1,9 +1,11 @@
> >> /*
> >> - * OMAP44xx secure APIs file.
> >> + * OMAP34xx and OMAP44xx secure APIs file.
> >>*
> >>* Copyright (C) 2010 Texas Instruments, Inc.
> >>* Written by Santosh Shilimkar
> >>*
> >> + * Copyright (C) 2012 Ivaylo Dimitrov
> >> + * Copyright (C) 2013 Pali Rohár
> >>*
> >>* This program is free software,you can redistribute it and/or modify
> >>* it under the terms of the GNU General Public License version 2 as
> >> @@ -54,6 +56,23 @@ ENTRY(omap_smc2)
> >>ldmfd sp!, {r4-r12, pc}
> >> ENDPROC(omap_smc2)
> >>
> >> +/**
> >> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
> >> + * Low level common routine for secure HAL and PPA APIs via smc #1
> >> + * r0 - @service_id: Secure Service ID
> >> + * r1 - @process_id: Process ID
> >> + * r2 - @flag: Flag to indicate the criticality of operation
> >> + * r3 - @pargs: Physical address of parameter list
> >> + */
> >> +ENTRY(omap_smc3)
> >> + stmfd sp!, {r4-r11, lr}
> >> + mov r12, r0 @ Copy the secure service ID
> >
> > I think you should save r12 in the call.
>
> Not necessary.
Assuming there are no other comments I'll apply these into
omap-for-v3.13/n900 branch.
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 v2 2/3] hwrng: OMAP3 ROM Random Number Generator support
* Pali Rohár [130920 06:33]:
> This driver provides kernel-side support for the Random Number
> Generator hardware found on OMAP34xx processors.
>
> This driver comes from Maemo 2.6.28 kernel and was tested on Nokia RX-51.
> It is platform device because it needs board specific function for smc calls.
This one is should be merged via the hw_random patches seprately:
Acked-by: Tony Lindgren
> Signed-off-by: Pali Rohár
> Signed-off-by: Juha Yrjola
> ---
> drivers/char/hw_random/Kconfig | 13 +++
> drivers/char/hw_random/Makefile|1 +
> drivers/char/hw_random/omap3-rom-rng.c | 141
>
> 3 files changed, 155 insertions(+)
> create mode 100644 drivers/char/hw_random/omap3-rom-rng.c
>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 0aa9d91..0a331c3 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -165,6 +165,19 @@ config HW_RANDOM_OMAP
>
> If unsure, say Y.
>
> +config HW_RANDOM_OMAP3_ROM
> + tristate "OMAP3 ROM Random Number Generator support"
> + depends on HW_RANDOM && ARCH_OMAP3
> + default HW_RANDOM
> + ---help---
> + This driver provides kernel-side support for the Random Number
> + Generator hardware found on OMAP34xx processors.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called omap3-rom-rng.
> +
> + If unsure, say Y.
> +
> config HW_RANDOM_OCTEON
> tristate "Octeon Random Number Generator support"
> depends on HW_RANDOM && CAVIUM_OCTEON_SOC
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index bed467c..7c8aa80 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -15,6 +15,7 @@ n2-rng-y := n2-drv.o n2-asm.o
> obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
> obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
> obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
> +obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
> obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o
> obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o
> obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o
> diff --git a/drivers/char/hw_random/omap3-rom-rng.c
> b/drivers/char/hw_random/omap3-rom-rng.c
> new file mode 100644
> index 000..c853e9e
> --- /dev/null
> +++ b/drivers/char/hw_random/omap3-rom-rng.c
> @@ -0,0 +1,141 @@
> +/*
> + * omap3-rom-rng.c - RNG driver for TI OMAP3 CPU family
> + *
> + * Copyright (C) 2009 Nokia Corporation
> + * Author: Juha Yrjola
> + *
> + * Copyright (C) 2013 Pali Rohár
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RNG_RESET0x01
> +#define RNG_GEN_PRNG_HW_INIT 0x02
> +#define RNG_GEN_HW 0x08
> +
> +/* param1: ptr, param2: count, param3: flag */
> +static u32 (*omap3_rom_rng_call)(u32, u32, u32);
> +
> +static struct timer_list idle_timer;
> +static int rng_idle;
> +static struct clk *rng_clk;
> +
> +static void omap3_rom_rng_idle(unsigned long data)
> +{
> + int r;
> +
> + r = omap3_rom_rng_call(0, 0, RNG_RESET);
> + if (r != 0) {
> + pr_err("reset failed: %d\n", r);
> + return;
> + }
> + clk_disable_unprepare(rng_clk);
> + rng_idle = 1;
> +}
> +
> +static int omap3_rom_rng_get_random(void *buf, unsigned int count)
> +{
> + u32 r;
> + u32 ptr;
> +
> + del_timer_sync(&idle_timer);
> + if (rng_idle) {
> + clk_prepare_enable(rng_clk);
> + r = omap3_rom_rng_call(0, 0, RNG_GEN_PRNG_HW_INIT);
> + if (r != 0) {
> + clk_disable_unprepare(rng_clk);
> + pr_err("HW init failed: %d\n", r);
> + return -EIO;
> + }
> + rng_idle = 0;
> + }
> +
> + ptr = virt_to_phys(buf);
> + r = omap3_rom_rng_call(ptr, count, RNG_GEN_HW);
> + mod_timer(&idle_timer, jiffies + msecs_to_jiffies(500));
> + if (r != 0)
> + return -EINVAL;
> + return 0;
> +}
> +
> +static int omap3_rom_rng_data_present(struct hwrng *rng, int wait)
> +{
> + return 1;
> +}
> +
> +static int omap3_rom_rng_data_read(struct hwrng *rng, u32 *data)
> +{
> + int r;
> +
> + r = omap3_rom_rng_get_random(data, 4);
> + if (r < 0)
> + return r;
> + return 4;
> +}
> +
> +static struct hwrng omap3_rom_rng_ops = {
> + .name = "omap3-rom",
> + .data_present = omap3_rom_rng_data_present,
> + .data_read = omap3_rom_rng_data_read,
> +};
> +
> +static int omap3_rom_rng_probe(struct platform_device *pdev)
> +{
> + pr
Re: [PATCH v2 2/3] ARM: dts: add minimal DT support for Nokia N950 & N9 phones
* Aaro Koskinen [130924 12:36]: > Add minimal DT support for Nokia N950 & N9 phones. The same functionality > that is provided by the current board file should work: serial console, > USB, OneNAND and MMC. Assuming Benoit will pick this one up: 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 v2 3/3] ARM: OMAP2: delete board-rm680
* Aaro Koskinen [130924 12:36]: > Delete board file for Nokia RM-680/RM-696 (N950/N9). DT-based booting > should be used for further development on this HW. I'll apply this into omap-for-v3.13/board-removal that I will rebase on Benoit's .dts changes before I push out that branch. 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 0/2] OMAP4+: Get rid of internal SRAM handling
* Rajendra Nayak [130827 03:19]: > Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) > use drivers/misc/sram.c driver instead of the omap internal > implementation for SRAM handling. Sounds like this series has some dependencies that we need to clear, so marking this thread as read and assuming a new series will be posted. 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 v2] RX-51: Add missing max_current to rx51_lp5523_led_config
* joerg Reisenweber [130923 06:14]: > On Mon 23 September 2013 14:50:12 Pali Rohár wrote: > > Hi Tony, > > > > here is new version (v2) of patch which adding max_current values to rx51 > > board data. According to joerg safe value for max_current is 100 (10 mA). > > > > > > RX-51: Add missing max_current to rx51_lp5523_led_config > > > > File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs > > attribute if value is higher than max_current specified in board file. By > > default global C variables are zero, so changing always failed. This patch > > adding missing max_current and setting it to max safe value 100 (10 mA). ... > Reviewed and found logically and technically correct > Signed-off-by: Joerg Reisenweber Thanks, I'll apply this into omap-for-v3.12/fixes as it's a regression. 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 RFC 5/6] ARM: dts: AM335x: prcm node (for reset)
* Afzal Mohammed [130902 07:30]:
> Add AM335x prcm node with reset binding.
Please put the .dts changes into a separate series from
driver changes so the driver maintainers don't accidentally
queue also the .dts changes. This is to avoid pointless
self-inflicted merge conflicts.
Regards,
Tony
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/boot/dts/am33xx.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4701e3c..c2ccf94 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -530,6 +530,12 @@
> #size-cells = <1>;
> status = "disabled";
> };
> +
> + prcm: prcm@44e0 {
> + compatible = "ti,am3352-prcm";
> + reg = <0x44e0 0x1300>;
> + #reset-cells = <1>;
> + };
> };
>
> clocks {
> --
> 1.8.3.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 RFC 4/6] ARM: OMAP2+: AM43x/AM335x: have reset controller
* Afzal Mohammed [130902 07:27]: > AM43x, AM335x have reset block as part of prcm, let reset driver be > usable with these SoC's. Once the driver is ready, this can be merged along with the reset driver: Acked-by: Tony Lindgren > Signed-off-by: Afzal Mohammed > --- > arch/arm/mach-omap2/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig > index 3eed000..fa28d1d 100644 > --- a/arch/arm/mach-omap2/Kconfig > +++ b/arch/arm/mach-omap2/Kconfig > @@ -72,6 +72,7 @@ config SOC_AM33XX > select CPU_V7 > select MULTI_IRQ_HANDLER > select COMMON_CLK > + select ARCH_HAS_RESET_CONTROLLER > > config SOC_AM43XX > bool "TI AM43x" > @@ -82,6 +83,7 @@ config SOC_AM43XX > select ARM_GIC > select COMMON_CLK > select MACH_OMAP_GENERIC > + select ARCH_HAS_RESET_CONTROLLER > > config ARCH_OMAP2PLUS > bool > -- > 1.8.3.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 v5 00/11] ARM: OMAP2+: AM43x PRCM basic support
* Rajendra Nayak [131003 23:50]: > 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 Looks good to me too. I'm assuming that Paul will queue this. And let's everybody make note that this will be the _last_ set of hwmod data we'll _ever_ merge as this all should be replaced with device tree + bus driver based approach for future SoCs. But let's get the common clock framework conversion done first, so this can wait until after that. 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: OMAP2+: hwmod: check for module address space during init
* Suman Anna [131003 10:07]: > 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. Hmm so is this needed as a fix for the -rcy cycle? Other than that looks OK to me, Paul should queue or ack this one: 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: mach-omap1: Fix omap1510_fpga_init_irq() implicit declarations.
* Majunath Goudar [131008 03:37]:
> This patch adds a omap1510_fpga_init_irq() inline dummy implementations
> in arch/arm/mach-omap1/common.h. Without this patch,build system can
> lead to issues. This was discovered during randconfig testing,in which
> other than CONFIG_ARCH_OMAP15XX was enabled the leading to the following
> error:
>
> CC arch/arm/mach-omap1/board-innovator.o
> arch/arm/mach-omap1/board-innovator.c: In function ‘innovator_init’:
> arch/arm/mach-omap1/board-innovator.c:377:3: error: implicit declaration of
> function ‘omap1510_fpga_init_irq’ [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [arch/arm/mach-omap1/board-innovator.o] Error 1
> make: *** [arch/arm/mach-omap1] Error 2
Thanks, I'll apply this into omap-for-v3.13/fixes-not-urgent
as it's been there for quite a while.
Regards,
Tony
> Signed-off-by: Manjunath Goudar
> Cc: Tony Lindgren
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
> ---
> arch/arm/mach-omap1/common.h |3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
> index abec019..732f8ee 100644
> --- a/arch/arm/mach-omap1/common.h
> +++ b/arch/arm/mach-omap1/common.h
> @@ -46,6 +46,9 @@ static inline void omap7xx_map_io(void)
> void omap1510_fpga_init_irq(void);
> void omap15xx_map_io(void);
> #else
> +static inline void omap1510_fpga_init_irq(void)
> +{
> +}
> static inline void omap15xx_map_io(void)
> {
> }
> --
> 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: [PATCH 2/2] ARM: dts: omap3-beagle: use 3630 definitions
On 10/08/2013 12:47 PM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Oct 07, 2013 at 12:20:09PM -0700, Tony Lindgren wrote:
>> * Nishanth Menon [131007 09:57]:
>>> beagle-xm currently would matchup with ti,omap3 which invokes
>>> omap3430_init_early instead of omap3630_init_early. So add
>>> compatiblity for 3630 to allow match
>>>
>>> Signed-off-by: Nishanth Menon
>>> ---
>>> arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> index 0f7cfc5..2079e22 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
>>> @@ -11,7 +11,7 @@
>>>
>>> / {
>>> model = "TI OMAP3 BeagleBoard xM";
>>> - compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
>>> + compatible = "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3-beagle",
>>> "ti,omap3";
>>>
>>> cpus {
>>> cpu@0 {
>>
>> This compatible string looks hacky.. How about just make it
>>
>> "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3";
>>
>> How about just leave out "ti,omap3-beagle" here?
>
> ti,omap3-beagle was already part of the original file, we can definitely
> remove but I'd expect us to maintain support for that string
> indefinitely should anybody continue to use older dtbs.
>
it already is supported (we still have a beagleboard) - the current
patch rev does nothing to break existing code or bindings.
--
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
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/08/2013 12:58 PM, Tony Lindgren wrote:
> * Nishanth Menon [131008 05:08]:
>> On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
>>> On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..4fe5b9c 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -113,6 +113,7 @@ MACHINE_END
#ifdef CONFIG_ARCH_OMAP3
static const char *omap3_boards_compat[] __initdata = {
"ti,omap3",
+ "ti,omap343x",
>>>
>>> You used omap36xx everywhere, so I guess this should be
>>> "ti,omap34xx"?
>>
>> 3630 has at least two variants:
>> http://www.ti.com/product/omap3621
>> http://www.ti.com/product/omap3630
>>
>> It got further spun off in 37xx family:
>> http://www.ti.com/product/dm3730 (DM3730 and DM3725)
>>
>> 3430 is no longer in production - but just had a single version (at
>> least what I can remember).
>>
>> 3530 variant of 3430 on the other hand has a few:
>> http://processors.wiki.ti.com/index.php/OMAP3_Overview
>>
>>
>> I am ok to change to ti,omap34xx if folks think that is the right
>> thing to do. Personally, I might prefer to handle 35xx family slightly
>> differently considering deltas.
>
> I've dropped that part as that's not needed for the fix AFAIK.
> Here's what I've applied and pushed out to omap-for-v3.12/fixes.
>
> Regards,
>
> Tony
>
> From: Nishanth Menon
> Date: Mon, 7 Oct 2013 15:43:49 -0500
> Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
> with device tree
>
> SoC family definitions at the moment are reactive to board needs
> as a result, beagle-xm would matchup with ti,omap3 which invokes
> omap3430_init_early instead of omap3630_init_early. Obviously, this is
> the wrong behavior.
>
> With clock node dts conversion, we get the following warnings before
> system hangs as a result and 3630 based platforms fails to boot
> (uart4 clocks are only present in OMAP3630 and not present in
> OMAP3430):
>
> ...
> omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
> omap_hwmod: uart4: cannot _init_clocks
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
> _init+0x6c/0x80()
> omap_hwmod: uart4: couldn't init clocks
> ...
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
> _enable+0x254/0x280()
> omap_hwmod: timer12: enabled state can only be entered from
> initialized, idle, or disabled state
> ...
>
> WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
> _idle+0xd4/0xf8()
> omap_hwmod: timer12: idle state can only be entered from enabled state
>
> WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
> _enable+0x254/0x280()
> omap_hwmod: uart4: enabled state can only be entered from
> initialized, idle, or disabled state
>
> So, add specific compatiblity for 3630 to allow match for Beagle-XM
> platform.
>
> Signed-off-by: Nishanth Menon
> [t...@atomide.com: left out ti,omap343x, updated comments]
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> b/arch/arm/boot/dts/omap3-beagle-xm.dts
> index 0c514dc..2816bf6 100644
> --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> @@ -11,7 +11,7 @@
>
> / {
> model = "TI OMAP3 BeagleBoard xM";
> - compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
> + compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
>
> cpus {
> cpu@0 {
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c
> index 39c7838..87162e1 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
> Device Tree)")
> .restart= omap3xxx_restart,
> MACHINE_END
>
> +static const char *omap36xx_boards_compat[] __initdata = {
> + "ti,omap36xx",
> + NULL,
> +};
> +
> +DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened Device Tree)")
> + .reserve= omap_reserve,
> + .map_io = omap3_map_io,
> + .init_early = omap3630_init_early,
> + .init_irq = omap_intc_of_init,
> + .handle_irq = omap3_intc_handle_irq,
> + .init_machine = omap_generic_init,
> + .init_late = omap3_init_late,
> + .init_time = omap3_sync32k_timer_init,
> + .dt_compat = omap36xx_boards_compat,
> + .restart= omap3xxx_restart,
> +MACHINE_END
> +
> static const char *omap3_gp_boards_compat[] __initdata = {
> "ti,omap3-beagle",
> "timll,omap3-devkit8000",
>
LGTM. Thanks for doing it.
--
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
Re: [PATCH V3] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
* Nishanth Menon [131008 05:08]:
> On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
> > On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
> >> diff --git a/arch/arm/mach-omap2/board-generic.c
> >> b/arch/arm/mach-omap2/board-generic.c
> >> index 39c7838..4fe5b9c 100644
> >> --- a/arch/arm/mach-omap2/board-generic.c
> >> +++ b/arch/arm/mach-omap2/board-generic.c
> >> @@ -113,6 +113,7 @@ MACHINE_END
> >> #ifdef CONFIG_ARCH_OMAP3
> >> static const char *omap3_boards_compat[] __initdata = {
> >>"ti,omap3",
> >> + "ti,omap343x",
> >
> > You used omap36xx everywhere, so I guess this should be
> > "ti,omap34xx"?
>
> 3630 has at least two variants:
> http://www.ti.com/product/omap3621
> http://www.ti.com/product/omap3630
>
> It got further spun off in 37xx family:
> http://www.ti.com/product/dm3730 (DM3730 and DM3725)
>
> 3430 is no longer in production - but just had a single version (at
> least what I can remember).
>
> 3530 variant of 3430 on the other hand has a few:
> http://processors.wiki.ti.com/index.php/OMAP3_Overview
>
>
> I am ok to change to ti,omap34xx if folks think that is the right
> thing to do. Personally, I might prefer to handle 35xx family slightly
> differently considering deltas.
I've dropped that part as that's not needed for the fix AFAIK.
Here's what I've applied and pushed out to omap-for-v3.12/fixes.
Regards,
Tony
From: Nishanth Menon
Date: Mon, 7 Oct 2013 15:43:49 -0500
Subject: [PATCH] ARM: OMAP3: Fix hardware detection for omap3630 when booted
with device tree
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.
With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):
...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocks
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...
WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled state
WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled state
So, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.
Signed-off-by: Nishanth Menon
[t...@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 0c514dc..2816bf6 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -11,7 +11,7 @@
/ {
model = "TI OMAP3 BeagleBoard xM";
- compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
+ compatible = "ti,omap3-beagle-xm", "ti,omap36xx", "ti,omap3";
cpus {
cpu@0 {
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 39c7838..87162e1 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -129,6 +129,24 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened
Device Tree)")
.restart= omap3xxx_restart,
MACHINE_END
+static const char *omap36xx_boards_compat[] __initdata = {
+ "ti,omap36xx",
+ NULL,
+};
+
+DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx (Flattened Device Tree)")
+ .reserve= omap_reserve,
+ .map_io = omap3_map_io,
+ .init_early = omap3630_init_early,
+ .init_irq = omap_intc_of_init,
+ .handle_irq = omap3_intc_handle_irq,
+ .init_machine = omap_generic_init,
+ .init_late = omap3_init_late,
+ .init_time = omap3_sync32k_timer_init,
+ .dt_compat = omap36xx_boards_compat,
+ .restart= omap3xxx_restart,
+MACHINE_END
+
static const char *omap3_gp_boards_compat[] __initdata = {
"ti,omap3-beagle",
"timll,omap3-devkit8000",
--
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 2/2] ARM: dts: omap3-beagle: use 3630 definitions
Hi,
On Mon, Oct 07, 2013 at 12:20:09PM -0700, Tony Lindgren wrote:
> * Nishanth Menon [131007 09:57]:
> > beagle-xm currently would matchup with ti,omap3 which invokes
> > omap3430_init_early instead of omap3630_init_early. So add
> > compatiblity for 3630 to allow match
> >
> > Signed-off-by: Nishanth Menon
> > ---
> > arch/arm/boot/dts/omap3-beagle-xm.dts |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > index 0f7cfc5..2079e22 100644
> > --- a/arch/arm/boot/dts/omap3-beagle-xm.dts
> > +++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
> > @@ -11,7 +11,7 @@
> >
> > / {
> > model = "TI OMAP3 BeagleBoard xM";
> > - compatible = "ti,omap3-beagle-xm", "ti,omap3-beagle", "ti,omap3";
> > + compatible = "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3-beagle",
> > "ti,omap3";
> >
> > cpus {
> > cpu@0 {
>
> This compatible string looks hacky.. How about just make it
>
> "ti,omap3-beagle-xm", "ti,omap363x", "ti,omap3";
>
> How about just leave out "ti,omap3-beagle" here?
ti,omap3-beagle was already part of the original file, we can definitely
remove but I'd expect us to maintain support for that string
indefinitely should anybody continue to use older dtbs.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: mach-omap2: board-generic: fix undefined symbol
* Simon Barth [131008 01:58]:
> Since dra7 reuses the function 'omap5_realtime_timer_init' in
> arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
> built for this SoC as well.
Thanks applying into omap-for-v3.12/fixes.
Regards,
Tony
> Signed-off-by: Simon Barth
> ---
> arch/arm/mach-omap2/timer.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index fa74a06..ead48fa 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -628,7 +628,7 @@ void __init omap4_local_timer_init(void)
> #endif /* CONFIG_HAVE_ARM_TWD */
> #endif /* CONFIG_ARCH_OMAP4 */
>
> -#ifdef CONFIG_SOC_OMAP5
> +#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
> void __init omap5_realtime_timer_init(void)
> {
> omap4_sync32k_timer_init();
> @@ -636,7 +636,7 @@ void __init omap5_realtime_timer_init(void)
>
> clocksource_of_init();
> }
> -#endif /* CONFIG_SOC_OMAP5 */
> +#endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
>
> /**
> * omap_timer_init - build and register timer device with an
> --
> 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: [RFCv3 0/7] OMAP SSI driver
* Sebastian Reichel [131006 13:36]: > Hi, > > Here is the third round of the OMAP SSI driver patches. Thanks for updating these, they look good to me now: 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: OMAP4/highbank: Flush L2 cache before disabling
* Taras Kondratiuk [131007 03:35]:
> Kexec disables outer cache before jumping to reboot code, but it doesn't
> flush it explicitly. Flush is done implicitly inside of l2x0_disable().
> But some SoC's override default .disable handler and don't flush cache.
> This may lead to a corrupted memory during Kexec reboot on these platforms.
>
> This patch adds cache flush inside of OMAP4 and Highbank outer_cache.disable()
> handlers to make it consistent with default l2x0_disable().
> Also it removes redundant outer_flush_all() call just before outer_disable().
Sounds correct to me:
Acked-by: Tony Lindgren
> Acked-by: Rob Herring
> Acked-by: Santosh Shilimkar
> Signed-off-by: Taras Kondratiuk
> ---
> Based on v3.12-rc3
>
> RFC v2: https://patchwork.kernel.org/patch/2990231/
> Make the fix specific to platforms that don't use l2x0_disable().
> RFC v1: https://patchwork.kernel.org/patch/2974431/
> ---
> Cc: Will Deacon
> Cc: Russell King
> Cc: Rob Herring
> Cc: Santosh Shilimkar
> Cc: linaro-ker...@lists.linaro.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-omap@vger.kernel.org
> ---
> arch/arm/mach-highbank/highbank.c |1 +
> arch/arm/mach-highbank/pm.c|1 -
> arch/arm/mach-omap2/omap4-common.c |1 +
> 3 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mach-highbank/highbank.c
> b/arch/arm/mach-highbank/highbank.c
> index 8e63ccd..22e6f34 100644
> --- a/arch/arm/mach-highbank/highbank.c
> +++ b/arch/arm/mach-highbank/highbank.c
> @@ -63,6 +63,7 @@ void highbank_set_cpu_jump(int cpu, void *jump_addr)
>
> static void highbank_l2x0_disable(void)
> {
> + outer_flush_all();
> /* Disable PL310 L2 Cache controller */
> highbank_smc1(0x102, 0x0);
> }
> diff --git a/arch/arm/mach-highbank/pm.c b/arch/arm/mach-highbank/pm.c
> index 04eddb4..9a5b8a7 100644
> --- a/arch/arm/mach-highbank/pm.c
> +++ b/arch/arm/mach-highbank/pm.c
> @@ -28,7 +28,6 @@
>
> static int highbank_suspend_finish(unsigned long val)
> {
> - outer_flush_all();
> outer_disable();
>
> highbank_set_pwr_suspend();
> diff --git a/arch/arm/mach-omap2/omap4-common.c
> b/arch/arm/mach-omap2/omap4-common.c
> index 2840d1e..f6ccab61 100644
> --- a/arch/arm/mach-omap2/omap4-common.c
> +++ b/arch/arm/mach-omap2/omap4-common.c
> @@ -163,6 +163,7 @@ void __iomem *omap4_get_l2cache_base(void)
>
> static void omap4_l2x0_disable(void)
> {
> + outer_flush_all();
> /* Disable PL310 L2 Cache controller */
> omap_smc1(0x102, 0x0);
> }
> --
> 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
--
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: Question about mmc4 initialization on OMAP5432
On Tuesday 08 October 2013 12:29 PM, Chen Baozi wrote: > Hi all, > > I have got a problem when booting dom0 kernel for Xen on OMAP5432 uEVM. > With a recent patch, Xen hypervisor is avoid to map "disabled" device > memory for dom0. In omap5-uevm.dts, we have got the &mmc4 node marked as > "disabled". So the Xen won't populate <0x480d1000 0x400> memory region > to the dom0. If dom0 is trying to access any memory address in this > area, the hypervisor would be panic with a tranlation fault. However, it > turns out that even the mmc4 is disabled in omap5-uevm.dts, Linux kernel > is trying to access the 0x480d1010 when booting, which then leads a > hypervisor panic as mentioned. > > The only point I know right now is that the 0x480d1010 is accessed by > the omap_hwmod_read(). However, what makes me confused is how the dom0 > kernel called omap_hwmod_read() to access 0x480d1010 while the mmc4 is > disabled. I guess it might relate to hard coded omap_hwmod structure but > have no idea what happen exactly when dom0 access the address due to the > lack of calling stack information when booting Xen hypervisor. > There is no hard-coding rather a different requirement why hwmod accesses the IP space. DT disabled is will ensure that the device won't get created but hwmod bus initially tries to put all the supported IPs in sane hardware state by doing reset on those IPs. We have proposals to address than in future where such resets are moved with device/driver probe etc to avoid such issues. Actually MMC4 is more for SDIO kind of usecase so you might even get rid of that in your case. Regards, Santosh -- 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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
* Tero Kristo [131008 01:26]: > On 10/08/2013 08:40 AM, Mike Turquette wrote: > > >3) Same concern as above but for the DT clkdev alias stuff. I guess > >you'll need to make all of the dependent drivers play nice with DT. Do > >you plan to remove it within a reasonable timeframe? It would be a nice > >reduction in LoC and more importantly it would mean that drivers were > >using clkdev in a more-correct fashion. > > This is probably harder, I think Tony is better to comment here, but > my idea is that in the worst case we can just break non-conforming > drivers by dropping the clkdev tables if nothing else helps. :) Most > of the tables are currently needed by hwmod, and there are already > patches around for adding DT clock support for hwmods, so once these > go in, we can at least reduce the table sizes considerably already. It should be possible to remove these as we go as things become DT only. Probably the biggest blocker right now is making omap3 DT only. But let's not start breaking things intentionally! 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
Question about mmc4 initialization on OMAP5432
Hi all, I have got a problem when booting dom0 kernel for Xen on OMAP5432 uEVM. With a recent patch, Xen hypervisor is avoid to map "disabled" device memory for dom0. In omap5-uevm.dts, we have got the &mmc4 node marked as "disabled". So the Xen won't populate <0x480d1000 0x400> memory region to the dom0. If dom0 is trying to access any memory address in this area, the hypervisor would be panic with a tranlation fault. However, it turns out that even the mmc4 is disabled in omap5-uevm.dts, Linux kernel is trying to access the 0x480d1010 when booting, which then leads a hypervisor panic as mentioned. The only point I know right now is that the 0x480d1010 is accessed by the omap_hwmod_read(). However, what makes me confused is how the dom0 kernel called omap_hwmod_read() to access 0x480d1010 while the mmc4 is disabled. I guess it might relate to hard coded omap_hwmod structure but have no idea what happen exactly when dom0 access the address due to the lack of calling stack information when booting Xen hypervisor. Thanks a lot. Chen Baozi -- 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 3/6] pinctrl: single: Prepare for supporting SoC specific features
* Linus Walleij [131008 05:03]: > On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren wrote: > > > Hi Linus W, > > > > Any comments on the pinctrl patches 3 - 5 in this series? > > I have no problems with this patch #3, as it is just changing syntax, > not semantics. > > The problems start with patch #4. > > I am tormented with mixed feelings about this, because from one point of > view I feel it is breaking the promise of pinctrl-single being a > driver for platforms > where a pin is controlled by a *single* register. It is still in that same *single* register. There are interrupt enable and interrupt status bits for *every* pin register on most omaps. > If this was pinctrl-foo.c I would not have been so much bothered, > but now it is something that was supposed to be self-contained and > simple, pertaining to a single register, starting to look like something > else. > > This is a bit like: "oh yeah just one register controls the pins, but under > some circumstances I also want to mess with this register over here, > and then this register over there ..." etc. Not true. If it was some other register I would have set it up as a separate driver under drivers/irqchip. > I'd like Haojian to ACK this to proceed since he's also using this driver > now. Then I feel better on continuing down this road ... > > Then I have a lesser comment on patch #4 since it makes it possible > for this pin controller to support wake-up interrupt, as I don't see how > this plays out with front-end GPIO controllers, but let's discuss that > in the context of that patch. It's completely separate from the GPIO controller wake-up events. 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 v3 2/4] mmc: omap_hsmmc: Enable SDIO IRQ.
Hi,
On Sat, Oct 05, 2013 at 01:17:08PM +0200, Andreas Fenkart wrote:
> For now, only support SDIO interrupt if we are booted with
> DT. This is because some platforms need special quirks. And
> we don't want to add new legacy mux platform init code
> callbacks any longer as we are moving to DT based booting
> anyways.
>
> Broken hardware, missing the swakueup line, should fallback
> to polling, by setting 'ti,quirk-swakup-missing' in the
> device tree. Otherwise pending SDIO IRQ are not detected
> while in suspend. This affects am33xx processors.
>
> Signed-off-by: Andreas Fenkart
I still think this patch needs to be splitted, see below.
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 94d6dc8..53beac4 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -130,6 +130,7 @@ static void apply_clk_hack(struct device *dev)
> #define TC_EN(1 << 1)
> #define BWR_EN (1 << 4)
> #define BRR_EN (1 << 5)
> +#define CIRQ_EN (1 << 8)
> #define ERR_EN (1 << 15)
> #define CTO_EN (1 << 16)
> #define CCRC_EN (1 << 17)
> @@ -210,6 +211,10 @@ struct omap_hsmmc_host {
> int reqs_blocked;
> int use_reg;
> int req_in_progress;
> + int flags;
> +#define HSMMC_RUNTIME_SUSPENDED (1 << 0)/* Runtime suspended */
> +#define HSMMC_SDIO_IRQ_ENABLED (1 << 1)/* SDIO irq enabled */
> +
> struct omap_hsmmc_next next_data;
> struct omap_mmc_platform_data *pdata;
> };
> @@ -490,27 +495,40 @@ static void omap_hsmmc_stop_clock(struct
> omap_hsmmc_host *host)
> static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
> struct mmc_command *cmd)
> {
> - unsigned int irq_mask;
> + u32 irq_mask = INT_EN_MASK;
> + unsigned long flags;
>
> if (host->use_dma)
> - irq_mask = INT_EN_MASK & ~(BRR_EN | BWR_EN);
> - else
> - irq_mask = INT_EN_MASK;
> + irq_mask &= ~(BRR_EN | BWR_EN);
is this a bugfix ? should it be sent as a separate patch ?
>
> /* Disable timeout for erases */
> if (cmd->opcode == MMC_ERASE)
> irq_mask &= ~DTO_EN;
>
> + spin_lock_irqsave(&host->irq_lock, flags);
why do you need this new locking here ? register acesses are atomic,
right ? If you really do need the locking, should it be a separate patch
as well ?
> OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
> +
> + /* latch pending CIRQ, but don't signal */
> + if (host->flags & HSMMC_SDIO_IRQ_ENABLED)
> + irq_mask |= CIRQ_EN;
why do you need this ? Looks like it should be yet another patch.
>
> static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
> {
> - OMAP_HSMMC_WRITE(host->base, ISE, 0);
> - OMAP_HSMMC_WRITE(host->base, IE, 0);
> + u32 irq_mask = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->irq_lock, flags);
> + /* no transfer running, need to signal cirq if */
if... ?
> + if (host->flags & HSMMC_SDIO_IRQ_ENABLED)
> + irq_mask |= CIRQ_EN;
> + OMAP_HSMMC_WRITE(host->base, ISE, irq_mask);
the whole fiddling with STAT and ISE registers look very bogus to me
(even on current state before this patch). We shouldn't be clearing
pending IRQ events here, right ? We could miss IRQs due to that.
> @@ -1067,8 +1085,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
> *dev_id)
> int status;
>
> status = OMAP_HSMMC_READ(host->base, STAT);
> - while (status & INT_EN_MASK && host->req_in_progress) {
> - omap_hsmmc_do_irq(host, status);
> + while (status & (INT_EN_MASK | CIRQ_EN)) {
why don't enable CIRQ_EN in INT_EN_MASK directly ?
> + if (host->req_in_progress)
> + omap_hsmmc_do_irq(host, status);
> +
> + if (status & CIRQ_EN)
> + mmc_signal_sdio_irq(host->mmc);
>
> /* Flush posted write */
> status = OMAP_HSMMC_READ(host->base, STAT);
> @@ -1583,6 +1605,42 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
> struct mmc_card *card)
> mmc_slot(host).init_card(card);
> }
>
> +static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
> +{
> + struct omap_hsmmc_host *host = mmc_priv(mmc);
> + u32 irq_mask;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&host->irq_lock, flags);
> +
> + if (enable)
> + host->flags |= HSMMC_SDIO_IRQ_ENABLED;
> + else
> + host->flags &= ~HSMMC_SDIO_IRQ_ENABLED;
> +
> + /* if statement here with followup patch */
> + {
> + irq_mask = OMAP_HSMMC_READ(host->base, I
Re: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
* Linus Walleij [131008 05:18]:
> On Thu, Oct 3, 2013 at 7:42 AM, Tony Lindgren wrote:
>
> > 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.
>
> So to be clear: is this enable and status bit in the *same*
> register as all other settings? Then it warrants having this
> under pinctrl-single still and I feel a bit better about this.
Yes there's a status bit on most omaps in the same register
for each pin.
There is a PRM interrupt that has wake-up events for internal
domain wake-ups and io chain wake-ups. The PRM interrupt is
already a chained IRQ. After we get the wake-up interrupt we
need to check the pinctrl registers that have wake-up bit
enabled for the wake-up status bit.
> Second: how does this relate to the case where say
> gpio-omap is using the same pins as a back-end (this
> is a real usecase right)?
The GPIO is a separate hardware block on omaps and has
it's own separate wake-up events.
> So gpio-omap already supports gpio_to_irq() and
> it does not support enable_irq_wake() on the GPIO
> lines as well.
Yeah those are specific to the GPIO block, and not related
to this driver. The GPIO lines have their own wake-up
mechanism that works for retention idle.
For off-idle, only for the first GPIO bank stays powered.
The other GPIO banks get powered down in off-idle mode.
> How does this play together? Is it like the pins have a set
> of wakeup IRQs and then the GPIO block has *another*
> set of wakeup IRQs?
Yes that's correct, they are completely separate.
> And if you do enable_irq_wake() on the GPIO line,
> should this not fall through to the pinctrl driver, so we
> should add pinctrl_gpio_enable_wake() and
> pinctrl_gpio_disable_wake() just like we have
> pinctrl_gpio_direction_input() and friends today,
> so that this request falls through to the pinctrl driver
> when a wakeup on a certain GPIO line is requested?
That's not needed for most cases at this point, the GPIO
block is already handling it's internal wake-up events.
Eventually we should also handle the corner case of
GPIO wake-up line connected to a GPIO bank that's not
the first bank for off-idle. For most low-power hardware
designs that's not needed as the critial pins typically
are placed in the first GPIO bank for this reason.
But let's first figure out how we want to handle the mapping
of wake-up interrupts to device interrupts in general.
Most omap devices have a dedicated io chain wake-up line, so
that's really the key thing to get working first.
> Now gpio-omap.c does not seem to use the pinctrl
> back-end commands, instead of using e.g.
> pinctrl_gpio_request() and GPIO to pin ranges it
> seems to use this hack:
>
> static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
> {
> if (bank->regs->pinctrl) {
> void __iomem *reg = bank->base + bank->regs->pinctrl;
>
> /* Claim the pin for MPU */
> __raw_writel(__raw_readl(reg) | (1 << offset), reg);
> }
>
> Can't we please make the OMAP GPIO driver use the
> pinctrl back-end with gpio ranges properly *before* we proceed
> to doing this kind of stuff? I think it is already looking
> like a bit of layered hacks :-(
Heh, that's not true. And I can totally see where the confusion
comes from :)
The naming "pinctrl" in the GPIO driver is a bit confusing and
it's use predates the pinctrl framework and has been in the GPIO
driver for probably 10 years or so.
The above does not have anything to do with the pinctrl
framework or this pinctrl driver. That is to mux the GPIO pins
inside the GPIO block between the ARM core and the DSP.
> Haojian is already using the pinctrl-single as backend to
> another GPIO controller (I think it's pinctrl-pl061.c) so surely
> this should be possible to do right.
Sure we can make the GPIO off-idle wake-up handling automatic
for the GPIO not in the first bank, but that's really a separate
patch.
> IIRC there are also other OMAP GPIO blocks so we need
> to look at the large picture here, for all of them.
Sorry I don't know which other OMAP GPIO blocks you're talking
about, care to be a bit more specific?
All the omaps I've seen use the gpio-omap.c. The other GPIOs
are typically on I2C chips.
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 0/1] Possibly fix USB OTG on GTA04 and N900
Hi, On Mon, Oct 07, 2013 at 04:28:12PM +0300, Roger Quadros wrote: > USB OTG on these boards might be broken on Greg's usb-next branch [1] > after the Generic PHY framework and associated patches were merged. > > This is a probable fix but I'm not able to test these boards. Please > give it a try and your Ack if it works. Thanks. > > [1] - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git I have tested the Nokia N900 part of the patch. Without this patch the USB port does not work: [1.015014] musb-omap2430 480ab000.usb_otg_hs: unable to find phy With the patch everything seems to work. Tested-by: Sebastian Reichel -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v3 0/3] AM33XX crypto DTS patches
Hi Joel, n 05/10/2013 21:04, Joel Fernandes wrote: These patches are some minor fixups and changes to commit messages to the AM33XX crypto (aes, sham) patches with reference to the comments at: http://comments.gmane.org/gmane.linux.drivers.devicetree/45961 Joel Fernandes (1): ARM: dts: AM33XX: Fix AES interrupt number Mark A. Greer (2): ARM: dts: AM33XX: Add SHAM data and documentation ARM: dts: AM33XX: Add AES data and documentation .../devicetree/bindings/crypto/omap-aes.txt| 31 ++ .../devicetree/bindings/crypto/omap-sham.txt | 28 +++ arch/arm/boot/dts/am335x-bone.dts | 8 ++ arch/arm/boot/dts/am335x-evm.dts | 8 ++ arch/arm/boot/dts/am335x-evmsk.dts | 8 ++ arch/arm/boot/dts/am33xx.dtsi | 19 + 6 files changed, 102 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/omap-aes.txt create mode 100644 Documentation/devicetree/bindings/crypto/omap-sham.txt I've just applied this series and the remaining ones from the previous version. Thanks, 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: [PATCH v6 3/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver
Hi Stan,
On Mon, 2013-10-07 at 12:28 +0300, Stanimir Varbanov wrote:
> Hi Ivan,
>
> Minor comments below.
>
> On 10/07/2013 10:44 AM, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > DWC3 glue layer is hardware layer around Synopsys DesignWare
> > USB3 core. Its purpose is to supply Synopsys IP with required
> > clocks, voltages and interface it with the rest of the SoC.
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > drivers/usb/dwc3/Kconfig|8 +++
> > drivers/usb/dwc3/Makefile |1 +
> > drivers/usb/dwc3/dwc3-msm.c | 168
> > +++
> > 3 files changed, 177 insertions(+)
> > create mode 100644 drivers/usb/dwc3/dwc3-msm.c
> >
> > diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> > index 70fc430..4c7b5a4 100644
> > --- a/drivers/usb/dwc3/Kconfig
> > +++ b/drivers/usb/dwc3/Kconfig
> > @@ -59,6 +59,14 @@ config USB_DWC3_EXYNOS
> > Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside,
> > say 'Y' or 'M' if you have one such device.
> >
> > +config USB_DWC3_MSM
> > + tristate "Qualcomm MSM/APQ Platforms"
> > + default USB_DWC3
> > + select USB_MSM_DWC3_PHYS
> > + help
> > + Recent Qualcomm SoCs ship with one DesignWare Core USB3 IP inside,
> > + say 'Y' or 'M' if you have one such device.
> > +
> > config USB_DWC3_PCI
> > tristate "PCIe-based Platforms"
> > depends on PCI
> > diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
> > index dd17601..a90de66 100644
> > --- a/drivers/usb/dwc3/Makefile
> > +++ b/drivers/usb/dwc3/Makefile
> > @@ -31,4 +31,5 @@ endif
> >
> > obj-$(CONFIG_USB_DWC3_OMAP)+= dwc3-omap.o
> > obj-$(CONFIG_USB_DWC3_EXYNOS) += dwc3-exynos.o
> > +obj-$(CONFIG_USB_DWC3_MSM) += dwc3-msm.o
> > obj-$(CONFIG_USB_DWC3_PCI) += dwc3-pci.o
> > diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
> > new file mode 100644
> > index 000..1d73f92
> > --- /dev/null
> > +++ b/drivers/usb/dwc3/dwc3-msm.c
> > @@ -0,0 +1,168 @@
> > +/* Copyright (c) 2013, The Linux Foundation. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +struct dwc3_msm {
> > + struct device *dev;
> > +
> > + struct clk *core_clk;
> > + struct clk *iface_clk;
> > + struct clk *sleep_clk;
> > + struct clk *utmi_clk;
> > +
> > + struct regulator*gdsc;
> > +};
> > +
> > +static int dwc3_msm_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *node = pdev->dev.of_node;
> > + struct dwc3_msm *mdwc;
> > + struct resource *res;
> > + void __iomem *tcsr;
> > + int ret = 0;
> > +
> > + mdwc = devm_kzalloc(&pdev->dev, sizeof(*mdwc), GFP_KERNEL);
> > + if (!mdwc)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, mdwc);
> > +
> > + mdwc->dev = &pdev->dev;
> > +
> > + mdwc->gdsc = devm_regulator_get(mdwc->dev, "gdsc");
> > +
> > + mdwc->core_clk = devm_clk_get(mdwc->dev, "core");
> > + if (IS_ERR(mdwc->core_clk)) {
> > + dev_dbg(mdwc->dev, "failed to get core clock\n");
> > + return PTR_ERR(mdwc->core_clk);
> > + }
> > +
> > + mdwc->iface_clk = devm_clk_get(mdwc->dev, "iface");
> > + if (IS_ERR(mdwc->iface_clk)) {
> > + dev_dbg(mdwc->dev, "failed to get iface clock\n");
> > + return PTR_ERR(mdwc->iface_clk);
> > + }
> > +
> > + mdwc->sleep_clk = devm_clk_get(mdwc->dev, "sleep");
> > + if (IS_ERR(mdwc->sleep_clk)) {
> > + dev_dbg(mdwc->dev, "failed to get sleep clock\n");
> > + return PTR_ERR(mdwc->sleep_clk);
> > + }
> > +
> > + mdwc->utmi_clk = devm_clk_get(mdwc->dev, "utmi");
> > + if (IS_ERR(mdwc->utmi_clk)) {
> > + dev_dbg(mdwc->dev, "failed to get utmi clock\n");
> > + return PTR_ERR(mdwc->utmi_clk);
> > + }
>
> I'm not sure that those dev_dbg() are useful at all.
They are, if you deal with WIP clocks and regulators implementations,
which is the case for this platform.
>
> > +
> > + if (!IS_ERR(mdwc->gdsc)) {
> > + ret = regulator_enable(mdwc->gdsc);
> > + if (ret)
> > + dev_err(mdwc->dev, "cannot enable gdsc\n");
> > + }
> > +
> > + /*
> > +* DWC3 Core requires its CORE CLK (aka maste
Re: [PATCH v6 2/3] usb: phy: Add Qualcomm SS-USB and HS-USB drivers for DW PHY's
Hi Stan,
On Mon, 2013-10-07 at 12:22 +0300, Stanimir Varbanov wrote:
> Hi Ivan,
>
> Few comments below.
>
> On 10/07/2013 10:44 AM, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov"
> >
> > These drivers handles control and configuration of the HS
> > and SS USB PHY transceivers. They are part of the driver
> > which manage Synopsys DesignWare USB3 controller stack
> > inside Qualcomm SoC's.
> >
> > Signed-off-by: Ivan T. Ivanov
> > ---
> > drivers/usb/phy/Kconfig | 11 ++
> > drivers/usb/phy/Makefile|2 +
> > drivers/usb/phy/phy-msm-dw-hs.c | 329 ++
> > drivers/usb/phy/phy-msm-dw-ss.c | 375
> > +++
> > 4 files changed, 717 insertions(+)
> > create mode 100644 drivers/usb/phy/phy-msm-dw-hs.c
> > create mode 100644 drivers/usb/phy/phy-msm-dw-ss.c
> >
> > diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
> > index d5589f9..bbb2d0e 100644
> > --- a/drivers/usb/phy/Kconfig
> > +++ b/drivers/usb/phy/Kconfig
> > @@ -214,6 +214,17 @@ config USB_RCAR_PHY
> > To compile this driver as a module, choose M here: the
> > module will be called phy-rcar-usb.
> >
> > +config USB_MSM_DW_PHYS
> > + tristate "Qualcomm USB controller DW PHY's wrappers support"
> > + depends on (USB || USB_GADGET) && ARCH_MSM
> > + select USB_PHY
> > + help
> > + Enable this to support the DW USB PHY transceivers on MSM chips
> > + with DWC3 USB core. It handles PHY initialization, clock
> > + management required after resetting the hardware and power
> > + management. This driver is required even for peripheral only or
> > + host only mode configurations.
> > +
> > config USB_ULPI
> > bool "Generic ULPI Transceiver Driver"
> > depends on ARM
> > diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
> > index 2135e85..4813eb5 100644
> > --- a/drivers/usb/phy/Makefile
> > +++ b/drivers/usb/phy/Makefile
> > @@ -26,6 +26,8 @@ obj-$(CONFIG_USB_EHCI_TEGRA) +=
> > phy-tegra-usb.o
> > obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
> > obj-$(CONFIG_USB_ISP1301) += phy-isp1301.o
> > obj-$(CONFIG_USB_MSM_OTG) += phy-msm-usb.o
> > +obj-$(CONFIG_USB_MSM_DW_PHYS) += phy-msm-dw-hs.o
> > +obj-$(CONFIG_USB_MSM_DW_PHYS) += phy-msm-dw-ss.o
> > obj-$(CONFIG_USB_MV_OTG) += phy-mv-usb.o
> > obj-$(CONFIG_USB_MXS_PHY) += phy-mxs-usb.o
> > obj-$(CONFIG_USB_RCAR_PHY) += phy-rcar-usb.o
> > diff --git a/drivers/usb/phy/phy-msm-dw-hs.c
> > b/drivers/usb/phy/phy-msm-dw-hs.c
> > new file mode 100644
> > index 000..d29c1f1
> > --- /dev/null
> > +++ b/drivers/usb/phy/phy-msm-dw-hs.c
> > @@ -0,0 +1,329 @@
> > +/* Copyright (c) 2013, Code Aurora Forum. All rights reserved.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/**
> > + * USB QSCRATCH Hardware registers
> > + */
> > +#define QSCRATCH_CTRL_REG (0x04)
> > +#define QSCRATCH_GENERAL_CFG (0x08)
> > +#define PHY_CTRL_REG (0x10)
> > +#define PARAMETER_OVERRIDE_X_REG (0x14)
> > +#define CHARGING_DET_CTRL_REG (0x18)
> > +#define CHARGING_DET_OUTPUT_REG(0x1c)
> > +#define ALT_INTERRUPT_EN_REG (0x20)
> > +#define PHY_IRQ_STAT_REG (0x24)
> > +#define CGCTL_REG (0x28)
> > +
>
> Please remove braces above and below.
ok
>
> > +#define PHY_3P3_VOL_MIN305 /* uV */
> > +#define PHY_3P3_VOL_MAX330 /* uV */
> > +#define PHY_3P3_HPM_LOAD 16000 /* uA */
> > +
> > +#define PHY_1P8_VOL_MIN180 /* uV */
> > +#define PHY_1P8_VOL_MAX180 /* uV */
> > +#define PHY_1P8_HPM_LOAD 19000 /* uA */
> > +
> > +/* TODO: these are suspicious */
> > +#define USB_VDDCX_NO 1 /* index */
> > +#define USB_VDDCX_MIN 5 /* index */
> > +#define USB_VDDCX_MAX 7 /* index */
> > +
> > +struct msm_dw_hs_phy {
> > + struct usb_phy phy;
> > + void __iomem*base;
> > + struct device *dev;
> > +
> > + struct clk *xo_clk;
> > + struct clk *sleep_a_clk;
> > +
> > + struct regulator*v3p3;
> > + struct re
Re: [PATCH] ARM: dts: omap5-uevm: mark TWL6037 as system-power-controller
On 09/19/2013 02:11 PM, Nishanth Menon wrote:
> This allows the palmas pm_power_off to kick in on power off command
> and switch off the board.
>
> Signed-off-by: Nishanth Menon
> ---
> Based on: (benoit's for_3.13/dts branch)
> https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/log/?h=for_3.13/dts
> This uses the support introduced by:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b81eec09a484c588ead035003ce7555ca8a9963a
>
> arch/arm/boot/dts/omap5-uevm.dts |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/omap5-uevm.dts
> b/arch/arm/boot/dts/omap5-uevm.dts
> index da25a14..8227386 100644
> --- a/arch/arm/boot/dts/omap5-uevm.dts
> +++ b/arch/arm/boot/dts/omap5-uevm.dts
> @@ -271,6 +271,7 @@
> reg = <0x48>;
> interrupt-controller;
> #interrupt-cells = <2>;
> + ti,system-power-controller;
>
> extcon_usb3: palmas_usb {
> compatible = "ti,palmas-usb-vid";
>
Gentle ping.
patchworks link: https://patchwork.kernel.org/patch/2913111/
--
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
Re: [PATCH v3 0/3] ARM: dts: omap3-igep: improvements for v3.13
Hi Javier On 07/10/2013 17:12, Javier Martinez Canillas wrote: Hi Benoit, This series are some enhancements and cleanups for IGEP boards that it would be great if can make it for v3.13. This is a third version of the patch-set that addresses some issues raised by Roger Quadros and is composed of the following patches: [PATCH v3 1/3] ARM: dts: omap3-igep: Add USB OTG support [PATCH v3 2/3] ARM: dts: omap3-igep0020: Add HS USB Host support [PATCH v3 3/3] ARM: dts: omap3-igep0020: use standard constant for IRQ The patches were tested using the new generic PHY framework that are currently on usb-next branch and will be part of v3.13 I've just pulled them into my branch. Thanks, 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: [PATCH 4/6] pinctrl: single: Add support for wake-up interrupts
On Thu, Oct 3, 2013 at 7:42 AM, Tony Lindgren wrote:
> 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.
So to be clear: is this enable and status bit in the *same*
register as all other settings? Then it warrants having this
under pinctrl-single still and I feel a bit better about this.
Second: how does this relate to the case where say
gpio-omap is using the same pins as a back-end (this
is a real usecase right)?
So gpio-omap already supports gpio_to_irq() and
it does not support enable_irq_wake() on the GPIO
lines as well.
How does this play together? Is it like the pins have a set
of wakeup IRQs and then the GPIO block has *another*
set of wakeup IRQs?
And if you do enable_irq_wake() on the GPIO line,
should this not fall through to the pinctrl driver, so we
should add pinctrl_gpio_enable_wake() and
pinctrl_gpio_disable_wake() just like we have
pinctrl_gpio_direction_input() and friends today,
so that this request falls through to the pinctrl driver
when a wakeup on a certain GPIO line is requested?
Now gpio-omap.c does not seem to use the pinctrl
back-end commands, instead of using e.g.
pinctrl_gpio_request() and GPIO to pin ranges it
seems to use this hack:
static void _enable_gpio_module(struct gpio_bank *bank, unsigned offset)
{
if (bank->regs->pinctrl) {
void __iomem *reg = bank->base + bank->regs->pinctrl;
/* Claim the pin for MPU */
__raw_writel(__raw_readl(reg) | (1 << offset), reg);
}
Can't we please make the OMAP GPIO driver use the
pinctrl back-end with gpio ranges properly *before* we proceed
to doing this kind of stuff? I think it is already looking
like a bit of layered hacks :-(
Haojian is already using the pinctrl-single as backend to
another GPIO controller (I think it's pinctrl-pl061.c) so surely
this should be possible to do right.
IIRC there are also other OMAP GPIO blocks so we need
to look at the large picture here, for all of them.
Yours,
Linus Walleij
--
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] ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
On 10/07/2013 07:05 PM, Sebastian Reichel wrote:
> On Mon, Oct 07, 2013 at 03:43:49PM -0500, Nishanth Menon wrote:
>> diff --git a/arch/arm/mach-omap2/board-generic.c
>> b/arch/arm/mach-omap2/board-generic.c
>> index 39c7838..4fe5b9c 100644
>> --- a/arch/arm/mach-omap2/board-generic.c
>> +++ b/arch/arm/mach-omap2/board-generic.c
>> @@ -113,6 +113,7 @@ MACHINE_END
>> #ifdef CONFIG_ARCH_OMAP3
>> static const char *omap3_boards_compat[] __initdata = {
>> "ti,omap3",
>> +"ti,omap343x",
>
> You used omap36xx everywhere, so I guess this should be
> "ti,omap34xx"?
3630 has at least two variants:
http://www.ti.com/product/omap3621
http://www.ti.com/product/omap3630
It got further spun off in 37xx family:
http://www.ti.com/product/dm3730 (DM3730 and DM3725)
3430 is no longer in production - but just had a single version (at
least what I can remember).
3530 variant of 3430 on the other hand has a few:
http://processors.wiki.ti.com/index.php/OMAP3_Overview
I am ok to change to ti,omap34xx if folks think that is the right
thing to do. Personally, I might prefer to handle 35xx family slightly
differently considering deltas.
--
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
Re: [PATCH 3/6] pinctrl: single: Prepare for supporting SoC specific features
On Mon, Oct 7, 2013 at 7:35 PM, Tony Lindgren wrote: > Hi Linus W, > > Any comments on the pinctrl patches 3 - 5 in this series? I have no problems with this patch #3, as it is just changing syntax, not semantics. The problems start with patch #4. I am tormented with mixed feelings about this, because from one point of view I feel it is breaking the promise of pinctrl-single being a driver for platforms where a pin is controlled by a *single* register. If this was pinctrl-foo.c I would not have been so much bothered, but now it is something that was supposed to be self-contained and simple, pertaining to a single register, starting to look like something else. This is a bit like: "oh yeah just one register controls the pins, but under some circumstances I also want to mess with this register over here, and then this register over there ..." etc. I'd like Haojian to ACK this to proceed since he's also using this driver now. Then I feel better on continuing down this road ... Then I have a lesser comment on patch #4 since it makes it possible for this pin controller to support wake-up interrupt, as I don't see how this plays out with front-end GPIO controllers, but let's discuss that in the context of that patch. Yours, Linus Walleij -- 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: [RESEND PATCH v3 11/11] ARM/dts: am335x-evm: Add audio support for am335x-evm.dts
On 10/08/2013 01:02 AM, Mark Rutland wrote:
+&mcasp1 {
>+ pinctrl-names = "default";
>+ pinctrl-0 = <&am335x_evm_audio_pins>;
I didn't see mention of pinctrl added to the binding. It should be.
I'll add that. Thanks!
Cheers,
Jyri
--
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: [RESEND PATCH v3 10/11] ARM/dts: am33xx: mcasp: Add new dma register location to reg-property
On 10/08/2013 01:00 AM, Mark Rutland wrote: For consistency with reg and other composite value properties, I'd prefer that each entry in the list were individually bracketed: dmas = <&edma 8>, <&edma 9>; Makes sense. I'll do that. Thanks! It would also be nice if interrupts were written this way. I'll change that too. Cheers, Jyri -- 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 1/6] DRIVERS: IRQCHIP: IRQ-GIC: Add support for routable irqs
On Mon, Sep 30, 2013 at 4:16 PM, Marc Zyngier wrote: > On 30/09/13 14:59, Sricharan R wrote: >> In some socs the gic can be preceded by a crossbar IP which >> routes the peripheral interrupts to the gic inputs. The peripheral >> interrupts are associated with a fixed crossbar input line and the >> crossbar routes that to one of the free gic input line. >> >> The DT entries for peripherals provides the fixed crossbar input line >> as its interrupt number and the mapping code should associate this with >> a free gic input line. This patch adds the support inside the gic irqchip >> to handle such routable irqs. The routable irqs are registered in a linear >> domain. The registered routable domain's callback should be implemented >> to get a free irq and to configure the IP to route it. > > Isn't this just another chained interrupt controller? How is it GIC > specific? I thought so from the beginning but I was dead wrong, as pointed out by tglx it is basically a hardware .map function, so its usecase will map to the irqdomain .map/.unmap so to say. Yours, Linus Walleij -- 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] usb: musb: dsps: disable the otg_timer while going to sleep
Testing with "freeze" I run into: | PM: Syncing filesystems ... done. | PM: Preparing system for freeze sleep | Freezing user space processes ... (elapsed 0.002 seconds) done. | Freezing remaining freezable tasks ... (elapsed 0.002 seconds) done. | PM: Entering freeze sleep | usb usb2: usb auto-resume | hub 2-0:1.0: hub_resume | hub 2-0:1.0: hub_suspend | usb usb2: bus suspend, wakeup 0 | usb usb1: usb auto-resume | hub 1-0:1.0: hub_resume | hub 1-0:1.0: hub_suspend | usb usb1: bus suspend, wakeup 0 | PM: suspend of devices complete after 54.622 msecs | PM: late suspend of devices complete after 4.782 msecs | PM: noirq suspend of devices complete after 4.990 msecs | Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0442460 | Internal error: : 1008 [#1] ARM | PC is at otg_timer+0x28/0x140 [musb_dsps] This is comming from first dsps_readb() in otg_timer(). The problem is that the device is already suspended (the clocks are off) and the timer tries to access register which fails. Since there is no need to keep this timer aroud while the device is going to suspend I suggest to remove the timer in suspend and queue it in the resume path. Signed-off-by: Sebastian Andrzej Siewior --- I don't have the "suspend" target in "state" just the "freezer" and with it I get into trouble in the otg_timer(). This triggers a few seconds after the suspend but since this depends on timming, it might trigger just a few secs after the suspend. What about the this? drivers/usb/musb/musb_dsps.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c index ced2b76..61b3f3e 100644 --- a/drivers/usb/musb/musb_dsps.c +++ b/drivers/usb/musb/musb_dsps.c @@ -659,6 +659,7 @@ static int dsps_suspend(struct device *dev) glue->context.tx_mode = dsps_readl(mbase, wrp->tx_mode); glue->context.rx_mode = dsps_readl(mbase, wrp->rx_mode); + del_timer_sync(&glue->timer); return 0; } @@ -679,6 +680,7 @@ static int dsps_resume(struct device *dev) musb->port_reset_state = false; schedule_work(&musb->port_reset_work); + mod_timer(&glue->timer, jiffies + wrp->poll_seconds * HZ); return 0; } -- 1.8.4.rc3 -- 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: [RESEND PATCH v3 05/11] ASoC: davinci-mcasp: Interrupts property to optional and add interrupt-names
On 10/08/2013 12:56 AM, Mark Rutland wrote: On Thu, Sep 26, 2013 at 08:18:30PM +0100, Jyri Sarha wrote: +- interrupts : Interrupt numbers for McASP, currently not used by the driver >+- interrupt-names : Known interrupt names are "tx" and "rx" Are these_all_ the interrupts the McASP may generate? I was under the impression there were also separate interrupts for errors. Those were all I could find from AM335X TRM. Cheers, Jyri -- 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: mach-omap1: Fix omap1510_fpga_init_irq() implicit declarations.
This patch adds a omap1510_fpga_init_irq() inline dummy implementations
in arch/arm/mach-omap1/common.h. Without this patch,build system can
lead to issues. This was discovered during randconfig testing,in which
other than CONFIG_ARCH_OMAP15XX was enabled the leading to the following
error:
CC arch/arm/mach-omap1/board-innovator.o
arch/arm/mach-omap1/board-innovator.c: In function ‘innovator_init’:
arch/arm/mach-omap1/board-innovator.c:377:3: error: implicit declaration of
function ‘omap1510_fpga_init_irq’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [arch/arm/mach-omap1/board-innovator.o] Error 1
make: *** [arch/arm/mach-omap1] Error 2
Signed-off-by: Manjunath Goudar
Cc: Tony Lindgren
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
arch/arm/mach-omap1/common.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap1/common.h b/arch/arm/mach-omap1/common.h
index abec019..732f8ee 100644
--- a/arch/arm/mach-omap1/common.h
+++ b/arch/arm/mach-omap1/common.h
@@ -46,6 +46,9 @@ static inline void omap7xx_map_io(void)
void omap1510_fpga_init_irq(void);
void omap15xx_map_io(void);
#else
+static inline void omap1510_fpga_init_irq(void)
+{
+}
static inline void omap15xx_map_io(void)
{
}
--
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
[PATCH v2 1/6] ARM: OMAP5: hwmod data: Add USB Host and TLL modules
Add hwmod data for High Speed USB host and TLL modules
CC: Paul Walmsley
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 135
1 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 1a21a81..1dd2c20 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1501,6 +1501,123 @@ static struct omap_hwmod omap54xx_uart6_hwmod = {
};
/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= &omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_usb_host_hs_hwmod_class = {
+ .name = "usb_host_hs",
+ .sysc = &omap54xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod omap54xx_usb_host_hs_hwmod = {
+ .name = "usb_host_hs",
+ .class = &omap54xx_usb_host_hs_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ /*
+* Errata: USBHOST Configured In Smart-Idle Can Lead To a Deadlock
+* id: i660
+*
+* Description:
+* In the following configuration :
+* - USBHOST module is set to smart-idle mode
+* - PRCM asserts idle_req to the USBHOST module ( This typically
+* happens when the system is going to a low power mode : all ports
+* have been suspended, the master part of the USBHOST module has
+* entered the standby state, and SW has cut the functional clocks)
+* - an USBHOST interrupt occurs before the module is able to answer
+* idle_ack, typically a remote wakeup IRQ.
+* Then the USB HOST module will enter a deadlock situation where it
+* is no more accessible nor functional.
+*
+* Workaround:
+* Don't use smart idle; use only force idle, hence HWMOD_SWSUP_SIDLE
+*/
+
+ /*
+* Errata: USB host EHCI may stall when entering smart-standby mode
+* Id: i571
+*
+* Description:
+* When the USBHOST module is set to smart-standby mode, and when it is
+* ready to enter the standby state (i.e. all ports are suspended and
+* all attached devices are in suspend mode), then it can wrongly assert
+* the Mstandby signal too early while there are still some residual OCP
+* transactions ongoing. If this condition occurs, the internal state
+* machine may go to an undefined state and the USB link may be stuck
+* upon the next resume.
+*
+* Workaround:
+* Don't use smart standby; use only force standby,
+* hence HWMOD_SWSUP_MSTANDBY
+*/
+
+ /*
+* During system boot; If the hwmod framework resets the module
+* the module will have smart idle settings; which can lead to deadlock
+* (above Errata Id:i660); so, dont reset the module during boot;
+* Use HWMOD_INIT_NO_RESET.
+*/
+
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_RESET,
+ .main_clk = "l3init_60m_fclk",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
OMAP54XX_CM_L3INIT_USB_HOST_HS_CLKCTRL_OFFSET,
+ .context_offs =
OMAP54XX_RM_L3INIT_USB_HOST_HS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
+ * 'usb_tll_hs' class
+ * usb_tll_hs module is the adapter on the usb_host_hs ports
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_usb_tll_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= &omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_usb_tll_hs_hwmod_class = {
+ .name = "usb_tll_hs",
+ .sysc = &omap54xx_usb_tll_hs_sysc,
+};
+
+static struct omap_hwmod omap54xx_usb_tll_hs_hwmod = {
+ .name = "usb_tll_hs",
+ .class = &omap54xx_usb_tll_hs_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk
[PATCH v2 2/6] ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module
USB Host driver (drivers/mfd/omap-usb-host.c) expects the 60MHz
reference clock to be named "init_60m_fclk". Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index edc801f..6f98be2 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -703,6 +703,8 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&l3init_60m_fclk>;
+ clock-names = "init_60m_fclk";
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
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 v2 4/6] ARM: dts: omap5-uevm: Provide USB PHY clock
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 748f6bf..6a0d73c 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80
HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = <&auxclk1>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk1_ck>;
+ clock-names = "main_clk";
clock-frequency = <1920>;
};
--
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 v2 0/6] Add USB Host support for OMAP5 uevm for 3.13
Hi, This patch series provide USB host support for the OMAP5 uEVM board. As ethernet port is over USB, it brings up ethernet as well. Series depends on the OMAP clock tree DT data series by Tero Kristo [1] Tested on OMAP5 uEVM and OMAP4 Panda. cheers, -roger [1] - OMAP Clock DT conversion http://www.spinics.net/lists/arm-kernel/msg275311.html Roger Quadros (6): ARM: OMAP5: hwmod data: Add USB Host and TLL modules ARM: dts: OMAP5: Add 60MHz clock reference to USB Host module ARM: dts: omap4-panda: Provide USB PHY clock ARM: dts: omap5-uevm: Provide USB PHY clock Revert "ARM: OMAP2+: Provide alias to USB PHY clock" mfd: omap-usb: prepare/unprepare clock while enable/disable arch/arm/boot/dts/omap4-panda-common.dtsi |8 +-- arch/arm/boot/dts/omap5-uevm.dts |8 +-- arch/arm/boot/dts/omap5.dtsi |2 + arch/arm/mach-omap2/board-generic.c| 23 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 135 drivers/mfd/omap-usb-host.c| 16 ++-- drivers/mfd/omap-usb-tll.c |4 +- 7 files changed, 152 insertions(+), 44 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 v2 5/6] Revert "ARM: OMAP2+: Provide alias to USB PHY clock"
This reverts commit 741532c4a995be11815cb72d4d7a48f442a22fea.
The proper clock reference is provided in device tree so we
no longer need this.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/board-generic.c | 23 +--
1 files changed, 1 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index cd85b36..da4e9b2 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
@@ -36,21 +35,6 @@ static struct of_device_id omap_dt_match_table[] __initdata
= {
{ }
};
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias("main_clk", NULL, clkname, NULL);
- if (ret) {
- pr_err("%s:Failed to add main_clk alias to %s :%d\n",
- __func__, clkname, ret);
- }
-}
-
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
@@ -61,15 +45,10 @@ static void __init omap_generic_init(void)
* HACK: call display setup code for selected boards to enable omapdss.
* This will be removed when omapdss supports DT.
*/
- if (of_machine_is_compatible("ti,omap4-panda")) {
+ if (of_machine_is_compatible("ti,omap4-panda"))
omap4_panda_display_init_of();
- legacy_init_ehci_clk("auxclk3_ck");
-
- }
else if (of_machine_is_compatible("ti,omap4-sdp"))
omap_4430sdp_display_init_of();
- else if (of_machine_is_compatible("ti,omap5-uevm"))
- legacy_init_ehci_clk("auxclk1_ck");
}
#ifdef CONFIG_SOC_OMAP2420
--
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 v2 6/6] mfd: omap-usb: prepare/unprepare clock while enable/disable
This should fix the following warning at boot on OMAP5 uEVM
[8.783155] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:883
__clk_enable+0x94/0xa4()
CC: Samuel Ortiz
CC: Lee Jones
CC: Tero Kristo
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 16
drivers/mfd/omap-usb-tll.c |4 ++--
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 29ee54d..a5b91f1 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -328,13 +328,13 @@ static int usbhs_runtime_resume(struct device *dev)
omap_tll_enable(pdata);
if (!IS_ERR(omap->ehci_logic_fck))
- clk_enable(omap->ehci_logic_fck);
+ clk_prepare_enable(omap->ehci_logic_fck);
for (i = 0; i < omap->nports; i++) {
switch (pdata->port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
if (!IS_ERR(omap->hsic60m_clk[i])) {
- r = clk_enable(omap->hsic60m_clk[i]);
+ r = clk_prepare_enable(omap->hsic60m_clk[i]);
if (r) {
dev_err(dev,
"Can't enable port %d hsic60m
clk:%d\n",
@@ -343,7 +343,7 @@ static int usbhs_runtime_resume(struct device *dev)
}
if (!IS_ERR(omap->hsic480m_clk[i])) {
- r = clk_enable(omap->hsic480m_clk[i]);
+ r = clk_prepare_enable(omap->hsic480m_clk[i]);
if (r) {
dev_err(dev,
"Can't enable port %d hsic480m
clk:%d\n",
@@ -354,7 +354,7 @@ static int usbhs_runtime_resume(struct device *dev)
case OMAP_EHCI_PORT_MODE_TLL:
if (!IS_ERR(omap->utmi_clk[i])) {
- r = clk_enable(omap->utmi_clk[i]);
+ r = clk_prepare_enable(omap->utmi_clk[i]);
if (r) {
dev_err(dev,
"Can't enable port %d clk : %d\n",
@@ -382,15 +382,15 @@ static int usbhs_runtime_suspend(struct device *dev)
switch (pdata->port_mode[i]) {
case OMAP_EHCI_PORT_MODE_HSIC:
if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_disable(omap->hsic60m_clk[i]);
+ clk_disable_unprepare(omap->hsic60m_clk[i]);
if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_disable(omap->hsic480m_clk[i]);
+ clk_disable_unprepare(omap->hsic480m_clk[i]);
/* Fall through as utmi_clks were used in HSIC mode */
case OMAP_EHCI_PORT_MODE_TLL:
if (!IS_ERR(omap->utmi_clk[i]))
- clk_disable(omap->utmi_clk[i]);
+ clk_disable_unprepare(omap->utmi_clk[i]);
break;
default:
break;
@@ -398,7 +398,7 @@ static int usbhs_runtime_suspend(struct device *dev)
}
if (!IS_ERR(omap->ehci_logic_fck))
- clk_disable(omap->ehci_logic_fck);
+ clk_disable_unprepare(omap->ehci_logic_fck);
omap_tll_disable(pdata);
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
index e59ac4c..1e57712 100644
--- a/drivers/mfd/omap-usb-tll.c
+++ b/drivers/mfd/omap-usb-tll.c
@@ -429,7 +429,7 @@ int omap_tll_enable(struct usbhs_omap_platform_data *pdata)
if (IS_ERR(tll->ch_clk[i]))
continue;
- r = clk_enable(tll->ch_clk[i]);
+ r = clk_prepare_enable(tll->ch_clk[i]);
if (r) {
dev_err(tll_dev,
"Error enabling ch %d clock: %d\n", i, r);
@@ -460,7 +460,7 @@ int omap_tll_disable(struct usbhs_omap_platform_data *pdata)
for (i = 0; i < tll->nch; i++) {
if (omap_usb_mode_needs_tll(pdata->port_mode[i])) {
if (!IS_ERR(tll->ch_clk[i]))
- clk_disable(tll->ch_clk[i]);
+ clk_disable_unprepare(tll->ch_clk[i]);
}
}
--
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 v2 3/6] ARM: dts: omap4-panda: Provide USB PHY clock
The USB PHY gets its clock from AUXCLK3. Provide this information. Signed-off-by: Roger Quadros --- arch/arm/boot/dts/omap4-panda-common.dtsi |8 ++-- 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 3e6801c..f90a1d4 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -83,12 +83,8 @@ compatible = "usb-nop-xceiv"; reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */ vcc-supply = <&hsusb1_power>; - /** -* FIXME: -* put the right clock phandle here when available -* clocks = <&auxclk3>; -* clock-names = "main_clk"; -*/ + clocks = <&auxclk3_ck>; + clock-names = "main_clk"; clock-frequency = <1920>; }; -- 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: [RESEND PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT
Hi, On 10/08/2013 12:13 PM, Jyri Sarha wrote: >> I have some questions however. I took a look at the McASP (TMS320C6000) >> reference guide, and the registers appeared to all be in one contiguous >> bank, and "mpu" and "dma" don't appear to be names of particular >> registers or names of banks of particular registers. Am I looking in the >> wrong place? Is there up-to-date documentation I can look at? >> >> Why are these split across two reg entries, and which particular >> registers do they actually cover? > > The need for two different register properties does not come from McASP > IP, but from SoC design. On AM33XX the McASP registers are mapped for MPU > through L4 bus, which is no accessible to the DMA controller. The McASP > data port registers are mapped trough L3 buss to a different address for > DMA controller. Maybe the second register property could be called to "dat" > instead of "dma" since only data port registers are mapped trough that > address. We have discussed this with Jyri and we are going to use 'dat' for the data port address. The driver can configure the IP via the 'mpu' area but it is preferred to use the 'dat' or data port of McASP when it comes to data. It is possible to use the transmit/receive buffer registers in the 'mpu' area but it get's complicated when more than one serializer is used. >>> - op-mode : I2S/DIT ops mode. >> >> What type is this? > > That property selects whether McASP is working in I2S mode or in > Integrated Digital audio interface Transmitter (DIT) mode for S/PDIF, > IEC60958-1, AES-3 formats. Not sure but we might be able to handle this via standard ASoC way, via the da_fmt so the machine driver will tell the mcasp driver what is the format it needs to send the data. Adding SND_SOC_DAIFMT_SPDIF/IEC60958/AES3 to core will be needed. > >> >> What are valid values? > > 0 and 1. I'll document those. Thanks. > >>> - tdm-slots : Slots for TDM operation. >> >> Here too. This description is completely opaque. >> > > I am not absolutely sure here. I'll check the details and try to come up > with a better description. Not sure about this either, my interpretation of what it means: number of channels to be sent via one serializer. as an example: We have 3 stereo codecs in the design all of them are connected to the same McASP instance but to be fed via different serializer: AXR0 - codec0 AXR1 - codec1 AXR2 - codec2 Since the codecs are stereo -> tdm-slots = <2>; two channels/serializer If the stream is stereo we only ouput to codec0 via AXR0. If the stream is 4 channel, the first 2 channels will be via AXR0 to codec0 the next 2 channles will be sent to codec1 via AXR1. and so on. I think it would be possible to extract this information from the serial-dir property + machine driver configured DAI_FMT and from the coming stream. I2S, L/R justified is stereo, in DSP modes we can have more channels. In the serial-dir array we could count the AXR directions. Basically all the information which is needed to make this redundant are there. But we have the legacy davinci users at the same time and we do not want to break eisting users. I think Daniel Mack (CCd) can clarify my understanding of the tdm-slots. >> It looks like some pins can be used as GPIO -- is there not a need for >> something like pinctrl for configuring this? >> > > That is true, but since driver does not support it and there is no example > of GPIO usage, no guess work has been done about the required DT > properties. This is kind of complicated issue. Any of the McASP pins (CLK, FS, AXR, etc) can be configured to be used as McASP pins or GPIO pins. This configuration is McASP IP specific, need to be done within McASP. pinctrl is overkill for this IMHO but we would need a gpio driver for McASP. If some driver requests a gpio in McASP we can just switch that pin to GPIO mode, however this brings up quite a bit of questions: - embedd the gpio driver into the dai driver? - if the system does not have audio -> no GPIO driver for the rest? - separate driver for gpio functionality? - Sanity cheks all over the place on which pin is GPIO or McASP. and so forth. -- Péter -- 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: [RESEND PATCH v3 03/11] ASoC: davinci-mcasp: Add DMA register locations to DT
On 10/08/2013 12:47 AM, Mark Rutland wrote:
Hello,
Hi!
I am not the author of this driver so my knowledge may have gaps, when
it comes to details I have not touched yet. Anyway, I do my best to
address your comments.
...
-- reg : Should contain McASP registers offset and length
+- reg : Should contain McASP registers address and length for mpu and
+ optionally for dma controller access.
+- reg-names : The mandatory reg-range must be named "mpu" and the optional DMA
+ reg-range must be named "dma". For backward compatibility it is
+ good to keep "mpu" first in the list.
I've never heard the term "reg-range" before. The should probably be something
like "reg entry". How about something like the following instead:
Well, an address and length describes a "range", but if it is not
commonly used term, there is no need to use it here either.
- reg: Should contain reg specifiers for the entries in the reg-names property.
- reg-names: Should contain:
* "mpu" for the main registers (required). For compatibility with
existing software, it is recommended this is the first entry.
* "dma" for the DMA registers (optional).
That way we don't end up describing each reg entry twice.
The both contain the same information, but your version is certainly
easier to read. I'll take it. Thanks!
I have some questions however. I took a look at the McASP (TMS320C6000)
reference guide, and the registers appeared to all be in one contiguous bank,
and "mpu" and "dma" don't appear to be names of particular registers or names
of banks of particular registers. Am I looking in the wrong place? Is there
up-to-date documentation I can look at?
Why are these split across two reg entries, and which particular registers do
they actually cover?
The need for two different register properties does not come from McASP
IP, but from SoC design. On AM33XX the McASP registers are mapped for
MPU through L4 bus, which is no accessible to the DMA controller. The
McASP data port registers are mapped trough L3 buss to a different
address for DMA controller. Maybe the second register property could be
called to "dat" instead of "dma" since only data port registers are
mapped trough that address.
I have some concern about the description of other properties too. If we're
going to amend the binding, they should be fixed up too.
- interrupts : Interrupt number for McASP
The device also seems to be able to generate multiple interrupts -- which
interrupt does this actually cover?
The driver doesn't seem to use it (by a grep of irq|interrupt). Have I missed
something?
No you have not. A later patch in this set make the interrupt property
optional and adds "tx" and "rx" interrupt-names:
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066732.html
- op-mode : I2S/DIT ops mode.
What type is this?
That property selects whether McASP is working in I2S mode or in
Integrated Digital audio interface Transmitter (DIT) mode for S/PDIF,
IEC60958-1, AES-3 formats.
What are valid values?
0 and 1. I'll document those. Thanks.
- tdm-slots : Slots for TDM operation.
Here too. This description is completely opaque.
I am not absolutely sure here. I'll check the details and try to come up
with a better description.
Talking about num-serializer and serial-dir property here...
Taking a look at the version in kernel sources this appears to be a list of
values, in groups of four?
What is the format of this property?
@@ -15,7 +19,6 @@ Required properties:
to "num-serializer" parameter. Each entry is a number indication
serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
-
The McASP can have up to 16 serializers for selecting data pin usage.
The numbers have been grouped into 4x4 matrix only for better
readability. BTW, the num-serializers property is redundant and it will
be removed in the next version of the patch series.
Optional properties:
- ti,hwmods : Must be "mcasp", n is controller instance starting 0
@@ -31,6 +34,7 @@ mcasp0: mcasp0@1d0 {
#address-cells = <1>;
#size-cells = <0>;
Why does this have #address-cells and #size-cells? There are no children in the
example.
I removed those from the actual dts file, but forgot to do so here. I'll
fix that. Thanks!
reg = <0x10 0x3000>;
+ reg-names "mpu";
interrupts = <82 83>;
op-mode = <0>;/* MCASP_IIS_MODE */
tdm-slots = <2>;
A few questions from a brief skim of the documentation:
There seem to be external clocks (AHCLKR and ACLKR), but they aren't described.
Are we always able to use an internal clock instead? Is no external reference
clock needed?
As far as I understand the choice is to use either McASP internal clock
or codec provided clock. The selection is made by the machine/platform
driver by calling snd_soc_dai_set_fmt() an
[PATCH] ARM: mach-omap2: board-generic: fix undefined symbol
Since dra7 reuses the function 'omap5_realtime_timer_init' in
arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
built for this SoC as well.
Signed-off-by: Simon Barth
---
arch/arm/mach-omap2/timer.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index fa74a06..ead48fa 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -628,7 +628,7 @@ void __init omap4_local_timer_init(void)
#endif /* CONFIG_HAVE_ARM_TWD */
#endif /* CONFIG_ARCH_OMAP4 */
-#ifdef CONFIG_SOC_OMAP5
+#if defined(CONFIG_SOC_OMAP5) || defined(CONFIG_SOC_DRA7XX)
void __init omap5_realtime_timer_init(void)
{
omap4_sync32k_timer_init();
@@ -636,7 +636,7 @@ void __init omap5_realtime_timer_init(void)
clocksource_of_init();
}
-#endif /* CONFIG_SOC_OMAP5 */
+#endif /* CONFIG_SOC_OMAP5 || CONFIG_SOC_DRA7XX */
/**
* omap_timer_init - build and register timer device with an
--
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: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
On 10/08/2013 08:40 AM, Mike Turquette wrote: Quoting Tero Kristo (2013-09-25 01:48:06) Hi all, Version 7 contains following high level changes: - Dropped support for basic bindings from Mike Turquette, instead using vendor specific bindings for all clocks - Mux clock + divider clock vendor specific bindings get rid of use of the bit-masks, instead these are generated runtime based on parent clock / divider min/max info, see individual patches for details - Added support for dummy_ck nodes, was missing from previous version - Fixed support for omap3630 - Added support for new clock node type: ti,mux-gate-clock (using composite clock type) - OMAP4 / OMAP5 only build fixes (compiler flag checks added to some files) - most of the of_omap_* calls renamed to of_ti_* - Rebased on top of v3.12-rc2 Hi Tero, I had one really minor request for one of the patches, otherwise I'm pretty happy with this series and I can take in the clock parts for 3.13. A few general comments: Yea, I'll add the is_enabled check to the APLL and repost. 1) I think I mentioned some time back that it would be wise to put a disclaimer at the top of each DT binding description stating something to the effect: "Binding status: Unstable - ABI compatibility may be broken in the future". Are you OK merging these bindings as-is without that kind of a disclaimer? Well, personally I don't mind, but if you think this would be good, I'll add this to next rev. 2) I hope to see the clockdomain stuff go away in the future. I'm OK to take it for now to aid in this DT transition but I would like some commitment that it will not stay in drivers/clk/omap forever. I guess for clockdomain you'll need to figure out how to handle those in a generic driver way. I think the clockdomain stuff should be possible to move to wherever CM driver is going to move. drivers/power/omap/... or something maybe. I have been starting some initial work on the CM driver cleanup for this purpose. 3) Same concern as above but for the DT clkdev alias stuff. I guess you'll need to make all of the dependent drivers play nice with DT. Do you plan to remove it within a reasonable timeframe? It would be a nice reduction in LoC and more importantly it would mean that drivers were using clkdev in a more-correct fashion. This is probably harder, I think Tony is better to comment here, but my idea is that in the worst case we can just break non-conforming drivers by dropping the clkdev tables if nothing else helps. :) Most of the tables are currently needed by hwmod, and there are already patches around for adding DT clock support for hwmods, so once these go in, we can at least reduce the table sizes considerably already. -Tero Regards, Mike Some detailed comments about patch level changes (if no mention, no major changes): - Patch #1: * removed use of reg-names property, instead registers mapped using compatible string * removed ti,modes property, instead uses DPLL mode flags now * separated AM33XX DPLLs under their own compatible strings - Patch #4 & #5: new patches - Patch #6: merged basic gate support from Mike to this patch as vendor specific gate clock support - Patch #9 & #10: new patches - Patch #11: dummy clocks added, USB / ABE DPLL setup ordering changed - Patch #14: dummy clocks added - Patch #20: dropped usage of reg-names property - Patch #21: dummy clocks added - Patch #22 & #23: new patches - Patch #30: AM35XX clock data added to this patch - Patch #31: * dummy clocks added * added missing 3630 clocks Test branch available here: https://github.com/t-kristo/linux-pm.git branch: mainline-3.12-rc2-ti-dt-clks-v7 Testing done: - am335x-bone : boot only - omap5-sevm : boot only - dra7-evm : boot only - omap3-beagle : boot + suspend/resume (ret + off) - omap4-panda-es : boot + suspend/resume Nishanth has also been doing some tests with omap3-beagle-xm with some WIP versions of this branch, but not with this latest one. Nishanth, maybe you can provide test results to this one also? -Tero -- 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 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On Tue, Oct 08, 2013 at 09:13:16AM +0200, Ben Dooks wrote:
> On 08/09/13 09:43, Pali Rohár wrote:
>> Here is new version (v4) of omap secure part patch:
>>
>> Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
>> but Nokia RX-51 board needs to call smc #1 for PPA access.
>>
>> Signed-off-by: Ivaylo Dimitrov
>> Signed-off-by: Pali Rohár
>> ---
>> diff --git a/arch/arm/mach-omap2/omap-secure.h
>> b/arch/arm/mach-omap2/omap-secure.h
>> index 0e72917..c4586f4 100644
>> --- a/arch/arm/mach-omap2/omap-secure.h
>> +++ b/arch/arm/mach-omap2/omap-secure.h
>> @@ -51,6 +51,7 @@
>> extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
>> u32 arg1, u32 arg2, u32 arg3, u32 arg4);
>> extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
>> +extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
>> extern phys_addr_t omap_secure_ram_mempool_base(void);
>> extern int omap_secure_ram_reserve_memblock(void);
>>
>> diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
>> index f6441c1..fd90125 100644
>> --- a/arch/arm/mach-omap2/omap-smc.S
>> +++ b/arch/arm/mach-omap2/omap-smc.S
>> @@ -1,9 +1,11 @@
>> /*
>> - * OMAP44xx secure APIs file.
>> + * OMAP34xx and OMAP44xx secure APIs file.
>>*
>>* Copyright (C) 2010 Texas Instruments, Inc.
>>* Written by Santosh Shilimkar
>>*
>> + * Copyright (C) 2012 Ivaylo Dimitrov
>> + * Copyright (C) 2013 Pali Rohár
>>*
>>* This program is free software,you can redistribute it and/or modify
>>* it under the terms of the GNU General Public License version 2 as
>> @@ -54,6 +56,23 @@ ENTRY(omap_smc2)
>> ldmfd sp!, {r4-r12, pc}
>> ENDPROC(omap_smc2)
>>
>> +/**
>> + * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
>> + * Low level common routine for secure HAL and PPA APIs via smc #1
>> + * r0 - @service_id: Secure Service ID
>> + * r1 - @process_id: Process ID
>> + * r2 - @flag: Flag to indicate the criticality of operation
>> + * r3 - @pargs: Physical address of parameter list
>> + */
>> +ENTRY(omap_smc3)
>> +stmfd sp!, {r4-r11, lr}
>> +mov r12, r0 @ Copy the secure service ID
>
> I think you should save r12 in the call.
Not necessary.
--
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 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On 08/09/13 09:43, Pali Rohár wrote:
Here is new version (v4) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..fd90125 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* This program is free software,you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
I think you should save r12 in the call.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
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
Important Information
Hello, Compliments and good day to you and your family. I write you this mail as a reminder once more having waited patiently for your response to my initial contact with you through snail mail. However since I assume you did not get it I want to use this medium even though it might not be the best form of communication in matters like this due to the ever growing disbelief and illicit scams and fraud associated with it, I seem to have no choice than to make use of it, coupled with the fact that it might be just perfect due to the ability to redeem time. Without wasting much of your time I am Mrs. Supini Thrunkul, an accountant with China Minsheng Banking Corporation Limited I want to bring you into a business venture which I think should be of interest and concern to you, since it has to do with a perceived family member of yours this is because there is a substantial amount of funds which I suspect is tied to a distant family member of yours. However I need to be sure that you must have received this communication so I will not divulge much information about it until i get a response from you. Kindly respond back to me. Best Regards, Mrs.Supini Thrunkul -- 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: [RESEND PATCH v3 04/11] ASoC: davinci-mcasp: Extract DMA channels directly from DT
On 10/08/2013 12:53 AM, Mark Rutland wrote: On Thu, Sep 26, 2013 at 08:18:29PM +0100, Jyri Sarha wrote: >Extract DMA channels directly from DT as they can not be found from >platform resources anymore. This is a work-around until davinci audio >driver is updated to use dmaengine. How long will this conversion take? That is uncertain, definitely not in time for v3.13. Best regards, Jyri -- 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
