mailing list shutting down
Hi, There are security issues with the server that hosts this mailing list and TI has decided to shut it down. Starting tomorrow, davinci-linux-open-source@linux.davincidsp.com will not be accessible. For kernel patches please send to LAKML and CC myself and Kevin. For other non-patch related discussions/questions please consider asking on LAKML or e2e.ti.com depending on the context. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci DT additions for v3.18 (merge window)
On Friday 05 September 2014 01:26 AM, Arnd Bergmann wrote: On Monday 01 September 2014, Sekhar Nori wrote: The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git v3.18/dt This is a branch, not a tag. Forgot to push out the signed tag? Yes, I did! Here is an updated pull request. The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.18/dt for you to fetch changes up to 3f526696e7840239844fc7ff9b5cf014d7192c42: ARM: DTS: da850-evm: Enable audio via simple-card (2014-08-26 15:34:44 +0530) DT additions for DA850. Adds EDMA and audio support. Peter Ujfalusi (6): ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0 ARM: DTS: da850: Add node for edma0 ARM: DTS: da850: Add node for McASP ARM: DTS: da850-evm: Enable McASP via DT boot ARM: DTS: da850-evm: Add node for tlv320aic3106 codec ARM: DTS: da850-evm: Enable audio via simple-card arch/arm/boot/dts/da850-evm.dts | 72 ++ arch/arm/boot/dts/da850.dtsi | 19 ++ arch/arm/mach-davinci/da8xx-dt.c |1 + 3 files changed, 92 insertions(+) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci fixes for v3.17
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.17-rc4 for you to fetch changes up to 929a015b1809a30748d487f9d25b16a41434b61a: ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC (2014-08-26 14:49:15 +0530) This patch fixes setup of second EDMA channel controller on DA850. Peter Ujfalusi (1): ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC arch/arm/common/edma.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci board file fixes for v3.18 (merge window)
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.18/board for you to fetch changes up to 9e9bc235580829e3a06ccd13aa10110478c2e093: ARM: davinci: board-da850-evm: Add needed regulators for tlv320aic3106 codec (2014-08-26 15:43:51 +0530) Some non-critcal fixes for DA850 EVM board file adding missing regulator information. Peter Ujfalusi (2): ARM: davinci: board-da850-evm: Mark dcdc2 of TPS65070 as always_on ARM: davinci: board-da850-evm: Add needed regulators for tlv320aic3106 codec arch/arm/mach-davinci/board-da850-evm.c | 15 +++ 1 file changed, 15 insertions(+) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci DT additions for v3.18 (merge window)
The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git v3.18/dt for you to fetch changes up to 3f526696e7840239844fc7ff9b5cf014d7192c42: ARM: DTS: da850-evm: Enable audio via simple-card (2014-08-26 15:34:44 +0530) DT additions for DA850. Adds EDMA and audio support. Peter Ujfalusi (6): ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0 ARM: DTS: da850: Add node for edma0 ARM: DTS: da850: Add node for McASP ARM: DTS: da850-evm: Enable McASP via DT boot ARM: DTS: da850-evm: Add node for tlv320aic3106 codec ARM: DTS: da850-evm: Enable audio via simple-card arch/arm/boot/dts/da850-evm.dts | 72 ++ arch/arm/boot/dts/da850.dtsi | 19 ++ arch/arm/mach-davinci/da8xx-dt.c |1 + 3 files changed, 92 insertions(+) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC
On Monday 04 August 2014 05:56 PM, Peter Ujfalusi wrote: The edma_setup_from_hw() should know about the CC number when parsing the CCCFG register - when it reads the register to be precise. The base addresses for CCs stored in an array and we need to provide the correct id to edma_read() in order to read the correct register. Cc: sta...@vger.kernel.org # 3.16 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Applied and will queue for v3.17-rc Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/2] ARM: davinci: board-da850-evm: Add needed regulators for tlv320aic3106 codec
On Monday 28 July 2014 04:54 PM, Peter Ujfalusi wrote: IOVDD: tps65070's dcdc2 AVDD and DRVDD: fixed regulator derived from 5V via TPS73701DCQ DVDD: fixed regulator derived from 5V via TPS73701DCQ This patch needed to be able to probe the audio codec. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/mach-davinci/board-da850-evm.c | 13 + Applied both for v3.18 while fixing the following: CHECK: Please use a blank line after function/struct/union/enum declarations #56: FILE: arch/arm/mach-davinci/board-da850-evm.c:845: } +/* Fixed regulator support */ total: 0 errors, 0 warnings, 1 checks, 37 lines checked Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/6] ARM: DT/davinci: Audio for da850-evm in DT boot
On Friday 01 August 2014 11:43 AM, Peter Ujfalusi wrote: Hi, Changes since v1: - fixed the address missmatch for tlv320aic3106 codec (@1b - 18) - The edma patches has been taken by Vinod, they should be in linux-next soon. I assume all of these 6 patches are meant to go through ARM SoC. I have applied all of them for v3.18. The following series will enable audio via simple card on the board when booted with DT. Thanks for doing this. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 0/6] ARM: DT/davinci: Audio for da850-evm in DT boot
On Tuesday 26 August 2014 03:54 PM, Sekhar Nori wrote: On Friday 01 August 2014 11:43 AM, Peter Ujfalusi wrote: Hi, Changes since v1: - fixed the address missmatch for tlv320aic3106 codec (@1b - 18) - The edma patches has been taken by Vinod, they should be in linux-next soon. I assume all of these 6 patches are meant to go through ARM SoC. I have applied all of them for v3.18. The following series will enable audio via simple card on the board when booted with DT. Thanks for doing this. Also tested audio playback and record on DA850 EVM. Works great! Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 2/6] ARM: DTS: da850: Add node for edma0
On Friday 01 August 2014 10:39 AM, Peter Ujfalusi wrote:
On 07/31/2014 05:26 PM, Sergei Shtylyov wrote:
On 07/31/2014 02:18 PM, Peter Ujfalusi wrote:
Add DT node for edma0.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/da850.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index b695548dbb4e..41ce4e8bf227 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -150,6 +150,12 @@
};
};
+edma0: edma@01c0 {
+compatible = ti,edma3;
+reg =0x0 0x1;
Why the mismatch between the unit-address part of the node name and the
reg property?
For some reason the whole da850 uses offset from 0x01c0 for the SoC IPs.
The nodes are under 'soc' and that has the ranges attribute.
I do not really like this either.
There is no reason I can remember for why we chose to go the offset +
ranges way. Probably based it on an early OMAP example. Right now lets
keep it that way unless there is a big disadvantage.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: i2c-davinci.c: CPU FREQ causes lock up due to xfr_complete
On Tuesday 29 July 2014 11:00 PM, Grygorii Strashko wrote:
Hi Jon,
On 07/29/2014 06:53 PM, Jon Cormier wrote:
A slimmer patch suggested by Grygorii Strashko grygorii.stras...@ti.com
Ok. The problem seems to be deeper than at first look.
You have sequence (in Mainline kernel):
cpufreq:
|- notify CPUFREQ_PRECHANGE
|- i2c-davinci will lock put I2C in reset
|- cpufreq_driver-target_index
|- davinci_target()
|- pdata-set_voltage() - It will try to use I2C to set new voltage,
while I2C is in reset or locked! Bug!
|- notify CPUFREQ_POSTCHANGE
|- i2c-davinci will re-enable I2C and adjust I2C clock
Good find. I really wonder how this escaped so far. I can swear cpufreq
transitions were tested multiple times. From the description it looks
like this should hit every single time there is a voltage adjustment.
On DA850 which is the only DaVinci implementing cpufreq, I2C0 input
frequency will remain constant across cpufreq transitions since it
derives from PLL0 AUXCLK which is used pre-multipler/divider. It remains
fixed.
The code seems to have been added for I2C1 which does have a fixed ratio
with cpu clock.
PMIC should usually be put on I2C0 to help prevent these kind of issues.
I see few possible ways to solve it:
1) use CLK notifier instead of CPUfreq notifiers
This will require common clock framework, right? We dont have that on
mach-davinci.
2) do smth similar to 61c7cff8 i2c: S3C24XX I2C frequency scaling support
+ 9bcd04bf i2c: s3c2410: grab adapter lock while changing i2c clock
This looks promising. Although I wonder if delta_f will always remain
zero in s3c24xx_i2c_cpufreq_transition() when the CPUFREQ_PRECHANGE call
is made - because clock tree is not updated yet?
3) update I2C clock in CPUFREQ_POSTCHANGE - may be unsafe
Well, even now the I2C clock is only getting updated in POSTCHANGE,
right? Also, resetting I2C in PRECHANGE seems excessive. It is only
required when changing the prescalar. So you can do:
} else if (val == CPUFREQ_POSTCHANGE) {
davinci_i2c_reset_ctrl(dev, 0);
i2c_davinci_calc_clk_dividers(dev);
davinci_i2c_reset_ctrl(dev, 1);
}
So this along with the i2c_lock_adapter() a la
s3c24xx_i2c_cpufreq_transition() should be the right fix, I guess.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/3] ARM/dma: edma: Serve cyclic clients via high priority queue
On Monday 28 July 2014 11:42 AM, Peter Ujfalusi wrote: On 07/08/2014 01:46 PM, Peter Ujfalusi wrote: Hi, It is preferred that audio is served with the highest priority queue in order to avoid delays in data transfer between memory and audio IP. The following series will add an API to arch code to assign a channel to a given queue. The default queue is changed from 0 (highest priority) to lowest priority. This should not really change any performance behavior as everything at highest priority is same as everything at lowest priority. In the dmaengine driver we move the cyclic channel to queue0 (highest priority) and move it back to default queue when the channel is terminated. ping? For 1/3 and 2/3: Acked-by: Sekhar Nori nsek...@ti.com Vinod, can you take the series together with your tree (if you are happy with the series, that is)? I don't have anything else queued for this merge window. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: convert all mov.* pc, reg to bx reg for ARMv6+
On Tuesday 01 July 2014 09:28 PM, Russell King wrote: ARMv6 and greater introduced a new instruction (bx) which can be used to return from function calls. Recent CPUs perform better when the bx lr instruction is used rather than the mov pc, lr instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro ret with all its variants for the condition code which will resolve to the appropriate instruction. Rather than doing this piecemeal, and miss some instances, change all the mov pc instances to use the new macro, with the exception of the movs instruction and the kprobes code. This allows us to detect the mov pc, lr case and fix it up - and also gives us the possibility of deploying this for other registers depending on the CPU selection. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-davinci/sleep.S| 2 +- I build, boot and suspend-to-RAM tested on DA850 which should exercise the path you modified. DaVinci devices are ARMv5 (ARM926) so the new bx instruction does not really get used. Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL 01/02] DaVinci EDMA clean-up for v3.16
On Tuesday 27 May 2014 03:28 AM, Olof Johansson wrote: This had a conflict with the fix from Thomas that fixes the binding. To avoid this, you could have merged Vinod's branch in on top of the fix branch you had, then build your new contents on top. I did notice the conflict, but did not think about merging my fixes branch in. Anyway, not a huge deal, but something to tweak in the future. Thanks. Will keep in mind. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL 01/02] DaVinci EDMA clean-up for v3.16
Hi Olof, Kevin, Arnd, These patches introduce a change to EDMA bindings. They deprecate some bindings but new kernel will continue to work with older DTBs since the information is now read from hardware instead. I have not been able to get an Ack/response from DT folks on this. Since it has been close to two weeks since the patches were first posted, I am asking for the patches to be merged so we dont miss the merge window. This pull request is on top of Vinod's topic/edma branch which he has guaranteed will not be rebased before going to Linus. This was needed because of dependency with some patches he has queued. This series introduces a trivial merge conflict with Linux-next because of a bug fix which went in after Vinod's branch was built. Thanks, Sekhar The following changes since commit b0cce4ca3e740b5224d75634aa9d9abe9dfceabb: dmaengine: edma: update DMA memcpy to use new param element (2014-04-30 10:36:57 +0530) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.16/edma for you to fetch changes up to 903ed4913c7fe78d2746445564634264291c7493: ARM: edma: Remove redundant/unused parameters from edma_soc_info (2014-05-22 14:55:25 +0530) This series makes edma use configuration information available within the IP instead of reading it from platform data or DT. Some other useful clean-ups are included too. Peter Ujfalusi (14): ARM: edma: Clean up and simplify the code around irq request ARM: edma: No need to clean the pdata in edma_of_parse_dt() ARM: edma: Take the number of tc from edma_soc_info (pdata) ARM: edma: Do not change TC - Queue mapping, leave it to default. ARM: davinci: Remove eDMA3 queue_tc_mapping data from edma_soc_info ARM: edma: Remove queue_tc_mapping data from edma_soc_info ARM: edma: Remove num_cc member from struct edma ARM: edma: Save number of regions from pdata to struct edma ARM: edma: Get IP configuration from HW (number of channels, tc, etc) dt/bindings: ti,edma: Remove redundant properties from documentation ARM: dts: am33xx: Remove obsolete properties from edma node ARM: dts: am4372: Remove obsolete properties from edma node ARM: davinci: Remove redundant/unused parameters for edma ARM: edma: Remove redundant/unused parameters from edma_soc_info Documentation/devicetree/bindings/dma/ti-edma.txt | 13 +- arch/arm/boot/dts/am33xx.dtsi |3 - arch/arm/boot/dts/am4372.dtsi |3 - arch/arm/common/edma.c| 175 ++--- arch/arm/mach-davinci/devices-da8xx.c | 31 arch/arm/mach-davinci/dm355.c | 14 -- arch/arm/mach-davinci/dm365.c | 16 -- arch/arm/mach-davinci/dm644x.c| 14 -- arch/arm/mach-davinci/dm646x.c| 16 -- include/linux/platform_data/edma.h|8 - 10 files changed, 93 insertions(+), 200 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL 02/02] DaVinci board changes for v3.16
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.16/board for you to fetch changes up to ea56785629494394b9e567c0a43690d6c972e137: ARM: davinci: remove checks for CONFIG_USB_MUSB_PERIPHERAL (2014-05-22 16:29:08 +0530) This patch clean-up an unused #define from code. Paul Bolle (1): ARM: davinci: remove checks for CONFIG_USB_MUSB_PERIPHERAL arch/arm/configs/davinci_all_defconfig |1 - arch/arm/mach-davinci/board-dm355-evm.c |4 arch/arm/mach-davinci/board-dm355-leopard.c |4 3 files changed, 9 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] i2c: davinci: Add block read functionality for IPMI
On Friday 02 May 2014 12:19 AM, Murali Karicheri wrote: Intelligent Plaform Management Interface (IPMI) requires I2C driver to support block read, where the first byte received from slave is the length of following data:- Added length check if the read type is block read (I2C_M_RECV_LEN) Send NACK/STOP bits before last byte is received Signed-off-by: Garrett Ding g-d...@ti.com Signed-off-by: Murali Karicheri m-kariche...@ti.com I tested this on a DA850 using i2cdetect and it did not seem to break anything so: Tested-by: Sekhar Nori nsek...@ti.com There are some checks that were triggered in checkpatch. You may want to fix them up. Thanks, Sekhar CHECK: Alignment should match open parenthesis #112: FILE: drivers/i2c/busses/i2c-davinci.c:557: + w = davinci_i2c_read_reg(dev, + DAVINCI_I2C_MDR_REG); CHECK: Alignment should match open parenthesis #115: FILE: drivers/i2c/busses/i2c-davinci.c:560: + davinci_i2c_write_reg(dev, + DAVINCI_I2C_MDR_REG, w); CHECK: Alignment should match open parenthesis #119: FILE: drivers/i2c/busses/i2c-davinci.c:564: + davinci_i2c_write_reg(dev, + DAVINCI_I2C_MDR_REG, w); total: 0 errors, 0 warnings, 3 checks, 67 lines checked ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci boot failures in next-20140519
On Tuesday 20 May 2014 10:32 PM, Prabhakar Lad wrote: Sekhar, I am not sure why this didnt work on your side you can find the boot log at [1], I tested this on latest next. I tried NFS after a long time. It could have been some setup issue. Thanks for testing at your end. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci boot failures in next-20140519
On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote: Hi, On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote: As found by my automated boot tester[1], dm365 EVM and da850 EVM started failing boot tests in today's linux-next. I haven't had the time to bisect, but it appears to be related to some devres failures in the EMAC driver. Full boot log below for the da850evm (the dm365 fault looks the same.) I too hit this issue, this was introduced with commit id: e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net: davinci_cpdma: Convert kzalloc() to devm_kzalloc().) Reverting this patch fixes it. From the outset patch looks good, not sure why exactly it is failing. Following patch seems to help. I will post it for review after some more analysis. Thanks, Sekhar diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/da index e76eae5..9cd0d9c 100644 --- a/drivers/net/ethernet/ti/davinci_emac.c +++ b/drivers/net/ethernet/ti/davinci_emac.c @@ -1930,7 +1930,7 @@ static int davinci_emac_probe(struct platform_device *pdev hw_ram_addr = (u32 __force)res-start + pdata-ctrl_ram_offset; memset(dma_params, 0, sizeof(dma_params)); - dma_params.dev = emac_dev; + dma_params.dev = pdev-dev; dma_params.dmaregs = priv-emac_base; dma_params.rxthresh = priv-emac_base + 0x120; dma_params.rxfree = priv-emac_base + 0x140; ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci boot failures in next-20140519
On Tuesday 20 May 2014 02:46 PM, Prabhakar Lad wrote: Hi Sekhar, On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote: Hi, On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote: As found by my automated boot tester[1], dm365 EVM and da850 EVM started failing boot tests in today's linux-next. I haven't had the time to bisect, but it appears to be related to some devres failures in the EMAC driver. Full boot log below for the da850evm (the dm365 fault looks the same.) I too hit this issue, this was introduced with commit id: e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net: davinci_cpdma: Convert kzalloc() to devm_kzalloc().) Reverting this patch fixes it. From the outset patch looks good, not sure why exactly it is failing. Following patch seems to help. I will post it for review after some more analysis. I am not sure if you hit the following issue later fixing above one, I see following issue on DA850 evm, No, I am using ramdisk though. Are you using NFS? git bisect points me to commit id: 975c3a671f11279441006a29a19f55ccc15fb320 ( mm: non-atomically mark page accessed during page cache allocation where possible) Does reverting this cause the issue to disappear? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] net: davinci_emac: fix oops caused by uninitialized ndev-dev
Commit e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
davinci_cpdma: Convert kzalloc() to devm_kzalloc()) triggered
a bug in emac_probe() wherein dev member of net_device is used
for devres allocations even before it is initialized.
This patch fixes that by using the struct device in platform_device
instead.
While at it, use pdev-dev consistently for console messages instead
of using ndev-dev for just one case and remove an unnecessary line
continuation.
Reported-by: Kevin Hilman khil...@linaro.org
Helped-by: George Cherian george.cher...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
This patch fixes a bug in linux-next so it can wait for
v3.16
drivers/net/ethernet/ti/davinci_emac.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c
b/drivers/net/ethernet/ti/davinci_emac.c
index e76eae5..f32d730 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1865,7 +1865,6 @@ static int davinci_emac_probe(struct platform_device
*pdev)
struct emac_priv *priv;
unsigned long hw_ram_addr;
struct emac_platform_data *pdata;
- struct device *emac_dev;
struct cpdma_params dma_params;
struct clk *emac_clk;
unsigned long emac_bus_frequency;
@@ -1911,7 +1910,6 @@ static int davinci_emac_probe(struct platform_device
*pdev)
priv-coal_intvl = 0;
priv-bus_freq_mhz = (u32)(emac_bus_frequency / 100);
- emac_dev = ndev-dev;
/* Get EMAC platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
priv-emac_base_phys = res-start + pdata-ctrl_reg_offset;
@@ -1930,7 +1928,7 @@ static int davinci_emac_probe(struct platform_device
*pdev)
hw_ram_addr = (u32 __force)res-start + pdata-ctrl_ram_offset;
memset(dma_params, 0, sizeof(dma_params));
- dma_params.dev = emac_dev;
+ dma_params.dev = pdev-dev;
dma_params.dmaregs = priv-emac_base;
dma_params.rxthresh = priv-emac_base + 0x120;
dma_params.rxfree = priv-emac_base + 0x140;
@@ -1994,7 +1992,7 @@ static int davinci_emac_probe(struct platform_device
*pdev)
if (netif_msg_probe(priv)) {
- dev_notice(emac_dev, DaVinci EMAC Probe found device \
+ dev_notice(pdev-dev, DaVinci EMAC Probe found device
(regs: %p, irq: %d)\n,
(void *)priv-emac_base_phys, ndev-irq);
}
--
1.7.10.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci boot failures in next-20140519
On Tuesday 20 May 2014 05:29 PM, Mel Gorman wrote:
On Tue, May 20, 2014 at 02:46:47PM +0530, Prabhakar Lad wrote:
Hi Sekhar,
On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori nsek...@ti.com wrote:
On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
Hi,
On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman khil...@linaro.org wrote:
As found by my automated boot tester[1], dm365 EVM and da850 EVM started
failing boot tests in today's linux-next.
I haven't had the time to bisect, but it appears to be related to some
devres failures in the EMAC driver. Full boot log below for the
da850evm (the dm365 fault looks the same.)
I too hit this issue, this was introduced with commit id:
e194312854edc22a2faf1931b3c0608fe20cb969 (drivers: net:
davinci_cpdma: Convert kzalloc() to devm_kzalloc().)
Reverting this patch fixes it.
From the outset patch looks good, not sure why exactly it is failing.
Following patch seems to help. I will post it for review after some more
analysis.
I am not sure if you hit the following issue later fixing above one,
I see following issue on DA850 evm,
git bisect points me to
commit id: 975c3a671f11279441006a29a19f55ccc15fb320
( mm: non-atomically mark page accessed during page cache allocation
where possible)
Unable to handle kernel paging request at virtual address 30e03501
pgd = c68cc000
[30e03501] *pgd=
Internal error: Oops: 1 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 1015 Comm: network.sh Not tainted 3.15.0-rc5-00323-g975c3a6 #9
task: c70c4e00 ti: c73d task.ti: c73d
PC is at init_page_accessed+0xc/0x24
LR is at shmem_write_begin+0x54/0x60
pc : [c0088aa0]lr : [c00923e8]psr: 2013
What line does this address correspond to according to addr2line? It's not
addr2line shows mm/swap.c:622
objdump shows that page pointer is corrupt in init_page_accessed()
c00805ec init_page_accessed:
/*
* Used to mark_page_accessed(page) that is not visible yet and when it is
* still safe to use non-atomic ops
*/
void init_page_accessed(struct page *page)
{
c00805ec: e1a0c00dmov ip, sp
c00805f0: e92dd800push{fp, ip, lr, pc}
c00805f4: e24cb004sub fp, ip, #4
c00805f8: e5903000ldr r3, [r0]
if (!PageReferenced(page))
c00805fc: e3130004tst r3, #4
When crash occurs, instruction at address c00805f8 crashes with r0 corrupt.
Attached[1] is the corresponding oops message.
Could you try this please?
diff --git a/mm/filemap.c b/mm/filemap.c
index 2a7b9d1..0691481 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2459,7 +2459,7 @@ ssize_t generic_perform_write(struct file *file,
flags |= AOP_FLAG_UNINTERRUPTIBLE;
do {
- struct page *page;
+ struct page *page = NULL;
unsigned long offset; /* Offset into pagecache page */
unsigned long bytes;/* Bytes to write to page */
size_t copied; /* Bytes copied from user */
This definitely avoided the oops, but I am still not able to get nfsroot
working
(it starts to mount the filesystem and eventually timesout). It could be a
different
problem. Need to get to a known working setup and then bisect.
Thanks,
Sekhar
[1] oops log that I observed.
Unable to handle kernel NULL pointer dereference at virtual address 000b
pgd = c703
[000b] *pgd=c7a9e831, *pte=, *ppte=
Internal error: Oops: 1 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 976 Comm: udevd Not tainted 3.15.0-rc5-next-20140519-07053-g0855e8f
#384
task: c7a7d500 ti: c7ad6000 task.ti: c7ad6000
PC is at init_page_accessed+0xc/0x24
LR is at shmem_write_begin+0x58/0x64
pc : [c00805f8]lr : [c0089d5c]psr: 2013
sp : c7ad7da8 ip : c7ad7db8 fp : c7ad7db4
r10: c0312600 r9 : c7ad7ee8 r8 :
r7 : 1000 r6 : c7ba365c r5 : ffe4 r4 : c7ad7e00
r3 : r2 : 0001 r1 : c7ad7d60 r0 : 000b
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: c703 DAC: 0015
Process udevd (pid: 976, stack limit = 0xc7ad61c0)
Stack: (0xc7ad7da8 to 0xc7ad8000)
7da0: c7ad7dd4 c7ad7db8 c0089d5c c00805fc 000200da
7dc0: 0005 c7ad7ed4 c7ad7e34 c7ad7dd8 c00751f0 c0089d14 0005
7de0: c7ad7e00 c7ad7e04 c7ad6000 c715e500
7e00: 000b 13ab6681 000b 0005 c715e500 c7ad6038
7e20: c7ad7ee8 c7ba365c c7ad7e8c c7ad7e38 c0077274 c007509c c0026850 c002648c
7e40: c7a7d7b4 c7ad7e90 c7ad7e74 c7ba35fc c7ad7ed4 c7ad7ed4 c7a7d500
7e60: beeffc58 c7ad7ee8 c7ba35fc c7ad7ed4 c715e500 c7a7d500 beeffc58
7e80: c7ad7ebc c7ad7e90 c0077568 c0077110 c7ad7ebc c7ad7ea0 c000c064 c000b118
7ea0: c7ad7f78 c715e500 c7ad7f44 c7ad7ec0 c00aedb8 c007753c
7ec0: 0005 c00af6b0 c7ad7f74 beeffc58 0005 0001 0005
7ee0: c7ad7ecc 0001
Re: [PATCH] ARM: davinci: remove checks for CONFIG_USB_MUSB_PERIPHERAL
On Thursday 15 May 2014 03:47 PM, Paul Bolle wrote: The Kconfig symbol USB_MUSB_PERIPHERAL was removed in v3.1. The last two checks for its macro now always evaluate to false. So remove these checks. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Eyeball tested only. This is just a straightforward cleanup. It does remove a comment. Is that comment still useful? Anyhow, I do wonder whether a proper fix is possible here. Perhaps Greg or Felipe knows: it is their commit 622859634a66 (usb: musb: drop a gigantic amount of ifdeferry) that removed USB_MUSB_PERIPHERAL. On the other hand I noticed that config USB_MUSB_DAVINCI depends on BROKEN. So maybe properly fixing just this small problem doesn't buy us much. Yes, it doesn't buy us much. I will still apply this anyway. The next person can save time spent searching for non-existing symbols. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci fixes for v3.15
On Sunday 11 May 2014 10:35 AM, Olof Johansson wrote: On Sat, May 10, 2014 at 3:57 AM, Sekhar Nori nsek...@ti.com wrote: Hi, On Tuesday 29 April 2014 08:03 PM, Sekhar Nori wrote: The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.15-rc4 for you to fetch changes up to cf7eb979116c2568e8bc3b6a7269c7a359864ace: ARM: common: edma: Fix xbar mapping (2014-04-29 19:33:49 +0530) Can you please pull this fix? Sekhar, I missed it because it wasn't sent to a...@kernel.org. Please send pull requests and patches you want us to directly apply there in the future (it goes to all of us). Thanks. Will keep in mind. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci fixes for v3.15
Hi, On Tuesday 29 April 2014 08:03 PM, Sekhar Nori wrote: The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.15-rc4 for you to fetch changes up to cf7eb979116c2568e8bc3b6a7269c7a359864ace: ARM: common: edma: Fix xbar mapping (2014-04-29 19:33:49 +0530) Can you please pull this fix? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: IGMP issue with Davinci kernel 2.6.31
On Saturday 03 May 2014 02:35 AM, Junfeng Feng wrote: Hello there, Right now, I try to support the IGMP functionality on Davinci. I have configured the option CONFIG_IP_MULTICAST. But when I try to join or leave one multicast group, I did not see the multicast traffic. For comparison, I have tried the same test program on Netra chip with kernel 2.6.37 and there is multicast message there. Have anyone encountered the same issue before? Thanks. This could be some issue in the mainline driver patched for in the TI tree. If you have not done so already, can you please send a mail to netdev list preferably after testing with latest mainline. You can also cc Mugunthan V N mugunthan...@ti.com Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci fixes for v3.15
The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.15-rc4 for you to fetch changes up to cf7eb979116c2568e8bc3b6a7269c7a359864ace: ARM: common: edma: Fix xbar mapping (2014-04-29 19:33:49 +0530) The patch fixes EDMA crossbar mapping to actually make it work. The patch has been tagged for stable. Thomas Gleixner (1): ARM: common: edma: Fix xbar mapping Documentation/devicetree/bindings/dma/ti-edma.txt |4 ++-- arch/arm/boot/dts/am33xx.dtsi |2 +- arch/arm/common/edma.c| 48 +++- 3 files changed, 18 insertions(+), 36 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DA850 - SD detection broken by edma change (but only on mainline)
On Thursday 17 April 2014 04:50 AM, Peter Howard wrote: On Tue, 2014-04-15 at 08:34 +1000, Peter Howard wrote: On Mon, 2014-04-14 at 14:02 +0530, Sekhar Nori wrote: Peter, On Monday 14 April 2014 12:30 PM, Peter Howard wrote: For the DA850, I've found that trying to detection of a card in the SD slot during boot is broken as of 3.12 on mainline. You end up like this (from a 3.14 kernel.org kernel): Could you try this patch? http://www.spinics.net/lists/linux-omap/msg104627.html That patch, by itself, doesn't appear to fix the problem. Whereas fully reverting the quoted patch does. Correction. I don't know what I did wrong the first time, but I tried applying it again to a clean untar of the linux-3.14 tarball from kernel.org, and it _does_ fix the problem. Okay, cool. The patch is present in v3.15-rc2 with stable tag added so it should fan out to various stable trees soon. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 3/8] davinci: da850: Use cpufreq_for_each_entry macro for iteration
On Wednesday 16 April 2014 03:56 AM, Stratos Karafotis wrote: The cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it. It should have no functional changes. Signed-off-by: Stratos Karafotis strat...@semaphore.gr I cannot test this (or even build this) since I do not have the patch which adds cpufreq_for_each_entry(). The change as such looks fine to me. Please prefix the subject line with ARM: as is the convention in ARM world. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/1] dma: edma: fix incorrect SG list handling
Vinod, On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote: The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: sta...@vger.kernel.org # v3.12.x+ Cc: Joel Fernandes jo...@ti.com Acked-by: Joel Fernandes jo...@ti.com Tested-by: Jon Ringle jrin...@gridpoint.com Tested-by: Alexander Holler hol...@ahsoftware.de Reported-by: Jon Ringle jrin...@gridpoint.com Signed-off-by: Sekhar Nori nsek...@ti.com Looks like this patch is not in mainline still? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DA850 - SD detection broken by edma change (but only on mainline)
Peter, On Monday 14 April 2014 12:30 PM, Peter Howard wrote: For the DA850, I've found that trying to detection of a card in the SD slot during boot is broken as of 3.12 on mainline. You end up like this (from a 3.14 kernel.org kernel): Could you try this patch? http://www.spinics.net/lists/linux-omap/msg104627.html Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/1] dma: edma: fix incorrect SG list handling
On Monday 14 April 2014 02:27 PM, Vinod Koul wrote: On Mon, Apr 14, 2014 at 02:01:11PM +0530, Sekhar Nori wrote: Vinod, On Wednesday 19 March 2014 11:25 AM, Sekhar Nori wrote: The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: sta...@vger.kernel.org # v3.12.x+ Cc: Joel Fernandes jo...@ti.com Acked-by: Joel Fernandes jo...@ti.com Tested-by: Jon Ringle jrin...@gridpoint.com Tested-by: Alexander Holler hol...@ahsoftware.de Reported-by: Jon Ringle jrin...@gridpoint.com Signed-off-by: Sekhar Nori nsek...@ti.com Looks like this patch is not in mainline still? Sorry looks like I have missed sending the email. I had applied it last week and today rebased after rc1. It would be part of rc2... Thank you! Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Monday 14 April 2014 05:26 PM, Peter Ujfalusi wrote:
Hi Vinod,
On 04/11/2014 03:46 PM, Vinod Koul wrote:
I think the number shouldn't be viewed in absolute terms. If we decide that
(lets
say) 0-7, then any controller should map 0 to lowest and 7 to highest.
For your case you can do this and then intermediate numbers would be medium
priority. Such a system might work well...
Also how would a client driver know which priority to use? Would it come from
DT?
I think DT would be the best place.
In the strict sense of what DT is supposed to represent, DT is not the
best place for this. Priority is usecase driven rather that hardware
description driven. So on a reasonably less loaded system, I am sure you
could run audio even with a lower priority DMA queue.
Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
wide variety of example use cases, I think it is too early to commit to
an ABI.
Not sure if we should set the range for this either. What I was thinking is to
add an optional new property to be set by the client nodes, using DMA:
mcasp0: mcasp@48038000 {
compatible = ti,am33xx-mcasp-audio;
...
dmas = edma 8,
edma 9;
dma-names = tx, rx;
dma-priorities = 2, 2;
};
We could agree that lower number means lower priority, higher is - well -
higher priority.
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is three
level. For designware controller you might have the range 0-8 as valid.
The question is how to get this information into use?
We can take the priority number in the core when the dma channel is requested
and add field to struct dma_chan in order to store it and the DMA drivers
could have access to it.
In this way we only need to update the nodes which needs non default priority
for DMA.
What do you think?
If we are using dma_slave_config, I think it will be easiest to define
two levels of priority (HIGH and LOW, as thats all we see a need for
right now), and have the audio driver select the HIGH priority. If
nothing is set, EDMA can default to LOW.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Monday 14 April 2014 06:11 PM, Peter Ujfalusi wrote:
On 04/14/2014 03:12 PM, Sekhar Nori wrote:
On Monday 14 April 2014 05:26 PM, Peter Ujfalusi wrote:
Hi Vinod,
On 04/11/2014 03:46 PM, Vinod Koul wrote:
I think the number shouldn't be viewed in absolute terms. If we decide
that (lets
say) 0-7, then any controller should map 0 to lowest and 7 to highest.
For your case you can do this and then intermediate numbers would be medium
priority. Such a system might work well...
Also how would a client driver know which priority to use? Would it come
from
DT?
I think DT would be the best place.
In the strict sense of what DT is supposed to represent, DT is not the
best place for this. Priority is usecase driven rather that hardware
description driven.
While this is true, the DMA priority - if supported by the DMA engine - is a
HW feature as well. If it is supported by the HW it can be used to tune and
partition the system for the anticipated load or purpose.
So on a reasonably less loaded system, I am sure you
could run audio even with a lower priority DMA queue.
Yes, you can. But as soon as you have other devices using the same priority
(with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
During audio playback/capture you execute a long MMC read for example can
introduce a glitch.
Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
wide variety of example use cases, I think it is too early to commit to
an ABI.
True, but we need to start from somewhere?
Right, and based on our IRC discussion, we are not really fixing up the
priority value space. That makes me much more comfortable with the idea.
Not sure if we should set the range for this either. What I was thinking is
to
add an optional new property to be set by the client nodes, using DMA:
mcasp0: mcasp@48038000 {
compatible = ti,am33xx-mcasp-audio;
...
dmas = edma 8,
edma 9;
dma-names = tx, rx;
dma-priorities = 2, 2;
};
We could agree that lower number means lower priority, higher is - well -
higher priority.
Even this does not have to be uniform across, right? The numbers could
be left to interpretation per-SoC.
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is
three
level. For designware controller you might have the range 0-8 as valid.
The question is how to get this information into use?
We can take the priority number in the core when the dma channel is
requested
and add field to struct dma_chan in order to store it and the DMA drivers
could have access to it.
How about Vinod's idea of extending dma_slave_config? Priority is
similar to rest of the runtime setup dmaengine_slave_config() is meant
to do.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Sekhar Nori nsek...@ti.com --- arch/arm/common/edma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 86a8b263278f..19520e2519d9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, pdata-queue_priority_mapping = queue_priority_map; - pdata-default_queue = 0; + /* select queue 1 as default */ It will be nice to expand the comment with explanation of why this is being chosen as default (lower priority queue by default for typical bulk data transfer). Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote: On 04/11/2014 11:17 AM, Sekhar Nori wrote: On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Sekhar Nori nsek...@ti.com --- arch/arm/common/edma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 86a8b263278f..19520e2519d9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, pdata-queue_priority_mapping = queue_priority_map; - pdata-default_queue = 0; + /* select queue 1 as default */ It will be nice to expand the comment with explanation of why this is being chosen as default (lower priority queue by default for typical bulk data transfer). Yes, extended comment is a good idea. For the next version I think I'm going to change the code around default TC/Queue and the non default queue selection, mostly based on Joel's comment: EVENTQ_1 as default queue. Set the EVENTQ_1 priority to 7 EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2 Add new member to struct edma, like high_pri_queue. When we set the queue priorities in edma_probe() we look for the highest priority queue and save the number in high_pri_queue. I will rename the edma_request_non_default_queue() to edma_request_high_pri_queue() and it will assign the channel to the high priority queue. I think this way it is going to be more explicit and IMHO a bit more safer in a sense the we are going to get high priority when we ask for it. Sounds much better. I had posted some ideas about adding support for channel priority in the core code but we can leave that for Vinod and Dan to say if they really see a need for that. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
On Friday 11 April 2014 03:12 PM, Vinod Koul wrote: On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote: On 04/11/2014 11:56 AM, Sekhar Nori wrote: On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote: On 04/11/2014 11:17 AM, Sekhar Nori wrote: On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote: Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Acked-by: Sekhar Nori nsek...@ti.com --- arch/arm/common/edma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 86a8b263278f..19520e2519d9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, pdata-queue_priority_mapping = queue_priority_map; -pdata-default_queue = 0; +/* select queue 1 as default */ It will be nice to expand the comment with explanation of why this is being chosen as default (lower priority queue by default for typical bulk data transfer). Yes, extended comment is a good idea. For the next version I think I'm going to change the code around default TC/Queue and the non default queue selection, mostly based on Joel's comment: EVENTQ_1 as default queue. Set the EVENTQ_1 priority to 7 EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2 Add new member to struct edma, like high_pri_queue. When we set the queue priorities in edma_probe() we look for the highest priority queue and save the number in high_pri_queue. I will rename the edma_request_non_default_queue() to edma_request_high_pri_queue() and it will assign the channel to the high priority queue. I think this way it is going to be more explicit and IMHO a bit more safer in a sense the we are going to get high priority when we ask for it. Sounds much better. I had posted some ideas about adding support for channel priority in the core code but we can leave that for Vinod and Dan to say if they really see a need for that. Is it part of this series? No, the current series has an EDMA specific way of managing priority. If we do it via the dmaengine core I think it would be better to have a new flag to be passed to dmaengine_prep_dma_*(). We could have for example: DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is possible. We can watch for this flag in the edma driver and act accordingly. ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally since audio should be treated in this way if the DMA IP can do this. Will the priority be different for each descriptor or would be based on channel usage. If not then we can add this in dma_slave_config ? The priority will be per-channel not per-transaction (at least for the use case we are talking about here). Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Building head of git repo gives kernel which segfaults loading init
On Friday 04 April 2014 06:35 AM, Peter Howard wrote: Problem tracked down - see at bottom. On Fri, 2014-04-04 at 10:21 +1100, Peter Howard wrote: On Fri, 2014-04-04 at 09:57 +1100, Peter Howard wrote: Dear All: I'm trying to build a kernel from the current head of the git repository for an OMAP-L138 board. This boots fine with a kernel built from the last Ti release*. However when I substitute in a kernel built from the repo, the kernel gets a SIGSEGV when it tries to start init (given you see nothing from init itself I'm guessing the segfault occurs during the loading of init). I'm building using da8xx_omapl_defconfig and the arago 2011.09 toolchain. Minor extra details: That defconfig doesn't enable MMC/SD support; I enabled it. No other changes. I also got the same behavior using da850_omapl138_defconfig from the last Ti release. I discovered the problem is not specific to the Ti git repo. So I went bisecting and ended up at this commit: [c2dde5f8f2095d7c623ff3565c1462e190272273] dmaengine: add TI EDMA DMA engine driver da8xx_omapl_defconfig does not enable the DMA driver by default. Once I enabled it, the problem went away. I'd say this is a bug. Either: A. You should be able to use the MMC/SD slot without enabling the DMA driver, or B. You shouldn't be able to create a configuration for the DaVinci where MMC/SD is enabled and the DMA driver isn't. So, which should it be? 'A' is the preferred solution. This problem however should be fixed in latest linux-next where da8xx_omapl_defconfig is removed and davinci_all_defconfig enables CONFIG_TI_EDMA Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 3/3] ata: add new-style AHCI platform driver for DaVinci DA850 AHCI controller
On Thursday 20 March 2014 11:57 PM, Bartlomiej Zolnierkiewicz wrote:
Add the new ahci_da850 host driver and remove the deprecated
ahci_platform_data platform code.
Please note that the new driver doesn't have the superfluous
clock control code as clock is already handled by the generic
AHCI platform library code.
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Hans de Goede hdego...@redhat.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Looks much better now and re-tested it on DA850 EVM. Few issues
pointed out below.
---
v2:
- dropped the experimental tag from the config option help
- fixed SYSCFG1 memory resource handling
- hardcoded the multiplier data and added a note about it
- used readl()/writel() instead of __raw_readl()/__raw_writel()
- dropped the superflous clock control
- cleaned up da850_sata_init()
- changed the platform device name and removed the platform ids table
- removed the deprecated ahci_platform_data platform code
- updated the patch description
arch/arm/mach-davinci/devices-da8xx.c | 99 +++--
drivers/ata/Kconfig | 9 +++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_da850.c | 116
++
4 files changed, 134 insertions(+), 91 deletions(-)
I prefer not to mix platform and driver together in one patch. If you
separate out the platform changes, I can take then through my tree with
out risk of conflicts. The platform changes can come after the driver
is introduced so there is no breakage.
create mode 100644 drivers/ata/ahci_da850.c
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0486cdf2..72bb8d6 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -1020,7 +1020,6 @@ int __init da8xx_register_spi_bus(int instance,
unsigned num_chipselect)
}
#ifdef CONFIG_ARCH_DAVINCI_DA850
-
static struct resource da850_sata_resources[] = {
{
.start = DA850_SATA_BASE,
@@ -1028,103 +1027,22 @@ static struct resource da850_sata_resources[] = {
.flags = IORESOURCE_MEM,
},
{
+ .start = DA8XX_SYSCFG1_BASE,
+ .end= DA8XX_SYSCFG1_BASE + SZ_4K - 1,
+ .flags = IORESOURCE_MEM,
This is not correct. The entire SYSCFG is not owned by SATA driver.
Its just that one PWRDN register. Here is a patch which applies on
top of your patch patch fixing it. Feel free to roll it in.
---8---
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 72bb8d6..56ea41d 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -1027,8 +1027,8 @@ static struct resource da850_sata_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = DA8XX_SYSCFG1_BASE,
- .end= DA8XX_SYSCFG1_BASE + SZ_4K - 1,
+ .start = DA8XX_SYSCFG1_BASE + DA8XX_PWRDN_REG,
+ .end= DA8XX_SYSCFG1_BASE + DA8XX_PWRDN_REG + 0x3,
.flags = IORESOURCE_MEM,
},
{
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
index 899270a..2c83613 100644
--- a/drivers/ata/ahci_da850.c
+++ b/drivers/ata/ahci_da850.c
@@ -16,8 +16,6 @@
#include linux/ahci_platform.h
#include ahci.h
-#define DA8XX_PWRDN_REG0x18
-
/* SATA PHY Control Register offset from AHCI base */
#define SATA_P0PHYCR_REG 0x178
@@ -37,15 +35,15 @@
*/
#define DA850_SATA_CLK_MULTIPLIER 7
-static void da850_sata_init(struct device *dev, void __iomem *syscfg1_base,
+static void da850_sata_init(struct device *dev, void __iomem *pwrdn_reg,
void __iomem *ahci_base)
{
unsigned int val;
/* Enable SATA clock receiver */
- val = readl(syscfg1_base + DA8XX_PWRDN_REG);
+ val = readl(pwrdn_reg);
val = ~BIT(0);
- writel(val, syscfg1_base + DA8XX_PWRDN_REG);
+ writel(val, pwrdn_reg);
val = SATA_PHY_MPY(DA850_SATA_CLK_MULTIPLIER + 1) | SATA_PHY_LOS(1) |
SATA_PHY_RXCDR(4) | SATA_PHY_RXEQ(1) | SATA_PHY_TXSWING(3) |
@@ -66,7 +64,7 @@ static int ahci_da850_probe(struct platform_device *pdev)
struct device *dev = pdev-dev;
struct ahci_host_priv *hpriv;
struct resource *res;
- void __iomem *syscfg1_base;
+ void __iomem *pwrdn_reg;
int rc;
hpriv = ahci_platform_get_resources(pdev);
@@ -81,11 +79,11 @@ static int ahci_da850_probe(struct platform_device *pdev)
if (!res)
goto disable_resources;
- syscfg1_base = devm_ioremap(dev, res-start, resource_size(res));
- if (!syscfg1_base)
+ pwrdn_reg = devm_ioremap(dev, res-start, resource_size(res));
+ if (!pwrdn_reg
Re: [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
On Friday 21 March 2014 09:26 PM, Arnd Bergmann wrote: From 5eaf7fdfe7c831d3aa24428a6e8d4509ac160db6 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann a...@arndb.de Date: Tue, 18 Feb 2014 12:23:19 +0100 Subject: [PATCH] ARM: davinci: use explicit 'select' for DA850_EVM The DAVINCI_DA850_EVM board uses an unusual method to enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols, which leads to the dependencies on these symbols being ignored. As GPIO_PCA953X actually requires I2C, that can lead to build failures when I2C is disabled. This patch removes the duplicate symbol definitions and instead enables them from the davinci_all_defconfig file. A different question whether we actually want to automatically enable them at all or rather put them into defconfig, but that should be a separate patch. This para can be dropped now. Signed-off-by: Arnd Bergmann a...@arndb.de Acked-by: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: davinci-linux-open-source@linux.davincidsp.com Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 3/4] ata: add new-style AHCI platform driver for DaVinci DA850 AHCI controller
Hi Bartlomiej,
On Tuesday 18 March 2014 12:01 AM, Bartlomiej Zolnierkiewicz wrote:
The new driver is named ahci_da850 and is only compile tested. Once it
is tested on the real hardware and verified to work correctly, the legacy
platform code (which depends on the deprecated struct ahci_platform_data)
can be removed.
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Thanks for the patch. I have been able to use your patch and verify SATA
functionality on DA850 EVM. I have some comments though.
---
drivers/ata/Kconfig | 9 +++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_da850.c | 178
+++
3 files changed, 188 insertions(+)
create mode 100644 drivers/ata/ahci_da850.c
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 371e8890..6379a00 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -97,6 +97,15 @@ config SATA_AHCI_PLATFORM
If unsure, say N.
+config AHCI_DA850
+ tristate DaVinci DA850 AHCI SATA support (experimental)
+ depends on ARCH_DAVINCI_DA850
+ help
+ This option enables support for the DaVinci DA850 SoC's
+ onboard AHCI SATA.
+
+ If unsure, say N.
+
config AHCI_ST
tristate ST AHCI SATA support
depends on ARCH_STI
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6123e64..0646d83 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_SATA_INIC162X) += sata_inic162x.o
obj-$(CONFIG_SATA_SIL24) += sata_sil24.o
obj-$(CONFIG_SATA_DWC) += sata_dwc_460ex.o
obj-$(CONFIG_SATA_HIGHBANK) += sata_highbank.o libahci.o
+obj-$(CONFIG_AHCI_DA850) += ahci_da850.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_IMX) += ahci_imx.o libahci.o
libahci_platform.o
obj-$(CONFIG_AHCI_SUNXI) += ahci_sunxi.o libahci.o libahci_platform.o
obj-$(CONFIG_AHCI_ST)+= ahci_st.o libahci.o
libahci_platform.o
diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
new file mode 100644
index 000..da874699
--- /dev/null
+++ b/drivers/ata/ahci_da850.c
@@ -0,0 +1,178 @@
+/*
+ * DaVinci DA850 AHCI SATA platform driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2, or (at your option)
+ * any later version.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pm.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/libata.h
+#include linux/ahci_platform.h
+#include ahci.h
+
+extern void __iomem *da8xx_syscfg1_base;
This platform specific extern symbol should not be used in drivers and
in fact checkpatch complains about it too. Can you instead get the
addresses you need as part of the device resources?
+#define DA8XX_SYSCFG1_VIRT(x)(da8xx_syscfg1_base + (x))
+#define DA8XX_PWRDN_REG 0x18
+
+/* SATA PHY Control Register offset from AHCI base */
+#define SATA_P0PHYCR_REG 0x178
+
+#define SATA_PHY_MPY(x) ((x) 0)
+#define SATA_PHY_LOS(x) ((x) 6)
+#define SATA_PHY_RXCDR(x)((x) 10)
+#define SATA_PHY_RXEQ(x) ((x) 13)
+#define SATA_PHY_TXSWING(x) ((x) 19)
+#define SATA_PHY_ENPLL(x)((x) 31)
These can be replaced with BIT(N)
+
+static struct clk *da850_sata_clk;
+static unsigned long da850_sata_refclkpn = 100 * 1000 * 1000;
This should ideally be platform data. Since we are not going to add
anymore board files, I am not going to ask you to add one.
However, with the input value hard coded in driver, it does not make
sense to have the frequencies table and its traversal. Instead, I
suggest you hard-code the multiplier itself with a porting warning
comment. Later when the DT conversion happens and this becomes a DT
property, we can add back the logic for multiple multiplier settings.
The way it is now, the code looks superfluous.
+
+/* Supported DA850 SATA crystal frequencies */
+#define KHZ_TO_HZ(freq) ((freq) * 1000)
+static unsigned long da850_sata_xtal[] = {
+ KHZ_TO_HZ(30),
+ KHZ_TO_HZ(25),
+ 0, /* Reserved */
+ KHZ_TO_HZ(187500),
+ KHZ_TO_HZ(15),
+ KHZ_TO_HZ(125000),
+ KHZ_TO_HZ(12),
+ KHZ_TO_HZ(10),
+ KHZ_TO_HZ(75000),
+ KHZ_TO_HZ(6),
+};
+
+static int da850_sata_init(struct device *dev, void __iomem *addr)
+{
+ int i, ret;
+ unsigned int val;
+
+ da850_sata_clk = clk_get(dev, NULL);
+ if (IS_ERR(da850_sata_clk))
+ return PTR_ERR(da850_sata_clk);
+
+ ret = clk_prepare_enable(da850_sata_clk);
+ if (ret)
+ goto err0;
Please switch to pm_runtime instead of using the clock APIs directly.
+
+ /* Enable SATA clock receiver */
+ val =
Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
Hi Arnd, On Thursday 20 March 2014 01:51 AM, Arnd Bergmann wrote: On Wednesday 19 March 2014 23:53:18 Sergei Shtylyov wrote: On 03/19/2014 10:29 PM, Arnd Bergmann wrote: The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY. The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the symbol to be exported from platform code. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: davinci-linux-open-source@linux.davincidsp.com --- arch/arm/mach-davinci/devices-da8xx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c index 0486cdf..4da868a 100644 --- a/arch/arm/mach-davinci/devices-da8xx.c +++ b/arch/arm/mach-davinci/devices-da8xx.c @@ -66,6 +66,7 @@ #define DA850_DMA_MMCSD1_TX EDMA_CTLR_CHAN(1, 29) void __iomem *da8xx_syscfg0_base; +EXPORT_SYMBOL_GPL(da8xx_syscfg0_base); /* used by OHCI_HCD */ I have submitted such patch years ago and it was turned down. The question is whether there is anyone who would do this properly. Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2) to control the clock, phy and host/gadget mode switch. In the modern world, we'd probably want to have a clock driver and a phy driver for these, based on a syscon driver. In all honesty I don't see that happening on davinci. A somewhat better approach would be to export a set of exported functions to access the one register from the platform, e.g. u32 da8xx_cfgchip2_get(void); void da8xx_cfgchip2_set(u32); That interface would still be a bit ugly, but much better than what we have today, and easy to implement. There is another thing we can do albeit in the driver (see patch). Not sure how the USB maintainer will feel about it but I think this has the advantage of not creating any hacky interfaces. And it leaves me with the hope that someone will find the time to convert to phy driver based on syscon at some point. Thanks, Sekhar ---8--- diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 3586460..c807d3f 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1178,7 +1178,8 @@ MODULE_LICENSE (GPL); #define SA_DRIVER ohci_hcd_sa_driver #endif -#ifdef CONFIG_ARCH_DAVINCI_DA8XX +/* DA8XX uses platform internal symbols. Cannot be built as module. */ +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) !defined(CONFIG_USB_OHCI_HCD_MODULE) #include ohci-da8xx.c #define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver #endif ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
On Thursday 20 March 2014 12:12 PM, Arnd Bergmann wrote: On Thursday 20 March 2014 01:36:13 Sergei Shtylyov wrote: On 03/19/2014 11:21 PM, Arnd Bergmann wrote: The question is whether there is anyone who would do this properly. Nobody cares, it seems. As you can imagine, I stopped to care enough after being switched to other projects. I only care about it because I have the intention to get all 'randconfig' kernels to build eventually. For stuff that is definitely 'legacy' and won't get cleaned up properly, I'm fine with a hack. Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2) The idea at the time was to just ioremap() this register but I was not very eager. Yes, that would work, too. However, that would cause problems later if we ever try to make the davinci platform multiplatform, unless we also pass the physical address in a platform resource and make this a larger Some SATA driver work done by Bartlomiej Zolnierkiewicz needed driver access to syscfg registers too and I just asked him to pass the physical addresses using platform resource. I think thats the best bet we have in the absence of a modern interface. The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it. CFGCHIP2 has controls both for USB 1.1 (OHCI) and USB 2.0 (MUSB). Not sure if there can be a single PHY driver for both. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci SoC fixes for v3.15
Hello, Here is a fix from Kevin over the soc pull request sent earlier. Thanks, Sekhar The following changes since commit 4b9e44f8d7c9cd166d8304b8f619741c1d59b836: ARM: davinci: remove da8xx_omapl_defconfig (2014-03-06 19:08:30 +0530) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.15/soc-2 for you to fetch changes up to b737f51d423861399079a1f66647e7a416de3318: ARM: davinci: fix DT booting with default defconfig (2014-03-20 15:39:38 +0530) Includes a patch to enable appended DTB support for DT booting on DA850 boards with older bootloaders. Kevin Hilman (1): ARM: davinci: fix DT booting with default defconfig arch/arm/configs/davinci_all_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index fff4eb6..2df72ff 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -40,6 +40,8 @@ CONFIG_LEDS=y CONFIG_USE_OF=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ARM_APPENDED_DTB=y +CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_AUTO_ZRELADDR=y CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y @@ -70,6 +72,7 @@ CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_PHYSMAP=m CONFIG_MTD_NAND=m CONFIG_MTD_NAND_DAVINCI=m +CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base
On Thursday 20 March 2014 05:27 PM, Arnd Bergmann wrote: On Thursday 20 March 2014, Sekhar Nori wrote: diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c index 3586460..c807d3f 100644 --- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -1178,7 +1178,8 @@ MODULE_LICENSE (GPL); #define SA_DRIVER ohci_hcd_sa_driver #endif -#ifdef CONFIG_ARCH_DAVINCI_DA8XX +/* DA8XX uses platform internal symbols. Cannot be built as module. */ +#if defined(CONFIG_ARCH_DAVINCI_DA8XX) !defined(CONFIG_USB_OHCI_HCD_MODULE) #include ohci-da8xx.c #define DAVINCI_PLATFORM_DRIVERohci_hcd_da8xx_driver #endif I wouldn't want to submit that patch to GregKH ;-) How about doing the same thing in a somewhat less sneaky way? Signed-off-by: Arnd Bergmann a...@arndb.de Much better! Please feel free to add Acked-by: Sekhar Nori nsek...@ti.com if it helps. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 07/62] ARM: davinci: make dm644x-evm phy fixup conditional
On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote: We cannot call phy_register_fixup_for_uid() if CONFIG_PHYLIB is not built into the kernel, and we should not enforce that to be built into vmlinux either, because one might want to disable the entire network stack. This change uses a compile-time condition on CONFIG_PHYLIB to remove the call in the cases where it cannot work. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: davinci-linux-open-source@linux.davincidsp.com Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 08/62] ARM: davinci: use explicit 'select' for DA850_EVM
On Thursday 20 March 2014 12:59 AM, Arnd Bergmann wrote: The DAVINCI_DA850_EVM board uses an unusual method to enable the GPIO_PCA953X and KEYBOARD_GPIO_POLLED symbols, which leads to the dependencies on these symbols being ignored. As GPIO_PCA953X actually requires I2C, that can lead to build failures when I2C is disabled. This patch removes the duplicate symbol definitions I am okay with this.. and instead adds equivalent 'select' statements that are conditional on the underlying dependencies. .. but not sure this is needed. The PCA953X was defaulted to y mainly because the IO expander was used to detect presence of daughter cards. Even then, I don't think there is any need to force its selection. A different question whether we actually want to automatically enable them at all or rather put them into defconfig, but that should be a separate patch. It can be enabled through defconfig as you said. I agree that can be a separate patch. For now, just dropping the replicated Kconfig symbols should be okay. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
On Monday 17 March 2014 07:35 PM, Linus Walleij wrote: On Mon, Mar 17, 2014 at 2:29 PM, Sekhar Nori nsek...@ti.com wrote: One thing to note is that this driver is used by keystone too and all its users are DT-only. Although I do not see any in-kernel DT GPIO users even there. I can confirm the patch does not break my gpiolib based test module (test with and without DT), but then it did not have an issue even before. Is that a Tested-by tag? :-) Yes. Tested-by: Sekhar Nori nsek...@ti.com If you're also convinced that fix is safe I'll push it as a fix to v3.14-rcN if for nothing else so for getting Mr. Holler to stop poking me in the chest. It is safe - at the least it does not break anything that is already working. I guess the decision to put it into -rc depends on whether you consider out of tree dtbs to be a valid usecase for the kernel. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] gpio: davinci: fix gpio selection for OF
Hi Alexander, On Tuesday 18 March 2014 03:15 PM, Alexander Holler wrote: Am 18.03.2014 09:37, schrieb Sekhar Nori: It is safe - at the least it does not break anything that is already working. I guess the decision to put it into -rc depends on whether you consider out of tree dtbs to be a valid usecase for the kernel. That's all DT is about, getting rid of the necessity for in-tree hw-descriptions. ;) But I don't need any rush here, I'm just unable to understand why the -rc phase isn't used for bug fixing as I believe that's what this phase is for. The push back you are seeing is because this is pretty late in -rc cycle. If this push back was not there the bug fix cycle would probably never close. In all probability, if this was -rc2 or even -rc3 there would not be so much discussion. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] dma: edma: fix incorrect SG list handling
The code to handle any length SG lists calls edma_resume()
even before edma_start() is called. This is incorrect
because edma_resume() enables edma events on the channel
after which CPU (in edma_start) cannot clear posted
events by writing to ECR (per the EDMA user's guide).
Because of this EDMA transfers fail to start if due
to some reason there is a pending EDMA event registered
even before EDMA transfers are started. This can happen if
an EDMA event is a byproduct of device initialization.
Fix this by calling edma_resume() only if it is not the
first batch of MAX_NR_SG elements.
Without this patch, MMC/SD fails to function on DA850 EVM
with DMA. The behaviour is triggered by specific IP and
this can explain why the issue was not reported before
(example with MMC/SD on AM335x).
Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card.
Cc: sta...@vger.kernel.org # v3.12.x+
Cc: Joel Fernandes jo...@ti.com
Reported-by: Jon Ringle jrin...@gridpoint.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Jon, can you please confirm this fixes the issue you
reported?
Joel, can you ack this please? In particular, I was
not able to test with SG list greater than MAX_NR_SG.
drivers/dma/edma.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cd8da45..bf5ad0f 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -182,11 +182,13 @@ static void edma_execute(struct edma_chan *echan)
echan-ecc-dummy_slot);
}
- edma_resume(echan-ch_num);
-
if (edesc-processed = MAX_NR_SG) {
dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
edma_start(echan-ch_num);
+ } else {
+ dev_dbg(dev, chan: %d: completed %d elements, resuming\n,
+ echan-ch_num, edesc-processed);
+ edma_resume(echan-ch_num);
}
/*
--
1.7.10.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] dma: edma: fix incorrect SG list handling
Hi Jon, On Monday 17 March 2014 06:28 PM, Jon Ringle wrote: On Mon, 17 Mar 2014, Sekhar Nori wrote: The code to handle any length SG lists calls edma_resume() even before edma_start() is called. This is incorrect because edma_resume() enables edma events on the channel after which CPU (in edma_start) cannot clear posted events by writing to ECR (per the EDMA user's guide). Because of this EDMA transfers fail to start if due to some reason there is a pending EDMA event registered even before EDMA transfers are started. This can happen if an EDMA event is a byproduct of device initialization. Fix this by calling edma_resume() only if it is not the first batch of MAX_NR_SG elements. Without this patch, MMC/SD fails to function on DA850 EVM with DMA. The behaviour is triggered by specific IP and this can explain why the issue was not reported before (example with MMC/SD on AM335x). Tested on DA850 EVM and AM335x EVM-SK using MMC/SD card. Cc: sta...@vger.kernel.org # v3.12.x+ Cc: Joel Fernandes jo...@ti.com Reported-by: Jon Ringle jrin...@gridpoint.com Signed-off-by: Sekhar Nori nsek...@ti.com --- Jon, can you please confirm this fixes the issue you reported? The patch does not apply on linux-3.12 due to changes to the 3 context lines at the start of the hunk. But, I manually fixed up the code and it does fix the issue on our AM1808 board. Thanks for the testing. The patch is meant for latest mainline but based on what you said, a manual backport to v3.12-stable will be required. Can you please reply with a formal Tested-by: ? Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: fix DT booting with default defconfig
On Tuesday 18 March 2014 03:01 AM, Kevin Hilman wrote: On Sun, Mar 16, 2014 at 10:00 PM, Sekhar Nori nsek...@ti.com wrote: On Friday 14 March 2014 11:00 PM, Kevin Hilman wrote: Davinci boards tend to have older booloaders without DTB support. Enable appended DTB support by default to allow DT booting on older platforms. While there, also enable /proc/device-tree support for easy verification of DT boot. Signed-off-by: Kevin Hilman khil...@linaro.org --- Sekhar, this applies on top of your latest defconfig cleanup queued for v3.15 and validated with DT and legacy boot on DA850 EVM. Thanks Kevin. If you will take this directly through ARM-SoC: Acked-by: Sekhar Nori nsek...@ti.com I'd prefer if you just take it along with your changes. Maybe as a fix for v3.15-rc since it fixes some booting issues with legacy booting on top of your defconfig cleanup. Okay sure. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: fix DT booting with default defconfig
On Friday 14 March 2014 11:00 PM, Kevin Hilman wrote: Davinci boards tend to have older booloaders without DTB support. Enable appended DTB support by default to allow DT booting on older platforms. While there, also enable /proc/device-tree support for easy verification of DT boot. Signed-off-by: Kevin Hilman khil...@linaro.org --- Sekhar, this applies on top of your latest defconfig cleanup queued for v3.15 and validated with DT and legacy boot on DA850 EVM. Thanks Kevin. If you will take this directly through ARM-SoC: Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci SoC updates for v3.15
The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.15/soc for you to fetch changes up to 4b9e44f8d7c9cd166d8304b8f619741c1d59b836: ARM: davinci: remove da8xx_omapl_defconfig (2014-03-06 19:08:30 +0530) This pull request removes da8xx_omapl_defconfig enabling all ARMv5 davinci devices to be built using davinci_all_defconfig Sekhar Nori (4): ARM: davinci: enable da8xx build concurrently with older devices ARM: davinci: add da8xx specific configs to davinci_all_defconfig ARM: davinci: da8xx: fix multiple watchdog device registration ARM: davinci: remove da8xx_omapl_defconfig arch/arm/configs/da8xx_omapl_defconfig | 139 arch/arm/configs/davinci_all_defconfig | 20 + arch/arm/mach-davinci/Makefile.boot| 20 ++--- arch/arm/mach-davinci/davinci.h|2 + arch/arm/mach-davinci/devices.c| 17 +--- arch/arm/mach-davinci/dm355.c |8 +- arch/arm/mach-davinci/dm365.c |8 +- arch/arm/mach-davinci/dm644x.c |8 +- arch/arm/mach-davinci/dm646x.c |8 +- 9 files changed, 59 insertions(+), 171 deletions(-) delete mode 100644 arch/arm/configs/da8xx_omapl_defconfig ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Davinci gpio devicetree
On Monday 03 March 2014 03:53 PM, Prabhakar Lad wrote:
Hi Alexander,
On Sat, Mar 1, 2014 at 6:58 PM, Alexander Holler hol...@ahsoftware.de wrote:
Hello,
Having had a second look at your example (comparing with what I've used
here), I think it might make sense to change it a bit:
Am 01.03.2014 14:10, schrieb Alexander Holler:
Am 28.02.2014 14:51, schrieb Prabhakar Lad:
+leds {
pinctrl-names = default;
pinctrl-0 = led_pins;
I think this can be dropped or else one might also feel led_pins are missing.
+compatible = gpio-leds;
+led1 {
+label = davinci:green:usr1;
+gpios = gpio0 10 GPIO_ACTIVE_HIGH;
linux,default-trigger = heartbeat;
+};
+
+led2 {
+label = davinci:red:debug1;
+gpios = gpio0 11 GPIO_ACTIVE_HIGH;
+};
+};
or just add ... to denote that there should/might be some additional stuff
which doesn't really belong to the description of the gpio-binding (like
pinctrl).
I would prefer ... instead
Sekhar If you are OK with the above changes I'll post a updated patch to DT
list
aswell let me know your comments on this.
Yes, please post a formal patch.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Davinci gpio devicetree
+ Prabhakar On Tuesday 25 February 2014 08:54 PM, Alexander Holler wrote: Hello, I've seen kernel 3.14-rc contains support for gpios using devicetree. I've two comments: 1. #gpio-cells seems to be missing, 2. a small usage example (e.g. with gpio-leds or gpio-keys) would be nice. Regards, Alexander Holler ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/5] ARM: davinci: tnetv107x removal
(fixed Cyril's e-mail address) On Wednesday 26 February 2014 06:13 PM, Arnd Bergmann wrote: This series removes the TI davinci/tnetv107x platform that has evidently bitrotted to the point where it's completely useless. While we could probably fix it and add a defconfig, it appears that there are actually no users of this platform, and it complicates the davinci code base because it's incompatible with all the other SoCs in there that are based on ARM926T. The five patches are completely independent of one another, and applying them out of order is fine since we just want to remove the code. However, I'm looking for an Ack from Cyril Chemparathy and Sekhar Nori first, to be sure we won't need this code in the future. Kevin Hilman has already mentioned that he sees no reason to keep this code. Acked-by: Sekhar Nori nsek...@ti.com Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/4] ARM: davinci: remove da8xx_omapl_defconfig
This patch series enabled da830 and da850 to build with davinci_all_defconfig and removes da8xx_omapl_defconfig since it will not be required anymore. Sekhar Nori (4): ARM: davinci: enable da8xx build concurrently with older devices ARM: davinci: add da8xx specific configs to davinci_all_defconfig ARM: davinci: da8xx: fix multiple watchdog device registration ARM: davinci: remove da8xx_omapl_defconfig arch/arm/configs/da8xx_omapl_defconfig | 139 arch/arm/configs/davinci_all_defconfig | 20 + arch/arm/mach-davinci/Makefile.boot| 20 ++--- arch/arm/mach-davinci/davinci.h|2 + arch/arm/mach-davinci/devices.c| 17 +--- arch/arm/mach-davinci/dm355.c |8 +- arch/arm/mach-davinci/dm365.c |8 +- arch/arm/mach-davinci/dm644x.c |8 +- arch/arm/mach-davinci/dm646x.c |8 +- 9 files changed, 59 insertions(+), 171 deletions(-) delete mode 100644 arch/arm/configs/da8xx_omapl_defconfig -- 1.7.10.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/4] ARM: davinci: add da8xx specific configs to davinci_all_defconfig
Add da8xx specific configs to davinci_all_defconfig so it can be used to support da830 and da850. Signed-off-by: Sekhar Nori nsek...@ti.com --- arch/arm/configs/davinci_all_defconfig | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index 8a8379a..fff4eb6 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -20,9 +20,14 @@ CONFIG_ARCH_DAVINCI_DM644x=y CONFIG_ARCH_DAVINCI_DM355=y CONFIG_ARCH_DAVINCI_DM646x=y CONFIG_ARCH_DAVINCI_DM365=y +CONFIG_ARCH_DAVINCI_DA830=y +CONFIG_ARCH_DAVINCI_DA850=y +CONFIG_MACH_DA8XX_DT=y CONFIG_MACH_SFFSDR=y CONFIG_MACH_NEUROS_OSD2=y CONFIG_MACH_DM355_LEOPARD=y +CONFIG_MACH_MITYOMAPL138=y +CONFIG_MACH_OMAPL138_HAWKBOARD=y CONFIG_DAVINCI_MUX_DEBUG=y CONFIG_DAVINCI_MUX_WARNINGS=y CONFIG_DAVINCI_RESET_CLOCKS=y @@ -32,9 +37,16 @@ CONFIG_PREEMPT=y CONFIG_AEABI=y # CONFIG_OABI_COMPAT is not set CONFIG_LEDS=y +CONFIG_USE_OF=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_AUTO_ZRELADDR=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y +CONFIG_CPU_FREQ_GOV_PERFORMANCE=m +CONFIG_CPU_FREQ_GOV_POWERSAVE=m +CONFIG_CPU_FREQ_GOV_ONDEMAND=m +CONFIG_CPU_IDLE=y CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=y @@ -72,6 +84,7 @@ CONFIG_TUN=m CONFIG_LXT_PHY=y CONFIG_LSI_ET1011C_PHY=y CONFIG_NET_ETHERNET=y +CONFIG_MII=y CONFIG_TI_DAVINCI_EMAC=y CONFIG_DM9000=y # CONFIG_NETDEV_1000 is not set @@ -98,15 +111,21 @@ CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_NR_UARTS=3 # CONFIG_HW_RANDOM is not set +CONFIG_SERIAL_OF_PLATFORM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_DAVINCI=y +CONFIG_PINCTRL_SINGLE=y CONFIG_GPIO_PCF857X=y CONFIG_WATCHDOG=y CONFIG_DAVINCI_WATCHDOG=m CONFIG_MFD_DM355EVM_MSP=y +CONFIG_TPS6507X=y CONFIG_VIDEO_OUTPUT_CONTROL=m +CONFIG_REGULATOR=y +CONFIG_REGULATOR_TPS6507X=y CONFIG_FB=y +CONFIG_FB_DA8XX=y CONFIG_FIRMWARE_EDID=y # CONFIG_VGA_CONSOLE is not set CONFIG_FRAMEBUFFER_CONSOLE=y -- 1.7.10.1 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci NAND update for v3.15
Hi, Can you please pull the following change for v3.15? The mtd changes are acked by Brian. We agreed to take this through ARM-SoC because of the number of changes to mach-davinci. I based this on -rc3 since I saw that ARM-SoC is on -rc3 anyway. Thanks, Sekhar The following changes since commit 6d0abeca3242a88cab8232e4acd7e2bf088f3bc2: Linux 3.14-rc3 (2014-02-16 13:30:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.15/nand for you to fetch changes up to 67f5185cad24b3c3d9ab07508dfcab55cdab02de: ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif (2014-02-23 20:33:18 +0530) A patch to break dependency of DaVinci NAND driver with mach-davinci. Required for reuse of driver on other platforms (keystone). Ivan Khoronzhuk (1): ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif arch/arm/mach-davinci/aemif.c | 107 --- arch/arm/mach-davinci/board-da830-evm.c |3 + arch/arm/mach-davinci/board-da850-evm.c |3 + arch/arm/mach-davinci/board-dm644x-evm.c|5 ++ arch/arm/mach-davinci/board-dm646x-evm.c|3 + arch/arm/mach-davinci/board-mityomapl138.c |4 + drivers/mtd/nand/davinci_nand.c | 22 - include/linux/platform_data/mtd-davinci-aemif.h |5 +- 8 files changed, 117 insertions(+), 35 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4] gpio: davinci: reuse for keystone soc
Hi Linus, On Thursday 06 February 2014 06:50 PM, Linus Walleij wrote: On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko grygorii.stras...@ti.com wrote: The similar GPIO HW block is used by keystone SoCs as in Davinci SoCs. Hence, reuse Davinci GPIO driver for Keystone taking into account that Keystone contains ARM GIC IRQ controller which is implemented using IRQ Chip. Documentation: http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Linus Walleij linus.wall...@linaro.org Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- Changes in v4: - rebased on top of v3.14 + [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup() Are you taking this through ARM SoC or is this something I should be merging? Can you please merge this through your tree as there aren't any dependencies with mach-davinci anymore. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v5] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
Hi Brian, On Thursday 30 January 2014 04:33 PM, Ivan Khoronzhuk wrote: The problem that the set timings code contains the call of Davinci platform function davinci_aemif_setup_timing() which is not accessible if kernel is built for another platform like Keystone. The Keysone platform is going to use TI AEMIF driver. If TI AEMIF is used we don't need to set timings and bus width. It is done by AEMIF driver. To get rid of davinci-nand driver dependency on aemif platform code we moved aemif code to davinci platform. The platform AEMIF code (aemif.c) has to be removed once Davinci will be converted to DT and use ti-aemif.c driver. Acked-by: Brian Norris computersforpe...@gmail.com Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com [nsek...@ti.com: fixed checkpatch error and a build breakage due to missing include, rebased onto l2-mtd/master] Signed-off-by: Sekhar Nori nsek...@ti.com Hope this patch looks good to you now. I would like to take it for v3.15 via DaVinci tree. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote: Hi Sekhar, Do you want me to correct it? Yes, please! Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Ivan Khoronzhuk ivan.khoronz...@ti.com
The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.
The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set timings and bus width.
It is done by AEMIF driver.
To get rid of davinci-nand driver dependency on aemif platform code
we moved aemif code to davinci platform.
The platform AEMIF code (aemif.c) has to be removed once Davinci
will be converted to DT and use ti-aemif.c driver.
Acked-by: Brian Norris computersforpe...@gmail.com
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
[nsek...@ti.com: fixed checkpatch error and a build breakage due to
missing include, rebased onto l2-mtd/master]
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Applies to latest of l2-mtd/master
arch/arm/mach-davinci/aemif.c | 106 ---
arch/arm/mach-davinci/board-da830-evm.c |3 +
arch/arm/mach-davinci/board-da850-evm.c |3 +
arch/arm/mach-davinci/board-dm644x-evm.c|5 ++
arch/arm/mach-davinci/board-dm646x-evm.c|3 +
arch/arm/mach-davinci/board-mityomapl138.c |4 +
drivers/mtd/nand/davinci_nand.c | 22 -
include/linux/platform_data/mtd-davinci-aemif.h |5 +-
8 files changed, 116 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
index f091a90..c805e83 100644
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -16,6 +16,7 @@
#include linux/time.h
#include linux/platform_data/mtd-davinci-aemif.h
+#include linux/platform_data/mtd-davinci.h
/* Timing value configuration */
@@ -43,6 +44,17 @@
WSTROBE(WSTROBE_MAX) | \
WSETUP(WSETUP_MAX))
+static inline unsigned int davinci_aemif_readl(void __iomem *base, int offset)
+{
+ return readl_relaxed(base + offset);
+}
+
+static inline void davinci_aemif_writel(void __iomem *base,
+ int offset, unsigned long value)
+{
+ writel_relaxed(value, base + offset);
+}
+
/*
* aemif_calc_rate - calculate timing data.
* @wanted: The cycle time needed in nanoseconds.
@@ -76,6 +88,7 @@ static int aemif_calc_rate(int wanted, unsigned long clk, int
max)
* @t: timing values to be progammed
* @base: The virtual base address of the AEMIF interface
* @cs: chip-select to program the timing values for
+ * @clkrate: the AEMIF clkrate
*
* This function programs the given timing values (in real clock) into the
* AEMIF registers taking the AEMIF clock into account.
@@ -86,24 +99,17 @@ static int aemif_calc_rate(int wanted, unsigned long clk,
int max)
*
* Returns 0 on success, else negative errno.
*/
-int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
- void __iomem *base, unsigned cs)
+static int davinci_aemif_setup_timing(struct davinci_aemif_timing *t,
+ void __iomem *base, unsigned cs,
+ unsigned long clkrate)
{
unsigned set, val;
int ta, rhold, rstrobe, rsetup, whold, wstrobe, wsetup;
unsigned offset = A1CR_OFFSET + cs * 4;
- struct clk *aemif_clk;
- unsigned long clkrate;
if (!t)
return 0; /* Nothing to do */
- aemif_clk = clk_get(NULL, aemif);
- if (IS_ERR(aemif_clk))
- return PTR_ERR(aemif_clk);
-
- clkrate = clk_get_rate(aemif_clk);
-
clkrate /= 1000;/* turn clock into kHz for ease of use */
ta = aemif_calc_rate(t-ta, clkrate, TA_MAX);
@@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct davinci_aemif_timing
*t,
return 0;
}
-EXPORT_SYMBOL(davinci_aemif_setup_timing);
+
+/**
+ * davinci_aemif_setup - setup AEMIF interface by davinci_nand_pdata
+ * @pdev - link to platform device to setup settings for
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup(struct platform_device *pdev)
+{
+ struct davinci_nand_pdata *pdata = dev_get_platdata(pdev-dev);
+ uint32_t val;
+ unsigned long clkrate;
+ struct resource *res;
+ void __iomem *base;
+ struct clk *clk;
+ int ret = 0;
+
+ clk = clk_get(pdev-dev, aemif);
+ if (IS_ERR(clk)) {
+ ret = PTR_ERR(clk);
+ dev_dbg(pdev-dev, unable to get AEMIF clock, err %d\n, ret);
+ return ret;
+ }
+
+ ret = clk_prepare_enable(clk);
+ if (ret 0) {
+ dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n
[GIT PULL] DaVinci DT updates for v3.14
The following changes since commit 374b105797c3d4f29c685f3be535c35f5689b30e:
Linux 3.13-rc3 (2013-12-06 09:34:04 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
tags/davinci-for-v3.14/dt
for you to fetch changes up to 3a9574f2aa4ffd9b867321a1f298893410bd3718:
ARM: davinci: da850 evm: add GPIO pinumux entries DT node (2013-12-15
18:40:49 +0530)
DaVinci device tree file updates to add GPIO
support.
KV Sujith (2):
ARM: davinci: da850: add GPIO DT node
ARM: davinci: da850 evm: add GPIO pinumux entries DT node
arch/arm/boot/dts/da850-evm.dts |3 +++
arch/arm/boot/dts/da850.dtsi| 14 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 588ce58..1e11e5a 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -101,6 +101,9 @@
pinctrl-names = default;
pinctrl-0 = mii_pins;
};
+ gpio: gpio@1e26000 {
+ status = okay;
+ };
};
nand_cs3@6200 {
status = okay;
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 8d17346..b695548 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -8,6 +8,7 @@
* option) any later version.
*/
#include skeleton.dtsi
+#include dt-bindings/interrupt-controller/irq.h
/ {
arm {
@@ -256,6 +257,19 @@
36
;
};
+ gpio: gpio@1e26000 {
+ compatible = ti,dm6441-gpio;
+ gpio-controller;
+ reg = 0x226000 0x1000;
+ interrupts = 42 IRQ_TYPE_EDGE_BOTH
+ 43 IRQ_TYPE_EDGE_BOTH 44 IRQ_TYPE_EDGE_BOTH
+ 45 IRQ_TYPE_EDGE_BOTH 46 IRQ_TYPE_EDGE_BOTH
+ 47 IRQ_TYPE_EDGE_BOTH 48 IRQ_TYPE_EDGE_BOTH
+ 49 IRQ_TYPE_EDGE_BOTH 50 IRQ_TYPE_EDGE_BOTH;
+ ti,ngpio = 144;
+ ti,davinci-gpio-unbanked = 0;
+ status = disabled;
+ };
};
nand_cs3@6200 {
compatible = ti,davinci-nand;
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] A DaVinci SoC update for v3.14
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
tags/davinci-for-v3.14/soc
for you to fetch changes up to 4408c26bc37fa8ada493ad41a6c7659b76fff483:
ARM: davinci: clock: return 0 upon error from clk_round_rate() (2013-11-27
14:48:33 +0530)
A patch to fix the return value of clk_round_rate()
Paul Walmsley (1):
ARM: davinci: clock: return 0 upon error from clk_round_rate()
arch/arm/mach-davinci/clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/clock.c
index dc9a470..985e5fd 100644
--- a/arch/arm/mach-davinci/clock.c
+++ b/arch/arm/mach-davinci/clock.c
@@ -133,7 +133,7 @@ EXPORT_SYMBOL(clk_get_rate);
long clk_round_rate(struct clk *clk, unsigned long rate)
{
if (clk == NULL || IS_ERR(clk))
- return -EINVAL;
+ return 0;
if (clk-round_rate)
return clk-round_rate(clk, rate);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v3 0/2] gpio: davinci: reuse for keystone arch
On Wednesday 08 January 2014 07:38 PM, Santosh Shilimkar wrote: On Tuesday 07 January 2014 11:06 PM, Sekhar Nori wrote: On Tuesday 07 January 2014 11:22 PM, Santosh Shilimkar wrote: Sekhar, On Tuesday 24 December 2013 06:41 AM, Grygorii Strashko wrote: This series is intended to update Davinci GPIO driver and reuse it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci. Keystone GPIO IP: supports: - up to 32 GPIO lines; - only unbanked irqs; See Documentation: Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf This series based on: https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio Changes in v3: - fixed code, changed by mistake; fixed sparse warning Changes in v2: - minor comments applied, no functional changes v2: https://lkml.org/lkml/2013/12/18/135 v1: https://lkml.org/lkml/2013/12/12/366 Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: Sekhar Nori nsek...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Grygorii Strashko (2): gpio: davinci: don't create irq_domain in case of unbanked irqs gpio: davinci: reuse for Keystone SoC .../devicetree/bindings/gpio/gpio-davinci.txt |4 +- drivers/gpio/gpio-davinci.c| 82 ++-- 2 files changed, 61 insertions(+), 25 deletions(-) Have you picked up the $subject series in your queue ? Not yet, at least on the new compatible introduction, I need an ack from DT folks. I noticed that but the usual 2 weeks period to get ack is over I guess ;-) The DT part is really trivial as well but I let you decide. I just realize that Rob's e-mail address bounces. I have added his updated address now and hopefully he will see this to provide his ack. Rob, We need your ack on 2/2 of this series. If you do not have the patch, I can forward it to you. I am happy with the patches though and have tested them as well, In case I do not get an ack from 2/2 in time, I can at least send 1/2 for inclusion after my first gpio pull request to ARM-SoC gets pulled. Would be great to get both of them but if not both at least 1/2. I had already sent it with my first pull request. Hmph. Everything except 2/2 of tis series should be in linux-next now. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci watchdog change for v3.14
Hi Arnd, Olof, Kevin,
Can you please pull the following patch. It has been acked by Wim.
There are some other davinci_wdt.c patches Wim has queued in his
tree, but a test merge of this patch with latest linux-next does
not throw any conflicts.
Thanks,
Sekhar
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git
tags/davinci-for-v3.14/watchdog
for you to fetch changes up to 843748123d95ae77a489b41f2f193e8502fc7ea8:
watchdog: davinci: rename platform driver to davinci-wdt (2014-01-09 16:48:31
+0530)
This patch updates the davinci watchdog
platform device name from generic watchdog
to something more specific.
Ivan Khoronzhuk (1):
watchdog: davinci: rename platform driver to davinci-wdt
arch/arm/mach-davinci/da830.c |2 +-
arch/arm/mach-davinci/da850.c |2 +-
arch/arm/mach-davinci/da8xx-dt.c |2 +-
arch/arm/mach-davinci/devices-da8xx.c |4 ++--
arch/arm/mach-davinci/devices.c |2 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c|2 +-
arch/arm/mach-davinci/dm646x.c|2 +-
drivers/watchdog/davinci_wdt.c|4 ++--
10 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 0813b51..82c6013 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -385,7 +385,7 @@ static struct clk_lookup da830_clks[] = {
CLK(NULL, pll0_sysclk7, pll0_sysclk7),
CLK(i2c_davinci.1,NULL, i2c0_clk),
CLK(NULL, timer0, timerp64_0_clk),
- CLK(watchdog, NULL, timerp64_1_clk),
+ CLK(davinci-wdt, NULL, timerp64_1_clk),
CLK(NULL, arm_rom, arm_rom_clk),
CLK(NULL, scr0_ss, scr0_ss_clk),
CLK(NULL, scr1_ss, scr1_ss_clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 352984e..ccb2f58 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -443,7 +443,7 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL, pll1_sysclk3, pll1_sysclk3),
CLK(i2c_davinci.1,NULL, i2c0_clk),
CLK(NULL, timer0, timerp64_0_clk),
- CLK(watchdog, NULL, timerp64_1_clk),
+ CLK(davinci-wdt, NULL, timerp64_1_clk),
CLK(NULL, arm_rom, arm_rom_clk),
CLK(NULL, tpcc0,tpcc0_clk),
CLK(NULL, tptc0,tptc0_clk),
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index d2bc574..ed19287 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -32,7 +32,7 @@ static void __init da8xx_init_irq(void)
static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA(ti,davinci-i2c, 0x01c22000, i2c_davinci.1, NULL),
- OF_DEV_AUXDATA(ti,davinci-wdt, 0x01c21000, watchdog, NULL),
+ OF_DEV_AUXDATA(ti,davinci-wdt, 0x01c21000, davinci-wdt, NULL),
OF_DEV_AUXDATA(ti,da830-mmc, 0x01c4, da830-mmc.0, NULL),
OF_DEV_AUXDATA(ti,da850-ehrpwm, 0x01f0, ehrpwm, NULL),
OF_DEV_AUXDATA(ti,da850-ehrpwm, 0x01f02000, ehrpwm, NULL),
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index c46eccb..f9ba74b 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -389,7 +389,7 @@ static struct resource da8xx_watchdog_resources[] = {
};
static struct platform_device da8xx_wdt_device = {
- .name = watchdog,
+ .name = davinci-wdt,
.id = -1,
.num_resources = ARRAY_SIZE(da8xx_watchdog_resources),
.resource = da8xx_watchdog_resources,
@@ -399,7 +399,7 @@ void da8xx_restart(enum reboot_mode mode, const char *cmd)
{
struct device *dev;
- dev = bus_find_device_by_name(platform_bus_type, NULL, watchdog);
+ dev = bus_find_device_by_name(platform_bus_type, NULL, davinci-wdt);
if (!dev) {
pr_err(%s: failed to find watchdog device\n, __func__);
return;
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 3996e98..5cf9a02 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -302,7 +302,7 @@ static struct resource wdt_resources[] = {
};
struct platform_device davinci_wdt_device = {
-
Re: [PATCH v3 0/2] gpio: davinci: reuse for keystone arch
On Tuesday 07 January 2014 11:22 PM, Santosh Shilimkar wrote: Sekhar, On Tuesday 24 December 2013 06:41 AM, Grygorii Strashko wrote: This series is intended to update Davinci GPIO driver and reuse it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci. Keystone GPIO IP: supports: - up to 32 GPIO lines; - only unbanked irqs; See Documentation: Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf This series based on: https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio Changes in v3: - fixed code, changed by mistake; fixed sparse warning Changes in v2: - minor comments applied, no functional changes v2: https://lkml.org/lkml/2013/12/18/135 v1: https://lkml.org/lkml/2013/12/12/366 Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: Sekhar Nori nsek...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Grygorii Strashko (2): gpio: davinci: don't create irq_domain in case of unbanked irqs gpio: davinci: reuse for Keystone SoC .../devicetree/bindings/gpio/gpio-davinci.txt |4 +- drivers/gpio/gpio-davinci.c| 82 ++-- 2 files changed, 61 insertions(+), 25 deletions(-) Have you picked up the $subject series in your queue ? Not yet, at least on the new compatible introduction, I need an ack from DT folks. I am happy with the patches though and have tested them as well, In case I do not get an ack from 2/2 in time, I can at least send 1/2 for inclusion after my first gpio pull request to ARM-SoC gets pulled. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci GPIO updates for v3.14
On Thursday 26 December 2013 12:33 AM, Sekhar Nori wrote: Hi Arnd, Olof, Kevin, Here are some DaVinci GPIO driver updates and the resulting platform code changes. All the patches have been acked by Linus. To handle dependencies easily, we both agreed that it will be better I send the driver updates via ARM-SoC. There is a new DT-binding which has been acked by Rob H. I have made the pull request over -rc4 instead of an older -rc because of this work depends on some fixes merged in that -rc (even for a successful build). Can you please pull this? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/2] gpio: davinci: reuse for Keystone SoC
Rob, On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote: The similar GPIO HW block is used by keystone SoCs as in Davinci SoCs. Hence, reuse Davinci GPIO driver for Keystone taking into account that Keystone contains ARM GIC IRQ controller which is implemented using IRQ Chip. Documentation: http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf Cc: Linus Walleij linus.wall...@linaro.org Cc: Alexandre Courbot gnu...@gmail.com Cc: Sekhar Nori nsek...@ti.com Cc: devicet...@vger.kernel.org Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com --- .../devicetree/bindings/gpio/gpio-davinci.txt |4 +- drivers/gpio/gpio-davinci.c| 46 2 files changed, 40 insertions(+), 10 deletions(-) diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt index a2e839d..4ce9862 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -1,7 +1,7 @@ -Davinci GPIO controller bindings +Davinci/Keystone GPIO controller bindings Required Properties: -- compatible: should be ti,dm6441-gpio +- compatible: should be ti,dm6441-gpio, ti,keystone-gpio Can I get your ack for this change? Its pretty trivial, but still.. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 2/2] gpio: davinci: reuse for Keystone SoC
On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:
The similar GPIO HW block is used by keystone SoCs as
in Davinci SoCs.
Hence, reuse Davinci GPIO driver for Keystone taking into
account that Keystone contains ARM GIC IRQ controller which
is implemented using IRQ Chip.
Documentation:
http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Sekhar Nori nsek...@ti.com
Cc: devicet...@vger.kernel.org
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
.../devicetree/bindings/gpio/gpio-davinci.txt |4 +-
drivers/gpio/gpio-davinci.c| 46
2 files changed, 40 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d..4ce9862 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,7 +1,7 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
Required Properties:
-- compatible: should be ti,dm6441-gpio
+- compatible: should be ti,dm6441-gpio, ti,keystone-gpio
- reg: Physical base address of the controller and the size of memory mapped
registers.
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 1b33806..38741cc 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -413,6 +413,26 @@ static const struct irq_domain_ops davinci_gpio_irq_ops
= {
.xlate = irq_domain_xlate_onetwocell,
};
+static struct irq_chip *davinci_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip_type gpio_unbanked;
+
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+
+ return gpio_unbanked.chip;
+};
+
+static struct irq_chip *keystone_gpio_get_irq_chip(unsigned int irq)
+{
+ static struct irq_chip gpio_unbanked;
+
+ gpio_unbanked = *irq_get_chip(irq);
+ return gpio_unbanked;
+};
+
+static const struct of_device_id davinci_gpio_ids[];
+
/*
* NOTE: for suspend/resume, probably best to make a platform_device with
* suspend_late/resume_resume calls hooking into results of the set_wake()
@@ -433,6 +453,18 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
struct davinci_gpio_platform_data *pdata = dev-platform_data;
struct davinci_gpio_regs __iomem *g;
struct irq_domain *irq_domain = NULL;
+ const struct of_device_id *match;
+ struct irq_chip *irq_chip;
+ struct irq_chip *(*gpio_get_irq_chip)(unsigned int irq);
+
+ /*
+ * Use davinci_gpio_get_irq_chip by default to handle non DT cases
+ */
+ gpio_get_irq_chip = davinci_gpio_get_irq_chip;
+ match = of_match_device(of_match_ptr(davinci_gpio_ids),
+ dev);
+ if (match)
+ gpio_get_irq_chip = match-data;
This produces a sparse warning:
CHECK drivers/gpio/gpio-davinci.c
drivers/gpio/gpio-davinci.c:467:35: warning: incorrect type in assignment
(different modifiers)
drivers/gpio/gpio-davinci.c:467:35:expected struct irq_chip *( *[assigned]
gpio_get_irq_chip )( ... )
drivers/gpio/gpio-davinci.c:467:35:got void const *const data
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2 1/2] gpio: davinci: don't create irq_domain in case of unbanked irqs
On Wednesday 18 December 2013 03:37 PM, Grygorii Strashko wrote:
The system may crash if:
- there are more then 1 bank
s/then/than
- unbanked irqs are enabled
- someone will call gpio_to_irq() for GPIO from bank2 or above
Hence, fix it by not creating irq_domain if unbanked irqs are enabled
and correct gpio_to_irq_banked() to handle this properly.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Alexandre Courbot gnu...@gmail.com
Cc: Sekhar Nori nsek...@ti.com
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
drivers/gpio/gpio-davinci.c | 34 +++---
1 file changed, 19 insertions(+), 15 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index 5d163c0..1b33806 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -351,7 +351,10 @@ static int gpio_to_irq_banked(struct gpio_chip *chip,
unsigned offset)
{
struct davinci_gpio_controller *d = chip2controller(chip);
- return irq_create_mapping(d-irq_domain, d-chip.base + offset);
+ if (d-irq_domain)
+ return irq_create_mapping(d-irq_domain, d-chip.base + offset);
+ else
+ return -ENXIO;
}
static int gpio_to_irq_unbanked(struct gpio_chip *chip, unsigned offset)
@@ -429,7 +432,7 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
struct davinci_gpio_controller *chips = platform_get_drvdata(pdev);
struct davinci_gpio_platform_data *pdata = dev-platform_data;
struct davinci_gpio_regs __iomem *g;
- struct irq_domain *irq_domain;
+ struct irq_domain *irq_domain = NULL;
ngpio = pdata-ngpio;
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
@@ -453,18 +456,20 @@ static int davinci_gpio_irq_setup(struct
platform_device *pdev)
}
clk_prepare_enable(clk);
- irq = irq_alloc_descs(-1, 0, ngpio, 0);
- if (irq 0) {
- dev_err(dev, Couldn't allocate IRQ numbers\n);
- return irq;
- }
+ if (!pdata-gpio_unbanked) {
+ irq = irq_alloc_descs(-1, 0, ngpio, 0);
+ if (irq 0) {
+ dev_err(dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
The code was correct before moving. Any objections to doing
return irq;
instead?
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v7] gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
On Friday 13 December 2013 09:34 AM, Prabhakar Lad wrote:
Hi Linus,
On Fri, Dec 13, 2013 at 2:01 AM, Linus Walleij linus.wall...@linaro.org
wrote:
On Wed, Dec 11, 2013 at 6:52 PM, Prabhakar Lad
prabhakar.cse...@gmail.com wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch replaces the __raw_readl/writel with
{readl|writel}_relaxed(), Altough the code runs on ARMv5
based SOCs, changing this will help copying the code
s/copying/using
for other uses.
Call out usability on big-endian machines specifically here.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
This patch is part of series [1] rest of the patches
are Acked/reviewed so posting this patch independently
and marking it as v7.
[1] http://www.spinics.net/lists/devicetree/msg13037.html
drivers/gpio/gpio-davinci.c | 36 ++--
Acked-by: Linus Walleij linus.wall...@linaro.org
Thanks for the Ack.
Should I take this into the GPIO tree, or should it go
in through the DaVinci tree?
To avoid dependencies its better it goes via DaVinci tree.
I added this to v3.14/gpio branch of my tree (with modifications I
mentioned above).
I dont think there are dependencies for this particular patch though
(applies and builds nicely on latest Linus T's tree). Even then, there
are too many GPIO patches floating around and I think it is better for
me to collect them for a while and if there really are no platform code
dependencies overall, I can probably hand that branch off to Linus W. We
will see.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 2/6] This patch converts the davinci gpio driver to use irqdomain support.
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
[grygorii.stras...@ti.com:
- switch to use one irq-domain per all GPIO banks
- keep irq_create_mapping() call in gpio_to_irq_banked() as it
simply transformed to irq_find_mapping() if IRQ mapping exist
already]
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
A proper subject line is missing. I added the following as the subject:
gpio: davinci: convert to use irqdomain
and moved your current subject line to become the commit text.
@@ -396,6 +411,20 @@ static int davinci_gpio_irq_setup(struct platform_device
*pdev)
}
clk_prepare_enable(clk);
+ irq = irq_alloc_descs(-1, 0, ngpio, 0);
+ if (irq 0) {
+ dev_err(dev, Couldn't allocate IRQ numbers\n);
+ return -ENODEV;
modified this to:
return irq;
since your have already received a more relevant error code. With these
modifications and Linus's ack, queuing for v3.14.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 3/6] gpio: davinci: remove unused variable intc_irq_num
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com As the davinci-gpio driver is migrated to use irqdomain there is no need to pass the irq base for the gpio driver. This patch removes this variable from davinci_gpio_platform_data and also the refrences from the machine file. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Queuing for v3.14 along with Linus's ack. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 5/6] ARM: davinci: da850: add GPIO DT node
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: From: KV Sujith sujit...@ti.com Add DT node for Davinci GPIO driver. Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Added to v3.14/dt branch of my k.org tree. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 6/6] ARM: davinci: da850 evm: add GPIO pinumux entries DT node
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
From: KV Sujith sujit...@ti.com
Add GPIO DT node and pinmux entries for DA850 EVM. GPIO is
configurable differently on different boards. So add GPIO
pinmuxing in dts file.
Signed-off-by: KV Sujith sujit...@ti.com
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
arch/arm/boot/dts/da850-evm.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 588ce58..f82c129 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -17,6 +17,21 @@
soc {
pmx_core: pinmux@1c14120 {
status = okay;
+
+ gpio_pins: pinmux_gpio_pins {
+ pinctrl-single,bits =
+ /* GPIO2_4 GPIO2_6 */
+ 0x18 0x8080 0xf0f0
+ /* GPIO2_8 GPIO2_15 */
+ 0x14 0x8008 0xf00f
+ /* GPIO3_12 GPIO3_13 */
+ 0x1C 0x8800 0xff00
+ /* GPIO4_0 GPIO4_1 */
+ 0x28 0x8800 0xff00
+ /* GPIO6_9 GPIO6_10 GPIO6_13 */
+ 0x34 0x08800800 0x0ff00f00
+ ;
+ };
};
Shouldn't these pinmux entries be part of actual device
node which needs them to be muxed this way? For now, I
have committed the attached reduced patch.
Thanks,
Sekhar
---8---
From 3a9574f2aa4ffd9b867321a1f298893410bd3718 Mon Sep 17 00:00:00 2001
From: KV Sujith sujit...@ti.com
Date: Thu, 21 Nov 2013 23:45:31 +0530
Subject: [PATCH 1/1] ARM: davinci: da850 evm: add GPIO pinumux entries DT node
Add GPIO DT node and pinmux entries for DA850 EVM. GPIO is
configurable differently on different boards. So add GPIO
pinmuxing in dts file.
Signed-off-by: KV Sujith sujit...@ti.com
Signed-off-by: Philip Avinash avinashphi...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/boot/dts/da850-evm.dts |3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 588ce58..1e11e5a 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -101,6 +101,9 @@
pinctrl-names = default;
pinctrl-0 = mii_pins;
};
+ gpio: gpio@1e26000 {
+ status = okay;
+ };
};
nand_cs3@6200 {
status = okay;
--
1.7.10.1
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v1 3/9] gpio: davinci: use chained_irq_enter/chained_irq_exit API
On Wednesday 27 November 2013 01:10 AM, Grygorii Strashko wrote: It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack) from chained IRQ handler directly. Because, Davinci GPIO block is used by different SoCs, which, in turn, have different Main IRQ controllers (Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce diffrent set of IRQ chip callbacks. As result, call of gpio_irq_handler() on Keysone will simply cause crash the system, because ARM-GIC implements .irq_eoi() instead of .irq_ack(). Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as they are intended to handle exact such cases. Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com Queued with Linus's and Santosh's acks. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote: Linus, Sekhar, On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote: This series is intended to update Davinci GPIO driver and reuse it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci. Keystone GPIO IP: supports: - up to 32 GPIO lines; - only unbanked irqs; See Documentation: Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf This series depends on: [1] [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio https://lkml.org/lkml/2013/11/8/22 [2] [PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement https://www.mail-archive.com/devicetree@vger.kernel.org/msg05970.html [3] gpio: davinci: get rid of DAVINCI_N_GPIO https://lkml.org/lkml/2013/11/26/405 [4] gpio: introduce GPIO_DAVINCI kconfig option https://lkml.org/lkml/2013/11/26/435 [5] gpio: davinci: use chained_irq_enter/chained_irq_exit API https://lkml.org/lkml/2013/11/26/428 To handle all dependencies, I've created a branch where I collected all ready to merge patches (all acks added in patches) and this series: - https://github.com/grygoriyS/linux.git - branch: keystone-master-gpio-for-next Can one of you pull all these patches ? So I went through my backlog and queued all that I think is ready. Here is the branch. Let me know if there is anything else missing. https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/gpio Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 0/2] gpio: davinci: reuse for keystone arch
On Sunday 15 December 2013 07:20 PM, Sekhar Nori wrote: On Sunday 15 December 2013 12:41 AM, Santosh Shilimkar wrote: Linus, Sekhar, On Thursday 12 December 2013 01:12 PM, Grygorii Strashko wrote: This series is intended to update Davinci GPIO driver and reuse it for Keystone SoCs, because Keystone uses the similar GPIO IP like Davinci. Keystone GPIO IP: supports: - up to 32 GPIO lines; - only unbanked irqs; See Documentation: Keystone - http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf This series depends on: [1] [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio https://lkml.org/lkml/2013/11/8/22 [2] [PATCH v6 0/6] gpio: daVinci: cleanup and feature enhancement https://www.mail-archive.com/devicetree@vger.kernel.org/msg05970.html [3] gpio: davinci: get rid of DAVINCI_N_GPIO https://lkml.org/lkml/2013/11/26/405 [4] gpio: introduce GPIO_DAVINCI kconfig option https://lkml.org/lkml/2013/11/26/435 [5] gpio: davinci: use chained_irq_enter/chained_irq_exit API https://lkml.org/lkml/2013/11/26/428 To handle all dependencies, I've created a branch where I collected all ready to merge patches (all acks added in patches) and this series: - https://github.com/grygoriyS/linux.git - branch: keystone-master-gpio-for-next Can one of you pull all these patches ? So I went through my backlog and queued all that I think is ready. Here is the branch. Let me know if there is anything else missing. Forgot to mention that I have not been able to test them today though. They will hit linux-next only after I have been able to test them and I send a pull request to arm-soc or Linus W. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci fixes for v3.13
Hi Arnd, Olof, Kevin, Looks like this pull request was never picked up. Can you please pull this for the next -rc? Thanks, Sekhar On 11/21/2013 10:18 PM, Sekhar Nori wrote: The following changes since commit 527d1511310a8965081869260394e20c7013: Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2013-11-20 15:13:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.13-rc1 for you to fetch changes up to e462f1f5174893f3f5efd03a31ca014b02120f9a: ARM: davinci: fix number of resources passed to davinci_gpio_register() (2013-11-21 20:13:28 +0530) This pull request contains a fixe for broken unbanked GPIO IRQ support and a fix for some random memory corruption. The bugs were introduced during v3.13 merge window. Lad, Prabhakar (2): gpio: davinci: fix check for unbanked gpio ARM: davinci: fix number of resources passed to davinci_gpio_register() arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- drivers/gpio/gpio-davinci.c|4 +++- 5 files changed, 7 insertions(+), 5 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci fixes for v3.13-rc3
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.13-rc3 for you to fetch changes up to ee880dbd1688c99084052c7890246c1e16c89820: ARM: davinci: Fix McASP mem resource names (2013-12-05 03:02:20 +0530) This pull request includes a patch to align platform code to driver's usage of platform_get_resource_byname() This is needed to start successfully probing audio again. The regression was introduced in v3.13 merge window. Peter Ujfalusi (1): ARM: davinci: Fix McASP mem resource names arch/arm/mach-davinci/devices-da8xx.c |4 ++-- arch/arm/mach-davinci/dm355.c |1 + arch/arm/mach-davinci/dm365.c |1 + arch/arm/mach-davinci/dm644x.c|1 + arch/arm/mach-davinci/dm646x.c|4 ++-- 5 files changed, 7 insertions(+), 4 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [GIT PULL] DaVinci fixes for v3.13-rc3
+ Peter Hi Olof, On 12/5/2013 4:03 AM, Olof Johansson wrote: Hi, Pulled. A suggestion for the future, please try to use a patch description that doesn't require you to motivate why this is needed now. I.e. the patch description should contain: What is broken How/when it broke (SHA or general timeframe) How it's fixed In this case, it wasn't obvious what the actual breakage was (i.e. audio not working), nor when it was introduced. Of course, if something is trivial you don't need to fill it in, nor should it be a form-based description. But those three answers should generally be possible to find in the patch description for a bugfix. Yes, understood. I generally do push back on this and this time I (quite unnecessarily) tried supplementing the information missing in description through the tag signing message. Should have made sure the commit description has the required information instead. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 4/6] gpio: davinci: add OF support
On Friday 29 November 2013 01:16 PM, Linus Walleij wrote: On Tue, Nov 26, 2013 at 6:12 PM, Sekhar Nori nsek...@ti.com wrote: On Tuesday 26 November 2013 06:03 PM, Grygorii Strashko wrote: Actually, the same was proposed by Linus, but we've tried avoid such huge rework - by switching to one irq_domain per all banks for example. I didn't really read that proposal from Linus so if two people independently suggested the same thing, there must be something worth considering there :) From a GPIO POV it's not such a big deal really, this approach is fine and the important thing is that we progress toward a more standard driver... it's more a question for the DT people IMO. I really like the current patch set. Rob has acked v5 of this patch. So no objection from DT people too. My concern was a bit futuristic. Since everyone is happy I think we can go with the current patch itself. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: Fix McASP mem resource names
Peter, On Wednesday 13 November 2013 08:18 PM, Peter Ujfalusi wrote: The ASoC McASP driver looks for the mem resources by name and: mpu and dat regions. Change/add the needed name for the mem resources so the driver can pick the correct resource. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com Thanks for the patch. It does make the soundcard detect again on DaVinci. Will queue for v3.13-rc3 (too late for -rc2, sorry!) Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: clock: return 0 upon error from clk_round_rate()
On Wednesday 27 November 2013 06:26 AM, Paul Walmsley wrote: clk_round_rate() should return 0 now upon an error, rather than returning a negative error code. This is because clk_round_rate() is being changed to return an unsigned return type rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Philip Avinash avinashphi...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com I applied this to my v3.14/soc[1] branch. For some reason I could not apply the patch to v3.11-rc1 (patch command returns error). Nothing is obviously worng. Anyway, the change is minor so I made the change manually. Thanks, Sekhar [1] https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.14/soc ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 4/6] gpio: davinci: add OF support
On Tuesday 26 November 2013 06:03 PM, Grygorii Strashko wrote: On 11/25/2013 01:00 PM, Sekhar Nori wrote: On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: From: KV Sujith sujit...@ti.com This patch adds OF parser support for davinci gpio driver and also appropriate documentation in gpio-davinci.txt located at Documentation/devicetree/bindings/gpio/. Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com [prabhakar.cse...@gmail.com: simplified the OF code, removed unnecessary DT property and also simplified the commit message] Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/gpio/gpio-davinci.txt | 41 ++ drivers/gpio/gpio-davinci.c| 57 ++-- 2 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt new file mode 100644 index 000..a2e839d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -0,0 +1,41 @@ +Davinci GPIO controller bindings + +Required Properties: +- compatible: should be ti,dm6441-gpio + +- reg: Physical base address of the controller and the size of memory mapped + registers. + +- gpio-controller : Marks the device node as a gpio controller. + +- interrupt-parent: phandle of the parent interrupt controller. + +- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are + supported at a time. If this is true.. + +- ti,ngpio: The number of GPIO pins supported. + +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt +line to processor. .. then why do you need to maintain this separately? Number of elements in interrupts property should give you this answer, no? There can certainly be devices (past and future) which use a mixture of banked and unbanked IRQs. So a binding which does not take care of this is likely to change in future and that is a problem since it brings in backward compatibility of the binding into picture. The right thing would be to define the DT node per-bank similar to what is done on OMAP rather than for all banks together. That way there can be a separate property which determines whether that bank supports direct-mapped or banked IRQs (or that could be inferred if the number of tuples in the interrupts property is more than one). Number of IRQ can't be simply used to determine type of IRQ - need to handle IRQ names, because each bank(32 gpios) may have up to 2 banked IRQs (one per 16 GPIO). Okay. That's why I inserted that comment in parenthesis :) Few things here: - The mixed banked/unbanked functionality has never been supported before. True. I actually misread the driver before. - The Davinci GPIO IP is different from OMAP and has common control registers for all banks. Well the only common register I can see is BINTEN - bank interrupt enable. This register can simply be initialized to enable interrupts from all banks possible as until the rising and falling edge triggers are programmed, there wont be any actual interrupts generated. - The proposed approach is more less easy to implement for DT case, but for not-DT case - the platform data will need to be changed significantly (. So, from this point of view, that would be a big change (actually the total driver rewriting). Well, I certainly don't think its a complete driver re-write. It will take a bit of effort agreed, but I think the driver will also come out a lot cleaner. Honestly, I am not so much worried about the kernel code here. Its the bindings I am worried about. Once the bindings go in assuming there will never be banked and unbanked GPIO IRQs on the same SoC, changing them to do something else will be very painful with the need to keep backward compatibility and support for both semantics. That said, because there is no present hardware which needs both banked and unbanked at the same time, I wont press for this to be done endlessly. Do you have any thoughts about how it can be done in a simpler way? I don't know if there is a simpler way, but I don't think there is too much effort too. I leave it to those implementing it though. Actually, the same was proposed by Linus, but we've tried avoid such huge rework - by switching to one irq_domain per all banks for example. I didn't really read that proposal from Linus so if two people independently suggested the same thing, there must be something worth considering there :) Thanks, Sekhar ___ Davinci-linux-open-source mailing
Re: [PATCH v6 4/6] gpio: davinci: add OF support
On Wednesday 27 November 2013 01:11 AM, Grygorii Strashko wrote: On 11/26/2013 07:12 PM, Sekhar Nori wrote: On Tuesday 26 November 2013 06:03 PM, Grygorii Strashko wrote: On 11/25/2013 01:00 PM, Sekhar Nori wrote: On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: From: KV Sujith sujit...@ti.com This patch adds OF parser support for davinci gpio driver and also appropriate documentation in gpio-davinci.txt located at Documentation/devicetree/bindings/gpio/. Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com [prabhakar.cse...@gmail.com: simplified the OF code, removed unnecessary DT property and also simplified the commit message] Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/gpio/gpio-davinci.txt | 41 ++ drivers/gpio/gpio-davinci.c| 57 ++-- 2 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt new file mode 100644 index 000..a2e839d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -0,0 +1,41 @@ +Davinci GPIO controller bindings + +Required Properties: +- compatible: should be ti,dm6441-gpio + +- reg: Physical base address of the controller and the size of memory mapped + registers. + +- gpio-controller : Marks the device node as a gpio controller. + +- interrupt-parent: phandle of the parent interrupt controller. + +- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are + supported at a time. If this is true.. + +- ti,ngpio: The number of GPIO pins supported. + +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt + line to processor. .. then why do you need to maintain this separately? Number of elements in interrupts property should give you this answer, no? There can certainly be devices (past and future) which use a mixture of banked and unbanked IRQs. So a binding which does not take care of this is likely to change in future and that is a problem since it brings in backward compatibility of the binding into picture. The right thing would be to define the DT node per-bank similar to what is done on OMAP rather than for all banks together. That way there can be a separate property which determines whether that bank supports direct-mapped or banked IRQs (or that could be inferred if the number of tuples in the interrupts property is more than one). Number of IRQ can't be simply used to determine type of IRQ - need to handle IRQ names, because each bank(32 gpios) may have up to 2 banked IRQs (one per 16 GPIO). Okay. That's why I inserted that comment in parenthesis :) Few things here: - The mixed banked/unbanked functionality has never been supported before. True. I actually misread the driver before. - The Davinci GPIO IP is different from OMAP and has common control registers for all banks. Well the only common register I can see is BINTEN - bank interrupt enable. This register can simply be initialized to enable interrupts from all banks possible as until the rising and falling edge triggers are programmed, there wont be any actual interrupts generated. - The proposed approach is more less easy to implement for DT case, but for not-DT case - the platform data will need to be changed significantly (. So, from this point of view, that would be a big change (actually the total driver rewriting). Well, I certainly don't think its a complete driver re-write. It will take a bit of effort agreed, but I think the driver will also come out a lot cleaner. Honestly, I am not so much worried about the kernel code here. Its the bindings I am worried about. Once the bindings go in assuming there will never be banked and unbanked GPIO IRQs on the same SoC, changing them to do something else will be very painful with the need to keep backward compatibility and support for both semantics. That said, because there is no present hardware which needs both banked and unbanked at the same time, I wont press for this to be done endlessly. Do you have any thoughts about how it can be done in a simpler way? I don't know if there is a simpler way, but I don't think there is too much effort too. I leave it to those implementing it though. Oh. I see no problem to implement it for DT, but this change require to convert one device to the tree of devices: GPIO controller |- GPIO bank1 ... |- GPIO bankX And that's will need to be handled somehow from platform code (which is non-DT and which I can't verify
Re: [PATCH v6 1/6] gpio: davinci: use readl/writel instead of __raw_*
Prabhakar,
On Monday 25 November 2013 09:42 AM, Prabhakar Lad wrote:
Hi Taras,
On Fri, Nov 22, 2013 at 3:38 PM, Taras Kondratiuk
taras.kondrat...@linaro.org wrote:
On 21 November 2013 20:15, Prabhakar Lad prabhakar.cse...@gmail.com wrote:
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch replaces the __raw_readl/writel with
readl and writel, Altough the code runs on ARMv5
based SOCs, changing this will help copying the code
for other uses.
This replacement has a functional impact: it adds memory barriers.
Please note this in the description.
Also please add a bit of explanation on why do you need to add barriers.
Agreed this adds memory barriers, I'll add a note about it.
Well the barriers certainly make it easier to debug by having both
device and memory accesses happen in program order. That said, if there
is no pressing reason to add barriers, you can use
{readl|writel}_relaxed() instead. That will make the code protable
across endianess.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v6 4/6] gpio: davinci: add OF support
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: From: KV Sujith sujit...@ti.com This patch adds OF parser support for davinci gpio driver and also appropriate documentation in gpio-davinci.txt located at Documentation/devicetree/bindings/gpio/. Acked-by: Linus Walleij linus.wall...@linaro.org Acked-by: Rob Herring rob.herr...@calxeda.com Signed-off-by: KV Sujith sujit...@ti.com Signed-off-by: Philip Avinash avinashphi...@ti.com [prabhakar.cse...@gmail.com: simplified the OF code, removed unnecessary DT property and also simplified the commit message] Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/gpio/gpio-davinci.txt | 41 ++ drivers/gpio/gpio-davinci.c| 57 ++-- 2 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt new file mode 100644 index 000..a2e839d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -0,0 +1,41 @@ +Davinci GPIO controller bindings + +Required Properties: +- compatible: should be ti,dm6441-gpio + +- reg: Physical base address of the controller and the size of memory mapped + registers. + +- gpio-controller : Marks the device node as a gpio controller. + +- interrupt-parent: phandle of the parent interrupt controller. + +- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are + supported at a time. If this is true.. + +- ti,ngpio: The number of GPIO pins supported. + +- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt + line to processor. .. then why do you need to maintain this separately? Number of elements in interrupts property should give you this answer, no? There can certainly be devices (past and future) which use a mixture of banked and unbanked IRQs. So a binding which does not take care of this is likely to change in future and that is a problem since it brings in backward compatibility of the binding into picture. The right thing would be to define the DT node per-bank similar to what is done on OMAP rather than for all banks together. That way there can be a separate property which determines whether that bank supports direct-mapped or banked IRQs (or that could be inferred if the number of tuples in the interrupts property is more than one). Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci fixes for v3.13
The following changes since commit 527d1511310a8965081869260394e20c7013: Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc (2013-11-20 15:13:47 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-fixes-for-v3.13-rc1 for you to fetch changes up to e462f1f5174893f3f5efd03a31ca014b02120f9a: ARM: davinci: fix number of resources passed to davinci_gpio_register() (2013-11-21 20:13:28 +0530) This pull request contains a fixe for broken unbanked GPIO IRQ support and a fix for some random memory corruption. The bugs were introduced during v3.13 merge window. Lad, Prabhakar (2): gpio: davinci: fix check for unbanked gpio ARM: davinci: fix number of resources passed to davinci_gpio_register() arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- drivers/gpio/gpio-davinci.c|4 +++- 5 files changed, 7 insertions(+), 5 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 1/2] gpio: davinci: Fix a check for unbanked gpio
On Monday 18 November 2013 04:18 PM, Linus Walleij wrote: On Tue, Nov 12, 2013 at 7:18 AM, Sekhar Nori nsek...@ti.com wrote: On Friday 08 November 2013 12:15 PM, Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes a check for offset in gpio_to_irq_unbanked() and also assigns gpio_irq, gpio_unbanked of chips[0] to appropriate values which is used in gpio_to_irq_unbanked() function. Reported-by: Grygorii Strashko grygorii.stras...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com You should note explicitly that this patch fixes broken unbanked IRQ support. You mostly just described what you are doing. I will fixup while committing. So you're carrying this patch Sekhar? Yes, and I would have sent this for upstream already if not for I going under the weather a bit past couple of days. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/6] gpio: davinci: Fixed a check for unbanked gpio
On Wednesday 06 November 2013 03:45 PM, Prabhakar Lad wrote: Hi Linus, On Wed, Nov 6, 2013 at 3:26 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Nov 6, 2013 at 10:33 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On Tue, Nov 5, 2013 at 6:09 PM, Linus Walleij linus.wall...@linaro.org wrote: On Sat, Nov 2, 2013 at 4:39 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes the check for the offset in gpio_to_irq_unbanked() function. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Is this a regression that should go in right now? Yes it needs too. But on top of *what* exactly? This does not apply to my gpio tree devel branch and not even on the mainline kernel. Looks like this needs to go via ARM tree as the earlier patches have gone via ARM tree itself [1]. If you can ACK it Sekhar can get it in via ARM tree. The dependent patches are all in linux-next through ARM SoC queued for v3.13 merge. This fix can either be sent late in merge cycle once Linus has pulled ARM SoC or after v3.13-rc1 comes out. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v4 1/6] gpio: davinci: Fixed a check for unbanked gpio
Hi Grygorii, On Wednesday 06 November 2013 05:03 PM, Grygorii Strashko wrote: Hi Sekhar, Linus, On 11/06/2013 12:49 PM, Sekhar Nori wrote: On Wednesday 06 November 2013 03:45 PM, Prabhakar Lad wrote: Hi Linus, On Wed, Nov 6, 2013 at 3:26 PM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Nov 6, 2013 at 10:33 AM, Prabhakar Lad prabhakar.cse...@gmail.com wrote: On Tue, Nov 5, 2013 at 6:09 PM, Linus Walleij linus.wall...@linaro.org wrote: On Sat, Nov 2, 2013 at 4:39 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch fixes the check for the offset in gpio_to_irq_unbanked() function. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Is this a regression that should go in right now? Yes it needs too. But on top of *what* exactly? This does not apply to my gpio tree devel branch and not even on the mainline kernel. Looks like this needs to go via ARM tree as the earlier patches have gone via ARM tree itself [1]. If you can ACK it Sekhar can get it in via ARM tree. The dependent patches are all in linux-next through ARM SoC queued for v3.13 merge. This fix can either be sent late in merge cycle once Linus has pulled ARM SoC or after v3.13-rc1 comes out. Pls, wait a bit - this fix is incomplete :( The below changes have to be done too: Can either you or Prabhakar send a separate patch (series) with only the fixes? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v2] ARM: davinci: convert to clockevents_config_and_register
On Wednesday 16 October 2013 01:20 PM, Uwe Kleine-König wrote:
Hello,
On Wed, Oct 16, 2013 at 08:49:17AM +0530, Sekhar Nori wrote:
On Sunday 13 October 2013 02:06 PM, Uwe Kleine-König wrote:
clockevents_config_and_register is superior compared to setting
shift/mult and {min,max}_delta_ns by hand.
Tested-by: Prabhakar Lad prabhakar.cse...@gmail.com
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Prabhakar Lad wrote:
I have boot tested this patch on OMAP-L138 and tested the uptime
(with min ticks set to 1), should that be enough ?
I don't know for sure, but I guess so. If you agree, here is an updated
patch.
Best regards
Uwe
arch/arm/mach-davinci/time.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 7a55b5c..29a1a5d 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -331,7 +331,6 @@ static void davinci_set_mode(enum clock_event_mode mode,
static struct clock_event_device clockevent_davinci = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
- .shift = 32,
.set_next_event = davinci_set_next_event,
.set_mode = davinci_set_mode,
};
@@ -397,14 +396,10 @@ void __init davinci_timer_init(void)
/* setup clockevent */
clockevent_davinci.name = id_to_name[timers[TID_CLOCKEVENT].id];
- clockevent_davinci.mult = div_sc(davinci_clock_tick_rate, NSEC_PER_SEC,
-clockevent_davinci.shift);
- clockevent_davinci.max_delta_ns =
- clockevent_delta2ns(0xfffe, clockevent_davinci);
- clockevent_davinci.min_delta_ns = 5; /* 50 usec */
clockevent_davinci.cpumask = cpumask_of(0);
- clockevents_register_device(clockevent_davinci);
+ clockevents_config_and_register(clockevent_davinci,
+ davinci_clock_tick_rate, 1, 0xfffe);
checkpatch --strict complains about alignment of line break. Fixed locally.
I used the same style as in other places in that file.
Okay, but I prefer to fix for new code.
Another thought that came to me is that it's probably worth mentioning
that the min_delta_ns is changed from 50 usec to 1 hw tick. Something
like:
Note that the minimum delay is changed from 50 us to 1 hw tick
(which corresponds to 42 ns assuming a 24 MHz clock). It's
expected that the old value was miscalculated.
That would be interesting in case that the patch results in regressions.
Too late as I already sent my pull request. Adding this to patch
description would have been nice, I agree.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci: an SoC update for v3.13
The following changes since commit 61e6cfa80de5760bbe406f4e815b7739205754d2: Linux 3.12-rc5 (2013-10-13 15:41:28 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v3.13/soc-2 for you to fetch changes up to 859236d017978bb95f3e2794aece57da3a40fe5c: ARM: davinci: convert to clockevents_config_and_register (2013-10-16 06:14:55 +0530) This pull request includes a patch to use clockevents_config_and_register() for registering the clockevent. Uwe Kleine-König (1): ARM: davinci: convert to clockevents_config_and_register arch/arm/mach-davinci/time.c |9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: convert to clockevents_config_and_register
On Wednesday 25 September 2013 03:32 AM, Uwe Kleine-König wrote:
clockevents_config_and_register is superior compared to setting
shift/mult and {min,max}_delta_ns by hand.
Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de
---
Hello,
I wonder where the 50 us limit comes from. This is not a hardware limit,
is it?
Best regards
Uwe
arch/arm/mach-davinci/time.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index 7a55b5c..627bf8b 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -331,7 +331,6 @@ static void davinci_set_mode(enum clock_event_mode mode,
static struct clock_event_device clockevent_davinci = {
.features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
- .shift = 32,
.set_next_event = davinci_set_next_event,
.set_mode = davinci_set_mode,
};
@@ -397,14 +396,11 @@ void __init davinci_timer_init(void)
/* setup clockevent */
clockevent_davinci.name = id_to_name[timers[TID_CLOCKEVENT].id];
- clockevent_davinci.mult = div_sc(davinci_clock_tick_rate, NSEC_PER_SEC,
- clockevent_davinci.shift);
- clockevent_davinci.max_delta_ns =
- clockevent_delta2ns(0xfffe, clockevent_davinci);
- clockevent_davinci.min_delta_ns = 5; /* 50 usec */
clockevent_davinci.cpumask = cpumask_of(0);
- clockevents_register_device(clockevent_davinci);
+ /* min tick corresponds to 50 usec assuming a 24 MHz clock */
+ clockevents_config_and_register(clockevent_davinci,
+ davinci_clock_tick_rate, 1200, 0xfffe);
Min ticks can be set to 1, IMO. I think the 50usec limit used earlier
should have actually been 50ns assuming a 24MHz clock.
Prabhakar,
Can you please test this patch on a DaVinci platform you have with 1200
replaced with 1. I currently do not have access to a board.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: davinci: usb: provide minimal support for da850.
On Tuesday 24 September 2013 07:16 PM, Paul Chavent wrote:
As for the da830 and hawk boards, the da850 can provide minimalist usb
1.1 implementation. Moreover, this patch has only been tested with the
OHCI (on an OMAP L138 EVM / DA850 board), not with the Inventra HC
(that seems broken for the DA8XX).
This patch is inspired by the hawk board implementation.
Signed-off-by: Paul Chavent paul.chav...@onera.fr
---
arch/arm/mach-davinci/board-da850-evm.c | 153
1 file changed, 153 insertions(+)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index dd1fb24..f0bee9d 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -62,6 +62,9 @@
#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
+#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
+#define DA850_USB1_OC_PINGPIO_TO_PIN(6, 13)
+
static struct mtd_partition da850evm_spiflash_part[] = {
[0] = {
.name = UBL,
@@ -1431,6 +1434,155 @@ static __init int da850_wl12xx_init(void)
#endif /* CONFIG_DA850_WL12XX */
+#ifdef CONFIG_USB
+
+static irqreturn_t da850_usb_ocic_irq(int irq, void *dev_id);
+static da8xx_ocic_handler_t da850_usb_ocic_handler;
+
+static const short da850_usb11_pins[] = {
+ DA850_GPIO2_4, DA850_GPIO6_13,
+ -1
+};
+
+static int da850_usb_set_power(unsigned port, int on)
+{
+ gpio_set_value(DA850_USB1_VBUS_PIN, on);
+ return 0;
+}
+
+static int da850_usb_get_power(unsigned port)
+{
+ return gpio_get_value(DA850_USB1_VBUS_PIN);
+}
+
+static int da850_usb_get_oci(unsigned port)
+{
+ return !gpio_get_value(DA850_USB1_OC_PIN);
+}
+
+static int da850_usb_ocic_notify(da8xx_ocic_handler_t handler)
+{
+ int irq = gpio_to_irq(DA850_USB1_OC_PIN);
+ int error = 0;
+
+ if (handler != NULL) {
+ da850_usb_ocic_handler = handler;
+
+ error = request_irq(irq, da850_usb_ocic_irq,
+ IRQF_DISABLED | IRQF_TRIGGER_RISING |
+ IRQF_TRIGGER_FALLING,
+ OHCI over-current indicator, NULL);
+ if (error)
+ pr_err(%s: could not request IRQ to watch
+ over-current indicator changes\n, __func__);
+ } else {
+ free_irq(irq, NULL);
+ }
+ return error;
+}
+
+static struct da8xx_ohci_root_hub da850_usb11_pdata = {
+ .set_power = da850_usb_set_power,
+ .get_power = da850_usb_get_power,
+ .get_oci= da850_usb_get_oci,
+ .ocic_notify= da850_usb_ocic_notify,
+ /* TPS2087 switch @ 5V */
+ .potpgt = (3 + 1) / 2, /* 3 ms max */
+};
+
+static irqreturn_t da850_usb_ocic_irq(int irq, void *dev_id)
+{
+ da850_usb_ocic_handler(da850_usb11_pdata, 1);
+ return IRQ_HANDLED;
+}
+
+static __init void da850_usb_init(void)
+{
+ void __iomem *cfg_chip2_base;
+ int ret;
+ u32 val;
+
+ /*
+ * Set up USB clock/mode in the CFGCHIP2 register.
+ */
+
+ cfg_chip2_base = DA8XX_SYSCFG0_VIRT(DA8XX_CFGCHIP2_REG);
+
+ val = __raw_readl(cfg_chip2_base);
+
+ /* USB2.0 PHY reference clock is 24 MHz */
+ val = ~CFGCHIP2_REFFREQ;
+ val |= CFGCHIP2_REFFREQ_24MHZ;
+
+ /*
+ * Select internal reference clock for USB 2.0 PHY
+ * and use it as a clock source for USB 1.1 PHY
+ * (this is the default setting anyway).
+ */
+ val = ~CFGCHIP2_USB1PHYCLKMUX;
+ val |= CFGCHIP2_USB2PHYCLKMUX;
+
+ /*
+ * We have to override VBUS/ID signals when MUSB is configured into the
+ * host-only mode -- ID pin will float if no cable is connected, so the
+ * controller won't be able to drive VBUS thinking that it's a B-device.
+ * Otherwise, we want to use the OTG mode and enable VBUS comparators.
+ */
+ val = ~CFGCHIP2_OTGMODE;
+#ifdef CONFIG_USB_MUSB_HOST
+ val |= CFGCHIP2_FORCE_HOST;
+#else
+ val |= CFGCHIP2_SESENDEN | CFGCHIP2_VBDTCTEN;
+#endif
This is not good since it forces you to have two different kernel builds
for host and device mode. Are you sure this configuration is needed? If
this cannot be avoided, then can you see if this can be moved to the
driver itself since then it can probably make better runtime decisions?
+
+ /* configure the CFGCHIP2 register */
+ __raw_writel(val, cfg_chip2_base);
Please use writel() and readl() or the _relaxed() variants.
Actually, it looks like all of this initialization can be moved to the
driver itself with data passed from platform. That way you dont have the
replicate this code for EVM.
Since you say the inventra doesn't work, it will most probably help if
you drop the inventra specific code from this patch. That part can be
Re: [PATCH v3] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 9/27/2013 5:58 AM, Joel Fernandes wrote: On 09/26/2013 06:13 PM, Olof Johansson wrote: On Thu, Sep 26, 2013 at 2:55 PM, Joel Fernandes jo...@ti.com wrote: HWMOD removal for MMC is breaking edma_start as the events are being manually triggered due to unused channel list not being clear. The above issue is fixed by reading the dmas property from the DT node if it exists and clearing the bits in the unused channel list if the dma controller used by any device is EDMA. For this purpose we use the of_* helpers to parse the arguments in the dmas phandle list. Also introduced is a minor clean up of a checkpatch error in old code. Reviewed-by: Sekhar Nori nsek...@ti.com Reported-by: Balaji T K balaj...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Olof Johansson o...@lixom.net Cc: Nishanth Menon n...@ti.com Cc: Pantel Antoniou pa...@antoniou-consulting.com Cc: Jason Kridner jkrid...@beagleboard.org Cc: Koen Kooi k...@dominion.thruhere.net Signed-off-by: Joel Fernandes jo...@ti.com --- Just resending this patch after discussing with Sekhar and Olof. Actually, the patch you talked to me about was v3 of this. It seems that you have reposted v6 but labelled it v3. This is very confusing. Sorry about this. :-( This is indeed v6. AM335x is being booted by many users such as the beaglebone community. DT is the only boot method available for all these users. EDMA is required for the operation for many common peripherals in AM335x SoC such as McASP, MMC and Crypto. Although EDMA DT nodes are going in only for 3.13, in reality the kernel has been used for more than a year with EDMA code and out of tree EDMA DTS patches. Hence though the DT nodes are still not in mainline, this patch can be still be considered a critical fix as such and it would be great if it could be included in 3.12-rc release. Thanks. This is really the root of this problem. If you sit on code out of tree for a year, and something breaks that we couldn't even have detected since we didn't have the out-of-tree pieces. We'll help you the first few times (such as now) but we will eventually stop caring. When I started looking at EDMA in June, I noticed that a lot had already been merged. EDMA DMA Engine driver itself was merged last year, no worries there. but the long pending list of fixes to be made to the driver had to written and rewritten multiple times which took a long time. Due to this, the EDMA device tree entries could not be merged in fear that doing so would cause problems such as MMC/SD corruption etc. If I was in a worse mood, then I'd just say that since your users already has to have out-of-tree code to even use this functionality, they could just add this fix on top of that stack of patches. But I'm in a slightly better mood than that and I'll pick it up this time. :) Thank you! :) More details about why this broke an existing feature folks were using: Previously the DMA resources for platform devices were being populated through HWMOD, however with the recent clean ups with HWMOD, this data has been moved to Device tree. The EDMA code though is not aware of this so it fails to fetch the DMA resources correctly which it needs to prepare the unused channel list (basically doesn't properly clear the channels that are in use, in the unused list). So that we can learn for next time: What should we (as in us maintainers and you TI) have done differently to avoid this? I think a little on both sides can be improved. For TI, a bit more work toward explaining patches better in change logs so that maintainers understand and are willing to help to get the code upstream would help. A lot of improvement to internal policies have been made for developing on upstream, and that's certainly a good thing but there's still more room for improvement. For maintainers, EDMA code would have been kept breathing all these months (atleast 8 months) if those temporary fixes mentioned above would have been merged into the kernel instead of not applied. With those fixes in place, dts could have been enabled and EDMA would be fully working all these months. This would have certainly made things a lot easier. Rewriting stuff the right way is OK but if it is a _lot_ of effort, then to keep things alive, merging stuff for now specially if they are one-liners could be made acceptable. Joel, can you give a link to the one-liner temporary fix that was was not merged? I am unable to put it in context. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
