RE: [PATCH 2/2] MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers
Mark Brown wrote: Help people find the overall architecture. Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com --- MAINTAINERS |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index a21d4fb..9eca526 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1054,6 +1054,8 @@ F: arch/arm/plat-s3c24xx/ F: arch/arm/plat-s5p/ F: drivers/*/*s3c2410* F: drivers/*/*/*s3c2410* +F: drivers/spi/spi-s3c* +F: sound/soc/samsung/* ARM/S3C2410 ARM ARCHITECTURE M: Ben Dooks ben-li...@fluff.org -- 1.7.7.2 Hmm, I'm ok on this but needs Grant's opinion :) (Cc'ed Grant Likely) Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-pm] [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
Chanwoo Choi wrote: Hi Kukjin Kim, Please reply about Sylwester Nawrocki and me. 2011/11/3 Sylwester Nawrocki s.nawro...@samsung.com Hi Kgene, On 11/03/2011 03:09 AM, Kukjin Kim wrote: As I said, I don't think we should control/gate the clocks with regarding power domain. As far as I know there is a plan to let the drivers override start/stop_device callbacks, moreover the clock control can be disabled globally by not implementing start/stop_device callbacks or per device by not adding clkdev entities to the device clock list at runtime PM core. So IMHO, there is/going to be enough flexibility. It should be controlled by each regarding device driver and in addition, as I know, to handle block of clock is not recommended on EXYNOS4 now. What do you mean by this ? I couldn't find such information in any documentation. Shouldn't clock gate block registers be touched by boot loader and the kernel? Our boot loaders disable all clocks, and if the global clock gate is not enabled by the kernel there is no chance any multimedia device will work. Should the global clock block gate be always enabled then ? I'm afraid it is not optimal form power management POV. Sylwester, let me check again before replying. To Kukjin Kim, Hi Chanwoo, Firstly, please use text-typed e-mail when you reply. It should be controlled by each regarding device driver and in addition, as I know, to handle block of clock is not recommended on EXYNOS4 now. As you said, should we separately control power and clock of power domain? If you ask my opinion, yes, I mean when it is required, it would be controlled independent. or Have to turn on the clock of power domain always? I didn't say like that. I think that it is to happen unnecessary power consumption. I don't think, when the power of block/domain is downed, does it happen _really_ meaningful power consumption? If we have to maintain on state of power domain clock, please let me know guide about this. Also, For example, fimg2d and framebuffer use LCD0 power domain as parent device.I If fimg2d and framebuffer is disabled state due to not using their, I think that we should turn off the clock of LCD0 power domain to reduce power leakage. I think, probably it doesn't matter. If any useful data, please let me know. Which each regarding device driver control the clock of power domain? I will expect for your reply. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] [PATCH 1/3 v3] ARM: EXYNOS4: Support for generic I/O power domains on EXYNOS4210/4212
On 11/15/11, Kukjin Kim kgene@samsung.com wrote: Chanwoo Choi wrote: Hi Kukjin Kim, Please reply about Sylwester Nawrocki and me. 2011/11/3 Sylwester Nawrocki s.nawro...@samsung.com Hi Kgene, On 11/03/2011 03:09 AM, Kukjin Kim wrote: As I said, I don't think we should control/gate the clocks with regarding power domain. As far as I know there is a plan to let the drivers override start/stop_device callbacks, moreover the clock control can be disabled globally by not implementing start/stop_device callbacks or per device by not adding clkdev entities to the device clock list at runtime PM core. So IMHO, there is/going to be enough flexibility. It should be controlled by each regarding device driver and in addition, as I know, to handle block of clock is not recommended on EXYNOS4 now. What do you mean by this ? I couldn't find such information in any documentation. Shouldn't clock gate block registers be touched by boot loader and the kernel? Our boot loaders disable all clocks, and if the global clock gate is not enabled by the kernel there is no chance any multimedia device will work. Should the global clock block gate be always enabled then ? I'm afraid it is not optimal form power management POV. Sylwester, let me check again before replying. To Kukjin Kim, Hi Chanwoo, Firstly, please use text-typed e-mail when you reply. It should be controlled by each regarding device driver and in addition, as I know, to handle block of clock is not recommended on EXYNOS4 now. As you said, should we separately control power and clock of power domain? If you ask my opinion, yes, I mean when it is required, it would be controlled independent. Okay. It's meaning-less, Until change his mind, just drop it. I hope you don't change this mind for long time. Thank you, Kyungmin Park or Have to turn on the clock of power domain always? I didn't say like that. I think that it is to happen unnecessary power consumption. I don't think, when the power of block/domain is downed, does it happen _really_ meaningful power consumption? If we have to maintain on state of power domain clock, please let me know guide about this. Also, For example, fimg2d and framebuffer use LCD0 power domain as parent device.I If fimg2d and framebuffer is disabled state due to not using their, I think that we should turn off the clock of LCD0 power domain to reduce power leakage. I think, probably it doesn't matter. If any useful data, please let me know. Which each regarding device driver control the clock of power domain? I will expect for your reply. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 1/2] arm: samsung: support the second capability for samsung-soc
Jaehoon Chung wrote:
In mmc, there are capabilities and use the host_caps.
That capability is expressed with bit[0:31].
But now..already filled the bit[0:31]...
so we need to denote with the other capability field.
(if we want to use the cache, powerclass, etc for eMMC..this field is
necessary)
Hi,
This description is better than previous.
However, I wonder this is _really_ used for eMMC at sdhci-s3c.c driver.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changelog v2:
- based-on samsung-soc's for-next tree.
arch/arm/plat-samsung/include/plat/sdhci.h |2 ++
arch/arm/plat-samsung/platformdata.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
samsung/include/plat/sdhci.h
index dcff7dd..bf33ea1 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @host_caps2: The Second Standard MMC host capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -63,6 +64,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned intmax_width;
unsigned inthost_caps;
+ unsigned inthost_caps2;
enum cd_types cd_type;
enum clk_types clk_type;
diff --git a/arch/arm/plat-samsung/platformdata.c b/arch/arm/plat-
samsung/platformdata.c
index 4c9a207..5ffcf46 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -54,4 +54,6 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata
*pd,
set-host_caps |= pd-host_caps;
if (pd-clk_type)
set-clk_type = pd-clk_type;
+ if (pd-host_caps2)
+ set-host_caps2 |= pd-host_caps2;
}
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] ARM: SAMSUNG: Add pm_caps into platform data
Sangwook Lee wrote:
Add pm_caps into platform_data. This is power management, usually
for SDIO device such as SDIO WLAN.
Signed-off-by: Sangwook Lee sangwook@samsung.com
---
arch/arm/plat-samsung/dev-hsmmc3.c |2 ++
arch/arm/plat-samsung/include/plat/sdhci.h |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/dev-hsmmc3.c
b/arch/arm/plat-samsung/dev-
hsmmc3.c
index ede776f..8f467f2 100644
--- a/arch/arm/plat-samsung/dev-hsmmc3.c
+++ b/arch/arm/plat-samsung/dev-hsmmc3.c
@@ -78,6 +78,8 @@ void s3c_sdhci3_set_platdata(struct s3c_sdhci_platdata
*pd)
set-cfg_card = pd-cfg_card;
if (pd-host_caps)
set-host_caps |= pd-host_caps;
+ if (pd-pm_caps)
+ set-pm_caps |= pd-pm_caps;
if (pd-clk_type)
set-clk_type = pd-clk_type;
}
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
samsung/include/plat/sdhci.h
index 058e096..35646de 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @pm_caps: SDIO host PM capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -67,6 +68,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned intmax_width;
unsigned inthost_caps;
+ unsigned intpm_caps;
enum cd_types cd_type;
enum clk_types clk_type;
--
1.7.4.1
Hi Sangwook,
I think you need to re-work based on latest my for-next.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND][PATCH] ARM: EXYNOS: Fixed undefined symbol compilation error.
Many drivers will fail to compile if compiled as module due to
undefined symbol exynos4_ioremap.
Fix has been added by exporting the same in cpu.c file.
Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com
---
arch/arm/mach-exynos/cpu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/cpu.c b/arch/arm/mach-exynos/cpu.c
index 8e09f34..027f65471 100644
--- a/arch/arm/mach-exynos/cpu.c
+++ b/arch/arm/mach-exynos/cpu.c
@@ -8,6 +8,7 @@
* published by the Free Software Foundation.
*/
+#include linux/module.h
#include linux/sched.h
#include linux/sysdev.h
#include linux/of.h
@@ -164,6 +165,7 @@ void __iomem *exynos4_ioremap(unsigned long phy, size_t
size, unsigned int type)
return __arm_ioremap(phy, size, type);
}
+EXPORT_SYMBOL(exynos4_ioremap);
static void exynos_idle(void)
{
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] arm: samsung: support the second capability for samsung-soc
Hi Kukjin
On 11/15/2011 06:53 PM, Kukjin Kim wrote:
Jaehoon Chung wrote:
In mmc, there are capabilities and use the host_caps.
That capability is expressed with bit[0:31].
But now..already filled the bit[0:31]...
so we need to denote with the other capability field.
(if we want to use the cache, powerclass, etc for eMMC..this field is
necessary)
Hi,
This description is better than previous.
However, I wonder this is _really_ used for eMMC at sdhci-s3c.c driver.
You means that samsung is using the other, right?
If that is reason, i think that we need to add the second capability in future.
Because, Second capability also need for SD/SDIO interface.
(if need not to add the second capability,
how do you add more capabilities for SD/SDIO)
Best Regards,
Jaehoon Chung
Thanks.
Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
Changelog v2:
- based-on samsung-soc's for-next tree.
arch/arm/plat-samsung/include/plat/sdhci.h |2 ++
arch/arm/plat-samsung/platformdata.c |2 ++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/sdhci.h b/arch/arm/plat-
samsung/include/plat/sdhci.h
index dcff7dd..bf33ea1 100644
--- a/arch/arm/plat-samsung/include/plat/sdhci.h
+++ b/arch/arm/plat-samsung/include/plat/sdhci.h
@@ -40,6 +40,7 @@ enum clk_types {
* struct s3c_sdhci_platdata() - Platform device data for Samsung SDHCI
* @max_width: The maximum number of data bits supported.
* @host_caps: Standard MMC host capabilities bit field.
+ * @host_caps2: The Second Standard MMC host capabilities bit field.
* @cd_type: Type of Card Detection method (see cd_types enum above)
* @clk_type: Type of clock divider method (see clk_types enum above)
* @ext_cd_init: Initialize external card detect subsystem. Called on
@@ -63,6 +64,7 @@ enum clk_types {
struct s3c_sdhci_platdata {
unsigned intmax_width;
unsigned inthost_caps;
+unsigned inthost_caps2;
enum cd_types cd_type;
enum clk_types clk_type;
diff --git a/arch/arm/plat-samsung/platformdata.c b/arch/arm/plat-
samsung/platformdata.c
index 4c9a207..5ffcf46 100644
--- a/arch/arm/plat-samsung/platformdata.c
+++ b/arch/arm/plat-samsung/platformdata.c
@@ -54,4 +54,6 @@ void s3c_sdhci_set_platdata(struct s3c_sdhci_platdata
*pd,
set-host_caps |= pd-host_caps;
if (pd-clk_type)
set-clk_type = pd-clk_type;
+if (pd-host_caps2)
+set-host_caps2 |= pd-host_caps2;
}
--
To unsubscribe from this list: send the line unsubscribe linux-mmc 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-samsung-soc 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] MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers
On Tue, Nov 15, 2011 at 06:14:22PM +0900, Kukjin Kim wrote: Mark Brown wrote: +F: drivers/spi/spi-s3c* +F: sound/soc/samsung/* Hmm, I'm ok on this but needs Grant's opinion :) (Cc'ed Grant Likely) Note that you can have multiple entries for a single file, people are supposed to use a bit of thought when working out who to mail - if you use something like get_maintainers it'll return all matching entries. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] mmc: core: Support packed command for eMMC4.5 device
+ if (rqc) + reqs = mmc_blk_chk_packable(mq, rqc); It would be best to keep all the calls to blk_fetch_request in the same location. Therefore, I suggest to move the call to mmc_blk_chk_packable to mmc/card/queue.c after the first request is fetched. At the first time, I considered that way. I'll do more, if possible. I considered more. I think that mmc_blk_chk_packable would rather be called only for r/w type than all request type(e.g. discard, flush). mmc_blk_chk_packable can check the cmd_flags of the request to verify it's not a flush/disacrad etc. In such cases will not pack. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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: core: Fix power_off_notify during suspend
Hi, On Tue, Nov 15 2011, Girish K S wrote: The eMMC 4.5 devices respond to only RESET and AWAKE command in the sleep state. Hence the mmc switch command to notify power off state should be sent before the device enters sleep state. This patch fixes the same. Signed-off-by: Girish K S girish.shivananja...@linaro.org Thanks, pushed to mmc-next for 3.2. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 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] mmc: core: Support packed command for eMMC4.5 device
+ phys_segments += next-nr_phys_segments;
+ if (phys_segments max_phys_segs) {
+ blk_requeue_request(q, next);
+ break;
+ }
I mentioned this before - if the next request is not packable
and
requeued,
blk_fetch_request will retrieve it again and this while loop
will
never terminate.
If next request is not packable, it is requeued and 'break'
terminates
this loop.
So it not infinite.
Right !! But that doesn't help finding the commands that are
packable.
Ideally, you'd need to pack all neighbouring requests into one packed
command.
The way CFQ works, it is not necessary that the fetch would return
all
outstanding
requests that are packable (unless you invoke a forced dispatch)
It
would be good to see some numbers on the number of pack hits /
misses
that
you would encounter with this logic, on a typical usecase.
Is it considered only for CFQ scheduler? How about other I/O
scheduler?
If all requests are drained from scheduler queue forcedly,
the number of candidate to be packed can be increased.
However we may lose the unique CFQ's strength and MMC D/D may take
the
CFQ's duty.
Basically, this patch accommodates the origin order requests from
I/O
scheduler.
In order to better utilize the packed commands feature and achieve
the
best performance improvements I think that the command packing should
be
done in the block layer, according to the scheduler policy.
That is, the scheduler should be aware of the capability of the
device to
receive a request list and its constrains (such as maximum number of
requests, max number of sectors etc) and use this information as a
factor
to its algorithm.
This way you keep the decision making in the hands of the scheduler
while
the MMC layer will only have to send this list as a packed command.
Yes, it would be another interesting approach.
Command packing you mentioned means gathering request among same
direction(read/write)?
Currently I/O scheduler may know device constrains which MMC driver
informs
with the exception of order information for packed command.
But I think the dependency of I/O scheduler may be able to come up.
How can MMC layer treat packed command with I/O scheduler which
doesn't support this?
The very act of packing presumes some sorting and re-ordering at the
I/O scheduler level.
When no such sorting is done (ex. noop), MMC should resort to
non-packed execution, respecting the system configuration choice.
Looking deeper into this, I think a better approach would be to set
the prep_rq_fn of the request_queue, with a custom mmc function that
decides if the requests are packable or not, and return a
BLKPREP_DEFER for those that can't be packed.
MMC layer anticipates the favorable requests for packing from I/O
scheduler.
Obviously request order from I/O scheduler might be poor for packing and
requests can't be packed.
But that doesn't mean mmc layer need to wait a better pack-case.
BLKPREP_DEFER may give rise to I/O latency. Top of request will be
deferred next time.
If request can't be packed, it'd rather be sent at once than delayed
by returning a BLKPREP_DEFER for better responsiveness.
Thanks.
Seungwon Jeon.
The decision whether a request is packable or not should not be made per
request, therefore I don't see the need for using req_prep_fn. The MMC
layer can peek each request and decide if to pack it or not when preparing
the packed list (as suggested in this patch). The scheduler changes will
improve the probability of getting a list that can be packed.
My suggestion for the scheduler change is:
The block layer will be notified of the packing limits via new queue
limits (in blk-settings). We can make it generic to allow all kinds of
requests lists. Example for the new queue limits can be:
Is_reqs_list_supported
Max_num_of_read_reqs_in_list
Max_num_of_write_reqs_in_list
max_blk_cnt_in_list
Is_list_interleaved (optional - to support read and write requests to be
linked together, not the case for eMMC4.5)
The scheduler, that will have all the required info in the queue limits,
will be able to decide which requests can be in the same list and move all
of them to the dispatch queue (in one elevator_dispatch_fn call).
I see 2 options for preparing the list:
Option 1. blk_fetch_request will prepare the list and return a list of
requests (will require a change in struct request to include the list but
can be more generic).
Option 2. The MMC layer will prepare the list. After fetching one request
the MMC layer can call blk_peek_request and check if the next request is
packable or not. By keeping all the calls to blk_peek_request under the
same queue lock we can guarantee to get the requests that the scheduler
pushed to the dispatch queue (this requires mmc_blk_chk_packable to move
to block.c). If the
RE: [PATCH] mmc: core: Fix power_off_notify during suspend
Chris, Girish, I have question here. Are these eMMC4.5 related patches are getting tested with real eMMC4.5 cards? Regards, Subhash -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Chris Ball Sent: Tuesday, November 15, 2011 6:47 PM To: Girish K S Cc: linux-...@vger.kernel.org; patc...@linaro.org; linux-samsung- s...@vger.kernel.org Subject: Re: [PATCH] mmc: core: Fix power_off_notify during suspend Hi, On Tue, Nov 15 2011, Girish K S wrote: The eMMC 4.5 devices respond to only RESET and AWAKE command in the sleep state. Hence the mmc switch command to notify power off state should be sent before the device enters sleep state. This patch fixes the same. Signed-off-by: Girish K S girish.shivananja...@linaro.org Thanks, pushed to mmc-next for 3.2. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: SAMSUNG: Save/restore GPIO drive strength across suspend/resume
Thomas Abraham wrote at Monday, November 14, 2011 12:37 PM: ... I am not sure how this works, but with dynamic transitioning, will it be possible to program the pinmux registers dynamically when a driver/controller decides to idle for sometime and come back up again (not a system wide suspend-resume cycle). There might be a need for the driver to inform the pinmux subsystem of this case and allow the pinmux subsystem to re-program pinmux registers as required. Well, such a feature doesn't exist yet. But, I envisaged extending the existing: pmx = pinmux_get() pinmux_enable(pmx) ... pinmux_disable(pmx) pinmux_put(pmx) to something like: pmx = pinmux_get(active) pinmux_enable(pmx) ... pinmux_switch(suspend) ... pinmux_switch(active) ... pinmux_disable(pmx) pinmux_put(pmx) (I think LinusW proposed an alternative a while back last time we talked about this) This has received only limited discussion though, and there are probably many gotchas to think through; I imagine any such feature is a way off. -- nvpublic -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] pinctrl: add a gpio and pinctrl driver for samsung io-pad controllers
Add a combined gpio and pinctrl io-pad driver for Samsung platforms.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
This driver supports gpio, pinctrl and pinmux functionality. At present, all the
possible pin groups and pin functions have not been added. This driver is
designed to be reusable across all Samsung SoC's and when this implemtation is
complete, the gpio driver in driver/gpio for samsung platforms can be phased
out.
Features like GPIO interrupt support and pin-config support are yet to be added.
drivers/pinctrl/Kconfig |6 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-samsung.c | 688 +
3 files changed, 695 insertions(+), 0 deletions(-)
create mode 100644 drivers/pinctrl/pinctrl-samsung.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index e17e2f8..55739d2 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -30,6 +30,12 @@ config PINMUX_U300
depends on ARCH_U300
select PINMUX
+config PINCTRL_SAMSUNG
+ bool Samsung pinctrl driver
+ default y
+ depends on PLAT_SAMSUNG
+ select PINMUX
+
endmenu
endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index bdc548a..463b934 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_PINCTRL) += core.o
obj-$(CONFIG_PINMUX) += pinmux.o
obj-$(CONFIG_PINMUX_SIRF) += pinmux-sirf.o
obj-$(CONFIG_PINMUX_U300) += pinmux-u300.o
+obj-$(CONFIG_PINCTRL_SAMSUNG) += pinctrl-samsung.o
diff --git a/drivers/pinctrl/pinctrl-samsung.c
b/drivers/pinctrl/pinctrl-samsung.c
new file mode 100644
index 000..0705a8d
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-samsung.c
@@ -0,0 +1,688 @@
+/*
+ * pin-controller/pin-mux/pin-config/gpio-driver for Samsung's SoC's.
+ *
+ * Copyright (c) 2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ * Copyright (c) 2011 Linaro Ltd
+ * http://www.linaro.org
+ *
+ * Author: Thomas Abraham thomas.abra...@linaro.org
+ *
+ * This driver is divided into two main components, gpiolib subsystem interface
+ * and the pin-controller subsystem interface. This model help to better
+ * abstract the details of pad controller for all the Samsung SoC's. The driver
+ * is reusuable on all the Samsung SoC's, though the data that could get
+ * accumulated in this file could be daunting.
+ *
+ * The driver functions are kept as generic as possible such that they are
+ * usable across multiple Samsung SoC's. The driver data differentiates the
+ * operation of the driver for each SoC by describing the complete
+ * pad-controller structure to the driver and the generic driver code operates
+ * on the SoC specific driver data. The driver data also includes runtime data
+ * required for the operation of the driver.
+ *
+ * List of ToDo's:
+ * 1. Add GPIO Interrupt support.
+ * 2. Add external interrupt (wakeup) support.
+ * 3 Add power management support.
+ * 4 Add pin-config (pull up/down, driver strength) support.
+ * 5. Find a better way to populate data about pins and functions.
+ * 6. Add driver data, pins, groups, functions for all Samsung SoC's and test.
+ *
+ * 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
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/pinctrl/pinctrl.h
+#include linux/pinctrl/pinmux.h
+#include linux/gpio.h
+
+#include plat/map-base.h
+#include plat/map-s5p.h
+
+#define DAT_REG0x4
+
+/**
+ * struct samsung_pin_bank: represent a controller pin-bank.
+ * @reg_offset: starting offset of the pin-bank registers.
+ * @pin_base: starting pin number of the bank.
+ * @nr_pins: number of pins included in this bank.
+ * @func_width: width of the function selector bit field.
+ * @irq_base: starting eint number of the bank.
+ */
+struct samsung_pin_bank {
+ unsigned intreg_offset;
+ unsigned intpin_base;
+ unsigned intnr_pins;
+ unsigned intfunc_width;
+ unsigned intirq_base;
+};
+
+/**
+ * struct samsung_pin_ctrl: represent a pin controller.
+ * @pin_banks: list of pin banks included in this controller.
+ * @nr_banks: number of pin banks.
+ * @base: starting system wide pin number.
+ * @nr_pins: number of pins supported by the controller.
+ * @label: for debug information.
+ */
+struct samsung_pin_ctrl {
+ struct samsung_pin_bank *pin_banks;
+ unsigned intnr_banks;
+ unsigned intbase;
+ unsigned intnr_pins;
+ char*label;
+};
+
+/**
+ * struct
