On 04/08/2010 04:06 PM, David Howells wrote: > It looks reasonable (feel free to add my Reviewed-by). But I can't test it as > I don't have any SMP NOMMU hardware. Published to linux-next w/ Reviewed-by added. Thank you. -- -- tejun
The way available scan modes are handled in the max1363 driver doesn't nicely equate to the AD7997, AD7997 or AD7991 series of ADCs. These devices feature up to 8 Channels while each channel can be independently included into the scan sequence. (this would require up to 256 'named' modes) A while ago we talked about this - and you said you would abandon the 'named' scan mode selection - and come up with something like a scan_elements directory with channel control files (enable/disable), and some sort of mechanism that rejects invalid combinations. I noticed some additions ... [PATCH 04/19] staging:iio: Support functions for scan mask matching But the sysfs interface is not in place. Is this something you're still planning to put into place? Best regards, Michael ------------------------------------------------------------------ ********* Analog Devices GmbH Open Platform Solutions ** ***** ** ** Wilhelm-Wagenfeld-Strasse 6 ** ***** D-80807 Munich ********* Germany Registergericht München HRB 40368, Geschäftsführer: Thomas Wessel, William A. Martin, Margaret K. Seif
Hi Michael > The way available scan modes are handled in the max1363 driver doesn't > nicely equate to the AD7997, AD7997 or AD7991 series of ADCs. > These devices feature up to 8 Channels while each channel can be independently > included into the scan sequence. > (this would require up to 256 'named' modes) I agree entirely. The approach originally used in max1363 has gone in the latest patch set posted the other day (indeed the set you reference below) > > A while ago we talked about this - and you said you would abandon the > 'named' scan mode selection - and come up with something like a scan_elements > directory with channel control files (enable/disable), and some sort of mechanism > that rejects invalid combinations. > > I noticed some additions ... > [PATCH 04/19] staging:iio: Support functions for scan mask matching Yup. That's what max1363 now does. In the same series, see [PATCH 08/19] staging:iio:max1363 move to new abi. (as the new abi didn't allow the 'named' scan mode approach!) Other than some renaming, the lis3l20dq for example has done the scan_elements approach from the start (as have some of the others.) Jonathan > > But the sysfs interface is not in place. > Is this something you're still planning to put into place? >(Continue reading)
On 05/04/10 11:37, Jonathan Cameron wrote: > Hi Michael >> The way available scan modes are handled in the max1363 driver doesn't >> nicely equate to the AD7997, AD7997 or AD7991 series of ADCs. >> These devices feature up to 8 Channels while each channel can be independently >> included into the scan sequence. >> (this would require up to 256 'named' modes) > I agree entirely. The approach originally used in max1363 has gone in the latest > patch set posted the other day (indeed the set you reference below) >> >> A while ago we talked about this - and you said you would abandon the >> 'named' scan mode selection - and come up with something like a scan_elements >> directory with channel control files (enable/disable), and some sort of mechanism >> that rejects invalid combinations. >> >> I noticed some additions ... >> [PATCH 04/19] staging:iio: Support functions for scan mask matching > Yup. That's what max1363 now does. In the same series, see > [PATCH 08/19] staging:iio:max1363 move to new abi. > > (as the new abi didn't allow the 'named' scan mode approach!) As a footnote. The max1363 changes are about the least tested and most complex part of that patch set, so any comments from anyone on that or other aspects of the set are welcome! I'll need to get these to Greg fairly soon if they are going to merge in the next window. > Other than some renaming, the lis3l20dq for example has done the scan_elements > approach from the start (as have some of the others.) >(Continue reading)
Hi Jonathan, Jonathan Cameron wrote on 2010-05-04: > Hi Michael >> The way available scan modes are handled in the max1363 driver doesn't >> nicely equate to the AD7997, AD7997 or AD7991 series of ADCs. These >> devices feature up to 8 Channels while each channel can be >> independently included into the scan sequence. (this would require up >> to 256 'named' modes) > I agree entirely. The approach originally used in max1363 has gone in > the latest patch set posted the other day (indeed the set you reference > below) >> >> A while ago we talked about this - and you said you would abandon >> the 'named' scan mode selection - and come up with something like a >> scan_elements directory with channel control files (enable/disable), >> and some sort of mechanism that rejects invalid combinations. >> >> I noticed some additions ... >> [PATCH 04/19] staging:iio: Support functions for scan mask matching > Yup. That's what max1363 now does. In the same series, see [PATCH > 08/19] staging:iio:max1363 move to new abi. > Sorry - I missed that one. > (as the new abi didn't allow the 'named' scan mode approach!) > > Other than some renaming, the lis3l20dq for example has done the > scan_elements approach from the start (as have some of the others.) >(Continue reading)
From: Michael Hennerich <michael.hennerich@...> Macro away the duplication to make maintenance easier. Signed-off-by: Michael Hennerich <michael.hennerich@...> Signed-off-by: Mike Frysinger <vapier@...> --- drivers/misc/ad525x_dpot.c | 238 ++++++++------------------------------------ 1 files changed, 43 insertions(+), 195 deletions(-) diff --git a/drivers/misc/ad525x_dpot.c b/drivers/misc/ad525x_dpot.c index 30a59f2..e6b274b 100644 --- a/drivers/misc/ad525x_dpot.c +++ b/drivers/misc/ad525x_dpot.c <at> <at> -158,175 +158,45 <at> <at> static ssize_t sysfs_do_cmd(struct device *dev, /* ------------------------------------------------------------------------- */ -static ssize_t show_rdac0(struct device *dev, - struct device_attribute *attr, char *buf) -{ - return sysfs_show_reg(dev, attr, buf, AD525X_I2C_RDAC | AD525X_RDAC0); -} - -static ssize_t set_rdac0(struct device *dev, - struct device_attribute *attr, - const char *buf, size_t count) -{ - return sysfs_set_reg(dev, attr, buf, count, - AD525X_I2C_RDAC | AD525X_RDAC0);(Continue reading)
From: Michael Hennerich <michael.hennerich@...> Split the bus logic out into separate files so that we can handle I2C and SPI busses independently. The new SPI bus logic brings in support for a lot more parts: AD5160, AD5161, AD5162, AD5165, AD5200, AD5201, AD5203, AD5204, AD5206, AD5207, AD5231, AD5232, AD5233, AD5235, AD5260, AD5262, AD5263, AD5290, AD5291, AD5292, AD5293, AD7376, AD8400, AD8402, AD8403, ADN2850 Signed-off-by: Michael Hennerich <michael.hennerich@...> Signed-off-by: Mike Frysinger <vapier@...> --- drivers/misc/Kconfig | 30 ++- drivers/misc/Makefile | 2 + drivers/misc/ad525x_dpot-i2c.c | 119 ++++++++ drivers/misc/ad525x_dpot-spi.c | 172 +++++++++++ drivers/misc/ad525x_dpot.c | 628 ++++++++++++++++++++-------------------- drivers/misc/ad525x_dpot.h | 173 +++++++++++ 6 files changed, 805 insertions(+), 319 deletions(-) create mode 100644 drivers/misc/ad525x_dpot-i2c.c create mode 100644 drivers/misc/ad525x_dpot-spi.c create mode 100644 drivers/misc/ad525x_dpot.h diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index 0d0d625..69e019e 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig <at> <at> -14,11 +14,15 <at> <at> menuconfig MISC_DEVICES if MISC_DEVICES(Continue reading)
From: Sonic Zhang <sonic.zhang@...> IP checksum is based on 16-bit one's complement algorithm. To deduce a value from checksum is equal to add its complement. Signed-off-by: Sonic Zhang <sonic.zhang@...> Signed-off-by: Mike Frysinger <vapier@...> --- drivers/net/bfin_mac.c | 23 +++++++++++++++++++++++ 1 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c index f9ba598..5b00fc8 100644 --- a/drivers/net/bfin_mac.c +++ b/drivers/net/bfin_mac.c <at> <at> -994,6 +994,10 <at> <at> static void bfin_mac_rx(struct net_device *dev) struct sk_buff *skb, *new_skb; unsigned short len; struct bfin_mac_local *lp __maybe_unused = netdev_priv(dev); +#if defined(BFIN_MAC_CSUM_OFFLOAD) + unsigned int i; + unsigned char fcs[ETH_FCS_LEN + 1]; +#endif /* check if frame status word reports an error condition * we which case we simply drop the packet <at> <at> -1027,6 +1031,8 <at> <at> static void bfin_mac_rx(struct net_device *dev) current_rx_ptr->desc_a.start_addr = (unsigned long)new_skb->data - 2; len = (unsigned short)((current_rx_ptr->status.status_word) & RX_FRLEN);(Continue reading)
From: Barry Song <barry.song@...> Newer on-chip MAC peripherals support IEEE 1588 PTP in the hardware, so extend the driver to support this functionality. Signed-off-by: Barry Song <barry.song@...> Signed-off-by: Mike Frysinger <vapier@...> --- drivers/net/Kconfig | 7 + drivers/net/bfin_mac.c | 341 +++++++++++++++++++++++++++++++++++++++++++++++- drivers/net/bfin_mac.h | 15 ++ 3 files changed, 362 insertions(+), 1 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 7b832c7..ac536b9 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig <at> <at> -887,6 +887,13 <at> <at> config BFIN_MAC_RMII help Use Reduced PHY MII Interface +config BFIN_MAC_USE_HWSTAMP + bool "Use IEEE 1588 hwstamp" + depends on BFIN_MAC && BF518 + default y + help + To support the IEEE 1588 Precision Time Protocol (PTP), select y here + config SMC9194 tristate "SMC 9194 support"(Continue reading)
From: Michael Hennerich <michael.hennerich@...> The current allocation does not include the memory required for blanking lines. So avoid memory corruption when multiple devices are using the DMA memory near each other. Signed-off-by: Michael Hennerich <michael.hennerich@...> Signed-off-by: Mike Frysinger <vapier@...> --- drivers/video/bfin-t350mcqb-fb.c | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb-fb.c index 44e49c2..c2ec3dc 100644 --- a/drivers/video/bfin-t350mcqb-fb.c +++ b/drivers/video/bfin-t350mcqb-fb.c <at> <at> -488,9 +488,9 <at> <at> static int __devinit bfin_t350mcqb_probe(struct platform_device *pdev) fbinfo->fbops = &bfin_t350mcqb_fb_ops; fbinfo->flags = FBINFO_FLAG_DEFAULT; - info->fb_buffer = - dma_alloc_coherent(NULL, fbinfo->fix.smem_len, &info->dma_handle, - GFP_KERNEL); + info->fb_buffer = dma_alloc_coherent(NULL, fbinfo->fix.smem_len + + ACTIVE_VIDEO_MEM_OFFSET, + &info->dma_handle, GFP_KERNEL); if (NULL == info->fb_buffer) { printk(KERN_ERR DRIVER_NAME <at> <at> -568,8 +568,8 <at> <at> out7:(Continue reading)
RSS Feed4 | |
|---|---|
4 | |
4 | |
3 | |
19 | |
13 | |
8 | |
19 | |
1 | |
3 | |
2 | |
8 | |
4 | |
20 | |
25 | |
18 | |
4 | |
6 | |
13 | |
16 | |
7 | |
40 | |
71 | |
32 | |
75 | |
6 | |
61 | |
43 | |
99 | |
27 | |
31 | |
134 | |
25 | |
126 | |
23 | |
48 | |
100 | |
24 | |
185 | |
34 | |
53 | |
132 | |
42 | |
116 | |
372 | |
124 | |
187 | |
538 | |
168 | |
38 | |
98 | |
74 | |
19 | |
50 | |
31 | |
63 | |
14 | |
47 | |
51 | |
31 | |
68 | |
80 | |
70 | |
45 | |
74 | |
27 | |
41 | |
36 | |
60 | |
39 | |
75 | |
20 | |
70 | |
61 | |
38 | |
10 |
