Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver |
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
- From: Konstantin Baydarov <kbaidarov@xxxxxxxxxxxxx>
- Date: Fri, 01 Jun 2012 17:40:25 +0400
- Cc: "Cousson, Benoit" <b-cousson@xxxxxx>, paul@xxxxxxxxx, amit.kucheria@xxxxxxxxxx, balbi@xxxxxx, kishon@xxxxxx, eduardo.valentin@xxxxxx, santosh.shilimkar@xxxxxx, J Keerthy <j-keerthy@xxxxxx>, linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx, linux-omap@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, amit.kachhap@xxxxxxxxxx
- In-reply-to: <20120601112951.GM12766@atomide.com>
- User-agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
Hi, Tony.
On 06/01/2012 03:29 PM, Tony Lindgren wrote:
> * Cousson, Benoit <b-cousson@xxxxxx> [120529 06:29]:
>> On 5/28/2012 1:35 PM, Eduardo Valentin wrote:
>>>> Mmm, we can have up to 4 control module instances in OMAP4.
>>>>
>>>> Well, I'm not sure it worth considering them as separate devices. Is
>>>> that your plan as well?
>>> At least for now I was focusing on the ctrl_module_core ...
>> OK, that's a good start already :-)
>>
>>>> But since they all have different base address, it will be trick to
>>>> handle them with only a single entry.
>>> Indeed. We can always add the support latter on.
>>>
>>> I am not sure what would be the best way to handle those instances though,
>>> and how they are going to expose APIs. Would need to have an instance bound
>>> to API set?
>> We should not go to that path I guess. We should have an API at
>> children level independent of the underlying control module
>> partitioning.
> These should be separate driver instances for the control modules.
>
> And then the ioremapped area should ignore at least the padconf
> registers so drivers/pinctrl/pinctrl-simple can handle those. There
> should not be any dependencies to the SCM driver from pinctrl-simple,
> the core SCM driver can manage the clocks and trigger the save of
> padconf regs.
>
> Also we should allow MMC driver handle the MMC specific registers
> and USB driver(s) handle the USB specific registers if possible. Those
> should not live under drivers/mfd unless there are some dependencies
> other than trying to ioremap the whole SCM module instead of ioremapping
> in each driver.
>
> 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 = __phys_to_pfn(L4_44XX_PHYS),
.length = L4_44XX_SIZE,
.type = MT_DEVICE,
...
So ioremap() always returns same virtual address (0xfc002000).
BR,
Konstantin Baydarov.
>
> Regards,
>
> Tony
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux Arm (vger)]
[ARM Kernel]
[ARM MSM]
[Linux Tegra]
[Maemo Users]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]