* Re: [PATCH] btrfs: ioctls would need unique id
From: Hugo Mills @ 2013-12-19 8:19 UTC (permalink / raw)
To: Anand Jain; +Cc: linux-btrfs
In-Reply-To: <1387425992-15268-1-git-send-email-anand.jain@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
On Thu, Dec 19, 2013 at 12:06:32PM +0800, Anand Jain wrote:
> BTRFS_IOC_SET_FEATURES and BTRFS_IOC_GET_SUPPORTED_FEATURES
> conflicts with BTRFS_IOC_GET_FEATURES
>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
> include/uapi/linux/btrfs.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
> index 7d7f776..0fe736e 100644
> --- a/include/uapi/linux/btrfs.h
> +++ b/include/uapi/linux/btrfs.h
> @@ -634,9 +634,9 @@ struct btrfs_ioctl_fslist_args {
> struct btrfs_ioctl_fslist_args)
> #define BTRFS_IOC_GET_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 57, \
> struct btrfs_ioctl_feature_flags)
> -#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 57, \
> +#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 58, \
> struct btrfs_ioctl_feature_flags[2])
> -#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 57, \
> +#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 59, \
> struct btrfs_ioctl_feature_flags[3])
The ioctls are distinct as tehy are, as they have different-sized
parameters. Changing these numbers is changing the public interface,
which is a big no-no.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I think that everything darkling says is actually a joke. ---
It's just that we haven't worked out most of them yet.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] ieee80211_i.h: Align struct ps_data.tim to unsigned long
From: Johannes Berg @ 2013-12-19 8:19 UTC (permalink / raw)
To: Joe Perches; +Cc: Jiri Benc, linux-wireless, netdev
In-Reply-To: <1387414337.13593.48.camel@joe-AO722>
On Wed, 2013-12-18 at 16:52 -0800, Joe Perches wrote:
> Its address is used as an unsigned long *, so make sure
> that the tim u8 array is properly aligned.
>
> Signed-off-by: Joe Perches <joe@perches.com
> ---
> > Care to send a proper patch? Otherwise I'll just re-do it and pick it up
> > that way ...
>
> I had a passing thought about this when out today.
> It should really be set to __aligned(__alignof(unsigned long))
> so here's a proper patch.
Hmm, yeah, I guess that's true, though sizeof() is probably >= on
anything where Linux runs (and otherwise arrays get problematic anyway?)
Anyway, I've dropped my patch in favour of yours.
johannes
^ permalink raw reply
* [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
From: Markus Pargmann @ 2013-12-19 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52B1D722.3040500@ti.com>
Hi,
On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote:
> On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote:
> > On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote:
> >> On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote:
> >>> Hi,
> >>>
> >>> This series introduces a driver to read and use the MACIDs stored in the am335x
> >>> control module. These are read-only registers for a unique MACID. At the moment
> >>> the MACIDs are generated randomly or they are set by the bootloader.
> >>>
> >>> A device node is added in am33xx dtsi and used by the cpsw slaves in the bone
> >>> board files.
> >>>
> >>> Regards,
> >>>
> >>> Markus
> >>>
> >>>
> >>> Markus Pargmann (6):
> >>> DT doc: net: cpsw mac-address is optional
> >>> net: cpsw: header, Add missing include
> >>> net: cpsw: Add control-module macid driver
> >>> net: cpsw: Use cpsw-ctrl-macid driver
> >>> arm: dts: am33xx, Add device node for cpsw-ctrl-macid
> >>> arm: dts: am335x beagle bone use processor macids
> >>>
> >>> .../devicetree/bindings/net/cpsw-ctrl-macid.txt | 31 +++++
> >>> Documentation/devicetree/bindings/net/cpsw.txt | 7 +-
> >>> arch/arm/boot/dts/am335x-bone.dts | 8 ++
> >>> arch/arm/boot/dts/am335x-boneblack.dts | 8 ++
> >>> arch/arm/boot/dts/am33xx.dtsi | 7 ++
> >>> drivers/net/ethernet/ti/Kconfig | 8 ++
> >>> drivers/net/ethernet/ti/Makefile | 1 +
> >>> drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 +++++++++++++++++++++
> >>> drivers/net/ethernet/ti/cpsw.c | 18 ++-
> >>> drivers/net/ethernet/ti/cpsw.h | 3 +
> >>> 10 files changed, 224 insertions(+), 5 deletions(-)
> >>> create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> >>> create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> >>>
> >> Mac ID is to be filled by U-Boot and this kind of approach is already
> >> rejected in linux-omap list.
> >>
> >> If proper ethaddr/eth*addr is populated in U-boot environment variable
> >> then mac-address dt property in ethernet* device nodes will be populated
> >> before boot kernel in U-boot. So I don't think this patch series is
> >> required.
> > but will u-boot read MACID from control module ?
> >
> Yes, U-Boot will read the MACID from control module and if a customer
> wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must
> be updated.
I think we should not rely on any bootloader to setup the macids
correctly.
U-Boot is not the only bootloader. There are others which may not
support cpsw or don't support devicetree or don't load the cpsw driver
automatically when no ethernet connection is used. Most installed
bootloaders use their local storage to load the kernel, so how can we be
certain that the bootloader added the correct MACIDs to the devicetree?
Why can't the kernel be bootloader independent?
A cpsw slave defined in am33xx.dtsi:
cpsw_emac0: slave at 4a100200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
This is not a proper hardware description, only a clear statement that
the kernel depends on U-Boot or any other bootloader that does always
set the mac-address the same way U-Boot does. But that DT is not usable
in anything else than Linux and U-Boot.
The TI reference manual clearly lists the MACID registers in the control
module so we can use that to describe the source of the MACIDs in DT,
independent of U-Boot. Any bootloader can use such a devictree and parse
the correct location in the control module.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 0/6] net: cpsw: Support for am335x chip MACIDs
From: Markus Pargmann @ 2013-12-19 8:19 UTC (permalink / raw)
To: Mugunthan V N
Cc: balbi, David S. Miller, Benoît Cousson, linux-omap,
devicetree, linux-arm-kernel, kernel
In-Reply-To: <52B1D722.3040500@ti.com>
Hi,
On Wed, Dec 18, 2013 at 10:40:58PM +0530, Mugunthan V N wrote:
> On Wednesday 18 December 2013 10:38 PM, Felipe Balbi wrote:
> > On Wed, Dec 18, 2013 at 10:30:55PM +0530, Mugunthan V N wrote:
> >> On Wednesday 18 December 2013 10:17 PM, Markus Pargmann wrote:
> >>> Hi,
> >>>
> >>> This series introduces a driver to read and use the MACIDs stored in the am335x
> >>> control module. These are read-only registers for a unique MACID. At the moment
> >>> the MACIDs are generated randomly or they are set by the bootloader.
> >>>
> >>> A device node is added in am33xx dtsi and used by the cpsw slaves in the bone
> >>> board files.
> >>>
> >>> Regards,
> >>>
> >>> Markus
> >>>
> >>>
> >>> Markus Pargmann (6):
> >>> DT doc: net: cpsw mac-address is optional
> >>> net: cpsw: header, Add missing include
> >>> net: cpsw: Add control-module macid driver
> >>> net: cpsw: Use cpsw-ctrl-macid driver
> >>> arm: dts: am33xx, Add device node for cpsw-ctrl-macid
> >>> arm: dts: am335x beagle bone use processor macids
> >>>
> >>> .../devicetree/bindings/net/cpsw-ctrl-macid.txt | 31 +++++
> >>> Documentation/devicetree/bindings/net/cpsw.txt | 7 +-
> >>> arch/arm/boot/dts/am335x-bone.dts | 8 ++
> >>> arch/arm/boot/dts/am335x-boneblack.dts | 8 ++
> >>> arch/arm/boot/dts/am33xx.dtsi | 7 ++
> >>> drivers/net/ethernet/ti/Kconfig | 8 ++
> >>> drivers/net/ethernet/ti/Makefile | 1 +
> >>> drivers/net/ethernet/ti/cpsw-ctrl-macid.c | 138 +++++++++++++++++++++
> >>> drivers/net/ethernet/ti/cpsw.c | 18 ++-
> >>> drivers/net/ethernet/ti/cpsw.h | 3 +
> >>> 10 files changed, 224 insertions(+), 5 deletions(-)
> >>> create mode 100644 Documentation/devicetree/bindings/net/cpsw-ctrl-macid.txt
> >>> create mode 100644 drivers/net/ethernet/ti/cpsw-ctrl-macid.c
> >>>
> >> Mac ID is to be filled by U-Boot and this kind of approach is already
> >> rejected in linux-omap list.
> >>
> >> If proper ethaddr/eth*addr is populated in U-boot environment variable
> >> then mac-address dt property in ethernet* device nodes will be populated
> >> before boot kernel in U-boot. So I don't think this patch series is
> >> required.
> > but will u-boot read MACID from control module ?
> >
> Yes, U-Boot will read the MACID from control module and if a customer
> wants to have his own MACID, U-boot ENV variable ethaddr/eth1addr must
> be updated.
I think we should not rely on any bootloader to setup the macids
correctly.
U-Boot is not the only bootloader. There are others which may not
support cpsw or don't support devicetree or don't load the cpsw driver
automatically when no ethernet connection is used. Most installed
bootloaders use their local storage to load the kernel, so how can we be
certain that the bootloader added the correct MACIDs to the devicetree?
Why can't the kernel be bootloader independent?
A cpsw slave defined in am33xx.dtsi:
cpsw_emac0: slave@4a100200 {
/* Filled in by U-Boot */
mac-address = [ 00 00 00 00 00 00 ];
};
This is not a proper hardware description, only a clear statement that
the kernel depends on U-Boot or any other bootloader that does always
set the mac-address the same way U-Boot does. But that DT is not usable
in anything else than Linux and U-Boot.
The TI reference manual clearly lists the MACID registers in the control
module so we can use that to describe the source of the MACIDs in DT,
independent of U-Boot. Any bootloader can use such a devictree and parse
the correct location in the control module.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: dm-multipath: Accept failed paths for multipath maps
From: Bart Van Assche @ 2013-12-19 8:21 UTC (permalink / raw)
To: device-mapper development; +Cc: Mike Snitzer, Stewart, Sean, Alasdair Kergon
In-Reply-To: <1387380498.7608.6.camel@ict-vth-stewarts01.ict.englab.netapp.com>
On 12/18/13 16:28, Stewart, Sean wrote:
> The most severe case is with
> InfiniBand, where the LLD may place a device offline, then every single
> reload that is trying to add a good path in will fail. I will qualify
> this by saying that I realize it is a problem that the device gets
> placed offline in the first place, but this patch would allow it a
> chance to continue on. The user still has to take manual steps to fix
> the problem in this case, but it seems less disruptive to applications.
Are you perhaps referring to the SRP initiator ? The above is correct
for old versions of the SRP initiator (< Linux kernel 3.12) but no
longer for upstream kernel versions >= 3.12. An effort is ongoing to
backport the latest SRP initiator changes into RHEL and SLES.
Bart.
^ permalink raw reply
* Re: [PATCH] android/pts: Add PICS, PIXITs and PTS for L2CAP
From: Johan Hedberg @ 2013-12-19 8:21 UTC (permalink / raw)
To: Sebastian Chlad; +Cc: linux-bluetooth, Sebastian Chlad
In-Reply-To: <1387395146-28084-1-git-send-email-sebastianx.chlad@intel.com>
Hi Sebastian,
On Wed, Dec 18, 2013, Sebastian Chlad wrote:
> This allows better tracking of the current state of implementation
> ---
> android/pics-l2cap.txt | 157 ++++++++++++++++++++++++++
> android/pixit-l2cap.txt | 39 +++++++
> android/pts-l2cap.txt | 293 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 489 insertions(+)
> create mode 100644 android/pics-l2cap.txt
> create mode 100644 android/pixit-l2cap.txt
> create mode 100644 android/pts-l2cap.txt
Looks otherwise fine to me, but are you've forgotten to add these to
EXTRA_DIST in android/Makefile.am. Otherwise the files would not get
included in the next release tarball we make.
Johan
^ permalink raw reply
* Re: [PATCH] mmc: core: don't return 1 for max_discard
From: Vladimir Zapolskiy @ 2013-12-19 8:22 UTC (permalink / raw)
To: Stephen Warren
Cc: Chris Ball, linux-mmc, linux-tegra, Stephen Warren, Adrian Hunter,
Dong Aisheng, Ulf Hansson
In-Reply-To: <52B22906.4010704@wwwdotorg.org>
On 12/19/13 00:00, Stephen Warren wrote:
> On 12/18/2013 03:27 PM, Stephen Warren wrote:
>> From: Stephen Warren<swarren@nvidia.com>
>>
>> In mmc_do_calc_max_discard(), if only a single erase block can be
>> discarded within the host controller's timeout, don't allow discard
>> operations at all.
>>
>> Previously, the code allowed sector-at-a-time discard (rather than
>> erase-block-at-a-time), which was chronically slow.
>>
>> Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
>> in qty == 1, which is immediately returned. This causes discard to
>> operate a single sector at a time, which is chronically slow. With this
>> patch in place, discard operates a single erase block at a time, which
>> is reasonably fast.
>
> Alternatively, is the real fix a revert of e056a1b5b67b "mmc: queue: let
> host controllers specify maximum discard timeout", followed by:
>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 050eb262485c..35c5b5d86c99 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -1950,7 +1950,6 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from,
>> cmd.opcode = MMC_ERASE;
>> cmd.arg = arg;
>> cmd.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
>> - cmd.cmd_timeout_ms = mmc_erase_timeout(card, arg, qty);
>> err = mmc_wait_for_cmd(card->host,&cmd, 0);
>> if (err) {
>> pr_err("mmc_erase: erase error %d, status %#x\n",
>> @@ -1962,7 +1961,7 @@ static int mmc_do_erase(struct mmc_card *card, unsigned int from,
>> if (mmc_host_is_spi(card->host))
>> goto out;
>>
>> - timeout = jiffies + msecs_to_jiffies(MMC_CORE_TIMEOUT_MS);
>> + timeout = jiffies + msecs_to_jiffies(mmc_erase_timeout(card, arg, qty));
>> do {
>> memset(&cmd, 0, sizeof(struct mmc_command));
>> cmd.opcode = MMC_SEND_STATUS;
>
> That certainly also seems to solve the problem on my board...
Personally I'd prefer this change.
Out of curiosity have you tried the approach I proposed as RFC with set
mmc_core.limit_erase_groups=0?
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] video: mx3fb: Allow blocking during framebuffer allocation
From: Sascha Hauer @ 2013-12-19 8:23 UTC (permalink / raw)
To: linux-fbdev
Cc: Sascha Hauer, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-kernel
No need to allocate the framebuffer from the atomic pool, we are not
in interrupt context. Adding GFP_KERNEL to the framebuffer allocation
allows to use the much bigger CMA pool to allocate the framebuffer.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/mx3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index cfdb380..c882bec 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1263,7 +1263,7 @@ static int mx3fb_map_video_memory(struct fb_info *fbi, unsigned int mem_len,
fbi->screen_base = dma_alloc_writecombine(fbi->device,
mem_len,
- &addr, GFP_DMA);
+ &addr, GFP_DMA | GFP_KERNEL);
if (!fbi->screen_base) {
dev_err(fbi->device, "Cannot allocate %u bytes framebuffer memory\n",
--
1.8.5.1
^ permalink raw reply related
* [PATCH] video: mx3fb: Allow blocking during framebuffer allocation
From: Sascha Hauer @ 2013-12-19 8:23 UTC (permalink / raw)
To: linux-fbdev
Cc: Sascha Hauer, Jean-Christophe Plagniol-Villard, Tomi Valkeinen,
linux-kernel
No need to allocate the framebuffer from the atomic pool, we are not
in interrupt context. Adding GFP_KERNEL to the framebuffer allocation
allows to use the much bigger CMA pool to allocate the framebuffer.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/video/mx3fb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index cfdb380..c882bec 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -1263,7 +1263,7 @@ static int mx3fb_map_video_memory(struct fb_info *fbi, unsigned int mem_len,
fbi->screen_base = dma_alloc_writecombine(fbi->device,
mem_len,
- &addr, GFP_DMA);
+ &addr, GFP_DMA | GFP_KERNEL);
if (!fbi->screen_base) {
dev_err(fbi->device, "Cannot allocate %u bytes framebuffer memory\n",
--
1.8.5.1
^ permalink raw reply related
* Re: [PATCH] reinstate ceph cluster_snap support
From: Alexandre Oliva @ 2013-12-19 8:22 UTC (permalink / raw)
To: Gregory Farnum; +Cc: Sage Weil, Samuel Just, ceph-devel@vger.kernel.org
In-Reply-To: <CAPYLRzjfiXYbe=kCbz+VpucH=GLGkFu+n-t=5wLsFCohF5pcjQ@mail.gmail.com>
On Dec 18, 2013, Gregory Farnum <greg@inktank.com> wrote:
> (you've never been getting a real point-in-time
> snapshot, although as long as you didn't use external communication
> channels you could at least be sure it contained a causal cut).
I never expected more than a causal cut, really (my wife got a PhD in
consistent checkpointing of distributed systems, so my expectations may
be somewhat better informed than those a random user might have ;-),
although even now I've seldom got a snapshot in which the osd data
differs across replicas (I actually check for that; that's part of my
reason for taking the snapshots in the first place), even when I fail to
explicitly make the cluster quiescent. But that's probably just “luck”,
as my cluster usually isn't busy when I take such snapshots ;-)
> And of course that's nothing compared to snapshotting the monitors, as
> you've noticed
I've given it some more thought, and it occurred to me that, if we make
mons take the snapshot when the snapshot-taking request is committed to
the cluster history, we should have the snapshots taking at the right
time and without the need for rolling them back and taking them again.
The idea is that, if the snapshot-taking is committed, eventually we'll
have a quorum carrying that commit, and thus each of the quorum members
will have taken a snapshot as soon as they got that commit, even if they
did so during recovery, or if they took so long to take the snapshot
that they got kicked out of the quorum for a while. If they get
actually restarted, they will get the commit again and take the snapshot
from the beginning. If all mons in the quorum that accepted the commit
get restarted so that none of them actually records the commit request,
and it doesn't get propagated to other mons that attempt to rejoin,
well, it's as if the request had never been committed. OTOH, if it did
get to other mons, or if any of them survives, the committed request
will make to a quorum and eventually to all monitors, each one taking
its snapshot at the time it gets the commit.
This should work as long as all mons get recovery info in the same
order, i.e., they won't get into their database history information that
happens-after the snapshot commit before the snapshot commit, nor will
they fail to get information that happened-before the snapshot commit
before getting the snapshot commit. That said, having little idea of
the inner workings of the monitors, I can't tell whether they actually
meet this “as long as” condition ;-(
> — but making it actually be a cluster snapshot (instead
> of something you could basically do by taking a btrfs snapshot
> yourself)
Taking btrfs snapshots manually over several osds on several hosts is
hardly a way to get a causal cut (but you already knew that ;-)
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 0/5] Enabling DRRS in the kernel
From: Vandana Kannan @ 2013-12-19 8:30 UTC (permalink / raw)
To: intel-gfx
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enabled swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID, which would list multiple
refresh rates for one resolution.
The patch series supports idleness detection in display i915 driver and
switch to low refresh rate.
Based on review comments, the functions for idleness detection have been
restructured.
Pradeep Bhat (3):
[Intel-gfx] drm/i915: Adding VBT fields to support eDP DRRS feature
[Intel-gfx] drm/i915: Parse EDID probed modes for DRRS support
[Intel-gfx] drm/i915: Add support for DRRS to switch RR
Vandana Kannan (2):
[Intel-gfx] drm/i915: Idleness detection for DRRS
[Intel-gfx] drm/i915/bdw: Add support for DRRS to switch RR
drivers/gpu/drm/i915/i915_drv.h | 25 +++++
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_bios.c | 23 +++++
drivers/gpu/drm/i915/intel_bios.h | 29 ++++++
drivers/gpu/drm/i915/intel_display.c | 14 +++
drivers/gpu/drm/i915/intel_dp.c | 181 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_drv.h | 43 +++++++-
drivers/gpu/drm/i915/intel_pm.c | 122 +++++++++++++++++++++++
drivers/gpu/drm/i915/intel_sprite.c | 3 +
9 files changed, 439 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH 1/5] drm/i915: Adding VBT fields to support eDP DRRS feature
From: Vandana Kannan @ 2013-12-19 8:30 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1387441863-21953-1-git-send-email-vandana.kannan@intel.com>
From: Pradeep Bhat <pradeep.bhat@intel.com>
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps us decide if seamless DRRS can be done
at runtime to support certain power saving features. This patch
was tested by setting necessary bit in VBT struct and merging
the new VBT with system BIOS so that we can read the value.
v2: Incorporated review comments from Chris Wilson
Removed "intel_" as a prefix for DRRS specific declarations.
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_drv.h | 9 +++++++++
drivers/gpu/drm/i915/intel_bios.c | 23 +++++++++++++++++++++++
drivers/gpu/drm/i915/intel_bios.h | 29 +++++++++++++++++++++++++++++
3 files changed, 61 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64ed8f4..4d6665b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1175,6 +1175,15 @@ struct intel_vbt_data {
int lvds_ssc_freq;
unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
+ /**
+ * DRRS mode type (Seamless OR Static DRRS)
+ * drrs_mode Val 0x2 is Seamless DRRS and 0 is Static DRRS.
+ * These values correspond to the VBT values for drrs mode.
+ */
+ int drrs_mode;
+ /* DRRS enabled or disabled in VBT */
+ bool drrs_enabled;
+
/* eDP */
int edp_rate;
int edp_lanes;
diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c
index 6dd622d..30ab5a3 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -195,6 +195,21 @@ get_lvds_fp_timing(const struct bdb_header *bdb,
return (const struct lvds_fp_timing *)((const u8 *)bdb + ofs);
}
+/**
+ * This function returns the 2 bit information pertaining to a panel type
+ * present in a 32 bit field in VBT blocks. There are 16 panel types in VBT
+ * each occupying 2 bits of information in some 32 bit fields of VBT blocks.
+ */
+static int
+get_mode_by_paneltype(unsigned int word)
+{
+ /**
+ * The caller of this API should interpret the 2 bits
+ * based on VBT description for that field.
+ */
+ return (word >> ((panel_type - 1) * 2)) & MODE_MASK;
+}
+
/* Try to find integrated panel data */
static void
parse_lfp_panel_data(struct drm_i915_private *dev_priv,
@@ -218,6 +233,11 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
panel_type = lvds_options->panel_type;
+ dev_priv->vbt.drrs_mode =
+ get_mode_by_paneltype(lvds_options->dps_panel_type_bits);
+ DRM_DEBUG_KMS("DRRS supported mode is : %s\n",
+ (dev_priv->vbt.drrs_mode == 0) ? "STATIC" : "SEAMLESS");
+
lvds_lfp_data = find_section(bdb, BDB_LVDS_LFP_DATA);
if (!lvds_lfp_data)
return;
@@ -488,6 +508,9 @@ parse_driver_features(struct drm_i915_private *dev_priv,
if (driver->dual_frequency)
dev_priv->render_reclock_avail = true;
+
+ dev_priv->vbt.drrs_enabled = driver->drrs_state;
+ DRM_DEBUG_KMS("DRRS State Enabled : %d\n", driver->drrs_state);
}
static void
diff --git a/drivers/gpu/drm/i915/intel_bios.h b/drivers/gpu/drm/i915/intel_bios.h
index f580a2b..8e594f6 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -202,6 +202,9 @@ struct bdb_general_features {
#define DEVICE_PORT_DVOB 0x01
#define DEVICE_PORT_DVOC 0x02
+/* Mask for DRRS / Panel Channel / SSC / BLT control bits extraction */
+#define MODE_MASK 0x3
+
/* We used to keep this struct but without any version control. We should avoid
* using it in the future, but it should be safe to keep using it in the old
* code. */
@@ -293,6 +296,18 @@ struct bdb_lvds_options {
u8 lvds_edid:1;
u8 rsvd2:1;
u8 rsvd4;
+ /* LVDS Panel channel bits stored here */
+ u32 lvds_panel_channel_bits;
+ /* LVDS SSC (Spread Spectrum Clock) bits stored here. */
+ u16 ssc_bits;
+ u16 ssc_freq;
+ u16 ssc_ddt;
+ /* Panel color depth defined here */
+ u16 panel_color_depth;
+ /* LVDS panel type bits stored here */
+ u32 dps_panel_type_bits;
+ /* LVDS backlight control type bits stored here */
+ u32 blt_control_type_bits;
} __attribute__((packed));
/* LFP pointer table contains entries to the struct below */
@@ -462,6 +477,20 @@ struct bdb_driver_features {
u8 hdmi_termination;
u8 custom_vbt_version;
+ /* Driver features data block */
+ u16 rmpm_state:1;
+ u16 s2ddt_state:1;
+ u16 dpst_state:1;
+ u16 bltclt_state:1;
+ u16 adb_state:1;
+ u16 drrs_state:1;
+ u16 grs_state:1;
+ u16 gpmt_state:1;
+ u16 tbt_state:1;
+ u16 psr_state:1;
+ u16 ips_state:1;
+ u16 reserved3:4;
+ u16 pc_feature_validity:1;
} __attribute__((packed));
#define EDP_18BPP 0
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/5] drm/i915: Add support for DRRS to switch RR
From: Vandana Kannan @ 2013-12-19 8:31 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1387441863-21953-1-git-send-email-vandana.kannan@intel.com>
From: Pradeep Bhat <pradeep.bhat@intel.com>
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and storing it in crtc_config
v3: Modified reference to edp_downclock and edp_downclock_avail based on the
changes made to move them from dev_private to intel_panel.
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 108 ++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_drv.h | 6 ++-
3 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3be449d..a52c663 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3203,6 +3203,7 @@
#define PIPECONF_INTERLACED_DBL_ILK (4 << 21) /* ilk/snb only */
#define PIPECONF_PFIT_PF_INTERLACED_DBL_ILK (5 << 21) /* ilk/snb only */
#define PIPECONF_INTERLACE_MODE_MASK (7 << 21)
+#define PIPECONF_EDP_RR_MODE_SWITCH (1 << 20)
#define PIPECONF_CXSR_DOWNCLOCK (1<<16)
#define PIPECONF_COLOR_RANGE_SELECT (1 << 13)
#define PIPECONF_BPC_MASK (0x7 << 5)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67674ee..e110f26 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -791,6 +791,22 @@ intel_dp_set_clock(struct intel_encoder *encoder,
}
}
+static void
+intel_dp_set_m2_n2(struct intel_crtc *crtc, struct intel_link_m_n *m_n)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ enum transcoder transcoder = crtc->config.cpu_transcoder;
+
+ I915_WRITE(PIPE_DATA_M2(transcoder),
+ TU_SIZE(m_n->tu) | m_n->gmch_m);
+ I915_WRITE(PIPE_DATA_N2(transcoder), m_n->gmch_n);
+ I915_WRITE(PIPE_LINK_M2(transcoder), m_n->link_m);
+ I915_WRITE(PIPE_LINK_N2(transcoder), m_n->link_n);
+
+ return;
+}
+
bool
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_config *pipe_config)
@@ -894,6 +910,14 @@ found:
pipe_config->port_clock,
&pipe_config->dp_m_n);
+ if (intel_connector->panel.edp_downclock_avail &&
+ intel_dp->drrs_state.is_drrs_supported == SEAMLESS_DRRS_SUPPORT) {
+ intel_link_compute_m_n(bpp, lane_count,
+ intel_connector->panel.edp_downclock,
+ pipe_config->port_clock,
+ &pipe_config->dp_m2_n2);
+ }
+
intel_dp_set_clock(encoder, pipe_config, intel_dp->link_bw);
return true;
@@ -3524,6 +3548,88 @@ intel_dp_init_panel_power_sequencer_registers(struct drm_device *dev,
I915_READ(pp_div_reg));
}
+void
+intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_mode_config *mode_config = &dev->mode_config;
+ struct intel_encoder *encoder;
+ struct intel_dp *intel_dp = NULL;
+ struct intel_crtc_config *config = NULL;
+ struct intel_crtc *intel_crtc = NULL;
+ struct intel_connector *intel_connector = NULL;
+ bool found_edp = false;
+ u32 reg, val;
+ int index = 0;
+
+ if (refresh_rate <= 0) {
+ DRM_INFO("Refresh rate should be positive non-zero.\n");
+ goto out;
+ }
+
+ list_for_each_entry(encoder, &mode_config->encoder_list, base.head) {
+ if (encoder->type == INTEL_OUTPUT_EDP) {
+ intel_dp = enc_to_intel_dp(&encoder->base);
+ intel_crtc = encoder->new_crtc;
+ if (!intel_crtc) {
+ DRM_INFO("DRRS: intel_crtc not initialized\n");
+ goto out;
+ }
+ config = &intel_crtc->config;
+ intel_connector = intel_dp->attached_connector;
+ found_edp = true;
+ break;
+ }
+ }
+
+ if (!found_edp) {
+ DRM_INFO("DRRS supported for eDP only.\n");
+ goto out;
+ }
+
+ if (intel_dp->drrs_state.is_drrs_supported < SEAMLESS_DRRS_SUPPORT) {
+ DRM_INFO("Seamless DRRS not supported.\n");
+ goto out;
+ }
+
+ if (intel_connector->panel.fixed_mode->vrefresh == refresh_rate)
+ index = DRRS_HIGH_RR;
+ else
+ index = DRRS_LOW_RR;
+
+ if (index == intel_dp->drrs_state.drrs_refresh_rate_type) {
+ DRM_INFO("DRRS requested for previously set RR...ignoring\n");
+ goto out;
+ }
+
+ if (!intel_crtc->active) {
+ DRM_INFO("eDP encoder has been disabled. CRTC not Active\n");
+ goto out;
+ }
+
+ mutex_lock(&intel_dp->drrs_state.mutex);
+
+ /* Haswell and below */
+ if (INTEL_INFO(dev)->gen >= 5 && INTEL_INFO(dev)->gen < 8) {
+ reg = PIPECONF(intel_crtc->config.cpu_transcoder);
+ val = I915_READ(reg);
+ if (index > DRRS_HIGH_RR) {
+ val |= PIPECONF_EDP_RR_MODE_SWITCH;
+ intel_dp_set_m2_n2(intel_crtc, &config->dp_m2_n2);
+ } else
+ val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
+ I915_WRITE(reg, val);
+ }
+
+ intel_dp->drrs_state.drrs_refresh_rate_type = index;
+ DRM_INFO("eDP Refresh Rate set to : %dHz\n", refresh_rate);
+
+ mutex_unlock(&intel_dp->drrs_state.mutex);
+
+out:
+ return;
+}
+
static void
intel_dp_drrs_initialize(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector,
@@ -3558,6 +3664,8 @@ intel_dp_drrs_initialize(struct intel_digital_port *intel_dig_port,
intel_connector->panel.edp_downclock =
intel_connector->panel.downclock_mode->clock;
+ mutex_init(&intel_dp->drrs_state.mutex);
+
intel_dp->drrs_state.is_drrs_supported
= dev_priv->vbt.drrs_mode;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index aa79adc..863fa60 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -291,6 +291,9 @@ struct intel_crtc_config {
int pipe_bpp;
struct intel_link_m_n dp_m_n;
+ /* m2_n2 for eDP downclock */
+ struct intel_link_m_n dp_m2_n2;
+
/*
* Frequence the dpll for the port should run at. Differs from the
* adjusted dotclock e.g. for DP or 12bpc hdmi mode. This is also
@@ -491,6 +494,7 @@ enum edp_drrs_refresh_rate_type {
struct drrs_info {
int is_drrs_supported;
int drrs_refresh_rate_type;
+ struct mutex mutex;
};
struct intel_dp {
@@ -763,7 +767,7 @@ void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
void intel_edp_psr_enable(struct intel_dp *intel_dp);
void intel_edp_psr_disable(struct intel_dp *intel_dp);
void intel_edp_psr_update(struct drm_device *dev);
-
+extern void intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate);
/* intel_dsi.c */
bool intel_dsi_init(struct drm_device *dev);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/5] drm/i915: Parse EDID probed modes for DRRS support
From: Vandana Kannan @ 2013-12-19 8:31 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1387441863-21953-1-git-send-email-vandana.kannan@intel.com>
From: Pradeep Bhat <pradeep.bhat@intel.com>
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel supports seamless DRRS or not.
This information is needed for supporting seamless DRRS switch for
certain power saving usecases. This patch is tested by enabling the DRM logs
and user should see whether Seamless DRRS is supported or not.
v2: Daniel's review comments
Modified downclock deduction based on intel_find_panel_downclock
v3: Chris's review comments
Moved edp_downclock_avail and edp_downclock to intel_panel
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_dp.c | 47 ++++++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_drv.h | 32 ++++++++++++++++++++++++++
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 82de200..67674ee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3524,6 +3524,48 @@ intel_dp_init_panel_power_sequencer_registers(struct drm_device *dev,
I915_READ(pp_div_reg));
}
+static void
+intel_dp_drrs_initialize(struct intel_digital_port *intel_dig_port,
+ struct intel_connector *intel_connector,
+ struct drm_display_mode *fixed_mode)
+{
+ struct drm_connector *connector = &intel_connector->base;
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /**
+ * Check if PSR is supported by panel and enabled
+ * if so then DRRS is reported as not supported for Haswell.
+ */
+ if (INTEL_INFO(dev)->gen < 8 && intel_edp_is_psr_enabled(dev)) {
+ DRM_INFO("eDP panel has PSR enabled. Cannot support DRRS\n");
+ return;
+ }
+
+ /* First check if DRRS is enabled from VBT struct */
+ if (!dev_priv->vbt.drrs_enabled) {
+ DRM_INFO("VBT doesn't support DRRS\n");
+ return;
+ }
+
+ intel_connector->panel.downclock_mode = intel_find_panel_downclock(dev,
+ fixed_mode, connector);
+
+ if (intel_connector->panel.downclock_mode != NULL &&
+ dev_priv->vbt.drrs_mode == SEAMLESS_DRRS_SUPPORT) {
+ intel_connector->panel.edp_downclock_avail = true;
+ intel_connector->panel.edp_downclock =
+ intel_connector->panel.downclock_mode->clock;
+
+ intel_dp->drrs_state.is_drrs_supported
+ = dev_priv->vbt.drrs_mode;
+
+ intel_dp->drrs_state.drrs_refresh_rate_type = DRRS_HIGH_RR;
+ DRM_INFO("SEAMLESS DRRS supported for eDP panel.\n");
+ }
+}
+
static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct intel_connector *intel_connector)
{
@@ -3537,6 +3579,8 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
struct drm_display_mode *scan;
struct edid *edid;
+ intel_dp->drrs_state.is_drrs_supported = DRRS_NOT_SUPPORTED;
+
if (!is_edp(intel_dp))
return true;
@@ -3581,6 +3625,9 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp,
list_for_each_entry(scan, &connector->probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
+ if (INTEL_INFO(dev)->gen >= 5)
+ intel_dp_drrs_initialize(intel_dig_port,
+ intel_connector, fixed_mode);
break;
}
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9f8b465..aa79adc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -168,6 +168,9 @@ struct intel_panel {
bool active_low_pwm;
struct backlight_device *device;
} backlight;
+
+ bool edp_downclock_avail;
+ int edp_downclock;
};
struct intel_connector {
@@ -462,6 +465,34 @@ struct intel_hdmi {
#define DP_MAX_DOWNSTREAM_PORTS 0x10
+/**
+ * This enum is used to indicate the DRRS support type.
+ * The values of the enum map 1-to-1 with the values from VBT.
+ */
+enum edp_panel_type {
+ DRRS_NOT_SUPPORTED = -1,
+ STATIC_DRRS_SUPPORT = 0,
+ SEAMLESS_DRRS_SUPPORT = 2
+};
+/**
+ * HIGH_RR is the highest eDP panel refresh rate read from EDID
+ * LOW_RR is the lowest eDP panel refresh rate found from EDID
+ * parsing for same resolution.
+ */
+enum edp_drrs_refresh_rate_type {
+ DRRS_HIGH_RR,
+ DRRS_LOW_RR,
+ DRRS_MAX_RR, /* RR count */
+};
+/**
+ * The drrs_info struct will represent the DRRS feature for eDP
+ * panel.
+ */
+struct drrs_info {
+ int is_drrs_supported;
+ int drrs_refresh_rate_type;
+};
+
struct intel_dp {
uint32_t output_reg;
uint32_t aux_ch_ctl_reg;
@@ -487,6 +518,7 @@ struct intel_dp {
bool want_panel_vdd;
bool psr_setup_done;
struct intel_connector *attached_connector;
+ struct drrs_info drrs_state;
};
struct intel_digital_port {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 5/5] drm/i915/bdw: Add support for DRRS to switch RR
From: Vandana Kannan @ 2013-12-19 8:31 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1387441863-21953-1-git-send-email-vandana.kannan@intel.com>
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next frame
that is output.
v2: Incorporated Chris's review comments
Changed to check for gen >=8 or gen > 5 before setting M/N registers
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/intel_dp.c | 31 ++++++++++++++++++++++++-------
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c96ed34..be06d73 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,11 +798,19 @@ intel_dp_set_m2_n2(struct intel_crtc *crtc, struct intel_link_m_n *m_n)
struct drm_i915_private *dev_priv = dev->dev_private;
enum transcoder transcoder = crtc->config.cpu_transcoder;
- I915_WRITE(PIPE_DATA_M2(transcoder),
- TU_SIZE(m_n->tu) | m_n->gmch_m);
- I915_WRITE(PIPE_DATA_N2(transcoder), m_n->gmch_n);
- I915_WRITE(PIPE_LINK_M2(transcoder), m_n->link_m);
- I915_WRITE(PIPE_LINK_N2(transcoder), m_n->link_n);
+ if (INTEL_INFO(dev)->gen >= 8) {
+ I915_WRITE(PIPE_DATA_M1(transcoder),
+ TU_SIZE(m_n->tu) | m_n->gmch_m);
+ I915_WRITE(PIPE_DATA_N1(transcoder), m_n->gmch_n);
+ I915_WRITE(PIPE_LINK_M1(transcoder), m_n->link_m);
+ I915_WRITE(PIPE_LINK_N1(transcoder), m_n->link_n);
+ } else if (INTEL_INFO(dev)->gen >= 5) {
+ I915_WRITE(PIPE_DATA_M2(transcoder),
+ TU_SIZE(m_n->tu) | m_n->gmch_m);
+ I915_WRITE(PIPE_DATA_N2(transcoder), m_n->gmch_n);
+ I915_WRITE(PIPE_LINK_M2(transcoder), m_n->link_m);
+ I915_WRITE(PIPE_LINK_N2(transcoder), m_n->link_n);
+ }
return;
}
@@ -3616,8 +3624,17 @@ intel_dp_set_drrs_state(struct drm_device *dev, int refresh_rate)
mutex_lock(&intel_dp->drrs_state.mutex);
- /* Haswell and below */
- if (INTEL_INFO(dev)->gen >= 5 && INTEL_INFO(dev)->gen < 8) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ switch (index) {
+ case DRRS_HIGH_RR:
+ intel_dp_set_m2_n2(intel_crtc, &config->dp_m_n);
+ break;
+ case DRRS_LOW_RR:
+ intel_dp_set_m2_n2(intel_crtc, &config->dp_m2_n2);
+ break;
+ };
+ } else if (INTEL_INFO(dev)->gen >= 5) {
+ /* Haswell and below */
reg = PIPECONF(intel_crtc->config.cpu_transcoder);
val = I915_READ(reg);
if (index > DRRS_HIGH_RR) {
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/5] drm/i915: Idleness detection for DRRS
From: Vandana Kannan @ 2013-12-19 8:31 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1387441863-21953-1-git-send-email-vandana.kannan@intel.com>
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in dual-display mode.
v2: Chris's review comments
Modify idleness detection implementation to make it similar to the
implementation of intel_update_fbc/intel_disable_fbc
Change-Id: I17b011b3867a39588375f2b97b992444972f7760
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
---
drivers/gpu/drm/i915/i915_drv.h | 16 +++++
drivers/gpu/drm/i915/intel_display.c | 14 ++++
drivers/gpu/drm/i915/intel_dp.c | 9 +++
drivers/gpu/drm/i915/intel_drv.h | 5 +-
drivers/gpu/drm/i915/intel_pm.c | 122 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/i915/intel_sprite.c | 3 +
6 files changed, 168 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4d6665b..7ed20cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -713,6 +713,21 @@ struct i915_fbc {
} no_fbc_reason;
};
+/* configure the number of secs the system must be idle
+ * before DRRS is enabled
+*/
+#define DRRS_IDLENESS_TIME 2000 /* in millisecs */
+
+struct i915_drrs {
+ struct intel_connector *connector;
+ struct intel_dp *dp;
+ struct intel_drrs_work {
+ struct delayed_work work;
+ struct drm_crtc *crtc;
+ int interval;
+ } *drrs_work;
+};
+
struct i915_psr {
bool sink_support;
bool source_ok;
@@ -1397,6 +1412,7 @@ typedef struct drm_i915_private {
int num_plane;
struct i915_fbc fbc;
+ struct i915_drrs drrs;
struct intel_opregion opregion;
struct intel_vbt_data vbt;
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0332d7c..a25c5da 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2385,6 +2385,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
}
intel_update_fbc(dev);
+ intel_update_drrs(dev);
intel_edp_psr_update(dev);
mutex_unlock(&dev->struct_mutex);
@@ -3549,6 +3550,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
for_each_encoder_on_crtc(dev, crtc, encoder)
@@ -3590,6 +3592,7 @@ static void haswell_crtc_enable_planes(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -3796,6 +3799,7 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -3843,6 +3847,7 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -8184,6 +8189,11 @@ static void intel_unpin_work_fn(struct work_struct *__work)
drm_gem_object_unreference(&work->old_fb_obj->base);
intel_update_fbc(dev);
+
+ /* disable current DRRS work scheduled and restart
+ * to push work by another x seconds
+ */
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
BUG_ON(atomic_read(&to_intel_crtc(work->crtc)->unpin_work_count) == 0);
@@ -8623,6 +8633,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
goto cleanup_pending;
intel_disable_fbc(dev);
+ intel_disable_drrs(dev);
intel_mark_fb_busy(obj, NULL);
mutex_unlock(&dev->struct_mutex);
@@ -10843,6 +10854,7 @@ void intel_modeset_init(struct drm_device *dev)
/* Just in case the BIOS is doing something questionable. */
intel_disable_fbc(dev);
+ intel_disable_drrs(dev);
}
static void
@@ -11250,6 +11262,8 @@ void intel_modeset_cleanup(struct drm_device *dev)
intel_disable_fbc(dev);
+ intel_disable_drrs(dev);
+
intel_disable_gt_powersave(dev);
ironlake_teardown_rc6(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e110f26..c96ed34 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3292,11 +3292,18 @@ void intel_dp_encoder_destroy(struct drm_encoder *encoder)
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
+ struct drm_i915_private *dev_priv = dev->dev_private;
i2c_del_adapter(&intel_dp->adapter);
drm_encoder_cleanup(encoder);
if (is_edp(intel_dp)) {
cancel_delayed_work_sync(&intel_dp->panel_vdd_work);
+ /* DRRS cleanup */
+ if (intel_dp->drrs_state.is_drrs_supported
+ == SEAMLESS_DRRS_SUPPORT) {
+ kfree(dev_priv->drrs.drrs_work);
+ dev_priv->drrs.drrs_work = NULL;
+ }
mutex_lock(&dev->mode_config.mutex);
ironlake_panel_vdd_off_sync(intel_dp);
mutex_unlock(&dev->mode_config.mutex);
@@ -3664,6 +3671,8 @@ intel_dp_drrs_initialize(struct intel_digital_port *intel_dig_port,
intel_connector->panel.edp_downclock =
intel_connector->panel.downclock_mode->clock;
+ intel_init_drrs_idleness_detection(dev,
+ intel_connector, intel_dp);
mutex_init(&intel_dp->drrs_state.mutex);
intel_dp->drrs_state.is_drrs_supported
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 863fa60..18647c7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -899,7 +899,10 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv);
void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv);
void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv);
void ilk_wm_get_hw_state(struct drm_device *dev);
-
+void intel_init_drrs_idleness_detection(struct drm_device *dev,
+ struct intel_connector *connector, struct intel_dp *dp);
+void intel_update_drrs(struct drm_device *dev);
+void intel_disable_drrs(struct drm_device *dev);
/* intel_sdvo.c */
bool intel_sdvo_init(struct drm_device *dev, uint32_t sdvo_reg, bool is_sdvob);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ff47520..3578d31 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -615,6 +615,128 @@ out_disable:
i915_gem_stolen_cleanup_compression(dev);
}
+static void intel_drrs_work_fn(struct work_struct *__work)
+{
+ struct intel_drrs_work *work =
+ container_of(to_delayed_work(__work),
+ struct intel_drrs_work, work);
+ struct drm_device *dev = work->crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ intel_dp_set_drrs_state(work->crtc->dev,
+ dev_priv->drrs.connector->panel.downclock_mode->vrefresh);
+}
+
+static void intel_cancel_drrs_work(struct drm_i915_private *dev_priv)
+{
+ if (dev_priv->drrs.drrs_work == NULL)
+ return;
+
+ DRM_DEBUG_KMS("cancelling pending DRRS enable\n");
+
+ cancel_delayed_work_sync(&dev_priv->drrs.drrs_work->work);
+}
+
+static void intel_enable_drrs(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ intel_cancel_drrs_work(dev_priv);
+
+ if (dev_priv->drrs.dp->drrs_state.drrs_refresh_rate_type
+ != DRRS_LOW_RR) {
+ dev_priv->drrs.drrs_work->crtc = crtc;
+
+ /* Delay the actual enabling to let pageflipping cease and the
+ * display to settle before starting DRRS
+ */
+ schedule_delayed_work(&dev_priv->drrs.drrs_work->work,
+ msecs_to_jiffies(dev_priv->drrs.drrs_work->interval));
+ }
+}
+
+void intel_disable_drrs(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+
+ /* as part of disable DRRS, reset refresh rate to HIGH_RR */
+ if (dev_priv->drrs.dp->drrs_state.drrs_refresh_rate_type
+ == DRRS_LOW_RR) {
+ intel_cancel_drrs_work(dev_priv);
+ intel_dp_set_drrs_state(dev,
+ dev_priv->drrs.connector->panel.fixed_mode->vrefresh);
+ }
+}
+
+/**
+ * intel_update_drrs - enable/disable DRRS as needed
+ * @dev: the drm_device
+ * @update: if set to true, cancel current work and schedule new work.
+ * if set to false, cancel current work and disable DRRS.
+*/
+void intel_update_drrs(struct drm_device *dev)
+{
+ struct drm_crtc *crtc = NULL, *tmp_crtc;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ /* if drrs.connector is NULL, then drrs_init did not get called.
+ * which means DRRS is not supported.
+ */
+ if (dev_priv->drrs.connector == NULL) {
+ DRM_INFO("DRRS is not supported.\n");
+ return;
+ }
+
+ list_for_each_entry(tmp_crtc, &dev->mode_config.crtc_list, head) {
+ if (tmp_crtc != NULL && intel_crtc_active(tmp_crtc) &&
+ to_intel_crtc(tmp_crtc)->primary_enabled) {
+ if (crtc) {
+ DRM_DEBUG_KMS(
+ "more than one pipe active, disabling DRRS\n");
+ goto out_drrs_disable;
+ }
+ crtc = tmp_crtc;
+ }
+ }
+
+ if (crtc == NULL) {
+ DRM_INFO("DRRS: crtc not initialized\n");
+ return;
+ }
+
+ intel_disable_drrs(dev);
+
+ /* re-enable idleness detection */
+ intel_enable_drrs(crtc);
+
+out_drrs_disable:
+ intel_disable_drrs(dev);
+}
+
+void intel_init_drrs_idleness_detection(struct drm_device *dev,
+ struct intel_connector *connector,
+ struct intel_dp *dp)
+{
+ struct intel_drrs_work *work;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ work = kzalloc(sizeof(struct intel_drrs_work), GFP_KERNEL);
+ if (!work) {
+ DRM_ERROR("Failed to allocate DRRS work structure\n");
+ return;
+ }
+
+ dev_priv->drrs.connector = connector;
+ dev_priv->drrs.dp = dp;
+
+ work->interval = DRRS_IDLENESS_TIME;
+ INIT_DELAYED_WORK(&work->work, intel_drrs_work_fn);
+
+ dev_priv->drrs.drrs_work = work;
+}
+
static void i915_pineview_get_mem_freq(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev->dev_private;
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 90a3f6d..637d814 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -560,6 +560,7 @@ intel_enable_primary(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
intel_update_fbc(dev);
+ intel_update_drrs(dev);
mutex_unlock(&dev->struct_mutex);
}
@@ -579,6 +580,8 @@ intel_disable_primary(struct drm_crtc *crtc)
mutex_lock(&dev->struct_mutex);
if (dev_priv->fbc.plane == intel_crtc->plane)
intel_disable_fbc(dev);
+
+ intel_disable_drrs(dev);
mutex_unlock(&dev->struct_mutex);
/*
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] regulator: tps65910: Add backup battery regulator
From: Markus Pargmann @ 2013-12-19 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131218162452.GX28455@sirena.org.uk>
On Wed, Dec 18, 2013 at 04:24:52PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2013 at 03:50:07PM +0100, Markus Pargmann wrote:
>
> > @@ -771,7 +794,7 @@ static struct regulator_ops tps65910_ops = {
> > .get_voltage_sel = tps65910_get_voltage_sel,
> > .set_voltage_sel = tps65910_set_voltage_sel,
> > .list_voltage = regulator_list_voltage_table,
> > - .map_voltage = regulator_map_voltage_ascend,
> > + .map_voltage = regulator_map_voltage_iterate,
> > };
>
> You should make separate ops for this rather than make all the other
> regulators take the performance hit.
Fixed.
>
> > static struct regulator_ops tps65911_ops = {
> > @@ -944,6 +967,7 @@ static struct of_regulator_match tps65910_matches[] = {
> > { .name = "vaux2", .driver_data = (void *) &tps65910_regs[10] },
> > { .name = "vaux33", .driver_data = (void *) &tps65910_regs[11] },
> > { .name = "vmmc", .driver_data = (void *) &tps65910_regs[12] },
> > + { .name = "vbb", .driver_data = (void *) &tps65910_regs[13] },
> > };
>
> Ugh, these numbered tables aren't good. Not a problem from this patch
> though.
>
> > - pmic->desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
> > + if (tps65910_chip_id(tps65910) == TPS65910 &&
> > + i == TPS65910_REG_VBB)
> > + pmic->desc[i].enable_mask = BBCH_BBCHEN_MASK;
> > + else
> > + pmic->desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
>
> switch statements please - it means if additional things need
> customising they can drop right in.
Fixed.
Thank you,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/2] regulator: tps65910: Add backup battery regulator
From: Markus Pargmann @ 2013-12-19 8:23 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-omap, linux-arm-kernel, kernel
In-Reply-To: <20131218162452.GX28455@sirena.org.uk>
On Wed, Dec 18, 2013 at 04:24:52PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2013 at 03:50:07PM +0100, Markus Pargmann wrote:
>
> > @@ -771,7 +794,7 @@ static struct regulator_ops tps65910_ops = {
> > .get_voltage_sel = tps65910_get_voltage_sel,
> > .set_voltage_sel = tps65910_set_voltage_sel,
> > .list_voltage = regulator_list_voltage_table,
> > - .map_voltage = regulator_map_voltage_ascend,
> > + .map_voltage = regulator_map_voltage_iterate,
> > };
>
> You should make separate ops for this rather than make all the other
> regulators take the performance hit.
Fixed.
>
> > static struct regulator_ops tps65911_ops = {
> > @@ -944,6 +967,7 @@ static struct of_regulator_match tps65910_matches[] = {
> > { .name = "vaux2", .driver_data = (void *) &tps65910_regs[10] },
> > { .name = "vaux33", .driver_data = (void *) &tps65910_regs[11] },
> > { .name = "vmmc", .driver_data = (void *) &tps65910_regs[12] },
> > + { .name = "vbb", .driver_data = (void *) &tps65910_regs[13] },
> > };
>
> Ugh, these numbered tables aren't good. Not a problem from this patch
> though.
>
> > - pmic->desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
> > + if (tps65910_chip_id(tps65910) == TPS65910 &&
> > + i == TPS65910_REG_VBB)
> > + pmic->desc[i].enable_mask = BBCH_BBCHEN_MASK;
> > + else
> > + pmic->desc[i].enable_mask = TPS65910_SUPPLY_STATE_ENABLED;
>
> switch statements please - it means if additional things need
> customising they can drop right in.
Fixed.
Thank you,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] irq-renesas-irqc: simplify irq_set_type() method
From: Simon Horman @ 2013-12-19 8:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: tglx, linux-sh, linux-kernel, magnus.damm
In-Reply-To: <201312140309.31407.sergei.shtylyov@cogentembedded.com>
On Sat, Dec 14, 2013 at 03:09:31AM +0300, Sergei Shtylyov wrote:
> Value 0 of the sense selection field of CONFIG_n register means "disable event
> detection" and serves in irqc_sense[] for marking the invalid values of the IRQ
> type (by just omitting initializers). There is no need for INTC_IRQ_SENSE_VALID
> and hence INTC_IRQ_SENSE() as all field values matching to the valid IRQ types
> are non-zero anyway.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Magnus, could you review this?
>
> ---
> The patch is against the 'irq/core' branch of the 'tip.git' repo.
>
> drivers/irqchip/irq-renesas-irqc.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> Index: renesas/drivers/irqchip/irq-renesas-irqc.c
> =================================> --- renesas.orig/drivers/irqchip/irq-renesas-irqc.c
> +++ renesas/drivers/irqchip/irq-renesas-irqc.c
> @@ -81,15 +81,12 @@ static void irqc_irq_disable(struct irq_
> iowrite32(BIT(hw_irq), p->cpu_int_base + IRQC_EN_STS);
> }
>
> -#define INTC_IRQ_SENSE_VALID 0x10
> -#define INTC_IRQ_SENSE(x) (x + INTC_IRQ_SENSE_VALID)
> -
> static unsigned char irqc_sense[IRQ_TYPE_SENSE_MASK + 1] = {
> - [IRQ_TYPE_LEVEL_LOW] = INTC_IRQ_SENSE(0x01),
> - [IRQ_TYPE_LEVEL_HIGH] = INTC_IRQ_SENSE(0x02),
> - [IRQ_TYPE_EDGE_FALLING] = INTC_IRQ_SENSE(0x04), /* Synchronous */
> - [IRQ_TYPE_EDGE_RISING] = INTC_IRQ_SENSE(0x08), /* Synchronous */
> - [IRQ_TYPE_EDGE_BOTH] = INTC_IRQ_SENSE(0x0c), /* Synchronous */
> + [IRQ_TYPE_LEVEL_LOW] = 0x01,
> + [IRQ_TYPE_LEVEL_HIGH] = 0x02,
> + [IRQ_TYPE_EDGE_FALLING] = 0x04, /* Synchronous */
> + [IRQ_TYPE_EDGE_RISING] = 0x08, /* Synchronous */
> + [IRQ_TYPE_EDGE_BOTH] = 0x0c, /* Synchronous */
> };
>
> static int irqc_irq_set_type(struct irq_data *d, unsigned int type)
> @@ -101,12 +98,12 @@ static int irqc_irq_set_type(struct irq_
>
> irqc_dbg(&p->irq[hw_irq], "sense");
>
> - if (!(value & INTC_IRQ_SENSE_VALID))
> + if (!value)
> return -EINVAL;
>
> tmp = ioread32(p->iomem + IRQC_CONFIG(hw_irq));
> tmp &= ~0x3f;
> - tmp |= value ^ INTC_IRQ_SENSE_VALID;
> + tmp |= value;
> iowrite32(tmp, p->iomem + IRQC_CONFIG(hw_irq));
> return 0;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] irq-renesas-irqc: simplify irq_set_type() method
From: Simon Horman @ 2013-12-19 8:24 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: tglx, linux-sh, linux-kernel, magnus.damm
In-Reply-To: <201312140309.31407.sergei.shtylyov@cogentembedded.com>
On Sat, Dec 14, 2013 at 03:09:31AM +0300, Sergei Shtylyov wrote:
> Value 0 of the sense selection field of CONFIG_n register means "disable event
> detection" and serves in irqc_sense[] for marking the invalid values of the IRQ
> type (by just omitting initializers). There is no need for INTC_IRQ_SENSE_VALID
> and hence INTC_IRQ_SENSE() as all field values matching to the valid IRQ types
> are non-zero anyway.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Magnus, could you review this?
>
> ---
> The patch is against the 'irq/core' branch of the 'tip.git' repo.
>
> drivers/irqchip/irq-renesas-irqc.c | 17 +++++++----------
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> Index: renesas/drivers/irqchip/irq-renesas-irqc.c
> ===================================================================
> --- renesas.orig/drivers/irqchip/irq-renesas-irqc.c
> +++ renesas/drivers/irqchip/irq-renesas-irqc.c
> @@ -81,15 +81,12 @@ static void irqc_irq_disable(struct irq_
> iowrite32(BIT(hw_irq), p->cpu_int_base + IRQC_EN_STS);
> }
>
> -#define INTC_IRQ_SENSE_VALID 0x10
> -#define INTC_IRQ_SENSE(x) (x + INTC_IRQ_SENSE_VALID)
> -
> static unsigned char irqc_sense[IRQ_TYPE_SENSE_MASK + 1] = {
> - [IRQ_TYPE_LEVEL_LOW] = INTC_IRQ_SENSE(0x01),
> - [IRQ_TYPE_LEVEL_HIGH] = INTC_IRQ_SENSE(0x02),
> - [IRQ_TYPE_EDGE_FALLING] = INTC_IRQ_SENSE(0x04), /* Synchronous */
> - [IRQ_TYPE_EDGE_RISING] = INTC_IRQ_SENSE(0x08), /* Synchronous */
> - [IRQ_TYPE_EDGE_BOTH] = INTC_IRQ_SENSE(0x0c), /* Synchronous */
> + [IRQ_TYPE_LEVEL_LOW] = 0x01,
> + [IRQ_TYPE_LEVEL_HIGH] = 0x02,
> + [IRQ_TYPE_EDGE_FALLING] = 0x04, /* Synchronous */
> + [IRQ_TYPE_EDGE_RISING] = 0x08, /* Synchronous */
> + [IRQ_TYPE_EDGE_BOTH] = 0x0c, /* Synchronous */
> };
>
> static int irqc_irq_set_type(struct irq_data *d, unsigned int type)
> @@ -101,12 +98,12 @@ static int irqc_irq_set_type(struct irq_
>
> irqc_dbg(&p->irq[hw_irq], "sense");
>
> - if (!(value & INTC_IRQ_SENSE_VALID))
> + if (!value)
> return -EINVAL;
>
> tmp = ioread32(p->iomem + IRQC_CONFIG(hw_irq));
> tmp &= ~0x3f;
> - tmp |= value ^ INTC_IRQ_SENSE_VALID;
> + tmp |= value;
> iowrite32(tmp, p->iomem + IRQC_CONFIG(hw_irq));
> return 0;
> }
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 2/2] ARM: dts: tps65910 backup battery regulator
From: Markus Pargmann @ 2013-12-19 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131218162546.GY28455@sirena.org.uk>
On Wed, Dec 18, 2013 at 04:25:46PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2013 at 03:50:08PM +0100, Markus Pargmann wrote:
> > This patch adds a devicetree node for the backup battery regulator.
>
> Your previous patch missed an update to the binding documentation for
> the regulator driver.
Right, thank you, I added vbb to the tps65910 mfd binding documentation.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: tps65910 backup battery regulator
From: Markus Pargmann @ 2013-12-19 8:25 UTC (permalink / raw)
To: Mark Brown; +Cc: Liam Girdwood, linux-omap, linux-arm-kernel, kernel
In-Reply-To: <20131218162546.GY28455@sirena.org.uk>
On Wed, Dec 18, 2013 at 04:25:46PM +0000, Mark Brown wrote:
> On Wed, Dec 18, 2013 at 03:50:08PM +0100, Markus Pargmann wrote:
> > This patch adds a devicetree node for the backup battery regulator.
>
> Your previous patch missed an update to the binding documentation for
> the regulator driver.
Right, thank you, I added vbb to the tps65910 mfd binding documentation.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH] ARM: shmobile: mackerel: Fix USBHS pinconf entry
From: Simon Horman @ 2013-12-19 8:27 UTC (permalink / raw)
To: linux-sh
In-Reply-To: <1387032301-6609-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Sat, Dec 14, 2013 at 03:45:01PM +0100, Laurent Pinchart wrote:
> Fix a typo in the USBHS1 pinconf entry that prevented the pull-down from
> being enabled.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> arch/arm/mach-shmobile/board-mackerel.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Simon,
>
> The bug that this patch fixes got introduced in "ARM: shmobile: mackerel: Use
> pinconf API to configure pin pull-down". Feel free to squash the fix with the
> original patch if possible.
Thanks, Laurent.
I will queue this up as an incremental patch.
>
> diff --git a/arch/arm/mach-shmobile/board-mackerel.c b/arch/arm/mach-shmobile/board-mackerel.c
> index 207acf0..b3ee96e 100644
> --- a/arch/arm/mach-shmobile/board-mackerel.c
> +++ b/arch/arm/mach-shmobile/board-mackerel.c
> @@ -1406,7 +1406,7 @@ static const struct pinctrl_map mackerel_pinctrl_map[] = {
> /* USBHS1 */
> PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs.1", "pfc-sh7372",
> "usb1_vbus", "usb1"),
> - PIN_MAP_CONFIGS_GROUP_DEFAULT("renesas_usbhs.&", "pfc-sh7372",
> + PIN_MAP_CONFIGS_GROUP_DEFAULT("renesas_usbhs.1", "pfc-sh7372",
> "usb1_vbus", pin_pulldown_conf),
> PIN_MAP_MUX_GROUP_DEFAULT("renesas_usbhs.1", "pfc-sh7372",
> "usb1_otg_id_0", "usb1"),
> --
> Regards,
>
> Laurent Pinchart
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/4] android/bluetooth: Add initial support for permanent storage
From: Johan Hedberg @ 2013-12-19 8:29 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1387375558-17976-2-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Wed, Dec 18, 2013, Szymon Janc wrote:
> +static void store_adapter_config(void)
> +{
> + GKeyFile *key_file;
> + gsize length = 0;
> + char addr[18];
> + char *data;
> +
> + key_file = g_key_file_new();
> +
> + if (!g_key_file_load_from_file(key_file, ANDROID_STORAGEDIR"/settings",
> + 0, NULL)) {
> + int fd = open(ANDROID_STORAGEDIR"/settings", O_CREAT, 0600);
> + if (fd < 0) {
> + error("Failed to create adapter config file: %d (%s)",
> + errno, strerror(errno));
> + return;
> + }
> +
> + close(fd);
> + }
> +
> + ba2str(&adapter.bdaddr, addr);
> +
> + g_key_file_set_string(key_file, "General", "Address", addr);
> + g_key_file_set_string(key_file, "General", "Name", adapter.name);
> + g_key_file_set_integer(key_file, "General", "DiscoverableTimeout",
> + adapter.discoverable_timeout);
> +
> + data = g_key_file_to_data(key_file, &length, NULL);
> +
> + g_file_set_contents(ANDROID_STORAGEDIR"/settings", data, length, NULL);
The whole open(..., O_CREAT, ...) trick you do seems completely
unnecessary as g_key_file_to_data will create the file if it doesn't
exist. Instead, if you want to log an error you'd need to check if
g_key_file_contents failed or not. Adding a GError into the mix and
logging the exact error message would be even better.
Johan
^ permalink raw reply
* [PATCH] perf config: ignore generated files in feature-checks
From: Chunwei Chen @ 2013-12-19 8:29 UTC (permalink / raw)
To: lkml; +Cc: Chunwei Chen, Ingo Molnar
Signed-off-by: Chunwei Chen <tuxoko@gmail.com>
---
tools/perf/config/feature-checks/.gitignore | 2 ++
1 file changed, 2 insertions(+)
create mode 100644 tools/perf/config/feature-checks/.gitignore
diff --git a/tools/perf/config/feature-checks/.gitignore b/tools/perf/config/feature-checks/.gitignore
new file mode 100644
index 0000000..9662c68
--- /dev/null
+++ b/tools/perf/config/feature-checks/.gitignore
@@ -0,0 +1,2 @@
+test-all
+*.d
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.