On Tue, 2014-06-03 at 15:11 +0900, Masahiro Yamada wrote:
> Could you fill the maintainers field (the last field of boards.cfg)?
Hans de Goede has a follow up series which includes this change.
Thanks,
Ian.
--
You received this message because you are subscribed to the Google Groups
"linux-su
On 3 June 2014 03:50, Jaehoon Chung wrote:
> +Suegnwon Jeon
>
> On 06/02/2014 05:48 PM, Ulf Hansson wrote:
>> On 2 June 2014 10:38, Jaehoon Chung wrote:
>>> On 06/02/2014 05:29 PM, Ulf Hansson wrote:
On 1 June 2014 11:23, Hans de Goede wrote:
> Hi,
>
>
> On 05/31/2014 10:13
From: Sascha Hauer
This adds SDIO devicetree subnode parsing to the mmc core. While
SDIO devices are runtime probable they sometimes need nonprobable
additional information on embedded systems, like an additional gpio
interrupt or a clock. This patch makes it possible to supply this
information f
Hi All,
Here is v3 of my submission of Sascha Hauer's
"mmc: Add SDIO function devicetree subnode parsing" patch.
Changes since v1:
- Submit as a stand-alone patch-set, rather then as part of a larger oob irq
support patchset crossing multiple subsystems
- Add a patch to document the already exi
From: Sascha Hauer
While SDIO devices are runtime probable they sometimes need nonprobable
additional information on embedded systems, like an additional gpio
interrupt or a clock. This binding describes how to add child nodes to the
devicetree to supply this information.
Signed-off-by: Sascha H
Input, nom nom nom!
I cut by {0x7c,0xFF16} termination I get 14 blocks.
Which is interesting because doing "strings" on your android driver I see:
Downlaod GSL1680E_FW_86VS_INET
Downlaod GSL1680E_FW_86VSH_INET
Downlaod GSL1680E_FW_66V_M4302_INET_V2
Downlaod GSL3680_FW_shenghexiang0072
Downl
On Sat, May 31, 2014 at 04:01:38PM +0200, Hans de Goede wrote:
> For level triggered gpio interrupts we need to use handle_fasteoi_irq,
> like we do with the irq-sunxi-nmi driver. This is necessary to give threaded
> interrupt handlers a chance to actuall clear the source of the interrupt
> (which
Hi all,
I am trying to use a pca9535 i2c gpio expander with interrupts on an A10
based board and struggled. I have figured out that the problem is the lack
of free virtual/software interrupts as configured in
arch/arm/plat-sunxi/include/plat/irqs.h. In that file NR_IRQS is coded as
(96+32) w
On Sat, May 31, 2014 at 04:01:39PM +0200, Hans de Goede wrote:
> Some drivers use disable_irq / enable_irq and do the work clearing the source
> in another thread instead of using a threaded interrupt handler.
>
> The irqchip used not having irq_disable and irq_enable callbacks in this case,
> wil
On Tue, Jun 3, 2014 at 3:46 PM, theRat wrote:
> Hi all,
>
> I am trying to use a pca9535 i2c gpio expander with interrupts on an A10
> based board and struggled. I have figured out that the problem is the lack
> of free virtual/software interrupts as configured in
> arch/arm/plat-sunxi/include/pl
Only once NR_IRQS is increased. On an A10 it is set at 128, the request
for 16 irqs fails in the pca953x driver. If NR_IRQS is increased the irqs
that get allocated are 127-142. When you export the gpios that are created
(240-255) they then get the edge file included in the sysfs.
On Tuesday
Hi,
On 06/03/2014 03:30 PM, Maxime Ripard wrote:
On Sat, May 31, 2014 at 04:01:38PM +0200, Hans de Goede wrote:
For level triggered gpio interrupts we need to use handle_fasteoi_irq,
like we do with the irq-sunxi-nmi driver. This is necessary to give threaded
interrupt handlers a chance to actu
Hi,
On 06/03/2014 03:47 PM, Maxime Ripard wrote:
On Sat, May 31, 2014 at 04:01:39PM +0200, Hans de Goede wrote:
Some drivers use disable_irq / enable_irq and do the work clearing the source
in another thread instead of using a threaded interrupt handler.
The irqchip used not having irq_disable
Hi,
On 06/02/2014 01:59 PM, Maxime Ripard wrote:
On Sat, May 31, 2014 at 04:01:37PM +0200, Hans de Goede wrote:
With level triggered interrupt mask / unmask will get called for each
interrupt, doing the somewhat expensive mux setting on each unmask thus is
not a good idea. Instead add a request
Full dmesg of TPC now:
https://www.dropbox.com/s/m9bv990gcjzn6rt/dmesg.txt
So after you cut the fw, 14 blocks? Hmmm, this is almost a go.
I'll try out fw_extractor and fw_info again and see which file makes it work.
Other source code I've seen needs firmware + config.
The 3.4 kernel continued to
Great news!
It works! Backwards... Basically the board was the 3rd in that list (INET_66V),
but that's an easy fix in the script.bin with the x y order.
Here's the firmware for 420TPC:
https://www.dropbox.com/s/7fz9i74l8rp70pk/420TPC.fw
Thank you for this amazing tool and driver port!
Stay tune
yer!!! \o/
I'll add your firmware to the others.
I take it this is still with the 3.0 kernel?
Can you humour me and try 3.4 with the suspend and Android stuff removed?
It is works with Android without the untested Android and suspend stuff,
I'll just drop them, and I don't have the guilt of car
Ühel kenal päeval, T, 03.06.2014 kell 20:10, kirjutas Joe Burmeister:
> yer!!! \o/
>
> I'll add your firmware to the others.
>
> I take it this is still with the 3.0 kernel?
> Can you humour me and try 3.4 with the suspend and Android stuff removed?
> It is works with Android without the untested
Hi,
Thank you for your update. Now I can load the correct firmware for my IC.
I also have a suggestion: With A20, I think you should remove
"IRQF_TRIGGER_FALLING |".
WITH ORIGINAL SOURCE CODE, dmesg shows the error with irq:
[ 23.424864] ===gslx680_ts_init==
There is something about it, and another GSLX680 driver (userspace one) at:
http://linux-sunxi.org/index.php?title=GSL1680
Really I should start the process of getting it merged so it's not out
of tree. Then it will be a case of instructions to get it working, which
should be get/extract firmwa
20 matches
Mail list logo
