Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-09-04 Thread Jan Beulich
>>> On 03.09.13 at 20:30, "K. Y. Srinivasan"  wrote:
> @@ -76,6 +80,26 @@ static void __init ms_hyperv_init_platform(void)
>   printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
>  ms_hyperv.features, ms_hyperv.hints);
>  
> + if (ms_hyperv.features & HV_X64_MSR_APIC_FREQUENCY_AVAILABLE) {
> + /*
> +  * Get the APIC frequency.
> +  */
> + rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
> + hv_lapic_frequency /= HZ;
> + lapic_timer_frequency = hv_lapic_frequency;
> + printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
> + lapic_timer_frequency);
> +
> + /*
> +  * On Hyper-V, when we are booting off an EFI firmware stack,
> +  * we do not have many legacy devices including PIC, PIT etc.
> +  */
> + if (efi_enabled(EFI_BOOT)) {
> + printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
> + legacy_pic = &null_legacy_pic;
> + }

And this check is really connected to the feature check around the
whole block, rather than being independent? (I'd also think that
this latter message would suffice to be KERN_DEBUG).

Jan

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 3/4] staging: et131x: Whitespace changes, cat some spilt lines

2013-09-04 Thread Dan Carpenter
Sorry, this is still in my postponed messages folder.  I meant to send
it earlier.

On Mon, Sep 02, 2013 at 10:23:21PM +0100, Mark Einon wrote:
> Ignoring checkpatch for some lines - now just over 80 chars, but much
> more readable.
> 

The person who "fixed" these long lines, did it in the wrong way, yes.
But we always apply those because it's the easiest way and you can't
fight against checkpatch.pl.  If we go back to long lines, we'll just
immediately apply another "break the long lines up" patch from some
newbie who doesn't know any better.

We need to fix it in the right way instead of re-introducing checkpatch
warnings.

> Signed-off-by: Mark Einon 
> ---
>  drivers/staging/et131x/et131x.c |  120 
> +--
>  1 file changed, 40 insertions(+), 80 deletions(-)
> 
> diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
> index a8f7cd7..55a6d59 100644
> --- a/drivers/staging/et131x/et131x.c
> +++ b/drivers/staging/et131x/et131x.c
> @@ -872,8 +872,8 @@ static void et131x_tx_dma_enable(struct et131x_adapter 
> *adapter)
>   /* Setup the transmit dma configuration register for normal
>* operation
>*/
> - writel(ET_TXDMA_SNGL_EPKT|(PARM_DMA_CACHE_DEF << ET_TXDMA_CACHE_SHIFT),
> - &adapter->regs->txdma.csr);
> + writel(ET_TXDMA_SNGL_EPKT | (PARM_DMA_CACHE_DEF << 
> ET_TXDMA_CACHE_SHIFT),

PARM_DMA_CACHE_DEF is a poorly chosen name.  It is too generic, it's too
long and it's misleading.  Also it is zero so this line is partly a
no-op.

> + &adapter->regs->txdma.csr);
>  }
>  
>  static inline void add_10bit(u32 *v, int n)
> @@ -978,12 +978,10 @@ static void et1310_config_mac_regs2(struct 
> et131x_adapter *adapter)
>   }
>  
>   /* We need to enable Rx/Tx */
> - cfg1 |= ET_MAC_CFG1_RX_ENABLE | ET_MAC_CFG1_TX_ENABLE |
> - ET_MAC_CFG1_TX_FLOW;
> + cfg1 |= ET_MAC_CFG1_RX_ENABLE | ET_MAC_CFG1_TX_ENABLE | 
> ET_MAC_CFG1_TX_FLOW;

Is it possible to choose shorter names?  If the names were each 2
characters shorter than this would fit.  I haven't really understood why
there are two configurations.  Why would you choose one configuration
as opposed to the other?  What I'm saying is that the naming is unclear.

>   /* Initialize loop back to off */
>   cfg1 &= ~(ET_MAC_CFG1_LOOPBACK | ET_MAC_CFG1_RX_FLOW);
> - if (adapter->flowcontrol == FLOW_RXONLY ||
> - adapter->flowcontrol == FLOW_BOTH)
> + if (adapter->flowcontrol == FLOW_RXONLY || adapter->flowcontrol == 
> FLOW_BOTH)
>   cfg1 |= ET_MAC_CFG1_RX_FLOW;

This should be:

if (adapter->flowcontrol == FLOW_RXONLY ||
adapter->flowcontrol == FLOW_BOTH)
cfg1 |= ET_MAC_CFG1_RX_FLOW;
writel(cfg1, &mac->cfg1);

When it's aligned like that it's fine and perfectly readable.

>   writel(cfg1, &mac->cfg1);
>  
> @@ -1807,8 +1805,7 @@ static void et131x_config_rx_dma_regs(struct 
> et131x_adapter *adapter)
>   writel(0, &rx_dma->psr_full_offset);
>  
>   psr_num_des = readl(&rx_dma->psr_num_des) & ET_RXDMA_PSR_NUM_DES_MASK;
> - writel((psr_num_des * LO_MARK_PERCENT_FOR_PSR) / 100,
> -&rx_dma->psr_min_des);
> + writel((psr_num_des * LO_MARK_PERCENT_FOR_PSR) / 100, 
> &rx_dma->psr_min_des);

The original is fine and it's already aligned properly.

>  
>   spin_lock_irqsave(&adapter->rcv_lock, flags);
>  
> @@ -1837,10 +1834,8 @@ static void et131x_config_rx_dma_regs(struct 
> et131x_adapter *adapter)
>   }
>  
>   /* Now's the best time to initialize FBR contents */

Do this:

struct fbr_lookup *fbr;

fbr = rx_local->fbr[id];

Then replace all the instances of "rx_local->fbr[id]" and it solves the
problems in this function.

> - fbr_entry =
> - (struct fbr_desc *) rx_local->fbr[id]->ring_virtaddr;
> - for (entry = 0;
> -  entry < rx_local->fbr[id]->num_entries; entry++) {
> + fbr_entry = (struct fbr_desc *) 
> rx_local->fbr[id]->ring_virtaddr;
> + for (entry = 0; entry < rx_local->fbr[id]->num_entries; 
> entry++) {
>   fbr_entry->addr_hi = rx_local->fbr[id]->bus_high[entry];
>   fbr_entry->addr_lo = rx_local->fbr[id]->bus_low[entry];
>   fbr_entry->word2 = entry;
> @@ -1850,10 +1845,8 @@ static void et131x_config_rx_dma_regs(struct 
> et131x_adapter *adapter)
>   /* Set the address and parameters of Free buffer ring 1 and 0
>* into the 1310's registers
>*/
> - writel(upper_32_bits(rx_local->fbr[id]->ring_physaddr),
> -base_hi);
> - writel(lower_32_bits(rx_local->fbr[id]->ring_physaddr),
> -base_lo);
> + writel(upper_32_bits(rx_local->fbr[i

Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-09-04 Thread Gleb Natapov
On Tue, Sep 03, 2013 at 11:30:23AM -0700, K. Y. Srinivasan wrote:
> Hyper-V supports a mechanism for retrieving the local APIC frequency.Use this 
> and bypass
> the calibration code in the kernel. This would allow us to boot the Linux 
> kernel as a
> "modern VM" on Hyper-V where many of the legacy devices (such as PIT) are not 
> emulated.
> 
> I would like to thank Olaf Hering , Jan Beulich 
>  and
> H. Peter Anvin  for their help in this effort.
> 
> In this version of the patch, I have addressed Jan's comments.
> 
> Signed-off-by: K. Y. Srinivasan 
> ---
>  arch/x86/include/uapi/asm/hyperv.h |   19 +++
>  arch/x86/kernel/cpu/mshyperv.c |   24 
>  2 files changed, 43 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/include/uapi/asm/hyperv.h 
> b/arch/x86/include/uapi/asm/hyperv.h
> index b80420b..b8f1c01 100644
> --- a/arch/x86/include/uapi/asm/hyperv.h
> +++ b/arch/x86/include/uapi/asm/hyperv.h
> @@ -27,6 +27,19 @@
>  #define HV_X64_MSR_VP_RUNTIME_AVAILABLE  (1 << 0)
>  /* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
>  #define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE  (1 << 1)
> +
> +/*
> + * There is a single feature flag that signifies the presence of the MSR
> + * that can be used to retrieve both the local APIC Timer frequency as
> + * well as the TSC frequency.
> + */
> +
> +/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is available */
> +#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 << 11)
> +
> +/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
> +#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 << 11)
> +
>  /*
>   * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
>   * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available
> @@ -136,6 +149,12 @@
>  /* MSR used to read the per-partition time reference counter */
>  #define HV_X64_MSR_TIME_REF_COUNT0x4020
>  
> +/* MSR used to retrieve the TSC frequency */
> +#define HV_X64_MSR_TSC_FREQUENCY 0x4022
> +
You do not use this MSR in the patch, but in general how it suppose to
work during migration if host TSC frequency changes?

> +/* MSR used to retrieve the local APIC timer frequency */
> +#define HV_X64_MSR_APIC_FREQUENCY0x4023
> +
>  /* Define the virtual APIC registers */
>  #define HV_X64_MSR_EOI   0x4070
>  #define HV_X64_MSR_ICR   0x4071
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 71a39f3..b3dc639 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -23,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct ms_hyperv_info ms_hyperv;
>  EXPORT_SYMBOL_GPL(ms_hyperv);
> @@ -67,6 +69,8 @@ static struct clocksource hyperv_cs = {
>  
>  static void __init ms_hyperv_init_platform(void)
>  {
> + u64 hv_lapic_frequency;
> +
>   /*
>* Extract the features and hints
>*/
> @@ -76,6 +80,26 @@ static void __init ms_hyperv_init_platform(void)
>   printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
>  ms_hyperv.features, ms_hyperv.hints);
>  
> + if (ms_hyperv.features & HV_X64_MSR_APIC_FREQUENCY_AVAILABLE) {
> + /*
> +  * Get the APIC frequency.
> +  */
> + rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
> + hv_lapic_frequency /= HZ;
> + lapic_timer_frequency = hv_lapic_frequency;
> + printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
> + lapic_timer_frequency);
> +
> + /*
> +  * On Hyper-V, when we are booting off an EFI firmware stack,
> +  * we do not have many legacy devices including PIC, PIT etc.
> +  */
> + if (efi_enabled(EFI_BOOT)) {
> + printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
> + legacy_pic = &null_legacy_pic;
> + }
> + }
> +
>   if (ms_hyperv.features & HV_X64_MSR_TIME_REF_COUNT_AVAILABLE)
>   clocksource_register_hz(&hyperv_cs, NSEC_PER_SEC/100);
>  }
> -- 
> 1.7.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

--
Gleb.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 4/5] Staging/iio/adc/touchscreen/MXS: add interrupt driven touch detection

2013-09-04 Thread Juergen Beisert
For battery driven systems it is a very bad idea to collect the touchscreen
data within a kernel busy loop.

This change uses the features of the hardware to delay and accumulate samples in
hardware to avoid a high interrupt and CPU load.

Note: this is only tested on a i.MX23 SoC yet.

Signed-off-by: Juergen Beisert 
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut 
CC: Fabio Estevam 
CC: Jonathan Cameron 
---
 drivers/staging/iio/adc/mxs-lradc.c | 609 
 1 file changed, 542 insertions(+), 67 deletions(-)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
b/drivers/staging/iio/adc/mxs-lradc.c
index 681ffd4..9462af0 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -129,6 +129,17 @@ enum mxs_lradc_ts {
MXS_LRADC_TOUCHSCREEN_5WIRE,
 };
 
+/*
+ * Touchscreen handling
+ */
+enum lradc_ts_plate {
+   LRADC_TOUCH = 0,
+   LRADC_SAMPLE_X,
+   LRADC_SAMPLE_Y,
+   LRADC_SAMPLE_PRESSURE,
+   LRADC_SAMPLE_VALID,
+};
+
 struct mxs_lradc {
struct device   *dev;
void __iomem*base;
@@ -169,13 +180,25 @@ struct mxs_lradc {
 #define CHAN_MASK_TOUCHSCREEN_4WIRE(0xf << 2)
 #define CHAN_MASK_TOUCHSCREEN_5WIRE(0x1f << 2)
enum mxs_lradc_ts   use_touchscreen;
-   boolstop_touchscreen;
booluse_touchbutton;
 
struct input_dev*ts_input;
struct work_struct  ts_work;
 
enum mxs_lradc_id   soc;
+   enum lradc_ts_plate cur_plate; /* statemachine */
+   boolts_valid;
+   unsignedts_x_pos;
+   unsignedts_y_pos;
+   unsignedts_pressure;
+
+   /* handle touchscreen's physical behaviour */
+   /* samples per coordinate */
+   unsignedover_sample_cnt;
+   /* time clocks between samples */
+   unsignedover_sample_delay;
+   /* time in clocks to wait after the plates where switched */
+   unsignedsettling_delay;
 };
 
 #defineLRADC_CTRL0 0x00
@@ -227,19 +250,33 @@ struct mxs_lradc {
 #defineLRADC_CH_ACCUMULATE (1 << 29)
 #defineLRADC_CH_NUM_SAMPLES_MASK   (0x1f << 24)
 #defineLRADC_CH_NUM_SAMPLES_OFFSET 24
+#defineLRADC_CH_NUM_SAMPLES(x) \
+   ((x) << LRADC_CH_NUM_SAMPLES_OFFSET)
 #defineLRADC_CH_VALUE_MASK 0x3
 #defineLRADC_CH_VALUE_OFFSET   0
 
 #defineLRADC_DELAY(n)  (0xd0 + (0x10 * (n)))
 #defineLRADC_DELAY_TRIGGER_LRADCS_MASK (0xff << 24)
 #defineLRADC_DELAY_TRIGGER_LRADCS_OFFSET   24
+#defineLRADC_DELAY_TRIGGER(x) \
+   (((x) << LRADC_DELAY_TRIGGER_LRADCS_OFFSET) & \
+   LRADC_DELAY_TRIGGER_LRADCS_MASK)
 #defineLRADC_DELAY_KICK(1 << 20)
 #defineLRADC_DELAY_TRIGGER_DELAYS_MASK (0xf << 16)
 #defineLRADC_DELAY_TRIGGER_DELAYS_OFFSET   16
+#defineLRADC_DELAY_TRIGGER_DELAYS(x) \
+   (((x) << LRADC_DELAY_TRIGGER_DELAYS_OFFSET) & \
+   LRADC_DELAY_TRIGGER_DELAYS_MASK)
 #defineLRADC_DELAY_LOOP_COUNT_MASK (0x1f << 11)
 #defineLRADC_DELAY_LOOP_COUNT_OFFSET   11
+#defineLRADC_DELAY_LOOP(x) \
+   (((x) << LRADC_DELAY_LOOP_COUNT_OFFSET) & \
+   LRADC_DELAY_LOOP_COUNT_MASK)
 #defineLRADC_DELAY_DELAY_MASK  0x7ff
 #defineLRADC_DELAY_DELAY_OFFSET0
+#defineLRADC_DELAY_DELAY(x) \
+   (((x) << LRADC_DELAY_DELAY_OFFSET) & \
+   LRADC_DELAY_DELAY_MASK)
 
 #defineLRADC_CTRL4 0x140
 #defineLRADC_CTRL4_LRADCSELECT_MASK(n) (0xf << ((n) * 4))
@@ -248,6 +285,466 @@ struct mxs_lradc {
 #define LRADC_RESOLUTION   12
 #define LRADC_SINGLE_SAMPLE_MASK   ((1 << LRADC_RESOLUTION) - 1)
 
+static bool mxs_lradc_check_touch_event(struct mxs_lradc *lradc)
+{
+   return !!(readl(lradc->base + LRADC_STATUS) &
+   LRADC_STATUS_TOUCH_DETECT_RAW);
+}
+
+static void mxs_lradc_setup_ts_channel(struct mxs_lradc *lradc, unsigned ch)
+{
+   /*
+* prepare for oversampling conversion
+*
+* from the datasheet:
+* "The ACCUMULATE bit in the appropriate channel register
+* HW_LRADC_CHn must be set to 1 if NUM_SAMPLES is greater then 0;
+* otherwise, the IRQs will not fire."
+*/
+   writel(LRADC_CH_ACCUMULATE 

[PATCH 2/5] Staging/iio/adc/touchscreen/MXS: separate i.MX28 specific register bits

2013-09-04 Thread Juergen Beisert
In order to support i.MX23 and i.MX28 within one driver we need to separate the
register definitions which differ in both SoC variants.

Signed-off-by: Juergen Beisert 
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut 
CC: Fabio Estevam 
CC: Jonathan Cameron 
---
 drivers/staging/iio/adc/mxs-lradc.c | 60 -
 1 file changed, 32 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
b/drivers/staging/iio/adc/mxs-lradc.c
index dffca90..00e0c29 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -179,24 +179,28 @@ struct mxs_lradc {
 };
 
 #defineLRADC_CTRL0 0x00
-#defineLRADC_CTRL0_TOUCH_DETECT_ENABLE (1 << 23)
-#defineLRADC_CTRL0_TOUCH_SCREEN_TYPE   (1 << 22)
-#defineLRADC_CTRL0_YNNSW   /* YM */(1 << 21)
-#defineLRADC_CTRL0_YPNSW   /* YP */(1 << 20)
-#defineLRADC_CTRL0_YPPSW   /* YP */(1 << 19)
-#defineLRADC_CTRL0_XNNSW   /* XM */(1 << 18)
-#defineLRADC_CTRL0_XNPSW   /* XM */(1 << 17)
-#defineLRADC_CTRL0_XPPSW   /* XP */(1 << 16)
-#defineLRADC_CTRL0_PLATE_MASK  (0x3f << 16)
+# define LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE  (1 << 23)
+# define LRADC_CTRL0_MX28_TOUCH_SCREEN_TYPE(1 << 22)
+# define LRADC_CTRL0_MX28_YNNSW/* YM */(1 << 21)
+# define LRADC_CTRL0_MX28_YPNSW/* YP */(1 << 20)
+# define LRADC_CTRL0_MX28_YPPSW/* YP */(1 << 19)
+# define LRADC_CTRL0_MX28_XNNSW/* XM */(1 << 18)
+# define LRADC_CTRL0_MX28_XNPSW/* XM */(1 << 17)
+# define LRADC_CTRL0_MX28_XPPSW/* XP */(1 << 16)
+
+#defineLRADC_CTRL0_MX28_PLATE_MASK \
+   LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
+   LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
+   LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW
 
 #defineLRADC_CTRL1 0x10
 #defineLRADC_CTRL1_TOUCH_DETECT_IRQ_EN (1 << 24)
 #defineLRADC_CTRL1_LRADC_IRQ_EN(n) (1 << ((n) + 16))
-#defineLRADC_CTRL1_LRADC_IRQ_EN_MASK   (0x1fff << 16)
+#defineLRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK  (0x1fff << 16)
 #defineLRADC_CTRL1_LRADC_IRQ_EN_OFFSET 16
 #defineLRADC_CTRL1_TOUCH_DETECT_IRQ(1 << 8)
 #defineLRADC_CTRL1_LRADC_IRQ(n)(1 << (n))
-#defineLRADC_CTRL1_LRADC_IRQ_MASK  0x1fff
+#defineLRADC_CTRL1_MX28_LRADC_IRQ_MASK 0x1fff
 #defineLRADC_CTRL1_LRADC_IRQ_OFFSET0
 
 #defineLRADC_CTRL2 0x20
@@ -264,7 +268,7 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
 * Virtual channel 0 is always used here as the others are always not
 * used if doing raw sampling.
 */
-   writel(LRADC_CTRL1_LRADC_IRQ_EN_MASK,
+   writel(LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
 
@@ -319,9 +323,9 @@ static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
uint32_t reg;
 
/* Enable touch detection. */
-   writel(LRADC_CTRL0_PLATE_MASK,
+   writel(LRADC_CTRL0_MX28_PLATE_MASK,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
-   writel(LRADC_CTRL0_TOUCH_DETECT_ENABLE,
+   writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
 
msleep(LRADC_TS_SAMPLE_DELAY_MS);
@@ -367,21 +371,21 @@ static int32_t mxs_lradc_ts_sample(struct mxs_lradc 
*lradc,
 */
switch (plate) {
case LRADC_SAMPLE_X:
-   ctrl0 = LRADC_CTRL0_XPPSW | LRADC_CTRL0_XNNSW;
+   ctrl0 = LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
chan = 3;
break;
case LRADC_SAMPLE_Y:
-   ctrl0 = LRADC_CTRL0_YPPSW | LRADC_CTRL0_YNNSW;
+   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
chan = 4;
break;
case LRADC_SAMPLE_PRESSURE:
-   ctrl0 = LRADC_CTRL0_YPPSW | LRADC_CTRL0_XNNSW;
+   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW;
chan = 5;
break;
}
 
if (change) {
-   writel(LRADC_CTRL0_PLATE_MASK,
+   writel(LRADC_CTRL0_MX28_PLATE_MASK,
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
writel(ctrl0, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
 
@@ -442,7 +446,7 @@ static void mxs_lradc_ts_work(struct work_struct *ts_work)
 
while (mxs_lradc_ts_touched(

[PATCH 1/5] Staging/iio/adc/touchscreen/MXS: distinguish i.MX23's and i.MX28's LRADC

2013-09-04 Thread Juergen Beisert
The LRADC units in i.MX23 and i.MX28 differ and we need to distinguish both
SoC variants in order to make the touchscreen work on i.MX23

Signed-off-by: Juergen Beisert 
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut 
CC: Fabio Estevam 
CC: Jonathan Cameron 
---
 drivers/staging/iio/adc/mxs-lradc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
b/drivers/staging/iio/adc/mxs-lradc.c
index a08c173..dffca90 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -174,6 +174,8 @@ struct mxs_lradc {
 
struct input_dev*ts_input;
struct work_struct  ts_work;
+
+   enum mxs_lradc_id   soc;
 };
 
 #defineLRADC_CTRL0 0x00
@@ -920,6 +922,7 @@ static int mxs_lradc_probe(struct platform_device *pdev)
}
 
lradc = iio_priv(iio);
+   lradc->soc = (enum mxs_lradc_id)of_id->data;
 
/* Grab the memory area */
iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
1.8.4.rc3

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 5/5] Staging/iio/adc/touchscreen/MXS: Remove old touchscreen detection implementation

2013-09-04 Thread Juergen Beisert
Signed-off-by: Juergen Beisert 
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut 
CC: Fabio Estevam 
CC: Jonathan Cameron 
---
 drivers/staging/iio/adc/mxs-lradc.c | 193 
 1 file changed, 193 deletions(-)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
b/drivers/staging/iio/adc/mxs-lradc.c
index 9462af0..f81d827 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -183,7 +183,6 @@ struct mxs_lradc {
booluse_touchbutton;
 
struct input_dev*ts_input;
-   struct work_struct  ts_work;
 
enum mxs_lradc_id   soc;
enum lradc_ts_plate cur_plate; /* statemachine */
@@ -821,196 +820,6 @@ static const struct iio_info mxs_lradc_iio_info = {
.read_raw   = mxs_lradc_read_raw,
 };
 
-static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
-{
-   uint32_t reg;
-
-   /* Enable touch detection. */
-   if (lradc->soc == IMX28_LRADC) {
-   writel(LRADC_CTRL0_MX28_PLATE_MASK,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
-   writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
-   } else {
-   writel(LRADC_CTRL0_MX23_PLATE_MASK,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
-   writel(LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
-   }
-
-   msleep(LRADC_TS_SAMPLE_DELAY_MS);
-
-   reg = readl(lradc->base + LRADC_STATUS);
-
-   return reg & LRADC_STATUS_TOUCH_DETECT_RAW;
-}
-
-static int32_t mxs_lradc_ts_sample(struct mxs_lradc *lradc,
-   enum lradc_ts_plate plate, int change)
-{
-   unsigned long delay, jiff;
-   uint32_t reg, ctrl0 = 0, chan = 0;
-   /* The touchscreen always uses CTRL4 slot #7. */
-   const uint8_t slot = 7;
-   uint32_t val;
-
-   /*
-* There are three correct configurations of the controller sampling
-* the touchscreen, each of these configuration provides different
-* information from the touchscreen.
-*
-* The following table describes the sampling configurations:
-* +-+---+---+---+
-* | Wire \ Axis |   X   |   Y   |   Z   |
-* +-+---+---+
-* |   X+ (CH2)  |   HI  |   TS  |   TS  |
-* +-+---+---+---+
-* |   X- (CH4)  |   LO  |   SH  |   HI  |
-* +-+---+---+---+
-* |   Y+ (CH3)  |   SH  |   HI  |   HI  |
-* +-+---+---+---+
-* |   Y- (CH5)  |   TS  |   LO  |   SH  |
-* +-+---+---+---+
-*
-* HI ... strong '1'  ; LO ... strong '0'
-* SH ... sample here ; TS ... tri-state
-*
-* There are a few other ways of obtaining the Z coordinate
-* (aka. pressure), but the one in the table seems to be the
-* most reliable one.
-*/
-   switch (plate) {
-   case LRADC_SAMPLE_X:
-   if (lradc->soc == IMX28_LRADC)
-   ctrl0 = LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
-   else
-   ctrl0 = LRADC_CTRL0_MX23_XP | LRADC_CTRL0_MX23_XM;
-   chan = 3;
-   break;
-   case LRADC_SAMPLE_Y:
-   if (lradc->soc == IMX28_LRADC)
-   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
-   else
-   ctrl0 = LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_YM;
-   chan = 4;
-   break;
-   case LRADC_SAMPLE_PRESSURE:
-   if (lradc->soc == IMX28_LRADC)
-   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW;
-   else
-   ctrl0 = LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_XM;
-   chan = 5;
-   break;
-   }
-
-   if (change) {
-   if (lradc->soc == IMX28_LRADC)
-   writel(LRADC_CTRL0_MX28_PLATE_MASK,
-   lradc->base + LRADC_CTRL0 + 
STMP_OFFSET_REG_CLR);
-   else
-   writel(LRADC_CTRL0_MX23_PLATE_MASK,
-   lradc->base + LRADC_CTRL0 + 
STMP_OFFSET_REG_CLR);
-
-   writel(ctrl0, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
-
-   writel(LRADC_CTRL4_LRADCSELECT_MASK(slot),
-   lradc->base + LRADC_CTRL4 + STMP_OFFSET_REG_CLR);
-   writel(chan << LRADC_CTRL4_LRADCSELECT_OFFSET(slot),
-   lradc->base + LRADC_CTRL4 + STMP_OFFSET_REG_SET);
-   }
-
-   writel(0x, lradc->base + LRADC_CH(slot) + STMP_OFF

[PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver

2013-09-04 Thread Juergen Beisert
Distinguish i.MX23 and i.MX28 at runtime and do the same for both SoC at least
for the 4 wire touchscreen.

Signed-off-by: Juergen Beisert 
CC: linux-arm-ker...@lists.infradead.org
CC: de...@driverdev.osuosl.org
CC: Marek Vasut 
CC: Fabio Estevam 
CC: Jonathan Cameron 
---
 drivers/staging/iio/adc/mxs-lradc.c | 134 +++-
 1 file changed, 102 insertions(+), 32 deletions(-)

diff --git a/drivers/staging/iio/adc/mxs-lradc.c 
b/drivers/staging/iio/adc/mxs-lradc.c
index 00e0c29..681ffd4 100644
--- a/drivers/staging/iio/adc/mxs-lradc.c
+++ b/drivers/staging/iio/adc/mxs-lradc.c
@@ -188,19 +188,33 @@ struct mxs_lradc {
 # define LRADC_CTRL0_MX28_XNPSW/* XM */(1 << 17)
 # define LRADC_CTRL0_MX28_XPPSW/* XP */(1 << 16)
 
+# define LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE  (1 << 20)
+# define LRADC_CTRL0_MX23_YM   (1 << 19)
+# define LRADC_CTRL0_MX23_XM   (1 << 18)
+# define LRADC_CTRL0_MX23_YP   (1 << 17)
+# define LRADC_CTRL0_MX23_XP   (1 << 16)
+
 #defineLRADC_CTRL0_MX28_PLATE_MASK \
+   LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE | \
LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW
 
+#defineLRADC_CTRL0_MX23_PLATE_MASK \
+   LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE | \
+   LRADC_CTRL0_MX23_YM | LRADC_CTRL0_MX23_XM | \
+   LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_XP
+
 #defineLRADC_CTRL1 0x10
 #defineLRADC_CTRL1_TOUCH_DETECT_IRQ_EN (1 << 24)
 #defineLRADC_CTRL1_LRADC_IRQ_EN(n) (1 << ((n) + 16))
 #defineLRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK  (0x1fff << 16)
+#defineLRADC_CTRL1_MX23_LRADC_IRQ_EN_MASK  (0x01ff << 16)
 #defineLRADC_CTRL1_LRADC_IRQ_EN_OFFSET 16
 #defineLRADC_CTRL1_TOUCH_DETECT_IRQ(1 << 8)
 #defineLRADC_CTRL1_LRADC_IRQ(n)(1 << (n))
 #defineLRADC_CTRL1_MX28_LRADC_IRQ_MASK 0x1fff
+#defineLRADC_CTRL1_MX23_LRADC_IRQ_MASK 0x01ff
 #defineLRADC_CTRL1_LRADC_IRQ_OFFSET0
 
 #defineLRADC_CTRL2 0x20
@@ -268,8 +282,9 @@ static int mxs_lradc_read_raw(struct iio_dev *iio_dev,
 * Virtual channel 0 is always used here as the others are always not
 * used if doing raw sampling.
 */
-   writel(LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
-   lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
+   if (lradc->soc == IMX28_LRADC)
+   writel(LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK,
+   lradc->base + LRADC_CTRL1 + STMP_OFFSET_REG_CLR);
writel(0xff, lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
 
/* Clean the slot's previous content, then set new one. */
@@ -323,10 +338,17 @@ static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
uint32_t reg;
 
/* Enable touch detection. */
-   writel(LRADC_CTRL0_MX28_PLATE_MASK,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
-   writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
-   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
+   if (lradc->soc == IMX28_LRADC) {
+   writel(LRADC_CTRL0_MX28_PLATE_MASK,
+   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
+   writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
+   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
+   } else {
+   writel(LRADC_CTRL0_MX23_PLATE_MASK,
+   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
+   writel(LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE,
+   lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
+   }
 
msleep(LRADC_TS_SAMPLE_DELAY_MS);
 
@@ -371,22 +393,36 @@ static int32_t mxs_lradc_ts_sample(struct mxs_lradc 
*lradc,
 */
switch (plate) {
case LRADC_SAMPLE_X:
-   ctrl0 = LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
+   if (lradc->soc == IMX28_LRADC)
+   ctrl0 = LRADC_CTRL0_MX28_XPPSW | LRADC_CTRL0_MX28_XNNSW;
+   else
+   ctrl0 = LRADC_CTRL0_MX23_XP | LRADC_CTRL0_MX23_XM;
chan = 3;
break;
case LRADC_SAMPLE_Y:
-   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
+   if (lradc->soc == IMX28_LRADC)
+   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_YNNSW;
+   else
+   ctrl0 = LRADC_CTRL0_MX23_YP | LRADC_CTRL0_MX23_YM;
chan = 4;
break;
case LRADC_SAMPLE_PRESSURE:
-   ctrl0 = LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_X

Re: [PATCH 2/5] Staging/iio/adc/touchscreen/MXS: separate i.MX28 specific register bits

2013-09-04 Thread Marek Vasut
Dear Juergen Beisert,

> In order to support i.MX23 and i.MX28 within one driver we need to separate
> the register definitions which differ in both SoC variants.
> 
> Signed-off-by: Juergen Beisert 
> CC: linux-arm-ker...@lists.infradead.org
> CC: de...@driverdev.osuosl.org
> CC: Marek Vasut 
> CC: Fabio Estevam 
> CC: Jonathan Cameron 
> ---
>  drivers/staging/iio/adc/mxs-lradc.c | 60
> - 1 file changed, 32 insertions(+), 28
> deletions(-)
> 
> diff --git a/drivers/staging/iio/adc/mxs-lradc.c
> b/drivers/staging/iio/adc/mxs-lradc.c index dffca90..00e0c29 100644
> --- a/drivers/staging/iio/adc/mxs-lradc.c
> +++ b/drivers/staging/iio/adc/mxs-lradc.c
> @@ -179,24 +179,28 @@ struct mxs_lradc {
>  };
> 
>  #define  LRADC_CTRL0 0x00
> -#define  LRADC_CTRL0_TOUCH_DETECT_ENABLE (1 << 23)
> -#define  LRADC_CTRL0_TOUCH_SCREEN_TYPE   (1 << 22)
> -#define  LRADC_CTRL0_YNNSW   /* YM */(1 << 21)
> -#define  LRADC_CTRL0_YPNSW   /* YP */(1 << 20)
> -#define  LRADC_CTRL0_YPPSW   /* YP */(1 << 19)
> -#define  LRADC_CTRL0_XNNSW   /* XM */(1 << 18)
> -#define  LRADC_CTRL0_XNPSW   /* XM */(1 << 17)
> -#define  LRADC_CTRL0_XPPSW   /* XP */(1 << 16)
> -#define  LRADC_CTRL0_PLATE_MASK  (0x3f << 16)
> +# define LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE(1 << 23)
> +# define LRADC_CTRL0_MX28_TOUCH_SCREEN_TYPE  (1 << 22)
> +# define LRADC_CTRL0_MX28_YNNSW  /* YM */(1 << 21)
> +# define LRADC_CTRL0_MX28_YPNSW  /* YP */(1 << 20)
> +# define LRADC_CTRL0_MX28_YPPSW  /* YP */(1 << 19)
> +# define LRADC_CTRL0_MX28_XNNSW  /* XM */(1 << 18)
> +# define LRADC_CTRL0_MX28_XNPSW  /* XM */(1 << 17)
> +# define LRADC_CTRL0_MX28_XPPSW  /* XP */(1 << 16)

Why do you put this space between # and define?

> +#define  LRADC_CTRL0_MX28_PLATE_MASK \
> + LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
> + LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
> + LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW
> 
>  #define  LRADC_CTRL1 0x10
>  #define  LRADC_CTRL1_TOUCH_DETECT_IRQ_EN (1 << 24)
>  #define  LRADC_CTRL1_LRADC_IRQ_EN(n) (1 << ((n) + 16))
> -#define  LRADC_CTRL1_LRADC_IRQ_EN_MASK   (0x1fff << 16)
> +#define  LRADC_CTRL1_MX28_LRADC_IRQ_EN_MASK  (0x1fff << 16)
>  #define  LRADC_CTRL1_LRADC_IRQ_EN_OFFSET 16
>  #define  LRADC_CTRL1_TOUCH_DETECT_IRQ(1 << 8)
>  #define  LRADC_CTRL1_LRADC_IRQ(n)(1 << (n))
> -#define  LRADC_CTRL1_LRADC_IRQ_MASK  0x1fff
> +#define  LRADC_CTRL1_MX28_LRADC_IRQ_MASK 0x1fff

MIght just be easier to define this as

LRADCIRQ_MASK(id) (((id) == MX23) ? 0x1ff : 0x1fff)

just like the MXS SSP driver does it. Then there won't be so much churn.

[...]

Best regards,
Marek Vasut
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 2/5] Staging/iio/adc/touchscreen/MXS: separate i.MX28 specific register bits

2013-09-04 Thread Dan Carpenter
On Wed, Sep 04, 2013 at 03:01:43PM +0200, Juergen Beisert wrote:
> +#define  LRADC_CTRL0_MX28_PLATE_MASK \
> + LRADC_CTRL0_MX28_YNNSW | LRADC_CTRL0_MX28_YPNSW | \
> + LRADC_CTRL0_MX28_YPPSW | LRADC_CTRL0_MX28_XNNSW | \
> + LRADC_CTRL0_MX28_XNPSW | LRADC_CTRL0_MX28_XPPSW

Put parenthesis are this macro.

regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 5/5] Staging/iio/adc/touchscreen/MXS: Remove old touchscreen detection implementation

2013-09-04 Thread Dan Carpenter
On Wed, Sep 04, 2013 at 03:01:46PM +0200, Juergen Beisert wrote:
> Signed-off-by: Juergen Beisert 
> CC: linux-arm-ker...@lists.infradead.org
> CC: de...@driverdev.osuosl.org
> CC: Marek Vasut 
> CC: Fabio Estevam 
> CC: Jonathan Cameron 
> ---

The change log is missing.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-09-04 Thread KY Srinivasan


> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Wednesday, September 04, 2013 2:40 AM
> To: KY Srinivasan
> Cc: x...@kernel.org; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; t...@linutronix.de; h...@zytor.com;
> jbeul...@suse.com; b...@alien8.de
> Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency
> from the hypervisor
> 
> On Tue, Sep 03, 2013 at 11:30:23AM -0700, K. Y. Srinivasan wrote:
> > Hyper-V supports a mechanism for retrieving the local APIC frequency.Use 
> > this
> and bypass
> > the calibration code in the kernel. This would allow us to boot the Linux 
> > kernel
> as a
> > "modern VM" on Hyper-V where many of the legacy devices (such as PIT) are
> not emulated.
> >
> > I would like to thank Olaf Hering , Jan Beulich
>  and
> > H. Peter Anvin  for their help in this effort.
> >
> > In this version of the patch, I have addressed Jan's comments.
> >
> > Signed-off-by: K. Y. Srinivasan 
> > ---
> >  arch/x86/include/uapi/asm/hyperv.h |   19 +++
> >  arch/x86/kernel/cpu/mshyperv.c |   24 
> >  2 files changed, 43 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/x86/include/uapi/asm/hyperv.h
> b/arch/x86/include/uapi/asm/hyperv.h
> > index b80420b..b8f1c01 100644
> > --- a/arch/x86/include/uapi/asm/hyperv.h
> > +++ b/arch/x86/include/uapi/asm/hyperv.h
> > @@ -27,6 +27,19 @@
> >  #define HV_X64_MSR_VP_RUNTIME_AVAILABLE(1 << 0)
> >  /* Partition Reference Counter (HV_X64_MSR_TIME_REF_COUNT) available*/
> >  #define HV_X64_MSR_TIME_REF_COUNT_AVAILABLE(1 << 1)
> > +
> > +/*
> > + * There is a single feature flag that signifies the presence of the MSR
> > + * that can be used to retrieve both the local APIC Timer frequency as
> > + * well as the TSC frequency.
> > + */
> > +
> > +/* Local APIC timer frequency MSR (HV_X64_MSR_APIC_FREQUENCY) is
> available */
> > +#define HV_X64_MSR_APIC_FREQUENCY_AVAILABLE (1 << 11)
> > +
> > +/* TSC frequency MSR (HV_X64_MSR_TSC_FREQUENCY) is available */
> > +#define HV_X64_MSR_TSC_FREQUENCY_AVAILABLE (1 << 11)
> > +
> >  /*
> >   * Basic SynIC MSRs (HV_X64_MSR_SCONTROL through HV_X64_MSR_EOM
> >   * and HV_X64_MSR_SINT0 through HV_X64_MSR_SINT15) available
> > @@ -136,6 +149,12 @@
> >  /* MSR used to read the per-partition time reference counter */
> >  #define HV_X64_MSR_TIME_REF_COUNT  0x4020
> >
> > +/* MSR used to retrieve the TSC frequency */
> > +#define HV_X64_MSR_TSC_FREQUENCY   0x4022
> > +
> You do not use this MSR in the patch, but in general how it suppose to
> work during migration if host TSC frequency changes?

TSC related migration issues are distinct from how we calibrate the TSC 
frequency. This MSR
allows you to retrieve the TSC frequency without having to do explicit 
calibration.

To address the migration issues; the hypervisor provides additional information 
on the host
that you are running that can be used to compensate for differences in TSC 
across hosts.  

Regards,

K. Y
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


RE: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency from the hypervisor

2013-09-04 Thread KY Srinivasan


> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, September 04, 2013 12:17 AM
> To: KY Srinivasan
> Cc: o...@aepfle.de; b...@alien8.de; a...@canonical.com; x...@kernel.org;
> t...@linutronix.de; de...@linuxdriverproject.org; gre...@linuxfoundation.org;
> jasow...@redhat.com; linux-ker...@vger.kernel.org; h...@zytor.com
> Subject: Re: [PATCH V2 1/1] X86: Hyper-V: Get the local APIC timer frequency
> from the hypervisor
> 
> >>> On 03.09.13 at 20:30, "K. Y. Srinivasan"  wrote:
> > @@ -76,6 +80,26 @@ static void __init ms_hyperv_init_platform(void)
> > printk(KERN_INFO "HyperV: features 0x%x, hints 0x%x\n",
> >ms_hyperv.features, ms_hyperv.hints);
> >
> > +   if (ms_hyperv.features & HV_X64_MSR_APIC_FREQUENCY_AVAILABLE) {
> > +   /*
> > +* Get the APIC frequency.
> > +*/
> > +   rdmsrl(HV_X64_MSR_APIC_FREQUENCY, hv_lapic_frequency);
> > +   hv_lapic_frequency /= HZ;
> > +   lapic_timer_frequency = hv_lapic_frequency;
> > +   printk(KERN_INFO "HyperV: LAPIC Timer Frequency: %#x\n",
> > +   lapic_timer_frequency);
> > +
> > +   /*
> > +* On Hyper-V, when we are booting off an EFI firmware stack,
> > +* we do not have many legacy devices including PIC, PIT etc.
> > +*/
> > +   if (efi_enabled(EFI_BOOT)) {
> > +   printk(KERN_INFO "HyperV: Using null_legacy_pic\n");
> > +   legacy_pic = &null_legacy_pic;
> > +   }
> 
> And this check is really connected to the feature check around the
> whole block, rather than being independent? (I'd also think that
> this latter message would suffice to be KERN_DEBUG).

I felt it was safer to first check for the feature  since if the feature is not
there, we need to calibrate based on PIT. Furthermore, the feature is available
even in legacy environments when we are not booting on an EFI stack.

Regards,

K. Y

> 
> Jan

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 3/5] Staging/iio/adc/touchscreen/MXS: add i.MX23 support to the LRADC driver

2013-09-04 Thread Dan Carpenter
On Wed, Sep 04, 2013 at 03:01:44PM +0200, Juergen Beisert wrote:
> @@ -323,10 +338,17 @@ static int mxs_lradc_ts_touched(struct mxs_lradc *lradc)
>   uint32_t reg;
>  
>   /* Enable touch detection. */
> - writel(LRADC_CTRL0_MX28_PLATE_MASK,
> - lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
> - writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
> - lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
> + if (lradc->soc == IMX28_LRADC) {
> + writel(LRADC_CTRL0_MX28_PLATE_MASK,
> + lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
> + writel(LRADC_CTRL0_MX28_TOUCH_DETECT_ENABLE,
> + lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
> + } else {
> + writel(LRADC_CTRL0_MX23_PLATE_MASK,
> + lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
> + writel(LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE,
> + lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);
> + }

I don't like the way this patch takes the driver and makes every line
an if else statement.  It would be cleaner to do this:

writel(lradc_plate_mask(lradc),
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_CLR);
writel(lradc_touch_detect_enable(lradc),
lradc->base + LRADC_CTRL0 + STMP_OFFSET_REG_SET);

Btw, LRADC_CTRL0_MX23_TOUCH_DETECT_ENABLE just enables the touch screen
to detect touches?  It seems like we could leave the "DETECT_" out of
the name.

Actually it would better yet if there were a function:

static inline void lradc_writel(struct mxs_lradc *lradc, u32 val,
size_t chan, size_t offset)
{
writel(val, lradc->base + chan + offset);
}

That way we could do:

lradc_writel(lradc_enable_touch(lradc), LRADC_CTRL0,
 STMP_OFFSET_REG_SET);

ACTUALLY!  When I look at it now the third argument is almost always
"set", "clear" or "toggle".

So we could do:

static inline void lradc_reg_set(struct mxs_lradc *lradc, u32 val,
size_t chan)
{
writel(val, lradc->base + chan + STMP_OFFSET_REG_SET);
}

So then it would be:

lradc_reg_clear(lradc_plate_mask(lradc), LRADC_CTRL0);
lradc_reg_set(lradc_enable_touch(lradc), LRADC_CTRL0);

I've just changed 11 lines of code down to 2 lines of code by hiding the
if statement in the header file.

Please redo this patch along those lines.

regards,
dan carpenter

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH 1/1] Drivers: hv: vmbus: Terminate vmbus version negotiation on timeout

2013-09-04 Thread K. Y. Srinivasan
commit 666b9adc801ef012612c4e43e0f44b2cdc1979cf terminated vmbus
version negotiation incorrectly. We need to terminate the version
negotiation only if the current negotiation were to timeout.

Signed-off-by: K. Y. Srinivasan 
---
 drivers/hv/connection.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index 8f4743a..936093e 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -195,7 +195,7 @@ int vmbus_connect(void)
 
do {
ret = vmbus_negotiate_version(msginfo, version);
-   if (ret)
+   if (ret == -ETIMEDOUT)
goto cleanup;
 
if (vmbus_connection.conn_state == CONNECTED)
-- 
1.7.4.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH] Staging: comedi: Fix dependencies for drivers misclassified as PCI

2013-09-04 Thread Ben Hutchings
On Mon, 2013-09-02 at 10:34 +0100, Ian Abbott wrote:
> On 2013-09-01 20:42, Ben Hutchings wrote:
> > The Fastwel UNIOxx-5 is a PCI/104 board so put COMEDI_UNIOXX5 under
> > COMEDI_ISA_DRIVERS.
> 
> ITYM a PC/104 board.

Of course.  There were lots of PCIs in this message already so I
couldn't stop after two letters. :-)

> > The PCI-20001C is, surprisingly, an ISA card, so also put
> > COMEDI_II_PCI20KC under COMEDI_ISA_DRIVERS.
> 
> COMEDI_II_PCI20KC has already been moved in Greg's staging-next, so the 
> patch won't apply cleanly there.

OK, I'll rebase this.

Ben.

> > The DIL/Net-PC 1486 is a 486 system, so put COMEDI_SSV_DNP under
> > COMEDI_MISC_DRIVERS and add a dependency on X86_32 || COMPILE_TEST.
> 
> Yes, COMEDI_MISC_DRIVERS will do.
> 
> > Signed-off-by: Ben Hutchings 
> 

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2] Staging: comedi: Fix dependencies for drivers misclassified as PCI

2013-09-04 Thread Ben Hutchings
The Fastwel UNIOxx-5 is a PC/104 board, so put COMEDI_UNIOXX5 under
COMEDI_ISA_DRIVERS.

The DIL/Net-PC 1486 is a 486 system, so put COMEDI_SSV_DNP under
COMEDI_MISC_DRIVERS and add a dependency on X86_32 || COMPILE_TEST.

Signed-off-by: Ben Hutchings 
---
v2: Fix typo in commit message; rebase on staging-next which already had
one of the Kconfig changes

 drivers/staging/comedi/Kconfig | 33 +
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/comedi/Kconfig b/drivers/staging/comedi/Kconfig
index a84aab4..f73287e 100644
--- a/drivers/staging/comedi/Kconfig
+++ b/drivers/staging/comedi/Kconfig
@@ -96,6 +96,15 @@ config COMEDI_SKEL
  To compile this driver as a module, choose M here: the module will be
  called skel.
 
+config COMEDI_SSV_DNP
+   tristate "SSV Embedded Systems DIL/Net-PC support"
+   depends on X86_32 || COMPILE_TEST
+   ---help---
+ Enable support for SSV Embedded Systems DIL/Net-PC
+
+ To compile this driver as a module, choose M here: the module will be
+ called ssv_dnp.
+
 endif # COMEDI_MISC_DRIVERS
 
 menuconfig COMEDI_ISA_DRIVERS
@@ -386,6 +395,14 @@ config COMEDI_DMM32AT
  To compile this driver as a module, choose M here: the module will be
  called dmm32at.
 
+config COMEDI_UNIOXX5
+   tristate "Fastwel UNIOxx-5 analog and digital io board support"
+   ---help---
+ Enable support for Fastwel UNIOxx-5 (analog and digital i/o) boards
+
+ To compile this driver as a module, choose M here: the module will be
+ called unioxx5.
+
 config COMEDI_FL512
tristate "FL512 ISA card support"
---help---
@@ -855,14 +872,6 @@ config COMEDI_DYNA_PCI10XX
  To compile this driver as a module, choose M here: the module will be
  called dyna_pci10xx.
 
-config COMEDI_UNIOXX5
-   tristate "Fastwel UNIOxx-5 analog and digital io board support"
-   ---help---
- Enable support for Fastwel UNIOxx-5 (analog and digital i/o) boards
-
- To compile this driver as a module, choose M here: the module will be
- called unioxx5.
-
 config COMEDI_GSC_HPDI
tristate "General Standards PCI-HPDI32 / PMC-HPDI32 support"
select COMEDI_FC
@@ -1085,14 +1094,6 @@ config COMEDI_S626
  To compile this driver as a module, choose M here: the module will be
  called s626.
 
-config COMEDI_SSV_DNP
-   tristate "SSV Embedded Systems DIL/Net-PC support"
-   ---help---
- Enable support for SSV Embedded Systems DIL/Net-PC
-
- To compile this driver as a module, choose M here: the module will be
- called ssv_dnp.
-
 config COMEDI_MITE
depends on HAS_DMA
tristate



signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH 0/4] [media] Make lirc_bt829 a well-behaved PCI driver

2013-09-04 Thread Ben Hutchings
On Mon, 2013-09-02 at 01:36 +0100, Ben Hutchings wrote:
> I noticed lirc_bt829 didn't have a module device ID table, so I set out
> to fix that and ended up with this series.
> 
> It still appears to do everything else wrong (like reinventing
> i2c-algo-bit) though...
> 
> This is compile-tested only.

On reflection, I think it might be better to leave this driver 'badly
behaved'.  It wants to use registers on a Mach64 VT, which has a
separate kernel framebuffer driver (atyfb) and userland X driver
(mach64).  If this driver is compatible with them now, changing it is
liable to break that.

I'll repost the minor fixes.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 1/4] [media] lirc_bt829: Fix physical address type

2013-09-04 Thread Ben Hutchings
Use phys_addr_t and log format %pa.

Signed-off-by: Ben Hutchings 
---
 drivers/staging/media/lirc/lirc_bt829.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_bt829.c 
b/drivers/staging/media/lirc/lirc_bt829.c
index fa31ee7..9c7be55 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -63,7 +63,7 @@ static bool debug;
} while (0)
 
 static int atir_minor;
-static unsigned long pci_addr_phys;
+static phys_addr_t pci_addr_phys;
 static unsigned char *pci_addr_lin;
 
 static struct lirc_driver atir_driver;
@@ -78,8 +78,7 @@ static struct pci_dev *do_pci_probe(void)
pci_addr_phys = 0;
if (my_dev->resource[0].flags & IORESOURCE_MEM) {
pci_addr_phys = my_dev->resource[0].start;
-   pr_info("memory at 0x%08X\n",
-  (unsigned int)pci_addr_phys);
+   pr_info("memory at %pa\n", &pci_addr_phys);
}
if (pci_addr_phys == 0) {
pr_err("no memory resource ?\n");




signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 2/4] [media] lirc_bt829: Fix iomap and PCI device leaks

2013-09-04 Thread Ben Hutchings
We must call iounmap() and pci_dev_put() when removed and on
the probe failure path.

Signed-off-by: Ben Hutchings 
---
 drivers/staging/media/lirc/lirc_bt829.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_bt829.c 
b/drivers/staging/media/lirc/lirc_bt829.c
index 9c7be55..a61d233 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -82,6 +82,7 @@ static struct pci_dev *do_pci_probe(void)
}
if (pci_addr_phys == 0) {
pr_err("no memory resource ?\n");
+   pci_dev_put(my_dev);
return NULL;
}
} else {
@@ -119,13 +120,16 @@ static void atir_set_use_dec(void *data)
 int init_module(void)
 {
struct pci_dev *pdev;
+   int rc;
 
pdev = do_pci_probe();
if (pdev == NULL)
return -ENODEV;
 
-   if (!atir_init_start())
-   return -ENODEV;
+   if (!atir_init_start()) {
+   rc = -ENODEV;
+   goto err_put_dev;
+   }
 
strcpy(atir_driver.name, "ATIR");
atir_driver.minor   = -1;
@@ -141,17 +145,28 @@ int init_module(void)
atir_minor = lirc_register_driver(&atir_driver);
if (atir_minor < 0) {
pr_err("failed to register driver!\n");
-   return atir_minor;
+   rc = atir_minor;
+   goto err_unmap;
}
dprintk("driver is registered on minor %d\n", atir_minor);
 
return 0;
+
+err_unmap:
+   iounmap(pci_addr_lin);
+err_put_dev:
+   pci_dev_put(pdev);
+   return rc;
 }
 

 void cleanup_module(void)
 {
+   struct pci_dev *pdev = to_pci_dev(atir_driver.dev);
+
lirc_unregister_driver(atir_minor);
+   iounmap(pci_addr_lin);
+   pci_dev_put(pdev);
 }
 





signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 4/4] [media] lirc_bt829: Note in TODO why it can't be a normal PCI driver yet

2013-09-04 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 drivers/staging/media/lirc/TODO | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/staging/media/lirc/TODO b/drivers/staging/media/lirc/TODO
index b6cb593..cbea5d8 100644
--- a/drivers/staging/media/lirc/TODO
+++ b/drivers/staging/media/lirc/TODO
@@ -2,6 +2,11 @@
   (see drivers/media/IR/mceusb.c vs. lirc_mceusb.c in lirc cvs for an
   example of a previously completed port).
 
+- lirc_bt829 uses registers on a Mach64 VT, which has a separate kernel
+  framebuffer driver (atyfb) and userland X driver (mach64).  It can't
+  simply be converted to a normal PCI driver, but ideally it should be
+  coordinated with the other drivers.
+
 Please send patches to:
 Jarod Wilson 
 Greg Kroah-Hartman 



signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 0/4] lirc_bt829 fixes, second try

2013-09-04 Thread Ben Hutchings
A less ambitious set of fixes for the lirc_bt829 driver.

Ben.

Ben Hutchings (4):
  [media] lirc_bt829: Fix physical address type
  [media] lirc_bt829: Fix iomap and PCI device leaks
  [media] lirc_bt829: Enable and disable device
  [media] lirc_bt829: Note in TODO why it can't be a normal PCI driver
yet

 drivers/staging/media/lirc/TODO |  5 +
 drivers/staging/media/lirc/lirc_bt829.c | 33 +++--
 2 files changed, 32 insertions(+), 6 deletions(-)




signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


[PATCH v2 3/4] [media] lirc_bt829: Enable and disable device

2013-09-04 Thread Ben Hutchings
We must not assume that the PCI device is already enabled.

Signed-off-by: Ben Hutchings 
---
 drivers/staging/media/lirc/lirc_bt829.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/lirc/lirc_bt829.c 
b/drivers/staging/media/lirc/lirc_bt829.c
index a61d233..623f10e 100644
--- a/drivers/staging/media/lirc/lirc_bt829.c
+++ b/drivers/staging/media/lirc/lirc_bt829.c
@@ -126,9 +126,13 @@ int init_module(void)
if (pdev == NULL)
return -ENODEV;
 
+   rc = pci_enable_device(pdev);
+   if (rc)
+   goto err_put_dev;
+
if (!atir_init_start()) {
rc = -ENODEV;
-   goto err_put_dev;
+   goto err_disable;
}
 
strcpy(atir_driver.name, "ATIR");
@@ -154,6 +158,8 @@ int init_module(void)
 
 err_unmap:
iounmap(pci_addr_lin);
+err_disable:
+   pci_disable_device(pdev);
 err_put_dev:
pci_dev_put(pdev);
return rc;
@@ -166,6 +172,7 @@ void cleanup_module(void)
 
lirc_unregister_driver(atir_minor);
iounmap(pci_addr_lin);
+   pci_disable_device(pdev);
pci_dev_put(pdev);
 }
 




signature.asc
Description: This is a digitally signed message part
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel


Re: [PATCH v2 1/4] [media] lirc_bt829: Fix physical address type

2013-09-04 Thread Fabio Estevam
On Wed, Sep 4, 2013 at 11:31 PM, Ben Hutchings  wrote:
> Use phys_addr_t and log format %pa.
>
> Signed-off-by: Ben Hutchings 
> ---
>  drivers/staging/media/lirc/lirc_bt829.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_bt829.c 
> b/drivers/staging/media/lirc/lirc_bt829.c
> index fa31ee7..9c7be55 100644
> --- a/drivers/staging/media/lirc/lirc_bt829.c
> +++ b/drivers/staging/media/lirc/lirc_bt829.c
> @@ -63,7 +63,7 @@ static bool debug;
> } while (0)
>
>  static int atir_minor;
> -static unsigned long pci_addr_phys;
> +static phys_addr_t pci_addr_phys;
>  static unsigned char *pci_addr_lin;
>
>  static struct lirc_driver atir_driver;
> @@ -78,8 +78,7 @@ static struct pci_dev *do_pci_probe(void)
> pci_addr_phys = 0;
> if (my_dev->resource[0].flags & IORESOURCE_MEM) {
> pci_addr_phys = my_dev->resource[0].start;
> -   pr_info("memory at 0x%08X\n",
> -  (unsigned int)pci_addr_phys);
> +   pr_info("memory at %pa\n", &pci_addr_phys);

Looks much better :-)

Reviewed-by: Fabio Estevam 
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel