Hi,
On 04/14/2014 08:19 PM, Clement Wong wrote:
Hi Hans,
Can A10/20 runs on mainline without hacks now?
As a headless server mostly yes, the only thing we're missing
for that scenario is mmc / sdcard support.
What's works and what doesn't?
Working:
* The basics: cpu bringup, interrupts,
The CubieTruck has an AMPAK AP6210 WiFi+Bluetooth module. The Bluetooth
part is a BCM20710 device connected to UART2 in the A20 SoC.
The IC requires a 32.768 KHz low power clock input for proper
auto-detection of the main clock, and an enable signal via GPIO.
Signed-off-by: Chen-Yu Tsai
rfkill-gpio has clk_enabled = blocked, which is true when rfkill
blocks the device. This results in calling clock enable/disable at
the wrong time. Reversing the value fixes this.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
net/rfkill/rfkill-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1
Some devices, such as Broadcom Bluetooth devices, require a specific
clock rate for the clock tied to the rfkill device. Add a clock-frequency
property so we can specify this from the device tree.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
.../devicetree/bindings/rfkill/rfkill-gpio.txt | 24 ++
net/rfkill/rfkill-gpio.c | 23 +
2 files changed, 47 insertions(+)
create mode 100644
This patch provides of_get_gpiod_flags_by_name(), which looks up GPIO
phandles by name only, through gpios/gpio-names, and not by index.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
drivers/gpio/gpiolib-of.c | 48 +++
include/linux/of_gpio.h | 3
Hi everyone,
This patch series adds device tree support to rfkill-gpio, and
fixes some issues I ran into. This is so we can define and control
RF devices through the device tree, such as the Broadcom BCM20710
UART-based Bluetooth device found on the CubieTruck.
The series is based on Heikki's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/04/2014 23:04, Mark Brown wrote:
On Mon, Apr 14, 2014 at 03:08:05PM +0200, Boris BREZILLON wrote:
SMBus is a subset of the I2C protocol, oftenly used to access
registers on
external devices.
This is basically fine. However...
+
On Mon, Apr 14, 2014 at 11:15 PM, Hans de Goede hdego...@redhat.com wrote:
Hi Arend,
On 04/11/2014 12:31 PM, Arend van Spriel wrote:
Hi Hans,
I have put some effort in adding device tree support in brcmfmac.
Unfortunately, I had no luck getting MMC up and running on pandaboard
extension
Hi Hans,
On Mon, Apr 14, 2014 at 11:23 PM, Hans de Goede hdego...@redhat.com wrote:
Hi All,
I've just updated:
https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
to 3.15-rc1
This means that a whole lot of patches have been dropped as they have all
been merged, hurray! The big
On Tue, Apr 15, 2014 at 09:36:13AM +0200, Boris BREZILLON wrote:
On 14/04/2014 23:04, Mark Brown wrote:
The transfer type gets set once per device at init time so why not
just parameterise based on val_bytes?
Actually, you may want to transfer 1 byte registers using the block
method (if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/04/2014 12:09, Mark Brown wrote:
On Tue, Apr 15, 2014 at 09:36:13AM +0200, Boris BREZILLON wrote:
On 14/04/2014 23:04, Mark Brown wrote:
The transfer type gets set once per device at init time so why not
just parameterise based on
On Tue, Apr 15, 2014 at 01:54:02PM +0200, Boris BREZILLON wrote:
On 15/04/2014 12:09, Mark Brown wrote:
OK, so if this a realistic issue then it seems like it's better to
implement three different buses - there is not really any common code
between the various paths.
Okay, I'll create 4
On Sunday, April 13, 2014 11:09:10 PM UTC+4:30, mahdi taheri wrote:
No Idea,help or suggestion? It is really important for me. no body can
help?
maybe I can solve it by udev or I shall try with kernel?
--
You received this message because you are subscribed to the Google Groups
On 15/04/2014 14:25, Lars-Peter Clausen wrote:
On 04/15/2014 01:54 PM, Boris BREZILLON wrote:
On 15/04/2014 12:09, Mark Brown wrote:
On Tue, Apr 15, 2014 at 09:36:13AM +0200, Boris BREZILLON wrote:
On 14/04/2014 23:04, Mark Brown wrote:
The transfer type gets set once per device at init
On Tue, Apr 15, 2014 at 02:25:15PM +0200, Lars-Peter Clausen wrote:
On 04/15/2014 01:54 PM, Boris BREZILLON wrote:
And, should I keep one method to register an smbus regmap or should I
provide one method per access type and get rid of the
regmap_smbus_transfer_type enum ?
I don't think we
On 04/15/2014 02:40 PM, Boris BREZILLON wrote:
On 15/04/2014 14:25, Lars-Peter Clausen wrote:
On 04/15/2014 01:54 PM, Boris BREZILLON wrote:
On 15/04/2014 12:09, Mark Brown wrote:
On Tue, Apr 15, 2014 at 09:36:13AM +0200, Boris BREZILLON wrote:
On 14/04/2014 23:04, Mark Brown wrote:
On 04/15/2014 02:56 PM, Mark Brown wrote:
[...]
My suggestion is that in regmap_init_i2c() you check the capabilities of the
I2C adapter. If it supports native I2C you setup the regmap with the
regmap_i2c struct just as it does right now. If the adapter does not support
native I2C, check if the
Hi Chen-Yu,
On Tue, Apr 15, 2014 at 02:41:35PM +0800, Chen-Yu Tsai wrote:
This patch provides of_get_gpiod_flags_by_name(), which looks up GPIO
phandles by name only, through gpios/gpio-names, and not by index.
IIRC, gpios only uses the *-gpios properties, and not gpios/gpio-names
pattern seen
On Tue, Apr 15, 2014 at 02:41:37PM +0800, Chen-Yu Tsai wrote:
rfkill-gpio calls clk_enable() without first calling clk_prepare(),
resulting in a warning and no effect. Switch to clk_prepare_enable()
and clk_disable_unprepare.
Signed-off-by: Chen-Yu Tsai w...@csie.org
Acked-by: Maxime Ripard
On Tue, Apr 15, 2014 at 02:41:38PM +0800, Chen-Yu Tsai wrote:
rfkill-gpio has clk_enabled = blocked, which is true when rfkill
blocks the device. This results in calling clock enable/disable at
the wrong time. Reversing the value fixes this.
Signed-off-by: Chen-Yu Tsai w...@csie.org
On Tue, Apr 15, 2014 at 02:41:40PM +0800, Chen-Yu Tsai wrote:
Some devices, such as Broadcom Bluetooth devices, require a specific
clock rate for the clock tied to the rfkill device. Add a clock-frequency
property so we can specify this from the device tree.
Signed-off-by: Chen-Yu Tsai
Ok, I need to ask you for some help, as it seems that you've done a lot on
Mali. I don't need any code help or similar, just a few sentences will do
if you have time :)
Currently I have OpenGL accelerated Qt, by using normal linux-sunxi with
r3p0 Mali drivers - I've noticed that you did your
On Tue, Apr 15, 2014 at 10:42 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Tue, Apr 15, 2014 at 02:41:41PM +0800, Chen-Yu Tsai wrote:
The CubieTruck has an AMPAK AP6210 WiFi+Bluetooth module. The Bluetooth
part is a BCM20710 device connected to UART2 in the A20 SoC.
The IC
For our use case here, which is a bluetooth chip connected on the UART,
there is no in kernel representation or driver to tie them to. Same goes
for UART based GPS chips. They just so happen to require toggling a GPIO,
and maybe enabling a specific clock, to get it running. Afterwards,
On Tue, Apr 15, 2014 at 03:34:55PM +0200, Lars-Peter Clausen wrote:
On 04/15/2014 02:56 PM, Mark Brown wrote:
- Providing APIs for registering actual smbus devices as a convenience
for devices with that constraint, regardless of how that is done
behind the scenes.
- Having the
Looks exciting!! Especially for us who use full HD!
Hope we'll be able to test something soon. :)
Clement
On Apr 6, 2014, at 12:43 PM, Siarhei Siamashka siarhei.siamas...@gmail.com
wrote:
On Sat, 05 Apr 2014 17:58:11 +0200
Jens Kuske jensku...@gmail.com wrote:
On 03/04/14 07:49, Siarhei
On Tue, Apr 15, 2014 at 09:18:11PM +0200, Lars-Peter Clausen wrote:
On 04/15/2014 06:46 PM, Mark Brown wrote:
Please note what I said about convenience - if lots of devices have
exactly the same set of constraints to set up it's possible sensible to
have a standard way of specifying them.
Thanks Hans,
On the mmc stuff, I just tested the latest code and I'm still getting
errors on my SDXC (64G) card. The SDXC card works fine on an x86 machine.
I'm having no issues with SDHC cards.
Running a 'grep -Ri sunxi' on the linux source tree results in I/O errors:
grep:
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
+Optional properties:
+- clocks : phandle to clock to enable/disable
Oh, and can't we use clock-names
On 04/15/2014 12:41 AM, Chen-Yu Tsai wrote:
Patch description?
diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt
+Required properties:
+- gpios : At most two GPIO phandles
+- gpio-names : Shall be
31 matches
Mail list logo
