* Re: [RFC PATCH] Audio standards on tm6000
From: Dmitri Belimov @ 2010-10-08 19:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Felipe Sanches, Stefan Ringel, Bee Hock Goh,
Luis Henrique Fagundes, Linux Media Mailing List
In-Reply-To: <4CAD5A78.3070803@redhat.com>
Hi Mauro
Not so good. Audio with this patch has bad white noise sometimes and
bad quality. I try found better configuration for SECAM-DK.
With my best regards, Dmitry.
> Hi Dmitri,
>
> IMO, the better is to remove the audio init from tm6000-core and add
> a separate per-standard set of tables.
>
> I'm enclosing the patch for it. Please check if this won't break for
> your device.
>
> On all tests I did here with a tm6010 device (HVR 900H), I was only
> able to listen to white noise.
>
> I'm suspecting that this device uses XC3028 MTS mode (e. g. uses
> xc3028 to decode audio, and just inputs the audio stream from some
> line IN. As the driver is not able yet to handle an audio mux, this
> may explain why I'm not able to receive any audio at all.
>
> Maybe tm5600 devices may also require (or use) line input entries,
> instead of I2S.
>
> Could you please check those issues?
>
> PS.: the PAL/M hunk will probably fail, as I likely applied some
> patches before this one, in order to try to fix it. It should be
> trivial to solve the conflicts.
>
> ---
>
> tm6000: Implement audio standard tables
>
> Implement separate tables for audio standards, associating them with
> the video standards.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
>
> diff --git a/drivers/staging/tm6000/tm6000-core.c
> b/drivers/staging/tm6000/tm6000-core.c index 57cb69e..9cb2901 100644
> --- a/drivers/staging/tm6000/tm6000-core.c
> +++ b/drivers/staging/tm6000/tm6000-core.c
> @@ -200,6 +200,10 @@ int tm6000_init_analog_mode(struct tm6000_core
> *dev) val &= ~0x40;
> tm6000_set_reg(dev,
> TM6010_REQ07_RC0_ACTIVE_VIDEO_SOURCE, val);
> + tm6000_set_reg(dev,
> TM6010_REQ08_RF1_AADC_POWER_DOWN, 0xfc); +
> +#if 0 /* FIXME: VBI is standard-dependent */
> +
> /* Init teletext */
> tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
> tm6000_set_reg(dev,
> TM6010_REQ07_R41_TELETEXT_VBI_CODE1, 0x27); @@ -249,44 +253,7 @@ int
> tm6000_init_analog_mode(struct tm6000_core *dev) tm6000_set_reg(dev,
> TM6010_REQ07_R5B_VBI_TELETEXT_DTO0, 0x4c); tm6000_set_reg(dev,
> TM6010_REQ07_R40_TELETEXT_VBI_CODE0, 0x01); tm6000_set_reg(dev,
> TM6010_REQ07_R3F_RESET, 0x00); -
> -
> - /* Init audio */
> - tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_R04_A_SIF_AMP_CTRL,
> 0xa0);
> - tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> - tm6000_set_reg(dev, TM6010_REQ08_R07_A_LEFT_VOL,
> 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_R08_A_RIGHT_VOL,
> 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> - tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> - tm6000_set_reg(dev, TM6010_REQ08_R0B_A_ASD_THRES1,
> 0x20);
> - tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2,
> 0x12);
> - tm6000_set_reg(dev, TM6010_REQ08_R0D_A_AMD_THRES,
> 0x20);
> - tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1,
> 0xf0);
> - tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2,
> 0x80);
> - tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1,
> 0xc0);
> - tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2,
> 0x80);
> - tm6000_set_reg(dev, TM6010_REQ08_R12_A_AGC_U, 0x12);
> - tm6000_set_reg(dev, TM6010_REQ08_R13_A_AGC_ERR_T,
> 0xfe);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R14_A_AGC_GAIN_INIT, 0x20);
> - tm6000_set_reg(dev, TM6010_REQ08_R15_A_AGC_STEP_THR,
> 0x14);
> - tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> - tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> - tm6000_set_reg(dev, TM6010_REQ08_R18_A_TR_CTRL,
> 0xa0);
> - tm6000_set_reg(dev, TM6010_REQ08_R19_A_FH_2FH_GAIN,
> 0x32);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R1A_A_NICAM_SER_MAX, 0x64);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R1B_A_NICAM_SER_MIN, 0x20);
> - tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1c,
> 0x00);
> - tm6000_set_reg(dev, REQ_08_SET_GET_AVREG_BIT, 0x1d,
> 0x00);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R1E_A_GAIN_DEEMPH_OUT, 0x13);
> - tm6000_set_reg(dev,
> TM6010_REQ08_R1F_A_TEST_INTF_SEL, 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_R20_A_TEST_PIN_SEL,
> 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_RE4_ADC_IN2_SEL,
> 0xf3);
> - tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x00);
> - tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> -
> +#endif
> } else {
> /* Enables soft reset */
> tm6000_set_reg(dev, TM6010_REQ07_R3F_RESET, 0x01);
> @@ -360,7 +327,6 @@ int tm6000_init_digital_mode(struct tm6000_core
> *dev) tm6000_set_reg(dev, TM6010_REQ07_RFE_POWER_DOWN, 0x28);
> tm6000_set_reg(dev,
> TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xfc); tm6000_set_reg(dev,
> TM6010_REQ08_RE6_POWER_DOWN_CTRL2, 0xff);
> - tm6000_set_reg(dev,
> TM6010_REQ08_RF1_AADC_POWER_DOWN, 0xfe); tm6000_read_write_usb(dev,
> 0xc0, 0x0e, 0x00c2, 0x0008, buf, 2); printk(KERN_INFO"buf %#x %#x\n",
> buf[0], buf[1]); } else {
> diff --git a/drivers/staging/tm6000/tm6000-stds.c
> b/drivers/staging/tm6000/tm6000-stds.c index 33adf6c..e79a72e 100644
> --- a/drivers/staging/tm6000/tm6000-stds.c
> +++ b/drivers/staging/tm6000/tm6000-stds.c
> @@ -28,8 +28,22 @@ struct tm6000_reg_settings {
> unsigned char value;
> };
>
> +enum tm6000_audio_std {
> + BG_NICAM,
> + BTSC,
> + BG_A2,
> + DK_NICAM,
> + EIAJ,
> + FM_RADIO,
> + I_NICAM,
> + KOREA_A2,
> + L_NICAM,
> +};
> +
> struct tm6000_std_tv_settings {
> v4l2_std_id id;
> + enum tm6000_audio_std audio_default_std;
> +
> struct tm6000_reg_settings sif[12];
> struct tm6000_reg_settings nosif[12];
> struct tm6000_reg_settings common[26];
> @@ -37,12 +51,14 @@ struct tm6000_std_tv_settings {
>
> struct tm6000_std_settings {
> v4l2_std_id id;
> + enum tm6000_audio_std audio_default_std;
> struct tm6000_reg_settings common[37];
> };
>
> static struct tm6000_std_tv_settings tv_stds[] = {
> {
> .id = V4L2_STD_PAL_M,
> + .audio_default_std = BTSC,
> .sif = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf2},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf8},
> @@ -96,12 +112,14 @@ static struct tm6000_std_tv_settings tv_stds[] =
> {
> {TM6010_REQ07_R04_LUMA_HAGC_CONTROL, 0xdc},
> {TM6010_REQ07_R0D_CHROMA_KILL_LEVEL, 0x07},
> - {TM6010_REQ08_R05_A_STANDARD_MOD, 0x22},
> +
> {TM6010_REQ07_R3F_RESET, 0x00},
> +
> {0, 0, 0},
> },
> }, {
> .id = V4L2_STD_PAL_Nc,
> + .audio_default_std = BTSC,
> .sif = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf2},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf8},
> @@ -161,6 +179,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
> },
> }, {
> .id = V4L2_STD_PAL,
> + .audio_default_std = BG_A2,
> .sif = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf2},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf8},
> @@ -220,6 +239,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
> },
> }, {
> .id = V4L2_STD_SECAM,
> + .audio_default_std = BG_NICAM,
> .sif = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf2},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf8},
> @@ -278,6 +298,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
> },
> }, {
> .id = V4L2_STD_NTSC,
> + .audio_default_std = BTSC,
> .sif = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf2},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf8},
> @@ -341,6 +362,7 @@ static struct tm6000_std_tv_settings tv_stds[] = {
> static struct tm6000_std_settings composite_stds[] = {
> {
> .id = V4L2_STD_PAL_M,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4},
> @@ -383,6 +405,7 @@ static struct tm6000_std_settings
> composite_stds[] = { },
> }, {
> .id = V4L2_STD_PAL_Nc,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4},
> @@ -425,6 +448,7 @@ static struct tm6000_std_settings
> composite_stds[] = { },
> }, {
> .id = V4L2_STD_PAL,
> + .audio_default_std = BG_A2,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4},
> @@ -467,6 +491,7 @@ static struct tm6000_std_settings
> composite_stds[] = { },
> }, {
> .id = V4L2_STD_SECAM,
> + .audio_default_std = BG_NICAM,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4},
> @@ -508,6 +533,7 @@ static struct tm6000_std_settings
> composite_stds[] = { },
> }, {
> .id = V4L2_STD_NTSC,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xf4},
> @@ -554,6 +580,7 @@ static struct tm6000_std_settings
> composite_stds[] = { static struct tm6000_std_settings svideo_stds[]
> = { {
> .id = V4L2_STD_PAL_M,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xfc},
> @@ -596,6 +623,7 @@ static struct tm6000_std_settings svideo_stds[] =
> { },
> }, {
> .id = V4L2_STD_PAL_Nc,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xfc},
> @@ -638,6 +666,7 @@ static struct tm6000_std_settings svideo_stds[] =
> { },
> }, {
> .id = V4L2_STD_PAL,
> + .audio_default_std = BG_A2,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xfc},
> @@ -680,6 +709,7 @@ static struct tm6000_std_settings svideo_stds[] =
> { },
> }, {
> .id = V4L2_STD_SECAM,
> + .audio_default_std = BG_NICAM,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xfc},
> @@ -721,6 +751,7 @@ static struct tm6000_std_settings svideo_stds[] =
> { },
> }, {
> .id = V4L2_STD_NTSC,
> + .audio_default_std = BTSC,
> .common = {
> {TM6010_REQ08_RE2_POWER_DOWN_CTRL1, 0xf0},
> {TM6010_REQ08_RE3_ADC_IN1_SEL, 0xfc},
> @@ -765,6 +796,136 @@ static struct tm6000_std_settings svideo_stds[]
> = { },
> };
>
> +
> +static int tm6000_set_audio_std(struct tm6000_core *dev,
> + enum tm6000_audio_std std)
> +{
> + switch (std) {
> + case BG_NICAM:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x11);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case BTSC:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x02);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1,
> 0xf0);
> + tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2,
> 0x80);
> + tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1,
> 0xc0);
> + tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2,
> 0x80);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case BG_A2:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x05);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1,
> 0xf0);
> + tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2,
> 0x80);
> + tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1,
> 0xc0);
> + tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2,
> 0x80);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case DK_NICAM:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2,
> 0x0a);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case EIAJ:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x03);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case FM_RADIO:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x01);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x0c);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x10);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case I_NICAM:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R0C_A_ASD_THRES2,
> 0x0a);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case KOREA_A2:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x04);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x04);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R0E_A_MONO_THRES1,
> 0xf0);
> + tm6000_set_reg(dev, TM6010_REQ08_R0F_A_MONO_THRES2,
> 0x80);
> + tm6000_set_reg(dev, TM6010_REQ08_R10_A_MUTE_THRES1,
> 0xc0);
> + tm6000_set_reg(dev, TM6010_REQ08_R11_A_MUTE_THRES2,
> 0xf0);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + case L_NICAM:
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x00);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R02_A_FIX_GAIN_CTRL, 0x02);
> + tm6000_set_reg(dev,
> TM6010_REQ08_R03_A_AUTO_GAIN_CTRL, 0x00);
> + tm6000_set_reg(dev, TM6010_REQ08_R05_A_STANDARD_MOD,
> 0x0a);
> + tm6000_set_reg(dev, TM6010_REQ08_R06_A_SOUND_MOD,
> 0x06);
> + tm6000_set_reg(dev, TM6010_REQ08_R09_A_MAIN_VOL,
> 0x08);
> + tm6000_set_reg(dev, TM6010_REQ08_R0A_A_I2S_MOD,
> 0x91);
> + tm6000_set_reg(dev, TM6010_REQ08_R16_A_AGC_GAIN_MAX,
> 0xfe);
> + tm6000_set_reg(dev, TM6010_REQ08_R17_A_AGC_GAIN_MIN,
> 0x01);
> + tm6000_set_reg(dev, TM6010_REQ08_R01_A_INIT, 0x80);
> + break;
> + }
> + return 0;
> +}
> +
> void tm6000_get_std_res(struct tm6000_core *dev)
> {
> /* Currently, those are the only supported resoltions */
> @@ -825,6 +986,8 @@ static int tm6000_set_tv(struct tm6000_core *dev,
> int pos) rc = tm6000_load_std(dev, tv_stds[pos].common,
> sizeof(tv_stds[pos].common));
>
> + tm6000_set_audio_std(dev, tv_stds[pos].audio_default_std);
> +
> return rc;
> }
>
> @@ -850,6 +1013,8 @@ int tm6000_set_standard(struct tm6000_core *dev,
> v4l2_std_id * norm) rc = tm6000_load_std(dev, svideo_stds[i].common,
> sizeof(svideo_stds[i].
> common));
> + tm6000_set_audio_std(dev,
> svideo_stds[i].audio_default_std); +
> goto ret;
> }
> }
> @@ -861,6 +1026,7 @@ int tm6000_set_standard(struct tm6000_core *dev,
> v4l2_std_id * norm) composite_stds[i].common,
> sizeof(composite_stds[i].
> common));
> + tm6000_set_audio_std(dev,
> composite_stds[i].audio_default_std); goto ret;
> }
> }
> diff --git a/drivers/staging/tm6000/tm6000-video.c
> b/drivers/staging/tm6000/tm6000-video.c index a45b012..9304158 100644
> --- a/drivers/staging/tm6000/tm6000-video.c
> +++ b/drivers/staging/tm6000/tm6000-video.c
> @@ -1015,7 +1015,8 @@ static int vidioc_s_std (struct file *file,
> void *priv, v4l2_std_id *norm) struct tm6000_fh *fh=priv;
> struct tm6000_core *dev = fh->dev;
>
> - rc=tm6000_set_standard (dev, norm);
> + rc = tm6000_set_standard(dev, norm);
> + rc = tm6000_init_analog_mode(dev);
>
> fh->width = dev->width;
> fh->height = dev->height;
> @@ -1292,9 +1293,10 @@ static int tm6000_open(struct file *file)
> "active=%d\n",list_empty(&dev->vidq.active));
>
> /* initialize hardware on analog mode */
> - if (dev->mode!=TM6000_MODE_ANALOG) {
> - rc=tm6000_init_analog_mode (dev);
> - if (rc<0)
> +// if (dev->mode!=TM6000_MODE_ANALOG) {
> +// rc = tm6000_set_standard(dev, dev->norm);
> + rc += tm6000_init_analog_mode(dev);
> + if (rc < 0)
> return rc;
>
> /* Put all controls at a sane state */
> @@ -1302,7 +1304,7 @@ static int tm6000_open(struct file *file)
> qctl_regs[i] =tm6000_qctrl[i].default_value;
>
> dev->mode=TM6000_MODE_ANALOG;
> - }
> +// }
>
> videobuf_queue_vmalloc_init(&fh->vb_vidq, &tm6000_video_qops,
> NULL, &dev->slock,
^ permalink raw reply
* Re: [PATCH 2/5] scsi: megaraid_sas - support devices update flag
From: James Bottomley @ 2010-10-07 22:35 UTC (permalink / raw)
To: bo yang; +Cc: bo.yang, linux-scsi, akpm, linux-kernel
In-Reply-To: <AANLkTim3OKvhov1uCj5g6YgmOzR1rDogLmtJMTkbYq5V@mail.gmail.com>
On Wed, 2010-09-22 at 22:50 -0400, bo yang wrote:
> Driver added the Device update flag to tell LSI application driver
> will do the device Update. LSI MegaRAID SAS application will check
> this flag to decide if it is need to update the Device or not.
Well, the good news is I've got the Online Controller reset update. The
bad news is that this patch now fails to apply: looks like an attachment
problem again:
Applying: megaraid_sas: support devices update flag
fatal: corrupt patch at line 70
Patch failed at 0001 megaraid_sas: support devices update flag
James
^ permalink raw reply
* Re: [PATCH] SCSI tape: add MTWEOFI to write filemarks without flushing drive buffer
From: James Bottomley @ 2010-10-07 21:54 UTC (permalink / raw)
To: Kai Makisara; +Cc: linux-scsi
In-Reply-To: <alpine.LNX.2.00.1008291828080.8430@kai.makisara.local>
On Sun, 2010-08-29 at 18:45 +0300, Kai Makisara wrote:
> This patch adds a new MTIOCTOP operation MTWEOFI that writes filemarks with
> immediate bit set. This means that the drive does not flush its buffer and the
> next file can be started immediately. This speeds up writing in applications
> that have to write multiple small files.
This patch is rejecting massively ... could you respin it against
scsi-misc, please?
jejb@mulgrave:~/git/scsi-misc-2.6> patch -p1 < ~/tmp.mail
patching file drivers/scsi/st.c
Hunk #1 FAILED at 9.
Hunk #2 succeeded at 17 with fuzz 2.
Hunk #3 FAILED at 2696.
Hunk #4 FAILED at 2883.
Hunk #5 FAILED at 2901.
4 out of 5 hunks FAILED -- saving rejects to file drivers/scsi/st.c.rej
patching file include/linux/mtio.h
Hunk #1 FAILED at 63.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/mtio.h.rej
patching file Documentation/scsi/st.txt
Hunk #1 succeeded at 2 with fuzz 2.
Hunk #2 FAILED at 85.
Hunk #3 FAILED at 301.
2 out of 3 hunks FAILED -- saving rejects to file Documentation/scsi/st.txt.rej
Thanks,
James
^ permalink raw reply
* Re: [PATCH v2 00/11] SDIO Runtime PM Support
From: Luciano Coelho @ 2010-10-08 5:00 UTC (permalink / raw)
To: ext Chris Ball
Cc: ext Ohad Ben-Cohen, linux-mmc@vger.kernel.org,
linux-wireless@vger.kernel.org, Nicolas Pitre
In-Reply-To: <20101007180107.GA15745@void.printf.net>
On Thu, 2010-10-07 at 20:01 +0200, ext Chris Ball wrote:
> Hi Luciano, Ohad,
>
> On Thu, Oct 07, 2010 at 03:32:16PM +0300, Luciano Coelho wrote:
> > I have tested this on my beagle board with the wl1271 patches that Ohad
> > provided and it seems to be working fine. I've also created a small
> > script to stress test the implementation a little bit and didn't see any
> > problems.
> >
> > Tested-by: Luciano Coelho <luciano.coelho@nokia.com>
> >
> > This is quite an important fix in the wl1271 point-of-view. Chris, do
> > you think there is any chance that this could make it to 2.6.37?
>
> Yes, can do -- the patchset looks good, and I've just pushed patches
> 1-9 (the MMC patches) to mmc-next. Please go ahead and submit the
> two wl1271 patches through wireless-testing whenever you're ready.
Thanks a lot, Chris! This will easy our development work quite much,
since we don't have to be applying separate patches to be able to enable
and disable the chip at runtime.
I'll apply the wl1271 patches via the wl12xx tree.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Ok, dumb question time ...
From: Joe Landman @ 2010-10-08 5:00 UTC (permalink / raw)
To: Neil Brown; +Cc: landman, linux-raid
In-Reply-To: <20101008155448.19d46db6@notabene>
On 10/08/2010 12:54 AM, Neil Brown wrote:
>> This is quite disconcerting ... I thought it would be simple.
>
> It is.
>
> You want the array to think that it only has two devices?
>
> mdadm --grow /dev/md0 --raid-devices=2
Very nice ... thanks!
^ permalink raw reply
* Re: [PATCH] serial: DCC(JTAG) serial and console emulation support
From: Daniel Walker @ 2010-10-08 4:59 UTC (permalink / raw)
To: Mike Frysinger
Cc: Greg KH, Alan Cox, linux-kernel, Hyok S. Choi, Tony Lindgren,
Jeff Ohlstein, Ben Dooks, Alan Cox, Kukjin Kim, Feng Tang,
Tobias Klauser, Jason Wessel, Philippe Langlais
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1771 bytes --]
I'm not disputing the serial core part. I ok with converting it to tty.
Daniel
Mike Frysinger <vapier@gentoo.org> wrote:
>On Thu, Oct 7, 2010 at 18:11, Daniel Walker wrote:
>> On Thu, 2010-10-07 at 14:52 -0700, Greg KH wrote:
>>> On Thu, Oct 07, 2010 at 02:47:18PM -0700, Daniel Walker wrote:
>>> > On Thu, 2010-10-07 at 14:15 -0700, Greg KH wrote:
>>> > > On Thu, Oct 07, 2010 at 01:51:18PM -0700, Daniel Walker wrote:
>>> > > > > We've said no over a period of about ten years to a lot of attempts to
>>> > > > > just borrow the ttyS0 range. If we'd said yes it would have been a
>>> > > > > complete mess by now.
>>> > > > >
>>> > > > > So the answer is no.
>>> > > >
>>> > > > Nothing can be unilateral, there's always room for exceptions. You
>>> > > > should say something more like "it's possible, but unlikely".
>>> > >
>>> > > Hm, how about this, as the TTY and serial driver[1] maintainer, I will
>>> > > not accept this kind of patch at all.
>>> > >
>>> > > Is that final enough for you?
>>> >
>>> > So you don't like it, that's fair enough .. <thinks>I wonder what other
>>> > maintainers I can send this too</thinks> ;)
>>> >
>>> > Can you be more specific about your objections
>>>
>>> See everything that Mike and Alan wrote, do I need to repeat it?
>>
>> I'm not sure .. I would say "Yes" if I didn't get the feeling your
>> already to tear my head off.
>>
>> I think the only disputed issue is the use of ttyS as options part of
>> the driver ..
>
>and using "serial_core" at all in favor of HVC or tty_core (the latter
>might be easier for you as the former is a bit of unknown atm)
>-mike
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Andrew Morton @ 2010-10-08 4:55 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101008133712.2a836331.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 8 Oct 2010 13:37:12 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Thu, 7 Oct 2010 16:14:54 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Thu, 7 Oct 2010 17:04:05 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > > account if flags are properly set.
> > >
> > > The core code, mem_cgroup_move_charge_pte_range() does
> > >
> > > pte_offset_map_lock();
> > > for all ptes in a page table:
> > > 1. look into page table, find_and_get a page
> > > 2. remove it from LRU.
> > > 3. move charge.
> > > 4. putback to LRU. put_page()
> > > pte_offset_map_unlock();
> > >
> > > for pte entries on a 3rd level? page table.
> > >
> > > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> > >
> > > for 32 pages: pte_offset_map_lock()
> > > find_and_get a page
> > > record it
> > > pte_offset_map_unlock()
> > > for all recorded pages
> > > isolate it from LRU.
> > > move charge
> > > putback to LRU
> > > for all recorded pages
> > > put_page()
> >
> > The patch makes the code larger, more complex and slower!
> >
>
> Slower ?
Sure. It walks the same data three times, potentially causing
thrashing in the L1 cache. It takes and releases locks at a higher
frequency. It increases the text size.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 2.6.36-rc7: kernel panic with SECURITY_TOMOYO=y
From: KOSAKI Motohiro @ 2010-10-08 4:55 UTC (permalink / raw)
To: Christian Kujau; +Cc: kosaki.motohiro, LKML, takedakn, penguin-kernel
In-Reply-To: <alpine.DEB.2.01.1010071637090.21082@trent.utfs.org>
> On Thu, 7 Oct 2010 at 15:43, Christian Kujau wrote:
> > Kernel panic - not syncing: Profile uersion 0 is not supported
>
> OK, I just saw that security/tomoyo/common.c panics when:
>
> if (tomoyo_profile_version != 20090903)
> panic("Profile version %u is not supported.\n",
> tomoyo_profile_version);
>
> If it's imperative that the profile version is somewhat current (mine was
> not, I had old tomoyo-ccstools installed), I would have expected a
> slightly more descriptive error messages (apart from that panic), but now
> I know. Upgraded to tomoyo-tools-2.3.0-20100820 did the trick.
I agree this zero information panic is suck.
Handa-san, please see this panic message again.
> Kernel panic - not syncing: Profile uersion 0 is not supported
Profile?
This message doesn't have any information which should we look!
And, 'profile' is wrong word. TOMOYO have to recommend to upgrade
userland tools here at minimum.
The best way is, of cource, you don't break backward compatibility.
> Call Trace:
> [efB4fd60] [c0008c88] show_stack+0x48/0x168 (unreliable)
> [ef84fda0] [c0375fe01 panic+0xa4/0x1ec
> [ef84fdf0] [c01c5f30] tomoyo_close_control+0x0/0xa4
> [efB4fe00] [c01cc2f0] tomoyo_load_policy+0xeB/0x11c
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: Andrew Morton @ 2010-10-08 4:55 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101008133712.2a836331.kamezawa.hiroyu@jp.fujitsu.com>
On Fri, 8 Oct 2010 13:37:12 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> On Thu, 7 Oct 2010 16:14:54 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > On Thu, 7 Oct 2010 17:04:05 +0900
> > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> >
> > > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > > account if flags are properly set.
> > >
> > > The core code, mem_cgroup_move_charge_pte_range() does
> > >
> > > pte_offset_map_lock();
> > > for all ptes in a page table:
> > > 1. look into page table, find_and_get a page
> > > 2. remove it from LRU.
> > > 3. move charge.
> > > 4. putback to LRU. put_page()
> > > pte_offset_map_unlock();
> > >
> > > for pte entries on a 3rd level? page table.
> > >
> > > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> > >
> > > for 32 pages: pte_offset_map_lock()
> > > find_and_get a page
> > > record it
> > > pte_offset_map_unlock()
> > > for all recorded pages
> > > isolate it from LRU.
> > > move charge
> > > putback to LRU
> > > for all recorded pages
> > > put_page()
> >
> > The patch makes the code larger, more complex and slower!
> >
>
> Slower ?
Sure. It walks the same data three times, potentially causing
thrashing in the L1 cache. It takes and releases locks at a higher
frequency. It increases the text size.
^ permalink raw reply
* RE: [PATCH 2/2] davinci: Platform support for OMAP-L137/AM17x NOR flash driver
From: Nori, Sekhar @ 2010-10-08 4:54 UTC (permalink / raw)
To: Sergei Shtylyov, Dharmappa, Savinay
Cc: Aleksey Makarov, davinci-linux-open-source@linux.davincidsp.com,
linux-mtd@lists.infradead.org, David Griego
In-Reply-To: <4CADE1B8.50800@mvista.com>
Hi Sergei,
On Thu, Oct 07, 2010 at 20:35:28, Sergei Shtylyov wrote:
> > +static void da830_evm_nor_done(void *data)
> > +{
> > + clk_disable(da830_evm_nor.clk);
> > + clk_put(da830_evm_nor.clk);
> > + iounmap(da830_evm_nor.latch.addr);
> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
> > + iounmap(da830_evm_nor.aemif.addr);
> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
> > +}
>
> Why you've changed this function which was useful also for the error cleanup
> before?
The issues down below aside, I think goto based error handling
is clearer to follow. Any objections to using goto based
error handing per-se?
Thanks,
Sekhar
>
> > +static int da830_evm_nor_init(void *data, int cs)
> > +{
> > + /* Turn on AEMIF clocks */
> > + da830_evm_nor.clk = clk_get(NULL, "aemif");
> > + if (IS_ERR(da830_evm_nor.clk)) {
> > + pr_err("%s: could not get AEMIF clock\n", __func__);
> > + da830_evm_nor.clk = NULL;
> > + return -ENODEV;
> > + }
> > + clk_enable(da830_evm_nor.clk);
> > +
> > + da830_evm_nor.aemif.res = request_mem_region(DA8XX_AEMIF_CTL_BASE,
> > + SZ_32K, "AEMIF control");
> > + if (da830_evm_nor.aemif.res == NULL) {
> > + pr_err("%s: could not request AEMIF control region\n",
> > + __func__);
> > + goto err_aemif_region;
>
> I wonder why you used goto's at all. Anyway, the error cleanup code is
> completely broken now.
>
> > + }
> > +
> > + da830_evm_nor.aemif.addr = ioremap_nocache(DA8XX_AEMIF_CTL_BASE,
> > + SZ_32K);
> > + if (da830_evm_nor.aemif.addr == NULL) {
> > + pr_err("%s: could not remap AEMIF control region\n", __func__);
> > + goto err_aemif_ioremap;
> > + }
> > +
> > + /* Setup AEMIF -- timings, etc. */
> > +
> > + /* Set maximum wait cycles */
> > + davinci_aemif_setup_timing(&da830_evm_norflash_timing,
> > + da830_evm_nor.aemif.addr, cs);
> > +
> > + davinci_aemif_setup_timing(&da830_evm_norflash_timing,
> > + da830_evm_nor.aemif.addr, cs + 1);
> > +
> > + /* Setup the window to access the latch */
> > + da830_evm_nor.latch.res =
> > + request_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE,
> > + "DA830 UI NOR address latch");
> > + if (da830_evm_nor.latch.res == NULL) {
> > + pr_err("%s: could not request address latch region\n",
> > + __func__);
> > + goto err_latch_region;
> > + }
> > +
> > + da830_evm_nor.latch.addr =
> > + ioremap_nocache(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
> > + if (da830_evm_nor.latch.addr == NULL) {
> > + pr_err("%s: could not remap address latch region\n", __func__);
> > + goto err_latch_ioremap;
> > + }
> > + return 0;
> > +
> > +err_aemif_region:
> > + release_mem_region(DA8XX_AEMIF_CTL_BASE, SZ_32K);
>
> Why release what you've just failed to request?!
>
> > + da830_evm_nor.aemif.res = NULL;
>
> Useless assignment.
>
> > + return -EBUSY;
>
> And you're not calling clk_disable().
>
> > +err_aemif_ioremap:
> > + iounmap(da830_evm_nor.aemif.addr);
>
> Why unmap what you've just failed to map?! da830_evm_nor.aemif.addr is NULL.
>
> > + da830_evm_nor.aemif.addr = NULL;
>
> Useless assignment.
>
> > + return -ENOMEM;
>
> You're not calling release_mem_region() and clk_disable().
>
> > +err_latch_region:
> > + release_mem_region(DA8XX_AEMIF_CS3_BASE, PAGE_SIZE);
>
> Why release what you've just failed to request?!
>
> > + da830_evm_nor.latch.res = NULL;
>
> Useless assginment.
>
> > + return -EBUSY;
>
> You're not calling iounmap() and release_mem_region() for the NOR flash
> region and also not calling clk_disable().
>
> > +
> > +err_latch_ioremap:
> > + iounmap(da830_evm_nor.latch.addr);
>
> Why unmap what you've just failed to map?! da830_evm_nor.latch.addr is NULL.
>
> > + da830_evm_nor.latch.addr = NULL;
>
> Useless assginment.
>
> > + return -ENOMEM;
>
> You're not release_mem_region() for the latch region, not calling iounmap()
> and release_mem_region() for the NOR flash region and also not calling
> clk_disable().
>
> > +}
> [...]
>
> Your changes made me doubt that you actually understood the code well enough
> before doing them...
>
> WBR, Sergei
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source@linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
^ permalink raw reply
* Re: Ok, dumb question time ...
From: Neil Brown @ 2010-10-08 4:54 UTC (permalink / raw)
To: landman; +Cc: linux-raid
In-Reply-To: <4CAE9C13.3060002@scalableinformatics.com>
On Fri, 08 Oct 2010 00:20:35 -0400
Joe Landman <landman@scalableinformatics.com> wrote:
> Not having much luck with this. Let me explain ...
>
> Imagine we have a RAID1 with 3 elements. It was originally a RAID1 with
> 2 elements, and we added a 3rd using
>
> mdadm /dev/md0 --add /dev/loop1
>
> What I want to do is conceptually very simple. I want to permanently
> remove loop1, without having the array become dirty, or degraded. That
> is, I would like
>
> mdadm /dev/md0 --fail /dev/loop1 --remove /dev/loop1
>
> to result in a clean array with two members.
>
> It doesn't. The array is marked as being in the "clean, degraded"
> state. Which, as it is the root file system array, has the unfortunate
> side effect of not allowing the RAID1 to properly assemble at boot (that
> degraded state).
>
> So ... can I force the array to either remove the extra unneeded loop1
> device, and update its metadata properly ... or force it into a clean,
> active state without the loop1 device, or force the assembly on boot to
> occur regardless of what it thinks it should have?
>
> This is quite disconcerting ... I thought it would be simple.
It is.
You want the array to think that it only has two devices?
mdadm --grow /dev/md0 --raid-devices=2
Done.
NeilBrown
^ permalink raw reply
* Re: [PATCH] remove leftover rcu_read_unlock calls from __mkroute_output
From: Eric Dumazet @ 2010-10-08 4:47 UTC (permalink / raw)
To: Dimitris Michailidis; +Cc: netdev
In-Reply-To: <1286498918-30636-1-git-send-email-dm@chelsio.com>
Le jeudi 07 octobre 2010 à 17:48 -0700, Dimitris Michailidis a écrit :
> Commit "fib: RCU conversion of fib_lookup()" removed rcu_read_lock() from
> __mkroute_output but left a couple of calls to rcu_read_unlock() in there.
> This causes lockdep to complain that the rcu_read_unlock() call in
> __ip_route_output_key causes a lock inbalance and quickly crashes the
> kernel. The below fixes this for me.
>
> Signed-off-by: Dimitris Michailidis <dm@chelsio.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks Dimitris !
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > A adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > A mm/memcontrol.c | A 18 ++++++++++++++++++
> > A 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > A /*
> > A * check whether the @pc is valid for moving account and call
> > A * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > A */
> > A static int mem_cgroup_move_account(struct page_cgroup *pc,
> > A A A A A A A A struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > A {
> > A A A A int ret = -EINVAL;
> > +
> > + A A A /*
> > + A A A A * We move severl flags and accounting information here. So we need to
> > + A A A A * avoid the races with update_stat routines. For most of routines,
> > + A A A A * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + A A A A * care of IRQ context. If flag updates comes from IRQ context, This
> > + A A A A * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + A A A A *
> > + A A A A * Now, the only race we have is Writeback flag. We wait for it cleared
> > + A A A A * before starting our jobs.
> > + A A A A */
> > +
> > + A A A lock_page(pc->page);
> > + A A A wait_on_page_writeback(pc->page);
> > +
> > A A A A lock_page_cgroup(pc);
> > A A A A if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > A A A A A A A A __mem_cgroup_move_account(pc, from, to, uncharge);
> > A A A A A A A A ret = 0;
> > A A A A }
> > A A A A unlock_page_cgroup(pc);
> > + A A A unlock_page(pc->page);
> > A A A A /*
> > A A A A * check events
> > A A A A */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > mm/memcontrol.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > /*
> > * check whether the @pc is valid for moving account and call
> > * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > */
> > static int mem_cgroup_move_account(struct page_cgroup *pc,
> > struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > {
> > int ret = -EINVAL;
> > +
> > + /*
> > + * We move severl flags and accounting information here. So we need to
> > + * avoid the races with update_stat routines. For most of routines,
> > + * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + * care of IRQ context. If flag updates comes from IRQ context, This
> > + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + *
> > + * Now, the only race we have is Writeback flag. We wait for it cleared
> > + * before starting our jobs.
> > + */
> > +
> > + lock_page(pc->page);
> > + wait_on_page_writeback(pc->page);
> > +
> > lock_page_cgroup(pc);
> > if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > __mem_cgroup_move_account(pc, from, to, uncharge);
> > ret = 0;
> > }
> > unlock_page_cgroup(pc);
> > + unlock_page(pc->page);
> > /*
> > * check events
> > */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
^ permalink raw reply
* Re: [PATCH] ehea: Fix a checksum issue on the receive path
From: Eric Dumazet @ 2010-10-08 4:45 UTC (permalink / raw)
To: leitao; +Cc: davem, netdev, Jay Vosburgh
In-Reply-To: <1286493453-21784-1-git-send-email-leitao@linux.vnet.ibm.com>
Le jeudi 07 octobre 2010 à 19:17 -0400, leitao@linux.vnet.ibm.com a
écrit :
> Currently we set all skbs with CHECKSUM_UNNECESSARY, even
> those whose protocol we don't know. This patch just
> add the CHECKSUM_COMPLETE tag for non TCP/UDP packets.
>
> Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
> ---
> drivers/net/ehea/ehea_main.c | 9 ++++++++-
> drivers/net/ehea/ehea_qmr.h | 1 +
> 2 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
> index 0471cae..45fd045 100644
> --- a/drivers/net/ehea/ehea_main.c
> +++ b/drivers/net/ehea/ehea_main.c
> @@ -533,8 +533,15 @@ static inline void ehea_fill_skb(struct net_device *dev,
> int length = cqe->num_bytes_transfered - 4; /*remove CRC */
>
> skb_put(skb, length);
> - skb->ip_summed = CHECKSUM_UNNECESSARY;
> skb->protocol = eth_type_trans(skb, dev);
> +
> + /* The packet was not an IPV4 packet so a complemented checksum was
> + calculated. The value is found in the Internet Checksum field. */
> + if (cqe->status & EHEA_CQE_BLIND_CKSUM) {
> + skb->ip_summed = CHECKSUM_COMPLETE;
> + skb->csum = csum_unfold(~cqe->inet_checksum_value);
> + } else
> + skb->ip_summed = CHECKSUM_UNNECESSARY;
> }
>
Hi Breno
Just to be clear : packets with wrong checksums are not given to upper
stack, so a tcpdump can not display them ? I am not sure many drivers do
that.
(EHEA_CQE_STAT_ERR_TCP, EHEA_CQE_STAT_ERR_IP)
Thanks !
^ permalink raw reply
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007161454.84570cf9.akpm@linux-foundation.org>
On Thu, 7 Oct 2010 16:14:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 7 Oct 2010 17:04:05 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > account if flags are properly set.
> >
> > The core code, mem_cgroup_move_charge_pte_range() does
> >
> > pte_offset_map_lock();
> > for all ptes in a page table:
> > 1. look into page table, find_and_get a page
> > 2. remove it from LRU.
> > 3. move charge.
> > 4. putback to LRU. put_page()
> > pte_offset_map_unlock();
> >
> > for pte entries on a 3rd level? page table.
> >
> > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> >
> > for 32 pages: pte_offset_map_lock()
> > find_and_get a page
> > record it
> > pte_offset_map_unlock()
> > for all recorded pages
> > isolate it from LRU.
> > move charge
> > putback to LRU
> > for all recorded pages
> > put_page()
>
> The patch makes the code larger, more complex and slower!
>
Slower ?
> I do think we're owed a more complete description of its benefits than
> "seems a bit long". Have problems been observed? Any measurements
> taken?
>
I'll rewrite the whole patch against today's mmotom.
Thanks,
-Kame
>
>
^ permalink raw reply
* Re: [PATCH] memcg: lock-free clear page writeback (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:41 UTC (permalink / raw)
To: Minchan Kim
Cc: Daisuke Nishimura, Greg Thelen, Andrew Morton, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <AANLkTi=kBnrtb5KkFQE3tNwVh1dWeUVBepWjec7ReVL0@mail.gmail.com>
On Fri, 8 Oct 2010 08:35:30 +0900
Minchan Kim <minchan.kim@gmail.com> wrote:
> Hi Kame,
>
> On Thu, Oct 7, 2010 at 3:24 PM, KAMEZAWA Hiroyuki
> <kamezawa.hiroyu@jp.fujitsu.com> wrote:
> > Greg, I think clear_page_writeback() will not require _any_ locks with this patch.
> > But set_page_writeback() requires it...
> > (Maybe adding a special function for clear_page_writeback() is better rather than
> > adding some complex to switch() in update_page_stat())
> >
> > ==
> > From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> >
> > Now, at page information accounting, we do lock_page_cgroup() if pc->mem_cgroup
> > points to a cgroup where someone is moving charges from.
> >
> > At supporing dirty-page accounting, one of troubles is writeback bit.
> > In general, writeback can be cleared via IRQ context. To update writeback bit
> > with lock_page_cgroup() in safe way, we'll have to disable IRQ.
> > ....or do something.
> >
> > This patch waits for completion of writeback under lock_page() and do
> > lock_page_cgroup() in safe way. (We never got end_io via IRQ context.)
> >
> > By this, writeback-accounting will never see race with account_move() and
> > it can trust pc->mem_cgroup always _without_ any lock.
> >
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
> > ---
> > mm/memcontrol.c | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > Index: mmotm-0928/mm/memcontrol.c
> > ===================================================================
> > --- mmotm-0928.orig/mm/memcontrol.c
> > +++ mmotm-0928/mm/memcontrol.c
> > @@ -2183,17 +2183,35 @@ static void __mem_cgroup_move_account(st
> > /*
> > * check whether the @pc is valid for moving account and call
> > * __mem_cgroup_move_account()
> > + * Don't call this under pte_lock etc...we'll do lock_page() and wait for
> > + * the end of I/O.
> > */
> > static int mem_cgroup_move_account(struct page_cgroup *pc,
> > struct mem_cgroup *from, struct mem_cgroup *to, bool uncharge)
> > {
> > int ret = -EINVAL;
> > +
> > + /*
> > + * We move severl flags and accounting information here. So we need to
> > + * avoid the races with update_stat routines. For most of routines,
> > + * lock_page_cgroup() is enough for avoiding race. But we need to take
> > + * care of IRQ context. If flag updates comes from IRQ context, This
> > + * "move account" will be racy (and cause deadlock in lock_page_cgroup())
> > + *
> > + * Now, the only race we have is Writeback flag. We wait for it cleared
> > + * before starting our jobs.
> > + */
> > +
> > + lock_page(pc->page);
> > + wait_on_page_writeback(pc->page);
> > +
> > lock_page_cgroup(pc);
> > if (PageCgroupUsed(pc) && pc->mem_cgroup == from) {
> > __mem_cgroup_move_account(pc, from, to, uncharge);
> > ret = 0;
> > }
> > unlock_page_cgroup(pc);
> > + unlock_page(pc->page);
> > /*
> > * check events
> > */
> >
> >
>
> Looks good to me.
> But let me ask a question.
> Why do only move_account need this logic?
Because charge/uncharge (add/remove to radix-tree or swapcache)
never happens while a page is PG_writeback.
> Is deadlock candidate is only this place?
yes.
> How about mem_cgroup_prepare_migration?
>
> unmap_and_move
> lock_page
> mem_cgroup_prepare_migration
> lock_page_cgroup
> ...
> softirq happen
> lock_page_cgroup
>
>
Nice cactch. I'll move prepare_migraon after wait_on_page_writeback()
> If race happens only where move_account and writeback, please describe
> it as comment.
> It would help to review the code in future.
>
Sure, updates are necessary.
Thanks,
-Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: empty filter on FORWARD chain with rp_filter means safe right?
From: Payam Chychi @ 2010-10-08 4:40 UTC (permalink / raw)
To: Scott Mcdermott; +Cc: netfilter
In-Reply-To: <20101008043129.GA2017@omnius.omnisys.com>
Thats correct Scott,
in order for any systems to abuse your setup they will need to be
directly connected to a segment that has knowledge of valid route to the
end system... meaning if a computer is 2 hops away and the router in
between has no knowledge of how to get to your private rfc1918 then pkts
get dropped.
Keep in mind that as ipv4 exhaustion gets extreme, some isps will use
rcf1918 blocks and route them either in their IGP or even EGP (aka
internet routes)...
-Payam
Network Engineer / Security Specialist
Scott Mcdermott wrote:
> Hello,
>
> I encountered a system today with two attached
> networks, one public and the other RFC1918. The box
> had ip_foward=1, FORWARD chain empty, policy ACCEPT.
> rp_filter was set on both the interfaces.
>
> Now if I were somewhere off the public interface, but
> many hops away, there is no possible way to get packets
> to the RFC1918 side of the box is there? Because I
> have no way to actually route the packets to the
> gateway with destination addresses on the far side. So
> actually this box is safe from malicious activity, even
> though there is an ACCEPT policy on FORWARD and it's
> set with routing enabled. Is this correct?
>
> Now if instead I have control of a station on the same
> segment as the gateway's public interface, or if I
> control routers in-between and can set up routes to get
> packets to the box with the internal IPs as
> destinations, then it's a different story. But in the
> common case of having ISPs in between (which will drop
> my packets with RFC1918 destinations), it's not
> possible to get packets to the gateway's internal
> network except if they NAT some of them for me.
>
> Please help me to see if my understanding is correct.
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH 2/3] Retry page fault when blocking on disk transfer.
From: Michel Lespinasse @ 2010-10-08 4:39 UTC (permalink / raw)
To: Rik van Riel, Linus Torvalds
Cc: linux-mm, Ying Han, linux-kernel, Andrew Morton, Nick Piggin,
Peter Zijlstra
In-Reply-To: <AANLkTimdACZ9Xm01DM2+E64+T5XfLffrkFBhf7CJ286p@mail.gmail.com>
On Tue, Oct 05, 2010 at 03:44:22PM -0700, Michel Lespinasse wrote:
> On Tue, Oct 5, 2010 at 10:38 AM, Rik van Riel <riel@redhat.com> wrote:
> > Looks like it should be relatively easy to do something
> > similar in do_swap_page also.
>
> Good idea. We don't make use of swap too much, which is probably why
> we didn't have that in our kernel, but it seems like a good idea just
> for uniformity. I'll add this in a follow-on patch.
So here's the patch. Sorry for the delay - it did not take long to write,
but I couldn't test it before today.
Please have a look - I'd like to add this to the series I sent earlier.
----------------------------------- 8< ---------------------------------
Retry page fault when blocking on swap in
This change is the cousin of 'Retry page fault when blocking
on disk transfer'. The idea here is to reduce mmap_sem hold times
that are caused by disk transfers when swapping in pages. We drop
mmap_sem while waiting for the page lock, and return the VM_FAULT_RETRY
flag. do_page_fault will then re-acquire mmap_sem and retry the
page fault. It is expected that upon retry the page will now be cached,
and thus the retry will complete with a low mmap_sem hold time.
Signed-off-by: Michel Lespinasse <walken@google.com>
diff --git a/mm/memory.c b/mm/memory.c
index b068c68..0ec70b4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2613,6 +2613,21 @@ int vmtruncate_range(struct inode *inode, loff_t offset, loff_t end)
return 0;
}
+static inline int lock_page_or_retry(struct page *page, struct mm_struct *mm,
+ unsigned int flags)
+{
+ if (trylock_page(page))
+ return 1;
+ if (!(flags & FAULT_FLAG_ALLOW_RETRY)) {
+ __lock_page(page);
+ return 1;
+ }
+
+ up_read(&mm->mmap_sem);
+ wait_on_page_locked(page);
+ return 0;
+}
+
/*
* We enter with non-exclusive mmap_sem (to exclude vma changes,
* but allow concurrent faults), and pte mapped but not yet locked.
@@ -2626,6 +2641,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page *page, *swapcache = NULL;
swp_entry_t entry;
pte_t pte;
+ int locked;
struct mem_cgroup *ptr = NULL;
int exclusive = 0;
int ret = 0;
@@ -2676,8 +2692,12 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
goto out_release;
}
- lock_page(page);
+ locked = lock_page_or_retry(page, mm, flags);
delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
+ if (!locked) {
+ ret |= VM_FAULT_RETRY;
+ goto out_release;
+ }
/*
* Make sure try_to_free_swap or reuse_swap_page or swapoff did not
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH 2/3] Retry page fault when blocking on disk transfer.
From: Michel Lespinasse @ 2010-10-08 4:39 UTC (permalink / raw)
To: Rik van Riel, Linus Torvalds
Cc: linux-mm, Ying Han, linux-kernel, Andrew Morton, Nick Piggin,
Peter Zijlstra
In-Reply-To: <AANLkTimdACZ9Xm01DM2+E64+T5XfLffrkFBhf7CJ286p@mail.gmail.com>
On Tue, Oct 05, 2010 at 03:44:22PM -0700, Michel Lespinasse wrote:
> On Tue, Oct 5, 2010 at 10:38 AM, Rik van Riel <riel@redhat.com> wrote:
> > Looks like it should be relatively easy to do something
> > similar in do_swap_page also.
>
> Good idea. We don't make use of swap too much, which is probably why
> we didn't have that in our kernel, but it seems like a good idea just
> for uniformity. I'll add this in a follow-on patch.
So here's the patch. Sorry for the delay - it did not take long to write,
but I couldn't test it before today.
Please have a look - I'd like to add this to the series I sent earlier.
----------------------------------- 8< ---------------------------------
Retry page fault when blocking on swap in
This change is the cousin of 'Retry page fault when blocking
on disk transfer'. The idea here is to reduce mmap_sem hold times
that are caused by disk transfers when swapping in pages. We drop
mmap_sem while waiting for the page lock, and return the VM_FAULT_RETRY
flag. do_page_fault will then re-acquire mmap_sem and retry the
page fault. It is expected that upon retry the page will now be cached,
and thus the retry will complete with a low mmap_sem hold time.
Signed-off-by: Michel Lespinasse <walken@google.com>
diff --git a/mm/memory.c b/mm/memory.c
index b068c68..0ec70b4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2613,6 +2613,21 @@ int vmtruncate_range(struct inode *inode, loff_t offset, loff_t end)
return 0;
}
+static inline int lock_page_or_retry(struct page *page, struct mm_struct *mm,
+ unsigned int flags)
+{
+ if (trylock_page(page))
+ return 1;
+ if (!(flags & FAULT_FLAG_ALLOW_RETRY)) {
+ __lock_page(page);
+ return 1;
+ }
+
+ up_read(&mm->mmap_sem);
+ wait_on_page_locked(page);
+ return 0;
+}
+
/*
* We enter with non-exclusive mmap_sem (to exclude vma changes,
* but allow concurrent faults), and pte mapped but not yet locked.
@@ -2626,6 +2641,7 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
struct page *page, *swapcache = NULL;
swp_entry_t entry;
pte_t pte;
+ int locked;
struct mem_cgroup *ptr = NULL;
int exclusive = 0;
int ret = 0;
@@ -2676,8 +2692,12 @@ static int do_swap_page(struct mm_struct *mm, struct vm_area_struct *vma,
goto out_release;
}
- lock_page(page);
+ locked = lock_page_or_retry(page, mm, flags);
delayacct_clear_flag(DELAYACCT_PF_SWAPIN);
+ if (!locked) {
+ ret |= VM_FAULT_RETRY;
+ goto out_release;
+ }
/*
* Make sure try_to_free_swap or reuse_swap_page or swapoff did not
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
^ permalink raw reply related
* Re: [PATCH v2] memcg: reduce lock time at move charge (Was Re: [PATCH 04/10] memcg: disable local interrupts in lock_page_cgroup()
From: KAMEZAWA Hiroyuki @ 2010-10-08 4:37 UTC (permalink / raw)
To: Andrew Morton
Cc: Daisuke Nishimura, Minchan Kim, Greg Thelen, linux-kernel,
linux-mm, containers, Andrea Righi, Balbir Singh
In-Reply-To: <20101007161454.84570cf9.akpm@linux-foundation.org>
On Thu, 7 Oct 2010 16:14:54 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 7 Oct 2010 17:04:05 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > Now, at task migration among cgroup, memory cgroup scans page table and moving
> > account if flags are properly set.
> >
> > The core code, mem_cgroup_move_charge_pte_range() does
> >
> > pte_offset_map_lock();
> > for all ptes in a page table:
> > 1. look into page table, find_and_get a page
> > 2. remove it from LRU.
> > 3. move charge.
> > 4. putback to LRU. put_page()
> > pte_offset_map_unlock();
> >
> > for pte entries on a 3rd level? page table.
> >
> > This pte_offset_map_lock seems a bit long. This patch modifies a rountine as
> >
> > for 32 pages: pte_offset_map_lock()
> > find_and_get a page
> > record it
> > pte_offset_map_unlock()
> > for all recorded pages
> > isolate it from LRU.
> > move charge
> > putback to LRU
> > for all recorded pages
> > put_page()
>
> The patch makes the code larger, more complex and slower!
>
Slower ?
> I do think we're owed a more complete description of its benefits than
> "seems a bit long". Have problems been observed? Any measurements
> taken?
>
I'll rewrite the whole patch against today's mmotom.
Thanks,
-Kame
>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Configuration of nestedhvm
From: Dong, Eddie @ 2010-10-08 4:34 UTC (permalink / raw)
To: Keir Fraser; +Cc: Xen-devel, Dong, Eddie
In-Reply-To: <987664A83D2D224EAE907B061CE93D530163EA9749@orsmsx505.amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 4104 bytes --]
Keir:
Despite of the negotioatiom of nested virtualization wrapper, here comes with the global configuration parameter and the CR4 layout handling between SVM & VMX. These are wrapper neutral IMO.
Thx, Eddie
===Patch1
Nested virtualization usage model is emerging, however we must guarantee it won't impact the performance of simple virtualization.
This patch add an boot parameter for nested virtualization, which is disabled by default for now.
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:29:38 2010 +0800
@@ -66,6 +66,9 @@ unsigned int opt_hvm_debug_level __read_
unsigned int opt_hvm_debug_level __read_mostly;
integer_param("hvm_debug", opt_hvm_debug_level);
+unsigned int enable_nested_hvm __read_mostly;
+integer_param("nested_hvm", enable_nested_hvm);
+
struct hvm_function_table hvm_funcs __read_mostly;
/* I/O permission bitmap is globally shared by all HVM guests. */
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:35:03 2010 +0800
@@ -250,6 +250,9 @@ hvm_set_segment_register(struct vcpu *v,
#define is_viridian_domain(_d) \
(is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
+/* TODO: handle per domain configuration */
+#define is_nestedhvm(_d) (enable_nested_hvm && is_hvm_domain(_d))
+
void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
void hvm_migrate_timers(struct vcpu *v);
===Patch2
This patch solves the CR4 bit (VMXE) format difference between AMD & Intel processor.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:46:55 2010 +0800
@@ -630,6 +630,11 @@ static int hvm_load_cpu_ctxt(struct doma
struct hvm_hw_cpu ctxt;
struct segment_register seg;
struct vcpu_guest_context *vc;
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(d) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
/* Which vcpu is this? */
vcpuid = hvm_load_instance(h);
@@ -662,7 +667,7 @@ static int hvm_load_cpu_ctxt(struct doma
return -EINVAL;
}
- if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS )
+ if ( ctxt.cr4 & rsv_bits )
{
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
ctxt.cr4);
@@ -1243,8 +1248,12 @@ int hvm_set_cr4(unsigned long value)
{
struct vcpu *v = current;
unsigned long old_cr;
-
- if ( value & HVM_CR4_GUEST_RESERVED_BITS )
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(v->domain) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
+ if ( value & rsv_bits )
{
HVM_DBG_LOG(DBG_LEVEL_1,
"Guest attempts to set reserved bit in CR4: %lx",
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:46:35 2010 +0800
@@ -291,7 +291,8 @@ static inline int hvm_do_pmu_interrupt(s
X86_CR4_DE | X86_CR4_PSE | X86_CR4_PAE | \
X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE | \
X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | \
- (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
+ (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))) | \
+ X86_CR4_VMXE)
/* These exceptions must always be intercepted. */
#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
[-- Attachment #2: patch1 --]
[-- Type: application/octet-stream, Size: 1540 bytes --]
Nested virtualization usage model is emerging, however we must guarantee it won't impact the performance of simple virtualization.
This patch add an boot parameter for nested virtualization, which is disabled by default for now.
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:29:38 2010 +0800
@@ -66,6 +66,9 @@ unsigned int opt_hvm_debug_level __read_
unsigned int opt_hvm_debug_level __read_mostly;
integer_param("hvm_debug", opt_hvm_debug_level);
+unsigned int enable_nested_hvm __read_mostly;
+integer_param("nested_hvm", enable_nested_hvm);
+
struct hvm_function_table hvm_funcs __read_mostly;
/* I/O permission bitmap is globally shared by all HVM guests. */
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:35:03 2010 +0800
@@ -250,6 +250,9 @@ hvm_set_segment_register(struct vcpu *v,
#define is_viridian_domain(_d) \
(is_hvm_domain(_d) && ((_d)->arch.hvm_domain.params[HVM_PARAM_VIRIDIAN]))
+/* TODO: handle per domain configuration */
+#define is_nestedhvm(_d) (enable_nested_hvm && is_hvm_domain(_d))
+
void hvm_cpuid(unsigned int input, unsigned int *eax, unsigned int *ebx,
unsigned int *ecx, unsigned int *edx);
void hvm_migrate_timers(struct vcpu *v);
[-- Attachment #3: patch2 --]
[-- Type: application/octet-stream, Size: 2231 bytes --]
This patch solves the CR4 bit (VMXE) format difference between AMD & Intel processor.
Signed-off-by: Qing He <qing.he@intel.com>
Signed-off-by: Eddie Dong <eddie.dong@intel.com>
diff -r 1385b15e168f xen/arch/x86/hvm/hvm.c
--- a/xen/arch/x86/hvm/hvm.c Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/arch/x86/hvm/hvm.c Fri Oct 08 10:46:55 2010 +0800
@@ -630,6 +630,11 @@ static int hvm_load_cpu_ctxt(struct doma
struct hvm_hw_cpu ctxt;
struct segment_register seg;
struct vcpu_guest_context *vc;
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(d) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
/* Which vcpu is this? */
vcpuid = hvm_load_instance(h);
@@ -662,7 +667,7 @@ static int hvm_load_cpu_ctxt(struct doma
return -EINVAL;
}
- if ( ctxt.cr4 & HVM_CR4_GUEST_RESERVED_BITS )
+ if ( ctxt.cr4 & rsv_bits )
{
gdprintk(XENLOG_ERR, "HVM restore: bad CR4 0x%"PRIx64"\n",
ctxt.cr4);
@@ -1243,8 +1248,12 @@ int hvm_set_cr4(unsigned long value)
{
struct vcpu *v = current;
unsigned long old_cr;
-
- if ( value & HVM_CR4_GUEST_RESERVED_BITS )
+ unsigned long rsv_bits = HVM_CR4_GUEST_RESERVED_BITS;
+
+ if ( !is_nestedhvm(v->domain) ||
+ boot_cpu_data.x86_vendor == X86_VENDOR_AMD )
+ rsv_bits |= X86_CR4_VMXE;
+ if ( value & rsv_bits )
{
HVM_DBG_LOG(DBG_LEVEL_1,
"Guest attempts to set reserved bit in CR4: %lx",
diff -r 1385b15e168f xen/include/asm-x86/hvm/hvm.h
--- a/xen/include/asm-x86/hvm/hvm.h Wed Oct 06 17:38:15 2010 +0100
+++ b/xen/include/asm-x86/hvm/hvm.h Fri Oct 08 10:46:35 2010 +0800
@@ -291,7 +291,8 @@ static inline int hvm_do_pmu_interrupt(s
X86_CR4_DE | X86_CR4_PSE | X86_CR4_PAE | \
X86_CR4_MCE | X86_CR4_PGE | X86_CR4_PCE | \
X86_CR4_OSFXSR | X86_CR4_OSXMMEXCPT | \
- (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))))
+ (cpu_has_xsave ? X86_CR4_OSXSAVE : 0))) | \
+ X86_CR4_VMXE)
/* These exceptions must always be intercepted. */
#define HVM_TRAP_MASK ((1U << TRAP_machine_check) | (1U << TRAP_invalid_op))
[-- Attachment #4: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: Slow link/Capacity changed + Kernel OOPS... possible hardware issues, ideas?
From: C Anthony Risinger @ 2010-10-08 4:34 UTC (permalink / raw)
To: Chris Ball; +Cc: linux-btrfs
In-Reply-To: <m37hhtmku4.fsf@pullcord.laptop.org>
On Thu, Oct 7, 2010 at 10:20 PM, Chris Ball <cjb@laptop.org> wrote:
> Hi,
>
> =A0 > can anyone point me in the right direction? =A0it looks like ma=
ybe
> =A0 > the SSD is failing to me (all the "slow link" and "capacity
> =A0 > changed to 0" stuff), but i really don't know. =A0i knew there =
was
> =A0 > a reason they were selling these things cheap on Newegg!!!
>
> Yes, the read errors are coming all the way up from the hardware;
> I don't think this is a btrfs problem.
>
> There's not much btrfs could do to help, except (over time) grow
> to handle I/O errors without BUG()ing out.
hmm, i'll have to keep playing with it i guess. /dev/sda1 is a ext2
boot partition; i tar + ssh'ed that several times to my other machine
without problems... i thought it would trip an issue if it really was
hardware, but it didn't, even after 30+ times.
i'll try to reinstall i guess, unless anyone has other input. i'll
probably just have to ask ASUS to replace it, because i don't think
i've even had it 6mo yet...
>:-O
thanks,
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Tips on debugging suspend/resume failure
From: Chris Ball @ 2010-10-08 4:37 UTC (permalink / raw)
To: Man Spaz; +Cc: linux-kernel
In-Reply-To: <103889.39682.qm@web120217.mail.ne1.yahoo.com>
Hi,
> But the question remains, how to get debug out? Is there a dmesg
> buffer that can persist if DRAM is being refreshed perhaps?
The most promising attempts involve using GPU RAM to store dmesg,
since it persists across a soft reboot and isn't going to be
overwritten as long as you get to it before the video driver does
after the crash. (Which you can ensure by blacklisting the driver.)
> Is there another way to skin this mongrel, I mean cat?
The most basic tool is probably CONFIG_PM_TRACE, which uses the
real-time clock to store a signature for the last driver to init
during suspend/resume -- after the crash, the kernel will interpret
the RTC hash it placed to give you a hint as to what might be failing.
The real answer, though, is to just keep trying to find any way at all
to get usable serial output, including by finding a different machine
with the same problem that has a serial port.
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* empty filter on FORWARD chain with rp_filter means safe right?
From: Scott Mcdermott @ 2010-10-08 4:31 UTC (permalink / raw)
To: netfilter
Hello,
I encountered a system today with two attached
networks, one public and the other RFC1918. The box
had ip_foward=1, FORWARD chain empty, policy ACCEPT.
rp_filter was set on both the interfaces.
Now if I were somewhere off the public interface, but
many hops away, there is no possible way to get packets
to the RFC1918 side of the box is there? Because I
have no way to actually route the packets to the
gateway with destination addresses on the far side. So
actually this box is safe from malicious activity, even
though there is an ACCEPT policy on FORWARD and it's
set with routing enabled. Is this correct?
Now if instead I have control of a station on the same
segment as the gateway's public interface, or if I
control routers in-between and can set up routes to get
packets to the box with the internal IPs as
destinations, then it's a different story. But in the
common case of having ISPs in between (which will drop
my packets with RFC1918 destinations), it's not
possible to get packets to the gateway's internal
network except if they NAT some of them for me.
Please help me to see if my understanding is correct.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.