Re: [PATCH v3 02/12] ARM: edma: Don't clear EMR of channel in edma_stop
On Monday 12 August 2013 09:59 AM, Joel Fernandes wrote: On Sun, Aug 11, 2013 at 11:25 PM, Sekhar Nori nsek...@ti.com wrote: On 8/8/2013 5:19 PM, Sekhar Nori wrote: On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote: We certainly don't want error conditions to be cleared any other place but the EDMA error handler, as this will make us 'forget' about missed events we might need to know errors have occurred. This fixes a race condition where the EMR was being cleared by the transfer completion interrupt handler. Basically, what was happening was: Missed event | | V SG1-SG2-SG3-Null \ \__TC Interrupt (Almost same time as ARM is executing TC interrupt handler, an event got missed and also forgotten by clearing the EMR). This causes the following problems: 1. If error interrupt is also pending and TC interrupt clears the EMR by calling edma_stop as has been observed in the edma_callback function, the ARM will execute the error interrupt even though the EMR is clear. As a result, the dma_ccerr_handler returns IRQ_NONE. If this happens enough number of times, IRQ subsystem disables the interrupt thinking its spurious which makes error handler never execute again. 2. Also even if error handler doesn't return IRQ_NONE, the removing of EMR removes the knowledge about which channel had a missed event, and thus a manual trigger on such channels cannot be performed. The EMR is ultimately being cleared by the Error interrupt handler once it is handled so we remove code that does it in edma_stop and allow it to happen there. Signed-off-by: Joel Fernandes jo...@ti.com Queuing this for v3.11 fixes. While committing, I changed the headline to remove capitalization and made it more readable by removing register level details. The new headline is: ARM: edma: don't clear missed events in edma_stop() Forgot to ask, should this be tagged for stable? IOW, how serious is this race in current kernel (without the entire series applied)? I have never observed it myself - so please provide details how easy/difficult it is to hit this condition. The race was uncovered by recent EDMA patch series, So this patch can go in for next kernel release as such, I am not aware of any other DMA user that maybe uncovering the race condition. Okay, I wont queue for -rc then. If Vinod wants to take this along with rest of the series, you can add my: Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- 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: RX51: kernel message spam from CPUfreq driver
On Sunday 11 August 2013 07:43 PM, Sebastian Reichel wrote: Hi, On RX-51 (Nokia N900) the (mainline) kernel constantly outputs the following message about 2-3x per second since some releases: [ 1038.314514] cpu cpu0: CPUfreq: Cannot find matching frequency for 12500 (The message is from drivers/cpufreq/omap-cpufreq.c, line 100) This is really annoying and makes debug output without a grep -v basically useless. Can you give me some hints how to solve the problem? Whats the system clock frequency used on RX-51? I guess omap2_dpll_round_rate() for some reason thinks that with the given sys clock its not possible to lock the DPLL at 125Mhz. If you can send the debug logs from omap2_dpll_round_rate() that should probably help know whats going wrong. -- 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 0/9] DRA7xx core support
On Sunday 04 August 2013 09:57 PM, Rajendra Nayak wrote: Changes in v3: -1- Dropped some clock/dpll framework builds for dra7 -2- Added all instances of IPs in dtsi file -3- dtsi does a 'disabled' by default and dts enables as needed -4- soc_is_dra7xx() based on DT compatible instead of using ID code Changes in v2: -1- Fixed minor changelog details -2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files) -4- Updated the EVM dts file with pin config details for uart/mcspi and i2c DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology. The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC. Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support. This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot. Tony, any chance of this series making it to 3.12? regards, Rajendra The bootloader support for the platform is already available in mainline u-boot. The patches posted in this series are available at: git://github.com/rrnayak/linux.git for-3.12/dra-core-v3 The patches (including the ones for in-kernel data) which boot on dra7xx evm are available at: t://github.com/rrnayak/linux.git out-of-tree/dra-integrated-v3 R Sricharan (8): ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512 ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Add the build support in omap2plus Rajendra Nayak (1): ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/Kconfig |2 +- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts | 140 + arch/arm/boot/dts/dra7.dtsi| 567 arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig| 12 +- arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/board-generic.c| 18 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c |4 +- arch/arm/mach-omap2/io.c | 20 +- arch/arm/mach-omap2/omap54xx.h |4 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 17 + arch/arm/mach-omap2/timer.c|3 +- arch/arm/plat-omap/Kconfig |2 +- 18 files changed, 795 insertions(+), 11 deletions(-) create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi -- 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: AM4372: add few nodes
Hi Mark,
On Saturday 10 August 2013 07:53 PM, Mark Rutland wrote:
+ mac: ethernet@4a10 {
+ compatible = ti,am4372-cpsw,ti,cpsw;
One point worth mentioning is that the ti,am4372-cpsw string isn't
documented. Will the ti,am4372-cpsw binding definitely be a superset
of the ti,cpsw binding, and if you were to take the DT as of this
patch, and attempt to use it with a future kernel, can you guarantee
it'll work?
ti,am4372-cpsw was not documented as OMAP DT maintainer didn't prefer
documenting only for a new compatible.
For the only patch on this file that went into mainline, in that series
actually I had posted patches to document ti,am4372-*, but as
maintainer didn't agree, it was discarded [A].
Regarding whether ti,am4372-cpsw would be a superset of ti,cpsw,
information I have (am4372 is in pre silicon stage) is that it is a
reuse from am335x (ti,cpsw should have been named ti,am3352-cpsw or
something like that, but nothing can be done now) with minor changes and
all existing functionalities available, Mugunthan can shed more light on
this, Mugunthan ?
As mentioned at other places in the thread, for cpsw, only a few
properties to prevent hwmod code crash was added. I am sure that
currently added properties for cpsw will not make driver functional this
Kernel version (if this goes in) or future versions. To make driver work
additional properties are required.
There are many other parameters which are missed here.
Reason has been mentioned in the commit message, quoting relevant here
again,
Actually, as you've marked the nodes disabled, it's probably fine. But
worth considering as properties are added...
There were two factors that was considered while adding cpsw node
1. DT as an ABI
2. While adding DT node, whether all existing required properties has to
be added
Regarding 1 - DT would not make driver work for this Kernel version and
also for not any newer Kernel version, I believe this does not go
against DT an an ABI, although in a negative sense. To make driver work
more DT properties would have to be added.
Regarding 2 - Currently, I believe most required optional properties
in bindings are defined w.r.t driver (bringing in a Linux attachment).
If DT is only a hardware description, required optional properties
should correspond to something that are a must for hardware to work and
additional features that can be used respectively. In that sense
interrupts property for many of the peripherals would have to be
considered optional, as it is possible to work in polling mode. And
would it be practical for DT in most of the cases to be a complete
hardware description ?, as to completely describe hardware, we may need
to have a large amount of properties that may not be relevant to
software. If requirement is only that DT should describe hardware that
is relevant for software (this would bring in a software dependency for
DT), required property for one software may not be required for another
piece of software or may be an optional property (like in the case of
interrupts as explained above).
So conclusion arrived within me was that as long as properties are not
modified, but only added and as long as it does not go against DT as an
ABI, it is ok.
I would like to hear from DT maintainers what the approach should be.
Regards
Afzal
[A] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89408.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 01/12] dma: edma: Setup parameters to DMA MAX_NR_SG at a time
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.
Also allocate as many as slots as needed by the SG list, but not more
than MAX_NR_SG. Then these slots will be reused accordingly.
For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5f3e532..7b0853c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -222,9 +222,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
enum dma_slave_buswidth dev_width;
u32 burst;
struct scatterlist *sg;
- int i;
int acnt, bcnt, ccnt, src, dst, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
+ int i, num_slots_needed;
'nslots' is more to my liking. Better keep variable names short.
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
@@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
edesc-pset_nr = sg_len;
- for_each_sg(sgl, sg, sg_len, i) {
- /* Allocate a PaRAM slot, if needed */
+ /* Allocate a PaRAM slot, if needed */
+
+ num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
nslots = min(MAX_NR_SG, sg_len);
+
+ for (i = 0; i num_slots_needed; i++) {
if (echan-slot[i] 0) {
echan-slot[i] =
edma_alloc_slot(EDMA_CTLR(echan-ch_num),
@@ -273,6 +276,10 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
return NULL;
}
}
+ }
+
+ /* Configure PaRAM sets for each SG */
+ for_each_sg(sgl, sg, sg_len, i) {
acnt = dev_width;
@@ -330,6 +337,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
/* Configure A or AB synchronized transfers */
if (edesc-absync)
edesc-pset[i].opt |= SYNCDIM;
+
Random extra newline.
The patch as such is fine, but I dont think it makes lot of sense
standalone. This needs to be merged into the patch where you actually
handle the entire SG list in batches.
Thanks,
Sekhar
--
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 03/12] dma: edma: remove limits on number of slots
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
With this series, this check is no longer required and
we shouldn't need to reject drivers DMA'ing more than the
MAX number of slots.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b0853c..b6d609c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -247,12 +247,6 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
return NULL;
}
- if (sg_len MAX_NR_SG) {
- dev_err(dev, Exceeded max SG segments %d %d\n,
- sg_len, MAX_NR_SG);
- return NULL;
- }
This patch comes too early. Should be moved to the end of the series
when the support you rely on is actually present.
Thanks,
Sekhar
--
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] N900: add device tree
* Jiri Kosina jkos...@suse.cz [130810 13:36]: On Sat, 10 Aug 2013, Pavel Machek wrote: [I wonder if this is clean-enough cause for trivial in resubmit mode?] On Sat, 10 Aug 2013, Belisko Marek wrote: Same for gta04 (omap3 based device) [1]. It was send upstream 2 times and second time there is no reply from 1.3.2013. Hi guys, once I am able to match signoffs in the patches to MAINTAINERS, I can take those through trivial.git in re-transmission mode (or feeeding those thgough akpm si an option as well). Please just send the patches to me in a new thread properly with all the Acks/Signoffs, and mark those appropriately (i.e. maintainer that would normally push this upstream desurfaced). Sorry for the delays, I think Benoit is still on vacation. Plus the non-functioning email address issue certainly does not help.. Anyways, let's just let Benoit queue these to avoid pointless merge conflicts with the .dts files as discussed several times earlier. 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] N900: add device tree
* Pavel Machek pa...@ucw.cz [130811 06:54]: Hi! [I wonder if this is clean-enough cause for trivial in resubmit mode?] On Sat, 10 Aug 2013, Belisko Marek wrote: Same for gta04 (omap3 based device) [1]. It was send upstream 2 times and second time there is no reply from 1.3.2013. Hi guys, once I am able to match signoffs in the patches to MAINTAINERS, I can take those through trivial.git in re-transmission mode (or feeeding those thgough akpm si an option as well). Please just send the patches to me in a new thread properly with all the Acks/Signoffs, and mark those appropriately (i.e. maintainer that would normally push this upstream desurfaced). I noticed that you are using Benoit older emails address (b-cous...@ti.com) which no longer exists instead of his new email address (benoit.cous...@linaro.org). So, it may be possible that Benoit have not even been getting your patches. Thanks for update. I'll send a patch to MAINTAINERS updating Benoit's email address so get_maintainer.pl will stop lying. Thanks! Benoit, could you take a look at the patch from this thread? I can resend it, but it should be in pretty much _all_ the webmail archives now :-). Hopefully Benoit will be back online after vacation soon :) Regaqrds, 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: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
* Dave Gerlach d-gerl...@ti.com [130809 14:02]: Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? Well maybe try to think how to use these features in a Linux generic way without having to export tons of custom functions? 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 1/1] MAINTAINERS: update Benoît Cousson email address
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current Benoît's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. Regards, Tony --- Patch on top of Linus's commit c095ba72 (Linux 3.11-rc4). Changes since v1: - I mostly send DT patches to Benoît but now I noticed that he also maintains other subsystems. Update the patch to change all his MAINTAINERS entries. MAINTAINERS |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index defc053..3466423 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5879,7 +5879,7 @@ F: drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5959,14 +5959,14 @@ S:Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.7.7.6 -- 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/9] DRA7xx core support
* Rajendra Nayak rna...@ti.com [130811 23:47]: On Sunday 04 August 2013 09:57 PM, Rajendra Nayak wrote: Changes in v3: -1- Dropped some clock/dpll framework builds for dra7 -2- Added all instances of IPs in dtsi file -3- dtsi does a 'disabled' by default and dts enables as needed -4- soc_is_dra7xx() based on DT compatible instead of using ID code Changes in v2: -1- Fixed minor changelog details -2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files) -4- Updated the EVM dts file with pin config details for uart/mcspi and i2c DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology. The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC. Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support. This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot. Tony, any chance of this series making it to 3.12? Looks OK to me, want to do a pull request against -rc5 for me? 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/3] ARM: OMAP2+: hwmod-data: Add SSI information
* Sebastian Reichel s...@debian.org [130811 09:25]:
From: Sebastian Reichel s...@ring0.de
This patch adds Synchronous Serial Interface (SSI) hwmod support for
OMAP34xx SoCs.
This should be queued or acked by Paul.
Regards,
Tony
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 104
1 file changed, 104 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0c3a427..74006c4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3693,6 +3693,109 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__aes
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/*
+ * 'ssi' class
+ * synchronous serial interface (multichannel and full-duplex serial if)
+ */
+
+static struct omap_hwmod_class_sysconfig omap34xx_ssi_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_EMUFREE |
+SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE |
+SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap34xx_ssi_hwmod_class = {
+ .name = ssi,
+ .sysc = omap34xx_ssi_sysc,
+};
+
+static struct omap_hwmod_irq_info omap34xx_ssi_irqs[] = {
+ { .name = ssi_p1_mpu_irq0, .irq = 67 },
+ { .name = ssi_p1_mpu_irq1, .irq = 68 },
+ { .name = ssi_p2_mpu_irq0, .irq = 69 },
+ { .name = ssi_p2_mpu_irq1, .irq = 70 },
+ { .name = ssi_gdd_mpu, .irq = 71 },
+ { .irq = -1 },
+};
+
+static struct omap_hwmod_addr_space omap34xx_ssi_addrs[] = {
+ {
+ .name = sys,
+ .pa_start = 0x48058000,
+ .pa_end = 0x48058fff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ /* generic distributed DMA */
+ .name = gdd,
+ .pa_start = 0x48059000,
+ .pa_end = 0x48059fff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ /* port 1: synchronous serial transmitter */
+ .name = p1_sst,
+ .pa_start = 0x4805a000,
+ .pa_end = 0x4805a7ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ /* port 1: synchronous serial receiver */
+ .name = p1_ssr,
+ .pa_start = 0x4805a800,
+ .pa_end = 0x4805afff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ /* port 2: synchronous serial transmitter */
+ .name = p2_sst,
+ .pa_start = 0x4805b000,
+ .pa_end = 0x4805b7ff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {
+ /* port 2: synchronous serial receiver */
+ .name = p2_ssr,
+ .pa_start = 0x4805b800,
+ .pa_end = 0x4805bfff,
+ .flags = ADDR_TYPE_RT,
+ },
+ {}
+};
+
+static struct omap_hwmod omap34xx_ssi_hwmod = {
+ .name = ssi,
+ .class = omap34xx_ssi_hwmod_class,
+ .clkdm_name = l3_init_clkdm,
+ .mpu_irqs = omap34xx_ssi_irqs,
+ .main_clk = ssi_ssr_fck,
+ .prcm = {
+ .omap2 = {
+ .prcm_reg_id= 1,
+ .module_bit = OMAP3430_EN_SSI_SHIFT,
+ .module_offs= WKUP_MOD,
+ .idlest_reg_id = 1,
+ .idlest_idle_bit= OMAP3430ES2_ST_SSI_IDLE_SHIFT,
+ },
+ },
+};
+
+/* SSI - l3 */
+static struct omap_hwmod_ocp_if omap34xx_l3__ssi = {
+ .master = omap3xxx_l3_main_hwmod,
+ .slave = omap34xx_ssi_hwmod,
+ .clk= ssi_ick,
+ .addr = omap34xx_ssi_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *omap3xxx_hwmod_ocp_ifs[] __initdata = {
omap3xxx_l3_main__l4_core,
omap3xxx_l3_main__l4_per,
@@ -3818,6 +3921,7 @@ static struct omap_hwmod_ocp_if
*omap34xx_hwmod_ocp_ifs[] __initdata = {
#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
#endif
+ omap34xx_l3__ssi,
NULL
};
--
1.7.10.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
Re: [PATCH v3 0/9] DRA7xx core support
On Monday 12 August 2013 01:54 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130811 23:47]: On Sunday 04 August 2013 09:57 PM, Rajendra Nayak wrote: Changes in v3: -1- Dropped some clock/dpll framework builds for dra7 -2- Added all instances of IPs in dtsi file -3- dtsi does a 'disabled' by default and dts enables as needed -4- soc_is_dra7xx() based on DT compatible instead of using ID code Changes in v2: -1- Fixed minor changelog details -2- Dropped the SRAM support patch since we need to move to drivers/misc/sram.c -3- Added DTS update patches to this series which were earlier posted as part of the data series (Since they don't have much objections as against the other in-kernel data files) -4- Updated the EVM dts file with pin config details for uart/mcspi and i2c DRA7xx based SoCs' are high-performance, infotainment application devices, based on enhanced OMAP architecture integrated on a 28nm technology. The DRA7xx family is composed of DRA75x and DRA74x devices. The current device for which the patches add support is the DRA752 SoC. Most of the core IPs are similar to those found on the OMAP5 devices, including the dual cortex-A15 based MPU subsystem, which has helped quite some reuse from existing OMAP5 support. This series contains only core support patches and none of the PRCM and hwmod data needed for the device to boot. Tony, any chance of this series making it to 3.12? Looks OK to me, want to do a pull request against -rc5 for me? Sure, will do. Thanks. 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 2/3] ARM: OMAP2+: HSI: Introduce OMAP SSI driver
* Sebastian Reichel s...@debian.org [130811 09:25]: From: Sebastian Reichel s...@ring0.de This patch adds an OMAP SSI driver to the HSI framework. The Synchronous Serial Interface (SSI) is a legacy version of HSI. As in the case of HSI, it is mainly used to connect Application engines (APE) with cellular modem engines (CMT) in cellular handsets. It provides a multichannel, full-duplex, multi-core communication with no reference clock. The OMAP SSI block is capable of reaching speeds of 110 Mbit/s. Good to see this being worked on, maybe we can finally start making calls with mainline kernel :) This one should be queued by: $ scripts/get_maintainer.pl -f drivers/hsi This should be a stand alone patch, right? You should resend with those people in cc. 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 3/3] ARM: OMAP2+: Add SSI driver configuration
* Sebastian Reichel s...@debian.org [130811 09:25]:
From: Sebastian Reichel s...@ring0.de
This patch configures and activates the OMAP SSI driver on the RX-51.
Hmm, I'd rather see this be DT only driver at this point. We're pretty
close to flipping omap3 to be DT only, and I'd rather not add new
platform code at this point. With DT, none of this patch is needed,
you can do all this in the driver probe based on the .dts configuration.
Regards,
Tony
arch/arm/mach-omap2/Makefile |4 ++
arch/arm/mach-omap2/board-rx51-peripherals.c | 10 +++-
arch/arm/mach-omap2/ssi.c| 82
++
3 files changed, 95 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/mach-omap2/ssi.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index d4f6715..ace860d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -222,6 +222,10 @@ ifneq ($(CONFIG_DRM_OMAP),)
obj-y+= drm.o
endif
+# Synchronous Serial Interface (SSI)
+omap-ssi-$(CONFIG_OMAP_SSI) := ssi.o
+obj-y+= $(omap-ssi-m) $(omap-ssi-y)
+
# Specific board support
obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o
obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..e2ca155 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -27,6 +27,7 @@
#include linux/power/isp1704_charger.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
+#include linux/platform_data/hsi-omap-ssi.h
#include asm/system_info.h
@@ -73,6 +74,8 @@
#define LIS302_IRQ1_GPIO 181
#define LIS302_IRQ2_GPIO 180 /* Not yet in use */
+#define RX51_CAWAKE_GPIO 151
+
/* List all SPI devices here. Note that the list/probe order seems to
matter! */
enum {
RX51_SPI_WL1251,
@@ -265,6 +268,11 @@ static struct spi_board_info
rx51_peripherals_spi_board_info[] __initdata = {
},
};
+static struct omap_ssi_board_config ssi_board_config = {
+ .num_ports = 1,
+ .cawake_gpio = { RX51_CAWAKE_GPIO },
+};
+
static struct platform_device rx51_battery_device = {
.name = rx51-battery,
.id = -1,
@@ -1295,7 +1303,7 @@ void __init rx51_peripherals_init(void)
if (partition)
omap_hsmmc_init(mmc);
+ omap_ssi_config(ssi_board_config);
rx51_charger_init();
rx51_init_twl4030_hwmon();
}
-
diff --git a/arch/arm/mach-omap2/ssi.c b/arch/arm/mach-omap2/ssi.c
new file mode 100644
index 000..a9d6eee
--- /dev/null
+++ b/arch/arm/mach-omap2/ssi.c
@@ -0,0 +1,82 @@
+/*
+ * linux/arch/arm/mach-omap2/ssi.c
+ *
+ * Copyright (C) 2010 Nokia Corporation. All rights reserved.
+ *
+ * Contact: Carlos Chinea carlos.chi...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ */
+
+#include linux/kernel.h
+#include linux/init.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/platform_data/hsi-omap-ssi.h
+#include omap_hwmod.h
+#include omap_device.h
+#include omap-pm.h
+
+static struct omap_ssi_platform_data ssi_pdata = {
+ .num_ports = SSI_NUM_PORTS,
+ .cawake_gpio= {0},
+ .get_dev_context_loss_count = omap_pm_get_dev_context_loss_count,
+};
+
+int __init omap_ssi_config(struct omap_ssi_board_config *ssi_config)
+{
+ unsigned int port, offset, cawake_gpio;
+ int err;
+
+ ssi_pdata.num_ports = ssi_config-num_ports;
+
+ for (port = 0, offset = 7; port ssi_config-num_ports; port++, offset
+= 5) {
+ cawake_gpio = ssi_config-cawake_gpio[port];
+ if (!cawake_gpio)
+ continue; /* Nothing to do */
+ err = gpio_request(cawake_gpio, cawake);
+ if (err 0)
+ goto rback;
+ gpio_direction_input(cawake_gpio);
+
+ ssi_pdata.cawake_gpio[port] = ssi_config-cawake_gpio[port];
+ }
+
+ return 0;
+
+rback:
+ pr_err(omap-ssi: Request cawake (gpio%d) failed\n, cawake_gpio);
+
Re: [PATCH v2 1/1] MAINTAINERS: update Benoît Cousson email address
Hi Tony, On Mon, Aug 12, 2013 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current Benoît's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. It seems so, at least I don't the SMTP 550 errors with it. But I agree that is best to wait for Benoit to confirm what is his current address. I just wanted to help... Regards, Tony Best regards, Javier --- Patch on top of Linus's commit c095ba72 (Linux 3.11-rc4). Changes since v1: - I mostly send DT patches to Benoît but now I noticed that he also maintains other subsystems. Update the patch to change all his MAINTAINERS entries. MAINTAINERS |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index defc053..3466423 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5879,7 +5879,7 @@ F: drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5959,14 +5959,14 @@ S:Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.7.7.6 -- 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
[PATCH] arm: omap5: dts: split SMPS10 dt node
SMPS10 has two outputs OUT1 and OUT2. Hence SMPS10 is modeled as
two regulators. The dt node is split to reflect it.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 65d7b60..05b9b12 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -334,9 +334,18 @@
ti,smps-range = 0x80;
};
- smps10_reg: smps10 {
+ smps10_out2_reg: smps10_out2 {
/* VBUS_5V_OTG */
- regulator-name = smps10;
+ regulator-name = smps10_out2;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps10_out1_reg: smps10_out1 {
+ /* VBUS_5V_OTG */
+ regulator-name = smps10_out1;
regulator-min-microvolt = 500;
regulator-max-microvolt = 500;
regulator-always-on;
--
1.7.10.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
[PATCH v3] arm: omap5: dts: add palmas-usb node
From: Felipe Balbi ba...@ti.com
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
[ kis...@ti.com : fix vbus-supply value after SMPS10 is modeled as 2 regulators]
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Change from v2:
fix vbus-supply value after SMPS10 is modeled as 2 regulators. This is needed
after SMPS10 is modeled as 2 regulators.
[1] models SMPS10 as 2 regulators.
[2] splits the SMPS10 node into two to represent the 2 regulators.
[1] - http://comments.gmane.org/gmane.linux.kernel/1542521
[2] - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93779.html
arch/arm/boot/dts/omap5-uevm.dts | 10 ++
arch/arm/boot/dts/omap5.dtsi |2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 08b7267..51a4acc 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -272,6 +272,11 @@
interrupt-controller;
#interrupt-cells = 2;
+ extcon_usb3: palmas_usb {
+ compatible = ti,palmas-usb;
+ ti,wakeup;
+ };
+
palmas_pmic {
compatible = ti,palmas-pmic;
interrupt-parent = palmas;
@@ -450,6 +455,11 @@
phys = 0 hsusb2_phy hsusb3_phy;
};
+usb3 {
+ extcon = extcon_usb3;
+ vbus-supply = smps10_out1_reg;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
ti,type = 2;
};
- omap_dwc3@4a02 {
+ usb3: omap_dwc3@4a02 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss;
reg = 0x4a02 0x1;
--
1.7.10.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 v2 1/1] MAINTAINERS: update Benoît Cousson email address
Hi, Looking into Benoit's tree https://git.kernel.org/cgit/linux/kernel/git/bcousson/linux-omap-dt.git/ we can see that last change there was made two months ago... So yes wee need to have at least confirmation from Benoit that he is going to maintain the tree. Also looks like OMAP devicetree-related patches hung in mailing lists at least for last 2 months... -- Best regards, Ruslan Bilvol On Mon, Aug 12, 2013 at 12:09 PM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Hi Tony, On Mon, Aug 12, 2013 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current Benoît's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. It seems so, at least I don't the SMTP 550 errors with it. But I agree that is best to wait for Benoit to confirm what is his current address. I just wanted to help... Regards, Tony Best regards, Javier --- Patch on top of Linus's commit c095ba72 (Linux 3.11-rc4). Changes since v1: - I mostly send DT patches to Benoît but now I noticed that he also maintains other subsystems. Update the patch to change all his MAINTAINERS entries. MAINTAINERS |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index defc053..3466423 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5879,7 +5879,7 @@ F: drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5959,14 +5959,14 @@ S:Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.7.7.6 -- 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 -- 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 07/12] dma: edma: Add function to dump a PaRAM set from PaRAM
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
Previously, such a dump function was used but it wasn't reading
from the PaRAM, rather just from a edmacc_param structure, we
add a helpful function for debugging that directly reads from
the PaRAM and gives the current state correctly (including links
and interrupt information).
Signed-off-by: Joel Fernandes jo...@ti.com
You should convert existing instances of PaRAM set dump to use this new
function along with introducing it.
Thanks,
Sekhar
---
drivers/dma/edma.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 080d669..a242269 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -102,6 +102,37 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
kfree(container_of(vdesc, struct edma_desc, vdesc));
}
+static inline void dump_pset(struct edma_chan *echan, int slot,
+ struct edmacc_param *pset_unused, int pset_idx)
+{
+ struct edmacc_param pset_local, *pset;
+ pset = pset_local;
+
+ edma_read_slot(slot, pset);
+
+ dev_dbg(echan-vchan.chan.device-dev,
+ \n pset[%d]:\n
+ chnum\t%d\n
+ slot\t%d\n
+ opt\t%08x\n
+ src\t%08x\n
+ dst\t%08x\n
+ abcnt\t%08x\n
+ ccnt\t%08x\n
+ bidx\t%08x\n
+ cidx\t%08x\n
+ lkrld\t%08x\n,
+ pset_idx, echan-ch_num, slot,
+ pset[0].opt,
+ pset[0].src,
+ pset[0].dst,
+ pset[0].a_b_cnt,
+ pset[0].ccnt,
+ pset[0].src_dst_bidx,
+ pset[0].src_dst_cidx,
+ pset[0].link_bcntrld);
+}
+
/* Dispatch a queued descriptor to the controller (caller holds lock) */
static void edma_execute(struct edma_chan *echan)
{
--
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 08/12] dma: edma: Add one more required slot to MAX slots
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
We'd now need a separate slot just for the channel and separate
ones for the 2 linked sets, so we make adjustments to allocate
an extra channel accordingly.
Signed-off-by: Joel Fernandes jo...@ti.com
No need for a separate patch for this, just do this in the patch where
you include the two linked sets.
---
drivers/dma/edma.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index a242269..df50a04 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -48,7 +48,7 @@
/* Max of 16 segments per channel to conserve PaRAM slots */
#define MAX_NR_SG16
-#define EDMA_MAX_SLOTS MAX_NR_SG
+#define EDMA_MAX_SLOTS (MAX_NR_SG+1)
#define EDMA_DESCRIPTORS 16
struct edma_desc {
@@ -311,6 +311,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
+ /* Allocate one extra to account for the channel itself */
+ num_slots_needed++;
You can do:
nslots = min(MAX_NR_SG, sg_len) + 1;
Thanks,
Sekhar
--
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] DRA7xx core support
Hi Tony, Heres the pull request for the dra7xx core support patches. The following changes since commit d4e4ab86bcba5a72779c43dc1459f71fea3d89c8: Linux 3.11-rc5 (2013-08-11 18:04:20 -0700) are available in the git repository at: git://github.com/rrnayak/linux.git tags/dra7-core-support-v3 for you to fetch changes up to 41f2119b3037e50482cb14eaa39e6b5c52113fb5: ARM: DRA7: Add the build support in omap2plus (2013-08-12 15:25:38 +0530) DRA7xx based SoC core support R Sricharan (8): ARM: DRA7: Reuse all of PRCM and MPUSS SMP infra ARM: DRA7: Reuse io tables and add a new .init_early ARM: DRA7: Resue the clocksource, clockevent support ARM: DRA7: board-generic: Add basic DT support ARM: DRA7: Kconfig: Make ARCH_NR_GPIO default to 512 ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board ARM: DRA7: id: Add cpu detection support for DRA7xx based SoCs' ARM: DRA7: Add the build support in omap2plus Rajendra Nayak (1): ARM: DRA7: hwmod: Reuse the soc_ops used for OMAP4/5 .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/Kconfig |2 +- arch/arm/boot/dts/Makefile |3 +- arch/arm/boot/dts/dra7-evm.dts | 140 + arch/arm/boot/dts/dra7.dtsi| 567 arch/arm/configs/omap2plus_defconfig |1 + arch/arm/mach-omap1/include/mach/soc.h |1 + arch/arm/mach-omap2/Kconfig| 12 +- arch/arm/mach-omap2/Makefile |6 + arch/arm/mach-omap2/board-generic.c| 18 + arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/id.c |4 +- arch/arm/mach-omap2/io.c | 20 +- arch/arm/mach-omap2/omap54xx.h |4 + arch/arm/mach-omap2/omap_hwmod.c |2 +- arch/arm/mach-omap2/soc.h | 17 + arch/arm/mach-omap2/timer.c|3 +- arch/arm/plat-omap/Kconfig |2 +- 18 files changed, 795 insertions(+), 11 deletions(-) create mode 100644 arch/arm/boot/dts/dra7-evm.dts create mode 100644 arch/arm/boot/dts/dra7.dtsi -- 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
[net-next PATCH 1/1] drivers: net: cpsw: Add support for new CPSW IP version present in AM43xx SoC
The new IP version which is present in AM43xx SoC has a minor changes and the
offsets are same as the previous version, so adding new IP version support in
the driver.
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
drivers/net/ethernet/ti/cpsw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index cd95671..0fcf212 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -83,6 +83,7 @@ do {
\
#define CPSW_VERSION_1 0x19010a
#define CPSW_VERSION_2 0x19010c
#define CPSW_VERSION_3 0x19010f
+#define CPSW_VERSION_4 0x190112
#define HOST_PORT_NUM 0
#define SLIVER_SIZE0x40
@@ -993,6 +994,7 @@ static void cpsw_slave_open(struct cpsw_slave *slave,
struct cpsw_priv *priv)
break;
case CPSW_VERSION_2:
case CPSW_VERSION_3:
+ case CPSW_VERSION_4:
slave_write(slave, TX_PRIORITY_MAPPING, CPSW2_TX_PRI_MAP);
break;
}
@@ -2018,6 +2020,7 @@ static int cpsw_probe(struct platform_device *pdev)
break;
case CPSW_VERSION_2:
case CPSW_VERSION_3:
+ case CPSW_VERSION_4:
priv-host_port_regs = ss_regs + CPSW2_HOST_PORT_OFFSET;
priv-cpts-reg = ss_regs + CPSW2_CPTS_OFFSET;
priv-hw_stats = ss_regs + CPSW2_HW_STATS;
--
1.8.4.rc1.21.gfb56570
--
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 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
On Tue, Jul 30, 2013 at 12:25:46PM +0100, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
Add minimal device tree source needed for DRA7 based SoCs.
Also add a board dts file for the dra7-evm (based on dra752)
which contains 1.5G of memory with 1G interleaved and 512MB
non-interleaved. Also added in the board file are pin configuration
details for i2c, mcspi and uart devices on board.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/Makefile |3 +-
arch/arm/boot/dts/dra7-evm.dts | 163 ++
arch/arm/boot/dts/dra7.dtsi| 488
3 files changed, 653 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/dra7-evm.dts
create mode 100644 arch/arm/boot/dts/dra7.dtsi
[...]
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
new file mode 100644
index 000..8a0c08e
--- /dev/null
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -0,0 +1,488 @@
+/*
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ * Based on omap4.dtsi
+ */
+
+/include/ skeleton.dtsi
+
+/ {
+ compatible = ti,dra7xx;
+ interrupt-parent = gic;
+
+ aliases {
+ serial0 = uart1;
+ serial1 = uart2;
+ serial2 = uart3;
+ serial3 = uart4;
+ serial4 = uart5;
+ serial5 = uart6;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = arm,cortex-a15;
+ timer {
+ compatible = arm,armv7-timer;
+ /*
+* PPI secure/nonsecure IRQ,
+* active low level-sensitive
+*/
+ interrupts = 1 13 0x308,
+1 14 0x308;
+ clock-frequency = 6144000;
+ };
+ };
The cpu nodes should have a reg matching their unit-address, and a
device_type = cpu.
The timer nodes should *not* be under the CPU nodes. They should be
under under the root node. I realise that it makes intuitive sense to
describe per-cpu resources this way, but that's not the way the bindings
are intended to be used (does thei DT even work?).
No virtual/hypervisor interrupts?
Do you really need the clock-frequency property? It's far preferrable to
have your bootloader do the right thing and program CNTFRQ with the
correct value.
+
+ gic: interrupt-controller@48211000 {
+ compatible = arm,cortex-a15-gic;
+ interrupt-controller;
+ #interrupt-cells = 3;
+ reg = 0x48211000 0x1000,
+ 0x48212000 0x1000;
Similarly, no GICH/GICV registers?
Thanks,
Mark.
--
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: Pandaboard: DT Boot fails when initramfs is loaded
Hi, On 08/11/2013 04:31 PM, Sebastian Reichel wrote: Hi, I try to boot the mainline omap kernel (I tried current mainline kernel from git and mainline 3.10-rc1+) on my Pandaboard using U-Boot as follows: mmcinfo ext2load mmc 0:2 0x8000 /boot/uImage ext2load mmc 0:2 0x8160 /boot/uInitrd ext2load mmc 0:2 0x9000 /boot/omap4-panda.dtb bootm 0x8000 0x8160 0x9000 What is the size of your uImage and uInitrd? Are you sure the load addresses are far apart to not cause overwrite? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 09/12] dma: edma: Implement multiple linked sets for continuity
On Monday 05 August 2013 04:14 PM, Joel Fernandes wrote:
Here we implement splitting up of the total MAX number of slots
available for a channel into 2 cyclically linked sets. Transfer
completion Interrupts are enabled on both linked sets and respective
handler recycles them on completion to process the next linked set.
Both linked sets are cyclically linked to each other to ensure
continuity of DMA operations. Interrupt handlers execute asynchronously
to the EDMA events and recycles the linked sets at the right time,
as a result EDMA is not blocked or dependent on interrupts and DMA
continues till the end of the SG-lists without any interruption.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 157
+++-
1 file changed, 118 insertions(+), 39 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index df50a04..70923a2 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -48,6 +48,7 @@
/* Max of 16 segments per channel to conserve PaRAM slots */
#define MAX_NR_SG16
+#define MAX_NR_LS(MAX_NR_SG 1)
#define EDMA_MAX_SLOTS (MAX_NR_SG+1)
#define EDMA_DESCRIPTORS 16
@@ -57,6 +58,7 @@ struct edma_desc {
int absync;
int pset_nr;
int total_processed;
+ int next_setup_linkset;
struct edmacc_param pset[0];
};
@@ -140,7 +142,9 @@ static void edma_execute(struct edma_chan *echan)
struct edma_desc *edesc;
struct device *dev = echan-vchan.chan.device-dev;
- int i, j, total_left, total_process;
+ int i, total_left, total_link_set;
+ int ls_cur_off, ls_next_off, slot_off;
+ struct edmacc_param tmp_param;
/* If either we processed all psets or we're still not started */
if (!echan-edesc ||
@@ -159,48 +163,121 @@ static void edma_execute(struct edma_chan *echan)
/* Find out how many left */
total_left = edesc-pset_nr - edesc-total_processed;
- total_process = total_left MAX_NR_SG ? MAX_NR_SG : total_left;
-
-
- /* Write descriptor PaRAM set(s) */
- for (i = 0; i total_process; i++) {
- j = i + edesc-total_processed;
- edma_write_slot(echan-slot[i], edesc-pset[j]);
- dev_dbg(echan-vchan.chan.device-dev,
- \n pset[%d]:\n
- chnum\t%d\n
- slot\t%d\n
- opt\t%08x\n
- src\t%08x\n
- dst\t%08x\n
- abcnt\t%08x\n
- ccnt\t%08x\n
- bidx\t%08x\n
- cidx\t%08x\n
- lkrld\t%08x\n,
- j, echan-ch_num, echan-slot[i],
- edesc-pset[j].opt,
- edesc-pset[j].src,
- edesc-pset[j].dst,
- edesc-pset[j].a_b_cnt,
- edesc-pset[j].ccnt,
- edesc-pset[j].src_dst_bidx,
- edesc-pset[j].src_dst_cidx,
- edesc-pset[j].link_bcntrld);
- /* Link to the previous slot if not the last set */
- if (i != (total_process - 1))
+ total_link_set = total_left MAX_NR_LS ? MAX_NR_LS : total_left;
The name you gave here sounds like this is defining total number of
linked PaRAM sets. Rather this is actually tracking the number of PaRAM
sets (slots) in current linked set, correct? Then may be just call it
'nslots' or even 'num_slots'? There are just too many variables with
total prefix to keep track of in this function!
+
+ /* First time, setup 2 cyclically linked sets, each containing half
+the slots allocated for this channel */
+ if (edesc-total_processed == 0) {
We dont need to check for this case for every DMA_COMPLETE interrupt.
May be move the initial setup to another function called from
edma_issue_pending()?
+ for (i = 0; i total_link_set; i++) {
+ edma_write_slot(echan-slot[i+1], edesc-pset[i]);
+
+ if (i != total_link_set - 1) {
+ edma_link(echan-slot[i+1], echan-slot[i+2]);
+ dump_pset(echan, echan-slot[i+1],
+ edesc-pset, i);
+ }
+ }
+
+ edesc-total_processed += total_link_set;
+
+ total_left = edesc-pset_nr - edesc-total_processed;
+
+ total_link_set = total_left MAX_NR_LS ?
+ MAX_NR_LS : total_left;
+
+ if (total_link_set) {
+ /* Don't setup interrupt for first linked set for cases
+
Re: [PATCH v3 08/12] dma: edma: Add one more required slot to MAX slots
On Mon, Aug 12, 2013 at 11:26:49AM +0530, Sekhar Nori wrote: No need for a separate patch for this, just do this in the patch where you include the two linked sets. Can you guys please think about the CC lists you're using for these patch serieses? I've certainly no interest in random patches to the DaVinci DMA controllers, and I suspect the same is true for most of the people on the CC list. signature.asc Description: Digital signature
Re: [PATCH v2 8/8] ARM: DRA7: dts: Add the dts files for dra7 SoC and dra7-evm board
Hi Rajendra,
On 30/07/2013 15:01, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:29 PM, Nishanth Menon wrote:
On 07/30/2013 07:56 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:16 PM, Nishanth Menon wrote:
On 07/30/2013 07:41 AM, Rajendra Nayak wrote:
On Tuesday 30 July 2013 06:00 PM, Nishanth Menon wrote:
On 07/30/2013 06:25 AM, Rajendra Nayak wrote:
From: R Sricharan r.sricha...@ti.com
[...]
+mcspi4: spi@480ba000 {
+compatible = ti,omap4-mcspi;
+reg = 0x480ba000 0x200;
+interrupts = 0 48 0x4;
+#address-cells = 1;
+#size-cells = 0;
+ti,hwmods = mcspi4;
+ti,spi-num-cs = 1;
+dmas = sdma 70, sdma 71;
+dma-names = tx0, rx0;
+};
+};
+};
ref: [1], we discussed that we should now be able to introduce all instances of
h/w blocks into the dra7.dts. Further, considering [2]
hmm, thats a long discussion on crossbar driver that [1] points to. Do you want
to summarize what you mean by 'introduce all instances of h/w blocks'
I recommend reading the last few emails on the thread about how we could do
this with pinctrl. unfortunately, this patch is not informative enough to
indicate that not all instances of the potential IP blocks are listed here.
would you not want to follow status = disabled for all modules by default and
enable required modules in board file, so that we dont have to respin this yet again?
Well, I was just following the convention of whats already followed on existing
OMAPs. See [3] for some views on these.
DRA7 case, I would not think it makes sense due to the number of product
variants being done, not all will use the same set. Further, rationale for DRA7
and my suggestion for Grant's option (1) is mainly because the product variants
will require more dtsis rather than board files using the product variants use
just the necessary modules from a common dtsi. Makes support of variants like
OMAP57xx etc trivial and constrainted to board file usage, rather than spinning
off new dtsis.
Makes sense with the different product variants for DRA7, AM335x already does
it this way, but the rest of OMAP3/4/5 are doing it the other way.
I think its just too confusing to follow different conventions for different
SoCs. We should stick to just one, either this way or that.
I think bucketing DRA7(with multitude of SoC variants) with OMAP family(usually
with 5 variants) will be a wrong approach. we should choose the approach
appropriate for the SoC. hence, OMAPx having all default enabled makes sense (as
the delta is usually trivial), but on DRA7, the variants are larger :(
just my 2 cents.
I can respin with the changes, but before I do so, Benoit do you agree with the
rationale for these and fine with the approach?
Sorry for the very late reply. I've just seen it because Mark's answer
put in again in my gmail box.
I'm not sure to understand what Nishanth and you are arguing for :-)
If this is about the default status state, I think that this flag is
anyway confusing because you cannot know if we are considering an IP
that does not exist at all in a variant or an IP that is not used on a
certain board...
This potential issue we can have with the second case is that the IP
might be enabled by the boot loader and never disabled because
status=disabled prevent DT to create the device, and thus prevent the
driver to properly idle the device.
That's why I did not like the usage of status=disabled by default,
because the way DT core handle that might not be appropriate for an IP
that is there but not use.
For a variant that does not contain physically the IP, that flag can be
relevant.
Regarding which default status is the best, I guess as soon as it is
consistant across a chip family, both are fine to me.
Not necessarily related to your discussion, but I still think that DT is
missing a flag to make the difference between the two cases.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] MAINTAINERS: update Benoît Cousson email address
On Mon, Aug 12, 2013 at 11:09 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Hi Tony, On Mon, Aug 12, 2013 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current Benoît's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. It seems so, at least I don't get SMTP 550 errors with it. But I agree that is best to wait for Benoit to confirm what is his current address. I just wanted to help... I see that Benoit also has a gmail address. I'm cc'ing him in this thread so he can confirm what is his current email address and MAINTAINERS can be updated so people can send OMAP DT patches to the correct address. Thanks a lot and best regards, Javier Regards, Tony Best regards, Javier --- Patch on top of Linus's commit c095ba72 (Linux 3.11-rc4). Changes since v1: - I mostly send DT patches to Benoît but now I noticed that he also maintains other subsystems. Update the patch to change all his MAINTAINERS entries. MAINTAINERS |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index defc053..3466423 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5879,7 +5879,7 @@ F: drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5959,14 +5959,14 @@ S:Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson benoit.cous...@linaro.org L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.7.7.6 -- 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 v2 1/1] MAINTAINERS: update Benoît Cousson email address
Hi Javier, Thanks for taking care of that. Sorry if I missed you for so long :-) I had to manage TI layoffs then vacation then starting my new job. On 12/08/2013 16:03, Javier Martinez Canillas wrote: On Mon, Aug 12, 2013 at 11:09 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Hi Tony, On Mon, Aug 12, 2013 at 9:55 AM, Tony Lindgren t...@atomide.com wrote: * Javier Martinez Canillas javier.marti...@collabora.co.uk [130811 08:28]: Using the email address listed on MAINTAINERS I keep getting SMTP 550 Invalid recipient errors. Update with what seems to be current Benoît's email address to make get_maintainer.pl to stop lying. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Is the linaro.org address still valid? We should probably wait for Benoit to confirm this to avoid more confusion. It seems so, at least I don't get SMTP 550 errors with it. But I agree that is best to wait for Benoit to confirm what is his current address. I just wanted to help... I see that Benoit also has a gmail address. I'm cc'ing him in this thread so he can confirm what is his current email address and MAINTAINERS can be updated so people can send OMAP DT patches to the correct address. Thanks a lot and best regards, Javier Here is my official new email address. I'll repost it properly, except if Tony is fine taking it like that. Regards, Benoit --- From 8a5464b6da7f076b7caa21ac96905b46cf26e269 Mon Sep 17 00:00:00 2001 From: Benoit Cousson bcous...@baylibre.com Date: Fri, 9 Aug 2013 23:19:15 +0200 Subject: [PATCH] MAINTAINERS: Update my email address Goodbye TI. Welcome new life! Signed-off-by: Benoit Cousson bcous...@baylibre.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk --- MAINTAINERS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 7cacc88..300c9f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5884,7 +5884,7 @@ F:drivers/i2c/busses/i2c-omap.c F: include/linux/i2c-omap.h OMAP DEVICE TREE SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson bcous...@baylibre.com M: Tony Lindgren t...@atomide.com L: linux-omap@vger.kernel.org L: devicet...@vger.kernel.org @@ -5964,14 +5964,14 @@ S: Maintained F: drivers/char/hw_random/omap-rng.c OMAP HWMOD SUPPORT -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson bcous...@baylibre.com M: Paul Walmsley p...@pwsan.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod.* OMAP HWMOD DATA FOR OMAP4-BASED DEVICES -M: Benoît Cousson b-cous...@ti.com +M: Benoît Cousson bcous...@baylibre.com L: linux-omap@vger.kernel.org S: Maintained F: arch/arm/mach-omap2/omap_hwmod_44xx_data.c -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 8/9] ARM: OMAP2+: AM33XX: Basic suspend resume support
Hi Russ, Russ Dill russ.d...@gmail.com writes: [...] I was taking a look at this situation, figuring that the suspend/resume callbacks in omap_device might be the right place to do it, and came across this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=72bb6f9b51c82c820ddef892455a85b115460904 Under what situations would the driver callbacks be present if probe fails? I'm looking at really_probe in drivers/base/dd.c, and if probe fails, dev-driver is set to NULL. What was the condition this was protecting against? The static suspend/resume methods for PM domains don't check for dev-driver. (c.f. device_resume_noirq()), so during system suspend, the PM domain callbacks are called whether or not there is a driver. A simlar fix could've been done by checking for the existence of dev-driver (and maybe that's a better solution), but I chose the latter so omap_device has a finer grained track of the driver status. Also, by modifying _od_suspend_noirq, can we force idle unbound omap device? Would we need a new omap_hwmod flag to check which devices should be force idled if no driver is bound? I suppose you could, but that would probably mask driver bugs where the driver is not properly runtime suspending itself before being removed. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivers/gpio/gpio-omap.c: convert comma to semicolon
Joe Perches j...@perches.com writes:
On Sat, 2013-08-10 at 17:40 +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Replace a comma between expression statements by a semicolon.
[]
I can't tell if the assignment to ct-regs.mask is really intended to be
under the if. The proposed patch preserves the current semantics, but not
the current indentation.
I'd suspect more that the indentation is correct
and the comma use incorrect.
It also looks more like a copy/paste error from
commit f8b46b583 when the code was restructured
a bit.
Kevin?
Yes, looks like a copy/paste error. The comma should simply be replaced
by a semi-colon.
Kevin
-#ifdef CONFIG_ARCH_OMAP16XX
- /* REVISIT: assuming only 16xx supports MPUIO wake events */
- .irq_set_wake = gpio_wake_enable,
-#endif
-};
+ /* REVISIT: assuming only 16xx supports MPUIO wake events */
+ if (cpu_is_omap16xx())
+ ct-chip.irq_set_wake = gpio_wake_enable,
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
[]
@@ -1029,10 +1029,10 @@ omap_mpuio_alloc_gc(struct gpio_bank *bank, unsigned
int irq_start,
ct-chip.irq_unmask = irq_gc_mask_clr_bit;
ct-chip.irq_set_type = gpio_irq_type;
-if (bank-regs-wkup_en)
-ct-chip.irq_set_wake = gpio_wake_enable,
-
-ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride;
+if (bank-regs-wkup_en) {
+ct-chip.irq_set_wake = gpio_wake_enable;
+ct-regs.mask = OMAP_MPUIO_GPIO_INT / bank-stride;
+}
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 v2 1/3] usb: dwc3: msm: Add device tree binding information
On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) probably good to spell out Synopsys rather than SNPS Synopsys (the company) has always used snps in their bindings though. +Required properities : +- compatible : sould be qcom,dwc3-hsphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + sleep_a_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for HSPHY + v3p3 : 3.3v supply for HSPHY + vbus : vbus supply for host mode + vddcx : vdd supply for HS-PHY digital circuit operation I believe these regulators belong to the PHY, not DWC3. Please write a PHY driver. +Required properities : +- compatible : sould be qcom,dwc3-ssphy; +- reg : offset and length of the register set in the memory map +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + xo : External reference clock 19 MHz + ref_clk : Reference clock - used in host mode. +supply-name-supply : phandle to the regulator device tree node +Required supply-name are: + v1p8 : 1.8v supply for SS-PHY + vddcx : vdd supply for SS-PHY digital circuit operation likewise, these regulators should be moved to the PHY driver. +Required properties : +- compatible : should be qcom,dwc3 +- reg : offset and length of the register set in the memory map + offset and length of the TCSR register for routing USB + signals to either picoPHY0 or picoPHY1. +- clocks : phandles to clock instances of the device tree nodes +- clock-names : + core_clk : Master/Core clock, have to be = 125 MHz for SS + operation and = 60MHz for HS operation + iface_clk : System bus AXI clock + sleep_clk : Sleep clock, used when USB3 core goes into low + power mode (U3). + utmi_clk : Generated by HS-PHY. Used to clock the low power + parts of thr HS Link layer. + +Optional properties : +- gdsc-supply : phandle to the globally distributed switch controller + regulator node to the USB controller. + +Sub nodes: +- Sub node for DWC3 USB3 controller. + This sub node is required property for device node. The properties + of this subnode are specified in dwc3.txt. Is tx-fifo-resize required for qcom,dwc3? if so we should call that out in the binding. AFAICT that's only needed for OMAP5 ES1.0. Unless Qualcomm also screwed up default TX FIFO sizes :-p -- balbi signature.asc Description: Digital signature
Re: [RFC 2/2] usb: dwc3: Add Qualcomm DWC3 glue layer driver
On Fri, Aug 09, 2013 at 07:09:18PM +0300, Ivan T. Ivanov wrote:
Hi,
On Fri, 2013-08-09 at 16:23 +0300, Felipe Balbi wrote:
Hi,
On Tue, Aug 06, 2013 at 02:53:11PM +0300, Ivan T. Ivanov wrote:
diff --git a/drivers/usb/dwc3/dwc3-msm.c b/drivers/usb/dwc3/dwc3-msm.c
new file mode 100644
index 000..e509abc
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-msm.c
@@ -0,0 +1,175 @@
+#undef CONFIG_REGULATOR
why ??
1. This shows that driver is still not fully tested
Regulators support is still missing in the MSM
2. Helps me to load driver successfully.
Then remove all the regulator-related code from this.
+ clk_prepare_enable(mdwc-core_clk);
+ clk_prepare_enable(mdwc-iface_clk);
+ clk_prepare_enable(mdwc-sleep_clk);
+ clk_prepare_enable(mdwc-utmi_clk);
do you really need to enable your clocks here ? Why don't you enable
them on runtime_resume and disable on runtime_suspend ?
I will like to make it working first and then will improve
power management.
alright, makes sense.
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ tcsr = devm_ioremap_resource(pdev-dev, res);
+ if (!tcsr) {
+ dev_dbg(pdev-dev, tcsr ioremap failed\n);
no need to ioremap, also you're likely leaking clocks and regulators
enabled here.
Make sure to have something like:
if (!tcsr)
goto err_disable_clocks;
/* TODO This has to be revised */\
[...]
Sure.
just to make it clear, I meant to say that you don't need to print the
error message :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
Will, On Friday 02 August 2013 11:48 AM, Will Deacon wrote: On Fri, Aug 02, 2013 at 04:45:46PM +0100, Sudeep KarkadaNagesha wrote: On 02/08/13 16:22, Santosh Shilimkar wrote: + @ Core indicates it is SMP. Check for Aegis SOC where a single + @ Cortex-A9 CPU is present but SMP operations fault. + mov r4, #0x4100 + orr r4, r4, #0xc000 + orr r4, r4, #0x0090 + teq r3, r4 @ Check for ARM Cortex-A9 + movne pc, lr @ Not ARM Cortex-A9, + + mrc p15, 4, r0, c15, c0 @ get SCU base address Correct me if I am interpreting this wrong, but CRn=15 here which is IMPLEMENTATION DEFINED registers. If not, then I wonder why few platform have to read SCU base from DT or some header, why not this way ? I don't know if there is Cortex-A9 based SOC which don't implement SCU CP15 base address register, so can't comment really why not always use CP15 based method. I am not even sure if there are other reasons behind DT usage. I may be wrong, but it's just my understanding as I see that ARM ARM clearly states CRn=15 space is IMPLEMENTATION DEFINED registers and we can't expect it to work on all IMPLEMENTATIONS. I just had a glance at all the usage of CR15 space of CP15 register, its either platform specific or under specific errata/condition. Will/Dave/Russell can confirm if it's safe to access these registers on any implementation or you may need to make it conditional. I think this an A9-specific register, which reads as 0 on UP A9 and reads as some form of PERIPH_BASE for SMP parts. The issue I have is when PERIPH_BASE is zero. What do we do here ? Should we document this in the code and proceed ? Mostly there is no platform with PERIPH_BASE = 0, so its should be fine but I am open for any other alternative. 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: [RFC PATCH v2 1/3] usb: dwc3: msm: Add device tree binding information
On Aug 12, 2013, at 1:04 PM, Felipe Balbi wrote: On Fri, Aug 09, 2013 at 10:31:58AM -0500, Kumar Gala wrote: On Aug 9, 2013, at 4:53 AM, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP (SNPS) probably good to spell out Synopsys rather than SNPS Synopsys (the company) has always used snps in their bindings though. I just meant in the commit message as SNPS wasn't obvious to me and I think when someone comes back and looks the commit message doing Synopsys (SNPS) is a little more readable. - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 0/9] ARM: OMAP2+: AM33XX: Add suspend-resume support
On 08/11/2013 06:53 AM, Daniel Mack wrote: Hi Dave, Thanks a lot for your work on this. On 06.08.2013 19:49, Dave Gerlach wrote: This is the third version of the patch series for adding basic suspend-resume support for AM33XX, previously submitted by Vaibhav Bedia. This patchset is based on 3.11-rc4 and depends on a forthcoming patchset from Suman Anna that adds mailbox support for the wkup_m3. The patches at [1], [2], and [3] are required for the pm code to properly suspend and resume. I applied your set and the one from Suman Anna, and with musb disabled and the firmware built from the sources you referenced, I'm able to put a custom AM33xx based board to suspend. The problem I currently face is that I can't make the board resume, as neither UART0 nor GPIO0 seem to work as wakeup source. Did you apply the other patches that are mentioned besides Suman's series? The board will hang while suspending without these. Which wakeup source did you use in your tests? Most of my verification was done with UART wakeup. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/9] memory: emif: Move EMIF register defines to include/linux/
On Thu, Aug 08, 2013 at 09:35:46AM -0400, Santosh Shilimkar wrote: (You have not CC'ed Greg, Looping him) On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote: OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Aneesh V ane...@ti.com --- drivers/memory/emif.h | 543 + include/linux/ti_emif.h | 558 +++ 2 files changed, 559 insertions(+), 542 deletions(-) create mode 100644 include/linux/ti_emif.h For file movement or some part of file movement, while formating patch, use git format-patch -C so that only delta change will appear in the patch. The patch as such is fine by me. Acked-by: Santosh Shililmar santosh.shilim...@ti.com Greg, Your ack is needed on this patch so that it can go along with the series. Subsequent patch from this series use the register defines from this patch. Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 1/9] memory: emif: Move EMIF register defines to include/linux/
On Monday 12 August 2013 03:32 PM, Greg Kroah-Hartman wrote: On Thu, Aug 08, 2013 at 09:35:46AM -0400, Santosh Shilimkar wrote: (You have not CC'ed Greg, Looping him) On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote: OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Aneesh V ane...@ti.com --- drivers/memory/emif.h | 543 + include/linux/ti_emif.h | 558 +++ 2 files changed, 559 insertions(+), 542 deletions(-) create mode 100644 include/linux/ti_emif.h For file movement or some part of file movement, while formating patch, use git format-patch -C so that only delta change will appear in the patch. The patch as such is fine by me. Acked-by: Santosh Shililmar santosh.shilim...@ti.com Greg, Your ack is needed on this patch so that it can go along with the series. Subsequent patch from this series use the register defines from this patch. Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org Thanks !! -- 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 08/12] dma: edma: Add one more required slot to MAX slots
On 08/12/2013 08:31 AM, Mark Brown wrote: On Mon, Aug 12, 2013 at 11:26:49AM +0530, Sekhar Nori wrote: No need for a separate patch for this, just do this in the patch where you include the two linked sets. Can you guys please think about the CC lists you're using for these patch serieses? I've certainly no interest in random patches to the DaVinci DMA controllers, and I suspect the same is true for most of the people on the CC list. Sorry. I was actually getting a sense of this. What I did initially was I copied the CC list from last years work on the same series hoping that it would be a complete mail chain. Bad judgement on my part. I should have paid more attention to Mark's rants about his inbox getting spammed with this series in those old threads ;) I guess moving forward I will use get_maintainer.pl and refine my git-send scripts with only interested folks. Any words of advice on when to and when not to CC someone remotely connected to a series is welcome. @Sekhar, let's keep only linux-omap, linux-davinci and few other interested folks on the CC chain for the rest of review on the series. Thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On 08/12/2013 02:17 PM, Kevin Hilman wrote: Dave Gerlach d-gerl...@ti.com writes: On 08/09/2013 12:11 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [130808 09:23]: On 08/08/2013 08:44 AM, Santosh Shilimkar wrote: Lets address the above better. I don't see a need of 8 functions exported doing one or 2 register writes. Look M3 based handling is going to be there on future SOCs as well and this kind of handling of IPC is very short cited. The idea here was to move all control module register accesses into one file in planning of implementing a driver for the control module itself in the future. Probably we should have a separate driver for M3 in linux which can have all this local code instead of all these exports. The wkup_m3 code has been moved to a small driver found in patch 8 of this series, would it better to move this code there rather than with the rest of the control module code? Please make everything you can into regular device drivers. We still have some dependencies to mach-omap2 code for PRCM for example, but we're trying to get all that to live in drivers. So for new pieces, let's not add further dependencies to complicate moving things to drivers. Regards, Tony Ok I will go ahead and pull the control module code that handles IPC into the wkup_m3 driver. Any control module register access still needs to stay in control.c. The wkup_m3.c file is still present in mach-omap2 as the right location for it wasn't decided in the last RFC. Any thoughts on a good location for it? I raised this also in earlier reviews, but don't remember the if it was answered... Why can't we handle the wkup_m3 using remoteproc/rpmsg instead of creating another little driver that duplicates communication with the M3. Note also that the firmware load part would also be provided by remoteproc/rpmsg. Looping Suman Anna who handled the IPC patches this patch set is based on top of... For the wkup_m3, the mailbox isn't used in a traditional manner. It's only used with a dummy write to trigger an interrupt from the A8 to the M3 and then communication happens in IPC registers within the control module. No messages are actually sent through the mailbox in either direction so that's why it was done this way rather than bring in full support for the mailbox. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] serial: OMAP: add RS485 support
On Sun, Aug 11, 2013 at 02:56:50PM +0100, Mark Jackson wrote: This patch adds RS485 support to the OMAP serial driver, as defined in:- Documentation/devicetree/bindings/serial/rs485.txt When a UART transmitter is connected to (eg) a RS485 driver, it is necessary to turn the driver on/off as quickly as possible. This is best achieved in the serial driver itself (rather than in userspace where the latency can be quite large). This patch allows a GPIO pin to be defined (via DT) that controls the enabling of the driver at the start of a message, and disables the driver when the message has been completed. When RS485 is disabled, the RTS pin is set to on. Signed-off-by: Mark Jackson m...@newflow.co.uk --- Changes in v2: - Fix incorrect logic in serial_omap_config_rs485() drivers/tty/serial/omap-serial.c | 178 ++ 1 file changed, 178 insertions(+) This doesn't apply to my tty-next branch: checking file drivers/tty/serial/omap-serial.c Hunk #1 FAILED at 40. Hunk #2 succeeded at 162 (offset 6 lines). Hunk #3 succeeded at 280 (offset 5 lines). Hunk #4 succeeded at 378 (offset 6 lines). Hunk #5 succeeded at 1312 (offset 8 lines). Hunk #6 succeeded at 1405 (offset 8 lines). Hunk #7 succeeded at 1528 (offset 10 lines). Hunk #8 FAILED at 1638. Hunk #9 succeeded at 1705 (offset 6 lines). 2 out of 9 hunks FAILED so I can't apply it, sorry. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] arm: omap5: dts: add palmas-usb node
On 08/12/2013 04:17 AM, Kishon Vijay Abraham I wrote:
From: Felipe Balbi ba...@ti.com
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
interrupt-controller;
#interrupt-cells = 2;
+ extcon_usb3: palmas_usb {
+ compatible = ti,palmas-usb;
This isn't so much a comment on this patch as the Palmas binding:
Presumably, the Palmas device contains a USB VID detector, not a whole
USB controller. I'd expect the compatible value to indicate this more
directly, i.e. be something like ti,palmas-usb-vid or
ti,palmas-usb-vid-detector.
--
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 01/12] dma: edma: Setup parameters to DMA MAX_NR_SG at a time
Dropped quite a few from the CC list...
On 08/12/2013 02:15 AM, Sekhar Nori wrote:
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.
Also allocate as many as slots as needed by the SG list, but not more
than MAX_NR_SG. Then these slots will be reused accordingly.
For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5f3e532..7b0853c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -222,9 +222,9 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
enum dma_slave_buswidth dev_width;
u32 burst;
struct scatterlist *sg;
-int i;
int acnt, bcnt, ccnt, src, dst, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
+int i, num_slots_needed;
'nslots' is more to my liking. Better keep variable names short.
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
@@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
edesc-pset_nr = sg_len;
-for_each_sg(sgl, sg, sg_len, i) {
-/* Allocate a PaRAM slot, if needed */
+/* Allocate a PaRAM slot, if needed */
+
+num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
nslots = min(MAX_NR_SG, sg_len);
I agree the original naming was quite long. I would rather using
something more descriptive though than nslots. How does slots_needed sound?
Thanks,
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/12] dma: edma: Setup parameters to DMA MAX_NR_SG at a time
Responding to other comments in this post,
On 08/12/2013 02:15 AM, Sekhar Nori wrote:
[..]
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
@@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
edesc-pset_nr = sg_len;
-for_each_sg(sgl, sg, sg_len, i) {
-/* Allocate a PaRAM slot, if needed */
+/* Allocate a PaRAM slot, if needed */
+
+num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
nslots = min(MAX_NR_SG, sg_len);
Changed to this, with the +1
+
+for (i = 0; i num_slots_needed; i++) {
if (echan-slot[i] 0) {
echan-slot[i] =
edma_alloc_slot(EDMA_CTLR(echan-ch_num),
@@ -273,6 +276,10 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
return NULL;
}
}
+}
+
+/* Configure PaRAM sets for each SG */
+for_each_sg(sgl, sg, sg_len, i) {
acnt = dev_width;
@@ -330,6 +337,7 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
/* Configure A or AB synchronized transfers */
if (edesc-absync)
edesc-pset[i].opt |= SYNCDIM;
+
Random extra newline.
Removing..
The patch as such is fine, but I dont think it makes lot of sense
standalone. This needs to be merged into the patch where you actually
handle the entire SG list in batches.
I think it does actually, this patch just takes care of preparing the
param set list correctly and allocating slots. It doesn't the actual DMA
or take part in the algorithm. As a result, the patch can be reused
incase in future the main algorithm is rewritten in a subsequent series.
Further this patch was reused straight from old implementation so it
proved to be useful being a separate patch last time. I also plan to
rewrite just this functionality in the future.
Thanks,
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 01/12] dma: edma: Setup parameters to DMA MAX_NR_SG at a time
On 08/12/2013 06:55 PM, Joel Fernandes wrote:
Dropped quite a few from the CC list...
On 08/12/2013 02:15 AM, Sekhar Nori wrote:
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.
Also allocate as many as slots as needed by the SG list, but not more
than MAX_NR_SG. Then these slots will be reused accordingly.
For ex, if MAX_NR_SG=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 5f3e532..7b0853c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -222,9 +222,9 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
enum dma_slave_buswidth dev_width;
u32 burst;
struct scatterlist *sg;
- int i;
int acnt, bcnt, ccnt, src, dst, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
+ int i, num_slots_needed;
'nslots' is more to my liking. Better keep variable names short.
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
@@ -262,8 +262,11 @@ static struct dma_async_tx_descriptor
*edma_prep_slave_sg(
edesc-pset_nr = sg_len;
- for_each_sg(sgl, sg, sg_len, i) {
- /* Allocate a PaRAM slot, if needed */
+ /* Allocate a PaRAM slot, if needed */
+
+ num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
nslots = min(MAX_NR_SG, sg_len);
I agree the original naming was quite long. I would rather using
something more descriptive though than nslots. How does slots_needed sound?
Sorry for the noise, nslots is fine and I've changed it to the same.
-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 v3 09/12] dma: edma: Implement multiple linked sets for continuity
On 08/12/2013 01:56 PM, Sekhar Nori wrote:
On Monday 05 August 2013 04:14 PM, Joel Fernandes wrote:
Here we implement splitting up of the total MAX number of slots
available for a channel into 2 cyclically linked sets. Transfer
completion Interrupts are enabled on both linked sets and respective
handler recycles them on completion to process the next linked set.
Both linked sets are cyclically linked to each other to ensure
continuity of DMA operations. Interrupt handlers execute asynchronously
to the EDMA events and recycles the linked sets at the right time,
as a result EDMA is not blocked or dependent on interrupts and DMA
continues till the end of the SG-lists without any interruption.
Suggested-by: Sekhar Nori nsek...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 157
+++-
1 file changed, 118 insertions(+), 39 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index df50a04..70923a2 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -48,6 +48,7 @@
/* Max of 16 segments per channel to conserve PaRAM slots */
#define MAX_NR_SG 16
+#define MAX_NR_LS (MAX_NR_SG 1)
#define EDMA_MAX_SLOTS (MAX_NR_SG+1)
#define EDMA_DESCRIPTORS16
@@ -57,6 +58,7 @@ struct edma_desc {
int absync;
int pset_nr;
int total_processed;
+int next_setup_linkset;
struct edmacc_param pset[0];
};
@@ -140,7 +142,9 @@ static void edma_execute(struct edma_chan *echan)
struct edma_desc *edesc;
struct device *dev = echan-vchan.chan.device-dev;
-int i, j, total_left, total_process;
+int i, total_left, total_link_set;
+int ls_cur_off, ls_next_off, slot_off;
+struct edmacc_param tmp_param;
/* If either we processed all psets or we're still not started */
if (!echan-edesc ||
@@ -159,48 +163,121 @@ static void edma_execute(struct edma_chan *echan)
/* Find out how many left */
total_left = edesc-pset_nr - edesc-total_processed;
-total_process = total_left MAX_NR_SG ? MAX_NR_SG : total_left;
-
-
-/* Write descriptor PaRAM set(s) */
-for (i = 0; i total_process; i++) {
-j = i + edesc-total_processed;
-edma_write_slot(echan-slot[i], edesc-pset[j]);
-dev_dbg(echan-vchan.chan.device-dev,
-\n pset[%d]:\n
- chnum\t%d\n
- slot\t%d\n
- opt\t%08x\n
- src\t%08x\n
- dst\t%08x\n
- abcnt\t%08x\n
- ccnt\t%08x\n
- bidx\t%08x\n
- cidx\t%08x\n
- lkrld\t%08x\n,
-j, echan-ch_num, echan-slot[i],
-edesc-pset[j].opt,
-edesc-pset[j].src,
-edesc-pset[j].dst,
-edesc-pset[j].a_b_cnt,
-edesc-pset[j].ccnt,
-edesc-pset[j].src_dst_bidx,
-edesc-pset[j].src_dst_cidx,
-edesc-pset[j].link_bcntrld);
-/* Link to the previous slot if not the last set */
-if (i != (total_process - 1))
+total_link_set = total_left MAX_NR_LS ? MAX_NR_LS : total_left;
The name you gave here sounds like this is defining total number of
linked PaRAM sets. Rather this is actually tracking the number of PaRAM
sets (slots) in current linked set, correct? Then may be just call it
'nslots' or even 'num_slots'? There are just too many variables with
total prefix to keep track of in this function!
I would rather just leave this naming alone. The code is quite self
documenting: total_link_set means Calculate what's the total size of a
Linkset, or total no.of slots in a linkset we need. This naming is fine
in my opinion and doesn't hurt line size at all, instead improving code
readability. I could dump the _ between link and set to make it:
total_linkset if that makes it any easier.
I agree there are too many variables in this function, but they each
serve a different purpose and required to implement the algorithm, which
is precisely I made them naming a bit more descriptive.
+
+/* First time, setup 2 cyclically linked sets, each containing half
+ the slots allocated for this channel */
+if (edesc-total_processed == 0) {
We dont need to check for this case for every DMA_COMPLETE interrupt.
May be move the initial setup to another function called from
edma_issue_pending()?
But how? That would only change the code to (?):
if (edesc-total_processed == 0) {
issue_pending();
}
Further it maybe appear that this case is uncommon, but it is a
Re: [PATCH v3 07/12] dma: edma: Add function to dump a PaRAM set from PaRAM
On 08/12/2013 12:52 AM, Sekhar Nori wrote:
On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote:
Previously, such a dump function was used but it wasn't reading
from the PaRAM, rather just from a edmacc_param structure, we
add a helpful function for debugging that directly reads from
the PaRAM and gives the current state correctly (including links
and interrupt information).
Signed-off-by: Joel Fernandes jo...@ti.com
You should convert existing instances of PaRAM set dump to use this new
function along with introducing it.
Well, the old dump callers were thrown out with completely rewritten
code. This rewritten code already contains the dump calls. Are you
saying pull out those dump pset calls into a separate patch?
Thanks,
-Joel
Sekhar
---
drivers/dma/edma.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 080d669..a242269 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -102,6 +102,37 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
kfree(container_of(vdesc, struct edma_desc, vdesc));
}
+static inline void dump_pset(struct edma_chan *echan, int slot,
+ struct edmacc_param *pset_unused, int pset_idx)
+{
+struct edmacc_param pset_local, *pset;
+pset = pset_local;
+
+edma_read_slot(slot, pset);
+
+dev_dbg(echan-vchan.chan.device-dev,
+\n pset[%d]:\n
+ chnum\t%d\n
+ slot\t%d\n
+ opt\t%08x\n
+ src\t%08x\n
+ dst\t%08x\n
+ abcnt\t%08x\n
+ ccnt\t%08x\n
+ bidx\t%08x\n
+ cidx\t%08x\n
+ lkrld\t%08x\n,
+pset_idx, echan-ch_num, slot,
+pset[0].opt,
+pset[0].src,
+pset[0].dst,
+pset[0].a_b_cnt,
+pset[0].ccnt,
+pset[0].src_dst_bidx,
+pset[0].src_dst_cidx,
+pset[0].link_bcntrld);
+}
+
/* Dispatch a queued descriptor to the controller (caller holds lock) */
static void edma_execute(struct edma_chan *echan)
{
--
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 08/12] dma: edma: Add one more required slot to MAX slots
On 08/12/2013 12:56 AM, Sekhar Nori wrote: On Monday 05 August 2013 09:44 PM, Joel Fernandes wrote: We'd now need a separate slot just for the channel and separate ones for the 2 linked sets, so we make adjustments to allocate an extra channel accordingly. Signed-off-by: Joel Fernandes jo...@ti.com No need for a separate patch for this, just do this in the patch where you include the two linked sets. Ok, I dropped this patch. Anyway, most of this patch has gone away now because of other changes you suggested. Thanks, -Joel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] extcon: palmas: Added a new compatible type *ti,palmas-usb-vid*
The Palmas device contains only a USB VID detector, so added a
compatible type *ti,palmas-usb-vid*. Dint remove the existing compatible
types for backward compatibility.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/extcon/extcon-twl.txt |3 ++-
drivers/extcon/extcon-palmas.c |1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
index 58f531a..5be4afc 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-twl.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -2,7 +2,8 @@ EXTCON FOR TWL CHIPS
PALMAS USB COMPARATOR
Required Properties:
- - compatible : Should be ti,palmas-usb or ti,twl6035-usb
+ - compatible : Should be ti,palmas-usb or ti,twl6035-usb or
+ ti,palmas-usb-vid.
- vbus-supply : phandle to the regulator device tree node.
Optional Properties:
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index b752a0a..4f83fae 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -223,6 +223,7 @@ static int palmas_usb_remove(struct platform_device *pdev)
static struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = ti,palmas-usb, },
+ { .compatible = ti,palmas-usb-vid, },
{ .compatible = ti,twl6035-usb, },
{ /* end */ }
};
--
1.7.10.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
[PATCH v4 2/2] arm: omap5: dts: add palmas-usb node
From: Felipe Balbi ba...@ti.com
Without this node, there will be no palmas
driver to notify dwc3 that a cable has
been connected and, without that, dwc3
will never initialize.
[ kis...@ti.com : fix vbus-supply value after SMPS10 is modeled as 2 regulators]
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Changes from v3:
* Changed the compatible type to ti,palmas-usb-vid
Changes from v2:
fix vbus-supply value after SMPS10 is modeled as 2 regulators. This is needed
after SMPS10 is modeled as 2 regulators.
[1] models SMPS10 as 2 regulators.
[2] splits the SMPS10 node into two to represent the 2 regulators.
[1] - http://comments.gmane.org/gmane.linux.kernel/1542521
[2] - http://www.mail-archive.com/linux-omap@vger.kernel.org/msg93779.html
arch/arm/boot/dts/omap5-uevm.dts | 10 ++
arch/arm/boot/dts/omap5.dtsi |2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index e8704bc..c18ea50 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -272,6 +272,11 @@
interrupt-controller;
#interrupt-cells = 2;
+ extcon_usb3: palmas_usb {
+ compatible = ti,palmas-usb-vid;
+ ti,wakeup;
+ };
+
palmas_pmic {
compatible = ti,palmas-pmic;
interrupt-parent = palmas;
@@ -460,6 +465,11 @@
phys = 0 hsusb2_phy hsusb3_phy;
};
+usb3 {
+ extcon = extcon_usb3;
+ vbus-supply = smps10_out1_reg;
+};
+
mcspi1 {
};
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 4e41409..1659246 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -634,7 +634,7 @@
ti,type = 2;
};
- omap_dwc3@4a02 {
+ usb3: omap_dwc3@4a02 {
compatible = ti,dwc3;
ti,hwmods = usb_otg_ss;
reg = 0x4a02 0x1;
--
1.7.10.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
