14 Nov, 2011

7 commits


10 Nov, 2011

1 commit


09 Nov, 2011

1 commit


08 Nov, 2011

1 commit


07 Nov, 2011

1 commit

  • * Have different dev_cfg structures and setup functions for new, old
    beaglebone boards setup pin mux accordingly

    * Fall back to older Bone boards if EEPROM reads are incorrect or empty

    * Read version field of EEPROM config to call correct setup_beaglebone
    function according to board version

    While at it, clean-up a bad comment style in existing code.

    Signed-off-by: Steve Kipisz
    Signed-off-by: Joel A Fernandes
    Signed-off-by: Sekhar Nori

    Joel A Fernandes
     

04 Nov, 2011

4 commits


02 Nov, 2011

1 commit


28 Oct, 2011

5 commits

  • Fix,

    arch/arm/mach-omap2/board-generic.c:76:20: warning: 'omap4_init' defined but not used

    Signed-off-by: Afzal Mohammed

    Afzal Mohammed
     
  • Fix,

    arch/arm/plat-omap/sram.c: In function 'omap3_sram_restore_context':
    arch/arm/plat-omap/sram.c:330:3: warning: initialization makes pointer from integer without a cast
    arch/arm/mach-omap2/pm34xx.c: In function 'omap_push_sram_idle':
    arch/arm/mach-omap2/pm34xx.c:848:22: warning: initialization makes pointer from integer without a cast
    arch/arm/mach-omap2/pm34xx.c:851:28: warning: initialization makes pointer from integer without a cast

    Signed-off-by: Afzal Mohammed

    Afzal Mohammed
     
  • JFFS2 clean marker offset used by Linux in case of 8-bit NAND device is
    0x1 omap2 NAND driver. But 1st 2 bytes is used to indicate bad blocks by
    manufacturers. So offset for JFFS2 clean markers is fixed to 0x2 in
    omap2 NAND driver irrespective of 8/16 bit device.
    Introduced new macro : JFFS2_CLEAN_MARKER_OFFSET to indicate 0x2 offset
    for JFFS2 clean marker.

    Signed-off-by: Philip, Avinash

    Philip, Avinash
     
  • For OOb_64, offset is fixed to 40 for kernel/fs, by changing
    kernel code to calculate hw_ecc layout considering these:
    1) 12 bytes in case of 512 byte access and 24 bytes in case of 256 byte
    access in OOB_64 can be supported.
    2) Ecc bytes lie to the end of OOB area.
    Introducing a new macro : MAX_HWECC_BYTES_OOB_64 which is the maximum
    number of eccbytes supported for OOB_64n Hamming ECC mode.

    Signed-off-by: Hrishikesh Bhandiwad
    Signed-off-by: Philip, Avinash

    Hrishikesh Bhandiwad
     
  • NAND ECC layout is updated in case of Hardware ECC scheme selection from
    platform data.
    ECC scheme to be used is indicated via the platform data in the board file.

    Signed-off-by: Philip, Avinash

    Philip, Avinash
     

27 Oct, 2011

19 commits