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: http://www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
On Mon, 07 Jun 2010 20:20:03 +0200
Michal Simek <[email protected]> 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);
}
FUJITA Tomonori wrote:
> On Mon, 07 Jun 2010 20:20:03 +0200
> Michal Simek <[email protected]> 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: http://www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663
On Tue, 08 Jun 2010 12:28:53 +0200
Michal Simek <[email protected]> wrote:
> FUJITA Tomonori wrote:
> > On Mon, 07 Jun 2010 20:20:03 +0200
> > Michal Simek <[email protected]> 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 <[email protected]>
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 <[email protected]>
---
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
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
On Tue, Jun 8, 2010 at 22:14, Linus Torvalds
<[email protected]> 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 -- [email protected]
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
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
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: http://www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian