* [PATCH v3] Visstrim SM10: Use mo_version to decide board video mode.
From: Sascha Hauer @ 2012-11-02 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACKLOr1DB1_G6ttVHc6p-+SjegmJL1r4pKpunvo43xFR7RyA4g@mail.gmail.com>
On Tue, Oct 30, 2012 at 03:52:10PM +0100, javier Martin wrote:
> On 28 September 2012 15:06, javier Martin
> <javier.martin@vista-silicon.com> wrote:
> > Hi Mauro,
> > this patch should originally go via arm-soc but it has a dependency on
> > support for coda video codec which is already in your tree.
> >
> > Now that we've got Sascha's ack could you merge this patch through your tree?
> >
> > Regards.
> >
>
> Hi Sascha,
> it seems Mauro missed to apply this patch through his tree.
> Moreover, 1 month later from my submission I think it should already
> apply to arm-soc.
>
> Could you please merge it?
Just applied it.
Thanks
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 0/4] Support the MX6 FEC as a PTP hardware clock
From: Richard Cochran @ 2012-11-02 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHrpEqRuy=kewK-592RphVfJnNoma2CPZytoTqLc45HeT53hRQ@mail.gmail.com>
On Fri, Nov 02, 2012 at 10:36:09AM +0800, Frank Li wrote:
> >
> > 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.
> >
>
> Thank you very much.
> I checked Ben's patch, which not affect FEC.
Maybe just remove the Kconfig line "select PPS".
Thanks,
Richard
^ permalink raw reply
* [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: N, Mugunthan V @ 2012-11-02 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50914107.2090909@ti.com>
> -----Original Message-----
> From: Cousson, Benoit
> Sent: Wednesday, October 31, 2012 8:47 PM
> To: Hiremath, Vaibhav
> Cc: netdev at vger.kernel.org; paul at pwsan.com; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; N, Mugunthan V;
> Richard Cochran
> Subject: Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module
> nodes for AM33XX
> > + compatible = "ti,cpsw";
> > + ti,hwmods = "cpgmac0";
> > + cpdma_channels = <8>;
> > + host_port_no = <0>;
> > + cpdma_reg_ofs = <0x800>;
> > + cpdma_sram_ofs = <0xa00>;
> > + ale_reg_ofs = <0xd00>;
> > + ale_entries = <1024>;
> > + host_port_reg_ofs = <0x108>;
> > + hw_stats_reg_ofs = <0x900>;
> > + bd_ram_ofs = <0x2000>;
> > + bd_ram_size = <0x2000>;
> > + no_bd_ram = <0>;
> > + rx_descs = <64>;
> > + mac_control = <0x20>;
>
> Do you have to store all these data in the DTS? Cannot it be in the
> driver?
>
> Do you expect to have several instance of the same IP with different
> parameters here?
Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
offsets. For example comparing the CPSW ip in TI814X and AM335X all the
above offsets are changed. So I have kept all these offsets in DT as driver
should not hold any SoC related informations
> > + cpsw_emac0: slave at 0 {
>
> Mmm, you are using some address later and here some relative number,
> that does not looks very consistent.
>
> > + slave_reg_ofs = <0x208>;
>
> Is it an offset from 4a100000? Cannot you use the address for the slave
> name?
>
> Something like that: cpsw_emac0: slave at 4a100208
>
I have followed the naming convention as per the TRM which is mentioned as
Slave 0 and Slave 1 and its offset is from 0x4a100000. I have taken the
reference from arch/arm/boot/dts/picoxcell-pc3x2.dtsi+167 and followed
the same naming convention from TRM. There is one more method to implement
in reference from arch/arm/boot/dts/imx6q.dtsi+408 as below
+ cpsw_emac0: slave at 208 {
+ slave_reg_ofs = <0x208>;
+ sliver_reg_ofs = <0xd80>;
+ /* Filled in by U-Boot */
+ mac-address = [ 00 00 00 00 00 00 ];
+ };
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Tomi Valkeinen @ 2012-11-02 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50936A6E.3020202@ti.com>
On 2012-11-02 08:38, Santosh Shilimkar wrote:
> Tony,
>
> On Friday 02 November 2012 04:18 AM, Tony Lindgren wrote:
>> This file has only omap_init_consistent_dma_size()
>> left that can be moved to plat-omap/dma.c.
>>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> ---
>> arch/arm/plat-omap/Makefile | 2 +-
>> arch/arm/plat-omap/common.c | 26 --------------------------
>> arch/arm/plat-omap/dma.c | 8 ++++++++
>> 3 files changed, 9 insertions(+), 27 deletions(-)
>> delete mode 100644 arch/arm/plat-omap/common.c
>>
>
> [..]
>
>> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
>> index c288b76..00a3a53 100644
>> --- a/arch/arm/plat-omap/dma.c
>> +++ b/arch/arm/plat-omap/dma.c
>> @@ -2146,6 +2146,14 @@ static struct platform_driver
>> omap_system_dma_driver = {
>> },
>> };
>>
>> +/* This must be called from init_early() */
>> +void __init omap_init_consistent_dma_size(void)
>> +{
>> +#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
>> + init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE << 20);
>> +#endif
>> +}
>> +
> Lets not move this in DMA code since the above is really related
> to frame buffer. It reserves more DMA area for dma_alloc_coherent()
> etc than default 2 MB. Infact, we should no longer need this with
> CMA and memblock in place.
>
> Tomi,
> Can we not get rid of the above memory reservation ?
Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
and I have no means to test it out, though. But below is a patch to
remove it. I also attached the patch, as it looks like thunderbird wants
to reformat the pasted patch... I'll remove the
CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
in my tree later.
>From 65c22c93928fbaaae846dd7df53343050bbcfc64 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Fri, 2 Nov 2012 10:36:13 +0200
Subject: [PATCH] ARM: OMAP: Remove omap_init_consistent_dma_size()
The only thing omap_init_consistent_dma_size() does is increase the
consistent DMA size if CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE is defined.
Increasing the consistent DMA size should no longer be needed with CMA
in place.
This patch removes omap_init_consistent_dma_size() and also
arch/arm/mach-omap2/io.c:omap_common_init_early() which becomes an empty
function.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap1/io.c | 1 -
arch/arm/mach-omap2/io.c | 12 ------------
arch/arm/plat-omap/common.c | 7 -------
arch/arm/plat-omap/include/plat/dma.h | 1 -
4 files changed, 21 deletions(-)
diff --git a/arch/arm/mach-omap1/io.c b/arch/arm/mach-omap1/io.c
index 6a5baab..b3d0fb3 100644
--- a/arch/arm/mach-omap1/io.c
+++ b/arch/arm/mach-omap1/io.c
@@ -134,7 +134,6 @@ void __init omap1_init_early(void)
*/
omap1_clk_init();
omap1_mux_init();
- omap_init_consistent_dma_size();
}
void __init omap1_init_late(void)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 4234d28..2597846 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -354,11 +354,6 @@ static int _set_hwmod_postsetup_state(struct
omap_hwmod *oh, void *data)
return omap_hwmod_set_postsetup_state(oh, *(u8 *)data);
}
-static void __init omap_common_init_early(void)
-{
- omap_init_consistent_dma_size();
-}
-
static void __init omap_hwmod_init_postsetup(void)
{
u8 postsetup_state;
@@ -379,7 +374,6 @@ void __init omap2420_init_early(void)
{
omap2_set_globals_242x();
omap2xxx_check_revision();
- omap_common_init_early();
omap2xxx_voltagedomains_init();
omap242x_powerdomains_init();
omap242x_clockdomains_init();
@@ -401,7 +395,6 @@ void __init omap2430_init_early(void)
{
omap2_set_globals_243x();
omap2xxx_check_revision();
- omap_common_init_early();
omap2xxx_voltagedomains_init();
omap243x_powerdomains_init();
omap243x_clockdomains_init();
@@ -428,7 +421,6 @@ void __init omap3_init_early(void)
omap2_set_globals_3xxx();
omap3xxx_check_revision();
omap3xxx_check_features();
- omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
omap3xxx_clockdomains_init();
@@ -462,7 +454,6 @@ void __init ti81xx_init_early(void)
omap2_set_globals_ti81xx();
omap3xxx_check_revision();
ti81xx_check_features();
- omap_common_init_early();
omap3xxx_voltagedomains_init();
omap3xxx_powerdomains_init();
omap3xxx_clockdomains_init();
@@ -520,7 +511,6 @@ void __init am33xx_init_early(void)
omap2_set_globals_am33xx();
omap3xxx_check_revision();
ti81xx_check_features();
- omap_common_init_early();
am33xx_voltagedomains_init();
am33xx_powerdomains_init();
am33xx_clockdomains_init();
@@ -536,7 +526,6 @@ void __init omap4430_init_early(void)
omap2_set_globals_443x();
omap4xxx_check_revision();
omap4xxx_check_features();
- omap_common_init_early();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
omap44xx_clockdomains_init();
@@ -558,7 +547,6 @@ void __init omap5_init_early(void)
{
omap2_set_globals_5xxx();
omap5xxx_check_revision();
- omap_common_init_early();
}
#endif
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 111315a..ab44d34 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -31,13 +31,6 @@ void __init omap_reserve(void)
omap_barrier_reserve_memblock();
}
-void __init omap_init_consistent_dma_size(void)
-{
-#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
- init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE << 20);
-#endif
-}
-
/*
* Stub function for OMAP2 so that common files
* continue to build when custom builds are used
diff --git a/arch/arm/plat-omap/include/plat/dma.h
b/arch/arm/plat-omap/include/plat/dma.h
index 0a87b05..f1b2ad3 100644
--- a/arch/arm/plat-omap/include/plat/dma.h
+++ b/arch/arm/plat-omap/include/plat/dma.h
@@ -449,7 +449,6 @@ struct omap_system_dma_plat_info {
u32 (*dma_read)(int reg, int lch);
};
-extern void __init omap_init_consistent_dma_size(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
extern int omap_request_dma(int dev_id, const char *dev_name,
void (*callback)(int lch, u16 ch_status, void *data),
--
1.7.10.4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-OMAP-Remove-omap_init_consistent_dma_size.patch
Type: text/x-patch
Size: 4526 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/5d1308d7/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121102/5d1308d7/attachment-0001.sig>
^ permalink raw reply related
* [PATCH v2 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
From: Cousson, Benoit @ 2012-11-02 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509374A4.8050806@ti.com>
Salut P?ter,
On 11/2/2012 8:22 AM, P?ter Ujfalusi wrote:
> Hi Benoit,
>
> On 10/31/2012 12:09 PM, Cousson, Benoit wrote:
>> 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?
>
> I think it is better to have nice API - even for a short term - than introduce
> a new wrapper just to count the DMA resources.
> Yes we only use this to either count all resources or to count the DMA
> resources only, but the other options does not look better either:
> 1. omap_hwmod_count_dma_resources(struct omap_hwmod *oh)
> 2. omap_hwmod_count_resources(struct omap_hwmod *oh, bool dma_only)
Fair enough. I'm OK with that. I'll take theses patches, except if Paul
already have a 3.8 branch for hwmod.
Regards,
Benoit
^ permalink raw reply
* [PATCH] i2c: omap: ensure writes to dev->buf_len are ordered
From: Felipe Balbi @ 2012-11-02 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101222316.GC22956@pengutronix.de>
Hi,
On Thu, Nov 01, 2012 at 11:23:16PM +0100, Wolfram Sang wrote:
> On Thu, Oct 25, 2012 at 12:00:48PM +0300, Felipe Balbi wrote:
> > if we allow compiler reorder our writes, we could
> > fall into a situation where dev->buf_len is reset
> > for no apparent reason.
> >
> > This bug was found with a simple script which would
> > transfer data to an i2c client from 1 to 1024 bytes
> > (a simple for loop), when we got to transfer sizes
> > bigger than the fifo size, dev->buf_len was reset
> > to zero before we had an oportunity to handle XDR
> > Interrupt. Because dev->buf_len was zero, we entered
> > omap_i2c_transmit_data() to transfer zero bytes,
> > which would mean we would just silently exit
> > omap_i2c_transmit_data() without actually writing
> > anything to DATA register. That would cause XDR
> > IRQ to trigger forever and we would never transfer
> > the remaining bytes.
> >
> > After adding the memory barrier, we also drop resetting
> > dev->buf_len to zero in omap_i2c_xfer_msg() because
> > both omap_i2c_transmit_data() and omap_i2c_receive_data()
> > will act until dev->buf_len reaches zero, rendering the
> > other write in omap_i2c_xfer_msg() redundant.
> >
> > This patch has been tested with pandaboard for a few
> > iterations of the script mentioned above.
> >
> > Signed-off-by: Felipe Balbi <balbi@ti.com>
> > ---
> >
> > This bug has been there forever, but it's quite annoying.
> > I think it deserves being pushed upstream during this -rc
> > cycle, but if Wolfram decides to wait until v3.8, I don't
> > mind.
>
> I would add this into 3.7, but what about the comments suggesting to use
> barrier()?
I was waiting for more comments, will respin the patch next week.
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/20121102/1206e9bb/attachment.sig>
^ permalink raw reply
* [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
From: Santosh Shilimkar @ 2012-11-02 8:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5093891D.6070302@ti.com>
On Friday 02 November 2012 02:19 PM, Tomi Valkeinen wrote:
> On 2012-11-02 08:38, Santosh Shilimkar wrote:
>> Tony,
>>
>> On Friday 02 November 2012 04:18 AM, Tony Lindgren wrote:
>>> This file has only omap_init_consistent_dma_size()
>>> left that can be moved to plat-omap/dma.c.
>>>
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>> ---
>>> arch/arm/plat-omap/Makefile | 2 +-
>>> arch/arm/plat-omap/common.c | 26 --------------------------
>>> arch/arm/plat-omap/dma.c | 8 ++++++++
>>> 3 files changed, 9 insertions(+), 27 deletions(-)
>>> delete mode 100644 arch/arm/plat-omap/common.c
>>>
>>
>> [..]
>>
>>> diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
>>> index c288b76..00a3a53 100644
>>> --- a/arch/arm/plat-omap/dma.c
>>> +++ b/arch/arm/plat-omap/dma.c
>>> @@ -2146,6 +2146,14 @@ static struct platform_driver
>>> omap_system_dma_driver = {
>>> },
>>> };
>>>
>>> +/* This must be called from init_early() */
>>> +void __init omap_init_consistent_dma_size(void)
>>> +{
>>> +#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
>>> + init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE << 20);
>>> +#endif
>>> +}
>>> +
>> Lets not move this in DMA code since the above is really related
>> to frame buffer. It reserves more DMA area for dma_alloc_coherent()
>> etc than default 2 MB. Infact, we should no longer need this with
>> CMA and memblock in place.
>>
>> Tomi,
>> Can we not get rid of the above memory reservation ?
>
> Yes, I think so. This one is only used for the old omapfb, i.e. omap1,
> and I have no means to test it out, though. But below is a patch to
> remove it. I also attached the patch, as it looks like thunderbird wants
> to reformat the pasted patch... I'll remove the
> CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE from the omapfb driver's Kconfig file
> in my tree later.
>
Great !!
Thanks for the patches Tomi.
For both the patches, feel free add.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* [PATCH v2] rtc: i.MX dryice: Add devicetree support
From: Sascha Hauer @ 2012-11-02 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348566986-9603-1-git-send-email-s.hauer@pengutronix.de>
Alessandro,
Everything fine with this patch? If yes, could you apply it?
Thanks
Sascha
On Tue, Sep 25, 2012 at 11:56:26AM +0200, Sascha Hauer wrote:
> Add devicetree probing, fixing some whitespace damage along the way.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>
> changes since v1:
>
> - document 'intrerrupts' property as mandatory, because the driver needs it.
>
> Documentation/devicetree/bindings/rtc/imx-di.txt | 19 +++++++++++++++++++
> drivers/rtc/rtc-imxdi.c | 12 +++++++++---
> 2 files changed, 28 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/rtc/imx-di.txt
>
> diff --git a/Documentation/devicetree/bindings/rtc/imx-di.txt b/Documentation/devicetree/bindings/rtc/imx-di.txt
> new file mode 100644
> index 0000000..42b92b5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rtc/imx-di.txt
> @@ -0,0 +1,19 @@
> +* i.MX25 dryice Real Time Clock controller
> +
> +This RTC is part of the i.MX25 dryice module. Documentation for this
> +unit is not publically available. This binding only makes use of the
> +RTC.
> +
> +Required properties:
> +- compatible: should be "fsl,imx25-rtc"
> +- reg: physical base address of the controller and length of memory mapped
> + region.
> +- interrupts: interrupt source for the dryice module
> +
> +Example:
> +
> + dryice at 53ffc000 {
> + compatible = "fsl,imx25-dryice", "fsl,imx25-rtc";
> + reg = <0x53ffc000 0x4000>;
> + interrupts = <25>;
> + };
> diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
> index 891cd6c..b2fe920 100644
> --- a/drivers/rtc/rtc-imxdi.c
> +++ b/drivers/rtc/rtc-imxdi.c
> @@ -493,11 +493,17 @@ static int __devexit dryice_rtc_remove(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct of_device_id of_dryice_rtc_match[] = {
> + { .compatible = "fsl,imx25-rtc", },
> + { },
> +};
> +
> static struct platform_driver dryice_rtc_driver = {
> .driver = {
> - .name = "imxdi_rtc",
> - .owner = THIS_MODULE,
> - },
> + .name = "imxdi_rtc",
> + .owner = THIS_MODULE,
> + .of_match_table = of_dryice_rtc_match,
> + },
> .remove = __devexit_p(dryice_rtc_remove),
> };
>
> --
> 1.7.10.4
>
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
From: Richard Cochran @ 2012-11-02 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293EA08F53@DBDE01.ent.ti.com>
On Fri, Nov 02, 2012 at 08:46:46AM +0000, N, Mugunthan V wrote:
> >
> > Do you expect to have several instance of the same IP with different
> > parameters here?
>
> Though CPSW is a single IP in AM335X, CPSW has sub modules like CPDMA, ALE,
> SLIVER, CPTS and SLAVES where is IP integrator can locate it at different
> offsets. For example comparing the CPSW ip in TI814X and AM335X all the
> above offsets are changed. So I have kept all these offsets in DT as driver
> should not hold any SoC related informations
Did you see the two messages on this point from yesterday?
Thanks,
Richard
^ permalink raw reply
* [PATCH] lpc32xx: irq - Set the chain handlers after setting up the IRQ domain
From: Roland Stigge @ 2012-11-02 9:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351772626-12615-1-git-send-email-alban.bedel@avionic-design.de>
On 11/01/2012 01:23 PM, Alban Bedel wrote:
> Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de>
> ---
> arch/arm/mach-lpc32xx/irq.c | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-lpc32xx/irq.c b/arch/arm/mach-lpc32xx/irq.c
> index 3c63327..b92dc25 100644
> --- a/arch/arm/mach-lpc32xx/irq.c
> +++ b/arch/arm/mach-lpc32xx/irq.c
> @@ -448,10 +448,6 @@ void __init lpc32xx_init_irq(void)
> __raw_writel(0, LPC32XX_INTC_MASK(LPC32XX_SIC1_BASE));
> __raw_writel(0, LPC32XX_INTC_MASK(LPC32XX_SIC2_BASE));
>
> - /* MIC SUBIRQx interrupts will route handling to the chain handlers */
> - irq_set_chained_handler(IRQ_LPC32XX_SUB1IRQ, lpc32xx_sic1_handler);
> - irq_set_chained_handler(IRQ_LPC32XX_SUB2IRQ, lpc32xx_sic2_handler);
> -
> /* Initially disable all wake events */
> __raw_writel(0, LPC32XX_CLKPWR_P01_ER);
> __raw_writel(0, LPC32XX_CLKPWR_INT_ER);
> @@ -485,6 +481,12 @@ void __init lpc32xx_init_irq(void)
> irq_base, 0,
> &irq_domain_simple_ops,
> NULL);
> - if (!lpc32xx_mic_domain)
> + if (!lpc32xx_mic_domain) {
> panic("Unable to add MIC irq domain\n");
> + return;
> + }
> +
> + /* MIC SUBIRQx interrupts will route handling to the chain handlers */
> + irq_set_chained_handler(IRQ_LPC32XX_SUB1IRQ, lpc32xx_sic1_handler);
> + irq_set_chained_handler(IRQ_LPC32XX_SUB2IRQ, lpc32xx_sic2_handler);
> }
Thanks for your patch!
I already posted basically the same change on 2012-10-28 already which
is part of my patch set for LPC32xx to be merged into arm-soc.git (will
do a pull request later). Fixing another irq bug in this platform/irq also.
Please also note that panic() doesn't return, so I won't include the
respective new return that you added.
Thanks,
Roland
^ permalink raw reply
* [PATCH 4/4] FEC: Add time stamping code and a PTP hardware clock
From: Richard Cochran @ 2012-11-02 9:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351657531-25989-1-git-send-email-Frank.Li@freescale.com>
On Wed, Oct 31, 2012 at 12:25:31PM +0800, Frank Li wrote:
> diff --git a/drivers/net/ethernet/freescale/Kconfig b/drivers/net/ethernet/freescale/Kconfig
> index feff516..ff3be53 100644
> --- a/drivers/net/ethernet/freescale/Kconfig
> +++ b/drivers/net/ethernet/freescale/Kconfig
> @@ -92,4 +92,13 @@ config GIANFAR
> This driver supports the Gigabit TSEC on the MPC83xx, MPC85xx,
> and MPC86xx family of chips, and the FEC on the 8540.
>
> +config FEC_PTP
> + bool "PTP Hardware Clock (PHC)"
> + depends on FEC
> + select PPS
> + select PTP_1588_CLOCK
> + --help---
> + Say Y here if you want to use PTP Hardware Clock (PHC) in the
> + driver. Only the basic clock operations have been implemented.
> +
Does the PTP function work with every FEC on ColdFire and i.MX?
Or do you need to limit this option in some way?
> endif # NET_VENDOR_FREESCALE
...
> diff --git a/drivers/net/ethernet/freescale/fec_ptp.c b/drivers/net/ethernet/freescale/fec_ptp.c
> new file mode 100644
> index 0000000..9b91da9
> --- /dev/null
> +++ b/drivers/net/ethernet/freescale/fec_ptp.c
...
> +/**
> + * fec_ptp_adjfreq - adjust ptp cycle frequency
> + * @ptp: the ptp clock structure
> + * @ppb: parts per billion adjustment from base
> + *
> + * Adjust the frequency of the ptp cycle counter by the
> + * indicated ppb from the base frequency.
> + *
> + * Because ENET hardware frequency adjust is complex,
> + * using software method to do that.
> + */
> +static int fec_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> +{
> + u64 diff;
> + unsigned long flags;
> + int neg_adj = 0;
> +
> + struct fec_enet_private *fep =
> + container_of(ptp, struct fec_enet_private, ptp_caps);
> +
> + if (ppb < 0) {
> + ppb = -ppb;
> + neg_adj = 1;
> + }
> +
> + spin_lock_irqsave(&fep->tmreg_lock, flags);
> + /*
> + * dummy read to set cycle_last in tc to now.
> + * So use adjusted mult to calculate when next call
> + * timercounter_read.
> + */
> + timecounter_read(&fep->tc);
You can reduce the time that the spin lock is held by moving the next
four lines before the locked region:
> + fep->cc.mult = FEC_CC_MULT;
> + diff = fep->cc.mult;
> + diff *= ppb;
> + diff = div_u64(diff, 1000000000ULL);
> +
> + if (neg_adj)
> + fep->cc.mult -= diff;
> + else
> + fep->cc.mult += diff;
> +
> + spin_unlock_irqrestore(&fep->tmreg_lock, flags);
> +
> + return 0;
> +}
Thanks,
Richard
^ permalink raw reply
* [PATCH 7/8] serial: xilinx_uartps: get clock rate info from dts
From: Lars-Peter Clausen @ 2012-11-02 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23a299ee5e89cfd17bb9affd8fbb9f41b79cfd46.1351721190.git.josh.cartwright@ni.com>
On 10/31/2012 08:28 PM, Josh Cartwright wrote:
> Add support for specifying clock information for the uart clk via the
> device tree. This eliminates the need to hardcode rates in the device
> tree.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
> drivers/tty/serial/xilinx_uartps.c | 30 +++++++++++++++++-------------
> 2 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
> index bb3085c..5fb763f 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -44,14 +44,14 @@
> compatible = "xlnx,xuartps";
> reg = <0xE0000000 0x1000>;
> interrupts = <0 27 4>;
> - clock = <50000000>;
> + clocks = <&uart_clk 0>;
> };
>
> uart1: uart at e0001000 {
> compatible = "xlnx,xuartps";
> reg = <0xE0001000 0x1000>;
> interrupts = <0 50 4>;
> - clock = <50000000>;
> + clocks = <&uart_clk 0>;
Shouldn't this be <&uart_clk 1>?
> };
>
> slcr: slcr at f8000000 {
^ permalink raw reply
* [PATCH RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
From: Roland Stigge @ 2012-11-02 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6vEr5fd0_ZuzV=nOXVfwA7_FB5L6KJsEwMEHmVj0rDA=g@mail.gmail.com>
On 10/31/2012 07:59 PM, Grant Likely wrote:
>> 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.
Yes, understand. What do you consider a good example of a command stream
type interface? Link or hint appreciated!
There was already mentioned the idea of a device node which can be
interfaced to via ioctl() for the various operations. Can it be a
"struct miscdevice" or do you require sth. more sophisticated?
Thanks in advance,
Roland
^ permalink raw reply
* [PATCH 5/8] ARM: zynq: add COMMON_CLK support
From: Lars-Peter Clausen @ 2012-11-02 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <94af5ee92c2d68f245eb902de74909aadf159be1.1351721190.git.josh.cartwright@ni.com>
On 10/31/2012 07:58 PM, Josh Cartwright wrote:
> [...]
> +#define PERIPH_CLK_CTRL_SRC(x) (periph_clk_parent_map[((x)&3)>>4])
> +#define PERIPH_CLK_CTRL_DIV(x) (((x)&0x3F00)>>8)
A few more spaces wouldn't hurt ;)
> [...]
> +static void __init zynq_periph_clk_setup(struct device_node *np)
> +{
> + struct zynq_periph_clk *periph;
> + const char *parent_names[3];
> + struct clk_init_data init;
> + struct clk *clk;
> + int err;
> + u32 reg;
> + int i;
> +
> + err = of_property_read_u32(np, "reg", ®);
> + WARN_ON(err);
Shouldn't the function abort if a error happens somewhere? Continuing here
will lead to undefined behavior. Same is probably true for the other WARN_ONs.
> +
> + periph = kzalloc(sizeof(*periph), GFP_KERNEL);
> + WARN_ON(!periph);
> +
> + periph->clk_ctrl = slcr_base + reg;
> + spin_lock_init(&periph->clkact_lock);
> +
> + init.name = np->name;
> + init.ops = &zynq_periph_clk_ops;
> + for (i = 0; i < ARRAY_SIZE(parent_names); i++)
> + parent_names[i] = of_clk_get_parent_name(np, i);
> + init.parent_names = parent_names;
> + init.num_parents = ARRAY_SIZE(parent_names);
> +
> + periph->hw.init = &init;
> +
> + clk = clk_register(NULL, &periph->hw);
> + WARN_ON(IS_ERR(clk));
> +
> + err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> + WARN_ON(err);
> +
> + for (i = 0; i < 2; i++) {
Not all of the peripheral clock generators have two output clocks. I think
it makes sense to use the number entries in clock-output-names here.
> + const char *name;
> +
> + err = of_property_read_string_index(np, "clock-output-names", i,
> + &name);
> + WARN_ON(err);
> +
> + periph->gates[i] = clk_register_gate(NULL, name, np->name, 0,
> + periph->clk_ctrl, i, 0,
> + &periph->clkact_lock);
> + WARN_ON(IS_ERR(periph->gates[i]));
> + }
> +
> + periph->onecell_data.clks = periph->gates;
> + periph->onecell_data.clk_num = i;
> +
> + err = of_clk_add_provider(np, of_clk_src_onecell_get,
> + &periph->onecell_data);
> + WARN_ON(err);
> +}
> [...]
^ permalink raw reply
* discrepancy while save and restore of debounce registers
From: Hebbar, Gururaja @ 2012-11-02 9:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50802B00.6090907@ti.com>
On Thu, Oct 18, 2012 at 21:44:56, Hunter, Jon wrote:
> Hi Gururaja,
>
> On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote:
> > Jon,
> >
> > On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
>
> [snip]
>
> >>> My doubt/questions are
> >>> 1. Why should debounce registers be updated only when it's accessed previously?
> >>
> >> If debounce is not being used by any of the gpios, then there is no need
> >> to restore them as there are no bits set. So this makes sense and saves
> >> a couple register writes.
> >
> > What I want to know is that other than saving register writes, is there any
> > other important stuff that specifies this requirement.
>
> From a HW perspective, none that I can see.
>
> From a SW perspective, yes, as I mentioned if you restore these
> registers without first initialising the context variables where these
> registers are stored, then you may be restoring unknown values to the
> registers and that is bad.
>
> >>> 2. What is the relation between updating debounce registers and crash seen on
> >>> others registers?
> >>
> >> This I am not sure about. I gave this a quick try on my omap3430 beagle
> >> board, but I did not see any side-effects from doing this. However, if
> >> you are always restoring the debounce context regardless of whether
> >> debounce is being used, then you could be writing bad values to the
> >> debounce registers as the context variables bank->context.debouce and
> >> bank->context.debouce_en may not initialised. So that is bad. However,
> >> that said I am still not sure how this could cause a crash.
> >>
> >> Can you share more details on ...
> >
> > Sorry for missing below details in first post.
> >
> >> 1. The OMAP platform you are using?
> >
> > I was trying this on TI AM335x platform (repo below). On AM335x EVM board
> >
> > http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;
> > h=refs/heads/v3.2-staging
> >
> >> 2. What linux distro/environment you are using?
> >
> > Arago AM335x PSP release (linux 3.2 + am335x patch-set)
> >
> >> 3. If there are any specific steps to reproduce this 100% of the time?
> >
> > On top of this tree, try suspend/resume using "echo mem > /syspower/state"
>
> I have a beagle-bone but unfortunately, suspend does not appear to be
> supported in the mainline kernel yet so I am unable to test this on the
> am335x on the mainline.
You can try the suspend/resume on BB from Arago tree which I mentioned above
>
> Have you compared the gpio driver from your v3.2 branch with the current
> mainline to see how different this code is? Ideally, it would be good to
> test on the mainline kernel for another data point to see if this is
> local to your branch.
The mainline kernel omap GPIO driver has changed a lot from current arago
tree (which is at v3.2). Upon comparing is when I found out about the
register access check done before restoring.
>
> Cheers
> Jon
>
>
>
Regards,
Gururaja
^ permalink raw reply
* [PATCH v3] linux,stdout-path helper
From: Sascha Hauer @ 2012-11-02 9:48 UTC (permalink / raw)
To: linux-arm-kernel
The following adds a helper for matching the linux,stdout-path property
in the chosen node and makes use of it in the i.MX serial driver.
changes since v2:
- move helper to OF core and make it independent of serial devices
changes since v1:
- move it out of the i.MX serial driver and make it generic for serial
devices.
----------------------------------------------------------------
Sascha Hauer (3):
OF: Add helper for matching against linux,stdout-path
serial: i.MX: Make console support non optional
serial: i.MX: evaluate linux,stdout-path property
drivers/of/Kconfig | 3 +++
drivers/of/Makefile | 1 +
drivers/of/of_stdout.c | 27 +++++++++++++++++++++++++++
drivers/tty/serial/Kconfig | 16 +---------------
drivers/tty/serial/imx.c | 12 +++++-------
include/linux/of_stdout.h | 24 ++++++++++++++++++++++++
6 files changed, 61 insertions(+), 22 deletions(-)
create mode 100644 drivers/of/of_stdout.c
create mode 100644 include/linux/of_stdout.h
^ permalink raw reply
* [PATCH 1/3] OF: Add helper for matching against linux,stdout-path
From: Sascha Hauer @ 2012-11-02 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351849734-9836-1-git-send-email-s.hauer@pengutronix.de>
devicetrees may have a linux,stdout-path property in the chosen
node describing the console device. This adds a helper function
to match a device against this property so a driver can call
add_preferred_console for a matching device.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/of/Kconfig | 3 +++
drivers/of/Makefile | 1 +
drivers/of/of_stdout.c | 27 +++++++++++++++++++++++++++
include/linux/of_stdout.h | 24 ++++++++++++++++++++++++
4 files changed, 55 insertions(+)
create mode 100644 drivers/of/of_stdout.c
create mode 100644 include/linux/of_stdout.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..8574ebb 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -67,6 +67,9 @@ config OF_MDIO
help
OpenFirmware MDIO bus (Ethernet PHY) accessors
+config OF_STDOUT
+ def_bool y
+
config OF_PCI
def_tristate PCI
depends on PCI
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..c9f3f2f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_OF_I2C) += of_i2c.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
+obj-$(CONFIG_OF_STDOUT) += of_stdout.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
diff --git a/drivers/of/of_stdout.c b/drivers/of/of_stdout.c
new file mode 100644
index 0000000..c9e370e
--- /dev/null
+++ b/drivers/of/of_stdout.c
@@ -0,0 +1,27 @@
+/*
+ * OF helper for linux,stdoutpath property.
+ *
+ * This file is released under the GPLv2
+ */
+#include <linux/of_stdout.h>
+
+/**
+ * of_device_is_stdout_path - check if a device node matches the
+ * linux,stdout-path property
+ *
+ * Check if this device node matches the linux,stdout-path property
+ * in the chosen node. return true if yes, false otherwise.
+ */
+int of_device_is_stdout_path(struct device_node *dn)
+{
+ const char *name;
+
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL)
+ return 0;
+
+ if (dn == of_find_node_by_path(name))
+ return 1;
+
+ return 0;
+}
diff --git a/include/linux/of_stdout.h b/include/linux/of_stdout.h
new file mode 100644
index 0000000..0d80674
--- /dev/null
+++ b/include/linux/of_stdout.h
@@ -0,0 +1,24 @@
+/*
+ * OF helper for linux,stdoutpath property.
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_STDOUT_H
+#define __LINUX_OF_STDOUT_H
+
+#ifdef CONFIG_OF_STDOUT
+
+#include <linux/of.h>
+int of_device_is_stdout_path(struct device_node *dn);
+
+#else
+
+static inline int of_device_is_stdout_path(struct device_node *dn)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* __LINUX_OF_STDOUT_H */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] serial: i.MX: Make console support non optional
From: Sascha Hauer @ 2012-11-02 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351849734-9836-1-git-send-email-s.hauer@pengutronix.de>
Traditionally console support is optional for serial drivers. This
makes it non optional for the i.MX driver since it's not worth
asking questions for a feature virtually every user of this driver
wants to have.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/tty/serial/Kconfig | 16 +---------------
drivers/tty/serial/imx.c | 8 +-------
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4720b4b..920dd0d 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -515,26 +515,12 @@ config SERIAL_IMX
bool "IMX serial port support"
depends on ARCH_MXC
select SERIAL_CORE
+ select SERIAL_CORE_CONSOLE
select RATIONAL
help
If you have a machine based on a Motorola IMX CPU you
can enable its onboard serial port by enabling this option.
-config SERIAL_IMX_CONSOLE
- bool "Console on IMX serial port"
- depends on SERIAL_IMX
- select SERIAL_CORE_CONSOLE
- help
- If you have enabled the serial port on the Motorola IMX
- CPU you can make it the console by answering Y to this option.
-
- Even if you say Y here, the currently visible virtual console
- (/dev/tty0) will still be used as the system console by default, but
- you can alter that using a kernel command line option such as
- "console=ttySA0". (Try "man bootparam" or see the documentation of
- your boot loader (lilo or loadlin) about how to pass options to the
- kernel at boot time.)
-
config SERIAL_UARTLITE
tristate "Xilinx uartlite serial port support"
depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e309e8b..3a9337e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1192,7 +1192,6 @@ static struct uart_ops imx_pops = {
static struct imx_port *imx_ports[UART_NR];
-#ifdef CONFIG_SERIAL_IMX_CONSOLE
static void imx_console_putchar(struct uart_port *port, int ch)
{
struct imx_port *sport = (struct imx_port *)port;
@@ -1348,11 +1347,6 @@ static struct console imx_console = {
.data = &imx_reg,
};
-#define IMX_CONSOLE &imx_console
-#else
-#define IMX_CONSOLE NULL
-#endif
-
static struct uart_driver imx_reg = {
.owner = THIS_MODULE,
.driver_name = DRIVER_NAME,
@@ -1360,7 +1354,7 @@ static struct uart_driver imx_reg = {
.major = SERIAL_IMX_MAJOR,
.minor = MINOR_START,
.nr = ARRAY_SIZE(imx_ports),
- .cons = IMX_CONSOLE,
+ .cons = &imx_console,
};
static int serial_imx_suspend(struct platform_device *dev, pm_message_t state)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] serial: i.MX: evaluate linux,stdout-path property
From: Sascha Hauer @ 2012-11-02 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351849734-9836-1-git-send-email-s.hauer@pengutronix.de>
devicetrees may have the linux,stdout-path property to specify the
console. This patch adds support to the i.MX serial driver for this.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
drivers/tty/serial/imx.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 3a9337e..41be237 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -47,6 +47,7 @@
#include <linux/slab.h>
#include <linux/of.h>
#include <linux/of_device.h>
+#include <linux/of_stdout.h>
#include <linux/pinctrl/consumer.h>
#include <asm/io.h>
@@ -1421,6 +1422,9 @@ static int serial_imx_probe_dt(struct imx_port *sport,
sport->devdata = of_id->data;
+ if (of_device_is_stdout_path(np))
+ add_preferred_console(imx_reg.cons->name, sport->port.line, 0);
+
return 0;
}
#else
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 03/14] ARM: OMAP5: id: Add cpu id for ES versions
From: Roger Quadros @ 2012-11-02 10:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1341566515-22665-4-git-send-email-santosh.shilimkar@ti.com>
Hi Santosh,
I believe the change from cpu_is_xxx() to soc_is_xxx() just for OMAP5
leads to unnecessary confusion, even though soc_is_ is more technically
correct.
What do you think?
regards,
-roger
On 07/06/2012 12:21 PM, Santosh Shilimkar wrote:
> From: R Sricharan <r.sricharan@ti.com>
>
> Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
> detection support.
>
> Signed-off-by: R Sricharan <r.sricharan@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/control.h | 4 ++++
> arch/arm/mach-omap2/id.c | 42 ++++++++++++++++++++++++++++++++-
> arch/arm/plat-omap/include/plat/cpu.h | 22 +++++++++++++++--
> 3 files changed, 65 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h
> index 295b390..b8cdc85 100644
> --- a/arch/arm/mach-omap2/control.h
> +++ b/arch/arm/mach-omap2/control.h
> @@ -253,6 +253,10 @@
> /* TI81XX CONTROL_DEVCONF register offsets */
> #define TI81XX_CONTROL_DEVICE_ID (TI81XX_CONTROL_DEVCONF + 0x000)
>
> +/* OMAP54XX CONTROL STATUS register */
> +#define OMAP5XXX_CONTROL_STATUS 0x134
> +#define OMAP5_DEVICETYPE_MASK (0x7 << 6)
> +
> /*
> * REVISIT: This list of registers is not comprehensive - there are more
> * that should be added.
> diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
> index 37eb95a..40373db 100644
> --- a/arch/arm/mach-omap2/id.c
> +++ b/arch/arm/mach-omap2/id.c
> @@ -50,6 +50,11 @@ int omap_type(void)
> val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
> } else if (cpu_is_omap44xx()) {
> val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
> + } else if (soc_is_omap54xx()) {
> + val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
> + val &= OMAP5_DEVICETYPE_MASK;
> + val >>= 6;
> + goto out;
> } else {
> pr_err("Cannot detect omap type!\n");
> goto out;
> @@ -100,7 +105,7 @@ static u16 tap_prod_id;
>
> void omap_get_die_id(struct omap_die_id *odi)
> {
> - if (cpu_is_omap44xx()) {
> + if (cpu_is_omap44xx() || soc_is_omap54xx()) {
> odi->id_0 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_0);
> odi->id_1 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_1);
> odi->id_2 = read_tap_reg(OMAP_TAP_DIE_ID_44XX_2);
> @@ -513,6 +518,41 @@ void __init omap4xxx_check_revision(void)
> ((omap_rev() >> 12) & 0xf), ((omap_rev() >> 8) & 0xf));
> }
>
> +void __init omap5xxx_check_revision(void)
> +{
> + u32 idcode;
> + u16 hawkeye;
> + u8 rev;
> +
> + idcode = read_tap_reg(OMAP_TAP_IDCODE);
> + hawkeye = (idcode >> 12) & 0xffff;
> + rev = (idcode >> 28) & 0xff;
> + switch (hawkeye) {
> + case 0xb942:
> + switch (rev) {
> + case 0:
> + default:
> + omap_revision = OMAP5430_REV_ES1_0;
> + }
> + break;
> +
> + case 0xb998:
> + switch (rev) {
> + case 0:
> + default:
> + omap_revision = OMAP5432_REV_ES1_0;
> + }
> + break;
> +
> + default:
> + /* Unknown default to latest silicon rev as default*/
> + omap_revision = OMAP5430_REV_ES1_0;
> + }
> +
> + pr_info("OMAP%04x ES%d.0\n",
> + omap_rev() >> 16, ((omap_rev() >> 12) & 0xf));
> +}
> +
> /*
> * Set up things for map_io and processor detection later on. Gets called
> * pretty much first thing from board init. For multi-omap, this gets
> diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
> index 14f050f..e2d911d 100644
> --- a/arch/arm/plat-omap/include/plat/cpu.h
> +++ b/arch/arm/plat-omap/include/plat/cpu.h
> @@ -9,7 +9,7 @@
> *
> * Written by Tony Lindgren <tony.lindgren@nokia.com>
> *
> - * Added OMAP4 specific defines - Santosh Shilimkar<santosh.shilimkar@ti.com>
> + * Added OMAP4/5 specific defines - Santosh Shilimkar<santosh.shilimkar@ti.com>
> *
> * This program is free software; you can redistribute it and/or modify
> * it under the terms of the GNU General Public License as published by
> @@ -70,6 +70,7 @@ unsigned int omap_rev(void);
> * cpu_is_omap443x(): True for OMAP4430
> * cpu_is_omap446x(): True for OMAP4460
> * cpu_is_omap447x(): True for OMAP4470
> + * soc_is_omap543x(): True for OMAP5430, OMAP5432
> */
> #define GET_OMAP_CLASS (omap_rev() & 0xff)
>
> @@ -122,6 +123,7 @@ IS_OMAP_CLASS(24xx, 0x24)
> IS_OMAP_CLASS(34xx, 0x34)
> IS_OMAP_CLASS(44xx, 0x44)
> IS_AM_CLASS(35xx, 0x35)
> +IS_OMAP_CLASS(54xx, 0x54)
> IS_AM_CLASS(33xx, 0x33)
>
> IS_TI_CLASS(81xx, 0x81)
> @@ -133,6 +135,7 @@ IS_OMAP_SUBCLASS(363x, 0x363)
> IS_OMAP_SUBCLASS(443x, 0x443)
> IS_OMAP_SUBCLASS(446x, 0x446)
> IS_OMAP_SUBCLASS(447x, 0x447)
> +IS_OMAP_SUBCLASS(543x, 0x543)
>
> IS_TI_SUBCLASS(816x, 0x816)
> IS_TI_SUBCLASS(814x, 0x814)
> @@ -156,6 +159,8 @@ IS_AM_SUBCLASS(335x, 0x335)
> #define cpu_is_omap443x() 0
> #define cpu_is_omap446x() 0
> #define cpu_is_omap447x() 0
> +#define soc_is_omap54xx() 0
> +#define soc_is_omap543x() 0
>
> #if defined(MULTI_OMAP1)
> # if defined(CONFIG_ARCH_OMAP730)
> @@ -291,6 +296,7 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define cpu_is_omap2430() 0
> #define cpu_is_omap3430() 0
> #define cpu_is_omap3630() 0
> +#define soc_is_omap5430() 0
>
> /*
> * Whether we have MULTI_OMAP1 or not, we still need to distinguish
> @@ -371,11 +377,18 @@ IS_OMAP_TYPE(3430, 0x3430)
> # define cpu_is_omap447x() is_omap447x()
> # endif
>
> +# if defined(CONFIG_SOC_OMAP5)
> +# undef soc_is_omap54xx
> +# undef soc_is_omap543x
> +# define soc_is_omap54xx() is_omap54xx()
> +# define soc_is_omap543x() is_omap543x()
> +#endif
> +
> /* Macros to detect if we have OMAP1 or OMAP2 */
> #define cpu_class_is_omap1() (cpu_is_omap7xx() || cpu_is_omap15xx() || \
> cpu_is_omap16xx())
> #define cpu_class_is_omap2() (cpu_is_omap24xx() || cpu_is_omap34xx() || \
> - cpu_is_omap44xx())
> + cpu_is_omap44xx() || soc_is_omap54xx())
>
> /* Various silicon revisions for omap2 */
> #define OMAP242X_CLASS 0x24200024
> @@ -428,9 +441,14 @@ IS_OMAP_TYPE(3430, 0x3430)
> #define OMAP447X_CLASS 0x44700044
> #define OMAP4470_REV_ES1_0 (OMAP447X_CLASS | (0x10 << 8))
>
> +#define OMAP54XX_CLASS 0x54000054
> +#define OMAP5430_REV_ES1_0 (OMAP54XX_CLASS | (0x30 << 16) | (0x10 << 8))
> +#define OMAP5432_REV_ES1_0 (OMAP54XX_CLASS | (0x32 << 16) | (0x10 << 8))
> +
> void omap2xxx_check_revision(void);
> void omap3xxx_check_revision(void);
> void omap4xxx_check_revision(void);
> +void omap5xxx_check_revision(void);
> void omap3xxx_check_features(void);
> void ti81xx_check_features(void);
> void omap4xxx_check_features(void);
>
^ permalink raw reply
* [RFC 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain
From: Santosh Shilimkar @ 2012-11-02 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKfTPtB4CBVZDLeRsqENUgZuefpG8+7g-oyPRMyY5J2iRJuEOA@mail.gmail.com>
On Monday 29 October 2012 03:20 PM, Vincent Guittot wrote:
> It looks like i need to describe more what
>
> On 29 October 2012 10:40, Vincent Guittot <vincent.guittot@linaro.org> wrote:
>> On 24 October 2012 17:17, Santosh Shilimkar <santosh.shilimkar@ti.com> wrote:
>>> Vincent,
>>>
>>> Few comments/questions.
>>>
>>>
>>> On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
>>>>
>>>> This new flag SD SHARE_POWERLINE reflects the sharing of the power rail
>>>> between the members of a domain. As this is the current assumption of the
>>>> scheduler, the flag is added to all sched_domain
>>>>
>>>> Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
>>>> ---
>>>> arch/ia64/include/asm/topology.h | 1 +
>>>> arch/tile/include/asm/topology.h | 1 +
>>>> include/linux/sched.h | 1 +
>>>> include/linux/topology.h | 3 +++
>>>> kernel/sched/core.c | 5 +++++
>>>> 5 files changed, 11 insertions(+)
>>>>
>>>> diff --git a/arch/ia64/include/asm/topology.h
>>>> b/arch/ia64/include/asm/topology.h
>>>> index a2496e4..065c720 100644
>>>> --- a/arch/ia64/include/asm/topology.h
>>>> +++ b/arch/ia64/include/asm/topology.h
>>>> @@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
>>>> | SD_BALANCE_EXEC \
>>>> | SD_BALANCE_FORK \
>>>> | SD_WAKE_AFFINE, \
>>>> + | arch_sd_share_power_line() \
>>>> .last_balance = jiffies, \
>>>> .balance_interval = 1, \
>>>> .nr_balance_failed = 0, \
>>>> diff --git a/arch/tile/include/asm/topology.h
>>>> b/arch/tile/include/asm/topology.h
>>>> index 7a7ce39..d39ed0b 100644
>>>> --- a/arch/tile/include/asm/topology.h
>>>> +++ b/arch/tile/include/asm/topology.h
>>>> @@ -72,6 +72,7 @@ static inline const struct cpumask *cpumask_of_node(int
>>>> node)
>>>> | 0*SD_PREFER_LOCAL \
>>>> | 0*SD_SHARE_CPUPOWER \
>>>> | 0*SD_SHARE_PKG_RESOURCES \
>>>> + | arch_sd_share_power_line() \
>>>> | 0*SD_SERIALIZE \
>>>> , \
>>>> .last_balance = jiffies, \
>>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>>> index 4786b20..74f2daf 100644
>>>> --- a/include/linux/sched.h
>>>> +++ b/include/linux/sched.h
>>>> @@ -862,6 +862,7 @@ enum cpu_idle_type {
>>>> #define SD_WAKE_AFFINE 0x0020 /* Wake task to waking CPU
>>>> */
>>>> #define SD_PREFER_LOCAL 0x0040 /* Prefer to keep tasks
>>>> local to this domain */
>>>> #define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power
>>>> */
>>>> +#define SD_SHARE_POWERLINE 0x0100 /* Domain members share power
>>>> domain */
>>>
>>> If you ignore the current use of SD_SHARE_CPUPOWER, isn't the meaning of
>>> CPUPOWER and POWERLINE is same here. Just trying to understand the clear
>>> meaning of this new flag. Have you not considered SD_SHARE_CPUPOWER
>>> because it is being used for cpu_power and needs at least minimum two
>>> domains ? SD_PACKING would have been probably more appropriate based
>>> on the way it is being used in further series.
>>
>> CPUPOWER reflects the share of hw ressources between cores like for
>> hyper threading. POWERLINE describes the fact that cores are sharing
>> the same power line amore precisely the powergate.
>
> Sorry, the mail has been sent too early while I was writing it
>
> CPUPOWER reflects the share of hw ressources between cores like for
> hyper threading. POWERLINE describes the fact that cores are sharing
> the same power line and more precisely the same power gating. It looks
> like I need to describe more precisely what i would mean with
> SHARE_POWERLINE.
>
Yes. More description will help. I see bit of overlap POWERLINE
flag with SD_SHARE_CPUPOWER and SD_SHARE_PKG_RESOURCES and hence
the questions.
> I don't want to use PACKING because it's more a behavior than a
> feature. If cores can power gate independently (!SD_SHARE_POWERLINE),
> packing small tasks is one interesting behavior but it may be not the
> only one. I want to make a difference between the HW configuration and
> the behavior we want to have above it
>
Fair enough. Thanks for clarification.
Regards,
Santosh
^ permalink raw reply
* [PATCH] ARM: S3C64XX: Fix up IRQ mapping for balblair on Cragganmore
From: Dimitris Papastamos @ 2012-11-02 10:38 UTC (permalink / raw)
To: linux-arm-kernel
We are using S3C_EINT(4) instead of S3C_EINT(5).
Change-Id: Ia197069ddc736813f2711c763469eaf655ea58ac
Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
---
arch/arm/mach-s3c64xx/mach-crag6410-module.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410-module.c b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
index 4744c42..c6d8dba 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410-module.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410-module.c
@@ -60,7 +60,7 @@ static struct spi_board_info balblair_devs[] = {
.bus_num = 0,
.chip_select = 0,
.mode = SPI_MODE_0,
- .irq = S3C_EINT(5),
+ .irq = S3C_EINT(4),
.controller_data = &wm0010_spi_csinfo,
.platform_data = &wm0010_pdata,
},
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] i2c: omap: revision register updates
From: Shubhrajyoti D @ 2012-11-02 10:39 UTC (permalink / raw)
To: linux-arm-kernel
Does the followiing
- Make the revision a 32- bit consisting of rev_lo amd rev_hi each
of 16 bits.
- Also use the revision register for the erratum i207.
Also more cleanup is possible will check on that subsequently.
Tested on OMAP4430sdp ,4460 ,omap3630 and 3430.
todo: omap2 testing.
Shubhrajyoti D (2):
i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
i2c: omap: Fix the revision register read
drivers/i2c/busses/i2c-omap.c | 62 +++++++++++++++++++++++++++++++---------
1 files changed, 48 insertions(+), 14 deletions(-)
--
1.7.5.4
^ permalink raw reply
* [PATCH 1/2] i2c: omap: Fix the revision register read
From: Shubhrajyoti D @ 2012-11-02 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852785-16961-1-git-send-email-shubhrajyoti@ti.com>
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.
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.
Also since the omap_i2c_read_reg uses reg_map_ip_* a raw_readw is done
to fetch the revision register.
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.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 59 ++++++++++++++++++++++++++++++++---------
1 files changed, 46 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index db31eae..d8e7709 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -49,9 +49,10 @@
#define OMAP_I2C_OMAP1_REV_2 0x20
/* 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_2430 0x00000036
+#define OMAP_I2C_REV_ON_3430_3530 0x0000003C
+#define OMAP_I2C_REV_ON_3630 0x00000040
+#define OMAP_I2C_REV_ON_4430_PLUS 0x50400002
/* 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;
+ u32 rev;
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 */
@@ -1052,6 +1053,14 @@ static const struct of_device_id omap_i2c_of_match[] = {
MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
#endif
+#define OMAP_I2C_SCHEME(rev) (rev & 0xc000) >> 14
+
+#define OMAP_I2C_REV_SCHEME_0_MAJOR(rev) (rev >> 4)
+#define OMAP_I2C_REV_SCHEME_0_MINOR(rev) (rev & 0xf)
+
+#define OMAP_I2C_REV_SCHEME_1_MAJOR(rev) ((rev & 0x0700) >> 7)
+#define OMAP_I2C_REV_SCHEME_1_MINOR(rev) (rev & 0x1f)
+
static int __devinit
omap_i2c_probe(struct platform_device *pdev)
{
@@ -1064,6 +1073,8 @@ omap_i2c_probe(struct platform_device *pdev)
const struct of_device_id *match;
int irq;
int r;
+ u32 rev;
+ u16 minor, major;
/* NOTE: driver uses the static register mapping */
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -1117,11 +1128,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 +1136,31 @@ 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-[15:14] ie scheme this is 1 indicates ver2.
+ * On omap3 Offset 4 is IE Reg the bit [15:14] is XDR_IE which is 0
+ * at reset. Also since the omap_i2c_read_reg uses reg_map_ip_* a
+ * raw_readw is done.
+ */
+ rev = __raw_readw(dev->base + 0x04);
+
+ switch (OMAP_I2C_SCHEME(rev)) {
+ case 0:
+ dev->regs = (u8 *)reg_map_ip_v1;
+ dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
+ minor = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
+ major = OMAP_I2C_REV_SCHEME_0_MAJOR(dev->rev);
+ break;
+ case 1:
+ /* FALLTHROUGH */
+ default:
+ dev->regs = (u8 *)reg_map_ip_v2;
+ rev = (rev << 16) |
+ omap_i2c_read_reg(dev, OMAP_I2C_IP_V2_REVNB_LO);
+ minor = OMAP_I2C_REV_SCHEME_1_MINOR(rev);
+ major = OMAP_I2C_REV_SCHEME_1_MAJOR(rev);
+ dev->rev = rev;
+ }
dev->errata = 0;
@@ -1155,7 +1185,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 */
@@ -1198,7 +1228,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev_info(dev->dev, "bus %d rev%d.%d.%d at %d kHz\n", adap->nr,
- dev->dtrev, dev->rev >> 4, dev->rev & 0xf, dev->speed);
+ dev->dtrev, major, minor, dev->speed);
of_i2c_register_devices(adap);
@@ -1264,6 +1294,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;
+
if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] i2c: omap: use revision check for OMAP_I2C_FLAG_APPLY_ERRATA_I207
From: Shubhrajyoti D @ 2012-11-02 10:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1351852785-16961-1-git-send-email-shubhrajyoti@ti.com>
The errata i207 is enabled for 2430 and 3xxx. Use the revision check
to enable the erratum instead.
Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com>
---
drivers/i2c/busses/i2c-omap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d8e7709..44245d4 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1164,7 +1164,8 @@ omap_i2c_probe(struct platform_device *pdev)
dev->errata = 0;
- if (dev->flags & OMAP_I2C_FLAG_APPLY_ERRATA_I207)
+ if (dev->rev >= OMAP_I2C_REV_ON_2430 &&
+ dev->rev < OMAP_I2C_REV_ON_4430_PLUS)
dev->errata |= I2C_OMAP_ERRATA_I207;
if (dev->rev <= OMAP_I2C_REV_ON_3430_3530)
--
1.7.5.4
^ permalink raw reply related
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