Re: [linux-sunxi] Re: [PATCH 5/5] ARM: dts: sun7i: Add dts file for Wits Pro A20 DKT

2015-08-02 Thread Hans de Goede

Hi,

On 01-08-15 11:30, Maxime Ripard wrote:

On Fri, Jul 31, 2015 at 06:13:06PM +0200, Hans de Goede wrote:

mmc-pwrseq-simple supports multiple reset/enable gpios (by listing
them all as reset-gpios and setting GPIO_ACTIVE_LOW/HIGH depending
on which value they need to be to activate things).

It also supports listing clocks which need to be enabled. I think
that it may be a good idea to use this to also enable the bluetooth
bits of the ap6210 module on the cubietruck. I know that the
actual bt is interfaced over an uart, and we really should have
a mechanism to enable/disable it separately, but for not this seems
like a good way to get bluetooth to work.

We should ofcourse add a comment to the dts file that this is not a
100% ideal solution, but other then that I think this should work
nicely. Maxime would enabling the bluetooth bits of this sdio
module via mmc-pwrseq be acceptable to you?


As long as we have some comment on top, yep.


Great, thanks.


ChenYu if Maxime acks this solution I hope you can write a patch for
this, since you've been working on the bluetooth support before.


Note that I'm in holidays starting today. I plan on doing my
pull-requests for 4.3 later today, and will probably not be able to
merge any patches during the next two weeks, which mean that your
mmc-power seq patch for the cubietruck was probably the last one I was
merging for the 4.3 merge window.


OK, that is good to know, thanks for the headsup and enjoy your hollidays.

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/d/optout.


Re: [linux-sunxi] Re: [PATCH 5/5] ARM: dts: sun7i: Add dts file for Wits Pro A20 DKT

2015-08-02 Thread Hans de Goede

Hi,

On 01-08-15 11:30, Maxime Ripard wrote:

On Fri, Jul 31, 2015 at 06:13:06PM +0200, Hans de Goede wrote:

mmc-pwrseq-simple supports multiple reset/enable gpios (by listing
them all as reset-gpios and setting GPIO_ACTIVE_LOW/HIGH depending
on which value they need to be to activate things).

It also supports listing clocks which need to be enabled. I think
that it may be a good idea to use this to also enable the bluetooth
bits of the ap6210 module on the cubietruck. I know that the
actual bt is interfaced over an uart, and we really should have
a mechanism to enable/disable it separately, but for not this seems
like a good way to get bluetooth to work.

We should ofcourse add a comment to the dts file that this is not a
100% ideal solution, but other then that I think this should work
nicely. Maxime would enabling the bluetooth bits of this sdio
module via mmc-pwrseq be acceptable to you?


As long as we have some comment on top, yep.


ChenYu if Maxime acks this solution I hope you can write a patch for
this, since you've been working on the bluetooth support before.


Note that I'm in holidays starting today. I plan on doing my
pull-requests for 4.3 later today, and will probably not be able to
merge any patches during the next two weeks, which mean that your
mmc-power seq patch for the cubietruck was probably the last one I was
merging for the 4.3 merge window.


I just noticed that your last push to

https://git.kernel.org/cgit/linux/kernel/git/mripard/linux.git/log/?h=sunxi/for-next

Is not in your github sunxi-next branch, it would be good if you could
merge the last changes there (when your back from your holliday).

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/d/optout.


[linux-sunxi] [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

2015-08-02 Thread Timo Sigurdsson
sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209 PMU
driver, so add them to allow for voltage-scaling with cpufreq-dt.

Signed-off-by: Timo Sigurdsson 
---
Changes since v1 (RFC):

- Dropped the changes to the cpufreq operating points and renamed the patch
accordingly
- Limited the CPU voltage range so it doesn't exceed the SOC specifications
---
 arch/arm/boot/dts/sun7i-a20-bananapi.dts | 35 
 1 file changed, 31 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts 
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..74382f3 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -92,6 +92,10 @@
status = "okay";
 };
 
+&cpu0 {
+   cpu-supply = <®_dcdc2>;
+};
+
 &ehci0 {
status = "okay";
 };
@@ -119,13 +123,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <&nmi_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
};
 };
 
@@ -182,6 +182,33 @@
};
 };
 
+#include "axp209.dtsi"
+
+®_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+®_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+®_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+®_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 ®_usb1_vbus {
status = "okay";
 };
-- 
2.1.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/d/optout.


[linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

2015-08-02 Thread Timo Sigurdsson
sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 boards
(or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
voltage for the lowest operating point to 1.0V so all boards can actually use
it.

Signed-off-by: Timo Sigurdsson 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6a63f30..f5f384c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -107,7 +107,7 @@
72  120
528000  110
312000  100
-   144000  90
+   144000  100
>;
#cooling-cells = <2>;
cooling-min-level = <0>;
-- 
2.1.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/d/optout.


[linux-sunxi] Re: [PATCH v3 resend 1/2] mfd: axp20x: Add missing registers, and mark more registers volatile

2015-08-02 Thread Bruno Prémont
On Sat,  1 Aug 2015 09:25:17 Hans de Goede  wrote:
> From: Bruno Prémont 
> 
> Add an extra set of registers which is necessary tu support the PMICs
> battery charger function, and mark registers which contain status bits,
> gpio status, and adc readings as volatile.
> 
> Cc: Bruno Prémont 
> Signed-off-by: Bruno Prémont 
> Signed-off-by: Hans de Goede 
> Acked-by: Lee Jones 
> Acked-by: Maxime Ripard 
> ---
> Changes in v2:
> -Add a AXP20X_OCV_MAX define
> Changes in v3:
> -Add Bruno's S-o-b
> ---
>  drivers/mfd/axp20x.c   | 8 +++-
>  include/linux/mfd/axp20x.h | 6 ++
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index b369cfc..8bd3283 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -61,10 +61,16 @@ static const struct regmap_access_table 
> axp152_volatile_table = {
>  static const struct regmap_range axp20x_writeable_ranges[] = {
>   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
>   regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
> + regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(15)),

As AXP20X_OCV_MAX has been added, this should be:
+   regmap_reg_range(AXP20X_RDC_H, AXP20X_OCV(AXP20X_OCV_MAX)),

>  };
>  
>  static const struct regmap_range axp20x_volatile_ranges[] = {
> + regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
> + regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
>   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
> + regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
> + regmap_reg_range(AXP20X_GPIO20_SS, AXP20X_GPIO3_CTRL),
> + regmap_reg_range(AXP20X_FG_RES, AXP20X_RDC_L),
>  };
>  
>  static const struct regmap_access_table axp20x_writeable_table = {
> @@ -195,7 +201,7 @@ static const struct regmap_config axp20x_regmap_config = {
>   .val_bits   = 8,
>   .wr_table   = &axp20x_writeable_table,
>   .volatile_table = &axp20x_volatile_table,
> - .max_register   = AXP20X_FG_RES,
> + .max_register   = AXP20X_OCV(AXP20X_OCV_MAX),
>   .cache_type = REGCACHE_RBTREE,
>  };
>  
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index 52203d5..cc8ad1e 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -190,6 +190,12 @@ enum {
>  #define AXP20X_CC_CTRL   0xb8
>  #define AXP20X_FG_RES0xb9
>  
> +/* OCV */
> +#define AXP20X_RDC_H 0xba
> +#define AXP20X_RDC_L 0xbb
> +#define AXP20X_OCV(m)(0xc0 + (m))
> +#define AXP20X_OCV_MAX   0xf
> +
>  /* AXP22X specific registers */
>  #define AXP22X_BATLOW_THRES1 0xe6
>  

-- 
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/d/optout.


Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

2015-08-02 Thread Timo Sigurdsson
Hi Stefan,

you didn't include me in your answer, hence the late reply...

Stefan Monnier schrieb am 29.07.2015 02:02:
>> IMHO for a common maximum opp that's a good approach. But for the lowest
>> frequency setting, it would seem more logical to me, to raise the voltage
>> to a point where all boards will run fine with them, unless those boards
>> cannot handle the frequency regardless of the higher voltage.

> I generally agre, tho IIRC some measurements seem to indicate that the
> lowest frequency settings did not bring much (if any) reduction in power
> consumption, making them rather useless.

That's an interesting point. However, that would be a different discussion. I
wouldn't mind if the 144MHz would be removed - my point was just that if it's 
supposed to be a common setting, it should work on all boards. I posted a patch
today to fix this. [1] That might be a good place to discuss whether this
setting should be removed entirely.

Regards,

Timo

[1] https://groups.google.com/forum/#!topic/linux-sunxi/fIfbdn7mrQA

-- 
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/d/optout.


Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

2015-08-02 Thread Julian Calaby
Hi Timo,

On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
 wrote:
> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 
> boards
> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise the
> voltage for the lowest operating point to 1.0V so all boards can actually use
> it.

Surely it wouldn't be added here if some could supply 0.9v.

Is the code that uses this smart enough to sensibly switch between two
operating points with the same frequency and different voltages? If
so, maybe just add a 144MHz @ 1.0v operating point?

(Alternatively, would it make sense to modify the code that uses this
to use frequencies with voltages specified that are lower than can be
supplied with the lowest voltage it can?)

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
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/d/optout.


Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

2015-08-02 Thread Chen-Yu Tsai
Hi,

On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby  wrote:
> Hi Timo,
>
> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>  wrote:
>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 
>> boards
>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise 
>> the
>> voltage for the lowest operating point to 1.0V so all boards can actually use
>> it.
>
> Surely it wouldn't be added here if some could supply 0.9v.

On the side, the original OPPs in the FEX files are actually
frequency/voltage ranges, and not just points. Mainlines OPPv2
will support these, along with turbo frequencies.

Furthermore, the FEX files also have fields that limit the
minimum and maximum frequencies.

> Is the code that uses this smart enough to sensibly switch between two
> operating points with the same frequency and different voltages? If
> so, maybe just add a 144MHz @ 1.0v operating point?

You could try. Though I really don't see much to gain here.

> (Alternatively, would it make sense to modify the code that uses this
> to use frequencies with voltages specified that are lower than can be
> supplied with the lowest voltage it can?)

I think that's a bit harder to get accepted.


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/d/optout.


Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

2015-08-02 Thread Julian Calaby
Hi Chen-Yu,

On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai  wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby  wrote:
>> Hi Timo,
>>
>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>>  wrote:
>>> sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 
>>> boards
>>> (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise 
>>> the
>>> voltage for the lowest operating point to 1.0V so all boards can actually 
>>> use
>>> it.
>>
>> Surely it wouldn't be added here if some could supply 0.9v.
>
> On the side, the original OPPs in the FEX files are actually
> frequency/voltage ranges, and not just points. Mainlines OPPv2
> will support these, along with turbo frequencies.

Ah, that makes sense.

> Furthermore, the FEX files also have fields that limit the
> minimum and maximum frequencies.

Is this going to be supported by OPPv2 too?

>> Is the code that uses this smart enough to sensibly switch between two
>> operating points with the same frequency and different voltages? If
>> so, maybe just add a 144MHz @ 1.0v operating point?
>
> You could try. Though I really don't see much to gain here.

>From what I recall, lower frequency = less power usage, though my
experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing
a lot of details. This is the sort of thing that requires thorough
testing on a dev board.

>> (Alternatively, would it make sense to modify the code that uses this
>> to use frequencies with voltages specified that are lower than can be
>> supplied with the lowest voltage it can?)
>
> I think that's a bit harder to get accepted.

Oh, definitely. It kinda makes sense, but at the same time it'll
require some seriously thorough testing on a lot of different boards.

My only real objection here is are there boards that can go down to
0.9v and if so, won't this change make them less power efficient in
the almost-idle case? And are those power savings enough to justify
not accepting this patch?

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

-- 
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/d/optout.


Re: [linux-sunxi] [PATCH] ARM: dts: sunxi: Raise minimum CPU voltage for sun7i-a20 to a level all boards can supply

2015-08-02 Thread Chen-Yu Tsai
On Mon, Aug 3, 2015 at 12:22 PM, Julian Calaby  wrote:
> Hi Chen-Yu,
>
> On Mon, Aug 3, 2015 at 12:37 PM, Chen-Yu Tsai  wrote:
>> Hi,
>>
>> On Mon, Aug 3, 2015 at 7:35 AM, Julian Calaby  
>> wrote:
>>> Hi Timo,
>>>
>>> On Mon, Aug 3, 2015 at 5:23 AM, Timo Sigurdsson
>>>  wrote:
 sun7i-a20.dtsi contains an cpufreq operating point at 0.9 volts. Most A20 
 boards
 (or all?), however, do not allow the voltage to go below 1.0V. Thus, raise 
 the
 voltage for the lowest operating point to 1.0V so all boards can actually 
 use
 it.
>>>
>>> Surely it wouldn't be added here if some could supply 0.9v.
>>
>> On the side, the original OPPs in the FEX files are actually
>> frequency/voltage ranges, and not just points. Mainlines OPPv2
>> will support these, along with turbo frequencies.
>
> Ah, that makes sense.
>
>> Furthermore, the FEX files also have fields that limit the
>> minimum and maximum frequencies.
>
> Is this going to be supported by OPPv2 too?

IIRC yes, OPPv2 moves to a range profile. OPPv2 is not merged yet.

>>> Is the code that uses this smart enough to sensibly switch between two
>>> operating points with the same frequency and different voltages? If
>>> so, maybe just add a 144MHz @ 1.0v operating point?
>>
>> You could try. Though I really don't see much to gain here.
>
> From what I recall, lower frequency = less power usage, though my
> experience is from x86 laptops, not ARM SoCs and I'm sure I'm missing
> a lot of details. This is the sort of thing that requires thorough
> testing on a dev board.

I agree, though my limited experiences tell me that the major savings
come from lowering the core voltage.

>>> (Alternatively, would it make sense to modify the code that uses this
>>> to use frequencies with voltages specified that are lower than can be
>>> supplied with the lowest voltage it can?)
>>
>> I think that's a bit harder to get accepted.
>
> Oh, definitely. It kinda makes sense, but at the same time it'll
> require some seriously thorough testing on a lot of different boards.
>
> My only real objection here is are there boards that can go down to
> 0.9v and if so, won't this change make them less power efficient in
> the almost-idle case? And are those power savings enough to justify
> not accepting this patch?

This will require most testing as well. (sigh) Alas, my boards aren't
stable enough at 0.9V, so I can't say much about it.


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/d/optout.


Re: [linux-sunxi] no shutdown pushing the power button

2015-08-02 Thread Chen-Yu Tsai
Hi,

On Sun, Aug 2, 2015 at 7:44 AM, Leonardo Canducci
 wrote:
> My Cubieboard runs Debian Jessie (linux 4.1 from experimental) on a SD card.
> I'd like to shutdown pushing the power button as I do on my NAND install
> (wheezy image and linux sunxi 3.4).
>
> On Jessie acpi_listen (and journalctl|syslog|dmesg) doesn't register any
> event when pushing the button while on Wheezy I get:
>
> leo@cubetto:~$ sudo acpi_listen
> button/power PBTN 0080 
> Broadcast message from root@cubetto (Sat Aug  1 18:57:04 2015):
> Power button pressed
> The system is going down for system halt NOW!
>
> Should I load a kernel module to get the button working?

First of all, you will need to enable INPUT_AXP20X_PEK, and
make sure axp20x-pek is compiled in or loaded.

You might also need to enable INPUT_EVDEV.


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/d/optout.


Re: [linux-sunxi] no shutdown pushing the power button

2015-08-02 Thread Leonardo Canducci
2015-08-03 6:41 GMT+02:00 Chen-Yu Tsai :
>
> Hi,
>
> On Sun, Aug 2, 2015 at 7:44 AM, Leonardo Canducci
>  wrote:
> > My Cubieboard runs Debian Jessie (linux 4.1 from experimental) on a SD
card.
> > I'd like to shutdown pushing the power button as I do on my NAND install
> > (wheezy image and linux sunxi 3.4).
> >
> > On Jessie acpi_listen (and journalctl|syslog|dmesg) doesn't register any
> > event when pushing the button while on Wheezy I get:
> >
> > leo@cubetto:~$ sudo acpi_listen
> > button/power PBTN 0080 
> > Broadcast message from root@cubetto (Sat Aug  1 18:57:04 2015):
> > Power button pressed
> > The system is going down for system halt NOW!
> >
> > Should I load a kernel module to get the button working?
>
> First of all, you will need to enable INPUT_AXP20X_PEK, and
> make sure axp20x-pek is compiled in or loaded.
>
> You might also need to enable INPUT_EVDEV.


On linux 4.1 and 4.0 (experimental and unstable branches) INPUT_AXP20X_PEK
is not enabled while INPUT_EVDEV is available as a module.

# CONFIG_INPUT_AXP20X_PEK is not set
CONFIG_INPUT_EVDEV=m

I guess I should recompile the kernel to get the button working.

Thanks!

--
Leonardo Canducci

-- 
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/d/optout.