Re: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
On 13/10/15 09:45, Roger Quadros wrote:
> Ben,
>
> On 13/10/15 11:23, Ben Dooks wrote:
>> On 12/10/15 20:19, Tony Lindgren wrote:
>>> * Ben Dooks [151012 11:22]:
>>>> On 12/10/15 18:45, Tony Lindgren wrote:
>>>>> * Ben Dooks [151012 10:38]:
>>>>>> The AM3715 OHCI controller will not function without the EHCI
>>>>>> unit's 120m fclk being enabled. If all the ports in the system
>>>>>> are set to OHCI then the 120m_fclk will not get enabled and no
>>>>>> devices are detected.
>>>>>>
>>>>>> Add a new (optional) property to signal the system must enable
>>>>>> the 120m_fck for OHCI so that if no EHCI ports are signalled
>>>>>> then the 120m_fclk should be enabled.
>>>>>>
>>>>>> We have found no information about why this is necessary, but
>>>>>> it is suspected the EHCI controller does not complete the initial
>>>>>> reset sequence and therefore does not hand control of the USB
>>>>>> port back.
>>>>>>
>>>>>> Signed-off-by: Ben Dooks
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>>>>>> drivers/mfd/omap-usb-host.c| 4
>>>>>> 2 files changed, 7 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>>>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>>>> index 38d9bb8..fb5fea5 100644
>>>>>> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>>>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>>>> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>>>>>> Optional properties:
>>>>>> - ctrl-module : phandle of the control module this glue uses to write
>>>>>> to
>>>>>> mailbox
>>>>>> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if
>>>>>> just
>>>>>> + using ohci. Needed for AM3517 in OHCI only mode.
>>>>>> +
>>>>>>
>>>>>> SOC specific device node entry
>>>>>> usb_otg_hs: usb_otg_hs@4a0ab000 {
>>>>>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>>>>>> index 1d924d1..13880cf 100644
>>>>>> --- a/drivers/mfd/omap-usb-host.c
>>>>>> +++ b/drivers/mfd/omap-usb-host.c
>>>>>> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device
>>>>>> *pdev)
>>>>>> need_logic_fck |= true;
>>>>>> }
>>>>>>
>>>>>> +/* The AM3517 requries the 120m-fck active to allow the
>>>>>> OHCI to work */
>>>>>> +if (of_property_read_bool(dev->of_node,
>>>>>> "ti,ohci-needs-120m-fck"))
>>>>>> +need_logic_fck |= true;
>>>>>> +
>>>>>> if (need_logic_fck) {
>>>>>> omap->ehci_logic_fck = devm_clk_get(dev,
>>>>>>
>>>>>> "usbhost_120m_fck");
>>>>>
>>>>> Hmm why not just use the standard device tree clocks property and then do
>>>>> clk_get_rate() on the clock?
>>>>
>>>> I don't see that helps enabling the clock. The code decideds if
>>>> no EHCI ports in use that it doesn't need to enable the EHCI fclk.
>>>
>>> Right, you need to do clk_prepare_enable() in it first? :)
>>
>> No, if that was the case the driver would never work for the EHCI case.
>>
>> The issue is:
>>
>> 1) All ports on the system are set to OHCI
>> 2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
>> 3) The OHCI fails to detect any devices due to point 2.
>>
>
> Instead of your existing approach why not just modify the preceeding
> if condition that sets need_logic_fck to suit the OHCI case.
>
> That way you don't need to add a new DT binding.
>
> The old assumption was that 120m_fck logic clock is only needed for
> EHCI mode but it looks like OHCI mode needs it as well.
>
> You should also rename omap->ehci_logic_fck to omap->hci_logic_fck
> as it is no longer ehci specific.
Thanks, will go and have a look at the manual later as didn't see two
separate 120m clocks when looking.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
On 12/10/15 20:19, Tony Lindgren wrote:
> * Ben Dooks [151012 11:22]:
>> On 12/10/15 18:45, Tony Lindgren wrote:
>>> * Ben Dooks [151012 10:38]:
>>>> The AM3715 OHCI controller will not function without the EHCI
>>>> unit's 120m fclk being enabled. If all the ports in the system
>>>> are set to OHCI then the 120m_fclk will not get enabled and no
>>>> devices are detected.
>>>>
>>>> Add a new (optional) property to signal the system must enable
>>>> the 120m_fck for OHCI so that if no EHCI ports are signalled
>>>> then the 120m_fclk should be enabled.
>>>>
>>>> We have found no information about why this is necessary, but
>>>> it is suspected the EHCI controller does not complete the initial
>>>> reset sequence and therefore does not hand control of the USB
>>>> port back.
>>>>
>>>> Signed-off-by: Ben Dooks
>>>> ---
>>>> Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>>>> drivers/mfd/omap-usb-host.c| 4
>>>> 2 files changed, 7 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>> index 38d9bb8..fb5fea5 100644
>>>> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>>>> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>>>> Optional properties:
>>>> - ctrl-module : phandle of the control module this glue uses to write to
>>>> mailbox
>>>> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
>>>> + using ohci. Needed for AM3517 in OHCI only mode.
>>>> +
>>>>
>>>> SOC specific device node entry
>>>> usb_otg_hs: usb_otg_hs@4a0ab000 {
>>>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>>>> index 1d924d1..13880cf 100644
>>>> --- a/drivers/mfd/omap-usb-host.c
>>>> +++ b/drivers/mfd/omap-usb-host.c
>>>> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device
>>>> *pdev)
>>>>need_logic_fck |= true;
>>>>}
>>>>
>>>> + /* The AM3517 requries the 120m-fck active to allow the OHCI to
>>>> work */
>>>> + if (of_property_read_bool(dev->of_node,
>>>> "ti,ohci-needs-120m-fck"))
>>>> + need_logic_fck |= true;
>>>> +
>>>>if (need_logic_fck) {
>>>>omap->ehci_logic_fck = devm_clk_get(dev,
>>>>"usbhost_120m_fck");
>>>
>>> Hmm why not just use the standard device tree clocks property and then do
>>> clk_get_rate() on the clock?
>>
>> I don't see that helps enabling the clock. The code decideds if
>> no EHCI ports in use that it doesn't need to enable the EHCI fclk.
>
> Right, you need to do clk_prepare_enable() in it first? :)
No, if that was the case the driver would never work for the EHCI case.
The issue is:
1) All ports on the system are set to OHCI
2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
3) The OHCI fails to detect any devices due to point 2.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
On 12/10/15 18:45, Tony Lindgren wrote:
> * Ben Dooks [151012 10:38]:
>> The AM3715 OHCI controller will not function without the EHCI
>> unit's 120m fclk being enabled. If all the ports in the system
>> are set to OHCI then the 120m_fclk will not get enabled and no
>> devices are detected.
>>
>> Add a new (optional) property to signal the system must enable
>> the 120m_fck for OHCI so that if no EHCI ports are signalled
>> then the 120m_fclk should be enabled.
>>
>> We have found no information about why this is necessary, but
>> it is suspected the EHCI controller does not complete the initial
>> reset sequence and therefore does not hand control of the USB
>> port back.
>>
>> Signed-off-by: Ben Dooks
>> ---
>> Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>> drivers/mfd/omap-usb-host.c| 4
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
>> b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> index 38d9bb8..fb5fea5 100644
>> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
>> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>> Optional properties:
>> - ctrl-module : phandle of the control module this glue uses to write to
>> mailbox
>> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
>> + using ohci. Needed for AM3517 in OHCI only mode.
>> +
>>
>> SOC specific device node entry
>> usb_otg_hs: usb_otg_hs@4a0ab000 {
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index 1d924d1..13880cf 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device
>> *pdev)
>> need_logic_fck |= true;
>> }
>>
>> +/* The AM3517 requries the 120m-fck active to allow the OHCI to
>> work */
>> +if (of_property_read_bool(dev->of_node,
>> "ti,ohci-needs-120m-fck"))
>> +need_logic_fck |= true;
>> +
>> if (need_logic_fck) {
>> omap->ehci_logic_fck = devm_clk_get(dev,
>> "usbhost_120m_fck");
>
> Hmm why not just use the standard device tree clocks property and then do
> clk_get_rate() on the clock?
I don't see that helps enabling the clock. The code decideds if
no EHCI ports in use that it doesn't need to enable the EHCI fclk.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
The AM3715 OHCI controller will not function without the EHCI
unit's 120m fclk being enabled. If all the ports in the system
are set to OHCI then the 120m_fclk will not get enabled and no
devices are detected.
Add a new (optional) property to signal the system must enable
the 120m_fck for OHCI so that if no EHCI ports are signalled
then the 120m_fclk should be enabled.
We have found no information about why this is necessary, but
it is suspected the EHCI controller does not complete the initial
reset sequence and therefore does not hand control of the USB
port back.
Signed-off-by: Ben Dooks
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
drivers/mfd/omap-usb-host.c| 4
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38d9bb8..fb5fea5 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -23,6 +23,9 @@ OMAP MUSB GLUE
Optional properties:
- ctrl-module : phandle of the control module this glue uses to write to
mailbox
+ - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
+ using ohci. Needed for AM3517 in OHCI only mode.
+
SOC specific device node entry
usb_otg_hs: usb_otg_hs@4a0ab000 {
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 1d924d1..13880cf 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device *pdev)
need_logic_fck |= true;
}
+ /* The AM3517 requries the 120m-fck active to allow the OHCI to
work */
+ if (of_property_read_bool(dev->of_node,
"ti,ohci-needs-120m-fck"))
+ need_logic_fck |= true;
+
if (need_logic_fck) {
omap->ehci_logic_fck = devm_clk_get(dev,
"usbhost_120m_fck");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] clk: ti: fix dual-registration of uart4_ick
On 02/10/15 07:07, Tero Kristo wrote: > On 10/02/2015 03:15 AM, Stephen Boyd wrote: >> On 09/29, Ben Dooks wrote: >>> On the OMAP AM3517 platform the uart4_ick gets registered >>> twice, causing any power managment to /dev/ttyO3 to fail >>> when trying to wake the device up. >>> >>> This solves the following oops: >>> >>> [] Unhandled fault: external abort on non-linefetch (0x1028) at >>> 0xfa09e008 >>> [] PC is at serial_omap_pm+0x48/0x15c >>> [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c >>> >>> Cc: sta...@vger.kernel.org >>> Cc: mturque...@baylibre.com >>> Cc: sb...@codeaurora.org >>> Cc: linux-...@vger.kernel.org >>> Cc: linux-omap@vger.kernel.org >>> Cc: t-kri...@ti.com >>> Cc: linux-ker...@lists.codethink.co.uk >>> Signed-off-by: Ben Dooks >> >> Which patch broke this? Adding a Fixes: line will help us figure >> out where to backport this. >> > > The issue has been around since the legacy clock data code already, I am > not quite sure which initially broke it though. As such, we can use the Thanks, i've been off ill for the last two days so catching up on this. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] clk: ti: fix dual-registration of uart4_ick
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power managment to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
Cc: sta...@vger.kernel.org
Cc: mturque...@baylibre.com
Cc: sb...@codeaurora.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: t-kri...@ti.com
Cc: linux-ker...@lists.codethink.co.uk
Signed-off-by: Ben Dooks
--
v2:
- fix omap36xx series clock registration for uart4
---
drivers/clk/ti/clk-3xxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 5e12f32..8d94b97 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
@@ -523,6 +522,7 @@ static struct ti_dt_clk am35xx_clks[] = {
static struct ti_dt_clk omap36xx_clks[] = {
DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"),
DT_CLK(NULL, "uart4_fck", "uart4_fck"),
+ DT_CLK(NULL, "uart4_ick", "uart4_ick"),
{ .node_name = NULL },
};
--
2.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: fix dual-registration of uart4_ick
On 25/09/15 06:42, Tero Kristo wrote:
> On 09/23/2015 08:30 PM, Tony Lindgren wrote:
>> * Ben Dooks [150923 07:53]:
>>> On the OMAP AM3517 platform the uart4_ick gets registered
>>> twice, causing any power managment to /dev/ttyO3 to fail
>>> when trying to wake the device up.
>>>
>>> This solves the following oops:
>>>
>>> [] Unhandled fault: external abort on non-linefetch (0x1028) at
>>> 0xfa09e008
>>> [] PC is at serial_omap_pm+0x48/0x15c
>>> [] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
>>
>> No uart4 on 34xx/35xx, that got introduced with 36xx so:
>>
>> Acked-by: Tony Lindgren
>>
>>> Signed-off-by: Ben Dooks
>>> ---
>>> drivers/clk/ti/clk-3xxx.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
>>> index 5e12f32..2e7ef1f 100644
>>> --- a/drivers/clk/ti/clk-3xxx.c
>>> +++ b/drivers/clk/ti/clk-3xxx.c
>>> @@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
>>> DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
>>> DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
>>> DT_CLK(NULL, "uart3_ick", "uart3_ick"),
>>> -DT_CLK(NULL, "uart4_ick", "uart4_ick"),
>>> DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
>>> DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
>>> DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
>
> NAK.
>
> This patch is actually only partially correct, it removes the uart4_ick
> alias for omap36xx also. It should be added back to the omap36xx clks
> array. Care to post a v2?
Thankyou for the feedback. I'll update, but do not have a device to test.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 usb host issue
On 22/05/15 14:50, Felipe Balbi wrote: > Hi, > > On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote: >> I am trying to get the full-speed USB host working on an custom >> AM3517 device with the 3.18.12 kernel. The hardware works (a >> 2.6.37 kernel has been used for testing). >> >> Does anyone have any experience of 3.18 (or similarly recent >> kernel on an AM3517 system) or have any pointers as where to >> start debugging? The ti-linux-3.14.y does not have any patches >> that aren't applied to the usb on 3.18.13. >> >> The cpu port 1 is connected by a TI TUSB1106 usb transceiver >> that is directly connected to a full-speed hub (TI USB2046) hub >> so the OHCI driver is the only one in use. >> >> Note, the ohci-omap3 is loaded as a module as this is how their >> user application expects to be able to shut down usb when it >> does not need it. >> >> The device tree configuration for the usb host: > > and what exactly doesn't work ? That old OHCI driver hasn't been > touched in years, it's no surprise that it stopped working :-( > > Anyway, what exactly doesn't work ? No device enumerates ? Do you > get any IRQs by plugging a new device in ? I just found this in my backlog, and thought I should follow up with the issue. It turns out that even if we're not using the EHCI unit, the 120m functional clock needs to be enabled. This may be down to an internal routing of port signals, or the USB front-end needing it. I've added a local boolean fix to enable the clock, and will post it as soon as we've had a chance to review and document. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: ti: fix dual-registration of uart4_ick
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power managment to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
Signed-off-by: Ben Dooks
---
drivers/clk/ti/clk-3xxx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index 5e12f32..2e7ef1f 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -374,7 +374,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
--
2.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: errata 430973: move !ARCH_MULTIPLATFORM to Kconfig
On 27/07/15 02:14, Sebastian Reichel wrote: > Hi, > > On Sun, Jul 26, 2015 at 11:51:45PM +0100, Russell King - ARM Linux > wrote: >> On Fri, Jul 24, 2015 at 02:16:06AM +0200, Sebastian Reichel >> wrote: >>> On Thu, Jul 23, 2015 at 01:35:53PM +0100, Russell King - ARM >>> Linux wrote: >>>> On Thu, Jul 23, 2015 at 02:48:03AM +0200, Sebastian Reichel >>>> wrote: >>>>> Having the !ARCH_MULTIPLATFORM dependency in the Kconfig >>>>> file results in one option less to think about when >>>>> configuring the kernel. >>>> >>>>> -#if defined(CONFIG_ARM_ERRATA_430973) && >>>>> !defined(CONFIG_ARCH_MULTIPLATFORM) +#ifdef >>>>> CONFIG_ARM_ERRATA_430973 teq r3, #0x0010 @ only >>>>> present in r1p* mrceq p15, 0, r0, c1, c0, 1 @ read aux >>>>> control register orreqr0, r0, #(1 << 6) @ set IBE to 1 >>>> >>>> NAK. Please read the mailing list history, I'm not >>>> repeating myself again on this. Thanks. >>> >>> It's a bit hard to search the mailing list history without a >>> bit more information. >> >> You were Cc'd on the previous round of review... > > But that discussion was about removing the check alltogether iirc. > This patch does not remove the !ARCH_MULTIPLATFORM check. It just > *moves* it from the sourcecode to the errata's Kconfig entry. > > The intention was to hide the Kconfig option on multiplatform > kernels, since it's completely useless there after the N900 > boardcode has been changed (PATCH 1/3). > >>> I guess you prefer to just add the !ARCH_MULTIPLATFORM >>> dependency to the Kconfig entry without removing the >>> additional check in the code? >> >> I was referring to the above change. >> >> However, having discussed with Will Deacon and checked the >> manuals, I think the change is okay after all: the auxillary >> control register is banked on secure parts, and the bit we'll be >> trying to change will be read-only in non-secure mode - and >> importantly won't fault. >> >> So, the change is fine, thanks. > > I think you missed the part adding the !ARCH_MULTIPLATFORM > dependency in Kconfig for ARM_ERRATA_430973. I only removed the > check in the sourcecode, since it is no longer required with the > dependency being in Kconfig. > > So I guess there are 3 options now: > > 1. Add !ARCH_MULTIPLATFORM dependency to Kconfig, keep extra check > in the sourcecode 2. Add !ARCH_MULTIPLATFORM dependency to Kconfig, > remove extra check in the sourcecode 3. Remove !ARCH_MULTIPLATFORM > dependency alltogether > > I will send an appropriate patch, if you tell me your preferred > option. This isn't the only place ARM_ERRATA_430973 is used, and if you make it configurable on !ARCH_MULTIPLATFORM then it makes it impossible to use a ARCH_MULTIPLATFORM kernel on something that is an Cortex-A8. See arch/arm/mm/proc-v7-2level.S -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517 usb host issue
On 22/05/15 23:13, Ben Dooks wrote:
> On 22/05/15 16:50, Felipe Balbi wrote:
>> Hi,
>
>> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>>> I am trying to get the full-speed USB host working on an custom
>>> AM3517 device with the 3.18.12 kernel. The hardware works (a
>>> 2.6.37 kernel has been used for testing).
>>>
>>> Does anyone have any experience of 3.18 (or similarly recent
>>> kernel on an AM3517 system) or have any pointers as where to
>>> start debugging? The ti-linux-3.14.y does not have any patches
>>> that aren't applied to the usb on 3.18.13.
>>>
>>> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that
>>> is directly connected to a full-speed hub (TI USB2046) hub so the
>>> OHCI driver is the only one in use.
>>>
>>> Note, the ohci-omap3 is loaded as a module as this is how their
>>> user application expects to be able to shut down usb when it does
>>> not need it.
>>>
>>> The device tree configuration for the usb host:
>
>> and what exactly doesn't work ? That old OHCI driver hasn't been
>> touched in years, it's no surprise that it stopped working :-(
>
>> Anyway, what exactly doesn't work ? No device enumerates ? Do you
>> get any IRQs by plugging a new device in ?
>
> I will check the interrupts when I get back into the office.
>
> There is only one device (the hub) which isn't enumerating and is
> hard-wired on the board.
>
>>>> &usbhshost { status = "okay"; /* just in case it is started
>>>> disabled */
>>>>
>>>> port1-mode = "ohci-phy-6pin-dpdm"; };
>>>>
>>>> &usbhsohci { status = "okay"; };
>>>>
>>>> &usbhsehci { status = "disabled"; /* no ehci on board */ };
>>>
>>>
>>> The usb from the logs is as follows. Some extra debugging has
>>> been added to verify the device-tree settings:
>>>
>>>> [0.00] AM3517 ES1.1 (l2cache sgx neon)
>>>>
>>>>
>>>> [0.869706] usbcore: registered new interface driver usbfs
>>>> [0.874270] usbcore: registered new interface driver hub
>>>> [0.878592] usbcore: registered new device driver usb
>>>> [1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
>>>> TLL Controller [1.273000] usbhs_omap 48064000.usbhshost:
>>>> ports 0 [1.278291] usbhs_omap 48064000.usbhshost: port 0:
>>>> ohci-phy-6pin-dpdm [1.284476] usbhs_omap
>>>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
>>>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
>>>> [1.293628] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [1.298434] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x1009 [1.302730]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>> [1.307668] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_suspend [1.310142] stopping usb controller
>>>> [1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>> [1.423547] usbhs_omap 48064000.usbhshost: 3 ports
>>>> [1.429065] usbhs_omap 48064000.usbhshost: starting TI
>>>> HSUSB Controller [1.433831] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [1.438625] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x1009 [1.442921]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>> [1.448548] usbhs_omap 48064000.usbhshost:
>>>> omap_usbhs_rev1_hostconfig => [1.455034] usbhs_omap
>>>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
>>>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>>>> [1.462337] stopping usb controller
>>>> [1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>>> [1.575408] usbhs_omap 48064000.usbhshost: populating usb
>>>> sub nodes
>>>>
>>>> [ 77.609168] usbhs_omap 48064000.usbhshost:
>>>> usbhs_runtime_resume [ 77.613927] usbhs_omap
>>>> 48064000.usbhshost: sysconfig 0x1009 [ 77.618374]
>>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>>> [ 77.802694] usb usb1: New USB device found, idVendor=1d6b,
>>>> idProduct=0001 [ 77.816003] usb usb1: New USB device strings:
>>>> Mfr=3, Product=2, SerialNumber1 [ 77.827391] usb usb1:
>>>>
Re: AM3517 usb host issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22/05/15 16:50, Felipe Balbi wrote:
> Hi,
>
> On Fri, May 22, 2015 at 11:04:33AM +0300, Ben Dooks wrote:
>> I am trying to get the full-speed USB host working on an custom
>> AM3517 device with the 3.18.12 kernel. The hardware works (a
>> 2.6.37 kernel has been used for testing).
>>
>> Does anyone have any experience of 3.18 (or similarly recent
>> kernel on an AM3517 system) or have any pointers as where to
>> start debugging? The ti-linux-3.14.y does not have any patches
>> that aren't applied to the usb on 3.18.13.
>>
>> The cpu port 1 is connected by a TI TUSB1106 usb transceiver that
>> is directly connected to a full-speed hub (TI USB2046) hub so the
>> OHCI driver is the only one in use.
>>
>> Note, the ohci-omap3 is loaded as a module as this is how their
>> user application expects to be able to shut down usb when it does
>> not need it.
>>
>> The device tree configuration for the usb host:
>
> and what exactly doesn't work ? That old OHCI driver hasn't been
> touched in years, it's no surprise that it stopped working :-(
>
> Anyway, what exactly doesn't work ? No device enumerates ? Do you
> get any IRQs by plugging a new device in ?
I will check the interrupts when I get back into the office.
There is only one device (the hub) which isn't enumerating and is
hard-wired on the board.
>>> &usbhshost { status = "okay"; /* just in case it is started
>>> disabled */
>>>
>>> port1-mode = "ohci-phy-6pin-dpdm"; };
>>>
>>> &usbhsohci { status = "okay"; };
>>>
>>> &usbhsehci { status = "disabled"; /* no ehci on board */ };
>>
>>
>> The usb from the logs is as follows. Some extra debugging has
>> been added to verify the device-tree settings:
>>
>>> [0.00] AM3517 ES1.1 (l2cache sgx neon)
>>>
>>>
>>> [0.869706] usbcore: registered new interface driver usbfs
>>> [0.874270] usbcore: registered new interface driver hub
>>> [0.878592] usbcore: registered new device driver usb
>>> [1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB
>>> TLL Controller [1.273000] usbhs_omap 48064000.usbhshost:
>>> ports 0 [1.278291] usbhs_omap 48064000.usbhshost: port 0:
>>> ohci-phy-6pin-dpdm [1.284476] usbhs_omap
>>> 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm ->5 [
>>> 1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
>>> [1.293628] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [1.298434] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x1009 [1.302730]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>> [1.307668] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_suspend [1.310142] stopping usb controller
>>> [1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>> [1.423547] usbhs_omap 48064000.usbhshost: 3 ports
>>> [1.429065] usbhs_omap 48064000.usbhshost: starting TI
>>> HSUSB Controller [1.433831] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [1.438625] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x1009 [1.442921]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>> [1.448548] usbhs_omap 48064000.usbhshost:
>>> omap_usbhs_rev1_hostconfig => [1.455034] usbhs_omap
>>> 48064000.usbhshost: UHH setup done, uhh_hostconfig=80d [
>>> 1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>>> [1.462337] stopping usb controller
>>> [1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>>> [1.575408] usbhs_omap 48064000.usbhshost: populating usb
>>> sub nodes
>>>
>>> [ 77.609168] usbhs_omap 48064000.usbhshost:
>>> usbhs_runtime_resume [ 77.613927] usbhs_omap
>>> 48064000.usbhshost: sysconfig 0x1009 [ 77.618374]
>>> usbhs_tll 48062000.usbhstll: omap_tll_enable()
>>> [ 77.802694] usb usb1: New USB device found, idVendor=1d6b,
>>> idProduct=0001 [ 77.816003] usb usb1: New USB device strings:
>>> Mfr=3, Product=2, SerialNumber1 [ 77.827391] usb usb1:
>>> Product: OHCI Host Controller [ 77.838674] usb usb1:
>>> Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty ohci_d [
>>> 77.849913] usb usb1: SerialNumber: 48064400.ohci
>>>
>
> OK, so this is roothub, what happens when a device is plugged to
> the other end ? Is VBUS charged ? We didn
AM3517 usb host issue
I am trying to get the full-speed USB host working on an custom AM3517
device with the 3.18.12 kernel. The hardware works (a 2.6.37 kernel has
been used for testing).
Does anyone have any experience of 3.18 (or similarly recent kernel on
an AM3517 system) or have any pointers as where to start debugging? The
ti-linux-3.14.y does not have any patches that aren't applied to the
usb on 3.18.13.
The cpu port 1 is connected by a TI TUSB1106 usb transceiver that is
directly connected to a full-speed hub (TI USB2046) hub so the OHCI
driver is the only one in use.
Note, the ohci-omap3 is loaded as a module as this is how their user
application expects to be able to shut down usb when it does not need
it.
The device tree configuration for the usb host:
> &usbhshost {
> status = "okay";/* just in case it is started disabled */
>
> port1-mode = "ohci-phy-6pin-dpdm";
> };
>
> &usbhsohci {
> status = "okay";
> };
>
> &usbhsehci {
> status = "disabled";/* no ehci on board */
> };
The usb from the logs is as follows. Some extra debugging has been
added to verify the device-tree settings:
> [0.00] AM3517 ES1.1 (l2cache sgx neon)
>
>
> [0.869706] usbcore: registered new interface driver usbfs
>
> [0.874270] usbcore: registered new interface driver hub
>
> [0.878592] usbcore: registered new device driver usb
>
> [1.223199] usbhs_tll 48062000.usbhstll: starting TI HSUSB TLL Controller
>
> [1.273000] usbhs_omap 48064000.usbhshost: ports 0
>
> [1.278291] usbhs_omap 48064000.usbhshost: port 0: ohci-phy-6pin-dpdm
>
> [1.284476] usbhs_omap 48064000.usbhshost: port0-mode: ohci-phy-6pin-dpdm
> ->5
> [1.288689] usbhs_tll 48062000.usbhstll: omap_tll_init()
>
> [1.293628] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume
>
> [1.298434] usbhs_omap 48064000.usbhshost: sysconfig 0x1009
>
> [1.302730] usbhs_tll 48062000.usbhstll: omap_tll_enable()
>
> [1.307668] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>
> [1.310142] stopping usb controller
>
> [1.419910] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>
> [1.423547] usbhs_omap 48064000.usbhshost: 3 ports
>
> [1.429065] usbhs_omap 48064000.usbhshost: starting TI HSUSB Controller
>
> [1.433831] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume
>
> [1.438625] usbhs_omap 48064000.usbhshost: sysconfig 0x1009
>
> [1.442921] usbhs_tll 48062000.usbhstll: omap_tll_enable()
>
> [1.448548] usbhs_omap 48064000.usbhshost: omap_usbhs_rev1_hostconfig =>
>
> [1.455034] usbhs_omap 48064000.usbhshost: UHH setup done,
> uhh_hostconfig=80d
> [1.459918] usbhs_omap 48064000.usbhshost: usbhs_runtime_suspend
>
> [1.462337] stopping usb controller
>
> [1.569905] usbhs_tll 48062000.usbhstll: omap_tll_disable()
>
> [1.575408] usbhs_omap 48064000.usbhshost: populating usb sub nodes
>
>
> [ 77.609168] usbhs_omap 48064000.usbhshost: usbhs_runtime_resume
>
> [ 77.613927] usbhs_omap 48064000.usbhshost: sysconfig 0x1009
>
> [ 77.618374] usbhs_tll 48062000.usbhstll: omap_tll_enable()
>
> [ 77.802694] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001
>
> [ 77.816003] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber1
> [ 77.827391] usb usb1: Product: OHCI Host Controller
>
> [ 77.838674] usb usb1: Manufacturer: Linux 3.18.13-00203-ga3c52be-dirty
> ohci_d
> [ 77.849913] usb usb1: SerialNumber: 48064400.ohci
>
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 3/4] of/clk: Register clocks suitable for Runtime PM with the PM core
On 30/04/14 14:25, Laurent Pinchart wrote: On Tuesday 29 April 2014 14:16:10 Grant Likely wrote: On Fri, 25 Apr 2014 16:44:58 -0700, Kevin Hilman wrote: Geert Uytterhoeven writes: When adding a device from DT, check if its clocks are suitable for Runtime PM, and register them with the PM core. If Runtime PM is disabled, just enable the clock. This allows the PM core to automatically manage gate clocks of devices for Runtime PM. ...unless the device is already in an existing pm_domain, right? I like this approach, and it extends nicely what we already do on platforms using drivers/base/power/clock_ops.c into DT land. My only concern is how this will interact if it's used along with devices that have existing pm_domains. I don't have any specific concerns (yet, because it's Friday, and my brain is turing off), but it just made me wonder if this will be potentially confusing. I have big concerns about this approach. First, it will only work if a clock is available at deivce creation time. The conversion of irq controllers to normal device drivers has already shown that is a bad idea. I also don't like that it tries to set up every clock, but there is no guarantee that the driver will even use it. I would rather see this behaviour linked into the function that obtains the clock at driver .probe() time. That way it can handle deferred probe correctly and it only sets up clocks that are actually used by the driver. I like the idea, as it gives an opt-in approach to the problem: drivers could decide whether they want the runtime PM core to handle clocks automatically (which should cover most cases), but would have the option of handling clocks manually if needed for special purposes. If drivers could have a field to say that they allow the driver-core or the pm-runtime would mean that drivers could easily be change without having to deal with what the SoC/SoC family have to care about this. It would also mean that we could change drivers without having to make any changes to the SoC to say that it has to opt-in to the support. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 12:14, David Laight wrote: From: Ben Dooks On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? Yes. Why do you care which USB controller is driving the pins? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. I realised that wasn't what you were doing, but at first it did seem to be what you were doing. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. Some of those look like pcb design decisions - so there is no dynamic changing, just config time plumbing. OTOH we are carrying PCIe using two SATA cables (the second carries the clock) so I suspect some SoC system pcbs may be able to support SATA or PCIe on the same connector). Yes, which means we will probably want to support the case where the USB3 is routed out of the PCIe lanes. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: rename 'phy' field of 'struct usb_hcd' to 'transceiver'
On 10/04/14 11:49, Sergei Shtylyov wrote: On 10-04-2014 13:20, David Laight wrote: It doesn't do any pin muxing. It switches SoC internal USB signals between USB controllers. The pins remain the same. Doesn't something like that already happen for the companion USB1 controllers for USB2 ports? Did you mean USB 1.1 and USB 2.0 controllers by USB1 and USB2? That also doesn't sound like you are changing the PHY. I am changing one of the PHY registers that controls USB port (Renesas calls it channel) multiplexing. I'd have thought that would happen if you had a single controller that select between multiply PHY. No, it's not the case. There is an interesting case, the USB3 shares a PHY with a SATA and the PCIE and SATA also share a PHY on the R8A7790. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/2] ARM: OMAP: Add secure function omap_smc3() which calling instruction smc #1
On 08/09/13 09:43, Pali Rohár wrote:
Here is new version (v4) of omap secure part patch:
Other secure functions omap_smc1() and omap_smc2() calling instruction smc #0
but Nokia RX-51 board needs to call smc #1 for PPA access.
Signed-off-by: Ivaylo Dimitrov
Signed-off-by: Pali Rohár
---
diff --git a/arch/arm/mach-omap2/omap-secure.h
b/arch/arm/mach-omap2/omap-secure.h
index 0e72917..c4586f4 100644
--- a/arch/arm/mach-omap2/omap-secure.h
+++ b/arch/arm/mach-omap2/omap-secure.h
@@ -51,6 +51,7 @@
extern u32 omap_secure_dispatcher(u32 idx, u32 flag, u32 nargs,
u32 arg1, u32 arg2, u32 arg3, u32 arg4);
extern u32 omap_smc2(u32 id, u32 falg, u32 pargs);
+extern u32 omap_smc3(u32 id, u32 process, u32 flag, u32 pargs);
extern phys_addr_t omap_secure_ram_mempool_base(void);
extern int omap_secure_ram_reserve_memblock(void);
diff --git a/arch/arm/mach-omap2/omap-smc.S b/arch/arm/mach-omap2/omap-smc.S
index f6441c1..fd90125 100644
--- a/arch/arm/mach-omap2/omap-smc.S
+++ b/arch/arm/mach-omap2/omap-smc.S
@@ -1,9 +1,11 @@
/*
- * OMAP44xx secure APIs file.
+ * OMAP34xx and OMAP44xx secure APIs file.
*
* Copyright (C) 2010 Texas Instruments, Inc.
* Written by Santosh Shilimkar
*
+ * Copyright (C) 2012 Ivaylo Dimitrov
+ * Copyright (C) 2013 Pali Rohár
*
* This program is free software,you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -54,6 +56,23 @@ ENTRY(omap_smc2)
ldmfd sp!, {r4-r12, pc}
ENDPROC(omap_smc2)
+/**
+ * u32 omap_smc3(u32 service_id, u32 process_id, u32 flag, u32 pargs)
+ * Low level common routine for secure HAL and PPA APIs via smc #1
+ * r0 - @service_id: Secure Service ID
+ * r1 - @process_id: Process ID
+ * r2 - @flag: Flag to indicate the criticality of operation
+ * r3 - @pargs: Physical address of parameter list
+ */
+ENTRY(omap_smc3)
+ stmfd sp!, {r4-r11, lr}
+ mov r12, r0 @ Copy the secure service ID
I think you should save r12 in the call.
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.3 v2] I2C: OMAP: fix build breakage when CONFIG_OF is not set
On Wed, Feb 08, 2012 at 01:18:21PM +0200, Luciano Coelho wrote:
> Since commit 6145197 (i2c: OMAP: Add DT support for i2c controller),
> building i2c_omap.c breaks if CONFIG_OF is not set:
>
> drivers/i2c/busses/i2c-omap.c: In function 'omap_i2c_probe':
> drivers/i2c/busses/i2c-omap.c:1021: error: 'omap_i2c_of_match' undeclared
> (first use in this function)
> drivers/i2c/busses/i2c-omap.c:1021: error: (Each undeclared identifier is
> reported only once
> drivers/i2c/busses/i2c-omap.c:1021: error: for each function it appears in.)
>
> This is because the definition of omap_i2c_of_match is #ifdef'd on
> CONFIG_OF, but the usage of it is not.
>
> Since the places where omap_ic2_of_match are prepared to get NULL
> pointers if CONFIG_OF is not defined, we can simply define it to NULL.
>
> Cc: Benoit Cousson
> Signed-off-by: Luciano Coelho
> Reviewed-by: Felipe Balbi
> ---
> v2: changed the commit log to use abbrev sha and include the commit subject
>
> drivers/i2c/busses/i2c-omap.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index f713eac..fd200eb 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -979,6 +979,8 @@ static const struct of_device_id omap_i2c_of_match[] = {
> { },
> };
> MODULE_DEVICE_TABLE(of, omap_i2c_of_match);
> +#else
> +static const struct of_device_id *omap_i2c_of_match = NULL;
> #endif
of_match_ptr(_ptr) will go to NULL if CONFIG_OF is not set, use that please.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MAINTAINERS: List i2c-omap and i2c-davinci drivers
On Tue, Jan 10, 2012 at 03:36:40PM +0100, Jean Delvare wrote: > This will ensure that the right people and lists are notified when > these drivers are modified. sounds like a good idea. > Signed-off-by: Jean Delvare > Cc: Tony Lindgren > Cc: Sekhar Nori > Cc: Kevin Hilman > --- > If there are no objections, I'll send this to Linus quickly. > > MAINTAINERS |3 +++ > 1 file changed, 3 insertions(+) > > --- linux-3.3-rc0.orig/MAINTAINERS2012-01-10 15:24:37.0 +0100 > +++ linux-3.3-rc0/MAINTAINERS 2012-01-10 15:27:28.0 +0100 > @@ -4673,6 +4673,8 @@ Q: http://patchwork.kernel.org/project/l > T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git > S: Maintained > F: arch/arm/*omap*/ > +F: drivers/i2c/busses/i2c-omap.c > +F: include/linux/i2c-omap.h > > OMAP CLOCK FRAMEWORK SUPPORT > M: Paul Walmsley > @@ -5945,6 +5947,7 @@ L: davinci-linux-open-source@linux.davin > Q: http://patchwork.kernel.org/project/linux-davinci/list/ > S: Supported > F: arch/arm/mach-davinci > +F: drivers/i2c/busses/i2c-davinci.c > > SIS 190 ETHERNET DRIVER > M: Francois Romieu > > > -- > Jean Delvare > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] I2C: OMAP: misc. updates for v3.3
On Thu, Jan 05, 2012 at 04:13:51PM -0800, Kevin Hilman wrote: > Hi Ben, > > Here's a few OMAP I2C updates for the v3.3 merge window. ok, added these to my i2c-next and for-33/i2c/omap. > Thanks, > > Kevin > > The following changes since commit 3f6b2a8bd6e4ff43269d89066a9fe06a0e5ba961: > > I2C: OMAP: correct SYSC register offset for OMAP4 (2011-12-13 11:35:56 > -0800) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.3/i2c/misc > > Benoit Cousson (1): > i2c: OMAP: Add DT support for i2c controller > > Jan Weitzel (1): > I2C: OMAP: NACK without STP > > Documentation/devicetree/bindings/i2c/omap-i2c.txt | 30 ++ > drivers/i2c/busses/i2c-omap.c | 108 > +--- > 2 files changed, 99 insertions(+), 39 deletions(-) > create mode 100644 Documentation/devicetree/bindings/i2c/omap-i2c.txt > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: I2C: add devexit to the remove code
On Tue, Dec 20, 2011 at 12:55:59PM +0530, Shubhrajyoti D wrote:
> The omap_i2c_remove function may not be needed after
> device exit so the memory could be freed.
>
> Signed-off-by: Shubhrajyoti D
Will add this later.
> ---
> drivers/i2c/busses/i2c-omap.c |5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index fa23faa..2efdc6b 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -,8 +,7 @@ err_release_region:
> return r;
> }
>
> -static int
> -omap_i2c_remove(struct platform_device *pdev)
> +static int __devexit omap_i2c_remove(struct platform_device *pdev)
> {
> struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
> struct resource *mem;
> @@ -1161,7 +1160,7 @@ static struct dev_pm_ops omap_i2c_pm_ops = {
>
> static struct platform_driver omap_i2c_driver = {
> .probe = omap_i2c_probe,
> - .remove = omap_i2c_remove,
> + .remove = __devexit_p(omap_i2c_remove),
> .driver = {
> .name = "omap_i2c",
> .owner = THIS_MODULE,
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] I2C: OMAP: misc. cleanup for v3.2
On Mon, Sep 26, 2011 at 03:30:50PM -0700, Kevin Hilman wrote: > ping > > On 09/06/2011 03:31 PM, Kevin Hilman wrote: > >Hi Ben, > > > >On 08/23/2011 05:10 PM, Kevin Hilman wrote: > >>Ben, > >> > >>Here's one more I2C cleanup series for v3.2. > >> > >>It applies on top of my for_3.2/i2c-fixes branch just submitted. > >> > >>Please pull into your tree for linux-next. > > > >I see you pulled the other two, can you pull this one as well? I've tried, but it seems to note that everything is up to date. Is this a suitable branch to pull onto latest so I can reset my next tree? -- Ben -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] I2C: OMAP: major cleanup for v3.2 (was for v3.1)
On Tue, Aug 23, 2011 at 04:48:29PM -0700, Kevin Hilman wrote: > Ben, > > This series fell through the cracks for v3.1, so I've now rebased it > onto v3.1-rc3 and am submitting it for v3.2. It no longer has any > dependencies on OMAP trees, so could you please pull this into your tree > for linux-next? > > A few more OMAP I2C series will be coming on top of this one. Thanks, will do that tonight when preparing new -next. > Thanks, > > Kevin > > > The following changes since commit fcb8ce5cfe30ca9ca5c9a79cdfe26d1993e65e0c: > > Linux 3.1-rc3 (2011-08-22 11:42:53 -0700) > > are available in the git repository at: > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.2/i2c-andy > > Andy Green (12): > I2C: OMAP2+: Name registers in I2C IP V2 only accordingly > I2C: OMAP: add rev to omap i2c platform data > I2C: OMAP1: set IP revision in platform data > I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus > added > I2C: OMAP2+: use platform_data ip revision to select register map > I2C: OMAP2+: Solve array bounds overflow error on i2c idle > I2C: OMAP2+: address confused probed version naming > I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data > I2C: OMAP2+: Pass flags up to omap i2c platform_data as well > I2C: OMAP1: set i2c unit feature implementation flags in platform data > I2C: OMAP2+: Convert omap I2C driver to use feature implementation > flags from platform data > I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in > dev_info > > arch/arm/plat-omap/i2c.c | 27 +++ > drivers/i2c/busses/i2c-omap.c | 100 ++++++-- > include/linux/i2c-omap.h |2 + > 3 files changed, 84 insertions(+), 45 deletions(-) -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] OMAP4: I2C : I2C context save
On Tue, Jul 05, 2011 at 02:50:46PM +0530, Shubhrajyoti D wrote: > Currently the OMAP4 doesnot hit device off still the > driver may have support for it.Adding support for the > same. > > Signed-off-by: Shubhrajyoti D I guess since the previous set has been taken by Kevin then these will be too. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: I2C: Enable FIFO usage for OMAP4
On Tue, Jul 05, 2011 at 05:01:01PM -0700, Kevin Hilman wrote:
> Shubhrajyoti D writes:
>
> > Currently the fifo depth is set to zero for OMAP4 which disables
> > the FIFO usage. This patch enables the FIFO usage for I2C transactions
> > on OMAP4 also.
> >
> > Tested on omap4430 and 3430.
> >
> > Reported-By: Nishanth Menon
> > Signed-off-by: Shubhrajyoti D
> > ---
> > Rebased on top of the series by Andy Green
> > http://www.spinics.net/lists/linux-i2c/msg05632.html
>
> Thanks.
>
> This is v3.1 material, but would be nice to see a couple tested-by or
> acked-by tags from folks that are more actively using the I2C driver
> before merging
>
> Kevin
guess you'll be picking these up?
>
> > drivers/i2c/busses/i2c-omap.c | 11 ++-
> > 1 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index d53cd61..8f87a37 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -1068,13 +1068,14 @@ omap_i2c_probe(struct platform_device *pdev)
> > * size. This is to ensure that we can handle the status on int
> > * call back latencies.
> > */
> > - if (dev->rev >= OMAP_I2C_REV_ON_3530_4430) {
> > - dev->fifo_size = 0;
> > +
> > + dev->fifo_size = (dev->fifo_size / 2);
> > +
> > + if (dev->rev >= OMAP_I2C_REV_ON_3530_4430)
> > dev->b_hw = 0; /* Disable hardware fixes */
> > - } else {
> > - dev->fifo_size = (dev->fifo_size / 2);
> > + else
> > dev->b_hw = 1; /* Enable hardware fixes */
> > - }
> > +
> > /* calculate wakeup latency constraint for MPU */
> > if (dev->set_mpu_wkup_lat != NULL)
> > dev->latency = (100 * dev->fifo_size) /
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Tue, Jul 05, 2011 at 12:00:56PM -0700, Kevin Hilman wrote: > Hi Ben, > > On Mon, 2011-06-27 at 15:15 -0700, Kevin Hilman wrote: > > On Mon, 2011-06-27 at 15:12 -0700, Kevin Hilman wrote: > > > > > Ping. I don't see this in linux-next yet. > > > > > > Are you planning to queue this for v3.1? > > > > > > > Oops, pushed send too soon on this... > > > > As this series touches various data files in arch/arm/mach-omap2/* and > > we have a handful of other changes to that data for this merge window, I > > think it would be better for conflict avoidance if this series is merged > > via Tony's linux-omap tree. > > > > With your Ack, we'll merge it via OMAP. > > I see that the same day I sent this, you merged it into your next-i2c > branch. Guess I was too late with my request. > > As I mentioned above, we will have several conflicts with the > arch/arm/mach-omap2 changes in this series, so we would prefer to merge > them via the OMAP tree if at all possible so we can properly handle the > conflicts. > > Do you mind dropping it from your next-i2c so we can merge it via > linux-omap (with your Ack.) Yes, and if you could indicate all the other omap i2c patches and I'll add my ack to yours. Acked-by: Ben Dooks > Thanks, > > Kevin > > > > _______ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: > Ben, > > Please pull in this series from Andy Green for the next merge window. > > v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic > sanity testing against with the latest kernel. These look much more like functionality changes than actual fixes, and are much more suited for inclusion into -next for once the next stable release is out. > It's also available here for pulling: > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.1/i2c-andy > > Original cover letter from Andy below: > > The following series removes cpu_...() usage completely from the > omap-i2c driver by having decisions about functional implementation > choices in the SoC held in cpu-specific hwmod tables that are > already established, or for OMAP1 where there is no hwmod, set at > OMAP1-specific i2c bus addition time. > > Along the way it solves two issues with the existing implementation, > that only 16-bit accesses are documented to be allowed to the I2C > peripheral unit, and that due to a confusion in the existing driver > about whether it is faced with a newer IP version on OMAP3530, currently > it writes to a random non-existent I2C register at times on that > platform. As noted above there's rather lot of functionality change to go in with fixing bugs. Is there a possibility of just fixing as many problems without making a pile of changes? > The patch series is quite extended from the first try thanks to > comments from Benoit Cousson. > > This 3rd try is based on 2.6.38-rc8 as requested. > > Andy Green (18): > I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c > I2C: OMAP2+: Name registers in I2C IP V2 only accordingly > I2C: OMAP2+: Introduce I2C IP versioning constants > I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision > I2C: OMAP: add rev to omap i2c platform data > I2C: OMAP1: set IP revision in platform data > I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus > added > I2C: OMAP2+: use platform_data ip revision to select register map > I2C: OMAP2+: Solve array bounds overflow error on i2c idle > I2C: OMAP2+: address confused probed version naming > I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 > I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data > I2C: OMAP2+: Pass flags up to omap i2c platform_data as well > I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each > cpu_... test > I2C: OMAP2+: add correct functionality flags to all omap2plus i2c > dev_attr > I2C: OMAP1: set i2c unit feature implementation flags in platform > data > I2C: OMAP2+: Convert omap I2C driver to use feature implementation > flags from platform data > I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in > dev_info > > arch/arm/mach-omap2/omap_hwmod_2420_data.c |8 ++- > arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++ > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 - > arch/arm/plat-omap/i2c.c | 27 > arch/arm/plat-omap/include/plat/i2c.h |3 +- > drivers/i2c/busses/i2c-omap.c | 100 > +++- > include/linux/i2c-omap.h | 29 > 8 files changed, 153 insertions(+), 51 deletions(-) > > -- > 1.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/18] I2C: OMAP: I2C fixes, removal of cpu_is... from driver
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote: > Ben, > > Please pull in this series from Andy Green for the next merge window. I'll have a look through this set as soon as possible. > v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic > sanity testing against with the latest kernel. > > It's also available here for pulling: > > git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git > for_3.1/i2c-andy > > Original cover letter from Andy below: > > The following series removes cpu_...() usage completely from the > omap-i2c driver by having decisions about functional implementation > choices in the SoC held in cpu-specific hwmod tables that are > already established, or for OMAP1 where there is no hwmod, set at > OMAP1-specific i2c bus addition time. > > Along the way it solves two issues with the existing implementation, > that only 16-bit accesses are documented to be allowed to the I2C > peripheral unit, and that due to a confusion in the existing driver > about whether it is faced with a newer IP version on OMAP3530, currently > it writes to a random non-existent I2C register at times on that > platform. > > The patch series is quite extended from the first try thanks to > comments from Benoit Cousson. > > This 3rd try is based on 2.6.38-rc8 as requested. > > Andy Green (18): > I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c > I2C: OMAP2+: Name registers in I2C IP V2 only accordingly > I2C: OMAP2+: Introduce I2C IP versioning constants > I2C: OMAP2+: Tag all OMAP2+ hwmod defintions with I2C IP revision > I2C: OMAP: add rev to omap i2c platform data > I2C: OMAP1: set IP revision in platform data > I2C: OMAP2+: Pass hwmod rev knowledge via platform_data when i2c bus > added > I2C: OMAP2+: use platform_data ip revision to select register map > I2C: OMAP2+: Solve array bounds overflow error on i2c idle > I2C: OMAP2+: address confused probed version naming > I2C: OMAP2+: increase omap_i2c_dev_attr flags from u8 to u32 > I2C: OMAP1/OMAP2+: add flags field to omap i2c platform data > I2C: OMAP2+: Pass flags up to omap i2c platform_data as well > I2C: OMAP1/OMAP2+: create omap I2C functionality flags for each > cpu_... test > I2C: OMAP2+: add correct functionality flags to all omap2plus i2c > dev_attr > I2C: OMAP1: set i2c unit feature implementation flags in platform > data > I2C: OMAP2+: Convert omap I2C driver to use feature implementation > flags from platform data > I2C: OMAP1/OMAP2+: prepend I2C IP version to probed version shown in > dev_info > > arch/arm/mach-omap2/omap_hwmod_2420_data.c |8 ++- > arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++ > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 13 > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 18 - > arch/arm/plat-omap/i2c.c | 27 > arch/arm/plat-omap/include/plat/i2c.h |3 +- > drivers/i2c/busses/i2c-omap.c | 100 > +++- > include/linux/i2c-omap.h | 29 > 8 files changed, 153 insertions(+), 51 deletions(-) > > -- > 1.7.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/7] ARM / Samsung: Use struct syscore_ops for "core" power management
gt; {
> unsigned int tmp;
>
> @@ -304,7 +304,7 @@ static int osiris_pm_suspend(struct sys_
> return 0;
> }
>
> -static int osiris_pm_resume(struct sys_device *sd)
> +static void osiris_pm_resume(void)
> {
> if (pm_osiris_ctrl0 & OSIRIS_CTRL0_FIX8)
> __raw_writeb(OSIRIS_CTRL1_FIX8, OSIRIS_VA_CTRL1);
> @@ -312,8 +312,6 @@ static int osiris_pm_resume(struct sys_d
> __raw_writeb(pm_osiris_ctrl0, OSIRIS_VA_CTRL0);
>
> s3c_gpio_cfgpin(S3C2410_GPA(21), S3C2410_GPA21_nRSTOUT);
> -
> - return 0;
> }
>
> #else
> @@ -321,16 +319,11 @@ static int osiris_pm_resume(struct sys_d
> #define osiris_pm_resume NULL
> #endif
>
> -static struct sysdev_class osiris_pm_sysclass = {
> - .name = "mach-osiris",
> +static struct syscore_ops osiris_pm_syscore_ops = {
> .suspend= osiris_pm_suspend,
> .resume = osiris_pm_resume,
> };
>
> -static struct sys_device osiris_pm_sysdev = {
> - .cls= &osiris_pm_sysclass,
> -};
> -
> /* Link for DVS driver to TPS65011 */
>
> static void osiris_tps_release(struct device *dev)
> @@ -439,8 +432,7 @@ static void __init osiris_map_io(void)
>
> static void __init osiris_init(void)
> {
> - sysdev_class_register(&osiris_pm_sysclass);
> - sysdev_register(&osiris_pm_sysdev);
> + register_syscore_ops(&osiris_pm_syscore_ops);
>
> s3c_i2c0_set_platdata(NULL);
> s3c_nand_set_platdata(&osiris_nand_info);
> Index: linux-2.6/arch/arm/mach-s3c2412/mach-jive.c
> ===
> --- linux-2.6.orig/arch/arm/mach-s3c2412/mach-jive.c
> +++ linux-2.6/arch/arm/mach-s3c2412/mach-jive.c
> @@ -17,7 +17,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -486,7 +486,7 @@ static struct s3c2410_udc_mach_info jive
> /* Jive power management device */
>
> #ifdef CONFIG_PM
> -static int jive_pm_suspend(struct sys_device *sd, pm_message_t state)
> +static int jive_pm_suspend(void)
> {
> /* Write the magic value u-boot uses to check for resume into
>* the INFORM0 register, and ensure INFORM1 is set to the
> @@ -498,10 +498,9 @@ static int jive_pm_suspend(struct sys_de
> return 0;
> }
>
> -static int jive_pm_resume(struct sys_device *sd)
> +static void jive_pm_resume(void)
> {
> __raw_writel(0x0, S3C2412_INFORM0);
> - return 0;
> }
>
> #else
> @@ -509,16 +508,11 @@ static int jive_pm_resume(struct sys_dev
> #define jive_pm_resume NULL
> #endif
>
> -static struct sysdev_class jive_pm_sysclass = {
> - .name = "jive-pm",
> +static struct syscore_ops jive_pm_syscore_ops = {
> .suspend= jive_pm_suspend,
> .resume = jive_pm_resume,
> };
>
> -static struct sys_device jive_pm_sysdev = {
> - .cls= &jive_pm_sysclass,
> -};
> -
> static void __init jive_map_io(void)
> {
> s3c24xx_init_io(jive_iodesc, ARRAY_SIZE(jive_iodesc));
> @@ -536,10 +530,9 @@ static void jive_power_off(void)
>
> static void __init jive_machine_init(void)
> {
> - /* register system devices for managing low level suspend */
> + /* register system core operations for managing low level suspend */
>
> - sysdev_class_register(&jive_pm_sysclass);
> - sysdev_register(&jive_pm_sysdev);
> + register_syscore_ops(&jive_pm_syscore_ops);
>
> /* write our sleep configurations for the IO. Pull down all unused
>* IO, ensure that we have turned off all peripherals we do not
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
On Thu, Mar 10, 2011 at 06:17:02AM -0700, Paul Walmsley wrote: > Hi Ben, > > On Thu, 10 Mar 2011, Rajendra Nayak wrote: > > > On Thursday 10 March 2011 05:48 PM, Paul Walmsley wrote: > > > This patch is currently breaking boot on OMAP4430 ES2.0 Pandaboard, > > > so I've dropped it from the integration branch until it can be > > > debugged. Could you check it, please? > > > > > > The tag "integration-2.6.39-20110310-008" of > > > git://git.pwsan.com/linux-integration boots fine; it's got everything > > > but this patch. Then when this patch is applied, I2C problems show > > > up, and root (on MMC) doesn't mount. > > > > Looks like you are missing this patch which should fix the i2c > > timeouts.. > > Do you think you'll merge this patch: > >http://marc.info/?l=linux-omap&m=129924561819873&w=2 > > during the 2.6.39 window? If so, then I'll add Rajendra's clockdomain > patch back in to my 2.6.39 queue here; it seems to depend on the I2C > driver patch. see http://git.fluff.org/gitweb?p=bjdooks/linux.git;a=shortlog;h=refs/heads/for-2639-rc7/i2c-fixes awaiting linus. > - Paul > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup
On Fri, Mar 04, 2011 at 09:00:00AM -0800, Kevin Hilman wrote: > Rajendra Nayak writes: > > > For the I2C module to be wakeup capable, programming I2C_WE > > register (which was skipped for OMAP4430) is needed > > even on OMAP4. > > This fixes i2c controller timeouts which were seen recently > > with the static dependency being cleared between MPU and > > L4PER clockdomains. > > > > Signed-off-by: Rajendra Nayak > > --- > > Patch is based on 2.6.38-rc7 kernel. > > Acked-by: Kevin Hilman > > Ben, looks like another fix that should be queued for 2.6.38-rc. I'll put together the couple of fixes I've got and send them to Linus at the end of the weekend. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: Double clear of ARDY status in IRQ handler
On Tue, Feb 15, 2011 at 10:13:58AM +0530, J, KEERTHY wrote:
> On Tue, Feb 15, 2011 at 5:35 AM, Kevin Hilman wrote:
> > Keerthy writes:
> >
> >> From: Richard woodruff
> >>
> >> ProDB00017052 - ARDY interrupt reasserted after being cleared.
> >
> >> This errata caused intermittent i2c instabilty(1 error per 3 hours) on
> >> several
> >> customer platforms. After applying the workaround the intermittent errors
> >> were
> >> not seen. This is not captured in the usual errata documents.
> >
> > This (presumably internal) ProDB number above is meaningless in the
> > public changelog. In lieu of a public erratum number, just summarize
> > the erratum/instability seen, references to other relevant public
> > errata (if any) would be useful too. IOW, "instability" isn't quite
> > accurate enough. A more detailed description of the problem/instability
> > is needed.
> >
>
> Kevin,
>
> Yes the ProDB number is internal. I will remove it from the change log.
> I will add a more detailed description of the problem.
Leave it in a comment at the most, it might be useful, otherwise please
respond to Kevin's review and then it'll be ready to merge.
> --
> Regards and Thanks,
> Keerthy
>
>
> > Thanks,
> >
> > Kevin
> >
> >>
> >> The workaround is to have a double clear of ARDY status in
> >> irq handler.
> >>
> >> Signed-off-by: Richard woodruff
> >> Signed-off-by: Keerthy
> >> ---
> >> 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 445de08..9bcefae 100644
> >> --- a/drivers/i2c/busses/i2c-omap.c
> >> +++ b/drivers/i2c/busses/i2c-omap.c
> >> @@ -851,7 +851,8 @@ complete:
> >> OMAP_I2C_STAT_AL)) {
> >> omap_i2c_ack_stat(dev, stat &
> >> (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
> >> - OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
> >> + OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
> >> + OMAP_I2C_STAT_ARDY));
> >> omap_i2c_complete_cmd(dev, err);
> >> return IRQ_HANDLED;
> >> }
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: OMAP: fix static suspend vs. runtime suspend
On Thu, Jan 27, 2011 at 04:18:41PM -0800, Kevin Hilman wrote:
> When runtime PM is enabled, each OMAP i2c device is suspended after
> each i2c xfer. However, there are two cases when the static suspend
> methods must be used to ensure the devices are suspended:
>
> 1) runtime PM is disabled, either at compile time or dynamically
> via /sys/devices/.../power/control.
> 2) an i2c client driver uses i2c during it's suspend callback, thus
>leaving the i2c driver active (NOTE: runtime suspend transitions are
>disabled during system suspend, so i2c activity during system
>suspend will runtime resume the device, but not runtime (re)suspend it.)
>
> Since the actual work to suspend the device is handled by the
> subsytem, call the bus methods to take care of it.
>
> NOTE: This takes care of a known suspend problem on OMAP3 where the
> TWL RTC driver does i2c xfers during its suspend path leaving the i2c
> driver in an active state (since runtime suspend transistions are
> disabled.)
>
> Signed-off-by: Kevin Hilman
> ---
> Ben, this is a regression in 2.6.38 so hopefully this can be queued
> in the 2.6.38-rc cycle. Thanks.
Ok, after all the discussions should I keep it in my -rc queue?
> drivers/i2c/busses/i2c-omap.c | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index b605ff3..0541df9 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -1137,12 +1137,40 @@ omap_i2c_remove(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_SUSPEND
> +static int omap_i2c_suspend(struct device *dev)
> +{
> + if (!pm_runtime_suspended(dev))
> + if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_suspend)
> + dev->bus->pm->runtime_suspend(dev);
> +
> + return 0;
> +}
> +
> +static int omap_i2c_resume(struct device *dev)
> +{
> + if (!pm_runtime_suspended(dev))
> + if (dev->bus && dev->bus->pm && dev->bus->pm->runtime_resume)
> + dev->bus->pm->runtime_resume(dev);
> +
> + return 0;
> +}
> +
> +static struct dev_pm_ops omap_i2c_pm_ops = {
> + .suspend = omap_i2c_suspend,
> + .resume = omap_i2c_resume,
> +};
> +#else
> +#define omap_i2c_pm_ops NULL
> +#endif
> +
> static struct platform_driver omap_i2c_driver = {
> .probe = omap_i2c_probe,
> .remove = omap_i2c_remove,
> .driver = {
> .name = "omap_i2c",
> .owner = THIS_MODULE,
> + .pm = &omap_i2c_pm_ops,
> },
> };
>
> --
> 1.7.3.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
On Thu, Dec 09, 2010 at 10:18:48PM +, aaro.koski...@nokia.com wrote: > Hi, > > Kevin Hilman [khil...@deeprootsystems.com]: > > Ben Dooks writes: > > > Renaming stuff like this is going to have an impact on the userspace > > > as anyone looking through /sys's driver heirarchy is going to miss the > > > old name... > > > > > > It all depends if you really want to go ahead with this... > > > > Yes, we are aware of the userspace impact, but this name change makes > > all devices on OMAP have consistent names and actually improves the > > ability to have userspace tools have consistent naming as well. > > So there are no imporant users, or if there is, they are prepared for this > change? > > >> > drivers/i2c/busses/i2c-omap.c|4 ++-- > > What about the .c / .ko file name? Pretty much everything in the drivers/i2c/busses directory is named i2c-.c, and I would like to keep it that way. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
On Thu, Dec 09, 2010 at 10:18:48PM +, aaro.koski...@nokia.com wrote: > Hi, > > Kevin Hilman [khil...@deeprootsystems.com]: > > Ben Dooks writes: > > > Renaming stuff like this is going to have an impact on the userspace > > > as anyone looking through /sys's driver heirarchy is going to miss the > > > old name... > > > > > > It all depends if you really want to go ahead with this... > > > > Yes, we are aware of the userspace impact, but this name change makes > > all devices on OMAP have consistent names and actually improves the > > ability to have userspace tools have consistent naming as well. > > So there are no imporant users, or if there is, they are prepared for this > change? > > >> > drivers/i2c/busses/i2c-omap.c|4 ++-- > > What about the .c / .ko file name? Pretty much everyone is in the form of i2c-xxx.c, so I would prefer it to stay that way. -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
On Thu, Dec 09, 2010 at 08:55:28AM -0800, Kevin Hilman wrote:
> Ben,
>
> Benoit Cousson writes:
>
> > The convention for omap device naming is omap_XXX.
> >
> > Rename the device and driver name in order to stick
> > to this naming convention.
> >
> > Change device name in clock nodes as well.
> >
> > Signed-off-by: Benoit Cousson
> > c: Paul Walmsley
> > Cc: Kevin Hilman
> > Cc: Rajendra Nayak
> > Cc: Ben Dooks
Acked-by: Ben Dooks
> > ---
> > arch/arm/mach-omap1/clock_data.c |6 +++---
> > arch/arm/mach-omap2/clock2420_data.c |8
> > arch/arm/mach-omap2/clock2430_data.c |8
> > arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
> > arch/arm/mach-omap2/clock44xx_data.c | 16
> > arch/arm/plat-omap/i2c.c |2 +-
> > drivers/i2c/busses/i2c-omap.c|4 ++--
> > 7 files changed, 28 insertions(+), 28 deletions(-)
>
> [...]
>
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index 760b8be..9d09083 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
> > .probe = omap_i2c_probe,
> > .remove = omap_i2c_remove,
> > .driver = {
> > - .name = "i2c_omap",
> > + .name = "omap_i2c",
> > .owner = THIS_MODULE,
> > },
> > };
> > @@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
> > MODULE_AUTHOR("MontaVista Software, Inc. (and others)");
> > MODULE_DESCRIPTION("TI OMAP I2C bus adapter");
> > MODULE_LICENSE("GPL");
> > -MODULE_ALIAS("platform:i2c_omap");
> > +MODULE_ALIAS("platform:omap_i2c");
>
> With your ack for the name change in the driver, we can merge this
> through the OMAP tree with the other core changes.
>
> Thanks,
>
> Kevin
>
--
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] I2C: i2c-omap: Change device name: i2c_omap -> omap_i2c
On Thu, Dec 09, 2010 at 08:55:28AM -0800, Kevin Hilman wrote:
> Ben,
>
> > The convention for omap device naming is omap_XXX.
> >
> > Rename the device and driver name in order to stick
> > to this naming convention.
Renaming stuff like this is going to have an impact on the userspace
as anyone looking through /sys's driver heirarchy is going to miss the
old name...
It all depends if you really want to go ahead with this...
> > Change device name in clock nodes as well.
> >
> > Signed-off-by: Benoit Cousson
> > c: Paul Walmsley
> > Cc: Kevin Hilman
> > Cc: Rajendra Nayak
> > Cc: Ben Dooks
> > ---
> > arch/arm/mach-omap1/clock_data.c |6 +++---
> > arch/arm/mach-omap2/clock2420_data.c |8
> > arch/arm/mach-omap2/clock2430_data.c |8
> > arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
> > arch/arm/mach-omap2/clock44xx_data.c | 16
> > arch/arm/plat-omap/i2c.c |2 +-
> > drivers/i2c/busses/i2c-omap.c|4 ++--
> > 7 files changed, 28 insertions(+), 28 deletions(-)
>
> [...]
>
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index 760b8be..9d09083 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -1139,7 +1139,7 @@ static struct platform_driver omap_i2c_driver = {
> > .probe = omap_i2c_probe,
> > .remove = omap_i2c_remove,
> > .driver = {
> > - .name = "i2c_omap",
> > + .name = "omap_i2c",
> > .owner = THIS_MODULE,
> > },
> > };
> > @@ -1161,4 +1161,4 @@ module_exit(omap_i2c_exit_driver);
> > MODULE_AUTHOR("MontaVista Software, Inc. (and others)");
> > MODULE_DESCRIPTION("TI OMAP I2C bus adapter");
> > MODULE_LICENSE("GPL");
> > -MODULE_ALIAS("platform:i2c_omap");
> > +MODULE_ALIAS("platform:omap_i2c");
>
> With your ack for the name change in the driver, we can merge this
> through the OMAP tree with the other core changes.
>
> Thanks,
>
> Kevin
>
--
--
Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/
Large Hadron Colada: A large Pina Colada that makes the universe disappear.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-omap: Set latency requirements only once for several messages
On Thu, Nov 18, 2010 at 12:04:20PM +0200, Samu Onkalo wrote: > Ordinary I2C read consist of two messages. First a write operation > to tell register address and then read operation to get data. > CPU wake up latency is set and removed twice in read case. > Set latency requirement before the message processing loop > and remove the requirement after the loop to remove latency > adjustment operations between the messages. > > Signed-off-by: Samu Onkalo > Acked-by: Kevin Hilman > Acked-by: Paul Walmsley I'll queue this for -rc unless it is going in via the omap list or it should wait for merge window? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
On Thu, Oct 07, 2010 at 10:37:03AM -0700, Kevin Hilman wrote: > Ben Dooks writes: > > [...] > > > As such, I should really go and read up all about this new runtime-pm > > and hwmod stuff before further commentign on the changes. > > ping > > >From the drivers perspective, you don't neet to know anything about > omap_hwmod. You can think of this change as simply using the runtime PM > API instead of the clock API for enabling and idling the device. > > With your ack (on this patch only) we'd like to merge this along with > the rest of the series for 2.6.37. Acked-by: Ben Dooks please post via your tree. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
On Tue, Sep 28, 2010 at 12:29:01PM +0530, Nayak, Rajendra wrote:
> ...
> > > >
> > > > static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > @@ -356,6 +333,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > unsigned long fclk_rate = 1200;
> > > > unsigned long timeout;
> > > > unsigned long internal_clk = 0;
> > > > + struct clk *fclk;
> > > >
> > > > if (dev->rev >= OMAP_I2C_REV_2) {
> > > > /* Disable I2C controller before soft reset */
> > > > @@ -414,7 +392,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > * always returns 12MHz for the functional clock, we can
> > > > * do this bit unconditionally.
> > > > */
> > > > - fclk_rate = clk_get_rate(dev->fclk);
> > > > + fclk = clk_get(dev->dev, "fck");
> > > > + fclk_rate = clk_get_rate(fclk);
> > > >
> > > > /* TRM for 5912 says the I2C clock must be prescaled to
> > > > be
> > > > * between 7 - 12 MHz. The XOR input clock is typically
> > > > @@ -443,7 +422,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > internal_clk = 9600;
> > > > else
> > > > internal_clk = 4000;
> > > > - fclk_rate = clk_get_rate(dev->fclk) / 1000;
> > > > + fclk = clk_get(dev->dev, "fck");
> > > > + fclk_rate = clk_get_rate(fclk) / 1000;
> > >
> > > You don't put the clk after getting it and using it once?
> >
> > clk_get needs an equivalent clk_put and not clk_get_rate. clk_get_rate
> > is used to merely know the existing rate of the clock.
>
> Sorry, I guess you did mean the clk_get above the clk_get_rate does not have
> an equivalent clk_put.
> I could put a clk_put for readability, but a clk_put on OMAP actually does map
> to an empty function.
> See arch/arm/plat-omap/include/plat/clkdev.h
> clk_get merely returns a pointer to the clk struct and does not do any
> usecounting,
> hence a clk_put does not do anything.
clk_get() should have a reference counter, and on many systems does.
This is why we ask people to put clk_put() when they don't need the
clock any more. It may not do anything on your system, but it will
set a good example to anyone copying your driver code.
As such, I should really go and read up all about this new runtime-pm
and hwmod stuff before further commentign on the changes.
> >
> > >
> > > > /* Compute prescaler divisor */
> > > > psc = fclk_rate / internal_clk;
> > > > @@ -1046,14 +1026,12 @@ omap_i2c_probe(struct platform_device *pdev)
> > > > else
> > > > dev->reg_shift = 2;
> > > >
> > > > - if ((r = omap_i2c_get_clocks(dev)) != 0)
> > > > - goto err_iounmap;
> > > > -
> > > > if (cpu_is_omap44xx())
> > > > dev->regs = (u8 *) omap4_reg_map;
> > > > else
> > > > dev->regs = (u8 *) reg_map;
> > > >
> > > > + pm_runtime_enable(&pdev->dev);
> > > > omap_i2c_unidle(dev);
> > > >
> > > > dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> > > > @@ -1125,8 +1103,6 @@ err_free_irq:
> > > > err_unuse_clocks:
> > > > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> > > > omap_i2c_idle(dev);
> > > > - omap_i2c_put_clocks(dev);
> > > > -err_iounmap:
> > > > iounmap(dev->base);
> > > > err_free_mem:
> > > > platform_set_drvdata(pdev, NULL);
> > > > @@ -1148,7 +1124,6 @@ omap_i2c_remove(struct platform_device *pdev)
> > > > free_irq(dev->irq, dev);
> > > > i2c_del_adapter(&dev->adapter);
> > > > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> > > > - omap_i2c_put_clocks(dev);
> > > > iounmap(dev->base);
> > > > kfree(dev);
> > > > mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > --
> > > > 1.5.4.7
> > > >
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> > > > the body of a message to majord...@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> > > --
> > > --
> > > Ben
> > >
> > > Q: What's a light-year?
> > > A: One-third less calories than a regular year.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.
Re: [PATCH v3 5/5] OMAP: I2C: Convert i2c driver to use PM runtime api's
On Tue, Sep 21, 2010 at 07:37:16PM +0530, Rajendra Nayak wrote:
> This patch converts the i2c driver to use PM runtime apis
>
> Signed-off-by: Rajendra Nayak
> Cc: Kevin Hilman
> Cc: Paul Walmsley
> ---
> drivers/i2c/busses/i2c-omap.c | 67
> +
> 1 files changed, 21 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 7674efb..126bde9 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
>
> /* I2C controller revisions */
> #define OMAP_I2C_REV_2 0x20
> @@ -175,8 +176,6 @@ struct omap_i2c_dev {
> void __iomem*base; /* virtual */
> int irq;
> int reg_shift; /* bit shift for I2C register
> addresses */
> - struct clk *iclk; /* Interface clock */
> - struct clk *fclk; /* Functional clock */
> struct completion cmd_complete;
> struct resource *ioarea;
> u32 latency;/* maximum mpu wkup latency */
> @@ -265,45 +264,18 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
> *i2c_dev, int reg)
> (i2c_dev->regs[reg] << i2c_dev->reg_shift));
> }
>
> -static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> +static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> {
> - int ret;
> + struct platform_device *pdev;
> + struct omap_i2c_bus_platform_data *pdata;
>
> - dev->iclk = clk_get(dev->dev, "ick");
> - if (IS_ERR(dev->iclk)) {
> - ret = PTR_ERR(dev->iclk);
> - dev->iclk = NULL;
> - return ret;
> - }
> + WARN_ON(!dev->idle);
>
> - dev->fclk = clk_get(dev->dev, "fck");
> - if (IS_ERR(dev->fclk)) {
> - ret = PTR_ERR(dev->fclk);
> - if (dev->iclk != NULL) {
> - clk_put(dev->iclk);
> - dev->iclk = NULL;
> - }
> - dev->fclk = NULL;
> - return ret;
> - }
> + pdev = to_platform_device(dev->dev);
> + pdata = pdev->dev.platform_data;
>
> - return 0;
> -}
> + pm_runtime_get_sync(&pdev->dev);
>
> -static void omap_i2c_put_clocks(struct omap_i2c_dev *dev)
> -{
> - clk_put(dev->fclk);
> - dev->fclk = NULL;
> - clk_put(dev->iclk);
> - dev->iclk = NULL;
> -}
> -
> -static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> -{
> - WARN_ON(!dev->idle);
> -
> - clk_enable(dev->iclk);
> - clk_enable(dev->fclk);
> if (cpu_is_omap34xx()) {
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> @@ -326,10 +298,15 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> {
> + struct platform_device *pdev;
> + struct omap_i2c_bus_platform_data *pdata;
> u16 iv;
>
> WARN_ON(dev->idle);
>
> + pdev = to_platform_device(dev->dev);
> + pdata = pdev->dev.platform_data;
> +
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> if (dev->rev >= OMAP_I2C_REV_ON_4430)
> omap_i2c_write_reg(dev, OMAP_I2C_IRQENABLE_CLR, 1);
> @@ -345,8 +322,8 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> }
> dev->idle = 1;
> - clk_disable(dev->fclk);
> - clk_disable(dev->iclk);
> +
> + pm_runtime_put_sync(&pdev->dev);
> }
>
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> @@ -356,6 +333,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> unsigned long fclk_rate = 1200;
> unsigned long timeout;
> unsigned long internal_clk = 0;
> + struct clk *fclk;
>
> if (dev->rev >= OMAP_I2C_REV_2) {
> /* Disable I2C controller before soft reset */
> @@ -414,7 +392,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>* always returns 12MHz for the functional clock, we can
>* do this bit unconditionally.
>*/
> - fclk_rate = clk_get_rate(dev->fclk);
> + fclk = clk_get(dev->dev, "fck");
> + fclk_rate = clk_get_rate(fclk);
>
> /* TRM for 5912 says the I2C clock must be prescaled to be
>* between 7 - 12 MHz. The XOR input clock is typically
> @@ -443,7 +422,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> internal_clk = 9600;
> else
> internal_clk = 4000;
> - fclk_rate = clk_get_rate(dev->fclk) / 1000;
> + fclk = clk_get(dev->dev, "fck");
> + fclk_rate = clk_get_rate(fclk) / 1000;
You don't put the clk afte
Re: [PATCH] i2c-omap: Make sure i2c bus is free before setting it to idle
On Thu, Sep 16, 2010 at 03:40:50PM -0700, Tony Lindgren wrote: > * Felipe Balbi [100826 00:34]: > > Hi, > > > > On Thu, Aug 26, 2010 at 09:36:44AM +0200, Nyman Mathias (Nokia-MS/Helsinki) > > wrote: > > >If the i2c bus receives an interrupt with both BB (bus busy) and > > >ARDY (register access ready) statuses set during the tranfer of the last > > >message > > >the bus was put to idle while still busy. > > > > > >This caused bus to timeout. > > > > > >Signed-off-by: Mathias Nyman > > > > adding linux-i2c and Ben Dooks to Cc list. > > Ben, can you please take this? The patchwork.kernel.org link is: thanks, added to for-linus/2636-rc6-i2c -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cpufreq for s3c2440 FriendlyArm
On 06/09/10 04:40, Marek Vasut wrote: > Dne Ne 5. září 2010 22:30:00 tarek attia napsal(a): >> Hi all, >> >> Did anyone try the cpufreq on the mini2440 ? and did anyone get it >> working on the board ? >> >> Each time I do the configuration in the kernel I found nothing on the >> board ,however after the compilation I found the cpufreq.o & pll.o but >> no file concerning that on the board . >> >> >> Any help will be appreciated. > > I believe you have the wrong mailing list here. LAK CCed. linux-arm-kernel is the right one. I've not tried on the mini2440, but it did work on other s3c2440 based machines. it may be there is a small bit of init missing for the mini2440 to get the cpufreq running. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] i2c-omap patches for 2.6.35 merge window
On Tue, May 11, 2010 at 11:35:01AM -0700, Tony Lindgren wrote: > Hi all, > > Here are the i2c-omap patches that we'd like to get in for 2.6.35. > > I believe all of these patches have been posted earlier already > to the i2c list. They all have been merged into the linux-omap master > branch for testing. > > I've removed some duplicate Cc fields from the commit messages > for the obvious mailings lists and the people who will be merging > them. > > Anyways, if no comments over the next few days, I'll reply to > this message with a pull request for Ben. I've applied these to for-2635/i2c-omap to get them into -next please keep the start of each commit the same, I prefer i2c-omap: thanks. > Regards, > > Tony > > --- > > Alexander Shishkin (2): > omap: i2c: make errata 1.153 workaround a separate function > omap: i2c: add a timeout to the busy waiting > > Kalle Jokiniemi (1): > i2c-omap: add mpu wake up latency constraint in i2c > > Santosh Shilimkar (1): > omap: i2c: Add i2c support on omap4 platform > > manjugk manjugk (2): > OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt > OMAP3: I2C: Clean up Errata 1p153 handling > > > arch/arm/plat-omap/i2c.c | 39 -- > drivers/i2c/busses/i2c-omap.c | 265 > - > include/linux/i2c-omap.h |9 + > 3 files changed, 246 insertions(+), 67 deletions(-) > create mode 100644 include/linux/i2c-omap.h > > -- > Signature > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4 v2] ks8851: Low level functions for read/write to companion eeprom
On Thu, May 06, 2010 at 12:20:12AM -0700, David Miller wrote: > From: Sebastien Jan > Date: Wed, 5 May 2010 20:45:53 +0200 > > > Low-level functions provide 16bits words read and write capability > > to ks8851 companion eeprom. > > > > Signed-off-by: Sebastien Jan > > Applied. So I take it the patches that used the drivers/misc/eeprom/eeprom_93cx6.c are not going to be merged? -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4 v2] ks8851: Low level functions for read/write to companion eeprom
On Wed, May 05, 2010 at 08:45:53PM +0200, Sebastien Jan wrote:
> Low-level functions provide 16bits words read and write capability
> to ks8851 companion eeprom.
Please use the eeprom interface that was added already
> Signed-off-by: Sebastien Jan
> ---
> drivers/net/ks8851.c | 228
> ++
> drivers/net/ks8851.h | 14 +++-
> 2 files changed, 241 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ks8851.c b/drivers/net/ks8851.c
> index a84e500..787f9df 100644
> --- a/drivers/net/ks8851.c
> +++ b/drivers/net/ks8851.c
> @@ -1044,6 +1044,234 @@ static const struct net_device_ops ks8851_netdev_ops
> = {
> .ndo_validate_addr = eth_validate_addr,
> };
>
> +/* Companion eeprom access */
> +
> +enum { /* EEPROM programming states */
> + EEPROM_CONTROL,
> + EEPROM_ADDRESS,
> + EEPROM_DATA,
> + EEPROM_COMPLETE
> +};
> +
> +/**
> + * ks8851_eeprom_read - read a 16bits word in ks8851 companion EEPROM
> + * @dev: The network device the PHY is on.
> + * @addr: EEPROM address to read
> + *
> + * eeprom_size: used to define the data coding length. Can be changed
> + * through debug-fs.
> + *
> + * Programs a read on the EEPROM using ks8851 EEPROM SW access feature.
> + * Warning: The READ feature is not supported on ks8851 revision 0.
> + *
> + * Rough programming model:
> + * - on period start: set clock high and read value on bus
> + * - on period / 2: set clock low and program value on bus
> + * - start on period / 2
> + */
> +unsigned int ks8851_eeprom_read(struct net_device *dev, unsigned int addr)
> +{
> + struct ks8851_net *ks = netdev_priv(dev);
> + int eepcr;
> + int ctrl = EEPROM_OP_READ;
> + int state = EEPROM_CONTROL;
> + int bit_count = EEPROM_OP_LEN - 1;
> + unsigned int data = 0;
> + int dummy;
> + unsigned int addr_len;
> +
> + addr_len = (ks->eeprom_size == 128) ? 6 : 8;
> +
> + /* start transaction: chip select high, authorize write */
> + mutex_lock(&ks->lock);
> + eepcr = EEPCR_EESA | EEPCR_EESRWA;
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + eepcr |= EEPCR_EECS;
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + mutex_unlock(&ks->lock);
> +
> + while (state != EEPROM_COMPLETE) {
> + /* falling clock period starts... */
> + /* set EED_IO pin for control and address */
> + eepcr &= ~EEPCR_EEDO;
> + switch (state) {
> + case EEPROM_CONTROL:
> + eepcr |= ((ctrl >> bit_count) & 1) << 2;
> + if (bit_count-- <= 0) {
> + bit_count = addr_len - 1;
> + state = EEPROM_ADDRESS;
> + }
> + break;
> + case EEPROM_ADDRESS:
> + eepcr |= ((addr >> bit_count) & 1) << 2;
> + bit_count--;
> + break;
> + case EEPROM_DATA:
> + /* Change to receive mode */
> + eepcr &= ~EEPCR_EESRWA;
> + break;
> + }
> +
> + /* lower clock */
> + eepcr &= ~EEPCR_EESCK;
> +
> + mutex_lock(&ks->lock);
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + mutex_unlock(&ks->lock);
> +
> + /* waitread period / 2 */
> + udelay(EEPROM_SK_PERIOD / 2);
> +
> + /* rising clock period starts... */
> +
> + /* raise clock */
> + mutex_lock(&ks->lock);
> + eepcr |= EEPCR_EESCK;
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + mutex_unlock(&ks->lock);
> +
> + /* Manage read */
> + switch (state) {
> + case EEPROM_ADDRESS:
> + if (bit_count < 0) {
> + bit_count = EEPROM_DATA_LEN - 1;
> + state = EEPROM_DATA;
> + }
> + break;
> + case EEPROM_DATA:
> + mutex_lock(&ks->lock);
> + dummy = ks8851_rdreg16(ks, KS_EEPCR);
> + mutex_unlock(&ks->lock);
> + data |= ((dummy >> EEPCR_EESB_OFFSET) & 1) << bit_count;
> + if (bit_count-- <= 0)
> + state = EEPROM_COMPLETE;
> + break;
> + }
> +
> + /* wait period / 2 */
> + udelay(EEPROM_SK_PERIOD / 2);
> + }
> +
> + /* close transaction */
> + mutex_lock(&ks->lock);
> + eepcr &= ~EEPCR_EECS;
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + eepcr = 0;
> + ks8851_wrreg16(ks, KS_EEPCR, eepcr);
> + mutex_unlock(&ks->lock);
> +
> + return data;
> +}
> +
> +/**
> + * ks8851_eeprom_write - write a 16bits word in ks8851 companion EEPROM
> + * @dev: The network device the PHY is on.
> + * @op: operand (can be WR
Re: [PATCH v4] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
On Mon, Apr 19, 2010 at 12:44:22PM +0530, Manjunatha GK wrote:
> Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> and the corresponding interrupt fire, even there is no data in
> the receive FIFO, or the I2C data transfer is still ongoing.
> These spurious RDR events must be ignored by the software.
>
> This patch handles and ignores RDR spurious interrupts.
>
> The below sequence is required in interrupt handler for
> handling this errata:
> 1. If RDR is set to 1, clear RDR
> 2. Read I2C status register and check for BusBusy bit. If BusBusy
> bit is set, skip remaining steps.
> 3. If BusBusy bit is not set, perform read operation on I2C status
> register.
> 4. If RDR is set, clear the same. Check RDR again and clear if it sets
> RDR bit again.
> 5. Perform I2C Data Read operation N number of times(where N is value
> read from the register BUFSTAT-RXSTAT bit fields).
>
> Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
> It is not applicable for OMAP4.
If people can give me a yes/no before the end of play tomorrow (ie,
2300GMT) then I will get this applied to for-linus/i2c and send it
for -rc.
> Signed-off-by: Manjunatha GK
> Cc: linux-...@vger.kernel.org
> Cc: ben-li...@fluff.org
> Cc: Kalliguddi, Hema
> Cc: Nishanth Menon
> Cc: Aaro Koskinen
>
> ---
> drivers/i2c/busses/i2c-omap.c | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index f2019d2..8309eac 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -796,6 +796,34 @@ complete:
> }
> if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> u8 num_bytes = 1;
> +
> + /*
> + * I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> + * Not applicable for OMAP4.
> + * Under certain rare conditions, RDR could be set again
> + * when the bus is busy, then ignore the interrupt and
> + * clear the interrupt.
> + */
> + if ((stat & OMAP_I2C_STAT_RDR) && !cpu_is_omap44xx()) {
> + /* Step 1: If RDR is set, clear it */
> + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
> +
> + /* Step 2: */
> + if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> + & OMAP_I2C_STAT_BB)) {
> + /* Step 3: */
> + if(omap_i2c_read_reg(dev,
> + OMAP_I2C_STAT_REG)
> + & OMAP_I2C_STAT_RDR) {
> + omap_i2c_ack_stat(dev,
> + OMAP_I2C_STAT_RDR);
> + dev_err(dev->dev,
> + "RDR when the bus is busy.\n");
> + continue;
> + }
> +
> + }
> + }
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_RRDY)
> num_bytes = dev->fifo_size;
> --
> 1.6.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] OMAP2/3: I2C: Errata ID i207: Clear wrong RDR interrupt
On Thu, Apr 15, 2010 at 03:08:16PM +0300, Aaro Koskinen wrote:
> Hi,
>
> Manjunatha GK wrote:
> > Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> > and the corresponding interrupt fire, even there is no data in
> > the receive FIFO, or the I2C data transfer is still ongoing.
> > These spurious RDR events must be ignored by the software.
> >
> > This patch handles and ignores RDR spurious interrupts.
> >
> > The below sequence is required in interrupt handler for
> > handling this errata:
> > 1. If RDR is set to 1, clear RDR
> > 2. Read I2C status register and check for BusBusy bit. If BusBusy
> > bit is set, skip remaining steps.
> > 3. If BusBusy bit is not set, perform read operation on I2C status
> > register.
> > 4. If RDR is set, clear the same. Check RDR again and clear if it sets
> > RDR bit again.
> > 5. Perform I2C Data Read operation N number of times(where N is value
> > read from the register BUFSTAT-RXSTAT bit fields).
> >
> > Note : This errata is applicable for OMAP2 and OMAP3 platforms only.
> > It is not applicable for OMAP4.
> >
> > Signed-off-by: Manjunatha GK
> > Cc: linux-...@vger.kernel.org
> > Cc: ben-li...@fluff.org
> > Cc: Kalliguddi, Hema
> > Cc: Nishanth Menon
> >
> > ---
> > drivers/i2c/busses/i2c-omap.c | 28
> > 1 files changed, 28 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index ae6f5c1..d1648da 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -733,6 +733,34 @@ complete:
> > }
> > if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> > u8 num_bytes = 1;
> > +
> > + /*
> > +* I2C Errata(Errata Nos. OMAP2: 1.67, OMAP3: 1.8)
> > +* Not applicable for OMAP4.
> > +* Under certain rare conditions, RDR could be set again
> > +* when the bus is busy, then ignore the interrupt and
> > +* clear the interrupt.
> > +*/
> > + if ((stat & OMAP_I2C_STAT_RDR) && !cpu_is_omap44xx()) {
> > + /* Step 1: If RDR is set, clear it */
> > + omap_i2c_ack_stat(dev, stat &
> > OMAP_I2C_STAT_RDR);
>
> You know the bit is set, so just: omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
>
> > +
> > + /* Step 2: */
> > + if(!(omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_BB)) {
> > + /* Step 3: */
> > + if(omap_i2c_read_reg(dev,
> > + OMAP_I2C_STAT_REG)
> > + & OMAP_I2C_STAT_RDR) {
> > + omap_i2c_ack_stat(dev, stat
> > + & OMAP_I2C_STAT_RDR);
>
> Same here.
>
> > + dev_err(dev->dev,
> > + "I2C : RDR when the bus is
> > busy.\n");
>
> Remove the "I2C : " from the log, it's redundant.
I'd agree, we're already prefixing this with the device name and
driver name from the dev_err() call. No need to add any more.
If it is in use elsewhere in the file, I'd prefer to see it removed
from the other points.
> > + continue;
> > + }
> > +
> > + }
> > + }
> > if (dev->fifo_size) {
> > if (stat & OMAP_I2C_STAT_RRDY)
> > num_bytes = dev->fifo_size;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP3: I2C: Errata i207: Clear wrong RDR interrupt
On Thu, Apr 01, 2010 at 08:53:04AM -0500, Nishanth Menon wrote:
> G, Manjunath Kondaiah had written, on 04/01/2010 07:20 AM, the following:
> >Under certain rare conditions, I2C_STAT[13].RDR bit may be set
> >and the corresponding interrupt fire, even there is no data in
> >the receive FIFO, or the I2C data transfer is still ongoing.
> >These spurious RDR events must be ignored by the software.
> >
> >This patch handles and ignores RDR spurious interrupts.
> >
> >Reviewed-by: Kalliguddi, Hema
> >Signed-off-by: Manjunatha GK
> >Cc: linux-omap@vger.kernel.org
> >Cc: linux-...@vger.kernel.org
> >Cc: ben-li...@fluff.org
> >Cc: Kalliguddi, Hema
> >---
> > drivers/i2c/busses/i2c-omap.c | 13 +
> > 1 files changed, 13 insertions(+), 0 deletions(-)
> >
> >diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> >index f2019d2..acf4076 100644
> >--- a/drivers/i2c/busses/i2c-omap.c
> >+++ b/drivers/i2c/busses/i2c-omap.c
> >@@ -796,6 +796,19 @@ complete:
> > }
> > if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> > u8 num_bytes = 1;
> >+
> >+/*
> >+ * OMAP3 I2C Errata ID: i207
> >+ * Under certain rare conditions, RDR could be set again
> >+ * when the bus is busy, then clear and ignore the
> >interrupt
> >+ */
> >+if (!(stat & OMAP_I2C_STAT_RRDY) && (stat &
> >+OMAP_I2C_STAT_BB)) {
> >+/* clear RDR */
> >+omap_i2c_ack_stat(dev, stat &
> >OMAP_I2C_STAT_RDR);
> >+dev_err(dev->dev, "I2C: RDR when bus is
> >busy.\n");
> >+return IRQ_HANDLED;
> >+}
> couple of comments after reading thru the errata:
> a) the sequence in the errata doc is:
> if (stat & OMAP_I2C_STAT_RDR) { /* This is cleaner that using an
> obtuse check using !(stat & OMAP_I2C_STAT_RRDY) */
> omap_i2c_ack_stat(dev, stat & OMAP_I2C_STAT_RDR); /* dummy read - i
> think this needs clarification as to why */
> if (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG) & OMAP_I2C_STAT_BB)
> /* reason for the i2c_read_reg is because errata mentions a dummy
> stat read which might mean something for BB -> I am not sure may
> need to be checked with H/w team. */
> continue; /* recheck - faster response compared to return and re
> generate interrupt */
> }
>
>
> b) does this apply to OMAP2 and OMAP4?
Ok, should this be held for further discussion?
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc-omap: Add support for 16-bit and 32-bit registers
On Sun, Mar 07, 2010 at 10:59:01PM +, Ben Dooks wrote: > On Sun, Mar 07, 2010 at 09:47:58AM -0800, Cory Maccarrone wrote: > > From: Marek Belisko > > > > The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring > > a modification of the register addresses in the mmc-omap driver. To resolve > > this, a bit shift is performed on base register addresses, either by 1 or 2 > > bits depending on the CPU in use. This yields the correct registers for > > each CPU. > > merged the previous one into my tree earlier today. ignore this, didn't read the message properly and thought it was the i2c patch. > > Signed-off-by: Marek Belisko > > Signed-off-by: Cory Maccarrone > > Signed-off-by: Tony Lindgren > > --- > > drivers/mmc/host/omap.c | 62 > > +-- > > 1 files changed, 33 insertions(+), 29 deletions(-) > > > > This is a resubmit of a patch I sent in several months ago. Tony Lindgren > > merged > > this into linux-omap's master and testing branches but has stated that he > > will not > > merge it further as linux-mmc needs to approve this. There hasn't been any > > comments > > raised on either of the linux-omap or linux-mmc mailing lists about > > problems. Due to > > the unique nature of the omap7xx platform, this patch is required for MMC > > card access. > > Is there any chance this can be included into the next -rc cycle, as it is > > a fix for > > devices that have 16-bit registers? > > > > diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c > > index c6d7e8e..53362c4 100644 > > --- a/drivers/mmc/host/omap.c > > +++ b/drivers/mmc/host/omap.c > > @@ -38,30 +38,30 @@ > > #include > > > > #defineOMAP_MMC_REG_CMD0x00 > > -#defineOMAP_MMC_REG_ARGL 0x04 > > -#defineOMAP_MMC_REG_ARGH 0x08 > > -#defineOMAP_MMC_REG_CON0x0c > > -#defineOMAP_MMC_REG_STAT 0x10 > > -#defineOMAP_MMC_REG_IE 0x14 > > -#defineOMAP_MMC_REG_CTO0x18 > > -#defineOMAP_MMC_REG_DTO0x1c > > -#defineOMAP_MMC_REG_DATA 0x20 > > -#defineOMAP_MMC_REG_BLEN 0x24 > > -#defineOMAP_MMC_REG_NBLK 0x28 > > -#defineOMAP_MMC_REG_BUF0x2c > > -#define OMAP_MMC_REG_SDIO 0x34 > > -#defineOMAP_MMC_REG_REV0x3c > > -#defineOMAP_MMC_REG_RSP0 0x40 > > -#defineOMAP_MMC_REG_RSP1 0x44 > > -#defineOMAP_MMC_REG_RSP2 0x48 > > -#defineOMAP_MMC_REG_RSP3 0x4c > > -#defineOMAP_MMC_REG_RSP4 0x50 > > -#defineOMAP_MMC_REG_RSP5 0x54 > > -#defineOMAP_MMC_REG_RSP6 0x58 > > -#defineOMAP_MMC_REG_RSP7 0x5c > > -#defineOMAP_MMC_REG_IOSR 0x60 > > -#defineOMAP_MMC_REG_SYSC 0x64 > > -#defineOMAP_MMC_REG_SYSS 0x68 > > +#defineOMAP_MMC_REG_ARGL 0x01 > > +#defineOMAP_MMC_REG_ARGH 0x02 > > +#defineOMAP_MMC_REG_CON0x03 > > +#defineOMAP_MMC_REG_STAT 0x04 > > +#defineOMAP_MMC_REG_IE 0x05 > > +#defineOMAP_MMC_REG_CTO0x06 > > +#defineOMAP_MMC_REG_DTO0x07 > > +#defineOMAP_MMC_REG_DATA 0x08 > > +#defineOMAP_MMC_REG_BLEN 0x09 > > +#defineOMAP_MMC_REG_NBLK 0x0a > > +#defineOMAP_MMC_REG_BUF0x0b > > +#defineOMAP_MMC_REG_SDIO 0x0d > > +#defineOMAP_MMC_REG_REV0x0f > > +#defineOMAP_MMC_REG_RSP0 0x10 > > +#defineOMAP_MMC_REG_RSP1 0x11 > > +#defineOMAP_MMC_REG_RSP2 0x12 > > +#defineOMAP_MMC_REG_RSP3 0x13 > > +#defineOMAP_MMC_REG_RSP4 0x14 > > +#defineOMAP_MMC_REG_RSP5 0x15 > > +#defineOMAP_MMC_REG_RSP6 0x16 > > +#defineOMAP_MMC_REG_RSP7 0x17 > > +#defineOMAP_MMC_REG_IOSR 0x18 > > +#defineOMAP_MMC_REG_SYSC 0x19 > > +#defineOMAP_MMC_REG_SYSS 0x1a > > > > #defineOMAP_MMC_STAT_CARD_ERR (1 << 14) > > #defineOMAP_MMC_STAT_CARD_IRQ (1 << 13) > > @@ -77,8 +77,9 @@ > > #defineOMAP_MMC_STAT_CARD_BUSY (1 << 2) > > #defineOMAP_MMC_STAT_END_OF_CMD(1 << 0) > > > > -#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base + > > OMAP_MMC_REG_##reg) > > -#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val), > > (host)->
Re: [PATCH] mmc-omap: Add support for 16-bit and 32-bit registers
On Sun, Mar 07, 2010 at 09:47:58AM -0800, Cory Maccarrone wrote:
> From: Marek Belisko
>
> The omap850 and omap730 use 16-bit registers instead of 32-bit, requiring
> a modification of the register addresses in the mmc-omap driver. To resolve
> this, a bit shift is performed on base register addresses, either by 1 or 2
> bits depending on the CPU in use. This yields the correct registers for
> each CPU.
merged the previous one into my tree earlier today.
> Signed-off-by: Marek Belisko
> Signed-off-by: Cory Maccarrone
> Signed-off-by: Tony Lindgren
> ---
> drivers/mmc/host/omap.c | 62
> +--
> 1 files changed, 33 insertions(+), 29 deletions(-)
>
> This is a resubmit of a patch I sent in several months ago. Tony Lindgren
> merged
> this into linux-omap's master and testing branches but has stated that he
> will not
> merge it further as linux-mmc needs to approve this. There hasn't been any
> comments
> raised on either of the linux-omap or linux-mmc mailing lists about problems.
> Due to
> the unique nature of the omap7xx platform, this patch is required for MMC
> card access.
> Is there any chance this can be included into the next -rc cycle, as it is a
> fix for
> devices that have 16-bit registers?
>
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index c6d7e8e..53362c4 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -38,30 +38,30 @@
> #include
>
> #define OMAP_MMC_REG_CMD0x00
> -#define OMAP_MMC_REG_ARGL 0x04
> -#define OMAP_MMC_REG_ARGH 0x08
> -#define OMAP_MMC_REG_CON0x0c
> -#define OMAP_MMC_REG_STAT 0x10
> -#define OMAP_MMC_REG_IE 0x14
> -#define OMAP_MMC_REG_CTO0x18
> -#define OMAP_MMC_REG_DTO0x1c
> -#define OMAP_MMC_REG_DATA 0x20
> -#define OMAP_MMC_REG_BLEN 0x24
> -#define OMAP_MMC_REG_NBLK 0x28
> -#define OMAP_MMC_REG_BUF0x2c
> -#define OMAP_MMC_REG_SDIO0x34
> -#define OMAP_MMC_REG_REV0x3c
> -#define OMAP_MMC_REG_RSP0 0x40
> -#define OMAP_MMC_REG_RSP1 0x44
> -#define OMAP_MMC_REG_RSP2 0x48
> -#define OMAP_MMC_REG_RSP3 0x4c
> -#define OMAP_MMC_REG_RSP4 0x50
> -#define OMAP_MMC_REG_RSP5 0x54
> -#define OMAP_MMC_REG_RSP6 0x58
> -#define OMAP_MMC_REG_RSP7 0x5c
> -#define OMAP_MMC_REG_IOSR 0x60
> -#define OMAP_MMC_REG_SYSC 0x64
> -#define OMAP_MMC_REG_SYSS 0x68
> +#define OMAP_MMC_REG_ARGL 0x01
> +#define OMAP_MMC_REG_ARGH 0x02
> +#define OMAP_MMC_REG_CON0x03
> +#define OMAP_MMC_REG_STAT 0x04
> +#define OMAP_MMC_REG_IE 0x05
> +#define OMAP_MMC_REG_CTO0x06
> +#define OMAP_MMC_REG_DTO0x07
> +#define OMAP_MMC_REG_DATA 0x08
> +#define OMAP_MMC_REG_BLEN 0x09
> +#define OMAP_MMC_REG_NBLK 0x0a
> +#define OMAP_MMC_REG_BUF0x0b
> +#define OMAP_MMC_REG_SDIO 0x0d
> +#define OMAP_MMC_REG_REV0x0f
> +#define OMAP_MMC_REG_RSP0 0x10
> +#define OMAP_MMC_REG_RSP1 0x11
> +#define OMAP_MMC_REG_RSP2 0x12
> +#define OMAP_MMC_REG_RSP3 0x13
> +#define OMAP_MMC_REG_RSP4 0x14
> +#define OMAP_MMC_REG_RSP5 0x15
> +#define OMAP_MMC_REG_RSP6 0x16
> +#define OMAP_MMC_REG_RSP7 0x17
> +#define OMAP_MMC_REG_IOSR 0x18
> +#define OMAP_MMC_REG_SYSC 0x19
> +#define OMAP_MMC_REG_SYSS 0x1a
>
> #define OMAP_MMC_STAT_CARD_ERR (1 << 14)
> #define OMAP_MMC_STAT_CARD_IRQ (1 << 13)
> @@ -77,8 +77,9 @@
> #define OMAP_MMC_STAT_CARD_BUSY (1 << 2)
> #define OMAP_MMC_STAT_END_OF_CMD(1 << 0)
>
> -#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base +
> OMAP_MMC_REG_##reg)
> -#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
> (host)->virt_base + OMAP_MMC_REG_##reg)
> +#define OMAP_MMC_REG(host, reg) (OMAP_MMC_REG_##reg <<
> (host)->reg_shift)
> +#define OMAP_MMC_READ(host, reg) __raw_readw((host)->virt_base +
> OMAP_MMC_REG(host, reg))
> +#define OMAP_MMC_WRITE(host, reg, val) __raw_writew((val),
> (host)->virt_base + OMAP_MMC_REG(host, reg))
>
> /*
> * Command types
> @@ -132,6 +133,7 @@ struct mmc_omap_host {
> int irq;
> unsigned char bus_mode;
> unsigned char hw_bus_mode;
> + unsigned intreg_shift;
>
> struct work_struct cmd_abort_work;
> unsignedabort:1;
> @@ -679,9 +681,9 @@ mmc_omap_xfer_data(struct mmc_omap_host *host, int write)
> host->data->bytes_xfered += n;
>
> if (write) {
> - __raw_writesw(host->virt_base + OMAP_MMC_
Re: [PATCH] omap: i2c: Add i2c support on omap4 platform
On Fri, Feb 19, 2010 at 10:03:00PM +0530, Santosh Shilimkar wrote:
> This patch is rebased version of earlier post to add I2C
> driver support to OMAP4 platform. On OMAP4, all
> I2C register address offsets are changed from OMAP1/2/3 I2C.
> In order to not have #ifdef's at various places in code,
> as well as to support multi-OMAP build, an array is created
> to hold the register addresses with it's offset.
>
> This patch was submitted, reviewed and acked on mailing list
> already. For more details refer below link
> http://www.mail-archive.com/linux-...@vger.kernel.org/msg02281.html
>
> This updated verion has a depedancy on "Add support for 16-bit registers"
> posted on linux-omap. Below is the patch-works link for the same
>
> http://patchwork.kernel.org/patch/72295/
currently even with this patch applied it doesn't apply cleanly.
> Signed-off-by: Syed Rafiuddin
> Signed-off-by: Santosh Shilimkar
> Acked-by: Kevin Hilman
> Reviewed-by: Paul Walmsley
> Reviewed-by: Tony Lindgren
> Cc: Ben Dooks
> Cc: Cory Maccarrone
> ---
> drivers/i2c/busses/i2c-omap.c | 146
> -
> 1 files changed, 114 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 9c3ce4d..7c15496 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -44,29 +44,37 @@
> /* I2C controller revisions present on specific hardware */
> #define OMAP_I2C_REV_ON_2430 0x36
> #define OMAP_I2C_REV_ON_3430 0x3C
> +#define OMAP_I2C_REV_ON_4430 0x40
>
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>
> -#define OMAP_I2C_REV_REG 0x00
> -#define OMAP_I2C_IE_REG 0x01
> -#define OMAP_I2C_STAT_REG0x02
> -#define OMAP_I2C_IV_REG 0x03
> /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
> -#define OMAP_I2C_WE_REG 0x03
> -#define OMAP_I2C_SYSS_REG0x04
> -#define OMAP_I2C_BUF_REG 0x05
> -#define OMAP_I2C_CNT_REG 0x06
> -#define OMAP_I2C_DATA_REG0x07
> -#define OMAP_I2C_SYSC_REG0x08
> -#define OMAP_I2C_CON_REG 0x09
> -#define OMAP_I2C_OA_REG 0x0a
> -#define OMAP_I2C_SA_REG 0x0b
> -#define OMAP_I2C_PSC_REG 0x0c
> -#define OMAP_I2C_SCLL_REG0x0d
> -#define OMAP_I2C_SCLH_REG0x0e
> -#define OMAP_I2C_SYSTEST_REG 0x0f
> -#define OMAP_I2C_BUFSTAT_REG 0x10
> +enum {
> + OMAP_I2C_REV_REG = 0,
> + OMAP_I2C_IE_REG,
> + OMAP_I2C_STAT_REG,
> + OMAP_I2C_IV_REG,
> + OMAP_I2C_WE_REG,
> + OMAP_I2C_SYSS_REG,
> + OMAP_I2C_BUF_REG,
> + OMAP_I2C_CNT_REG,
> + OMAP_I2C_DATA_REG,
> + OMAP_I2C_SYSC_REG,
> + OMAP_I2C_CON_REG,
> + OMAP_I2C_OA_REG,
> + OMAP_I2C_SA_REG,
> + OMAP_I2C_PSC_REG,
> + OMAP_I2C_SCLL_REG,
> + OMAP_I2C_SCLH_REG,
> + OMAP_I2C_SYSTEST_REG,
> + OMAP_I2C_BUFSTAT_REG,
> + OMAP_I2C_REVNB_LO,
> + OMAP_I2C_REVNB_HI,
> + OMAP_I2C_IRQSTATUS_RAW,
> + OMAP_I2C_IRQENABLE_SET,
> + OMAP_I2C_IRQENABLE_CLR,
> +};
>
> /* I2C Interrupt Enable Register (OMAP_I2C_IE): */
> #define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int
> enable */
> @@ -169,6 +177,7 @@ struct omap_i2c_dev {
> u32 speed; /* Speed of bus in Khz */
> u16 cmd_err;
> u8 *buf;
> + u8 *regs;
> size_t buf_len;
> struct i2c_adapter adapter;
> u8 fifo_size; /* use as flag and value
> @@ -187,15 +196,64 @@ struct omap_i2c_dev {
> u16 westate;
> };
>
> +const static u8 reg_map[] = {
> + [OMAP_I2C_REV_REG] = 0x00,
> + [OMAP_I2C_IE_REG] = 0x01,
> + [OMAP_I2C_STAT_REG] = 0x02,
> + [OMAP_I2C_IV_REG] = 0x03,
> + [OMAP_I2C_WE_REG] = 0x03,
> + [OMAP_I2C_SYSS_REG] = 0x04,
> + [OMAP_I2C_BUF_REG] = 0x05,
> + [OMAP_I2C_CNT_REG] = 0x06,
> + [OMAP_I2C_DATA_REG] = 0x07,
> + [OMAP_I2C_SYSC_REG] = 0x08,
> + [OMAP_I2C_CON_REG] = 0x09,
> + [OMAP_I2C_OA_REG] = 0x0a,
> + [OMAP_I2C_SA_REG] = 0x0b,
> + [OMAP_I2C_PSC_REG] = 0x0c,
> + [OMAP_I2C_SCLL_REG] = 0x0d,
> + [OMAP_I2C_SCLH_REG] = 0x0e,
> + [OMAP_I2C_SYSTEST_REG] = 0x0f,
> + [OMAP_I2C_BUFSTAT_REG] = 0x10,
> +};
&
Re: [PATCH RE-SEND-2] ARM: MM: Add ARM_L1_CACHE_SHIFT_6 for handle inside each ARCH Kconfig
On Thu, Jan 28, 2010 at 10:15:32AM +0900, Kukjin Kim wrote: > This patch adds ARM_L1_CACHE_SHIFT_6 into arch/arm/Kconfig. Basically, > ARM L1 cache line size is 32Bytes. Therefore, whenever new ARCH which > has 64Bytes L1 cache line size is added, have to set ARM_L1_CACHE_SHIFT > to 6. That is, have to add/modify arch/arm/mm/Kconfig. > This patch is for handle it in each ARCH such as ARCH_OMAP3, ARCH_S5PC1XX, > and ARCH_S5PV210 which is in review. > This patch also adds selecting ARM_L1_CACHE_SHIFT_6 into Kconfig of > ARCH_OMAP3 and ARCH_S5PC1XX. Note, 'this patch' is pretty much redudant, it is common knowledege and self-evident that this is a patch. I think the only problem with this patch is that the description could do with a re-write, as so: Add ARM_L1_CACHE_SHIFT_6 to arch/arm/Kconfig to allow CPUs with L1 cache lines which are 64bytes to indicate this without having to alter the arch/arm/mm/Kconfig entry each time. Update the mm Kconfig so that ARM_L1_CACHE_SHIFT default value uses this and change OMAP3 and SPC1XX to select ARM_L1_CACHE_SHIFT_6. > Signed-off-by: Kukjin Kim > --- > arch/arm/Kconfig |6 ++ > arch/arm/mm/Kconfig|2 +- > arch/arm/plat-omap/Kconfig |1 + > 3 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index a5602ec..13c07a6 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -161,6 +161,11 @@ config ARCH_MTD_XIP > config GENERIC_HARDIRQS_NO__DO_IRQ > def_bool y > > +config ARM_L1_CACHE_SHIFT_6 > + bool > + help > + Setting ARM L1 cache line size to 64 Bytes. > + > if OPROFILE > > config OPROFILE_ARMV6 > @@ -646,6 +651,7 @@ config ARCH_S5PC1XX > select GENERIC_GPIO > select HAVE_CLK > select CPU_V7 > + select ARM_L1_CACHE_SHIFT_6 > help > Samsung S5PC1XX series based systems > > diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig > index 91617f7..8ca9fb7 100644 > --- a/arch/arm/mm/Kconfig > +++ b/arch/arm/mm/Kconfig > @@ -779,5 +779,5 @@ config CACHE_XSC3L2 > > config ARM_L1_CACHE_SHIFT > int > - default 6 if ARCH_OMAP3 || ARCH_S5PC1XX > + default 6 if ARM_L1_CACHE_SHIFT_6 > default 5 > diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig > index e2ea04a..2e3eec6 100644 > --- a/arch/arm/plat-omap/Kconfig > +++ b/arch/arm/plat-omap/Kconfig > @@ -22,6 +22,7 @@ config ARCH_OMAP3 > bool "TI OMAP3" > select CPU_V7 > select COMMON_CLKDEV > + select ARM_L1_CACHE_SHIFT_6 > > config ARCH_OMAP4 > bool "TI OMAP4" > -- > 1.6.2.5 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] Arm Gic Changes
On Wed, Jan 27, 2010 at 11:32:24AM -0800, adhar...@codeaurora.org wrote: > From: Abhijeet Dharmapurikar > > Few fixes and improvements to arch/arm/common/gic.c file. both ARM and GIC in the title should be all in capitals, they are abbreviations of something longer. I think it would be nicer to make GIC in all the patch titles all capital instead of all lower case. > Abhijeet Dharmapurikar (5): > gic: prevent gic from crossing NR_IRQ > gic: add callback for mask_ack > gic: Add set_type callback > gic: dont disable INT in ack callback > gic: initialize interrupts as per argument > > arch/arm/common/gic.c| 114 - > arch/arm/include/asm/hardware/gic.h |3 +- > arch/arm/mach-omap2/board-4430sdp.c |3 +- > arch/arm/mach-realview/realview_eb.c | 10 ++- > arch/arm/mach-realview/realview_pb1176.c |7 ++- > arch/arm/mach-realview/realview_pb11mp.c |7 ++- > arch/arm/mach-realview/realview_pba8.c |4 +- > arch/arm/mach-realview/realview_pbx.c|5 +- > arch/arm/mach-ux500/cpu-u8500.c |2 +- > 9 files changed, 122 insertions(+), 33 deletions(-) > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Ben Gamari wrote: > Bcc: > Subject: GPIO chip select support in omap2_mcspi driver > > Hey, > > Recently I have been looking to use a BeagleBoard to drive several > serial ADCs and DACs in a data acquisition and analysis setup. Unfortunately, > the > BeagleBoard is severely limited by the number of SPI controllers it > exposes on the expansion connector (McSPI3 with 2 CS lines and McSPI4 > with one). This is insufficient for our application and thus I have been > investigating adding support to the mcspi driver for using GPIO lines as > chip select lines, as is done in the pxa2xx, bfin5xx, and s3c24xx drivers. > > To this end, I have a few questions about how this support was > implemented. First, it seems that the s3c24xx driver is built on the > spi_bitbang driver, despite interfacing with a dedicated hardware SPI > controller. What is the reason for this? Was this done specifically for > the purpose of incorporating support for GPIO CS pins? The spi_bitbang driver also has a really useful spi queue and workqueue built into it, which is what the s3c24xx spi driver actually bothers to use. > It seems like the rough idea is to add a cs_gpio field to the device > struct (omap2_mcspi) and add the appropriate code to the > omap2_mcspi_force_cs() to bring cs_gpio high or low if it is valid. The > potential problem I can see with this is that omap2_mcspi_set_enable() > is called to enable the channel before the force_cs() is called (in > omap2_mcspi_work()). If I'm interpreting the documentation correctly, > the enable bit starts the clocks, meaning that the chip will begin > clocking out data before CS is brought high. I must be missing something > here, no? > > For reference, I included a short list of relevant commits below, largely for > my own benefit. I would greatly appreciate any feedback you might have. > > Thanks, > - Ben > > > pxa2xx_spi: a7bb3909b3293d503211d7f6af8ed62c1644b686 > bfin_spi: 42c78b2bf51bafb4cfa98dfecc28dd9b8bcd04b0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [I2C-OMAP] Add support for 16-bit registers
On Sat, Dec 05, 2009 at 11:14:08PM -0800, Cory Maccarrone wrote:
> The current i2c-omap driver is set up for 32-bit registers, which
> corresponds to most OMAP devices. However, OMAP730/850 based
> devices use a 16-bit register size.
>
> This change modifies the driver to perform a runtime CPU type check
> to determine the register sizes, and uses a bit shift of either 1
> or 2 bits to compute the proper register sizes for all registers.
>
> Signed-off-by: Cory Maccarrone
> ---
> drivers/i2c/busses/i2c-omap.c | 138
> ++---
> 1 files changed, 73 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 827da08..dc7cf71 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -49,24 +49,26 @@
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>
> #define OMAP_I2C_REV_REG 0x00
> -#define OMAP_I2C_IE_REG 0x04
> -#define OMAP_I2C_STAT_REG0x08
> -#define OMAP_I2C_IV_REG 0x0c
> +#define OMAP_I2C_IE_REG 0x01
> +#define OMAP_I2C_STAT_REG0x02
> +#define OMAP_I2C_IV_REG 0x03
> /* For OMAP3 I2C_IV has changed to I2C_WE (wakeup enable) */
> -#define OMAP_I2C_WE_REG 0x0c
> -#define OMAP_I2C_SYSS_REG0x10
> -#define OMAP_I2C_BUF_REG 0x14
> -#define OMAP_I2C_CNT_REG 0x18
> -#define OMAP_I2C_DATA_REG0x1c
> -#define OMAP_I2C_SYSC_REG0x20
> -#define OMAP_I2C_CON_REG 0x24
> -#define OMAP_I2C_OA_REG 0x28
> -#define OMAP_I2C_SA_REG 0x2c
> -#define OMAP_I2C_PSC_REG 0x30
> -#define OMAP_I2C_SCLL_REG0x34
> -#define OMAP_I2C_SCLH_REG0x38
> -#define OMAP_I2C_SYSTEST_REG 0x3c
> -#define OMAP_I2C_BUFSTAT_REG 0x40
> +#define OMAP_I2C_WE_REG 0x03
> +#define OMAP_I2C_SYSS_REG0x04
> +#define OMAP_I2C_BUF_REG 0x05
> +#define OMAP_I2C_CNT_REG 0x06
> +#define OMAP_I2C_DATA_REG0x07
> +#define OMAP_I2C_SYSC_REG0x08
> +#define OMAP_I2C_CON_REG 0x09
> +#define OMAP_I2C_OA_REG 0x0a
> +#define OMAP_I2C_SA_REG 0x0b
> +#define OMAP_I2C_PSC_REG 0x0c
> +#define OMAP_I2C_SCLL_REG0x0d
> +#define OMAP_I2C_SCLH_REG0x0e
> +#define OMAP_I2C_SYSTEST_REG 0x0f
> +#define OMAP_I2C_BUFSTAT_REG 0x10
> +
> +#define OMAP_I2C_REG(host, reg) (OMAP_I2C_##reg##_REG <<
> (host)->reg_shift)
could you leave the definitions alone and shift the other way?
> /* I2C Interrupt Enable Register (OMAP_I2C_IE): */
> #define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int
> enable */
> @@ -161,6 +163,7 @@ struct omap_i2c_dev {
> struct device *dev;
> void __iomem*base; /* virtual */
> int irq;
> + int reg_shift; /* bit shift for I2C register
> addresses */
> struct clk *iclk; /* Interface clock */
> struct clk *fclk; /* Functional clock */
> struct completion cmd_complete;
> @@ -232,7 +235,7 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> clk_enable(dev->fclk);
> dev->idle = 0;
> if (dev->iestate)
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> + omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, IE), dev->iestate);
how about changing the read and write register calls to do the
necessary address munging so you don't have to change all the
callsites throughout the file?
> }
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> @@ -241,15 +244,15 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
>
> WARN_ON(dev->idle);
>
> - dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> + dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, IE));
> + omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, IE), 0);
> if (dev->rev < OMAP_I2C_REV_2) {
> - iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
> + iv = omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, IV)); /* Read
> clears */
> } else {
> - omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> + omap_i2c_write_reg(dev, OMAP_I2C_REG(dev, STAT), dev->iestate);
>
> /* Flush posted write before the dev->idle store occurs */
> - omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
> + omap_i2c_read_reg(dev, OMAP_I2C_REG(dev, STAT));
> }
> dev->idle = 1;
> clk_disable(dev->fclk);
> @@ -265,12 +268,12 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>
Re:
Syed Rafiuddin wrote: From: Syed Rafiuddin This patch Adds Keypad support on OMAP4.And adds OMAP4 register addresses and configures them for OMAP4. [SNIP] Subjects are considered useful, please supply at-least semi meaningful subject next time! -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] i2c-omap: I2C clean-up patch
On Thu, Aug 20, 2009 at 11:21:13AM -0500, Moiz Sonasath wrote: > This patch includes the following fixes: > -Fix I2C status ACK > -ACK pending [R/X]DR and [R/X]RDY interrupts in the error/completeion path > -Enable workaround for Errata 1.153 based on I2C IP block ok, will add these to my fixes tree. > Signed-off-by: Moiz Sonasath > Signed-off-by: Vikram Pandita > > Moiz Sonasath (3): > i2c-omap: Fix I2C status ACK > i2c-omap: ACK pending [R/X]DR and [R/X]RDY interrupts in the > error/completeion path > i2c-omap: Enable workaround for Errata 1.153 based on I2C IP block > > drivers/i2c/busses/i2c-omap.c | 14 -- > 1 files changed, 12 insertions(+), 2 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT][PATCH-v2][RFC] OMAP4: I2C Support for OMAP4430
On Tue, Aug 18, 2009 at 03:35:31PM +0530, Syed Rafiuddin wrote: > Ben, > > > On Fri, Jul 24, 2009 at 04:40:02PM +0530, Syed Rafiuddin wrote: > >> Hi Ben, > >> > >> > This patch adds OMAP4 support to the I2C driver. All I2C register > >> > addresses are different > >> between > >> > OMAP1/2/3 and OMAP4. In order to not have #ifdef's at various places in > >> > code, as well as to > >> > support multi-OMAP build, Array's are created to hold the register > >> > addresses. > >> > > >> > Signed-off-by: Syed Rafiuddin > >> > --- > >> > >> No comment received on this patch, > >> Is there anything that I need to resolve? > >> Else can this patch get merged. > > > > sorry, been busy, will look at this in the next few days. > > Seems like no issues with the patch since no comments received from long time. > Did you get a chance to look at the patch.Could you please merge this. I can't currently think of any neater way of doing this, so i'll probably merge this. > Regards, > Syed Rafiuddin > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the I2C_BUFFSTAT register
On Tue, Jul 21, 2009 at 10:14:06AM -0500, Sonasath, Moiz wrote:
> Fix bug in reading the I2C_BUFFSTAT register for getting byte count on RX/TX
> interrupt.
>
> On Interrupt: I2C_STAT[RDR],
> read 'RXSTAT' from I2C_BUFFSTAT[8-13]
> On Interrupt: I2C_STAT[XDR]
> read 'TXSTAT' from I2C_BUFFSTAT[0-5]
>
> Signed-off-by: Jagadeesh Pakaravoor
> Signed-off-by: Moiz Sonasath
> Signed-off-by: Vikram pandita
IIRC, email addresses should have a space between the real name
and the address part. I've fixed this when applying as well as
changing all subjects to start i2c-omap:
> ---
> drivers/i2c/busses/i2c-omap.c | 14 --
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index ad8d201..d280acf 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -692,9 +692,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_RRDY)
> num_bytes = dev->fifo_size;
> - else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + else/* read RXSTAT on RDR interrupt */
> + num_bytes = (omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG)
> + >> 8) & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
> @@ -731,9 +732,10 @@ omap_i2c_isr(int this_irq, void *dev_id)
> if (dev->fifo_size) {
> if (stat & OMAP_I2C_STAT_XRDY)
> num_bytes = dev->fifo_size;
> - else
> - num_bytes = omap_i2c_read_reg(dev,
> - OMAP_I2C_BUFSTAT_REG);
> + else/* read TXSTAT on XDR interrupt */
> + num_bytes = omap_i2c_read_reg(dev,
> + OMAP_I2C_BUFSTAT_REG)
> + & 0x3F;
> }
> while (num_bytes) {
> num_bytes--;
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT][PATCH-v2][RFC] OMAP4: I2C Support for OMAP4430
On Fri, Jul 24, 2009 at 04:40:02PM +0530, Syed Rafiuddin wrote: > Hi Ben, > > > This patch adds OMAP4 support to the I2C driver. All I2C register addresses > > are different between > > OMAP1/2/3 and OMAP4. In order to not have #ifdef's at various places in > > code, as well as to > > support multi-OMAP build, Array's are created to hold the register > > addresses. > > > > Signed-off-by: Syed Rafiuddin > > --- > > No comment received on this patch, > Is there anything that I need to resolve? > Else can this patch get merged. sorry, been busy, will look at this in the next few days. > Regards, > Syed Rafiuddin > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] [OMAP:I2C] Small bug fixes and errata 1.153
On Tue, Jul 21, 2009 at 10:13:20AM -0500, Sonasath, Moiz wrote: > > This patch includes the following: > - Bug in reading the RXSTAT/TXSTAT values from I2C_BUFFSTAT > - In case of a NACK|ARDY|AL interrupts return from the ISR > - OMAP3430 silicon errata 1.153 hi, in future it would be better to prefix the patch subjects with i2c-omap (IE, the driver name). > Signed-off-by: Moiz Sonasath ^ space to go in here. > Signed-off-by: Vikram pandita > Moiz Sonasath (3): > [OMAP:I2C]Bug in reading the RXSTAT/TXSTAT values from the > I2C_BUFFSTAT register > [OMAP:I2C]In case of a NACK|ARDY|AL return from the ISR > [OMAP:I2C]OMAP3430 Silicon Errata 1.153 > > drivers/i2c/busses/i2c-omap.c | 42 +--- > 1 files changed, 34 insertions(+), 8 deletions(-) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP3: PM: (re)init for every transfer to support off-mode
On Tue, Jul 21, 2009 at 04:09:03PM -0700, Kevin Hilman wrote:
> From: Rajendra Nayak
>
> Because of OMAP off-mode, powerdomain can go off when I2C is idle.
> Save enough state, and do a re-init for each transfer.
>
> Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
> (SYSC_REG) and Aaro Koskinen (wakeup sources.)
>
> Also, The OMAP3430 TRM states:
>
> "During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
> changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers. Changes may
> result in unpredictable behavior."
>
> Hence, the I2C_EN bit should be clearer when modifying these
> registers. Please note that clearing the entire I2C_CON register to
> disable the I2C module is safe, because the I2C_CON register is
> re-configured for each transfer.
should this be applied as a bugfix, or kept for next merge window?
> Signed-off-by: Jouni Hogander
> Signed-off-by: Rajendra Nayak
> Cc: Jagadeesh Bhaskar Pakaravoor
> Cc: Aaro Koskinen
> Cc: Jon Hunter
> Cc: Hu Tao
> Cc: Xiaolong Chen
> Signed-off-by: Kevin Hilman
> ---
> This patch has been tested extensively as part of the OMAP 'PM branch'
>
> drivers/i2c/busses/i2c-omap.c | 64 ++--
> 1 files changed, 41 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index ad8d201..bb8ae50 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -178,6 +178,12 @@ struct omap_i2c_dev {
> unsignedb_hw:1; /* bad h/w fixes */
> unsignedidle:1;
> u16 iestate;/* Saved interrupt register */
> + u16 pscstate;
> + u16 scllstate;
> + u16 sclhstate;
> + u16 bufstate;
> + u16 syscstate;
> + u16 westate;
> };
>
> static inline void omap_i2c_write_reg(struct omap_i2c_dev *i2c_dev,
> @@ -230,9 +236,18 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
>
> clk_enable(dev->iclk);
> clk_enable(dev->fclk);
> + if (cpu_is_omap34xx()) {
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG, dev->bufstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, dev->syscstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> + }
> dev->idle = 0;
> - if (dev->iestate)
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> }
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> @@ -258,7 +273,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
>
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> {
> - u16 psc = 0, scll = 0, sclh = 0;
> + u16 psc = 0, scll = 0, sclh = 0, buf = 0;
> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> unsigned long fclk_rate = 1200;
> unsigned long timeout;
> @@ -287,24 +302,22 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> SYSC_AUTOIDLE_MASK);
>
> } else if (dev->rev >= OMAP_I2C_REV_ON_3430) {
> - u32 v;
> -
> - v = SYSC_AUTOIDLE_MASK;
> - v |= SYSC_ENAWAKEUP_MASK;
> - v |= (SYSC_IDLEMODE_SMART <<
> + dev->syscstate = SYSC_AUTOIDLE_MASK;
> + dev->syscstate |= SYSC_ENAWAKEUP_MASK;
> + dev->syscstate |= (SYSC_IDLEMODE_SMART <<
> __ffs(SYSC_SIDLEMODE_MASK));
> - v |= (SYSC_CLOCKACTIVITY_FCLK <<
> + dev->syscstate |= (SYSC_CLOCKACTIVITY_FCLK <<
> __ffs(SYSC_CLOCKACTIVITY_MASK));
>
> - omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, v);
> + omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG,
> + dev->syscstate);
> /*
>* Enabling all wakup sources to stop I2C freezing on
>* WFI instruction.
>* REVISIT: Some wkup sources might not be needed.
>*/
> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> - OMAP_I2C_WE_ALL);
> -
> + dev->westate = OMAP_I2C_WE_ALL;
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->wes
Re: [PATCH 0/44] includecheck: fix multiple includes
Jaswinder Singh Rajput wrote: On Wed, 2009-07-08 at 22:13 +0100, Russell King wrote: On Wed, Jul 08, 2009 at 11:30:59PM +0530, Jaswinder Singh Rajput wrote: I am still waiting ACK/NAK for : includecheck fix: arm, misc.c includecheck fix: arm, atomic.h includecheck fix: arm, board-dm355-evm.c includecheck fix: arm, board-dm355-leopard.c includecheck fix: arm, board-dm644x-evm.c includecheck fix: arm, board-dm646x-evm.c includecheck fix: arm, board-sffsdr.c includecheck fix: arm, mach-mx3/devices.c includecheck fix: arm, mach-omap1/mcbsp.c includecheck fix: arm, mach-omap2/mcbsp.c includecheck fix: arm, plat-s3c64xx/pm.c includecheck fix: arm, plat-stmp3xxx/pinmux.c You're still waiting because apparantly you never sent this set anywhere near any ARM people before. For the first two, I'll ack them: Acked-by: Russell King The remainder look sane to me, but you'll have to seek acks from the individual platform maintainer(s). Ack for plat-s3c64xx/pm.c: Acked-by: Ben Dooks -- Ben Dooks, Software Engineer, Simtec Electronics http://www.simtec.co.uk/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Reclaim address space on omaps, Tony on vacation in July
On Fri, Jun 26, 2009 at 09:25:40AM +0300, Tony Lindgren wrote: > Hi all, > > Last week I posted some more omap io.h clean-up patches to the linux-omap > list [1], and started looking at what it would take to reclaim lost address > space on top of the io.h clean-up patches. > > Looks like we should be able to reclaim about 454MB of the 640MB > of the lost IO address space by doing the following: > > 1. Start converting drivers using omap_read/write to use ioremap + >__raw_read/write ioremap implies readl/writel, the __raw stuff is for items that have been mapped by iodesc (iirc). -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c: i2c-omap: Call request_irq with IRQF_DISABLED
On Fri, Mar 06, 2009 at 03:34:54PM +0200, Ari Kauppi wrote:
> I have observed some Spurious IRQ's for I2C1 when all kernel hacking options
> (and thus LOCKDEP) are disabled.
>
> Applying Richard Woodruff's 'I2C bug fixes for L-O and L-Z' seems to help
> but IRQF_DISABLED is needed for proper behaviour.
>
> Signed-off-by: Ari Kauppi
> Acked-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 0c3ed41..18af43f 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -847,7 +847,7 @@ omap_i2c_probe(struct platform_device *pdev)
> omap_i2c_init(dev);
>
> isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
> - r = request_irq(dev->irq, isr, 0, pdev->name, dev);
> + r = request_irq(dev->irq, isr, IRQF_DISABLED, pdev->name, dev);
Is disabling all IRQs on the system the right thing to do?
> if (r) {
> dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
> --
> 1.5.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP: Add missing wakeup events
On Mon, Feb 02, 2009 at 12:47:05PM +0530, Pakaravoor, Jagadeesh wrote: > Ben, > > Did you get a chance to look at this patch? Is it a necesary bugfix, or should it wait for the next merge window? > -Original Message- > From: linux-i2c-ow...@vger.kernel.org > [mailto:linux-i2c-ow...@vger.kernel.org] On Behalf Of Pakaravoor, Jagadeesh > Sent: Friday, January 23, 2009 2:19 PM > To: linux-...@vger.kernel.org > Cc: linux-omap@vger.kernel.org; Ben Dooks > Subject: [PATCH] I2C: OMAP: Add missing wakeup events > > From: Jagadeesh Bhaskar Pakaravoor > > Include wake up events for receiver overflow and transmitter > underflow in OMAP_I2C_WE_REG configuration. Also fix a small > typo. > > Signed-off-by: Jagadeesh Bhaskar Pakaravoor > --- > Index: kernel_org/drivers/i2c/busses/i2c-omap.c > === > --- kernel_org.orig/drivers/i2c/busses/i2c-omap.c 2009-01-23 > 12:46:58.0 +0530 > +++ kernel_org/drivers/i2c/busses/i2c-omap.c 2009-01-23 14:15:52.187150630 > +0530 > @@ -92,8 +92,10 @@ > #define OMAP_I2C_STAT_AL (1 << 0)/* Arbitration lost int ena */ > > /* I2C WE wakeup enable register */ > -#define OMAP_I2C_WE_XDR_WE (1 << 14) /* TX drain wakup */ > +#define OMAP_I2C_WE_XDR_WE (1 << 14) /* TX drain wakeup */ > #define OMAP_I2C_WE_RDR_WE (1 << 13) /* RX drain wakeup */ > +#define OMAP_I2C_WE_ROVR_WE (1 << 11) /* RX overflow wakeup */ > +#define OMAP_I2C_WE_XUDF_WE (1 << 10) /* TX underflow wakeup */ > #define OMAP_I2C_WE_AAS_WE (1 << 9)/* Address as slave wakeup*/ > #define OMAP_I2C_WE_BF_WE(1 << 8)/* Bus free wakeup */ > #define OMAP_I2C_WE_STC_WE (1 << 6)/* Start condition wakeup */ > @@ -104,6 +106,7 @@ > #define OMAP_I2C_WE_AL_WE(1 << 0)/* Arbitration lost wakeup */ > > #define OMAP_I2C_WE_ALL (OMAP_I2C_WE_XDR_WE | > OMAP_I2C_WE_RDR_WE | \ > + OMAP_I2C_WE_ROVR_WE | OMAP_I2C_WE_XUDF_WE | \ > OMAP_I2C_WE_AAS_WE | OMAP_I2C_WE_BF_WE | \ > OMAP_I2C_WE_STC_WE | OMAP_I2C_WE_GC_WE | \ > OMAP_I2C_WE_DRDY_WE | OMAP_I2C_WE_ARDY_WE | \ > -- > With Regards, > Jagadeesh Bhaskar P > > > Some men see things as they are and say why - I dream things that never were > and say why not. > - George Bernard Shaw > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I2C: OMAP: Include OMAP_I2C_SYSC_REG in save and restore
On Fri, Jan 23, 2009 at 12:24:45PM +0530, Pakaravoor, Jagadeesh wrote: > From: Jagadeesh Bhaskar Pakaravoor > > Save and restore should include OMAP_I2C_SYSC_REG. is this necessary for inclusion as a bugfix, or can it wait for a merge window? -- Ben (b...@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] i2c-omap: convert 'rev1' flag to generic 'rev' u8
On Tue, Dec 16, 2008 at 09:59:59PM +, Ben Dooks wrote:
> On Fri, Nov 28, 2008 at 05:34:57PM -0800, Tony Lindgren wrote:
> > From: Paul Walmsley
> >
> > i2c-omap discriminates only between "revision 1" or "greater than
> > revision 1." A following patch introduces code that must also
> > discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support
> > this by storing the full revision data from the I2C_REV register, rather
> > than just a single bit.
> >
> > The revision definitions may need to be extended for other ES levels
> > that aren't currently available here. rev3.6 is what's present on the
> > 2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2
> > here.
> >
> > Signed-off-by: Paul Walmsley
> > Signed-off-by: Tony Lindgren
> > ---
> > drivers/i2c/busses/i2c-omap.c | 25 -
> > 1 files changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> > index 40a1e4b..3ac510d 100644
> > --- a/drivers/i2c/busses/i2c-omap.c
> > +++ b/drivers/i2c/busses/i2c-omap.c
> > @@ -38,6 +38,13 @@
> > #include
> > #include
> >
> > +/* I2C controller revisions */
> > +#define OMAP_I2C_REV_2 0x20
> > +
> > +/* I2C controller revisions present on specific hardware */
> > +#define OMAP_I2C_REV_ON_2430 0x36
> > +#define OMAP_I2C_REV_ON_3430 0x3C
> > +
> > /* timeout waiting for the controller to respond */
> > #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> >
> > @@ -139,7 +146,7 @@ struct omap_i2c_dev {
> > * fifo_size==0 implies no fifo
> > * if set, should be trsh+1
> > */
> > - unsignedrev1:1;
> > + u8 rev;
> > unsignedb_hw:1; /* bad h/w fixes */
> > unsignedidle:1;
> > u16 iestate;/* Saved interrupt register */
> > @@ -209,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> >
> > dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> > omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> > - if (dev->rev1) {
> > + if (dev->rev < OMAP_I2C_REV_2) {
> > iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
> > } else {
> > omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> > @@ -231,7 +238,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > unsigned long timeout;
> > unsigned long internal_clk = 0;
> >
> > - if (!dev->rev1) {
> > + if (dev->rev >= OMAP_I2C_REV_2) {
> > omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
> > /* For some reason we need to set the EN bit before the
> > * reset done bit gets set. */
> > @@ -710,6 +717,7 @@ omap_i2c_probe(struct platform_device *pdev)
> > struct omap_i2c_dev *dev;
> > struct i2c_adapter *adap;
> > struct resource *mem, *irq, *ioarea;
> > + void *isr;
>
> There is a proper definition for the function type in
>
I'm feeling a bit of Christmas spirit finally, will pull these and
add a fix myself for this.
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] i2c-omap: convert 'rev1' flag to generic 'rev' u8
On Fri, Nov 28, 2008 at 05:34:57PM -0800, Tony Lindgren wrote:
> From: Paul Walmsley
>
> i2c-omap discriminates only between "revision 1" or "greater than
> revision 1." A following patch introduces code that must also
> discriminate between rev2.x, rev3.6, and rev3.12 controllers. Support
> this by storing the full revision data from the I2C_REV register, rather
> than just a single bit.
>
> The revision definitions may need to be extended for other ES levels
> that aren't currently available here. rev3.6 is what's present on the
> 2430SDP here (unknown ES revision); rev3.12 is used on the 3430ES2
> here.
>
> Signed-off-by: Paul Walmsley
> Signed-off-by: Tony Lindgren
> ---
> drivers/i2c/busses/i2c-omap.c | 25 -
> 1 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 40a1e4b..3ac510d 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -38,6 +38,13 @@
> #include
> #include
>
> +/* I2C controller revisions */
> +#define OMAP_I2C_REV_2 0x20
> +
> +/* I2C controller revisions present on specific hardware */
> +#define OMAP_I2C_REV_ON_2430 0x36
> +#define OMAP_I2C_REV_ON_3430 0x3C
> +
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
>
> @@ -139,7 +146,7 @@ struct omap_i2c_dev {
>* fifo_size==0 implies no fifo
>* if set, should be trsh+1
>*/
> - unsignedrev1:1;
> + u8 rev;
> unsignedb_hw:1; /* bad h/w fixes */
> unsignedidle:1;
> u16 iestate;/* Saved interrupt register */
> @@ -209,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
>
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> - if (dev->rev1) {
> + if (dev->rev < OMAP_I2C_REV_2) {
> iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
> } else {
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> @@ -231,7 +238,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> unsigned long timeout;
> unsigned long internal_clk = 0;
>
> - if (!dev->rev1) {
> + if (dev->rev >= OMAP_I2C_REV_2) {
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
> /* For some reason we need to set the EN bit before the
>* reset done bit gets set. */
> @@ -710,6 +717,7 @@ omap_i2c_probe(struct platform_device *pdev)
> struct omap_i2c_dev *dev;
> struct i2c_adapter *adap;
> struct resource *mem, *irq, *ioarea;
> + void *isr;
There is a proper definition for the function type in
> int r;
> u32 speed = 0;
>
> @@ -760,8 +768,7 @@ omap_i2c_probe(struct platform_device *pdev)
>
> omap_i2c_unidle(dev);
>
> - if (cpu_is_omap15xx())
> - dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
> + dev->rev = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
>
> if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> u16 s;
> @@ -782,16 +789,16 @@ omap_i2c_probe(struct platform_device *pdev)
> /* reset ASAP, clearing any IRQs */
> omap_i2c_init(dev);
>
> - r = request_irq(dev->irq, dev->rev1 ? omap_i2c_rev1_isr : omap_i2c_isr,
> - 0, pdev->name, dev);
> + isr = (dev->rev < OMAP_I2C_REV_2) ? omap_i2c_rev1_isr : omap_i2c_isr;
> + r = request_irq(dev->irq, isr, 0, pdev->name, dev);
>
> if (r) {
> dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
> goto err_unuse_clocks;
> }
> - r = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) & 0xff;
> +
> dev_info(dev->dev, "bus %d rev%d.%d at %d kHz\n",
> - pdev->id, r >> 4, r & 0xf, dev->speed);
> + pdev->id, dev->rev >> 4, dev->rev & 0xf, dev->speed);
>
> omap_i2c_idle(dev);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben (b...@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-pull request for i2c-omap updates (Re: [PATCH 00/12] Updates for i2c-omap for 2.6.29 merge window, v5)
On Fri, Nov 28, 2008 at 05:56:12PM -0800, Tony Lindgren wrote:
> Ben,
>
> Here's the pull request for you.
>
> Regards,
>
> Tony
> The following changes since commit 13d428afc007fcfcd6deeb215618f54cf9c0cae6:
> Linus Torvalds (1):
> Linux 2.6.28-rc6
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
> i2c-for-ben
>
> Chandra shekhar (1):
> i2c-omap: Add support for omap34xx
>
> Jarkko Nikula (1):
> i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
>
> Kalle Jokiniemi (1):
> i2c-omap: Enable I2C wakeups for 34xx
>
> Nishanth Menon (1):
> i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
>
> Paul Walmsley (6):
> i2c-omap: Close suspected race between omap_i2c_idle() and
> omap_i2c_isr()
> i2c-omap: Mark init-only functions as __init
> i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
> i2c-omap: fix I2C timeouts due to recursive omap_i2c_{un,}idle()
> i2c-omap: convert 'rev1' flag to generic 'rev' u8
> i2c-omap: reprogram OCP_SYSCONFIG register after reset
>
> Syed Mohammed Khasim (1):
> i2c-omap: Add high-speed support to omap-i2c
>
> Tony Lindgren (1):
> i2c-omap: Clean-up i2c-omap
>
> arch/arm/mach-omap2/clock24xx.h |4 +-
> drivers/i2c/busses/i2c-omap.c | 420
> ++-
> 2 files changed, 330 insertions(+), 94 deletions(-)
Ok, i've had a look through and most of these pass a quick review,,
will do a full review in the next day or so.
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: highspeed only over 1000mhz
On Sat, Oct 18, 2008 at 12:09:55AM +0300, Felipe Balbi wrote:
> up to 1000mhz it's Fast Mode+, not highspeed.
mill-hz? 1MHz or 1000kHz.
> Signed-off-by: Felipe Balbi <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a999606..53d6244 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -296,7 +296,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> psc = psc - 1;
>
> /* If configured for High Speed */
> - if (dev->speed > 400) {
> + if (dev->speed > 1000) {
> /* For first phase of HS mode */
> fsscll = internal_clk / (400 * 2) - 6;
> fssclh = internal_clk / (400 * 2) - 6;
> --
> 1.6.0.2.307.gc427
>
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 8/8] i2c-omap: Clean-up i2c-omap
On Thu, Sep 25, 2008 at 10:53:54AM +0300, Tony Lindgren wrote:
> Minor checkpatch and formatting clean-up. Also update copyrights.
looks ok, assuming it doesn't get broken by any changes
from the review comments i've made earlier in the series.
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 28
> 1 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5c54864..a41b655 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -2,13 +2,15 @@
> * TI OMAP I2C master mode driver
> *
> * Copyright (C) 2003 MontaVista Software, Inc.
> - * Copyright (C) 2004 Texas Instruments.
> - *
> - * Updated to work with multiple I2C interfaces on 24xx by
> - * Tony Lindgren <[EMAIL PROTECTED]> and Imre Deak <[EMAIL PROTECTED]>
> * Copyright (C) 2005 Nokia Corporation
> + * Copyright (C) 2004 - 2007 Texas Instruments.
> *
> - * Cleaned up by Juha Yrj??l?? <[EMAIL PROTECTED]>
> + * Originally written by MontaVista Software, Inc.
> + * Additional contributions by:
> + * Tony Lindgren <[EMAIL PROTECTED]>
> + * Imre Deak <[EMAIL PROTECTED]>
> + * Juha Yrj??l?? <[EMAIL PROTECTED]>
> + * Syed Khasim <[EMAIL PROTECTED]>
> *
> * 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
> @@ -33,8 +35,7 @@
> #include
> #include
> #include
> -
> -#include
> +#include
>
> /* timeout waiting for the controller to respond */
> #define OMAP_I2C_TIMEOUT (msecs_to_jiffies(1000))
> @@ -215,7 +216,7 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> if (dev->rev1)
> - iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
> */
> + iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears */
> else
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> /*
> @@ -334,9 +335,9 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>
> /* Enable interrupts */
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
> -(OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> - OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
> - OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
> + (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> + OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
> + OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
> (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
> return 0;
> }
> @@ -402,8 +403,10 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> w |= OMAP_I2C_CON_XA;
> if (!(msg->flags & I2C_M_RD))
> w |= OMAP_I2C_CON_TRX;
> +
> if (!dev->b_hw && stop)
> w |= OMAP_I2C_CON_STP;
> +
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w);
>
> /*
> @@ -476,7 +479,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
> msgs[], int num)
>
> omap_i2c_unidle(dev);
>
> - if ((r = omap_i2c_wait_for_bb(dev)) < 0)
> + r = omap_i2c_wait_for_bb(dev);
> + if (r < 0)
> goto out;
>
> for (i = 0; i < num; i++) {
> --
> 1.5.6.rc3.21.g8c6b5
>
>
> ___
> i2c mailing list
> [EMAIL PROTECTED]
> http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 6/8] i2c-omap: Mark init-only functions as __init
On Thu, Sep 25, 2008 at 10:53:52AM +0300, Tony Lindgren wrote:
> From: Paul Walmsley <[EMAIL PROTECTED]>
>
> Mark functions called only at init time as __init.
surely these should be __devinit in case of hotplugged-ness?
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index b41431a..e71f1f2 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -154,7 +154,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
> *i2c_dev, int reg)
> return __raw_readw(i2c_dev->base + reg);
> }
>
> -static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> +static int __init omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> {
> if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
> dev->iclk = clk_get(dev->dev, "i2c_ick");
> @@ -697,7 +697,7 @@ static const struct i2c_algorithm omap_i2c_algo = {
> .functionality = omap_i2c_func,
> };
>
> -static int
> +static int __init
> omap_i2c_probe(struct platform_device *pdev)
> {
> struct omap_i2c_dev *dev;
> --
> 1.5.6.rc3.21.g8c6b5
>
>
> ___
> i2c mailing list
> [EMAIL PROTECTED]
> http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 7/8] i2c-omap: Don't compile in OMAP15xx I2C ISR for non-OMAP15xx builds
On Thu, Sep 25, 2008 at 10:53:53AM +0300, Tony Lindgren wrote:
> From: Paul Walmsley <[EMAIL PROTECTED]>
>
> Skip compiling OMAP15xx I2C ISR for non-OMAP15xx builds. Saves 400 bytes
> of text for most OMAP builds.
you've sneaked in __devinit/__devexit changes into this patch,
I'm going to put my foot down on that.
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index e71f1f2..5c54864 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -511,6 +511,9 @@ omap_i2c_ack_stat(struct omap_i2c_dev *dev, u16 stat)
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat);
> }
>
> +/* rev1 devices are apparently only on some 15xx */
> +#ifdef CONFIG_ARCH_OMAP15XX
> +
> static irqreturn_t
> omap_i2c_rev1_isr(int this_irq, void *dev_id)
> {
> @@ -565,6 +568,9 @@ omap_i2c_rev1_isr(int this_irq, void *dev_id)
>
> return IRQ_HANDLED;
> }
> +#else
> +#define omap_i2c_rev1_isr0
> +#endif
>
> static irqreturn_t
> omap_i2c_isr(int this_irq, void *dev_id)
> @@ -843,14 +849,14 @@ static struct platform_driver omap_i2c_driver = {
> };
>
> /* I2C may be needed to bring up other drivers */
> -static int __init
> +static int __devinit
> omap_i2c_init_driver(void)
> {
> return platform_driver_register(&omap_i2c_driver);
> }
> subsys_initcall(omap_i2c_init_driver);
>
> -static void __exit omap_i2c_exit_driver(void)
> +static void __devexit omap_i2c_exit_driver(void)
a differerent change to the one advertised.
> {
> platform_driver_unregister(&omap_i2c_driver);
> }
> --
> 1.5.6.rc3.21.g8c6b5
>
>
> ___
> i2c mailing list
> [EMAIL PROTECTED]
> http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 5/8] i2c-omap: Add support on 34xx
On Thu, Sep 25, 2008 at 10:53:51AM +0300, Tony Lindgren wrote:
> From: Chandra shekhar <[EMAIL PROTECTED]>
Not very informative description in here. At lease you could have
copied the subject?
> Signed-off-by: chandra shekhar <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 12 +++-
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index ded4636..b41431a 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -156,7 +156,7 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
> *i2c_dev, int reg)
>
> static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> {
> - if (cpu_is_omap16xx() || cpu_is_omap24xx()) {
> + if (cpu_is_omap16xx() || cpu_class_is_omap2()) {
> dev->iclk = clk_get(dev->dev, "i2c_ick");
> if (IS_ERR(dev->iclk)) {
> dev->iclk = NULL;
> @@ -279,7 +279,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> psc = fclk_rate / 1200;
> }
>
> - if (cpu_is_omap2430()) {
> + if (cpu_is_omap2430() || cpu_is_omap34xx()) {
>
> /* HSI2C controller internal clk rate should be 19.2 Mhz */
> internal_clk = 19200;
> @@ -616,7 +616,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
> *dev->buf++ = w;
> dev->buf_len--;
> /* Data reg from 2430 is 8 bit wide */
> - if (!cpu_is_omap2430()) {
> + if (!cpu_is_omap2430() &&
> + !cpu_is_omap34xx()) {
> if (dev->buf_len) {
> *dev->buf++ = w >> 8;
> dev->buf_len--;
> @@ -654,7 +655,8 @@ omap_i2c_isr(int this_irq, void *dev_id)
> w = *dev->buf++;
> dev->buf_len--;
> /* Data reg from 2430 is 8 bit wide */
> - if (!cpu_is_omap2430()) {
> + if (!cpu_is_omap2430() &&
> + !cpu_is_omap34xx()) {
> if (dev->buf_len) {
> w |= *dev->buf++ << 8;
> dev->buf_len--;
> @@ -748,7 +750,7 @@ omap_i2c_probe(struct platform_device *pdev)
> if (cpu_is_omap15xx())
> dev->rev1 = omap_i2c_read_reg(dev, OMAP_I2C_REV_REG) < 0x20;
>
> - if (cpu_is_omap2430()) {
> + if (cpu_is_omap2430() || cpu_is_omap34xx()) {
> u16 s;
>
> /* Set up the fifo size - Get total size */
> --
> 1.5.6.rc3.21.g8c6b5
>
>
> ___
> i2c mailing list
> [EMAIL PROTECTED]
> http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 4/8] i2c-omap: FIFO handling support and broken hw workaround for i2c-omap
On Thu, Sep 25, 2008 at 10:53:50AM +0300, Tony Lindgren wrote:
> From: Nishanth Menon <[EMAIL PROTECTED]>
>
> Based on an earlier patch from Nishant Menon:
>
> - Transfers can use FIFO on FIFO capable devices
> - Prevents errors for HSI2C if FIFO is not used
> - Implemented errenous handling of STT-STP handling on SDP2430
>
> Also merged in is a fix from Jaron Marini to fix occasional i2c
> hang if OMAP_I2C_CON_STT remains asserted.
This looks ok
> Signed-off-by: Jason P Marini <[EMAIL PROTECTED]>
> Signed-off-by: Nishanth Menon <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 189
> -
> 1 files changed, 149 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 0d30790..ded4636 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -55,8 +55,11 @@
> #define OMAP_I2C_SCLL_REG0x34
> #define OMAP_I2C_SCLH_REG0x38
> #define OMAP_I2C_SYSTEST_REG 0x3c
> +#define OMAP_I2C_BUFSTAT_REG 0x40
>
> /* I2C Interrupt Enable Register (OMAP_I2C_IE): */
> +#define OMAP_I2C_IE_XDR (1 << 14) /* TX Buffer drain int
> enable */
> +#define OMAP_I2C_IE_RDR (1 << 13) /* RX Buffer drain int
> enable */
> #define OMAP_I2C_IE_XRDY (1 << 4)/* TX data ready int enable */
> #define OMAP_I2C_IE_RRDY (1 << 3)/* RX data ready int enable */
> #define OMAP_I2C_IE_ARDY (1 << 2)/* Access ready int enable */
> @@ -64,7 +67,8 @@
> #define OMAP_I2C_IE_AL (1 << 0)/* Arbitration lost int
> ena */
>
> /* I2C Status Register (OMAP_I2C_STAT): */
> -#define OMAP_I2C_STAT_SBD(1 << 15) /* Single byte data */
> +#define OMAP_I2C_STAT_XDR(1 << 14) /* TX Buffer draining */
> +#define OMAP_I2C_STAT_RDR(1 << 13) /* RX Buffer draining */
> #define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */
> #define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */
> #define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */
> @@ -78,12 +82,14 @@
>
> /* I2C Buffer Configuration Register (OMAP_I2C_BUF): */
> #define OMAP_I2C_BUF_RDMA_EN (1 << 15) /* RX DMA channel enable */
> +#define OMAP_I2C_BUF_RXFIF_CLR (1 << 14) /* RX FIFO Clear */
> #define OMAP_I2C_BUF_XDMA_EN (1 << 7)/* TX DMA channel enable */
> +#define OMAP_I2C_BUF_TXFIF_CLR (1 << 6)/* TX FIFO Clear */
>
> /* I2C Configuration Register (OMAP_I2C_CON): */
> #define OMAP_I2C_CON_EN (1 << 15) /* I2C module enable */
> #define OMAP_I2C_CON_BE (1 << 14) /* Big endian mode */
> -#define OMAP_I2C_CON_OPMODE (1 << 12) /* High Speed support */
> +#define OMAP_I2C_CON_OPMODE_HS (1 << 12) /* High Speed support */
> #define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
> #define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
> #define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
> @@ -127,7 +133,12 @@ struct omap_i2c_dev {
> u8 *buf;
> size_t buf_len;
> struct i2c_adapter adapter;
> + u8 fifo_size; /* use as flag and value
> + * fifo_size==0 implies no fifo
> + * if set, should be trsh+1
> + */
> unsignedrev1:1;
> + unsignedb_hw:1; /* bad h/w fixes */
> unsignedidle:1;
> u16 iestate;/* Saved interrupt register */
> };
> @@ -310,6 +321,14 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
> omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
>
> + if (dev->fifo_size)
> + /* Note: setup required fifo size - 1 */
> + omap_i2c_write_reg(dev, OMAP_I2C_BUF_REG,
> + (dev->fifo_size - 1) << 8 | /* RTRSH */
> + OMAP_I2C_BUF_RXFIF_CLR |
> + (dev->fifo_size - 1) | /* XTRSH */
> + OMAP_I2C_BUF_TXFIF_CLR);
> +
> /* Take the I2C module out of reset: */
> omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>
> @@ -317,7 +336,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG,
> (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
> - OMAP_I2C_IE_AL));
> + OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
> +
Re: [i2c] [PATCH 3/8] i2c-omap: Add high-speed support to omap-i2c
On Thu, Sep 25, 2008 at 10:53:49AM +0300, Tony Lindgren wrote:
> From: Syed Mohammed Khasim <[EMAIL PROTECTED]>
>
> Omap2430 has additional support for high-speed I2C.
>
> This patch moves I2C speed parameter (from module) to platform data.
> Also added basic High Speed support based on I2C bus speed.
>
> This patch is tested for high speed I2C (with TWL4030 Keypad) and works as
> expected.
>
> Signed-off-by: Syed Mohammed Khasim <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 111 +---
> 1 files changed, 80 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index a06ad42..0d30790 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -83,6 +83,7 @@
> /* I2C Configuration Register (OMAP_I2C_CON): */
> #define OMAP_I2C_CON_EN (1 << 15) /* I2C module enable */
> #define OMAP_I2C_CON_BE (1 << 14) /* Big endian mode */
> +#define OMAP_I2C_CON_OPMODE (1 << 12) /* High Speed support */
> #define OMAP_I2C_CON_STB (1 << 11) /* Start byte mode (master) */
> #define OMAP_I2C_CON_MST (1 << 10) /* Master/slave mode */
> #define OMAP_I2C_CON_TRX (1 << 9)/* TX/RX mode (master only) */
> @@ -91,6 +92,10 @@
> #define OMAP_I2C_CON_STP (1 << 1)/* Stop cond (master only) */
> #define OMAP_I2C_CON_STT (1 << 0)/* Start condition (master) */
>
> +/* I2C SCL time value when Master */
> +#define OMAP_I2C_SCLL_HSSCLL 8
> +#define OMAP_I2C_SCLH_HSSCLH 8
> +
> /* I2C System Test Register (OMAP_I2C_SYSTEST): */
> #ifdef DEBUG
> #define OMAP_I2C_SYSTEST_ST_EN (1 << 15) /* System test
> enable */
> @@ -109,12 +114,6 @@
> /* I2C System Configuration Register (OMAP_I2C_SYSC): */
> #define OMAP_I2C_SYSC_SRST (1 << 1)/* Soft Reset */
>
> -/* REVISIT: Use platform_data instead of module parameters */
> -/* Fast Mode = 400 kHz, Standard = 100 kHz */
> -static int clock = 100; /* Default: 100 kHz */
> -module_param(clock, int, 0);
> -MODULE_PARM_DESC(clock, "Set I2C clock in kHz: 400=fast mode (default ==
> 100)");
> -
> struct omap_i2c_dev {
> struct device *dev;
> void __iomem*base; /* virtual */
> @@ -123,6 +122,7 @@ struct omap_i2c_dev {
> struct clk *fclk; /* Functional clock */
> struct completion cmd_complete;
> struct resource *ioarea;
> + u32 speed; /* Speed of bus in Khz */
> u16 cmd_err;
> u8 *buf;
> size_t buf_len;
> @@ -152,17 +152,28 @@ static int omap_i2c_get_clocks(struct omap_i2c_dev *dev)
> return -ENODEV;
> }
> }
> -
> - dev->fclk = clk_get(dev->dev, "i2c_fck");
> - if (IS_ERR(dev->fclk)) {
> - if (dev->iclk != NULL) {
> - clk_put(dev->iclk);
> - dev->iclk = NULL;
> + /* For I2C operations on 2430 we need 96Mhz clock */
> + if (cpu_is_omap2430()) {
> + dev->fclk = clk_get(dev->dev, "i2chs_fck");
> + if (IS_ERR(dev->fclk)) {
> + if (dev->iclk != NULL) {
> + clk_put(dev->iclk);
> + dev->iclk = NULL;
> + }
I'm sorry, but I think this is mis-use of the clock system. The
actual name of the clock should be provided for the driver, not
the driver having to search for different clocks.
> + dev->fclk = NULL;
> + return -ENODEV;
> + }
> + } else {
> + dev->fclk = clk_get(dev->dev, "i2c_fck");
> + if (IS_ERR(dev->fclk)) {
> + if (dev->iclk != NULL) {
> + clk_put(dev->iclk);
> + dev->iclk = NULL;
> + }
> + dev->fclk = NULL;
> + return -ENODEV;
> }
> - dev->fclk = NULL;
> - return -ENODEV;
> }
> -
> return 0;
> }
>
> @@ -210,9 +221,11 @@ static void omap_i2c_idle(struct omap_i2c_dev *dev)
>
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> {
> - u16 psc = 0;
> + u16 psc = 0, scll = 0, sclh = 0;
> + u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> unsigned long fclk_rate = 1200;
> unsigned long timeout;
> + unsigned long internal_clk = 0;
>
> if (!dev->rev1) {
> omap_i2c_write_reg(dev, OMAP_I2C_SYSC_REG, OMAP_I2C_SYSC_SRST);
> @@ -255,18 +268,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> psc = fclk_rate / 1200;
> }
>
> + if (cpu_is_omap2430()) {
> +
> + /* HSI2C
Re: [i2c] [PATCH 0/8] Updates for i2c-omap from linux-omap tree for review, v2
On Thu, Sep 25, 2008 at 10:53:46AM +0300, Tony Lindgren wrote: > Hi all, > > Here's a repost of the whole series, the first series had a compile > error starting with one of the patches. Sorry for the extra noise. > > This series contains pending i2c-omap patches from linux-omap tree > for review. > > Looks like we've managed to pile up stuff in the omap tree for this > driver again... Anyways, future patches will be coming straight via > the i2c list. > > The first two patches could be pushed as fixes to current -rc series, > but I'm fine with them going in later too. It is too late in the -rc series, and it will be easier to push the lot in one go. > I've left out some clean-up from the last patch so it won't conflict with > omap ioremp changes that are currently in Russell King's devel > branch. If you can provide an url to a git tree to pull, that'd be great, otherwise I'll apply from the series unless anyone else decides there are problems with it. -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 2/8] i2c-omap: Close suspected race between omap_i2c_idle() and omap_i2c_isr()
On Thu, Sep 25, 2008 at 10:53:48AM +0300, Tony Lindgren wrote:
> From: Paul Walmsley <[EMAIL PROTECTED]>
>
> omap_i2c_idle() sets an internal flag, "dev->idle", instructing its
> ISR to decline interrupts. It sets this flag before it actually masks
> the interrupts on the I2C controller. This is problematic, since an
> I2C interrupt could arrive after dev->idle is set, but before the
> interrupt source is masked. When this happens, Linux disables the I2C
> controller's IRQ, causing all future transactions on the bus to fail.
>
> Symptoms, happening on about 7% of boots:
>
>irq 56: nobody cared (try booting with the "irqpoll" option)
>
>Disabling IRQ #56
>i2c_omap i2c_omap.1: controller timed out
>
> In omap_i2c_idle(), this patch sets dev->idle only after the interrupt
> mask write to the I2C controller has left the ARM write buffer.
> That's probably the major offender. For additional prophylaxis, in
> omap_i2c_unidle(), the patch clears the dev->idle flag before
> interrupts are enabled, rather than afterwards.
>
> The patch has survived twenty-two reboots on the 3430SDP here without
> wedging I2C1. Not absolutely dispositive, but promising!
that looks ok.
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> ---
> drivers/i2c/busses/i2c-omap.c | 10 --
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index cfb76f5..a06ad42 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -181,22 +181,28 @@ static void omap_i2c_unidle(struct omap_i2c_dev *dev)
> if (dev->iclk != NULL)
> clk_enable(dev->iclk);
> clk_enable(dev->fclk);
> + dev->idle = 0;
> if (dev->iestate)
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> - dev->idle = 0;
> }
>
> static void omap_i2c_idle(struct omap_i2c_dev *dev)
> {
> u16 iv;
>
> - dev->idle = 1;
> dev->iestate = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
> omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, 0);
> if (dev->rev1)
> iv = omap_i2c_read_reg(dev, OMAP_I2C_IV_REG); /* Read clears
> */
> else
> omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, dev->iestate);
> + /*
> + * The wmb() is to ensure that the I2C interrupt mask write
> + * reaches the I2C controller before the dev->idle store
> + * occurs.
> + */
> + wmb();
> + dev->idle = 1;
> clk_disable(dev->fclk);
> if (dev->iclk != NULL)
> clk_disable(dev->iclk);
> --
> 1.5.6.rc3.21.g8c6b5
>
>
> ___
> i2c mailing list
> [EMAIL PROTECTED]
> http://lists.lm-sensors.org/mailman/listinfo/i2c
--
Ben ([EMAIL PROTECTED], http://www.fluff.org/)
'a smiley only costs 4 bytes'
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] [PATCH 1/8] i2c-omap: Do not use interruptible wait call in omap_i2c_xfer_msg
On Thu, Sep 25, 2008 at 10:53:47AM +0300, Tony Lindgren wrote: > From: Jarkko Nikula <[EMAIL PROTECTED]> > > If there is a signal pending and wait_for_completion_interruptible_timeout > terminates with -ERESTARTSYS, we return and disable the i2c clocks in > omap_i2c_xfer. > > If we terminate before sending last i2c message with a stop condition, the > bus remains busy and we are not able to send new messages into bus with > successive omap_i2c_xfer calls. Therefore a pending signal is not caught > here and we return only because of timeout or i2c error. I assume that this is preferable to aborting an transfer when the signal is caught (if possible) ? > Signed-off-by: Jarkko Nikula <[EMAIL PROTECTED]> > Signed-off-by: Juha Yrjola <[EMAIL PROTECTED]> > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]> > --- > drivers/i2c/busses/i2c-omap.c |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c > index e7eb7bf..cfb76f5 100644 > --- a/drivers/i2c/busses/i2c-omap.c > +++ b/drivers/i2c/busses/i2c-omap.c > @@ -328,8 +328,8 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap, > w |= OMAP_I2C_CON_STP; > omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, w); > > - r = wait_for_completion_interruptible_timeout(&dev->cmd_complete, > - OMAP_I2C_TIMEOUT); > + r = wait_for_completion_timeout(&dev->cmd_complete, > + OMAP_I2C_TIMEOUT); > dev->buf_len = 0; > if (r < 0) > return r; > -- > 1.5.6.rc3.21.g8c6b5 > > > ___ > i2c mailing list > [EMAIL PROTECTED] > http://lists.lm-sensors.org/mailman/listinfo/i2c -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM MMU: add strongly-ordered memory type
On Mon, Aug 04, 2008 at 05:40:57PM -0600, Paul Walmsley wrote:
>
> Add the MT_MEMORY_STRONGLY_ORDERED memory type for ARM strongly ordered
> memory.
>
> This is used on OMAP3 for on-board SRAM. On OMAP, SRAM is used for code
> that changes the SDRAM controller's clock, temporarily blocking access to
> SDRAM. During this period, as code executes from SRAM, the ARM cache
> controller can attempt to write dirty cache lines back to SDRAM to make
> room for SRAM cache lines, causing the MPU subsystem to hang. To avoid
> this, we mark SRAM as strongly- ordered memory.
Is the controller allowed to write dirty cache lines out at any time it
likes? Surely a better fix is to drain the cache of the changes before
changing the clock for the SDRAM?
> Problem noted by Richard Woodruff <[EMAIL PROTECTED]>. Fix derived
> from the TI CDP codebase.
>
> Signed-off-by: Paul Walmsley <[EMAIL PROTECTED]>
> ---
>
> arch/arm/mm/mmu.c |5 +
> include/asm-arm/mach/map.h | 13 +++--
> 2 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index 2d6d682..5b56539 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -239,6 +239,11 @@ static struct mem_type mem_types[] = {
> .prot_sect = PMD_TYPE_SECT,
> .domain= DOMAIN_KERNEL,
> },
> + [MT_MEMORY_STRONGLY_ORDERED] = {
> + .prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE |
> + PMD_SECT_UNCACHED,
> + .domain= DOMAIN_KERNEL,
> + },
> };
>
> const struct mem_type *get_mem_type(unsigned int type)
> diff --git a/include/asm-arm/mach/map.h b/include/asm-arm/mach/map.h
> index 7ef3c83..8cb46b7 100644
> --- a/include/asm-arm/mach/map.h
> +++ b/include/asm-arm/mach/map.h
> @@ -19,12 +19,13 @@ struct map_desc {
> };
>
> /* types 0-3 are defined in asm/io.h */
> -#define MT_CACHECLEAN4
> -#define MT_MINICLEAN 5
> -#define MT_LOW_VECTORS 6
> -#define MT_HIGH_VECTORS 7
> -#define MT_MEMORY8
> -#define MT_ROM 9
> +#define MT_CACHECLEAN4
> +#define MT_MINICLEAN 5
> +#define MT_LOW_VECTORS 6
> +#define MT_HIGH_VECTORS 7
> +#define MT_MEMORY8
> +#define MT_ROM 9
> +#define MT_MEMORY_STRONGLY_ORDERED 10
>
> #define MT_NONSHARED_DEVICE MT_DEVICE_NONSHARED
> #define MT_IXP2000_DEVICEMT_DEVICE_IXP2000
>
>
> ---
> List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
> FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php
> Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php
--
--
Ben
Q: What's a light-year?
A: One-third less calories than a regular year.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [i2c] N800 problems with MMC, LM8323 on current linux-omap git head
On Tue, Jul 22, 2008 at 04:37:42PM +0300, Riku Voipio wrote: > On Tue, Jul 22, 2008 at 07:52:44AM -0500, Felipe Balbi wrote: > > On Tue, 22 Jul 2008 15:47:43 +0300, Riku Voipio <[EMAIL PROTECTED]> wrote: > > > > > Hmm. I think it would be better to avoid calling the probe > > > in first place. git diff made the attached patch look more > > > confusing than it actually is. Personally I'd eliminate > > > all ifdefs from those i2c_board_info structs. > > > I did the same thing before, but then we're gonna start adding > > several i2c_board_info for different hw. I mean, we should > > just reuse the code and the driver should know when the device > > is not present and stop probing without any problems to the rest > > of the system. > > If the different hw has different devices on the i2c bus, then > different i2c_board_info struct should be provided. IIRC i2c_board_info > is expected to provide a accurate picture of what i2c devices is > connected to the bus. This has been used as a argument to remove detection > code from .probe functions. > > To all the confused i2c list readers, the topic is about should we > split n800_i2c_board_info_2 [0] to n800 and n810 specific structs[1] > or make the lm8323 configure to err out earlier[2]. Split them into a common and then machine specfic structures, you are allowed to register more than one board per bus. > [0] > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=blob;f=arch/arm/mach-omap2/board-n800.c;h=ae85c2c60534820856c8bb0e019be29f2375470b;hb=HEAD#l645 > [1] http://article.gmane.org/gmane.linux.ports.arm.omap/9562 > [2] http://article.gmane.org/gmane.linux.ports.arm.omap/9522 > > > "rm -rf" only sounds scary if you don't have backups > > ___ > i2c mailing list > [EMAIL PROTECTED] > http://lists.lm-sensors.org/mailman/listinfo/i2c -- Ben ([EMAIL PROTECTED], http://www.fluff.org/) 'a smiley only costs 4 bytes' -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
