Sunxi platforms come with at least 3 TWI (I2C) controllers and some platforms
even have up to 5. This adds support for every controller on each supported
platform, which is especially useful when using expansion ports on single-board-
computers.
Signed-off-by: Paul Kocialkowski
---
arch/arm/incl
Orion5x, Kirkwood and Armada XP platforms come with a single TWSI (I2C) MVTWSI
controller. However, other platforms using MVTWSI may come with more: this is
the case on Allwinner (sunxi) platforms, where up to 4 controllers can be found
on the same chip.
Signed-off-by: Paul Kocialkowski
---
arch
Changes since v4:
* Got rid of Kconfig after all
* Only build mvtwsi when at least one controller is enabled on sunxi
* Controller 0 doesn't have to be enabled in particular
Changes since v3:
* Kconfig support for MVTWSI
* Only enable twsi0 by default for platforms that always use it for the AXP
*
On 4 April 2015 at 02:38, Thomas Chou wrote:
>
> Hi Simon,
>
>
> On 2015年04月04日 07:57, Simon Glass wrote:
>>
>> This function should not return a value.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> arch/nios2/cpu/fdt.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/arch/nios2/cp
Initially I found this driver has set priv_auto_alloc_size but it actually
never use dev->priv. The U_BOOT_DEVICE(lpc32xx_gpios) does not provide the
platdata and all fields in struct lpc32xx_gpio_platdata are set in probe.
It looks like the struct lpc32xx_gpio_platdata actually should be a priv
da
As best I can tell, there's no difference between bulk and interrupt
transfers in terms of how the HW should be programmed, at least given
that we're executing one transaction at a time rather than scheduling
them into frames for maximum throughput.
This patch ends up sharing the toggle bit state
A bit must be set in HCCHAR when communicating with low-speed devices.
I have no idea why there's no corresponding bit to distinguish between
full-speed and high-speed devices, but no matter; they all work now!
Signed-off-by: Stephen Warren
---
drivers/usb/host/dwc2.c | 21 -
If the USB transfer fails or otherwise returns no data, don't process the
(non-existent) reponse data and generate keypresses from it. Doing so
makes each successful transaction appear to be a new keypress, which
results in ridiculously fast key repeat rates.
FIXME: This breaks USB keyboard on at
On 03/27/2015 11:06 AM, Albert ARIBAUD wrote:
> On Fri, 27 Feb 2015 02:40:33 +0900, Masahiro Yamada
> wrote:
>> My main motivations for this commit are:
>>
>> [1] Follow the arch/arm/Makefile style of Linux Kernel
>>
>> [2] Maintain compiler options systematically
>> Currently, we give -march=*
On 04/10/2015 09:07 PM, Stephen Warren wrote:
> If the USB transfer fails or otherwise returns no data, don't process the
> (non-existent) reponse data and generate keypresses from it. Doing so
> makes each successful transaction appear to be a new keypress, which
> results in ridiculously fast key
On 2015-04-11 05:49, Stephen Warren wrote:
> On 03/27/2015 11:06 AM, Albert ARIBAUD wrote:
>> On Fri, 27 Feb 2015 02:40:33 +0900, Masahiro Yamada
>> wrote:
>>> My main motivations for this commit are:
>>>
>>> [1] Follow the arch/arm/Makefile style of Linux Kernel
>>>
>>> [2] Maintain compiler opt
11 matches
Mail list logo
