* [RFC PATCH] ARM: OMAP4: ID: Improve features detection and check
From: Santosh Shilimkar @ 2012-11-01 16:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5092A156.4000601@ti.com>
On Thursday 01 November 2012 09:50 PM, ivan.khoronzhuk wrote:
> On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
>> On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
>>> Replaces several flags bearing the same meaning. There is no need
>>> to set flags due to different omap types here, it can be checked
>>> in appropriate places as well.
>>>
>>> Cc: Tony Lindgren <tony@atomide.com>
>>> Cc: Russell King <linux@arm.linux.org.uk>
>>> Cc: linux-omap at vger.kernel.org
>>> Cc: linux-arm-kernel at lists.infradead.org
>>> Cc: linux-kernel at vger.kernel.org
>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>>> ---
>>> arch/arm/mach-omap2/id.c | 25 +++++++------------------
>>> arch/arm/mach-omap2/soc.h | 8 ++------
>>> 2 files changed, 9 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
>>> index cf2362c..3c47a19 100644
>>> --- a/arch/arm/mach-omap2/id.c
>>> +++ b/arch/arm/mach-omap2/id.c
>>> @@ -28,6 +28,9 @@
>>> #include "soc.h"
>>> #include "control.h"
>>>
>>> +#define OMAP4_SILICON_TYPE_STANDARD 0x01
>>> +#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
>>> +
>>> static unsigned int omap_revision;
>>> static const char *cpu_rev;
>>> u32 omap_features;
>>> @@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
>>> {
>>> u32 si_type;
>>>
>>> - if (cpu_is_omap443x())
>>> - omap_features |= OMAP4_HAS_MPU_1GHZ;
>>> -
>>> + si_type =
>>> + (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) >> 16)
>>> & 0x03;
>>>
>>> - if (cpu_is_omap446x()) {
>>> - si_type =
>>> - read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
>>> - switch ((si_type & (3 << 16)) >> 16) {
>>> - case 2:
>>> - /* High performance device */
>>> - omap_features |= OMAP4_HAS_MPU_1_5GHZ;
>>> - break;
>>> - case 1:
>>> - default:
>>> - /* Standard device */
>>> - omap_features |= OMAP4_HAS_MPU_1_2GHZ;
>>> - break;
>>> - }
>>> - }
>>> + if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
>>> + omap_features = OMAP4_HAS_PERF_SILICON;
>>
>> Well the detection isn't for performance/standard but there are some
>> features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
>> where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
>> information is also effused. Have you considered this aspect while
>> creating this patch ?
>>
>> Regards
>> Santosh
>>
>
> I had considered it. There is no dependency on the features.
> DCC usage depends on asked frequency on the fly, not from the features.
> Depending on "performance/standard" feature the available frequencies
> should be chosen in places where they are needed, for example while
> initializing OPPs.
>
You are correct about the way DCC is handled in the clock code. Infact
all these features like L2CACHE, SGX, IVA etc is more for to display
boot messages.
> Currently we have several features while it is only one indeed.
>
1GHz, 1.2GHz, 1.5 GHz are not same since the silicon capability itself
is different.
git blame tells me that Nishant has sent this update so looping him
if above differentiation in boot log helps.
Nishant,
What's your take on removing above freq prints and marking
those silicon as performance silicons as the $subject patch does ?
Regards
Santosh
^ permalink raw reply
* [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: David Miller @ 2012-11-01 16:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351657480-24745-1-git-send-email-Frank.Li@freescale.com>
From: Frank Li <Frank.Li@freescale.com>
Date: Wed, 31 Oct 2012 12:24:40 +0800
> This patch series enables hardware time stamping and a PTP hardware clock
> for mx6 ENET controller.
>
> Frank Li (4):
> net: fec: move fec_enet_private to header file
> ARM: dts: imx6q: Add ENET PTP clock pin and clock source
> ARM: imx6q: Set enet tx reference clk from anatop to support 1588
> FEC: Add time stamping code and a PTP hardware clock
All applied to net-next.
Please make sure your changes are in sync with Ben's PTP/PPS
Kconfig changes of today, and send me any changes if necessary.
^ permalink raw reply
* [PATCH 1/6] arch: Change defconfigs to point to g_mass_storage.
From: Michal Nazarewicz @ 2012-11-01 16:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1211011033170.1762-100000@iolanthe.rowland.org>
> On Wed, 31 Oct 2012, Michal Nazarewicz wrote:
>> --- a/arch/arm/configs/qil-a9260_defconfig
>> +++ b/arch/arm/configs/qil-a9260_defconfig
>> @@ -108,7 +108,6 @@ CONFIG_ROOT_NFS=y
>> CONFIG_NLS_CODEPAGE_437=y
>> CONFIG_NLS_CODEPAGE_850=y
>> CONFIG_NLS_ISO8859_1=y
>> -CONFIG_DEBUG_KERNEL=y
>> CONFIG_DEBUG_USER=y
>> CONFIG_DEBUG_LL=y
>> # CONFIG_CRYPTO_HW is not set
On Thu, Nov 01 2012, Alan Stern wrote:
> This seems to have crept in by mistake.
Yes, obviously, thanks!
I have updated version prepared, will send it tomorrow in case someone
have some more comments.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Micha? ?mina86? Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/92bca589/attachment.sig>
^ permalink raw reply
* [PATCH net-next V3 00/10] Support the CPTS as a PTP Hardware Clock
From: David Miller @ 2012-11-01 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351535536.git.richardcochran@gmail.com>
All applied to net-next
Ben made some changes today to how PTP/PPS is Kconfig'd etc.
so please make sure your driver is in sync with that.
Thanks.
^ permalink raw reply
* [RFC PATCH] ARM: OMAP4: ID: Improve features detection and check
From: ivan.khoronzhuk @ 2012-11-01 16:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50925E7F.7080602@ti.com>
On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
> On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
>> Replaces several flags bearing the same meaning. There is no need
>> to set flags due to different omap types here, it can be checked
>> in appropriate places as well.
>>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: linux-omap at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
>> ---
>> arch/arm/mach-omap2/id.c | 25 +++++++------------------
>> arch/arm/mach-omap2/soc.h | 8 ++------
>> 2 files changed, 9 insertions(+), 24 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
>> index cf2362c..3c47a19 100644
>> --- a/arch/arm/mach-omap2/id.c
>> +++ b/arch/arm/mach-omap2/id.c
>> @@ -28,6 +28,9 @@
>> #include "soc.h"
>> #include "control.h"
>>
>> +#define OMAP4_SILICON_TYPE_STANDARD 0x01
>> +#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
>> +
>> static unsigned int omap_revision;
>> static const char *cpu_rev;
>> u32 omap_features;
>> @@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
>> {
>> u32 si_type;
>>
>> - if (cpu_is_omap443x())
>> - omap_features |= OMAP4_HAS_MPU_1GHZ;
>> -
>> + si_type =
>> + (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) >> 16)
>> & 0x03;
>>
>> - if (cpu_is_omap446x()) {
>> - si_type =
>> - read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
>> - switch ((si_type & (3 << 16)) >> 16) {
>> - case 2:
>> - /* High performance device */
>> - omap_features |= OMAP4_HAS_MPU_1_5GHZ;
>> - break;
>> - case 1:
>> - default:
>> - /* Standard device */
>> - omap_features |= OMAP4_HAS_MPU_1_2GHZ;
>> - break;
>> - }
>> - }
>> + if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
>> + omap_features = OMAP4_HAS_PERF_SILICON;
>
> Well the detection isn't for performance/standard but there are some
> features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
> where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
> information is also effused. Have you considered this aspect while
> creating this patch ?
>
> Regards
> Santosh
>
I had considered it. There is no dependency on the features.
DCC usage depends on asked frequency on the fly, not from the features.
Depending on "performance/standard" feature the available frequencies
should be chosen in places where they are needed, for example while
initializing OPPs.
Currently we have several features while it is only one indeed.
--
Regards,
Ivan Khoronzhuk
^ permalink raw reply
* [PATCH 0/3] ARM: dts: OMAP4/5 device-tree timer updates
From: Benoit Cousson @ 2012-11-01 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351784967-32520-1-git-send-email-jon-hunter@ti.com>
Hi Jon,
On 11/01/2012 04:49 PM, Jon Hunter wrote:
> A few device tree timer updates for OMAP4/5 devices.
>
> This series adds ...
> 1. MPU private addresses for OMAP4 timers
> 2. Timer nodes for OMAP5
> 3. 32kHz counter node for OMAP5
Great, thanks for that update. Just in time before the pull request.
> This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts
>
> Jon Hunter (3):
> ARM: dts: Update OMAP4 timer addresses
> ARM: dts: Add OMAP5 timer nodes
> ARM: dts: Add OMAP5 counter node
I've just updated slightly the subjects:
3b3132f ARM: dts: OMAP5: Add counter node
df692a9 ARM: dts: OMAP5: Add timer nodes
d03a93b ARM: dts: OMAP4: Update timer addresses
There are now in my for_3.8/dts branch.
Thanks,
Benoit
^ permalink raw reply
* [PATCH] i2c: mxs: remove broken PIOQUEUE support
From: Marek Vasut @ 2012-11-01 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101160828.GA18425@pengutronix.de>
Dear Wolfram Sang,
> On Thu, Nov 01, 2012 at 03:28:17PM +0100, Marek Vasut wrote:
> > Dear Wolfram Sang,
> >
> > > This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally,
> > > only PIOQEUE
> >
> > PIOQUEUE ;-)
>
> Yup, right!
>
> > > was supported, then DMA support was added. The original
> > > intention was to keep PIOQUEUE since it has less overhead what is nice
> > > for small transfers. However, runtime switching between PIOQEUE and DMA
> > > depending on the transfer size never worked despite a lot of trying.
> > > Since PIOQUEUE mode itself was flaky (polling at places where
> > > interrupts failed to work) and the implementation also imposed a size
> > > limit for transfers, it is best to remove the support altogether which
> > > makes the driver a lot cleaner and more robust. If somebody really
> > > wants less overhead, plain PIO mode could still be implemented with
> > > the addidtional advantage that this mode is also available on MX23,
> > > too.
> >
> > Yes, looks to be the way to go.
> >
> > Reviewed-by: Marek Vasut <marex@denx.de>
>
> Thanks.
>
> BTW have you tried combining all i2c-messages (msgs[]) of the transfer
> into one DMA chain? That would reduce overhead, too, no?
Yes, that'd work. But then, you usually don't transfer enough messages to notice
the effect. Implementing PIO transfer for small messages would be much more
beneficial.
Best regards,
Marek Vasut
^ permalink raw reply
* [PATCH] i2c: mxs: remove broken PIOQUEUE support
From: Wolfram Sang @ 2012-11-01 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201211011528.17596.marex@denx.de>
On Thu, Nov 01, 2012 at 03:28:17PM +0100, Marek Vasut wrote:
> Dear Wolfram Sang,
>
> > This I2C master can do DMA and PIOQUEUE (PIO with FIFO). Originally,
> > only PIOQEUE
>
> PIOQUEUE ;-)
Yup, right!
>
> > was supported, then DMA support was added. The original
> > intention was to keep PIOQUEUE since it has less overhead what is nice
> > for small transfers. However, runtime switching between PIOQEUE and DMA
> > depending on the transfer size never worked despite a lot of trying.
> > Since PIOQUEUE mode itself was flaky (polling at places where interrupts
> > failed to work) and the implementation also imposed a size limit for
> > transfers, it is best to remove the support altogether which makes the
> > driver a lot cleaner and more robust. If somebody really wants less
> > overhead, plain PIO mode could still be implemented with the addidtional
> > advantage that this mode is also available on MX23, too.
>
> Yes, looks to be the way to go.
>
> Reviewed-by: Marek Vasut <marex@denx.de>
Thanks.
BTW have you tried combining all i2c-messages (msgs[]) of the transfer
into one DMA chain? That would reduce overhead, too, no?
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/eaefaebd/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc3
From: Mark Jackson @ 2012-11-01 15:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509134A4.708@mimc.co.uk>
On 31/10/12 14:24, Mark Jackson wrote:
> On 31/10/12 13:57, Hiremath, Vaibhav wrote:
>> On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote:
>>>
>>> If I try the latest mainline U-Boot (or the TI branch), I just get to "Starting kernel ..." and then
>>> hangs.
>>>
>>
>>
>> I am using Mainline u-boot and it works for me. Can you paste u-boot boot
>> log and environment variable here?
>
> ------------------------
> mainline U-Boot boot log
> ------------------------
> U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50)
> OMAP SD/MMC: 0
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50)
>
> I2C: ready
> DRAM: 256 MiB
> WARNING: Caches not enabled
> MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
> Using default environment
>
> Net: cpsw
> Hit any key to stop autoboot: 0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> 29 bytes read
> Loaded environment from uEnv.txt
> Importing environment from mmc ...
> 4315695 bytes read
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 80200000 ...
> Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d
> Image Type: ARM Linux Kernel Image (uncompressed)
> Data Size: 4308448 Bytes = 4.1 MiB
> Load Address: 80008000
> Entry Point: 80008000
> Verifying Checksum ... OK
> Loading Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> ------------------------
> Contents of uEnv.txt
> --------------------
> mmcrootfstype=ext2 rootwait
Vaibhav
Does this boot log shed any light on my non-boot problem ?
Are we using the same U-Boot version (2012.10-00434-ged296d2) ?
Can you post your linux-ohporter .config ?
I was also thinking, if the previously mentioned patch [1] was concerning toolchains, what toolchain
are you using ? I'm using the latest mainline Buildroot git, which compiles gcc version 4.5.4
(Buildroot 2012.11-git-00497-ge48bf89).
[1] - http://www.spinics.net/lists/linux-omap/msg79911.html
Cheers
Mark J.
^ permalink raw reply
* [PATCH 3/3] ARM: dts: Add OMAP5 counter node
From: Jon Hunter @ 2012-11-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351784967-32520-1-git-send-email-jon-hunter@ti.com>
Add the 32kHz counter node for OMAP5 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c8954f1..ead74c8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -77,6 +77,12 @@
ranges;
ti,hwmods = "l3_main_1", "l3_main_2", "l3_main_3";
+ counter32k: counter at 4ae04000 {
+ compatible = "ti,omap-counter32k";
+ reg = <0x4ae04000 0x40>;
+ ti,hwmods = "counter_32k";
+ };
+
omap5_pmx_core: pinmux at 4a002840 {
compatible = "ti,omap4-padconf", "pinctrl-single";
reg = <0x4a002840 0x01b6>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: Add OMAP5 timer nodes
From: Jon Hunter @ 2012-11-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351784967-32520-1-git-send-email-jon-hunter@ti.com>
Add the 11 timer nodes for OMAP5 devices.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 89 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 930dbfe..c8954f1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -379,5 +379,94 @@
ti,buffer-size = <128>;
ti,hwmods = "mcbsp3";
};
+
+ timer1: timer at 4ae18000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4ae18000 0x80>;
+ interrupts = <0 37 0x4>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer at 48032000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48032000 0x80>;
+ interrupts = <0 38 0x4>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer at 48034000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48034000 0x80>;
+ interrupts = <0 39 0x4>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer at 48036000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48036000 0x80>;
+ interrupts = <0 40 0x4>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer at 40138000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x40138000 0x80>,
+ <0x49038000 0x80>;
+ interrupts = <0 41 0x4>;
+ ti,hwmods = "timer5";
+ ti,timer-dsp;
+ };
+
+ timer6: timer at 4013a000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4013a000 0x80>,
+ <0x4903a000 0x80>;
+ interrupts = <0 42 0x4>;
+ ti,hwmods = "timer6";
+ ti,timer-dsp;
+ ti,timer-pwm;
+ };
+
+ timer7: timer at 4013c000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4013c000 0x80>,
+ <0x4903c000 0x80>;
+ interrupts = <0 43 0x4>;
+ ti,hwmods = "timer7";
+ ti,timer-dsp;
+ };
+
+ timer8: timer at 4013e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4013e000 0x80>,
+ <0x4903e000 0x80>;
+ interrupts = <0 44 0x4>;
+ ti,hwmods = "timer8";
+ ti,timer-dsp;
+ ti,timer-pwm;
+ };
+
+ timer9: timer at 4803e000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4803e000 0x80>;
+ interrupts = <0 45 0x4>;
+ ti,hwmods = "timer9";
+ };
+
+ timer10: timer at 48086000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48086000 0x80>;
+ interrupts = <0 46 0x4>;
+ ti,hwmods = "timer10";
+ };
+
+ timer11: timer at 48088000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48088000 0x80>;
+ interrupts = <0 47 0x4>;
+ ti,hwmods = "timer11";
+ ti,timer-pwm;
+ };
};
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] ARM: dts: Update OMAP4 timer addresses
From: Jon Hunter @ 2012-11-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351784967-32520-1-git-send-email-jon-hunter@ti.com>
For OMAP4 devices, timers 5-8 have both a L3 bus address and a Cortex-A9
private bus address. Currently the device-tree source only contains the
L3 bus address for these timers. Update these timers to include the
Cortex-A9 private address and make the default address the Cortex-A9
private bus address to match the current HWMOD implementation.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 23ee149..739bb79 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -469,33 +469,37 @@
ti,hwmods = "timer4";
};
- timer5: timer at 49038000 {
+ timer5: timer at 40138000 {
compatible = "ti,omap2-timer";
- reg = <0x49038000 0x80>;
+ reg = <0x40138000 0x80>,
+ <0x49038000 0x80>;
interrupts = <0 41 0x4>;
ti,hwmods = "timer5";
ti,timer-dsp;
};
- timer6: timer at 4903a000 {
+ timer6: timer at 4013a000 {
compatible = "ti,omap2-timer";
- reg = <0x4903a000 0x80>;
+ reg = <0x4013a000 0x80>,
+ <0x4903a000 0x80>;
interrupts = <0 42 0x4>;
ti,hwmods = "timer6";
ti,timer-dsp;
};
- timer7: timer at 4903c000 {
+ timer7: timer at 4013c000 {
compatible = "ti,omap2-timer";
- reg = <0x4903c000 0x80>;
+ reg = <0x4013c000 0x80>,
+ <0x4903c000 0x80>;
interrupts = <0 43 0x4>;
ti,hwmods = "timer7";
ti,timer-dsp;
};
- timer8: timer at 4903e000 {
+ timer8: timer at 4013e000 {
compatible = "ti,omap2-timer";
- reg = <0x4903e000 0x80>;
+ reg = <0x4013e000 0x80>,
+ <0x4903e000 0x80>;
interrupts = <0 44 0x4>;
ti,hwmods = "timer8";
ti,timer-pwm;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] ARM: dts: OMAP4/5 device-tree timer updates
From: Jon Hunter @ 2012-11-01 15:49 UTC (permalink / raw)
To: linux-arm-kernel
A few device tree timer updates for OMAP4/5 devices.
This series adds ...
1. MPU private addresses for OMAP4 timers
2. Timer nodes for OMAP5
3. 32kHz counter node for OMAP5
This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8.
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts
Jon Hunter (3):
ARM: dts: Update OMAP4 timer addresses
ARM: dts: Add OMAP5 timer nodes
ARM: dts: Add OMAP5 counter node
arch/arm/boot/dts/omap4.dtsi | 20 +++++----
arch/arm/boot/dts/omap5.dtsi | 95 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 107 insertions(+), 8 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v4 00/10] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: David Miller @ 2012-11-01 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351690694.git.nicolas.ferre@atmel.com>
From: Nicolas Ferre <nicolas.ferre@atmel.com>
Date: Wed, 31 Oct 2012 17:04:49 +0100
> This is an enhancement work that began several years ago. I try to catchup with
> some performance improvement that has been implemented then by Havard.
> The ring index logic and the TX error path modification are the biggest changes
> but some cleanup/debugging have been added along the way.
> The GEM revision will benefit from the Gigabit support.
> Newer pinctrl infrastructure support is added but it is optional.
>
> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
> flavors.
>
> v4: - remove unneeded device tree header includes
> - modified the computation of available entries in ring buffer
> v3: - rebased on net-next to take into account current effor to merge
> at91_ether with macb drivers
> - add additional patch to use the new pinctrl infrastructure
> v2: - modify the tx error handling: now uses a workqueue
> - information provided by ethtool -i were not accurate: removed
Series applied to net-next
^ permalink raw reply
* [GIT PULL] ARM: tegra: fixes for 3.7-rc4
From: Stephen Warren @ 2012-11-01 15:43 UTC (permalink / raw)
To: linux-arm-kernel
Here we have just a single fix for the Tegra30 pinctrl module's register
range size in device tre.
----------------------------------------------------------------
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git tegra-for-3.7-fixes-for-rc4
for you to fetch changes up to 322337b8fbd8c392246529d5db924820fc0c7381:
ARM: dt: tegra: fix length of pad control and mux registers
----------------------------------------------------------------
Pritesh Raithatha (1):
ARM: dt: tegra: fix length of pad control and mux registers
arch/arm/boot/dts/tegra30.dtsi | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH v5] pwm: vt8500: Update vt8500 PWM driver support
From: Thierry Reding @ 2012-11-01 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351302597-4167-1-git-send-email-linux@prisktech.co.nz>
On Sat, Oct 27, 2012 at 02:49:57PM +1300, Tony Prisk wrote:
> This patch updates pwm-vt8500.c to support devicetree probing and
> make use of the common clock subsystem.
>
> A binding document describing the PWM controller found on
> arch-vt8500 is also included.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> v4:
> return err from clk_enable rather than -EBUSY
> v5:
> replace IS_ERR_OR_NULL with IS_ERR as pointed out by Chris Brand
>
> .../devicetree/bindings/pwm/vt8500-pwm.txt | 17 ++++
> drivers/pwm/pwm-vt8500.c | 86 ++++++++++++++------
> 2 files changed, 80 insertions(+), 23 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
Applied, thanks.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/df148230/attachment.sig>
^ permalink raw reply
* [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge
From: Francesco Lavra @ 2012-11-01 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351698033-8980-2-git-send-email-rajanikanth.hv@linaro.org>
On 10/31/2012 04:40 PM, Rajanikanth H.V wrote:
> From: "Rajanikanth H.V" <rajanikanth.hv@stericsson.com>
>
> - This patch adds device tree support for fuelgauge driver
> - optimize bm devices platform_data usage and of_probe(...)
> Note: of_probe() routine for battery managed devices is made
> common across all bm drivers.
> - test status:
> - interrupt numbers assigned differs between legacy and FDT mode.
>
> Signed-off-by: Rajanikanth H.V <rajanikanth.hv@stericsson.com>
[...]
> +int __devinit
> +bmdevs_of_probe(struct device *dev,
> + struct device_node *np,
> + struct abx500_bm_data **battery)
> +{
> + struct abx500_battery_type *btype;
> + struct device_node *np_bat_supply;
> + struct abx500_bm_data *bat;
> + const char *btech;
> + char bat_tech[8];
> + int i, thermistor;
> +
> + *battery = &ab8500_bm_data;
> +
> + /* get phandle to 'battery-info' node */
> + np_bat_supply = of_parse_phandle(np, "battery", 0);
> + if (!np_bat_supply) {
> + dev_err(dev, "missing property battery\n");
> + return -EINVAL;
> + }
> + if (of_property_read_bool(np_bat_supply,
> + "thermistor-on-batctrl"))
> + thermistor = NTC_INTERNAL;
> + else
> + thermistor = NTC_EXTERNAL;
> +
> + bat = *battery;
> + if (thermistor == NTC_EXTERNAL) {
> + bat->n_btypes = 4;
> + bat->bat_type = bat_type_ext_thermistor;
> + bat->adc_therm = ABx500_ADC_THERM_BATTEMP;
> + }
> + btech = of_get_property(np_bat_supply,
> + "stericsson,battery-type", NULL);
> + if (!btech) {
> + dev_warn(dev, "missing property battery-name/type\n");
> + strcpy(bat_tech, "UNKNOWN");
> + } else {
> + strcpy(bat_tech, btech);
> + }
I don't get the point of declaring the char array and copying the string
in it, when you could simply use just the pointer returned by
of_get_property().
Anyway, if the string property is longer than 8 characters, you are
writing past the size of the destination array.
^ permalink raw reply
* [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
From: Grant Likely @ 2012-11-01 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031193033.GA4164@opensource.wolfsonmicro.com>
On Wed, Oct 31, 2012 at 8:30 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Wed, Oct 31, 2012 at 04:00:17PM +0100, Grant Likely wrote:
>
>> For the API, I don't think it is a good idea at all to try and
>> abstract away gpios on multiple controllers. I understand that it
>> makes life a lot easier for userspace to abstract those details away,
>> but the problem is that it hides very important information about how
>> the system is actually constructed that is important to actually get
>> things to work. For example, say you have a gpio-connected device with
>> the constraint that GPIOA must change either before or at the same
>> time as GPIOB, but never after. If those GPIOs are on separate
>> controllers, then the order is completely undefined, and the user has
>> no way to control that other than to fall back to manipulating GPIOs
>> one at a time again (and losing all the performance benefits). Either
>> controller affinity needs to be explicit in the API, or the API needs
>> to be constraint oriented (ie. a stream of commands and individual
>> commands can be coalesced if they meet the constraints**). Also, the
>> API requires remapping the GPIO numbers which forces the code to be a
>> lot more complex than it needs to be.
>
> It feels like I'm missing something here but can we not simply say that
> if the user cares about the ordering of the signal changes within an
> update then they should be doing two separate updates? Most of the
> cases I'm aware of do things as an update with a strobe or clock that
> latches the values.
>
> The big advantage of grouping things together is that it means that we
> centralise the fallback code.
The internal ABI is less of an issue because it is a whole lot easier
to change compared to a userspace ABI (though I think we can do a lot
better before deciding to merge it). Userspace also appears to be the
intended usage, so I've focused my review on that use case.
g.
^ permalink raw reply
* [PATCH 6/6] pinctrl: sirf: enable the driver support new SiRFmarco SoC
From: Barry Song @ 2012-11-01 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4wqaii9=8C8rXftzjYcPa95_Djf=uOfZZEKV-zz-ky0QQ@mail.gmail.com>
2012/9/28 Barry Song <21cnbao@gmail.com>:
> Hi linus,
> thanks very much!
>
> 2012/9/28 Linus Walleij <linus.walleij@linaro.org>:
>> On Thu, Sep 27, 2012 at 11:56 AM, Barry Song <Barry.Song@csr.com> wrote:
>>
>>> From: Barry Song <Baohua.Song@csr.com>
>>>
>>> The driver supports old up SiRFprimaII SoCs, this patch makes it support
>>> the new SiRFmarco as well.
>>> SiRFmarco, as a SMP SoC, adds new SIRFSOC_GPIO_PAD_EN_CLR registers, to
>>> disable GPIO pad, we should write 1 to the corresponding bit in the new
>>> CLEAR register instead of writing 0 to SIRFSOC_GPIO_PAD_EN.
>>>
>>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>>
>> This doesn't apply to my tree, you must have some other changes that
>> are not included in the patch set...
>>
>> Can you pls try to generate and test the patch against the pinctrl tree?
>>
>> I might apply it as per the "new driver" rule if I can convince myself that it
>> doesn't destabilize the current driver.
>
> this one actually depends on:
>
> http://git.kernel.org/?p=linux/kernel/git/arm/arm-soc.git;a=commitdiff;h=056876f6c73406c06d530d16d020177f5ec4a0bd
> which was applied to arm soc tree.
>
> the only conflict comes from:
> static const struct of_device_id pinmux_ids[] __devinitconst = {
> { .compatible = "sirf,prima2-pinctrl" },
> + { .compatible = "sirf,marco-pinctrl" },
> {}
> };
>
> as commit 056876f6c73406c0 renamed the old
> static const struct of_device_id pinmux_ids[] __devinitconst = {
> { .compatible = "sirf,prima2-gpio-pinmux" },
> {}
> };
> to
> static const struct of_device_id pinmux_ids[] __devinitconst = {
> { .compatible = "sirf,sirf,prima2-pinctrl" },
> {}
> };
>
> so i think the best way is we hold on this patch for the moment, and
> wait for 3.7-rc1.
> all other 5 are critical fixes and have no merge conflict with arm-soc
> tree as i have tried.
Hi Linus,
this one can be applied now. would you apply? as i have tried, now it
can be applied directly againest 3.7-rc3:
barry at barry-VirtualBox:~/development/linux-2.6$ git log
commit 5e0ca7b04ab1a5e4ca778045fdc6b97c1bd2ea3f
Author: Barry Song <Baohua.Song@csr.com>
Date: Thu Sep 27 17:56:30 2012 +0800
pinctrl: sirf: enable the driver support new SiRFmarco SoC
The driver supports old up SiRFprimaII SoCs, this patch makes it support
the new SiRFmarco as well.
SiRFmarco, as a SMP SoC, adds new SIRFSOC_GPIO_PAD_EN_CLR registers, to
disable GPIO pad, we should write 1 to the corresponding bit in the new
CLEAR register instead of writing 0 to SIRFSOC_GPIO_PAD_EN.
Signed-off-by: Barry Song <Baohua.Song@csr.com>
commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Oct 28 12:24:48 2012 -0700
Linux 3.7-rc3
commit 5a5210c6adaddbed823162eb76dfdbac72bdb802
Merge: 8e99165 8bc5e4e
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Oct 28 11:14:52 2012 -0700
>
>> Yours,
>> Linus Walleij
-barry
^ permalink raw reply
* [PATCH 2/3] spi: spidev: Add Rohm DH2228FV DAC compatible string
From: Mark Brown @ 2012-11-01 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351679410-11026-3-git-send-email-maxime.ripard@free-electrons.com>
On Wed, Oct 31, 2012 at 11:30:09AM +0100, Maxime Ripard wrote:
> Since we don't have a driver for it yet, use spidev instead.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/595dcd7c/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] spi: spidev: Add device tree bindings
From: Mark Brown @ 2012-11-01 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351679410-11026-2-git-send-email-maxime.ripard@free-electrons.com>
On Wed, Oct 31, 2012 at 11:30:08AM +0100, Maxime Ripard wrote:
> This will allow to probe spidev from device tree by adding the
> compatible string of each device to this array.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/d637203f/attachment.sig>
^ permalink raw reply
* [PATCH v2] dmaengine: sirf: enable the driver support new SiRFmarco SoC
From: Barry Song @ 2012-11-01 14:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Barry Song <Baohua.Song@csr.com>
The driver supports old up SiRFprimaII SoCs, this patch makes it support
the new SiRFmarco as well.
SiRFmarco, as a SMP SoC, adds new DMA_INT_EN_CLR and DMA_CH_LOOP_CTRL_CLR
registers, to disable IRQ/Channel, we should write 1 to the corresponding
bit in the two CLEAR register.
Tested on SiRFmarco using SPI driver:
$ /mnt/spidev-sirftest -D /dev/spidev32766.0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00
$ cat /proc/interrupts
CPU0 CPU1
32: 1593 0 GIC sirfsoc_timer0
33: 0 3533 GIC sirfsoc_timer1
44: 0 0 GIC sirfsoc_dma
45: 16 0 GIC sirfsoc_dma
47: 6 0 GIC sirfsoc_spi
50: 5654 0 GIC sirfsoc-uart
...
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
v2:
rebase to the next branch of dma-slave tree;
drivers/dma/Kconfig | 4 ++--
drivers/dma/sirf-dma.c | 25 +++++++++++++++++++------
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 6761cc8..0b408bb 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -212,8 +212,8 @@ config TIMB_DMA
Enable support for the Timberdale FPGA DMA engine.
config SIRF_DMA
- tristate "CSR SiRFprimaII DMA support"
- depends on ARCH_PRIMA2
+ tristate "CSR SiRFprimaII/SiRFmarco DMA support"
+ depends on ARCH_SIRF
select DMA_ENGINE
help
Enable support for the CSR SiRFprimaII DMA engine.
diff --git a/drivers/dma/sirf-dma.c b/drivers/dma/sirf-dma.c
index d451caa..b551c8b 100644
--- a/drivers/dma/sirf-dma.c
+++ b/drivers/dma/sirf-dma.c
@@ -32,7 +32,9 @@
#define SIRFSOC_DMA_CH_VALID 0x140
#define SIRFSOC_DMA_CH_INT 0x144
#define SIRFSOC_DMA_INT_EN 0x148
+#define SIRFSOC_DMA_INT_EN_CLR 0x14C
#define SIRFSOC_DMA_CH_LOOP_CTRL 0x150
+#define SIRFSOC_DMA_CH_LOOP_CTRL_CLR 0x15C
#define SIRFSOC_DMA_MODE_CTRL_BIT 4
#define SIRFSOC_DMA_DIR_CTRL_BIT 5
@@ -76,6 +78,7 @@ struct sirfsoc_dma {
struct sirfsoc_dma_chan channels[SIRFSOC_DMA_CHANNELS];
void __iomem *base;
int irq;
+ bool is_marco;
};
#define DRV_NAME "sirfsoc_dma"
@@ -288,13 +291,19 @@ static int sirfsoc_dma_terminate_all(struct sirfsoc_dma_chan *schan)
int cid = schan->chan.chan_id;
unsigned long flags;
- writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
- ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
- writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
-
- writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
- & ~((1 << cid) | 1 << (cid + 16)),
+ if (!sdma->is_marco) {
+ writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_INT_EN) &
+ ~(1 << cid), sdma->base + SIRFSOC_DMA_INT_EN);
+ writel_relaxed(readl_relaxed(sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL)
+ & ~((1 << cid) | 1 << (cid + 16)),
sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL);
+ } else {
+ writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_INT_EN_CLR);
+ writel_relaxed((1 << cid) | 1 << (cid + 16),
+ sdma->base + SIRFSOC_DMA_CH_LOOP_CTRL_CLR);
+ }
+
+ writel_relaxed(1 << cid, sdma->base + SIRFSOC_DMA_CH_VALID);
spin_lock_irqsave(&schan->lock, flags);
list_splice_tail_init(&schan->active, &schan->free);
@@ -568,6 +577,9 @@ static int __devinit sirfsoc_dma_probe(struct platform_device *op)
return -ENOMEM;
}
+ if (of_device_is_compatible(dn, "sirf,marco-dmac"))
+ sdma->is_marco = true;
+
if (of_property_read_u32(dn, "cell-index", &id)) {
dev_err(dev, "Fail to get DMAC index\n");
return -ENODEV;
@@ -668,6 +680,7 @@ static int __devexit sirfsoc_dma_remove(struct platform_device *op)
static struct of_device_id sirfsoc_dma_match[] = {
{ .compatible = "sirf,prima2-dmac", },
+ { .compatible = "sirf,marco-dmac", },
{},
};
--
1.7.1
^ permalink raw reply related
* [PATCH v4 00/10] net/macb: driver enhancement concerning GEM support, ring logic and cleanup
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-01 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1351690694.git.nicolas.ferre@atmel.com>
On 17:04 Wed 31 Oct , Nicolas Ferre wrote:
> This is an enhancement work that began several years ago. I try to catchup with
> some performance improvement that has been implemented then by Havard.
> The ring index logic and the TX error path modification are the biggest changes
> but some cleanup/debugging have been added along the way.
> The GEM revision will benefit from the Gigabit support.
> Newer pinctrl infrastructure support is added but it is optional.
>
> The series has been tested on several Atmel AT91 SoC with the two MACB/GEM
> flavors.
>
> v4: - remove unneeded device tree header includes
> - modified the computation of available entries in ring buffer
> v3: - rebased on net-next to take into account current effor to merge
> at91_ether with macb drivers
> - add additional patch to use the new pinctrl infrastructure
> v2: - modify the tx error handling: now uses a workqueue
> - information provided by ethtool -i were not accurate: removed
>
>
> Havard Skinnemoen (4):
> net/macb: memory barriers cleanup
> net/macb: change debugging messages
> net/macb: clean up ring buffer logic
> net/macb: Offset first RX buffer by two bytes
>
> Jean-Christophe PLAGNIOL-VILLARD (1):
> net/macb: add pinctrl consumer support
>
> Nicolas Ferre (4):
> net/macb: remove macb_get_drvinfo()
> net/macb: tx status is more than 8 bits now
> net/macb: ethtool interface: add register dump feature
> net/macb: better manage tx errors
>
> Patrice Vilchez (1):
> net/macb: Add support for Gigabit Ethernet mode
>
> drivers/net/ethernet/cadence/at91_ether.c | 6 +-
> drivers/net/ethernet/cadence/macb.c | 448 +++++++++++++++++++++---------
> drivers/net/ethernet/cadence/macb.h | 30 +-
> 3 files changed, 337 insertions(+), 147 deletions(-)
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
>
> --
> 1.8.0
>
^ permalink raw reply
* [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-11-01 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6vEr5fd0_ZuzV=nOXVfwA7_FB5L6KJsEwMEHmVj0rDA=g@mail.gmail.com>
On 19:59 Wed 31 Oct , Grant Likely wrote:
> Hi Roland
>
> On Wed, Oct 31, 2012 at 6:19 PM, Roland Stigge <stigge@antcom.de> wrote:
> > On 10/31/2012 04:00 PM, Grant Likely wrote:
> >> For the API, I don't think it is a good idea at all to try and
> >> abstract away gpios on multiple controllers. I understand that it
> >> makes life a lot easier for userspace to abstract those details away,
> >> but the problem is that it hides very important information about how
> >> the system is actually constructed that is important to actually get
> >> things to work. For example, say you have a gpio-connected device with
> >> the constraint that GPIOA must change either before or at the same
> >> time as GPIOB, but never after. If those GPIOs are on separate
> >> controllers, then the order is completely undefined
> >
> > It is correct that it's not (yet) well documented and the API is also
> > not very explicit about it, but the actual approach of the manipulation
> > order is to let drivers handle gpios "as simultaneous as possible" and
> > when not possible, do it in the _order of bits specified_ (either
> > defined at the device tree level, or when created via
> > block_gpio_create() directly).
>
> The documentation is actually fine. I do understand that the intent is
> "as simultaneous as possible", but I accept the point that the order
> of specification affects the behaviour*. However, it still remains
> that the method used by the ABI abstracts at the wrong level and that
> blocking arbitrary GPIO pins into a single virtual GPIO register is a
> bad idea.
>
> *note that the current code doesn't implement that intended behaviour
> either since the gpios are processed in the order of the controllers,
> not the order of the bits.
>
> > I'm not sure how far you tested the API in depth: You can already define
> > a block that maps onto a subset of gpios on a controller and internally
> > of course maps onto those set and clear operations. Whenever you need to
> > manipulate a different subset (whether disjoint or overlapping), you can
> > easily define _additional_ blocks. From my experience, this solves most
> > of the real world problems when n-bit busses are bit banged over GPIOs.
> > Doesn't this already solve this (in a different way, though)?
>
> Blech! Requiring a new block for each possible combination of
> write-at-once bits is a horrible ABI. That just strengthens my opinion
> that the abstraction isn't right yet.
>
> > Pin direction currently needs to be set up separately, analogous to
> > requesting gpios. Need to document this better, right. The assumption is
> > that I/O needs to be efficient primarily, before bloating the API with
> > direction functions. Or should I add functions for this?
>
> Since this is a userspace facing ABI, once it is merged it cannot be
> changed in an incompatible way. I cannot merge it until there is at
> least a plan for how to handle all of the reasonable use cases. That
> means it must support set/clear or mask operations. Also, if it sticks
> with the design of grouping pins from multiple controllers, then it
> needs to handle explicitly constraining what order operations are
> performed in at the time of the operation. At the time of setup
> doesn't work since constraints between pins may not always be in the
> same order.
>
> I really think you should consider implementing a command stream type
> of interface.
I agreed with Grant and I'm not also a fan of the sysfs ABI
as I already point out in the previous version and Linus too
Best Regards,
J.
>
> g.
^ permalink raw reply
* [Patch v2 3/4] ASoC: atmel-ssc-dai: register platform from DAIs
From: Mark Brown @ 2012-11-01 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351668420-18447-3-git-send-email-voice.shen@atmel.com>
On Wed, Oct 31, 2012 at 03:26:59PM +0800, Bo Shen wrote:
> +Required properties:
> + - compatible: "atmel,atmel-ssc-dai"
> + - atmel,dai-master: this dai base on which ssc controller
> +Example:
> +dai: dai {
> + compatible = "atmel,atmel-ssc-dai";
> + atmel,dai-master = <&ssc0>;
> +};
This seems to be a purely virtual device which remaps the SSC onto the
Linux audio subsystem? If that is the case then it shouldn't appear in
the device tree, the machine driver should just directly reference the
SSC and instantiate any devices required in Linux directly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121101/daf7cdde/attachment-0001.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox