On Wed, 08 Jun 2011 11:32:47 -0700
Kevin Hilman khil...@ti.com wrote:
I traced breakage to commit 638080c (OMAP2+ / PM: move runtime
PM implementation to use device power domains).
Reventing that and and 2064af9 (PM: Revert driver core: platform_bus:
allow runtime override of
On Wed, Jun 8, 2011 at 1:46 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Tuesday 07 June 2011 15:46:26 Ohad Ben-Cohen wrote:
Where do you take care of those potential offsets today ? Or do you
simply ignore the offsets and map the entire page ?
Here
On 06/09/11 03:21, Alexander Holler wrote:
On 08.06.2011 23:57, Igor Grinberg wrote:
On 06/07/11 14:15, Alexander Holler wrote:
Am 07.06.2011 11:50, schrieb Igor Grinberg:
On 06/07/11 11:01, Alexander Holler wrote:
Am 31.05.2011 12:29, schrieb Tony Lindgren:
* Alexander
Hello,
Am 09.06.2011 09:40, schrieb Igor Grinberg:
On 06/09/11 03:21, Alexander Holler wrote:
I see. Is the new patch version somehow provides better functionality?
You configure the gpio for output, this means that the pin is actually driven
and not just relies on internal pullup (which can
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains should be idled
post a state_switch *only* if idle transitions on the
sleep_switch which is initialised to 0 in omap_set_pwrdm_state
happens to be a valid sleep_switch type (FORCEWAKEUP_SWITCH)
which are defined as
#define FORCEWAKEUP_SWITCH 0
#define LOWPOWERSTATE_SWITCH1
This causes the function to wrongly program some clock domains
even when the
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain.c | 21 +
arch/arm/mach-omap2/clockdomain.h |3 +++
2 files changed, 24 insertions(+), 0
Since MMC driver is yet to be adapted to
runtime PM and still uses direct clock
calls to enable/disable module, its needed
that the clockdomain (for MMC) is always kept force
enabled since the next few patches move
the clockdomain handling from clock framework
to hwmod framework and break MMC.
Add the SoC specific implemenation for clkdm_is_idle
for OMAP2/3 and OMAP4.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 12
arch/arm/mach-omap2/clockdomain44xx.c |7 +++
2 files changed, 19 insertions(+), 0 deletions(-)
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to enable or auto
-3- Wait for the desired module idle status to be FUNC
-4- Program clkdm in HW_AUTO(if supported)
This sequence applies to all older
Optional clocks have a requirement to have the clockdomain
force enabled (SW_WKUP) before the optional clock itself
is enabled.
Since optional clocks are currently handled directly by
drivers using the clock framework, this needs to be handled
at the clock framework. This sequence is already
Hi,
On OMAP4, the PRCM recommended sequence for enabling
a module after power-on-reset is
-1- Force clkdm to SW_WKUP
-2- Configure desired module mode to enable or auto
-3- Wait for the desired module idle status to be FUNC
-4- Program clkdm in HW_AUTO(if supported)
This sequence applies to all
There is a need to identify optional clock nodes in
the clock framework, so some specific sequence
to enable them can be supported, which should be
evident in the subsequent patches.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c| 34
SDMA and EDMA are TI SoC specific DMA controllers. Their drivers have been
maintained in the respective SoC folders till now.
arch/arm/plat-omap/dma.c
arch/arm/mach-davinci/dma.c
I have gone through the existing offload engine (DMA) drivers in drivers/dma
which do slave transfers. I would like
Can you please re-post with sensible wrapping at or before column 72.
I'm not manually reformatting your entire message just so I can find
the relevant bits to reply to.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Hello,
Following set contains PRCM chain interrupt handling for OMAP3/4. Contents
of this set:
- Patch 1 was initially made by Thomas Petazzoni I believe, I made some
OMAP4 specific fixes on that one and updated this to conform to latest
kernel APIs. This patch contains the main logic for
Introduce a chained interrupt handler mechanism for the PRCM
interrupt, so that individual PRCM event can cleanly be handled by
handlers in separate drivers. We do this by introducing PRCM event
names, which are then matched to the particular PRCM interrupt bit
depending on the specific OMAP SoC
PRCM interrupt handler will now parse registered pads to see whether there
is an active wakeup event. If this is the case, the corresponding interrupt
will be triggered. This can be used for example with UART driver to register
PAD wakeup event for the UART RX pin, and when this happens, UART
This patch is just to test that the idea works generally, proper implementation
should be done for the OMAP UART driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/pm44xx.c |4
arch/arm/mach-omap2/serial.c |3 +++
drivers/tty/serial/omap-serial.c |
Hello,
Changes since v2:
- TWL_COMMON_PDATA_AUDIO is used from the beginning, reducing changes later
- twl6040 thermal shutdown handling added
- pmic-common.c/h renamed as twl-common.c/h. This will allows new twl related
features to be added, not directly related to pmic.
- Rebased on top
Reduce the amount of duplicated code by moving the common
configuration for TWL6030 (on OMAP4 platform) to the
twl-common file.
Use the omap4_pmic_get_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Misael Lopez Cruz misael.lo...@ti.com
---
drivers/input/misc/Kconfig |2 +-
Allign the platform data names for twl4030 audio submodule:
twl4030_audio_data: for the core MFD driver
twl4030_codec_data: for ASoC codec driver
twl4030_vibra_data: for the input/ForceFeedback driver
To avoid breakage, change all depending drivers, files
to use the new types.
Signed-off-by:
From: Misael Lopez Cruz misael.lo...@ti.com
Convert TWL6040 CODEC driver into a TWL6040 MFD child, it implies
that MFD-level operations like register accesses, clock setting
and power management are done through MFD APIs, not directly by
CODEC driver anymore. To avoid conflicts with the other MFD
Pass twl4030_codec_data instead of the twl4030_audio_data
for the ASoC codec driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040-core.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/twl6040-core.c
Add twl4030_vibra platform data, and the needed regulators
for twl6040 vibrator.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 48 +++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git
From: Misael Lopez Cruz misael.lo...@ti.com
Add twl6040_vibra as a child of MFD device twl6040_codec. This
implementation covers the PCM-to-PWM mode of TWL6040 vibrator
module.
Signed-off-by: Jorge Eduardo Candelaria jorge.candela...@ti.com
Signed-off-by: Misael Lopez Cruz misael.lo...@ti.com
From: Misael Lopez Cruz misael.lo...@ti.com
TWL6040 IC provides analog high-end audio codec functions for
handset applications. It contains several audio analog inputs
and outputs as well as vibrator support. It's connected to the
host processor via PDM interface for audio data communication.
The
In preparation of renaming the driver from twl4030-codec
to twl4030-audio, first do some clean ups in the driver,
which does not cause any problems outside.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl4030-codec.c | 135 ++-
1
Some regulator config can be moved out from board files,
since they are close to identical.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 51 --
arch/arm/mach-omap2/board-cm-t35.c | 41
Reduce the amount of duplicated code by moving the common
configuration for twl4030/5030/tpsxx to the twl-common file.
Use the omap3_pmic_get_config function from board files to
properly configure the PMIC with the common fields.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Introduce a new file, which will be used to configure
common pmic (TWL) devices, regulators, and TWL audio.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/common-board-devices.c | 21 -
Hello,
I want to power down Voice/Bluetooth sidetone PGA of TWL5030.
I set the VSTPGA Register/BTSTPGA Register to 0x00,but it seems that
the Voice/Bluetooth sidetone PGA still work,
and even set VSTPGA/BTSTPGA to Mute,there still have sidetone come out.
How can I power down Voice/Bluetooth
Hello,
I want to power down Voice/Bluetooth sidetone PGA of TWL5030.
I set the VSTPGA Register/BTSTPGA Register to 0x00,but it seems that
the Voice/Bluetooth sidetone PGA still work,
and even set VSTPGA/BTSTPGA to Mute,there still have sidetone come out.
How can I power down Voice/Bluetooth
On Wed, 8 Jun 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
[...]
you need to separate the system suspend handling from runtime PM.
/me risks getting yelled at again and jumps back in ;)
Each of them requires a different approach, because the goal is really
Hi,
This patch set implements runtime PM adaptation for OMAP DSS driver.
This is second version of the set, changing the way pm_runtime is used. In this
version the omapdss' pm_runtime adaptation is written as it should be, using
pm_runtime callbacks, in which context save/restore and opt-clock
get_context_loss_count functions return context loss count as u32, and
zero means an error. However, zero is also returned when context has
never been lost and could also be returned when the context loss count
has wrapped and goes to zero.
Change the functions to return an int, with negative
If ULPS exit fails, and the following reset fails also, Taal driver was
left in state where it thinks DSI is enabled while it really isn't,
leading to crash.
This patch checks the return value of taal_panel_reset, and if that
fails, ulps_enabled is left true, causing the driver to retry ulps exit
LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause
any problems currently, as DSI HW is reset when it is enabled. However,
if the reset is not done, operation fails if the bits are still set.
So reset the bits after entering ULPS to ensure operation even without
HW reset.
Get and put for dpll4_m4_ck was handled in dss_init/dss_exit. Move the
code to dss_get/put_clocks(), which is a better place to handle it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 52
1 files changed, 26
Both dss.c and dsi.c had a probe function, which was almost a dummy one,
calling dss_init() and dsi_init().
Remove the init functions by moving the initialization code into probe
functions.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 30 ++---
The initialization order of the DSS modules is important when pm_runtime
support is implemented. Currently RFBI is initialized before DISPC,
which will cause problems with pm_runtime as RFBI uses DISPC.
Change the init order so that DISPC is before RFBI.
Signed-off-by: Tomi Valkeinen
The function to get device's context loss count has changed from
omap_pm_get_last_off_on_transaction_id() to
omap_pm_get_dev_context_loss_count()
Change name of the function pointer in omapdss.h accordingly, and use
the term context loss count instead of context id in the code.
Restructure the
DSS enables core clocks for the duration of initialization to avoid
unnecessary context saves and restores.
With PM runtime the clocks cannot be handled in this way, outside the
dss module drivers. Thus we need to remove the optimization.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Initialize get_context_loss_count in the DSS board data to
omap_pm_get_dev_context_loss_count, so that omapdss driver can use it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git
DSI PLL requires sys_clk to function, and DPI enables sys_clk when it
wants to use DSI PLL. However, DSI PLL code already handles enabling
sys_clk, so DPI's sys_clk code is extra.
Remove the unneeded sys_clk handling from dpi.c.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
OMAP2 doesn't have CPR, PRELOAD nor FIR_COEF_V registers. Add new
feature definitions for those, and check the feature before accessing
those registers.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c| 145
OMAP3430 requires an 96MHz clock to VENC's DAC, but no other OMAP needs
it.
Add a new feature, FEAT_VENC_REQUIRES_TV_DAC_CLK, which tells if the
clock is needed on this platform, and use that feature in venc.c to
decide if the clock needs enabling.
Signed-off-by: Tomi Valkeinen
Currently dss.c does all the low level clock handling in the DSS, and
thus it contains pointers to all the clocks. This allows dss.c to dump
the clock information for all the clocks.
With pm_runtime this is no longer the case, as each submodule will
handle its clocks independently. Thus remove
CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET is used to avoid an unclear bug at
DSS reset time. The pm runtime will handle reset in the future, and this
code has to be removed. Hopefully we won't see this error anymore.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Add missing DSS optional clocks to HWMOD data for OMAP4xxx.
Add HWMOD_CONTROL_OPT_CLKS_IN_RESET flag for dispc to fix dispc reset.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 40
Add DSS optional clocks to HWMOD data for OMAP2420.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git
Add DSS optional clocks to HWMOD data for OMAP2430.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git
Add DSS optional clocks to HWMOD data for OMAP3xxx.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 37 ++-
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git
Currently using pm_runtime with DSS requires the DSS driver to enable
the DSS functional clock before calling pm_runtime_get(). That makes it
impossible to use pm_runtime in DSS as it is meant to be used, with
pm_runtime callbacks.
This patch changes the hwmod database for OMAP4 so that enabling
Some of the optional clocks for dss_core are not needed. Remove them.
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git
opt_clock_available() is no longer needed, so remove it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 12
include/video/omapdss.h |2 --
2 files changed, 0 insertions(+), 14 deletions(-)
diff --git
dss.c only saves 1 register (3 in OMAP3) so the extra overhead from
need_ctx_restore co. is probably bigger than the time spent saving and
restoring those few registers every time.
So remove the code from dss.c and restore context every time dss has
been off.
Signed-off-by: Tomi Valkeinen
The current method of saving and restoring the context could cause a
restore before saving, effectively restoring zero values to registers.
Add ctx_valid field to indicate if the saved context is valid and can be
restored.
Also restructure the code to save the ctx_loss_count in save_context(),
omapdss driver now gets the clocks via hwmod opt clocks, so clock
aliases for omapdss_dss are no longer needed.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 10 +-
1
The current method of saving and restoring the context could cause a
restore before saving, effectively restoring zero values to registers.
Add ctx_valid field to indicate if the saved context is valid and can be
restored.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
oh_core variable is no longer used, so it and its initialization can be
removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 10 --
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c
dispc.c enables and disables clocks in almost every function to make
sure the clocks are enabled when the function is called. This is rather
unoptimal way to handle the problem.
With pm_runtime other components have to call dispc_runtime_get() to
enable dispc clocks before calling any other dispc
On Thu, 2011-06-09 at 16:56 +0300, Tomi Valkeinen wrote:
Hi,
This patch set implements runtime PM adaptation for OMAP DSS driver.
These patches can be found from:
git://gitorious.org/linux-omap-dss2/linux.git pmruntime
The branch is actually pmruntime-v2, my mistake.
Tomi
--
To
Hi Kevin and Felipe,
Kevin Hilman wrote:
In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support
for device power domains) a better way for handling platform-specific
power hooks was introduced.
Rather than using the platform_bus dev_pm_ops overrides
Here it is, with proper line wrapping;
SDMA and EDMA are TI SoC specific DMA controllers. Their drivers have
been maintained in the respective SoC folders till now.
arch/arm/plat-omap/dma.c
arch/arm/mach-davinci/dma.c
I have gone through the existing offload engine (DMA) drivers in
drivers/dma
On Thu, Jun 09, 2011 at 09:31:56PM +0530, Raju, Sundaram wrote:
Here it is, with proper line wrapping;
Thanks. This is much easier to reply to.
I believe that even though the dmaengine framework addresses and
supports most of the required use cases of a client driver to a DMA
controller,
Sakari Ailus sakari.ai...@maxwell.research.nokia.com writes:
Hi Kevin and Felipe,
Kevin Hilman wrote:
In commit 7538e3db6e015e890825fbd9f8659952896ddd5b (PM: add support
for device power domains) a better way for handling platform-specific
power hooks was introduced.
Rather than using
Nishanth Menon n...@ti.com writes:
OMAP3+: PM: VC: handle mutant channel config for OMAP4 MPU channel
handles the mutant channel flags, however since vc_cfg_bits is static
file wide variable, it makes better sense to update this based on
the specific channel using mutant or not. else if we
Nishanth Menon n...@ti.com writes:
if volt_reg and cmd_reg are the same from PMIC configuration,
we can use the cmd reg by using racen -
-ECONFUSED
If volt_reg and cmd_reg are the same then I understood RACEN to be a
don't care. Zero means use volt_reg, 1 means use cmd_reg, but if
volt_reg
Nishanth Menon n...@ti.com writes:
OMAP4's PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. In combinations where the same slave address
is used for all domains, it is possible to setup the VC channel for the
dependent channels to use the same
Kevin Hilman khil...@ti.com writes:
[...]
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index f079167..1732258 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -109,6 +109,15 @@ struct omap_volt_data {
u8 vp_errgain;
Nishanth Menon n...@ti.com writes:
OMAP4's PRM_VC_CFG_CHANNEL register allows for flexibility of configuring
for various PMIC configurations. In combinations where we'd like to
use the default VC channel's voltage_reg address in a particular non-default
VC channel, we allow the use of
On Thu, Jun 9, 2011 at 6:09 PM, Raju, Sundaram sunda...@ti.com wrote:
Generic buffer description:
A generic buffer can be split into number of frames which contain number of
chunks inside them. The frames need not be contiguous, nor do the chunks
inside a frame.
On Thursday 09 June 2011 15:30:24 Peter Ujfalusi wrote:
Rename the driver, and header file from twl4030-codec to
twl4030-audio.
To avoid breakage change depending drivers at the same time.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: Misael Lopez Cruz misael.lo...@ti.com
---
On Thu, Jun 09, 2011 at 04:56:42PM +0300, Tomi Valkeinen wrote:
+int dispc_runtime_get(void)
+{
+ int r;
+
+ DSSDBG(dispc_runtime_get\n);
+
+ r = pm_runtime_get_sync(dispc.pdev-dev);
+ WARN_ON(r 0);
+ return r 0 ? r : 0;
+}
+
+void dispc_runtime_put(void)
+{
+
Hi Govindraj
On 06/08/2011 11:35 PM, Govindraj wrote:
On Thu, Jun 9, 2011 at 2:09 AM, Jon Hunterjon-hun...@ti.com wrote:
Hi Govindraj,
On 6/8/2011 6:23 AM, Govindraj.R wrote:
[snip]
+
+#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is msecs */
[snip]
@@ -1295,18 +1381,36 @@
On 06/09/2011 03:49 PM, Jon Hunter wrote:
Hi Govindraj
On 06/08/2011 11:35 PM, Govindraj wrote:
On Thu, Jun 9, 2011 at 2:09 AM, Jon Hunterjon-hun...@ti.com wrote:
Hi Govindraj,
On 6/8/2011 6:23 AM, Govindraj.R wrote:
[snip]
+
+#define OMAP_UART_AUTOSUSPEND_DELAY (30 * HZ) /* Value is
we have a special section for const data
which is only needed during init, that's
__initconst. Use that instead of __initdata
which is for non-const data.
Signed-off-by: Felipe Balbi ba...@ti.com
---
This patch is against devel-devicetree branch from
linux-omap.
On Thu, Jun 09, 2011 at 04:24:06PM +0530, Rajendra Nayak wrote:
Add a clockdomain api to check if hardware supervised
idle transitions are enabled on a clockdomain.
...
+ * clkdm_is_idle - Check if the clkdm hwsup/autoidle is enabled
A minor suggestion on naming: clkdm_allows_idle seems more
On Thu, Jun 09, 2011 at 04:24:09PM +0530, Rajendra Nayak wrote:
The omap_set_pwrdm_state function forces clockdomains
to idle, without checking the existing idle state
programmed, instead based solely on the HW capability
of the clockdomain to support idle.
This is wrong and the clockdomains
Hi,
I have mcbsp1 working on an external codec. I moved the wires to the
mcbsp3 pins. The codec is master, using tdm mode. I use the same codec
i2s bus, and it gets the same setup (I change the dai-link stuff in my
alsa machine driver to use the other omap i2s bus for my tests). If I
pull the clk
On Thursday 09 June 2011 22:37:28 Arnd Bergmann wrote:
Better use the -M flag to git-format-patch when moving files, to make it
obvious what has or has not changed, and to reduce the size of the email.
I tend to forgot the -M flag, thanks.
Also, shouldn't this file go into the sound/soc/
83 matches
Mail list logo
