[PATCH] ARM: Samsung: Make uart_save static in pm.c file
Fixes the following sparse warning:
arch/arm/plat-samsung/pm.c:77:21:
warning: symbol 'uart_save' was not declared. Should it be static?
Signed-off-by: Sachin Kamat
---
arch/arm/plat-samsung/pm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-samsung/pm.c b/arch/arm/plat-samsung/pm.c
index 64ab65f..1507028 100644
--- a/arch/arm/plat-samsung/pm.c
+++ b/arch/arm/plat-samsung/pm.c
@@ -74,7 +74,7 @@ unsigned char pm_uart_udivslot;
#ifdef CONFIG_SAMSUNG_PM_DEBUG
-struct pm_uart_save uart_save[CONFIG_SERIAL_SAMSUNG_UARTS];
+static struct pm_uart_save uart_save[CONFIG_SERIAL_SAMSUNG_UARTS];
static void s3c_pm_save_uart(unsigned int uart, struct pm_uart_save *save)
{
--
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/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
Hi Arnd,
On Wed, Aug 1, 2012 at 8:50 PM, Arnd Bergmann wrote:
> On Wednesday 01 August 2012, Praveen Paneri wrote:
>> This patch set introduces a phy driver for samsung SoCs. It uses the existing
>> transceiver infrastructure to provide phy control functions. Use of this
>> driver
>> can be extended for usb host phy as well. Over the period of time all the phy
>> related code for most of the samsung SoCs can be integrated here.
>> Removing the existing phy code from mach-s3c64xx but not from other machine
>> code.This driver is tested with smdk6410 and Exynos4210(with DT).
>
> This looks very nice overall, great work!
Thank you!
>
> We will still have to take care of the pmu isolation callback in the
> long run, when we get to the point of removing all auxdata. Do you
> have a plan on how to do that? If yes, it would be good to mention
> that in the changelog.
Yes! I understand this problem and this is the reason these patches
were sitting in my system for couple of weeks. In a discussion with
Thomas an idea of using the existing regulator framework to
enable/disable numerous PHYs came up. For example the PMU unit
of Exynos4210 has a register set dedicated just to control USBD_PHY,
HDMI_PHY, MIPI_PHY, DAC_PHY and more. If a regulator with
each phy control register as LDO is written, the phy driver becomes a
static consumer and will modify as below.
diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c
index 33119eb..4f69675 100644
--- a/drivers/usb/phy/sec_usbphy.c
+++ b/drivers/usb/phy/sec_usbphy.c
@@ -28,8 +28,8 @@
#include
#include
#include
+#include
#include
-#include
#include "sec_usbphy.h"
@@ -41,7 +41,7 @@ enum sec_cpu_type {
/*
* struct sec_usbphy - transceiver driver state
* @phy: transceiver structure
- * @plat: platform data
+ * @vusbphy: PMU regulator for usb phy
* @dev: The parent device supplied to the probe function
* @clk: usb phy clock
* @regs: usb phy register memory base
@@ -49,7 +49,7 @@ enum sec_cpu_type {
*/
struct sec_usbphy {
struct usb_phy phy;
- struct s3c_usbphy_plat *plat;
+ struct regulator *vusbphy;
struct device *dev;
struct clk *clk;
void __iomem*regs;
@@ -187,8 +187,11 @@ static int sec_usbphy_init(struct usb_phy *phy)
}
/* Disable phy isolation */
- if (sec->plat && sec->plat->pmu_isolation)
- sec->plat->pmu_isolation(false);
+ ret = regulator_enable(sec->vusbphy);
+ if (ret) {
+ dev_err(sec->dev, "Failed to enable regulator for USBPHY\n");
+ return ret;
+ }
/* Initialize usb phy registers */
sec_usbphy_enable(sec);
@@ -208,8 +211,8 @@ static void sec_usbphy_shutdown(struct usb_phy *phy)
sec_usbphy_disable(sec);
/* Enable phy isolation */
- if (sec->plat && sec->plat->pmu_isolation)
- sec->plat->pmu_isolation(true);
+ if (regulator_disable(sec->vusbphy))
+ dev_err(sec->dev, "Failed to disable regulator for USBPHY\n");
/* Disable the phy clock */
sec_usbphy_clk_control(sec, false);
@@ -263,7 +266,6 @@ static int __devinit sec_usbphy_probe(struct
platform_device *pdev)
return -ENOMEM;
sec->dev= &pdev->dev;
- sec->plat = pdata;
sec->regs = phy_base;
sec->phy.dev= sec->dev;
sec->phy.label = "sec-usbphy";
@@ -271,6 +273,14 @@ static int __devinit sec_usbphy_probe(struct
platform_device *pdev)
sec->phy.shutdown = sec_usbphy_shutdown;
sec->cpu_type = sec_usbphy_get_driver_data(pdev);
+ /* acquire regulator */
+ sec->vusbphy = regulator_get(sec->dev, "usbdphy");
+ if (IS_ERR_OR_NULL(sec->vusbphy)) {
+ dev_err(dev, "failed to get regulator 'usbdphy'\n");
+ ret = -ENXIO;
+ goto err;
+ }
+
ret = usb_add_phy(&sec->phy, USB_PHY_TYPE_USB2);
if (ret)
goto err;
@@ -292,6 +302,7 @@ static int __exit sec_usbphy_remove(struct
platform_device *pdev)
clk_put(sec->clk);
sec->clk = NULL;
}
+ regulator_put(sec->vusbphy);
return 0;
}
This kind of regulator, if generalised can be useful.
Please comment.
>
> My guess is that the PMU code should be moved into a higher-level
> abstraction. I don't know if you would use one of those we already
Could you please point out the location of the code.
> have or whether you'd introduce a new subsystem for those. Apparently.
Havent thought about it. Trying to work it out with the existing infra of the
kernel.
> other platforms have similar issues, so I'd suggest you leave the
> callback for now, but we should at some point discuss what to to
> about it.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord..
Re: [PATCH v3 2/2] ARM: EXYNOS: Add Gscaler device from DT
Hi Kgene, Cc: Rob Herring On 08/01/2012 11:00 AM, Kukjin Kim wrote: > +* Samsung Exynos5 Gscaler device > + > +Gscaler is used for scaling and color space conversion on EXYNOS5 >> SoCs. > + > +Required properties: > +- compatible: should be "samsung,exynos5250-gsc" IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can >> use same gscaler driver. >> >> In addition to the below explanation, perhaps it's obvious, but the driver >> can claim compatibility with multiple devices, i.e. match with multiple >> 'compatible' properties. >> > > The name of exact model is 'gscaler' for EXYNOS5 SoCs not only for > EXYNOS5250. So the driver which has been submitted is also 'exynos-gsc' not > 'exynos5250-gsc'. Note that there is no gscaler on EXYNOS4 SoCs now, it can > be either 'exynos5-gsc' or 'exynos-gsc'. In addition, since some > peripherals/drivers can be used for multiple SoCs and actually it does, I'm > still thinking the compatible should be represent its usage. I don't know > why restricted name is much clearer. And if multiple 'compatible' is > required, we can add it later. Sorry, but I cannot agree with that. :) There is no exynos5 SoC, it's just a common name for the whole series that includes: exynos5250, exynos5450 ones and more. We shouldn't use such common name for just a subset of exynos5 chips, in case different GScaler versions get deployed in future SoCs. It wouldn't be clear what specific SoCs the "samsung,exynos5-gsc" compatible string applies to, would it ? I believe there are already minor differences in GScaler parameters on currently available exynos5 SoC. The variant data structures are used to handle this and the compatible string determines which variant data structure is selected during driver's initialization. If you use a wildcard 'compatible' string this won't be possible any more. Also it would look odd IMO to have two compatible strings like: compatible = "samsung,exynos5-gsc", "samsung,exynos5400-gsc"; Please also see: http://devicetree.org/Device_Tree_Usage#Understanding_the_compatible_Property -- Regards, 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 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
On Wednesday 01 August 2012, Praveen Paneri wrote: > This patch set introduces a phy driver for samsung SoCs. It uses the existing > transceiver infrastructure to provide phy control functions. Use of this > driver > can be extended for usb host phy as well. Over the period of time all the phy > related code for most of the samsung SoCs can be integrated here. > Removing the existing phy code from mach-s3c64xx but not from other machine > code.This driver is tested with smdk6410 and Exynos4210(with DT). This looks very nice overall, great work! We will still have to take care of the pmu isolation callback in the long run, when we get to the point of removing all auxdata. Do you have a plan on how to do that? If yes, it would be good to mention that in the changelog. My guess is that the PMU code should be moved into a higher-level abstraction. I don't know if you would use one of those we already have or whether you'd introduce a new subsystem for those. Apparently other platforms have similar issues, so I'd suggest you leave the callback for now, but we should at some point discuss what to to about it. Arnd -- 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 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
On Thursday 26 July 2012, Vinayak Holikatti wrote: > > This patch set adds following features > - Seggregate PCI specific code in ufshcd.c > - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module > - Adds Platform glue driver ufshcd-pltfrm.c > - Update correct transfer size in Command UPIU I've found a few trivial issues that I just replied on. Other than that, please add my Reviewed-by: Arnd Bergmann -- 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/4] [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver
On Thursday 26 July 2012, Vinayak Holikatti wrote:
> diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c
> new file mode 100644
> index 000..d078744
> --- /dev/null
> +++ b/drivers/scsi/ufs/ufshcd-pci.c
> @@ -0,0 +1,228 @@
> +/*
> + * Universal Flash Storage Host controller driver
> + *
> + * This code is based on drivers/scsi/ufs/ufshcd-pci.c
> + * Copyright (C) 2011-2012 Samsung India Software Operations
> + *
> + * Santosh Yaraganavi
> + * Vinayak Holikatti
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * NO WARRANTY
> + * THE PROGRAM IS PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR
> + * CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT
> + * LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT,
> + * MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is
> + * solely responsible for determining the appropriateness of using and
> + * distributing the Program and assumes all risks associated with its
> + * exercise of rights under this Agreement, including but not limited to
> + * the risks and costs of program errors, damage to or loss of data,
> + * programs or equipment, and unavailability or interruption of operations.
> +
> + * DISCLAIMER OF LIABILITY
> + * NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY
> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND
> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
> + * TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> + * USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED
> + * HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES
It's a bit unusual to have three separate warranty disclaimers. Unless you've
specifically been asked to include all of them by your legal department to
do it like this, I would suggest you remove all but on of them.
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
> + * USA.
These statements also get outdated frequently when the FSF moves its
offices. We have the same thing in the global COPYING file of the kernel,
so most people don't carry their own copy.
> +static int __init ufshcd_module_init(void)
> {
> + pr_info("UFS Host Driver Core loaded\n");
> return 0;
> }
>
> +static void __exit ufshcd_module_exit(void)
> +{
> + pr_info("UFS Host Driver Core unloaded\n");
> +}
> +
> +module_init(ufshcd_module_init);
> +module_exit(ufshcd_module_exit);
The pr_info statements do not add any real value here. I would just drop
the module_init/module_exit functions entirely as they are not required.
Arnd
--
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/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
On Thursday 26 July 2012, Vinayak Holikatti wrote:
> -static void ufshcd_remove(struct pci_dev *pdev)
> +void ufshcd_remove(struct ufs_hba *hba)
> {
> - struct ufs_hba *hba = pci_get_drvdata(pdev);
> -
> /* disable interrupts */
> ufshcd_int_config(hba, UFSHCD_INT_DISABLE);
> - free_irq(pdev->irq, hba);
>
> ufshcd_hba_stop(hba);
> ufshcd_hba_free(hba);
>
> scsi_remove_host(hba->host);
> scsi_host_put(hba->host);
> +}
> +EXPORT_SYMBOL(ufshcd_remove);
For driver internal symbols, you should always use "EXPORT_SYMBOL_GPL"
here.
Arnd
--
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] ASoC: Samsung: Update Kconfig for Exynos5250 and Exynos4412
Hi, On Wed, Aug 1, 2012 at 8:36 AM, Kukjin Kim wrote: > Padmavathi Venna wrote: >> >> Update Kconfig file to support the Exynos5250 and Exynos4412 >> >> Signed-off-by: Sangsu Park >> Signed-off-by: Sangbeom Kim >> Signed-off-by: Padmavathi Venna >> --- >> sound/soc/samsung/Kconfig |8 >> 1 files changed, 4 insertions(+), 4 deletions(-) >> >> diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig >> index fe3995c..d54e400 100644 >> --- a/sound/soc/samsung/Kconfig >> +++ b/sound/soc/samsung/Kconfig >> @@ -1,6 +1,6 @@ >> config SND_SOC_SAMSUNG >> tristate "ASoC support for Samsung" >> - depends on ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PC100 || >> ARCH_S5PV210 || ARCH_S5P64X0 || ARCH_EXYNOS4 >> + depends on PLAT_SAMSUNG >> select S3C64XX_DMA if ARCH_S3C64XX >> select S3C2410_DMA if ARCH_S3C24XX >> help >> @@ -63,7 +63,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8580 >> >> config SND_SOC_SAMSUNG_SMDK_WM8994 >> tristate "SoC I2S Audio support for WM8994 on SMDK" >> - depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 || >> MACH_SMDK4212) >> + depends on SND_SOC_SAMSUNG && (MACH_SMDKV310 || MACH_SMDKC210 || >> MACH_SMDK4212 || MACH_SMDK4412 || SOC_EXYNOS5250) > > Well, do you think _really_ all board which has a EXYNOS5250 SoC is needed > this config? > > I don't think so? Yes. It is not required on all boards which has EXYNOS5250 SoC. I will change this. > > [...] > > 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 -- 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: Re: [PATCH] ARM: EXYNOS: Add I2S SFR base addresses
On Wed, Aug 1, 2012 at 8:34 AM, Kukjin Kim wrote:
> PADMAVATHI VENNA wrote:
>
> Padma, don't post with html styled :(
Sorry for the inconvenience. I will take care.
>
> And you need to check the regarding addresses as per Sachin commented.
Okay.
>
> Thanks.
>
> Best regards,
> Kgene.
Thanks&Regards
Padma
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
> --- Original Message ---
> Sender : Sachin Kamat
> Date : Jul 26, 2012 13:41 (GMT+09:00)
> Title : Re: [PATCH] ARM: EXYNOS: Add I2S SFR base addresses
>
> On 25 July 2012 17:35, Padmavathi Venna wrote:
>> The base address of I2S 0 controller is similar in exynos4 and exynos5
>> platforms. So this patch defines a common macro for the I2S controller
>> 0 base address in both the platforms and use the same macro.
>>
>> This patch also defines the I2S controller 1,2 base addresses in exynos5
>> and correct the I2S controller 1 base address in exynos4
>>
>> Signed-off-by: Padmavathi Venna
>> ---
>> arch/arm/mach-exynos/dev-audio.c|2 +-
>> arch/arm/mach-exynos/include/mach/map.h |6 --
>> 2 files changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/dev-audio.c
> b/arch/arm/mach-exynos/dev-audio.c
>> index b33a5b6..5dbc9a2 100644
>> --- a/arch/arm/mach-exynos/dev-audio.c
>> +++ b/arch/arm/mach-exynos/dev-audio.c
>> @@ -62,7 +62,7 @@ static struct s3c_audio_pdata i2sv5_pdata = {
>> };
>>
>> static struct resource exynos4_i2s0_resource[] = {
>> - [0] = DEFINE_RES_MEM(EXYNOS4_PA_I2S0, SZ_256),
>> + [0] = DEFINE_RES_MEM(EXYNOS_PA_I2S0, SZ_256),
>> [1] = DEFINE_RES_DMA(DMACH_I2S0_TX),
>> [2] = DEFINE_RES_DMA(DMACH_I2S0_RX),
>> [3] = DEFINE_RES_DMA(DMACH_I2S0S_TX),
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h
> b/arch/arm/mach-exynos/include/mach/map.h
>> index c72b675..5cf7d91 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -39,9 +39,11 @@
>>
>> #define EXYNOS4_PA_G2D 0x1280
>>
>> -#define EXYNOS4_PA_I2S00x0383
>> -#define EXYNOS4_PA_I2S10xE310
>> +#define EXYNOS_PA_I2S0 0x0383
>> +#define EXYNOS4_PA_I2S10xE210
>> #define EXYNOS4_PA_I2S20xE2A0
>
> As per the TRM, these addresses (I2S1 and I2S2) are 0x1396 and
> 0x1397 respectively on Exynos4412 SoC.
> Please verify.
> I didn't verify Exynos4412 before. I will send a new patch for this.
>
>
>> +#define EXYNOS5_PA_I2S10x12D6
>> +#define EXYNOS5_PA_I2S20x12D7
>>
>> #define EXYNOS4_PA_PCM00x0384
>> #define EXYNOS4_PA_PCM10x1398
>> --
>> 1.7.4.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
--
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: EXYNOS: Add static mapping for EXYNOS Audio Subsystem
On Wed, Aug 1, 2012 at 8:56 AM, Kukjin Kim wrote:
> Padmavathi Venna wrote:
>>
>> The CMU of EXYNOS can't control Audio Subsystem's clocks because
>> AUDSS SFRs aren't located in CMU. But AUDSS is a kind of CMU for
>> Audio Subsystem and need to use clock framework. This mapping
>> address will be used for AUDSS clock control.
>>
>> Signed-off-by: sangsu4u.park
>
> Maybe Sangsu Park?
>
>> Signed-off-by: Padmavathi Venna
>> ---
>> arch/arm/mach-exynos/common.c|5 +
>> arch/arm/mach-exynos/include/mach/map.h |1 +
>> arch/arm/plat-samsung/include/plat/map-s5p.h |2 ++
>> 3 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
>> index 4eb39cd..4070c79 100644
>> --- a/arch/arm/mach-exynos/common.c
>> +++ b/arch/arm/mach-exynos/common.c
>> @@ -109,6 +109,11 @@ static struct map_desc exynos_iodesc[] __initdata = {
>> .pfn= __phys_to_pfn(EXYNOS_PA_CHIPID),
>> .length = SZ_4K,
>> .type = MT_DEVICE,
>> + }, {
>> + .virtual= (unsigned long)S5P_VA_AUDSS,
>> + .pfn= __phys_to_pfn(EXYNOS_PA_AUDSS),
>> + .length = SZ_4K,
>> + .type = MT_DEVICE,
>> },
>> };
>>
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
>> exynos/include/mach/map.h
>> index 5cf7d91..9c044a0 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -39,6 +39,7 @@
>>
>> #define EXYNOS4_PA_G2D 0x1280
>>
>> +#define EXYNOS_PA_AUDSS 0x0381
>> #define EXYNOS_PA_I2S0 0x0383
>> #define EXYNOS4_PA_I2S1 0xE210
>> #define EXYNOS4_PA_I2S2 0xE2A0
>> diff --git a/arch/arm/plat-samsung/include/plat/map-s5p.h b/arch/arm/plat-
>> samsung/include/plat/map-s5p.h
>> index c2d7bda..3558277 100644
>> --- a/arch/arm/plat-samsung/include/plat/map-s5p.h
>> +++ b/arch/arm/plat-samsung/include/plat/map-s5p.h
>> @@ -40,6 +40,8 @@
>> #define S5P_VA_GIC_CPU S3C_ADDR(0x0281)
>> #define S5P_VA_GIC_DIST S3C_ADDR(0x0282)
>>
>> +#define S5P_VA_AUDSS S3C_ADDR(0x0291)
>
> Is there any reason to use the offset, 0x0291?
>
> [...]
>
> And I think, this patch should be patch-set with your '[PATCH] ARM: EXYNOS:
> Add clocks for EXYNOS Audio Subsystem.'
Okay. In the next version I will send it along with clock support for audio.
>
> Thanks.
>
> Best regards,
> Kgene.
Thanks&Regards
Padma
> --
> 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
--
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: [alsa-devel] [PATCH 1/2] ASOC: SAMSUNG: Add DT support for i2s
Hi, On Wed, Aug 1, 2012 at 1:59 PM, Sangbeom Kim wrote: > Hi, > On Wednesday, July 25, 2012 9:09 PM, Padmavathi Venna wrote: > >> Add support for device based discovery. >> > Currently, I'm reviewing your patch set. > Your patch can support device tree for Samsung's i2s. > But I wonder that Your patch can support non-dt too, > So, Please test your patch on non-dt environment. > It looks unclear handling of clock source. > After code review, I will give you more detail comments, Okey. I will test these patches in non-dt environment. > > Thanks, > Sangbeom. > > -- > 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: [PATCH] ARM: EXYNOS: Add clocks for EXYNOS Audio Subsystem.
Hi,
On Wed, Aug 1, 2012 at 9:21 AM, Kukjin Kim wrote:
> Padmavathi Venna wrote:
>>
>> Audiocdclk frequency is 16.9344MHz in SMDK5250 and this clock is
>> board specific. So this patch adds a function to set the required
>> audio codec clk frequency from machine file.
>>
>> This patch also adds all the required clock instances for audio
>> subsystem and adds the clock alias names for i2sclk and busclk.
>>
>> Signed-off-by: Taylor Hutt
>> Signed-off-by: sangsu4u.park
>> Signed-off-by: Padmavathi Venna
>> ---
>> arch/arm/mach-exynos/clock-exynos5.c | 129
>>
>> arch/arm/mach-exynos/common.h |1 +
>> arch/arm/mach-exynos/include/mach/regs-audss.h | 12 ++
>> arch/arm/mach-exynos/mach-exynos5-dt.c |1 +
>> 4 files changed, 143 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-
>> exynos/clock-exynos5.c
>> index 774533c..681450a 100644
>> --- a/arch/arm/mach-exynos/clock-exynos5.c
>> +++ b/arch/arm/mach-exynos/clock-exynos5.c
>> @@ -20,10 +20,13 @@
>> #include
>> #include
>> #include
>> +#include
>
> Why do we need above on this patch?
It's by mistake. I will remove this line in the next patch set.
>
>> #include
>> +#include
>
> Same as above.
It's by mistake. I will remove this line in the next patch set.
>
>>
>> #include
>> #include
>> +#include
>
> See below my comment.
>
>> #include
>>
>> #include "common.h"
>> @@ -106,6 +109,16 @@ static struct clk exynos5_clk_sclk_usbphy = {
>> .rate = 4800,
>> };
>>
>> +struct clk exynos5_clk_audiocdclk0 = {
>> + .id = -1,
>> + .name = "audiocdclk",
>> +};
>> +
>> +void exynos5_set_audiocdclk_rate(unsigned long rate)
>> +{
>> + clk_default_setrate(&exynos5_clk_audiocdclk0, rate);
>> +}
>> +
>> static int exynos5_clksrc_mask_top_ctrl(struct clk *clk, int enable)
>> {
>> return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_TOP, clk, enable);
>> @@ -171,6 +184,16 @@ static int exynos5_clk_ip_gps_ctrl(struct clk *clk,
>> int enable)
>> return s5p_gatectrl(EXYNOS5_CLKGATE_IP_GPS, clk, enable);
>> }
>>
>> +static int exynos5_clksrc_mask_maudio_ctrl(struct clk *clk, int enable)
>> +{
>> + return s5p_gatectrl(EXYNOS5_CLKSRC_MASK_MAUDIO, clk, enable);
>> +}
>> +
>> +static int exynos5_clk_audss_ctrl(struct clk *clk, int enable)
>> +{
>> + return s5p_gatectrl(EXYNOS_CLKGATE_AUDSS, clk, enable);
>> +}
>> +
>> static int exynos5_clk_ip_mfc_ctrl(struct clk *clk, int enable)
>> {
>> return s5p_gatectrl(EXYNOS5_CLKGATE_IP_MFC, clk, enable);
>> @@ -635,6 +658,11 @@ static struct clk exynos5_init_clocks_off[] = {
>> .ctrlbit= (1 << 3),
>> }, {
>> .name = "iis",
>> + .devname= "samsung-i2s.0",
>> + .enable = exynos5_clk_audss_ctrl,
>> + .ctrlbit= (3 << 2),
>> + }, {
>> + .name = "iis",
>> .devname= "samsung-i2s.1",
>> .enable = exynos5_clk_ip_peric_ctrl,
>> .ctrlbit= (1 << 20),
>> @@ -645,6 +673,11 @@ static struct clk exynos5_init_clocks_off[] = {
>> .ctrlbit= (1 << 21),
>> }, {
>> .name = "pcm",
>> + .devname= "samsung-pcm.0",
>> + .enable = exynos5_clk_audss_ctrl,
>> + .ctrlbit= (3 << 4),
>> + }, {
>> + .name = "pcm",
>> .devname= "samsung-pcm.1",
>> .enable = exynos5_clk_ip_peric_ctrl,
>> .ctrlbit= (1 << 22),
>> @@ -870,6 +903,95 @@ static struct clk exynos5_init_clocks_on[] = {
>> }
>> };
>>
>> +static struct clk *clkset_sclk_audio0_list[] = {
>> + [0] = &exynos5_clk_audiocdclk0,
>> + [1] = &clk_ext_xtal_mux,
>> + [2] = &exynos5_clk_sclk_hdmi27m,
>> + [3] = &exynos5_clk_sclk_dptxphy,
>> + [4] = &exynos5_clk_sclk_usbphy,
>> + [5] = &exynos5_clk_sclk_hdmiphy,
>> + [6] = &exynos5_clk_mout_mpll.clk,
>> + [7] = &exynos5_clk_mout_epll.clk,
>> + [8] = &exynos5_clk_sclk_vpll.clk,
>> + [9] = &exynos5_clk_mout_cpll.clk,
>> +};
>> +
>> +static struct clksrc_sources exynos5_clkset_sclk_audio0 = {
>> + .sources= clkset_sclk_audio0_list,
>> + .nr_sources = ARRAY_SIZE(clkset_sclk_audio0_list),
>> +};
>> +
>> +static struct clksrc_clk exynos5_clk_sclk_audio0 = {
>> + .clk= {
>> + .name = "audio-bus",
>
> sclk_audio?
Yes. The name of this clock instance can be changed to sclk_audio for
better understanding.
>
>> + .enable = exynos5_clksrc_mask_maudio_ctrl,
>> + .ctrlbit= (1 << 0),
>> + },
>> + .sources = &exynos5_clkset_sclk_audio0,
>> + .reg_src = { .reg = EXYNOS5_CLKSRC_MAUDIO, .shift = 0, .size = 4 },
>> + .reg_div = { .reg = EXYNOS5_CLKDIV_MAUDIO, .sh
[PATCH 5/5] ARM: Exynos4210: Enabling sec_usbphy driver
Adding usbphy node for Exynos4210 along with the platform data.
Signed-off-by: Praveen Paneri
---
arch/arm/boot/dts/exynos4210.dtsi |5 +
arch/arm/mach-exynos/include/mach/map.h |1 +
arch/arm/mach-exynos/mach-exynos4-dt.c |8
arch/arm/mach-exynos/setup-usb-phy.c| 13 +
4 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index a1dd2ee..fc9e00f 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -45,6 +45,11 @@
interrupts = <0 44 0>, <0 45 0>;
};
+ usbphy@125B {
+ compatible = "samsung,exynos4210-usbphy";
+ reg = <0x125B 0x100>;
+ };
+
keypad@100A {
compatible = "samsung,s5pv210-keypad";
reg = <0x100A 0x100>;
diff --git a/arch/arm/mach-exynos/include/mach/map.h
b/arch/arm/mach-exynos/include/mach/map.h
index ca4aa89..a265634 100644
--- a/arch/arm/mach-exynos/include/mach/map.h
+++ b/arch/arm/mach-exynos/include/mach/map.h
@@ -231,6 +231,7 @@
#define S3C_PA_SPI1EXYNOS4_PA_SPI1
#define S3C_PA_SPI2EXYNOS4_PA_SPI2
#define S3C_PA_USB_HSOTG EXYNOS4_PA_HSOTG
+#define S3C_PA_USB_PHY EXYNOS4_PA_HSPHY
#define S5P_PA_EHCIEXYNOS4_PA_EHCI
#define S5P_PA_FIMC0 EXYNOS4_PA_FIMC0
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index e7e9743..9126637 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
#include
@@ -20,9 +21,14 @@
#include
#include
+#include
#include "common.h"
+static struct s3c_usbphy_plat exynos4_usbphy_pdata = {
+ .pmu_isolation = s5p_usb_phy_pmu_isolation,
+};
+
/*
* The following lookup table is used to override device names when devices
* are registered from device tree. This is temporarily added to enable
@@ -57,6 +63,8 @@ static const struct of_dev_auxdata
exynos4210_auxdata_lookup[] __initconst = {
"s3c2440-i2c.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA0, "dma-pl330.0", NULL),
OF_DEV_AUXDATA("arm,pl330", EXYNOS4_PA_PDMA1, "dma-pl330.1", NULL),
+ OF_DEV_AUXDATA("samsung,exynos4210-usbphy", EXYNOS4_PA_HSPHY,
+ "s3c-usbphy", &exynos4_usbphy_pdata),
{},
};
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index 1af0a7f..3fca203 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -193,3 +193,16 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int
type)
return -EINVAL;
}
+
+void s5p_usb_phy_pmu_isolation(int on)
+{
+ if (on) {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+ & ~S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ } else {
+ writel(readl(S5P_USBDEVICE_PHY_CONTROL)
+ | S5P_USBDEVICE_PHY_ENABLE,
+ S5P_USBDEVICE_PHY_CONTROL);
+ }
+}
--
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
[PATCH 4/5] ARM: S3C64XX: Enabling sec_usbphy driver
Adding platform device for sec_usbphy driver. Enabling it for s3c64xx
based machines using s3c-hsotg.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/include/mach/map.h |2 +
arch/arm/mach-s3c64xx/mach-crag6410.c|3 ++
arch/arm/mach-s3c64xx/mach-smartq.c |4 +++
arch/arm/mach-s3c64xx/mach-smdk6410.c|3 ++
arch/arm/mach-s3c64xx/setup-usb-phy.c| 14 +++
arch/arm/plat-samsung/devs.c | 32 ++
arch/arm/plat-samsung/include/plat/devs.h|1 +
arch/arm/plat-samsung/include/plat/usb-phy.h |1 +
8 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/include/mach/map.h
b/arch/arm/mach-s3c64xx/include/mach/map.h
index 8e2097b..dc482bb 100644
--- a/arch/arm/mach-s3c64xx/include/mach/map.h
+++ b/arch/arm/mach-s3c64xx/include/mach/map.h
@@ -65,6 +65,7 @@
#define S3C64XX_PA_NAND(0x7020)
#define S3C64XX_PA_FB (0x7710)
+#define S3C64XX_PA_USB_HSPHY (0x7C10)
#define S3C64XX_PA_USB_HSOTG (0x7C00)
#define S3C64XX_PA_WATCHDOG(0x7E004000)
#define S3C64XX_PA_RTC (0x7E005000)
@@ -113,6 +114,7 @@
#define S3C_PA_FB S3C64XX_PA_FB
#define S3C_PA_USBHOST S3C64XX_PA_USBHOST
#define S3C_PA_USB_HSOTG S3C64XX_PA_USB_HSOTG
+#define S3C_PA_USB_PHY S3C64XX_PA_USB_HSPHY
#define S3C_PA_RTC S3C64XX_PA_RTC
#define S3C_PA_WDT S3C64XX_PA_WATCHDOG
#define S3C_PA_SPI0S3C64XX_PA_SPI0
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 984146e..88c4671 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -337,6 +337,7 @@ static struct platform_device wallvdd_device = {
};
static struct platform_device *crag6410_devices[] __initdata = {
+ &s3c_device_usbphy,
&s3c_device_hsmmc0,
&s3c_device_hsmmc2,
&s3c_device_i2c0,
@@ -767,6 +768,7 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
+static struct s3c_usbphy_plat crag6410_usbphy_pdata;
static void __init crag6410_machine_init(void)
{
@@ -792,6 +794,7 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
+ s3c_usbphy_set_platdata(&crag6410_usbphy_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index 3647202..97751d5 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -235,6 +235,7 @@ static struct i2c_board_info smartq_i2c_devs[] __initdata =
{
};
static struct platform_device *smartq_devices[] __initdata = {
+ &s3c_device_usbphy,
&s3c_device_hsmmc1, /* Init iNAND first, ... */
&s3c_device_hsmmc0, /* ... then the external SD card */
&s3c_device_hsmmc2,
@@ -381,9 +382,12 @@ void __init smartq_map_io(void)
smartq_lcd_mode_set();
}
+static struct s3c_usbphy_plat smartq_usbphy_pdata;
+
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
+ s3c_usbphy_set_platdata(&smartq_usbphy_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index ceec1a9..c5ea838 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -264,6 +264,7 @@ static struct samsung_keypad_platdata smdk6410_keypad_data
__initdata = {
static struct map_desc smdk6410_iodesc[] = {};
static struct platform_device *smdk6410_devices[] __initdata = {
+ &s3c_device_usbphy,
#ifdef CONFIG_SMDK6410_SD_CH0
&s3c_device_hsmmc0,
#endif
@@ -628,6 +629,7 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
+static struct s3c_usbphy_plat smdk6410_usbphy_pdata;
static void __init smdk6410_map_io(void)
{
@@ -657,6 +659,7 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(&smdk6410_lcd_pdata);
+ s3c_usbphy_set_platdata(&smdk6410_usbphy_pdata);
samsung_keypad_set_platdata(&smdk6410_keypad_data);
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index 7a09553..3aee778 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,3 +9,17 @@
*
*/
+#include
+#include
+#include
+
+void s5p_usb_phy_pmu_isola
[PATCH 3/5] ARM: S3C64XX: Removing old phy setup code
This patch removes old phy code from platform side. 'setup-usb-phy.c'
will be used for providing transceiver platform data in next
patch. Not all of the platform data code is removed as there are others
making use of platform_data defined for hsotg. That can be removed once
all the SoCs start using the new transceiver for usb phy setup.
Signed-off-by: Praveen Paneri
---
arch/arm/mach-s3c64xx/mach-crag6410.c |2 -
arch/arm/mach-s3c64xx/mach-smartq.c |2 -
arch/arm/mach-s3c64xx/mach-smdk6410.c |2 -
arch/arm/mach-s3c64xx/setup-usb-phy.c | 79 -
4 files changed, 0 insertions(+), 85 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index d0c352d..984146e 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -767,7 +767,6 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct s3c_hsotg_plat crag6410_hsotg_pdata;
static void __init crag6410_machine_init(void)
{
@@ -793,7 +792,6 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(&i2c0_pdata);
s3c_i2c1_set_platdata(&i2c1_pdata);
s3c_fb_set_platdata(&crag6410_lcd_pdata);
- s3c_hsotg_set_platdata(&crag6410_hsotg_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index ceeb1de..3647202 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -187,7 +187,6 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata __initdata
= {
},
};
-static struct s3c_hsotg_plat smartq_hsotg_pdata;
static int __init smartq_lcd_setup_gpio(void)
{
@@ -385,7 +384,6 @@ void __init smartq_map_io(void)
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
- s3c_hsotg_set_platdata(&smartq_hsotg_pdata);
s3c_hwmon_set_platdata(&smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(&smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(&smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index df3103d..ceec1a9 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -628,7 +628,6 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.pwm_id = 1,
};
-static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
static void __init smdk6410_map_io(void)
{
@@ -658,7 +657,6 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(&smdk6410_lcd_pdata);
- s3c_hsotg_set_platdata(&smdk6410_hsotg_pdata);
samsung_keypad_set_platdata(&smdk6410_keypad_data);
diff --git a/arch/arm/mach-s3c64xx/setup-usb-phy.c
b/arch/arm/mach-s3c64xx/setup-usb-phy.c
index f6757e0..7a09553 100644
--- a/arch/arm/mach-s3c64xx/setup-usb-phy.c
+++ b/arch/arm/mach-s3c64xx/setup-usb-phy.c
@@ -9,82 +9,3 @@
*
*/
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-static int s3c_usb_otgphy_init(struct platform_device *pdev)
-{
- struct clk *xusbxti;
- u32 phyclk;
-
- writel(readl(S3C64XX_OTHERS) | S3C64XX_OTHERS_USBMASK, S3C64XX_OTHERS);
-
- /* set clock frequency for PLL */
- phyclk = readl(S3C_PHYCLK) & ~S3C_PHYCLK_CLKSEL_MASK;
-
- xusbxti = clk_get(&pdev->dev, "xusbxti");
- if (xusbxti && !IS_ERR(xusbxti)) {
- switch (clk_get_rate(xusbxti)) {
- case 12 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_12M;
- break;
- case 24 * MHZ:
- phyclk |= S3C_PHYCLK_CLKSEL_24M;
- break;
- default:
- case 48 * MHZ:
- /* default reference clock */
- break;
- }
- clk_put(xusbxti);
- }
-
- /* TODO: select external clock/oscillator */
- writel(phyclk | S3C_PHYCLK_CLK_FORCE, S3C_PHYCLK);
-
- /* set to normal OTG PHY */
- writel((readl(S3C_PHYPWR) & ~S3C_PHYPWR_NORMAL_MASK), S3C_PHYPWR);
- mdelay(1);
-
- /* reset OTG PHY and Link */
- writel(S3C_RSTCON_PHY | S3C_RSTCON_HCLK | S3C_RSTCON_PHYCLK,
- S3C_RSTCON);
- udelay(20); /* at-least 10uS */
- writel(0, S3C_RSTCON);
-
- return 0;
-}
-
-static int s3c_usb_otgphy_exit(struct platform_device *pdev)
-{
- writel((readl(S3C_PHYPWR) | S3C_PHYPWR_ANALOG_POWERDOWN |
- S3C_PHYPWR_OTG_DISABLE), S3C_PHYPWR);
-
- writel(readl(S3C64XX_OTHERS) & ~S3C64XX_OTHERS_USBMASK, S3C6
[PATCH 2/5] usb: s3c-hsotg: Adding phy driver support
Adding the transceiver to hsotg driver. Keeping the platform data
for continuing the smooth operation for boards which still uses it
Signed-off-by: Praveen Paneri
---
drivers/usb/gadget/s3c-hsotg.c | 38 --
1 files changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c
index b13e0bb..f4ba9a3 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/gadget/s3c-hsotg.c
@@ -32,6 +32,7 @@
#include
#include
+#include
#include
#include
@@ -133,7 +134,9 @@ struct s3c_hsotg_ep {
* struct s3c_hsotg - driver state.
* @dev: The parent device supplied to the probe function
* @driver: USB gadget driver
- * @plat: The platform specific configuration data.
+ * @phy: The otg phy transeiver structure for phy control.
+ * @plat: The platform specific configuration data. This can be removed once
+ * all SoCs support usb transceiver.
* @regs: The memory area mapped for accessing registers.
* @irq: The IRQ number we are using
* @supplies: Definition of USB power supplies
@@ -153,6 +156,7 @@ struct s3c_hsotg_ep {
struct s3c_hsotg {
struct device*dev;
struct usb_gadget_driver *driver;
+ struct usb_phy *phy;
struct s3c_hsotg_plat*plat;
spinlock_t lock;
@@ -2854,7 +2858,10 @@ static void s3c_hsotg_phy_enable(struct s3c_hsotg *hsotg)
struct platform_device *pdev = to_platform_device(hsotg->dev);
dev_dbg(hsotg->dev, "pdev 0x%p\n", pdev);
- if (hsotg->plat->phy_init)
+
+ if (hsotg->phy)
+ usb_phy_init(hsotg->phy);
+ else if (hsotg->plat->phy_init)
hsotg->plat->phy_init(pdev, hsotg->plat->phy_type);
}
@@ -2869,7 +2876,9 @@ static void s3c_hsotg_phy_disable(struct s3c_hsotg *hsotg)
{
struct platform_device *pdev = to_platform_device(hsotg->dev);
- if (hsotg->plat->phy_exit)
+ if (hsotg->phy)
+ usb_phy_shutdown(hsotg->phy);
+ else if (hsotg->plat->phy_exit)
hsotg->plat->phy_exit(pdev, hsotg->plat->phy_type);
}
@@ -3493,6 +3502,7 @@ static void s3c_hsotg_release(struct device *dev)
static int __devinit s3c_hsotg_probe(struct platform_device *pdev)
{
struct s3c_hsotg_plat *plat = pdev->dev.platform_data;
+ struct usb_phy *phy;
struct device *dev = &pdev->dev;
struct s3c_hsotg_ep *eps;
struct s3c_hsotg *hsotg;
@@ -3501,20 +3511,25 @@ static int __devinit s3c_hsotg_probe(struct
platform_device *pdev)
int ret;
int i;
- plat = pdev->dev.platform_data;
- if (!plat) {
- dev_err(&pdev->dev, "no platform data defined\n");
- return -EINVAL;
- }
-
hsotg = devm_kzalloc(&pdev->dev, sizeof(struct s3c_hsotg), GFP_KERNEL);
if (!hsotg) {
dev_err(dev, "cannot get memory\n");
return -ENOMEM;
}
+ phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
+ if (!phy) {
+ /* Fallback for platform data */
+ plat = pdev->dev.platform_data;
+ if (!plat) {
+ dev_err(&pdev->dev, "no platform data or transceiver
defined\n");
+ return -ENODEV;
+ } else
+ hsotg->plat = plat;
+ } else
+ hsotg->phy = phy;
+
hsotg->dev = dev;
- hsotg->plat = plat;
hsotg->clk = clk_get(&pdev->dev, "otg");
if (IS_ERR(hsotg->clk)) {
@@ -3689,6 +3704,9 @@ static int __devexit s3c_hsotg_remove(struct
platform_device *pdev)
s3c_hsotg_phy_disable(hsotg);
regulator_bulk_free(ARRAY_SIZE(hsotg->supplies), hsotg->supplies);
+ if (hsotg->phy)
+ devm_usb_put_phy(&pdev->dev, hsotg->phy);
+
clk_disable_unprepare(hsotg->clk);
clk_put(hsotg->clk);
--
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
[PATCH 1/5] usb: phy: samsung: Introducing usb phy driver for hsotg
This driver uses usb_phy interface to interact with s3c-hsotg. Supports
phy_init and phy_shutdown functions to enable/disable phy. Tested with
smdk6410 and smdkv310. More SoCs can be brought under later.
Signed-off-by: Praveen Paneri
---
.../devicetree/bindings/usb/samsung-usbphy.txt |9 +
drivers/usb/phy/Kconfig|8 +
drivers/usb/phy/Makefile |1 +
drivers/usb/phy/sec_usbphy.c | 354
drivers/usb/phy/sec_usbphy.h | 48 +++
include/linux/platform_data/s3c-hsotg.h|5 +
6 files changed, 425 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
create mode 100644 drivers/usb/phy/sec_usbphy.c
create mode 100644 drivers/usb/phy/sec_usbphy.h
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
new file mode 100644
index 000..fefd9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
@@ -0,0 +1,9 @@
+* Samsung's usb phy transceiver
+
+The Samsung's phy transceiver is used for controlling usb otg phy for
+s3c-hsotg usb device controller.
+
+Required properties:
+- compatible : should be "samsung,exynos4210-usbphy"
+- reg : base physical address of the phy registers and length of memory mapped
+ region.
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e7cf84f..abbebe2 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -15,3 +15,11 @@ config USB_ISP1301
To compile this driver as a module, choose M here: the
module will be called isp1301.
+
+config SEC_USBPHY
+ bool "Samsung USB PHY controller Driver"
+ depends on USB_S3C_HSOTG
+ select USB_OTG_UTILS
+ help
+ Enable this to support Samsung USB phy controller for samsung
+ SoCs.
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index eca095b..6bb66f0 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -5,3 +5,4 @@
ccflags-$(CONFIG_USB_DEBUG) := -DDEBUG
obj-$(CONFIG_USB_ISP1301) += isp1301.o
+obj-$(CONFIG_SEC_USBPHY) += sec_usbphy.o
diff --git a/drivers/usb/phy/sec_usbphy.c b/drivers/usb/phy/sec_usbphy.c
new file mode 100644
index 000..33119eb
--- /dev/null
+++ b/drivers/usb/phy/sec_usbphy.c
@@ -0,0 +1,354 @@
+/* linux/drivers/usb/phy/sec_usbphy.c
+ *
+ * Copyright (c) 2012 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Author: Praveen Paneri
+ *
+ * Samsung USB2.0 High-speed OTG transceiver, talks to S3C HS OTG controller
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "sec_usbphy.h"
+
+enum sec_cpu_type {
+ TYPE_S3C64XX,
+ TYPE_EXYNOS4210,
+};
+
+/*
+ * struct sec_usbphy - transceiver driver state
+ * @phy: transceiver structure
+ * @plat: platform data
+ * @dev: The parent device supplied to the probe function
+ * @clk: usb phy clock
+ * @regs: usb phy register memory base
+ * @cpu_type: machine identifier
+ */
+struct sec_usbphy {
+ struct usb_phy phy;
+ struct s3c_usbphy_plat *plat;
+ struct device *dev;
+ struct clk *clk;
+ void __iomem*regs;
+ int cpu_type;
+};
+
+#define phy_to_sec(x) container_of((x), struct sec_usbphy, phy)
+
+/*
+ * Enables or disables the phy clock
+ * returns 0 on success else the error
+ */
+static int sec_usbphy_clk_control(struct sec_usbphy *sec, bool on)
+{
+ if (on) {
+ if (!sec->clk) {
+ sec->clk = clk_get(sec->dev, "otg");
+ if (IS_ERR(sec->clk)) {
+ dev_err(sec->dev, "Failed to get otg clock\n");
+ return PTR_ERR(sec->clk);
+ }
+ }
+ clk_enable(sec->clk);
+ } else {
+ clk_disable(sec->clk);
+ clk_put(sec->clk);
+ }
+
+ return 0;
+}
+
+/*
+ * Returns reference clock frequency
+ */
+static int sec_usbphy_get_refclk_freq(struct sec_usbphy *sec)
+{
+ struct clk *ref_clk;
+ int refclk_freq = 0;
+
+ ref_c
[PATCH 0/5] usb: phy: samsung: Introducing usb phy driver for samsung SoCs
This patch set introduces a phy driver for samsung SoCs. It uses the existing transceiver infrastructure to provide phy control functions. Use of this driver can be extended for usb host phy as well. Over the period of time all the phy related code for most of the samsung SoCs can be integrated here. Removing the existing phy code from mach-s3c64xx but not from other machine code.This driver is tested with smdk6410 and Exynos4210(with DT). Praveen Paneri (5): usb: phy: samsung: Introducing usb phy driver for hsotg usb: s3c-hsotg: Adding phy driver support ARM: S3C64XX: Removing old phy setup code ARM: S3C64XX: Enabling sec_usbphy driver ARM: Exynos4210: Enabling sec_usbphy driver .../devicetree/bindings/usb/samsung-usbphy.txt |9 + arch/arm/boot/dts/exynos4210.dtsi |5 + arch/arm/mach-exynos/include/mach/map.h|1 + arch/arm/mach-exynos/mach-exynos4-dt.c |8 + arch/arm/mach-exynos/setup-usb-phy.c | 13 + arch/arm/mach-s3c64xx/include/mach/map.h |2 + arch/arm/mach-s3c64xx/mach-crag6410.c |5 +- arch/arm/mach-s3c64xx/mach-smartq.c|6 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |5 +- arch/arm/mach-s3c64xx/setup-usb-phy.c | 79 + arch/arm/plat-samsung/devs.c | 32 ++ arch/arm/plat-samsung/include/plat/devs.h |1 + arch/arm/plat-samsung/include/plat/usb-phy.h |1 + drivers/usb/gadget/s3c-hsotg.c | 38 ++- drivers/usb/phy/Kconfig|8 + drivers/usb/phy/Makefile |1 + drivers/usb/phy/sec_usbphy.c | 354 drivers/usb/phy/sec_usbphy.h | 48 +++ include/linux/platform_data/s3c-hsotg.h|5 + 19 files changed, 533 insertions(+), 88 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt create mode 100644 drivers/usb/phy/sec_usbphy.c create mode 100644 drivers/usb/phy/sec_usbphy.h -- 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/3] ARM: exynos: Save combiner registers on suspend
Jonathan Kliegman wrote:
>
> The interupt combiner registers need to be saved on suspend resume
> or its interrupts (trackpad and keyboard most noticeably) won't work
> after resume.
>
> Signed-off-by: Jonathan Kliegman
> ---
> arch/arm/mach-exynos/common.c | 74
> +
> 1 files changed, 67 insertions(+), 7 deletions(-)
[...]
> +#ifdef CONFIG_PM
#ifdef CONFIG_CPU_PM?
> +static void combiner_save(void)
> +{
> + int i;
> +
> + for (i = 0; i < rt_max_combiner_nr; i++) {
> + if (combiner_data[i].irq_mask &
> + __raw_readl(combiner_data[i].base +
COMBINER_ENABLE_SET))
> {
> + combiner_data[i].saved_on = true;
> + } else {
> + combiner_data[i].saved_on = false;
> + }
> + }
> +}
> +
> +static void combiner_restore(void)
> +{
> + int i;
> +
> + for (i = 0; i < rt_max_combiner_nr; i++) {
> + if (!combiner_data[i].saved_on)
> + continue;
> +
> + __raw_writel(combiner_data[i].irq_mask,
> + combiner_data[i].base + COMBINER_ENABLE_SET);
> + }
> +}
> +
> +
No need double empty lines :)
> +static int combiner_notifier(struct notifier_block *self, unsigned long
> cmd,
> + void *v)
> +{
> + switch (cmd) {
> + case CPU_PM_ENTER:
Should be CPU_CLUSTER_PM_ENTER?
> + combiner_save();
> + break;
> + case CPU_PM_EXIT:
CPU_CLUSTER_PM_EXIT?
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 V2 5/5] arm: samsung: delete frame buffer header files from platform
Sylwester Nawrocki wrote: > > Hi, > > On 08/01/2012 11:39 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim > wrote: > >>> Leela Krishna Amudala wrote: > > The FIMD register headers are moved to include/video/ > hence, deleting these files from platform side > > Signed-off-by: Leela Krishna Amudala > --- > arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - > arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > >>> --- > > 2 files changed, 0 insertions(+), 562 deletions(-) > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > > >>> No. This should be squashed into first patch on this series. See below. > >>> > >>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > >>> > >>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 > >>> -- > >>> 2 files changed, 134 insertions(+), 170 deletions(-) > >>> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >>> rename arch/arm/plat-samsung/include/plat/regs-fb.h => > >>> include/video/samsung_fimd.h (74%) > >>> > >> > >> If I squash it with the first patch and if somebody set that as a head > >> commit, it will break the build. Hence, splitted it up from the first > >> patch. > >> > > NACK. your changes are not adding just moving. So should be squashed. If > > required, you could create just one patch for moving them, probably, 1st, > > 3rd, 4th and 5th patches into one patch. > > Yes, this patch series is mainly moving files around. But to avoid git > bisect breakage, it should be split as it is done now, or the whole > series should be squashed into one patch. The latter might be even easier > to handle, but having a single patch touching arch/arm/ and drivers/ > might not be a good idea. If you're fine handling that, then we just > need to squash this series into single patch. > It just need to be ensured, IMO, there is no bisection breakage. > I know you meant. But we don't need to keep the changes 'adding and removing' for just moving on this. I commented on 0/5 patch in this series before, if this is ready, I will create topic branch so that it could be merged into both mine and Florian's. 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 V2 0/5] arm: samsung: Move FIMD headers to include/video/
Florian Tobias Schandinat wrote: > > On 08/01/2012 02:28 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from > arch > >> side > >> to include/video/samsung_fimd.h > >> > >> This patchset is created and rebased against master branch of torvalds > >> tree. > >> Tested on smdk5250 board, build tested for other boards. > >> > > (Cc'ed Florian Tobias Schandinat) > > > > Yeah, since it's merge window, this series could be created against on > > mainline. And IMO, would be helpful to us if this series could be sent > to > > upstream via samsung tree after reviewing, because this touches too many > > files in samsung tree and just adds include/video/samsung_fimd.h. But > I'm > > not sure the added inclusion will be used in other file of drivers/video. > If > > so, I can provide some topic branch can be merged into Florian's tree. > > Florian, how about? > > Using a topic branch to merge it in both trees sounds like a good plan > to me. > Sure, if this change is ready, I will create topic branch then let you 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 V2 5/5] arm: samsung: delete frame buffer header files from platform
Hi, On 08/01/2012 11:39 AM, Kukjin Kim wrote: > Leela Krishna Amudala wrote: >> On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim wrote: >>> Leela Krishna Amudala wrote: The FIMD register headers are moved to include/video/ hence, deleting these files from platform side Signed-off-by: Leela Krishna Amudala --- arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - arch/arm/plat-samsung/include/plat/regs-fb.h| 403 >>> --- 2 files changed, 0 insertions(+), 562 deletions(-) delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h >>> No. This should be squashed into first patch on this series. See below. >>> >>> arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 >>> >>> .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 >>> -- >>> 2 files changed, 134 insertions(+), 170 deletions(-) >>> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h >>> rename arch/arm/plat-samsung/include/plat/regs-fb.h => >>> include/video/samsung_fimd.h (74%) >>> >> >> If I squash it with the first patch and if somebody set that as a head >> commit, it will break the build. Hence, splitted it up from the first >> patch. >> > NACK. your changes are not adding just moving. So should be squashed. If > required, you could create just one patch for moving them, probably, 1st, > 3rd, 4th and 5th patches into one patch. Yes, this patch series is mainly moving files around. But to avoid git bisect breakage, it should be split as it is done now, or the whole series should be squashed into one patch. The latter might be even easier to handle, but having a single patch touching arch/arm/ and drivers/ might not be a good idea. If you're fine handling that, then we just need to squash this series into single patch. It just need to be ensured, IMO, there is no bisection breakage. -- Regards, 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 0/5] arm: samsung: Move FIMD headers to include/video/
On 08/01/2012 02:28 AM, Kukjin Kim wrote: > Leela Krishna Amudala wrote: >> >> This patchset moves the contents of regs-fb-v4.h and regs-fb.h from arch >> side >> to include/video/samsung_fimd.h >> >> This patchset is created and rebased against master branch of torvalds >> tree. >> Tested on smdk5250 board, build tested for other boards. >> > (Cc'ed Florian Tobias Schandinat) > > Yeah, since it's merge window, this series could be created against on > mainline. And IMO, would be helpful to us if this series could be sent to > upstream via samsung tree after reviewing, because this touches too many > files in samsung tree and just adds include/video/samsung_fimd.h. But I'm > not sure the added inclusion will be used in other file of drivers/video. If > so, I can provide some topic branch can be merged into Florian's tree. > Florian, how about? Using a topic branch to merge it in both trees sounds like a good plan to me. Best regards, Florian Tobias Schandinat > > Thanks. > > Best regards, > Kgene. > -- > Kukjin Kim , Senior Engineer, > SW Solution Development Team, Samsung Electronics Co., Ltd. > >> Changes from version 1: >> - Split the patches as per Sylwester comments >> - Changed FIMD_V8_xxx macro to EXYNOS5_xxx >> >> Leela Krishna Amudala (5): >> include/video: Add samsung FIMD register header >> include/video: Add Exynos5 specific FIMD register offsets >> arm: samsung: Include the modified FIMD header file >> driver: Include the modified FIMD header file >> arm: samsung: delete frame buffer header files from platform >> >> arch/arm/mach-exynos/mach-nuri.c |2 +- >> arch/arm/mach-exynos/mach-origen.c |2 +- >> arch/arm/mach-exynos/mach-smdk4x12.c |2 +- >> arch/arm/mach-exynos/mach-smdkv310.c |2 +- >> arch/arm/mach-exynos/mach-universal_c210.c |2 +- >> arch/arm/mach-exynos/setup-fimd0.c |2 +- >> arch/arm/mach-s3c24xx/mach-smdk2416.c |2 +- >> arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- >> arch/arm/mach-s3c64xx/mach-crag6410.c |2 +- >> arch/arm/mach-s3c64xx/mach-hmt.c |2 +- >> arch/arm/mach-s3c64xx/mach-mini6410.c |2 +- >> arch/arm/mach-s3c64xx/mach-ncp.c |2 +- >> arch/arm/mach-s3c64xx/mach-real6410.c |2 +- >> arch/arm/mach-s3c64xx/mach-smartq5.c |2 +- >> arch/arm/mach-s3c64xx/mach-smartq7.c |2 +- >> arch/arm/mach-s3c64xx/mach-smdk6410.c |2 +- >> arch/arm/mach-s5p64x0/mach-smdk6440.c |2 +- >> arch/arm/mach-s5p64x0/mach-smdk6450.c |2 +- >> arch/arm/mach-s5pc100/mach-smdkc100.c |2 +- >> arch/arm/mach-s5pv210/mach-aquila.c|2 +- >> arch/arm/mach-s5pv210/mach-goni.c |2 +- >> arch/arm/mach-s5pv210/mach-smdkv210.c |2 +- >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > >> >> drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +- >> drivers/video/s3c-fb.c |2 +- >> .../plat/regs-fb.h => include/video/samsung_fimd.h | 152 >> +-- >> 26 files changed, 165 insertions(+), 194 deletions(-) >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h >> rename arch/arm/plat-samsung/include/plat/regs-fb.h => >> include/video/samsung_fimd.h (74%) > > -- 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 5/5] arm: samsung: delete frame buffer header files from platform
Leela Krishna Amudala wrote: > > Hello Kgene, > > On Wed, Aug 1, 2012 at 7:34 AM, Kukjin Kim wrote: > > Leela Krishna Amudala wrote: > >> > >> The FIMD register headers are moved to include/video/ > >> hence, deleting these files from platform side > >> > >> Signed-off-by: Leela Krishna Amudala > >> --- > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 159 - > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 403 > > --- > >> > >> 2 files changed, 0 insertions(+), 562 deletions(-) > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb.h > >> > > No. This should be squashed into first patch on this series. See below. > > > > arch/arm/plat-samsung/include/plat/regs-fb-v4.h| 159 > > > > .../plat/regs-fb.h => include/video/samsung_fimd.h | 145 > > -- > > 2 files changed, 134 insertions(+), 170 deletions(-) > > delete mode 100644 arch/arm/plat-samsung/include/plat/regs-fb-v4.h > > rename arch/arm/plat-samsung/include/plat/regs-fb.h => > > include/video/samsung_fimd.h (74%) > > > > If I squash it with the first patch and if somebody set that as a head > commit, it will break the build. Hence, splitted it up from the first > patch. > NACK. your changes are not adding just moving. So should be squashed. If required, you could create just one patch for moving them, probably, 1st, 3rd, 4th and 5th patches into one patch. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > Thank you Sylwester for suggesting this split up change. > > Regards, > Leela Krishna -- 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] ARM: EXYNOS: Add Gscaler device from DT
Sylwester Nawrocki wrote: > > On 08/01/2012 09:48 AM, Thomas Abraham wrote: > > On 1 August 2012 12:10, Kukjin Kim wrote: > >> Shaik Ameer Basha wrote: > > > > [...] > > > >>> +* Samsung Exynos5 Gscaler device > >>> + > >>> +Gscaler is used for scaling and color space conversion on EXYNOS5 > SoCs. > >>> + > >>> +Required properties: > >>> +- compatible: should be "samsung,exynos5250-gsc" > >> > >> IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can > use > >> same gscaler driver. > > In addition to the below explanation, perhaps it's obvious, but the driver > can claim compatibility with multiple devices, i.e. match with multiple > 'compatible' properties. > The name of exact model is 'gscaler' for EXYNOS5 SoCs not only for EXYNOS5250. So the driver which has been submitted is also 'exynos-gsc' not 'exynos5250-gsc'. Note that there is no gscaler on EXYNOS4 SoCs now, it can be either 'exynos5-gsc' or 'exynos-gsc'. In addition, since some peripherals/drivers can be used for multiple SoCs and actually it does, I'm still thinking the compatible should be represent its usage. I don't know why restricted name is much clearer. And if multiple 'compatible' is required, we can add it later. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. > > > The compatible string should always be specific and it should clearly > > identify the type of the controller. If there are other variants of > > the GSC controller in previous of upcoming SoC's, then those > > controllers will have a different compatible value. > > > > This allows device drivers to know the type of the controller and > > handle the differences among them. And, the node in the dts/dtsi file > > should always claim compatibility to the base version of the > > controller that the platform supports. > > > > So the compatible value "samsung,exynos5250-gsc" is right one. If a > > new SoC in the Exynos5 family has the same GSC controller as that in > > Exynos5250 (no difference at all), then GSC device node in its dts > > file can continue to claim compatibility to Exynos5250 type. The > > "samsung,s3c2410-wdt is an example of this case which has been used on > > all Samsung SoC's . > > -- 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: [alsa-devel] [PATCH 1/2] ASOC: SAMSUNG: Add DT support for i2s
Hi, On Wednesday, July 25, 2012 9:09 PM, Padmavathi Venna wrote: > Add support for device based discovery. > Currently, I'm reviewing your patch set. Your patch can support device tree for Samsung's i2s. But I wonder that Your patch can support non-dt too, So, Please test your patch on non-dt environment. It looks unclear handling of clock source. After code review, I will give you more detail comments, Thanks, Sangbeom. -- 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] ARM: EXYNOS: Add Gscaler device from DT
On 08/01/2012 09:48 AM, Thomas Abraham wrote: > On 1 August 2012 12:10, Kukjin Kim wrote: >> Shaik Ameer Basha wrote: > > [...] > >>> +* Samsung Exynos5 Gscaler device >>> + >>> +Gscaler is used for scaling and color space conversion on EXYNOS5 SoCs. >>> + >>> +Required properties: >>> +- compatible: should be "samsung,exynos5250-gsc" >> >> IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can use >> same gscaler driver. In addition to the below explanation, perhaps it's obvious, but the driver can claim compatibility with multiple devices, i.e. match with multiple 'compatible' properties. Regards, Sylwester > The compatible string should always be specific and it should clearly > identify the type of the controller. If there are other variants of > the GSC controller in previous of upcoming SoC's, then those > controllers will have a different compatible value. > > This allows device drivers to know the type of the controller and > handle the differences among them. And, the node in the dts/dtsi file > should always claim compatibility to the base version of the > controller that the platform supports. > > So the compatible value "samsung,exynos5250-gsc" is right one. If a > new SoC in the Exynos5 family has the same GSC controller as that in > Exynos5250 (no difference at all), then GSC device node in its dts > file can continue to claim compatibility to Exynos5250 type. The > "samsung,s3c2410-wdt is an example of this case which has been used on > all Samsung SoC's . > > Thanks, > Thomas. -- 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] ARM: EXYNOS: Add Gscaler device from DT
Thomas Abraham wrote: > > On 1 August 2012 12:10, Kukjin Kim wrote: > > Shaik Ameer Basha wrote: > > [...] > > >> +* Samsung Exynos5 Gscaler device > >> + > >> +Gscaler is used for scaling and color space conversion on EXYNOS5 SoCs. > >> + > >> +Required properties: > >> +- compatible: should be "samsung,exynos5250-gsc" > > > > IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can > use > > same gscaler driver. > > The compatible string should always be specific and it should clearly > identify the type of the controller. If there are other variants of > the GSC controller in previous of upcoming SoC's, then those > controllers will have a different compatible value. > As I commented, there will be no differences for gscaler between EXYNOS5 SoCs. So IMO, the 'exynos5-gsc' is clear enough for compatible string of EXYNOS5 Gscaler. > This allows device drivers to know the type of the controller and > handle the differences among them. And, the node in the dts/dtsi file > should always claim compatibility to the base version of the > controller that the platform supports. > > So the compatible value "samsung,exynos5250-gsc" is right one. If a > new SoC in the Exynos5 family has the same GSC controller as that in > Exynos5250 (no difference at all), then GSC device node in its dts > file can continue to claim compatibility to Exynos5250 type. The I don't think so... > "samsung,s3c2410-wdt is an example of this case which has been used on > all Samsung SoC's . > I think, the case of 's3c2410-wdt' is different because you know, the name has been used for a long time in addition, the name of driver is s3c2410_wdt.c. But in this case, gscaler should be same on EXYNOS5 SoCs which is including upcoming, so I don't see why we should use 'exynos5250-gsc' for all of EXYNOS5 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 v3 2/2] ARM: EXYNOS: Add Gscaler device from DT
On 1 August 2012 12:10, Kukjin Kim wrote: > Shaik Ameer Basha wrote: [...] >> +* Samsung Exynos5 Gscaler device >> + >> +Gscaler is used for scaling and color space conversion on EXYNOS5 SoCs. >> + >> +Required properties: >> +- compatible: should be "samsung,exynos5250-gsc" > > IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can use > same gscaler driver. The compatible string should always be specific and it should clearly identify the type of the controller. If there are other variants of the GSC controller in previous of upcoming SoC's, then those controllers will have a different compatible value. This allows device drivers to know the type of the controller and handle the differences among them. And, the node in the dts/dtsi file should always claim compatibility to the base version of the controller that the platform supports. So the compatible value "samsung,exynos5250-gsc" is right one. If a new SoC in the Exynos5 family has the same GSC controller as that in Exynos5250 (no difference at all), then GSC device node in its dts file can continue to claim compatibility to Exynos5250 type. The "samsung,s3c2410-wdt is an example of this case which has been used on all Samsung SoC's . Thanks, Thomas. -- 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] ARM: EXYNOS: Add Gscaler device from DT
Hi Kukjin Kim,
On Wed, Aug 1, 2012 at 12:10 PM, Kukjin Kim wrote:
> Shaik Ameer Basha wrote:
>>
>> This patch adds,
>> - 4 Gscaler devices to the DT device list
>> - Gscaler specific entries to the machine file
>> - binding documentation for Gscaler entries
>>
>> Signed-off-by: Abhilash Kesavan
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> .../devicetree/bindings/media/exynos5-gsc.txt | 32
>>
>> arch/arm/boot/dts/exynos5250.dtsi | 28
> +
>> arch/arm/mach-exynos/include/mach/map.h|3 ++
>> arch/arm/mach-exynos/mach-exynos5-dt.c |8 +
>> 4 files changed, 71 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/media/exynos5-
>> gsc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> new file mode 100644
>> index 000..1cb4ea0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
>> @@ -0,0 +1,32 @@
>> +* Samsung Exynos5 Gscaler device
>> +
>> +Gscaler is used for scaling and color space conversion on EXYNOS5 SoCs.
>> +
>> +Required properties:
>> +- compatible: should be "samsung,exynos5250-gsc"
>
> IMO, should be "samsung,exynos5-gsc" because upcoming EXYNOS5 SoCs can use
> same gscaler driver.
>
yes. thats true. i will change that.
>> +- reg: should contain Gscaler physical address location and length.
>> +- interrupts: should contain Gscaler interrupt number
>> +
>> +Example:
>> +
>> +gsc_0: gsc@0x13e0 {
>> + compatible = "samsung,exynos5250-gsc";
>
> + compatible = "samsung,exynos5-gsc";
>
ok. will update this accordingly.
>> + reg = <0x13e0 0x1000>;
>> + interrupts = <0 85 0>;
>> +};
>> +
>
> [...]
>
>
>> diff --git a/arch/arm/mach-exynos/include/mach/map.h b/arch/arm/mach-
>> exynos/include/mach/map.h
>> index c72b675..217e470 100644
>> --- a/arch/arm/mach-exynos/include/mach/map.h
>> +++ b/arch/arm/mach-exynos/include/mach/map.h
>> @@ -121,6 +121,9 @@
>> #define EXYNOS4_PA_SYSMMU_MFC_L 0x1362
>> #define EXYNOS4_PA_SYSMMU_MFC_R 0x1363
>>
>> +/* x = 0...3 */
>> +#define EXYNOS5_PA_GSC(x)(0x13e0 + ((x) * 0x1))
>
> I think, separated definitions would be nice because the number of channel
> can be changed on other upcoming EXYNOS5 SoCs.
>
> +#define EXYNOS5_PA_GSC00x13E0
> +#define EXYNOS5_PA_GSC10x13E1
> +#define EXYNOS5_PA_GSC20x13E2
> +#define EXYNOS5_PA_GSC30x13E3
Ok. I will update as per your suggestion.
>
> [...]
>
> Thanks.
>
> Best regards,
> Kgene.
> --
> Kukjin Kim , Senior Engineer,
> SW Solution Development Team, Samsung Electronics Co., Ltd.
>
Thanks,
Shaik Ameer Basha
--
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/2] ARM: EXYNOS: Add clock support for Gscaler
Hi Kukjin Kim,
thanks for the review comments.
On Wed, Aug 1, 2012 at 11:54 AM, Kukjin Kim wrote:
> Shaik Ameer Basha wrote:
>>
>> Add required clock support for Gscaler for exynos5
>>
>> Signed-off-by: Abhilash Kesavan
>> Signed-off-by: Leela Krishna Amudala
>> Signed-off-by: Prathyush K
>> Signed-off-by: Shaik Ameer Basha
>> ---
>> arch/arm/mach-exynos/clock-exynos5.c | 100
>> ++
>> 1 files changed, 100 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-exynos/clock-exynos5.c b/arch/arm/mach-
>> exynos/clock-exynos5.c
>> index 774533c..49a76b1 100644
>> --- a/arch/arm/mach-exynos/clock-exynos5.c
>> +++ b/arch/arm/mach-exynos/clock-exynos5.c
>> @@ -552,6 +552,81 @@ static struct clksrc_clk exynos5_clk_aclk_66 = {
>> .reg_div = { .reg = EXYNOS5_CLKDIV_TOP0, .shift = 0, .size = 3 },
>> };
>>
>> +/* for aclk_300_gscl_mid */
>
> No need above comment which is certain.
>
Ok. I will remove all unnecessary comments.
>> +static struct clksrc_clk exynos5_clk_mout_aclk_300_gscl_mid = {
>> + .clk = {
>> + .name = "mout_aclk_300_gscl_mid",
>> + },
>> + .sources = &exynos5_clkset_aclk,
>> + .reg_src = { .reg = EXYNOS5_CLKSRC_TOP0, .shift = 24, .size = 1 },
>> +};
>> +
>> +/* for aclk_300_gscl_mid1 */
>
> Same as above.
>
>> +static struct clk *exynos5_clkset_aclk_300_gscl_mid1_list[] = {
>> + [0] = &exynos5_clk_sclk_vpll.clk,
>> + [1] = &exynos5_clk_mout_cpll.clk,
>> +};
>
> In this case, the above sources can be used for gscl_mid1 and disp1_mid as
> well. So how about exynos5_clkset_mid1_list?
yes. you are right.
I will change the name as per your suggestion. (i.e., exynos5_clkset_mid1_list)
>
>> +
>> +static struct clksrc_sources exynos5_clkset_aclk_300_gscl_mid1 = {
>> + .sources= exynos5_clkset_aclk_300_gscl_mid1_list,
>> + .nr_sources =
> ARRAY_SIZE(exynos5_clkset_aclk_300_gscl_mid1_list),
>> +};
>
> If so, need to update this.
Ok. I will update here too...
>
>> +
>> +
>
> no need double empty lines.
ok. will remove the extra lines.
>
>> +static struct clksrc_clk exynos5_clk_mout_aclk_300_gscl_mid1 = {
>> + .clk= {
>> + .name = "mout_aclk_300_gscl_mid1",
>> + },
>> + .sources = &exynos5_clkset_aclk_300_gscl_mid1,
>> + .reg_src = { .reg = EXYNOS5_CLKSRC_TOP1, .shift = 12, .size = 1 },
>> +};
>> +
>> +/* for aclk_300_gscl */
>
> no need useless comment.
>
>> +static struct clk *exynos5_clkset_aclk_300_gscl_list[] = {
>> + [0] = &exynos5_clk_mout_aclk_300_gscl_mid.clk,
>> + [1] = &exynos5_clk_mout_aclk_300_gscl_mid1.clk,
>> +};
>> +
>> +static struct clksrc_sources exynos5_clkset_aclk_300_gscl = {
>> + .sources= exynos5_clkset_aclk_300_gscl_list,
>> + .nr_sources = ARRAY_SIZE(exynos5_clkset_aclk_300_gscl_list),
>> +};
>> +
>> +static struct clksrc_clk exynos5_clk_mout_aclk_300_gscl = {
>> + .clk= {
>
> Tap please.
Ok. i will change that.
>
>> + .name = "mout_aclk_300_gscl",
>> + },
>> + .sources = &exynos5_clkset_aclk_300_gscl,
>> + .reg_src = { .reg = EXYNOS5_CLKSRC_TOP0, .shift = 25, .size = 1 },
>> +};
>> +
>> +static struct clksrc_clk exynos5_clk_dout_aclk_300_gscl = {
>> + .clk= {
>
> Same as above.
Ok. i will change that.
>
>> + .name = "dout_aclk_300_gscl",
>> + .parent = &exynos5_clk_mout_aclk_300_gscl.clk,
>> + },
>> + .reg_div = { .reg = EXYNOS5_CLKDIV_TOP1, .shift = 12, .size = 3 },
>> +};
>
> And I think, we don't need to define above 'clksrc_clk's?
>
Sorry. you are right. i will remove that.
> +static struct clksrc_clk exynos5_clk_mdout_aclk_300_gscl = {
> + .clk= {
> + .name = "mdout_aclk_300_gscl",
> + },
> + .sources = &exynos5_clkset_aclk_300_gscl,
> + .reg_src = { .reg = EXYNOS5_CLKSRC_TOP0, .shift = 25, .size = 1 },
>> + .reg_div = { .reg = EXYNOS5_CLKDIV_TOP1, .shift = 12, .size = 3 },
> +};
>
> [...]
>
> 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
