Re: [PATCH] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
On 12/10/15 20:19, Tony Lindgren wrote:
> * Ben Dooks <ben.do...@codethink.co.uk> [151012 11:22]:
>> On 12/10/15 18:45, Tony Lindgren wrote:
>>> * Ben Dooks <ben.do...@codethink.co.uk> [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 <ben.do...@codethink.co.uk>
>>>> ---
>>>> 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 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 <ben.do...@codethink.co.uk> [151012 11:22]:
>>>> On 12/10/15 18:45, Tony Lindgren wrote:
>>>>> * Ben Dooks <ben.do...@codethink.co.uk> [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 <ben.do...@codethink.co.uk>
>>>>>> ---
>>>>>> 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
[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 <ben.do...@codethink.co.uk>
---
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] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock
On 12/10/15 18:45, Tony Lindgren wrote:
> * Ben Dooks <ben.do...@codethink.co.uk> [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 <ben.do...@codethink.co.uk>
>> ---
>> 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
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 <ben.do...@codethink.co.uk> >> >> 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 <ben.do...@codethink.co.uk>
--
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 <ben.do...@codethink.co.uk> [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 <t...@atomide.com>
>>
>>> Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
>>> ---
>>> 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 <ben.do...@codethink.co.uk>
---
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:
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't even enumerate
TUSB2046, did you look at its datasheet
(http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
kernel toggles that ? Anything interesting from usbmon ?
I've gone through the schematics and verified the hub's reset line
is connected where we think it is (will try and check with a 'scope
on monday that it is being taken high, the boot-loader starts it low).
The root has just the one device connected, and unfortunately the
hw designer decided to hard-wire the D+ pull-up to 3.3V instead
of the transceiver's pull pin.
Not tried usbmon yet. However if the hub is not being detected then
probably won't show anything either.
I am going to install devmem2 into the root image and use it to poke
around and see the state of the system at run time.
Thanks for looking in to this.
The hub is functioning, 3.3V is up, the ~RESET line is high and the
6MHz crystal is running
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: 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't even enumerate
TUSB2046, did you look at its datasheet
(http://www.ti.com/lit/ds/symlink/tusb2046b.pdf) ? What is the
state of RESETn pin ? Perhaps that's tied to a GPIO and the old TI
kernel toggles that ? Anything interesting from usbmon ?
I've gone through the schematics and verified the hub's reset line
is connected where we think it is (will try and check with a 'scope
on monday that it is being taken high, the boot-loader starts it low).
The root has just the one device connected, and unfortunately the
hw designer decided to hard-wire the D+ pull-up to 3.3V instead
of the transceiver's pull pin.
Not tried usbmon yet. However if the hub is not being detected then
probably won't show anything either.
I am going to install devmem2 into the root image and use it to poke
around and see the state of the system at run time.
Thanks for looking in to this.
- --
Ben Dooks http://www.codethink.co.uk/
Senior Engineer
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 khil...@linaro.org wrote: Geert Uytterhoeven geert+rene...@glider.be 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 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 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 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 Dimitrovfreemangor...@abv.bg
Signed-off-by: Pali Rohárpali.ro...@gmail.com
---
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 Shilimkarsantosh.shilim...@ti.com
*
+ * Copyright (C) 2012 Ivaylo Dimitrovfreemangor...@abv.bg
+ * Copyright (C) 2013 Pali Rohárpali.ro...@gmail.com
*
* 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 b-cous...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
---
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 kh...@linux-fr.org Cc: Tony Lindgren t...@atomide.com Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@ti.com --- 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 p...@pwsan.com @@ -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 rom...@fr.zoreil.com -- 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: [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 shubhrajy...@ti.com
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. 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: [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] OMAP4: I2C: Enable FIFO usage for OMAP4
On Tue, Jul 05, 2011 at 05:01:01PM -0700, Kevin Hilman wrote:
Shubhrajyoti D shubhrajy...@ti.com 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 n...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
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][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 shubhrajy...@ti.com 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 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 ben-li...@fluff.org 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] 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-omapm=129924561819873w=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 rna...@ti.com 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 rna...@ti.com --- Patch is based on 2.6.38-rc7 kernel. Acked-by: Kevin Hilman khil...@ti.com 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 khil...@ti.com wrote:
Keerthy j-keer...@ti.com writes:
From: Richard woodruff r-woodru...@ti.com
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 r-woodru...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 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 khil...@ti.com
---
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 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 b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
---
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,
Benoit Cousson b-cous...@ti.com 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 b-cous...@ti.com
c: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Ben Dooks ben-...@fluff.org
Acked-by: Ben Dooks ben-li...@fluff.org
---
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 10:18:48PM +, aaro.koski...@nokia.com wrote: Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org 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 10:18:48PM +, aaro.koski...@nokia.com wrote: Hi, Kevin Hilman [khil...@deeprootsystems.com]: Ben Dooks ben-...@fluff.org 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-something.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] 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 samu.p.onk...@nokia.com Acked-by: Kevin Hilman khil...@deeprootsystems.com Acked-by: Paul Walmsley p...@pwsan.com 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 ben-...@fluff.org 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 ben-li...@fluff.org 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:
snip...
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.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 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 rna...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Paul Walmsley p...@pwsan.com
---
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 linux/io.h
#include linux/slab.h
#include linux/i2c-omap.h
+#include linux/pm_runtime.h
/* 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 after getting it and using it once?
/* Compute prescaler divisor */
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 felipe.ba...@nokia.com [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 mathias.ny...@nokia.com 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 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 s-...@ti.com
---
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 WRITE, EWEN, EWDS)
+ * @addr: EEPROM address to write
+ * @data: data to write
+ *
+ * eeprom_size: used to define the data coding length. Can be changed
+ * through
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 s-...@ti.com 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 s-...@ti.com 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 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 manj...@ti.com
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
Cc: Nishanth Menon n...@ti.com
---
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 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 manj...@ti.com
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
---
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] 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 hem...@ti.com
Signed-off-by: Manjunatha GK manj...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: ben-li...@fluff.org
Cc: Kalliguddi, Hema hem...@ti.com
---
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 marek.beli...@open-nandra.com
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 marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
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 plat/fpga.h
#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)-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
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 rafiuddin.s...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Paul Walmsley p...@pwsan.com
Reviewed-by: Tony Lindgren t...@atomide.com
Cc: Ben Dooks ben-li...@fluff.org
Cc: Cory Maccarrone darkstar6...@gmail.com
---
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,
+};
+
+const static u8 omap4_reg_map[] = {
+ [OMAP_I2C_REV_REG] = 0x04,
+ [OMAP_I2C_IE_REG] = 0x2c,
+ [OMAP_I2C_STAT_REG] = 0x28,
+ [OMAP_I2C_IV_REG] = 0x34,
+ [OMAP_I2C_WE_REG] = 0x34,
+ [OMAP_I2C_SYSS_REG] = 0x90,
+ [OMAP_I2C_BUF_REG] = 0x94,
+ [OMAP_I2C_CNT_REG] = 0x98,
+ [OMAP_I2C_DATA_REG] = 0x9c,
+ [OMAP_I2C_SYSC_REG] = 0x20
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 marek.beli...@open-nandra.com
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 marek.beli...@open-nandra.com
Signed-off-by: Cory Maccarrone darkstar6...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
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 plat/fpga.h
#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_REG_DATA,
host-buffer, n);
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 kgene@samsung.com --- 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 adhar...@quicinc.com 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 darkstar6...@gmail.com
---
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)
unsigned long internal_clk = 0;
if (dev-rev = OMAP_I2C_REV_2) {
-
Re:
Syed Rafiuddin wrote: From: Syed Rafiuddin rafiuddin.s...@ti.com 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: [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 rafiuddin.s...@ti.com --- 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 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 m-sonas...@ti.com Signed-off-by: Vikram Pandita vikram.pand...@ti.com 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: [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 rna...@ti.com
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 jouni.hogan...@nokia.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Cc: Jagadeesh Bhaskar Pakaravoor j-pakarav...@ti.com
Cc: Aaro Koskinen aaro.koski...@nokia.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Hu Tao ta...@motorola.com
Cc: Xiaolong Chen a21...@motorola.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
---
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;
+
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 Sonasathm-sonas...@ti.com ^ space to go in here. Signed-off-by: Vikram panditavikram.pand...@ti.com 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: [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 rafiuddin.s...@ti.com --- 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 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 Pakaravoorj-pakarav...@ti.com
Signed-off-by: Moiz Sonasathm-sonas...@ti.com
Signed-off-by: Vikram panditavikram.pand...@ti.com
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: [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 rmk+ker...@arm.linux.org.uk 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-li...@fluff.org -- 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 ext-ari.kau...@nokia.com
Acked-by: Felipe Balbi felipe.ba...@nokia.com
---
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 j-pakarav...@ti.com 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 j-pakarav...@ti.com --- 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 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 p...@pwsan.com
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 p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
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 linux/clk.h
#include linux/io.h
+/* 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
linux/interrupt.h
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: [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 p...@pwsan.com
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 p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
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 linux/clk.h
#include linux/io.h
+/* 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
linux/interrupt.h
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] 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 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: [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)
warning traceback here
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 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 controller internal clk rate should be 19.2 Mhz */
+ internal_clk = 19200;
+ fclk_rate = clk_get_rate(dev-fclk) / 1000;
+
+ /* Compute
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) ?
+ (OMAP_I2C_IE_RDR | OMAP_I2C_IE_XDR) : 0));
return 0;
}
@@ -364,6 +384,11 @@ static int omap_i2c_xfer_msg(struct i2c_adapter
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 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 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 linux/completion.h
#include linux/platform_device.h
#include linux/clk.h
-
-#include asm/io.h
+#include linux/io.h
/* 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: [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
