Re: [PATCH v3 8/9] usb: chipidea: move usb_otg into struct ci_hdrc
Hi, On Mon, Sep 01, 2014 at 09:13:43AM +0800, Peter Chen wrote: > On Fri, Aug 29, 2014 at 04:25:35PM +0200, Antoine Tenart wrote: > > On Tue, Aug 26, 2014 at 06:22:40PM +0800, Peter Chen wrote: > > > On Fri, Aug 22, 2014 at 05:50:19PM +0200, Antoine Ténart wrote: > > > > > > If the common usb_otg and usb_phy struct still has another's pointer, you > > > may not need to add this patch. > > > > Except if we want to access the OTG member when not using an USB PHY. > > If there is no USB PHY, the probe at core.c will turn error. I meant if we use a PHY from the common PHY framework (struct phy) and not one from the USB one (struct usb_phy). The 'struct phy' does not have a pointer to an OTG structure. Antoine -- Antoine Ténart, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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/
RE: [PATCHv1 4/7] ASoC: dts: kirkwood-t5325: To support simple card newest style.
Hi Andrew,
Thanks very much for you comment and advice.
I will resend this patch series to compatibility with the old DTs, and it will
Up to the owners to update the DTs to support the new style of DTs.
BRs
Xiubo
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, September 01, 2014 9:42 PM
> To: Xiubo Li-B47053
> Cc: broo...@kernel.org; lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.de;
> kuninori.morimoto...@renesas.com; moin...@free.fr; and...@lunn.ch;
> jsa...@ti.com; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org; alsa-devel@alsa-
> project.org; Guo Shawn-R65073; linux-kernel@vger.kernel.org; Jason Cooper
> Subject: Re: [PATCHv1 4/7] ASoC: dts: kirkwood-t5325: To support simple card
> newest style.
>
> On Mon, Sep 01, 2014 at 12:29:38PM +0800, Xiubo Li wrote:
> > This patch depends on the following simple card patch:
> > ===
> > ASoC: simple-card: Merge single and muti DAI link code.
>
> Saying what a patch depends on, is not the best of ChangeLog.
>
> Say something like:
>
> The simple-card binding has been changed, so that a dai-link subnode
> is now required, and the properties directly under the sound node are
> no longer allowed. Modify the DT to fit this new binding.
>
>Andrew
>
>
> >
> > This patch merge single DAI link and muti-DAI links code together,
> > and simply the simple-card driver code.
> >
> > And also do some other improvement:
> >
> > Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
> > mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
> > frame clock is as master/slave.
> >
> > So these same DAI formats should be informed to CPU and CODE DAIs at
> > the same time. For the Codec driver will set the bit clock and frame
> > clock as the DAI formats said, but for the CPU driver, if the the
> > bit clock or frame clock is as Codec master, so it should be set CPU
> > DAI device as bit clock or frame clock as slave, and vice versa.
> >
> > The old code will cause confusion, and we should be clear that the
> > letter 'C' here mean to Codec.
> > ===
> >
> > Signed-off-by: Xiubo Li
> > ---
> > arch/arm/boot/dts/kirkwood-t5325.dts | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/kirkwood-t5325.dts
> b/arch/arm/boot/dts/kirkwood-t5325.dts
> > index 610ec0f..25d1223 100644
> > --- a/arch/arm/boot/dts/kirkwood-t5325.dts
> > +++ b/arch/arm/boot/dts/kirkwood-t5325.dts
> > @@ -189,7 +189,6 @@
> >
> > sound {
> > compatible = "simple-audio-card";
> > - simple-audio-card,format = "i2s";
> > simple-audio-card,routing =
> > "Headphone Jack", "HPL",
> > "Headphone Jack", "HPR",
> > @@ -204,12 +203,14 @@
> >
> > simple-audio-card,mclk-fs = <256>;
> >
> > - simple-audio-card,cpu {
> > - sound-dai = <>;
> > - };
> > -
> > - simple-audio-card,codec {
> > - sound-dai = <>;
> > + simple-audio-card,dai-link {
> > + format = "i2s";
> > + cpu {
> > + sound-dai = <>;
> > + };
> > + codec {
> > + sound-dai = <>;
> > + };
> > };
> > };
> > };
> > --
> > 1.8.4
> >
--
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/
RE: [RFC][PATCH] ASoC: simple-card: Merge single and muti DAI link code.
Hi Jyri,
I'll follow Mark's advice of maintaining compatibility with the old DTs.
Thanks very much for your comments, and this is very important for me.
And I will also update the binding documet for simple card, please help
me review it, any comment and advice are welcome.
The goal is to simplify the simple card code and make it more readable and
Easier to add muti DAI links support from the single DAI link DTs, this will
Be very useful on my LS1+ SoCs in the future.
BRs
Xiubo
> -Original Message-
> From: Jyri Sarha [mailto:jsa...@ti.com]
> Sent: Monday, September 01, 2014 5:39 PM
> To: Xiubo Li-B47053; broo...@kernel.org; alsa-de...@alsa-project.org
> Cc: linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Kuninori
> Morimoto; Jean-Francois Moine; Nicolin Chen
> Subject: Re: [RFC][PATCH] ASoC: simple-card: Merge single and muti DAI link
> code.
>
> This patch would break the current syntax without introducing any
> improvements over it (actually the opposite, see bellow). So in its
> current form I don't like this patch at all.
>
> On 08/29/2014 09:46 AM, Xiubo Li wrote:
> > This patch merge single DAI link and muti-DAI links code together,
> > and simply the simple-card driver code.
> >
> > And also do some other improvement:
> >
> > Since from the DAI format micro SND_SOC_DAIFMT_CBx_CFx, the 'CBx'
> > mean Codec's bit clock is as master/slave and the 'CFx' mean Codec's
> > frame clock is as master/slave.
> >
> > So these same DAI formats should be informed to CPU and CODE DAIs at
> > the same time. For the Codec driver will set the bit clock and frame
> > clock as the DAI formats said, but for the CPU driver, if the the
> > bit clock or frame clock is as Codec master, so it should be set CPU
> > DAI device as bit clock or frame clock as slave, and vice versa.
> >
>
> But there is no such problem with the current code any more. The new
> preferred way is to indicate bitclock and frame master with phandles
> that refer to the master DAI on the link (see the examples bellow).
>
> > The old code will cause confusion, and we should be clear that the
> > letter 'C' here mean to Codec.
> >
> > Signed-off-by: Xiubo Li
> > Cc: Kuninori Morimoto
> > Cc: Jean-Francois Moine
> > Cc: Jyri Sarha
> > Cc: Nicolin Chen
> > ---
> >
> > Hi,
> >
> > This patch will break the old DT, so i just send one RFC version, and
> > will add the old DT patches in next version if this patch can work
> > well.
>
> I do not object in getting rid of this simplified description for a
> single dailink card:
>
> (example 1)
> sound {
> compatible = "simple-audio-card";
> ...
> simple-audio-card,format = "left_j";
> simple-audio-card,bitclock-master = <_master>;
> simple-audio-card,frame-master = <_master>;
> simple-audio-card,cpu {
> sound-dai = <_fsi2 0>;
> };
>
> dailink0_master: simple-audio-card,codec {
> sound-dai = <>;
> clocks = <>;
> };
> };
>
> and describing the DAI-links always like this:
>
> (example 2)
> sound {
> compatible = "simple-audio-card";
> ...
> simple-audio-card,dai-link@0 {
> format = "i2s";
> bitclock-master = <_master>;
> frame-master = <_master>;
> dailink0_master: cpu {
> sound-dai = < 0>;
> };
> codec {
> sound-dai = < 0>;
> };
> };
> };
>
> But I do object going back to the old syntax exclusively and
> describing the bitclock and frame master always with simple boolean
> properties, like this:
>
> (example 3)
> sound {
> compatible = "simple-audio-card";
> ...
> simple-audio-card,dai-link@0 {
> format = "i2s";
> dailink0_master: cpu {
> sound-dai = < 0>;
> };
> codec {
> sound-dai = < 0>;
> bitclock-master;
> frame-master;
> };
> };
> };
>
> In my opinion we should rather get rid of this syntax than move
> exclusively to it.
>
> The syntax of example 2 is simply superior to the syntax of example
> 3. With the syntax on example 2 it is possible to describe TDM setups
> where there is multiple codecs on a single i2s bus. The syntax of
> example 3 simply can not describe that kind of setup.
>
> If you need to have the backwards compatibility syntax describing the
> clock masters to work also in the multilink mode (example 3), then do
> just that (it is simple enough [1]). But please do not break the new
> phandle based syntax!!!
>
> Best regards,
> Jyri
>
> [1] To enable legacy syntax in multilink mode just apply this patch:
>
> diff --git a/sound/soc/generic/simple-card.c
> b/sound/soc/generic/simple-card.c
> index 8dd7957..aed3423 100644
> --- a/sound/soc/generic/simple-card.c
> +++ b/sound/soc/generic/simple-card.c
>
Re: [PATCH] fs/super.c: do not shrink fs slab during direct memory reclaim
Hi, Dave On 2014/9/2 7:51, Dave Chinner wrote: > On Fri, Aug 29, 2014 at 05:57:22PM +0800, Xue jiufei wrote: >> The patch trys to solve one deadlock problem caused by cluster >> fs, like ocfs2. And the problem may happen at least in the below >> situations: >> 1)Receiving a connect message from other nodes, node queues a >> work_struct o2net_listen_work. >> 2)o2net_wq processes this work and calls sock_alloc() to allocate >> memory for a new socket. >> 3)It would do direct memory reclaim when available memory is not >> enough and trigger the inode cleanup. That inode being cleaned up >> is happened to be ocfs2 inode, so call evict()->ocfs2_evict_inode() >> ->ocfs2_drop_lock()->dlmunlock()->o2net_send_message_vec(), >> and wait for the unlock response from master. >> 4)tcp layer received the response, call o2net_data_ready() and >> queue sc_rx_work, waiting o2net_wq to process this work. >> 5)o2net_wq is a single thread workqueue, it process the work one by >> one. Right now it is still doing o2net_listen_work and cannot handle >> sc_rx_work. so we deadlock. >> >> It is impossible to set GFP_NOFS for memory allocation in sock_alloc(). >> So we use PF_FSTRANS to avoid the task reentering filesystem when >> available memory is not enough. >> >> Signed-off-by: joyce.xue > > For the second time: use memalloc_noio_save/memalloc_noio_restore. > And please put a great big comment in the code explaining why you > need to do this special thing with memory reclaim flags. > > Cheers, > > Dave. > Thanks for your reply. But I am afraid that memalloc_noio_save/ memalloc_noio_restore can not solve my problem. __GFP_IO is cleared if PF_MEMALLOC_NOIO is set and can avoid doing IO in direct memory reclaim. However, __GFP_FS is still set that can not avoid pruning dcache and icache in memory allocation, resulting in the deadlock I described. Thanks. XueJiufei -- 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/
[PATCH] Revert "leds: convert blink timer to workqueue"
This reverts commit 8b37e1bef5a6b60e949e28a4db3006e4b00bd758.
It's broken as it changes led_blink_set() in a way that it can now sleep
(while synchronously waiting for workqueue to be cancelled). That's a
problem, because it's possible that this function gets called from atomic
context (tpt_trig_timer() takes a readlock and thus disables preemption).
This has been brought up 3 weeks ago already [1] but no proper fix has
materialized, and I keep seeing the problem since 3.18-rc1.
[1] https://lkml.org/lkml/2014/8/16/128
BUG: sleeping function called from invalid context at kernel/workqueue.c:2650
in_atomic(): 1, irqs_disabled(): 0, pid: 2335, name: wpa_supplicant
5 locks held by wpa_supplicant/2335:
#0: (rtnl_mutex){+.+.+.}, at: [] rtnl_lock+0x12/0x20
#1: (>mtx){+.+.+.}, at: []
cfg80211_mgd_wext_siwessid+0x5c/0x180 [cfg80211]
#2: (>mtx){+.+.+.}, at: []
ieee80211_prep_connection+0x17a/0x9a0 [mac80211]
#3: (>chanctx_mtx){+.+.+.}, at: []
ieee80211_vif_use_channel+0x5d/0x2a0 [mac80211]
#4: (>leddev_list_lock){.+.+..}, at: []
tpt_trig_timer+0xec/0x170 [mac80211]
CPU: 0 PID: 2335 Comm: wpa_supplicant Not tainted 3.17.0-rc3 #1
Hardware name: LENOVO 7470BN2/7470BN2, BIOS 6DET38WW (2.02 ) 12/19/2008
8800360b5a50 8800751f76d8 8159e97f 8800360b5a30
8800751f76e8 810739a5 8800751f77b0 8106862f
810685d0 0aa22092 8804 8800361c59d0
Call Trace:
[] dump_stack+0x4d/0x66
[] __might_sleep+0xe5/0x120
[] flush_work+0x5f/0x270
[] ? mod_delayed_work_on+0x80/0x80
[] ? mark_held_locks+0x6a/0x90
[] ? __cancel_work_timer+0x6f/0x100
[] ? trace_hardirqs_on_caller+0xfd/0x1c0
[] __cancel_work_timer+0x7b/0x100
[] cancel_delayed_work_sync+0xe/0x10
[] led_blink_set+0x1b/0x40
[] tpt_trig_timer+0x110/0x170 [mac80211]
[] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
[] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
[] ieee80211_idle_off+0xe/0x10 [mac80211]
[] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
[] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
[] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
[] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
[] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
[] ieee80211_auth+0x13/0x20 [mac80211]
[] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
[] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
[] cfg80211_connect+0x3f0/0x540 [cfg80211]
[] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
[] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
[] ? cfg80211_wext_giwessid+0x50/0x50 [cfg80211]
[] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
[] ioctl_standard_iw_point+0x14c/0x3e0
[] ? trace_hardirqs_on_caller+0xfd/0x1c0
[] ioctl_standard_call+0x8a/0xd0
[] ? ioctl_standard_iw_point+0x3e0/0x3e0
[] wireless_process_ioctl.constprop.10+0xb6/0x100
[] wext_handle_ioctl+0x5d/0xb0
[] dev_ioctl+0x329/0x620
[] ? trace_hardirqs_on_caller+0xfd/0x1c0
[] sock_ioctl+0x142/0x2e0
[] do_vfs_ioctl+0x300/0x520
[] ? sysret_check+0x1b/0x56
[] ? trace_hardirqs_on_caller+0xfd/0x1c0
[] SyS_ioctl+0x81/0xa0
[] system_call_fastpath+0x1a/0x1f
wlan0: send auth to 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: authenticated
wlan0: associate with 00:0b:6b:3c:8c:e4 (try 1/3)
wlan0: RX AssocResp from 00:0b:6b:3c:8c:e4 (capab=0x431 status=0 aid=2)
wlan0: associated
IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
cfg80211: Calling CRDA for country: NA
wlan0: Limiting TX power to 27 (27 - 0) dBm as advertised by 00:0b:6b:3c:8c:e4
=
[ INFO: inconsistent lock state ]
3.17.0-rc3 #1 Not tainted
-
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
swapper/0/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
((&(_cdev->blink_work)->work)){+.?...}, at: []
flush_work+0x0/0x270
{SOFTIRQ-ON-W} state was registered at:
[] __lock_acquire+0x30e/0x1a30
[] lock_acquire+0x91/0x110
[] flush_work+0x38/0x270
[] __cancel_work_timer+0x7b/0x100
[] cancel_delayed_work_sync+0xe/0x10
[] led_blink_set+0x1b/0x40
[] tpt_trig_timer+0x110/0x170 [mac80211]
[] ieee80211_mod_tpt_led_trig+0x9d/0x160 [mac80211]
[] __ieee80211_recalc_idle+0x98/0x140 [mac80211]
[] ieee80211_idle_off+0xe/0x10 [mac80211]
[] ieee80211_add_chanctx+0x3b/0x220 [mac80211]
[] ieee80211_new_chanctx+0x44/0xf0 [mac80211]
[] ieee80211_vif_use_channel+0x1fa/0x2a0 [mac80211]
[] ieee80211_prep_connection+0x188/0x9a0 [mac80211]
[] ieee80211_mgd_auth+0x256/0x2e0 [mac80211]
[] ieee80211_auth+0x13/0x20 [mac80211]
[] cfg80211_mlme_auth+0x106/0x270 [cfg80211]
[] cfg80211_conn_do_work+0x155/0x3b0 [cfg80211]
[] cfg80211_connect+0x3f0/0x540 [cfg80211]
[] cfg80211_mgd_wext_connect+0x158/0x1f0 [cfg80211]
[] cfg80211_mgd_wext_siwessid+0xde/0x180 [cfg80211]
[] cfg80211_wext_siwessid+0x1d/0x40 [cfg80211]
[] ioctl_standard_iw_point+0x14c/0x3e0
[] ioctl_standard_call+0x8a/0xd0
[]
[PATCH 0/7] ARM: at91: update defconfigs
Following recent work on the AT91 platforms, update the defconfigs to include the new power and reset driver, the ADC and touchscreen driver, the new PWM driver using the generic PWM framework. Also remove deprecated options like CONFIG_PROC_DEVICETREE, CONFIG_SCSI_MULTI_LUN, CONFIG_MII, CONFIG_MTD_CHAR. Alexandre Belloni (7): ARM: at91: at91_dt: update defconfig ARM: at91: at91sam9260_9g20: update defconfig ARM: at91: at91sam9261_9g10: update defconfig ARM: at91: at91sam9263: update defconfig ARM: at91: at91sam9g45: update defconfig ARM: at91: at91sam9rl: update defconfig ARM: at91: sama5: update defconfig arch/arm/configs/at91_dt_defconfig | 25 + arch/arm/configs/at91sam9260_9g20_defconfig | 13 + arch/arm/configs/at91sam9261_9g10_defconfig | 5 ++--- arch/arm/configs/at91sam9263_defconfig | 13 ++--- arch/arm/configs/at91sam9g45_defconfig | 19 +++ arch/arm/configs/at91sam9rl_defconfig | 19 ++- arch/arm/configs/sama5_defconfig| 12 ++-- 7 files changed, 57 insertions(+), 49 deletions(-) -- 1.9.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/
[PATCH 1/7] ARM: at91: at91_dt: update defconfig
Update defconfig, adding: - ADC/touchscreen - PWM support using the generic framework - generic PWM leds - Power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91_dt_defconfig | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig index 300ded9acbe9..b52da263d534 100644 --- a/arch/arm/configs/at91_dt_defconfig +++ b/arch/arm/configs/at91_dt_defconfig @@ -18,15 +18,14 @@ CONFIG_SOC_AT91RM9200=y CONFIG_SOC_AT91SAM9260=y CONFIG_SOC_AT91SAM9261=y CONFIG_SOC_AT91SAM9263=y +CONFIG_SOC_AT91SAM9RL=y CONFIG_SOC_AT91SAM9G45=y CONFIG_SOC_AT91SAM9X5=y CONFIG_SOC_AT91SAM9N12=y -CONFIG_SOC_AT91SAM9RL=y CONFIG_MACH_AT91RM9200_DT=y CONFIG_MACH_AT91SAM9_DT=y CONFIG_AT91_TIMER_HZ=128 CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_UACCESS_WITH_MEMCPY=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 @@ -63,23 +62,19 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_DATAFLASH=y CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_GLUEBI=y -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=8192 -CONFIG_ATMEL_PWM=y CONFIG_ATMEL_TCLIB=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_NETDEVICES=y CONFIG_MACB=y @@ -105,9 +100,8 @@ CONFIG_RT2800USB=m CONFIG_RT2800USB_RT53XX=y CONFIG_RT2800USB_RT55XX=y CONFIG_RT2800USB_UNKNOWN=y -CONFIG_RTLWIFI=m -# CONFIG_RTLWIFI_DEBUG is not set CONFIG_RTL8192CU=m +# CONFIG_RTLWIFI_DEBUG is not set CONFIG_MWIFIEX=m CONFIG_MWIFIEX_SDIO=m CONFIG_MWIFIEX_USB=m @@ -131,6 +125,8 @@ CONFIG_I2C=y CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_AT91SAM9X_WATCHDOG=y @@ -144,10 +140,6 @@ CONFIG_BACKLIGHT_ATMEL_LCDC=y # CONFIG_BACKLIGHT_GENERIC is not set CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y -CONFIG_FONTS=y -CONFIG_FONT_8x8=y -CONFIG_FONT_ACORN_8x8=y -CONFIG_FONT_MINI_4x6=y CONFIG_LOGO=y CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y @@ -169,6 +161,7 @@ CONFIG_MMC_SPI=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y @@ -179,6 +172,10 @@ CONFIG_RTC_DRV_AT91RM9200=y CONFIG_RTC_DRV_AT91SAM9=y CONFIG_DMADEVICES=y # CONFIG_IOMMU_SUPPORT is not set +CONFIG_IIO=y +CONFIG_AT91_ADC=y +CONFIG_PWM=y +CONFIG_PWM_ATMEL=y CONFIG_EXT4_FS=y CONFIG_FANOTIFY=y CONFIG_VFAT_FS=y @@ -209,3 +206,7 @@ CONFIG_CRC_CCITT=y CONFIG_CRC_ITU_T=y CONFIG_CRC7=m CONFIG_AVERAGE=y +CONFIG_FONTS=y +CONFIG_FONT_8x8=y +CONFIG_FONT_ACORN_8x8=y +CONFIG_FONT_MINI_4x6=y -- 1.9.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/
[PATCH 2/7] ARM: at91: at91sam9260_9g20: update defconfig
Update defconfig, adding: - ADC/touchscreen - Power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91sam9260_9g20_defconfig | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/at91sam9260_9g20_defconfig b/arch/arm/configs/at91sam9260_9g20_defconfig index c4c160fc8791..3ada05d639ad 100644 --- a/arch/arm/configs/at91sam9260_9g20_defconfig +++ b/arch/arm/configs/at91sam9260_9g20_defconfig @@ -54,7 +54,6 @@ CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_OF_PARTS=y CONFIG_MTD_BLOCK=y CONFIG_MTD_DATAFLASH=y CONFIG_MTD_NAND=y @@ -66,13 +65,10 @@ CONFIG_BLK_DEV_RAM_SIZE=8192 CONFIG_EEPROM_AT25=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_NETDEVICES=y -CONFIG_MII=y CONFIG_MACB=y # CONFIG_NET_VENDOR_BROADCOM is not set -# CONFIG_NET_VENDOR_CHELSIO is not set # CONFIG_NET_VENDOR_FARADAY is not set # CONFIG_NET_VENDOR_INTEL is not set # CONFIG_NET_VENDOR_MARVELL is not set @@ -86,7 +82,6 @@ CONFIG_SMSC_PHY=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_KEYBOARD_GPIO=y # CONFIG_INPUT_MOUSE is not set -# CONFIG_SERIO is not set CONFIG_SERIAL_ATMEL=y CONFIG_SERIAL_ATMEL_CONSOLE=y CONFIG_HW_RANDOM=y @@ -97,6 +92,8 @@ CONFIG_SPI=y CONFIG_SPI_ATMEL=y CONFIG_SPI_SPIDEV=y CONFIG_GPIO_SYSFS=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y @@ -127,6 +124,8 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_RV3029C2=y CONFIG_RTC_DRV_AT91SAM9=y +CONFIG_IIO=y +CONFIG_AT91_ADC=y CONFIG_EXT4_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y @@ -139,10 +138,8 @@ CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_UTF8=y -# CONFIG_ENABLE_WARN_DEPRECATED is not set -CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_FTRACE is not set CONFIG_DEBUG_LL=y -CONFIG_AT91_DEBUG_LL_DBGU0=y CONFIG_EARLY_PRINTK=y -- 1.9.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/
[PATCH 5/7] ARM: at91: at91sam9g45: update defconfig
Update defconfig, adding: - PWM support using the generic framework - generic PWM leds - Power/reset - Watchdog and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91sam9g45_defconfig | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/arch/arm/configs/at91sam9g45_defconfig b/arch/arm/configs/at91sam9g45_defconfig index c6661a60025d..f66d1a1b64bf 100644 --- a/arch/arm/configs/at91sam9g45_defconfig +++ b/arch/arm/configs/at91sam9g45_defconfig @@ -20,7 +20,6 @@ CONFIG_MACH_AT91SAM9M10G45EK=y CONFIG_MACH_AT91SAM9_DT=y CONFIG_AT91_SLOW_CLOCK=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_UACCESS_WITH_MEMCPY=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 @@ -51,7 +50,6 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_DATAFLASH=y CONFIG_MTD_NAND=y @@ -62,15 +60,12 @@ CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=8192 -CONFIG_ATMEL_PWM=y CONFIG_ATMEL_TCLIB=y CONFIG_ATMEL_SSC=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_NETDEVICES=y -CONFIG_MII=y CONFIG_MACB=y CONFIG_DAVICOM_PHY=y # CONFIG_INPUT_MOUSEDEV is not set @@ -93,18 +88,22 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_WATCHDOG_NOWAYOUT=y +CONFIG_AT91SAM9X_WATCHDOG=y CONFIG_FB=y CONFIG_FB_ATMEL=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_BACKLIGHT_ATMEL_LCDC=y -CONFIG_BACKLIGHT_ATMEL_PWM=y # CONFIG_BACKLIGHT_GENERIC is not set +CONFIG_BACKLIGHT_PWM=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y -CONFIG_FONTS=y CONFIG_LOGO=y CONFIG_SOUND=y CONFIG_SND=y @@ -135,6 +134,7 @@ CONFIG_MMC_ATMELMCI=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y @@ -147,6 +147,8 @@ CONFIG_DMATEST=m # CONFIG_IOMMU_SUPPORT is not set CONFIG_IIO=y CONFIG_AT91_ADC=y +CONFIG_PWM=y +CONFIG_PWM_ATMEL=y CONFIG_EXT4_FS=y CONFIG_FANOTIFY=y CONFIG_VFAT_FS=y @@ -159,8 +161,8 @@ CONFIG_NLS_CODEPAGE_437=y CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_STRIP_ASM_SYMS=y -# CONFIG_SCHED_DEBUG is not set CONFIG_DEBUG_MEMORY_INIT=y +# CONFIG_SCHED_DEBUG is not set # CONFIG_FTRACE is not set CONFIG_DEBUG_USER=y CONFIG_DEBUG_LL=y @@ -170,3 +172,4 @@ CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_USER_API_HASH=m CONFIG_CRYPTO_USER_API_SKCIPHER=m # CONFIG_CRYPTO_HW is not set +CONFIG_FONTS=y -- 1.9.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/
[PATCH 3/7] ARM: at91: at91sam9261_9g10: update defconfig
Update defconfig, adding power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91sam9261_9g10_defconfig | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/arm/configs/at91sam9261_9g10_defconfig b/arch/arm/configs/at91sam9261_9g10_defconfig index f80e993b04ce..0c505d801e25 100644 --- a/arch/arm/configs/at91sam9261_9g10_defconfig +++ b/arch/arm/configs/at91sam9261_9g10_defconfig @@ -1,4 +1,3 @@ -CONFIG_EXPERIMENTAL=y # CONFIG_LOCALVERSION_AUTO is not set CONFIG_KERNEL_LZMA=y # CONFIG_SWAP is not set @@ -20,7 +19,6 @@ CONFIG_MACH_AT91SAM9261EK=y CONFIG_MACH_AT91SAM9G10EK=y # CONFIG_ARM_THUMB is not set CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x2110,3145728 root=/dev/ram0 rw" @@ -55,7 +53,6 @@ CONFIG_ATMEL_TCLIB=y CONFIG_ATMEL_SSC=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y CONFIG_DM9000=y CONFIG_USB_ZD1201=m @@ -87,6 +84,8 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y -- 1.9.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/
[PATCH 6/7] ARM: at91: at91sam9rl: update defconfig
Update defconfig, adding: - USB gadget - PWM support using the generic framework - generic PWM leds - LEDs triggers - Power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91sam9rl_defconfig | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/arch/arm/configs/at91sam9rl_defconfig b/arch/arm/configs/at91sam9rl_defconfig index 5d7797d43d23..4c26d344ae88 100644 --- a/arch/arm/configs/at91sam9rl_defconfig +++ b/arch/arm/configs/at91sam9rl_defconfig @@ -2,8 +2,8 @@ # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_LOG_BUF_SHIFT=14 -CONFIG_EMBEDDED=y CONFIG_BLK_DEV_INITRD=y +CONFIG_EMBEDDED=y CONFIG_SLAB=y CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y @@ -37,7 +37,6 @@ CONFIG_BLK_DEV_RAM_COUNT=4 CONFIG_BLK_DEV_RAM_SIZE=24576 CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=320 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=240 @@ -54,20 +53,31 @@ CONFIG_I2C_CHARDEV=y CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y CONFIG_AT91SAM9X_WATCHDOG=y CONFIG_FB=y CONFIG_FB_ATMEL=y +CONFIG_USB_GADGET=y +CONFIG_USB_ATMEL_USBA=y CONFIG_MMC=y CONFIG_MMC_ATMELMCI=m +CONFIG_NEW_LEDS=y +CONFIG_LEDS_CLASS=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGERS=y +CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AT91SAM9=y CONFIG_IIO=y CONFIG_AT91_ADC=y -CONFIG_EXT2_FS=y -CONFIG_MSDOS_FS=y +CONFIG_PWM=y +CONFIG_PWM_ATMEL=y +CONFIG_EXT4_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y CONFIG_UBIFS_FS=y @@ -77,7 +87,6 @@ CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_UTF8=y -CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_USER=y CONFIG_DEBUG_LL=y -- 1.9.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/
[PATCH 7/7] ARM: at91: sama5: update defconfig
Update defconfig, adding: - PWM support using the generic framework - generic PWM leds - Power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/sama5_defconfig | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig index 4414990521d3..eaff1292d09f 100644 --- a/arch/arm/configs/sama5_defconfig +++ b/arch/arm/configs/sama5_defconfig @@ -21,7 +21,6 @@ CONFIG_SOC_SAM_V7=y CONFIG_SOC_SAMA5D3=y CONFIG_MACH_SAMA5_DT=y CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_UACCESS_WITH_MEMCPY=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 @@ -65,7 +64,6 @@ CONFIG_DEVTMPFS_MOUNT=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_CFI=y CONFIG_MTD_M25P80=y @@ -73,7 +71,6 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_ATMEL=y CONFIG_MTD_UBI=y CONFIG_MTD_UBI_GLUEBI=y -CONFIG_PROC_DEVICETREE=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=4 @@ -83,10 +80,8 @@ CONFIG_ATMEL_SSC=y CONFIG_EEPROM_AT24=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y # CONFIG_SCSI_LOWLEVEL is not set CONFIG_NETDEVICES=y -CONFIG_MII=y CONFIG_MACB=y # CONFIG_NET_VENDOR_BROADCOM is not set # CONFIG_NET_VENDOR_CIRRUS is not set @@ -135,6 +130,8 @@ CONFIG_SPI=y CONFIG_SPI_ATMEL=y CONFIG_SPI_GPIO=y CONFIG_GPIO_SYSFS=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_SSB=m CONFIG_REGULATOR=y @@ -165,6 +162,7 @@ CONFIG_MMC_ATMELMCI=y CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_LEDS_TRIGGER_GPIO=y @@ -174,6 +172,8 @@ CONFIG_DMADEVICES=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_IIO=y CONFIG_AT91_ADC=y +CONFIG_PWM=y +CONFIG_PWM_ATMEL=y CONFIG_EXT4_FS=y CONFIG_FANOTIFY=y CONFIG_VFAT_FS=y @@ -188,8 +188,8 @@ CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_STRIP_ASM_SYMS=y CONFIG_DEBUG_FS=y -# CONFIG_SCHED_DEBUG is not set CONFIG_DEBUG_MEMORY_INIT=y +# CONFIG_SCHED_DEBUG is not set # CONFIG_FTRACE is not set CONFIG_DEBUG_USER=y CONFIG_DEBUG_LL=y -- 1.9.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/
[PATCH 4/7] ARM: at91: at91sam9263: update defconfig
Update defconfig, adding: - PWM support using the generic framework - generic PWM leds - Power/reset and removing deprecated config options. Signed-off-by: Alexandre Belloni --- arch/arm/configs/at91sam9263_defconfig | 13 ++--- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/arch/arm/configs/at91sam9263_defconfig b/arch/arm/configs/at91sam9263_defconfig index e40026364e57..8b671c977b81 100644 --- a/arch/arm/configs/at91sam9263_defconfig +++ b/arch/arm/configs/at91sam9263_defconfig @@ -18,7 +18,6 @@ CONFIG_MACH_AT91SAM9263EK=y CONFIG_MTD_AT91_DATAFLASH_CARD=y # CONFIG_ARM_THUMB is not set CONFIG_AEABI=y -# CONFIG_OABI_COMPAT is not set CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_CMDLINE="mem=64M console=ttyS0,115200 initrd=0x2110,3145728 root=/dev/ram0 rw" @@ -51,7 +50,6 @@ CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CMDLINE_PARTS=y -CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_NFTL=y CONFIG_NFTL_RW=y @@ -64,13 +62,10 @@ CONFIG_MTD_UBI_GLUEBI=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=8192 -CONFIG_ATMEL_PWM=y CONFIG_ATMEL_TCLIB=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y -CONFIG_SCSI_MULTI_LUN=y CONFIG_NETDEVICES=y -CONFIG_MII=y CONFIG_MACB=y CONFIG_SMSC_PHY=y # CONFIG_WLAN is not set @@ -92,6 +87,8 @@ CONFIG_I2C_GPIO=y CONFIG_SPI=y CONFIG_SPI_ATMEL=y CONFIG_GPIO_SYSFS=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y CONFIG_WATCHDOG_NOWAYOUT=y @@ -103,7 +100,6 @@ CONFIG_LCD_CLASS_DEVICE=y CONFIG_BACKLIGHT_CLASS_DEVICE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y -CONFIG_FONTS=y CONFIG_LOGO=y CONFIG_SOUND=y CONFIG_SND=y @@ -129,12 +125,14 @@ CONFIG_SDIO_UART=m CONFIG_MMC_ATMELMCI=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y -CONFIG_LEDS_ATMEL_PWM=y CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_AT91SAM9=y +CONFIG_PWM=y +CONFIG_PWM_ATMEL=y CONFIG_EXT4_FS=y CONFIG_VFAT_FS=y CONFIG_TMPFS=y @@ -150,3 +148,4 @@ CONFIG_NLS_ISO8859_1=y CONFIG_NLS_UTF8=y CONFIG_DEBUG_USER=y CONFIG_XZ_DEC=y +CONFIG_FONTS=y -- 1.9.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/
Re: [PATCH v6 2/6] arm64: ptrace: allow tracer to skip a system call
On 09/01/2014 08:47 PM, Russell King - ARM Linux wrote: On Wed, Aug 27, 2014 at 02:55:46PM +0900, AKASHI Takahiro wrote: 1) setting x0 to -ENOSYS is necessary because, otherwise, user-issued syscall(-1) will return a bogus value when audit tracing is on. Please note that, on arm, not traced traced -- -- syscall(-1) aborted OOPs(BUG_ON) syscall(-3000) aborted aborted syscall(1000)ENOSYS ENOSYS Two points here: 1. You've found a case which causes a BUG_ON(). Where is the bug report for this, so the problem can be investigated and resolved? I think that I mentioned it could also happen on arm somewhere in a talk with Will, but don't remember exactly when. 2. What do you mean by "aborted" ? I mean that the process will receive SIGILL and get aborted. A system call number, like -1 and -3000, won't be trapped by *switch* statement in asm_syscall() and end up with being signaled. Please, if you find a problem with 32-bit ARM, report it. Don't hide it, because hiding it can be a security issue or in the case of BUG_ON(), it could be a denial of service issue. As you're part of Linaro, I would have thought you'd be more responsible in this regard - after all, Linaro is supposed to be about improving the ARM kernel... Maybe I got that wrong, and Linaro is actually about ensuring that the ARM kernel is stuffed full of broken features? I thought my first priority was on arm64 (and then arm), but now that you and Will seem to want to see the fix first on arm, okey, I will start with arm issue. Thanks, -Takahiro AKASHI -- 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/
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Tue, Sep 2, 2014 at 11:00 AM, Lee Jones wrote: > On Mon, 01 Sep 2014, Johan Hovold wrote: >> On Mon, Sep 01, 2014 at 07:22:39PM +0300, Octavian Purdila wrote: >> > On Mon, Sep 1, 2014 at 6:46 PM, Lee Jones wrote: >> > > On Mon, 01 Sep 2014, Octavian Purdila wrote: >> > > >> > >> On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: >> > >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: >> > >> >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones >> > >> >> wrote: >> >> > >> >> > You should have a small MFD driver which controls resources and >> > >> >> > registers children. All other functionality should live in their >> > >> >> > respective drivers/X locations i.e. USB functionallity should >> > >> >> > normally >> > >> >> > live in drivers/usb. >> > >> >> > >> > >> >> >> > >> >> OK, that sounds better. I am not sure how to handle the registration >> > >> >> part though, since in this case we need to create the children at >> > >> >> runtime, from the usb probe routine. >> > >> >> >> > >> >> The only solution I see is to move the driver completely to >> > >> >> usb/drivers and continue to use the MFD infrastructure. Does that >> > >> >> sound OK to you? >> > >> > >> > >> > I have no problem with that. If this is an MFD driver, it _should_ >> > >> > live in drivers/mfd. However, all of that USB specific stuff >> > >> > defiantly should not. >> > >> > >> > >> > >> It is a multi-function driver which is using the USB interface, so >> > >> > >> I >> > >> am not sure where it belongs. The only driver that calls >> > >> mfd_add_devices and is not in drivers/mfd is the hid sensor hub >> > >> driver. >> > >> >> > >> BTW, the mfd/viperboard.c driver is very similar with this driver. It >> > >> has less USB specific stuff because the protocol is simpler, but still >> > >> has some. >> > > >> > > Looking at viperboard.c, it seems to use some basic generic framework >> > > calls to obtain some information about the device information like >> > > version numbers. Your driver is leaps and bounds more USB centric. >> > > >> > > Your MFD driver should know about things like; regmap, platform data, >> > > memory allocation, same-chip devices (children), etc. Your MFD driver >> > > should not need to concern itself with; endpoints, slots, URBs, USB >> > > device IDs and the like. The later knowledge belongs in drivers/usb. >> > > >> > > You should be calling mfd_add_devices() from within the MFD driver. >> > > At a guess, I would say that you need a new entry for the USB stuff in >> > > your mfd_cells structure. >> > > >> > >> > Makes sense, thanks for making clearing up what the MFD part of the >> > driver should do. >> > >> > Here is how I think it could work: >> > >> > * keep the usb probe routine in the MFD driver (and keep it a usb driver) >> > >> > * add a new cell for the usb part >> > >> > * pass the usb_interface via platform_data to the USB sub-driver's >> > platform_device probe routine and continue the USB setup there >> > >> > Lee, USB folks, is this acceptable? >> >> No, no. USB is not a function of the MFD device, it's the transport. >> Thus there should be no USB MFD-cell. No subdriver can work without it. >> >> And the USB id belongs in the MFD-driver in the same way that an >> i2c id (address) does. >> >> Just like an MFD device with i2c as a transport, this driver would >> function as an arbiter to a shared resource (i.e. the register space). >> The reason it seems much more USB-centric than an i2c-mfd driver is that >> that transport API is simpler and some code have also already been >> generalised (e.g. regmap), whereas we appear to have only two USB >> mfd-drivers thus far. >> >> The viperboard is perhaps a bad example in so far that it has pushed the >> transport details down into the subdrivers (and thus into gpio, i2c and >> iio subsystems) instead of handling it one place. > > Thanks for your explanation. I take your point about the USB ID and I > did say I was guessing that the USB part should exist as a child > device. > > So after your comments I decided to do a little investigation. It > appears that this MFD driver is _just_ using the common API which all > other devices utilising USB comms are forced to use. Is that correct? > > If so, I have a question. Is there no way to hide more of the USB > specifics inside a better, simpler API? It looks like the drivers > which use USB are subjected to a lot (too much) of what might be > considered internals. Or is it just that the client has to tinker > with too many dials to get anything sensible out? *shudders* > Yes, the driver is just using the common USB API to communicate with the device. It is more complicated then the average USB driver because there is a single interface and a single receive endpoint which needs to serve multiple drivers and requests, thus the need to multiplex the communication. >> I haven't looked at the details of the protocol for the device in >> question, but it might even be possible to use regmap
Re: [RFC PATCH] netlink: Safer deletion of sk_bind_node
In one of our random test runs we observed the crash mentioned in the previous mail. After debugging we found out that the call flow of the inline and static functions were netlink_release -netlink_remove -__sk_del_bind_node --__hlist_del *pprev was NULL in __hlist_del function while deleting >sk_bind_node hlist_node. Hence the patch was given. In netlink_remove function , first the sk_del_node_init function will be called. This internally calls __sk_del_node_init function. While deleting >sk_node hlist_node using __sk_del_node function there is a NULL check with sk_hashed function. Why there is no NULL check for *pprev while deleting >sk_bind_node ? On Tuesday 02 September 2014 10:33 AM, David Miller wrote: > From: Harish Jenny K N > Date: Mon, 1 Sep 2014 12:38:29 +0530 > > Firstly, you really need to fix your outgoing email so that your email > address appears in your From: header properly. > >> From: Harish Jenny K N >> >> Unable to handle kernel NULL pointer dereference at virtual address >> >> (netlink_release+0x0/0x2a0) from [<8034e78c>] >> (sock_release+0x28/0xa4) >> (sock_release+0x0/0xa4) from [<8034e830>] (sock_close+0x28/0x34) >> (sock_close+0x0/0x34) from [<800f3490>] (__fput+0xf0/0x1ec) >> (__fput+0x0/0x1ec) from [<800f3634>] (fput+0x10/0x14) >> (fput+0x0/0x14) from [<80040a64>] (task_work_run+0xb8/0xd8) >> (task_work_run+0x0/0xd8) from [<800113a0>] >> (do_work_pending+0xb0/0xc4) >> (do_work_pending+0x0/0xc4) from [<8000d960>] (work_pending+0xc/0x20) >> Call flow of the inline and static functions >> netlink_release >> -netlink_remove >> -__sk_del_bind_node >> --__hlist_del >> >> Signed-off-by: Harish Jenny K N > This doesn't tell us anything about how this situation can be > arrived at. > > When subscriptions changes, we delete the node with the table lock > held if subscriptions goes to zero. We only try to delete the node > when subscriptions was zero. -- 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/
Re: [RESEND PATCH] arm64: dts: add symlink
On Tue, Sep 02, 2014 at 04:49:16AM +0100, Pankaj Dubey wrote:
> Add symlink to include/dt-bindings from arch/arm64/boot/dts/include/ to
> match the ones in ARM architectures so that preprocessed device
> tree files can include various useful constant definitions.
>
> See commit c58299aa8754 ("kbuild: create an "include chroot" for DT bindings")
> merged in v3.10-rc1 for details.
>
> CC: Catalin Marinas
> Signed-off-by: Pankaj Dubey
> ---
>
> Resubmitting this change as now it will be required for Samsung ARM64
> based SoC.
Just include this change in the series adding a .dts that needs it -- it
doesn't really make sense in isolation (unless somebody desperately wants
this in?).
Will
--
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/
Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"
Michel Dänzer writes:
> On 30.08.2014 22:59, Mikael Pettersson wrote:
> > Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> > after a while in X + firefox. This still occurs with yesterday's HEAD
> > of Linus' repo. 3.16 and ealier kernels are fine.
> >
> > I ran a bisect, which identified:
> >
> > commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
> > Author: Michel Dänzer
> > Date: Thu Jul 31 18:43:49 2014 +0900
> >
> > drm/radeon: Always flush the HDP cache before submitting a CS to the
> > GPU
> >
> > as the cause of my screen corruption. Reverting this from 3.17-rc2
> > (which requires manual intervention due to subsequent changes in
> > radeon_ring_commit()) eliminates the screen corruption.
>
> Does the patch below help?
Thanks for the patch, I'll test it on Friday evening when I'm
back home and have access to the affected machine.
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 4c5ec44..3ff9c53 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev,
> struct radeon_ring *ring)
> radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
> }
>
> +/**
> + * r100_mmio_hdp_flush - flush Host Data Path via MMIO
> + * rdev: radeon device structure
> + */
> +void r100_mmio_hdp_flush(struct radeon_device *rdev)
> +{
> +WREG32(RADEON_HOST_PATH_CNTL,
> + rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
> +(void)RREG32(RADEON_HOST_PATH_CNTL);
> +WREG32(RADEON_HOST_PATH_CNTL,
> + rdev->config.r100.hdp_cntl);
> +(void)RREG32(RADEON_HOST_PATH_CNTL);
> +}
> +
> static void r100_cp_load_microcode(struct radeon_device *rdev)
> {
> const __be32 *fw_data;
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
> b/drivers/gpu/drm/radeon/radeon_asic.c
> index abe..c23a123 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.c
> +++ b/drivers/gpu/drm/radeon/radeon_asic.c
> @@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
> .resume = _resume,
> .vga_set_state = _vga_set_state,
> .asic_reset = _asic_reset,
> -.mmio_hdp_flush = NULL,
> +.mmio_hdp_flush = r100_mmio_hdp_flush,
> .gui_idle = _gui_idle,
> .mc_wait_for_idle = _mc_wait_for_idle,
> .gart = {
> diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
> b/drivers/gpu/drm/radeon/radeon_asic.h
> index 275a5dc..e9b1c35 100644
> --- a/drivers/gpu/drm/radeon/radeon_asic.h
> +++ b/drivers/gpu/drm/radeon/radeon_asic.h
> @@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
> struct radeon_ring *ring);
> void r100_ring_hdp_flush(struct radeon_device *rdev,
> struct radeon_ring *ring);
> +void r100_mmio_hdp_flush(struct radeon_device *rdev);
> +
> /*
> * r200,rv250,rs300,rv280
> */
> diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
> b/drivers/gpu/drm/radeon/radeon_gem.c
> index bfd7e1b..3d0f564 100644
> --- a/drivers/gpu/drm/radeon/radeon_gem.c
> +++ b/drivers/gpu/drm/radeon/radeon_gem.c
> @@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev,
> void *data,
> r = radeon_bo_wait(robj, _placement, false);
> /* Flush HDP cache via MMIO if necessary */
> if (rdev->asic->mmio_hdp_flush &&
> +!rdev->asic->ring[RADEON_RING_TYPE_GFX_INDEX]->hdp_flush &&
> radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
> robj->rdev->asic->mmio_hdp_flush(rdev);
> drm_gem_object_unreference_unlocked(gobj);
> diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
> b/drivers/gpu/drm/radeon/radeon_ring.c
> index d656079..b82843b 100644
> --- a/drivers/gpu/drm/radeon/radeon_ring.c
> +++ b/drivers/gpu/drm/radeon/radeon_ring.c
> @@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev,
> struct radeon_ring *ring,
> /* If we are emitting the HDP flush via the ring buffer, we need to
> * do it before padding.
> */
> -if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
> +if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
> +!rdev->asic->mmio_hdp_flush)
> rdev->asic->ring[ring->idx]->hdp_flush(rdev, ring);
> /* We pad to match fetch size */
> while (ring->wptr & ring->align_mask) {
>
>
>
> --
> Earthling Michel Dänzer| http://www.amd.com
> Libre software enthusiast |Mesa and X developer
--
--
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/
Re: [PATCH v2 06/12] ARM: at91: add MTD_SPI_NOR (new dependency for M25P80)
On 01/05/2014 08:26, Brian Norris : > This defconfig contains the CONFIG_M25P80 symbol, which is now > dependent on the MTD_SPI_NOR symbol. Add CONFIG_MTD_SPI_NOR to satisfy > the new dependency. > > At the same time, drop the now-nonexistent CONFIG_MTD_CHAR symbol. > > Signed-off-by: Brian Norris > Cc: Andrew Victor > Cc: Nicolas Ferre Okay, now taken in at91-3.18-defconfig, thanks: Acked-by: Nicolas Ferre > Cc: Jean-Christophe Plagniol-Villard > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > arch/arm/configs/sama5_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/configs/sama5_defconfig > b/arch/arm/configs/sama5_defconfig > index dc3881e07630..8282ebab6e52 100644 > --- a/arch/arm/configs/sama5_defconfig > +++ b/arch/arm/configs/sama5_defconfig > @@ -65,12 +65,12 @@ CONFIG_DEVTMPFS_MOUNT=y > # CONFIG_PREVENT_FIRMWARE_BUILD is not set > CONFIG_MTD=y > CONFIG_MTD_CMDLINE_PARTS=y > -CONFIG_MTD_CHAR=y > CONFIG_MTD_BLOCK=y > CONFIG_MTD_CFI=y > CONFIG_MTD_M25P80=y > CONFIG_MTD_NAND=y > CONFIG_MTD_NAND_ATMEL=y > +CONFIG_MTD_SPI_NOR=y > CONFIG_MTD_UBI=y > CONFIG_MTD_UBI_GLUEBI=y > CONFIG_PROC_DEVICETREE=y > -- Nicolas Ferre -- 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/
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Tue, 02 Sep 2014, Arnd Bergmann wrote:
> On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> >
> > > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > > migration path. What I want to end up with is infrastructure that
> > > > > lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > > without needing the platform_driver for syscon. That should not
> > > > > require any form of compatibility layer because to the driver
> > > > > using it there is no API change.
> > > >
> > > > Somehow I think the likelyhood is that I am misreading the patch.
> > > >
> > > > I thought that before this patch drivers we had to register a syscon
> > > > device to bind to this driver, which was fine for the first use-cases
> > > > of syscon as it wasn't required too early during boot. However, now
> > > > there are use-cases where systems require access to syscon registers
> > > > eariler in boot we require a means to obtain access prior to device
> > > > probing. I thought this patch not only provides that possibilty, but
> > > > also leaves in the ability to register direct from DT.
> > >
> > > Right, it does provide the ability to have syscon before devices
> > > are registered, I missed that part.
> > >
> > > > > In contrast, this patch introduces a new of_syscon_{un,}register()
> > > > > interface that would get removed after the the above has
> > > > > been implemented, causing extra churn for any driver that also
> > > > > wants to provide a regmap-like interface.
> > > >
> > > > When will we ever not have to register syscon?
> > >
> > > The idea is that we implicitly register the syscon block when someone
> > > calls syscon_regmap_lookup_by_compatible or
> > > syscon_regmap_lookup_by_phandle
> > > and then return a reference to that new syscon. When another driver
> > > looks up the same device node, we just pass a reference to the existing
> > > syscon.
> >
> > Doesn't sound too unreasonable. So how about instead of exporting
> > these new of_syscon_{un,}register() calls, we make them static and
> > call them from syscon_regmap_lookup_by_{phandle,compatible}?
>
> Yes, that would be a good start. We should think about whether we want
> to remove the existing DT probing at the same time, since it becomes
> unused, and we might want to move the code to drivers/base/regmap_*.c
> at some point
I'd support that move - and can even draft the patch if required.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
RE: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Tuesday, September 02, 2014 1:45 PM
> To: linux-arm-ker...@lists.infradead.org
> Cc: Lee Jones; kgene@samsung.com; li...@arm.linux.org.uk;
> naus...@samsung.com; Pankaj Dubey; Tomasz Figa;
linux-kernel@vger.kernel.org;
> jo...@samsung.com; vikas.saj...@samsung.com; linux-samsung-
> s...@vger.kernel.org; broo...@kernel.org; thomas...@samsung.com;
> chow@samsung.com
> Subject: Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon
devices
>
> On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> >
> > > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > > migration path. What I want to end up with is infrastructure
> > > > > that lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > > without needing the platform_driver for syscon. That should not
> > > > > require any form of compatibility layer because to the driver
> > > > > using it there is no API change.
> > > >
> > > > Somehow I think the likelyhood is that I am misreading the patch.
> > > >
> > > > I thought that before this patch drivers we had to register a
> > > > syscon device to bind to this driver, which was fine for the first
> > > > use-cases of syscon as it wasn't required too early during boot.
> > > > However, now there are use-cases where systems require access to
> > > > syscon registers eariler in boot we require a means to obtain
> > > > access prior to device probing. I thought this patch not only
> > > > provides that possibilty, but also leaves in the ability to register
direct from
> DT.
> > >
> > > Right, it does provide the ability to have syscon before devices are
> > > registered, I missed that part.
> > >
> > > > > In contrast, this patch introduces a new
> > > > > of_syscon_{un,}register() interface that would get removed after
> > > > > the the above has been implemented, causing extra churn for any
> > > > > driver that also wants to provide a regmap-like interface.
> > > >
> > > > When will we ever not have to register syscon?
> > >
> > > The idea is that we implicitly register the syscon block when
> > > someone calls syscon_regmap_lookup_by_compatible or
> > > syscon_regmap_lookup_by_phandle and then return a reference to that
> > > new syscon. When another driver looks up the same device node, we
> > > just pass a reference to the existing syscon.
> >
> > Doesn't sound too unreasonable. So how about instead of exporting
> > these new of_syscon_{un,}register() calls, we make them static and
> > call them from syscon_regmap_lookup_by_{phandle,compatible}?
>
> Yes, that would be a good start. We should think about whether we want to
remove
> the existing DT probing at the same time, since it becomes unused, and we
might
> want to move the code to drivers/base/regmap_*.c at some point.
>
OK, I am working on these two parts. Once code is in proper form and tested
on
our setup I will post here.
Thanks,
Pankaj
> Arnd
--
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/
Re: [PATCH] fs: replace int param with size_t for seq_open_private()
On 01/09/14 22:22, Al Viro wrote: On Mon, Sep 01, 2014 at 03:38:51PM +0100, Rob Jones wrote: kmalloc where it is expected to be a size_t. Which is a mistake too because allocations are never that large. Yet. *raised eyebrow* You do realize that kmalloc() gives physically contiguous allocation, right? Do please try to not be quite so patronizing. It's very counter- productive. And refuses to allocate more than KMALLOC_MAX_SIZE, while we are at it. With allocations anywhere near such range being very heavily discouraged. There might or might not be point in using size_t for kmalloc() argument, but "future-proofing" isn't it. Indeed, and I am following up those arguments with people that may want to be constructive. -- Rob Jones Codethink Ltd mailto:rob.jo...@codethink.co.uk tel:+44 161 236 5575 -- 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/
[PATCH net v2] ipv6: fix rtnl locking in setsockopt for anycast and multicast
Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST
triggers the assertion in addrconf_join_solict()/addrconf_leave_solict()
ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to
take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with
ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before
calling ipv6_dev_mc_inc/dec.
This patch moves ASSERT_RTNL() up a level in the call stack.
Signed-off-by: Cong Wang
Signed-off-by: Sabrina Dubroca
Reported-by: Tommi Rantala
---
As was said earlier, this should go in stable.
v2:
- based on net
- keep dev_get_by_flags_rcu and RCU in ipv6_sock_ac_*
- remove two ASSERT_RTNL() that are not necessary
Thank you for your help, Hannes!
net/ipv6/addrconf.c | 15 +--
net/ipv6/anycast.c | 12
net/ipv6/mcast.c| 14 ++
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 0b239fc1816e..aa0e135b808c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1690,14 +1690,12 @@ void addrconf_dad_failure(struct inet6_ifaddr *ifp)
addrconf_mod_dad_work(ifp, 0);
}
-/* Join to solicited addr multicast group. */
-
+/* Join to solicited addr multicast group.
+ * caller must hold RTNL */
void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- ASSERT_RTNL();
-
if (dev->flags&(IFF_LOOPBACK|IFF_NOARP))
return;
@@ -1705,12 +1703,11 @@ void addrconf_join_solict(struct net_device *dev, const
struct in6_addr *addr)
ipv6_dev_mc_inc(dev, );
}
+/* caller must hold RTNL */
void addrconf_leave_solict(struct inet6_dev *idev, const struct in6_addr *addr)
{
struct in6_addr maddr;
- ASSERT_RTNL();
-
if (idev->dev->flags&(IFF_LOOPBACK|IFF_NOARP))
return;
@@ -1718,12 +1715,11 @@ void addrconf_leave_solict(struct inet6_dev *idev,
const struct in6_addr *addr)
__ipv6_dev_mc_dec(idev, );
}
+/* caller must hold RTNL */
static void addrconf_join_anycast(struct inet6_ifaddr *ifp)
{
struct in6_addr addr;
- ASSERT_RTNL();
-
if (ifp->prefix_len >= 127) /* RFC 6164 */
return;
ipv6_addr_prefix(, >addr, ifp->prefix_len);
@@ -1732,12 +1728,11 @@ static void addrconf_join_anycast(struct inet6_ifaddr
*ifp)
ipv6_dev_ac_inc(ifp->idev->dev, );
}
+/* caller must hold RTNL */
static void addrconf_leave_anycast(struct inet6_ifaddr *ifp)
{
struct in6_addr addr;
- ASSERT_RTNL();
-
if (ifp->prefix_len >= 127) /* RFC 6164 */
return;
ipv6_addr_prefix(, >addr, ifp->prefix_len);
diff --git a/net/ipv6/anycast.c b/net/ipv6/anycast.c
index 210183244689..45b9d81d91e8 100644
--- a/net/ipv6/anycast.c
+++ b/net/ipv6/anycast.c
@@ -77,6 +77,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const
struct in6_addr *addr)
pac->acl_next = NULL;
pac->acl_addr = *addr;
+ rtnl_lock();
rcu_read_lock();
if (ifindex == 0) {
struct rt6_info *rt;
@@ -137,6 +138,7 @@ int ipv6_sock_ac_join(struct sock *sk, int ifindex, const
struct in6_addr *addr)
error:
rcu_read_unlock();
+ rtnl_unlock();
if (pac)
sock_kfree_s(sk, pac, sizeof(*pac));
return err;
@@ -171,13 +173,17 @@ int ipv6_sock_ac_drop(struct sock *sk, int ifindex, const
struct in6_addr *addr)
spin_unlock_bh(_sk_ac_lock);
+ rtnl_lock();
rcu_read_lock();
dev = dev_get_by_index_rcu(net, pac->acl_ifindex);
if (dev)
ipv6_dev_ac_dec(dev, >acl_addr);
rcu_read_unlock();
+ rtnl_unlock();
sock_kfree_s(sk, pac, sizeof(*pac));
+ if (!dev)
+ return -ENODEV;
return 0;
}
@@ -198,6 +204,7 @@ void ipv6_sock_ac_close(struct sock *sk)
spin_unlock_bh(_sk_ac_lock);
prev_index = 0;
+ rtnl_lock();
rcu_read_lock();
while (pac) {
struct ipv6_ac_socklist *next = pac->acl_next;
@@ -212,6 +219,7 @@ void ipv6_sock_ac_close(struct sock *sk)
pac = next;
}
rcu_read_unlock();
+ rtnl_unlock();
}
static void aca_put(struct ifacaddr6 *ac)
@@ -233,6 +241,8 @@ int ipv6_dev_ac_inc(struct net_device *dev, const struct
in6_addr *addr)
struct rt6_info *rt;
int err;
+ ASSERT_RTNL();
+
idev = in6_dev_get(dev);
if (idev == NULL)
@@ -302,6 +312,8 @@ int __ipv6_dev_ac_dec(struct inet6_dev *idev, const struct
in6_addr *addr)
{
struct ifacaddr6 *aca, *prev_aca;
+ ASSERT_RTNL();
+
write_lock_bh(>lock);
prev_aca = NULL;
for (aca = idev->ac_list; aca; aca = aca->aca_next) {
diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 617f0958e164..a23b655a7627 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
@@
Re: [Linaro-acpi] [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
On 1 September 2014 19:35, Marc Zyngier wrote: > > On 01/09/14 15:57, Hanjun Guo wrote: > > From: Tomasz Nowicki > > > > ACPI kernel uses MADT table for proper GIC initialization. It needs to > > parse GIC related subtables, collect CPU interface and distributor > > addresses and call driver initialization function (which is hardware > > abstraction agnostic). In a similar way, FDT initialize GICv1/2. > > > > NOTE: This commit allow to initialize GICv1/2 only. > > I cannot help but notice that there is no support for KVM here. It'd be > good to add a note to that effect, so that people do not expect > virtualization support to be working when booting with ACPI. Just a heads up for this, I run up to this problem too while testing and by forcing some values for vgic and arch_timers I could boot a QEMU guest without problems. I'll try and see if it will be easy to handle this more properly instead of hardcoded values. Regards. -- 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/
Re: [PATCH v2] drm/i915: Fix lock dropping in intel_tv_detect()
On Tue, Sep 02, 2014 at 11:16:12AM +0300, Ville Syrjälä wrote: > On Tue, Sep 02, 2014 at 10:41:05AM +0300, Jani Nikula wrote: > > On Mon, 01 Sep 2014, Chris Wilson wrote: > > > On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote: > > >> On Mon, Sep 01, 2014 at 11:20:09AM +0100, Chris Wilson wrote: > > >> > On Mon, Sep 01, 2014 at 01:07:40PM +0300, > > >> > ville.syrj...@linux.intel.com wrote: > > >> > > From: Ville Syrjälä > > >> > > > > >> > > When intel_tv_detect() fails to do load detection it would forget to > > >> > > drop the locks and clean up the acquire context. Fix it up. > > >> > > > > >> > > This is a regression from: > > >> > > commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 > > >> > > Author: Ville Syrjälä > > >> > > Date: Mon Aug 11 13:15:35 2014 +0300 > > >> > > > > >> > > drm/i915: Fix locking for intel_enable_pipe_a() > > >> > > > > >> > > v2: Make the code more readable (Chris) > > >> > > > > >> > > Cc: Tibor Billes > > >> > > Signed-off-by: Ville Syrjälä > > >> > > > >> > Hmm, if we use WARN_ON() you should init type. > > >> > > >> type is always set in the branch that sets status=connected. > > > > > > Back to thinking about readability and making sure that the WARN_ON > > > never happens with just a glance. Otherwise, the WARN_ON would be better > > > as WARN_ON(unsigned)type >= last_tv_type); Or something. Anway, take > > > your pick and slap my r-b on it. :) > > > > Ville? > > I don't know anymore. Just kill the WARN_ON() if it makes things > confusing? Just drop the WARN_ON. I prefer the if() using the status rather than type, as that seems more idiomatic (when looking at our other detection routines). -Chris -- Chris Wilson, Intel Open Source Technology Centre -- 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/
Re: NFC depmod dependecy cycles
On 09/02/2014 10:23 AM, Daniel Wagner wrote: > Hi Samuel, > > I just tried 3.17-rc3 and run into this problem: > > # make modules_install > > DEPMOD 3.17.0-rc3-2-g7505cea > depmod: WARNING: found 6 modules in dependency cycles! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/drivers/nfc/st21nfcb/st21nfcb.ko > in dependency cycle! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/drivers/nfc/st21nfcb/ndlc.ko > in dependency cycle! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/rfkill/rfkill.ko in > dependency cycle! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/nfc/nfc.ko in > dependency cycle! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/nfc/nci/nci.ko in > dependency cycle! > depmod: WARNING: > /lib/modules/3.17.0-rc3-2-g7505cea/kernel/lib/crc-ccitt.ko in > dependency cycle! > ./scripts/depmod.sh: line 57: 23387 Segmentation fault (core > dumped) "$DEPMOD" "$@" "$KERNELRELEASE" $SYMBOL_PREFIX > make: *** [_modinst_post] Error 139 > > > After disabling the whole NFC subsystem depmod was happy again. Forgot to add my configuration: CONFIG_NFC=m CONFIG_NFC_DIGITAL=m CONFIG_NFC_NCI=m CONFIG_NFC_NCI_SPI=y CONFIG_NFC_HCI=m CONFIG_NFC_SHDLC=y # # Near Field Communication (NFC) devices # CONFIG_NFC_PN533=m CONFIG_NFC_WILINK=m CONFIG_NFC_TRF7970A=m CONFIG_NFC_MEI_PHY=m CONFIG_NFC_SIM=m CONFIG_NFC_PORT100=m CONFIG_NFC_PN544=m CONFIG_NFC_PN544_I2C=m CONFIG_NFC_PN544_MEI=m CONFIG_NFC_MICROREAD=m CONFIG_NFC_MICROREAD_I2C=m CONFIG_NFC_MICROREAD_MEI=m CONFIG_NFC_MRVL=m CONFIG_NFC_MRVL_USB=m CONFIG_NFC_ST21NFCA=m CONFIG_NFC_ST21NFCA_I2C=m CONFIG_NFC_ST21NFCB=m CONFIG_NFC_ST21NFCB_I2C=m cheers, daniel -- 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/
NFC depmod dependecy cycles
Hi Samuel, I just tried 3.17-rc3 and run into this problem: # make modules_install DEPMOD 3.17.0-rc3-2-g7505cea depmod: WARNING: found 6 modules in dependency cycles! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/drivers/nfc/st21nfcb/st21nfcb.ko in dependency cycle! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/drivers/nfc/st21nfcb/ndlc.ko in dependency cycle! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/rfkill/rfkill.ko in dependency cycle! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/nfc/nfc.ko in dependency cycle! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/net/nfc/nci/nci.ko in dependency cycle! depmod: WARNING: /lib/modules/3.17.0-rc3-2-g7505cea/kernel/lib/crc-ccitt.ko in dependency cycle! ./scripts/depmod.sh: line 57: 23387 Segmentation fault (core dumped) "$DEPMOD" "$@" "$KERNELRELEASE" $SYMBOL_PREFIX make: *** [_modinst_post] Error 139 After disabling the whole NFC subsystem depmod was happy again. cheers, daniel -- 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/
Re: [PATCH 1/2] fsnotify/fdinfo: use named constants instead of hardcoded values
On Tue, Sep 02, 2014 at 12:14:08PM +0400, Cyrill Gorcunov wrote: > On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote: > > MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64 > > bytes, so exportfs_encode_inode_fh can return an error. > > > > Cc: Cyrill Gorcunov > > Cc: Alexander Viro > > Cc: Andrew Morton > > Signed-off-by: Andrey Vagin > Acked-by: Cyrill Gorcunov Btw, I think both are good candidates for @stable. -- 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/
[PATCH V2 1/4] clk: mvebu: Fix clk frequency value if SSCG is enabled
When the SSCG (Spread Spectrum Clock Generator) is enabled, it shifts
the frequency of the clock. The percentage is no more than 1% but when
the clock is used for a timer it leads to a clock drift.
This patch allows to correct the affected clock when the SSCG is
enabled. The check is done in an new optional function related to each
SoC: is_sscg_enabled(). The fix is done with the other new optional
function related to each SoC: fix_sscg_deviation. If one these
functions are not present then no correction is done on the clock
frequency.
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/common.c | 82 ++
drivers/clk/mvebu/common.h | 7
2 files changed, 89 insertions(+)
diff --git a/drivers/clk/mvebu/common.c b/drivers/clk/mvebu/common.c
index 25ceccf939ad..354bbadb3bce 100644
--- a/drivers/clk/mvebu/common.c
+++ b/drivers/clk/mvebu/common.c
@@ -26,8 +26,85 @@
* Core Clocks
*/
+#define SSCG_CONF_MODE(reg)(((reg) >> 16) & 0x3)
+#define SSCG_SPREAD_DOWN 0x0
+#define SSCG_SPREAD_UP 0x1
+#define SSCG_SPREAD_CENTRAL0x2
+#define SSCG_CONF_LOW(reg) (((reg) >> 8) & 0xFF)
+#define SSCG_CONF_HIGH(reg)((reg) & 0xFF)
+
static struct clk_onecell_data clk_data;
+/*
+ * This function can be used by the Kirkwood, the Armada 370, the
+ * Armada XP and the Armada 375 SoC. The name of the function was
+ * chosen following the dt convention: using the first known SoC
+ * compatible with it.
+ */
+u32 kirkwood_fix_sscg_deviation(struct device_node *np, u32 system_clk)
+{
+ struct device_node *sscg_np = NULL;
+ void __iomem *sscg_map;
+ u32 sscg_reg;
+ s32 low_bound, high_bound;
+ u64 freq_swing_half;
+
+ sscg_np = of_find_node_by_name(np, "sscg");
+ if (sscg_np == NULL) {
+ pr_err("cannot get SSCG register node\n");
+ return system_clk;
+ }
+
+ sscg_map = of_iomap(sscg_np, 0);
+ if (sscg_map == NULL) {
+ pr_err("cannot map SSCG register\n");
+ goto out;
+ }
+
+ sscg_reg = readl(sscg_map);
+ high_bound = SSCG_CONF_HIGH(sscg_reg);
+ low_bound = SSCG_CONF_LOW(sscg_reg);
+
+ if ((high_bound - low_bound) <= 0)
+ goto out;
+ /*
+* From Marvell engineer we got the following formula (when
+* this code was written, the datasheet was erroneous)
+* Spread percentage = 1/96 * (H - L) / H
+* H = SSCG_High_Boundary
+* L = SSCG_Low_Boundary
+*
+* As the deviation is half of spread then it lead to the
+* following formula in the code.
+*
+* To avoid an overflow and not lose any significant digit in
+* the same time we have to use a 64 bit integer.
+*/
+
+ freq_swing_half = (((u64)high_bound - (u64)low_bound)
+ * (u64)system_clk);
+ do_div(freq_swing_half, (2 * 96 * high_bound));
+
+ switch (SSCG_CONF_MODE(sscg_reg)) {
+ case SSCG_SPREAD_DOWN:
+ system_clk -= freq_swing_half;
+ break;
+ case SSCG_SPREAD_UP:
+ system_clk += freq_swing_half;
+ break;
+ case SSCG_SPREAD_CENTRAL:
+ default:
+ break;
+ }
+
+ iounmap(sscg_map);
+
+out:
+ of_node_put(sscg_np);
+
+ return system_clk;
+}
+
void __init mvebu_coreclk_setup(struct device_node *np,
const struct coreclk_soc_desc *desc)
{
@@ -62,6 +139,11 @@ void __init mvebu_coreclk_setup(struct device_node *np,
of_property_read_string_index(np, "clock-output-names", 1,
_name);
rate = desc->get_cpu_freq(base);
+
+ if (desc->is_sscg_enabled && desc->fix_sscg_deviation
+ && desc->is_sscg_enabled(base))
+ rate = desc->fix_sscg_deviation(np, rate);
+
clk_data.clks[1] = clk_register_fixed_rate(NULL, cpuclk_name, NULL,
CLK_IS_ROOT, rate);
WARN_ON(IS_ERR(clk_data.clks[1]));
diff --git a/drivers/clk/mvebu/common.h b/drivers/clk/mvebu/common.h
index f968b4d9df92..59efaa850bde 100644
--- a/drivers/clk/mvebu/common.h
+++ b/drivers/clk/mvebu/common.h
@@ -28,6 +28,8 @@ struct coreclk_soc_desc {
u32 (*get_tclk_freq)(void __iomem *sar);
u32 (*get_cpu_freq)(void __iomem *sar);
void (*get_clk_ratio)(void __iomem *sar, int id, int *mult, int *div);
+ bool (*is_sscg_enabled)(void __iomem *sar);
+ u32 (*fix_sscg_deviation)(struct device_node *np, u32 system_clk);
const struct coreclk_ratio *ratios;
int num_ratios;
};
@@ -45,4 +47,9 @@ void __init mvebu_coreclk_setup(struct device_node *np,
void __init mvebu_clk_gating_setup(struct device_node *np,
const struct clk_gating_soc_desc *desc);
+/*
+ * This function is shared among the Kirkwood, Armada
[PATCH V2 4/4] clk: mvebu: armada-375: Fix the description of the SAR in the comment
For dealing with the code we use the SAR1 and not the SAR0. The code was correct, and now the comments too. Signed-off-by: Gregory CLEMENT --- drivers/clk/mvebu/armada-375.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/mvebu/armada-375.c b/drivers/clk/mvebu/armada-375.c index c991a4d95e10..c7af2242b796 100644 --- a/drivers/clk/mvebu/armada-375.c +++ b/drivers/clk/mvebu/armada-375.c @@ -27,14 +27,14 @@ * all modified at the same time, and not separately as for the Armada * 370 or the Armada XP SoCs. * - * SAR0[21:17] : CPU frequencyDDR frequency L2 frequency + * SAR1[21:17] : CPU frequencyDDR frequency L2 frequency * 6 = 400 MHz 400 MHz 200 MHz * 15 = 600 MHz 600 MHz 300 MHz * 21 = 800 MHz 534 MHz 400 MHz * 25 = 1000 MHz 500 MHz 500 MHz * others reserved. * - * SAR0[22] : TCLK frequency + * SAR1[22] : TCLK frequency * 0 = 166 MHz * 1 = 200 MHz */ -- 1.9.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/
[PATCH V2 0/4] clk: mvebu: Improve clock drift
Hi Mike, Jason, Andrew and Sebastian, Few users reported a timer drift on the Armada 370 based board such as the mirabox or the Netgear ReadyNAS 102. This is the second series with few improvements after the review of the 1st version. The reason is that when the SSCG (Spread Spectrum Clock Generator) is enabled, it shifts the frequency of the clock. The percentage is no more than 1% but when the clock is used for a timer it leads to a clock drift. This series allows to correct the affected clock when the SSCG is enabled. This drift can happen on all the mvebu SoC on the cpu clock block (ie cpu, ddr and l2 cache). Currently the only notable effect is for the Armada 370 because this SoC use the l2cache clock as source for the timer. That's why even if the series allow any of the mvebu SoC to benefit to this correction, Armada 370 is the only user of it. The first 2 patches should go through the clk subsystem, whereas the third one should go to the arm-soc through the mvebu tree. The last one is just to fix a typo I found while I was reading the clk code. Thanks, Gregory Changelog: v1 -> v2: - made the function a370_is_sscg_enabled() a static one - reword the comment to make clear that the formula in datasheet is erroneous - added a fix_sscg_deviation() callback in order to be able to deal with the Dove case which is different from the other mvebu SoCs Gregory CLEMENT (4): clk: mvebu: Fix clk frequency value if SSCG is enabled clk: mvebu: armada-370: Fix timer drift caused by the SSCG deviation ARM: mvebu: add SSCG to Armada 370 Device Tree clk: mvebu: armada-375: Fix the description of the SAR in the comment arch/arm/boot/dts/armada-370.dtsi | 4 ++ drivers/clk/mvebu/armada-370.c| 8 drivers/clk/mvebu/armada-375.c| 4 +- drivers/clk/mvebu/common.c| 82 +++ drivers/clk/mvebu/common.h| 7 5 files changed, 103 insertions(+), 2 deletions(-) -- 1.9.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/
Re: [PATCH v2] drm/i915: Fix lock dropping in intel_tv_detect()
On Tue, Sep 02, 2014 at 10:41:05AM +0300, Jani Nikula wrote: > On Mon, 01 Sep 2014, Chris Wilson wrote: > > On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote: > >> On Mon, Sep 01, 2014 at 11:20:09AM +0100, Chris Wilson wrote: > >> > On Mon, Sep 01, 2014 at 01:07:40PM +0300, ville.syrj...@linux.intel.com > >> > wrote: > >> > > From: Ville Syrjälä > >> > > > >> > > When intel_tv_detect() fails to do load detection it would forget to > >> > > drop the locks and clean up the acquire context. Fix it up. > >> > > > >> > > This is a regression from: > >> > > commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 > >> > > Author: Ville Syrjälä > >> > > Date: Mon Aug 11 13:15:35 2014 +0300 > >> > > > >> > > drm/i915: Fix locking for intel_enable_pipe_a() > >> > > > >> > > v2: Make the code more readable (Chris) > >> > > > >> > > Cc: Tibor Billes > >> > > Signed-off-by: Ville Syrjälä > >> > > >> > Hmm, if we use WARN_ON() you should init type. > >> > >> type is always set in the branch that sets status=connected. > > > > Back to thinking about readability and making sure that the WARN_ON > > never happens with just a glance. Otherwise, the WARN_ON would be better > > as WARN_ON(unsigned)type >= last_tv_type); Or something. Anway, take > > your pick and slap my r-b on it. :) > > Ville? I don't know anymore. Just kill the WARN_ON() if it makes things confusing? -- Ville Syrjälä Intel OTC -- 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/
[PATCH V2 3/4] ARM: mvebu: add SSCG to Armada 370 Device Tree
The Armada 370 SoC has a Spread Spectrum Clock Generator. This commit
adds the description of this generator to the Device Tree describing
this SoC.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-370.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/armada-370.dtsi
b/arch/arm/boot/dts/armada-370.dtsi
index 21b588b6f6bd..dfbbb709f4fb 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -206,6 +206,10 @@
status = "okay";
};
+ sscg@18330 {
+ reg = <0x18330 0x4>;
+ };
+
interrupt-controller@2 {
reg = <0x20a00 0x1d0>, <0x21870 0x58>;
};
--
1.9.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/
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Tuesday 02 September 2014 09:05:16 Lee Jones wrote:
> On Mon, 01 Sep 2014, Arnd Bergmann wrote:
>
> > On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > > migration path. What I want to end up with is infrastructure that
> > > > lets anybody call syscon_regmap_lookup_by_pdevname or
> > > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > > without needing the platform_driver for syscon. That should not
> > > > require any form of compatibility layer because to the driver
> > > > using it there is no API change.
> > >
> > > Somehow I think the likelyhood is that I am misreading the patch.
> > >
> > > I thought that before this patch drivers we had to register a syscon
> > > device to bind to this driver, which was fine for the first use-cases
> > > of syscon as it wasn't required too early during boot. However, now
> > > there are use-cases where systems require access to syscon registers
> > > eariler in boot we require a means to obtain access prior to device
> > > probing. I thought this patch not only provides that possibilty, but
> > > also leaves in the ability to register direct from DT.
> >
> > Right, it does provide the ability to have syscon before devices
> > are registered, I missed that part.
> >
> > > > In contrast, this patch introduces a new of_syscon_{un,}register()
> > > > interface that would get removed after the the above has
> > > > been implemented, causing extra churn for any driver that also
> > > > wants to provide a regmap-like interface.
> > >
> > > When will we ever not have to register syscon?
> >
> > The idea is that we implicitly register the syscon block when someone
> > calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
> > and then return a reference to that new syscon. When another driver
> > looks up the same device node, we just pass a reference to the existing
> > syscon.
>
> Doesn't sound too unreasonable. So how about instead of exporting
> these new of_syscon_{un,}register() calls, we make them static and
> call them from syscon_regmap_lookup_by_{phandle,compatible}?
Yes, that would be a good start. We should think about whether we want
to remove the existing DT probing at the same time, since it becomes
unused, and we might want to move the code to drivers/base/regmap_*.c
at some point.
Arnd
--
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/
[PATCH V2 2/4] clk: mvebu: armada-370: Fix timer drift caused by the SSCG deviation
This commit activates the SSCG deviation correction for the Armada
370. It uses the optional function introduced by the commit "clk:
mvebu: Fix clk frequency value if SSCG is enabled".
Without this fix the deviation measured on a Mirabox was of a few
second each hour, whereas with this fix it was reduced at around
50ppm (around 4s per day).
Signed-off-by: Gregory CLEMENT
---
drivers/clk/mvebu/armada-370.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/clk/mvebu/armada-370.c b/drivers/clk/mvebu/armada-370.c
index bef198a83863..756f0f39d6a3 100644
--- a/drivers/clk/mvebu/armada-370.c
+++ b/drivers/clk/mvebu/armada-370.c
@@ -23,6 +23,7 @@
*/
#define SARL 0 /* Low part [0:31] */
+#define SARL_A370_SSCG_ENABLE BIT(10)
#define SARL_A370_PCLK_FREQ_OPT11
#define SARL_A370_PCLK_FREQ_OPT_MASK 0xF
#define SARL_A370_FAB_FREQ_OPT 15
@@ -133,10 +134,17 @@ static void __init a370_get_clk_ratio(
}
}
+static bool a370_is_sscg_enabled(void __iomem *sar)
+{
+ return !(readl(sar) & SARL_A370_SSCG_ENABLE);
+}
+
static const struct coreclk_soc_desc a370_coreclks = {
.get_tclk_freq = a370_get_tclk_freq,
.get_cpu_freq = a370_get_cpu_freq,
.get_clk_ratio = a370_get_clk_ratio,
+ .is_sscg_enabled = a370_is_sscg_enabled,
+ .fix_sscg_deviation = kirkwood_fix_sscg_deviation,
.ratios = a370_coreclk_ratios,
.num_ratios = ARRAY_SIZE(a370_coreclk_ratios),
};
--
1.9.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/
Re: [PATCH 2/2] fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
On Tue, Sep 02, 2014 at 12:00:15PM +0400, Andrey Vagin wrote: > Currently we handle only ENOSPC. In case of other errors the file_handle > variable isn't filled properly and we will show a part of stack. > > Cc: Cyrill Gorcunov > Cc: Alexander Viro > Cc: Andrew Morton > Signed-off-by: Andrey Vagin Acked-by: Cyrill Gorcunov -- 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/
Re: [PATCH 1/2] fsnotify/fdinfo: use named constants instead of hardcoded values
On Tue, Sep 02, 2014 at 12:00:14PM +0400, Andrey Vagin wrote: > MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64 > bytes, so exportfs_encode_inode_fh can return an error. > > Cc: Cyrill Gorcunov > Cc: Alexander Viro > Cc: Andrew Morton > Signed-off-by: Andrey Vagin Acked-by: Cyrill Gorcunov -- 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/
Re: [PATCH] mfd: syscon: Decouple syscon interface from syscon devices
On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> On Monday 01 September 2014 17:04:26 Lee Jones wrote:
> > On Mon, 01 Sep 2014, Arnd Bergmann wrote:
> > > Maybe I'm misreading the patch, but I don't see how it creates a
> > > migration path. What I want to end up with is infrastructure that
> > > lets anybody call syscon_regmap_lookup_by_pdevname or
> > > syscon_regmap_lookup_by_compatible (if they really need to)
> > > without needing the platform_driver for syscon. That should not
> > > require any form of compatibility layer because to the driver
> > > using it there is no API change.
> >
> > Somehow I think the likelyhood is that I am misreading the patch.
> >
> > I thought that before this patch drivers we had to register a syscon
> > device to bind to this driver, which was fine for the first use-cases
> > of syscon as it wasn't required too early during boot. However, now
> > there are use-cases where systems require access to syscon registers
> > eariler in boot we require a means to obtain access prior to device
> > probing. I thought this patch not only provides that possibilty, but
> > also leaves in the ability to register direct from DT.
>
> Right, it does provide the ability to have syscon before devices
> are registered, I missed that part.
>
> > > In contrast, this patch introduces a new of_syscon_{un,}register()
> > > interface that would get removed after the the above has
> > > been implemented, causing extra churn for any driver that also
> > > wants to provide a regmap-like interface.
> >
> > When will we ever not have to register syscon?
>
> The idea is that we implicitly register the syscon block when someone
> calls syscon_regmap_lookup_by_compatible or syscon_regmap_lookup_by_phandle
> and then return a reference to that new syscon. When another driver
> looks up the same device node, we just pass a reference to the existing
> syscon.
Doesn't sound too unreasonable. So how about instead of exporting
these new of_syscon_{un,}register() calls, we make them static and
call them from syscon_regmap_lookup_by_{phandle,compatible}?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
[PATCH 2/2] fs/notify: don't show f_handle if exportfs_encode_inode_fh failed
Currently we handle only ENOSPC. In case of other errors the file_handle
variable isn't filled properly and we will show a part of stack.
Cc: Cyrill Gorcunov
Cc: Alexander Viro
Cc: Andrew Morton
Signed-off-by: Andrey Vagin
---
fs/notify/fdinfo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 660d33b..9d7e2b9 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -50,7 +50,7 @@ static int show_mark_fhandle(struct seq_file *m, struct inode
*inode)
size = f.handle.handle_bytes >> 2;
ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle,
, 0);
- if ((ret == FILEID_INVALID) || (ret == -ENOSPC)) {
+ if ((ret == FILEID_INVALID) || (ret < 0)) {
WARN_ONCE(1, "Can't encode file handler for inotify: %d\n",
ret);
return 0;
}
--
1.9.3
--
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/
[PATCH 1/2] fsnotify/fdinfo: use named constants instead of hardcoded values
MAX_HANDLE_SZ is equal to 128, but currently the size of pad is only 64
bytes, so exportfs_encode_inode_fh can return an error.
Cc: Cyrill Gorcunov
Cc: Alexander Viro
Cc: Andrew Morton
Signed-off-by: Andrey Vagin
---
fs/notify/fdinfo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/notify/fdinfo.c b/fs/notify/fdinfo.c
index 238a593..660d33b 100644
--- a/fs/notify/fdinfo.c
+++ b/fs/notify/fdinfo.c
@@ -42,7 +42,7 @@ static int show_mark_fhandle(struct seq_file *m, struct inode
*inode)
{
struct {
struct file_handle handle;
- u8 pad[64];
+ u8 pad[MAX_HANDLE_SZ];
} f;
int size, ret, i;
@@ -50,7 +50,7 @@ static int show_mark_fhandle(struct seq_file *m, struct inode
*inode)
size = f.handle.handle_bytes >> 2;
ret = exportfs_encode_inode_fh(inode, (struct fid *)f.handle.f_handle,
, 0);
- if ((ret == 255) || (ret == -ENOSPC)) {
+ if ((ret == FILEID_INVALID) || (ret == -ENOSPC)) {
WARN_ONCE(1, "Can't encode file handler for inotify: %d\n",
ret);
return 0;
}
--
1.9.3
--
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/
Re: [PATCH v2 1/3] mfd: add support for Diolan DLN-2 devices
On Mon, 01 Sep 2014, Johan Hovold wrote: > On Mon, Sep 01, 2014 at 07:22:39PM +0300, Octavian Purdila wrote: > > On Mon, Sep 1, 2014 at 6:46 PM, Lee Jones wrote: > > > On Mon, 01 Sep 2014, Octavian Purdila wrote: > > > > > >> On Mon, Sep 1, 2014 at 2:39 PM, Lee Jones wrote: > > >> > On Mon, 01 Sep 2014, Octavian Purdila wrote: > > >> >> On Mon, Sep 1, 2014 at 12:51 PM, Lee Jones > > >> >> wrote: > > > >> >> > You should have a small MFD driver which controls resources and > > >> >> > registers children. All other functionality should live in their > > >> >> > respective drivers/X locations i.e. USB functionallity should > > >> >> > normally > > >> >> > live in drivers/usb. > > >> >> > > > >> >> > > >> >> OK, that sounds better. I am not sure how to handle the registration > > >> >> part though, since in this case we need to create the children at > > >> >> runtime, from the usb probe routine. > > >> >> > > >> >> The only solution I see is to move the driver completely to > > >> >> usb/drivers and continue to use the MFD infrastructure. Does that > > >> >> sound OK to you? > > >> > > > >> > I have no problem with that. If this is an MFD driver, it _should_ > > >> > live in drivers/mfd. However, all of that USB specific stuff > > >> > defiantly should not. > > >> > > > >> > >> It is a multi-function driver which is using the USB interface, so I > > >> am not sure where it belongs. The only driver that calls > > >> mfd_add_devices and is not in drivers/mfd is the hid sensor hub > > >> driver. > > >> > > >> BTW, the mfd/viperboard.c driver is very similar with this driver. It > > >> has less USB specific stuff because the protocol is simpler, but still > > >> has some. > > > > > > Looking at viperboard.c, it seems to use some basic generic framework > > > calls to obtain some information about the device information like > > > version numbers. Your driver is leaps and bounds more USB centric. > > > > > > Your MFD driver should know about things like; regmap, platform data, > > > memory allocation, same-chip devices (children), etc. Your MFD driver > > > should not need to concern itself with; endpoints, slots, URBs, USB > > > device IDs and the like. The later knowledge belongs in drivers/usb. > > > > > > You should be calling mfd_add_devices() from within the MFD driver. > > > At a guess, I would say that you need a new entry for the USB stuff in > > > your mfd_cells structure. > > > > > > > Makes sense, thanks for making clearing up what the MFD part of the > > driver should do. > > > > Here is how I think it could work: > > > > * keep the usb probe routine in the MFD driver (and keep it a usb driver) > > > > * add a new cell for the usb part > > > > * pass the usb_interface via platform_data to the USB sub-driver's > > platform_device probe routine and continue the USB setup there > > > > Lee, USB folks, is this acceptable? > > No, no. USB is not a function of the MFD device, it's the transport. > Thus there should be no USB MFD-cell. No subdriver can work without it. > > And the USB id belongs in the MFD-driver in the same way that an > i2c id (address) does. > > Just like an MFD device with i2c as a transport, this driver would > function as an arbiter to a shared resource (i.e. the register space). > The reason it seems much more USB-centric than an i2c-mfd driver is that > that transport API is simpler and some code have also already been > generalised (e.g. regmap), whereas we appear to have only two USB > mfd-drivers thus far. > > The viperboard is perhaps a bad example in so far that it has pushed the > transport details down into the subdrivers (and thus into gpio, i2c and > iio subsystems) instead of handling it one place. Thanks for your explanation. I take your point about the USB ID and I did say I was guessing that the USB part should exist as a child device. So after your comments I decided to do a little investigation. It appears that this MFD driver is _just_ using the common API which all other devices utilising USB comms are forced to use. Is that correct? If so, I have a question. Is there no way to hide more of the USB specifics inside a better, simpler API? It looks like the drivers which use USB are subjected to a lot (too much) of what might be considered internals. Or is it just that the client has to tinker with too many dials to get anything sensible out? *shudders* > I haven't looked at the details of the protocol for the device in > question, but it might even be possible to use regmap here (as I > mentioned in my comments on v1). Obviously that would be preferred. Octavian, did you look into that? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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
Re: [PATCH v6 2/6] arm64: ptrace: allow tracer to skip a system call
On 09/01/2014 08:37 PM, Will Deacon wrote: On Wed, Aug 27, 2014 at 06:55:46AM +0100, AKASHI Takahiro wrote: On 08/27/2014 02:51 AM, Will Deacon wrote: On Fri, Aug 22, 2014 at 01:35:17AM +0100, AKASHI Takahiro wrote: Oops, you're absolutely right. I didn't think of this case. syscall_trace_enter() should not return a syscallno directly, but always return -1 if syscallno < 0. (except when secure_computing() returns with -1) This also implies that tracehook_report_syscall() should also have a return value. Will, is this fine with you? Well, the first thing that jumps out at me is why this is being done completely differently for arm64 and arm. I thought adding the new ptrace requests would reconcile the differences? I'm not sure what portion of my code you mentioned as "completely different", but 1) setting x0 to -ENOSYS is necessary because, otherwise, user-issued syscall(-1) will return a bogus value when audit tracing is on. Please note that, on arm, not traced traced -- -- syscall(-1) aborted OOPs(BUG_ON) syscall(-3000) aborted aborted syscall(1000)ENOSYS ENOSYS So, anyhow, its a bit difficult and meaningless to mimic these invalid cases. I'm not suggesting we make ourselves bug-compatible with ARM. Instead, I'd rather see a series of patches getting the ARM code working correctly, before we go off doing something different for arm64. I see. 2) branching a new label, syscall_trace_return_skip (see entry.S), after syscall_trace_enter() is necessary in order to avoid OOPS in audit_syscall_enter() as we discussed. Did I make it clear? Sure. So let's fix ARM, then look at the arm64 port after that. I really want to avoid divergence in this area. Okey, I will start with fixing the issue on arm. -Takahiro AKASHI Will -- 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/
Re: linux-next: jdelvare-hwmon tree unfetchable
Hi all, On Mon, 01 Sep 2014 08:49:36 -0700, Guenter Roeck wrote: > On 09/01/2014 05:28 AM, Mark Brown wrote: > > Today's linux-next merge of the jdelvare-hwmon tree got a conflict with > > Linus' > > tree which appeared to be due to the hwmon quilt series I got from Stephen > > being > > based on v3.14-rc3 and subsequent changes from mainline interacting badly > > with > > it. In addition I'm not able to check the original series since > > linux-fr.org does > > not resolve for me. > > Jean dropped the linux-fr.org domain, and his old e-mail address probably > won't work anymore. I can confirm that. linux-fr.org is history, from now on I'll be using my @suse.de address for all open source related work. I thought I had already updated all references and let everyone involved know about the change, but apparently I failed to do so, sorry about that. > The alternate (and temporary) pointer he gave me > is http://jdelvare.nerim.net/devel/linux-3/jdelvare-hwmon/. It is empty, > so you did not miss anything. That's right. As many temporary things, I'm afraid it's there to last ;-) -- Jean Delvare SUSE L3 Support -- 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/
Re: eeprom Board Information EEPROM
On Mon, Sep 01, 2014 at 01:52:10PM +0530, kavitha bk wrote: > On Sat, Aug 30, 2014 at 2:26 AM, Andreas Werner wrote: > > > I have a question regarding a driver for a Board Information EEPROM. > > > > I want to give our customer easy access to our Board Information EEPROM > > which is an 256byte I2C eeprom. > > > > > > > > There is a defined structure of information at the beginning of the eeprom > > which includes board name, serialnumber, production date, repair date and > > a eeprom structure ident number. > > > > The rest of the eeprom is for user defined settings where customer can > > write > > any data to. > > > > I want to have access to the eeprom without any special to and without > > installing > > anything just running linux and to a cat/echo to sysfs entries to > > read/write > > data to the eeprom. > > > > What i want to do is to create sysfs entries for the pre defined settings > > and > > on entrie where customer can access the rest of the eeprom bytes. > > > > Is drivers/misc/eeprom the right place to put those kind of driver in? > > > Yes You can add here > > > Or are > > there any other options to write those kind of driver? > > > > Which eeprom are you using? You can explore CONFIG_EEPROM_AT24 driver for > writing a sys interface > Ok i will check it out. Thanks. Regards Andy > > > > > > > Regards > > Andy > > -- > > 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/ > > -- 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/
[PATCH 0/5] clk: at91: fix USB clk support on at91rm9200/sam9 SoCs
Hi, This patch series fixes several bugs in the PLL driver preventing a proper set_rate on the PLL clk. It also enables propagation of set_rate request on the USB clk in order to configure the PLL rate according to the USB block requirement (48 MHz). Note that existing kernels, relying on the PLL configuration made by the the bootloader should not be impacted by this bug, but others (those directly booting from at91bootstrap or not enabling USB support in the bootloader) will be. This bug was reported by Gaël, who's directly booting the kernel from the bootstrap. Best Regards, Boris Boris BREZILLON (5): clk: at91: fix PLL_MAX_COUNT macro definition clk: at91: rework PLL rate calculation clk: at91: fix recalc_rate implementation of PLL driver clk: at91: rework rm9200 USB clock to propagate set_rate to the parent clk clk: at91: fix div by zero in USB clock driver drivers/clk/at91/clk-pll.c | 160 +++-- drivers/clk/at91/clk-usb.c | 20 -- 2 files changed, 96 insertions(+), 84 deletions(-) -- 1.9.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/
[PATCH 3/5] clk: at91: fix recalc_rate implementation of PLL driver
Use the cached values to calculate PLL rate instead of the register values.
This is required to prevent erroneous PLL rate return when the PLL rate
has been configured but the PLL is not prepared yet.
Signed-off-by: Boris BREZILLON
Reported-by: Gaël PORTAY
---
drivers/clk/at91/clk-pll.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index a1adcf1..6ec79db 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -151,16 +151,11 @@ static unsigned long clk_pll_recalc_rate(struct clk_hw
*hw,
unsigned long parent_rate)
{
struct clk_pll *pll = to_clk_pll(hw);
- const struct clk_pll_layout *layout = pll->layout;
- struct at91_pmc *pmc = pll->pmc;
- int offset = PLL_REG(pll->id);
- u32 tmp = pmc_read(pmc, offset) & layout->pllr_mask;
- u8 div = PLL_DIV(tmp);
- u16 mul = PLL_MUL(tmp, layout);
- if (!div || !mul)
+
+ if (!pll->div || !pll->mul)
return 0;
- return (parent_rate * (mul + 1)) / div;
+ return (parent_rate / pll->div) * (pll->mul + 1);
}
static long clk_pll_get_best_div_mul(struct clk_pll *pll, unsigned long rate,
--
1.9.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/
[PATCH 2/5] clk: at91: rework PLL rate calculation
The AT91 PLL rate configuration is done by configuring a multiplier/divider
pair.
The previous calculation was over-complicated (and apparently buggy).
Simplify the implementation and add some comments to explain what is done
here.
Signed-off-by: Boris BREZILLON
Reported-by: Gaël PORTAY
---
drivers/clk/at91/clk-pll.c | 147 -
1 file changed, 77 insertions(+), 70 deletions(-)
diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c
index 7b453b9..a1adcf1 100644
--- a/drivers/clk/at91/clk-pll.c
+++ b/drivers/clk/at91/clk-pll.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,6 +30,9 @@
#define PLL_DIV(reg) ((reg) & PLL_DIV_MASK)
#define PLL_MUL(reg, layout) (((reg) >> (layout)->mul_shift) & \
(layout)->mul_mask)
+#define PLL_MUL_MIN2
+#define PLL_MUL_MASK(layout) ((layout)->mul_mask)
+#define PLL_MUL_MAX(layout)(PLL_MUL_MASK(layout) + 1)
#define PLL_ICPR_SHIFT(id) ((id) * 16)
#define PLL_ICPR_MASK(id) (0x << PLL_ICPR_SHIFT(id))
#define PLL_MAX_COUNT 0x3f
@@ -163,99 +167,102 @@ static long clk_pll_get_best_div_mul(struct clk_pll
*pll, unsigned long rate,
unsigned long parent_rate,
u32 *div, u32 *mul,
u32 *index) {
- unsigned long maxrate;
- unsigned long minrate;
- unsigned long divrate;
- unsigned long bestdiv = 1;
- unsigned long bestmul;
- unsigned long tmpdiv;
- unsigned long roundup;
- unsigned long rounddown;
- unsigned long remainder;
- unsigned long bestremainder;
- unsigned long maxmul;
- unsigned long maxdiv;
- unsigned long mindiv;
- int i = 0;
const struct clk_pll_layout *layout = pll->layout;
const struct clk_pll_characteristics *characteristics =
pll->characteristics;
+ unsigned long bestremainder = ULONG_MAX;
+ unsigned long maxdiv, mindiv, tmpdiv;
+ long bestrate = -ERANGE;
+ unsigned long bestdiv;
+ unsigned long bestmul;
+ int i = 0;
- /* Minimum divider = 1 */
- /* Maximum multiplier = max_mul */
- maxmul = layout->mul_mask + 1;
- maxrate = (parent_rate * maxmul) / 1;
-
- /* Maximum divider = max_div */
- /* Minimum multiplier = 2 */
- maxdiv = PLL_DIV_MAX;
- minrate = (parent_rate * 2) / maxdiv;
-
+ /* Check if parent_rate is a valid input rate */
if (parent_rate < characteristics->input.min ||
- parent_rate < characteristics->input.max)
- return -ERANGE;
-
- if (parent_rate < minrate || parent_rate > maxrate)
+ parent_rate > characteristics->input.max)
return -ERANGE;
- for (i = 0; i < characteristics->num_output; i++) {
- if (parent_rate >= characteristics->output[i].min &&
- parent_rate <= characteristics->output[i].max)
- break;
- }
-
- if (i >= characteristics->num_output)
- return -ERANGE;
-
- bestmul = rate / parent_rate;
- rounddown = parent_rate % rate;
- roundup = rate - rounddown;
- bestremainder = roundup < rounddown ? roundup : rounddown;
-
- if (!bestremainder) {
- if (div)
- *div = bestdiv;
- if (mul)
- *mul = bestmul;
- if (index)
- *index = i;
- return rate;
- }
-
- maxdiv = 255 / (bestmul + 1);
- if (parent_rate / maxdiv < characteristics->input.min)
- maxdiv = parent_rate / characteristics->input.min;
- mindiv = parent_rate / characteristics->input.max;
- if (parent_rate % characteristics->input.max)
- mindiv++;
-
- for (tmpdiv = mindiv; tmpdiv < maxdiv; tmpdiv++) {
- divrate = parent_rate / tmpdiv;
-
- rounddown = rate % divrate;
- roundup = divrate - rounddown;
- remainder = roundup < rounddown ? roundup : rounddown;
-
+ /*
+* Calculate minimum divider based on the minimum multiplier, the
+* parent_rate and the requested rate.
+* Should always be 2 according to the input and output characteristics
+* of the PLL blocks.
+*/
+ mindiv = (parent_rate * PLL_MUL_MIN) / rate;
+ if (!mindiv)
+ mindiv = 1;
+
+ /*
+* Calculate the maximum divider which is limited by PLL register
+* layout (limited by the MUL or DIV field size).
+*/
+ maxdiv = DIV_ROUND_UP(parent_rate * PLL_MUL_MAX(layout), rate);
+ if (maxdiv > PLL_DIV_MAX)
+ maxdiv = PLL_DIV_MAX;
+
+ /*
+* Iterate over
[PATCH 4/5] clk: at91: rework rm9200 USB clock to propagate set_rate to the parent clk
The RM9200 USB clock is actually connected to a single parent (the PLLB)
on which we can apply a specific divider.
The USB clock divider does not allow for fine grained control on the USB
clock frequency, hence propagating the set_rate request to the parent is
the only choice we have to properly configure the USB clock rate.
Signed-off-by: Boris BREZILLON
Reported-by: Gaël PORTAY
---
drivers/clk/at91/clk-usb.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
index 7d1d26a..1838777 100644
--- a/drivers/clk/at91/clk-usb.c
+++ b/drivers/clk/at91/clk-usb.c
@@ -238,16 +238,22 @@ static long at91rm9200_clk_usb_round_rate(struct clk_hw
*hw, unsigned long rate,
unsigned long *parent_rate)
{
struct at91rm9200_clk_usb *usb = to_at91rm9200_clk_usb(hw);
+ struct clk *parent = __clk_get_parent(hw->clk);
unsigned long bestrate = 0;
int bestdiff = -1;
unsigned long tmprate;
int tmpdiff;
int i = 0;
- for (i = 0; i < 4; i++) {
+ for (i = 0; i < RM9200_USB_DIV_TAB_SIZE; i++) {
+ unsigned long tmp_parent_rate;
+
if (!usb->divisors[i])
continue;
- tmprate = *parent_rate / usb->divisors[i];
+
+ tmp_parent_rate = rate * usb->divisors[i];
+ tmp_parent_rate = __clk_round_rate(parent, tmp_parent_rate);
+ tmprate = tmp_parent_rate / usb->divisors[i];
if (tmprate < rate)
tmpdiff = rate - tmprate;
else
@@ -256,6 +262,7 @@ static long at91rm9200_clk_usb_round_rate(struct clk_hw
*hw, unsigned long rate,
if (bestdiff < 0 || bestdiff > tmpdiff) {
bestrate = tmprate;
bestdiff = tmpdiff;
+ *parent_rate = tmp_parent_rate;
}
if (!bestdiff)
@@ -311,7 +318,7 @@ at91rm9200_clk_register_usb(struct at91_pmc *pmc, const
char *name,
init.ops = _usb_ops;
init.parent_names = _name;
init.num_parents = 1;
- init.flags = 0;
+ init.flags = CLK_SET_RATE_PARENT;
usb->hw.init =
usb->pmc = pmc;
--
1.9.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/
[PATCH 1/5] clk: at91: fix PLL_MAX_COUNT macro definition
Signed-off-by: Boris BREZILLON Reported-by: Gaël PORTAY --- drivers/clk/at91/clk-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/at91/clk-pll.c b/drivers/clk/at91/clk-pll.c index cf6ed02..7b453b9 100644 --- a/drivers/clk/at91/clk-pll.c +++ b/drivers/clk/at91/clk-pll.c @@ -31,7 +31,7 @@ (layout)->mul_mask) #define PLL_ICPR_SHIFT(id) ((id) * 16) #define PLL_ICPR_MASK(id) (0x << PLL_ICPR_SHIFT(id)) -#define PLL_MAX_COUNT 0x3ff +#define PLL_MAX_COUNT 0x3f #define PLL_COUNT_SHIFT8 #define PLL_OUT_SHIFT 14 #define PLL_MAX_ID 1 -- 1.9.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/
[PATCH 5/5] clk: at91: fix div by zero in USB clock driver
Test rate value before calculating the div value to avoid div by zero.
Signed-off-by: Boris BREZILLON
Reported-by: Gaël PORTAY
---
drivers/clk/at91/clk-usb.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/at91/clk-usb.c b/drivers/clk/at91/clk-usb.c
index 1838777..24b5b02 100644
--- a/drivers/clk/at91/clk-usb.c
+++ b/drivers/clk/at91/clk-usb.c
@@ -279,10 +279,13 @@ static int at91rm9200_clk_usb_set_rate(struct clk_hw *hw,
unsigned long rate,
int i;
struct at91rm9200_clk_usb *usb = to_at91rm9200_clk_usb(hw);
struct at91_pmc *pmc = usb->pmc;
- unsigned long div = parent_rate / rate;
+ unsigned long div;
- if (parent_rate % rate)
+ if (!rate || parent_rate % rate)
return -EINVAL;
+
+ div = parent_rate / rate;
+
for (i = 0; i < RM9200_USB_DIV_TAB_SIZE; i++) {
if (usb->divisors[i] == div) {
tmp = pmc_read(pmc, AT91_CKGR_PLLBR) &
--
1.9.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/
Re: [PATCH] Input: cap1106 - fix register definition
On 09/02/2014 08:32 AM, Klaus Goger wrote: > Use the correct register address for Calibration Active and Interrupt > Enable > > Signed-off-by: Klaus Goger These register definitions are currently unused, but your fix is correct. Just curious - are you planning to send patches that make use of them? Acked-by: Daniel Mack Thanks, Daniel > --- > drivers/input/keyboard/cap1106.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/input/keyboard/cap1106.c > b/drivers/input/keyboard/cap1106.c > index 180b184..d70b65a 100644 > --- a/drivers/input/keyboard/cap1106.c > +++ b/drivers/input/keyboard/cap1106.c > @@ -33,8 +33,8 @@ > #define CAP1106_REG_SENSOR_CONFIG0x22 > #define CAP1106_REG_SENSOR_CONFIG2 0x23 > #define CAP1106_REG_SAMPLING_CONFIG 0x24 > -#define CAP1106_REG_CALIBRATION 0x25 > -#define CAP1106_REG_INT_ENABLE 0x26 > +#define CAP1106_REG_CALIBRATION 0x26 > +#define CAP1106_REG_INT_ENABLE 0x27 > #define CAP1106_REG_REPEAT_RATE 0x28 > #define CAP1106_REG_MT_CONFIG0x2a > #define CAP1106_REG_MT_PATTERN_CONFIG0x2b > -- 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/
Re: [PATCH v2] sched: Reduce contention in update_cfs_rq_blocked_load
On Mon, 2014-09-01 at 14:55 +0200, Peter Zijlstra wrote:
> But yes, unbounded errors here are a problem, sure relaxing the updates
> makes things go fast, they also make things go skew.
Okay. In that case, would you like to take our original patch which
avoids unnecessary updates?
-
Subject: [PATCH] sched: Reduce contention in update_cfs_rq_blocked_load
When running workloads on 2+ socket systems, based on perf profiles, the
update_cfs_rq_blocked_load function often shows up as taking up a
noticeable % of run time.
Much of the contention is in __update_cfs_rq_tg_load_contrib when we
update the tg load contribution stats. However, it turns out that in many
cases, they don't need to be updated and "tg_contrib" is 0.
This patch adds a check in __update_cfs_rq_tg_load_contrib to skip updating
tg load contribution stats when nothing needs to be updated. This reduces the
cacheline contention that would be unnecessary.
Cc: Yuyang Du
Cc: Aswin Chandramouleeswaran
Cc: Chegu Vinod
Cc: Scott J Norton
Reviewed-by: Ben Segall
Reviewed-by: Waiman Long
Signed-off-by: Jason Low
---
kernel/sched/fair.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d3427a8..45e346c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2382,6 +2382,9 @@ static inline void __update_cfs_rq_tg_load_contrib(struct
cfs_rq *cfs_rq,
tg_contrib = cfs_rq->runnable_load_avg + cfs_rq->blocked_load_avg;
tg_contrib -= cfs_rq->tg_load_contrib;
+ if (!tg_contrib)
+ return;
+
if (force_update || abs(tg_contrib) > cfs_rq->tg_load_contrib / 8) {
atomic_long_add(tg_contrib, >load_avg);
cfs_rq->tg_load_contrib += tg_contrib;
--
1.7.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/
Re: [PATCH v2] drm/i915: Fix lock dropping in intel_tv_detect()
On Mon, 01 Sep 2014, Chris Wilson wrote: > On Mon, Sep 01, 2014 at 01:36:37PM +0300, Ville Syrjälä wrote: >> On Mon, Sep 01, 2014 at 11:20:09AM +0100, Chris Wilson wrote: >> > On Mon, Sep 01, 2014 at 01:07:40PM +0300, ville.syrj...@linux.intel.com >> > wrote: >> > > From: Ville Syrjälä >> > > >> > > When intel_tv_detect() fails to do load detection it would forget to >> > > drop the locks and clean up the acquire context. Fix it up. >> > > >> > > This is a regression from: >> > > commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 >> > > Author: Ville Syrjälä >> > > Date: Mon Aug 11 13:15:35 2014 +0300 >> > > >> > > drm/i915: Fix locking for intel_enable_pipe_a() >> > > >> > > v2: Make the code more readable (Chris) >> > > >> > > Cc: Tibor Billes >> > > Signed-off-by: Ville Syrjälä >> > >> > Hmm, if we use WARN_ON() you should init type. >> >> type is always set in the branch that sets status=connected. > > Back to thinking about readability and making sure that the WARN_ON > never happens with just a glance. Otherwise, the WARN_ON would be better > as WARN_ON(unsigned)type >= last_tv_type); Or something. Anway, take > your pick and slap my r-b on it. :) Ville? J. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre -- Jani Nikula, Intel Open Source Technology Center -- 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/
[PATCH v2] ufs: fix deadlocks introduced by sb mutex merge
Commit 0244756edc4b ("ufs: sb mutex merge + mutex_destroy") introduces
deadlocks in ufs_new_inode() and ufs_free_inode().
Most callers of that functions acqure the mutex by themselves and
ufs_{new,free}_inode() do that via lock_ufs(),
i.e we have an unavoidable double lock.
The patch proposes to resolve the issue by making sure that
ufs_{new,free}_inode() are not called with the mutex held.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
fs/ufs/inode.c | 7 ++-
fs/ufs/namei.c | 14 ++
2 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/fs/ufs/inode.c b/fs/ufs/inode.c
index 7c580c97990e..be7d42c7d938 100644
--- a/fs/ufs/inode.c
+++ b/fs/ufs/inode.c
@@ -902,9 +902,6 @@ void ufs_evict_inode(struct inode * inode)
invalidate_inode_buffers(inode);
clear_inode(inode);
- if (want_delete) {
- lock_ufs(inode->i_sb);
- ufs_free_inode (inode);
- unlock_ufs(inode->i_sb);
- }
+ if (want_delete)
+ ufs_free_inode(inode);
}
diff --git a/fs/ufs/namei.c b/fs/ufs/namei.c
index 90d74b8f8eba..2df62a73f20c 100644
--- a/fs/ufs/namei.c
+++ b/fs/ufs/namei.c
@@ -126,12 +126,12 @@ static int ufs_symlink (struct inode * dir, struct dentry
* dentry,
if (l > sb->s_blocksize)
goto out_notlocked;
- lock_ufs(dir->i_sb);
inode = ufs_new_inode(dir, S_IFLNK | S_IRWXUGO);
err = PTR_ERR(inode);
if (IS_ERR(inode))
- goto out;
+ goto out_notlocked;
+ lock_ufs(dir->i_sb);
if (l > UFS_SB(sb)->s_uspi->s_maxsymlinklen) {
/* slow symlink */
inode->i_op = _symlink_inode_operations;
@@ -181,13 +181,9 @@ static int ufs_mkdir(struct inode * dir, struct dentry *
dentry, umode_t mode)
struct inode * inode;
int err;
- lock_ufs(dir->i_sb);
- inode_inc_link_count(dir);
-
inode = ufs_new_inode(dir, S_IFDIR|mode);
- err = PTR_ERR(inode);
if (IS_ERR(inode))
- goto out_dir;
+ return PTR_ERR(inode);
inode->i_op = _dir_inode_operations;
inode->i_fop = _dir_operations;
@@ -195,6 +191,9 @@ static int ufs_mkdir(struct inode * dir, struct dentry *
dentry, umode_t mode)
inode_inc_link_count(inode);
+ lock_ufs(dir->i_sb);
+ inode_inc_link_count(dir);
+
err = ufs_make_empty(inode, dir);
if (err)
goto out_fail;
@@ -212,7 +211,6 @@ out_fail:
inode_dec_link_count(inode);
inode_dec_link_count(inode);
iput (inode);
-out_dir:
inode_dec_link_count(dir);
unlock_ufs(dir->i_sb);
goto out;
--
1.9.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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:15 PM, Eliezer Tamir wrote:
> On 02/09/2014 06:29, Jason Wang wrote:
>> On 09/01/2014 02:39 PM, Eliezer Tamir wrote:
>>> On 29/08/2014 06:08, Jason Wang wrote:
> Yes, but rx busy polling only works in process context and does not
> disable bh, so it may be not an issue.
>>> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled.
>> True, so we need probably also exit the loop when there are pending bhs.
> I'm not so sure, in the typical busy poll scenario, the incoming
> traffic is the most time-critical thing in the system.
> It's so important that you are willing to trade lots of CPU power
> for better latency. The user has decided that he wants to dedicate
> this CPU mostly for that.
But user should increase the process priority or cgroup in this case.
> This is not something that plays nice with
> other apps, but this is what the user wants.
So the busy polling looks have a higher priority somehow than other
processes.
> So, you definitely don't want to starve any bh, and you should
> regularly re-enable bh's, but you also don't want to stop everything
> at any time a bh is scheduled.
If I get your meaning, you may want call to rcu_read_lock_bh() and get
socket napi id inside the do{} loop? This seems can prevent bhs from
being starved and can also handle the case that the packets were from
different NAPIs.
>
> You also want network processing on the queues that are busy polled
> to come through busy polling and not through NAPI, which is run in bh
> context.
>
> -Eliezer
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/
Re: [BISECTED] 3.17-rc1 radeon screen corruption due to "Always flush the HDP cache before submitting a CS to the GPU"
On 30.08.2014 22:59, Mikael Pettersson wrote:
> Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
> after a while in X + firefox. This still occurs with yesterday's HEAD
> of Linus' repo. 3.16 and ealier kernels are fine.
>
> I ran a bisect, which identified:
>
> commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
> Author: Michel Dänzer
> Date: Thu Jul 31 18:43:49 2014 +0900
>
> drm/radeon: Always flush the HDP cache before submitting a CS to the GPU
>
> as the cause of my screen corruption. Reverting this from 3.17-rc2
> (which requires manual intervention due to subsequent changes in
> radeon_ring_commit()) eliminates the screen corruption.
Does the patch below help?
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5ec44..3ff9c53 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring)
radeon_ring_write(ring, rdev->config.r100.hdp_cntl);
}
+/**
+ * r100_mmio_hdp_flush - flush Host Data Path via MMIO
+ * rdev: radeon device structure
+ */
+void r100_mmio_hdp_flush(struct radeon_device *rdev)
+{
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev->config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev->config.r100.hdp_cntl);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+}
+
static void r100_cp_load_microcode(struct radeon_device *rdev)
{
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index abe..c23a123 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
.resume = _resume,
.vga_set_state = _vga_set_state,
.asic_reset = _asic_reset,
- .mmio_hdp_flush = NULL,
+ .mmio_hdp_flush = r100_mmio_hdp_flush,
.gui_idle = _gui_idle,
.mc_wait_for_idle = _mc_wait_for_idle,
.gart = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 275a5dc..e9b1c35 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
struct radeon_ring *ring);
void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring);
+void r100_mmio_hdp_flush(struct radeon_device *rdev);
+
/*
* r200,rv250,rs300,rv280
*/
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index bfd7e1b..3d0f564 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
r = radeon_bo_wait(robj, _placement, false);
/* Flush HDP cache via MMIO if necessary */
if (rdev->asic->mmio_hdp_flush &&
+ !rdev->asic->ring[RADEON_RING_TYPE_GFX_INDEX]->hdp_flush &&
radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
robj->rdev->asic->mmio_hdp_flush(rdev);
drm_gem_object_unreference_unlocked(gobj);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index d656079..b82843b 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev, struct
radeon_ring *ring,
/* If we are emitting the HDP flush via the ring buffer, we need to
* do it before padding.
*/
- if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush)
+ if (hdp_flush && rdev->asic->ring[ring->idx]->hdp_flush &&
+ !rdev->asic->mmio_hdp_flush)
rdev->asic->ring[ring->idx]->hdp_flush(rdev, ring);
/* We pad to match fetch size */
while (ring->wptr & ring->align_mask) {
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
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/
Re: [PATCH] clk: fractional-divider: cast parent_rate to u64 before multiplying
Am Montag, 1. September 2014, 17:26:29 schrieb Mike Turquette: > Quoting Heiko Stübner (2014-08-28 03:46:10) > > > On 32bit architectures, like ARM calculating the fractional rate will > > do the multiplication before converting the value to u64 when it gets > > assigned to ret, which can produce overflows. > > > > The error in question happened with a parent_rate of 386MHz, m = 3000, > > n = 6, which resulted in a wrong rate value of 15812Hz. > > > > Therefore cast parent_rate to u64 to make sure the multiplication > > happens in a 64bit space and produces the correct 192MHz in the example. > > > > Signed-off-by: Heiko Stuebner > > Looks good to me. Have you observed this issue using the vanilla > kernel.org sources or on a downstream tree? I'm trying to decide if I > should take this into clk-fixes or clk-next. > > If this doesn't happen in practice on any merged platform then I'll take > it for 3.18. It happens on the Rockchip platform with the newly added fractional branches you just applied ... so it doesn't look like anybody else is affected right now. Heiko > > Regards, > Mike > > > --- > > > > drivers/clk/clk-fractional-divider.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/clk/clk-fractional-divider.c > > b/drivers/clk/clk-fractional-divider.c index ede685c..82a59d0 100644 > > --- a/drivers/clk/clk-fractional-divider.c > > +++ b/drivers/clk/clk-fractional-divider.c > > @@ -36,7 +36,7 @@ static unsigned long clk_fd_recalc_rate(struct clk_hw > > *hw,> > > m = (val & fd->mmask) >> fd->mshift; > > n = (val & fd->nmask) >> fd->nshift; > > > > - ret = parent_rate * m; > > + ret = (u64)parent_rate * m; > > > > do_div(ret, n); > > > > return ret; -- 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/
Re: [PATCH] mfd: palmas: Add support for optional wakeup
On Mon, 01 Sep 2014, Nishanth Menon wrote:
> On 09/01/2014 04:32 AM, Lee Jones wrote:
> >On Fri, 29 Aug 2014, Nishanth Menon wrote:
> >>On 08/29/2014 05:56 AM, Lee Jones wrote:
> >>>On Tue, 19 Aug 2014, Nishanth Menon wrote:
> >>>
> With the recent pinctrl-single changes, omaps can treat wake-up events
> from deeper idle states as interrupts.
>
> Let's add support for the optional second interrupt for wake-up
> events. And then SoC can wakeup and handle the event using it's
> regular handler.
>
> Finally, to pass the wake-up interrupt in the dts file,
> interrupts-extended property needs to be passed.
>
> This is similar in approach to commit 2a0b965cfb6e ("serial: omap: Add
> support for optional wake-up")
>
> Signed-off-by: Nishanth Menon
> ---
> Documentation/devicetree/bindings/mfd/palmas.txt | 20
> >>>
> >>>DT Ack please.
> >
> >Please read Documentation/devicetree/bindings/submittingpatches.txt
>
> I assume you wanted me to note the following:
> "
> The Documentation/ portion of the patch should be a separate patch.
> "
>
> Many maintainers prefer that when the bindings for the device is
> new, and when additional properties are added, they prefer it part
> of same patch.. Anyways.. if the above is what you prefer, I can
> follow that.
I tend to like it done properly please.
> In short, I assume you'd like three patches:
> a) fix up style of current documentation - palmas to palmas@40
> b) Split documentation for interrupt-extended from the current patch
> into it's own patch.
> c) remainder of this patch as is..
>
> Does that sound right?
That does, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/
Re: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with chipset info struct
On Tue, 02 Sep 2014, Chang, Rebecca Swee Fun wrote: > > > > -Original Message- > > From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] > > Sent: 01 September, 2014 6:25 PM > > To: Lee Jones > > Cc: Bjorn Helgaas; linux-kernel@vger.kernel.org; Samuel Ortiz; Chang, > > Rebecca > > Swee Fun > > Subject: Re: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with > > chipset info struct > > > > On Mon, 2014-09-01 at 10:16 +0100, Lee Jones wrote: > > > On Fri, 22 Aug 2014, Andy Shevchenko wrote: > > > > > > > Introduce additional struct to hold chipset info. This chipset info > > > > will be used to store features that are supported by specific > > > > processor or chipset. LPC_SCH supports SMBUS, GPIO and WDT features. > > > > As this code base might expand further to support more processors, > > > > this implementation will help to keep code base clean and manageable. > > > > > > > > Signed-off-by: Chang Rebecca Swee Fun > > > > > > > > Tested-by: Chang Rebecca Swee Fun > > > > Signed-off-by: Andy Shevchenko > > > > [] > > > > > > > The first patch would look a great deal cleaner if it had these > > > changes in too. Unless you have a really good reason not to, please > > > consider squashing them. > > > > The only reason behind is that this patch (in other form) was written by > > Rebecca in the first place. I recommended to clean up before, and actually > > did > > that clean up and amended Rebecca's patch. > > > > So, if Rebecca has now objections I could squash it. > > I have no objections. Thanks. Thanks Rebecca. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
Re: [PATCH v7 2/5] MFD: RK808: Add new mfd driver for RK808
On Mon, 01 Sep 2014, Doug Anderson wrote: > On Mon, Sep 1, 2014 at 3:09 AM, Lee Jones wrote: > > On Mon, 01 Sep 2014, Chris Zhong wrote: > > > >> The RK808 chip is a power management IC for multimedia and handheld > >> devices. It contains the following components: > >> > >> - Regulators > >> - RTC > >> - Clkout > >> > >> The RK808 core driver is registered as a platform driver and provides > >> communication through I2C with the host device for the different > >> components. > >> > >> Signed-off-by: Chris Zhong > >> Signed-off-by: Zhang Qing > > > > Couple of nits. Once fixed you can apply my: > > > > Acked-by: Lee Jones > > > > [...] > > > >> +/* > >> + * MFD core driver for Rockchip RK808 > >> + * > >> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd > > > > Author? > > I asked Chris to remove the author in my response to an earlier > version since it's at the bottom (MODULE_AUTHOR) and it seems extra > duplication. You are the boss though, so if it should go both places > then Chris should add this back. Sorry for the bad advice, Chris. Yes, both places please. They do different things. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:12 PM, Peter Zijlstra wrote: > On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote: >> > I see, how about just exporting a boolean helper like >> > current_can_busy_loop() and take care all of the conditions (pending bhs >> > and rcu callbacks, runnable processes) in scheduler code itself? > How is that going to help the cases that are hurt by not spinning for a > packet? The patch does not help for this case. Spinning in the case only help for a single process but hurt all others. Those other processes may not use busy polling or even non network related. Spinning still may give somewhat a high priority to the process who use busy polling or reading which is unfair. And how much we can gain for only a single process by spinning still when several other tasks could be done is still questionable. It's quite possible that we could only get one or zero packet after wasting lots of the cpu cycles when there are thousands or more sockets. -- 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/
Re: [PATCH V2] edac, amd64_edac: Modify usage of amd64_read_dct_pci_cfg()
On Tue, Aug 26, 2014 at 12:44:09PM -0500, Aravind Gopalakrishnan wrote:
> Rationale behind this change:
> - F2x1xx addresses were stopped from being mapped explicitly to DCT1
>from F15h (OR) onwards. They use _dct[0:1] mechanism to access the
>registers. So we should move away from using address ranges to select
>DCT for these families.
> - On newer processors, the address ranges used to indicate DCT1 (0x140,
>0x1a0) have different meanings than what is assumed currently.
>
> Changes introduced:
> - amd64_read_dct_pci_cfg() now takes in dct value and uses it for
>'selecting the dct'
> - Update usage of the function
> - Remove [k8|f10]_read_dct_pci_cfg() as they don't do much different
>from amd64_read_pci_cfg().
>- Move the k8 specific check to amd64_read_pci_cfg
> - Remove now needless .read_dct_pci_cfg
>
> Testing:
> - Tested on Fam 10h; Fam15h Models: 00h, 30h; Fam16h using 'EDAC_DEBUG'
>and mce_amd_inj
> - driver obtains info from F2x registers and caches it in pvt
>structures correctly
> - ECC decoding wotks fine
>
> Signed-off-by: Aravind Gopalakrishnan
> ---
> Changes in V2: (per Boris suggestion)
> - Hide family checks in amd64_read_dct_pci_cfg()
> - Use pvt structure for family checks and not boot_cpu_data
>
> drivers/edac/amd64_edac.c | 134
> ++
> drivers/edac/amd64_edac.h | 23 ++--
> 2 files changed, 83 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
> index f8bf000..ba0b78e 100644
> --- a/drivers/edac/amd64_edac.c
> +++ b/drivers/edac/amd64_edac.c
> @@ -60,6 +60,20 @@ static const struct scrubrate {
> { 0x00, 0UL},/* scrubbing off */
> };
>
> +/*
> + * Depending on the family, F2 DCT reads need special handling:
> + *
> + * K8: has a single DCT only and no address offsets >= 0x100
> + *
> + * F10h: each DCT has its own set of regs
> + * DCT0 -> F2x040..
> + * DCT1 -> F2x140..
> + *
> + * F16h: has only 1 DCT
> + *
> + * For all above families, we should use the 'raw' version
> + * i.e, amd64_read_pci_cfg() function
> + */
> int __amd64_read_pci_cfg_dword(struct pci_dev *pdev, int offset,
> u32 *val, const char *func)
> {
> @@ -87,35 +101,6 @@ int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int
> offset,
> }
>
> /*
> - *
> - * Depending on the family, F2 DCT reads need special handling:
> - *
> - * K8: has a single DCT only
> - *
> - * F10h: each DCT has its own set of regs
> - * DCT0 -> F2x040..
> - * DCT1 -> F2x140..
> - *
> - * F15h: we select which DCT we access using F1x10C[DctCfgSel]
> - *
> - * F16h: has only 1 DCT
> - */
> -static int k8_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
> -const char *func)
> -{
> - if (addr >= 0x100)
> - return -EINVAL;
> -
> - return __amd64_read_pci_cfg_dword(pvt->F2, addr, val, func);
> -}
> -
> -static int f10_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
> - const char *func)
> -{
> - return __amd64_read_pci_cfg_dword(pvt->F2, addr, val, func);
> -}
> -
> -/*
> * Select DCT to which PCI cfg accesses are routed
> */
> static void f15h_select_dct(struct amd64_pvt *pvt, u8 dct)
> @@ -128,19 +113,14 @@ static void f15h_select_dct(struct amd64_pvt *pvt, u8
> dct)
> amd64_write_pci_cfg(pvt->F1, DCT_CFG_SEL, reg);
> }
>
> -static int f15_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
> - const char *func)
> +/*
> + * F15h: F2x1xx addresses do not map explicitly to DCT1.
> + * We should select which DCT we access using F1x10C[DctCfgSel]
> + */
> +int f15_read_dct_pci_cfg(struct amd64_pvt *pvt, u8 dct, int addr, u32 *val,
> + const char *func)
> {
> - u8 dct = 0;
> -
> - /* For F15 M30h, the second dct is DCT 3, refer to BKDG Section 2.10 */
> - if (addr >= 0x140 && addr <= 0x1a0) {
> - dct = (pvt->model >= 0x30) ? 3 : 1;
> - addr -= 0x100;
> - }
> -
> f15h_select_dct(pvt, dct);
> -
> return __amd64_read_pci_cfg_dword(pvt->F2, addr, val, func);
> }
>
> @@ -767,17 +747,21 @@ static void read_dct_base_mask(struct amd64_pvt *pvt)
> int reg1 = DCSB1 + (cs * 4);
> u32 *base0 = >csels[0].csbases[cs];
> u32 *base1 = >csels[1].csbases[cs];
> + u8 dct = 0;
>
> - if (!amd64_read_dct_pci_cfg(pvt, reg0, base0))
> + if (!amd64_read_dct_pci_cfg(pvt, dct, reg0, base0))
> edac_dbg(0, " DCSB0[%d]=0x%08x reg: F2x%x\n",
>cs, *base0, reg0);
>
> - if (pvt->fam == 0xf || dct_ganging_enabled(pvt))
> + if (pvt->fam == 0xf)
> continue;
>
> - if (!amd64_read_dct_pci_cfg(pvt, reg1, base1))
> + dct = ((pvt->fam ==
Re: [PATCH 4/4] x86, fpu: irq_fpu_usable: kill all checks except !in_kernel_fpu
On Fri, Aug 29, 2014 at 11:17 AM, Oleg Nesterov wrote:
> ONCE AGAIN, THIS IS MORE THE QUESTION THAN THE PATCH.
this patch I think needs more thought for sure. please see below.
>
> interrupted_kernel_fpu_idle() does:
>
> if (use_eager_fpu())
> return true;
>
> return !__thread_has_fpu(current) &&
> (read_cr0() & X86_CR0_TS);
>
> and it is absolutely not clear why these 2 cases differ so much.
>
> To remind, the use_eager_fpu() case is buggy; __save_init_fpu() in
> __kernel_fpu_begin() can race with math_state_restore() which does
> __thread_fpu_begin() + restore_fpu_checking(). So we should fix this
> race anyway and we can't require __thread_has_fpu() == F likes the
> !use_eager_fpu() case does, in this case kernel_fpu_begin() will not
> work if it interrupts the idle thread (this will reintroduce the
> performance regression fixed by 5187b28f).
>
> Probably math_state_restore() can use kernel_fpu_disable/end() which
> sets/clears in_kernel_fpu, or it can disable irqs. Doesn't matter, we
> should fix this bug anyway.
>
> And if we fix this bug, why else !use_eager_fpu() case needs the much
> more strict check? Why we can't handle the __thread_has_fpu(current)
> case the same way?
>
> The comment deleted by this change says:
>
> and TS must be set so that the clts/stts pair does nothing
>
> and can explain the difference, but I can not understand this (again,
> assuming that we fix the race(s) mentoined above).
>
> Say, user_fpu_begin(). Yes, kernel_fpu_begin/end() can restore X86_CR0_TS.
> But this should be fine?
No. The reason is that has_fpu state and cr0.TS can get out of sync.
Let's say you get an interrupt after clts() in __thread_fpu_begin()
called as part of user_fpu_begin().
And because of this proposed change, irq_fpu_usable() returns true and
an interrupt can end-up using fpu and after the return from interrupt
we can have a state where cr0.TS is set but we end up resuming the
execution from __thread_set_has_fpu(). Now after this point has_fpu is
set but cr0.TS is set. And now any schedule() with this state (let's
say immd after preemption_enable() at the end of user_fpu_begin()) is
dangerous. We can get a dna fault in the middle of __switch_to() which
can lead to subtle bugs.
> A context switch before restore_user_xstate()
> can equally set it back?
> And device_not_available() should be fine even
> in kernel context?
not in some critical places like switch_to().
other than this patch, rest of the changes look ok to me. Can you
please resend this patchset with the math_state_restore() race
addressed aswell?
thanks,
suresh
>
> I'll appreciate any comment.
> ---
> arch/x86/kernel/i387.c | 44 +---
> 1 files changed, 1 insertions(+), 43 deletions(-)
>
> diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
> index 9fb2899..ef60f33 100644
> --- a/arch/x86/kernel/i387.c
> +++ b/arch/x86/kernel/i387.c
> @@ -22,54 +22,12 @@
> static DEFINE_PER_CPU(bool, in_kernel_fpu);
>
> /*
> - * Were we in an interrupt that interrupted kernel mode?
> - *
> - * On others, we can do a kernel_fpu_begin/end() pair *ONLY* if that
> - * pair does nothing at all: the thread must not have fpu (so
> - * that we don't try to save the FPU state), and TS must
> - * be set (so that the clts/stts pair does nothing that is
> - * visible in the interrupted kernel thread).
> - *
> - * Except for the eagerfpu case when we return 1.
> - */
> -static inline bool interrupted_kernel_fpu_idle(void)
> -{
> - if (this_cpu_read(in_kernel_fpu))
> - return false;
> -
> - if (use_eager_fpu())
> - return true;
> -
> - return !__thread_has_fpu(current) &&
> - (read_cr0() & X86_CR0_TS);
> -}
> -
> -/*
> - * Were we in user mode (or vm86 mode) when we were
> - * interrupted?
> - *
> - * Doing kernel_fpu_begin/end() is ok if we are running
> - * in an interrupt context from user mode - we'll just
> - * save the FPU state as required.
> - */
> -static inline bool interrupted_user_mode(void)
> -{
> - struct pt_regs *regs = get_irq_regs();
> - return regs && user_mode_vm(regs);
> -}
> -
> -/*
> * Can we use the FPU in kernel mode with the
> * whole "kernel_fpu_begin/end()" sequence?
> - *
> - * It's always ok in process context (ie "not interrupt")
> - * but it is sometimes ok even from an irq.
> */
> bool irq_fpu_usable(void)
> {
> - return !in_interrupt() ||
> - interrupted_user_mode() ||
> - interrupted_kernel_fpu_idle();
> + return !this_cpu_read(in_kernel_fpu);
> }
> EXPORT_SYMBOL(irq_fpu_usable);
>
> --
> 1.5.5.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/
Re: [PATCH] x86: only load initrd above 4g on second try
* Matt Fleming [140830 13:24]: > On Wed, 27 Aug, at 10:13:22AM, Yinghai Lu wrote: > > How about adding more info print out like: > > "Try to load initrd file to higher address..." > Yeah, that could work, at least we've had some debugging information to > go on if people start reporting hangs, though I'd suggest using "Trying" > or "Attempting". That should be fine. That would at least give the user something easy to search for (both web and source), and thus make it possible to at least get an idea of why the boot is hanging for the few people that's going to hit this. For most systems, the default to load the initrd/initramfs below 4G (and only load it above on the second attempt) will handle our buggy EFI's... To me this sounds like something that should work. Cheers, Anders -- Option Paralysis: The tendency, when given unlimited choices, to make none. -- Douglas Coupland, "Generation X: Tales for an Accelerated Culture" -- 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/
[PATCH] usb: gadget: f_fs: add usb_functionfs_descs_head_v2
Add usb_functionfs_descs_head_v2 structure for the new layout of
descriptors.
Signed-off-by: Zhuang Jin Can
---
include/uapi/linux/usb/functionfs.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..0b3f9fc 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -32,6 +32,15 @@ struct usb_endpoint_descriptor_no_audio {
__u8 bInterval;
} __attribute__((packed));
+struct usb_functionfs_descs_head_v2 {
+ __le32 magic;
+ __le32 length;
+ __le32 flags;
+ __le32 fs_count;
+ __le32 hs_count;
+ __le32 ss_count;
+} __attribute__((packed));
+
/* Legacy format, deprecated as of 3.14. */
struct usb_functionfs_descs_head {
__le32 magic;
--
1.7.9.5
--
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/
Re: [PATCH] PM / Domains: Make generic_pm_domain.name const
Hi Rafael,
On Tue, Sep 2, 2014 at 1:50 AM, Rafael J. Wysocki wrote:
>> Signed-off-by: Geert Uytterhoeven
>
> I'm going to apply this one. Does anything depend on it?
Thanks. So far nothing depends on it.
>> ---
>> include/linux/pm_domain.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
>> index 7c1d252b20c0..ebc4c76ffb73 100644
>> --- a/include/linux/pm_domain.h
>> +++ b/include/linux/pm_domain.h
>> @@ -60,7 +60,7 @@ struct generic_pm_domain {
>> struct mutex lock;
>> struct dev_power_governor *gov;
>> struct work_struct power_off_work;
>> - char *name;
>> + const char *name;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/
Re: [uas/3.16.1] panic in uas_data_cmplt()
Hi, On 09/02/2014 06:18 AM, Chunwei Chen wrote: > Dear all: > > The kernel version is 3.16.1-1-ARCH > > Today I keep getting this panic when booting up. > http://i.imgur.com/0Rx93Kr.jpg > > It might be that the UAS device was in some strange state, > because that after I unplugged and power-cycled the UAS, > everything went normal again. > > Does anyone know what's the root cause of this issue? > Or could anyone provide some instruction on how to debug this issue? There seem to be some issues in the error handling paths of the uas driver. I plan to rewrite them completely for robustness and go through them with a fine comb to fix any possible bugs while at it. I'll send out a mail when I've a new version ready for testing. Regards, Hans -- 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/
[PATCH] Input: cap1106 - fix register definition
Use the correct register address for Calibration Active and Interrupt Enable Signed-off-by: Klaus Goger --- drivers/input/keyboard/cap1106.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c index 180b184..d70b65a 100644 --- a/drivers/input/keyboard/cap1106.c +++ b/drivers/input/keyboard/cap1106.c @@ -33,8 +33,8 @@ #define CAP1106_REG_SENSOR_CONFIG 0x22 #define CAP1106_REG_SENSOR_CONFIG2 0x23 #define CAP1106_REG_SAMPLING_CONFIG0x24 -#define CAP1106_REG_CALIBRATION0x25 -#define CAP1106_REG_INT_ENABLE 0x26 +#define CAP1106_REG_CALIBRATION0x26 +#define CAP1106_REG_INT_ENABLE 0x27 #define CAP1106_REG_REPEAT_RATE0x28 #define CAP1106_REG_MT_CONFIG 0x2a #define CAP1106_REG_MT_PATTERN_CONFIG 0x2b -- 1.9.0 -- 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/
Re: [PATCH 1/4] x86, fpu: introduce per-cpu "bool in_kernel_fpu"
On Fri, Aug 29, 2014 at 11:16 AM, Oleg Nesterov wrote:
> interrupted_kernel_fpu_idle() tries to detect if kernel_fpu_begin()
> is safe or not. In particulat it should obviously deny the nested
> kernel_fpu_begin() and this logic doesn't look clean.
>
> If use_eager_fpu() == T we rely on a) __thread_has_fpu() check in
> interrupted_kernel_fpu_idle(), and b) on the fact that _begin() does
> __thread_clear_has_fpu().
>
> Otherwise we demand that the interrupted task has no FPU if it is in
> kernel mode, this works becase __kernel_fpu_begin() does clts().
>
> Add the per-cpu "bool in_kernel_fpu" variable, and change this code
> to check/set/clear it. This allows to do some cleanups (see the next
> changes) and fixes.
>
> Note that the current code looks racy. Say, kernel_fpu_begin() right
> after math_state_restore()->__thread_fpu_begin() will overwrite the
> regs we are going to restore. This patch doesn't even try to fix this,
yes indeed, explicit calls to math_state_restore() in eager_fpu case
has this race. I guess this is present from the commit 5187b28f.
thanks,
suresh
> it just adds the comment, but "in_kernel_fpu" can also be used to
> implement kernel_fpu_disable() / kernel_fpu_enable().
>
> Signed-off-by: Oleg Nesterov
> ---
> arch/x86/include/asm/i387.h |2 +-
> arch/x86/kernel/i387.c | 10 ++
> 2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
> index ed8089d..5e275d3 100644
> --- a/arch/x86/include/asm/i387.h
> +++ b/arch/x86/include/asm/i387.h
> @@ -40,8 +40,8 @@ extern void __kernel_fpu_end(void);
>
> static inline void kernel_fpu_begin(void)
> {
> - WARN_ON_ONCE(!irq_fpu_usable());
> preempt_disable();
> + WARN_ON_ONCE(!irq_fpu_usable());
> __kernel_fpu_begin();
> }
>
> diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
> index d5dd808..8fb8868 100644
> --- a/arch/x86/kernel/i387.c
> +++ b/arch/x86/kernel/i387.c
> @@ -19,6 +19,8 @@
> #include
> #include
>
> +static DEFINE_PER_CPU(bool, in_kernel_fpu);
> +
> /*
> * Were we in an interrupt that interrupted kernel mode?
> *
> @@ -33,6 +35,9 @@
> */
> static inline bool interrupted_kernel_fpu_idle(void)
> {
> + if (this_cpu_read(in_kernel_fpu))
> + return false;
> +
> if (use_eager_fpu())
> return __thread_has_fpu(current);
>
> @@ -73,6 +78,9 @@ void __kernel_fpu_begin(void)
> {
> struct task_struct *me = current;
>
> + this_cpu_write(in_kernel_fpu, true);
> +
> + /* FIXME: race with math_state_restore()-like code */
> if (__thread_has_fpu(me)) {
> __thread_clear_has_fpu(me);
> __save_init_fpu(me);
> @@ -99,6 +107,8 @@ void __kernel_fpu_end(void)
> } else {
> stts();
> }
> +
> + this_cpu_write(in_kernel_fpu, false);
> }
> EXPORT_SYMBOL(__kernel_fpu_end);
>
> --
> 1.5.5.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/
Re: early microcode: how to disable at runtime?
On Mon, Sep 01, 2014 at 04:59:21PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 01 Sep 2014, H. Peter Anvin wrote: > > No, it is worse to rename it and have older kernels behave differently. > > Kernel options are basically super obscure to most people anyway. > > Ok, so rename is out, although as long as the rename was accepted for > 3.16-stable, it would be just 3.16 and 3.16.1 (and maybe 3.16.2) that would > not have the new name. > > Options left are "keep it as is", or "add new and [optionally] deprecate > old". I can't really tell for sure which one you'd prefer from your > previous answer. Let me answer to all the concerns here: * the parameter is not in kernel-parameters.txt for the simple reason that we don't want people to disable ucode loaders left and right. The absolutely normal, 99% situation should be loading works fine or we don't load the ucode at all - this option is only for the very, very, very! obscure and strange situation where we want to rule out any microcode interference. Just in case. This situation should almost never happen. * The param naming could be argued about - maybe it is ugly and unreadable for that same reason. > This can be a very big deal when things go wrong: it is hard for the > regular user to recover from an initramfs image that crashes the > system, and the early initramfs has no "disable" trigger. This maybe is a serious problem but disabling microcode loading is not the proper solution. If the microcode in the initrd is corrupted, it should simply not get loaded and system should continue as much as it can - it *should* *not* be a requirement to disable the ucode loader in order to workaround corrupted initrds. And frankly, I'm trying to imagine how a corrupted microcode in an initrd would ever fail the booting. So Henrique, if you have something which is *not* hypothetical, please say so. It needs to be fixed properly and not with disabling the ucode loader. -- Regards/Gruss, Boris. -- -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:03 PM, Eliezer Tamir wrote: > On 02/09/2014 06:35, Jason Wang wrote: >> On 09/01/2014 02:55 PM, Eliezer Tamir wrote: >>> On 26/08/2014 10:16, Jason Wang wrote: On 08/25/2014 09:16 PM, Eliezer Tamir wrote: >>> Think about the case where two processes are busy polling on the >>> same CPU and the same device queue. Since busy polling processes >>> incoming packets on the queue from any process, this scenario works >>> well currently, >> I see, but looks like we can simply do this by exiting the busy loop >> when ndo_busy_poll() finds something but not for current socket? > I don't think there is a need for that. > > When ndo_busy_poll() finds something it feeds it to the stack, which > will process the packet, just as if it came from NAPI polling. > So, if this is data that someone is blocked waiting on, the stack will > wake them up, and then you presumably can decide which app should get > the cpu. Yes, but current code can not do this. In most of the cases, the new woke up process have no chance to run if another process is busy loop in the same cpu. > > Note, that there is no easy way to know, when looking at the > incoming traffic, whether it is important, or even if you are seeing > a full message. (Maybe you only have 9 packets out of 10?) > The only place this knowledge might exist is in the layers of the > stack closer to the user. > >>> and will not work at all when polling yields to other >>> processes that are of the same priority that are running on the same >>> CPU. >>> Maybe the networking subsystem should maintain a list of device >>> queues that need busypolling and have a thread that would poll >>> all of them when there's nothing better to do. >> Not sure whether this method will scale considering thousands of sockets >> and processes. > There may be millions of sockets, but in most cases only a handful of > device queues per CPU to busy poll on. I have tested the epoll rfc > code with hundreds of thousands of sockets and one or two device > queues and is scales pretty well. > > The part I don't like in that code is the cumbersome mechanism I used > to track the socket -> queue relationship. I think that if I had more > time to work on it, I would instead look into extending the epoll > interface so that libevent can tell the kernel what it wants, instead > of having the busypoll code try and learn it. I'd like to have a look at this rfc. Could you please give me a pointer? I've done a quick search on kernel mailing list but didn't find it. Thanks > > Cheers, > Eliezer -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 02/09/2014 06:29, Jason Wang wrote: > On 09/01/2014 02:39 PM, Eliezer Tamir wrote: >> On 29/08/2014 06:08, Jason Wang wrote: Yes, but rx busy polling only works in process context and does not disable bh, so it may be not an issue. >> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled. > > True, so we need probably also exit the loop when there are pending bhs. I'm not so sure, in the typical busy poll scenario, the incoming traffic is the most time-critical thing in the system. It's so important that you are willing to trade lots of CPU power for better latency. The user has decided that he wants to dedicate this CPU mostly for that. This is not something that plays nice with other apps, but this is what the user wants. So, you definitely don't want to starve any bh, and you should regularly re-enable bh's, but you also don't want to stop everything at any time a bh is scheduled. You also want network processing on the queues that are busy polled to come through busy polling and not through NAPI, which is run in bh context. -Eliezer -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote: > I see, how about just exporting a boolean helper like > current_can_busy_loop() and take care all of the conditions (pending bhs > and rcu callbacks, runnable processes) in scheduler code itself? How is that going to help the cases that are hurt by not spinning for a packet? -- 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/
Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using
On 9/2/14 13:17, Paul Gortmaker wrote: > [Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using] > On 01/09/2014 (Mon 10:01) H. Peter Anvin wrote: > >> On 09/01/2014 09:08 AM, Paul Gortmaker wrote: > diff --git a/init/Kconfig b/init/Kconfig index ac033c3..f301cc8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -23,6 +23,12 @@ config CONSTRUCTORS config IRQ_WORK bool +config CPU_LITTLE_ENDIAN + bool + +config CPU_BIG_ENDIAN + bool >>> >>> Perhaps you should take a cursory look at what already exists in tree >>> before blindly trying to add more to it? >>> >>> $ git grep CPU_BIG_ENDIAN | wc -l >>> 88 >>> >> >> The whole point of this patchset is to make these already widely-used >> options universal across the tree. > > OK, but that was not at _all_ what I thought when looking at this... > > Instead I saw a well intentioned, but perhaps not fully thought out > attempt at fixing a largely irrelevant randconfig/allmodconfig of a > 1990's vintage ISDN driver coming from that x86-only era, built against > an architecture that will never use or support it (microblaze). > > In today's world, we'd probably not accept a new ethernet driver or > filesystem if it was incapable of handling both BE and LE (exception > being SoC ethernet physically bound to one specific CPU, of course.) > So the justification given in the commit log for expanding the scope to > better deal with the stuff found in ISDN and the like was questionable. > After a simple search, for crypto, it may be endian sensitive, and for architectures may be endian sensitive, in config time. bash-3.2# find ./ | grep Kconfig | xargs grep depend | grep ENDIAN .//arch/arm/mm/Kconfig: depends on ARCH_SUPPORTS_BIG_ENDIAN .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN .//arch/arm64/Kconfig:depends on OF && !CPU_BIG_ENDIAN .//arch/mips/Kconfig: depends on SYS_SUPPORTS_BIG_ENDIAN .//arch/mips/Kconfig: depends on SYS_SUPPORTS_LITTLE_ENDIAN .//arch/mips/Kconfig: depends on SGI_IP22 || SGI_IP28 || (SNI_RM && CPU_LITTLE_ENDIAN) .//arch/powerpc/platforms/Kconfig.cputype:depends on !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on CPU_LITTLE_ENDIAN [...] .//crypto/Kconfig:depends on ARM && KERNEL_MODE_NEON && !CPU_BIG_ENDIAN .//crypto/Kconfig:depends on ARM && KERNEL_MODE_NEON && !CPU_BIG_ENDIAN .//drivers/crypto/Kconfig:depends on PPC64 && IBMVIO && !CPU_LITTLE_ENDIAN [...] It is a simple search, so I am not sure whether have other modules also need LE or BE. > Secondly, I don't think it is well known that Kbuild will tolerate > multiply defined symbols of the exact same name, and since that isn't > mentioned in the commit log (as documented and/or tested), I envisioned > this breaking powerpc and other arch who already define one (or both) > of these two. I found multi-define _is_ documented as supported in > Documentation/kbuild but I still wonder how much it is used and how > well it handles things like in powerpc, where one of them (LE?) also > lists a "select ... " line and help text under the bool. > > So if we want to do this, I'd suggest a commit log that really gets > to the intended point; something along the lines of: > > -- > > Currently we have some architectures defining their own bool for > CPU_LITTLE_ENDIAN and/or CPU_BIG_ENDIAN. As of 3.17-rc3 we have: > > CPU_BIG_ENDIAN: arc, arm, arm64, c6x, mips, powerpc, sh > CPU_LITTLE_ENDIAN: m32r, mips, powerpc, sh > > Note that the scope does not cover all arch, which reduces the utility > value of these items in generic and/or arch independent code, as > neither may be defined, making tests on their values inconclusive. > > To fix the above, the goal is to make both items present in an arch > independent Kconfig. We can do this immediately without having to > simultaneously touch the existing arch bool definitions because... > > This change was tested on a powerpc LE config since it has help text > and a select line, and the behaviour of both before and after the > change was found to be ... > > -- > > Also, having the suggested change Cc'd to linux-arch would be sensible, > I think. And one might want to make it a series, showing the follow on > arch specific commits you have planned that "select" an endian, since > the maintainers may want evidence it will be carried to completion and > they also may
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 02/09/2014 06:35, Jason Wang wrote: > On 09/01/2014 02:55 PM, Eliezer Tamir wrote: >> On 26/08/2014 10:16, Jason Wang wrote: >>> On 08/25/2014 09:16 PM, Eliezer Tamir wrote: >> Think about the case where two processes are busy polling on the >> same CPU and the same device queue. Since busy polling processes >> incoming packets on the queue from any process, this scenario works >> well currently, > > I see, but looks like we can simply do this by exiting the busy loop > when ndo_busy_poll() finds something but not for current socket? I don't think there is a need for that. When ndo_busy_poll() finds something it feeds it to the stack, which will process the packet, just as if it came from NAPI polling. So, if this is data that someone is blocked waiting on, the stack will wake them up, and then you presumably can decide which app should get the cpu. Note, that there is no easy way to know, when looking at the incoming traffic, whether it is important, or even if you are seeing a full message. (Maybe you only have 9 packets out of 10?) The only place this knowledge might exist is in the layers of the stack closer to the user. >> and will not work at all when polling yields to other >> processes that are of the same priority that are running on the same >> CPU. > >> >> Maybe the networking subsystem should maintain a list of device >> queues that need busypolling and have a thread that would poll >> all of them when there's nothing better to do. > > Not sure whether this method will scale considering thousands of sockets > and processes. There may be millions of sockets, but in most cases only a handful of device queues per CPU to busy poll on. I have tested the epoll rfc code with hundreds of thousands of sockets and one or two device queues and is scales pretty well. The part I don't like in that code is the cumbersome mechanism I used to track the socket -> queue relationship. I think that if I had more time to work on it, I would instead look into extending the epoll interface so that libevent can tell the kernel what it wants, instead of having the busypoll code try and learn it. Cheers, Eliezer -- 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/
Re: Re: [PATCH 1/3] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte
(2014/09/02 0:15), Christoph Hellwig wrote: On Mon, Sep 01, 2014 at 12:33:28PM +, Yoshihiro YUNOMAE wrote: For getting driver byte, host byte, msg byte, and status byte, macros are implemented in scsi/scsi.h, so we use it. As mentioned about three times in various previous scsi logging discussions this is entirely wrong and breaks decoding binary trace buffers. No, this patch uses just macros, so this does not change decoders. However, other patches change decoders in format files, so we need to consider about these decoders more, as you say. We'll discuss on https://lkml.org/lkml/2014/8/28/657. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- 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/
Re: Re: [PATCH 1/3] scsi/trace: Use macros for getting driver byte, host byte, msg byte, and status byte
(2014/09/02 0:15), Christoph Hellwig wrote: On Mon, Sep 01, 2014 at 12:33:28PM +, Yoshihiro YUNOMAE wrote: For getting driver byte, host byte, msg byte, and status byte, macros are implemented in scsi/scsi.h, so we use it. As mentioned about three times in various previous scsi logging discussions this is entirely wrong and breaks decoding binary trace buffers. No, this patch uses just macros, so this does not change decoders. However, other patches change decoders in format files, so we need to consider about these decoders more, as you say. We'll discuss on https://lkml.org/lkml/2014/8/28/657. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 02/09/2014 06:35, Jason Wang wrote: On 09/01/2014 02:55 PM, Eliezer Tamir wrote: On 26/08/2014 10:16, Jason Wang wrote: On 08/25/2014 09:16 PM, Eliezer Tamir wrote: Think about the case where two processes are busy polling on the same CPU and the same device queue. Since busy polling processes incoming packets on the queue from any process, this scenario works well currently, I see, but looks like we can simply do this by exiting the busy loop when ndo_busy_poll() finds something but not for current socket? I don't think there is a need for that. When ndo_busy_poll() finds something it feeds it to the stack, which will process the packet, just as if it came from NAPI polling. So, if this is data that someone is blocked waiting on, the stack will wake them up, and then you presumably can decide which app should get the cpu. Note, that there is no easy way to know, when looking at the incoming traffic, whether it is important, or even if you are seeing a full message. (Maybe you only have 9 packets out of 10?) The only place this knowledge might exist is in the layers of the stack closer to the user. and will not work at all when polling yields to other processes that are of the same priority that are running on the same CPU. Maybe the networking subsystem should maintain a list of device queues that need busypolling and have a thread that would poll all of them when there's nothing better to do. Not sure whether this method will scale considering thousands of sockets and processes. There may be millions of sockets, but in most cases only a handful of device queues per CPU to busy poll on. I have tested the epoll rfc code with hundreds of thousands of sockets and one or two device queues and is scales pretty well. The part I don't like in that code is the cumbersome mechanism I used to track the socket - queue relationship. I think that if I had more time to work on it, I would instead look into extending the epoll interface so that libevent can tell the kernel what it wants, instead of having the busypoll code try and learn it. Cheers, Eliezer -- 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/
Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using
On 9/2/14 13:17, Paul Gortmaker wrote: [Re: [PATCH] init/Kconfig: Add ENDIAN attributes for all architectures using] On 01/09/2014 (Mon 10:01) H. Peter Anvin wrote: On 09/01/2014 09:08 AM, Paul Gortmaker wrote: diff --git a/init/Kconfig b/init/Kconfig index ac033c3..f301cc8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -23,6 +23,12 @@ config CONSTRUCTORS config IRQ_WORK bool +config CPU_LITTLE_ENDIAN + bool + +config CPU_BIG_ENDIAN + bool Perhaps you should take a cursory look at what already exists in tree before blindly trying to add more to it? $ git grep CPU_BIG_ENDIAN | wc -l 88 The whole point of this patchset is to make these already widely-used options universal across the tree. OK, but that was not at _all_ what I thought when looking at this... Instead I saw a well intentioned, but perhaps not fully thought out attempt at fixing a largely irrelevant randconfig/allmodconfig of a 1990's vintage ISDN driver coming from that x86-only era, built against an architecture that will never use or support it (microblaze). In today's world, we'd probably not accept a new ethernet driver or filesystem if it was incapable of handling both BE and LE (exception being SoC ethernet physically bound to one specific CPU, of course.) So the justification given in the commit log for expanding the scope to better deal with the stuff found in ISDN and the like was questionable. After a simple search, for crypto, it may be endian sensitive, and for architectures may be endian sensitive, in config time. bash-3.2# find ./ | grep Kconfig | xargs grep depend | grep ENDIAN .//arch/arm/mm/Kconfig: depends on ARCH_SUPPORTS_BIG_ENDIAN .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN .//arch/arm/mm/Kconfig: depends on CPU_BIG_ENDIAN .//arch/arm64/Kconfig:depends on OF !CPU_BIG_ENDIAN .//arch/mips/Kconfig: depends on SYS_SUPPORTS_BIG_ENDIAN .//arch/mips/Kconfig: depends on SYS_SUPPORTS_LITTLE_ENDIAN .//arch/mips/Kconfig: depends on SGI_IP22 || SGI_IP28 || (SNI_RM CPU_LITTLE_ENDIAN) .//arch/powerpc/platforms/Kconfig.cputype:depends on !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on PPC_BOOK3S_64 !CPU_LITTLE_ENDIAN .//arch/powerpc/platforms/Kconfig.cputype:depends on CPU_LITTLE_ENDIAN [...] .//crypto/Kconfig:depends on ARM KERNEL_MODE_NEON !CPU_BIG_ENDIAN .//crypto/Kconfig:depends on ARM KERNEL_MODE_NEON !CPU_BIG_ENDIAN .//drivers/crypto/Kconfig:depends on PPC64 IBMVIO !CPU_LITTLE_ENDIAN [...] It is a simple search, so I am not sure whether have other modules also need LE or BE. Secondly, I don't think it is well known that Kbuild will tolerate multiply defined symbols of the exact same name, and since that isn't mentioned in the commit log (as documented and/or tested), I envisioned this breaking powerpc and other arch who already define one (or both) of these two. I found multi-define _is_ documented as supported in Documentation/kbuild but I still wonder how much it is used and how well it handles things like in powerpc, where one of them (LE?) also lists a select ... line and help text under the bool. So if we want to do this, I'd suggest a commit log that really gets to the intended point; something along the lines of: -- Currently we have some architectures defining their own bool for CPU_LITTLE_ENDIAN and/or CPU_BIG_ENDIAN. As of 3.17-rc3 we have: CPU_BIG_ENDIAN: arc, arm, arm64, c6x, mips, powerpc, sh CPU_LITTLE_ENDIAN: m32r, mips, powerpc, sh Note that the scope does not cover all arch, which reduces the utility value of these items in generic and/or arch independent code, as neither may be defined, making tests on their values inconclusive. To fix the above, the goal is to make both items present in an arch independent Kconfig. We can do this immediately without having to simultaneously touch the existing arch bool definitions because... This change was tested on a powerpc LE config since it has help text and a select line, and the behaviour of both before and after the change was found to be ... -- Also, having the suggested change Cc'd to linux-arch would be sensible, I think. And one might want to make it a series, showing the follow on arch specific commits you have planned that select an endian, since the maintainers may want evidence it will be carried to completion and they also may have something additional to say (as in the case of arch/arm where there is already CPU_ENDIAN_BE8 and CPU_ENDIAN_BE32 Kconfig items). Paul. -- OK, thanks, what
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote: I see, how about just exporting a boolean helper like current_can_busy_loop() and take care all of the conditions (pending bhs and rcu callbacks, runnable processes) in scheduler code itself? How is that going to help the cases that are hurt by not spinning for a packet? -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 02/09/2014 06:29, Jason Wang wrote: On 09/01/2014 02:39 PM, Eliezer Tamir wrote: On 29/08/2014 06:08, Jason Wang wrote: Yes, but rx busy polling only works in process context and does not disable bh, so it may be not an issue. sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled. True, so we need probably also exit the loop when there are pending bhs. I'm not so sure, in the typical busy poll scenario, the incoming traffic is the most time-critical thing in the system. It's so important that you are willing to trade lots of CPU power for better latency. The user has decided that he wants to dedicate this CPU mostly for that. This is not something that plays nice with other apps, but this is what the user wants. So, you definitely don't want to starve any bh, and you should regularly re-enable bh's, but you also don't want to stop everything at any time a bh is scheduled. You also want network processing on the queues that are busy polled to come through busy polling and not through NAPI, which is run in bh context. -Eliezer -- 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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:03 PM, Eliezer Tamir wrote: On 02/09/2014 06:35, Jason Wang wrote: On 09/01/2014 02:55 PM, Eliezer Tamir wrote: On 26/08/2014 10:16, Jason Wang wrote: On 08/25/2014 09:16 PM, Eliezer Tamir wrote: Think about the case where two processes are busy polling on the same CPU and the same device queue. Since busy polling processes incoming packets on the queue from any process, this scenario works well currently, I see, but looks like we can simply do this by exiting the busy loop when ndo_busy_poll() finds something but not for current socket? I don't think there is a need for that. When ndo_busy_poll() finds something it feeds it to the stack, which will process the packet, just as if it came from NAPI polling. So, if this is data that someone is blocked waiting on, the stack will wake them up, and then you presumably can decide which app should get the cpu. Yes, but current code can not do this. In most of the cases, the new woke up process have no chance to run if another process is busy loop in the same cpu. Note, that there is no easy way to know, when looking at the incoming traffic, whether it is important, or even if you are seeing a full message. (Maybe you only have 9 packets out of 10?) The only place this knowledge might exist is in the layers of the stack closer to the user. and will not work at all when polling yields to other processes that are of the same priority that are running on the same CPU. Maybe the networking subsystem should maintain a list of device queues that need busypolling and have a thread that would poll all of them when there's nothing better to do. Not sure whether this method will scale considering thousands of sockets and processes. There may be millions of sockets, but in most cases only a handful of device queues per CPU to busy poll on. I have tested the epoll rfc code with hundreds of thousands of sockets and one or two device queues and is scales pretty well. The part I don't like in that code is the cumbersome mechanism I used to track the socket - queue relationship. I think that if I had more time to work on it, I would instead look into extending the epoll interface so that libevent can tell the kernel what it wants, instead of having the busypoll code try and learn it. I'd like to have a look at this rfc. Could you please give me a pointer? I've done a quick search on kernel mailing list but didn't find it. Thanks Cheers, Eliezer -- 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/
Re: early microcode: how to disable at runtime?
On Mon, Sep 01, 2014 at 04:59:21PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 01 Sep 2014, H. Peter Anvin wrote: No, it is worse to rename it and have older kernels behave differently. Kernel options are basically super obscure to most people anyway. Ok, so rename is out, although as long as the rename was accepted for 3.16-stable, it would be just 3.16 and 3.16.1 (and maybe 3.16.2) that would not have the new name. Options left are keep it as is, or add new and [optionally] deprecate old. I can't really tell for sure which one you'd prefer from your previous answer. Let me answer to all the concerns here: * the parameter is not in kernel-parameters.txt for the simple reason that we don't want people to disable ucode loaders left and right. The absolutely normal, 99% situation should be loading works fine or we don't load the ucode at all - this option is only for the very, very, very! obscure and strange situation where we want to rule out any microcode interference. Just in case. This situation should almost never happen. * The param naming could be argued about - maybe it is ugly and unreadable for that same reason. This can be a very big deal when things go wrong: it is hard for the regular user to recover from an initramfs image that crashes the system, and the early initramfs has no disable trigger. This maybe is a serious problem but disabling microcode loading is not the proper solution. If the microcode in the initrd is corrupted, it should simply not get loaded and system should continue as much as it can - it *should* *not* be a requirement to disable the ucode loader in order to workaround corrupted initrds. And frankly, I'm trying to imagine how a corrupted microcode in an initrd would ever fail the booting. So Henrique, if you have something which is *not* hypothetical, please say so. It needs to be fixed properly and not with disabling the ucode loader. -- Regards/Gruss, Boris. -- -- 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/
Re: [PATCH 1/4] x86, fpu: introduce per-cpu bool in_kernel_fpu
On Fri, Aug 29, 2014 at 11:16 AM, Oleg Nesterov o...@redhat.com wrote:
interrupted_kernel_fpu_idle() tries to detect if kernel_fpu_begin()
is safe or not. In particulat it should obviously deny the nested
kernel_fpu_begin() and this logic doesn't look clean.
If use_eager_fpu() == T we rely on a) __thread_has_fpu() check in
interrupted_kernel_fpu_idle(), and b) on the fact that _begin() does
__thread_clear_has_fpu().
Otherwise we demand that the interrupted task has no FPU if it is in
kernel mode, this works becase __kernel_fpu_begin() does clts().
Add the per-cpu bool in_kernel_fpu variable, and change this code
to check/set/clear it. This allows to do some cleanups (see the next
changes) and fixes.
Note that the current code looks racy. Say, kernel_fpu_begin() right
after math_state_restore()-__thread_fpu_begin() will overwrite the
regs we are going to restore. This patch doesn't even try to fix this,
yes indeed, explicit calls to math_state_restore() in eager_fpu case
has this race. I guess this is present from the commit 5187b28f.
thanks,
suresh
it just adds the comment, but in_kernel_fpu can also be used to
implement kernel_fpu_disable() / kernel_fpu_enable().
Signed-off-by: Oleg Nesterov o...@redhat.com
---
arch/x86/include/asm/i387.h |2 +-
arch/x86/kernel/i387.c | 10 ++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/x86/include/asm/i387.h b/arch/x86/include/asm/i387.h
index ed8089d..5e275d3 100644
--- a/arch/x86/include/asm/i387.h
+++ b/arch/x86/include/asm/i387.h
@@ -40,8 +40,8 @@ extern void __kernel_fpu_end(void);
static inline void kernel_fpu_begin(void)
{
- WARN_ON_ONCE(!irq_fpu_usable());
preempt_disable();
+ WARN_ON_ONCE(!irq_fpu_usable());
__kernel_fpu_begin();
}
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index d5dd808..8fb8868 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -19,6 +19,8 @@
#include asm/fpu-internal.h
#include asm/user.h
+static DEFINE_PER_CPU(bool, in_kernel_fpu);
+
/*
* Were we in an interrupt that interrupted kernel mode?
*
@@ -33,6 +35,9 @@
*/
static inline bool interrupted_kernel_fpu_idle(void)
{
+ if (this_cpu_read(in_kernel_fpu))
+ return false;
+
if (use_eager_fpu())
return __thread_has_fpu(current);
@@ -73,6 +78,9 @@ void __kernel_fpu_begin(void)
{
struct task_struct *me = current;
+ this_cpu_write(in_kernel_fpu, true);
+
+ /* FIXME: race with math_state_restore()-like code */
if (__thread_has_fpu(me)) {
__thread_clear_has_fpu(me);
__save_init_fpu(me);
@@ -99,6 +107,8 @@ void __kernel_fpu_end(void)
} else {
stts();
}
+
+ this_cpu_write(in_kernel_fpu, false);
}
EXPORT_SYMBOL(__kernel_fpu_end);
--
1.5.5.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/
[PATCH] Input: cap1106 - fix register definition
Use the correct register address for Calibration Active and Interrupt Enable Signed-off-by: Klaus Goger klaus.go...@theobroma-systems.com --- drivers/input/keyboard/cap1106.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/input/keyboard/cap1106.c b/drivers/input/keyboard/cap1106.c index 180b184..d70b65a 100644 --- a/drivers/input/keyboard/cap1106.c +++ b/drivers/input/keyboard/cap1106.c @@ -33,8 +33,8 @@ #define CAP1106_REG_SENSOR_CONFIG 0x22 #define CAP1106_REG_SENSOR_CONFIG2 0x23 #define CAP1106_REG_SAMPLING_CONFIG0x24 -#define CAP1106_REG_CALIBRATION0x25 -#define CAP1106_REG_INT_ENABLE 0x26 +#define CAP1106_REG_CALIBRATION0x26 +#define CAP1106_REG_INT_ENABLE 0x27 #define CAP1106_REG_REPEAT_RATE0x28 #define CAP1106_REG_MT_CONFIG 0x2a #define CAP1106_REG_MT_PATTERN_CONFIG 0x2b -- 1.9.0 -- 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/
Re: [uas/3.16.1] panic in uas_data_cmplt()
Hi, On 09/02/2014 06:18 AM, Chunwei Chen wrote: Dear all: The kernel version is 3.16.1-1-ARCH Today I keep getting this panic when booting up. http://i.imgur.com/0Rx93Kr.jpg It might be that the UAS device was in some strange state, because that after I unplugged and power-cycled the UAS, everything went normal again. Does anyone know what's the root cause of this issue? Or could anyone provide some instruction on how to debug this issue? There seem to be some issues in the error handling paths of the uas driver. I plan to rewrite them completely for robustness and go through them with a fine comb to fix any possible bugs while at it. I'll send out a mail when I've a new version ready for testing. Regards, Hans -- 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/
Re: [PATCH] PM / Domains: Make generic_pm_domain.name const
Hi Rafael,
On Tue, Sep 2, 2014 at 1:50 AM, Rafael J. Wysocki r...@rjwysocki.net wrote:
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
I'm going to apply this one. Does anything depend on it?
Thanks. So far nothing depends on it.
---
include/linux/pm_domain.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
index 7c1d252b20c0..ebc4c76ffb73 100644
--- a/include/linux/pm_domain.h
+++ b/include/linux/pm_domain.h
@@ -60,7 +60,7 @@ struct generic_pm_domain {
struct mutex lock;
struct dev_power_governor *gov;
struct work_struct power_off_work;
- char *name;
+ const char *name;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/
[PATCH] usb: gadget: f_fs: add usb_functionfs_descs_head_v2
Add usb_functionfs_descs_head_v2 structure for the new layout of
descriptors.
Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com
---
include/uapi/linux/usb/functionfs.h |9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/linux/usb/functionfs.h
b/include/uapi/linux/usb/functionfs.h
index 0154b28..0b3f9fc 100644
--- a/include/uapi/linux/usb/functionfs.h
+++ b/include/uapi/linux/usb/functionfs.h
@@ -32,6 +32,15 @@ struct usb_endpoint_descriptor_no_audio {
__u8 bInterval;
} __attribute__((packed));
+struct usb_functionfs_descs_head_v2 {
+ __le32 magic;
+ __le32 length;
+ __le32 flags;
+ __le32 fs_count;
+ __le32 hs_count;
+ __le32 ss_count;
+} __attribute__((packed));
+
/* Legacy format, deprecated as of 3.14. */
struct usb_functionfs_descs_head {
__le32 magic;
--
1.7.9.5
--
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/
Re: [PATCH] x86: only load initrd above 4g on second try
* Matt Fleming m...@console-pimps.org [140830 13:24]: On Wed, 27 Aug, at 10:13:22AM, Yinghai Lu wrote: How about adding more info print out like: Try to load initrd file to higher address... Yeah, that could work, at least we've had some debugging information to go on if people start reporting hangs, though I'd suggest using Trying or Attempting. That should be fine. That would at least give the user something easy to search for (both web and source), and thus make it possible to at least get an idea of why the boot is hanging for the few people that's going to hit this. For most systems, the default to load the initrd/initramfs below 4G (and only load it above on the second attempt) will handle our buggy EFI's... To me this sounds like something that should work. Cheers, Anders -- Option Paralysis: The tendency, when given unlimited choices, to make none. -- Douglas Coupland, Generation X: Tales for an Accelerated Culture -- 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/
Re: [PATCH 4/4] x86, fpu: irq_fpu_usable: kill all checks except !in_kernel_fpu
On Fri, Aug 29, 2014 at 11:17 AM, Oleg Nesterov o...@redhat.com wrote:
ONCE AGAIN, THIS IS MORE THE QUESTION THAN THE PATCH.
this patch I think needs more thought for sure. please see below.
interrupted_kernel_fpu_idle() does:
if (use_eager_fpu())
return true;
return !__thread_has_fpu(current)
(read_cr0() X86_CR0_TS);
and it is absolutely not clear why these 2 cases differ so much.
To remind, the use_eager_fpu() case is buggy; __save_init_fpu() in
__kernel_fpu_begin() can race with math_state_restore() which does
__thread_fpu_begin() + restore_fpu_checking(). So we should fix this
race anyway and we can't require __thread_has_fpu() == F likes the
!use_eager_fpu() case does, in this case kernel_fpu_begin() will not
work if it interrupts the idle thread (this will reintroduce the
performance regression fixed by 5187b28f).
Probably math_state_restore() can use kernel_fpu_disable/end() which
sets/clears in_kernel_fpu, or it can disable irqs. Doesn't matter, we
should fix this bug anyway.
And if we fix this bug, why else !use_eager_fpu() case needs the much
more strict check? Why we can't handle the __thread_has_fpu(current)
case the same way?
The comment deleted by this change says:
and TS must be set so that the clts/stts pair does nothing
and can explain the difference, but I can not understand this (again,
assuming that we fix the race(s) mentoined above).
Say, user_fpu_begin(). Yes, kernel_fpu_begin/end() can restore X86_CR0_TS.
But this should be fine?
No. The reason is that has_fpu state and cr0.TS can get out of sync.
Let's say you get an interrupt after clts() in __thread_fpu_begin()
called as part of user_fpu_begin().
And because of this proposed change, irq_fpu_usable() returns true and
an interrupt can end-up using fpu and after the return from interrupt
we can have a state where cr0.TS is set but we end up resuming the
execution from __thread_set_has_fpu(). Now after this point has_fpu is
set but cr0.TS is set. And now any schedule() with this state (let's
say immd after preemption_enable() at the end of user_fpu_begin()) is
dangerous. We can get a dna fault in the middle of __switch_to() which
can lead to subtle bugs.
A context switch before restore_user_xstate()
can equally set it back?
And device_not_available() should be fine even
in kernel context?
not in some critical places like switch_to().
other than this patch, rest of the changes look ok to me. Can you
please resend this patchset with the math_state_restore() race
addressed aswell?
thanks,
suresh
I'll appreciate any comment.
---
arch/x86/kernel/i387.c | 44 +---
1 files changed, 1 insertions(+), 43 deletions(-)
diff --git a/arch/x86/kernel/i387.c b/arch/x86/kernel/i387.c
index 9fb2899..ef60f33 100644
--- a/arch/x86/kernel/i387.c
+++ b/arch/x86/kernel/i387.c
@@ -22,54 +22,12 @@
static DEFINE_PER_CPU(bool, in_kernel_fpu);
/*
- * Were we in an interrupt that interrupted kernel mode?
- *
- * On others, we can do a kernel_fpu_begin/end() pair *ONLY* if that
- * pair does nothing at all: the thread must not have fpu (so
- * that we don't try to save the FPU state), and TS must
- * be set (so that the clts/stts pair does nothing that is
- * visible in the interrupted kernel thread).
- *
- * Except for the eagerfpu case when we return 1.
- */
-static inline bool interrupted_kernel_fpu_idle(void)
-{
- if (this_cpu_read(in_kernel_fpu))
- return false;
-
- if (use_eager_fpu())
- return true;
-
- return !__thread_has_fpu(current)
- (read_cr0() X86_CR0_TS);
-}
-
-/*
- * Were we in user mode (or vm86 mode) when we were
- * interrupted?
- *
- * Doing kernel_fpu_begin/end() is ok if we are running
- * in an interrupt context from user mode - we'll just
- * save the FPU state as required.
- */
-static inline bool interrupted_user_mode(void)
-{
- struct pt_regs *regs = get_irq_regs();
- return regs user_mode_vm(regs);
-}
-
-/*
* Can we use the FPU in kernel mode with the
* whole kernel_fpu_begin/end() sequence?
- *
- * It's always ok in process context (ie not interrupt)
- * but it is sometimes ok even from an irq.
*/
bool irq_fpu_usable(void)
{
- return !in_interrupt() ||
- interrupted_user_mode() ||
- interrupted_kernel_fpu_idle();
+ return !this_cpu_read(in_kernel_fpu);
}
EXPORT_SYMBOL(irq_fpu_usable);
--
1.5.5.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/
Re: [PATCH V2] edac, amd64_edac: Modify usage of amd64_read_dct_pci_cfg()
On Tue, Aug 26, 2014 at 12:44:09PM -0500, Aravind Gopalakrishnan wrote:
Rationale behind this change:
- F2x1xx addresses were stopped from being mapped explicitly to DCT1
from F15h (OR) onwards. They use _dct[0:1] mechanism to access the
registers. So we should move away from using address ranges to select
DCT for these families.
- On newer processors, the address ranges used to indicate DCT1 (0x140,
0x1a0) have different meanings than what is assumed currently.
Changes introduced:
- amd64_read_dct_pci_cfg() now takes in dct value and uses it for
'selecting the dct'
- Update usage of the function
- Remove [k8|f10]_read_dct_pci_cfg() as they don't do much different
from amd64_read_pci_cfg().
- Move the k8 specific check to amd64_read_pci_cfg
- Remove now needless .read_dct_pci_cfg
Testing:
- Tested on Fam 10h; Fam15h Models: 00h, 30h; Fam16h using 'EDAC_DEBUG'
and mce_amd_inj
- driver obtains info from F2x registers and caches it in pvt
structures correctly
- ECC decoding wotks fine
Signed-off-by: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com
---
Changes in V2: (per Boris suggestion)
- Hide family checks in amd64_read_dct_pci_cfg()
- Use pvt structure for family checks and not boot_cpu_data
drivers/edac/amd64_edac.c | 134
++
drivers/edac/amd64_edac.h | 23 ++--
2 files changed, 83 insertions(+), 74 deletions(-)
diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index f8bf000..ba0b78e 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -60,6 +60,20 @@ static const struct scrubrate {
{ 0x00, 0UL},/* scrubbing off */
};
+/*
+ * Depending on the family, F2 DCT reads need special handling:
+ *
+ * K8: has a single DCT only and no address offsets = 0x100
+ *
+ * F10h: each DCT has its own set of regs
+ * DCT0 - F2x040..
+ * DCT1 - F2x140..
+ *
+ * F16h: has only 1 DCT
+ *
+ * For all above families, we should use the 'raw' version
+ * i.e, amd64_read_pci_cfg() function
+ */
int __amd64_read_pci_cfg_dword(struct pci_dev *pdev, int offset,
u32 *val, const char *func)
{
@@ -87,35 +101,6 @@ int __amd64_write_pci_cfg_dword(struct pci_dev *pdev, int
offset,
}
/*
- *
- * Depending on the family, F2 DCT reads need special handling:
- *
- * K8: has a single DCT only
- *
- * F10h: each DCT has its own set of regs
- * DCT0 - F2x040..
- * DCT1 - F2x140..
- *
- * F15h: we select which DCT we access using F1x10C[DctCfgSel]
- *
- * F16h: has only 1 DCT
- */
-static int k8_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
-const char *func)
-{
- if (addr = 0x100)
- return -EINVAL;
-
- return __amd64_read_pci_cfg_dword(pvt-F2, addr, val, func);
-}
-
-static int f10_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
- const char *func)
-{
- return __amd64_read_pci_cfg_dword(pvt-F2, addr, val, func);
-}
-
-/*
* Select DCT to which PCI cfg accesses are routed
*/
static void f15h_select_dct(struct amd64_pvt *pvt, u8 dct)
@@ -128,19 +113,14 @@ static void f15h_select_dct(struct amd64_pvt *pvt, u8
dct)
amd64_write_pci_cfg(pvt-F1, DCT_CFG_SEL, reg);
}
-static int f15_read_dct_pci_cfg(struct amd64_pvt *pvt, int addr, u32 *val,
- const char *func)
+/*
+ * F15h: F2x1xx addresses do not map explicitly to DCT1.
+ * We should select which DCT we access using F1x10C[DctCfgSel]
+ */
+int f15_read_dct_pci_cfg(struct amd64_pvt *pvt, u8 dct, int addr, u32 *val,
+ const char *func)
{
- u8 dct = 0;
-
- /* For F15 M30h, the second dct is DCT 3, refer to BKDG Section 2.10 */
- if (addr = 0x140 addr = 0x1a0) {
- dct = (pvt-model = 0x30) ? 3 : 1;
- addr -= 0x100;
- }
-
f15h_select_dct(pvt, dct);
-
return __amd64_read_pci_cfg_dword(pvt-F2, addr, val, func);
}
@@ -767,17 +747,21 @@ static void read_dct_base_mask(struct amd64_pvt *pvt)
int reg1 = DCSB1 + (cs * 4);
u32 *base0 = pvt-csels[0].csbases[cs];
u32 *base1 = pvt-csels[1].csbases[cs];
+ u8 dct = 0;
- if (!amd64_read_dct_pci_cfg(pvt, reg0, base0))
+ if (!amd64_read_dct_pci_cfg(pvt, dct, reg0, base0))
edac_dbg(0, DCSB0[%d]=0x%08x reg: F2x%x\n,
cs, *base0, reg0);
- if (pvt-fam == 0xf || dct_ganging_enabled(pvt))
+ if (pvt-fam == 0xf)
continue;
- if (!amd64_read_dct_pci_cfg(pvt, reg1, base1))
+ dct = ((pvt-fam == 0x15)
+ (pvt-model == 0x30)) ? 3 : 1;
That selection can go into amd64_read_dct_pci_cfg() too, right?
+
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:12 PM, Peter Zijlstra wrote: On Tue, Sep 02, 2014 at 11:38:40AM +0800, Jason Wang wrote: I see, how about just exporting a boolean helper like current_can_busy_loop() and take care all of the conditions (pending bhs and rcu callbacks, runnable processes) in scheduler code itself? How is that going to help the cases that are hurt by not spinning for a packet? The patch does not help for this case. Spinning in the case only help for a single process but hurt all others. Those other processes may not use busy polling or even non network related. Spinning still may give somewhat a high priority to the process who use busy polling or reading which is unfair. And how much we can gain for only a single process by spinning still when several other tasks could be done is still questionable. It's quite possible that we could only get one or zero packet after wasting lots of the cpu cycles when there are thousands or more sockets. -- 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/
phpBB 3.1.0 new version
phpBB 3.1.0 new version is out . Please update your forum to the latest version . We provide paid support if you are interested, please, reply to this email Thank you -- 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/
Re: [PATCH v7 2/5] MFD: RK808: Add new mfd driver for RK808
On Mon, 01 Sep 2014, Doug Anderson wrote: On Mon, Sep 1, 2014 at 3:09 AM, Lee Jones lee.jo...@linaro.org wrote: On Mon, 01 Sep 2014, Chris Zhong wrote: The RK808 chip is a power management IC for multimedia and handheld devices. It contains the following components: - Regulators - RTC - Clkout The RK808 core driver is registered as a platform driver and provides communication through I2C with the host device for the different components. Signed-off-by: Chris Zhong z...@rock-chips.com Signed-off-by: Zhang Qing zhangq...@rock-chips.com Couple of nits. Once fixed you can apply my: Acked-by: Lee Jones lee.jo...@linaro.org [...] +/* + * MFD core driver for Rockchip RK808 + * + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd Author? I asked Chris to remove the author in my response to an earlier version since it's at the bottom (MODULE_AUTHOR) and it seems extra duplication. You are the boss though, so if it should go both places then Chris should add this back. Sorry for the bad advice, Chris. Yes, both places please. They do different things. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
Re: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with chipset info struct
On Tue, 02 Sep 2014, Chang, Rebecca Swee Fun wrote: -Original Message- From: Andy Shevchenko [mailto:andriy.shevche...@linux.intel.com] Sent: 01 September, 2014 6:25 PM To: Lee Jones Cc: Bjorn Helgaas; linux-kernel@vger.kernel.org; Samuel Ortiz; Chang, Rebecca Swee Fun Subject: Re: [PATCH v1 2/5] mfd: lpc_sch: better code manageability with chipset info struct On Mon, 2014-09-01 at 10:16 +0100, Lee Jones wrote: On Fri, 22 Aug 2014, Andy Shevchenko wrote: Introduce additional struct to hold chipset info. This chipset info will be used to store features that are supported by specific processor or chipset. LPC_SCH supports SMBUS, GPIO and WDT features. As this code base might expand further to support more processors, this implementation will help to keep code base clean and manageable. Signed-off-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Tested-by: Chang Rebecca Swee Fun rebecca.swee.fun.ch...@intel.com Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com [] The first patch would look a great deal cleaner if it had these changes in too. Unless you have a really good reason not to, please consider squashing them. The only reason behind is that this patch (in other form) was written by Rebecca in the first place. I recommended to clean up before, and actually did that clean up and amended Rebecca's patch. So, if Rebecca has now objections I could squash it. I have no objections. Thanks. Thanks Rebecca. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
Re: [PATCH] mfd: palmas: Add support for optional wakeup
On Mon, 01 Sep 2014, Nishanth Menon wrote: On 09/01/2014 04:32 AM, Lee Jones wrote: On Fri, 29 Aug 2014, Nishanth Menon wrote: On 08/29/2014 05:56 AM, Lee Jones wrote: On Tue, 19 Aug 2014, Nishanth Menon wrote: With the recent pinctrl-single changes, omaps can treat wake-up events from deeper idle states as interrupts. Let's add support for the optional second interrupt for wake-up events. And then SoC can wakeup and handle the event using it's regular handler. Finally, to pass the wake-up interrupt in the dts file, interrupts-extended property needs to be passed. This is similar in approach to commit 2a0b965cfb6e (serial: omap: Add support for optional wake-up) Signed-off-by: Nishanth Menon n...@ti.com --- Documentation/devicetree/bindings/mfd/palmas.txt | 20 DT Ack please. Please read Documentation/devicetree/bindings/submittingpatches.txt I assume you wanted me to note the following: The Documentation/ portion of the patch should be a separate patch. Many maintainers prefer that when the bindings for the device is new, and when additional properties are added, they prefer it part of same patch.. Anyways.. if the above is what you prefer, I can follow that. I tend to like it done properly please. In short, I assume you'd like three patches: a) fix up style of current documentation - palmas to palmas@40 b) Split documentation for interrupt-extended from the current patch into it's own patch. c) remainder of this patch as is.. Does that sound right? That does, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/
Re: [PATCH] clk: fractional-divider: cast parent_rate to u64 before multiplying
Am Montag, 1. September 2014, 17:26:29 schrieb Mike Turquette: Quoting Heiko Stübner (2014-08-28 03:46:10) On 32bit architectures, like ARM calculating the fractional rate will do the multiplication before converting the value to u64 when it gets assigned to ret, which can produce overflows. The error in question happened with a parent_rate of 386MHz, m = 3000, n = 6, which resulted in a wrong rate value of 15812Hz. Therefore cast parent_rate to u64 to make sure the multiplication happens in a 64bit space and produces the correct 192MHz in the example. Signed-off-by: Heiko Stuebner he...@sntech.de Looks good to me. Have you observed this issue using the vanilla kernel.org sources or on a downstream tree? I'm trying to decide if I should take this into clk-fixes or clk-next. If this doesn't happen in practice on any merged platform then I'll take it for 3.18. It happens on the Rockchip platform with the newly added fractional branches you just applied ... so it doesn't look like anybody else is affected right now. Heiko Regards, Mike --- drivers/clk/clk-fractional-divider.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/clk-fractional-divider.c b/drivers/clk/clk-fractional-divider.c index ede685c..82a59d0 100644 --- a/drivers/clk/clk-fractional-divider.c +++ b/drivers/clk/clk-fractional-divider.c @@ -36,7 +36,7 @@ static unsigned long clk_fd_recalc_rate(struct clk_hw *hw, m = (val fd-mmask) fd-mshift; n = (val fd-nmask) fd-nshift; - ret = parent_rate * m; + ret = (u64)parent_rate * m; do_div(ret, n); return ret; -- 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/
Re: [BISECTED] 3.17-rc1 radeon screen corruption due to Always flush the HDP cache before submitting a CS to the GPU
On 30.08.2014 22:59, Mikael Pettersson wrote:
Since 3.17-rc1 my radeon card (RV370 / X1050 card) causes screen corruption
after a while in X + firefox. This still occurs with yesterday's HEAD
of Linus' repo. 3.16 and ealier kernels are fine.
I ran a bisect, which identified:
commit 72a9987edcedb89db988079a03c9b9c65b6ec9ac
Author: Michel Dänzer michel.daen...@amd.com
Date: Thu Jul 31 18:43:49 2014 +0900
drm/radeon: Always flush the HDP cache before submitting a CS to the GPU
as the cause of my screen corruption. Reverting this from 3.17-rc2
(which requires manual intervention due to subsequent changes in
radeon_ring_commit()) eliminates the screen corruption.
Does the patch below help?
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 4c5ec44..3ff9c53 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1070,6 +1070,20 @@ void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring)
radeon_ring_write(ring, rdev-config.r100.hdp_cntl);
}
+/**
+ * r100_mmio_hdp_flush - flush Host Data Path via MMIO
+ * rdev: radeon device structure
+ */
+void r100_mmio_hdp_flush(struct radeon_device *rdev)
+{
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev-config.r100.hdp_cntl | RADEON_HDP_READ_BUFFER_INVALIDATE);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+ WREG32(RADEON_HOST_PATH_CNTL,
+ rdev-config.r100.hdp_cntl);
+ (void)RREG32(RADEON_HOST_PATH_CNTL);
+}
+
static void r100_cp_load_microcode(struct radeon_device *rdev)
{
const __be32 *fw_data;
diff --git a/drivers/gpu/drm/radeon/radeon_asic.c
b/drivers/gpu/drm/radeon/radeon_asic.c
index abe..c23a123 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.c
+++ b/drivers/gpu/drm/radeon/radeon_asic.c
@@ -408,7 +408,7 @@ static struct radeon_asic r300_asic_pcie = {
.resume = r300_resume,
.vga_set_state = r100_vga_set_state,
.asic_reset = r300_asic_reset,
- .mmio_hdp_flush = NULL,
+ .mmio_hdp_flush = r100_mmio_hdp_flush,
.gui_idle = r100_gui_idle,
.mc_wait_for_idle = r300_mc_wait_for_idle,
.gart = {
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 275a5dc..e9b1c35 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -150,6 +150,8 @@ void r100_gfx_set_wptr(struct radeon_device *rdev,
struct radeon_ring *ring);
void r100_ring_hdp_flush(struct radeon_device *rdev,
struct radeon_ring *ring);
+void r100_mmio_hdp_flush(struct radeon_device *rdev);
+
/*
* r200,rv250,rs300,rv280
*/
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index bfd7e1b..3d0f564 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -368,6 +368,7 @@ int radeon_gem_wait_idle_ioctl(struct drm_device *dev, void
*data,
r = radeon_bo_wait(robj, cur_placement, false);
/* Flush HDP cache via MMIO if necessary */
if (rdev-asic-mmio_hdp_flush
+ !rdev-asic-ring[RADEON_RING_TYPE_GFX_INDEX]-hdp_flush
radeon_mem_type_to_domain(cur_placement) == RADEON_GEM_DOMAIN_VRAM)
robj-rdev-asic-mmio_hdp_flush(rdev);
drm_gem_object_unreference_unlocked(gobj);
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index d656079..b82843b 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -188,7 +188,8 @@ void radeon_ring_commit(struct radeon_device *rdev, struct
radeon_ring *ring,
/* If we are emitting the HDP flush via the ring buffer, we need to
* do it before padding.
*/
- if (hdp_flush rdev-asic-ring[ring-idx]-hdp_flush)
+ if (hdp_flush rdev-asic-ring[ring-idx]-hdp_flush
+ !rdev-asic-mmio_hdp_flush)
rdev-asic-ring[ring-idx]-hdp_flush(rdev, ring);
/* We pad to match fetch size */
while (ring-wptr ring-align_mask) {
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
--
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/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On 09/02/2014 02:15 PM, Eliezer Tamir wrote:
On 02/09/2014 06:29, Jason Wang wrote:
On 09/01/2014 02:39 PM, Eliezer Tamir wrote:
On 29/08/2014 06:08, Jason Wang wrote:
Yes, but rx busy polling only works in process context and does not
disable bh, so it may be not an issue.
sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled.
True, so we need probably also exit the loop when there are pending bhs.
I'm not so sure, in the typical busy poll scenario, the incoming
traffic is the most time-critical thing in the system.
It's so important that you are willing to trade lots of CPU power
for better latency. The user has decided that he wants to dedicate
this CPU mostly for that.
But user should increase the process priority or cgroup in this case.
This is not something that plays nice with
other apps, but this is what the user wants.
So the busy polling looks have a higher priority somehow than other
processes.
So, you definitely don't want to starve any bh, and you should
regularly re-enable bh's, but you also don't want to stop everything
at any time a bh is scheduled.
If I get your meaning, you may want call to rcu_read_lock_bh() and get
socket napi id inside the do{} loop? This seems can prevent bhs from
being starved and can also handle the case that the packets were from
different NAPIs.
You also want network processing on the queues that are busy polled
to come through busy polling and not through NAPI, which is run in bh
context.
-Eliezer
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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/
