* [PATCH RFC] i2c: omap: Fix the revision register read
From: Shubhrajyoti @ 2012-10-31 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031101201.GB10094@arwen.pp.htv.fi>
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
>> The revision register on OMAP4 is a 16-bit lo and a 16-bit
>> hi. Currently the driver reads only the lower 8-bits.
>> Fix the same by preventing the truncating of the rev register
>> for OMAP4.
> very good, but you need to test this with OMAP2/3/4 (5 ??). How was this
> tested ?
>
>> Also use the scheme bit ie bit-14 of the hi register to know if it
>> is OMAP_I2C_IP_VERSION_2.
>>
>> On platforms previous to OMAP4 the offset 0x04 is IE register whose
>> bit-14 reset value is 0, the code uses the same to its advantage.
>>
>> The dev->regs is populated after reading the rev_hi. A NULL check
>> has been added in the resume handler to prevent the access before
>> the setting of the regs.
> this could get some rephrasing, I guess. At least to me it's difficult
> to understand what you mean :-s
>
>> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
>> ---
>> todo: some of the flag checks can be removed in favour of revision check.
>>
>> drivers/i2c/busses/i2c-omap.c | 35 +++++++++++++++++++++++++----------
>> 1 files changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index db31eae..651a7f7 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -51,7 +51,8 @@
>> /* I2C controller revisions present on specific hardware */
>> #define OMAP_I2C_REV_ON_2430 0x36
>> #define OMAP_I2C_REV_ON_3430_3530 0x3C
>> -#define OMAP_I2C_REV_ON_3630_4430 0x40
>> +#define OMAP_I2C_REV_ON_3630 0x40
>> +#define OMAP_I2C_REV_ON_4430_PLUS 0x5040
> I would rather see a proper decoding of the revision, meaning that you
> would:
>
> For omap2/3:
>
> rev major = rev >> 8;
> rev minor = rev & 0xff;
you mean
rev major = rev >> 4;
rev minor = rev & 0xf;
thats doable too. However that currently that is read together currently.
>
> For OMAP4/5:
>
> well, that's a lot more complex, but you have that data ;-)
>
>> /* timeout waiting for the controller to respond */
>> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>> @@ -202,7 +203,7 @@ struct omap_i2c_dev {
>> * fifo_size==0 implies no fifo
>> * if set, should be trsh+1
>> */
>> - u8 rev;
>> + u16 rev;
> IMHO this should be u32, so you don't need rev_lo and rev_hi below.
>
>> unsigned b_hw:1; /* bad h/w fixes */
>> unsigned receiver:1; /* true when we're in receiver mode */
>> u16 iestate; /* Saved interrupt register */
>> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
>>
>> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
>>
>> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
>> + if (dev->rev < OMAP_I2C_REV_ON_3630)
>> dev->b_hw = 1; /* Enable hardware fixes */
>>
>> /* calculate wakeup latency constraint for MPU */
>> @@ -1064,6 +1065,8 @@ omap_i2c_probe(struct platform_device *pdev)
>> const struct of_device_id *match;
>> int irq;
>> int r;
>> + u16 rev_lo;
>> + u16 rev_hi;
>>
>> /* NOTE: driver uses the static register mapping */
>> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> @@ -1117,11 +1120,6 @@ omap_i2c_probe(struct platform_device *pdev)
>>
>> dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
>>
>> - if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
>> - dev->regs = (u8 *)reg_map_ip_v2;
>> - else
>> - dev->regs = (u8 *)reg_map_ip_v1;
>> -
>> pm_runtime_enable(dev->dev);
>> pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
>> pm_runtime_use_autosuspend(dev->dev);
>> @@ -1130,7 +1128,21 @@ omap_i2c_probe(struct platform_device *pdev)
>> if (IS_ERR_VALUE(r))
>> goto err_free_mem;
>>
>> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> + /* Read the Rev hi bit-14 ie scheme this is 1 indicates ver2 or
>> + * highlander.
> the "scheme" in highlander is a 2 bit value. In order to make this
> future proof, you need to read both bits (31:30).
Good point will fix it.
>
>> + * On omap3 Offset 4 is IE Reg the bit 14 is XDR_IE which is 0 at reset.
>> + */
> please align the * characters.
yes will repost
>
>> + rev_hi = __raw_readw(dev->base + 0x04);
> you should make omap_i2c_read_reg() work fine for this case too.
Just felt it is more readlable this way also I didnt want to use the
reg_shift etc.
which also may get cleaned up sometime.
>
>> +
>> + if (rev_hi & 0x4000) {/* If scheme 1*/
> you should add a symbolic define for scheme, something like:
>
> switch (OMAP_I2C_SCHEME(rev)) {
> case OMAP_I2C_SCHEME_1:
> foo();
> break;
> case OMAP_I2C_SCHEME_2:
> /* FALLTHROUGH */
> default:
> bar();
> }
>
> note that this will also default to highest known scheme if another
> scheme is added. You need to make the driver behave like that to
> decrease amount of rework to support newest OMAPs.
OK.
>
>> + dev->regs = (u8 *)reg_map_ip_v2;
>> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_HI);
>> + rev_lo = omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
>> + dev_info(dev->dev, "the low rev %x\n", rev_lo);
>> + } else {
>> + dev->regs = (u8 *)reg_map_ip_v1;
>> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>> + }
>>
>> dev->errata = 0;
>>
>> @@ -1155,7 +1167,7 @@ omap_i2c_probe(struct platform_device *pdev)
>>
>> dev->fifo_size = (dev->fifo_size / 2);
>>
>> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
>> + if (dev->rev < OMAP_I2C_REV_ON_3630)
>> dev->b_hw = 1; /* Enable hardware fixes */
>>
>> /* calculate wakeup latency constraint for MPU */
>> @@ -1264,6 +1276,9 @@ static int omap_i2c_runtime_resume(struct device *dev)
>> struct platform_device *pdev = to_platform_device(dev);
>> struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
>>
>> + if (!_dev->regs)
>> + return 0;
> this is wrong, you need to make sure dev->regs is set early enough.
^ permalink raw reply
* [PATCH] mmc: s3cmci: use tasklet_kill in device remove/release process
From: Xiaotian Feng @ 2012-10-31 10:48 UTC (permalink / raw)
To: linux-arm-kernel
Some driver uses tasklet_disable in device remove/release process,
tasklet_disable will inc tasklet->count and return. If the tasklet
is not handled yet under some softirq pressure, the tasklet will be
placed on the tasklet_vec, never have a chance to be excuted. This might
lead to a heavy loaded ksoftirqd, wakeup with pending_softirq, but
tasklet is disabled. tasklet_kill should be used in this case.
Signed-off-by: Xiaotian Feng <dannyfeng@tencent.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Chris Ball <cjb@laptop.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mmc at vger.kernel.org
---
drivers/mmc/host/s3cmci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 4638dda..d70d0cc 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -1830,7 +1830,7 @@ static int __devexit s3cmci_remove(struct platform_device *pdev)
clk_put(host->clk);
- tasklet_disable(&host->pio_tasklet);
+ tasklet_kill(&host->pio_tasklet);
if (s3cmci_host_usedma(host))
s3c2410_dma_free(host->dma, &s3cmci_dma_client);
--
1.7.9.5
^ permalink raw reply related
* OMAP baseline test results for v3.7-rc1
From: Kevin Hilman @ 2012-10-31 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAORVsuWqoqrza-qrJskpMTj=2MW6JxNEhVzjWVXkM1mpqVO8cQ@mail.gmail.com>
Hi Jean,
Jean Pihet <jean.pihet@newoldbits.com> writes:
[...]
>> Based on a very quick look, I'd say the original patch 3db11fe is broken.
>> I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is
>> honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for
>> omap2plus_defconfig.
>
> Withtout CPU_IDLE set the PM QoS has no influence on the power domains states.
Exactly, which means there is *no* constraint set when CPUidle is
disabled, and it's exactly this that is different from the behavior
before your patch.
Before your patch, the constraint would be set whether or not CPUidle
was enabled, correct?
The solution to this will probably be to make OMAPs non-CPUidle idle path
check the constraints.
Kevin
^ permalink raw reply
* Two questions about streaming DMA flushing
From: Catalin Marinas @ 2012-10-31 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFNq8R4DMKqRtR7junM6v_NnU=pCi8bpOCf5HP_sQgmztQr-cg@mail.gmail.com>
On 31 October 2012 09:40, Li Haifeng <omycle@gmail.com> wrote:
> 2012/10/31 Catalin Marinas <catalin.marinas@arm.com>:
>> On Wed, Oct 31, 2012 at 02:15:04AM +0000, Li Haifeng wrote:
>>> Sorry to disturb you.
>>>
>>> I have two questions for streaming DMA flushing @ arch/arm/mm/cache-v7.S.
>>>
>>> 1.
>>> 332 ENTRY(v7_dma_map_area)
>>> 333 add r1, r1, r0
>>> 334 teq r2, #DMA_FROM_DEVICE
>>> 335 beq v7_dma_inv_range
>>> 336 b v7_dma_clean_range
>>> 337 ENDPROC(v7_dma_map_area)
>>>
>>> The function of v7_dma_map_area will invalidate corresponding cache line
>>> firstly and then clean the cache for DMA_FROM_DEVICE . I am confused the
>>> sequence of the operations. IMO, the invalidate should be followed by the clean
>>> action. Is it right?
>>
>> If the direction is DMA_FROM_DEVICE, it only invalidates the cache (beq
>> instruction).
>
> Sorry for my careless.
>
> Why doesn't need clean for DMA_FROM_DEVICE? Will the data modified
> before dma mapping be lost?
Yes, that's exactly the point of DMA_FROM_DEVICE, the device is going
to write that buffer anyway.
--
Catalin
^ permalink raw reply
* [PATCH v3] ARM: dts: AM33xx: Add SPI node
From: Philip, Avinash @ 2012-10-31 10:51 UTC (permalink / raw)
To: linux-arm-kernel
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
Tested-by: Matt Porter <mporter@ti.com>
---
Changes since v2:
- Commit message corrected.
- Rebase on top of for_3.8/dts
Changes since v1:
- Corrected reg offset in reg DT entry.
:100644 100644 97a7bd3... 6e04789... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..6e04789 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,29 @@
76>;
ti,hwmods = "rtc";
};
+
+ spi0: spi at 48030000 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x48030000 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <65>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi0";
+ status = "disabled";
+ };
+
+ spi1: spi at 481a0000 {
+ compatible = "ti,omap4-mcspi";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x481a0000 0x400>;
+ interrupt-parent = <&intc>;
+ interrupt = <125>;
+ ti,spi-num-cs = <2>;
+ ti,hwmods = "spi1";
+ status = "disabled";
+ };
};
};
--
1.7.0.4
^ permalink raw reply related
* [GIT PULL] ARM: OMAP: more hwmod/PRCM fixes for 3.7-rc
From: Paul Walmsley @ 2012-10-31 10:51 UTC (permalink / raw)
To: linux-arm-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Tony
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-3.7-rc
for you to fetch changes up to 945365c4da8c29bbb0109a728e6dca691d78a5de:
ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init (2012-10-29 22:13:44 -0600)
- ----------------------------------------------------------------
A few more OMAP fixes for the 3.7-rc timeframe. Mostly hwmod fixes.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/fixes_b_v3.7-rc/20121029222655/
However the v3.7-rc3 kernel is still missing fixes for several regressions,
which cause several tests to fail. With several reverts, fixes, and workarounds
applied, the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/TEST_fixes_b_v3.7-rc/20121030185805/
which indicate that the series tests cleanly.
- ----------------------------------------------------------------
vmlinux object size
(delta in bytes from test_v3.7-rc3 (8f0d8163b50e01f398b14bcd4dc039ac5ab18d64)):
text data bss total kernel
-108 -8 0 -116 am33xx_only
+56 +16 0 +72 n800_multi_omap2xxx
+20 +16 0 +36 n800_only_a
0 0 0 0 omap1_defconfig
0 0 0 0 omap1_defconfig_1510innovator_only
0 0 0 0 omap1_defconfig_5912osk_only
-92 -16 0 -108 omap2plus_defconfig
-96 -8 0 -104 omap2plus_defconfig_2430sdp_only
-92 +16 0 -76 omap2plus_defconfig_cpupm
-92 -16 0 -108 omap2plus_defconfig_no_pm
-92 +16 0 -76 omap2plus_defconfig_omap2_4_only
-172 +16 0 -156 omap2plus_defconfig_omap3_4_only
+12 +16 0 +28 rmk_omap3430_ldp_oldconfig
+44 +24 0 +68 rmk_omap4430_sdp_oldconfig
Miguel Vadillo (1):
ARM: OMAP2+: clockdomain: Fix OMAP4 ISS clk domain to support only SWSUP
Paul Walmsley (2):
ARM: OMAP2+: hwmod: add flag to prevent hwmod code from touching IP block during init
ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
Tero Kristo (1):
ARM: OMAP: hwmod: wait for sysreset complete after enabling hwmod
arch/arm/mach-omap2/clockdomains44xx_data.c | 2 +-
arch/arm/mach-omap2/omap_hwmod.c | 59 ++++++++++++++++++++------
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 8 ++++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 6 +++
4 files changed, 60 insertions(+), 15 deletions(-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBAgAGBQJQkQIvAAoJEMePsQ0LvSpLjvAP/A6xnRpJsqr6do1SDRfCb3G+
xh+Cem5AkkGnhlQ1VFAyMqxAoVytZjjBxkq/UyJEFcnuQP7hV3DZtNLFyp9A3NlG
WZDHvwUZmmWA7adqRLQ9DwXnlxx4JPrdaCHLCwBoqSFOR1De6oxqPY5KSNy5CoTL
D55b0Yb+BH/Z6KMr6NQi8H0Vp3wE0tAAVxoUJ6SPSHgJOW/cqLAwzSdhiUWvfDMP
nFBfPGDWC+lju3RgUM034f632zm9mC1xhtM6Y+5eHerHZgedo3eaZyGOpzZOpLeT
bOKIoA3xelZ9AsgYT8FowRwWpP+XN+vkSccOU/n8LKdkpmfllp9J6vicoqtyMGMA
qoyu7Y63DMOWbzvHqJbVBmWAMviDd3tPzCAPZpEqPmn0+8+mC037KnYyuMiPX7dC
LdOqtIKYnXrk+vi7ukdzwJRMkAfCY2FOsjg4WiUqkeDS2ZSETLFm/aJyTdeHGKux
h4mixvJ/h1rGHVc6U9gp53QlMj4wdFG+9cWhfxR/dv2/g84/IaNTFrRTJziyTPz7
zKeKcX2ezIMHvOzySytkBQePEQsps/eBpF5MsLA5w1M3/47a4UxwhRKGxgFvzTJ9
zIzQOAuMI01CbHvLTa1dohFcINT1Zd0cK3ZpshBKcsxCwmT7LJKM50XZ0Ddw6Kc9
yhW5ZWK83wd+oER3mR/k
=t6ib
-----END PGP SIGNATURE-----
^ permalink raw reply
* [GIT PULL] ARM: OMAP: more hwmod/PRCM fixes for 3.7-rc
From: Paul Walmsley @ 2012-10-31 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210311050040.4160@utopia.booyaka.com>
Hi Tony
On Wed, 31 Oct 2012, Paul Walmsley wrote:
> The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
>
> Linux 3.7-rc3 (2012-10-28 12:24:48 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-fixes-b-for-3.7-rc
>
> for you to fetch changes up to 945365c4da8c29bbb0109a728e6dca691d78a5de:
>
> ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init (2012-10-29 22:13:44 -0600)
Kevin just alerted me that I missed one of the comments on one of these
patches. So, will update it, re-test, and send a new pull request.
- Paul
^ permalink raw reply
* [PATCH RFC] i2c: omap: Fix the revision register read
From: Shubhrajyoti @ 2012-10-31 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121031101201.GB10094@arwen.pp.htv.fi>
On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
>>
>> > + if (!_dev->regs)
>> > + return 0;
> this is wrong, you need to make sure dev->regs is set early enough.
to set the dev->regs I use the value read from revision register.
to read the revision register I do a get_sync first. This in turn leads
to the call to resume handler.
At this point the regs is NULL and so the check.
After reading the register and checking the scheme bit.
the reg map is populated.
How can this issue be solved?
^ permalink raw reply
* [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
From: Philip, Avinash @ 2012-10-31 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5090FEE1.5070206@ti.com>
On Wed, Oct 31, 2012 at 16:05:13, Cousson, Benoit wrote:
>
> On 10/31/2012 11:16 AM, Benoit Cousson wrote:
> > Hi Avinash,
> >
> > On 10/30/2012 10:41 AM, Philip, Avinash wrote:
> >> On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
> >>> On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
> >>>> Adds AM33XX SPI support for am335x-bone and am335x-evm.
> >>
> >> Matt,
> >>
> >> Can you build SPI DT patch with DMA support on top of SPI DT patch
> >> I submitted [1]. With the patch [1] SPI can work on PIO mode.
> >> So we can have basic SPI support available in 3.8.
> >>
> >> Benoit,
> >> Can you accept the SPI DT patch [1]
> >
> > Yes, I've just applied it in for_3.8/dts branch
>
> Well, in fact I did not, it does not apply :-(
>
> Can you rebase on top of the for_3.8/dts branch? I've just applied the
> RTC patch on top that was OK.
Ok.
Thanks
Avinash
>
> Thanks,
> Benoit
>
> >
> >> In case if you want I will resubmit a patch with subject line modified.
> >
> > No, that's fine.
> >
> > Thanks,
> > Benoit
> >
> >>
> >> Current subject line
> >> arm/dts: AM33XX: Add SPI device tree data
> >>
> >> 1. https://patchwork.kernel.org/patch/1470661/
> >>
> >> Thanks
> >> Avinash
> >>
> >>>>
> >>>> Signed-off-by: Matt Porter <mporter@ti.com>
> >>>> ---
> >>>> arch/arm/boot/dts/am335x-bone.dts | 17 +++++++++++++++
> >>>> arch/arm/boot/dts/am335x-evm.dts | 9 ++++++++
> >>>> arch/arm/boot/dts/am33xx.dtsi | 43 +++++++++++++++++++++++++++++++++++++
> >>>> 3 files changed, 69 insertions(+)
> >>>>
> >>>> diff --git a/arch/arm/boot/dts/am335x-bone.dts b/arch/arm/boot/dts/am335x-bone.dts
> >>>> index 5510979..23edfd8 100644
> >>>> --- a/arch/arm/boot/dts/am335x-bone.dts
> >>>> +++ b/arch/arm/boot/dts/am335x-bone.dts
> >>>> @@ -18,6 +18,17 @@
> >>>> reg = <0x80000000 0x10000000>; /* 256 MB */
> >>>> };
> >>>>
> >>>> + am3358_pinmux: pinmux at 44e10800 {
> >>>> + spi1_pins: pinmux_spi1_pins {
> >>>> + pinctrl-single,pins = <
> >>>> + 0x190 0x13 /* mcasp0_aclkx.spi1_sclk, OUTPUT_PULLUP | MODE3 */
> >>>> + 0x194 0x33 /* mcasp0_fsx.spi1_d0, INPUT_PULLUP | MODE3 */
> >>>> + 0x198 0x13 /* mcasp0_axr0.spi1_d1, OUTPUT_PULLUP | MODE3 */
> >>>> + 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0, OUTPUT_PULLUP | MODE3 */
> >>>> + >;
> >>>> + };
> >>>> + };
> >>>> +
> >>>
> >>> Change to am33xx_pinmux.
> >>>
> >>>> ocp {
> >>>> uart1: serial at 44e09000 {
> >>>> status = "okay";
> >>>> @@ -84,3 +95,9 @@
> >>>> &mmc1 {
> >>>> vmmc-supply = <&ldo3_reg>;
> >>>> };
> >>>> +
> >>>> +&spi1 {
> >>>> + status = "okay";
> >>>> + pinctrl-names = "default";
> >>>> + pinctrl-0 = <&spi1_pins>;
> >>>> +};
> >>>> diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
> >>>> index d63fce8..8d5f660 100644
> >>>> --- a/arch/arm/boot/dts/am335x-evm.dts
> >>>> +++ b/arch/arm/boot/dts/am335x-evm.dts
> >>>> @@ -124,3 +124,12 @@
> >>>> &mmc1 {
> >>>> vmmc-supply = <&vmmc_reg>;
> >>>> };
> >>>> +
> >>>> +&spi0 {
> >>>> + status = "okay";
> >>>> + spi-flash at 0 {
> >>>> + compatible = "spansion,s25fl064k", "m25p80";
> >>>> + spi-max-frequency = <24000000>;
> >>>> + reg = <0>;
> >>>> + };
> >>>> +};
> >>>
> >>> In AM335x-evm, SPI flash available in profile #2 (am335x evm specific profiles).
> >>> So can you drop this changes as if I understood correctly, am335x-evm.dts will be
> >>> populated for devices present only on profile #0.
> >>>
> >>>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> >>>> index 26a6af7..063ecea 100644
> >>>> --- a/arch/arm/boot/dts/am33xx.dtsi
> >>>> +++ b/arch/arm/boot/dts/am33xx.dtsi
> >>>> @@ -40,6 +40,15 @@
> >>>> };
> >>>> };
> >>>>
> >>>> + am3358_pinmux: pinmux at 44e10800 {
> >>>> + compatible = "pinctrl-single";
> >>>> + reg = <0x44e10800 0x0238>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + pinctrl-single,register-width = <32>;
> >>>> + pinctrl-single,function-mask = <0x7f>;
> >>>> + };
> >>>> +
> >>>
> >>> Pin ctrl support already submitted
> >>> http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
> >>>
> >>> Thanks
> >>> Avinash
> >>>
> >>>> /*
> >>>> * XXX: Use a flat representation of the AM33XX interconnect.
> >>>> * The real AM33XX interconnect network is quite complex.Since
> >>>> @@ -261,6 +270,40 @@
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>> + spi0: spi at 48030000 {
> >>>> + compatible = "ti,omap4-mcspi";
> >>>> + ti,hwmods = "spi0";
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <0x48030000 0x400>;
> >>>> + interrupt-parent = <&intc>;
> >>>> + interrupt = <65>;
> >>>> + dmas = <&edma 16
> >>>> + &edma 17
> >>>> + &edma 18
> >>>> + &edma 19>;
> >>>> + dma-names = "tx0", "rx0", "tx1", "rx1";
> >>>> + ti,spi-num-cs = <2>;
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> + spi1: spi at 481a0000 {
> >>>> + compatible = "ti,omap4-mcspi";
> >>>> + ti,hwmods = "spi1";
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + reg = <0x481a0000 0x400>;
> >>>> + interrupt-parent = <&intc>;
> >>>> + interrupt = <125>;
> >>>> + dmas = <&edma 42
> >>>> + &edma 43
> >>>> + &edma 44
> >>>> + &edma 45>;
> >>>> + dma-names = "tx0", "rx0", "tx1", "rx1";
> >>>> + ti,spi-num-cs = <2>;
> >>>> + status = "disabled";
> >>>> + };
> >>>> +
> >>>> wdt2: wdt at 44e35000 {
> >>>> compatible = "ti,omap3-wdt";
> >>>> ti,hwmods = "wd_timer2";
> >>>> --
> >>>> 1.7.9.5
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> linux-arm-kernel mailing list
> >>>> linux-arm-kernel at lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >>>>
> >>>
> >>>
> >>
> >
>
>
^ permalink raw reply
* [PATCH v2] ARM: dts: am33xx: rtc node
From: Benoit Cousson @ 2012-10-31 11:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351589646-27082-1-git-send-email-afzal@ti.com>
Hi Afzal,
On 10/30/2012 10:34 AM, Afzal Mohammed wrote:
> Add am33xx rtc node.
>
> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
> Hi Benoit,
>
> This is based on your for_3.8/dts branch.
I've just applied it in the branch with a slight change in the subject.
Thanks,
Benoit
>
> This has been tested on Beagle Bone.
>
> Bindings along with driver changes for DT has been picked by Andrew
> Morton and is now present in linux-next.
>
> Regards
> Afzal
>
> v2
> 1. Remove interrupt parent in rtc node.
> 2. Modify subject as per new convention.
>
>
> arch/arm/boot/dts/am33xx.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 70d24b8..97a7bd3 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -291,5 +291,13 @@
> ti,hwmods = "timer7";
> ti,timer-pwm;
> };
> +
> + rtc at 44e3e000 {
> + compatible = "ti,da830-rtc";
> + reg = <0x44e3e000 0x1000>;
> + interrupts = <75
> + 76>;
> + ti,hwmods = "rtc";
> + };
> };
> };
>
^ permalink raw reply
* [PATCH v2 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
From: Cousson, Benoit @ 2012-10-31 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351596296-13825-2-git-send-email-peter.ujfalusi@ti.com>
Hi Peter,
That's great you've have done that fix.
On 10/30/2012 12:24 PM, Peter Ujfalusi wrote:
> Add flags parameter for omap_hwmod_count_resources() so users can tell which
> type of resources they are interested when counting them in hwmod database.
Mmm, does it worth doing that for every resources considering that this
is a temporary situation and than only the DMA resources are an issue so
far?
Otherwise that looks fine to me and will allow a much smoother
transition to full DT.
Thanks,
Benoit
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> ---
> arch/arm/mach-omap2/omap_hwmod.c | 27 ++++++++++++++++-----------
> arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
> arch/arm/plat-omap/omap_device.c | 11 ++++++++---
> 3 files changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
> index b969ab1..a79c941 100644
> --- a/arch/arm/mach-omap2/omap_hwmod.c
> +++ b/arch/arm/mach-omap2/omap_hwmod.c
> @@ -3337,7 +3337,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
> /**
> * omap_hwmod_count_resources - count number of struct resources needed by hwmod
> * @oh: struct omap_hwmod *
> - * @res: pointer to the first element of an array of struct resource to fill
> + * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
> *
> * Count the number of struct resource array elements necessary to
> * contain omap_hwmod @oh resources. Intended to be called by code
> @@ -3350,20 +3350,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
> * resource IDs.
> *
> */
> -int omap_hwmod_count_resources(struct omap_hwmod *oh)
> +int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
> {
> - struct omap_hwmod_ocp_if *os;
> - struct list_head *p;
> - int ret;
> - int i = 0;
> + int ret = 0;
>
> - ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
> + if (flags & IORESOURCE_IRQ)
> + ret += _count_mpu_irqs(oh);
>
> - p = oh->slave_ports.next;
> + if (flags & IORESOURCE_DMA)
> + ret += _count_sdma_reqs(oh);
>
> - while (i < oh->slaves_cnt) {
> - os = _fetch_next_ocp_if(&p, &i);
> - ret += _count_ocp_if_addr_spaces(os);
> + if (flags & IORESOURCE_MEM) {
> + int i = 0;
> + struct omap_hwmod_ocp_if *os;
> + struct list_head *p = oh->slave_ports.next;
> +
> + while (i < oh->slaves_cnt) {
> + os = _fetch_next_ocp_if(&p, &i);
> + ret += _count_ocp_if_addr_spaces(os);
> + }
> }
>
> return ret;
> diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> index b3349f7..48a6f5d 100644
> --- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
> +++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
> @@ -628,7 +628,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16 reg_offs);
> u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
> int omap_hwmod_softreset(struct omap_hwmod *oh);
>
> -int omap_hwmod_count_resources(struct omap_hwmod *oh);
> +int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags);
> int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
> int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res);
> int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
> diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
> index 7a7d1f2..915cf68 100644
> --- a/arch/arm/plat-omap/omap_device.c
> +++ b/arch/arm/plat-omap/omap_device.c
> @@ -442,19 +442,21 @@ int omap_device_get_context_loss_count(struct platform_device *pdev)
> /**
> * omap_device_count_resources - count number of struct resource entries needed
> * @od: struct omap_device *
> + * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
> *
> * Count the number of struct resource entries needed for this
> * omap_device @od. Used by omap_device_build_ss() to determine how
> * much memory to allocate before calling
> * omap_device_fill_resources(). Returns the count.
> */
> -static int omap_device_count_resources(struct omap_device *od)
> +static int omap_device_count_resources(struct omap_device *od,
> + unsigned long flags)
> {
> int c = 0;
> int i;
>
> for (i = 0; i < od->hwmods_cnt; i++)
> - c += omap_hwmod_count_resources(od->hwmods[i]);
> + c += omap_hwmod_count_resources(od->hwmods[i], flags);
>
> pr_debug("omap_device: %s: counted %d total resources across %d hwmods\n",
> od->pdev->name, c, od->hwmods_cnt);
> @@ -558,7 +560,10 @@ struct omap_device *omap_device_alloc(struct platform_device *pdev,
> od->hwmods = hwmods;
> od->pdev = pdev;
>
> - res_count = omap_device_count_resources(od);
> + /* Count all resources for the device */
> + res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
> + IORESOURCE_DMA |
> + IORESOURCE_MEM);
> /*
> * DT Boot:
> * OF framework will construct the resource structure (currently
>
^ permalink raw reply
* [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Florian Fainelli @ 2012-10-31 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351245804-31478-2-git-send-email-thomas.petazzoni@free-electrons.com>
Hello Thomas,
On Friday 26 October 2012 12:03:21 Thomas Petazzoni wrote:
> This patch contains a new network driver for the network unit of the
> ARM Marvell Armada 370 and the Armada XP. Both SoCs use the PJ4B
> processor, a Marvell-developed ARM core that implements the ARMv7
> instruction set.
>
> Compared to previous ARM Marvell SoCs (Kirkwood, Orion, Discovery),
> the network unit in Armada 370 and Armada XP is highly different. This
> is the reason why this new 'mvneta' driver is needed, while the older
> ARM Marvell SoCs use the 'mv643xx_eth' driver.
>
> Here is an overview of the most important hardware changes that
> require a new, specific, driver for the network unit of Armada 370/XP:
>
> - The new network unit has a completely different design and layout
> for the RX and TX descriptors. They are now organized as a simple
> array (each RX and TX queue has base address and size of this
> array) rather than a linked list as in the old SoCs.
>
> - The new network unit has a different RXQ and TXQ management: this
> management is done using special read/write counter registers,
> while in the Old SocS, it was done using the Ownership bit in RX
> and TX descriptors.
>
> - The new network unit has different interrupt registers
>
> - The new network unit way of cleaning of interrupts is not done by
> writing to the cause register, but by updating per-queue counters
>
> - The new network unit has different GMAC registers (link, speed,
> duplex configuration) and different WRR registers.
>
> - The new network unit has lots of new units like PnC (Parser and
> Classifier), PMT, BM (Memory Buffer Management), xPON, and more.
>
> The driver proposed in the current patch only handles the basic
> features. Additional hardware features will progressively be supported
> as needed.
>
> This code has originally been written by Rami Rosen
> <rosenr@marvell.com>, and then reviewed and cleaned up by Thomas
> Petazzoni <thomas.petazzoni@free-electrons.com>.
This is looking good from a PHY lib point of view now, thanks for doing this!
--
Florian
^ permalink raw reply
* [PATCH v4 4/5] ARM: annotate VMALLOC_END definition with _AC
From: Josh Cartwright @ 2012-10-31 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <29530110-f967-49c0-a2bc-d035d02da2a5@VA3EHSMHS020.ehs.local>
On Wed, Oct 31, 2012 at 08:43:35AM +0000, Michal Simek wrote:
>
>
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: Tuesday, October 30, 2012 11:22 PM
> > To: Michal Simek
> > Cc: Josh Cartwright; arm at kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; John Linn; Nick Bowler; Russell King - ARM Linux
> > Subject: Re: [PATCH v4 4/5] ARM: annotate VMALLOC_END definition with _AC
> >
> > On Saturday 27 October 2012, Michal Simek wrote:
> > > > diff --git a/arch/arm/include/asm/pgtable.h
> > > > b/arch/arm/include/asm/pgtable.h index 08c1231..72904a2 100644
> > > > --- a/arch/arm/include/asm/pgtable.h
> > > > +++ b/arch/arm/include/asm/pgtable.h
> > > > @@ -40,7 +40,7 @@
> > > > */
> > > > #define VMALLOC_OFFSET (8*1024*1024)
> > > > #define VMALLOC_START (((unsigned long)high_memory +
> > > > VMALLOC_OFFSET) & ~(VMALLOC_OFFSET-1))
> > > > -#define VMALLOC_END 0xff000000UL
> > > > +#define VMALLOC_END _AC(0xff000000,UL)
> > >
> > > This shouldn't be the part of this series but should go to mainline through
> > different tree.
> > > Arnd, Olof: Can you take this patch to your arm-soc tree?
> > >
> > > I don't think it is a good workstyle to propose it to mainline through zynq soc
> > tree.
> > > What do you think?
> >
> > The arm-soc tree is not the right place either, this is architecture code which is in
> > Russell's domain. I would suggest getting an Ack from Russell if he's ok with it
> > and then merging it together with your other changes into arm-soc.
>
> That's what I thought too.
> Not sure if Josh wants to push this to mainline.
The patch is not relevant anymore. It was needed when the virtual
address of the early uart mapping was defined via VMALLOC_END. That was
causing us problems, so we ended up choosing a fixed, known working
address within the vmalloc region to map the uart.
Thanks,
Josh
-------------- 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/20121031/9c397885/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: dts: am33xx: rtc node
From: Afzal Mohammed @ 2012-10-31 11:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50910664.1010304@ti.com>
On Wednesday 31 October 2012 04:37 PM, Benoit Cousson wrote:
> I've just applied it in the branch with a slight change in the subject.
Thanks Benoit
Regards
Afzal
^ permalink raw reply
* [PATCH v3] ARM: dts: AM33xx: Add SPI node
From: Benoit Cousson @ 2012-10-31 11:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351680669-20718-1-git-send-email-avinashphilip@ti.com>
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
> Add McSPI data node to AM33XX device tree file. The McSPI module (and so
> as the driver) is reused from OMAP4.
>
> Signed-off-by: Philip, Avinash <avinashphilip@ti.com>
> Tested-by: Matt Porter <mporter@ti.com>
> ---
Applied in for_3.8/dts
Thanks,
Benoit
> Changes since v2:
> - Commit message corrected.
> - Rebase on top of for_3.8/dts
>
> Changes since v1:
> - Corrected reg offset in reg DT entry.
>
> :100644 100644 97a7bd3... 6e04789... M arch/arm/boot/dts/am33xx.dtsi
> arch/arm/boot/dts/am33xx.dtsi | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 97a7bd3..6e04789 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -299,5 +299,29 @@
> 76>;
> ti,hwmods = "rtc";
> };
> +
> + spi0: spi at 48030000 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x48030000 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi0";
> + status = "disabled";
> + };
> +
> + spi1: spi at 481a0000 {
> + compatible = "ti,omap4-mcspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a0000 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + ti,spi-num-cs = <2>;
> + ti,hwmods = "spi1";
> + status = "disabled";
> + };
> };
> };
>
^ permalink raw reply
* [PATCH RFC] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-10-31 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509101EF.1070108@ti.com>
Hi,
On Wed, Oct 31, 2012 at 04:18:15PM +0530, Shubhrajyoti wrote:
> On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Oct 31, 2012 at 02:29:19PM +0530, Shubhrajyoti D wrote:
> >> The revision register on OMAP4 is a 16-bit lo and a 16-bit
> >> hi. Currently the driver reads only the lower 8-bits.
> >> Fix the same by preventing the truncating of the rev register
> >> for OMAP4.
> > very good, but you need to test this with OMAP2/3/4 (5 ??). How was this
> > tested ?
> >
> >> Also use the scheme bit ie bit-14 of the hi register to know if it
> >> is OMAP_I2C_IP_VERSION_2.
> >>
> >> On platforms previous to OMAP4 the offset 0x04 is IE register whose
> >> bit-14 reset value is 0, the code uses the same to its advantage.
> >>
> >> The dev->regs is populated after reading the rev_hi. A NULL check
> >> has been added in the resume handler to prevent the access before
> >> the setting of the regs.
> > this could get some rephrasing, I guess. At least to me it's difficult
> > to understand what you mean :-s
> >
> >> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> >> ---
> >> todo: some of the flag checks can be removed in favour of revision check.
> >>
> >> drivers/i2c/busses/i2c-omap.c | 35 +++++++++++++++++++++++++----------
> >> 1 files changed, 25 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> >> index db31eae..651a7f7 100644
> >> --- a/drivers/i2c/busses/i2c-omap.c
> >> +++ b/drivers/i2c/busses/i2c-omap.c
> >> @@ -51,7 +51,8 @@
> >> /* I2C controller revisions present on specific hardware */
> >> #define OMAP_I2C_REV_ON_2430 0x36
> >> #define OMAP_I2C_REV_ON_3430_3530 0x3C
> >> -#define OMAP_I2C_REV_ON_3630_4430 0x40
> >> +#define OMAP_I2C_REV_ON_3630 0x40
> >> +#define OMAP_I2C_REV_ON_4430_PLUS 0x5040
> > I would rather see a proper decoding of the revision, meaning that you
> > would:
> >
> > For omap2/3:
> >
> > rev major = rev >> 8;
> > rev minor = rev & 0xff;
> you mean
>
> rev major = rev >> 4;
> rev minor = rev & 0xf;
might be, I didn't look at the TRM to make sure, my bad :-)
> thats doable too. However that currently that is read together
> currently.
and that's what's wrong IMHO. What's current in driver is only valid for
OMAP1 IIRC.
> > For OMAP4/5:
> >
> > well, that's a lot more complex, but you have that data ;-)
> >
> >> /* timeout waiting for the controller to respond */
> >> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> >> @@ -202,7 +203,7 @@ struct omap_i2c_dev {
> >> * fifo_size==0 implies no fifo
> >> * if set, should be trsh+1
> >> */
> >> - u8 rev;
> >> + u16 rev;
> > IMHO this should be u32, so you don't need rev_lo and rev_hi below.
> >
> >> unsigned b_hw:1; /* bad h/w fixes */
> >> unsigned receiver:1; /* true when we're in receiver mode */
> >> u16 iestate; /* Saved interrupt register */
> >> @@ -490,7 +491,7 @@ static void omap_i2c_resize_fifo(struct omap_i2c_dev *dev, u8 size, bool is_rx)
> >>
> >> omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, buf);
> >>
> >> - if (dev->rev < OMAP_I2C_REV_ON_3630_4430)
> >> + if (dev->rev < OMAP_I2C_REV_ON_3630)
> >> dev->b_hw = 1; /* Enable hardware fixes */
> >>
> >> /* calculate wakeup latency constraint for MPU */
> >> @@ -1064,6 +1065,8 @@ omap_i2c_probe(struct platform_device *pdev)
> >> const struct of_device_id *match;
> >> int irq;
> >> int r;
> >> + u16 rev_lo;
> >> + u16 rev_hi;
> >>
> >> /* NOTE: driver uses the static register mapping */
> >> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> @@ -1117,11 +1120,6 @@ omap_i2c_probe(struct platform_device *pdev)
> >>
> >> dev->reg_shift = (dev->flags >> OMAP_I2C_FLAG_BUS_SHIFT__SHIFT) & 3;
> >>
> >> - if (dev->dtrev == OMAP_I2C_IP_VERSION_2)
> >> - dev->regs = (u8 *)reg_map_ip_v2;
> >> - else
> >> - dev->regs = (u8 *)reg_map_ip_v1;
> >> -
> >> pm_runtime_enable(dev->dev);
> >> pm_runtime_set_autosuspend_delay(dev->dev, OMAP_I2C_PM_TIMEOUT);
> >> pm_runtime_use_autosuspend(dev->dev);
> >> @@ -1130,7 +1128,21 @@ omap_i2c_probe(struct platform_device *pdev)
> >> if (IS_ERR_VALUE(r))
> >> goto err_free_mem;
> >>
> >> - dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> >> + /* Read the Rev hi bit-14 ie scheme this is 1 indicates ver2 or
> >> + * highlander.
> > the "scheme" in highlander is a 2 bit value. In order to make this
> > future proof, you need to read both bits (31:30).
> Good point will fix it.
> >
> >> + * On omap3 Offset 4 is IE Reg the bit 14 is XDR_IE which is 0 at reset.
> >> + */
> > please align the * characters.
> yes will repost
> >
> >> + rev_hi = __raw_readw(dev->base + 0x04);
> > you should make omap_i2c_read_reg() work fine for this case too.
>
> Just felt it is more readlable this way also I didnt want to use the
> reg_shift etc.
>
> which also may get cleaned up sometime.
correct, but I think for now using omap_i2c_read_reg() is fine.
Maybe defining (for now) REV_HI and REV_LO on both reg_maps would do it?
Just for the time being until we can get rid of reg_shift and
omap_i2c_ip_version ??
I don't know, but to me using __raw_readl() with a hardcoded offset is a
bit odd.
--
balbi
-------------- 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/20121031/da098f2c/attachment.sig>
^ permalink raw reply
* [PATCH RFC] i2c: omap: Fix the revision register read
From: Felipe Balbi @ 2012-10-31 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5091045E.8040407@ti.com>
Hi,
On Wed, Oct 31, 2012 at 04:28:38PM +0530, Shubhrajyoti wrote:
> On Wednesday 31 October 2012 03:42 PM, Felipe Balbi wrote:
> >>
> >> > + if (!_dev->regs)
> >> > + return 0;
> > this is wrong, you need to make sure dev->regs is set early enough.
>
>
> to set the dev->regs I use the value read from revision register.
>
> to read the revision register I do a get_sync first. This in turn leads
> to the call to resume handler.
> At this point the regs is NULL and so the check.
>
> After reading the register and checking the scheme bit.
> the reg map is populated.
>
> How can this issue be solved?
aaa good point, missed that. Nevermind that comment ;-)
cheers
--
balbi
-------------- 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/20121031/cc7b16de/attachment.sig>
^ permalink raw reply
* [PATCH 1/3] irqchip: Move ARM GIC to drivers/irqchip
From: Catalin Marinas @ 2012-10-31 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50906B16.8060204@gmail.com>
On Wed, Oct 31, 2012 at 12:04:38AM +0000, Rob Herring wrote:
> On 10/30/2012 05:47 PM, Russell King - ARM Linux wrote:
> > On Tue, Oct 30, 2012 at 12:21:20PM -0500, Rob Herring wrote:
> >> Looking at this some more, arm64 doesn't need most of what's in gic.h.
> >> The register defines should be moved into the .c file. The remaining
> >> function declarations either are not needed (i.e. gic_init) or should
> >> should be done like the handle_irq function pointer init. We don't want
> >> to have platform code calling gic_cascade_irq or gic_raise_softirq
> >> directly.
> >
> > Softirqs are about the SPIs which are used for SMP IPIs and platform
> > specific wakeup of CPUs. And platform code _needs_ to specify the
> > way IPIs are delivered on the platform. irqchip can't do that because
> > irqchip knows nothing about SPIs (neither does genirq.)
>
> Right. v7 is unchanged, so the question is really only about how v8 will
> do this. Hopefully, ARM is standardizing this for v8. We probably want
> the gic (or other irqchip) to setup a raise_softirq function ptr on init
> rather than having a direct call to gic_raise_softirq.
In my sample ARMv8 model code I have an older version of gic.c moved to
drivers/irqchip and modified just for the arm64 needs. The gic_of_init()
function calls set_smp_cross_call(git_raise_softirq).
http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-aarch64.git;a=commitdiff;h=5cd20480f4d7b56160b3312df14fba3b2bda6798
The gic_secondary_init() is done from a CPU notifier as I wanted to
separate this from the SoC code (even on arch/arm, all the calls to
gic_secondary_init() are the same, so it could be factored out to a
notifier or some function pointer set by gic.c).
And let's assume there is no need for gic_cascade_irq().
--
Catalin
^ permalink raw reply
* [PATCH v4 1/2] ARM: clk-imx27: Add missing clock for mx2-camera
From: Mauro Carvalho Chehab @ 2012-10-31 11:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351598606-8485-1-git-send-email-fabio.estevam@freescale.com>
Em Tue, 30 Oct 2012 10:03:25 -0200
Fabio Estevam <fabio.estevam@freescale.com> escreveu:
> During the clock conversion for mx27 the "per4_gate" clock was missed to get
> registered as a dependency of mx2-camera driver.
>
> In the old mx27 clock driver we used to have:
>
> DEFINE_CLOCK1(csi_clk, 0, NULL, 0, parent, &csi_clk1, &per4_clk);
>
> ,so does the same in the new clock driver
>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
As it seems that those patches depend on some patches at the arm tree,
the better is to merge them via -arm tree.
So,
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> ---
> Changes since v3:
> - Use imx27-camera.0 instead of mx2-camera.0, due to recent changes in the
> imx27 clock (commit 27b76486a3: media: mx2_camera: remove cpu_is_xxx by using platform_device_id)
>
> arch/arm/mach-imx/clk-imx27.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
> index 585ab25..2880bd9 100644
> --- a/arch/arm/mach-imx/clk-imx27.c
> +++ b/arch/arm/mach-imx/clk-imx27.c
> @@ -224,6 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
> clk_register_clkdev(clk[lcdc_ipg_gate], "ipg", "imx21-fb.0");
> clk_register_clkdev(clk[lcdc_ahb_gate], "ahb", "imx21-fb.0");
> clk_register_clkdev(clk[csi_ahb_gate], "ahb", "imx27-camera.0");
> + clk_register_clkdev(clk[per4_gate], "per", "imx27-camera.0");
> clk_register_clkdev(clk[usb_div], "per", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ipg_gate], "ipg", "fsl-usb2-udc");
> clk_register_clkdev(clk[usb_ahb_gate], "ahb", "fsl-usb2-udc");
Cheers,
Mauro
^ permalink raw reply
* [PATCH v4 2/2] mx2_camera: Fix regression caused by clock conversion
From: Mauro Carvalho Chehab @ 2012-10-31 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351598606-8485-2-git-send-email-fabio.estevam@freescale.com>
Em Tue, 30 Oct 2012 10:03:26 -0200
Fabio Estevam <fabio.estevam@freescale.com> escreveu:
> Since mx27 transitioned to the commmon clock framework in 3.5, the correct way
> to acquire the csi clock is to get csi_ahb and csi_per clocks separately.
>
> By not doing so the camera sensor does not probe correctly:
>
> soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0
> mx2-camera mx2-camera.0: Camera driver attached to camera 0
> ov2640 0-0030: Product ID error fb:fb
> mx2-camera mx2-camera.0: Camera driver detached from camera 0
> mx2-camera mx2-camera.0: MX2 Camera (CSI) driver probed, clock frequency: 66500000
>
> Adapt the mx2_camera driver to the new clock framework and make it functional
> again.
>
> Tested-by: Ga?tan Carlier <gcembed@gmail.com>
> Tested-by: Javier Martin <javier.martin@vista-silicon.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
As it seems that those patches depend on some patches at the arm tree,
the better is to merge them via -arm tree.
So,
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
> ---
> Changes since v3:
> - Drop unneeded clk_unprepare calls as pointed out by Guennadi
> Changes since v2:
> - Fix clock error handling code as pointed out by Russell King
> Changes since v1:
> - Rebased against linux-next 20121008.
> drivers/media/platform/soc_camera/mx2_camera.c | 39 ++++++++++++++++++------
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/platform/soc_camera/mx2_camera.c b/drivers/media/platform/soc_camera/mx2_camera.c
> index e575ae8..558f6a3 100644
> --- a/drivers/media/platform/soc_camera/mx2_camera.c
> +++ b/drivers/media/platform/soc_camera/mx2_camera.c
> @@ -278,7 +278,8 @@ struct mx2_camera_dev {
> struct device *dev;
> struct soc_camera_host soc_host;
> struct soc_camera_device *icd;
> - struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_emma_ahb, *clk_emma_ipg;
> + struct clk *clk_csi_ahb, *clk_csi_per;
>
> void __iomem *base_csi, *base_emma;
>
> @@ -464,7 +465,8 @@ static void mx2_camera_deactivate(struct mx2_camera_dev *pcdev)
> {
> unsigned long flags;
>
> - clk_disable_unprepare(pcdev->clk_csi);
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> + clk_disable_unprepare(pcdev->clk_csi_per);
> writel(0, pcdev->base_csi + CSICR1);
> if (is_imx27_camera(pcdev)) {
> writel(0, pcdev->base_emma + PRP_CNTL);
> @@ -492,10 +494,14 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> if (pcdev->icd)
> return -EBUSY;
>
> - ret = clk_prepare_enable(pcdev->clk_csi);
> + ret = clk_prepare_enable(pcdev->clk_csi_ahb);
> if (ret < 0)
> return ret;
>
> + ret = clk_prepare_enable(pcdev->clk_csi_per);
> + if (ret < 0)
> + goto exit_csi_ahb;
> +
> csicr1 = CSICR1_MCLKEN;
>
> if (is_imx27_camera(pcdev))
> @@ -512,6 +518,11 @@ static int mx2_camera_add_device(struct soc_camera_device *icd)
> icd->devnum);
>
> return 0;
> +
> +exit_csi_ahb:
> + clk_disable_unprepare(pcdev->clk_csi_ahb);
> +
> + return ret;
> }
>
> static void mx2_camera_remove_device(struct soc_camera_device *icd)
> @@ -1772,10 +1783,17 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> break;
> }
>
> - pcdev->clk_csi = devm_clk_get(&pdev->dev, "ahb");
> - if (IS_ERR(pcdev->clk_csi)) {
> - dev_err(&pdev->dev, "Could not get csi clock\n");
> - err = PTR_ERR(pcdev->clk_csi);
> + pcdev->clk_csi_ahb = devm_clk_get(&pdev->dev, "ahb");
> + if (IS_ERR(pcdev->clk_csi_ahb)) {
> + dev_err(&pdev->dev, "Could not get csi ahb clock\n");
> + err = PTR_ERR(pcdev->clk_csi_ahb);
> + goto exit;
> + }
> +
> + pcdev->clk_csi_per = devm_clk_get(&pdev->dev, "per");
> + if (IS_ERR(pcdev->clk_csi_per)) {
> + dev_err(&pdev->dev, "Could not get csi per clock\n");
> + err = PTR_ERR(pcdev->clk_csi_per);
> goto exit;
> }
>
> @@ -1785,12 +1803,13 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
>
> pcdev->platform_flags = pcdev->pdata->flags;
>
> - rate = clk_round_rate(pcdev->clk_csi, pcdev->pdata->clk * 2);
> + rate = clk_round_rate(pcdev->clk_csi_per,
> + pcdev->pdata->clk * 2);
> if (rate <= 0) {
> err = -ENODEV;
> goto exit;
> }
> - err = clk_set_rate(pcdev->clk_csi, rate);
> + err = clk_set_rate(pcdev->clk_csi_per, rate);
> if (err < 0)
> goto exit;
> }
> @@ -1848,7 +1867,7 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev)
> goto exit_free_emma;
>
> dev_info(&pdev->dev, "MX2 Camera (CSI) driver probed, clock frequency: %ld\n",
> - clk_get_rate(pcdev->clk_csi));
> + clk_get_rate(pcdev->clk_csi_per));
>
> return 0;
>
Cheers,
Mauro
^ permalink raw reply
* [PATCH V3] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
From: Hebbar, Gururaja @ 2012-10-31 11:57 UTC (permalink / raw)
To: linux-arm-kernel
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
>From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller > 25MHz
Note:
The implementation reuses the output of calc_divisor() so as to reduce
code addition.
Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
Changes in V2
- Added note in commit message about code re-use
- replaced ((a & BIT(n) == BIT(n))) with (a & BIT(n)) since
effectively both are same.
Changes in V3
- use symbolic define for hardcoded value (25000000)
- use of_property_read_bool() instead of of_find_property()
:100644 100644 be76a23... ed271fc... M Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 5434fd8... 4f7fcee... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 +
arch/arm/plat-omap/include/plat/mmc.h | 1 +
drivers/mmc/host/omap_hsmmc.c | 31 +++++++++++++++++++-
3 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
"supply-name" examples are "vmmc", "vmmc_aux" etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed
Example:
mmc1: mmc at 0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS (1 << 0)
#define HSMMC_HAS_UPDATED_RESET (1 << 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 << 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5434fd8..4f7fcee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 << 26)
#define VS30 (1 << 25)
+#define HSS (1 << 21)
#define SDVS18 (0x5 << 9)
#define SDVS30 (0x6 << 9)
#define SDVS33 (0x7 << 9)
@@ -90,6 +91,7 @@
#define MSBS (1 << 5)
#define BCE (1 << 1)
#define FOUR_BIT (1 << 1)
+#define HSPE (1 << 2)
#define DDR (1 << 19)
#define DW8 (1 << 5)
#define CC 0x1
@@ -113,6 +115,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 400000
#define OMAP_MMC_MAX_CLOCK 52000000
+#define HSMMC_CLKOUT 25000000
#define DRIVER_NAME "omap_hsmmc"
/*
@@ -495,6 +498,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
struct mmc_ios *ios = &host->mmc->ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
@@ -502,7 +506,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
regval = OMAP_HSMMC_READ(host->base, SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv << 6) | (DTO << 16);
OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
@@ -513,6 +518,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
&& time_before(jiffies, timeout))
cpu_relax();
+ /*
+ * Enable High-Speed Support
+ * Pre-Requisites
+ * - Controller should support High-Speed-Enable Bit
+ * - Controller should not be using DDR Mode
+ * - Controller should advertise that it supports High Speed
+ * in capabilities register
+ * - MMC/SD clock coming out of controller > 25MHz
+ */
+ if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
+ (ios->timing != MMC_TIMING_UHS_DDR50) &&
+ (OMAP_HSMMC_READ(host->base, CAPA) & HSS)) {
+ regval = OMAP_HSMMC_READ(host->base, HCTL);
+ if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > HSMMC_CLKOUT)
+ regval |= HSPE;
+ else
+ regval &= ~HSPE;
+
+ OMAP_HSMMC_WRITE(host->base, HCTL, regval);
+ }
+
omap_hsmmc_start_clock(host);
}
@@ -1709,6 +1735,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
if (!of_property_read_u32(np, "max-frequency", &max_freq))
pdata->max_freq = max_freq;
+ if (of_property_read_bool(np, "ti,needs-special-hs-handling"))
+ pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
+
return pdata;
}
#else
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 8/8] ARM: OMAP3: do not delete per_clkdm autodeps during idle
From: Tero Kristo @ 2012-10-31 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210160603390.9767@utopia.booyaka.com>
Hi Paul,
On Tue, 2012-10-16 at 07:29 +0000, Paul Walmsley wrote:
> Hi Kevin,
>
> Here's an updated version of this one, with the erratum coverage expanded
> to include OMAP34xx/35xx.
>
> I think this one can replace Tero's "[PATCHv6 06/11] ARM: OMAP:
> clockdomain: add support for preventing autodep delete" and "[PATCHv6
> 07/11] ARM: OMAP3: do not delete per_clkdm autodeps during idle". Tero,
> please let us know if you feel otherwise.
Yes, these are no longer necessary, just tested the set.
No other changes seem to be necessary for the set except trivial rebase.
Would you like me to re-send the pwrdm-changes set or...?
-Tero
>
> The patch seems to pass testing on 37xx. Was not able to really test it
> on 35xx due to PM regressions in v3.7-rc1.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Tue, 16 Oct 2012 00:08:53 -0600
> Subject: [PATCH] ARM: OMAP3: PM: apply part of the erratum i582 workaround
>
> On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
> powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
> upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
> PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
> unusable. This is erratum i582 in the OMAP36xx Silicon Errata
> document.
>
> This patch implements one of several parts of the workaround: the
> addition of the wakeup dependency between the PER and WKUP
> clockdomains, such that PER will wake up at the same time CORE_L3
> does.
>
> This is not a complete workaround. For it to be complete:
>
> 1. the PER powerdomain's next power state must not be set to OSWR or
> OFF if the CORE powerdomain's next power state is set to CSWR or
> ON;
>
> 2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
> if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
> PER went OFF while CORE stayed on. If loopback tests fail, then
> those devices will be unusable until PER and CORE can undergo a
> transition from ON to OSWR/OFF and back ON.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Tero Kristo <t-kristo@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> ---
> arch/arm/mach-omap2/pm.h | 1 +
> arch/arm/mach-omap2/pm34xx.c | 30 ++++++++++++++++++++++++++++--
> 2 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 686137d..67d6613 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -91,6 +91,7 @@ extern void omap3_save_scratchpad_contents(void);
>
> #define PM_RTA_ERRATUM_i608 (1 << 0)
> #define PM_SDRC_WAKEUP_ERRATUM_i583 (1 << 1)
> +#define PM_PER_MEMORIES_ERRATUM_i582 (1 << 2)
>
> #if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3)
> extern u16 pm34xx_errata;
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index c0f8a78..2e0c9e8 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -651,14 +651,17 @@ static void __init pm_errata_configure(void)
> /* Enable the l2 cache toggling in sleep logic */
> enable_omap3630_toggle_l2_on_restore();
> if (omap_rev() < OMAP3630_REV_ES1_2)
> - pm34xx_errata |= PM_SDRC_WAKEUP_ERRATUM_i583;
> + pm34xx_errata |= (PM_SDRC_WAKEUP_ERRATUM_i583 |
> + PM_PER_MEMORIES_ERRATUM_i582);
> + } else if (cpu_is_omap34xx()) {
> + pm34xx_errata |= PM_PER_MEMORIES_ERRATUM_i582;
> }
> }
>
> int __init omap3_pm_init(void)
> {
> struct power_state *pwrst, *tmp;
> - struct clockdomain *neon_clkdm, *mpu_clkdm;
> + struct clockdomain *neon_clkdm, *mpu_clkdm, *per_clkdm, *wkup_clkdm;
> int ret;
>
> if (!omap3_has_io_chain_ctrl())
> @@ -710,6 +713,8 @@ int __init omap3_pm_init(void)
>
> neon_clkdm = clkdm_lookup("neon_clkdm");
> mpu_clkdm = clkdm_lookup("mpu_clkdm");
> + per_clkdm = clkdm_lookup("per_clkdm");
> + wkup_clkdm = clkdm_lookup("wkup_clkdm");
>
> #ifdef CONFIG_SUSPEND
> omap_pm_suspend = omap3_pm_suspend;
> @@ -726,6 +731,27 @@ int __init omap3_pm_init(void)
> if (IS_PM34XX_ERRATUM(PM_RTA_ERRATUM_i608))
> omap3630_ctrl_disable_rta();
>
> + /*
> + * The UART3/4 FIFO and the sidetone memory in McBSP2/3 are
> + * not correctly reset when the PER powerdomain comes back
> + * from OFF or OSWR when the CORE powerdomain is kept active.
> + * See OMAP36xx Erratum i582 "PER Domain reset issue after
> + * Domain-OFF/OSWR Wakeup". This wakeup dependency is not a
> + * complete workaround. The kernel must also prevent the PER
> + * powerdomain from going to OSWR/OFF while the CORE
> + * powerdomain is not going to OSWR/OFF. And if PER last
> + * power state was off while CORE last power state was ON, the
> + * UART3/4 and McBSP2/3 SIDETONE devices need to run a
> + * self-test using their loopback tests; if that fails, those
> + * devices are unusable until the PER/CORE can complete a transition
> + * from ON to OSWR/OFF and then back to ON.
> + *
> + * XXX Technically this workaround is only needed if off-mode
> + * or OSWR is enabled.
> + */
> + if (IS_PM34XX_ERRATUM(PM_PER_MEMORIES_ERRATUM_i582))
> + clkdm_add_wkdep(per_clkdm, wkup_clkdm);
> +
> clkdm_add_wkdep(neon_clkdm, mpu_clkdm);
> if (omap_type() != OMAP2_DEVICE_TYPE_GP) {
> omap3_secure_ram_storage =
^ permalink raw reply
* [PATCH 1/6] arm: use devicetree to get smp_twd clock
From: Mark Langsdorf @ 2012-10-31 12:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351685025-26698-1-git-send-email-mark.langsdorf@calxeda.com>
From: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/kernel/smp_twd.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/arch/arm/kernel/smp_twd.c b/arch/arm/kernel/smp_twd.c
index b22d700..600fbcc 100644
--- a/arch/arm/kernel/smp_twd.c
+++ b/arch/arm/kernel/smp_twd.c
@@ -237,12 +237,15 @@ static irqreturn_t twd_handler(int irq, void *dev_id)
return IRQ_NONE;
}
-static struct clk *twd_get_clock(void)
+static struct clk *twd_get_clock(struct device_node *np)
{
- struct clk *clk;
+ struct clk *clk = NULL;
int err;
- clk = clk_get_sys("smp_twd", NULL);
+ if (np)
+ clk = of_clk_get(np, 0);
+ if (!clk)
+ clk = clk_get_sys("smp_twd", NULL);
if (IS_ERR(clk)) {
pr_err("smp_twd: clock not found: %d\n", (int)PTR_ERR(clk));
return clk;
@@ -263,6 +266,7 @@ static struct clk *twd_get_clock(void)
return ERR_PTR(err);
}
+ twd_timer_rate = clk_get_rate(clk);
return clk;
}
@@ -273,12 +277,7 @@ static int __cpuinit twd_timer_setup(struct clock_event_device *clk)
{
struct clock_event_device **this_cpu_clk;
- if (!twd_clk)
- twd_clk = twd_get_clock();
-
- if (!IS_ERR_OR_NULL(twd_clk))
- twd_timer_rate = clk_get_rate(twd_clk);
- else
+ if (IS_ERR_OR_NULL(twd_clk))
twd_calibrate_rate();
__raw_writel(0, twd_base + TWD_TIMER_CONTROL);
@@ -349,6 +348,10 @@ int __init twd_local_timer_register(struct twd_local_timer *tlt)
if (!twd_base)
return -ENOMEM;
+ twd_clk = twd_get_clock(NULL);
+
+ twd_clk = twd_get_clock(NULL);
+
return twd_local_timer_common_register();
}
@@ -383,6 +386,8 @@ void __init twd_local_timer_of_register(void)
goto out;
}
+ twd_clk = twd_get_clock(np);
+
err = twd_local_timer_common_register();
out:
--
1.7.11.7
^ permalink raw reply related
* [PATCH V3] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
From: Felipe Balbi @ 2012-10-31 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351684656-30275-1-git-send-email-gururaja.hebbar@ti.com>
Hi,
On Wed, Oct 31, 2012 at 05:27:36PM +0530, Hebbar, Gururaja wrote:
> HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> Other platforms like TI81xx, OMAP4 may need this as-well. This depends
> on the HSMMC IP timing closure done for the high speed cards.
>
> From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
>
> The MMC/SD/SDIO output signals can be driven on either falling edge or
> rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
> to reach better timing performance, and thus to increase data transfer
> frequency.
>
> There are few pre-requisites for enabling the HSPE bit
> - Controller should support High-Speed-Enable Bit and
> - Controller should not be using DDR Mode and
> - Controller should advertise that it supports High Speed in
> capabilities register and
> - MMC/SD clock coming out of controller > 25MHz
>
> Note:
> The implementation reuses the output of calc_divisor() so as to reduce
> code addition.
>
> Signed-off-by: Hebbar, Gururaja <gururaja.hebbar@ti.com>
this looks good to my eyes, hopefully I haven't missed anything:
Reviewed-by: Felipe Balbi <balbi@ti.com>
> ---
> Rebased on mmc-next (v3.7.0-rc1)
> Only Build tested since EDMA support for AM335x is not yet added
>
> Changes in V2
> - Added note in commit message about code re-use
> - replaced ((a & BIT(n) == BIT(n))) with (a & BIT(n)) since
> effectively both are same.
>
> Changes in V3
> - use symbolic define for hardcoded value (25000000)
> - use of_property_read_bool() instead of of_find_property()
>
> :100644 100644 be76a23... ed271fc... M Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> :100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
> :100644 100644 5434fd8... 4f7fcee... M drivers/mmc/host/omap_hsmmc.c
> .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 1 +
> arch/arm/plat-omap/include/plat/mmc.h | 1 +
> drivers/mmc/host/omap_hsmmc.c | 31 +++++++++++++++++++-
> 3 files changed, 32 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> index be76a23..ed271fc 100644
> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
> "supply-name" examples are "vmmc", "vmmc_aux" etc
> ti,non-removable: non-removable slot (like eMMC)
> ti,needs-special-reset: Requires a special softreset sequence
> +ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed
>
> Example:
> mmc1: mmc at 0x4809c000 {
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h b/arch/arm/plat-omap/include/plat/mmc.h
> index 8b4e4f2..346af5b 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
> /* we can put the features above into this variable */
> #define HSMMC_HAS_PBIAS (1 << 0)
> #define HSMMC_HAS_UPDATED_RESET (1 << 1)
> +#define HSMMC_HAS_HSPE_SUPPORT (1 << 2)
> unsigned features;
>
> int switch_pin; /* gpio (card detect) */
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 5434fd8..4f7fcee 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -63,6 +63,7 @@
>
> #define VS18 (1 << 26)
> #define VS30 (1 << 25)
> +#define HSS (1 << 21)
> #define SDVS18 (0x5 << 9)
> #define SDVS30 (0x6 << 9)
> #define SDVS33 (0x7 << 9)
> @@ -90,6 +91,7 @@
> #define MSBS (1 << 5)
> #define BCE (1 << 1)
> #define FOUR_BIT (1 << 1)
> +#define HSPE (1 << 2)
> #define DDR (1 << 19)
> #define DW8 (1 << 5)
> #define CC 0x1
> @@ -113,6 +115,7 @@
> #define MMC_TIMEOUT_MS 20
> #define OMAP_MMC_MIN_CLOCK 400000
> #define OMAP_MMC_MAX_CLOCK 52000000
> +#define HSMMC_CLKOUT 25000000
> #define DRIVER_NAME "omap_hsmmc"
>
> /*
> @@ -495,6 +498,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
> struct mmc_ios *ios = &host->mmc->ios;
> unsigned long regval;
> unsigned long timeout;
> + unsigned long clkdiv;
>
> dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
>
> @@ -502,7 +506,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
>
> regval = OMAP_HSMMC_READ(host->base, SYSCTL);
> regval = regval & ~(CLKD_MASK | DTO_MASK);
> - regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
> + clkdiv = calc_divisor(host, ios);
> + regval = regval | (clkdiv << 6) | (DTO << 16);
> OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
> OMAP_HSMMC_WRITE(host->base, SYSCTL,
> OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
> @@ -513,6 +518,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host *host)
> && time_before(jiffies, timeout))
> cpu_relax();
>
> + /*
> + * Enable High-Speed Support
> + * Pre-Requisites
> + * - Controller should support High-Speed-Enable Bit
> + * - Controller should not be using DDR Mode
> + * - Controller should advertise that it supports High Speed
> + * in capabilities register
> + * - MMC/SD clock coming out of controller > 25MHz
> + */
> + if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
> + (ios->timing != MMC_TIMING_UHS_DDR50) &&
> + (OMAP_HSMMC_READ(host->base, CAPA) & HSS)) {
> + regval = OMAP_HSMMC_READ(host->base, HCTL);
> + if (clkdiv && (clk_get_rate(host->fclk)/clkdiv) > HSMMC_CLKOUT)
> + regval |= HSPE;
> + else
> + regval &= ~HSPE;
> +
> + OMAP_HSMMC_WRITE(host->base, HCTL, regval);
> + }
> +
> omap_hsmmc_start_clock(host);
> }
>
> @@ -1709,6 +1735,9 @@ static struct omap_mmc_platform_data *of_get_hsmmc_pdata(struct device *dev)
> if (!of_property_read_u32(np, "max-frequency", &max_freq))
> pdata->max_freq = max_freq;
>
> + if (of_property_read_bool(np, "ti,needs-special-hs-handling"))
> + pdata->slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
> +
> return pdata;
> }
> #else
> --
> 1.7.0.4
>
--
balbi
-------------- 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/20121031/0e1f36c4/attachment.sig>
^ permalink raw reply
* [PATCH v3 01/11] clk: davinci - add main PLL clock driver
From: Sekhar Nori @ 2012-10-31 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351181518-11882-2-git-send-email-m-karicheri2@ti.com>
Hi Murali,
On 10/25/2012 9:41 PM, Murali Karicheri wrote:
> This is the driver for the main PLL clock hardware found on DM SoCs.
> This driver borrowed code from arch/arm/mach-davinci/clock.c and
> implemented the driver as per common clock provider API. The main PLL
> hardware typically has a multiplier, a pre-divider and a post-divider.
> Some of the SoCs has the divider fixed meaning they can not be
> configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used
> to tell the driver if a hardware has these dividers present or not.
> Driver is configured through the struct clk_pll_data that has the
> SoC specific clock data.
>
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> ---
> diff --git a/drivers/clk/davinci/clk-pll.c b/drivers/clk/davinci/clk-pll.c
> +static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct clk_pll *pll = to_clk_pll(hw);
> + struct clk_pll_data *pll_data = pll->pll_data;
> + u32 mult = 1, prediv = 1, postdiv = 1;
No need to initialize mult here. I gave this comment last time around as
well.
> + unsigned long rate = parent_rate;
> +
> + mult = readl(pll_data->reg_pllm);
> +
> + /*
> + * if fixed_multiplier is non zero, multiply pllm value by this
> + * value.
> + */
> + if (pll_data->fixed_multiplier)
> + mult = pll_data->fixed_multiplier *
> + (mult & pll_data->pllm_mask);
> + else
> + mult = (mult & pll_data->pllm_mask) + 1;
Hmm, this is interpreting the 'mult' register field differently in both
cases. In one case it is 'actual multiplier - 1' and in other case it is
the 'actual multiplier' itself. Can we be sure that the mult register
definition will change whenever there is a fixed multiplier in the PLL
block? I don't think any of the existing DaVinci devices have a fixed
multiplier. Is this on keystone?
> +struct clk *clk_register_davinci_pll(struct device *dev, const char *name,
> + const char *parent_name,
> + struct clk_pll_data *pll_data)
> +{
> + struct clk_init_data init;
> + struct clk_pll *pll;
> + struct clk *clk;
> +
> + if (!pll_data)
> + return ERR_PTR(-ENODEV);
-EINVAL? Clearly you are treating NULL value as an invalid argument here.
Thanks,
Sekhar
^ 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