Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context. It is
a working in progress.
Main changes since previous patch set version:
- Bandgap and usb phy: drivers are now independent from
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |
e API
arguments, becuase there can be only one instance control
module device.
Signed-off-by: Konstantin Baydarov
Signed-off-by: J Keerthy
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
Documentation/devicetree/bindings/mfd/omap_control.txt | 44 +
arch/arm/mach-
nctions]
Signed-off-by: Konstantin Baydarov
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
drivers/usb/otg/Kconfig | 12 ++
drivers/usb/otg/Makefile |1
drivers/usb/otg/omap4-usb-phy.c | 167 ++
in
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy
Signed-off-by: Eduardo Valentin
---
arch/arm/mach-omap2/include/mach/control.h | 116
1 files changed, 116 insertions(+), 0 de
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/arm/mach-omap2
of bandgap dynamically in bandgap driver probe
function by reading
omap core control module revision register CONTROL_GEN_CORE_REVISION.
Signed-off-by: Konstantin Baydarov
Signed-off-by: Eduardo Valentin
Signed-off-by: Keerthy
---
Documentation/devicetree/bindings/thermal/omap_bandgap.txt
This patch exposes OMAP4 thermal sensor as a thermal zone
named "cpu". Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1
driver
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarov
Hi, Tony.
On 06/20/2012 02:22 PM, Tony Lindgren wrote:
> * Konstantin Baydarov [120618 04:36]:
>> This patch introduces a MFD core device driver for
>> OMAP system control module.
>>
>> The control module allows software control of
>> various static mod
Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context. It is
a working in progress.
Main changes since previous patch set version:
- Bandgap and usb phy: drivers are now independent from con
omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov
Signed-off-by: J Keerthy
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Val
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov
---
arch/arm/mach-omap2/id.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2
or musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Konstantin Baydarov
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
---
drivers/usb/otg/Kconfig | 12 +++
drivers/u
omap4: thermal: add basic CPU thermal zone
This patch exposes OMAP4 thermal sensor as a thermal zone
named "cpu". Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin
---
drivers/thermal/Kconfi
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
> Hello,
>
> On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
>> This patch introduces a MFD core device driver for OMAP system control
>> module.
>>
>> The control module allows softwar
Hello.
On 06/28/2012 01:49 PM, Valentin, Eduardo wrote:
> Hello,
>
> On Thu, Jun 28, 2012 at 12:37 PM, Konstantin Baydarov
> wrote:
>> Hi.
>>
>> On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
>>> Hello,
>>>
>>> On Wed, Jun 27, 2012
On 06/28/2012 02:12 PM, Konstantin Baydarov wrote:
> The interface(design) of omap-control-core.c has already been discussed many
> times :(
> Eduardo, in his patch set, suggested following design:
> - omap-control-core.c ioremaps SCM window and provide functions to read/write
> S
Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context.
As Bandgap and usb phy drivers are now independent from control module driver
and they will be sent separately. IIUC, Bandgap driver has
is probed with postcore_initcall.
Control module register CONTROL_STATUS that is needed
by omap_type() is early mapped by postcore_initcall_sync.
Signed-off-by: J Keerthy
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Eduardo Valentin
Signed-off-by: Konstantin Baydarov
---
.../devicetree
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Eduardo Valentin
Signed-off-by: Konstantin Baydarov
---
arch/arm/mach-omap2/id.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentin
Signed-off-by: Konstantin Baydarov
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts
Hi, Balbi.
On 07/25/2012 03:06 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Jul 25, 2012 at 03:05:13PM +0400, Konstantin Baydarov wrote:
>> Most of the OMAP4 control module register defines are not used and
>> can be removed. Keep only needed defines and move them to com
HI, Sergei.
On 07/25/2012 04:39 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 25-07-2012 15:05, Konstantin Baydarov wrote:
>
>> OMAP system control module can be probed early, then
>> omap_type is safe to use its APIs.
>
>> TODO: add support for other omap ver
Hi, Tony.
On 08/08/2012 06:39 PM, Tony Lindgren wrote:
> * Tony Lindgren [120808 07:11]:
>> * Tony Lindgren [120808 07:05]:
>>> * Konstantin Baydarov [120725 04:10]:
>>>> +
>>>> +u32 omap_control_status_read(void)
>>>> +{
>>>>
Hi, Tony.
On 08/08/2012 06:59 PM, Konstantin Baydarov wrote:
> Yes, omap_type() is called very early , that is why I'm using
> early_initcall for omap_control_base initialization.
>
> Do you mean following?:
> void __init omap2_set_globals_control(struct omap_gl
r solution by having
> APIs with early_* prefixes, and solve the IO address mapping with
> a DT entry, for instance. But feel free to propose better ways.
In my latest version I got rid from early API set, check out patch for V3 patch
set.
I'll attach patch for current version late
0.409423] [] (plat_early_device_setup+0x2c/0x3c) from
[] (do_one_initcall+0x90/0x164)
[0.419586] [] (do_one_initcall+0x90/0x164) from []
(kernel_init+0x54/0x1a4)
[0.428771] [] (kernel_init+0x54/0x1a4) from []
(kernel_thread_exit+0x0/0x8)
[0.437957] ---[ end trace da227214a824
.end= 0x4a0027ff,
> + .flags = IORESOURCE_MEM,
> + },
> +};
Init control module platform device resources from device tree instead of
hard-coding them.
Prevent control module driver registering itself second time after it has
already been registered by early_platform_driver_register_all().
Hi.
On 05/25/2012 03:11 PM, Valentin, Eduardo wrote:
> Konstantin,
>
> On Fri, May 25, 2012 at 1:50 PM, Konstantin Baydarov
> wrote:
>> Hi.
>>
>> On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
>>> Hello Paul and Tony,
>>>
>>> This
k in omap-bandgap driver to prevent blocking of
control module general registers access.
I wasn't able to test - I have panda 4430 board.
TODO:
Prevent over-usage of spin_lock/spin_unlock for sequential calls of
bg_writel().
Signed-off-by: Konstantin Baydarov
Index: omap-thermal/drivers/mfd/o
gt; + bandgap {
> + compatible = "ti,omap4460-bandgap";
> + interrupts = <0 126 4>; /* talert */
> + ti,tshut-gpio = <86>; /* tshut */
> +
NFIG register.
So IIUC theoretically CONTROL_GEN_CORE module clock can be automatically gated.
Recalling that CONTROL_GEN_CORE module has an THERMAL_ALERT interrupt that is
used by the bandgap driver, I'm wondering if the THERMAL_ALERT interrupt will
be fired when CONTROL_GEN_CORE mod
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>Hi, Eduardo.
>>
>> On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
>>> This patch add device tree entries on OMAP4 based boards
>>> for System Cont
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
>>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>>> Hi, Eduardo.
>>>>
>>>> On 0
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
> On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
>> On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
>>> On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
>>>> Hi, Eduardo.
>>>>
>>>> On 0
Hi.
On 05/31/2012 04:52 PM, Cousson, Benoit wrote:
> On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
>> Hello,
>>
>> On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
>>>Hi.
>>>
>>> On 05/30/2012 01:26 PM, Cousson, Beno
ver.
>
> We can have a static map for the SCM, so ioremapping each driver
> individually should not be an issue.
Actually SCM registers window is mapped statically. Mapping is defined in
omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:
...
.virtual= L4_44XX_VIRT,
.pfn
On 06/01/2012 06:13 PM, Tony Lindgren wrote:
> * Konstantin Baydarov [120601 06:44]:
>> On 06/01/2012 03:29 PM, Tony Lindgren wrote:
>>> We can have a static map for the SCM, so ioremapping each driver
>>> individually should not be an issue.
>> Actually SCM regi
ce - no new clock are
registered.
So, is it fine to drop omap device and skip omap_device_build() call?
BR,
Konstantin Baydarov.
>
>> Regards,
>> Benoit
>>
>>> Signed-off-by: Kishon Vijay Abraham I
>>> Signed-off-by: Eduardo Valentin
>>> ---
>>&g
40 matches
Mail list logo
