Re: [PATCH 0/19 v4] s5p-fimc driver conversion to media controller and control framework
On 09/06/2011 10:52 PM, Mauro Carvalho Chehab wrote: > Em 03-09-2011 13:32, Sylwester Nawrocki escreveu: >> On 09/01/2011 05:30 PM, Sylwester Nawrocki wrote: >>> Hello, >>> >>> following is a fourth version of the patchset converting s5p-fimc driver >>> to the media controller API and the new control framework. >>> >>> Mauro, could you please have a look at the patches and let me know of any >>> doubts? >>> I tried to provide possibly detailed description of what each patch does >>> and why. >>> >>> The changeset is available at: >>>http://git.infradead.org/users/kmpark/linux-2.6-samsung >>>branch: v4l_fimc_for_mauro >>> >>> on top of patches from Marek's 'Videobuf2& FIMC fixes" pull request >>> which this series depends on. >> ... >>> >>> Sylwester Nawrocki (19): >>>s5p-fimc: Remove registration of video nodes from probe() >>>s5p-fimc: Remove sclk_cam clock handling >>>s5p-fimc: Limit number of available inputs to one >>>s5p-fimc: Remove sensor management code from FIMC capture driver >>>s5p-fimc: Remove v4l2_device from video capture and m2m driver >>>s5p-fimc: Add the media device driver >>>s5p-fimc: Conversion to use struct v4l2_fh >>>s5p-fimc: Convert to the new control framework >>>s5p-fimc: Add media operations in the capture entity driver >>>s5p-fimc: Add PM helper function for streaming control >>>s5p-fimc: Correct color format enumeration >>>s5p-fimc: Convert to use media pipeline operations >>>s5p-fimc: Add subdev for the FIMC processing block >>>s5p-fimc: Add support for JPEG capture >>>s5p-fimc: Add v4l2_device notification support for single frame >>> capture >>>s5p-fimc: Use consistent names for the buffer list functions >>>s5p-fimc: Add runtime PM support in the camera capture driver >>>s5p-fimc: Correct crop offset alignment on exynos4 >>>s5p-fimc: Remove single-planar capability flags >> >> oops, I've done this posting wrong, the first patch is missing here :( >> -> s5p-fimc: Add media entity initialization >> >> Still the patch set is complete at git repository as indicated above. >> I'm sorry for the confusion. > > No problem. I always check from git. > > Patches applied, thanks! Thank you! I've received the notice about patches from Marek's pull request, but the other 20 patches from this thread are not in staging/for_v3.2 branch. Are you planning to handle that later? -- Cheers. Sylwester -- 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 v2] mmc: core: Add default timeout value for CMD6.
Acked-by: Kyungmin Park
Nitpick: see below comments and typo.
On Thu, Sep 8, 2011 at 3:10 PM, Seungwon Jeon wrote:
> EXT_CSD[248] includes the default maximum timeout for CMD6.
> This field is added at eMMC4.5 Spec. And it can be used for default
> timeout except for some operations which don't define the timeout(i.e.
> background operation, sanitize, flush cache) in eMMC4.5 Spec.
>
> Signed-off-by: Seungwon Jeon
> ---
> v2 : apply default maximum timeout of CMD6 which specific timeout is not
> defined.
>
> drivers/mmc/core/mmc.c | 14 ++
> include/linux/mmc/card.h | 1 +
> include/linux/mmc/mmc.h | 1 +
> 3 files changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 5700b1c..b148bb1 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -410,6 +410,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> else
> card->erased_byte = 0x0;
>
> + if (card->ext_csd.rev >= 6)
> + card->ext_csd.generic_cmd6_time = 10 *
> + ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
Even though generic_cmd6_time is cleared at card initialization. Make
sure set the 0 when not eMMC v4.5 to make consistent with previous
version and codes.
else
card->ext_csd.generic_cmd6_time = 0;
> +
> out:
> return err;
> }
> @@ -668,7 +672,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> */
> if (card->ext_csd.enhanced_area_en) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_ERASE_GROUP_DEF, 1, 0);
> + EXT_CSD_ERASE_GROUP_DEF, 1,
> + card->ext_csd.generic_cmd6_time);
>
> if (err && err != -EBADMSG)
> goto free_card;
> @@ -711,7 +716,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> if ((card->ext_csd.hs_max_dtr != 0) &&
> (host->caps & MMC_CAP_MMC_HIGHSPEED)) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_HS_TIMING, 1, 0);
> + EXT_CSD_HS_TIMING, 1,
> + card->ext_csd.generic_cmd6_time);
> if (err && err != -EBADMSG)
> goto free_card;
>
> @@ -783,7 +789,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
> ext_csd_bits[idx][0],
> - 0);
> + card->ext_csd.generic_cmd6_time);
> if (!err) {
> mmc_set_bus_width(card->host, bus_width);
>
> @@ -806,7 +812,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_BUS_WIDTH,
> ext_csd_bits[idx][1],
> - 0);
> + card->ext_csd.generic_cmd6_time);
> }
> if (err) {
> printk(KERN_WARNING "%s: switch to bus width %d ddr %d
> "
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index b460fc2..e992fe3 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -52,6 +52,7 @@ struct mmc_ext_csd {
> u8 part_config;
> unsigned int part_time; /* Units: ms */
> unsigned int sa_timeout; /* Units: 100ns */
> + unsigned int generic_cmd6_time; /* Units: ms */
The correct unit is 10ms
> unsigned int hs_max_dtr;
> unsigned int sectors;
> unsigned int card_type;
> diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
> index 5a794cb..e869f00 100644
> --- a/include/linux/mmc/mmc.h
> +++ b/include/linux/mmc/mmc.h
> @@ -293,6 +293,7 @@ struct _mmc_csd {
> #define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
> #define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
> #define EXT_CSD_TRIM_MULT 232 /* RO */
> +#define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
>
> /*
> * EXT_CSD field definitions
> --
> 1.7.0.4
>
> --
> 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.kerne
Re: [PATCH] mmc: core: Fix the incorrect calculation for erase unit size.
Acked-by: Kyungmin Park On Thu, Sep 8, 2011 at 2:59 PM, Seungwon Jeon wrote: > Erase unit size of high capacity is multiple of 512KiB not 1024KiB. > > Signed-off-by: Seungwon Jeon > --- > drivers/mmc/core/mmc.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index b148bb1..7991ecf 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -332,7 +332,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 > *ext_csd) > card->ext_csd.hc_erase_timeout = 300 * > ext_csd[EXT_CSD_ERASE_TIMEOUT_MULT]; > card->ext_csd.hc_erase_size = > - ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 10; > + ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 9; > > card->ext_csd.rel_sectors = ext_csd[EXT_CSD_REL_WR_SEC_C]; > > -- > 1.7.0.4 > > -- > 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
[PATCH v2] mmc: core: Add default timeout value for CMD6.
EXT_CSD[248] includes the default maximum timeout for CMD6.
This field is added at eMMC4.5 Spec. And it can be used for default
timeout except for some operations which don't define the timeout(i.e.
background operation, sanitize, flush cache) in eMMC4.5 Spec.
Signed-off-by: Seungwon Jeon
---
v2 : apply default maximum timeout of CMD6 which specific timeout is not
defined.
drivers/mmc/core/mmc.c | 14 ++
include/linux/mmc/card.h |1 +
include/linux/mmc/mmc.h |1 +
3 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 5700b1c..b148bb1 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -410,6 +410,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
else
card->erased_byte = 0x0;
+ if (card->ext_csd.rev >= 6)
+ card->ext_csd.generic_cmd6_time = 10 *
+ ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
+
out:
return err;
}
@@ -668,7 +672,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
*/
if (card->ext_csd.enhanced_area_en) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_ERASE_GROUP_DEF, 1, 0);
+EXT_CSD_ERASE_GROUP_DEF, 1,
+card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
@@ -711,7 +716,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if ((card->ext_csd.hs_max_dtr != 0) &&
(host->caps & MMC_CAP_MMC_HIGHSPEED)) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_HS_TIMING, 1, 0);
+EXT_CSD_HS_TIMING, 1,
+card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
@@ -783,7 +789,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_BUS_WIDTH,
ext_csd_bits[idx][0],
-0);
+card->ext_csd.generic_cmd6_time);
if (!err) {
mmc_set_bus_width(card->host, bus_width);
@@ -806,7 +812,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_BUS_WIDTH,
ext_csd_bits[idx][1],
-0);
+card->ext_csd.generic_cmd6_time);
}
if (err) {
printk(KERN_WARNING "%s: switch to bus width %d ddr %d "
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index b460fc2..e992fe3 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -52,6 +52,7 @@ struct mmc_ext_csd {
u8 part_config;
unsigned intpart_time; /* Units: ms */
unsigned intsa_timeout; /* Units: 100ns */
+ unsigned intgeneric_cmd6_time; /* Units: ms */
unsigned inths_max_dtr;
unsigned intsectors;
unsigned intcard_type;
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index 5a794cb..e869f00 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -293,6 +293,7 @@ struct _mmc_csd {
#define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
#define EXT_CSD_SEC_FEATURE_SUPPORT231 /* RO */
#define EXT_CSD_TRIM_MULT 232 /* RO */
+#define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
/*
* EXT_CSD field definitions
--
1.7.0.4
--
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] mmc: core: Fix the incorrect calculation for erase unit size.
Erase unit size of high capacity is multiple of 512KiB not 1024KiB. Signed-off-by: Seungwon Jeon --- drivers/mmc/core/mmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c index b148bb1..7991ecf 100644 --- a/drivers/mmc/core/mmc.c +++ b/drivers/mmc/core/mmc.c @@ -332,7 +332,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd) card->ext_csd.hc_erase_timeout = 300 * ext_csd[EXT_CSD_ERASE_TIMEOUT_MULT]; card->ext_csd.hc_erase_size = - ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 10; + ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] << 9; card->ext_csd.rel_sectors = ext_csd[EXT_CSD_REL_WR_SEC_C]; -- 1.7.0.4 -- 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 v3 2/2] mmc: core: Add Poweroff Notify handling eMMC 4.5
Hi Girish,
Could you check my feedbacks about previous version?
There is something misunderstood.
I added comment below.
Best regards,
Seungwon Jeon.
Girish K S wrote:
>
> This patch adds the power off notification handling
> during suspend and system poweroff.
> For suspend mode short timeout is used, whereas for the
> normal poweroff long timeout is used.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/core.c | 33 +
> drivers/mmc/core/mmc.c |4 +++-
> drivers/mmc/host/sdhci.c | 10 ++
> include/linux/mmc/card.h | 19 +++
> include/linux/mmc/host.h |4
> 5 files changed, 69 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 91a0a74..da5d298 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1130,9 +1130,38 @@ static void mmc_power_up(struct mmc_host *host)
>
> static void mmc_power_off(struct mmc_host *host)
> {
> + struct mmc_card *card = host->card;
> + unsigned int notify_type;
> + unsigned int timeout;
> + int err;
> +
> host->ios.clock = 0;
> host->ios.vdd = 0;
>
> + if (mmc_card_mmc(card) &&
> + (mmc_card_powernotify_on(card))) {
> +
> + if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
> + notify_type = EXT_CSD_POWER_OFF_SHORT;
> + timeout = card->ext_csd.generic_cmd6_time;
> + mmc_card_set_powernotify_short(card);
> + } else {
> + notify_type = EXT_CSD_POWER_OFF_LONG;
> + timeout = card->ext_csd.power_off_longtime;
> + mmc_card_set_powernotify_long(card);
> + }
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_OFF_NOTIFICATION,
> + notify_type, timeout);
> +
> + if (err && err != -EBADMSG)
> + printk(KERN_ERR "Device failed to respond "
> + "within %d poweroff time."
> + "forcefully powering down"
> + "the device\n", timeout);
> + }
> +
> /*
>* Reset ocr mask to be the highest possible voltage supported for
>* this mmc host. This value will be used at next power up.
> @@ -1147,6 +1176,8 @@ static void mmc_power_off(struct mmc_host *host)
> host->ios.bus_width = MMC_BUS_WIDTH_1;
> host->ios.timing = MMC_TIMING_LEGACY;
> mmc_set_ios(host);
> + /*Set the card state to no notification after the poweroff*/
> + mmc_card_set_powernotify_off(card);
> }
>
> /*
> @@ -2022,6 +2053,7 @@ int mmc_pm_notify(struct notifier_block
> *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 1;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
> spin_unlock_irqrestore(&host->lock, flags);
> cancel_delayed_work_sync(&host->detect);
>
> @@ -2044,6 +2076,7 @@ int mmc_pm_notify(struct notifier_block
> *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 0;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
> spin_unlock_irqrestore(&host->lock, flags);
> mmc_detect_change(host, 0);
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 2f06b37..8868da8 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -715,13 +715,15 @@ static int mmc_init_card(struct mmc_host *host, u32
> ocr,
>* If the host supports the power_off_notify capability then
>* set the notification byte in the ext_csd register of device
>*/
> - if (host->caps & MMC_CAP_POWER_OFF_NOTIFY) {
> + if ((host->caps & MMC_CAP_POWER_OFF_NOTIFY) &&
> + (mmc_card_powernotify_off(card))) {
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> EXT_CSD_POWER_OFF_NOTIFICATION,
> EXT_CSD_POWER_ON,
> card->ext_csd.generic_cmd6_time);
> if (err && err != -EBADMSG)
> goto free_card;
> + mmc_card_set_powernotify_on(card);
Even if err is -EBADMSG, mmc_card_set_powernotify_on() will be executed.
In such cases, mmc_card_set_powernotify_off() will be correct.
> }
>
> /*
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e02cc1..92ea734 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2566,6 +2566,16 @@ int sdhci_add_host(struct sdhci_host *host)
> if (caps[1] & SDHCI_DRIVER_TYPE_D)
> mmc->caps |= MMC_CAP_DRIVER_TYPE_D;
>
> + /*
> + * If Notify capability is enabled and
> + * notify ty
[PATCH v3 0/2] mmc: core: Add Poweroff Notify handling eMMC 4.5
This patch series adds the power off notification handling during suspend and system poweroff. For suspend mode short timeout is used, whereas for the normal poweroff long timeout is used. Includes the updates suggested for V2 patches. Girish K S (2): mmc: core: Add power off notify feature(eMMC 4.5) mmc: core: Add Poweroff Notify handling drivers/mmc/core/core.c | 33 + drivers/mmc/core/mmc.c | 21 +++-- drivers/mmc/host/sdhci.c | 10 ++ include/linux/mmc/card.h | 20 include/linux/mmc/host.h |5 + include/linux/mmc/mmc.h |7 +++ 6 files changed, 94 insertions(+), 2 deletions(-) -- 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] input: samsung-keypad: Add device tree support
Hi Dmitry,
On 8 September 2011 02:20, Dmitry Torokhov wrote:
> Hi Thomas,
>
> On Tue, Sep 06, 2011 at 07:25:17PM +0530, Thomas Abraham wrote:
>> static int samsung_keypad_is_s5pv210(struct device *dev)
>> {
>> struct platform_device *pdev = to_platform_device(dev);
>> - enum samsung_keypad_type type =
>> - platform_get_device_id(pdev)->driver_data;
>> + enum samsung_keypad_type type;
>>
>> +#ifdef CONFIG_OF
>> + if (dev->of_node)
>> + return of_device_is_compatible(dev->of_node,
>> + "samsung,s5pv210-keypad");
>> +#endif
>> + type = platform_get_device_id(pdev)->driver_data;
>> return type == KEYPAD_TYPE_S5PV210;
>
> This function is called every time we scan keypad matrix, I do not think
> you want to scan DT bindings here. You need to cache the device type at
> probe time and use it.
Ok. As you suggested, this will be changed to cache the type in driver
private data during probe and use the cached copy when required.
>
>> }
>>
>> @@ -235,6 +246,130 @@ static void samsung_keypad_close(struct input_dev
>> *input_dev)
>> samsung_keypad_stop(keypad);
>> }
>>
>> +#ifdef CONFIG_OF
>> +static
>> +struct samsung_keypad_platdata *samsung_keypad_parse_dt(struct device *dev)
>> +{
>> + struct samsung_keypad_platdata *pdata;
>> + struct matrix_keymap_data *keymap_data;
>> + uint32_t *keymap;
>> + struct device_node *np = dev->of_node, *key_np;
>> + unsigned int key_count = 0;
>> +
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata) {
>> + dev_err(dev, "could not allocate memory for platform data\n");
>> + return NULL;
>> + }
>
> pdata is not used once probe() completes so it would be better to free
> it and not rely on devm_* facilities to free it for you once device
> unbinds from the driver.
Ok. That would be better. pdata will be freed after probe completes.
>
>> +
>> + of_property_read_u32(np, "samsung,keypad-num-rows", &pdata->rows);
>> + of_property_read_u32(np, "samsung,keypad-num-columns", &pdata->cols);
>> + if (!pdata->rows || !pdata->cols) {
>> + dev_err(dev, "number of keypad rows/columns not specified\n");
>> + return NULL;
>> + }
>> +
>> + keymap_data = devm_kzalloc(dev, sizeof(*keymap_data), GFP_KERNEL);
>> + if (!keymap_data) {
>> + dev_err(dev, "could not allocate memory for keymap data\n");
>> + return NULL;
>> + }
>> + pdata->keymap_data = keymap_data;
>> +
>> + for_each_child_of_node(np, key_np)
>> + key_count++;
>> +
>> + keymap_data->keymap_size = key_count;
>> + keymap = devm_kzalloc(dev, sizeof(uint32_t) * key_count, GFP_KERNEL);
>> + if (!keymap) {
>> + dev_err(dev, "could not allocate memory for keymap\n");
>> + return NULL;
>> + }
>> + keymap_data->keymap = keymap;
>> +
>> + for_each_child_of_node(np, key_np) {
>> + unsigned int row, col, key_code;
>> + of_property_read_u32(key_np, "keypad,row", &row);
>> + of_property_read_u32(key_np, "keypad,column", &col);
>> + of_property_read_u32(key_np, "keypad,key-code", &key_code);
>> + *keymap++ = KEY(row, col, key_code);
>> + }
>
> THis seems like generic mechanism that could be used by other drivers...
> Maybe move into matrix-keypad.c? You would also not need to allocate
> temporary buffer for intermediate keymap data.
Yes, this could be reused in other drivers as well. But, moving this
into matrix-keypad.c file means that KEYBOARD_MATRIX config option
would have to be selected for all platforms reusing this code. So, I
am not sure of the right place for this.
>
>> +
>> + if (of_get_property(np, "linux,input-no-autorepeat", NULL))
>> + pdata->no_autorepeat = true;
>> + if (of_get_property(np, "linux,input-wakeup", NULL))
>> + pdata->wakeup = true;
>> +
>> + return pdata;
>> +}
>> +
>> +static void samsung_keypad_parse_dt_gpio(struct device *dev,
>> + struct samsung_keypad *keypad)
>> +{
>> + struct device_node *np = dev->of_node;
>> + int gpio, ret, row, col;
>> +
>> + for (row = 0; row < keypad->rows; row++) {
>> + gpio = of_get_named_gpio(np, "row-gpios", row);
>> + keypad->row_gpios[row] = gpio;
>> + if (!gpio_is_valid(gpio)) {
>> + dev_err(dev, "keypad row[%d]: invalid gpio %d\n",
>> + row, gpio);
>> + continue;
>> + }
>> +
>> + ret = gpio_request(gpio, "keypad-row");
>> + if (ret)
>> + dev_err(dev, "keypad row[%d] gpio request failed\n",
>> + row);
>> + }
>> +
>> + for (col = 0; col < keypad->cols; col++) {
>> + gpio = of_get_named_gpio(np, "col-gpios", col);
>> +
[PATCH v3 2/2] mmc: core: Add Poweroff Notify handling eMMC 4.5
This patch adds the power off notification handling
during suspend and system poweroff.
For suspend mode short timeout is used, whereas for the
normal poweroff long timeout is used.
Signed-off-by: Girish K S
---
drivers/mmc/core/core.c | 33 +
drivers/mmc/core/mmc.c |4 +++-
drivers/mmc/host/sdhci.c | 10 ++
include/linux/mmc/card.h | 19 +++
include/linux/mmc/host.h |4
5 files changed, 69 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 91a0a74..da5d298 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1130,9 +1130,38 @@ static void mmc_power_up(struct mmc_host *host)
static void mmc_power_off(struct mmc_host *host)
{
+ struct mmc_card *card = host->card;
+ unsigned int notify_type;
+ unsigned int timeout;
+ int err;
+
host->ios.clock = 0;
host->ios.vdd = 0;
+ if (mmc_card_mmc(card) &&
+ (mmc_card_powernotify_on(card))) {
+
+ if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
+ notify_type = EXT_CSD_POWER_OFF_SHORT;
+ timeout = card->ext_csd.generic_cmd6_time;
+ mmc_card_set_powernotify_short(card);
+ } else {
+ notify_type = EXT_CSD_POWER_OFF_LONG;
+ timeout = card->ext_csd.power_off_longtime;
+ mmc_card_set_powernotify_long(card);
+ }
+
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_POWER_OFF_NOTIFICATION,
+ notify_type, timeout);
+
+ if (err && err != -EBADMSG)
+ printk(KERN_ERR "Device failed to respond "
+ "within %d poweroff time."
+ "forcefully powering down"
+ "the device\n", timeout);
+ }
+
/*
* Reset ocr mask to be the highest possible voltage supported for
* this mmc host. This value will be used at next power up.
@@ -1147,6 +1176,8 @@ static void mmc_power_off(struct mmc_host *host)
host->ios.bus_width = MMC_BUS_WIDTH_1;
host->ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
+ /*Set the card state to no notification after the poweroff*/
+ mmc_card_set_powernotify_off(card);
}
/*
@@ -2022,6 +2053,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
spin_lock_irqsave(&host->lock, flags);
host->rescan_disable = 1;
+ host->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
spin_unlock_irqrestore(&host->lock, flags);
cancel_delayed_work_sync(&host->detect);
@@ -2044,6 +2076,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
spin_lock_irqsave(&host->lock, flags);
host->rescan_disable = 0;
+ host->power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
spin_unlock_irqrestore(&host->lock, flags);
mmc_detect_change(host, 0);
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 2f06b37..8868da8 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -715,13 +715,15 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
* If the host supports the power_off_notify capability then
* set the notification byte in the ext_csd register of device
*/
- if (host->caps & MMC_CAP_POWER_OFF_NOTIFY) {
+ if ((host->caps & MMC_CAP_POWER_OFF_NOTIFY) &&
+ (mmc_card_powernotify_off(card))) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_POWER_OFF_NOTIFICATION,
EXT_CSD_POWER_ON,
card->ext_csd.generic_cmd6_time);
if (err && err != -EBADMSG)
goto free_card;
+ mmc_card_set_powernotify_on(card);
}
/*
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 0e02cc1..92ea734 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2566,6 +2566,16 @@ int sdhci_add_host(struct sdhci_host *host)
if (caps[1] & SDHCI_DRIVER_TYPE_D)
mmc->caps |= MMC_CAP_DRIVER_TYPE_D;
+ /*
+* If Notify capability is enabled and
+* notify type is not initialised by host, set default to
+* long power off notify timeout value
+*/
+ if (mmc->caps & MMC_CAP_POWER_OFF_NOTIFY)
+ mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
+ else
+ mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
+
/* Initial value for re-tuning timer count */
host->tuning_count = (caps[1] & SDHCI_RETUN
[PATCH v3 1/2] mmc: core: Add power off notify feature(eMMC 4.5)
This patch adds the support for power off notify feature
available in eMMC 4.5 devices.
If the the host has support for this feature, then the
mmc core will notify it to the device by setting the
POWER_OFF_NOTIFICATION byte in the extended csd register
with a value 1(POWER_ON).
This patch should be applied after Seungwon Jeon's
patch for cmd6 timeout.
Signed-off-by: Girish K S
---
drivers/mmc/core/mmc.c | 19 +--
include/linux/mmc/card.h |1 +
include/linux/mmc/host.h |1 +
include/linux/mmc/mmc.h |7 +++
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 68eb368..2f06b37 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -410,10 +410,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
else
card->erased_byte = 0x0;
- if (card->ext_csd.rev >= 6)
+ if (card->ext_csd.rev >= 6) {
card->ext_csd.generic_cmd6_time = 10 *
ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
-
+ card->ext_csd.power_off_longtime = 10 *
+ ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
+ }
out:
return err;
}
@@ -710,6 +712,19 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
/*
+* If the host supports the power_off_notify capability then
+* set the notification byte in the ext_csd register of device
+*/
+ if (host->caps & MMC_CAP_POWER_OFF_NOTIFY) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+ EXT_CSD_POWER_OFF_NOTIFICATION,
+ EXT_CSD_POWER_ON,
+ card->ext_csd.generic_cmd6_time);
+ if (err && err != -EBADMSG)
+ goto free_card;
+ }
+
+ /*
* Activate high speed (if supported)
*/
if ((card->ext_csd.hs_max_dtr != 0) &&
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index e992fe3..2bf2843 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -53,6 +53,7 @@ struct mmc_ext_csd {
unsigned intpart_time; /* Units: ms */
unsigned intsa_timeout; /* Units: 100ns */
unsigned intgeneric_cmd6_time; /* Units: ms */
+ unsigned intpower_off_longtime; /* Units: ms */
unsigned inths_max_dtr;
unsigned intsectors;
unsigned intcard_type;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 1d09562..cf2dadc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -229,6 +229,7 @@ struct mmc_host {
#define MMC_CAP_MAX_CURRENT_600(1 << 28) /* Host max current
limit is 600mA */
#define MMC_CAP_MAX_CURRENT_800(1 << 29) /* Host max current
limit is 800mA */
#define MMC_CAP_CMD23 (1 << 30) /* CMD23 supported. */
+#define MMC_CAP_POWER_OFF_NOTIFY(1 << 31)/*Notify poweroff supported */
mmc_pm_flag_t pm_caps;/* supported pm features */
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index e869f00..a788e01 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -270,6 +270,7 @@ struct _mmc_csd {
* EXT_CSD fields
*/
+#define EXT_CSD_POWER_OFF_NOTIFICATION 34 /* R/W */
#define EXT_CSD_PARTITION_ATTRIBUTE156 /* R/W */
#define EXT_CSD_PARTITION_SUPPORT 160 /* RO */
#define EXT_CSD_WR_REL_PARAM 166 /* RO */
@@ -293,6 +294,7 @@ struct _mmc_csd {
#define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
#define EXT_CSD_SEC_FEATURE_SUPPORT231 /* RO */
#define EXT_CSD_TRIM_MULT 232 /* RO */
+#define EXT_CSD_POWER_OFF_LONG_TIME247 /*RO*/
#define EXT_CSD_GENERIC_CMD6_TIME 248 /* RO */
/*
@@ -329,6 +331,11 @@ struct _mmc_csd {
#define EXT_CSD_SEC_BD_BLK_EN BIT(2)
#define EXT_CSD_SEC_GB_CL_EN BIT(4)
+#define EXT_CSD_NO_POWER_NOTIFICATION 0
+#define EXT_CSD_POWER_ON 1
+#define EXT_CSD_POWER_OFF_SHORT2
+#define EXT_CSD_POWER_OFF_LONG 3
+
/*
* MMC_SWITCH access modes
*/
--
1.7.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
[RESEND PATCH] ARM: EXYNOS4: Add machine support for 7" LCD on ORIGEN
ORIGEN board is fitted with 7" LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Signed-off-by: Tushar Behera
---
The original patch-mail bounced back from linux-samsung-soc@vger.kernel.org,
hence resending the patch again.
The patch is rebased on [1]. For proper working of LCD on ORIGEN,
following patches are needed. These patches are already submitted to
the mailing list.
a. ARM: EXYNOS4: Add PWM backlight support on Origen
Author: Giridhar Maruthy
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Author: Inderpal Singh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
arch/arm/mach-exynos4/Kconfig |2 +
arch/arm/mach-exynos4/mach-origen.c | 50 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..8656f49 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,8 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..f2cea78 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,21 @@
#include
#include
#include
+#include
+
+#include
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
@@ -79,10 +84,54 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, "GPE3_4");
+ gpio_direction_output(gpio, power);
+ gpio_free(gpio);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = "platform-lcd",
+ .dev.parent = &s5p_device_fimd0.dev,
+ .dev.platform_data = &origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = &origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
&s3c_device_hsmmc2,
&s3c_device_rtc,
&s3c_device_wdt,
+ &s5p_device_fimd0,
+ &origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,6 +144,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(&origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
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: [PATCH 1/2] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
Hi Dmitry,
On 8 September 2011 03:19, Dmitry Torokhov wrote:
[...]
> BTW, should we do something like below?
>
> Thanks.
>
> --
> Dmitry
>
> Input: samsung-keypad - enable compiling on other platforms
>
> From: Dmitry Torokhov
>
> There is nothing in keypad platform definitions that requires
> the driver be complied on Samsung platform only, so let's move them
> out of the platform subdirectory and relax the dependencies.
>
> Signed-off-by: Dmitry Torokhov
> ---
>
> arch/arm/plat-samsung/include/plat/keypad.h | 27 +
> drivers/input/keyboard/Kconfig | 5 ++-
> drivers/input/keyboard/samsung-keypad.c | 2 +
> include/linux/input/samsung-keypad.h | 43
> +++
> 4 files changed, 48 insertions(+), 29 deletions(-)
> create mode 100644 include/linux/input/samsung-keypad.h
>
>
> diff --git a/arch/arm/plat-samsung/include/plat/keypad.h
> b/arch/arm/plat-samsung/include/plat/keypad.h
> index b59a648..8fddee3 100644
> --- a/arch/arm/plat-samsung/include/plat/keypad.h
> +++ b/arch/arm/plat-samsung/include/plat/keypad.h
> @@ -13,32 +13,7 @@
> #ifndef __PLAT_SAMSUNG_KEYPAD_H
> #define __PLAT_SAMSUNG_KEYPAD_H
>
> -#include
> -
> -#define SAMSUNG_MAX_ROWS 8
> -#define SAMSUNG_MAX_COLS 8
> -
> -/**
> - * struct samsung_keypad_platdata - Platform device data for Samsung Keypad.
> - * @keymap_data: pointer to &matrix_keymap_data.
> - * @rows: number of keypad row supported.
> - * @cols: number of keypad col supported.
> - * @no_autorepeat: disable key autorepeat.
> - * @wakeup: controls whether the device should be set up as wakeup source.
> - * @cfg_gpio: configure the GPIO.
> - *
> - * Initialisation data specific to either the machine or the platform
> - * for the device driver to use or call-back when configuring gpio.
> - */
> -struct samsung_keypad_platdata {
> - const struct matrix_keymap_data *keymap_data;
> - unsigned int rows;
> - unsigned int cols;
> - bool no_autorepeat;
> - bool wakeup;
> -
> - void (*cfg_gpio)(unsigned int rows, unsigned int cols);
> -};
> +#include
>
> /**
> * samsung_keypad_set_platdata - Set platform data for Samsung Keypad device.
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index de846f8..db1b221 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -434,9 +434,10 @@ config KEYBOARD_PMIC8XXX
>
> config KEYBOARD_SAMSUNG
> tristate "Samsung keypad support"
> - depends on SAMSUNG_DEV_KEYPAD
> + depends on HAVE_CLK
> help
> - Say Y here if you want to use the Samsung keypad.
> + Say Y here if you want to use the keypad on your Samsung mobile
> + device.
In this case, Samsung Keyboad option would be listed in the available
keyboard list in menuconfig for non-samsung platforms as well. Knowing
that Samsung keypad controller has been used only in Samsung
Application Processor SoC's only (and would be this way for quite
sometime), should we not retain its selection to Samsung AP SoC's
only?
>
> To compile this driver as a module, choose M here: the
> module will be called samsung-keypad.
> diff --git a/drivers/input/keyboard/samsung-keypad.c
> b/drivers/input/keyboard/samsung-keypad.c
> index d244fdf..1a2b755 100644
> --- a/drivers/input/keyboard/samsung-keypad.c
> +++ b/drivers/input/keyboard/samsung-keypad.c
> @@ -22,7 +22,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #define SAMSUNG_KEYIFCON 0x00
> #define SAMSUNG_KEYIFSTSCLR 0x04
> diff --git a/include/linux/input/samsung-keypad.h
> b/include/linux/input/samsung-keypad.h
> new file mode 100644
> index 000..f25619b
> --- /dev/null
> +++ b/include/linux/input/samsung-keypad.h
> @@ -0,0 +1,43 @@
> +/*
> + * Samsung Keypad platform data definitions
> + *
> + * Copyright (C) 2010 Samsung Electronics Co.Ltd
> + * Author: Joonyoung Shim
> + *
> + * 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.
> + */
> +
> +#ifndef __SAMSUNG_KEYPAD_H
> +#define __SAMSUNG_KEYPAD_H
> +
> +#include
> +
> +#define SAMSUNG_MAX_ROWS 8
> +#define SAMSUNG_MAX_COLS 8
> +
> +/**
> + * struct samsung_keypad_platdata - Platform device data for Samsung Keypad.
> + * @keymap_data: pointer to &matrix_keymap_data.
> + * @rows: number of keypad row supported.
> + * @cols: number of keypad col supported.
> + * @no_autorepeat: disable key autorepeat.
> + * @wakeup: controls whether the device should be set up as wakeup source.
> + * @cfg_gpio: configure the GPIO.
> + *
> + * Initialisation data specific to either the machine or the platform
> + * for the device driver to use or call-back when configuring gp
Re: [PATCH 1/2] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
Hi Dmitry, On 7 September 2011 23:52, Dmitry Torokhov wrote: > Hi Thomas, > > On Tue, Sep 06, 2011 at 07:25:16PM +0530, Thomas Abraham wrote: >> Samsung keyboard driver could be used with platforms using device tree. >> So the inclusion of samsung keyboard driver cannot be based on >> SAMSUNG_DEV_KEYPAD. A new config option HAVE_SAMSUNG_KEYPAD is added >> which device tree based platforms should use to include samsung keyboard >> driver. > > I am sorry, I do not follow... What is the difference between > SAMSUNG_DEV_KEYPAD and HAVE_SAMSUNG_KEYPAD? They look exactly the same. The inclusion of platform device instance for keypad (in arch/arm/plat-samsung/dev-keypad.c) in the build depends on SAMSUNG_DEV_KEYPAD. The samsung-keypad driver is also dependent on SAMSUNG_DEV_KEYPAD. In case of device tree based instantiation of keypad, compilation of dev-keypad.c file is not required. So SAMSUNG_DEV_KEYPAD config option will not be selected.In that case, the compilation of the keypad driver cannot be dependent on SAMSUNG_DEV_KEYPAD. There should be another option to select the keypad driver and so HAVE_SAMSUNG_KEYPAD was introduced. HAVE_SAMSUNG_KEYPAD can be selected on platforms that need the samsung-keypad driver but do no need the keypad platform device. Thanks for your review and comments. Regards, Thomas. > > Thanks, > >> >> Signed-off-by: Thomas Abraham >> --- >> drivers/input/keyboard/Kconfig | 9 - >> 1 files changed, 8 insertions(+), 1 deletions(-) >> >> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig >> index b4dee9d..370fb18 100644 >> --- a/drivers/input/keyboard/Kconfig >> +++ b/drivers/input/keyboard/Kconfig >> @@ -423,9 +423,16 @@ config KEYBOARD_PMIC8XXX >> To compile this driver as a module, choose M here: the module will >> be called pmic8xxx-keypad. >> >> +config HAVE_SAMSUNG_KEYPAD >> + bool >> + help >> + This will include Samsung Keypad controller driver support. If you >> + want to include Samsung Keypad support for any machine, kindly >> + select this in the respective mach-/Kconfig file. >> + >> config KEYBOARD_SAMSUNG >> tristate "Samsung keypad support" >> - depends on SAMSUNG_DEV_KEYPAD >> + depends on SAMSUNG_DEV_KEYPAD || HAVE_SAMSUNG_KEYPAD >> help >> Say Y here if you want to use the Samsung keypad. >> >> -- >> 1.6.6.rc2 >> > > -- > Dmitry > -- 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 v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
Jassi Brar wrote:
> Subject: Re: [PATCH v8 04/16] DMA: PL330: Remove the start operation
> for handling DMA_TERMINATE_ALL command
>
> On 7 September 2011 12:53, Kukjin Kim wrote:
> > Jassi Brar wrote:
> >>
> >> On 6 September 2011 17:57, Russell King - ARM Linux
> >> wrote:
> >> > On Tue, Sep 06, 2011 at 05:52:19PM +0530, Jassi Brar wrote:
> >> >> On Fri, Sep 2, 2011 at 6:14 AM, Boojin Kim
> wrote:
> >> >> > Origianl code carries out the start operation after flush
> operation.
> >> >> > But start operation is not required for DMA_TERMINATE_ALL
> command.
> >> >> > So, This patch removes the unnecessary start operation and
> only carries out
> >> >> > the flush oeration for handling DMA_TERMINATE_ALL command.
> >> >>
> >> >> Not exactly. The 'start' is impotent when called from this path
> because there
> >> >> is nothing left queued after the call to 'flush'.
> >> >> pl330_tasklet() is called because that is a common function that
> does the
> >> >> house-keeping acc to what's presently in 'work' and 'done' lists.
> >> >>
> >> >> Though as a side-effect, your patch does avoid doing callbacks
> on submitted
> >> >> xfers during DMA_TERMINATE_ALL - which may or may not be the
> right thing
> >> >> to do.
> >> >
> >> > It is defined that DMA_TERMINATE_ALL does not call the callbacks:
> >> >
> >> > 1. int dmaengine_terminate_all(struct dma_chan *chan)
> >> >
> >> > � This causes all activity for the DMA channel to be stopped, and
> may
> >> > � discard data in the DMA FIFO which hasn't been fully transferred.
> >> > � No callback functions will be called for any incomplete
> transfers.
> >> >
> >> Ok, thanks for the info.
> >>
> >> Boojin Kim, please re-write the changelog to state only preventing
> >> callbacks during DMA_TERMINATE_ALL as the reason.
> >
> > As above, we don't need callback as well start operation in
> DMA_TERMIANTE_ALL command and her patch just removed them for
> DMA_TERMINATE_ALL here. So current git message seems to have proper
> behavior of patch.
> >
> Nopes.
>
> No modification to current code is needed if only the following is to
> be the reason.
> {
> Origianl code carries out the start operation after flush operation.
> But start operation is not required for DMA_TERMINATE_ALL command.
> So, This patch removes the unnecessary start operation and only
> carries out
> the flush oeration for handling DMA_TERMINATE_ALL command.
> }
>
> The patch, however, has unintended good effect of "preventing
> callbacks
> from DMA_TERMINATE_ALL".
> The only valid reason, and which is no way implied by the changelog.
According to dmaengine document, dmaengine_terminate_all() is used to pause
or stop the channel. So, dmaengine_terminate_all() doesn뭪 need to have the
start operation and callback calling.
This patch is originally aimed at removing unnecessary operations including
the start operation and callback call for dmaengine_terminate_all(). And I
think my message pretty expresses the purpose of this patch.
Thanks,
Boojin kim
--
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] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
On Wed, Sep 07, 2011 at 11:22:48AM -0700, Dmitry Torokhov wrote:
> Hi Thomas,
>
> On Tue, Sep 06, 2011 at 07:25:16PM +0530, Thomas Abraham wrote:
> > Samsung keyboard driver could be used with platforms using device tree.
> > So the inclusion of samsung keyboard driver cannot be based on
> > SAMSUNG_DEV_KEYPAD. A new config option HAVE_SAMSUNG_KEYPAD is added
> > which device tree based platforms should use to include samsung keyboard
> > driver.
>
> I am sorry, I do not follow... What is the difference between
> SAMSUNG_DEV_KEYPAD and HAVE_SAMSUNG_KEYPAD? They look exactly the same.
>
BTW, should we do something like below?
Thanks.
--
Dmitry
Input: samsung-keypad - enable compiling on other platforms
From: Dmitry Torokhov
There is nothing in keypad platform definitions that requires
the driver be complied on Samsung platform only, so let's move them
out of the platform subdirectory and relax the dependencies.
Signed-off-by: Dmitry Torokhov
---
arch/arm/plat-samsung/include/plat/keypad.h | 27 +
drivers/input/keyboard/Kconfig |5 ++-
drivers/input/keyboard/samsung-keypad.c |2 +
include/linux/input/samsung-keypad.h| 43 +++
4 files changed, 48 insertions(+), 29 deletions(-)
create mode 100644 include/linux/input/samsung-keypad.h
diff --git a/arch/arm/plat-samsung/include/plat/keypad.h
b/arch/arm/plat-samsung/include/plat/keypad.h
index b59a648..8fddee3 100644
--- a/arch/arm/plat-samsung/include/plat/keypad.h
+++ b/arch/arm/plat-samsung/include/plat/keypad.h
@@ -13,32 +13,7 @@
#ifndef __PLAT_SAMSUNG_KEYPAD_H
#define __PLAT_SAMSUNG_KEYPAD_H
-#include
-
-#define SAMSUNG_MAX_ROWS 8
-#define SAMSUNG_MAX_COLS 8
-
-/**
- * struct samsung_keypad_platdata - Platform device data for Samsung Keypad.
- * @keymap_data: pointer to &matrix_keymap_data.
- * @rows: number of keypad row supported.
- * @cols: number of keypad col supported.
- * @no_autorepeat: disable key autorepeat.
- * @wakeup: controls whether the device should be set up as wakeup source.
- * @cfg_gpio: configure the GPIO.
- *
- * Initialisation data specific to either the machine or the platform
- * for the device driver to use or call-back when configuring gpio.
- */
-struct samsung_keypad_platdata {
- const struct matrix_keymap_data *keymap_data;
- unsigned int rows;
- unsigned int cols;
- bool no_autorepeat;
- bool wakeup;
-
- void (*cfg_gpio)(unsigned int rows, unsigned int cols);
-};
+#include
/**
* samsung_keypad_set_platdata - Set platform data for Samsung Keypad device.
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index de846f8..db1b221 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -434,9 +434,10 @@ config KEYBOARD_PMIC8XXX
config KEYBOARD_SAMSUNG
tristate "Samsung keypad support"
- depends on SAMSUNG_DEV_KEYPAD
+ depends on HAVE_CLK
help
- Say Y here if you want to use the Samsung keypad.
+ Say Y here if you want to use the keypad on your Samsung mobile
+ device.
To compile this driver as a module, choose M here: the
module will be called samsung-keypad.
diff --git a/drivers/input/keyboard/samsung-keypad.c
b/drivers/input/keyboard/samsung-keypad.c
index d244fdf..1a2b755 100644
--- a/drivers/input/keyboard/samsung-keypad.c
+++ b/drivers/input/keyboard/samsung-keypad.c
@@ -22,7 +22,7 @@
#include
#include
#include
-#include
+#include
#define SAMSUNG_KEYIFCON 0x00
#define SAMSUNG_KEYIFSTSCLR0x04
diff --git a/include/linux/input/samsung-keypad.h
b/include/linux/input/samsung-keypad.h
new file mode 100644
index 000..f25619b
--- /dev/null
+++ b/include/linux/input/samsung-keypad.h
@@ -0,0 +1,43 @@
+/*
+ * Samsung Keypad platform data definitions
+ *
+ * Copyright (C) 2010 Samsung Electronics Co.Ltd
+ * Author: Joonyoung Shim
+ *
+ * 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.
+ */
+
+#ifndef __SAMSUNG_KEYPAD_H
+#define __SAMSUNG_KEYPAD_H
+
+#include
+
+#define SAMSUNG_MAX_ROWS 8
+#define SAMSUNG_MAX_COLS 8
+
+/**
+ * struct samsung_keypad_platdata - Platform device data for Samsung Keypad.
+ * @keymap_data: pointer to &matrix_keymap_data.
+ * @rows: number of keypad row supported.
+ * @cols: number of keypad col supported.
+ * @no_autorepeat: disable key autorepeat.
+ * @wakeup: controls whether the device should be set up as wakeup source.
+ * @cfg_gpio: configure the GPIO.
+ *
+ * Initialisation data specific to either the machine or the platform
+ * for the device driver to use or call-back when configuring gpio.
+ */
+struct samsung_keypad_platdata {
+ const struc
Re: [PATCH 2/2] input: samsung-keypad: Add device tree support
Hi Thomas,
On Tue, Sep 06, 2011 at 07:25:17PM +0530, Thomas Abraham wrote:
> static int samsung_keypad_is_s5pv210(struct device *dev)
> {
> struct platform_device *pdev = to_platform_device(dev);
> - enum samsung_keypad_type type =
> - platform_get_device_id(pdev)->driver_data;
> + enum samsung_keypad_type type;
>
> +#ifdef CONFIG_OF
> + if (dev->of_node)
> + return of_device_is_compatible(dev->of_node,
> + "samsung,s5pv210-keypad");
> +#endif
> + type = platform_get_device_id(pdev)->driver_data;
> return type == KEYPAD_TYPE_S5PV210;
This function is called every time we scan keypad matrix, I do not think
you want to scan DT bindings here. You need to cache the device type at
probe time and use it.
> }
>
> @@ -235,6 +246,130 @@ static void samsung_keypad_close(struct input_dev
> *input_dev)
> samsung_keypad_stop(keypad);
> }
>
> +#ifdef CONFIG_OF
> +static
> +struct samsung_keypad_platdata *samsung_keypad_parse_dt(struct device *dev)
> +{
> + struct samsung_keypad_platdata *pdata;
> + struct matrix_keymap_data *keymap_data;
> + uint32_t *keymap;
> + struct device_node *np = dev->of_node, *key_np;
> + unsigned int key_count = 0;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata) {
> + dev_err(dev, "could not allocate memory for platform data\n");
> + return NULL;
> + }
pdata is not used once probe() completes so it would be better to free
it and not rely on devm_* facilities to free it for you once device
unbinds from the driver.
> +
> + of_property_read_u32(np, "samsung,keypad-num-rows", &pdata->rows);
> + of_property_read_u32(np, "samsung,keypad-num-columns", &pdata->cols);
> + if (!pdata->rows || !pdata->cols) {
> + dev_err(dev, "number of keypad rows/columns not specified\n");
> + return NULL;
> + }
> +
> + keymap_data = devm_kzalloc(dev, sizeof(*keymap_data), GFP_KERNEL);
> + if (!keymap_data) {
> + dev_err(dev, "could not allocate memory for keymap data\n");
> + return NULL;
> + }
> + pdata->keymap_data = keymap_data;
> +
> + for_each_child_of_node(np, key_np)
> + key_count++;
> +
> + keymap_data->keymap_size = key_count;
> + keymap = devm_kzalloc(dev, sizeof(uint32_t) * key_count, GFP_KERNEL);
> + if (!keymap) {
> + dev_err(dev, "could not allocate memory for keymap\n");
> + return NULL;
> + }
> + keymap_data->keymap = keymap;
> +
> + for_each_child_of_node(np, key_np) {
> + unsigned int row, col, key_code;
> + of_property_read_u32(key_np, "keypad,row", &row);
> + of_property_read_u32(key_np, "keypad,column", &col);
> + of_property_read_u32(key_np, "keypad,key-code", &key_code);
> + *keymap++ = KEY(row, col, key_code);
> + }
THis seems like generic mechanism that could be used by other drivers...
Maybe move into matrix-keypad.c? You would also not need to allocate
temporary buffer for intermediate keymap data.
> +
> + if (of_get_property(np, "linux,input-no-autorepeat", NULL))
> + pdata->no_autorepeat = true;
> + if (of_get_property(np, "linux,input-wakeup", NULL))
> + pdata->wakeup = true;
> +
> + return pdata;
> +}
> +
> +static void samsung_keypad_parse_dt_gpio(struct device *dev,
> + struct samsung_keypad *keypad)
> +{
> + struct device_node *np = dev->of_node;
> + int gpio, ret, row, col;
> +
> + for (row = 0; row < keypad->rows; row++) {
> + gpio = of_get_named_gpio(np, "row-gpios", row);
> + keypad->row_gpios[row] = gpio;
> + if (!gpio_is_valid(gpio)) {
> + dev_err(dev, "keypad row[%d]: invalid gpio %d\n",
> + row, gpio);
> + continue;
> + }
> +
> + ret = gpio_request(gpio, "keypad-row");
> + if (ret)
> + dev_err(dev, "keypad row[%d] gpio request failed\n",
> + row);
> + }
> +
> + for (col = 0; col < keypad->cols; col++) {
> + gpio = of_get_named_gpio(np, "col-gpios", col);
> + keypad->col_gpios[col] = gpio;
> + if (!gpio_is_valid(gpio)) {
> + dev_err(dev, "keypad column[%d]: invalid gpio %d\n",
> + col, gpio);
> + continue;
> + }
> +
> + ret = gpio_request(col, "keypad-col");
> + if (ret)
> + dev_err(dev, "keypad column[%d] gpio request failed\n",
> + col);
I think we should bail out if one of the calls fails.
> + }
> +}
> +
> +static void samsung_keypad_dt_gpio_free(struct samsung_keypad *keypad)
> +{
> + int c
Re: [PATCH 1/2] input: samsung-keypad: Add HAVE_SAMSUNG_KEYPAD config option
Hi Thomas, On Tue, Sep 06, 2011 at 07:25:16PM +0530, Thomas Abraham wrote: > Samsung keyboard driver could be used with platforms using device tree. > So the inclusion of samsung keyboard driver cannot be based on > SAMSUNG_DEV_KEYPAD. A new config option HAVE_SAMSUNG_KEYPAD is added > which device tree based platforms should use to include samsung keyboard > driver. I am sorry, I do not follow... What is the difference between SAMSUNG_DEV_KEYPAD and HAVE_SAMSUNG_KEYPAD? They look exactly the same. Thanks, > > Signed-off-by: Thomas Abraham > --- > drivers/input/keyboard/Kconfig |9 - > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig > index b4dee9d..370fb18 100644 > --- a/drivers/input/keyboard/Kconfig > +++ b/drivers/input/keyboard/Kconfig > @@ -423,9 +423,16 @@ config KEYBOARD_PMIC8XXX > To compile this driver as a module, choose M here: the module will > be called pmic8xxx-keypad. > > +config HAVE_SAMSUNG_KEYPAD > + bool > + help > + This will include Samsung Keypad controller driver support. If you > + want to include Samsung Keypad support for any machine, kindly > + select this in the respective mach-/Kconfig file. > + > config KEYBOARD_SAMSUNG > tristate "Samsung keypad support" > - depends on SAMSUNG_DEV_KEYPAD > + depends on SAMSUNG_DEV_KEYPAD || HAVE_SAMSUNG_KEYPAD > help > Say Y here if you want to use the Samsung keypad. > > -- > 1.6.6.rc2 > -- Dmitry -- 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 0/3] ARM: SAMSUNG: register the second instance of PL330 DMAC
alim akhtar wrote: > > From: Alim Akhtar > > Two instance of platform data is provided for PL330 but only one PL330 DMAC > instance is registered with amba_device. > These patch sets registers the second instance with amba_device. > > These patches are based on kgene's tree next/topic-dma-pl330 branch. > http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;;a=summary > > Alim Akhtar (3): > ARM: EXYNOS4: register the second instance of pl330 DMAC > ARM: S5PV210: register the second instance of pl330 DMAC > ARM: S5PC100: register the second instance of pl330 DMAC > > arch/arm/mach-exynos4/dma.c |1 + > arch/arm/mach-s5pc100/dma.c |1 + > arch/arm/mach-s5pv210/dma.c |1 + > 3 files changed, 3 insertions(+), 0 deletions(-) > > -- > 1.7.2.3 Looks ok to me, will apply whole series. Thanks. Best regards, Kgene. -- Kukjin Kim , 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: [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
Jassi Brar wrote: > > On 6 September 2011 17:57, Russell King - ARM Linux > wrote: > > On Tue, Sep 06, 2011 at 05:52:19PM +0530, Jassi Brar wrote: > >> On Fri, Sep 2, 2011 at 6:14 AM, Boojin Kim wrote: > >> > Origianl code carries out the start operation after flush operation. > >> > But start operation is not required for DMA_TERMINATE_ALL command. > >> > So, This patch removes the unnecessary start operation and only carries > >> > out > >> > the flush oeration for handling DMA_TERMINATE_ALL command. > >> > >> Not exactly. The 'start' is impotent when called from this path because > >> there > >> is nothing left queued after the call to 'flush'. > >> pl330_tasklet() is called because that is a common function that does the > >> house-keeping acc to what's presently in 'work' and 'done' lists. > >> > >> Though as a side-effect, your patch does avoid doing callbacks on submitted > >> xfers during DMA_TERMINATE_ALL - which may or may not be the right thing > >> to do. > > > > It is defined that DMA_TERMINATE_ALL does not call the callbacks: > > > > 1. int dmaengine_terminate_all(struct dma_chan *chan) > > > > This causes all activity for the DMA channel to be stopped, and may > > discard data in the DMA FIFO which hasn't been fully transferred. > > No callback functions will be called for any incomplete transfers. > > > Ok, thanks for the info. > > Boojin Kim, please re-write the changelog to state only preventing > callbacks during DMA_TERMINATE_ALL as the reason. As above, we don't need callback as well start operation in DMA_TERMIANTE_ALL command and her patch just removed them for DMA_TERMINATE_ALL here. So current git message seems to have proper behavior of patch. Thanks. Best regards, Kgene. -- Kukjin Kim , 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: [PATCH V3 1/7] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata
Ajay Kumar wrote:
>
> This patch:
> Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
> Also, register "s5p64x0-fb" type driver_data.
> Existing s3c_fb_driverdata definitions in s3c-fb.c
> supports 5 or 2 windows.
>
Hi Ajay,
(Cc'ed Florian Tobias Schandina)
> Signed-off-by: Ajay Kumar
> acked-by: Jingoo Han
Should be "Acked-by"...
Acked-by: Kukjin Kim
Florian,
This is required for supporting FB on Samsung S5P64X0 SoC.
If you're ok, please apply this into your tree...
And if you need original patch, let us know. Ajay will send again.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> ---
> drivers/video/s3c-fb.c | 27 +++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 4aecf21..0fda252 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443
=
> {
> },
> };
>
> +static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
> + .variant = {
> + .nr_windows = 3,
> + .vidtcon= VIDTCON0,
> + .wincon = WINCON(0),
> + .winmap = WINxMAP(0),
> + .keycon = WKEYCON,
> + .osd= VIDOSD_BASE,
> + .osd_stride = 16,
> + .buf_start = VIDW_BUF_START(0),
> + .buf_size = VIDW_BUF_SIZE(0),
> + .buf_end= VIDW_BUF_END(0),
> +
> + .palette = {
> + [0] = 0x2400,
> + [1] = 0x2800,
> + [2] = 0x2c00,
> + },
> + },
> + .win[0] = &s3c_fb_data_s5p_wins[0],
> + .win[1] = &s3c_fb_data_s5p_wins[1],
> + .win[2] = &s3c_fb_data_s5p_wins[2],
> +};
> +
> static struct platform_device_id s3c_fb_driver_ids[] = {
> {
> .name = "s3c-fb",
> @@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[]
= {
> }, {
> .name = "s3c2443-fb",
> .driver_data= (unsigned long)&s3c_fb_data_s3c2443,
> + }, {
> + .name = "s5p64x0-fb",
> + .driver_data= (unsigned long)&s3c_fb_data_s5p64x0,
> },
> {},
> };
> --
> 1.7.0.4
--
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 V3 5/7] ARM: S5P64X0: Add file to hold common Framebuffer and LCD code
Ajay Kumar wrote:
>
> This patch creates a file which holds the framebuffer and
> LCD code which is common for SMDK6440 and SMDK6450.
> It mainly includes:
> -- Basic FB window definition.
> -- platform data for FB and LCD.
> -- platform_device support for LCD.
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/mach-s5p64x0/Kconfig |5 +
> arch/arm/mach-s5p64x0/Makefile |3 +
> .../mach-s5p64x0/include/mach/smdk64x0-common-fb.h | 26 ++
> arch/arm/mach-s5p64x0/smdk64x0-common-fb.c | 92
>
> 4 files changed, 126 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/include/mach/smdk64x0-common-
> fb.h
> create mode 100644 arch/arm/mach-s5p64x0/smdk64x0-common-fb.c
>
> diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
> index 4fee745..00d5873 100644
> --- a/arch/arm/mach-s5p64x0/Kconfig
> +++ b/arch/arm/mach-s5p64x0/Kconfig
> @@ -32,6 +32,11 @@ config S5P64X0_SETUP_I2C1
> help
> Common setup code for i2c bus 1.
>
> +config SMDK64X0_COMMON_FB
> + bool
> + help
> + Common framebuffer and LCD code which can be shared across SMDKs.
> +
> # machine support
>
> config MACH_SMDK6440
> diff --git a/arch/arm/mach-s5p64x0/Makefile
b/arch/arm/mach-s5p64x0/Makefile
> index 487d179..d09d81b 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -22,6 +22,9 @@ obj-$(CONFIG_CPU_S5P6450) += clock-s5p6450.o
> obj-$(CONFIG_MACH_SMDK6440) += mach-smdk6440.o
> obj-$(CONFIG_MACH_SMDK6450) += mach-smdk6450.o
>
> +#common code
> +obj-$(CONFIG_SMDK64X0_COMMON_FB) += smdk64x0-common-fb.o
> +
> # device support
>
> obj-y+= dev-audio.o
> diff --git a/arch/arm/mach-s5p64x0/include/mach/smdk64x0-common-fb.h
> b/arch/arm/mach-s5p64x0/include/mach/smdk64x0-common-fb.h
> new file mode 100644
> index 000..e3b87b9
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/include/mach/smdk64x0-common-fb.h
> @@ -0,0 +1,26 @@
> +/* linux/arch/arm/mach-s5p64x0/include/mach/smdk64x0-common-fb.h
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * Includes declarations for variables and functions
> + * needed in order to support framebuffer.
> + *
> + * 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
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +extern structs3c_fb_pd_win smdk64x0_fb_win0;
> +extern structs3c_fb_platdata smdk64x0_lcd_pdata;
> +extern structplat_lcd_data smdk64x0_lcd_power_data;
> +extern structplatform_device smdk64x0_lcd_lte480wv;
> +extern void smdk64x0_lte480_reset_power(struct plat_lcd_data *pd,
> + unsigned int power);
> diff --git a/arch/arm/mach-s5p64x0/smdk64x0-common-fb.c b/arch/arm/mach-
> s5p64x0/smdk64x0-common-fb.c
> new file mode 100644
> index 000..a3203f8
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/smdk64x0-common-fb.c
> @@ -0,0 +1,92 @@
> +/* linux/arch/arm/mach-s5p64x0/smdk64x0-common-fb.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * Includes definitions for variables and functions
> + * needed in order to support framebuffer.
> + * Note that this code is common across SMDK6440 and SMDK6450.
> + *
> + * 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
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +/* Frame Buffer */
> +struct s3c_fb_pd_win smdk64x0_fb_win0 = {
> + .win_mode = {
> + .left_margin= 8,
> + .right_margin = 13,
> + .upper_margin = 7,
> + .lower_margin = 5,
> + .hsync_len = 3,
> + .vsync_len = 1,
> + .xres = 800,
> + .yres = 480,
> + .refresh= 60,
> + },
> + .max_bpp= 32,
> + .default_bpp= 24,
> +};
> +
> +struct s3c_fb_platdata smdk64x0_lcd_pdata __initdata = {
> + .win[0] = &smdk64x0_fb_win0,
> + .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
> + .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
> + .setup_gpio = s5p64x0_fb_gpio_setup_24bpp,
> +};
> +
> +/* LCD power controller */
> +void smdk64x0_lte480_reset_power(struct plat_lcd_data *pd,
> + unsigned int power)
> +{
> + unsigned int cfg;
> + int err;
> +
> + if (power) {
> + cfg = readl(S5P64X0_SYS_ID) & 0xf;
> +
RE: [PATCH V3 4/7] ARM: S5P64X0: Add GPIO and SPCON settings for LCD
Ajay Kumar wrote:
>
> This patch adds:
> -- GPIO lines settings(HSYNC, VSYNC, VCLK and VD) for LCD.
> -- Function to select LCD interface (RGB/i80)
>
> Signed-off-by: Ajay Kumar
> ---
> arch/arm/mach-s5p64x0/Kconfig |6 +++
> arch/arm/mach-s5p64x0/Makefile |1 +
> arch/arm/mach-s5p64x0/include/mach/regs-gpio.h |4 ++
> arch/arm/mach-s5p64x0/setup-fb.c | 48
>
> arch/arm/plat-samsung/include/plat/fb.h| 14 +++
> 5 files changed, 73 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-s5p64x0/setup-fb.c
>
> diff --git a/arch/arm/mach-s5p64x0/Kconfig b/arch/arm/mach-s5p64x0/Kconfig
> index 65c7518..4fee745 100644
> --- a/arch/arm/mach-s5p64x0/Kconfig
> +++ b/arch/arm/mach-s5p64x0/Kconfig
> @@ -21,6 +21,12 @@ config CPU_S5P6450
> help
> Enable S5P6450 CPU support
>
> +config S5P64X0_SETUP_FB
How about to use S5P64X0_SETUP_FB_24BPP like others?
> + bool
> + help
> + Common setup code for S5P64X0 based boards with a LCD display
> + through RGB interface.
> +
> config S5P64X0_SETUP_I2C1
> bool
> help
> diff --git a/arch/arm/mach-s5p64x0/Makefile
b/arch/arm/mach-s5p64x0/Makefile
> index 5f6afdf..487d179 100644
> --- a/arch/arm/mach-s5p64x0/Makefile
> +++ b/arch/arm/mach-s5p64x0/Makefile
> @@ -28,3 +28,4 @@ obj-y += dev-audio.o
> obj-$(CONFIG_S3C64XX_DEV_SPI)+= dev-spi.o
>
> obj-$(CONFIG_S5P64X0_SETUP_I2C1) += setup-i2c1.o
> +obj-$(CONFIG_S5P64X0_SETUP_FB) += setup-fb.o
> diff --git a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
b/arch/arm/mach-
> s5p64x0/include/mach/regs-gpio.h
> index 6ce2547..34d4412 100644
> --- a/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
> +++ b/arch/arm/mach-s5p64x0/include/mach/regs-gpio.h
> @@ -44,4 +44,8 @@
> #define S5P64X0_EINT0MASK(S5P_VA_GPIO +
> EINT0MASK_OFFSET)
> #define S5P64X0_EINT0PEND(S5P_VA_GPIO +
> EINT0PEND_OFFSET)
>
> +#define S5P64X0_SPCON0 (S5P_VA_GPIO + 0x1A0)
> +#define S5P64X0_SPCON0_LCD_SEL_MASK (0x3 << 0)
> +#define S5P64X0_SPCON0_LCD_SEL_RGB (0x1 << 0)
I can't find where 'xxx_LCD_SEL_RGB' is used...of course, it can be used
later.
But please don't add definition which is not used now.
> +
> #endif /* __ASM_ARCH_REGS_GPIO_H */
> diff --git a/arch/arm/mach-s5p64x0/setup-fb.c
b/arch/arm/mach-s5p64x0/setup-fb.c
> new file mode 100644
> index 000..0d9903a
> --- /dev/null
> +++ b/arch/arm/mach-s5p64x0/setup-fb.c
arch/arm/mach-s5p64x0/setup-fb-24bpp.c?
And if required, we can change it later with others next time...
> @@ -0,0 +1,48 @@
> +/* linux/arch/arm/mach-s5p64x0/setup-fb.c
> + *
> + * Copyright (c) 2011 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com/
> + *
> + * Base S5P64X0 GPIO setup information for LCD framebuffer
> + *
> + * GPIO settings for LCD on any other board based on s5p64x0
> + * should go in this file.
> + *
> + * 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
> + * published by the Free Software Foundation.
> +*/
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include
> +#include
> +
> +void s5p64x0_fb_init(int lcd_interface_type)
> +{
> + unsigned int cfg;
> +
> + /* select TFT LCD type (RGB I/F) */
> + cfg = __raw_readl(S5P64X0_SPCON0);
> + cfg &= ~S5P64X0_SPCON0_LCD_SEL_MASK;
> + cfg |= lcd_interface_type;
> + __raw_writel(cfg, S5P64X0_SPCON0);
Hmm...how about to move above into its board file? So we don't need to get
the argument, lcd_interface_type...
> +}
> +
> +void s5p64x0_fb_gpio_setup_24bpp(void)
> +{
> + unsigned int chipid;
> +
> + chipid = __raw_readl(S5P64X0_SYS_ID) & 0xf;
You can use soc_is_xxx() here instead of checking of CPUID directly.
> + if (chipid == 0x4) {
> + s3c_gpio_cfgrange_nopull(S5P6440_GPI(0), 16,
> S3C_GPIO_SFN(2));
> + s3c_gpio_cfgrange_nopull(S5P6440_GPJ(0), 12,
> S3C_GPIO_SFN(2));
> + } else if (chipid == 0x5) {
> + s3c_gpio_cfgrange_nopull(S5P6450_GPI(0), 16,
> S3C_GPIO_SFN(2));
> + s3c_gpio_cfgrange_nopull(S5P6450_GPJ(0), 12,
> S3C_GPIO_SFN(2));
> + }
> +}
> diff --git a/arch/arm/plat-samsung/include/plat/fb.h b/arch/arm/plat-
> samsung/include/plat/fb.h
> index 01f10e4..bd79c0a 100644
> --- a/arch/arm/plat-samsung/include/plat/fb.h
> +++ b/arch/arm/plat-samsung/include/plat/fb.h
> @@ -109,4 +109,18 @@ extern void s5pv210_fb_gpio_setup_24bpp(void);
> */
> extern void exynos4_fimd0_gpio_setup_24bpp(void);
>
> +/**
> + * s5p64x0_fb_init() - Common setup function for LCD
> + *
> + * Select LCD I/F configuration-RGB style or i80 style
> + */
> +extern void s5p64x0_fb_init(int lcd_interface_type);
> +
> +/**
> + * s5p64x0_fb_gpio_setup_24bpp() - Common GPIO setup function for L
RE: [PATCH] ARM: EXYNOS4: ADD USB EHCI device to SMDKV310
Kukjin Kim wrote:
>
> Sachin Kamat wrote:
> >
> > Signed-off-by: Bhuvana Kakunoori
> > Signed-off-by: Pankaj Dubey
> > Signed-off-by: Sachin Kamat
> > ---
> > arch/arm/mach-exynos4/Kconfig |2 ++
> > arch/arm/mach-exynos4/mach-smdkv310.c | 16
> > 2 files changed, 18 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/mach-exynos4/Kconfig
b/arch/arm/mach-exynos4/Kconfig
> > index bb29d51..cc97d23 100644
> > --- a/arch/arm/mach-exynos4/Kconfig
> > +++ b/arch/arm/mach-exynos4/Kconfig
> > @@ -136,6 +136,7 @@ config MACH_SMDKV310
> > bool "SMDKV310"
> > select CPU_EXYNOS4210
> > select S5P_DEV_FIMD0
> > + select S5P_DEV_USB_EHCI
> > select S3C_DEV_RTC
> > select S3C_DEV_WDT
> > select S3C_DEV_I2C1
> > @@ -151,6 +152,7 @@ config MACH_SMDKV310
> > select SAMSUNG_DEV_PWM
> > select EXYNOS4_DEV_SYSMMU
> > select EXYNOS4_SETUP_FIMD0
> > + select EXYNOS4_SETUP_USB_PHY
> > select EXYNOS4_SETUP_I2C1
> > select EXYNOS4_SETUP_KEYPAD
> > select EXYNOS4_SETUP_SDHCI
> > diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-
> > exynos4/mach-smdkv310.c
> > index 5f62b2b..b6c28ea 100644
> > --- a/arch/arm/mach-exynos4/mach-smdkv310.c
> > +++ b/arch/arm/mach-exynos4/mach-smdkv310.c
> > @@ -33,6 +33,8 @@
> > #include
> > #include
> > #include
> > +#include
> > +#include
> >
> > #include
> >
> > @@ -167,6 +169,16 @@ static struct i2c_board_info i2c_devs1[] __initdata
= {
> > {I2C_BOARD_INFO("wm8994", 0x1a),},
> > };
> >
> > +/* USB EHCI */
> > +static struct s5p_ehci_platdata smdkv310_ehci_pdata;
> > +
> > +static void __init smdkv310_ehci_init(void)
> > +{
> > + struct s5p_ehci_platdata *pdata = &smdkv310_ehci_pdata;
> > +
> > + s5p_ehci_set_platdata(pdata);
> > +}
> > +
> > static struct platform_device *smdkv310_devices[] __initdata = {
> > &s3c_device_hsmmc0,
> > &s3c_device_hsmmc1,
> > @@ -175,6 +187,7 @@ static struct platform_device *smdkv310_devices[]
> > __initdata = {
> > &s3c_device_i2c1,
> > &s3c_device_rtc,
> > &s3c_device_wdt,
> > + &s5p_device_ehci,
> > &exynos4_device_ac97,
> > &exynos4_device_i2s0,
> > &samsung_device_keypad,
> > @@ -258,6 +271,9 @@ static void __init smdkv310_machine_init(void)
> >
> > samsung_bl_set(&smdkv310_bl_gpio_info, &smdkv310_bl_data);
> >
> > + smdkv310_ehci_init();
> > + clk_xusbxti.rate = 2400;
> > +
> > platform_add_devices(smdkv310_devices,
> > ARRAY_SIZE(smdkv310_devices));
> > s5p_device_mfc.dev.parent = &exynos4_device_pd[PD_MFC].dev;
> > }
> > --
> > 1.7.4.1
>
> (Cc'ed Jingoo Han)
>
> Well, this is same with Jingoo's patch on smdkc210 which has been
submitted at
> 12th Aug.
>
> I requested to him to re-work this on smdkv310 on his patch just now...
> Hmm...I don't know :(
>
> Let me think again...
>
As I've heard, Jingoo talked you about this patch and you agreed to use
Jingoo's patch on SMDKV310. So I dropped this and will pick up his patch.
If any problems, please let me know.
Thanks.
Best regards,
Kgene.
--
Kukjin Kim , 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: [PATCH v8 04/16] DMA: PL330: Remove the start operation for handling DMA_TERMINATE_ALL command
On 7 September 2011 12:53, Kukjin Kim wrote:
> Jassi Brar wrote:
>>
>> On 6 September 2011 17:57, Russell King - ARM Linux
>> wrote:
>> > On Tue, Sep 06, 2011 at 05:52:19PM +0530, Jassi Brar wrote:
>> >> On Fri, Sep 2, 2011 at 6:14 AM, Boojin Kim wrote:
>> >> > Origianl code carries out the start operation after flush operation.
>> >> > But start operation is not required for DMA_TERMINATE_ALL command.
>> >> > So, This patch removes the unnecessary start operation and only carries
>> >> > out
>> >> > the flush oeration for handling DMA_TERMINATE_ALL command.
>> >>
>> >> Not exactly. The 'start' is impotent when called from this path because
>> >> there
>> >> is nothing left queued after the call to 'flush'.
>> >> pl330_tasklet() is called because that is a common function that does the
>> >> house-keeping acc to what's presently in 'work' and 'done' lists.
>> >>
>> >> Though as a side-effect, your patch does avoid doing callbacks on
>> >> submitted
>> >> xfers during DMA_TERMINATE_ALL - which may or may not be the right thing
>> >> to do.
>> >
>> > It is defined that DMA_TERMINATE_ALL does not call the callbacks:
>> >
>> > 1. int dmaengine_terminate_all(struct dma_chan *chan)
>> >
>> > This causes all activity for the DMA channel to be stopped, and may
>> > discard data in the DMA FIFO which hasn't been fully transferred.
>> > No callback functions will be called for any incomplete transfers.
>> >
>> Ok, thanks for the info.
>>
>> Boojin Kim, please re-write the changelog to state only preventing
>> callbacks during DMA_TERMINATE_ALL as the reason.
>
> As above, we don't need callback as well start operation in DMA_TERMIANTE_ALL
> command and her patch just removed them for DMA_TERMINATE_ALL here. So
> current git message seems to have proper behavior of patch.
>
Nopes.
No modification to current code is needed if only the following is to
be the reason.
{
Origianl code carries out the start operation after flush operation.
But start operation is not required for DMA_TERMINATE_ALL command.
So, This patch removes the unnecessary start operation and only carries out
the flush oeration for handling DMA_TERMINATE_ALL command.
}
The patch, however, has unintended good effect of "preventing callbacks
from DMA_TERMINATE_ALL".
The only valid reason, and which is no way implied by the changelog.
--
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] ARM: EXYNOS4: Add HDMI support for Origen
This patch adds HDMI (TVout) support for Origen board.
This patch is based on for-next branch of Kukjin Kim's tree:
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=summary
This patch is tested using Hatim's patch:
http://www.spinics.net/lists/linux-samsung-soc/msg06367.html
Signed-off-by: Sachin Kamat
---
arch/arm/mach-exynos4/Kconfig |2 ++
arch/arm/mach-exynos4/mach-origen.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 181fb04..4f908f7 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -225,6 +225,8 @@ config MACH_ORIGEN
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
select EXYNOS4_SETUP_SDHCI
+ select S5P_DEV_I2C_HDMIPHY
+ select S5P_DEV_TV
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..6ec68ee 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -81,8 +81,11 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
static struct platform_device *origen_devices[] __initdata = {
&s3c_device_hsmmc2,
+ &s5p_device_i2c_hdmiphy,
&s3c_device_rtc,
&s3c_device_wdt,
+ &s5p_device_hdmi,
+ &s5p_device_mixer,
};
static void __init origen_map_io(void)
@@ -95,6 +98,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
+ s5p_i2c_hdmiphy_set_platdata(NULL);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
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: [PATCH 0/2] video: s3c-fb: Add window positioning support
Hi Florian, On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote: > Hi all, > > On 08/25/2011 07:51 PM, Ajay Kumar wrote: > > Just as a note, there are many drivers like mx3fb.c, au1200fb.c and OMAP > > seem to be doing window/plane positioning in their driver code. > > Is it possible to have this window positioning support at a common place? > > Good point. Congratulations for figuring out that I like to standardize > things. But I think your suggestion is far from being enough to be useful > for userspace (which is our goal so that applications can be reused along > drivers and don't need to know about individual drivers). Beside standardizing things, do you also like to take them one level higher to solve challenging issues ? I know the answer must be yes :-) The problem at hand here is something we have solved in V4L2 (theoretically only for part of it) with the media controller API, the V4L2 subdevs and their pad-level format API. In a nutshell, the media controller lets drivers model hardware as a graph of buliding blocks connected through their pads and expose that description to userspace applications. In V4L2 most of those blocks are V4L2 subdevs, which are abstract building blocks that implement sets of standard operations. Those operations are exposed to userspace through the V4L2 subdevs pad-level format API, allowing application to configure sizes and selection rectangles at all pads in the graph. Selection rectangles can be used to configure cropping and composing, which is exactly what the window positioning API needs to do. Instead of creating a new fbdev-specific API to do the same, shouldn't we try to join forces ? > So let me at first summarize how I understand you implemented those things > after having a brief look at some of the drivers: > Windows are rectangular screen areas whose pixel data come from other > locations. The other locations are accessible via other framebuffer > devices (e.g. fb1). So in this area the data of fb1 is shown and not the > data of fb0 that would be normally shown. > > So in addition to your proposed positioning I think we should also have the > following to give userspace a useful set of functionality: > > - a way to discover how the screen is composited (how many windows are > there, how they are stacked and how to access those) > > - a way to enable/disable windows (make them (in)visible) > > - reporting and selecting how the window content can be mixed with the root > screen (overwrite, source or destination color keying) > > - things like window size and color format could be handled by the usual fb > API used on the window. However there might be restrictions which cause > them to be not 100% API compatible (for example when changing the color > format if the windows are required to have the same format as the root > screen) > > - do we need to worry about hardware (up/down) scaling of the window > content? > > > So is that what you need for a standardized window implementation? > Any additional things that were useful/needed in this context? > Would you consider adding support for this API in your drivers? (as > standardizing wouldn't be useful if nobody would implement it) -- Regards, Laurent Pinchart -- 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/5] ARM: SAMSUNG: Make the sleep code common for S3C64XX and newer SoCs
On Fri, Aug 12, 2011 at 03:56:24PM +0530, Abhilash Kesavan wrote: > +ENTRY(s3c_cpu_resume) > +#if defined(CONFIG_S3C_PM_DEBUG_LED_SMDK) > + > +#undef S3C64XX_VA_GPIO > +#define S3C64XX_VA_GPIO (0x0) > +#define S3C64XX_GPNCON (S3C64XX_GPN_BASE + 0x00) > +#define S3C64XX_GPNDAT (S3C64XX_GPN_BASE + 0x04) > + > +#define S3C64XX_GPN_CONMASK(__gpio) (0x3 << ((__gpio) * 2)) > +#define S3C64XX_GPN_OUTPUT(__gpio) (0x1 << ((__gpio) * 2)) > + > + /* Initialise the GPIO state if we are debugging via the SMDK LEDs, > + * as the uboot version supplied resets these to inputs during the > + * resume checks. > + */ > + > + ldr r3, =S3C64XX_PA_GPIO > + ldr r0, [ r3, #S3C64XX_GPNCON ] > + bic r0, r0, #(S3C64XX_GPN_CONMASK(12) | S3C64XX_GPN_CONMASK(13) | \ > + S3C64XX_GPN_CONMASK(14) | S3C64XX_GPN_CONMASK(15)) > + orr r0, r0, #(S3C64XX_GPN_OUTPUT(12) | S3C64XX_GPN_OUTPUT(13) | \ > + S3C64XX_GPN_OUTPUT(14) | S3C64XX_GPN_OUTPUT(15)) > + str r0, [ r3, #S3C64XX_GPNCON ] > + > + ldr r0, [ r3, #S3C64XX_GPNDAT ] > + bic r0, r0, #0xf << 12 @ GPN12..15 > + orr r0, r0, #1 << 15@ GPN15 > + str r0, [ r3, #S3C64XX_GPNDAT ] > +#endif This is incompatible with the aim of a single kernel booting on many ARM platforms. Rather than consolidating down to just one implementation, how about consolidating to two - one for everything but SMDK, and one for the SMDK with the LED stuff. You can then chose which you want - either the s3c_generic_resume (which is just the magic code plus the branch) or s3c_smdk_leds_resume (which would be the magic code plus the LEDS stuff plus the branch.) -- 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
