RE: [PATCH v10 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
> -Original Message-
> From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> Sent: Saturday, April 02, 2011 12:26 AM
> To: Tirumala Marri
> Cc: Keshava Munegowda; linux-...@vger.kernel.org;
linuxppc-dev@lists.ozlabs.org; g...@kroah.com;
> Fushen Chen; Mark Miesfeld
> Subject: Re: [PATCH v10 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core
Interface Layer (CIL)
>
> Hello.
>
> Tirumala Marri wrote:
>
> >>> +void dwc_otg_core_init(struct core_if *core_if)
> >>> +{
> >>> + u32 i;
> >>> + ulong global_reg = core_if->core_global_regs;
> >>> + struct device_if *dev_if = core_if->dev_if;
> >>> + u32 ahbcfg = 0;
> >>> + u32 i2cctl = 0;
> >>> + u32 gusbcfg;
>
> >> Tabify the declarations ;
>
> > [Marri] When I checked again in my source, I do see the tabs added
before
> > declarations.
>
> He means that tabs should be between the variable's type and name,
but
> there's no such requirement actually.
I am sorry if there is no such requirement, since I had such comments and
I fixed it and
Now I have commented.
Keshava Munegowda
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v10 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core Interface Layer (CIL)
On Tue, Apr 05, 2011 at 12:38:03PM +0530, Keshava Munegowda wrote:
> > -Original Message-
> > From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
> > Sent: Saturday, April 02, 2011 12:26 AM
> > To: Tirumala Marri
> > Cc: Keshava Munegowda; linux-...@vger.kernel.org;
> linuxppc-dev@lists.ozlabs.org; g...@kroah.com;
> > Fushen Chen; Mark Miesfeld
> > Subject: Re: [PATCH v10 03/10] USB/ppc4xx: Add Synopsys DWC OTG Core
> Interface Layer (CIL)
> >
> > Hello.
> >
> > Tirumala Marri wrote:
> >
> > >>> +void dwc_otg_core_init(struct core_if *core_if)
> > >>> +{
> > >>> + u32 i;
> > >>> + ulong global_reg = core_if->core_global_regs;
> > >>> + struct device_if *dev_if = core_if->dev_if;
> > >>> + u32 ahbcfg = 0;
> > >>> + u32 i2cctl = 0;
> > >>> + u32 gusbcfg;
> >
> > >> Tabify the declarations ;
> >
> > > [Marri] When I checked again in my source, I do see the tabs added
> before
> > > declarations.
> >
> > He means that tabs should be between the variable's type and name,
> but
> > there's no such requirement actually.
>
> I am sorry if there is no such requirement, since I had such comments and
> I fixed it and
> Now I have commented.
it's true we don't have that requirement, but it does look better when
we have many local variables. IMHO, whatever we can do to go easy on the
eyes, we should.
--
balbi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Replace open coded instruction patching with patch_instruction/patch_branch
There are a few places we patch instructions without using
patch_instruction and patch_branch, probably because they
predated it. Fix it.
Signed-off-by: Anton Blanchard
---
Index: powerpc.git/arch/powerpc/mm/hash_utils_64.c
===
--- powerpc.git.orig/arch/powerpc/mm/hash_utils_64.c2011-02-25
14:15:49.972437235 +1100
+++ powerpc.git/arch/powerpc/mm/hash_utils_64.c 2011-04-05 18:43:33.860987967
+1000
@@ -53,6 +53,7 @@
#include
#include
#include
+#include
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -547,15 +548,7 @@ int remove_section_mapping(unsigned long
}
#endif /* CONFIG_MEMORY_HOTPLUG */
-static inline void make_bl(unsigned int *insn_addr, void *func)
-{
- unsigned long funcp = *((unsigned long *)func);
- int offset = funcp - (unsigned long)insn_addr;
-
- *insn_addr = (unsigned int)(0x4801 | (offset & 0x03fc));
- flush_icache_range((unsigned long)insn_addr, 4+
- (unsigned long)insn_addr);
-}
+#define FUNCTION_TEXT(A) ((*(unsigned long *)(A)))
static void __init htab_finish_init(void)
{
@@ -570,16 +563,33 @@ static void __init htab_finish_init(void
extern unsigned int *ht64_call_hpte_remove;
extern unsigned int *ht64_call_hpte_updatepp;
- make_bl(ht64_call_hpte_insert1, ppc_md.hpte_insert);
- make_bl(ht64_call_hpte_insert2, ppc_md.hpte_insert);
- make_bl(ht64_call_hpte_remove, ppc_md.hpte_remove);
- make_bl(ht64_call_hpte_updatepp, ppc_md.hpte_updatepp);
+ patch_branch(ht64_call_hpte_insert1,
+ FUNCTION_TEXT(ppc_md.hpte_insert),
+ BRANCH_SET_LINK);
+ patch_branch(ht64_call_hpte_insert2,
+ FUNCTION_TEXT(ppc_md.hpte_insert),
+ BRANCH_SET_LINK);
+ patch_branch(ht64_call_hpte_remove,
+ FUNCTION_TEXT(ppc_md.hpte_remove),
+ BRANCH_SET_LINK);
+ patch_branch(ht64_call_hpte_updatepp,
+ FUNCTION_TEXT(ppc_md.hpte_updatepp),
+ BRANCH_SET_LINK);
+
#endif /* CONFIG_PPC_HAS_HASH_64K */
- make_bl(htab_call_hpte_insert1, ppc_md.hpte_insert);
- make_bl(htab_call_hpte_insert2, ppc_md.hpte_insert);
- make_bl(htab_call_hpte_remove, ppc_md.hpte_remove);
- make_bl(htab_call_hpte_updatepp, ppc_md.hpte_updatepp);
+ patch_branch(htab_call_hpte_insert1,
+ FUNCTION_TEXT(ppc_md.hpte_insert),
+ BRANCH_SET_LINK);
+ patch_branch(htab_call_hpte_insert2,
+ FUNCTION_TEXT(ppc_md.hpte_insert),
+ BRANCH_SET_LINK);
+ patch_branch(htab_call_hpte_remove,
+ FUNCTION_TEXT(ppc_md.hpte_remove),
+ BRANCH_SET_LINK);
+ patch_branch(htab_call_hpte_updatepp,
+ FUNCTION_TEXT(ppc_md.hpte_updatepp),
+ BRANCH_SET_LINK);
}
static void __init htab_initialize(void)
Index: powerpc.git/arch/powerpc/mm/slb.c
===
--- powerpc.git.orig/arch/powerpc/mm/slb.c 2011-02-25 14:15:49.952435267
+1100
+++ powerpc.git/arch/powerpc/mm/slb.c 2011-04-05 18:42:27.018630388 +1000
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
extern void slb_allocate_realmode(unsigned long ea);
@@ -249,9 +250,8 @@ void switch_slb(struct task_struct *tsk,
static inline void patch_slb_encoding(unsigned int *insn_addr,
unsigned int immed)
{
- *insn_addr = (*insn_addr & 0x) | immed;
- flush_icache_range((unsigned long)insn_addr, 4+
- (unsigned long)insn_addr);
+ int insn = (*insn_addr & 0x) | immed;
+ patch_instruction(insn_addr, insn);
}
void slb_set_size(u16 size)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Revert 737a3bb9416ce2a7c7a4170852473a4fcc9c67e8 ?
On Die, 2011-04-05 at 01:52 +0200, Gabriel Paubert wrote: > > Actually I thought that the name radeon_cp that is registered there > would appear somwhere under /sys (or /proc) but failed to find it... FWIW the radeon_cp* functions are in drivers/gpu/drm/radeon. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Some minor powerpc fixes for you, freescale device-tree updates and a few nits like wrong ifdef's etc... Cheers, Ben. The following changes since commit b2a8b4b81966094703088a7bc76a313af841924d: Merge branch 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 (2011-04-04 17:56:07 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Benjamin Herrenschmidt (2): Merge remote branch 'kumar/merge' into merge powerpc/pseries: Don't register global initcall Kumar Gala (1): edac/mpc85xx: Limit setting/clearing of HID1[RFXE] to e500v1/v2 cores Matt Evans (1): powerpc/pseries: Fix build without CONFIG_HOTPLUG_CPU Paul Gortmaker (1): powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP. Prabhakar Kushwaha (1): powerpc/85xx: Update dts for PCIe memory maps to match u-boot of Px020RDB Ryan Grimm (1): powerpc: Set nr_cpu_ids early and use it to free PACAs arch/powerpc/boot/dts/p1020rdb.dts| 12 +- arch/powerpc/boot/dts/p2020rdb.dts| 12 +- arch/powerpc/boot/dts/p2020rdb_camp_core0.dts |4 +- arch/powerpc/boot/dts/p2020rdb_camp_core1.dts | 10 arch/powerpc/kernel/crash.c |6 ++-- arch/powerpc/kernel/paca.c|2 +- arch/powerpc/kernel/setup-common.c|3 ++ arch/powerpc/platforms/pseries/setup.c|2 +- arch/powerpc/platforms/pseries/smp.c | 17 ++- drivers/edac/mpc85xx_edac.c | 27 +--- 10 files changed, 57 insertions(+), 38 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: checking status semantics with compatible functions
On Wed, 2011-03-30 at 08:31 -0600, Grant Likely wrote: > Yes, of_device_is_available() should be checked, but it should not be > added directly to of_device_is_compatible(). I'm okay with adding > a helper variant that does the of_device_is_compatible() check. > > In that particular case, I'd also suggest using > for_each_matching_node(). Agreed. A device might be unavailable due to how FW configured the machine, but made later on available by the kernel, that shouldn't impact the interface compatibility test. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/book3e: Fix extlb size
On Apr 5, 2011, at 1:28 AM, Michael Ellerman wrote:
> The calculation of the size for the exception save area of the TLB
> miss handler is wrong, luckily it's too big not too small.
>
> Rework it to make it a bit clearer, and also correct. We want 3 save
> areas, each EX_TLB_SIZE _bytes_.
Where does the 3 come from? I have a guess, and think its possible we (FSL)
want 4?
>
> Signed-off-by: Michael Ellerman
> ---
> arch/powerpc/include/asm/paca.h |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/paca.h b/arch/powerpc/include/asm/paca.h
> index ec57540..f7aa4fd 100644
> --- a/arch/powerpc/include/asm/paca.h
> +++ b/arch/powerpc/include/asm/paca.h
> @@ -106,7 +106,7 @@ struct paca_struct {
> pgd_t *pgd; /* Current PGD */
> pgd_t *kernel_pgd; /* Kernel PGD */
> u64 exgen[8] __attribute__((aligned(0x80)));
> - u64 extlb[EX_TLB_SIZE*3] __attribute__((aligned(0x80)));
> + u64 extlb[3][EX_TLB_SIZE / sizeof(u64)] __attribute__((aligned(0x80)));
> u64 exmc[8];/* used for machine checks */
> u64 excrit[8]; /* used for crit interrupts */
> u64 exdbg[8]; /* used for debug interrupts */
> --
> 1.7.1
>
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 03/34] powerpc: Call gzip with -n
The timestamps recorded in the .gz files add no value.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Michal Marek
---
arch/powerpc/boot/wrapper |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index cb97e75..854797b 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -251,7 +251,7 @@ if [ -z "$cacheit" -o ! -f "$vmz$gzip" -o "$vmz$gzip" -ot
"$kernel" ]; then
${CROSS}objcopy $objflags "$kernel" "$vmz.$$"
if [ -n "$gzip" ]; then
-gzip -f -9 "$vmz.$$"
+gzip -n -f -9 "$vmz.$$"
fi
if [ -n "$cacheit" ]; then
@@ -336,7 +336,7 @@ coff)
$objbin/hack-coff "$ofile"
;;
cuboot*)
-gzip -f -9 "$ofile"
+gzip -n -f -9 "$ofile"
${MKIMAGE} -A ppc -O linux -T kernel -C gzip -a "$base" -e "$entry" \
$uboot_version -d "$ofile".gz "$ofile"
;;
@@ -383,6 +383,6 @@ ps3)
odir="$(dirname "$ofile.bin")"
rm -f "$odir/otheros.bld"
-gzip --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
+gzip -n --force -9 --stdout "$ofile.bin" > "$odir/otheros.bld"
;;
esac
--
1.7.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 05/34] powerpc: Use the deterministic mode of ar
Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Michal Marek --- arch/powerpc/boot/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index 8917816..d028a65 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -127,7 +127,7 @@ quiet_cmd_bootas = BOOTAS $@ cmd_bootas = $(CROSS32CC) -Wp,-MD,$(depfile) $(BOOTAFLAGS) -c -o $@ $< quiet_cmd_bootar = BOOTAR $@ - cmd_bootar = $(CROSS32AR) -cr $@. $(filter-out FORCE,$^); mv $@. $@ + cmd_bootar = $(CROSS32AR) -crD $@. $(filter-out FORCE,$^); mv $@. $@ $(obj-libfdt): $(obj)/%.o: $(srctree)/scripts/dtc/libfdt/%.c FORCE $(call if_changed_dep,bootcc) -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 00/34] Make kernel build deterministic
Hi,
this series makes it possible to build bit-identical kernel image and
modules from identical sources. Of course the build is already
deterministic in terms of behavior of the code, but the various
timestamps embedded in the object files make it hard to compare two
builds, for instance to verify that a makefile cleanup didn't
accidentally change something. A prime example is /proc/config.gz, which
has both a timestamp in the gzip header and a timestamp in the payload
data. With this series applied, a script like this will produce
identical kernels each time:
#!/bin/bash
rm -rf /dev/shm/{source,build}{,1,2}
export KCONFIG_NOTIMESTAMP=1
export KBUILD_BUILD_TIMESTAMP='Sun May 1 12:00:00 CEST 2011'
export KBUILD_BUILD_USER=user
export KBUILD_BUILD_HOST=host
export ROOT_DEV=FLOPPY
for i in 1 2; do
mkdir /dev/shm/source
# randomize the inode order just for fun
git ls-tree -r -z --name-only HEAD | sort -R -z | xargs -0 \
cp --parents --target=/dev/shm/source
pushd /dev/shm/source
mkdir /dev/shm/build
>/dev/shm/build/all.config
for opt in GCOV_KERNEL UBIFS_FS_DEBUG; do
echo "# CONFIG_$opt is not set" >>"/dev/shm/build"/all.config
done
make O="/dev/shm/build" KCONFIG_ALLCONFIG=1 allmodconfig
make O="/dev/shm/build" -j64
popd
mv /dev/shm/source /dev/shm/source$i
mv /dev/shm/build /dev/shm/build$i
done
diff -rq /dev/shm/build{1,2}
Unfortunatelly, this cannot be used to validate indentation-only
patches, even if CONFIG_DEBUG_INFO is turned off. This is because of the
__FILE__ and __LINE__ macros used in many places. For the same reason,
the source and build directory needs to be the same, otherwise the
results will differ. This was tested on
x86_64/{defconfig,allmodconfig,allyesconfig} and ppc64/defconfig. The
series is also available at
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git
deterministic-build-v1
Michal
Michal Marek (34):
kconfig: Do not record timestamp in auto.conf and autoconf.h
kbuild: Call gzip with -n
powerpc: Call gzip with -n
kbuild: Use the deterministic mode of ar
powerpc: Use the deterministic mode of ar
kbuild: Drop unused LINUX_COMPILE_TIME and LINUX_COMPILE_DOMAIN
macros
kbuild: Allow to override LINUX_COMPILE_BY and LINUX_COMPILE_HOST
macros
initramfs: Use KBUILD_BUILD_TIMESTAMP for generated entries
x86: Allow to override the ROOT_DEV variable
cyclades: Drop __TIME__ usage
nozomi: Drop __TIME__ usage
isdn/diva: Drop __TIME__ usage
media/radio-maxiradio: Drop __TIME__ usage
media/cx231xx: Drop __TIME__ usage
baycom: Drop __TIME__ usage
nand/denali: Drop __TIME__ usage
hdlcdrv: Drop __TIME__ usage
wan/pc300: Drop __TIME__ usage
rt2x00: Drop __TIME__ usage
parport: Drop __TIME__ usage
aacraid: Drop __TIME__ usage
scsi/in2000: Drop __TIME__ usage
scsi/wd33c93: Drop __TIME__ usage
usb/u132-hcd: Drop __TIME__ usage
usb/ftdi-elan: Drop __TIME__ usage
dlm: Drop __TIME__ usage
gfs2: Drop __TIME__ usage
atm: Drop __TIME__ usage
tipc: Drop __TIME__ usage
rio: Drop __DATE__ usage
edac: Drop __DATE__ usage
pmcraid: Drop __DATE__ usage
usb/lh7a40x_udc: Drop __DATE__ usage
checkpatch: Warn about usage of __DATE__, __TIME__ and __TIMESTAMP__
Documentation/kbuild/kbuild.txt | 12 ++
arch/powerpc/boot/Makefile |2 +-
arch/powerpc/boot/wrapper|6 ++--
arch/x86/boot/Makefile |2 +-
drivers/char/cyclades.c |3 +-
drivers/char/nozomi.c|3 +-
drivers/char/rio/rioinit.c |2 +-
drivers/edac/amd76x_edac.c |2 +-
drivers/edac/amd8111_edac.c |2 +-
drivers/edac/amd8131_edac.c |2 +-
drivers/edac/cpc925_edac.c |2 +-
drivers/edac/e752x_edac.c|2 +-
drivers/edac/e7xxx_edac.c|2 +-
drivers/edac/edac_module.c |2 +-
drivers/edac/i5000_edac.c|2 +-
drivers/edac/i5400_edac.c|2 +-
drivers/edac/i7300_edac.c|2 +-
drivers/edac/i7core_edac.c |2 +-
drivers/edac/i82860_edac.c |2 +-
drivers/edac/i82875p_edac.c |2 +-
drivers/edac/i82975x_edac.c |2 +-
drivers/edac/mpc85xx_edac.h |2 +-
drivers/edac/mv64x60_edac.h |2 +-
drivers/edac/ppc4xx_edac.c |2 +-
drivers/edac/r82600_edac.c |2 +-
drivers/isdn/hardware/eicon/divasfunc.c |5 +--
drivers/media/radio/radio-maxiradio.c|3 +-
drivers/media/video/cx231xx/cx231xx-avcore.c |2 +-
drivers/mtd/nand/denali.c|3 +-
drivers/net/hamradio
[RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
The patch below removes an unused config variable found by using a kernel cleanup script. Note: I did try to cross compile these but hit erros while doing so.. (gcc is not setup to cross compile) and am unsure if anymore needs to be done. Please have a look if/when anybody has free time. Signed-off-by: Justin P. Mattock CC: Benjamin Herrenschmidt CC: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/sysdev/Makefile |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile index 1e0c933..243b6ad 100644 --- a/arch/powerpc/sysdev/Makefile +++ b/arch/powerpc/sysdev/Makefile @@ -18,7 +18,6 @@ obj-$(CONFIG_FSL_PMC) += fsl_pmc.o obj-$(CONFIG_FSL_LBC) += fsl_lbc.o obj-$(CONFIG_FSL_GTM) += fsl_gtm.o obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o -obj-$(CONFIG_FSL_85XX_CACHE_SRAM) += fsl_85xx_l2ctlr.o fsl_85xx_cache_sram.o obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o obj-$(CONFIG_FSL_RIO) += fsl_rio.o obj-$(CONFIG_TSI108_BRIDGE)+= tsi108_pci.o tsi108_dev.o -- 1.7.4.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC 5/5]arch:powerpc:kernel:Makefile Remove unused config in the Makefile.
The patch below removes an unused config variable found by using a kernel cleanup script. Note: I did try to cross compile these but hit erros while doing so.. (gcc is not setup to cross compile) and am unsure if anymore needs to be done. Please have a look if/when anybody has free time. Signed-off-by: Justin P. Mattock CC: Benjamin Herrenschmidt Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/kernel/Makefile |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 3bb2a3e..4fa0d52 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -75,7 +75,6 @@ obj-$(CONFIG_PPC_FSL_BOOK3E) += cpu_setup_fsl_booke.o dbell.o obj-$(CONFIG_PPC_BOOK3E_64)+= dbell.o extra-y:= head_$(CONFIG_WORD_SIZE).o -extra-$(CONFIG_PPC_BOOK3E_32) := head_new_booke.o extra-$(CONFIG_40x):= head_40x.o extra-$(CONFIG_44x):= head_44x.o extra-$(CONFIG_FSL_BOOKE) := head_fsl_booke.o -- 1.7.4.2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC 2/5]arch:powerpc:sysdev:Makefile Remove unused config in the Makefile.
On Tue, 5 Apr 2011 09:58:19 -0700 "Justin P. Mattock" wrote: > The patch below removes an unused config variable found by using a kernel > cleanup script. > Note: I did try to cross compile these but hit erros while doing so.. > (gcc is not setup to cross compile) and am unsure if anymore needs to be done. > Please have a look if/when anybody has free time. > > Signed-off-by: Justin P. Mattock > CC: Benjamin Herrenschmidt > CC: linuxppc-dev@lists.ozlabs.org > > --- > arch/powerpc/sysdev/Makefile |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile > index 1e0c933..243b6ad 100644 > --- a/arch/powerpc/sysdev/Makefile > +++ b/arch/powerpc/sysdev/Makefile > @@ -18,7 +18,6 @@ obj-$(CONFIG_FSL_PMC) += fsl_pmc.o > obj-$(CONFIG_FSL_LBC)+= fsl_lbc.o > obj-$(CONFIG_FSL_GTM)+= fsl_gtm.o > obj-$(CONFIG_MPC8xxx_GPIO) += mpc8xxx_gpio.o > -obj-$(CONFIG_FSL_85XX_CACHE_SRAM)+= fsl_85xx_l2ctlr.o > fsl_85xx_cache_sram.o > obj-$(CONFIG_SIMPLE_GPIO)+= simple_gpio.o > obj-$(CONFIG_FSL_RIO)+= fsl_rio.o > obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pci.o tsi108_dev.o Those files do exist, and aren't pulled in by any other means I can see. It was introduced by commit 6db92cc9d07db9f713da8554b4bcdfc8e54ad386, whose changelog says: Drivers can do the following in Kconfig to use these APIs "select FSL_85XX_CACHE_SRAM if MPC85xx" Now, the absence of such a kconfig option[1] is a problem, but I don't think outright removal (labelled "trivial cleanup") is appropriate, unless nobody fixes it after the problem is pointed out. And if it is removed, the files should go with it. -Scott [1] and of any drivers that select it, though this was added fairly recently -- perhaps such a driver change is on its way? ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: > > Hi, > > this series makes it possible to build bit-identical kernel image and > modules from identical sources. Of course the build is already > deterministic in terms of behavior of the code, but the various > timestamps embedded in the object files make it hard to compare two > builds, for instance to verify that a makefile cleanup didn't > accidentally change something. A prime example is /proc/config.gz, which > has both a timestamp in the gzip header and a timestamp in the payload > data. With this series applied, a script like this will produce > identical kernels each time: Very nice stuff. Do you want to take the individual patches through one of your trees, or do you mind if the subsystem maintainers take them through theirs? thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: > > > > Hi, > > > > this series makes it possible to build bit-identical kernel image and > > modules from identical sources. Of course the build is already > > deterministic in terms of behavior of the code, but the various > > timestamps embedded in the object files make it hard to compare two > > builds, for instance to verify that a makefile cleanup didn't > > accidentally change something. A prime example is /proc/config.gz, which > > has both a timestamp in the gzip header and a timestamp in the payload > > data. With this series applied, a script like this will produce > > identical kernels each time: > > Very nice stuff. Do you want to take the individual patches through one > of your trees, or do you mind if the subsystem maintainers take them > through theirs? I'm happy for this to go through a single tree. James ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
Em 05-04-2011 15:16, James Bottomley escreveu: > On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: >> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: >>> >>> Hi, >>> >>> this series makes it possible to build bit-identical kernel image and >>> modules from identical sources. Of course the build is already >>> deterministic in terms of behavior of the code, but the various >>> timestamps embedded in the object files make it hard to compare two >>> builds, for instance to verify that a makefile cleanup didn't >>> accidentally change something. A prime example is /proc/config.gz, which >>> has both a timestamp in the gzip header and a timestamp in the payload >>> data. With this series applied, a script like this will produce >>> identical kernels each time: >> >> Very nice stuff. Do you want to take the individual patches through one >> of your trees, or do you mind if the subsystem maintainers take them >> through theirs? > > I'm happy for this to go through a single tree. Me too. With respect to the patches I was c/c (patches 13, 14, 31): Acked-by: Mauro Carvalho Chehab Thanks, Mauro. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
sdhc/mpc8536 - SDCard always detected like read-only
Hello, I am working in a MPC8536e custom board. Our custom board has a slot to SDCards conected to the MPC8536e's eSDHC controller. We are using just 4-serial data pins of eSDHC controller. My kernel is 2.6.35.7 and I am using buildroot to build the root system with uClib. I can mount and read the data from SDCards in the slot. But I am facing errors when I try write something in the card. I am testing two SDcards: Kingston and a LG, both with 2GB capacity. I tryed ext3 and fat32 filesystems with the same results. When the card is detected the log is (observe the ro flag in the first line): mmcblk0: mmc0:57f7 SD02G 1.83 GiB (ro) mmcblk0: mmc0: starting CMD18 arg flags 00b5 mmc0: blksz 512 blocks 8 flags 0200 tsac 100 ms nsac 0 mmc0: CMD12 arg flags 049d sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001 sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x000a sdhci [sdhci_irq()]: *** mmc0 got interrupt: 0x0001 mmc0: req done (CMD18): 0: 0900 mmc0: 4096 bytes transferred: 0 mmc0: (CMD12): 0: 0b00 p1 I am sure the write protection mechanism on SDCard is in the unlock position, but the kernel drivers detects the card like read-only. Has someone idea why this happen? Every idea or tip is apreciated. Regards, Moratelli. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only
> Every idea or tip is apreciated. Please post your dts. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only
Em Ter, 2011-04-05 às 21:02 +0200, Wolfram Sang escreveu:
> > Every idea or tip is apreciated.
>
> Please post your dts.
>
/*
* MPC8536 DS Device Tree Source
*
* Copyright 2008-2009 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
it
* under the terms of the GNU General Public License as published by
the
* Free Software Foundation; either version 2 of the License, or (at
your
* option) any later version.
*/
/dts-v1/;
/ {
model = "fsl,mpc8536ds";
compatible = "fsl,mpc8536ds";
#address-cells = <2>;
#size-cells = <2>;
aliases {
ethernet0 = &enet0;
serial0 = &serial0;
serial1 = &serial1;
pci1 = &pci1;
};
cpus {
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
PowerPC,8536@0 {
device_type = "cpu";
reg = <0>;
next-level-cache = <&L2>;
};
};
memory {
device_type = "memory";
reg = <0 0 0 0>;// Filled by U-Boot
};
soc@fffe0 {
#address-cells = <1>;
#size-cells = <1>;
device_type = "soc";
compatible = "simple-bus";
ranges = <0x0 0xf 0xffe0 0x10>;
bus-frequency = <0>;// Filled out by uboot.
ecm-law@0 {
compatible = "fsl,ecm-law";
reg = <0x0 0x1000>;
fsl,num-laws = <12>;
};
ecm@1000 {
compatible = "fsl,mpc8536-ecm", "fsl,ecm";
reg = <0x1000 0x1000>;
interrupts = <17 2>;
interrupt-parent = <&mpic>;
};
memory-controller@2000 {
compatible = "fsl,mpc8536-memory-controller";
reg = <0x2000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <18 0x2>;
};
L2: l2-cache-controller@2 {
compatible = "fsl,mpc8536-l2-cache-controller";
reg = <0x2 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <16 0x2>;
};
i2c@3000 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <0>;
compatible = "fsl-i2c";
reg = <0x3000 0x100>;
interrupts = <43 0x2>;
interrupt-parent = <&mpic>;
dfsrr;
hwmon@48 {
compatible = "national,lm73";
reg = <0x49>;
};
rtc@68 {
compatible = "rtc-m41t80,m41t82";
reg = <0x68>;
};
lm90@4C {
compatible = "lm90,adt7461";
reg = <0x4C>;
};
};
i2c@3100 {
#address-cells = <1>;
#size-cells = <0>;
cell-index = <1>;
compatible = "fsl-i2c";
reg = <0x3100 0x100>;
interrupts = <43 0x2>;
interrupt-parent = <&mpic>;
dfsrr;
sfp@50 {
compatible = "sfp_teste,sfp_teste";
reg = <0x50>;
};
bcm56334@44{
compatible = "bcm56334,bcm56334";
reg = <0x44>;
};
};
spi@7000 {
cell-index = <0>;
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc8536-espi";
reg = <0x7000 0x1000>;
interrupts = <59 0x2>;
interrupt-parent = <&mpic>;
fsl,espi-num-chipselects = <4>;
mode = "cpu";
};
dma@21300 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8536-dma", "fsl,eloplus-dma";
reg = <0x21300 4>;
Re: [PATCH 00/34] Make kernel build deterministic
On Tue, Apr 05, 2011 at 03:29:19PM -0300, Mauro Carvalho Chehab wrote: > Em 05-04-2011 15:16, James Bottomley escreveu: > > On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: > >> On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: > >>> > >>> Hi, > >>> > >>> this series makes it possible to build bit-identical kernel image and > >>> modules from identical sources. Of course the build is already > >>> deterministic in terms of behavior of the code, but the various > >>> timestamps embedded in the object files make it hard to compare two > >>> builds, for instance to verify that a makefile cleanup didn't > >>> accidentally change something. A prime example is /proc/config.gz, which > >>> has both a timestamp in the gzip header and a timestamp in the payload > >>> data. With this series applied, a script like this will produce > >>> identical kernels each time: > >> > >> Very nice stuff. Do you want to take the individual patches through one > >> of your trees, or do you mind if the subsystem maintainers take them > >> through theirs? > > > > I'm happy for this to go through a single tree. > > Me too. > > With respect to the patches I was c/c (patches 13, 14, 31): > > Acked-by: Mauro Carvalho Chehab Me too. Acked-by: Greg Kroah-Hartman on the patches I was copied on. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 00/34] Make kernel build deterministic
On Tue, 2011-04-05 at 08:49 -0700, Greg KH wrote: > On Tue, Apr 05, 2011 at 04:58:47PM +0200, Michal Marek wrote: > > > > Hi, > > > > this series makes it possible to build bit-identical kernel image and > > modules from identical sources. Of course the build is already > > deterministic in terms of behavior of the code, but the various > > timestamps embedded in the object files make it hard to compare two > > builds, for instance to verify that a makefile cleanup didn't > > accidentally change something. A prime example is /proc/config.gz, which > > has both a timestamp in the gzip header and a timestamp in the payload > > data. With this series applied, a script like this will produce > > identical kernels each time: > > Very nice stuff. Do you want to take the individual patches through one > of your trees, or do you mind if the subsystem maintainers take them > through theirs? But unfortunately, it is very easy to break this and for sure it'll be broken very soon. So additionally, I'd suggest: 1. Instrument checkpatch.pl and make it err or warn on timestamps. 2. Probably instrument linux-next to rise a warning when people break this. -- Best Regards, Artem Bityutskiy (Битюцкий Артём) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Combining multiple NAND MTDs
Hello, I have an 8308 using the fsl_elbc_nand NAND controller. I have chip selects 2 & 3 hooked up to a single die multiple chip select NAND chip. I have programmed u-boot and the kernel correctly and the NAND "chips" are found: NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit) eLBC NAND device at 0xe060, bank 1 NAND device: Manufacturer ID: 0xec, Chip ID: 0xd3 (Samsung NAND 1GiB 3,3V 8-bit) eLBC NAND device at 0xe0608000, bank 2 The nand chips are correctly show up: # cat /proc/mtd dev:size erasesize name mtd0: 0200 0002 "fe00.flash" mtd1: 4000 0002 "e060.flash" mtd2: 4000 0002 "e0608000.flash" (mtd0 is unrelated NOR part). I want to run UBIFS on the combined 2 gigs of flash. Whats the best way to do this? I tried using the mtdconcat stuff and wrote a small driver but I am not sure how to populate the mtd_info structure since do_probe_map doesn't work with NAND AFAIK. I see that fsl_elbc_select_chip says "hardware does not seem to support this". Not sure if this is related. I see some comments in mtd-physmap.txt about using multiple reg ranges? Does this work with NAND? Thanks for any pointers, Barry ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/book3e: Fix extlb size
On Tue, 2011-04-05 at 07:41 -0500, Kumar Gala wrote: > > Rework it to make it a bit clearer, and also correct. We want 3 save > > areas, each EX_TLB_SIZE _bytes_. > > Where does the 3 come from? I have a guess, and think its possible we > (FSL) want 4? Wrong guess :-) It's not about exception levels. It's about how much the handler can re-enter (2 with E.PT, 3 with virtual linear) For MC's, CRITs etc... which we don't support on Book3E 64-bit at this stage, you'll have to probably backup the whole area... that or move the TLB frame pointer SPR to a separate set of 3 levels, but then you'd have to fix the code that makes assumption about level 0 being at a fixed offset in the PACA and instead use alignment tricks. We need that because that's how we "reset" the TLB frame when a second level finds a fault. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: sdhc/mpc8536 - SDCard always detected like read-only
> sdhci@2e000 {
> compatible = "fsl,mpc8536-esdhc", "fsl,esdhc";
> reg = <0x2e000 0x1000>;
> interrupts = <72 0x2>;
> interrupt-parent = <&mpic>;
> /* Filled in by U-Boot */
> clock-frequency = <0>;
> };
Hmm, I am not too familiar with those SoCs, yet some 83xx needed
sdhci,wp-inverted;
here. Maybe yours, too? Would fit the symptoms.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/book3e: Fix extlb size
On Apr 5, 2011, at 6:39 PM, Benjamin Herrenschmidt wrote: > On Tue, 2011-04-05 at 07:41 -0500, Kumar Gala wrote: >>> Rework it to make it a bit clearer, and also correct. We want 3 save >>> areas, each EX_TLB_SIZE _bytes_. >> >> Where does the 3 come from? I have a guess, and think its possible we >> (FSL) want 4? > > Wrong guess :-) It's not about exception levels. It's about how much > the handler can re-enter (2 with E.PT, 3 with virtual linear) > > For MC's, CRITs etc... which we don't support on Book3E 64-bit at this > stage, you'll have to probably backup the whole area... that or move > the TLB frame pointer SPR to a separate set of 3 levels, but then you'd > have to fix the code that makes assumption about level 0 being at a > fixed offset in the PACA and instead use alignment tricks. We need that > because that's how we "reset" the TLB frame when a second level finds > a fault. > > Cheers, > Ben. Gotcha, can we add a comment here about what the '3' is about. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
The CPU_FTRS_POSSIBLE and CPU_FTRS_ALWAYS defines did not encompass
e5500 CPU features when built for 64-bit. This causes issues with
cpu_has_feature() as it utilizes the POSSIBLE & ALWAYS defines as part
of its check.
Signed-off-by: Kumar Gala
---
* I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not.
I'm assuming this is the reason that we use a #define on __powerpc64__
arch/powerpc/include/asm/cputable.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index be3cdf9..8200e9d 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -434,7 +434,7 @@ extern const char *powerpc_base_platform;
CPU_FTR_PURR | CPU_FTR_REAL_LE | CPU_FTR_NO_SLBIE_B)
#define CPU_FTRS_COMPATIBLE(CPU_FTR_USE_TB | CPU_FTR_PPCAS_ARCH_V2)
-#ifdef __powerpc64__
+#if defined(__powerpc64__) && !defined(CONFIG_PPC_BOOK3E)
#define CPU_FTRS_POSSIBLE \
(CPU_FTRS_POWER3 | CPU_FTRS_RS64 | CPU_FTRS_POWER4 |\
CPU_FTRS_PPC970 | CPU_FTRS_POWER5 | CPU_FTRS_POWER6 | \
@@ -478,7 +478,7 @@ enum {
};
#endif /* __powerpc64__ */
-#ifdef __powerpc64__
+#if defined(__powerpc64__) && !defined(CONFIG_PPC_BOOK3E)
#define CPU_FTRS_ALWAYS\
(CPU_FTRS_POWER3 & CPU_FTRS_RS64 & CPU_FTRS_POWER4 &\
CPU_FTRS_PPC970 & CPU_FTRS_POWER5 & CPU_FTRS_POWER6 & \
--
1.7.3.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc/book3e: Fix CPU feature handling on e5500
Hi Kumar, On Wed, 6 Apr 2011 00:29:32 -0500 Kumar Gala wrote: > > * I'm concerned if its ok to assume 'enum' can handle a 64-bit mask or not. > I'm assuming this is the reason that we use a #define on __powerpc64__ enums are *ints* and therefore 32 bit. gcc can cope, but warns about it (I think). So we must use the #define if any of the included bits are above 2^32. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpyjmkHUlgyg.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
