Hi Linus and Stephen,
I've signed up for an kernel.org account and moved the blackfin tree to kernel.org for convenience as some developers' suggestion. Pls update the url to:
http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
Hi Linus,
please pull blackfin updates for Linux 3.11, some minor changes for performance and bug fixes.
The following changes since commit 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376:
Linux 3.10 (2013-06-30 15:13:29 -0700)
are available in the git repository at:
http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git tags/blackfin-for-linus
for you to fetch changes up to 150382a53d11256e5666c86525c8bf8d23684532:
smp: refine bf561 smpboot code (2013-07-09 15:50:38 +0800)
----------------------------------------------------------------
blackfin updates for Linux 3.11
----------------------------------------------------------------
Scott Jiang (1):
bf609: rename bfin6xx_spi to bfin_spi3
Sonic Zhang (2):
kgdb: blackfin: include irq_regs.h in kgdb.c
bf609: add cpu revision 0.1
Steven Miao (2):
bf609: stmmac: fix build after stmmac_mdio_bus_data changed
smp: refine bf561 smpboot code
arch/blackfin/Kconfig | 2 +-
.../include/asm/{bfin6xx_spi.h => bfin_spi3.h} | 4 ++--
arch/blackfin/kernel/kgdb.c | 1 +
arch/blackfin/mach-bf561/smp.c | 7 +++----
arch/blackfin/mach-bf609/boards/ezkit.c | 19 +++++++++----------
arch/blackfin/mach-common/smp.c | 18 ++++++++----------
6 files changed, 24 insertions(+), 27 deletions(-)
rename arch/blackfin/include/asm/{bfin6xx_spi.h => bfin_spi3.h} (99%)
Hi Steven,
On Tue, 9 Jul 2013 17:15:30 +0800 Steven Miao <[email protected]> wrote:
>
> I've signed up for an kernel.org account and moved the blackfin tree to kernel.org for convenience as some developers' suggestion. Pls update the url to:
> http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
That tree only has for-linus and master branches. linux-next uses the
blackfin-linus branch of your github tree ... so what should I use now?
--
Cheers,
Stephen Rothwell [email protected]
Hi Stephen,
On Wed, Jul 10, 2013 at 1:55 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Steven,
>
> On Tue, 9 Jul 2013 17:15:30 +0800 Steven Miao <[email protected]> wrote:
>>
>> I've signed up for an kernel.org account and moved the blackfin tree to kernel.org for convenience as some developers' suggestion. Pls update the url to:
>> http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
>
> That tree only has for-linus and master branches. linux-next uses the
> blackfin-linus branch of your github tree ... so what should I use now?
Pls use for-linus branch on
http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
Thanks.
>
> --
> Cheers,
> Stephen Rothwell [email protected]
Hi Steven,
On Wed, 10 Jul 2013 14:05:45 +0800 Steven Miao <[email protected]> wrote:
>
> Pls use for-linus branch on
> http://git.kernel.org/pub/scm/linux/kernel/git/realmz6/blackfin-linux.git
Done.
--
Cheers,
Stephen Rothwell [email protected]
Hi Steven,
On Tue, Jul 9, 2013 at 11:15 AM, Steven Miao <[email protected]> wrote:
> Steven Miao (2):
> smp: refine bf561 smpboot code
Unfortunately this landed too late in -next to notice:
arch/blackfin/mach-common/smp.c:150:2: error: conversion to non-scalar
type requested
arch/blackfin/mach-common/smp.c:185:23: error: incompatible types when
assigning to type 'atomic_t' from type 'int'
arch/blackfin/mach-common/smp.c:186:24: error: incompatible types when
assigning to type 'atomic_t' from type 'int'
make[2]: *** [arch/blackfin/mach-common/smp.o] Error 1
http://kisskb.ellerman.id.au/kisskb/buildresult/9115952/
It's a bit embarrassing to break your own core code (with a patch that was
submitted for public review in August 2012?).
The last two can be trivially-fixed with the following
(whitespace-damaged gmail)
patch:
--- a/arch/blackfin/mach-common/smp.c
+++ b/arch/blackfin/mach-common/smp.c
@@ -182,8 +182,8 @@ static void bfin_ipi_init(void)
struct ipi_data *bfin_ipi_data;
for_each_possible_cpu(cpu) {
bfin_ipi_data = &per_cpu(bfin_ipi, cpu);
- bfin_ipi_data->bits = 0;
- bfin_ipi_data->count = 0;
+ atomic_set(&bfin_ipi_data->bits, 0);
+ atomic_set(&bfin_ipi_data->count, 0);
}
}
but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
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 Mon, Jul 15, 2013 at 10:28 AM, Geert Uytterhoeven
<[email protected]> wrote:
>
> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
It's also broken. There's no guarantee that an "atomic_t" is just a
value. Now, the old sparc32 stuff (which hid lock bits in atomic_t)
may be gone, but it's still the case that atomic_t may not actually
work with xchg.
(In *practice* it works on normal architectures, so I'm not saying
that we don't have it, but it's a bug if we do).
There are "atomic_xchg()" and "atomic_xchg64()" functions that are supported.
Linus
Hi Geert,
On Tue, Jul 16, 2013 at 1:28 AM, Geert Uytterhoeven
<[email protected]> wrote:
> Hi Steven,
>
> On Tue, Jul 9, 2013 at 11:15 AM, Steven Miao <[email protected]> wrote:
>> Steven Miao (2):
>> smp: refine bf561 smpboot code
>
> Unfortunately this landed too late in -next to notice:
>
> arch/blackfin/mach-common/smp.c:150:2: error: conversion to non-scalar
> type requested
> arch/blackfin/mach-common/smp.c:185:23: error: incompatible types when
> assigning to type 'atomic_t' from type 'int'
> arch/blackfin/mach-common/smp.c:186:24: error: incompatible types when
> assigning to type 'atomic_t' from type 'int'
> make[2]: *** [arch/blackfin/mach-common/smp.o] Error 1
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/9115952/
>
> It's a bit embarrassing to break your own core code (with a patch that was
> submitted for public review in August 2012?).
>
> The last two can be trivially-fixed with the following
> (whitespace-damaged gmail)
> patch:
>
> --- a/arch/blackfin/mach-common/smp.c
> +++ b/arch/blackfin/mach-common/smp.c
> @@ -182,8 +182,8 @@ static void bfin_ipi_init(void)
> struct ipi_data *bfin_ipi_data;
> for_each_possible_cpu(cpu) {
> bfin_ipi_data = &per_cpu(bfin_ipi, cpu);
> - bfin_ipi_data->bits = 0;
> - bfin_ipi_data->count = 0;
> + atomic_set(&bfin_ipi_data->bits, 0);
> + atomic_set(&bfin_ipi_data->count, 0);
> }
> }
Sorry, I should use atomic_ops to hanle atomic_t type.
>
> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
>
> 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, Jul 16, 2013 at 1:49 AM, Linus Torvalds
<[email protected]> wrote:
> On Mon, Jul 15, 2013 at 10:28 AM, Geert Uytterhoeven
> <[email protected]> wrote:
>>
>> but the first one is non-trivial: using xchg() on atomic_t is a bit gross...
>
> It's also broken. There's no guarantee that an "atomic_t" is just a
> value. Now, the old sparc32 stuff (which hid lock bits in atomic_t)
> may be gone, but it's still the case that atomic_t may not actually
> work with xchg.
>
> (In *practice* it works on normal architectures, so I'm not saying
> that we don't have it, but it's a bug if we do).
>
> There are "atomic_xchg()" and "atomic_xchg64()" functions that are supported.
I'll send a patch to fix it.
>
> Linus