Re: [linux-sunxi] Video chip in A31 box
On Tue, Jan 28, 2014 at 04:16:00PM -0500, jonsm...@gmail.com wrote: > > > > I know that our support for A31 is severely lacking, but please work > > through the http://linux-sunxi.org/New_Device_howto anyway. > > Not sure I am going to work on this board. I missed the fact that it > doesn't have a SD Card slot when I bough it. So you're not even intending to document your findings about this hardware? Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: [PATCH RFC 4/6] net: rfkill: gpio: add device tree support
Hi, On Mon, Jan 27, 2014 at 10:24 PM, Maxime Ripard wrote: > Hi, > > On Fri, Jan 17, 2014 at 02:47:29PM +0800, Chen-Yu Tsai wrote: >> Signed-off-by: Chen-Yu Tsai >> --- >> .../devicetree/bindings/rfkill/rfkill-gpio.txt | 26 >> ++ >> net/rfkill/rfkill-gpio.c | 23 +++ >> 2 files changed, 49 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> >> diff --git a/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> new file mode 100644 >> index 000..8a07ea4 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/rfkill/rfkill-gpio.txt >> @@ -0,0 +1,26 @@ >> +GPIO controlled RFKILL devices >> + >> +Required properties: >> +- compatible : Must be "rfkill-gpio". >> +- rfkill-name: Name of RFKILL device >> +- rfkill-type: Type of RFKILL device: 1 for WiFi, 2 for BlueTooth >> +- NAME_shutdown-gpios: GPIO phandle to shutdown control >> + (phandle must be the second) > > Can't it be handled by a regulator? > >> +- NAME_reset-gpios : GPIO phandle to reset control > > And this one using the reset framework? The driver is already used in platform device and ACPI fashions. AFAIK, ACPI only passes the GPIO lines. Preferably the behavior and requirements between the different usages remain the same. Cheers ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 2/8] clk: sunxi: update clock-output-names dt binding documentation
Hi Maxime, On Fri, Jan 17, 2014 at 10:55 AM, Emilio López wrote: > Hi, > > El 09/01/14 05:52, Chen-Yu Tsai escribió: > >> clock-output-names is now required for most of sunxi clock nodes, to >> provide the name of the corresponding clock. Add the new requirements, >> exceptions, as well as examples. >> >> Signed-off-by: Chen-Yu Tsai >> --- >> Documentation/devicetree/bindings/clock/sunxi.txt | 36 >> +++ >> 1 file changed, 31 insertions(+), 5 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt >> b/Documentation/devicetree/bindings/clock/sunxi.txt >> index 0c127cd..8a9147d 100644 >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt >> @@ -44,10 +44,18 @@ Required properties for all clocks: >> multiplexed clocks, the list order must match the hardware >> programming order. >> - #clock-cells : from common clock binding; shall be set to 0 except for >> - "allwinner,*-gates-clk" where it shall be set to 1 >> + "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and >> + "allwinner,sun4i-pll6-clk" where it shall be set to 1 >> >> -Additionally, "allwinner,*-gates-clk" clocks require: >> -- clock-output-names : the corresponding gate names that the clock >> controls >> +Additionally, most clocks require "clock-output-names": >> +- "allwinner,*-gates-clk" : the corresponding gate names that the clock >> controls >> +- "allwinner,sun4i-pll5-clk" : "pll5_ddr", "pll5_mbus" >> +- "allwinner,sun4i-pll6-clk" : "pll6_sata", "pll6_other" >> +- "allwinner,sun4i-cpu-clk", "allwinner,sun4i-axi-clk", >> + "allwinner,sun4i-ahb-clk", "allwinner,sun4i-ahb-clk", >> + "allwinner,sun4i-apb1-mux-clk", "allwinner,sun4i-apb1-clk" >> + do not need "clock-output-names" >> +- all others clocks : the corresponding module name of that clock > > > As we discussed on IRC, I wonder if such verbosity is actually needed. Maybe > we should dictate that all clocks must list their corresponding outputs on > clock-output-names (with it being the module name if it only has one > output). Maxime, could we get your input on this? Thanks ChenYu -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH tools 2/2] Fix bogus usage message in pio tool.
>From c1c9a0432331a59e047a3330f89e2cca27e77b25 Mon Sep 17 00:00:00 2001
Signed-off-by: Michal Suchanek
---
pio.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/pio.c b/pio.c
index e48a660..7ef4514 100644
--- a/pio.c
+++ b/pio.c
@@ -167,8 +167,11 @@ static const char *argv0;
static void usage(int rc )
{
-
- fprintf(stderr, "usage: %s [-m|-i input] [-o output] pin..\n", argv0);
+
+ fprintf(stderr, "usage: %s -m|-i input [-o output] pin..\n", argv0);
+ fprintf(stderr," -m mmap - read pin state
from system\n");
+ fprintf(stderr," -i read pin state from
file\n");
+ fprintf(stderr," -o save pin state data to
file\n");
fprintf(stderr," print Show all pins\n");
fprintf(stderr," PxxShow pin\n");
fprintf(stderr," Pxx Configure pin\n");
@@ -179,7 +182,7 @@ static void usage(int rc )
fprintf(stderr, "\n mode 0-7, 0=input, 1=ouput, 2-7 I/O
function\n");
fprintf(stderr, " pull 0=none, 1=up, 2=down\n");
fprintf(stderr, " drive 0-3, I/O drive level\n");
-
+
exit(rc);
}
--
1.7.10.4
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH tools 1/2] Fix usb-boot usage message.
>From f60714a19c55b1462a5cb2f18d56dce8d5033ec9 Mon Sep 17 00:00:00 2001 When - is specified usb-boot interprets it as kernel so the usage message is clearly bogus. Signed-off-by: Michal Suchanek --- usb-boot |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/usb-boot b/usb-boot index 548cfdc..77e87ce 100755 --- a/usb-boot +++ b/usb-boot @@ -1,7 +1,7 @@ #!/bin/sh -e top=`dirname $0` if [ $# -lt 2 ]; then - echo "Usage: $0 u-boot-spl.bin u-boot.bin [boot.scr|-] [kernel script.bin [initramfs]]" + echo "Usage: $0 u-boot-spl.bin u-boot.bin [boot.scr] [kernel script.bin [initramfs]]" exit 1 fi board=$1; shift || (echo "ERROR: u-boot-spl.bin must be specified"; exit 1;) -- 1.7.10.4 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH 3.4] Revert "usb:sunxi:Fix "device not recognized" problem during android boot (3.4)"
>From c35e54a6500e3b99fa90544d123df306d11f Mon Sep 17 00:00:00 2001
This reverts commit 44a6e1bfed98cd636b55a1191426ce2c373e15b2.
Before this commit USB gadgets work if you boot with cable connected.
eg. download kernel over FEL, mount NFS root over g_ether.
After this commit gadgets only come up if cable is unplugged.
eg. boot, load g_ether (nothing) unplug and replug cable - USB gadget is
seen by the host on the other end of the cable. Only tested the FEL boot
because I have no kernel installed on device.
Signed-off-by: Michal Suchanek
---
drivers/usb/sunxi_usb/udc/sw_udc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/sunxi_usb/udc/sw_udc.c
b/drivers/usb/sunxi_usb/udc/sw_udc.c
index 283ae4c..1e054a5 100644
--- a/drivers/usb/sunxi_usb/udc/sw_udc.c
+++ b/drivers/usb/sunxi_usb/udc/sw_udc.c
@@ -2757,12 +2757,12 @@ static int sw_udc_set_pullup(struct sw_udc *udc, int
is_on)
{
DMSG_DBG_UDC("sw_udc_set_pullup\n");
- is_udc_enable = is_on;
if(!is_peripheral_active()){
DMSG_PANIC("ERR: usb device is not active\n");
return 0;
}
+ is_udc_enable = is_on;
if(is_on){
sw_udc_enable(udc);
--
1.7.10.4
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Video chip in A31 box
On Tue, Jan 28, 2014 at 4:06 PM, Luc Verhaegen wrote: > On Tue, Jan 28, 2014 at 01:59:03PM -0500, jonsm...@gmail.com wrote: >> I just received an A31 box that has a GM7122 chip in it. >> http://www.aliexpress.com/item/CS918S-Android-4-2-2-Set-Top-Box-smart-TV-BOX-camera-Quad-Core-A31-1GB/1529995174.html >> >> http://www.gotecom.com/News_Show.php?id=86 >> >> Any idea why this chip is on the board? It is something to do with HDMI. >> >> Any guesses what that unmarked 8 pin chip in the photo does? It is something to do with power supply. Not sure why it is need with AXP power chip. >> >> I have adb access, what should I look for? >> >> -- >> Jon Smirl >> jonsm...@gmail.com > > I know that our support for A31 is severely lacking, but please work > through the http://linux-sunxi.org/New_Device_howto anyway. Not sure I am going to work on this board. I missed the fact that it doesn't have a SD Card slot when I bough it. > > Luc Verhaegen. > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Video chip in A31 box
On Tue, Jan 28, 2014 at 01:59:03PM -0500, jonsm...@gmail.com wrote: > I just received an A31 box that has a GM7122 chip in it. > http://www.aliexpress.com/item/CS918S-Android-4-2-2-Set-Top-Box-smart-TV-BOX-camera-Quad-Core-A31-1GB/1529995174.html > > http://www.gotecom.com/News_Show.php?id=86 > > Any idea why this chip is on the board? It is something to do with HDMI. > > Any guesses what that unmarked 8 pin chip in the photo does? > > I have adb access, what should I look for? > > -- > Jon Smirl > jonsm...@gmail.com I know that our support for A31 is severely lacking, but please work through the http://linux-sunxi.org/New_Device_howto anyway. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
Hi, On Tue, Jan 28, 2014 at 5:41 PM, Maxime Ripard wrote: > Hi, > > On Tue, Jan 28, 2014 at 12:02:23PM +0100, Hans de Goede wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> On 01/28/2014 11:40 AM, Maxime Ripard wrote: >> >> Jumping in here to try and clarify things, or so I hope at least :) > > Sure :) > >> No, the IRQ from the PMIC is a level sensitive IRQ, so it would look >> like this: > > Hmm, your mailer seems to have mangled your drawing :( > >> The PMIC irq line won't go low until an i2c write to its irq status >> registers write-clears all status bits for which the corresponding >> bit in the irq-mask register is set. > > Which makes sense too > >> And the only reason the NMI -> GIC also goes low is because the unmask >> operation writes a second ack to the NMI controller in the unmask >> callback of the NMI controller driver. > > Yes, and this is exactly what I don't understand. You shouldn't need > that ack in first place, since it's been done already right after the > unmask. But the first ack is ignored since the IRQ line is still maintained asserted by PMIC. >> Note that we cannot use edge triggered interrupts here because the PMIC >> has the typical setup with multiple irq status bits driving a single >> irq line, so the irq handler does read irq-status, handle stuff, >> write-clear irq-status. And if any other irq-status bits get set >> between the read and write-clear the PMIC -> NMI line will stay >> high, as it should since there are more interrupts to handle. > > Yep, the edge-thing was just the only case I could think of where it > could lead to troubles. > > In what you're saying, which makes total sense, if we don't do the > ack, as soon as the irq will be unmasked, since the level is high, the > handler will be called again, treat the new interrupts, and so on. I > don't see how this is an issue actually. This is exactly why in unmask callback we first ACK and then unmask. So, if the line is still maintained up by PMIC then a new interrupt is raised otherwise nothing happens. >> > But in this case, you would have two events coming from your >> > device (the two rising edges), so you'd expect two interrupts. And >> > in the case of a level triggered interrupt, the device would keep >> > the interrupt line active until it's unmasked, so we wouldn't end >> > up with this either. >> > >> >> sunxi_sc_nmi_ack_and_unmask is therefore called (by >> >> irq_finalize_oneshot) after the IRQ thread has been >> >> executed. After the IRQ thread has ACKed the IRQs on the >> >> originating device we can finally ACK and unmask again the NMI. >> > >> > And what happens if you get a new interrupt right between the end >> > of the handler and the unmask? >> >> The implicit ack done by the unmask will be ignored if the NMI line >> is still high, just like the initial ack is ignored (which is why we >> need the mask), and when the unmask completes the irq will >> immediately retrigger, as it should. > > Yeah, but why do we need the ack in the first place? I can't think of > a case where the ACK would be doing something useful. Either: > - there is no new interrupts between the mask/ack and the unmask, so > there's no interrupt to ack. > - There's a new interrupt between the mask/ack and the > unmask. There's two more cases here: > * The interrupt came before the device handler kicked in, and the > handler will treat it/ack it: No issue > * The interrupt comes right after the handler has been acking its > interrupt, the level stays high, your handler is called once > again, you can treat it: No issue AFAIU the problem here is that the only ACK that is able to assert the line NMI -> GIC is the ACK by the unmask callback. All the others ACKs before that one are ignored by the NMI controller since the line PMIC -> NMI is still asserted. >> >>> I really wonder whether it makes sense to have a generic chip >> >>> here. It seems to be much more complicated than it should. It's >> >>> only about a single interrupt interrupt chip here. >> >> >> >> I agree but is there any other way to manage the NMI without the >> >> driver of the device connected to NMI having to worry about >> >> acking/masking/unmasking/ etc..? >> > >> > Yes, just declare a "raw" irqchip. Pretty much like we do on >> > irq-sun4i for example. >> >> Hmm, I'm not going to say that using a raw irqchip here is a bad >> idea, it sounds like it would be better. > > There's none. It was a separate comment :) > >> But I don't think this will solve the need the mask / umask. The >> problem is we need to do an i2c write to clear the interrupt source, >> which needs to be done from a thread / workqueue. So when the >> interrupt handler finishes the source won't be cleared yet, and >> AFAIK then only way to deal with this is to mask the interrupt until >> we've cleared the interrupt source. > > Yes, but the interrupt is still masked during the time between the > "hard" handler and the t
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
On Tue, Jan 28, 2014 at 12:02 PM, Hans de Goede wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > On 01/28/2014 11:40 AM, Maxime Ripard wrote: > > Jumping in here to try and clarify things, or so I hope at least :) Thank you :) I'm sure you will explain this better than me. > The PMIC irq line won't go low until an i2c write to its irq status > registers write-clears all status bits for which the corresponding > bit in the irq-mask register is set. > > And the only reason the NMI -> GIC also goes low is because the unmask > operation writes a second ack to the NMI controller in the unmask > callback of the NMI controller driver. Exactly. PMIC -> NMI is cleared when the irq handler write-clears all the IRQs on PMIC while NMI -> GIC is cleared by the ACK in the unmask callback. > Hmm, I'm not going to say that using a raw irqchip here is a bad idea, it > sounds like it would be better. > > But I don't think this will solve the need the mask / umask. The problem is > we need to do an i2c write to clear the interrupt source, which needs to > be done from a thread / workqueue. So when the interrupt handler finishes > the source won't be cleared yet, and AFAIK then only way to deal with this > is to mask the interrupt until we've cleared the interrupt source. That's why the driver using the NMI controller has to use IRQF_ONESHOT so that the interrupt is not unmasked after the hard interrupt context handler but it is unmasked after the thread handler function has been executed (calling the unmask callback) Thank you for explaining this mess you couldn't be clearer than that. -- Carlo Caione -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH v2 1/5] clk: sunxi: Add support for USB clock-register reset bits
Hi Hans,
El 22/01/14 18:36, Hans de Goede escribió:
The usb-clk register is special in that it not only contains clk gate bits,
but also has a few reset bits. This commit adds support for this by allowing
gates type sunxi clks to also register a reset controller.
Signed-off-by: Hans de Goede
---
(snip)
static const struct gates_data sun4i_axi_gates_data __initconst = {
@@ -818,6 +873,7 @@ static void __init sunxi_gates_clk_setup(struct device_node
*node,
struct gates_data *data)
{
struct clk_onecell_data *clk_data;
+ struct gates_reset_data *reset_data;
const char *clk_parent;
const char *clk_name;
void *reg;
@@ -861,6 +917,21 @@ static void __init sunxi_gates_clk_setup(struct
device_node *node,
clk_data->clk_num = i;
of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+
+ /* Register a reset controler for gates with reset bits */
+ if (data->reset_mask == 0)
+ return;
+
+ reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
+ if (!reset_data)
+ return;
+
+ reset_data->reg = reg;
+ reset_data->lock = &clk_lock;
+ reset_data->rcdev.nr_resets = hweight32(data->reset_mask);
I know I made you change this, but after having a second look into
nr_resets, I think your original implementation makes more sense. This
will break if you use a mask with holes on it. Sorry :(
+ reset_data->rcdev.ops = &sunxi_gates_reset_ops;
+ reset_data->rcdev.of_node = node;
+ reset_controller_register(&reset_data->rcdev);
}
Emilio
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: Video chip in A31 box
On Tue, Jan 28, 2014 at 1:59 PM, jonsm...@gmail.com wrote: > I just received an A31 box that has a GM7122 chip in it. > http://www.aliexpress.com/item/CS918S-Android-4-2-2-Set-Top-Box-smart-TV-BOX-camera-Quad-Core-A31-1GB/1529995174.html > > http://www.gotecom.com/News_Show.php?id=86 > > Any idea why this chip is on the board? It is something to do with HDMI. The GM7122 generates composite video out which is hidden on a third pin in the audio jack. Be careful ordering this, they are multiple versions of the CS918S. I meant to order - 2GB, 16GB, 5MP for $99 http://www.aliexpress.com/item/Free-Shipping-New-CS918S-Quad-Core-Android-TV-Box-2GB-DDR3-16GB-Built-in-5MP-Camera/1479373538.html I got - 1GB, 8GB, 2MP for $85 by accident since I was tricked by the identical part numbers. Not a good deal for $85. > > Any guesses what that unmarked 8 pin chip in the photo does? > > I have adb access, what should I look for? > > -- > Jon Smirl > jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH 3.4] sunxi-hdmiaudio: enable low sample-rate HDMI audi
Cubietruck (A20) connected to a BenQ monitor. The driver advertises SNDRV_PCM_RATE_8000_192000 in sndhdmi.c which I guess is incorrect if HDMI does not support it + I must be very lucky :-) On Tuesday, 28 January 2014 06:39:30 UTC, Rudi wrote: > > Am 27.01.2014 21:54, schrieb Phil Scull: > > > Low sample rate audio was not playing on > patrickhwood/linux-sunxi/tree/pat-3.4.75-ct > > over HDMI. > > The following changes result in sound being played, which can be > demonstrated with > > speaker-test. > > On which devcie did you try ? AFAIK, the HDMI spec does not allow rates > below 32kHz. > So if that works, it's just good luck. My Yamaha AVR for example would not > accept > anything these rates. Not even on S/PDIF. > > > -- > > Ruediger "Rudi" Ihle > > > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
Hi, On Tue, Jan 28, 2014 at 12:02:23PM +0100, Hans de Goede wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > On 01/28/2014 11:40 AM, Maxime Ripard wrote: > > Jumping in here to try and clarify things, or so I hope at least :) Sure :) > No, the IRQ from the PMIC is a level sensitive IRQ, so it would look > like this: Hmm, your mailer seems to have mangled your drawing :( > The PMIC irq line won't go low until an i2c write to its irq status > registers write-clears all status bits for which the corresponding > bit in the irq-mask register is set. Which makes sense too > And the only reason the NMI -> GIC also goes low is because the unmask > operation writes a second ack to the NMI controller in the unmask > callback of the NMI controller driver. Yes, and this is exactly what I don't understand. You shouldn't need that ack in first place, since it's been done already right after the unmask. > Note that we cannot use edge triggered interrupts here because the PMIC > has the typical setup with multiple irq status bits driving a single > irq line, so the irq handler does read irq-status, handle stuff, > write-clear irq-status. And if any other irq-status bits get set > between the read and write-clear the PMIC -> NMI line will stay > high, as it should since there are more interrupts to handle. Yep, the edge-thing was just the only case I could think of where it could lead to troubles. In what you're saying, which makes total sense, if we don't do the ack, as soon as the irq will be unmasked, since the level is high, the handler will be called again, treat the new interrupts, and so on. I don't see how this is an issue actually. > > But in this case, you would have two events coming from your > > device (the two rising edges), so you'd expect two interrupts. And > > in the case of a level triggered interrupt, the device would keep > > the interrupt line active until it's unmasked, so we wouldn't end > > up with this either. > > > >> sunxi_sc_nmi_ack_and_unmask is therefore called (by > >> irq_finalize_oneshot) after the IRQ thread has been > >> executed. After the IRQ thread has ACKed the IRQs on the > >> originating device we can finally ACK and unmask again the NMI. > > > > And what happens if you get a new interrupt right between the end > > of the handler and the unmask? > > The implicit ack done by the unmask will be ignored if the NMI line > is still high, just like the initial ack is ignored (which is why we > need the mask), and when the unmask completes the irq will > immediately retrigger, as it should. Yeah, but why do we need the ack in the first place? I can't think of a case where the ACK would be doing something useful. Either: - there is no new interrupts between the mask/ack and the unmask, so there's no interrupt to ack. - There's a new interrupt between the mask/ack and the unmask. There's two more cases here: * The interrupt came before the device handler kicked in, and the handler will treat it/ack it: No issue * The interrupt comes right after the handler has been acking its interrupt, the level stays high, your handler is called once again, you can treat it: No issue > >>> I really wonder whether it makes sense to have a generic chip > >>> here. It seems to be much more complicated than it should. It's > >>> only about a single interrupt interrupt chip here. > >> > >> I agree but is there any other way to manage the NMI without the > >> driver of the device connected to NMI having to worry about > >> acking/masking/unmasking/ etc..? > > > > Yes, just declare a "raw" irqchip. Pretty much like we do on > > irq-sun4i for example. > > Hmm, I'm not going to say that using a raw irqchip here is a bad > idea, it sounds like it would be better. There's none. It was a separate comment :) > But I don't think this will solve the need the mask / umask. The > problem is we need to do an i2c write to clear the interrupt source, > which needs to be done from a thread / workqueue. So when the > interrupt handler finishes the source won't be cleared yet, and > AFAIK then only way to deal with this is to mask the interrupt until > we've cleared the interrupt source. Yes, but the interrupt is still masked during the time between the "hard" handler and the thread, so there's no way you can get an interrupt flood during that time. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 3.4 00/11] sunxi-disp: hotplug + dpms support
Hi, On 01/27/2014 10:28 PM, Phil Scull wrote: Hans, I still have trouble getting the HDMI monitor to come out of suspend running linaro on CT. Removing the lines that switch the clock off and back on again seems to sort the problem. There is probably a deeper underlying issue tho. Interested if you have any thoughts. I don't have any insights on this I'm afraid. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] pio tool usage message is bogus
Hi, On 01/28/2014 02:29 PM, Michal Suchanek wrote: Hello, I have the sauce so I can presumably rip out the useful parts and make own tool but here is what I get with pio: root@A13:/sunxi-tools# ./pio print usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level root@A13:/sunxi-tools# ./pio PF02 usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level pio was orignally written to work on mem-dumps, use -m to make it open /dev/mem and directly read / write the real pio settings. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
These distros all do not have any getty running on the serial port. The virtual terminals should be working, or you can add a /etc/init/ttyS0.conf. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
On 28-01-14 13:57, Puneet B wrote: Hi Dimitriy, I downloded linaro-saucy-developer-20131216-586.tar.gz probably also without GUI. try hansg's fedora images to get yourself more familiar, that should work just fine. google for hansg cubieboard fedora 19 r3; his own repo seems to be down atm and i copied in sdcard and booted. But i got struck here: [7.057834] devtmpfs: mounted <6>Freeing init memory: 216K [7.069043] Freeing init memory: 216K <6>Write protecting the kernel text section c0008000 - c0817000 [7.078378] Write protecting the kernel text section c0008000 - c0817000 <4>init: ureadahead main process (71) terminated with status 5 [7.644747] init: ureadahead main process (71) terminated with status 5 Kindly tell me what will be the issue. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] pio tool usage message is bogus
Hello, I have the sauce so I can presumably rip out the useful parts and make own tool but here is what I get with pio: root@A13:/sunxi-tools# ./pio print usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level root@A13:/sunxi-tools# ./pio PF02 usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
Hi Dimitriy, I downloded linaro-saucy-developer-20131216-586.tar.gz and i copied in sdcard and booted. But i got struck here: [7.057834] devtmpfs: mounted <6>Freeing init memory: 216K [7.069043] Freeing init memory: 216K <6>Write protecting the kernel text section c0008000 - c0817000 [7.078378] Write protecting the kernel text section c0008000 - c0817000 <4>init: ureadahead main process (71) terminated with status 5 [7.644747] init: ureadahead main process (71) terminated with status 5 Kindly tell me what will be the issue. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
> > > but once i boot i got struck here. > > <6>Freeing init memory: 212K > [6.629097] Freeing init memory: 212K > <6>Write protecting the kernel text section c0008000 - c07d2000 > [6.638421] Write protecting the kernel text section c0008000 - c07d2000 > <30>systemd-udevd[165]: starting version 204 > <4>init: plymouth main process (78) killed by ABRT signal > <4>init: plymouth-splash main process (202) terminated with status 2 > <4>init: failsafe main process (225) killed by TERM signal > <4>init: plymouth-stop pre-start process (303) terminated with status 1 > You have no console or output because you are launching empty ubuntu-core, which is a minimalistic package consisting of what you need to install packages with chroot environment. It is not made to be an end user system. Mount this rootfs with your PC, chroot there and install atleast package "ubuntu-minimal". For more info, google manuals for ubuntu-core, there are plenty, both for x86 and ARM. If you don't want to make your own ubuntu from scratch with ubuntu-core as a base, just grab any latest Linaro http://releases.linaro.org/latest/ubuntu/saucy-images and have fun with everything already set up. Best Regards, Dmitriy Beykun -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 01/28/2014 11:40 AM, Maxime Ripard wrote:
Jumping in here to try and clarify things, or so I hope at least :)
> On Fri, Jan 17, 2014 at 09:54:55AM +0100, Carlo Caione wrote:
+/* + * Ack level interrupts right before unmask + * + * In case of
level-triggered interrupt, IRQ line must be acked before it + * is
unmasked or else a double-interrupt is triggered + */ + +static void
sunxi_sc_nmi_ack_and_unmask(struct irq_data *d) +{ + struct
irq_chip_generic *gc = irq_data_get_irq_chip_data(d); + struct
irq_chip_type *ct = irq_data_get_chip_type(d); + u32 mask = d->mask; +
+ if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK) +
ct->chip.irq_ack(d); + + irq_gc_lock(gc); + irq_reg_writel(mask,
gc->reg_base + ct->regs.mask); +
irq_gc_unlock(gc); +}
>>>
>>> Hmmm, handle_level_irq seems to be doing exactly that already. It first
>>> masks and acks the interrupts, and then unmask it, so we should be fine,
>>> don't we?
>>
>> We don't, or at least handle_level_irq doesn't work for all the cases.
>
> This is what I find weird :)
>
>> Let's say (i.e. this is the cubieboard2 case) that to the irqchip is
>> connected to the IRQ line of a PMIC accessed by I2C. In this case we cannot
>> mask/ack the interrupt on the originating device in the hard interrupt
>> handler (in which handle_level_irq is) since we need to access the I2C bus
>> in an non-interrupt context.
>
> We agree here.
>
>> ACKing the IRQ in handle_level_irq at this point is pretty much useless
>> since we still have to ACK the IRQs on the originating device and this will
>> be done in a IRQ thread started after the hard IRQ handler.
>
> Ok, so what you're saying is that you want to adress this case:
>
> handle_level_irq | devicedevice | mask ack handler irq acked
> unmask | ||| | | v vvv v v
>
> NMI -> GIC: ++ +- ---++-+
>
> PMIC -> NMI: +-+ +-+ + +---+
> +
>
> Right?
No, the IRQ from the PMIC is a level sensitive IRQ, so it would look like this:
> handle_level_irq | devicedevice | mask ack handler irq acked
> unmask | ||| | | v vvv v v
>
> NMI -> GIC: +--+ ---+
> +--
>
> PMIC -> NMI: +-+ +
> +--
The PMIC irq line won't go low until an i2c write to its irq status
registers write-clears all status bits for which the corresponding
bit in the irq-mask register is set.
And the only reason the NMI -> GIC also goes low is because the unmask
operation writes a second ack to the NMI controller in the unmask
callback of the NMI controller driver.
Note that we cannot use edge triggered interrupts here because the PMIC
has the typical setup with multiple irq status bits driving a single
irq line, so the irq handler does read irq-status, handle stuff,
write-clear irq-status. And if any other irq-status bits get set
between the read and write-clear the PMIC -> NMI line will stay
high, as it should since there are more interrupts to handle.
> But in this case, you would have two events coming from your device (the two
> rising edges), so you'd expect two interrupts. And in the case of a level
> triggered interrupt, the device would keep the interrupt line active until
> it's unmasked, so we wouldn't end up with this either.
>
>> sunxi_sc_nmi_ack_and_unmask is therefore called (by irq_finalize_oneshot)
>> after the IRQ thread has been executed. After the IRQ thread has ACKed the
>> IRQs on the originating device we can finally ACK and unmask again the NMI.
>
> And what happens if you get a new interrupt right between the end of the
> handler and the unmask?
The implicit ack done by the unmask will be ignored if the NMI line is still
high, just like the initial ack is ignored (which is why we need the mask),
and when the unmask completes the irq will immediately retrigger, as it should.
>>> I really wonder whether it makes sense to have a generic chip here. It
>>> seems to be much more complicated than it should. It's only about a single
>>> interrupt interrupt chip here.
>>
>> I agree but is there any other way to manage the NMI without the driver of
>> the device connected to NMI having to worry about acking/masking/unmasking/
>> etc..?
>
> Yes, just declare a "raw" irqchip. Pretty much like we do on irq-sun4i for
> example.
Hmm, I'm not going to say that using a raw irqchip here is a bad idea, it
sounds like it would be better.
But I don't think this will solve the need the mask / umask. The problem is
we need to do an i2c write to clear the interrupt source, which needs to
be done from a thread / workqueue. So when the int
[linux-sunxi] Re: [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 01/28/2014 10:44 AM, Maxime Ripard wrote: > On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote: "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13 >>> >>> Maybe we can just remove the gates from there? Even though they are gates, >>> they are also (a bit) more than that. >> >> To be clear you mean s/usb-gates-clk/usb-clk/ right ? > > Yep, exactly > >>> I guess that means that we will have the OHCI0 gate declared with >>> <&...-gates-clk 6>, while it's actually the first gate for this clock? >> >> Correct. >> >>> Maybe introducing an offset field in the gates_data would be a good idea, >>> so that we always start from indexing the gates from 0 in the DT? >> >> Well for the other "gates" type clks we also have holes in the range, and we >> always refer to the clk with the bit number in the reg as the clock-cell >> value. > > Yes, we have holes, but I see two majors differences here: - the other gates > are just gates, while the usb clocks are a bit more than that. The usb-clk registers contain more then that, but the bits we are talking about now are gates. > - the other gates' gating bits thus all start at bit 0, while here, since > it's kind of a "mixed" clock, the gating bits start at bit 6 (on the A20 at > least) Right, still I believe that the consistent thing to do is keeping the bit-number for the bit in the register controlling the gate as the specifier. When adding new dts entries / reviewing existing ones I'm used to matching the specifier to the bit-nr in the data-sheet, I think making things different just for this one register is counter productive. Regards, Hans -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLnf80ACgkQF3VEtJrzE/udugCdEDpN65hazG7H+FD45iOVnTY9 548An3dXeF6f8wp5REck5H3gqQPQkIoX =6yba -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
On Fri, Jan 17, 2014 at 09:54:55AM +0100, Carlo Caione wrote:
> >> +/*
> >> + * Ack level interrupts right before unmask
> >> + *
> >> + * In case of level-triggered interrupt, IRQ line must be acked before it
> >> + * is unmasked or else a double-interrupt is triggered
> >> + */
> >> +
> >> +static void sunxi_sc_nmi_ack_and_unmask(struct irq_data *d)
> >> +{
> >> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> >> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
> >> + u32 mask = d->mask;
> >> +
> >> + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK)
> >> + ct->chip.irq_ack(d);
> >> +
> >> + irq_gc_lock(gc);
> >> + irq_reg_writel(mask, gc->reg_base + ct->regs.mask);
> >> + irq_gc_unlock(gc);
> >> +}
> >
> > Hmmm, handle_level_irq seems to be doing exactly that already. It
> > first masks and acks the interrupts, and then unmask it, so we should
> > be fine, don't we?
>
> We don't, or at least handle_level_irq doesn't work for all the cases.
This is what I find weird :)
> Let's say (i.e. this is the cubieboard2 case) that to the irqchip is
> connected to the IRQ line of a PMIC accessed by I2C. In this case we
> cannot mask/ack the interrupt on the originating device in the hard
> interrupt handler (in which handle_level_irq is) since we need to
> access the I2C bus in an non-interrupt context.
We agree here.
> ACKing the IRQ in handle_level_irq at this point is pretty much
> useless since we still have to ACK the IRQs on the originating
> device and this will be done in a IRQ thread started after the hard
> IRQ handler.
Ok, so what you're saying is that you want to adress this case:
handle_level_irq
| devicedevice
| mask ack handler irq acked unmask
| ||| | |
v vvv v v
NMI -> GIC:
++ +-
---++-+
PMIC -> NMI:
+-+ +-+
+ +---+ +
Right?
But in this case, you would have two events coming from your device
(the two rising edges), so you'd expect two interrupts. And in the
case of a level triggered interrupt, the device would keep the
interrupt line active until it's unmasked, so we wouldn't end up with
this either.
> sunxi_sc_nmi_ack_and_unmask is therefore called (by
> irq_finalize_oneshot) after the IRQ thread has been executed. After
> the IRQ thread has ACKed the IRQs on the originating device we can
> finally ACK and unmask again the NMI.
And what happens if you get a new interrupt right between the end of
the handler and the unmask?
>
> >> +static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32
> >> off,
> >> + u32 val)
> >> +{
> >> + irq_reg_writel(val, gc->reg_base + off);
> >> +}
> >> +
> >> +static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
> >> +{
> >> + return irq_reg_readl(gc->reg_base + off);
> >> +}
> >> +
> >> +static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc
> >> *desc)
> >> +{
> >> + struct irq_domain *domain = irq_desc_get_handler_data(desc);
> >> + struct irq_chip *chip = irq_get_chip(irq);
> >> + unsigned int virq = irq_find_mapping(domain, 0);
> >> +
> >> + chained_irq_enter(chip, desc);
> >> + generic_handle_irq(virq);
> >> + chained_irq_exit(chip, desc);
> >> +}
> >> +
> >> +static int sunxi_sc_nmi_set_type(struct irq_data *data, unsigned int
> >> flow_type)
> >> +{
> >> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
> >> + struct irq_chip_type *ct = gc->chip_types;
> >> + u32 src_type_reg;
> >> + u32 ctrl_off = ct->regs.type;
> >> + unsigned int src_type;
> >> + unsigned int i;
> >> +
> >> + irq_gc_lock(gc);
> >> +
> >> + switch (flow_type & IRQF_TRIGGER_MASK) {
> >> + case IRQ_TYPE_EDGE_FALLING:
> >> + src_type = SUNXI_SRC_TYPE_EDGE_FALLING;
> >> + break;
> >> + case IRQ_TYPE_EDGE_RISING:
> >> + src_type = SUNXI_SRC_TYPE_EDGE_RISING;
> >> + break;
> >> + case IRQ_TYPE_LEVEL_HIGH:
> >> + src_type = SUNXI_SRC_TYPE_LEVEL_HIGH;
> >> + break;
> >> + case IRQ_TYPE_NONE:
> >> + case IRQ_TYPE_LEVEL_LOW:
> >> + src_type = SUNXI_SRC_TYPE_LEVEL_LOW;
> >> + break;
> >> + default:
> >> + irq_gc_unlock(gc);
> >> + pr_err("%s: Cannot assign multiple trigger modes to IRQ
> >> %d.\n",
> >> + __func__, data->irq);
> >> + return -EBADR;
> >> + }
> >> +
> >> + irqd_set_trigger_type(data, flow_type);
> >> + irq_setup_alt_chip(data, flow_type);
> >> +
> >> + for (i = 0; i <= gc->num_ct; i++, ct++)
> >> + if (ct->type & flow_type)
> >> + ctrl_off = ct->regs.type;
> >> +
> >> +
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On 01/28/2014 11:11 AM, Arend van Spriel wrote: > On 01/27/2014 11:12 AM, Tomasz Figa wrote: >>> The brcmfmac driver that consumes these DT nodes will have a closer look >>> at the device obtaining the chipid during the probe and determine if it >>> can support it. So the compatible string indicates that the device needs >>> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac >>> wireless driver. >> >> The compatible string should guarantee that the chip ID register holds a >> valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to > > I am not sure I understand this requirement. Is the DT node claimed > somehow after of_find_matching_node() and unavailable to other drivers. > >> me. The string must specify the family of chips with this chip ID scheme >> in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a >> risk of, say, BCM43999 showing up, which would be a completely different >> chip. while having the model matching the pattern. > > If a completely different chip, ie. BCM43999, shows up in a board the > device tree should not use "brcm,bcm43xx-fmac". That would be an error > in the dts file, right? All the devices listed in your bindings patch > are treated the same, ie. *compatible* on DT level and hence can have > the same compatible property. > > In my opinion that is what the compatible property is about. It > identifies how a specific category of devices is accessed/configured. As > an example please see [1]. It shows one compatible string for a binding > that is used for different MPIC controllers. > > Just to be clear, I like your suggestion to use "brcm,bcm43xx-fmac", but > felt you did not so added my explanation/point of view. The usual way to solve this is to have the dts file have a list of compatibility strings going from specific to more generic, so for ie the wifi on the cubietruck the dts file would contain: compatible = "brcm,bcm43362", "brcm,bcm43xx-fmac"; And then the brcmfmac driver will contain .compatible = "brcm,bcm43xx-fmac" If we then ever need to have some specific quirks in the driver the driver can use of_device_is_compatible(dev->of_node, "brcm,bcm43362") to check for the 43362. Their could even be a completely separate driver for the "brcm,bcm43362", with brcmfmac still claiming "brcm,bcm43xx-fmac", as matching is done from left to right, so if there is a specific driver and a more generic one the specific driver will win (assuming both are built-in / loaded at probe time). TL;DR: dts file should have: compatible = "brcm,bcm43362", "brcm,bcm43xx-fmac"; brcmfmac should have: .compatible = "brcm,bcm43xx-fmac", So that we can add device specific quirks later (if necessary). Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 01/27/2014 11:12 AM, Tomasz Figa wrote: >> The brcmfmac driver that consumes these DT nodes will have a closer look >> at the device obtaining the chipid during the probe and determine if it >> can support it. So the compatible string indicates that the device needs >> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac >> wireless driver. > > The compatible string should guarantee that the chip ID register holds a > valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to I am not sure I understand this requirement. Is the DT node claimed somehow after of_find_matching_node() and unavailable to other drivers. > me. The string must specify the family of chips with this chip ID scheme > in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a > risk of, say, BCM43999 showing up, which would be a completely different > chip. while having the model matching the pattern. If a completely different chip, ie. BCM43999, shows up in a board the device tree should not use "brcm,bcm43xx-fmac". That would be an error in the dts file, right? All the devices listed in your bindings patch are treated the same, ie. *compatible* on DT level and hence can have the same compatible property. In my opinion that is what the compatible property is about. It identifies how a specific category of devices is accessed/configured. As an example please see [1]. It shows one compatible string for a binding that is used for different MPIC controllers. Just to be clear, I like your suggestion to use "brcm,bcm43xx-fmac", but felt you did not so added my explanation/point of view. Regards, Arend [1] Documentation/devicetree/bindings/powerpc/fsl/mpic.txt -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote: > >> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13 > > > > Maybe we can just remove the gates from there? Even though they > > are gates, they are also (a bit) more than that. > > To be clear you mean s/usb-gates-clk/usb-clk/ right ? Yep, exactly > > I guess that means that we will have the OHCI0 gate declared with > > <&...-gates-clk 6>, while it's actually the first gate for this > > clock? > > Correct. > > > Maybe introducing an offset field in the gates_data would be a > > good idea, so that we always start from indexing the gates from 0 > > in the DT? > > Well for the other "gates" type clks we also have holes in the > range, and we always refer to the clk with the bit number in the reg > as the clock-cell value. Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that. - the other gates' gating bits thus all start at bit 0, while here, since it's kind of a "mixed" clock, the gating bits start at bit 6 (on the A20 at least) -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
