Re: RE: [PATCH 2/2] ARM: EXYNOS4: Add USB PHY initialization for device

[PANKAJ KUMAR DUBEY]

Title: Samsung Enterprise Portal mySingle



Hi Kukjin,
 
 
--- Original Message ---
Sender : Kukjin Kim E5/Senior Engineer/SW Solution Development Team/Samsung Electronics
Date : Aug 31, 2011 11:05 (GMT+05:00)
Title : RE: [PATCH 2/2] ARM: EXYNOS4: Add USB PHY initialization for device
 
Sachin Kamat wrote:> > From: Pankaj Dubey > > This patch modifies USB PHY initialization code so that USB host> and device can be initialized with the same function.> > Signed-off-by: Pankaj Dubey > Signed-off-by: Sachin Kamat > --->  arch/arm/mach-exynos4/include/mach/regs-pmu.h |2 +->  arch/arm/mach-exynos4/setup-usb-phy.c |  159 ---> ->  2 files changed, 107 insertions(+), 54 deletions(-)> > diff --git a/arch/arm/mach-exynos4/include/mach/regs-pmu.hb/arch/arm/mach-> exynos4/include/mach/regs-pmu.h> index cdf9b47..c4709f2 100644> --- a/arch/arm/mach-exynos4/include/mach/regs-pmu.h> +++ b/arch/arm/mach-exynos4/include/mach/regs-pmu.h> @@ -34,7 +34,7 @@>  #define S5P_WAKEUP_STAT> S5P_PMUREG(0x0600)>  #define S5P_EINT_WAKEUP_MASK> S5P_PMUREG(0x0604)>  #define S5P_WAKEUP_MASK> S5P_PMUREG(0x0608)> -> +#define S5P_USBDEVICE_PHY_CONTROL> S5P_PMUREG(0x0704)>  #define S5P_USBHOST_PHY_CONTROL> S5P_PMUREG(0x0708)>  #define S5P_USBHOST_PHY_ENABLE (1 << 0)> > diff --git a/arch/arm/mach-exynos4/setup-usb-phy.c b/arch/arm/mach-> exynos4/setup-usb-phy.c> index f4c944a..69878a1 100644> --- a/arch/arm/mach-exynos4/setup-usb-phy.c> +++ b/arch/arm/mach-exynos4/setup-usb-phy.c> @@ -21,51 +21,65 @@> >  int s5p_usb_phy_init(struct platform_device *pdev, int type)>  {> + struct clk *otg_clk, *usbhost_clk;> + struct clk *xusbxti_clk;> + u32 phyclk;> + u32 rstcon;> + int err;> + if ((type != S5P_USB_PHY_HOST) && (type != S5P_USB_PHY_DEVICE))> + return -EINVAL;> +> + otg_clk = clk_get(&pdev->dev, "otg");> + if (IS_ERR(otg_clk)) {> + dev_err(&pdev->dev, "Failed to get otg clock ");> + return PTR_ERR(otg_clk);> + }> +> + err = clk_enable(otg_clk);> + if (err) {> + clk_put(otg_clk);> + return err;> + }> +> + /* set clock frequency for PLL */> + phyclk = readl(EXYNOS4_PHYCLK) & ~CLKSEL_MASK;> +> + xusbxti_clk = clk_get(&pdev->dev, "xusbxti");> + if (xusbxti_clk && !IS_ERR(xusbxti_clk)) {> + switch (clk_get_rate(xusbxti_clk)) {> + case 12 * MHZ:> + phyclk |= CLKSEL_12M;> + break;> + case 24 * MHZ:> + phyclk |= CLKSEL_24M;> + break;> + default:> + case 48 * MHZ:> + /* default reference clock */> + break;> + }> + clk_put(xusbxti_clk);> + }> +> + writel(phyclk, EXYNOS4_PHYCLK);> +>   if (type == S5P_USB_PHY_HOST) {> - struct clk *otg_clk;> - struct clk *xusbxti_clk;> - u32 phyclk;> - u32 rstcon;> - int err;> -> - otg_clk = clk_get(&pdev->dev, "otg");> - if (IS_ERR(otg_clk)) {> - dev_err(&pdev->dev, "Failed to get otg clock ");> - return PTR_ERR(otg_clk);> + usbhost_clk = clk_get(&pdev->dev, "usbhost");> +> + if (IS_ERR(usbhost_clk)) {> + dev_err(&pdev->dev, "Failed to get usbhostclock ");> + return PTR_ERR(usbhost_clk);(Cc'ed Yulgon Kim and Kyoungil Kim)Hmm...I know, since the USB Host PHY Controller is included in the 'otg'clock domain the 'otg' clock is controlled here. But the USB Host clock iscontrolled in ehci-s5p driver now so we don't need to add this here.
---
Yes, you are correct, usb_host clock is not supposed to be handle here. I will re-submit this patch after correction.
--->   }> > - err = clk_enable(otg_clk);> + err = clk_enable(usbhost_clk);>   if (err) {> - clk_put(otg_clk);> + clk_put(usbhost_clk);>   return err;>   }> >   writel(readl(S5P_USBHOST_PHY_CONTROL) |> S5P_USBHOST_PHY_ENABLE,>   S5P_USBHOST_PHY_CONTROL);> > - /* set clock frequency for PLL */> - phyclk = readl(EXYNOS4_PHYCLK) & ~CLKSEL_MASK;> -> - xusbxti_clk = clk_get(&pdev->dev, "xusbxti");> - if (xusbxti_clk && !IS_ERR(xusbxti_clk)) {> - switch (clk_get_rate(xusbxti_clk)) {> - case 12 * MHZ:> - phyclk |= CLKSEL_12M;> - break;> - case 24 * MHZ:> - phyclk |= CLKSEL_24M;> - break;> - default:> - case 48 * MHZ:> - /* default reference clock */> - break;> - }> - clk_put(xusbxti_clk);> - }> -> - writel(phyclk, EXYNOS4_PHYCLK);> -> - /* floating prevention logic: disable */>   writel((readl(EXYNOS4_PHY1CON) | FPENABLEN),> EXYNOS4_PHY1CON);> >   /* set to normal HSIC 0 and 1 of PHY1 */> @@ -84,30 +98,61 @@ int s5p_usb_phy_init(struct platform_device *pdev,int type)> >   rstcon &= ~(HOST_LINK_PORT_SWRST_MASK |> PHY1_SWRST_MASK);>   writel(rstcon, EXYNOS4_RSTCON);> - udelay(80);> + } else if (type == S5P_USB_PHY_DEVICE) {> + writel(readl(S5P_USBDEVICE_PHY_CONTROL) | (0x1<<0),> + S5P_USBDEVICE_PHY_CONTROL);> + writel((readl(EXYNOS4_PHYPWR) & ~(0x7<<3)&~(0x1<<0)),> + EXYNOS4_PHYPWR);> + writel((readl(EXYNOS4_PHYCLK) & ~(0x5<<2))|(0x3<<0),> + EXYNOS4_PHYCLK);> + writel((readl(EXYNOS4_RSTCON) & ~(0x3<<1))|(0x1<<0),> + EXYNOS4_RSTCON);> + udelay(10);> + writel(readl(EXYNOS4_RSTCON) & ~(0x7<<0),> + EXYNOS4_RSTCON);> + }> + udelay(80);> > - clk_disable(otg_clk);> - clk_put(otg_clk);> + clk_disable(otg_clk);> + clk_put(otg_clk);> + if (ty

Re: RE: [PATCH 1/2] ARM: EXYNOS4: Code cleanup and remove extra functions.

[PANKAJ KUMAR DUBEY]

Title: Samsung Enterprise Portal mySingle



Hi Kukjin,
 
--- Original Message ---
Sender : Kukjin Kim E5/Senior Engineer/SW Solution Development Team/Samsung Electronics
Date : Aug 31, 2011 10:42 (GMT+05:00)
Title : RE: [PATCH 1/2] ARM: EXYNOS4: Code cleanup and remove extra functions.
 
Sachin Kamat wrote:> > From: Pankaj Dubey > > This patch removes the intermediate exynos4_usb_phy1_init and> exynos4_usb_phy1_exit function calls.> > Signed-off-by: Pankaj Dubey > Signed-off-by: Sachin Kamat > --->  arch/arm/mach-exynos4/setup-usb-phy.c |  166 +++->  1 files changed, 78 insertions(+), 88 deletions(-)> > diff --git a/arch/arm/mach-exynos4/setup-usb-phy.c b/arch/arm/mach-> exynos4/setup-usb-phy.c> index 39aca04..f4c944a 100644> --- a/arch/arm/mach-exynos4/setup-usb-phy.c> +++ b/arch/arm/mach-exynos4/setup-usb-phy.c> @@ -19,118 +19,108 @@>  #include >  #include > > -static int exynos4_usb_phy1_init(struct platform_device *pdev)> +int s5p_usb_phy_init(struct platform_device *pdev, int type)>  {> - struct clk *otg_clk;> - struct clk *xusbxti_clk;> - u32 phyclk;> - u32 rstcon;> - int err;> -> - otg_clk = clk_get(&pdev->dev, "otg");> - if (IS_ERR(otg_clk)) {> - dev_err(&pdev->dev, "Failed to get otg clock ");> - return PTR_ERR(otg_clk);> - }> + if (type == S5P_USB_PHY_HOST) {> + struct clk *otg_clk;> + struct clk *xusbxti_clk;> + u32 phyclk;> + u32 rstcon;> + int err;> +> + otg_clk = clk_get(&pdev->dev, "otg");> + if (IS_ERR(otg_clk)) {> + dev_err(&pdev->dev, "Failed to get otg clock ");> + return PTR_ERR(otg_clk);> + }> > - err = clk_enable(otg_clk);> - if (err) {> - clk_put(otg_clk);> - return err;> - }> + err = clk_enable(otg_clk);> + if (err) {> + clk_put(otg_clk);> + return err;> + }> > - writel(readl(S5P_USBHOST_PHY_CONTROL) |> S5P_USBHOST_PHY_ENABLE,> + writel(readl(S5P_USBHOST_PHY_CONTROL) |> S5P_USBHOST_PHY_ENABLE,>   S5P_USBHOST_PHY_CONTROL);> > - /* set clock frequency for PLL */> - phyclk = readl(EXYNOS4_PHYCLK) & ~CLKSEL_MASK;> -> - xusbxti_clk = clk_get(&pdev->dev, "xusbxti");> - if (xusbxti_clk && !IS_ERR(xusbxti_clk)) {> - switch (clk_get_rate(xusbxti_clk)) {> - case 12 * MHZ:> - phyclk |= CLKSEL_12M;> - break;> - case 24 * MHZ:> - phyclk |= CLKSEL_24M;> - break;> - default:> - case 48 * MHZ:> - /* default reference clock */> - break;> - }> + /* set clock frequency for PLL */> + phyclk = readl(EXYNOS4_PHYCLK) & ~CLKSEL_MASK;> +> + xusbxti_clk = clk_get(&pdev->dev, "xusbxti");> + if (xusbxti_clk && !IS_ERR(xusbxti_clk)) {> + switch (clk_get_rate(xusbxti_clk)) {> + case 12 * MHZ:> + phyclk |= CLKSEL_12M;> + break;> + case 24 * MHZ:> + phyclk |= CLKSEL_24M;> + break;> + default:> + case 48 * MHZ:> + /* default reference clock */> + break;> + }>   clk_put(xusbxti_clk);> - }> + }> > - writel(phyclk, EXYNOS4_PHYCLK);> + writel(phyclk, EXYNOS4_PHYCLK);> > - /* floating prevention logic: disable */> - writel((readl(EXYNOS4_PHY1CON) | FPENABLEN),> EXYNOS4_PHY1CON);> + /* floating prevention logic: disable */> + writel((readl(EXYNOS4_PHY1CON) | FPENABLEN),> EXYNOS4_PHY1CON);> > - /* set to normal HSIC 0 and 1 of PHY1 */> - writel((readl(EXYNOS4_PHYPWR) & ~PHY1_HSIC_NORMAL_MASK),> + /* set to normal HSIC 0 and 1 of PHY1 */> + writel((readl(EXYNOS4_PHYPWR) &> ~PHY1_HSIC_NORMAL_MASK),>   EXYNOS4_PHYPWR);> > - /* set to normal standard USB of PHY1 */> - writel((readl(EXYNOS4_PHYPWR) & ~PHY1_STD_NORMAL_MASK),> EXYNOS4_PHYPWR);> + /* set to normal standard USB of PHY1 */> + writel((readl(EXYNOS4_PHYPWR) &> ~PHY1_STD_NORMAL_MASK),> + EXYNOS4_PHYPWR);> > - /* reset all ports of both PHY and Link */> - rstcon = readl(EXYNOS4_RSTCON) | HOST_LINK_PORT_SWRST_MASK |> - PHY1_SWRST_MASK;> - writel(rstcon, EXYNOS4_RSTCON);> - udelay(10);> + /* reset all ports of both PHY and Link */> + rstcon = readl(EXYNOS4_RSTCON) |> HOST_LINK_PORT_SWRST_MASK |> + PHY1_SWRST_MASK;> + writel(rstcon, EXYNOS4_RSTCON);> + udelay(10);> > - rstcon &= ~(HOST_LINK_PORT_SWRST_MASK | PHY1_SWRST_MASK);> - writel(rstcon, EXYNOS4_RSTCON);> - udelay(80);> + rstcon &= ~(HOST_LINK_PORT_SWRST_MASK |> PHY1_SWRST_MASK);> + writel(rstcon, EXYNOS4_RSTCON);> + udelay(80);> > - clk_disable(otg_clk);> - clk_put(otg_clk);> + clk_disable(otg_clk);> + clk_put(otg_clk);> > - return 0;> + return 0;> + }> + return -EINVAL;>  }> > -static int exynos4_usb_phy1_exit(struct platform_device *pdev)> +int s5p_usb_phy_exit(struct platform_device *pdev, int type)>  {> - struct clk *otg_clk;> - int err;> -> - otg_clk = clk_get(&pdev->dev, "otg");> - if (IS_ERR(otg_clk)) {> - dev_err(&pdev->dev, "Failed to get otg clock ");> - return PTR_ERR(otg_clk);> - }> + if (type == S5P_USB_PHY_HOST) {> + struct clk *otg_clk;> + int err;> + otg_clk = clk_get(&pdev->dev, "otg");> + if (IS_ERR(otg_clk)) {> + dev_err(&pdev->dev, "Failed to get otg clock ");> + return PTR_ERR(otg_clk);> + }> > - err = clk_enable(otg_clk);> - if (err) {> - clk_put(otg_clk);> - return err;> - }> + err = clk_enable(otg_clk);> + if (err) {> + clk_put(otg_clk);> + retu

Re: ARM CPU part numbers

[David Brown]

On Thu, Sep 01, 2011 at 10:40:27AM +0100, Andrew Stubbs wrote:

> I'm currently trying to get GCC to auto-detect what CPU to optimize
> for by finding out what CPU it's actually running on (the user would
> only have to pass -mcpu=native). It does this simply by reading
> /proc/cpuinfo.
> 
> The problem is finding what magic numbers correspond to what CPU.
> I've found the numbers for A8 and A9 empirically, but I'd like a
> longer list than that!
> 
> Does anybody have a list of such numbers?
> 
> Or else, perhaps people could just post any number they happen to know?

/proc/cpuinfo on the three Qualcomm MSM platforms I have convenient
gives:

The Hardware string on the last one is my device tree work, it's on an
MSM8660 FLUID
(http://www.bsquare.com/snapdragon-mobile-development-platform.aspx)

--
Processor   : ARMv7 Processor rev 1 (v7l)
processor   : 0
BogoMIPS: 13.53

processor   : 1
BogoMIPS: 13.53

Features: swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x04d
CPU revision: 1

Hardware: QCT MSM8960 CDP
Revision: 
Serial  : 
--
Processor   : ARMv7 Processor rev 1 (v7l)
BogoMIPS: 191.69
Features: swp half thumb fastmult vfp edsp neon vfpv3
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part: 0xc05
CPU revision: 1

Hardware: QCT MSM9615 CDP
Revision: 
Serial  : 
--
Processor   : ARMv7 Processor rev 2 (v7l)
processor   : 0
BogoMIPS: 501.35

processor   : 1
BogoMIPS: 209.30

Features: swp half thumb fastmult vfp edsp neon tls
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x0
CPU part: 0x02d
CPU revision: 2

Hardware: Qualcomm MSM (Flattened Device Tree)
Revision: 
Serial  : 
--

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: 11.08 Pre-built Images

[Anca Emanuel]

Is there an tutorial to install qemu in ubuntu and run some linaro image ?

I want to test it.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN

[Tushar Behera]

Hi Kukjin,

On Wednesday 31 August 2011 06:31 AM, Kukjin Kim wrote:

Tushar Behera wrote:


Platform data for SDHCI controller on ORIGEN board is missing the
support for 8-bit bus width. The platform data is extended in sync
with other EXYNOS4 machines.

Signed-off-by: Tushar Behera
---
  arch/arm/mach-exynos4/mach-origen.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/mach-origen.c

b/arch/arm/mach-exynos4/mach-

origen.c
index ae18812..6b6cd77 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]

__initdata =

{
  static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
  };

  static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
+   .max_width  = 8,
+   .host_caps  = MMC_CAP_8_BIT_DATA,
+#endif
  };

  static struct platform_device *origen_devices[] __initdata = {
--
1.7.4.1


Hi Tushar,

I wonder the bus width of SDHCI controller can be changed manually on ORIGEN
like SMDK board.


I will do further test and update you about the results.


Thanks.

Best regards,
Kgene.
--
Kukjin Kim, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.




--
Tushar Behera

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN

[Tushar Behera]

Hi Kukjin,

On Wednesday 31 August 2011 06:23 AM, Kukjin Kim wrote:

Tushar Behera wrote:

-Original Message-
From: Tushar Behera [mailto:tushar.beh...@linaro.org]
Sent: Friday, August 26, 2011 6:39 PM
To: linux-samsung-...@vger.kernel.org
Cc: linaro-dev@lists.linaro.org; kgene@samsung.com; patc...@linaro.org
Subject: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on
ORIGEN

Secondary MMC port on ORIGEN is connected to sdhci instance 0. Support
for secondary MMC port is extended by registering sdhci instance 0.

Since sdhci instance 2 can contain a bootable media, sdhci instance 0
is registered after instance 2.


Would be helpful if above comments could be included in codes :)


Signed-off-by: Tushar Behera
---
  arch/arm/mach-exynos4/Kconfig   |1 +
  arch/arm/mach-exynos4/mach-origen.c |7 +++
  2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index e6925de..4c14d5e 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -229,6 +229,7 @@ config MACH_ORIGEN
select CPU_EXYNOS4210
select S3C_DEV_RTC
select S3C_DEV_WDT
+   select S3C_DEV_HSMMC
select S3C_DEV_HSMMC2
select EXYNOS4_SETUP_SDHCI
help
diff --git a/arch/arm/mach-exynos4/mach-origen.c

b/arch/arm/mach-exynos4/mach-

origen.c
index e280270..ae18812 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -72,6 +72,11 @@ static struct s3c2410_uartcfg origen_uartcfgs[]

__initdata = {

},
  };

+static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
+   .cd_type= S3C_SDHCI_CD_INTERNAL,
+   .clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
+};
+
  static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type   = S3C_SDHCI_CLK_DIV_EXTERNAL,
@@ -79,6 +84,7 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {

  static struct platform_device *origen_devices[] __initdata = {
&s3c_device_hsmmc2,
+   &s3c_device_hsmmc0,
&s3c_device_rtc,
&s3c_device_wdt,
  };
@@ -93,6 +99,7 @@ static void __init origen_map_io(void)
  static void __init origen_machine_init(void)
  {
s3c_sdhci2_set_platdata(&origen_hsmmc2_pdata);
+   s3c_sdhci0_set_platdata(&origen_hsmmc0_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
  }

--
1.7.4.1


OK, will apply.
If you don't mind, I will add comments the reason of the ordering when I
apply this.


Thanks. That would be great.


Thanks.

Best regards,
Kgene.
--
Kukjin Kim, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.




--
Tushar Behera

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[James Westby]

On Thu, 1 Sep 2011 17:54:55 -0500, Zach Pfeffer  wrote:
> On 1 September 2011 17:21, James Westby  wrote:
> > On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer  
> > wrote:
> >> We've had two instances of this problem for all the builds we've ever
> >> done. One instance was trying to sync u-boot and the other was trying
> >> to sync the TI LT kernel. John Rigby suggested the branch approach and
> >> it seems to have worked, so I'd like to go with that.
> >
> > Paul is working on a change to make tags usable as well. It seems to me
> > that we have a couple of options
> >
> >  1) Use branches long term. Paul can continue to push the patch for
> >  correctness sake, but we don't plan to use it.
> 
> #1 because from what I can see, that is more inline with the original
> repo vision, if Paul's change gets in and makes people rethink things
> than I think that'll be great!

Ok, then I guess that leaves Andy unhappy, but I think everyone has a
clearer picture of the current situation and the plans now.

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] RFCv2: video support for dri2

[Rob Clark]

On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton  wrote:
> On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark  wrote:
>> To allow the potential use of overlays to display video content, a few
>> extra parameters are required:
>>
>>  + source buffer in different format (for example, various YUV formats)
>>   and size as compared to destination drawable
>>  + multi-planar formats where discontiguous buffers are used for
>>   different planes.  For example, luma and chroma split across
>>   multiple memory banks or with different tiled formats.
>>  + flipping between multiple back buffers, perhaps not in order (to
>>   handle video formats with B-frames)
>>  + cropping during swap.. in case of video, perhaps the required hw
>>   buffers are larger than the visible picture to account for codec
>>   borders (for example, reference frames where a block/macroblock
>>   moves past the edge of the visible picture, but back again in
>>   subsequent frames).
>>
>> Current solutions use the GPU to do a scaled/colorconvert into a DRI2
>> buffer from the client context.  The goal of this protocol change is
>> to push the decision to use overlay or GPU blit to the xorg driver.
>>
>> In many cases, an overlay will avoid several passes through memory
>> (blit/scale/colorconvert to DRI back-buffer on client side, blit to
>> front and fake-front, and then whatever compositing is done by the
>> window manager).  On the other hand, overlays can often be handled
>> directly by the scanout engine in the display hardware, with the GPU
>> switched off.
>>
>> The disadvantages of overlays are that they are (usually) a limited
>> resource, sometimes with scaling constraints, and certainly with
>> limitations about transformational effects.
>>
>> The goal of combining video and dri2 is to have the best of both worlds,
>> to have the flexibility of GPU blitting (ie. no limited number of video
>> ports, no constraint about transformational effects), while still having
>> the power consumption benefits of overlays (reduced memory bandwidth
>> usage and ability to shut off the GPU) when the UI is relatively
>> static other than the playing video.
>>
>> Note: video is not exactly the same as 3d, there are a number of other
>> things to consider (scaling, colorconvert, multi-planar formats).  But
>> on the other hand the principle is similar (direct rendering from hw
>> video codecs).  And a lot infrastructure of connection, authentication,
>> is same.  So there are two options, either extend DRI2 or add a new
>> protocol which duplicates some parts.  I'd like to consider extending
>> DRI2 first, but if people think the requirements for video are too
>> much different from 3d, then I could split this into a new protocol.
>
> ...
>
>> +┌───
>> +    DRI2SetAttribute
>> +       drawable: DRAWABLE
>> +       attribute: ATOM
>> +       value: INT32
>> +      ▶
>> +└───
>> +       Errors: Window, Match, Value
>> +
>> +       The DRI2SetAttribute request sets the value of a drawable attribute.
>> +       The drawable attribute is identified by the attribute atom.  The
>> +       following strings are guaranteed to generate valid atoms using the
>> +       InternAtom request.
>> +
>> +       String                Type
>> +       -
>> +
>> +       "XV_ENCODING"         ENCODINGID
>> +       "XV_HUE"              [-1000..1000]
>> +       "XV_SATURATION"       [-1000..1000]
>> +       "XV_BRIGHTNESS"       [-1000..1000]
>> +       "XV_CONTRAST"         [-1000..1000]
>> +       "XV_WIDTH"            [0..MAX_INT]
>> +       "XV_HEIGHT"           [0..MAX_INT]
>> +       "XV_OSD"              XID
>> +
>> +       If the given attribute doesn't match an attribute supported by the
>> +       drawable a Match error is generated.  The supplied encoding
>> +       must be one of the encodings listed for the adaptor, otherwise an
>> +       Encoding error is generated.
>> +
>> +       If the adaptor doesn't support the exact hue, saturation,
>> +       brightness, and contrast levels supplied, the closest levels
>> +       supported are assumed.  The DRI2GetAttribute request can be used
>> +       to query the resulting levels.
>> +
>> +       The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating
>> +       that no scaling is performed and the buffer sizes match the drawable
>> +       size.  They can be overriden by the client if scaling is desired.
>> +
>> +       The "XV_OSD" attribute specifies the XID of a pixmap containing
>> +       ARGB data to be non-destructively overlayed over the video.  This
>> +       could be used to implement subtiles, on-screen-menus, etc.
>> +
>> + :     TODO: Is there a need to support DRI2SetAttribute for non-video
>> + :     DRI2DRIVER types?
>> + :
>> + :     TODO: Do we need to keep something like PortNotify.. if attributes
>> + :     are only changing in response to DRI2SetAttribute from the client,
>> + :     then having a PortNotify like mechanism seem

Re: Choosing the timer to use in benchmarking

[Michael Hope]

On Fri, Sep 2, 2011 at 10:56 AM, John Stultz  wrote:
> On Wed, 2011-08-31 at 07:43 +1200, Michael Hope wrote:
>> I was quite impressed with how steady the process clock was under
>> different CPU loads.  It doesn't seem to round up or down to a
>> scheduler tick either which is nice.
>
> Hmm. Very interesting results! Its been a little while since I've looked
> into the cpu time accounting, but I'd be hesitant to trust that it has
> finer then HZ granularity everywhere. I know that has been an issue in
> the past. I'll have to look into it.

I was wondering the same and had a play with it as part of the
exercise.  Plotted the clock time for differing numbers of loop and
didn't see the staircasing effect you'd expect if the time was rounded
to the nearest scheduler tick.

I also had a look at the delta between each run and the standard
deviation was nice and low - around 50 us.

-- Michael

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Choosing the timer to use in benchmarking

[John Stultz]

On Wed, 2011-08-31 at 07:43 +1200, Michael Hope wrote:
> I was quite impressed with how steady the process clock was under
> different CPU loads.  It doesn't seem to round up or down to a
> scheduler tick either which is nice.

Hmm. Very interesting results! Its been a little while since I've looked
into the cpu time accounting, but I'd be hesitant to trust that it has
finer then HZ granularity everywhere. I know that has been an issue in
the past. I'll have to look into it.

thanks
-john



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Zach Pfeffer]

On 1 September 2011 17:21, James Westby  wrote:
> On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer  
> wrote:
>> We've had two instances of this problem for all the builds we've ever
>> done. One instance was trying to sync u-boot and the other was trying
>> to sync the TI LT kernel. John Rigby suggested the branch approach and
>> it seems to have worked, so I'd like to go with that.
>
> Paul is working on a change to make tags usable as well. It seems to me
> that we have a couple of options
>
>  1) Use branches long term. Paul can continue to push the patch for
>  correctness sake, but we don't plan to use it.

#1 because from what I can see, that is more inline with the original
repo vision, if Paul's change gets in and makes people rethink things
than I think that'll be great!

>  2) Use branches for now. Paul fixes repo to make tags usable, at which
>  point we allow people (e.g. Andy) to use those too.
>
> Which would you advocate?
>
> Thanks,
>
> James
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] RFCv2: video support for dri2

[Younes Manton]

On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark  wrote:
> To allow the potential use of overlays to display video content, a few
> extra parameters are required:
>
>  + source buffer in different format (for example, various YUV formats)
>   and size as compared to destination drawable
>  + multi-planar formats where discontiguous buffers are used for
>   different planes.  For example, luma and chroma split across
>   multiple memory banks or with different tiled formats.
>  + flipping between multiple back buffers, perhaps not in order (to
>   handle video formats with B-frames)
>  + cropping during swap.. in case of video, perhaps the required hw
>   buffers are larger than the visible picture to account for codec
>   borders (for example, reference frames where a block/macroblock
>   moves past the edge of the visible picture, but back again in
>   subsequent frames).
>
> Current solutions use the GPU to do a scaled/colorconvert into a DRI2
> buffer from the client context.  The goal of this protocol change is
> to push the decision to use overlay or GPU blit to the xorg driver.
>
> In many cases, an overlay will avoid several passes through memory
> (blit/scale/colorconvert to DRI back-buffer on client side, blit to
> front and fake-front, and then whatever compositing is done by the
> window manager).  On the other hand, overlays can often be handled
> directly by the scanout engine in the display hardware, with the GPU
> switched off.
>
> The disadvantages of overlays are that they are (usually) a limited
> resource, sometimes with scaling constraints, and certainly with
> limitations about transformational effects.
>
> The goal of combining video and dri2 is to have the best of both worlds,
> to have the flexibility of GPU blitting (ie. no limited number of video
> ports, no constraint about transformational effects), while still having
> the power consumption benefits of overlays (reduced memory bandwidth
> usage and ability to shut off the GPU) when the UI is relatively
> static other than the playing video.
>
> Note: video is not exactly the same as 3d, there are a number of other
> things to consider (scaling, colorconvert, multi-planar formats).  But
> on the other hand the principle is similar (direct rendering from hw
> video codecs).  And a lot infrastructure of connection, authentication,
> is same.  So there are two options, either extend DRI2 or add a new
> protocol which duplicates some parts.  I'd like to consider extending
> DRI2 first, but if people think the requirements for video are too
> much different from 3d, then I could split this into a new protocol.

...

> +┌───
> +    DRI2SetAttribute
> +       drawable: DRAWABLE
> +       attribute: ATOM
> +       value: INT32
> +      ▶
> +└───
> +       Errors: Window, Match, Value
> +
> +       The DRI2SetAttribute request sets the value of a drawable attribute.
> +       The drawable attribute is identified by the attribute atom.  The
> +       following strings are guaranteed to generate valid atoms using the
> +       InternAtom request.
> +
> +       String                Type
> +       -
> +
> +       "XV_ENCODING"         ENCODINGID
> +       "XV_HUE"              [-1000..1000]
> +       "XV_SATURATION"       [-1000..1000]
> +       "XV_BRIGHTNESS"       [-1000..1000]
> +       "XV_CONTRAST"         [-1000..1000]
> +       "XV_WIDTH"            [0..MAX_INT]
> +       "XV_HEIGHT"           [0..MAX_INT]
> +       "XV_OSD"              XID
> +
> +       If the given attribute doesn't match an attribute supported by the
> +       drawable a Match error is generated.  The supplied encoding
> +       must be one of the encodings listed for the adaptor, otherwise an
> +       Encoding error is generated.
> +
> +       If the adaptor doesn't support the exact hue, saturation,
> +       brightness, and contrast levels supplied, the closest levels
> +       supported are assumed.  The DRI2GetAttribute request can be used
> +       to query the resulting levels.
> +
> +       The "XV_WIDTH" and "XV_HEIGHT" attributes default to zero, indicating
> +       that no scaling is performed and the buffer sizes match the drawable
> +       size.  They can be overriden by the client if scaling is desired.
> +
> +       The "XV_OSD" attribute specifies the XID of a pixmap containing
> +       ARGB data to be non-destructively overlayed over the video.  This
> +       could be used to implement subtiles, on-screen-menus, etc.
> +
> + :     TODO: Is there a need to support DRI2SetAttribute for non-video
> + :     DRI2DRIVER types?
> + :
> + :     TODO: Do we need to keep something like PortNotify.. if attributes
> + :     are only changing in response to DRI2SetAttribute from the client,
> + :     then having a PortNotify like mechanism seems overkill.  The 
> assumption
> + :     here is that, unlike Xv ports, DRI2 video drawables are not a limited
> + :     resource (ie. if you run out of (or

Re: Tracking Android kernel tips and Android builds

[James Westby]

On Thu, 1 Sep 2011 17:10:03 -0500, Zach Pfeffer  wrote:
> We've had two instances of this problem for all the builds we've ever
> done. One instance was trying to sync u-boot and the other was trying
> to sync the TI LT kernel. John Rigby suggested the branch approach and
> it seems to have worked, so I'd like to go with that.

Paul is working on a change to make tags usable as well. It seems to me
that we have a couple of options

  1) Use branches long term. Paul can continue to push the patch for
  correctness sake, but we don't plan to use it.

  2) Use branches for now. Paul fixes repo to make tags usable, at which
  point we allow people (e.g. Andy) to use those too.

Which would you advocate?

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Zach Pfeffer]

On 1 September 2011 17:04, James Westby  wrote:
> On Thu, 1 Sep 2011 16:51:25 -0500, Zach Pfeffer  
> wrote:
>> Anyhow, we have a few ways to solve this issue. I would say that as
>> long as we reference trees whose shas are reachable from the branches
>> in the remote git, then we should be fine. From a manifest
>> perspective, we like to sync a tip branch, once the build is completed
>> the sha will be the tip of that tip branch, as long as that sha sticks
>> around in another branch in the repo everything should work.
>
> Andy's question earlier in this threads was whether we had to use
> branches here. It seems you are saying that we are going to use
> branches?

We've had two instances of this problem for all the builds we've ever
done. One instance was trying to sync u-boot and the other was trying
to sync the TI LT kernel. John Rigby suggested the branch approach and
it seems to have worked, so I'd like to go with that.

> Thanks,
>
> James
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[James Westby]

On Thu, 1 Sep 2011 16:51:25 -0500, Zach Pfeffer  wrote:
> Anyhow, we have a few ways to solve this issue. I would say that as
> long as we reference trees whose shas are reachable from the branches
> in the remote git, then we should be fine. From a manifest
> perspective, we like to sync a tip branch, once the build is completed
> the sha will be the tip of that tip branch, as long as that sha sticks
> around in another branch in the repo everything should work.

Andy's question earlier in this threads was whether we had to use
branches here. It seems you are saying that we are going to use
branches?

Thanks,

James

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ACTIVITY] Kernel WG Weekly Status report for week ending 2011-09-02

[Mounir Bsaibes]

Enclosed  please find the link to the Weekly Status report
for the kernel  working group for the week ending 2011-08-26.

== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/Kernel/Meetings/2011-08-29

== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/Kernel/Status/2011-09-01

== Summary, for details see the Status Report ==
 * New kernel process overview doc is being drafted
https://docs.google.com/a/linaro.org/document/d/19bqP5akuMCEohb5Ko94emUWBVgk6I83noBELV8jcWLg/edit?pli=1
 * Submitted pl330 DMA driver device tree support patches for review.
 * Samsung's uart irq handling patches that move irq handling from platform
code to driver is accepted in Greg's tty tree.
 * Brought up i.mx6q SMP support
* Added the support of ARM Dormant/Shutdown mode on i.mx6q
* A v3.1-rc2 and device tree based kernel is running on i.mx6q
  * i.MX code clean up and consolidation: patch-set has been merged to soc
tree.
  * Pushed out v5 of the pinctrl/pinmux subsystem
  * The bulk of gpio.h cleanup patches have been merged
  * John Stultz Implemented the proposed config tooling for config
fragments, as will be presented at Plumbers conference
  * Posted kprobes test code to the linux-arm-kernel list.
  * Improved flash performance use case an simulation programs to provide
details of timings so that simulation accuracy can be mor easily judged.
  * Submitted  patches   "Remove define CONSISTENT_DMA_SIZE" were pulled by
RMK for inclusion in Linux 3.2.
  * Rebased and resubmitted a patch to get rid of a few StrongARM
cache-related build time constants (prerequisite to another patch  series
removing most instances of )


Best regards,
Mounir


-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
http://twitter.com/#!/linaroorg
http://www.linaro.org/linaro-blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Zach Pfeffer]

On 1 September 2011 05:59, Christian Robottom Reis  wrote:
> On Tue, Aug 30, 2011 at 11:13:08AM -0500, Zach Pfeffer wrote:
>> > Any other issues that I've missed? Where should we come down in this case?
>>
>> I say we stay the course and fix the issue of sha's disappearing. I
>> feel this way because its:
>>
>> 1. Technically feasible in the short term.
>> 2. Saves the substantial burden of redirecting to the user.
>> 3. Supports the only way that you can guarantee 100% build fidelity.
>
> Can you restate "fix the issue of sha's [sic] disappearing" in a way
> which I can understand? As far as I know, the actual problem is that
> repo isn't fetching all tags.
>
> Or are you describing the symptom as seen from the build system? Because
> my suggestion (ship a forked repo temporarily) would address that.

Here's the symptom. Android uses a tool called repo to fetch all the
source code in a project. repo reads a manifest file that lists each
git it needs to clone. The syntax used to specify the git includes a
feature that allows you to fetch a branch, tag or specific revision.
An example of an entry of this manifest file that fetches a particular
branch is:




We use this for our tip builds.

An example that fetches a particular revision is:




We use entries like this for our release builds.

We do this because the sha1 allows for the exact state of the git to
be checked out. Its better than a tag or a branch because both are
moveable and the tags tend to pileup. Its also very easy to create a
"pinned-manifest" that just lists each sha; you can do it in
automation, and you don't have to write the tags back to the subgits
which you may not control.

The pinned-manifest.xml allows a user to create a build that what we
built exactly; this is useful if someone is trying to bisect a bug on
the exact version of a build or they want to perform an experiment on
the exact version.

Developers who just want to work on tip, which is most developers, can
just pull the manifest that tracks a particular branch. Developers are
encouraged to just use tip since the pinned-manifests may not reflect
the current build state.

When I sync a build using the pinned-manifest.xml then I essentially
do a for each git in manifest x operation. If the sha doesn't exist
the repo sync fails and the user has to start over from scratch.

Why would a sha disappear?

git-gc handles clean up of unreachable objects. git-gc
(http://www.kernel.org/pub/software/scm/git/docs/v1.7.6.1/git-gc.html)

Commits that are reachable from (taken from man):

Objects referenced by your current set of branches and tags
Objects referenced by the index
Remote-tracking branches
Refs saved by git filter-branch in refs/original/
Reflogs (which may reference commits in branches that were later
amended or rewound).

So then what happens in a typical repo init, repo sync

People who want to use a pinned-manifest.xml will run something like:

repo init -u git://git.linaro.org/android/platform/manifests.git -b
linaro-android-11.08-release -m LEB-panda.xml
repo sync

Prefix both with REPO_TRACE=1 to see exactly what git commands get executed.

We create release builds using the pinned-manifest.xml since we want
to reproduce the builds exactly. Again we use the sha's because we may
not be able to lay a tag on a git we don't own.

under the covers repo sync is doing a few things (see REPO_TRACE=1 for
the whole list), but it basically comes down to:

For each git:
git init
git fetch
git pack-refs
git update-ref (sha should be valid, points HEAD to branch head or sha)

For each git
git gc, to save space

For each git
git read-tree ..., to bring the tree up-to-date

So repo is really doing a good job. Its saving space by getting rid of
things, limiting disk-space usage, etc...and is really just using some
low level git commands to accomplish its job.

Anyhow, we have a few ways to solve this issue. I would say that as
long as we reference trees whose shas are reachable from the branches
in the remote git, then we should be fine. From a manifest
perspective, we like to sync a tip branch, once the build is completed
the sha will be the tip of that tip branch, as long as that sha sticks
around in another branch in the repo everything should work.

> --
> Christian Robottom Reis   | [+55 16] 3376 0125 | http://launchpad.net/~kiko
> Canonical Ltd.            | [+55 16] 9112 6430 | http://async.com.br/~kiko
>

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Stubbs, Andrew]

On 01/09/11 12:02, Pawel Moll wrote:
>> If you search the specs on http://infocenter.arm.com for "Main ID
>> register" you should get all the numbers you wish for :-)
>
> Apparently it's called "ID Code Register" for ARM9 and the expected (not
> tested ;-) values would be:

Thanks Paweł, this is exactly the sort of thing I was looking for.

Andrew
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [U-Boot] [PATCH] s5p-mmc: Fix ambiguous setting of data transfer width

[Andy Fleming]

On Tue, Aug 30, 2011 at 5:55 AM, Chander Kashyap
 wrote:
> mmc data transfer width is set as following:
> WIDE8[5]:
> 0 = Depend on WIDE4
> 1 = 8-bit mode
> WIDE4[1]:
> 1 = 4-bit mode
> 0 = 1-bit mode
>
> In case of 4-bit mode reset 8-bit mode and
> in case of 1-bit mode reset 8-bit mode and 4-bit mode
>
> Signed-off-by: Chander Kashyap 
> ---
>  drivers/mmc/s5p_mmc.c |   10 +++---
>  1 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/s5p_mmc.c b/drivers/mmc/s5p_mmc.c
> index 7786ecf..6e6ad08 100644
> --- a/drivers/mmc/s5p_mmc.c
> +++ b/drivers/mmc/s5p_mmc.c
> @@ -368,12 +368,16 @@ static void mmc_set_ios(struct mmc *mmc)
>         * 1 = 4-bit mode
>         * 0 = 1-bit mode
>         */
> -       if (mmc->bus_width == 8)
> +       if (mmc->bus_width == 8) {
>                ctrl |= (1 << 5);
> -       else if (mmc->bus_width == 4)
> +               ctrl &= ~(1 << 1);


I know these were like this before, but those numbers are awfully
magical. You should really define constants for them.

Also, this seems like a very confusing way to do this? Why not clear
both bits at the start, and then set the one that is needed?

Andy

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux

[Stephen Warren]

Linus Walleij wrote at Thursday, September 01, 2011 3:33 AM:
> This adds a driver for the U300 pinmux portions of the system
> controller "SYSCON". It also serves as an example of how to use
> the pinmux subsystem. This driver also houses the platform data
> for the only supported platform.

> diff --git a/drivers/pinctrl/pinmux-u300.c b/drivers/pinctrl/pinmux-u300.c

> +/*
> + * We define explicit indexes of the groups since these will be
> + * referenced in the pinmuxes below.
> + */
> +#define POWERGRP_INDEX 0
> +#define UART0GRP_INDEX 1
> +#define MMC0GRP_INDEX 2
> +#define SPI0GRP_INDEX 3
> +
> +static const struct u300_pin_group u300_pin_groups[] = {
> + [POWERGRP_INDEX] = {
> + .name = "powergrp",
> + .pins = power_pins,
> + .num_pins = ARRAY_SIZE(power_pins),
> + },
...
> +/**
> + * struct u300_pmx_func - describes U300 pinmux functions
> + * @name: the name of this specific function
> + * @groups: corresponding pin groups
> + * @onmask: bits to set to enable this when doing pin muxing
> + */
> +struct u300_pmx_func {
> + const char *name;
> + const unsigned groups[1];
> + const struct u300_pmx_mask *mask;
> +};
> +
> +static const struct u300_pmx_func u300_pmx_functions[] = {
> + {
> + .name = "power",
> + .groups = { POWERGRP_INDEX },
> + /* Mask is N/A */
> + },

Hmmm. That's a lot of _INDEX defines that'd need to be set up, at least
to fully represent a chip like Tegra. Can the pinmux core be modified
such that the group list is an array of names (char*) rather than the
actual numeric IDs of the groups? Still, perhaps we could use the enum
we already have for this, so perhaps it isn't a big deal...

-- 
nvpublic


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

RE: [PATCH 1/4 v6] drivers: create a pin control subsystem v6

[Stephen Warren]

Linus Walleij wrote at Thursday, September 01, 2011 3:32 AM:
> This creates a subsystem for handling of pin control devices.
> These are devices that control different aspects of package
> pins.

Overall, I think this is beginning to look very good. Thanks for taking
care of my requests.

I want to check one thing: A given pin can be in multiple pin groups at
once. This will be important when biasing/... is added, since Tegra will
then having 2 sets of overlapping pin groups that cover all/most pins;
one set for muxing and one for biasing etc. Each pin will be in one of
the mux groups and one of the bias groups. I'm pretty sure this is the
case, but just wanted to double-check.

As you already acknowledge, one missing feature is handling multiple map
entries for each pinmux_get()/enable().

My final area of contention is the GPIO-specific APIs and mapping.

The only thing pinmux allows you to do with the GPIO ranges are
request_gpio and free_gpio. Some thoughts:

* These only exist to prevent an explosion in the number of functions. I
don't think we need these APIs to avoid this; see my discussion below.

* These APIs don't work in the same way as mapping table entries; what
if switching a controller between two sets of pins also required
using a different GPIO; I might want to put the equivalent of
request_gpio and free_gpio into the mapping table. This can only be done
if we represent GPIOs as just another function, rather than special-
casing them.

* If we get rid of the GPIO APIs, we can then get rid of the GPIO ranges
too, which cuts out a lot of code.

I would imagine treating GPIOs as just another function. I'll repeat
some text I wrote previously (https://lkml.org/lkml/2011/8/26/298) about
how I see this working:

>SW For reference, here's how I'd imagine modeling those three cases in
>SW pinmux (all based on my earlier comments about the data model I imagine,
>SW rather than what's currently in the pinmux patches):

>SW 1) Have a single function "gpio" that can be applied to any pin that
>SW supports it. The actual GPIO number that gets mux'd onto the pin differs
>SW per pin, and is determine by HW design. But logically, we're connecting
>SW that pin to function "gpio", so we only need one function name for that.

So here, the only issue is that if "GPIO" can be assigned per pin, we'd
need to define a pingroup per pin, even if we had a set of other groups
for muxing. (And a pin would have to be in its per-pin pingroup, and
mux group, which goes back to my very first comment above.) I suppose this
might end up being a lot of pingroups. However, this is all data, and
it seems like having large data is better than having large code? Still,
these per-pin groups might end up existing for other functionality like
biasing anyway, depending on HW.

>SW 2) Have a function for each GPIO controller that can be attached to a
>SW pin; "gpioa" or "gpiob". Based on the pin being configured, and which of
>SW those two GPIO functions is selected, the HW determines the specific GPIO
>SW number that's assigned to the pin.

>SW 3) Where the GPIO ID assigned to pins is user-selectable, have a function
>SW per GPIO ID; "gpio1", "gpio2", "gpio3", ... "gpio31". This sounds like
>SW it'd cause a huge explosion in the number of functions; one to represent
>SW each GPIO ID. However, I suspect this won't be too bad in practice, since
>SW there's presumably some practical limit to the amount of muxing logic that
>SW can be applied to each pin in HW, so the set of options won't be too large.

In https://lkml.org/lkml/2011/8/29/74, it sounded like you weren't averse
to the idea of treating GPIOs like any other function.



A number of smaller comments directed at specific parts of the patch
text are below.

> +++ b/Documentation/pinctrl.txt

> +The pin control subsystem will call the .list_groups() function repeatedly
> +beginning on 0 until it returns non-zero to determine legal selectors

Given you said that pingroups are mandatory, I wonder why struct pinctrl_desc
doesn't just have an ngroups field to; that'd save having to iterate over calls
to list_groups to find the total number of groups.

> +Pinmux conventions
> +==

Just wanted to say that I agree with the description of the data model given
in this section of the docs, with the exceptions listed early in this email.

> +- FUNCTIONS using a certain PIN GROUP on a certain PIN CONTROLLER are 
> provided
> +  on a first-come first-serve basis,

It might be better to say that pins are provided on a first-come first-
serve bases, and hence pin groups too. Function doesn't really come into
it; the function is just how you program the pins/groups after you've
applied first-come first-serve.

> +Pinmux drivers
> +==
> +
> +It is the responsibility of the pinmux driver to determine whether or not
> +the requested function can actually be enabled, and in that case poke the
> +hardware so that this happens.

Perhaps augment that to make it clear that 

[PATCH] RFCv2: video support for dri2

[Rob Clark]

To allow the potential use of overlays to display video content, a few
extra parameters are required:

 + source buffer in different format (for example, various YUV formats)
   and size as compared to destination drawable
 + multi-planar formats where discontiguous buffers are used for
   different planes.  For example, luma and chroma split across
   multiple memory banks or with different tiled formats.
 + flipping between multiple back buffers, perhaps not in order (to
   handle video formats with B-frames)
 + cropping during swap.. in case of video, perhaps the required hw
   buffers are larger than the visible picture to account for codec
   borders (for example, reference frames where a block/macroblock
   moves past the edge of the visible picture, but back again in
   subsequent frames).

Current solutions use the GPU to do a scaled/colorconvert into a DRI2
buffer from the client context.  The goal of this protocol change is
to push the decision to use overlay or GPU blit to the xorg driver.

In many cases, an overlay will avoid several passes through memory
(blit/scale/colorconvert to DRI back-buffer on client side, blit to
front and fake-front, and then whatever compositing is done by the
window manager).  On the other hand, overlays can often be handled
directly by the scanout engine in the display hardware, with the GPU
switched off.

The disadvantages of overlays are that they are (usually) a limited
resource, sometimes with scaling constraints, and certainly with
limitations about transformational effects.

The goal of combining video and dri2 is to have the best of both worlds,
to have the flexibility of GPU blitting (ie. no limited number of video
ports, no constraint about transformational effects), while still having
the power consumption benefits of overlays (reduced memory bandwidth
usage and ability to shut off the GPU) when the UI is relatively
static other than the playing video.

Note: video is not exactly the same as 3d, there are a number of other
things to consider (scaling, colorconvert, multi-planar formats).  But
on the other hand the principle is similar (direct rendering from hw
video codecs).  And a lot infrastructure of connection, authentication,
is same.  So there are two options, either extend DRI2 or add a new
protocol which duplicates some parts.  I'd like to consider extending
DRI2 first, but if people think the requirements for video are too
much different from 3d, then I could split this into a new protocol.
---
 dri2proto.txt |  133 -
 1 files changed, 131 insertions(+), 2 deletions(-)

diff --git a/dri2proto.txt b/dri2proto.txt
index df763c7..92f85a4 100644
--- a/dri2proto.txt
+++ b/dri2proto.txt
@@ -163,7 +163,8 @@ and DRI2InvalidateBuffers.
 6. Protocol Types
 
 DRI2DRIVER { DRI2DriverDRI
-DRI2DriverVDPAU }
+DRI2DriverVDPAU,
+DRI2DriverXV }
 
These values describe the type of driver the client will want
to load.  The server sends back the name of the driver to use
@@ -184,6 +185,11 @@ DRI2ATTACHMENT { DRI2BufferFrontLeft
These values describe various attachment points for DRI2
buffers.
 
+   In the case of video driver (DRI2DriverXV) the attachment,
+   other than DRI2BufferFrontLeft, just indicates buffer
+   number and has no other special significance.  There is no
+   automatic maintenance of DRI2BufferFakeFrontLeft.
+
 DRI2BUFFER { attachment: CARD32
 name: CARD32
 pitch: CARD32
@@ -201,7 +207,8 @@ DRI2ATTACH_FORMAT { attachment: CARD32
 
The DRI2ATTACH_FORMAT describes an attachment and the associated
format.  'attachment' describes the attachment point for the buffer,
-   'format' describes an opaque, device-dependent format for the buffer.
+   'format' describes an opaque, device-dependent format for the buffer,
+   or a fourcc for non-device-dependent formats.
 
 ⚙ ⚙ ⚙  ⚙ ⚙ ⚙
 
@@ -440,6 +447,97 @@ The name of this extension is "DRI2".
DRI2SwapBuffers requests to swap at most once per interval frames,
which is useful useful for limiting the frame rate.
 
+┌───
+DRI2SetAttribute
+   drawable: DRAWABLE
+   attribute: ATOM
+   value: INT32
+  ▶
+└───
+   Errors: Window, Match, Value
+
+   The DRI2SetAttribute request sets the value of a drawable attribute.
+   The drawable attribute is identified by the attribute atom.  The
+   following strings are guaranteed to generate valid atoms using the
+   InternAtom request.
+
+   StringType
+   -
+
+   "XV_ENCODING" ENCODINGID
+   "XV_HUE"  [-1000..1000]
+   "XV_SATURATION"   [-1000..1000]
+   "XV_BRIGHTNESS"   [-1000..1000]
+   "XV_CONTRAST" [-1000..1000]
+   "XV_WIDTH"[0..MAX_INT]

RE: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

[Stephen Warren]

Linus Walleij wrote at Thursday, September 01, 2011 3:13 AM:
...
> I will need Arnds or similars advice on it so we don't
> grow a lib/mysql into the kernel with this kind of
> schemes and get slammed for overcomplicating
> things when trying to merge the beast.

I /think/ the whole multi-row thing is just doing this:

for each row of table:
if it matches search terms:
Activate the specified function on the group

Whereas handling just one entry is almost the same:

for each row of table:
if it matches search terms:
Activate the specified function on the group
break

Of course, in the former case, the error-handling also has to iterate
over all the already-processed rows and unreserved/unprogram the HW too,
but that should be a pretty simple loop too.

And replying to your immediately earlier email:

...
> > Hence, a given board would only need rows 0, 1+2, or
> > 3+4+5 from the mapping table shown above, assuming the width of the MMC
> > port didn't vary at run-time.
> 
> OK we're on the same page I think. If I fix this, then
> you're happy?

I haven't read patchset 6 yet, but from the descriptions in your email
and the patch 0 changelog, it certainly sounds like we're on very
similar pages now.

> > Some pin parameters might be defined per:
> >
> > * Pin (probably most systems other than Tegra)
> > * Pin group (for pull-up/down, tristate on Tegra)
> > * Drive group (another set of groups of pins on Tegra that arbitrarily
> > overlap/intersect with the mux pin groups (for drive-strength settings
> > on Tegra).
> 
> Since these things are unrelated to muxing I prefer that
> we add that as a separate set of ops in struct pinctrl_device.
> 
> The driver can very well reuse the same groups internally,
> nothing prevents that.
> 
> I am not intending to address the issue of pin bias,
> driver strength, load capacitance, schmitt-trigger input
> etc etc etc in this first iteration of the pin control subsystem,
> what I want is to get the infrastructure and pin muxing
> into the kernel then extend it with other pin control.
> 
> I'm trying to avoid excess upfront design.
> 
> Do you think these features are needed from day 1
> to be of any use for Tegra?

I think having just muxing support would work fine for a first pass.

Looking forward a little, I expect that different SoCs have such a
different set of biasing/driver-strength/... options that actually having
some formalized semantic representation of what those options are doesn't
make sense; all we need is a standard API to set the values for a given
pin or pingroup; just like the config API you already had, but applied
to pingroups rather than explicitly GPIOs, and where the driver supplies
the names for the settings and interprets what the values mean for a
given setting. I imagine having the config API in the first pass wouldn't
be contentious, provided it applied to pingroups.

Just possibly, I could imagine needing config entries in the mapping table,
so when switching between mapping entries at run-time you could both program
muxing and other configuration. However, that's definitely not a first-pass
thing, as you say. And I'm just guessing if it'll be needed anyway.

> > Or, in more normalized fashion, with multiple rows per pingroup, each
> > entry containing:
> > * Name of pingroup
> > * One pin with in the pingroup
> 
> I don't get this "one pin within the the pingroup"
> what if the same pin is part of multiple groups?

It was just a data-representation thing. You could either have:

struct {
char * pingroup;
int npins;
int * pins;
};

Where one row represents everything about a pingroup, or:

struct {
char * pingroup;
int pin;
};

Where you'd need a row for each pin in a pingroup.

Go with whatever you find is easiest; I was just thinking databases for
a while!

-- 
nvpublic


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ACTIVITY] Power Management WG Weekly Status report week ending 2011-09-02

[Mounir Bsaibes]

Enclosed  please find the link to the Meeting Minutes & Weekly Status report

for the Power Management working group for the week ending 2011-08-26.

== Meeting Minutes ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-08-31

== Weekly Status Report ==
https://wiki.linaro.org/WorkingGroups/PowerManagement/Status/2011-09-01


== Summary ==

 * Made hotplug power measurements on st-e u8500 platform
   * mp3 playback test showed between 7 to 8% power improvement
   * cpuhotplug - For Linux idle case, no visible improvement as power is
already very low
 * Finished GPIO support in power debug.
 * linaro-pm-qa integration with LAVA went well, we should start seeing a
daily test of power management suite
 * Published git tree containing common Samsung save and restore code
 * Preparing thermal framework for upstreaming and preparing slides for
Plumbers conference
 * Started to work on integration of thermal with OMAP4460 power management
 * Re-writing cpuidle driver
 * Started design work on struct clk, created some notes and design points
for discussion at LPC
 * Rebased PMWG kernel git tree to 3.1-rc4

Best regards,
Mounir


-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
http://twitter.com/#!/linaroorg
http://www.linaro.org/linaro-blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH] mmc: omap_hsmmc: DMA unmap only once in case of MMC error

[S, Venkatraman]

On Mon, Aug 29, 2011 at 3:38 AM, Per Forlin  wrote:
> Reported by Russell King:
> 
> mmcblk0: error -84 transferring data, sector 149201, nr 64,
> cmd response 0x900, card status 0xb00
> mmcblk0: retrying using single block read
>
> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811 check_unmap
> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
> it has not allocated [device address=0x80933000] [size=20480 bytes]
> -
>
> In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
> and then again in omap_hsmmc_post_req(). Resolve this by clearing the
> host_cookie to indicate there is no DMA mapped memory to unmap.
>
> Signed-off-by: Per Forlin 
> ---
> Bug fix on 3.1-rc3
>
>  drivers/mmc/host/omap_hsmmc.c |    7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 21e4a79..31d9817 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct 
> omap_hsmmc_host *host, int errno)
>                        host->data->sg_len,
>                        omap_hsmmc_get_dma_dir(host, host->data));
>                omap_free_dma(dma_ch);
> +               host->data->host_cookie = 0;
>        }
>        host->data = NULL;
>  }
> @@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc, 
> struct mmc_request *mrq,
>        struct mmc_data *data = mrq->data;
>
>        if (host->use_dma) {
> -               dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len,
> -                            omap_hsmmc_get_dma_dir(host, data));
> +               if (data->host_cookie)
> +                       dma_unmap_sg(mmc_dev(host->mmc), data->sg,
> +                                    data->sg_len,
> +                                    omap_hsmmc_get_dma_dir(host, data));
>                data->host_cookie = 0;
>        }
>  }
> --
> 1.7.4.1
>
>

I just posted a patch [1] which just consolidates all unmapping to
just post_req.
This would obviously prevent double unmapping, and keeps all the related
dma operations at a single place. Let me know if that works better.

[1]: http://marc.info/?l=linux-mmc&m=131490406920616&w=2

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[ANNOUNCE] Power Management linaro-pm-qa test project

[Mounir Bsaibes]

The Linaro Power Management Working Group has created a Launchpad project to

develop functional test suite  for the power management blocks on arm:
* cpuidle
* cpufreq
* cpu hotplug
* sched_mc


This test suite would allow to quickly spot configuration errors and
regressions in existing
functionality on automated daily builds. It will be continually enhanced
to incorporate new frameworks, stress-test existing ones and eventually add
energy measurements.

The project can be found at: https://launchpad.net/linaro-pm-qa

Best regards,
Mounir


-- 
Mounir Bsaibes
Project Manager

Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106
http://twitter.com/#!/linaroorg
http://www.linaro.org/linaro-blog 
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Update on Gerrit deployment

[John Stultz]

On Sun, 2011-08-28 at 10:35 +0800, Andy Green wrote:
> On 08/28/2011 05:20 AM, Somebody in the thread at some point said:
> > But I've got an open mind and am willing to try it out and figure out a
> > workflow. I suspect for me it really won't be anything other then a
> > different location to "git push" to.
> 
> I think we are having different takes on it (although I appreciate 
> reading your somewhat nuanced view) because application of patches 
> doesn't mean for me what it means to a history branch.
> 
> The patch does not just go on top of HEAD and then you're done, it needs 
> to be placed at the right topic branch layer in tracking; may need to be 
> adapted to apply to an intermediate branch (eg, tilt-3.0) that is on a 
> different pinned release basis, then the intermediate branch rebased 
> against the final basis like, eg, your android tree to provide the final 
> output.

Right. So yes, the applying a series of patches directly to the tree
isn't as big of a perk for your topic branches.

But... One way it can work is by applying them on top the gerrit head,
you can then pluck them via git cherry-pick into your own tree and into
the right topic branch. Then the next time you rebase/push, the patch
should be included there. If gerrit provides a changeid on the merged
patch (this I've not tried, so maybe it doesn't), it should then be able
to track that the patch is also merged in your newly rebased HEAD.

But again, I really doubt there will be much in the way of kernel
patches being submitted via gerrit (for most I suspect its more work to
submit via gerrit then it is to mail patches). So I'd really only focus
on gerrit as just a different public git repo to push your work to.

thanks
-john



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [Request] Can Linaro-dev not send duplicate mail to recipients?

[John Stultz]

On Thu, 2011-09-01 at 10:45 +0100, Jon Medhurst (Tixy) wrote:
> On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> > It seems the linaro-dev list isn't configed to avoid mailing folks who
> > are already recipients of the email.
> 
> Go to  http://lists.linaro.org/mailman/options/linaro-dev
> and select "Avoid duplicate copies of messages".

Ah! Perfect! Thanks so much!
-john






___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Paul Sokolovsky]

On Thu, 1 Sep 2011 13:23:37 +0200
Alexander Sack  wrote:

> On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis
> wrote:
> 
> > On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> > > Hello Christian,
> > >
> > > On Tue, 30 Aug 2011 12:43:40 -0300
> > > Christian Robottom Reis  wrote:
> > >
> > > > On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> > > > > Yeah, I have patch for that. But we cannot use before upstream
> > > > > accepts it (because people will get errors checking out tree)
> > > > > and I don't hold my breath for that at all.
> > > >
> > > > Why wouldn't we provide our own version of repo that worked
> > > > around this issue?
> > >
> > > By the same reason we don't fork entire Android itself and fixing
> > > it to work "right"? ;-)
> >
> > Either I'm missing the point or you are. We "fork" Android and
> > everything else all the time; we then proceed to send the patches
> > upstream and help them through the process, and so for me the
> > "fork" is more like a cooperative branch.
> >
> > Look, this is a weird conversation and I want to get out of it as
> > soon as I can. But you guys are overblowing the issue -- I'm just
> > suggesting that if the patch will take a while to go upstream, you
> > can ship a separate repo tool. We do this all the time in Linaro
> > (just look at www.linaro.org/downloads).
> >
> >
> I agree with kiko here. If the repo patch would have a clearer
> indication in gerrit by now that this is not acceptable upstream I

It seems that they're really not against it. My concern was that tag
fetching was omitted deliberately to save on traffic and they would be
reluctant to add it. But it turned out that's actually not that
easy to do that on git's side using raw git fetch, in particular, "git
fetch --tags", like I patched it first, indeed fetches *only* tags (and
git docs are confusing in this respect). But they even suggested how to
do it right, which I just have tested to work for our case:

https://pastebin.linaro.org/220/
https://pastebin.linaro.org/221/
https://pastebin.linaro.org/222/

review.source.android.com is down now (hmm, is it hosted on the same
host as android.git.kernel.org ?), but I'll prepare new version of the
patch when it's up.

> would have agreed to think about a solution on the git branch policy
> side. But if the lack of --tag hurts us now badly we should work
> around somehow by patching repo etc. until that patch discussion
> gives us more assurance that adopting everyone's workflow is not just
> for the sake of a temporary bandaid.

Well, it's very easy for me to prepare a new repo branch and hand out a
download link to release managers if that's what we want. But as
it's just milestone start, let's hope it might land in upstream indeed.


-- 
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [Request] Can Linaro-dev not send duplicate mail to recipients?

[Christian Robottom Reis]

On Wed, Aug 31, 2011 at 09:05:55PM -0700, John Stultz wrote:
> It seems the linaro-dev list isn't configed to avoid mailing folks who
> are already recipients of the email. So if you're on linaro-dev and
> you're also To/CC'ed in the email, you get it twice (three times if your
> other work email was CC'ed as well, but that cannot be helped).

I know this is controversial, but I really like that pattern. It ensures
that I filter messages that are directly to me specially, while the rest
just goes into a lower priority archive folder.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Pawel Moll]

> > PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)
> 
> What about non-ARM implementations from e.g. Qualcomm and Marvell?

Sorry, I have no access to theirs specs and the ARM ARM (Architecture
Reference Manual) does not enforce any particular numbering scheme.

Some SA and PXA processors are enumerated in the qemu's list mentioned
by Dave Gilbert, but that's probably less interesting as well.

Paweł



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Arnd Bergmann]

On Thursday 01 September 2011, Andrew Stubbs wrote:
> Hi all,
> 
> I'm currently trying to get GCC to auto-detect what CPU to optimize for 
> by finding out what CPU it's actually running on (the user would only 
> have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
> 
> The problem is finding what magic numbers correspond to what CPU. I've 
> found the numbers for A8 and A9 empirically, but I'd like a longer list 
> than that!
> 
> Does anybody have a list of such numbers?
> 
> Or else, perhaps people could just post any number they happen to know?
> 
> I do have a few devices other than A8 and A9 lying around I can look at, 
> but the problem there is I don't actually know for certain what exact 
> CPU model those numbers map to, so confirmed numbers only please.

This is what we use in the kernel: to find out the architecture level:

#define CPU_ARCH_UNKNOWN0
#define CPU_ARCH_ARMv3  1
#define CPU_ARCH_ARMv4  2
#define CPU_ARCH_ARMv4T 3
#define CPU_ARCH_ARMv5  4
#define CPU_ARCH_ARMv5T 5
#define CPU_ARCH_ARMv5TE6
#define CPU_ARCH_ARMv5TEJ   7
#define CPU_ARCH_ARMv6  8
#define CPU_ARCH_ARMv7  9

int cpu_architecture(void)
{
int cpu_arch;

if ((read_cpuid_id() & 0x0008f000) == 0) {
cpu_arch = CPU_ARCH_UNKNOWN;
} else if ((read_cpuid_id() & 0x0008f000) == 0x7000) {
cpu_arch = (read_cpuid_id() & (1 << 23)) ? CPU_ARCH_ARMv4T : 
CPU_ARCH_ARMv3;
} else if ((read_cpuid_id() & 0x0008) == 0x) {
cpu_arch = (read_cpuid_id() >> 16) & 7;
if (cpu_arch)
cpu_arch += CPU_ARCH_ARMv3;
} else if ((read_cpuid_id() & 0x000f) == 0x000f) {
unsigned int mmfr0;

/* Revised CPUID format. Read the Memory Model Feature
 * Register 0 and check for VMSAv7 or PMSAv7 */
asm("mrcp15, 0, %0, c0, c1, 4"
: "=r" (mmfr0));
if ((mmfr0 & 0x000f) >= 0x0003 ||
(mmfr0 & 0x00f0) >= 0x0030)
cpu_arch = CPU_ARCH_ARMv7;
else if ((mmfr0 & 0x000f) == 0x0002 ||
 (mmfr0 & 0x00f0) == 0x0020)
cpu_arch = CPU_ARCH_ARMv6;
else
cpu_arch = CPU_ARCH_UNKNOWN;
} else
cpu_arch = CPU_ARCH_UNKNOWN;

return cpu_arch;
}


[ within the /proc/cpuinfo code: ]
...
seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
seq_printf(m, "CPU architecture: %s\n", proc_arch[cpu_architecture()]);

if ((read_cpuid_id() & 0x0008f000) == 0x) {
/* pre-ARM7 */
seq_printf(m, "CPU part\t: %07x\n", read_cpuid_id() >> 4);
} else {
if ((read_cpuid_id() & 0x0008f000) == 0x7000) {
/* ARM7 */
seq_printf(m, "CPU variant\t: 0x%02x\n",
   (read_cpuid_id() >> 16) & 127);
} else {
/* post-ARM7 */
seq_printf(m, "CPU variant\t: 0x%x\n",
   (read_cpuid_id() >> 20) & 15);
}
seq_printf(m, "CPU part\t: 0x%03x\n",
   (read_cpuid_id() >> 4) & 0xfff);
}
seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
...



Arnd

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Mans Rullgard]

On 1 September 2011 12:02, Pawel Moll  wrote:
>> If you search the specs on http://infocenter.arm.com for "Main ID
>> register" you should get all the numbers you wish for :-)
>
> Apparently it's called "ID Code Register" for ARM9 and the expected (not
> tested ;-) values would be:
>
> ARM926 - 0x926
> ARM946 - 0x946
> ARM966 - 0x966
>
> etc., you get the picture :-)
>
> Paweł
>
> PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM Ltd.)

What about non-ARM implementations from e.g. Qualcomm and Marvell?  A Marvell
I have on hand reports this:

Processor   : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 1192.75
Features: swp half fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Here the Processor line contains the exact name of the CPU, which can presumably
derived from the ID register somehow.

I don't have a Qualcomm processor handy at the moment.

> PPS. I think older (and MMU-less) parts were using other scheme...

They do, but I wouldn't worry about that since they're not likely to be running
gcc anyway.

-- 
Mans Rullgard
Multimedia
mans.rullg...@linaro.org

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[David Gilbert]

On 1 September 2011 10:40, Andrew Stubbs  wrote:
> Hi all,
>
> I'm currently trying to get GCC to auto-detect what CPU to optimize for by
> finding out what CPU it's actually running on (the user would only have to
> pass -mcpu=native). It does this simply by reading /proc/cpuinfo.
>
> The problem is finding what magic numbers correspond to what CPU. I've found
> the numbers for A8 and A9 empirically, but I'd like a longer list than that!
>
> Does anybody have a list of such numbers?
>
> Or else, perhaps people could just post any number they happen to know?
>
> I do have a few devices other than A8 and A9 lying around I can look at, but
> the problem there is I don't actually know for certain what exact CPU model
> those numbers map to, so confirmed numbers only please.

The QEMU tree appears to have a list in target-arm/cpu.h (LGPL):

#define ARM_CPUID_ARM1026 0x4106a262
#define ARM_CPUID_ARM926  0x41069265
#define ARM_CPUID_ARM946  0x41059461
#define ARM_CPUID_TI915T  0x54029152
#define ARM_CPUID_TI925T  0x54029252
#define ARM_CPUID_SA1100  0x4401A11B
#define ARM_CPUID_SA1110  0x6901B119
#define ARM_CPUID_PXA250  0x69052100
#define ARM_CPUID_PXA255  0x69052d00
#define ARM_CPUID_PXA260  0x69052903
#define ARM_CPUID_PXA261  0x69052d05
#define ARM_CPUID_PXA262  0x69052d06
#define ARM_CPUID_PXA270  0x69054110
#define ARM_CPUID_PXA270_A0   0x69054110
#define ARM_CPUID_PXA270_A1   0x69054111
#define ARM_CPUID_PXA270_B0   0x69054112
#define ARM_CPUID_PXA270_B1   0x69054113
#define ARM_CPUID_PXA270_C0   0x69054114
#define ARM_CPUID_PXA270_C5   0x69054117
#define ARM_CPUID_ARM1136 0x4117b363
#define ARM_CPUID_ARM1136_R2  0x4107b362
#define ARM_CPUID_ARM1176 0x410fb767
#define ARM_CPUID_ARM11MPCORE 0x410fb022
#define ARM_CPUID_CORTEXA80x410fc080
#define ARM_CPUID_CORTEXA8_R2 0x412fc083
#define ARM_CPUID_CORTEXA90x410fc090
#define ARM_CPUID_CORTEXM30x410fc231

With the field you were looking at being nybbles 3..1

Dave

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Pawel Moll]

> I actually did look for a bit and never found a definitive list. I've
> found descriptions of the bitfield and some sample values, but I haven't
> seen an actual official list.

That's correct, I don't think such a list exists (at least within
official ARM specs). What I meant is searching for the register name and
getting the number out the relevant TRM).

Cheers!

Paweł



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Alexander Sack]

On Thu, Sep 1, 2011 at 1:05 PM, Christian Robottom Reis wrote:

> On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> > Hello Christian,
> >
> > On Tue, 30 Aug 2011 12:43:40 -0300
> > Christian Robottom Reis  wrote:
> >
> > > On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> > > > Yeah, I have patch for that. But we cannot use before upstream
> > > > accepts it (because people will get errors checking out tree) and I
> > > > don't hold my breath for that at all.
> > >
> > > Why wouldn't we provide our own version of repo that worked around
> > > this issue?
> >
> > By the same reason we don't fork entire Android itself and fixing it to
> > work "right"? ;-)
>
> Either I'm missing the point or you are. We "fork" Android and
> everything else all the time; we then proceed to send the patches
> upstream and help them through the process, and so for me the "fork" is
> more like a cooperative branch.
>
> Look, this is a weird conversation and I want to get out of it as soon
> as I can. But you guys are overblowing the issue -- I'm just suggesting
> that if the patch will take a while to go upstream, you can ship a
> separate repo tool. We do this all the time in Linaro (just look at
> www.linaro.org/downloads).
>
>
I agree with kiko here. If the repo patch would have a clearer indication in
gerrit by now that this is not acceptable upstream I would have agreed to
think about a solution on the git branch policy side. But if the lack of
--tag hurts us now badly we should work around somehow by patching repo etc.
until that patch discussion gives us more assurance that adopting everyone's
workflow is not just for the sake of a temporary bandaid.


-- 

 - Alexander
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Marcin Juszkiewicz]

W dniu 01.09.2011 12:20, Pawel Moll pisze:
>> Does anybody have a list of such numbers?

ARM926 - 0x926 (atmel at91sam9263)
ARM920 - 0x920 (atmel at91rm9200)

I have some armv4t/v5t/v6 systems here but none of them under power.

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Christian Robottom Reis]

On Thu, Sep 01, 2011 at 11:20:21AM +0100, Pawel Moll wrote:
> > Does anybody have a list of such numbers?
> 
> If you search the specs on http://infocenter.arm.com for "Main ID
> register" you should get all the numbers you wish for :-)

I actually did look for a bit and never found a definitive list. I've
found descriptions of the bitfield and some sample values, but I haven't
seen an actual official list.


http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344k/Bgbiddeb.html

For the M Series:

http://infocenter.arm.com/help/topic/com.arm.doc.dui0395b/CIHCAGHH.html
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Christian Robottom Reis]

On Wed, Aug 31, 2011 at 02:19:08PM +0300, Paul Sokolovsky wrote:
> Hello Christian,
> 
> On Tue, 30 Aug 2011 12:43:40 -0300
> Christian Robottom Reis  wrote:
> 
> > On Tue, Aug 30, 2011 at 01:25:15PM +0300, Paul Sokolovsky wrote:
> > > Yeah, I have patch for that. But we cannot use before upstream
> > > accepts it (because people will get errors checking out tree) and I
> > > don't hold my breath for that at all.
> > 
> > Why wouldn't we provide our own version of repo that worked around
> > this issue?
> 
> By the same reason we don't fork entire Android itself and fixing it to
> work "right"? ;-)

Either I'm missing the point or you are. We "fork" Android and
everything else all the time; we then proceed to send the patches
upstream and help them through the process, and so for me the "fork" is
more like a cooperative branch.

Look, this is a weird conversation and I want to get out of it as soon
as I can. But you guys are overblowing the issue -- I'm just suggesting
that if the patch will take a while to go upstream, you can ship a
separate repo tool. We do this all the time in Linaro (just look at
www.linaro.org/downloads).

It doesn't mean the patch won't go upstream eventually, nor that you
won't find another solution -- it just means this thread can end and we
can go on working without getting other teams all excited about having
to change their source control working models.
-- 
Christian Robottom Reis, Engineering VP
Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935
Linaro.org: Open Source Software for ARM SoCs

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Pawel Moll]

> If you search the specs on http://infocenter.arm.com for "Main ID
> register" you should get all the numbers you wish for :-)

Apparently it's called "ID Code Register" for ARM9 and the expected (not
tested ;-) values would be:

ARM926 - 0x926
ARM946 - 0x946
ARM966 - 0x966

etc., you get the picture :-) 

Paweł

PS. The number I quoted are valid when "CPU implementer" == 0x41 (ARM
Ltd.)

PPS. I think older (and MMU-less) parts were using other scheme...





___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: Tracking Android kernel tips and Android builds

[Christian Robottom Reis]

On Tue, Aug 30, 2011 at 11:13:08AM -0500, Zach Pfeffer wrote:
> > Any other issues that I've missed? Where should we come down in this case?
> 
> I say we stay the course and fix the issue of sha's disappearing. I
> feel this way because its:
> 
> 1. Technically feasible in the short term.
> 2. Saves the substantial burden of redirecting to the user.
> 3. Supports the only way that you can guarantee 100% build fidelity.

Can you restate "fix the issue of sha's [sic] disappearing" in a way
which I can understand? As far as I know, the actual problem is that
repo isn't fetching all tags.

Or are you describing the symptom as seen from the build system? Because
my suggestion (ship a forked repo temporarily) would address that.
-- 
Christian Robottom Reis   | [+55 16] 3376 0125 | http://launchpad.net/~kiko
Canonical Ltd.| [+55 16] 9112 6430 | http://async.com.br/~kiko

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: ARM CPU part numbers

[Pawel Moll]

> Does anybody have a list of such numbers?

If you search the specs on http://infocenter.arm.com for "Main ID
register" you should get all the numbers you wish for :-)

> Or else, perhaps people could just post any number they happen to know?

For v6 and v7 processors, the /proc/cpuinfo's "CPU part" (I guess that's
the one you are after?) is the "Part number" in the "Main ID register".
For Cortex-A family these are going to be 0xc00 + number, ie. 0xc09 =
A9, 0xc08 = A8, 0xc0f = A15 etc. ARM11 family is (surprise, what's hex
value for 11? ;-) 0xb0_ etc.

So for what I know:

Cortex A5 - 0xc05
Cortex A8 - 0xc08
Cortex A9 - 0xc09
Cortex A15 - 0xc0f

Cortex R4 - 0xc14
Cortex R5 - 0xc15

ARM1136 - 0xb36
ARM1156 - 0xb56
ARM1176 - 0xb76
ARM11 MPCore - 0xb02

Cheers!

Paweł



___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [Request] Can Linaro-dev not send duplicate mail to recipients?

[Jon Medhurst (Tixy)]

On Wed, 2011-08-31 at 21:05 -0700, John Stultz wrote:
> It seems the linaro-dev list isn't configed to avoid mailing folks who
> are already recipients of the email.

Go to  http://lists.linaro.org/mailman/options/linaro-dev
and select "Avoid duplicate copies of messages".

Interestingly, for me, this option was set and I had to clear it as I
don't want gaps in the threads in my mailing list folders.

-- 
Tixy


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

ARM CPU part numbers

[Andrew Stubbs]

Hi all,

I'm currently trying to get GCC to auto-detect what CPU to optimize for 
by finding out what CPU it's actually running on (the user would only 
have to pass -mcpu=native). It does this simply by reading /proc/cpuinfo.


The problem is finding what magic numbers correspond to what CPU. I've 
found the numbers for A8 and A9 empirically, but I'd like a longer list 
than that!


Does anybody have a list of such numbers?

Or else, perhaps people could just post any number they happen to know?

I do have a few devices other than A8 and A9 lying around I can look at, 
but the problem there is I don't actually know for certain what exact 
CPU model those numbers map to, so confirmed numbers only please.


Thanks

Andrew

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 2/4 v6] pinmux: add a driver for the U300 pinmux

[Linus Walleij]

From: Linus Walleij 

This adds a driver for the U300 pinmux portions of the system
controller "SYSCON". It also serves as an example of how to use
the pinmux subsystem. This driver also houses the platform data
for the only supported platform.

Signed-off-by: Linus Walleij 
---
ChangeLog v5->v6:

- Adjust driver to use the new pin group concept so that it
  serves as a good illustration of how to use groups.

- Provide pinmux functions separate from groups, add a
  group association field to the U300 pinmux struct and
  provide a callback function to retrieve the available
  groups per function.

- Adjust to various other changes like the per-pin debug print
  function being part of pinctrl_ops rather than the pinmux_ops.
---
 arch/arm/mach-u300/core.c |   26 ++
 drivers/pinctrl/Kconfig   |7 +
 drivers/pinctrl/Makefile  |1 +
 drivers/pinctrl/pinmux-u300.c |  932 +
 drivers/pinctrl/pinmux-u300.h |  141 +++
 5 files changed, 1107 insertions(+), 0 deletions(-)
 create mode 100644 drivers/pinctrl/pinmux-u300.c
 create mode 100644 drivers/pinctrl/pinmux-u300.h

diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 399c89f..2020bf9 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1630,6 +1631,27 @@ static struct platform_device dma_device = {
},
 };
 
+static struct platform_device pinmux_device = {
+   .name = "pinmux-u300",
+   .id = -1,
+   .num_resources = ARRAY_SIZE(pinmux_resources),
+   .resource = pinmux_resources,
+};
+
+/* Padmux settings */
+static struct pinmux_map u300_padmux_map[] = {
+   /* anonymous map for chip power */
+   {
+   .name = "power",
+   .ctrl_dev_name = "pinctrl.0",
+   .function = "power",
+   .dev_name = NULL,
+   },
+   PINMUX_MAP_PRIMARY("mmc0", "mmci"),
+   PINMUX_MAP_PRIMARY("spi0", "pl022"),
+   PINMUX_MAP_PRIMARY("uart0", "uart0"),
+};
+
 /*
  * Notice that AMBA devices are initialized before platform devices.
  *
@@ -1828,6 +1850,10 @@ void __init u300_init_devices(void)
 
u300_assign_physmem();
 
+   /* Initialize pinmuxing */
+   pinmux_register_mappings(u300_padmux_map,
+ARRAY_SIZE(u300_padmux_map));
+
/* Register subdevices on the I2C buses */
u300_i2c_register_board_devices();
 
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index adb0be0..fdeca2f 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -26,4 +26,11 @@ config DEBUG_PINCTRL
help
  Say Y here to add some extra checks and diagnostics to PINCTRL calls.
 
+config PINMUX_U300
+   bool "U300 pinmux driver"
+   depends on ARCH_U300
+   select PINMUX
+   help
+ Say Y here to enable the U300 pinmux driver
+
 endif
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 596ce9f..63d4241 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -4,3 +4,4 @@ ccflags-$(CONFIG_DEBUG_PINMUX)  += -DDEBUG
 
 obj-$(CONFIG_PINCTRL)  += core.o
 obj-$(CONFIG_PINMUX)   += pinmux.o
+obj-$(CONFIG_PINMUX_U300)  += pinmux-u300.o
diff --git a/drivers/pinctrl/pinmux-u300.c b/drivers/pinctrl/pinmux-u300.c
new file mode 100644
index 000..48e1ec7
--- /dev/null
+++ b/drivers/pinctrl/pinmux-u300.c
@@ -0,0 +1,932 @@
+/*
+ * Driver for the U300 pin controller
+ *
+ * Based on the original U300 padmux functions
+ * Copyright (C) 2009-2011 ST-Ericsson AB
+ * Author: Martin Persson 
+ * Author: Linus Walleij 
+ *
+ * The DB3350 design and control registers are oriented around pads rather than
+ * pins, so we enumerate the pads we can mux rather than actual pins. The pads
+ * are connected to different pins in different packaging types, so it would
+ * be confusing.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pinmux-u300.h"
+
+#define DRIVER_NAME "pinmux-u300"
+
+/*
+ * The DB3350 has 467 pads, I have enumerated the pads clockwise around the
+ * edges of the silicon, finger by finger. LTCORNER upper left is pad 0.
+ * Data taken from the PadRing chart, arranged like this:
+ *
+ *   0 . 104
+ * 466105
+ *   ..
+ *   ..
+ * 358224
+ *  357  225
+ */
+#define U300_NUM_PADS 467
+
+/* Pad names for the pinmux subsystem */
+const struct pinctrl_pin_desc __refdata u300_pads[] = {
+   /* Pads along the top edge of the chip */
+   PINCTRL_PIN(0, "P PAD VDD 28"),
+   PINCTRL_PIN(1, "P PAD GND 28"),
+   PINCTRL_PIN(2, "PO SIM RST N"),
+   PINCTRL_PIN(3, "VSSIO 25"),
+   PINCTRL_PIN(4, "VSSA ADDA ESDSUB"),
+   PINCTRL_PIN(5, "PWR VSSCOMMON"),
+   PINCTRL_PIN(6, "PI ADC I1 POS"),
+   PINCTRL_PIN(7, "PI ADC I1 NEG"),
+   PINCTRL_PIN(8, "PWR VSSAD

[PATCH 4/4 v6] mach-u300: activate pinmux driver, delete old padmux driver

[Linus Walleij]

From: Linus Walleij 

This hooks the pinmux driver into the U300 platform and deletes
the old machine-specific driver.

Signed-off-by: Linus Walleij 
---
 arch/arm/mach-u300/Kconfig   |2 +
 arch/arm/mach-u300/Makefile  |2 +-
 arch/arm/mach-u300/core.c|   12 +-
 arch/arm/mach-u300/include/mach/syscon.h |  136 ---
 arch/arm/mach-u300/mmc.c |   16 --
 arch/arm/mach-u300/padmux.c  |  367 --
 arch/arm/mach-u300/padmux.h  |   39 
 arch/arm/mach-u300/regulator.c   |   16 ++
 arch/arm/mach-u300/spi.c |   20 --
 drivers/pinctrl/pinmux-u300.c|5 +-
 10 files changed, 31 insertions(+), 584 deletions(-)
 delete mode 100644 arch/arm/mach-u300/padmux.c
 delete mode 100644 arch/arm/mach-u300/padmux.h

diff --git a/arch/arm/mach-u300/Kconfig b/arch/arm/mach-u300/Kconfig
index 32a7b0f..449fd6a 100644
--- a/arch/arm/mach-u300/Kconfig
+++ b/arch/arm/mach-u300/Kconfig
@@ -6,6 +6,8 @@ comment "ST-Ericsson Mobile Platform Products"
 
 config MACH_U300
bool "U300"
+   select PINCTRL
+   select PINMUX_U300
 
 comment "ST-Ericsson U300/U330/U335/U365 Feature Selections"
 
diff --git a/arch/arm/mach-u300/Makefile b/arch/arm/mach-u300/Makefile
index 8fd354a..2855381 100644
--- a/arch/arm/mach-u300/Makefile
+++ b/arch/arm/mach-u300/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel, U300 machine.
 #
 
-obj-y  := core.o clock.o timer.o padmux.o
+obj-y  := core.o clock.o timer.o
 obj-m  :=
 obj-n  :=
 obj-   :=
diff --git a/arch/arm/mach-u300/core.c b/arch/arm/mach-u300/core.c
index 2020bf9..67ae781 100644
--- a/arch/arm/mach-u300/core.c
+++ b/arch/arm/mach-u300/core.c
@@ -1536,6 +1536,14 @@ static struct coh901318_platform coh901318_platform = {
.max_channels = U300_DMA_CHANNELS,
 };
 
+static struct resource pinmux_resources[] = {
+   {
+   .start = U300_SYSCON_BASE,
+   .end   = U300_SYSCON_BASE + SZ_4K - 1,
+   .flags = IORESOURCE_MEM,
+   },
+};
+
 static struct platform_device wdog_device = {
.name = "coh901327_wdog",
.id = -1,
@@ -1665,10 +1673,10 @@ static struct platform_device *platform_devs[] 
__initdata = {
&gpio_device,
&nand_device,
&wdog_device,
-   &ave_device
+   &ave_device,
+   &pinmux_device,
 };
 
-
 /*
  * Interrupts: the U300 platforms have two pl190 ARM PrimeCells connected
  * together so some interrupts are connected to the first one and some
diff --git a/arch/arm/mach-u300/include/mach/syscon.h 
b/arch/arm/mach-u300/include/mach/syscon.h
index 7444f5c..6e84f07 100644
--- a/arch/arm/mach-u300/include/mach/syscon.h
+++ b/arch/arm/mach-u300/include/mach/syscon.h
@@ -234,91 +234,6 @@
 #define U300_SYSCON_ECCR_EMIF_1_RET_OUT_CLK_EN_N_DISABLE   (0x0004)
 #define U300_SYSCON_ECCR_EMIF_MEMCLK_RET_EN_N_DISABLE  (0x0002)
 #define U300_SYSCON_ECCR_EMIF_SDRCLK_RET_EN_N_DISABLE  (0x0001)
-/* PAD MUX Control register 1 (LOW) 16bit (R/W) */
-#define U300_SYSCON_PMC1LR (0x007C)
-#define U300_SYSCON_PMC1LR_MASK(0x)
-#define U300_SYSCON_PMC1LR_CDI_MASK(0xC000)
-#define U300_SYSCON_PMC1LR_CDI_CDI (0x)
-#define U300_SYSCON_PMC1LR_CDI_EMIF(0x4000)
-#ifdef CONFIG_MACH_U300_BS335
-#define U300_SYSCON_PMC1LR_CDI_CDI2(0x8000)
-#define U300_SYSCON_PMC1LR_CDI_WCDMA_APP_GPIO  (0xC000)
-#elif CONFIG_MACH_U300_BS365
-#define U300_SYSCON_PMC1LR_CDI_GPIO(0x8000)
-#define U300_SYSCON_PMC1LR_CDI_WCDMA   (0xC000)
-#endif
-#define U300_SYSCON_PMC1LR_PDI_MASK(0x3000)
-#define U300_SYSCON_PMC1LR_PDI_PDI (0x)
-#define U300_SYSCON_PMC1LR_PDI_EGG (0x1000)
-#define U300_SYSCON_PMC1LR_PDI_WCDMA   (0x3000)
-#define U300_SYSCON_PMC1LR_MMCSD_MASK  (0x0C00)
-#define U300_SYSCON_PMC1LR_MMCSD_MMCSD (0x)
-#define U300_SYSCON_PMC1LR_MMCSD_MSPRO (0x0400)
-#define U300_SYSCON_PMC1LR_MMCSD_DSP   (0x0800)
-#define U300_SYSCON_PMC1LR_MMCSD_WCDMA (0x0C00)
-#define U300_SYSCON_PMC1LR_ETM_MASK(0x0300)
-#define U300_SYSCON_PMC1LR_ETM_ACC (0x)
-#define U300_SYSCON_PMC1LR_ETM_APP (0x0100)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_MASK (0x00C0)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_STATIC   (0x)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_NFIF (0x0040)
-#define U300_SYSCON_PMC1LR_EMIF_1_CS2_SDRA

[PATCH 3/4 v6] amba: request muxing for PrimeCell devices

[Linus Walleij]

From: Linus Walleij 

This makes the AMBA PrimeCell drivers request padmuxing for
themselves in the same manner as clocks and voltage is currently
requested.

Signed-off-by: Linus Walleij 
---
 drivers/amba/bus.c   |   49 -
 include/linux/amba/bus.h |2 +
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index d74926e..bd0516c 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -474,6 +474,40 @@ static void amba_put_disable_vcore(struct amba_device 
*pcdev)
}
 }
 
+static int amba_get_enable_pinmux(struct amba_device *pcdev)
+{
+   struct pinmux *pmx = pinmux_get(&pcdev->dev, NULL);
+   int ret;
+
+   pcdev->pmx = pmx;
+
+   if (IS_ERR(pmx)) {
+   /* It is OK not to supply a pinmux regulator */
+   if (PTR_ERR(pmx) == -ENODEV)
+   return 0;
+   return PTR_ERR(pmx);
+   }
+
+   ret = pinmux_enable(pmx);
+   if (ret) {
+   pinmux_put(pmx);
+   pcdev->pmx = ERR_PTR(-ENODEV);
+   }
+
+   return ret;
+}
+
+static void amba_put_disable_pinmux(struct amba_device *pcdev)
+{
+   struct pinmux *pmx = pcdev->pmx;
+
+   if (!IS_ERR(pmx)) {
+   pinmux_disable(pmx);
+   pinmux_put(pmx);
+   }
+}
+
+
 /*
  * These are the device model conversion veneers; they convert the
  * device model structures to our more specific structures.
@@ -486,13 +520,22 @@ static int amba_probe(struct device *dev)
int ret;
 
do {
-   ret = amba_get_enable_vcore(pcdev);
+   ret = amba_get_enable_pinmux(pcdev);
if (ret)
break;
 
+   ret = amba_get_enable_vcore(pcdev);
+   if (ret) {
+   amba_put_disable_pinmux(pcdev);
+   break;
+   }
+
ret = amba_get_enable_pclk(pcdev);
-   if (ret)
+   if (ret) {
+   amba_put_disable_pinmux(pcdev);
+   amba_put_disable_vcore(pcdev);
break;
+   }
 
ret = pcdrv->probe(pcdev, id);
if (ret == 0)
@@ -500,6 +543,7 @@ static int amba_probe(struct device *dev)
 
amba_put_disable_pclk(pcdev);
amba_put_disable_vcore(pcdev);
+   amba_put_disable_pinmux(pcdev);
} while (0);
 
return ret;
@@ -513,6 +557,7 @@ static int amba_remove(struct device *dev)
 
amba_put_disable_pclk(pcdev);
amba_put_disable_vcore(pcdev);
+   amba_put_disable_pinmux(pcdev);
 
return ret;
 }
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index fcbbe71..35f1193 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define AMBA_NR_IRQS   2
 #define AMBA_CID   0xb105f00d
@@ -30,6 +31,7 @@ struct amba_device {
struct resource res;
struct clk  *pclk;
struct regulator*vcore;
+   struct pinmux   *pmx;
u64 dma_mask;
unsigned intperiphid;
unsigned intirq[AMBA_NR_IRQS];
-- 
1.7.3.2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

[PATCH 0/4] pin controller subsystem v6

[Linus Walleij]

From: Linus Walleij 

This is the sixth iteration of the controller subsystem, most
changes are described in the first patch, copied here for reference:

ChangeLog v5->v6:

- Create an abstract pin group concept that can sort pins into
  named and enumerated groups no matter what the use of these
  groups may be, one possible usecase is a group of pins being
  muxed in or so. The intention is however to also use these
  groups for other pin control activities.

- Make it compulsory for pinmux functions to associate with
  at least one group, so the abstract pin group concept is used
  to define the groups of pins affected by a pinmux function.
  The pinmux driver interface has been altered so as to enforce
  a function to list applicable groups per function.

- Provide an optional .group entry in the pinmux machine map
  so the map can select beteween different available groups
  to be used with a certain function.

- Consequent changes all over the place so that e.g. debugfs
  present reasonable information about the world.

- Drop the per-pin mux (*config) function in the pinmux_ops
  struct - I was afraid that this would start to be used for
  things totally unrelated to muxing, we can introduce that to
  the generic struct pinctrl_ops if needed. I want to keep
  muxing orthogonal to other pin control subjects and not mix
  these things up.

Linus Walleij (4):
  drivers: create a pin control subsystem v6
  pinmux: add a driver for the U300 pinmux
  amba: request muxing for PrimeCell devices
  mach-u300: activate pinmux driver, delete old padmux driver

 Documentation/ABI/testing/sysfs-class-pinmux |   11 +
 Documentation/pinctrl.txt|  876 
 MAINTAINERS  |5 +
 arch/arm/mach-u300/Kconfig   |2 +
 arch/arm/mach-u300/Makefile  |2 +-
 arch/arm/mach-u300/core.c|   38 +-
 arch/arm/mach-u300/include/mach/syscon.h |  136 
 arch/arm/mach-u300/mmc.c |   16 -
 arch/arm/mach-u300/padmux.c  |  367 --
 arch/arm/mach-u300/padmux.h  |   39 --
 arch/arm/mach-u300/regulator.c   |   16 +
 arch/arm/mach-u300/spi.c |   20 -
 drivers/Kconfig  |4 +
 drivers/Makefile |2 +
 drivers/amba/bus.c   |   49 ++-
 drivers/pinctrl/Kconfig  |   36 +
 drivers/pinctrl/Makefile |7 +
 drivers/pinctrl/core.c   |  599 +
 drivers/pinctrl/core.h   |   24 +
 drivers/pinctrl/pinmux-u300.c|  931 ++
 drivers/pinctrl/pinmux-u300.h|  141 
 drivers/pinctrl/pinmux.c |  822 +++
 drivers/pinctrl/pinmux.h |4 +
 include/linux/amba/bus.h |2 +
 include/linux/pinctrl/machine.h  |   73 ++
 include/linux/pinctrl/pinctrl.h  |  172 +
 include/linux/pinctrl/pinmux.h   |  124 
 27 files changed, 3935 insertions(+), 583 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-class-pinmux
 create mode 100644 Documentation/pinctrl.txt
 delete mode 100644 arch/arm/mach-u300/padmux.c
 delete mode 100644 arch/arm/mach-u300/padmux.h
 create mode 100644 drivers/pinctrl/Kconfig
 create mode 100644 drivers/pinctrl/Makefile
 create mode 100644 drivers/pinctrl/core.c
 create mode 100644 drivers/pinctrl/core.h
 create mode 100644 drivers/pinctrl/pinmux-u300.c
 create mode 100644 drivers/pinctrl/pinmux-u300.h
 create mode 100644 drivers/pinctrl/pinmux.c
 create mode 100644 drivers/pinctrl/pinmux.h
 create mode 100644 include/linux/pinctrl/machine.h
 create mode 100644 include/linux/pinctrl/pinctrl.h
 create mode 100644 include/linux/pinctrl/pinmux.h

-- 
1.7.3.2


___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

[Linus Walleij]

Damn gmail punished me when writing the reply, sent by mistake :-(

And I intended to post v6 first.

These parts were being typed as I screwed up:

On Thu, Sep 1, 2011 at 10:59 AM, Linus Walleij  wrote:

> function and group names shall match what is
> presented from the pin controller driver.
>
> You can thing of this as SQL:
>
> SELECT ctrl_dev_name,
> TOP 1
>  FROM MAPS
>  WHERE dev_name = device_name
>  AND ctrl_dev_name = ctrl_dev_name
>  AND function = function
>  AND group = group

I don't know the exact SQL syntax anymore, thing
is that it selects one matching row only.

>> mmc0    8-bit A         mmc0
>> mmc0    8-bit B         mmc0
>> mmc0    8-bit C         mmc0
>
> I assume you mean that semantically this shall
> be a 1..* relation, so that if I say:
>
> pmx = pinmux_get(&dev, "8-bit");
>
> Then all pins in the union {A, B, C} shall be
> allocated and enabled/disabled simultaneously.
>
> so it'd be like the database equivalent:

What I wanted to illustrate here is that the database
return multiple matching rows.

Anyway, I'm onto that.

I will need Arnds or similars advice on it so we don't
grow a lib/mysql into the kernel with this kind of
schemes and get slammed for overcomplicating
things when trying to merge the beast.

So I'm still a bit reluctant about this part  :-/

> Then the pinmux_map maps usually one but sometimes
> more of these {function, position} tuples to the device.

{ function, group } it is.

> And, you also request the currently not implemented
> extenstion that a mux can match multiple map entries.
>
> I'll fix.

Or rather, I'll try.

>> 2) "Positions" are defined per "function", rather than as a global concept.
>>
>> This leads to positions having meaningless integer names. As such,
>> constructing the mapping table will be error-prone; who could remember
>> that position 0 is a 2-bit bus using a certain set of pins, yet position
>> 1 is an 8-bit bus using a different set of pins? I suppose textual names
>> might help here. However, by replacing the concept of positions with
>> multiple explicit entries in the mapping table (as in my example above),
>> that problem is solved; we name the pins (or pingroups) to which we apply
>> the driver-level function in each entry, thus it's more self-documenting.
>
> Again I can replace position integers with strings if that is what
> you want?

Forget this, part of earlier reply.

positions are replaced with groups, which have names.

>> Driver-supplied data 4)
>>
>> Table of legal functions per pin/pingroup; each entry containing:
>> * Name of pin or pingroup
>
> OK I have this now, e.g. inspect the file
> /pinctrl.0/groups

Should be pingroups, and output was correct in the first letter.

>> Board-supplied data 1)
>>
>> Mapping table, each entry containing:
>> * Driver name/pointer
>> * Name of function seen by driver
>> * Pin/pingroup name to configure
>> * Name of driver function to apply to pin/pingroup

This I think is what we have now.

>> Note that I assume there may be multiple rows for any combination of the
>> first two fields in this table, and that all will be operated on by a
>> single pinmux_get()/pinmux_enable() call.

We don't have these multiple rows yet. But I'll try
to implement that.

>> Some enhancements in the above list of tables over previous times that I've
>> talked about this:
>>
>> * Created a separate optional table for a list of pingroups, thus not
>> burdening SoCs other than Tegra with the pingroup concept.

Nah I made it compulsory for pinmux drivers to define their
affected group of pins using an associated abstract pin group.
Makes more sense to me and makes for code reuse if the
groups are used for other things.

>> * Allow either a pin or pingroup name in the driver's "table of legal
>> functions per pin" and the "mapping table"; core can simply look through
>> the pingroup table if present, then fall back to looking in pin table,
>> when determining what a pin/pingroup name means.

Simplified by mandating to use groups. I hope.
A pin table would be equivalent to a group anyway,
just not having its own data structure.

>> * I assume that entries in the "table of pins" or "table of pingroups"
>> might have no corresponding entries in " Table of legal functions per
>> pin"; in this case, those pin/pingroup names would only be useful for
>> pinmux_config() to operate on.

I made it compulsory to associate at least one group of
pins to each function, easier to grasp.

>> P.S. I'll be on vacation 9/2-9/17. I'm not sure if I'll have any form of
>> network access during this time or not. You may not see many more pinmux
>> comments from me during that time.

No problem, I have all life to sort this out.

Thanks,
Linus Walleij

___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev

Re: [PATCH 1/4 v5] drivers: create a pin control subsystem v5

[Linus Walleij]

On Mon, Aug 29, 2011 at 11:32 PM, Stephen Warren  wrote:

> 1) There is still a 1:1 correspondence between what a function in the
> pinmux core<->driver interface, and the pinmux mapping table. I believe
> we need a 1:n correspondence.

Yes I know that, but the positions were never
about solving that issue.

What you are requesting (just like earlier) is
that one requlator_get() should be able to
retrieve multiple map entries and enable/disable
them.

I 've been working on that, it's just a bit tricky.

> i.e. rather than:
>
> driver function/position list:
> function@position pins
> - 
> mmc0@0            0, 1, 2, 3
> mmc0@1            0, 1, 2, 3, 4, 5
> mmc0@2            0, 1, 2, 3, 4, 5, 6, 7, 8, 9
>
> core mapping table:
> driver  name  function@position
> --    -
> mmc0    2-bit mmc0@0
> mmc0    4-bit mmc0@1
> mmc0    8-bit mmc0@2

There is no combined function@postion,
these are two were separate fields in the
struct pinmux_map.

What I wanted to express was the noted feature of the
hardware to have the same function in several positions
simply, believing it would be more intuitive.

But since the positions does not seem to be the
answer to the question I've just ripped them out
again. It is now (v6) replaced with a pin group
concept which I hope is closer to what you want.

> I'd far rather see:
>
> driver function list:
> function
> -
> mmc0

Can now be found in
/pinctrl/pinctrl.0/pinmux-functions

It will now show the list of different groups that the
function can use.

So a function has 1..* groups associated with it.

Example from U300:

root@ME:/debug/pinctrl/pinctrl.0 cat pinmux-functions
function: power, groups = [ powergrp ]
function: uart0, groups = [ uart0grp ]
function: mmc0, groups = [ mmc0grp ]
function: spi0, groups = [ spi0grp ]

Just one group per function here but can be many.

> driver pin/pingrup list: (names of pins or pingroups):
> pingroup
> 
> A
> B
> C

Can now be found in
/pinctrl/pinctrl.0/pingroups

Example from U300:

root@ME:/debug/pinctrl/pinctrl.0 cat pingroups
registered pin groups:
group: powergrp, pins = [ 0 1 3 31 46 47 49 50 61 62 63 64 78 79 80 81
92 93 94 95 101 102 103 104 115 116 117 118 130 131 132 133 145 146
147 148 159 160 172 173 174 175 187 188 189 190 201 202 211 212 213
214 215 218 223 224 225 226 231 232 237 238 239 240 245 246 251 252
256 257 258 259 264 265 270 271 276 277 278 279 284 285 290 291 295
296 299 300 301 302 303 309 310 311 312 319 320 321 322 329 330 331
332 341 342 343 344 358 359 360 361 372 373 374 375 388 389 390 391
402 403 404 405 413 414 415 416 427 428 429 430 443 444 455 456 457
458 ]
group: uart0grp, pins = [ 134 135 136 137 ]
group: mmc0grp, pins = [ 166 167 168 169 170 171 176 177 ]
group: spi0grp, pins = [ 420 421 422 423 424 425 ]

Notice that it's not prefixed with the string
"pinmux-", it's just a number of groups of pins,
which can be used for anything, one usecase is
muxing. So I now have an abstract pin group
concept and the pinmux function has atleast
one such group associated.

> core mapping table:
> driver  name  position  function
> --      -
> mmc0    2-bit A         mmc0
> mmc0    4-bit A         mmc0
> mmc0    4-bit B         mmc0
> mmc0    8-bit A         mmc0
> mmc0    8-bit B         mmc0
> mmc0    8-bit C         mmc0

Now the struct pinmux_map entries look
like this:

struct pinmux_map {
const char *name;
struct device *ctrl_dev;
const char *ctrl_dev_name;
const char *function;
const char *group;
struct device *dev;
const char *dev_name;
};

Correspondance per above would be:

dev_name, name, group, function

function and group names shall match what is
presented from the pin controller driver.

You can thing of this as SQL:

SELECT ctrl_dev_name,
TOP 1
  FROM MAPS
  WHERE dev_name = device_name
  AND ctrl_dev_name = ctrl_dev_name
  AND function = function
  AND group = group

(the struct device * entries are for the shiny world
where we can access all struct device * at boot or
so)

Then it's the first point about multiple maps
per mux again I guess, when you write like this:

> mmc08-bit A mmc0
> mmc08-bit B mmc0
> mmc08-bit C mmc0

I assume you mean that semantically this shall
be a 1..* relation, so that if I say:

pmx = pinmux_get(&dev, "8-bit");

Then all pins in the union {A, B, C} shall be
allocated and enabled/disabled simultaneously.

so it'd be like the database equivalent:

I am working on that...

> Note again that I'm assuming above that the driver-supplied function and
> pingroup list included all possible options the SoC HW supports, whereas
> the mapping table would include just those configurations ever actually
> used by the particular board the code is executed upon; from board files
> or devicetree data.

This is my current working assumption also.

The pinmux driver should nominally expose all functions in all