Merge tag 's3c24xx-driver-1' of...

		#gpio-cells = <4>;

		gpio-controller;

	};

Samsung S3C24XX GPIO Controller

Required properties:

- compatible: Compatible property value should be "samsung,s3c24xx-gpio".

- reg: Physical base address of the controller and length of memory mapped

  region.

- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes

  should be the following with values derived from the SoC user manual.

     <[phandle of the gpio controller node]

      [pin number within the gpio controller]

      [mux function]

      [flags and pull up/down]

  Values for gpio specifier:

  - Pin number: depending on the controller a number from 0 up to 15.

  - Mux function: Depending on the SoC and the gpio bank the gpio can be set

                  as input, output or a special function

  - Flags and Pull Up/Down: the values to use differ for the individual SoCs

                    example S3C2416/S3C2450:

                            0 - Pull Up/Down Disabled.

                            1 - Pull Down Enabled.

                            2 - Pull Up Enabled.

          Bit 16 (0x00010000) - Input is active low.

  Consult the user manual for the correct values of Mux and Pull Up/Down.

- gpio-controller: Specifies that the node is a gpio controller.

- #address-cells: should be 1.

- #size-cells: should be 1.

Example:

	gpa: gpio-controller@56000000 {

		#address-cells = <1>;

		#size-cells = <1>;

		compatible = "samsung,s3c24xx-gpio";

		reg = <0x56000000 0x10>;

		#gpio-cells = <3>;

		gpio-controller;

	};

Required Properties:

- compatible: should be one of the following.

  - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller,

  - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller,

  - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller,

  - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller,

  - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,

  - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.

  - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.

   - compatible: identifies the type of the external wakeup interrupt controller

     The possible values are:

     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller

       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,

     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller

       found on Samsung S3C2412 and S3C2413 SoCs,

     - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller

       found on Samsung S3C64xx SoCs,

     - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller

After a while you will start to get messages about current status or error like

in the original code.

Note that running a new test will stop any in progress test.

Note that running a new test will not stop any in progress test.

The following command should return actual state of the test.

	% cat /sys/kernel/debug/dmatest/run

The module parameters that is supplied to the kernel command line will be used

for the first performed test. After user gets a control, the test could be

interrupted or re-run with same or different parameters. For the details see

the above section "Part 2 - When dmatest is built as a module..."

re-run with the same or different parameters. For the details see the above

section "Part 2 - When dmatest is built as a module..."

In both cases the module parameters are used as initial values for the test case.

You always could check them at run-time by running

	removing extended attributes) the on-disk superblock feature

	bit field will be updated to reflect this format being in use.

	CRC enabled filesystems always use the attr2 format, and so

	will reject the noattr2 mount option if it is set.

  barrier

	Enables the use of block layer write barriers for writes into

	the journal and unwritten extent conversion.  This allows for

      fix_the_problem(ucp->dar);

    }

When in an active transaction that takes a signal, we need to be careful with

the stack.  It's possible that the stack has moved back up after the tbegin.

The obvious case here is when the tbegin is called inside a function that

returns before a tend.  In this case, the stack is part of the checkpointed

transactional memory state.  If we write over this non transactionally or in

suspend, we are in trouble because if we get a tm abort, the program counter and

stack pointer will be back at the tbegin but our in memory stack won't be valid

anymore.

To avoid this, when taking a signal in an active transaction, we need to use

the stack pointer from the checkpointed state, rather than the speculated

state.  This ensures that the signal context (written tm suspended) will be

written below the stack required for the rollback.  The transaction is aborted

becuase of the treclaim, so any memory written between the tbegin and the

signal will be rolled back anyway.

For signals taken in non-TM or suspended mode, we use the

normal/non-checkpointed stack pointer.

Failure cause codes used by kernel

==================================

kernel aborted a transaction:

 TM_CAUSE_RESCHED       Thread was rescheduled.

 TM_CAUSE_TLBI          Software TLB invalide.

 TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.

 TM_CAUSE_SYSCALL       Currently unused; future syscalls that must abort

                        transactions for consistency will use this.

 TM_CAUSE_SIGNAL        Signal delivered.

 TM_CAUSE_MISC          Currently unused.

 TM_CAUSE_ALIGNMENT     Alignment fault.

 TM_CAUSE_EMULATE       Emulation that touched memory.

These can be checked by the user program's abort handler as TEXASR[0:7].

These can be checked by the user program's abort handler as TEXASR[0:7].  If

bit 7 is set, it indicates that the error is consider persistent.  For example

a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.q

GDB

===