[GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Michal Simek]

Hi Linus,

here are only fixes for Microblaze. There is no any new features. 
(flush_dcache_page patch fix problem on WB system)
Just note: Some new patches broke Microblaze arch that's why I would 
like to add at least these patches to your tree.

Thanks,
Michal


The following changes since commit 386f40c86d6c8d5b717ef20620af1a750d0dacb4:
   Linus Torvalds (1):
         Revert "tty: fix a little bug in scrup, vt.c"

are available in the git repository at:

   git://git.monstr.eu/linux-2.6-microblaze.git next

Michal Simek (7):
       microblaze: Fix __copy_to/from_user_inatomic macros
       microblaze: Sync noMMU and MMU setup_memory
       microblaze: Fix comment for TLB
       microblaze: Implement flush_dcache_page macro
       microblaze: Enable NEED_SG_DMA_LENGTH
       microblaze: Remove unused label
       microblaze: Define ARCH_SLAB_MINALIGN

  arch/microblaze/Kconfig                  |    3 +++
  arch/microblaze/include/asm/cacheflush.h |   13 +++++++++----
  arch/microblaze/include/asm/page.h       |    2 ++
  arch/microblaze/include/asm/uaccess.h    |    4 ++--
  arch/microblaze/kernel/misc.S            |    2 +-
  arch/microblaze/mm/fault.c               |    1 -
  arch/microblaze/mm/init.c                |    7 +------
  7 files changed, 18 insertions(+), 14 deletions(-)


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[FUJITA Tomonori]

On Mon, 07 Jun 2010 20:20:03 +0200
Michal Simek <michal.simek@petalogix.com> wrote:

> Hi Linus,
> 
> here are only fixes for Microblaze. There is no any new features. 
> (flush_dcache_page patch fix problem on WB system)
> Just note: Some new patches broke Microblaze arch that's why I would 
> like to add at least these patches to your tree.
> 
> Thanks,
> Michal
> 
> 
> The following changes since commit 386f40c86d6c8d5b717ef20620af1a750d0dacb4:
>    Linus Torvalds (1):
>          Revert "tty: fix a little bug in scrup, vt.c"
> 
> are available in the git repository at:
> 
>    git://git.monstr.eu/linux-2.6-microblaze.git next
> 
> Michal Simek (7):
>        microblaze: Fix __copy_to/from_user_inatomic macros
>        microblaze: Sync noMMU and MMU setup_memory
>        microblaze: Fix comment for TLB
>        microblaze: Implement flush_dcache_page macro
>        microblaze: Enable NEED_SG_DMA_LENGTH

Sorry, my scatterlist patchset breaks microblaze?

Seems that microblaze can simply remove sg->dma_length instead of
enabling NEED_SG_DMA_LENGTH. If sg->dma_length is always equal to
sg->length on your architecture, you don't need to waste memory for
sg->dma_length.


diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index 9dcd90b..79c7465 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -90,7 +90,6 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
 	/* FIXME this part of code is untested */
 	for_each_sg(sgl, sg, nents, i) {
 		sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
-		sg->dma_length = sg->length;
 		__dma_sync_page(page_to_phys(sg_page(sg)), sg->offset,
 							sg->length, direction);
 	}

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Michal Simek]

FUJITA Tomonori wrote:
> On Mon, 07 Jun 2010 20:20:03 +0200
> Michal Simek <michal.simek@petalogix.com> wrote:
> 
>> Hi Linus,
>>
>> here are only fixes for Microblaze. There is no any new features. 
>> (flush_dcache_page patch fix problem on WB system)
>> Just note: Some new patches broke Microblaze arch that's why I would 
>> like to add at least these patches to your tree.
>>
>> Thanks,
>> Michal
>>
>>
>> The following changes since commit 386f40c86d6c8d5b717ef20620af1a750d0dacb4:
>>    Linus Torvalds (1):
>>          Revert "tty: fix a little bug in scrup, vt.c"
>>
>> are available in the git repository at:
>>
>>    git://git.monstr.eu/linux-2.6-microblaze.git next
>>
>> Michal Simek (7):
>>        microblaze: Fix __copy_to/from_user_inatomic macros
>>        microblaze: Sync noMMU and MMU setup_memory
>>        microblaze: Fix comment for TLB
>>        microblaze: Implement flush_dcache_page macro
>>        microblaze: Enable NEED_SG_DMA_LENGTH
> 
> Sorry, my scatterlist patchset breaks microblaze?

yes, it does.
http://www.monstr.eu/wiki/doku.php?id=log:2010-06-07_12_23_12#folded_17

> 
> Seems that microblaze can simply remove sg->dma_length instead of
> enabling NEED_SG_DMA_LENGTH. If sg->dma_length is always equal to
> sg->length on your architecture, you don't need to waste memory for
> sg->dma_length.

Please correct me if I am wrong. dma_length is used for 64bit machines.
Microblaze is "only" 32bit.

Can you please generate proper patch?

Thanks,
Michal


> 
> 
> diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
> index 9dcd90b..79c7465 100644
> --- a/arch/microblaze/kernel/dma.c
> +++ b/arch/microblaze/kernel/dma.c
> @@ -90,7 +90,6 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
>  	/* FIXME this part of code is untested */
>  	for_each_sg(sgl, sg, nents, i) {
>  		sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
> -		sg->dma_length = sg->length;
>  		__dma_sync_page(page_to_phys(sg_page(sg)), sg->offset,
>  							sg->length, direction);
>  	}


-- 
Michal Simek, Ing. (M.Eng)
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[FUJITA Tomonori]

On Tue, 08 Jun 2010 12:28:53 +0200
Michal Simek <michal.simek@petalogix.com> wrote:

> FUJITA Tomonori wrote:
> > On Mon, 07 Jun 2010 20:20:03 +0200
> > Michal Simek <michal.simek@petalogix.com> wrote:
> > 
> >> Hi Linus,
> >>
> >> here are only fixes for Microblaze. There is no any new features. 
> >> (flush_dcache_page patch fix problem on WB system)
> >> Just note: Some new patches broke Microblaze arch that's why I would 
> >> like to add at least these patches to your tree.
> >>
> >> Thanks,
> >> Michal
> >>
> >>
> >> The following changes since commit 386f40c86d6c8d5b717ef20620af1a750d0dacb4:
> >>    Linus Torvalds (1):
> >>          Revert "tty: fix a little bug in scrup, vt.c"
> >>
> >> are available in the git repository at:
> >>
> >>    git://git.monstr.eu/linux-2.6-microblaze.git next
> >>
> >> Michal Simek (7):
> >>        microblaze: Fix __copy_to/from_user_inatomic macros
> >>        microblaze: Sync noMMU and MMU setup_memory
> >>        microblaze: Fix comment for TLB
> >>        microblaze: Implement flush_dcache_page macro
> >>        microblaze: Enable NEED_SG_DMA_LENGTH
> > 
> > Sorry, my scatterlist patchset breaks microblaze?
> 
> yes, it does.
> http://www.monstr.eu/wiki/doku.php?id=log:2010-06-07_12_23_12#folded_17

Sorry about that.


> > Seems that microblaze can simply remove sg->dma_length instead of
> > enabling NEED_SG_DMA_LENGTH. If sg->dma_length is always equal to
> > sg->length on your architecture, you don't need to waste memory for
> > sg->dma_length.
> 
> Please correct me if I am wrong. dma_length is used for 64bit machines.

dma_length is used for 32bit machines too.

dma_length is necessary if sg->dma_length can be different to
sg->length, that is, some IOMMU implementations merge several sg
entries to one sg entry.

There are not many 32bit architectures that support an IOMMU so
NEED_SG_DMA_LENGTH is usually used on 64bit archs though.


> Microblaze is "only" 32bit.
> 
> Can you please generate proper patch?

Sure. With this patch, you don't need to enable NEED_SG_DMA_LENGTH.

=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] microblaze: fix sg_dma_len() regression

The commit 8e98307de0d746cb0845ebf66535ce2184c25a2 broke microblaze.

dma_direct_map_sg() sets sg->dma_length, however microblaze doesn't
set NEED_SG_DMA_LENGTH so scatterlist strcutres doesn't include
dma_length.

sg->dma_length is always equal to sg->length on microblaze. So we
don't need to set set dma_length, that is, microblaze can simply use
sg->length.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 arch/microblaze/kernel/dma.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/arch/microblaze/kernel/dma.c b/arch/microblaze/kernel/dma.c
index 9dcd90b..79c7465 100644
--- a/arch/microblaze/kernel/dma.c
+++ b/arch/microblaze/kernel/dma.c
@@ -90,7 +90,6 @@ static int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl,
 	/* FIXME this part of code is untested */
 	for_each_sg(sgl, sg, nents, i) {
 		sg->dma_address = sg_phys(sg) + get_dma_direct_offset(dev);
-		sg->dma_length = sg->length;
 		__dma_sync_page(page_to_phys(sg_page(sg)), sg->offset,
 							sg->length, direction);
 	}
-- 
1.6.5

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Linus Torvalds]

On Mon, 7 Jun 2010, Michal Simek wrote:
> 
> here are only fixes for Microblaze. There is no any new features.
> (flush_dcache_page patch fix problem on WB system)
> Just note: Some new patches broke Microblaze arch that's why I would like to
> add at least these patches to your tree.

This _still_ doesn't seem to be "just regressions and major bugfixes for 
things like oopses and security issues".

Why do I even have to send this email?

		Linus

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Geert Uytterhoeven]

On Tue, Jun 8, 2010 at 22:14, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Mon, 7 Jun 2010, Michal Simek wrote:
>> here are only fixes for Microblaze. There is no any new features.
>> (flush_dcache_page patch fix problem on WB system)
>> Just note: Some new patches broke Microblaze arch that's why I would like to
>> add at least these patches to your tree.
>
> This _still_ doesn't seem to be "just regressions and major bugfixes for
> things like oopses and security issues".
>
> Why do I even have to send this email?

Seems like you will have written more angry emails than there will be
new commits in 2.6.35-rc3 ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Linus Torvalds]

On Tue, 8 Jun 2010, Geert Uytterhoeven wrote:
> 
> Seems like you will have written more angry emails than there will be
> new commits in 2.6.35-rc3 ;-)

Well, partly in order to be fair. I did consider letting architectures 
like microblaze just off the hook entirely - it's not like it will affect 
a lot of people. But at the same time, I don't want to be in the situation 
that some people get to send me patches just because I don't happen to 
think that their changes will matter to most others.

And at this stage, I'd rather be too strict than too lenient. If -rc3 has 
no new regressions, and fixes the ones that hit people worst, I'll be very 
happy. I can be more open to patches after I get back, if it turns out 
that I was _too_ strict for -rc3.

As to the number of "no, I won't take it" emails, I suspect a large part 
of that is simply because most developers (understandably) do not read 
lkml, stauing mostly on the development lists that are more specific to 
their particular area. As a result, there's no real way to reliably reach 
people, and I end up sending basically the same message several times.

Which obviously tends to also then make the messages more cross ;)

			Linus

Re: [GIT PULL] arch/microblaze fixes for 2.6.35-rc3 v2

[Michal Simek]

Linus Torvalds wrote:
> 
> On Tue, 8 Jun 2010, Geert Uytterhoeven wrote:
>> Seems like you will have written more angry emails than there will be
>> new commits in 2.6.35-rc3 ;-)
> 
> Well, partly in order to be fair. I did consider letting architectures 
> like microblaze just off the hook entirely - it's not like it will affect 
> a lot of people. But at the same time, I don't want to be in the situation 
> that some people get to send me patches just because I don't happen to 
> think that their changes will matter to most others.
> 
> And at this stage, I'd rather be too strict than too lenient. If -rc3 has 
> no new regressions, and fixes the ones that hit people worst, I'll be very 
> happy. I can be more open to patches after I get back, if it turns out 
> that I was _too_ strict for -rc3.
> 
> As to the number of "no, I won't take it" emails, I suspect a large part 
> of that is simply because most developers (understandably) do not read 
> lkml, stauing mostly on the development lists that are more specific to 
> their particular area. As a result, there's no real way to reliably reach 
> people, and I end up sending basically the same message several times.
> 
> Which obviously tends to also then make the messages more cross ;)

First of all let me apologize for this situation. There is no excuse
that I sent new features in requests after rc.

I've changed my workflow and I will send new pull request with the 
strict regression fixes only. There will be only two patches which I 
would like to add to your tree.

Thanks and sorry for hassle,
Michal


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian