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: help regarding Kernel(version 3.6 or above) upgrade for OMAPL138 davinci
On Wednesday 10 September 2014 02:11 PM, Rajkumar Arjunan wrote: > Hi Sekhar, > > Thanks for your reply. > > Host Processor:- OMAP L138 (EVM board) > > I want to use Linux kernel > > TI is providing officially kernel version 3.3 as latest where BLE will not > support. I require minimum kernel version 3.6 or above for BLE(Bluetooth Low > Energy). > > Could you please send me git link for minimum kernel version 3.6 or above > where USB host support (OHCI and MUSB support needed for OMAPL138) bugs were > fixed. Sorry, I haven't really tested OHCI or MUSB on DA850/OMAP-L138 in a while now. OHCI should be in a much better shape than MUSB. The MUSB maintainer marked DA8XX support as BROKEN because it does not build and fixing it requires a proper PHY driver to be written. So MUSB does involve a bunch of work. 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: help regarding Kernel(version 3.6 or above) upgrade for OMAPL138 davinci
On Wednesday 10 September 2014 01:05 PM, Rajkumar Arjunan wrote: > Hi > > > > > > We are using OMAP L138 for our products. Our Linux kernel version is > 3.3(DAVINCI PSP release 03.22.00.06). > > We plan to upgrade our kernel version 3.6 or above ,because we require > full BLE(Bluetooth Low energy) functionally for our products. > > > > Could you please suggest us, the stable kernel version(above 3.6) which > is easy to port, provide git link and documentations. If by "stable" you meant "productized by TI" then no version later than the one you mentioned was productized by TI. You can use the latest stable/longterm kernel available from kernel.org. You will have to upgrade the out of tree portions yourself or ask for help on e2e.ti.com or from your local TI rep. 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 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
[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 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
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 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 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 > --- > 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] 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: # 3.16 > Signed-off-by: Peter Ujfalusi 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/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
>>> ---
>>> 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
>
>
> 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 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
> ---
> 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
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 access not working on 3.15 or git master?
On Monday 16 June 2014 05:10 AM, Peter Howard wrote: > I'm finding that, while the SD driver initialises and the card is > detected, that's where things stop. > > The (cut down) boot log is as follows: > > brd: module loaded > > davinci_mdio davinci_mdio.0: davinci mdio revision 1.5 > > davinci_mdio davinci_mdio.0: detected phy mask fffe > > libphy: davinci_mdio.0: probed > > davinci_mdio davinci_mdio.0: phy[0]: device davinci_mdio-0:00, driver unknown > > input: gpio-keys-polled as /devices/platform/gpio-keys-polled.1/input/input0 > > i2c /dev entries driver > > davinci_mmc da830-mmc.0: Using DMA, 4-bit mode > > TCP: cubic registered > > NET: Registered protocol family 17 > > LDO2: incomplete constraints, leaving on > > LDO1: incomplete constraints, leaving on > > VDCDC3: incomplete constraints, leaving on > > VDCDC2: incomplete constraints, leaving on > > VDCDC1: incomplete constraints, leaving on > > console [netcon0] enabled > > netconsole: network logging started > > davinci_emac davinci_emac.1: using random MAC addr: 66:e9:e3:43:07:13 > > mmc0: new high speed SDHC card at address 0007 > > drivers/rtc/hctosys.c: unable to open rtc device (rtc0) > > net eth0: Request IRQ 33 > > net eth0: Request IRQ 34 > > net eth0: Request IRQ 35 > > net eth0: Request IRQ 36 > > davinci_mdio davinci_mdio.0: resetting idled controller > > net eth0: attached PHY driver [Generic PHY] > (mii_bus:phy_addr=davinci_mdio-0:00) > davinci_emac davinci_emac.1 eth0: Link is Up - 100Mbps/Full - flow control > rx/tx > Sending DHCP requests ., OK > > IP-Config: Got DHCP answer from 192.168.1.17, my address is 192.168.0.150 > > IP-Config: Complete: > > device=eth0, hwaddr=66:e9:e3:43:07:13, ipaddr=192.168.0.150, > mask=255.255.4 > host=192.168.0.150, domain=gme.net.au, nis-domain=(none) > > bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= > > nameserver0=192.168.1.14, nameserver1=192.168.1.17 > > Waiting for root device /dev/mmcblk0p2... > > random: nonblocking pool is initialized > > > I haven't done any further debugging yet to see what happens (or doesn't > happen) after > > mmc0: new high speed SDHC card at address 0007 > > > > The build sequence was: > * tar xf linux-3.15.tar.xz > * cd linux-3.15 > * cp arch/arm/configs/davinci_all_defconfig .config > * make ARCH=arm CROSS_COMPILE=arm-arago-linux-gnueabi- menuconfig > (only change was to make MMC/SD support and the relevant driver > built-in instead of in a module) > * make ARCH=arm LOADADDR=0xc0008000 > CROSS_COMPILE=arm-arago-linux-gnueabi- uImage -j9 > > The image was then copied to the SD card and then booted. I'm assuming > that it *should* work. The same process on the master branch of the > repo at git.kernel.org produces the same behavior. Can you make sure CONFIG_MMC_BLOCK=y in .config? If that does not help, can you check the output of /proc/interrupts. Do you see EDMA interrupts incrementing? Also, just to rule out other issues, can you build with CONFIG_TI_EDMA=n? This will force the driver into PIO mode. Switching on CONFIG_MMC_DEBUG might also help throw more light on what the issue is. 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 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
[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
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 > Signed-off-by: Murali Karicheri I tested this on a DA850 using i2cdetect and it did not seem to break anything so: Tested-by: Sekhar Nori 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 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 wrote:
>>> On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote:
>>>> Hi,
>>>>
>>>> On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman 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 : []lr : []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 :
/*
* 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 : []lr : []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
[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
Helped-by: George Cherian
Signed-off-by: Sekhar Nori
---
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 02:46 PM, Prabhakar Lad wrote: > Hi Sekhar, > > On Tue, May 20, 2014 at 1:43 PM, Sekhar Nori wrote: >> On Tuesday 20 May 2014 12:49 PM, Prabhakar Lad wrote: >>> Hi, >>> >>> On Tue, May 20, 2014 at 12:08 AM, Kevin Hilman 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
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 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: [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
> ---
> 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 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 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: [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 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: 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 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 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 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 >>> Acked-by: Joel Fernandes >>> Tested-by: Jon Ringle >>> Tested-by: Alexander Holler >>> Reported-by: Jon Ringle >>> Signed-off-by: Sekhar Nori >> >> 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: 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
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 > Acked-by: Joel Fernandes > Tested-by: Jon Ringle > Tested-by: Alexander Holler > Reported-by: Jon Ringle > Signed-off-by: Sekhar Nori 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: [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 >>>>> >>>>> Acked-by: Sekhar Nori >>>>> >>>>>> --- >>>>>> 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: [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 >> >> Acked-by: Sekhar Nori >> >>> --- >>> 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 07/14] arm: common: edma: API to request non default queue for a channel
On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
> When using eDMA3 via dmaengine all dma channels will use the default queue.
> Since during request time we do not have means to change this it need to be
> done
> later, before the DMA has been started.
> With the added function it is possible to move the channel to a non default
> queue if it is possible, otherwise (when only one EQ/TC is available for the
> CC)
> the default queue is going to be used.
> For example: For optimal system performance the audio (cyclic) DMA should
> be placed to a separate queue which is different than what the rest of the
> system is using.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/common/edma.c | 27 +++
> include/linux/platform_data/edma.h | 2 ++
> 2 files changed, 29 insertions(+)
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index be267b2080be..eaf6dd19f082 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -712,6 +712,33 @@ int edma_alloc_channel(int channel,
> }
> EXPORT_SYMBOL(edma_alloc_channel);
>
> +/**
> + * edma_request_non_default_queue - try to map the channel to non default
> queue
> + * @channel: dma channel returned from edma_alloc_channel()
> + *
> + * For certain type of applications like audio it is preferred to not use the
> + * default event queue/tc to avoid eDMA caused latency.
> + *
> + * This function will iterate through the event queues available for the CC
> and
> + * picks the first EQ/TC which is not set as the default for the CC
> + */
> +void edma_request_non_default_queue(int channel)
> +{
> + unsigned ctlr = EDMA_CTLR(channel);
> + enum dma_event_q eventq_no = EVENTQ_DEFAULT;
> + int i;
> +
> + for (i = 0; i < edma_cc[ctlr]->num_tc; i++) {
> + if (i != edma_cc[ctlr]->default_queue) {
> + eventq_no = i;
> + break;
> + }
> + }
> +
> + channel = EDMA_CHAN_SLOT(channel);
> + map_dmach_queue(ctlr, channel, eventq_no);
> +}
> +EXPORT_SYMBOL(edma_request_non_default_queue);
With this API, the caller cannot be sure of what the final affect on the
channel will be. It depends a lot on what the default queue setting is.
And that can change independent of this API.
I am not an expert in dmaengine, but it looks like we are trying to
workaround the fact that dmaengine does not support multiple transfer
priorities for a dma_chan. If yes, it will be better to add support for
doing this in dmaengine core itself. A generic priority space could be
supported which each DMA device can then map to its hardware support.
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 Acked-by: Sekhar Nori > --- > 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: 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
> Cc: Kevin Hilman
> Cc: Hans de Goede
> Signed-off-by: Bartlomiej Zolnierkiewicz
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
#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->
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 > 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 > Acked-by: Sekhar Nori > Cc: Kevin Hilman > Cc: davinci-linux-open-source@linux.davincidsp.com Acked-by: Sekhar Nori 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
On Thursday 20 March 2014 06:27 PM, Bartlomiej Zolnierkiewicz wrote:
>>> diff --git a/drivers/ata/ahci_da850.c b/drivers/ata/ahci_da850.c
>>> +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?
>
> This is problematic because it is system resource not particular device
> resource. I would prefer to wait with fixing it until the conversion to
> the device tree.
The way you have it now, module build will fail because the symbol isn't
exported from platform code (and it should not be). The register is
"system level" but it is SATA specific and I see no problem in passing
it to the driver.
Conversion to device tree will not change anything until we throw out
the platform device code. That may or may not ever happen.
>>> +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.
>
> Could you please elaborate a bit more on this?
I meant using pm_runtime_get_sync() to enable the clocks. There are many
examples in the kernel. drivers/watchdog/omap_wdt.c is one.
Documentation is available in Documentation/power/runtime_pm.txt
>>> +static struct platform_device_id ahci_da850_platform_ids[] = {
>>> + { .name = "ahci" },
>>
>> I was not able to get this driver probed with this name (I guess that
>> was because the generic driver was picked instead?). Can you please
>
> Yes, the generic driver should be disabled to use this one.
>> change it to "da850-sata"?
>
> I prefer to remove the ids table (so the "ahci_da850" driver name is
> used) and update the platform device name accordingly. This would also
> allow me to remove the old ahci_platform_data code in this patch.
>
> Is this OK with you?
Fine with me. Sounds good.
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 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 > Cc: Sekhar Nori > Cc: Kevin Hilman > Cc: davinci-linux-open-source@linux.davincidsp.com Acked-by: Sekhar Nori 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 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
Much better! Please feel free to add
Acked-by: Sekhar Nori
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
[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 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
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
>>> Cc: Sekhar Nori
>>> Cc: Kevin Hilman
>>> 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 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
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
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#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 = __raw_readl(D
Re: [PATCH] dma: edma: fix incorrect SG list handling
On Wednesday 19 March 2014 10:09 AM, Sekhar Nori wrote: > On Wednesday 19 March 2014 12:16 AM, Joel Fernandes wrote: >> On 03/18/2014 10:28 AM, Vinod Koul wrote: >>> where is this patch, somehow am not able to find in my inbox or archives... >>> >> >> I found it archived here: >> http://comments.gmane.org/gmane.linux.davinci/28569 >> >> Patch doesn't breaking anything for > MAX_NR_SG list size on AM335x, so >> it looks good. >> >> Acked-by: Joel Fernandes > > Joel, thanks for the ack. > > Vinod, Looks like the vger and Intel spam filters dropped the patch. I > will try again. Okay, I see see the patch in dmaengine list archives now and hopefully it has reached Vinod too. I think the issue last time around was that From: and Return-Path: headers ended up having different addresses. 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 1/1] 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
Acked-by: Joel Fernandes
Tested-by: Jon Ringle
Tested-by: Alexander Holler
Reported-by: Jon Ringle
Signed-off-by: Sekhar Nori
---
Same as the version send previously (which did not make
into all mailing lists). Commit message updates with
tested-by and acks received.
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
On Wednesday 19 March 2014 12:16 AM, Joel Fernandes wrote: > On 03/18/2014 10:28 AM, Vinod Koul wrote: >> where is this patch, somehow am not able to find in my inbox or archives... >> > > I found it archived here: > http://comments.gmane.org/gmane.linux.davinci/28569 > > Patch doesn't breaking anything for > MAX_NR_SG list size on AM335x, so > it looks good. > > Acked-by: Joel Fernandes Joel, thanks for the ack. Vinod, Looks like the vger and Intel spam filters dropped the patch. I will try again. 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
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 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 > > 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] 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 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 >>> --- >>> 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 > > 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 v2] gpio: davinci: fix gpio selection for OF
On Friday 14 March 2014 04:32 PM, Linus Walleij wrote: > On Fri, Mar 14, 2014 at 11:08 AM, Alexander Holler > wrote: >> Am 11.03.2014 11:15, schrieb Linus Walleij: >>> On Wed, Mar 5, 2014 at 12:21 PM, Alexander Holler >>> wrote: >>> The driver missed an of_xlate function to translate gpio numbers as found in the DT to the correct chip and number. While there I've set #gpio_cells to a fixed value of 2. I've used gpio-pxa.c as template for those changes and tested my changes successfully on a da850 board using entries for gpio-leds in a DT. So I didn't reinvent the wheel but just copied and tested stuff. Thanks to Grygorii Strashko for the hint to the existing code in gpio-pxa. Signed-off-by: Alexander Holler Signed-off-by: Grygorii Strashko >>> >>> This v2 version applied, thanks! >> >> Thanks, but actually that should have been a fix for 3.14 with which the >> OF functionality for davinci gpio gets introduced. I assum with the >> patch in for-next, 3.14 will appear with that functionality broken and >> it will become a candidate for -stable. > > I just get the impression that DT support for DaVinci in v3.14 is so risky > and unstable that noone except those implementing it (i.e. you) is really > using it, is that correct? > > In that case it is hardly a fix that we need to rush out to the entire world. 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. 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] 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: # v3.12.x+ >> Cc: Joel Fernandes >> Reported-by: Jon Ringle >> Signed-off-by: Sekhar Nori >> --- >> 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
[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: # v3.12.x+
Cc: Joel Fernandes
Reported-by: Jon Ringle
Signed-off-by: Sekhar Nori
---
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] 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 > --- > 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 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: [PATCH 0/4] ARM: davinci: remove da8xx_omapl_defconfig
On Wednesday 26 February 2014 12:18 PM, Sekhar Nori wrote: > 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 Queuing these for v3.15 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
On Monday 03 March 2014 03:53 PM, Prabhakar Lad wrote:
> Hi Alexander,
>
> On Sat, Mar 1, 2014 at 6:58 PM, Alexander Holler 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 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 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 --- 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
[PATCH 1/4] ARM: davinci: enable da8xx build concurrently with older devices
Enable da8xx devices to build concurrently with older (traditional) DaVinci devices. Do this by defining multiple zreladdr values and enabling AUTO_ZRELADDR to prevent build regressions. Note that we do not enable AUTO_ZRELADDR in da8xx_omapl_defconfig since it is meant to be removed. Signed-off-by: Sekhar Nori --- arch/arm/configs/davinci_all_defconfig |1 + arch/arm/mach-davinci/Makefile.boot| 20 +++- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/arch/arm/configs/davinci_all_defconfig b/arch/arm/configs/davinci_all_defconfig index ab2f737..8a8379a 100644 --- a/arch/arm/configs/davinci_all_defconfig +++ b/arch/arm/configs/davinci_all_defconfig @@ -34,6 +34,7 @@ CONFIG_AEABI=y CONFIG_LEDS=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_AUTO_ZRELADDR=y CONFIG_PM_RUNTIME=y CONFIG_NET=y CONFIG_PACKET=y diff --git a/arch/arm/mach-davinci/Makefile.boot b/arch/arm/mach-davinci/Makefile.boot index 04a6c4e..4b81601 100644 --- a/arch/arm/mach-davinci/Makefile.boot +++ b/arch/arm/mach-davinci/Makefile.boot @@ -1,13 +1,7 @@ -ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y) -ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y) -$(error Cannot enable DaVinci and DA8XX platforms concurrently) -else - zreladdr-y += 0xc0008000 -params_phys-y := 0xc100 -initrd_phys-y := 0xc080 -endif -else - zreladdr-y += 0x80008000 -params_phys-y := 0x8100 -initrd_phys-y := 0x8080 -endif +zreladdr-$(CONFIG_ARCH_DAVINCI_DA8XX) += 0xc0008000 +params_phys-$(CONFIG_ARCH_DAVINCI_DA8XX) := 0xc100 +initrd_phys-$(CONFIG_ARCH_DAVINCI_DA8XX) := 0xc080 + +zreladdr-$(CONFIG_ARCH_DAVINCI_DMx)+= 0x80008000 +params_phys-$(CONFIG_ARCH_DAVINCI_DMx) := 0x8100 +initrd_phys-$(CONFIG_ARCH_DAVINCI_DMx) := 0x8080 -- 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 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 4/4] ARM: davinci: remove da8xx_omapl_defconfig
Remove da8xx_omapl_defconfig. Use davinci_all_defconfig for da830 and da850 as well. Signed-off-by: Sekhar Nori --- arch/arm/configs/da8xx_omapl_defconfig | 139 1 file changed, 139 deletions(-) delete mode 100644 arch/arm/configs/da8xx_omapl_defconfig diff --git a/arch/arm/configs/da8xx_omapl_defconfig b/arch/arm/configs/da8xx_omapl_defconfig deleted file mode 100644 index 1571bea..000 --- a/arch/arm/configs/da8xx_omapl_defconfig +++ /dev/null @@ -1,139 +0,0 @@ -CONFIG_EXPERIMENTAL=y -# CONFIG_SWAP is not set -CONFIG_SYSVIPC=y -CONFIG_POSIX_MQUEUE=y -CONFIG_IKCONFIG=y -CONFIG_IKCONFIG_PROC=y -CONFIG_LOG_BUF_SHIFT=14 -CONFIG_CGROUPS=y -CONFIG_BLK_DEV_INITRD=y -CONFIG_EXPERT=y -CONFIG_MODULES=y -CONFIG_MODULE_UNLOAD=y -CONFIG_MODULE_FORCE_UNLOAD=y -CONFIG_MODVERSIONS=y -# CONFIG_BLK_DEV_BSG is not set -# CONFIG_IOSCHED_DEADLINE is not set -# CONFIG_IOSCHED_CFQ is not set -CONFIG_ARCH_DAVINCI=y -CONFIG_ARCH_DAVINCI_DA830=y -CONFIG_ARCH_DAVINCI_DA850=y -CONFIG_MACH_DA8XX_DT=y -CONFIG_MACH_MITYOMAPL138=y -CONFIG_MACH_OMAPL138_HAWKBOARD=y -CONFIG_DAVINCI_RESET_CLOCKS=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y -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_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 -CONFIG_UNIX=y -CONFIG_INET=y -CONFIG_IP_PNP=y -CONFIG_IP_PNP_DHCP=y -# CONFIG_INET_LRO is not set -CONFIG_NETFILTER=y -CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" -CONFIG_DEVTMPFS=y -CONFIG_DEVTMPFS_MOUNT=y -# CONFIG_FW_LOADER is not set -CONFIG_BLK_DEV_LOOP=m -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_COUNT=1 -CONFIG_BLK_DEV_RAM_SIZE=32768 -CONFIG_EEPROM_AT24=y -CONFIG_SCSI=m -CONFIG_BLK_DEV_SD=m -CONFIG_NETDEVICES=y -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_NETDEV_1000 is not set -# CONFIG_NETDEV_1 is not set -CONFIG_NETCONSOLE=y -CONFIG_NETPOLL_TRAP=y -CONFIG_INPUT_MOUSEDEV=m -CONFIG_INPUT_EVDEV=m -CONFIG_INPUT_EVBUG=m -CONFIG_KEYBOARD_ATKBD=m -CONFIG_KEYBOARD_GPIO=y -CONFIG_KEYBOARD_XTKBD=m -# CONFIG_INPUT_MOUSE is not set -CONFIG_INPUT_TOUCHSCREEN=y -CONFIG_SERIO_LIBPS2=y -# CONFIG_VT_CONSOLE is not set -CONFIG_SERIAL_8250=y -CONFIG_SERIAL_8250_CONSOLE=y -CONFIG_SERIAL_8250_NR_UARTS=3 -CONFIG_SERIAL_OF_PLATFORM=y -CONFIG_I2C=y -CONFIG_I2C_CHARDEV=y -CONFIG_I2C_DAVINCI=y -CONFIG_PINCTRL_SINGLE=y -# CONFIG_HWMON is not set -CONFIG_WATCHDOG=y -CONFIG_REGULATOR=y -CONFIG_REGULATOR_DUMMY=y -CONFIG_REGULATOR_TPS6507X=y -CONFIG_FB=y -CONFIG_FB_DA8XX=y -# CONFIG_VGA_CONSOLE is not set -CONFIG_FRAMEBUFFER_CONSOLE=y -CONFIG_LOGO=y -CONFIG_SOUND=m -CONFIG_SND=m -CONFIG_SND_SOC=m -CONFIG_SND_DAVINCI_SOC=m -# CONFIG_HID_SUPPORT is not set -# CONFIG_USB_SUPPORT is not set -CONFIG_DMADEVICES=y -CONFIG_TI_EDMA=y -CONFIG_EXT2_FS=y -CONFIG_EXT3_FS=y -CONFIG_XFS_FS=m -CONFIG_INOTIFY=y -CONFIG_AUTOFS4_FS=m -CONFIG_MSDOS_FS=y -CONFIG_VFAT_FS=y -CONFIG_TMPFS=y -CONFIG_CRAMFS=y -CONFIG_MINIX_FS=m -CONFIG_NFS_FS=y -CONFIG_NFS_V3=y -CONFIG_ROOT_NFS=y -CONFIG_NFSD=m -CONFIG_NFSD_V3=y -CONFIG_SMB_FS=m -CONFIG_PARTITION_ADVANCED=y -CONFIG_NLS_CODEPAGE_437=y -CONFIG_NLS_ASCII=m -CONFIG_NLS_ISO8859_1=y -CONFIG_NLS_UTF8=m -CONFIG_DEBUG_FS=y -CONFIG_DEBUG_KERNEL=y -CONFIG_TIMER_STATS=y -CONFIG_DEBUG_RT_MUTEXES=y -CONFIG_DEBUG_MUTEXES=y -# CONFIG_RCU_CPU_STALL_DETECTOR is not set -CONFIG_DEBUG_USER=y -CONFIG_DEBUG_ERRORS=y -# CONFIG_CRYPTO_ANSI_CPRNG is not set -# CONFIG_CRYPTO_HW is not set -CONFIG_CRC_CCITT=m -CONFIG_CRC_T10DIF=m -- 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 3/4] ARM: davinci: da8xx: fix multiple watchdog device registration
Fix multiple watchdog device registration on da8xx devices
due to davinci_init_devices blindly registering watchdog
device.
Fix this by getting rid of the initcall and instead registering
watchdog for each soc.
Signed-off-by: Sekhar Nori
---
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 +++-
6 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 2eebc43..4ffc37a 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -79,6 +79,8 @@ int davinci_gpio_register(struct resource *res, int size,
void *pdata);
#define DM646X_ASYNC_EMIF_CONTROL_BASE 0x20008000
#define DM646X_ASYNC_EMIF_CS2_SPACE_BASE 0x4200
+int davinci_init_wdt(void);
+
/* DM355 function declarations */
void dm355_init(void);
void dm355_init_spi0(unsigned chipselect_mask,
diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
index 5cf9a02..6257aa4 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -313,9 +313,9 @@ void davinci_restart(enum reboot_mode mode, const char *cmd)
davinci_watchdog_reset(&davinci_wdt_device);
}
-static void davinci_init_wdt(void)
+int davinci_init_wdt(void)
{
- platform_device_register(&davinci_wdt_device);
+ return platform_device_register(&davinci_wdt_device);
}
static struct platform_device davinci_gpio_device = {
@@ -348,16 +348,3 @@ struct davinci_timer_instance davinci_timer_instance[2] = {
},
};
-/*-*/
-
-static int __init davinci_init_devices(void)
-{
- /* please keep these calls, and their implementations above,
-* in alphabetical order so they're easier to sort through.
-*/
- davinci_init_wdt();
-
- return 0;
-}
-arch_initcall(davinci_init_devices);
-
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index 4668c0e..07381d8 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -1076,12 +1076,18 @@ int __init dm355_init_video(struct vpfe_config
*vpfe_cfg,
static int __init dm355_init_devices(void)
{
+ int ret = 0;
+
if (!cpu_is_davinci_dm355())
return 0;
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
- return 0;
+ ret = davinci_init_wdt();
+ if (ret)
+ pr_warn("%s: watchdog init failed: %d\n", __func__, ret);
+
+ return ret;
}
postcore_initcall(dm355_init_devices);
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index b44b49e..08a61b9 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -1436,6 +1436,8 @@ int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
static int __init dm365_init_devices(void)
{
+ int ret = 0;
+
if (!cpu_is_davinci_dm365())
return 0;
@@ -1445,6 +1447,10 @@ static int __init dm365_init_devices(void)
platform_device_register(&dm365_mdio_device);
platform_device_register(&dm365_emac_device);
- return 0;
+ ret = davinci_init_wdt();
+ if (ret)
+ pr_warn("%s: watchdog init failed: %d\n", __func__, ret);
+
+ return ret;
}
postcore_initcall(dm365_init_devices);
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 5c3e0be..5debffb 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -964,6 +964,8 @@ int __init dm644x_init_video(struct vpfe_config *vpfe_cfg,
static int __init dm644x_init_devices(void)
{
+ int ret = 0;
+
if (!cpu_is_davinci_dm644x())
return 0;
@@ -972,6 +974,10 @@ static int __init dm644x_init_devices(void)
platform_device_register(&dm644x_mdio_device);
platform_device_register(&dm644x_emac_device);
- return 0;
+ ret = davinci_init_wdt();
+ if (ret)
+ pr_warn("%s: watchdog init failed: %d\n", __func__, ret);
+
+ return ret;
}
postcore_initcall(dm644x_init_devices);
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 81768dd..332d00d 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -955,12 +955,18 @@ void __init dm646x_init(void)
static int __init dm646x_init_devices(void)
{
+ int ret = 0;
+
if (!cpu_is_davinci_dm646x())
return 0;
platform_device_register(&dm646x_mdio_device);
platform_device_register(&dm646x_emac_device);
- return 0;
[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 > 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 >> Acked-by: Linus Walleij >> Signed-off-by: Grygorii Strashko >> --- >> 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 > Signed-off-by: Ivan Khoronzhuk > [nsek...@ti.com: fixed checkpatch error and a build breakage due to >missing include, rebased onto l2-mtd/master] > Signed-off-by: Sekhar Nori 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
[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
[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
/ {
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
[PATCH v4 1/1] ARM: davinci: aemif: get rid of davinci-nand driver dependency on aemif
From: Ivan Khoronzhuk
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
Signed-off-by: Ivan Khoronzhuk
[nsek...@ti.com: fixed checkpatch error and a build breakage due to
missing include, rebased onto l2-mtd/master]
Signed-off-by: Sekhar Nori
---
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
#include
+#include
/* 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",
+ ret);
+ return ret;
+ }
+
[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
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 >>>> Cc: Alexandre Courbot >>>> Cc: Sekhar Nori >>>> Cc: Santosh Shilimkar >>>> >>>> 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
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 >> Cc: Alexandre Courbot >> Cc: Sekhar Nori >> Cc: Santosh Shilimkar >> >> 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
[GIT PULL] DaVinci GPIO updates for v3.14
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).
Thanks,
Sekhar
The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:
Linux 3.13-rc4 (2013-12-15 12:31:33 -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/gpio
for you to fetch changes up to 6075a8b2b6c32ddcb99b85189ae41ab2903e560f:
gpio: davinci: don't create irq_domain in case of unbanked irqs (2013-12-26
00:02:12 +0530)
DaVinci GPIO driver updates
---
This pull request contains updates
to DaVinci GPIO driver and the
resultant platform code changes. The
updates include DT-conversion and
changes to make the driver cross-platform
ready.
Grygorii Strashko (4):
gpio: davinci: get rid of DAVINCI_N_GPIO
gpio: introduce GPIO_DAVINCI kconfig option
gpio: davinci: use chained_irq_enter/chained_irq_exit API
gpio: davinci: don't create irq_domain in case of unbanked irqs
KV Sujith (1):
gpio: davinci: add OF support
Lad, Prabhakar (3):
gpio: davinci: use {readl|writel}_relaxed() instead of __raw_*
gpio: davinci: convert to use irqdomain support.
gpio: davinci: remove unused variable intc_irq_num
.../devicetree/bindings/gpio/gpio-davinci.txt | 41 +
arch/arm/mach-davinci/da830.c |1 -
arch/arm/mach-davinci/da850.c |1 -
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 |1 -
drivers/gpio/Kconfig |7 +
drivers/gpio/Makefile |2 +-
drivers/gpio/gpio-davinci.c| 185 ++--
include/linux/platform_data/gpio-davinci.h |3 +-
11 files changed, 177 insertions(+), 67 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-davinci.txt
___
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
> Cc: Alexandre Courbot
> Cc: Sekhar Nori
>
> Acked-by: Santosh Shilimkar
> Signed-off-by: Grygorii Strashko
> ---
> 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 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
> Cc: Alexandre Courbot
> Cc: Sekhar Nori
> Cc: devicet...@vger.kernel.org
>
> Acked-by: Santosh Shilimkar
> Signed-off-by: Grygorii Strashko
> ---
> .../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 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 > Cc: Alexandre Courbot > Cc: Sekhar Nori > Cc: devicet...@vger.kernel.org > > Acked-by: Santosh Shilimkar > Signed-off-by: Grygorii Strashko > --- > .../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 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: [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: [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 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 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
>
> 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
> Signed-off-by: Philip Avinash
> Signed-off-by: Lad, Prabhakar
> ---
> 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
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
Signed-off-by: Philip Avinash
Signed-off-by: Lad, Prabhakar
Signed-off-by: Sekhar Nori
---
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: [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 > > Add DT node for Davinci GPIO driver. > > Signed-off-by: KV Sujith > Signed-off-by: Philip Avinash > Signed-off-by: Lad, Prabhakar 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 3/6] gpio: davinci: remove unused variable intc_irq_num
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote: > From: "Lad, Prabhakar" > > 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 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 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"
>
> Signed-off-by: Lad, Prabhakar
> [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
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 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
> wrote:
>> On Wed, Dec 11, 2013 at 6:52 PM, Prabhakar Lad
>> wrote:
>>
>>> From: "Lad, Prabhakar"
>>>
>>> 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
>>> ---
>>> 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
>>
> 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: [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
[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
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
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 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 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 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
