On 10.11.16 18:37, Grygorii Strashko wrote:
On 11/09/2016 05:56 PM, Ivan Khoronzhuk wrote:
On 09.11.16 23:09, Grygorii Strashko wrote:
On 11/08/2016 07:10 AM, Ivan Khoronzhuk wrote:
The dma ctlr is reseted to 0 while cpdma start, thus cpdma ctlr
I assume this is because
On 10.11.16 18:37, Grygorii Strashko wrote:
On 11/09/2016 05:56 PM, Ivan Khoronzhuk wrote:
On 09.11.16 23:09, Grygorii Strashko wrote:
On 11/08/2016 07:10 AM, Ivan Khoronzhuk wrote:
The dma ctlr is reseted to 0 while cpdma start, thus cpdma ctlr
I assume this is because
On 17.08.16 09:22, Mugunthan V N wrote:
On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:
These ops allow to control number of channels driver is allowed to
work with at cpdma level. The maximum number of channels is 8 for
rx and 8 for tx. In dual_emac mode the h/w channels are
On 17.08.16 09:22, Mugunthan V N wrote:
On Tuesday 16 August 2016 04:55 AM, Ivan Khoronzhuk wrote:
These ops allow to control number of channels driver is allowed to
work with at cpdma level. The maximum number of channels is 8 for
rx and 8 for tx. In dual_emac mode the h/w channels are
On 26.07.16 19:02, Grygorii Strashko wrote:
On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:
On 22.07.16 16:58, Grygorii Strashko wrote:
Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
cpsw_remove()
- cpdma_ctlr_destroy()
- spin_lock_irqsave(>lock,
On 26.07.16 19:02, Grygorii Strashko wrote:
On 07/23/2016 09:24 AM, Ivan Khoronzhuk wrote:
On 22.07.16 16:58, Grygorii Strashko wrote:
Fix deadlock in cpdma_ctlr_destroy() which is triggered now on
cpsw module removal:
cpsw_remove()
- cpdma_ctlr_destroy()
- spin_lock_irqsave(>lock,
On 23.06.16 15:36, Grygorii Strashko wrote:
TI CPDMA currently uses a bitmap for tracking descriptors alloactions
allocations, but The genalloc already handles the same and can be used
as with special memory (SRAM) as with DMA cherent memory chank
(dma_alloc_coherent()). Hence, switch to using
On 23.06.16 15:36, Grygorii Strashko wrote:
TI CPDMA currently uses a bitmap for tracking descriptors alloactions
allocations, but The genalloc already handles the same and can be used
as with special memory (SRAM) as with DMA cherent memory chank
(dma_alloc_coherent()). Hence, switch to using
Hi Paul,
The dmi_remap() is arch dependent function and for mainline used as
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.
The only reason why the bug wasn't
Hi Paul,
The dmi_remap() is arch dependent function and for mainline used as
ioremap_cache for x86, arm..
And only for ia64 as ioremap (where it's same as ioremap_cache). I'm talking
about k4.5.
It's rather bug of dmi_remap than the patch which just use it.
The only reason why the bug wasn't
Hi Ben,
There is no need in this patch for 3.2, only beginning from 3.19.
SMBIOSv3 is absent in k3.2, and for previous SMBIOS versions 16-bit dmi len
is enough. It should had been mentioned in the commit/code, sorry.
On 05.05.15 04:16, Ben Hutchings wrote:
3.2.69-rc1 review patch. If anyone
Hi Ben,
There is no need in this patch for 3.2, only beginning from 3.19.
SMBIOSv3 is absent in k3.2, and for previous SMBIOS versions 16-bit dmi len
is enough. It should had been mentioned in the commit/code, sorry.
On 05.05.15 04:16, Ben Hutchings wrote:
3.2.69-rc1 review patch. If anyone
Sorry sent it from wrong address, just don't have access to linaro mailbox,
at least for now.
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi, Jean
On 26.04.15 23:47, Jean Delvare wrote:
The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker,
Hi, Jean
On 26.04.15 23:47, Jean Delvare wrote:
The SMBIOS v3 entry points specify a maximum length for the DMI table,
not the exact length. Thus there may be garbage after the end-of-table
marker, which we don't want to export to user-space. Adjust dmi_len
when we find the end-of-table marker,
Sorry sent it from wrong address, just don't have access to linaro mailbox,
at least for now.
--
Regards,
Ivan Khoronzhuk
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Jean,
On 21.04.15 18:36, Jean Delvare wrote:
Hi again Ivan,
On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:
+ bin_attr_DMI.size = dmi_len;
+ bin_attr_DMI.private = dmi_table;
+ ret = sysfs_create_bin_file(tables_kobj, _attr_DMI);
+ if (!ret)
+
Hi Jean,
On 21.04.15 17:24, Jean Delvare wrote:
Hi Ivan,
On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But
Hi Jean,
On 21.04.15 17:24, Jean Delvare wrote:
Hi Ivan,
On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But
Jean,
On 21.04.15 18:36, Jean Delvare wrote:
Hi again Ivan,
On Mon, 20 Apr 2015 13:19:46 +0300, Ivan Khoronzhuk wrote:
+ bin_attr_DMI.size = dmi_len;
+ bin_attr_DMI.private = dmi_table;
+ ret = sysfs_create_bin_file(tables_kobj, bin_attr_DMI);
+ if (!ret)
+
Hi Jean,
On 17.04.15 13:11, Ivan.khoronzhuk wrote:
On 17.04.15 11:54, Jean Delvare wrote:
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
On 16.04.15 11:35, Jean Delvare wrote:
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
Jean, do you want me to pick
On 17.04.15 11:54, Jean Delvare wrote:
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
On 16.04.15 11:35, Jean Delvare wrote:
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
Jean, do you want me to pick this patch up or are you going to?
Good question, we need
On 17.04.15 11:54, Jean Delvare wrote:
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
On 16.04.15 11:35, Jean Delvare wrote:
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
Jean, do you want me to pick this patch up or are you going to?
Good question, we need
Hi Jean,
On 17.04.15 13:11, Ivan.khoronzhuk wrote:
On 17.04.15 11:54, Jean Delvare wrote:
Hi Ivan,
On Thu, 16 Apr 2015 23:16:59 +0300, Ivan.khoronzhuk wrote:
On 16.04.15 11:35, Jean Delvare wrote:
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
Jean, do you want me to pick
Hi Jean,
On 16.04.15 11:35, Jean Delvare wrote:
Hi Matt,
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
On Thu, 02 Apr, at 03:57:01PM, Ivan Khoronzhuk wrote:
The "dmi_table" function looks like data instance, but it does DMI
table decode. This patch renames it to "dmi_decode_table"
Sorry, sent it from not original mail.
On 16.04.15 20:27, subscivan wrote:
Jean,
On 16.04.15 18:44, Jean Delvare wrote:
Hi Ivan,
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
On 16.04.15 12:52, Jean Delvare wrote:
On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk
Hi Jean,
On 16.04.15 12:52, Jean Delvare wrote:
Hi Ivan,
On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But
Hi Jean,
On 16.04.15 12:52, Jean Delvare wrote:
Hi Ivan,
On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But
Sorry, sent it from not original mail.
On 16.04.15 20:27, subscivan wrote:
Jean,
On 16.04.15 18:44, Jean Delvare wrote:
Hi Ivan,
Le Thursday 16 April 2015 à 15:56 +0300, Ivan.khoronzhuk a écrit :
On 16.04.15 12:52, Jean Delvare wrote:
On Thu, 2 Apr 2015 15:57:02 +0300, Ivan Khoronzhuk
Hi Jean,
On 16.04.15 11:35, Jean Delvare wrote:
Hi Matt,
On Wed, 15 Apr 2015 15:35:30 +0100, Matt Fleming wrote:
On Thu, 02 Apr, at 03:57:01PM, Ivan Khoronzhuk wrote:
The dmi_table function looks like data instance, but it does DMI
table decode. This patch renames it to dmi_decode_table name
On 02.04.15 15:57, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi
+ Roy
On 02.04.15 18:08, Jean Delvare wrote:
Le Thursday 02 April 2015 à 16:02 +0300, Ivan.khoronzhuk a écrit :
Hi Jean,
Sorry for the late reply.
I've send new series
"[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables"
with all last propositions.
Thanks Ivan,
+ Roy
On 02.04.15 18:08, Jean Delvare wrote:
Le Thursday 02 April 2015 à 16:02 +0300, Ivan.khoronzhuk a écrit :
Hi Jean,
Sorry for the late reply.
I've send new series
[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables
with all last propositions.
Thanks Ivan, no problem
On 02.04.15 15:57, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for situation when /dev/mem
usage is disabled, the utils have to use dmi
Hi Jean,
Sorry for the late reply.
I've send new series
"[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables"
with all last propositions.
On 20.03.15 10:16, Jean Delvare wrote:
Hi Ivan,
On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:
On 19.03.15 1
Hi Jean,
Sorry for the late reply.
I've send new series
[Patch 0/3] firmware: dmi_scan: add SBMIOS entry point and DMI tables
with all last propositions.
On 20.03.15 10:16, Jean Delvare wrote:
Hi Ivan,
On Thu, 19 Mar 2015 19:35:34 +0200, Ivan.khoronzhuk wrote:
On 19.03.15 17:30, Jean Delvare
On 26.03.15 15:05, Matt Fleming wrote:
On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:
Matt, I've sent new patch that replaces this one.
"[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs"
It can take a while to go via review.
OK, thanks Ivan. I've dropped commit
On 26.03.15 15:05, Matt Fleming wrote:
On Mon, 16 Mar, at 11:02:29PM, Ivan.khoronzhuk wrote:
Matt, I've sent new patch that replaces this one.
[Patch] firmware: dmi_scan: split dmisubsystem from dmi-sysfs
It can take a while to go via review.
OK, thanks Ivan. I've dropped commit (firmware
On 19.03.15 17:30, Jean Delvare wrote:
Hi Ivan,
Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for
On 10.03.15 11:13, Jean Delvare wrote:
Hi Ivan,
Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.
Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :
On 02/26/2015 11:36 AM, Jean Delvare
On 19.03.15 17:30, Jean Delvare wrote:
Hi Ivan,
Le Monday 16 March 2015 à 22:57 +0200, Ivan Khoronzhuk a écrit :
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's done via /dev/mem. But for
On 10.03.15 11:13, Jean Delvare wrote:
Hi Ivan,
Sorry for the late reply. I think I addressed some points in other
replies already, but for completeness let me reply to this post too.
Le Wednesday 04 March 2015 à 14:30 +0200, Ivan.khoronzhuk a écrit :
On 02/26/2015 11:36 AM, Jean Delvare
On 12.03.15 14:22, Matt Fleming wrote:
On Tue, 2015-03-10 at 10:13 +0100, Jean Delvare wrote:
If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.
Great, thanks.
Ivan, please go ahead and submit a new version,
On 12.03.15 14:22, Matt Fleming wrote:
On Tue, 2015-03-10 at 10:13 +0100, Jean Delvare wrote:
If Matt is OK to get another version,
Let it be smbios_entry_point.
If it's more convenient, it should be changed while it's possible.
Great, thanks.
Ivan, please go ahead and submit a new version,
Hi Jean,
On 03/05/2015 09:46 AM, Jean Delvare wrote:
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
On 02/26/2015 11:41 AM, Jean Delvare wrote:
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0
Hi Jean,
On 03/05/2015 09:46 AM, Jean Delvare wrote:
Hi Ivan,
On Wed, 04 Mar 2015 14:28:20 +0200, Ivan.khoronzhuk wrote:
On 02/26/2015 11:41 AM, Jean Delvare wrote:
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0
Hi Jean,
See reply at v4.
On 02/26/2015 10:50 AM, Jean Delvare wrote:
Hi Ivan, Mark and all,
Le Tuesday 03 February 2015 à 17:48 +0200, Ivan Khoronzhuk a écrit :
On 02/03/2015 04:58 PM, Mark Salter wrote:
On Wed, 2015-01-28 at 14:39 +0200, Ivan Khoronzhuk wrote:
Some utils, like dmidecode
Hi Jean.
On 02/26/2015 11:41 AM, Jean Delvare wrote:
Replying to myself...
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to
On 02/26/2015 11:36 AM, Jean Delvare wrote:
Hi Ivan,
Sorry for the late review.
On Wed, 4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's
On 02/26/2015 11:36 AM, Jean Delvare wrote:
Hi Ivan,
Sorry for the late review.
On Wed, 4 Feb 2015 19:06:03 +0200, Ivan Khoronzhuk wrote:
Some utils, like dmidecode and smbios, need to access SMBIOS entry
table area in order to get information like SMBIOS version, size, etc.
Currently it's
Hi Jean,
See reply at v4.
On 02/26/2015 10:50 AM, Jean Delvare wrote:
Hi Ivan, Mark and all,
Le Tuesday 03 February 2015 à 17:48 +0200, Ivan Khoronzhuk a écrit :
On 02/03/2015 04:58 PM, Mark Salter wrote:
On Wed, 2015-01-28 at 14:39 +0200, Ivan Khoronzhuk wrote:
Some utils, like dmidecode
Hi Jean.
On 02/26/2015 11:41 AM, Jean Delvare wrote:
Replying to myself...
On Thu, 26 Feb 2015 09:50:42 +0100, Jean Delvare wrote:
Please also note that the recently released version 3.0.0 of the SMBIOS
specification introduces a new entry point format, and the firmware is
allowed to
On 12/18/2013 02:13 PM, Sekhar Nori wrote:
On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote:
Hi, Sekhar
This patch is based on "Reuse davinci-nand driver for Keystone arch" series.
The series has passed review at https://lkml.org/lkml/2013/12/17/241
and can be fou
On 12/18/2013 02:13 PM, Sekhar Nori wrote:
On Wednesday 18 December 2013 05:21 PM, ivan.khoronzhuk wrote:
Hi, Sekhar
This patch is based on Reuse davinci-nand driver for Keystone arch series.
The series has passed review at https://lkml.org/lkml/2013/12/17/241
and can be found at http
On 12/05/2013 08:11 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
On 12/18/2013 09:14 AM, Brian Norris wrote:
On Tue, Dec 17, 2013 at 02:59:06PM +0200, Ivan Khoronzhuk wrote:
This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.
v3..v4:
- mtd: nand: davinci: fix driver registration
dropped
On 12/18/2013 09:14 AM, Brian Norris wrote:
On Tue, Dec 17, 2013 at 02:59:06PM +0200, Ivan Khoronzhuk wrote:
This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.
v3..v4:
- mtd: nand: davinci: fix driver registration
dropped
On 12/05/2013 08:11 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
On 12/17/2013 10:50 AM, Brian Norris wrote:
> On Thu, Dec 05, 2013 at 07:25:55PM +0200, Ivan Khoronzhuk wrote:
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -558,6 +557,8 @@ static struct davinci_nand_pdata
>>
On 12/17/2013 10:42 AM, Brian Norris wrote:
On Thu, Dec 05, 2013 at 07:25:57PM +0200, Ivan Khoronzhuk wrote:
The TI AEMIF driver registers are used to setup timings for each chip
select. The same registers range is used to setup NAND settings.
The AEMIF and NAND drivers not use the same
On 12/17/2013 11:24 AM, Brian Norris wrote:
> On Thu, Dec 05, 2013 at 07:25:49PM +0200, Ivan Khoronzhuk wrote:
>> --- a/drivers/mtd/nand/davinci_nand.c
>> +++ b/drivers/mtd/nand/davinci_nand.c
>> @@ -877,6 +877,7 @@ static int __exit nand_davinci_remove(struct
>> platform_device *pdev)
>> }
>>
On 12/17/2013 11:24 AM, Brian Norris wrote:
On Thu, Dec 05, 2013 at 07:25:49PM +0200, Ivan Khoronzhuk wrote:
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -877,6 +877,7 @@ static int __exit nand_davinci_remove(struct
platform_device *pdev)
}
static
On 12/17/2013 10:42 AM, Brian Norris wrote:
On Thu, Dec 05, 2013 at 07:25:57PM +0200, Ivan Khoronzhuk wrote:
The TI AEMIF driver registers are used to setup timings for each chip
select. The same registers range is used to setup NAND settings.
The AEMIF and NAND drivers not use the same
On 12/17/2013 10:50 AM, Brian Norris wrote:
On Thu, Dec 05, 2013 at 07:25:55PM +0200, Ivan Khoronzhuk wrote:
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -558,6 +557,8 @@ static struct davinci_nand_pdata
ti,davinci-mask-chipsel, prop))
+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org
On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:
After Keystone watchdog driver updates are already merged we can
enable WDT in config.
Signed-off-by: Ivan Khoronzhuk
---
Based on
+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org
On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:
Add watchdog entry to keystone device tree.
Acked-by: Guenter Roeck
Signed-off-by: Ivan Khoronzhuk
---
Based on
On 12/10/2013 01:09 AM, Kumar Gala wrote:
>
> On Nov 26, 2013, at 10:27 AM, Grygorii Strashko
> wrote:
>
>> On 11/22/2013 11:04 PM, Kumar Gala wrote:
>>>
>>> On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk wrote:
>>>
Add bindings for AEMIF controller drivers/memory/ti-aemif.c
>>>
>>>
On 12/10/2013 01:09 AM, Kumar Gala wrote:
On Nov 26, 2013, at 10:27 AM, Grygorii Strashko grygorii.stras...@ti.com
wrote:
On 11/22/2013 11:04 PM, Kumar Gala wrote:
On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk ivan.khoronz...@ti.com wrote:
Add bindings for AEMIF controller
+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org
On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:
Add watchdog entry to keystone device tree.
Acked-by: Guenter Roeck li...@roeck-us.net
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
+ CC
devicet...@vger.kernel.org
linux-arm-ker...@lists.infradead.org
linux-kernel@vger.kernel.org
On 12/10/2013 04:47 PM, Ivan Khoronzhuk wrote:
After Keystone watchdog driver updates are already merged we can
enable WDT in config.
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
On 12/06/2013 11:04 PM, Sekhar Nori wrote:
> On 12/5/2013 11:41 PM, Ivan Khoronzhuk wrote:
>
>> diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
>> b/arch/arm/mach-davinci/board-mityomapl138.c
>> index 7aa105b..98a66ff 100644
>> --- a/arch/arm/mach-davinci/board-mityomapl138.c
>> +++
On 12/06/2013 11:04 PM, Sekhar Nori wrote:
On 12/5/2013 11:41 PM, Ivan Khoronzhuk wrote:
diff --git a/arch/arm/mach-davinci/board-mityomapl138.c
b/arch/arm/mach-davinci/board-mityomapl138.c
index 7aa105b..98a66ff 100644
--- a/arch/arm/mach-davinci/board-mityomapl138.c
+++
On 12/04/2013 08:58 PM, Guenter Roeck wrote:
On Wed, Dec 04, 2013 at 08:42:31PM +0200, ivan.khoronzhuk wrote:
On 12/04/2013 08:28 PM, Guenter Roeck wrote:
On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
To reduce code duplicate
On 12/04/2013 08:28 PM, Guenter Roeck wrote:
> On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
>> On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
>>> To reduce code duplicate and increase code readability use WDT core
>>> code to handle WDT interface.
>>>
>>> Remove io_lock as the WDT
On 11/29/2013 06:38 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 08:01 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
On 11/29/2013 06:38 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 08:01 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
On 12/04/2013 08:28 PM, Guenter Roeck wrote:
On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex
On 12/04/2013 08:58 PM, Guenter Roeck wrote:
On Wed, Dec 04, 2013 at 08:42:31PM +0200, ivan.khoronzhuk wrote:
On 12/04/2013 08:28 PM, Guenter Roeck wrote:
On Wed, Dec 04, 2013 at 11:34:46PM +0530, Sekhar Nori wrote:
On 11/27/2013 6:18 PM, Ivan Khoronzhuk wrote:
To reduce code duplicate
On 11/29/2013 05:10 PM, Santosh Shilimkar wrote:
On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote:
Hi Kumar Gala,
On 11/22/2013 11:06 PM, Kumar Gala wrote:
On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk wrote:
On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote
On 11/29/2013 05:32 PM, Santosh Shilimkar wrote:
> On Wednesday 20 November 2013 10:46 AM, Ivan Khoronzhuk wrote:
>> Add new AEMIF driver for EMIF16 Texas Instruments controller.
>> The EMIF16 module is intended to provide a glue-less interface to
>> a variety of asynchronous memory devices like
On 11/29/2013 06:28 PM, Santosh Shilimkar wrote:
> Ivan,
> On Thursday 21 November 2013 06:28 AM, Ivan Khoronzhuk wrote:
>> This series contains fixes and updates of Davinci nand driver in
>> order to reuse it for Keystone platform.
>>
>> The series is combination of two following series:
>> -
On 11/29/2013 06:28 PM, Santosh Shilimkar wrote:
Ivan,
On Thursday 21 November 2013 06:28 AM, Ivan Khoronzhuk wrote:
This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.
The series is combination of two following series:
- Davinci nand
On 11/29/2013 05:32 PM, Santosh Shilimkar wrote:
On Wednesday 20 November 2013 10:46 AM, Ivan Khoronzhuk wrote:
Add new AEMIF driver for EMIF16 Texas Instruments controller.
The EMIF16 module is intended to provide a glue-less interface to
a variety of asynchronous memory devices like ASRA M,
On 11/29/2013 05:10 PM, Santosh Shilimkar wrote:
On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote:
Hi Kumar Gala,
On 11/22/2013 11:06 PM, Kumar Gala wrote:
On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk ivan.khoronz...@ti.com wrote:
On 11/20/2013 08:21 PM, Jean-Christophe
On 11/29/2013 06:38 AM, Sekhar Nori wrote:
> On Wednesday 27 November 2013 08:01 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
On 11/29/2013 06:38 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 08:01 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
On 11/28/2013 08:04 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 09:27 PM, Guenter Roeck wrote:
On 11/27/2013 06:00 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 07:01 PM, Ivan Khoronzhuk wrote:
As we switch to use the watchdog core which permits more than one
active watchdog
+ CC Santosh Shilimkar
On 11/27/2013 04:31 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
+ CC Santosh Shilimkar
On 11/27/2013 04:31 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
On 11/28/2013 08:04 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 09:27 PM, Guenter Roeck wrote:
On 11/27/2013 06:00 AM, Sekhar Nori wrote:
On Wednesday 27 November 2013 07:01 PM, Ivan Khoronzhuk wrote:
As we switch to use the watchdog core which permits more than one
active watchdog
On 11/27/2013 03:07 PM, Sekhar Nori wrote:
On Wednesday 27 November 2013 04:31 PM, ivan.khoronzhuk wrote:
@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
davinci_cfg_reg(DM644X_ATAEN_DISABLE);
/* only one device will be jumpered and detected
On 11/27/2013 03:33 AM, Brian Norris wrote:
Hi Ivan,
On Thu, Nov 21, 2013 at 01:28:15PM +0200, Ivan Khoronzhuk wrote:
This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.
The series is combination of two following series:
- Davinci nand
On 11/27/2013 10:35 AM, Sekhar Nori wrote:
+ MTD maintainers
On Tuesday 26 November 2013 01:30 AM, 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
On 11/27/2013 02:37 AM, Brian Norris wrote:
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote:
On 11/26/2013 8:35 PM, Santosh Shilimkar wrote:
On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote:
On Monday 11
On 11/27/2013 09:04 AM, Guenter Roeck wrote:
On 11/26/2013 08:31 PM, Sekhar Nori wrote:
On Monday 25 November 2013 07:34 PM, Ivan Khoronzhuk wrote:
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex to
On 11/27/2013 09:04 AM, Guenter Roeck wrote:
On 11/26/2013 08:31 PM, Sekhar Nori wrote:
On Monday 25 November 2013 07:34 PM, Ivan Khoronzhuk wrote:
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex to
On 11/27/2013 02:37 AM, Brian Norris wrote:
On Tue, Nov 26, 2013 at 01:26:44PM -0500, Santosh Shilimkar wrote:
On Tuesday 26 November 2013 12:21 PM, Sekhar Nori wrote:
On 11/26/2013 8:35 PM, Santosh Shilimkar wrote:
On Tuesday 26 November 2013 02:20 AM, Sekhar Nori wrote:
On Monday 11
On 11/27/2013 10:35 AM, Sekhar Nori wrote:
+ MTD maintainers
On Tuesday 26 November 2013 01:30 AM, 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
On 11/27/2013 03:33 AM, Brian Norris wrote:
Hi Ivan,
On Thu, Nov 21, 2013 at 01:28:15PM +0200, Ivan Khoronzhuk wrote:
This series contains fixes and updates of Davinci nand driver in
order to reuse it for Keystone platform.
The series is combination of two following series:
- Davinci nand
On 11/27/2013 03:07 PM, Sekhar Nori wrote:
On Wednesday 27 November 2013 04:31 PM, ivan.khoronzhuk wrote:
@@ -192,9 +193,15 @@ static __init void davinci_ntosd2_init(void)
davinci_cfg_reg(DM644X_ATAEN_DISABLE);
/* only one device will be jumpered and detected
1 - 100 of 182 matches
Mail list logo
