git tree

git tree

[Ryan]

Hi,
  Looking at the linux-omap tree using the gitweb interface. Apart
from the "master" branch and tags.
  why do we have lots of branches? How and when do they intertact with
each other.


17 hours ago omap1-upstream shortlog | log | tree
17 hours ago omap2-upstream shortlog | log | tree
17 hours ago omap3-boards shortlog | log | tree
17 hours ago omap3-upstream shortlog | log | tree
17 hours ago omap4 shortlog | log | tree
17 hours ago pm shortlog | log | tree
19 hours ago omap-headers shortlog | log | tree
19 hours ago omap-upstream shortlog | log | tree
19 hours ago omap-fixes shortlog | log | tree
47 hours ago master shortlog | log | tree
2 weeks ago omap-decimate shortlog | log | tree
2 weeks ago omapfb-upstream shortlog | log | tree
2 weeks ago omap-pool shortlog | log | tree
3 weeks ago for-next-2.6.30 shortlog | log | tree
4 weeks ago for-next shortlog | log | tree
4 weeks ago iommu shortlog | log | tree
2 months ago omap-2.6.29 shortlog | log | tree
3 months ago clks-testing shortlog | log | tree
3 months ago delete shortlog | log | tree
4 months ago omap-2.6.28 shortlog | log | tree
4 months ago tidspbridge shortlog | log | tree
5 months ago dspgateway shortlog | log | tree
5 months ago linus shortlog | log | tree
6 months ago musb shortlog | log | tree


Can anyone explain what exactly goes into each of them?
Some are straight forward like pm, usb, tidspbridge, gateway. not sure
about for-next-2.6.30, omap-fixes.

Trying to understand things/mode of development in here.


Thank you,
Ryan
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git tree

[Tony Lindgren]

Hi,

* Ryan <ryanphilips19@googlemail.com> [090624 12:42]:
> Hi,
>   Looking at the linux-omap tree using the gitweb interface. Apart
> from the "master" branch and tags.
>   why do we have lots of branches? How and when do they intertact with
> each other.
> 
> 
> 17 hours ago omap1-upstream shortlog | log | tree
> 17 hours ago omap2-upstream shortlog | log | tree
> 17 hours ago omap3-boards shortlog | log | tree
> 17 hours ago omap3-upstream shortlog | log | tree
> 17 hours ago omap4 shortlog | log | tree
> 17 hours ago pm shortlog | log | tree
> 19 hours ago omap-headers shortlog | log | tree
> 19 hours ago omap-upstream shortlog | log | tree
> 19 hours ago omap-fixes shortlog | log | tree
> 47 hours ago master shortlog | log | tree
> 2 weeks ago omap-decimate shortlog | log | tree
> 2 weeks ago omapfb-upstream shortlog | log | tree
> 2 weeks ago omap-pool shortlog | log | tree
> 3 weeks ago for-next-2.6.30 shortlog | log | tree
> 4 weeks ago for-next shortlog | log | tree
> 4 weeks ago iommu shortlog | log | tree
> 2 months ago omap-2.6.29 shortlog | log | tree
> 3 months ago clks-testing shortlog | log | tree
> 3 months ago delete shortlog | log | tree
> 4 months ago omap-2.6.28 shortlog | log | tree
> 4 months ago tidspbridge shortlog | log | tree
> 5 months ago dspgateway shortlog | log | tree
> 5 months ago linus shortlog | log | tree
> 6 months ago musb shortlog | log | tree
> 
> 
> Can anyone explain what exactly goes into each of them?
> Some are straight forward like pm, usb, tidspbridge, gateway. not sure
> about for-next-2.6.30, omap-fixes.

More or less the various branches are topic branches of patches
going to the mainline kernel. For example, omap-fixes contains fixes to
be sent during the -rc cycle, omap-upstream contains omap common patches
for the next merge window, omap1-upstream omap1 specific patches for
the next merge window and so on.

The master branch is more or less merge of all the topic branches.
Currently missing from it are the pm branch and the dss2 branch.

> Trying to understand things/mode of development in here.

Hope this helps. In general, your should now be able to do almost
all the patches against Linus' mainline kernel. Of course until
we get pm and dss2 into the mainline kernel, those patches need to
be done against pm and dss2 branches.

So everybody, where possible, please base all the patches against
Linus' kernel stable something or -rc someting, that way they are
easy to merge in.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: git tree

[Pandita, Vikram]

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony
>
>Hi,
>
>* Ryan <ryanphilips19@googlemail.com> [090624 12:42]:
>> Hi,
>>   Looking at the linux-omap tree using the gitweb interface. Apart
>> from the "master" branch and tags.
>>   why do we have lots of branches? How and when do they intertact with
>> each other.
>>
>> Can anyone explain what exactly goes into each of them?
>> Some are straight forward like pm, usb, tidspbridge, gateway. not sure
>> about for-next-2.6.30, omap-fixes.
>
>More or less the various branches are topic branches of patches
>going to the mainline kernel. For example, omap-fixes contains fixes to
>be sent during the -rc cycle, omap-upstream contains omap common patches
>for the next merge window, omap1-upstream omap1 specific patches for
>the next merge window and so on.
>
>The master branch is more or less merge of all the topic branches.
>Currently missing from it are the pm branch and the dss2 branch.
>
>> Trying to understand things/mode of development in here.
>
>Hope this helps. In general, your should now be able to do almost
>all the patches against Linus' mainline kernel. Of course until
>we get pm and dss2 into the mainline kernel, those patches need to
>be done against pm and dss2 branches.
>
>So everybody, where possible, please base all the patches against
>Linus' kernel stable something or -rc someting, that way they are
>easy to merge in.

Are you recommending that future patches posted to l-o list should be based of kernel.org 
and not master of l-o?

>
>Regards,
>
>Tony
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git tree

[Tony Lindgren]

* Pandita, Vikram <vikram.pandita@ti.com> [090625 17:08]:
> 
> 
> >-----Original Message-----
> >From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Tony
> >
> >Hi,
> >
> >* Ryan <ryanphilips19@googlemail.com> [090624 12:42]:
> >> Hi,
> >>   Looking at the linux-omap tree using the gitweb interface. Apart
> >> from the "master" branch and tags.
> >>   why do we have lots of branches? How and when do they intertact with
> >> each other.
> >>
> >> Can anyone explain what exactly goes into each of them?
> >> Some are straight forward like pm, usb, tidspbridge, gateway. not sure
> >> about for-next-2.6.30, omap-fixes.
> >
> >More or less the various branches are topic branches of patches
> >going to the mainline kernel. For example, omap-fixes contains fixes to
> >be sent during the -rc cycle, omap-upstream contains omap common patches
> >for the next merge window, omap1-upstream omap1 specific patches for
> >the next merge window and so on.
> >
> >The master branch is more or less merge of all the topic branches.
> >Currently missing from it are the pm branch and the dss2 branch.
> >
> >> Trying to understand things/mode of development in here.
> >
> >Hope this helps. In general, your should now be able to do almost
> >all the patches against Linus' mainline kernel. Of course until
> >we get pm and dss2 into the mainline kernel, those patches need to
> >be done against pm and dss2 branches.
> >
> >So everybody, where possible, please base all the patches against
> >Linus' kernel stable something or -rc someting, that way they are
> >easy to merge in.
> 
> Are you recommending that future patches posted to l-o list should be based of kernel.org 
> and not master of l-o?

Yeah, for all the patches that do not have dependencies to other topic
branches such as pm, dss2.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git tree

[Zha, Qipeng]

Hi 

I got pwm subsystem git tree info as below from v3.19-rc6 MAINTAINER And I clone it, found the version is v3.12 Is the tree current maintain tree ? or there is a new one, thanks.

git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git
 

Best wishes
Qipeng

-----Original Message-----
From: linux-pwm-owner@vger.kernel.org [mailto:linux-pwm-owner@vger.kernel.org] On Behalf Of Shawn Guo
Sent: Monday, March 02, 2015 8:32 PM
To: Gaetan Hug
Cc: thierry.reding@gmail.com; linux-pwm@vger.kernel.org; linux-kernel@vger.kernel.org; fabio.estevam@freescale.com
Subject: Re: [PATCH] pwm: mxs: fix period divider computation

On Wed, Feb 18, 2015 at 02:06:34PM +0100, Gaetan Hug wrote:
> The driver computes which clock divider it sould be using from the 
> requested period. This computation assumes that the link between the 
> register value and the actual divider value is raising 2 to the power 
> of the registry value.
> 
>     div = 1 << regvalue
> 
> This is true only for the first 5 values out of 8. Next values are 64,
> 256 and, 1024 - instead of 32, 64, 128.

Just checked i.MX28 Reference Manual, and yes, this is the case.

> This affects only the users requesting a period > 0.04369s.
> 
> Replace the computation with a look-up table.

Your SoB is missing here.  Otherwise,

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> ---
>  drivers/pwm/pwm-mxs.c |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c index
> f75ecb0..c65e183 100644
> --- a/drivers/pwm/pwm-mxs.c
> +++ b/drivers/pwm/pwm-mxs.c
> @@ -35,6 +35,8 @@
>  #define  PERIOD_CDIV(div)	(((div) & 0x7) << 20)
>  #define  PERIOD_CDIV_MAX	8
>  
> +static unsigned const int cdiv[PERIOD_CDIV_MAX] = {1, 2, 4, 8, 16, 
> +64, 256, 1024};
> +
>  struct mxs_pwm_chip {
>  	struct pwm_chip chip;
>  	struct clk *clk;
> @@ -54,13 +56,13 @@ static int mxs_pwm_config(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>  
>  	rate = clk_get_rate(mxs->clk);
>  	while (1) {
> -		c = rate / (1 << div);
> +		c = rate / cdiv[div];
>  		c = c * period_ns;
>  		do_div(c, 1000000000);
>  		if (c < PERIOD_PERIOD_MAX)
>  			break;
>  		div++;
> -		if (div > PERIOD_CDIV_MAX)
> +		if (div >= PERIOD_CDIV_MAX)
>  			return -EINVAL;
>  	}
>  
> --
> 1.7.10.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git tree

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

On Thu, Mar 05, 2015 at 07:53:16AM +0000, Zha, Qipeng wrote:
> Hi 
> 
> I got pwm subsystem git tree info as below from v3.19-rc6 MAINTAINER
> And I clone it, found the version is v3.12 Is the tree current
> maintain tree ? or there is a new one, thanks.
> 
> git git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git

You're probably looking at the master branch, but I don't update that.
Use the for-next branch, which is what gets merged into linux-next.

Thierry

> -----Original Message-----
> From: linux-pwm-owner@vger.kernel.org [mailto:linux-pwm-owner@vger.kernel.org] On Behalf Of Shawn Guo
> Sent: Monday, March 02, 2015 8:32 PM
> To: Gaetan Hug
> Cc: thierry.reding@gmail.com; linux-pwm@vger.kernel.org; linux-kernel@vger.kernel.org; fabio.estevam@freescale.com
> Subject: Re: [PATCH] pwm: mxs: fix period divider computation
> 
> On Wed, Feb 18, 2015 at 02:06:34PM +0100, Gaetan Hug wrote:
> > The driver computes which clock divider it sould be using from the 
> > requested period. This computation assumes that the link between the 
> > register value and the actual divider value is raising 2 to the power 
> > of the registry value.
> > 
> >     div = 1 << regvalue
> > 
> > This is true only for the first 5 values out of 8. Next values are 64,
> > 256 and, 1024 - instead of 32, 64, 128.
> 
> Just checked i.MX28 Reference Manual, and yes, this is the case.
> 
> > This affects only the users requesting a period > 0.04369s.
> > 
> > Replace the computation with a look-up table.
> 
> Your SoB is missing here.  Otherwise,
> 
> Acked-by: Shawn Guo <shawn.guo@linaro.org>
> 
> > ---
> >  drivers/pwm/pwm-mxs.c |    6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pwm/pwm-mxs.c b/drivers/pwm/pwm-mxs.c index
> > f75ecb0..c65e183 100644
> > --- a/drivers/pwm/pwm-mxs.c
> > +++ b/drivers/pwm/pwm-mxs.c
> > @@ -35,6 +35,8 @@
> >  #define  PERIOD_CDIV(div)	(((div) & 0x7) << 20)
> >  #define  PERIOD_CDIV_MAX	8
> >  
> > +static unsigned const int cdiv[PERIOD_CDIV_MAX] = {1, 2, 4, 8, 16, 
> > +64, 256, 1024};
> > +
> >  struct mxs_pwm_chip {
> >  	struct pwm_chip chip;
> >  	struct clk *clk;
> > @@ -54,13 +56,13 @@ static int mxs_pwm_config(struct pwm_chip *chip, 
> > struct pwm_device *pwm,
> >  
> >  	rate = clk_get_rate(mxs->clk);
> >  	while (1) {
> > -		c = rate / (1 << div);
> > +		c = rate / cdiv[div];
> >  		c = c * period_ns;
> >  		do_div(c, 1000000000);
> >  		if (c < PERIOD_PERIOD_MAX)
> >  			break;
> >  		div++;
> > -		if (div > PERIOD_CDIV_MAX)
> > +		if (div >= PERIOD_CDIV_MAX)
> >  			return -EINVAL;
> >  	}
> >  
> > --
> > 1.7.10.4
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pwm" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

git tree

[Zha, Qipeng]

Hi Dear

Could you confirm the git tree is below to maintain platform x86 driver ? If not , could you tell me which one Thanks.
It report non reachable when I clone it.
git clone https://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git



Best wishes
Qipeng

-----Original Message-----
From: platform-driver-x86-owner@vger.kernel.org [mailto:platform-driver-x86-owner@vger.kernel.org] On Behalf Of Darren Hart
Sent: Wednesday, March 04, 2015 12:44 AM
To: Krzysztof Kozlowski
Cc: Sebastian Reichel; Dmitry Eremin-Solenikov; David Woodhouse; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org; Cezary Jackiewicz; platform-driver-x86@vger.kernel.org; Kyungmin Park; Marek Szyprowski
Subject: Re: [PATCH v4 11/20] power_supply: Change ownership from driver to core

On Thu, Feb 26, 2015 at 12:31:13PM +0100, Krzysztof Kozlowski wrote:
> On czw, 2015-02-26 at 12:28 +0100, Krzysztof Kozlowski wrote:
> > On śro, 2015-02-25 at 22:14 -0800, Darren Hart wrote:
> > > On Thu, Feb 26, 2015 at 01:45:22AM +0100, Sebastian Reichel wrote:
> > 
> > (...)
> > 
> > > > I would like to merge this via the power supply subsystem. Some 
> > > > of the files being patched are not under my maintainence, 
> > > > though. It would be nice if I get an Acked-By from their maintainers.
> > > > 
> > > > As far as I can see this patch is currently missing feedback from:
> > > > 
> > > > arch/x86/platform/olpc: x86 Maintainers
> > > > drivers/acpi: Rafael J. Wysocki, Len Brown
> > > > drivers/hid: Jiri Kosina
> > > > drivers/platform/x86: Darren Hart
> > > 
> > > For compal-laptop.c:
> > > 
> > > Acked-by: Darren Hart <dvhart@linux.intel.com>
> 
> (previous mail sent by mistake)
> 
> Hi Darren,
> 
> Could you also look at my other fixes sent few days ago:
> https://lkml.org/lkml/2015/2/20/158
> compal-laptop: Check return value of power_supply_register
> 
> It touches the same line so the patchset power-supply-rework depends 
> on it to avoid conflicts. If the fix looks OK, maybe it could go 
> through Sebastian's tree with your ack?

Done, and apologies for the delay. Going through Sebastien is preferred, thanks.

--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

git tree

[Zha, Qipeng]

Hi Dear

Could you confirm the git tree is below to maintain platform x86 driver ? If not , could you tell me which one Thanks.
It report non reachable when I clone it.
git clone https://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git



Best wishes
Qipeng

-----Original Message-----
From: platform-driver-x86-owner@vger.kernel.org [mailto:platform-driver-x86-owner@vger.kernel.org] On Behalf Of Darren Hart
Sent: Wednesday, March 04, 2015 12:44 AM
To: Krzysztof Kozlowski
Cc: Sebastian Reichel; Dmitry Eremin-Solenikov; David Woodhouse; linux-pm@vger.kernel.org; linux-kernel@vger.kernel.org; Cezary Jackiewicz; platform-driver-x86@vger.kernel.org; Kyungmin Park; Marek Szyprowski
Subject: Re: [PATCH v4 11/20] power_supply: Change ownership from driver to core

On Thu, Feb 26, 2015 at 12:31:13PM +0100, Krzysztof Kozlowski wrote:
> On czw, 2015-02-26 at 12:28 +0100, Krzysztof Kozlowski wrote:
> > On śro, 2015-02-25 at 22:14 -0800, Darren Hart wrote:
> > > On Thu, Feb 26, 2015 at 01:45:22AM +0100, Sebastian Reichel wrote:
> > 
> > (...)
> > 
> > > > I would like to merge this via the power supply subsystem. Some 
> > > > of the files being patched are not under my maintainence, 
> > > > though. It would be nice if I get an Acked-By from their maintainers.
> > > > 
> > > > As far as I can see this patch is currently missing feedback from:
> > > > 
> > > > arch/x86/platform/olpc: x86 Maintainers
> > > > drivers/acpi: Rafael J. Wysocki, Len Brown
> > > > drivers/hid: Jiri Kosina
> > > > drivers/platform/x86: Darren Hart
> > > 
> > > For compal-laptop.c:
> > > 
> > > Acked-by: Darren Hart <dvhart@linux.intel.com>
> 
> (previous mail sent by mistake)
> 
> Hi Darren,
> 
> Could you also look at my other fixes sent few days ago:
> https://lkml.org/lkml/2015/2/20/158
> compal-laptop: Check return value of power_supply_register
> 
> It touches the same line so the patchset power-supply-rework depends 
> on it to avoid conflicts. If the fix looks OK, maybe it could go 
> through Sebastian's tree with your ack?

Done, and apologies for the delay. Going through Sebastien is preferred, thanks.

--
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@vger.kernel.org More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git tree

[Darren Hart]

On Thu, Mar 05, 2015 at 07:47:18AM +0000, Zha, Qipeng wrote:
> Hi Dear
> 
> Could you confirm the git tree is below to maintain platform x86 driver ? If not , could you tell me which one Thanks.
> It report non reachable when I clone it.
> git clone https://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.git

You can alsways find the latest information in the MAINTAINERS file:

$ grep platform-drivers MAINTAINERS
T:      git git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

git tree

[Luís Vitório Cargnini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear fellows,
Please which git tree I should use ?
I'm using the kernel.org tree and the latest tag is

S v2.6.22-rc4        5b78c77092a6  Linus 2.6.22-rc4

cg-status
Heads:
    >master     2a1c4dfbbe9fd7f756e62579bb42d341d340bd0f
   R origin     2a1c4dfbbe9fd7f756e62579bb42d341d340bd0f
- --
-
------------------------------------------------------------------------------
Thanks && Regards
Msc. Bsc. Luís Vitório Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 - Building 30
P.O. Box: 90619-900 - Porto Alegre/RS
Phone: +55 51 3320 3500  extension: 7696
-
---------------------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGrdYcKNrSZaSIZoURAkWKAJ0Yc0IKqIBe84ctxtyzgWrZ0ezRjACePtg9
7y+UkKTe6TJYhR3WgbfnRuY=
=nPfw
-----END PGP SIGNATURE-----

Re: git tree

[Felipe Balbi]

Hi,

On 7/30/07, Luís Vitório Cargnini <lvcargnini@ieee.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear fellows,
> Please which git tree I should use ?
> I'm using the kernel.org tree and the latest tag is

And which other tree should you use??
This is the one and only linux-omap tree, you can get a mirror from
monta vista's servers, but it's the same tree anyway.

This tree is a bit outdated since tony still on vacations afaik... but
soon it'll be upgraded.

regards

>
> S v2.6.22-rc4        5b78c77092a6  Linus 2.6.22-rc4
>
> cg-status
> Heads:
>     >master     2a1c4dfbbe9fd7f756e62579bb42d341d340bd0f
>    R origin     2a1c4dfbbe9fd7f756e62579bb42d341d340bd0f
> - --
> -
> ------------------------------------------------------------------------------
> Thanks && Regards
> Msc. Bsc. Luís Vitório Cargnini
> IEEE Member
> Electrical Engineer Faculty @ PUCRS
> Ipiranga Avenue, 6681 - Building 30
> P.O. Box: 90619-900 - Porto Alegre/RS
> Phone: +55 51 3320 3500  extension: 7696
> -
> ---------------------------------------------------------------------------------
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGrdYcKNrSZaSIZoURAkWKAJ0Yc0IKqIBe84ctxtyzgWrZ0ezRjACePtg9
> 7y+UkKTe6TJYhR3WgbfnRuY=
> =nPfw
> -----END PGP SIGNATURE-----
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>


-- 
Best Regards,

Felipe Balbi
felipebalbi@users.sourceforge.net

Git tree

[Veda N]

Hi,
   I am using the latest git tree. MTD and nand support for SDP does not
exist.

   Am not able to boot out of JFFS file system.

  Has anyone tried booting latest git kernel out of JFFS2 filesystem.


Regards,
vedan

Re: Git tree

[Trilok Soni]

Hi Veda,

On 7/17/07, Veda N <veda74@gmail.com> wrote:
> Hi,
>    I am using the latest git tree. MTD and nand support for SDP does not
> exist.
>
>    Am not able to boot out of JFFS file system.
>
>   Has anyone tried booting latest git kernel out of JFFS2 filesystem.

Which board are you referring too? Do you mean 3430 or 2430, and I
think for 2430 NAND support is there.

-- 
--Trilok Soni

Re: Git tree

[Maximus]

On 7/17/07, Veda N <veda74@gmail.com> wrote:
> Hi,
>    I am using the latest git tree. MTD and nand support for SDP does not
> exist.

   Were you able to boot out of nand flash using the git-tree?.

  "make omap_2430sdp_defconfig" does not enable nand support.

  one-nand support is enabled. Both are exclusive.


-- john


>    Am not able to boot out of JFFS file system.
>
>   Has anyone tried booting latest git kernel out of JFFS2 filesystem.
>
>
> Regards,
> vedan
> _______________________________________________
> Linux-omap-open-source mailing list
> Linux-omap-open-source@linux.omap.com
> http://linux.omap.com/mailman/listinfo/linux-omap-open-source
>

Re: git tree

[Grant Likely]

On 4/16/07, Wolfgang Reissnegger <wolfgang.reissnegger@xilinx.com> wrote:
> Hi Grant,
>
> just checked out your virtex-dev branch. I noticed that you also have a
> virtex-temac and a virtex-sysace branch that got merged into the
> virtex-dev branch.
>
> I was wondering what your branching strategy is. How is your workflow
> if, say a TEMAC bug is being fixed? Do you plan on removing the
> individual driver branches around? In which branches do you fix the
> bugs? What do you pull from where?

I haven't quite decided yet.  The -temac and -sysace branches are a
bit of an experiment.  I thought it might be a good idea to maintain
the drivers in seperate branches so it is easy to get a diff on just
that driver; but the individual drivers are pretty seperate anyway (in
different directories).  I think I'll probably drop the -temac and
-sysace branches, and just maintain all my changes in the -dev branch.
 The -forupstream branch is specifically for patches that are due to
go upstream.  I'll add patches there when I think they are suitable
for mainline, and post them to the list.

>
> Do you pull changes from mainline back into your tree(s) on a daily basis?

No.  I'll rebase them once in a while as needed, but I'm not going to
try to stay perpetually up-to-date. The best way to get perpetual
up-to-dateness is to get the drivers iinto a good state and get them
into mainline (which is certainly my goal)

>
> Right now I branched off a 2.6.20 branch and then added my patches (e.g.
> uc0, mb). For each patch I created a new branch. Once I finished adding
> the patches, I consolidated everything into a "Xilinx" branch. I'm
> beginning to wonder if this was a good way to do it. My branches look
> like this now:
>
> * 2.6.20-xlnx
>   b2.6.20
>   b2.6.20-uc0
>   b2.6.20-uc0-mb
>   b2.6.20-uc0-mb-xlnx
>   master
>   origin
>
> Is it common practice to keep individual branches in the repository?

In public trees, no, not really.  In my private tree I've got task
branches galore, but it's probably too confusing to have loads of
branches in a public tree.

>
> I like the way you have the branches separated out for each driver. I
> think I should get them from your tree, merge them with what I have and
> add new driver branches as I add more drivers. This way it would be
> easiest to sync your tree with Xilinx's

As I said, the drivers are already split out by directories; so what I
did is probably unnecessary.  But, yes, feel free to pull my tree into
yours.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: git tree

[David H. Lynch Jr]

Grant Likely wrote:
> I haven't quite decided yet.  The -temac and -sysace branches are a
> bit of an experiment.  I thought it might be a good idea to maintain
> the drivers in seperate branches so it is easy to get a diff on just
> that driver; but the individual drivers are pretty seperate anyway (in
> different directories).  I think I'll probably drop the -temac and
> -sysace branches, and just maintain all my changes in the -dev branch.
>  The -forupstream branch is specifically for patches that are due to
> go upstream.  I'll add patches there when I think they are suitable
> for mainline, and post them to the list.
    I would greatly appreciate pointers to so reference for using git
for kernel development.
    I have looked through most of the howto's and have a basic
competence with git.

    I am looking for something more like how to manage development with
possibly multiple
    devices/projects.
    Not necescarily what is possible, but what Standard Operating
Procedure for most developers.


   



-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: git tree

[Grant Likely]

On 4/21/07, David H. Lynch Jr <dhlii@comcast.net> wrote:
>     I am looking for something more like how to manage development with
> possibly multiple
>     devices/projects.
>     Not necescarily what is possible, but what Standard Operating
> Procedure for most developers.

The papers on http://www.jdl.com are very good at covering
collaboration with git.  Take a look at them, and then feel free to
ask more questions.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Git tree

[Luís Cargnini]

Please whose git tree i must use the git tree provided bit mvist or
kernel.org ??
the problem compiling the source from kernel.org:

 CHK     include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/compile.h
  CC      arch/arm/plat-omap/clock.o
arch/arm/plat-omap/clock.c:31: error: static declaration of 'clocks' follows
non-static declaration
include/asm/arch/clock.h:19: error: previous declaration of 'clocks' was
here
arch/arm/plat-omap/clock.c:33: error: static declaration of 'clockfw_lock'
follows non-static declaration
include/asm/arch/clock.h:20: error: previous declaration of 'clockfw_lock'
was here
make[1]: *** [arch/arm/plat-omap/clock.o] Error 1
make: *** [arch/arm/plat-omap] Error 2

persist.
How could i fix this ?
someone mentioned a patch where i found this patch for gcc ?
i'm using the denx toolchain, but thinking im recreate my own toolchain,
someone using 4.1.0 ??
and have a howto or quick-setup ?

compiling gcc.4.1.0 i founded the following:
In file included from ../../gcc-4.1.0/gcc/crtstuff.c:68:
../../gcc-4.1.0/gcc/tsystem.h:90:19: error: stdio.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:93:23: error: sys/types.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:96:19: error: errno.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:103:20: error: string.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:104:20: error: stdlib.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:105:20: error: unistd.h: No such file or
directory
../../gcc-4.1.0/gcc/tsystem.h:111:18: error: time.h: No such file or
directory
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/home/lvcargnini/puc/instramed/build/b-gcc/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/lvcargnini/puc/instramed/build/b-gcc'


but
../gcc-4.1.0/gcc/config/arm/t-linux
....
TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc
-D__gthr_posix_h
....
 and my configure line is
../gcc-4.1.0/configure --prefix=/opt/arm-linux --target=arm-linux
--with-float=soft --with-cpu=arm9tdmi --disable-shared --disable-threads
--with-headers=/opt/arm-linux/arm-linux/include --enable-languages=c


thanks for any help.

-- 
Thanks && Regards
Msc. Bsc. Luís Vitório Cargnini
IEEE Member
Mastering Degree student @ PUC-RS Electrical Engineer Faculty