* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Wei Yongjun @ 2016-09-25 15:44 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Fixes the following sparse warning:
drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
symbol 'sdhci_arasan_reset' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/mmc/host/sdhci-of-arasan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
index da8e40a..e263671 100644
--- a/drivers/mmc/host/sdhci-of-arasan.c
+++ b/drivers/mmc/host/sdhci-of-arasan.c
@@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
}
-void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
+static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
{
u8 ctrl;
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
^ permalink raw reply related
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Boris Brezillon @ 2016-09-25 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921104414.16241-1-nicolas.ferre@atmel.com>
On Wed, 21 Sep 2016 12:44:14 +0200
Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> From: Alexey Starikovskiy <aystarik@gmail.com>
>
> The problem with previous code was it rounded values in wrong
> place and produced wrong baud rate in some cases.
>
> Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> drivers/tty/serial/atmel_serial.c | 10 ++++++----
> include/linux/atmel_serial.h | 1 +
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index 5f550d9feed9..fd8aa1f4ba78 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -2170,13 +2170,15 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> * accurately. This feature is enabled only when using normal mode.
> * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
> * Currently, OVER is always set to 0 so we get
> - * baudrate = selected clock (16 * (CD + FP / 8))
> + * baudrate = selected clock / (16 * (CD + FP / 8))
> + * then
> + * 8 CD + FP = selected clock / (2 * baudrate)
> */
> if (atmel_port->has_frac_baudrate &&
> (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> - div = DIV_ROUND_CLOSEST(port->uartclk, baud);
> - cd = div / 16;
> - fp = DIV_ROUND_CLOSEST(div % 16, 2);
> + div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
> + cd = div >> 3;
> + fp = div & ATMEL_US_FP_MASK;
> } else {
> cd = uart_get_divisor(port, baud);
> }
> diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
> index f8e452aa48d7..bd2560502f3c 100644
> --- a/include/linux/atmel_serial.h
> +++ b/include/linux/atmel_serial.h
> @@ -119,6 +119,7 @@
> #define ATMEL_US_BRGR 0x20 /* Baud Rate Generator Register */
> #define ATMEL_US_CD GENMASK(15, 0) /* Clock Divider */
> #define ATMEL_US_FP_OFFSET 16 /* Fractional Part */
> +#define ATMEL_US_FP_MASK 0x7
>
> #define ATMEL_US_RTOR 0x24 /* Receiver Time-out Register for USART */
> #define ATMEL_UA_RTOR 0x28 /* Receiver Time-out Register for UART */
^ permalink raw reply
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Boris Brezillon @ 2016-09-25 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922114308.0913c60e@bbrezillon>
On Thu, 22 Sep 2016 11:43:08 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
> On Thu, 22 Sep 2016 09:39:04 +0200
> Boris Brezillon <boris.brezillon@free-electrons.com> wrote:
>
> > On Thu, 22 Sep 2016 09:07:46 +0200
> > Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de> wrote:
> >
> > > On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote:
> > > > From: Alexey Starikovskiy <aystarik@gmail.com>
> > > >
> > > > The problem with previous code was it rounded values in wrong
> > > > place and produced wrong baud rate in some cases.
> > > >
> > > > Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> > > > [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> > > > Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> > > > ---
> > > > drivers/tty/serial/atmel_serial.c | 10 ++++++----
> > > > include/linux/atmel_serial.h | 1 +
> > > > 2 files changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > > index 5f550d9feed9..fd8aa1f4ba78 100644
> > > > --- a/drivers/tty/serial/atmel_serial.c
> > > > +++ b/drivers/tty/serial/atmel_serial.c
> > > > @@ -2170,13 +2170,15 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
> > > > * accurately. This feature is enabled only when using normal mode.
> > > > * baudrate = selected clock / (8 * (2 - OVER) * (CD + FP / 8))
> > > > * Currently, OVER is always set to 0 so we get
> > > > - * baudrate = selected clock (16 * (CD + FP / 8))
> > > > + * baudrate = selected clock / (16 * (CD + FP / 8))
> > > > + * then
> > > > + * 8 CD + FP = selected clock / (2 * baudrate)
> > > > */
> > > > if (atmel_port->has_frac_baudrate &&
> > > > (mode & ATMEL_US_USMODE) == ATMEL_US_USMODE_NORMAL) {
> > > > - div = DIV_ROUND_CLOSEST(port->uartclk, baud);
> > > > - cd = div / 16;
> > > > - fp = DIV_ROUND_CLOSEST(div % 16, 2);
> > > > + div = DIV_ROUND_CLOSEST(port->uartclk, baud * 2);
> > > > + cd = div >> 3;
> > > > + fp = div & ATMEL_US_FP_MASK;
> > >
> > > given baud = 115200 and uartclk = 5414300 this results in:
> > >
> > > div = DIV_ROUND_CLOSEST(5414300, 115200 * 2) = 23
> > > cd = 2
> > > fp = 7
> >
> > How about:
> >
> > div = DIV_ROUND_CLOSEST(port->uartclk, baud);
> > cd = div / 16;
> > fp = (div % 16) / 2;
> >
> > best_baud = port->uartclk / ((16 * cd) + (8 * fp));
> >
> > /* Check if we can get a better approximation by rounding up. */
> > if (div % 2) {
> > int alt_baud, alt_fp, alt_cd;
> >
> > alt_fp = fp++;
> > alt_cd = cd;
> > if (alt_fp > 7) {
> > alt_cd++;
> > alt_fp = 0;
> > }
> >
> > alt_baud = port->uartclk / ((16 * alt_cd) + (8 *alt_fp));
> > if (abs(best_baud - baud) > abs(alt_baud - baud)) {
>
> After a lengthy discussion that happened on IRC (#armlinux), Uwe
> proved me wrong. This should actually be
>
>
> /*
> * Calculate the Error in the time domain:
> * Error = (RealBaudPeriod - ExpectedBaudPeriod) /
> * ExpectedBaudPeriod;
> *
> * which after conversion to the frequency domain gives:
> * Error = 1 - (ExpectedBaudRate/RealBaudRate);
> *
> * and since we want to compare 2 errors and avoid
> * approximation, we have:
> *
> * if (RealBaudRate2 * (RealBaudRate1 - ExpectedBaudRate) <
> * RealBaudRate1 * (RealBaudRate2 - ExpectedBaudRate))
> * ...
> *
> */
> if (alt_baud * abs(best_baud - baud) >
> best_baud * abs(alt_baud - baud))
>
> Thanks for your patience ;-).
>
> > best_baud = alt_baud;
> > fp = alt_fp;
> > cd = alt_cd;
> > }
> > }
> >
> > >
> > > which yields a rate of 5414300 / 46 = 117702.17. With cd = 3 and fp = 0
> > > however the resulting rate is 5414300 / 48 = 112797.92.
> > >
> > > Which one is better?
Okay, it seems I was wrong here. It appears that 117702.17 is better
than 112797.92, and Alexey's patch is calculating the best cd and fp
values for all cases.
^ permalink raw reply
* [PATCH 0/4] Add DMA support for ti_am335x_adc driver
From: Jonathan Cameron @ 2016-09-25 9:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921161134.6951-1-mugunthanvnm@ti.com>
On 21/09/16 17:11, Mugunthan V N wrote:
> The ADC has a 64 work depth fifo length which holds the ADC data
> till the CPU reads. So when a user program needs a large ADC data
> to operate on, then it has to do multiple reads to get its
> buffer. Currently if the application asks for 4 samples per
> channel with all 8 channels are enabled, kernel can provide only
> 3 samples per channel when all 8 channels are enabled (logs at
> [1]). So with DMA support user can request for large number of
> samples at a time (logs at [2]).
>
> Tested the patch on AM437x-gp-evm and AM335x Boneblack with the
> patch [3] to enable ADC and pushed a branch for testing [4]
>
> [1] - http://pastebin.ubuntu.com/23211490/
> [2] - http://pastebin.ubuntu.com/23211492/
> [3] - http://pastebin.ubuntu.com/23211494/
> [4] - git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git iio-dma
Just curious. How fast is the ADC sampling at in these? Never that
obvious for this driver!
I'm also curious as to whether you started to hit the limits of the
kfifo based interface. Might be worth considering adding alternative
support for the dma buffers interface which is obviously much lower
overhead.
Good to have this work prior to that as the kfifo stuff is somewhat
easier to use.
Jonathan
>
> Mugunthan V N (4):
> mfd: ti_am335x_tscadc: store physical address
> drivers: iio: ti_am335x_adc: add dma support
> ARM: dts: am33xx: add DMA properties for tscadc
> ARM: dts: am4372: add DMA properties for tscadc
>
> arch/arm/boot/dts/am33xx.dtsi | 2 +
> arch/arm/boot/dts/am4372.dtsi | 2 +
> drivers/iio/adc/ti_am335x_adc.c | 160 ++++++++++++++++++++++++++++++++++-
> drivers/mfd/ti_am335x_tscadc.c | 1 +
> include/linux/mfd/ti_am335x_tscadc.h | 8 ++
> 5 files changed, 170 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* [PATCH 3/5] iio: adc: sunxi-gpadc-iio: enable iio_buffers
From: Jonathan Cameron @ 2016-09-25 9:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ffca0be9-56c0-5f84-09ee-884d5e94e9df@free-electrons.com>
On 24/09/16 18:40, Quentin Schulz wrote:
> Hi Jonathan,
>
> Sorry for the (long) delay, I did not have time to work on it. I'll
> mainly work in my free time now.
>
> Keep in mind this patch was proposed based on the v2 of the ADC patches.
> Since then, substantial changes have been made and I'm working on
> rebasing this series of patches on the v6, so comments here might
> include references to code parts added later in the ADC patch series.
>
> On 24/07/2016 13:03, Jonathan Cameron wrote:
>> On 20/07/16 09:29, Quentin Schulz wrote:
>>> This enables the use of buffers on ADC channels of sunxi-gpadc-iio driver.
>>> It also prepares the code which will be used by the touchscreen driver
>>> named sunxi-gpadc-ts.
>>>
>>> The GPADC on Allwinner SoCs (A10, A13 and A31) has a 12 bits register for
>>> conversion's data. The GPADC uses the same ADC channels for the ADC and the
>>> touchscreen therefore exposes these channels to the sunxi-gpadc-ts iio
>>> consumer which will be in charge of reading data from these channels for
>>> the input framework.
>>>
>>> The temperature can only be read when in touchscreen mode. This means if
>>> the buffers are being used for the ADC, the temperature sensor cannot be
>>> read.
>> That may be the bizarest hardware restriction I've heard of in a while! :)
>>>
>>> When a FIFO_DATA_PENDING irq occurs, its handler will read the entire FIFO
>>> and fill a buffer before sending it to the consumers which registered in
>>> IIO for the ADC channels.
>>>
>>> When a consumer starts buffering ADC channels,
>>> sunxi_gpadc_buffer_postenable is called and will enable FIFO_DATA_PENDING
>>> irq and select the mode in which the GPADC should run (ADC or touchscreen)
>>> depending on a property of the DT ("allwinner,ts-attached").
>>> When the consumer stops buffering, it disables the same irq.
>> Hmm. Might be possible to distinguish which consumer caused the start.
>> Thus, if the touchscreen is there we would know purely based on the
>> driver being the requester that we need to be in touchscreen mode.
>>
>
> As of yet, can't see in which way I can retrieve the consumer in
> provider code. Maybe I'm missing something, I don't know?
I don't think we have a current way of doing this... Might be possible
to add one, but it would be a rather odd bit of reverse looking up.
>
>>>
>>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>> You are moving fast on this - I'd have been tempted to do a mega
>> series with the updated version of the basic support and this on top
>> rather than a new unconnected series.
>>
>> (I'd forgotten that was still under review so got confused when I
>> went to look something up in the files you are modifying!).
>>> ---
>>> drivers/iio/adc/Kconfig | 1 +
>>> drivers/iio/adc/sunxi-gpadc-iio.c | 153 ++++++++++++++++++++++++++++++++++----
>>> 2 files changed, 138 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
>>> index 184856f..15e3b08 100644
>>> --- a/drivers/iio/adc/Kconfig
>>> +++ b/drivers/iio/adc/Kconfig
>>> @@ -342,6 +342,7 @@ config SUNXI_ADC
>>> tristate "ADC driver for sunxi platforms"
>>> depends on IIO
>>> depends on MFD_SUNXI_ADC
>>> + depends on IIO_BUFFER_CB
>>> help
>>> Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
>>> ADC. This ADC provides 4 channels which can be used as an ADC or as a
>>> diff --git a/drivers/iio/adc/sunxi-gpadc-iio.c b/drivers/iio/adc/sunxi-gpadc-iio.c
>>> index 87cc913..2e44ca7 100644
>>> --- a/drivers/iio/adc/sunxi-gpadc-iio.c
>>> +++ b/drivers/iio/adc/sunxi-gpadc-iio.c
>>> @@ -16,8 +16,9 @@
>>> #include <linux/platform_device.h>
>>> #include <linux/regmap.h>
>>>
>>> -#include <linux/iio/iio.h>
>>> +#include <linux/iio/buffer.h>
>>> #include <linux/iio/driver.h>
>>> +#include <linux/iio/iio.h>
>> Can't say I'm a particular fan of reordering headers to be in alphabetical
>> order, but I suppose it doesn't really matter if you want to do it.
>> (to my mind there is a tree structure implicit in these headers with iio.h
>> at the top for generic support, then the various sub elements below).
>>
>>> #include <linux/iio/machine.h>
>>> #include <linux/mfd/sunxi-gpadc-mfd.h>
>>>
>>> @@ -71,6 +72,7 @@
>>> #define SUNXI_GPADC_TP_DATA_XY_CHANGE BIT(13)
>>> #define SUNXI_GPADC_TP_FIFO_TRIG_LEVEL(x) ((x) << 8) /* 5 bits */
>>> #define SUNXI_GPADC_TP_DATA_DRQ_EN BIT(7)
>>> +/* Be careful, flushing FIFO spawns SUNXI_GPADC_FIFO_DATA_PENDING interrupts */
>> Sounds like you learned that one the hard way ;)
>>> #define SUNXI_GPADC_TP_FIFO_FLUSH BIT(4)
>>> #define SUNXI_GPADC_TP_UP_IRQ_EN BIT(1)
>>> #define SUNXI_GPADC_TP_DOWN_IRQ_EN BIT(0)
>>> @@ -79,6 +81,7 @@
>>> #define SUNXI_GPADC_TEMP_DATA_PENDING BIT(18)
>>> #define SUNXI_GPADC_FIFO_OVERRUN_PENDING BIT(17)
>>> #define SUNXI_GPADC_FIFO_DATA_PENDING BIT(16)
>>> +#define SUNXI_GPADC_RXA_CNT GENMASK(12, 8)
>>> #define SUNXI_GPADC_TP_IDLE_FLG BIT(2)
>>> #define SUNXI_GPADC_TP_UP_PENDING BIT(1)
>>> #define SUNXI_GPADC_TP_DOWN_PENDING BIT(0)
>>> @@ -101,19 +104,43 @@ struct sunxi_gpadc_dev {
>>> unsigned int fifo_data_irq;
>>> unsigned int temp_data_irq;
>>> unsigned int flags;
>>> + struct iio_dev *indio_dev;
>> I was suprised to see this as normally it is cleaner to structure
>> the whole code to go in one direction through the structures (which is
>> why we don't provide a generic iio_device_from_priv bit of pointer magic).
>>
>> Anyhow, don't htink you are actually using it ;)
>>
>
> I'm using to push to buffers from the irq handler since I pass the local
> structure (sunxi_gpadc_dev) to the irq handler when registering it. But
> I guess I can pass the iio_dev instead and remove this from the local
> structure.
I'd prefer passing the iio_dev and keep all lookups in one direction.
>
> [...]
>>> static int sunxi_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>>> int *val)
>>> {
>>> struct sunxi_gpadc_dev *info = iio_priv(indio_dev);
>>> + bool buffered = info->buffered;
>> Not worth the local version...
>>> int ret = 0;
>>> + unsigned int reg;
>>>
>>> mutex_lock(&indio_dev->mlock);
>>>
>>> reinit_completion(&info->completion);
>>> +
>>> + reg = SUNXI_GPADC_TP_FIFO_TRIG_LEVEL(1) | SUNXI_GPADC_TP_FIFO_FLUSH;
>>> + regmap_update_bits(info->regmap, SUNXI_GPADC_TP_INT_FIFOC, reg, reg);
>> I'd put it in directly rahter than having a reg local variable. To mind
>> mind that would be slightly easier to understand.
>>> +
>>> if (info->flags & SUNXI_GPADC_ARCH_SUN6I)
>>> regmap_write(info->regmap, SUNXI_GPADC_TP_CTRL1,
>>> SUNXI_GPADC_SUN6I_TP_MODE_EN |
>>> @@ -153,9 +185,9 @@ static int sunxi_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
>>> SUNXI_GPADC_TP_MODE_EN |
>>> SUNXI_GPADC_TP_ADC_SELECT |
>>> SUNXI_GPADC_ADC_CHAN_SELECT(channel));
>>> - regmap_write(info->regmap, SUNXI_GPADC_TP_INT_FIFOC,
>>> - SUNXI_GPADC_TP_FIFO_TRIG_LEVEL(1) |
>>> - SUNXI_GPADC_TP_FIFO_FLUSH);
>> Whole load of infrastructure in place to lock buffered mode out and
>> revent transitions when we can't have them.
>>
>> iio_claim_direct_mode etc. I think you can just use that here?
>> If you need to do extra checks on it being enabled that should be
>> fine too.
>>
>
> Yes, way better with iio_device_claim_direct_mode and iio_buffer_enabled!
>
>> As a general rule, it makes sense to simply disable polled reads
>> if in buffered mode. Leads to much simpler code and generally
>> the data is already known to userspace anyway.
>>
>
> That's what I try to do.
> However, I think the temperature of the SoC is an interesting feature to
> have. Since it ("hardwarely") works while the ADC is read in touchscreen
> mode (even in buffer mode), I guess it could be a good idea to allow it
> in the driver. If we don't do that, boards with a touchscreen connected
> to the ADC of the SoC will not get SoC temperatures and can't have
> proper thermal management. We already have one board in that case: the
> PocketCHIP.
>
> Therefore, I also need to know if when the buffer is enabled, if it's
> for buffering ADC data or touchscreen data. If it's for ADC data, then I
> should disable temperature readings since it will return senseless
> values (from memory, always 0 which means something like -144?C).
Nice so no thermal management if we don't have a touch screen :)
>
>> I have been meaning to do it a bit better when we have multiple
>> in kernel consumers, some expecting polled readings and some
>> pushed. There some core caching magic will make sense to
>> keep the polled channels as available as possible when running
>> the buffers.
>>
>> A bit fiddly to implement + might have some slightly suprising
>> results on delays on channels when say a sysfs trigger is
>> being used... (not a problem here as you have a fifo and hence
>> aren't using triggers).
>>
>> Anyhow, not really relevant here :)
>>
> [...]
>>> case IIO_CHAN_INFO_RAW:
>> Definitely use the iio_claim_direct_mode stuff here to avoid possible races
>> with the buffer being enabled whilst this read is in flight.
>
> Indeed.
>
>>> + if (info->buffered)
>>> + return -EBUSY;
>>> +
>>> ret = sunxi_gpadc_adc_read(indio_dev, chan->channel, val);
>>> if (ret)
>>> return ret;
>>> @@ -261,7 +302,29 @@ static irqreturn_t sunxi_gpadc_temp_data_irq_handler(int irq, void *dev_id)
>>> static irqreturn_t sunxi_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
>>> {
>>> struct sunxi_gpadc_dev *info = dev_id;
>>> - int ret;
>>> + int ret, reg, i, fifo_count;
>>> +
>>> + if (info->buffered) {
>>> + if (regmap_read(info->regmap, SUNXI_GPADC_TP_INT_FIFOS, ®))
>>> + return IRQ_HANDLED;
>>> +
>>> + fifo_count = (reg & SUNXI_GPADC_RXA_CNT) >> 8;
>>> + /* Sometimes, the interrupt occurs when the FIFO is empty. */
>>> + if (!fifo_count)
>>> + return IRQ_HANDLED;
>>> +
>>> + for (i = 0; i < fifo_count; i++) {
>>> + if (regmap_read(info->regmap, SUNXI_GPADC_TP_DATA,
>>> + &info->buffer.buffer[i]))
>>> + return IRQ_HANDLED;
>>> + }
>>> +
>>> + info->buffer.buff_size = i;
>>> +
>>> + iio_push_to_buffers(info->indio_dev, &info->buffer);
>> This is expecting a single 'scan' - e.g. set of channels read at one
>> time. Here I think we could have repeated sets of channels?
>> (at least that would be what is normally meant by a fifo in such
>> a device).
>>
>> If so you need to read 'whole' scans and push them one at a time.
>> We don't yet have a bulk iio_push_to_buffers, though we can add
>> one if it makes sense. Care will be needed though as we'd need
>> handle the case of different consumers either supporting or
>> not supporting this new functionality. Not particularly hard though
>> if it is worth doing.
>
> I didn't know it was meant for only one scan. Then I need a bulk
> iio_push_to_buffers.
We've had a few cases where that would be handy recently.
The bit that makes it complex is if we are doing any demux of the channels
to multiple consumers. Could be done by falling back to separating
the scan's out and pushing them one by one through the demux though.
Not sure there is a better way to do it though...
>
> I have a rather big problem. The whole first FIFO at each touch is
> unusable so I have to drop it. I can detect the beginning of a touch
> when the TP_UP irq occurs, then I know the next full FIFO the consumer
> receives by callback is to be dropped. If I use push_to_buffers to send
> coordinates by coordinates, the consumer has no mean to know when the
> second FIFO (the first to be valid) starts and can be used. Either we
> can find a way to notify the consumer of the start of a new FIFO or I
> have to use a bulk iio_push_to_buffers.
Nasty indeed.
>
> The workaround would be to register the TP_UP irq in the provider (the
> ADC driver) and do not send the first FIFO to the consumer. But then, we
> need a way to know which consumer requests buffering to know when to
> enable this irq and do all touchscreen-only logic (dropping first
> frame). And I guess we don't have something like that yet. Or I could
> only code a buffering in touchscreen mode and add the ADC buffering
> later? But it doesn't feel right to do what I think should be handled
> (TP_UP irq handler and first FIFO dropping) in the consumer, in the
> provider.
Would indeed by the nicer way of doing it, but we are ultimately working
around a hardware issue (to my mind it should never return rubbish!)
so I'd not worry too much about where the fix is.
>
> So it's quiet a dead-end yet if I can't use iio_push_to_buffers with a
> whole FIFO (which you told is not how it is meant to be used).
It only worked here because you had control of both ends of the link.
First thought is that we should add a bulk push to buffers, but
that a little bit of fiddly code would be needed to unwind the
data in the demux if needed. Probably not too hard to do. It would then
need to repackage the data up as a bulk buffer data block to send onwards.
To do this I think you'd need to:
1) Add core support to have a bulk push with the right magic around to call
the demux code in a loop over all the elements before pushing on.
2) Bulk handling in the callback buffer.
3) Kfifo bulk handling (mostly to allow us to test the demux code).
Actually, short of stuff I haven't thought of, doesn't look too tricky
and useful feature to have in general.
Jonathan
>
> [...]
> Thanks,
>
> Quentin
>
^ permalink raw reply
* [linux-sunxi] [PATCH v6 0/3] ASoC: sun4i-codec: Distinguish sun4i from sun7i
From: Danny Milosavljevic @ 2016-09-25 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924200503.10728-1-dannym@scratchpost.org>
The only changes here are the commit summary in the cover letter (it's correct now) and the commit message of patch 1.
I see that the v5 patches 2 and 3 have already been applied in the mean time - and the functional content in v6 is identical.
Therefore, the only thing that needs to be looked at is patch 1 - where I modified the commit message only compared to v5.
Thanks!
^ permalink raw reply
* [PATCH] drm/exynos: mark exynos_dp_crtc_clock_enable() static
From: Baoyou Xie @ 2016-09-25 7:54 UTC (permalink / raw)
To: linux-arm-kernel
We get 1 warning when building kernel with W=1:
drivers/gpu/drm/exynos/exynos_dp.c:46:5: warning: no previous prototype for 'exynos_dp_crtc_clock_enable' [-Wmissing-prototypes]
In fact, this function is only used in the file in which it is
declared and don't need a declaration, but can be made static.
So this patch marks it 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/exynos/exynos_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index 4f08505..528229f 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -43,7 +43,7 @@ struct exynos_dp_device {
struct analogix_dp_plat_data plat_data;
};
-int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
+static int exynos_dp_crtc_clock_enable(struct analogix_dp_plat_data *plat_data,
bool enable)
{
struct exynos_dp_device *dp = to_dp(plat_data);
--
2.7.4
^ permalink raw reply related
* [PATCH v4 1/1] clk: mvebu: migrate CP110 system controller to clk_hw API and registration
From: Marcin Wojtas @ 2016-09-25 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789673-3837-1-git-send-email-mw@semihalf.com>
Now that we have clk_hw based provider APIs to register clks, we
can get rid of struct clk pointers while registering clks in Armada
CP110 system controller driver. This commit introduces new
API and registration for all clocks in CP110 HW blocks.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
---
drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
1 file changed, 72 insertions(+), 78 deletions(-)
diff --git a/drivers/clk/mvebu/cp110-system-controller.c b/drivers/clk/mvebu/cp110-system-controller.c
index f2303da..0116808 100644
--- a/drivers/clk/mvebu/cp110-system-controller.c
+++ b/drivers/clk/mvebu/cp110-system-controller.c
@@ -87,7 +87,7 @@ struct cp110_gate_clk {
u8 bit_idx;
};
-#define to_cp110_gate_clk(clk) container_of(clk, struct cp110_gate_clk, hw)
+#define to_cp110_gate_clk(hw) container_of(hw, struct cp110_gate_clk, hw)
static int cp110_gate_enable(struct clk_hw *hw)
{
@@ -123,13 +123,14 @@ static const struct clk_ops cp110_gate_ops = {
.is_enabled = cp110_gate_is_enabled,
};
-static struct clk *cp110_register_gate(const char *name,
- const char *parent_name,
- struct regmap *regmap, u8 bit_idx)
+static struct clk_hw *cp110_register_gate(const char *name,
+ const char *parent_name,
+ struct regmap *regmap, u8 bit_idx)
{
struct cp110_gate_clk *gate;
- struct clk *clk;
+ struct clk_hw *hw;
struct clk_init_data init;
+ int ret;
gate = kzalloc(sizeof(*gate), GFP_KERNEL);
if (!gate)
@@ -146,39 +147,37 @@ static struct clk *cp110_register_gate(const char *name,
gate->bit_idx = bit_idx;
gate->hw.init = &init;
- clk = clk_register(NULL, &gate->hw);
- if (IS_ERR(clk))
+ hw = &gate->hw;
+ ret = clk_hw_register(NULL, hw);
+ if (ret) {
kfree(gate);
+ hw = ERR_PTR(ret);
+ }
- return clk;
+ return hw;
}
-static void cp110_unregister_gate(struct clk *clk)
+static void cp110_unregister_gate(struct clk_hw *hw)
{
- struct clk_hw *hw;
-
- hw = __clk_get_hw(clk);
- if (!hw)
- return;
-
- clk_unregister(clk);
+ clk_hw_unregister(hw);
kfree(to_cp110_gate_clk(hw));
}
-static struct clk *cp110_of_clk_get(struct of_phandle_args *clkspec, void *data)
+static struct clk_hw *cp110_of_clk_get(struct of_phandle_args *clkspec,
+ void *data)
{
- struct clk_onecell_data *clk_data = data;
+ struct clk_hw_onecell_data *clk_data = data;
unsigned int type = clkspec->args[0];
unsigned int idx = clkspec->args[1];
if (type == CP110_CLK_TYPE_CORE) {
if (idx > CP110_MAX_CORE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[idx];
+ return clk_data->hws[idx];
} else if (type == CP110_CLK_TYPE_GATABLE) {
if (idx > CP110_MAX_GATABLE_CLOCKS)
return ERR_PTR(-EINVAL);
- return clk_data->clks[CP110_MAX_CORE_CLOCKS + idx];
+ return clk_data->hws[CP110_MAX_CORE_CLOCKS + idx];
}
return ERR_PTR(-EINVAL);
@@ -189,8 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
struct regmap *regmap;
struct device_node *np = pdev->dev.of_node;
const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
- struct clk_onecell_data *cp110_clk_data;
- struct clk *clk, **cp110_clks;
+ struct clk_hw_onecell_data *cp110_clk_data;
+ struct clk_hw *hw, **cp110_clks;
u32 nand_clk_ctrl;
int i, ret;
@@ -203,80 +202,75 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
- cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
- CP110_CLK_NUM, GFP_KERNEL);
- if (!cp110_clks)
- return -ENOMEM;
-
- cp110_clk_data = devm_kzalloc(&pdev->dev,
- sizeof(*cp110_clk_data),
+ cp110_clk_data = devm_kzalloc(&pdev->dev, sizeof(*cp110_clk_data) +
+ sizeof(struct clk_hw *) * CP110_CLK_NUM,
GFP_KERNEL);
if (!cp110_clk_data)
return -ENOMEM;
- cp110_clk_data->clks = cp110_clks;
- cp110_clk_data->clk_num = CP110_CLK_NUM;
+ cp110_clks = cp110_clk_data->hws;
+ cp110_clk_data->num = CP110_CLK_NUM;
- /* Register the APLL which is the root of the clk tree */
+ /* Register the APLL which is the root of the hw tree */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_APLL, &apll_name);
- clk = clk_register_fixed_rate(NULL, apll_name, NULL, 0,
- 1000 * 1000 * 1000);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_rate(NULL, apll_name, NULL, 0,
+ 1000 * 1000 * 1000);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail0;
}
- cp110_clks[CP110_CORE_APLL] = clk;
+ cp110_clks[CP110_CORE_APLL] = hw;
/* PPv2 is APLL/3 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_PPV2, &ppv2_name);
- clk = clk_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, ppv2_name, apll_name, 0, 1, 3);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail1;
}
- cp110_clks[CP110_CORE_PPV2] = clk;
+ cp110_clks[CP110_CORE_PPV2] = hw;
/* EIP clock is APLL/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_EIP, &eip_name);
- clk = clk_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, eip_name, apll_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail2;
}
- cp110_clks[CP110_CORE_EIP] = clk;
+ cp110_clks[CP110_CORE_EIP] = hw;
/* Core clock is EIP/2 */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_CORE, &core_name);
- clk = clk_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, core_name, eip_name, 0, 1, 2);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail3;
}
- cp110_clks[CP110_CORE_CORE] = clk;
+ cp110_clks[CP110_CORE_CORE] = hw;
/* NAND can be either APLL/2.5 or core clock */
of_property_read_string_index(np, "core-clock-output-names",
CP110_CORE_NAND, &nand_name);
if (nand_clk_ctrl & NF_CLOCK_SEL_400_MASK)
- clk = clk_register_fixed_factor(NULL, nand_name,
- apll_name, 0, 2, 5);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ apll_name, 0, 2, 5);
else
- clk = clk_register_fixed_factor(NULL, nand_name,
- core_name, 0, 1, 1);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = clk_hw_register_fixed_factor(NULL, nand_name,
+ core_name, 0, 1, 1);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail4;
}
- cp110_clks[CP110_CORE_NAND] = clk;
+ cp110_clks[CP110_CORE_NAND] = hw;
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
const char *parent, *name;
@@ -335,16 +329,16 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
break;
}
- clk = cp110_register_gate(name, parent, regmap, i);
- if (IS_ERR(clk)) {
- ret = PTR_ERR(clk);
+ hw = cp110_register_gate(name, parent, regmap, i);
+ if (IS_ERR(hw)) {
+ ret = PTR_ERR(hw);
goto fail_gate;
}
- cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
+ cp110_clks[CP110_MAX_CORE_CLOCKS + i] = hw;
}
- ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);
+ ret = of_clk_add_hw_provider(np, cp110_of_clk_get, cp110_clk_data);
if (ret)
goto fail_clk_add;
@@ -355,44 +349,44 @@ static int cp110_syscon_clk_probe(struct platform_device *pdev)
fail_clk_add:
fail_gate:
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
fail4:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
fail3:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
fail2:
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
fail1:
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
fail0:
return ret;
}
static int cp110_syscon_clk_remove(struct platform_device *pdev)
{
- struct clk **cp110_clks = platform_get_drvdata(pdev);
+ struct clk_hw **cp110_clks = platform_get_drvdata(pdev);
int i;
of_clk_del_provider(pdev->dev.of_node);
for (i = 0; i < CP110_MAX_GATABLE_CLOCKS; i++) {
- struct clk *clk = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
+ struct clk_hw *hw = cp110_clks[CP110_MAX_CORE_CLOCKS + i];
- if (clk)
- cp110_unregister_gate(clk);
+ if (hw)
+ cp110_unregister_gate(hw);
}
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
- clk_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
- clk_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_NAND]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_CORE]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_EIP]);
+ clk_hw_unregister_fixed_factor(cp110_clks[CP110_CORE_PPV2]);
+ clk_hw_unregister_fixed_rate(cp110_clks[CP110_CORE_APLL]);
return 0;
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH v4 0/1] Armada 7k/8k CP110 system controller fixes
From: Marcin Wojtas @ 2016-09-25 7:47 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Two patches from the third version of the patchset have already been
applied, so I re-send the last one with corrected allocation of
clock data, which was pointed in the review.
Any feedback would be very welcome.
Best regards,
Marcin
Changelog:
v4 <- v3
* fix allocation of clock data
v3 <- v2
* return -ENOMEM on alloc failures
v1 <- v2
* replace setting CLK_IS_BASIC flag with clearing init structure fields
with memset
* minor improvements of allocation and error checking
* add migration to clk_hw
Marcin Wojtas (1):
clk: mvebu: migrate CP110 system controller to clk_hw API and
registration
drivers/clk/mvebu/cp110-system-controller.c | 150 +++++++++++++---------------
1 file changed, 72 insertions(+), 78 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH 2/2] drm/rockchip: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:43 UTC (permalink / raw)
To: linux-arm-kernel
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:309:6: warning: no previous prototype for 'rockchip_drm_fb_suspend' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_drv.c:318:6: warning: no previous prototype for 'rockchip_drm_fb_resume' [-Wmissing-prototypes]
In fact, these functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 76eaf1d..38c3be5 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -309,7 +309,7 @@ static struct drm_driver rockchip_drm_driver = {
};
#ifdef CONFIG_PM_SLEEP
-void rockchip_drm_fb_suspend(struct drm_device *drm)
+static void rockchip_drm_fb_suspend(struct drm_device *drm)
{
struct rockchip_drm_private *priv = drm->dev_private;
@@ -318,7 +318,7 @@ void rockchip_drm_fb_suspend(struct drm_device *drm)
console_unlock();
}
-void rockchip_drm_fb_resume(struct drm_device *drm)
+static void rockchip_drm_fb_resume(struct drm_device *drm)
{
struct rockchip_drm_private *priv = drm->dev_private;
--
2.7.4
^ permalink raw reply related
* [PATCH] drm/mediatek: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:41 UTC (permalink / raw)
To: linux-arm-kernel
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]
In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..be4e19c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1086,19 +1086,19 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
return 0;
}
-void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, true);
hdmi->audio_enable = true;
}
-void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, false);
hdmi->audio_enable = false;
}
-int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+static int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
struct hdmi_audio_param *param)
{
if (!hdmi->audio_enable) {
@@ -1624,7 +1624,8 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data)
mtk_hdmi_audio_disable(hdmi);
}
-int mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH] drm/mediatek: mark symbols static where possible
From: Baoyou Xie @ 2016-09-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474789109-22010-1-git-send-email-baoyou.xie@linaro.org>
We get 4 warnings when building kernel with W=1:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1089:6: warning: no previous prototype for 'mtk_hdmi_audio_enable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1095:6: warning: no previous prototype for 'mtk_hdmi_audio_disable' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1101:5: warning: no previous prototype for 'mtk_hdmi_audio_set_param' [-Wmissing-prototypes]
drivers/gpu/drm/mediatek/mtk_hdmi.c:1627:5: warning: no previous prototype for 'mtk_hdmi_audio_digital_mute' [-Wmissing-prototypes]
In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks both functions with 'static'.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/mediatek/mtk_hdmi.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
index 334562d..be4e19c 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
@@ -1086,19 +1086,19 @@ static int mtk_hdmi_output_init(struct mtk_hdmi *hdmi)
return 0;
}
-void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_enable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, true);
hdmi->audio_enable = true;
}
-void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
+static void mtk_hdmi_audio_disable(struct mtk_hdmi *hdmi)
{
mtk_hdmi_aud_enable_packet(hdmi, false);
hdmi->audio_enable = false;
}
-int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
+static int mtk_hdmi_audio_set_param(struct mtk_hdmi *hdmi,
struct hdmi_audio_param *param)
{
if (!hdmi->audio_enable) {
@@ -1624,7 +1624,8 @@ static void mtk_hdmi_audio_shutdown(struct device *dev, void *data)
mtk_hdmi_audio_disable(hdmi);
}
-int mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
+static int
+mtk_hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
{
struct mtk_hdmi *hdmi = dev_get_drvdata(dev);
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drm/rockchip: add missing header dependencies
From: Baoyou Xie @ 2016-09-25 7:38 UTC (permalink / raw)
To: linux-arm-kernel
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:130:5: warning: no previous prototype for 'rockchip_drm_fbdev_init' [-Wmissing-prototypes]
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c:173:6: warning: no previous prototype for 'rockchip_drm_fbdev_fini' [-Wmissing-prototypes]
In fact, these functions are declared
in drivers/gpu/drm/rockchip/rockchip_drm_fbdev.h,
so this patch adds missing header dependencies.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
index 207e01d..a16c69f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c
@@ -20,6 +20,7 @@
#include "rockchip_drm_drv.h"
#include "rockchip_drm_gem.h"
#include "rockchip_drm_fb.h"
+#include "rockchip_drm_fbdev.h"
#define PREFERRED_BPP 32
#define to_drm_private(x) \
--
2.7.4
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Krzysztof Kozlowski @ 2016-09-25 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87fuopvwjy.fsf@machinist.wiedmeyer.de>
On Sat, Sep 24, 2016 at 11:04:49PM +0200, Wolfgang Wiedmeyer wrote:
>
> Krzysztof Kozlowski writes:
>
> > On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
> >>
> >> Krzysztof Kozlowski writes:
> >>
> >> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
> >> >> This allows to reboot the device into recovery mode and into the download
> >> >> mode of the bootloader.
> >> >
> >> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
> >> > that information here?
> >>
> >> I'm only working with the stock one. I was under the impression that the
> >> stock bootloader cannot be replaced on a i9300 because there's a
> >> signature check. Is UBoot loaded after the stock one on Trats2 or how
> >> does this work? I didn't find information on that.
> >
> > +CC Marek,
> >
> > Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> > into Trats2 on my own. I always used targets prepared to be "Trats2"
> > type.
>
> It would be awesome to be able to run U-Boot on i9300. Is there a way to
> test this by not risking to brick the device, e.g. by booting from the
> SD card? Then I could send an updated version of the patch that is
> compatible with U-Boot :)
I don't think the stock bootloader supports chaining another bootloader
from SD card. There is a way of booting from SD card by shortening a
resistor but it is an emergency rescue procedure to overwrite existing
bootloader with data from SD card (to restore device). This thread might
be interesting:
http://forum.xda-developers.com/showpost.php?p=47234165&postcount=220
https://smyl.es/samsung-galaxy-iii-s3-gt-i9300-jtag-leaked-document-how-to-repair-soft-bricked-galaxy-s3/
On xda-developers you might find more data about this (including the
procedure for emergency restore from SD card). Somehow people flash and
unbrick their devices when playing with CyanogenMod...
Best regards,
Krzysztof
^ permalink raw reply
* Applied "ASoC: sun4i-codec: Rename some sun7i-only registers" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915143922.4890-3-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Rename some sun7i-only registers
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 4f0c4e99312d8887483474d60e47ab4e24713114 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Thu, 22 Sep 2016 09:13:12 +0200
Subject: [PATCH] ASoC: sun4i-codec: Rename some sun7i-only registers
Some of the registers defined in the driver are only usable on the
A20. Rename these registers.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 44f170c73b06..9d8c027f7c55 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -96,8 +96,8 @@
/* Other various ADC registers */
#define SUN4I_CODEC_DAC_TXCNT (0x30)
#define SUN4I_CODEC_ADC_RXCNT (0x34)
-#define SUN4I_CODEC_AC_SYS_VERI (0x38)
-#define SUN4I_CODEC_AC_MIC_PHONE_CAL (0x3c)
+#define SUN7I_CODEC_AC_DAC_CAL (0x38)
+#define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
struct sun4i_codec {
struct device *dev;
@@ -680,7 +680,7 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
- .max_register = SUN4I_CODEC_AC_MIC_PHONE_CAL,
+ .max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
static const struct of_device_id sun4i_codec_of_match[] = {
--
2.9.3
^ permalink raw reply related
* Applied "ASoC: sun4i-codec: Add custom regmap configs" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922071313.12891-4-dannym@scratchpost.org>
The patch
ASoC: sun4i-codec: Add custom regmap configs
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From c1d5065a0bd09bac783120b73bfa768ba6a493d9 Mon Sep 17 00:00:00 2001
From: Danny Milosavljevic <dannym@scratchpost.org>
Date: Thu, 22 Sep 2016 09:13:13 +0200
Subject: [PATCH] ASoC: sun4i-codec: Add custom regmap configs
The A20 has a few extra registers that the A10 doesn't have.
Therefore, use different regmaps for A10 as compared to A20.
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/sunxi/sun4i-codec.c | 38 +++++++++++++++++++++++++++++++++++---
1 file changed, 35 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
index 9d8c027f7c55..eb6808842208 100644
--- a/sound/soc/sunxi/sun4i-codec.c
+++ b/sound/soc/sunxi/sun4i-codec.c
@@ -680,12 +680,37 @@ static const struct regmap_config sun4i_codec_regmap_config = {
.reg_bits = 32,
.reg_stride = 4,
.val_bits = 32,
+ .max_register = SUN4I_CODEC_ADC_RXCNT,
+};
+
+static const struct regmap_config sun7i_codec_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
.max_register = SUN7I_CODEC_AC_MIC_PHONE_CAL,
};
+struct sun4i_codec_quirks {
+ const struct regmap_config *regmap_config;
+};
+
+static const struct sun4i_codec_quirks sun4i_codec_quirks = {
+ .regmap_config = &sun4i_codec_regmap_config,
+};
+
+static const struct sun4i_codec_quirks sun7i_codec_quirks = {
+ .regmap_config = &sun7i_codec_regmap_config,
+};
+
static const struct of_device_id sun4i_codec_of_match[] = {
- { .compatible = "allwinner,sun4i-a10-codec" },
- { .compatible = "allwinner,sun7i-a20-codec" },
+ {
+ .compatible = "allwinner,sun4i-a10-codec",
+ .data = &sun4i_codec_quirks,
+ },
+ {
+ .compatible = "allwinner,sun7i-a20-codec",
+ .data = &sun7i_codec_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_codec_of_match);
@@ -758,6 +783,7 @@ static int sun4i_codec_probe(struct platform_device *pdev)
{
struct snd_soc_card *card;
struct sun4i_codec *scodec;
+ const struct sun4i_codec_quirks *quirks;
struct resource *res;
void __iomem *base;
int ret;
@@ -775,8 +801,14 @@ static int sun4i_codec_probe(struct platform_device *pdev)
return PTR_ERR(base);
}
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (quirks == NULL) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
scodec->regmap = devm_regmap_init_mmio(&pdev->dev, base,
- &sun4i_codec_regmap_config);
+ quirks->regmap_config);
if (IS_ERR(scodec->regmap)) {
dev_err(&pdev->dev, "Failed to create our regmap\n");
return PTR_ERR(scodec->regmap);
--
2.9.3
^ permalink raw reply related
* Applied "ASoC: exynos: organize the asoc audio into a menu" to the asoc tree
From: Mark Brown @ 2016-09-25 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474311470-23175-1-git-send-email-ayaka@soulik.info>
The patch
ASoC: exynos: organize the asoc audio into a menu
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 090d93488135c8422d7711a8cefa4ed1cff7744a Mon Sep 17 00:00:00 2001
From: Randy Li <ayaka@soulik.info>
Date: Tue, 20 Sep 2016 02:57:50 +0800
Subject: [PATCH] ASoC: exynos: organize the asoc audio into a menu
It is simple sound card time, we could assign different codec
to a interface without making a specific driver for it. The SPDIF
and I2S interface for Samsung would be possible used by
simple-sound-card, but not sure about the PCM.
Those S3C time entries are left alone as I don't think any new board
would need them.
Signed-off-by: Randy Li <ayaka@soulik.info>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/samsung/Kconfig | 57 ++++++++++++++++++++++++-----------------------
1 file changed, 29 insertions(+), 28 deletions(-)
diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig
index 7b722b0094d9..f6023b46c107 100644
--- a/sound/soc/samsung/Kconfig
+++ b/sound/soc/samsung/Kconfig
@@ -1,12 +1,14 @@
-config SND_SOC_SAMSUNG
+menuconfig SND_SOC_SAMSUNG
tristate "ASoC support for Samsung"
depends on (PLAT_SAMSUNG || ARCH_EXYNOS)
select SND_SOC_GENERIC_DMAENGINE_PCM
- help
+ ---help---
Say Y or M if you want to add support for codecs attached to
the Samsung SoCs' Audio interfaces. You will also need to
select the audio interfaces to support below.
+if SND_SOC_SAMSUNG
+
config SND_S3C24XX_I2S
tristate
@@ -18,22 +20,22 @@ config SND_S3C2412_SOC_I2S
select SND_S3C_I2SV2_SOC
config SND_SAMSUNG_PCM
- tristate
+ tristate "Samsung PCM interface support"
config SND_SAMSUNG_AC97
tristate
select SND_SOC_AC97_BUS
config SND_SAMSUNG_SPDIF
- tristate
+ tristate "Samsung SPDIF transmitter support"
select SND_SOC_SPDIF
config SND_SAMSUNG_I2S
- tristate
+ tristate "Samsung I2S interface support"
config SND_SOC_SAMSUNG_NEO1973_WM8753
tristate "Audio support for Openmoko Neo1973 Smartphones (GTA02)"
- depends on SND_SOC_SAMSUNG && MACH_NEO1973_GTA02
+ depends on MACH_NEO1973_GTA02
select SND_S3C24XX_I2S
select SND_SOC_WM8753
select SND_SOC_BT_SCO
@@ -43,7 +45,7 @@ config SND_SOC_SAMSUNG_NEO1973_WM8753
config SND_SOC_SAMSUNG_JIVE_WM8750
tristate "SoC I2S Audio support for Jive"
- depends on SND_SOC_SAMSUNG && MACH_JIVE && I2C
+ depends on MACH_JIVE && I2C
select SND_SOC_WM8750
select SND_S3C2412_SOC_I2S
help
@@ -51,7 +53,7 @@ config SND_SOC_SAMSUNG_JIVE_WM8750
config SND_SOC_SAMSUNG_SMDK_WM8580
tristate "SoC I2S Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_I2S
@@ -60,7 +62,6 @@ config SND_SOC_SAMSUNG_SMDK_WM8580
config SND_SOC_SAMSUNG_SMDK_WM8994
tristate "SoC I2S Audio support for WM8994 on SMDK"
- depends on SND_SOC_SAMSUNG
depends on I2C=y
select MFD_WM8994
select SND_SOC_WM8994
@@ -70,7 +71,7 @@ config SND_SOC_SAMSUNG_SMDK_WM8994
config SND_SOC_SAMSUNG_SMDK2443_WM9710
tristate "SoC AC97 Audio support for SMDK2443 - WM9710"
- depends on SND_SOC_SAMSUNG && MACH_SMDK2443
+ depends on MACH_SMDK2443
select AC97_BUS
select SND_SOC_AC97_CODEC
select SND_SAMSUNG_AC97
@@ -80,7 +81,7 @@ config SND_SOC_SAMSUNG_SMDK2443_WM9710
config SND_SOC_SAMSUNG_LN2440SBC_ALC650
tristate "SoC AC97 Audio support for LN2440SBC - ALC650"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX
+ depends on ARCH_S3C24XX
select AC97_BUS
select SND_SOC_AC97_CODEC
select SND_SAMSUNG_AC97
@@ -90,7 +91,7 @@ config SND_SOC_SAMSUNG_LN2440SBC_ALC650
config SND_SOC_SAMSUNG_S3C24XX_UDA134X
tristate "SoC I2S Audio support UDA134X wired to a S3C24XX"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX
+ depends on ARCH_S3C24XX
select SND_S3C24XX_I2S
select SND_SOC_L3
select SND_SOC_UDA134X
@@ -102,21 +103,21 @@ config SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_SIMTEC_TLV320AIC23
tristate "SoC I2S Audio support for TLV320AIC23 on Simtec boards"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX && I2C
+ depends on ARCH_S3C24XX && I2C
select SND_S3C24XX_I2S
select SND_SOC_TLV320AIC23_I2C
select SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_SIMTEC_HERMES
tristate "SoC I2S Audio support for Simtec Hermes board"
- depends on SND_SOC_SAMSUNG && ARCH_S3C24XX && I2C
+ depends on ARCH_S3C24XX && I2C
select SND_S3C24XX_I2S
select SND_SOC_TLV320AIC3X
select SND_SOC_SAMSUNG_SIMTEC
config SND_SOC_SAMSUNG_H1940_UDA1380
tristate "Audio support for the HP iPAQ H1940"
- depends on SND_SOC_SAMSUNG && ARCH_H1940 && I2C
+ depends on ARCH_H1940 && I2C
select SND_S3C24XX_I2S
select SND_SOC_UDA1380
help
@@ -124,7 +125,7 @@ config SND_SOC_SAMSUNG_H1940_UDA1380
config SND_SOC_SAMSUNG_RX1950_UDA1380
tristate "Audio support for the HP iPAQ RX1950"
- depends on SND_SOC_SAMSUNG && MACH_RX1950 && I2C
+ depends on MACH_RX1950 && I2C
select SND_S3C24XX_I2S
select SND_SOC_UDA1380
help
@@ -132,7 +133,7 @@ config SND_SOC_SAMSUNG_RX1950_UDA1380
config SND_SOC_SAMSUNG_SMDK_WM9713
tristate "SoC AC97 Audio support for SMDK with WM9713"
- depends on SND_SOC_SAMSUNG && (MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDK6410 || MACH_SMDKC100 || MACH_SMDKV210 || MACH_SMDKC110
select SND_SOC_WM9713
select SND_SAMSUNG_AC97
help
@@ -140,20 +141,19 @@ config SND_SOC_SAMSUNG_SMDK_WM9713
config SND_SOC_SMARTQ
tristate "SoC I2S Audio support for SmartQ board"
- depends on SND_SOC_SAMSUNG && MACH_SMARTQ && I2C
+ depends on MACH_SMARTQ && I2C
select SND_SAMSUNG_I2S
select SND_SOC_WM8750
config SND_SOC_SAMSUNG_SMDK_SPDIF
tristate "SoC S/PDIF Audio support for SMDK"
- depends on SND_SOC_SAMSUNG
select SND_SAMSUNG_SPDIF
help
Say Y if you want to add support for SoC S/PDIF audio on the SMDK.
config SND_SOC_SMDK_WM8580_PCM
tristate "SoC PCM Audio support for WM8580 on SMDK"
- depends on SND_SOC_SAMSUNG && (MACH_SMDKV210 || MACH_SMDKC110)
+ depends on MACH_SMDKV210 || MACH_SMDKC110
depends on I2C
select SND_SOC_WM8580
select SND_SAMSUNG_PCM
@@ -162,7 +162,6 @@ config SND_SOC_SMDK_WM8580_PCM
config SND_SOC_SMDK_WM8994_PCM
tristate "SoC PCM Audio support for WM8994 on SMDK"
- depends on SND_SOC_SAMSUNG
depends on I2C=y
select MFD_WM8994
select SND_SOC_WM8994
@@ -172,7 +171,7 @@ config SND_SOC_SMDK_WM8994_PCM
config SND_SOC_SPEYSIDE
tristate "Audio support for Wolfson Speyside"
- depends on SND_SOC_SAMSUNG && I2C && SPI_MASTER
+ depends on I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM8996
@@ -182,14 +181,14 @@ config SND_SOC_SPEYSIDE
config SND_SOC_TOBERMORY
tristate "Audio support for Wolfson Tobermory"
- depends on SND_SOC_SAMSUNG && INPUT && I2C
+ depends on INPUT && I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM8962
config SND_SOC_BELLS
tristate "Audio support for Wolfson Bells"
- depends on SND_SOC_SAMSUNG && MFD_ARIZONA && I2C && SPI_MASTER
+ depends on MFD_ARIZONA && I2C && SPI_MASTER
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5102
@@ -200,7 +199,7 @@ config SND_SOC_BELLS
config SND_SOC_LOWLAND
tristate "Audio support for Wolfson Lowland"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select SND_SOC_WM5100
@@ -208,7 +207,7 @@ config SND_SOC_LOWLAND
config SND_SOC_LITTLEMILL
tristate "Audio support for Wolfson Littlemill"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
depends on MACH_WLF_CRAGG_6410 || COMPILE_TEST
select SND_SAMSUNG_I2S
select MFD_WM8994
@@ -216,7 +215,7 @@ config SND_SOC_LITTLEMILL
config SND_SOC_SNOW
tristate "Audio support for Google Snow boards"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
select SND_SOC_MAX98090
select SND_SOC_MAX98095
select SND_SAMSUNG_I2S
@@ -226,6 +225,8 @@ config SND_SOC_SNOW
config SND_SOC_ARNDALE_RT5631_ALC5631
tristate "Audio support for RT5631(ALC5631) on Arndale Board"
- depends on SND_SOC_SAMSUNG && I2C
+ depends on I2C
select SND_SAMSUNG_I2S
select SND_SOC_RT5631
+
+endif #SND_SOC_SAMSUNG
--
2.9.3
^ permalink raw reply related
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Florian Fainelli @ 2016-09-25 2:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160924235945.32128-1-iwamatsu@nigauri.org>
On 09/24/2016 04:59 PM, Nobuhiro Iwamatsu wrote:
> Add support for board based on the Altera Cyclone V SoC.
> This board has the following functions:
> - 1 GiB of DRAM
> - 1 Gigabit ethernet
> - 1 SD card slot
> - 1 USB gadget port
> - QSPI NOR Flash
> - I2C EEPROMs and I2C RTC
> - DVI output
> - Audio port
>
> This commit supports without QSPI, DVI and Audio.
>
> Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> ---
> V2: move the PHY of setting to the Ethetnet PHY node level.
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 123 +++++++++++++++++++++++++++
> 2 files changed, 124 insertions(+)
> create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index befcd26..7c5f0c3 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -696,6 +696,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += \
> socfpga_cyclone5_de0_sockit.dtb \
> socfpga_cyclone5_sockit.dtb \
> socfpga_cyclone5_socrates.dtb \
> + socfpga_cyclone5_sodia.dtb \
> socfpga_cyclone5_vining_fpga.dtb \
> socfpga_vt.dtb
> dtb-$(CONFIG_ARCH_SPEAR13XX) += \
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
> new file mode 100644
> index 0000000..9aaf413
> --- /dev/null
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
> @@ -0,0 +1,123 @@
> +/*
> + * Copyright (C) 2016 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include "socfpga_cyclone5.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> + model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
> + compatible = "altr,socfpga-cyclone5", "altr,socfpga";
> +
> + chosen {
> + bootargs = "earlyprintk";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory {
> + name = "memory";
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + aliases {
> + ethernet0 = &gmac1;
> + };
> +
> + regulator_3_3v: 3-3-v-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "3.3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + leds: gpio-leds {
> + compatible = "gpio-leds";
> +
> + hps_led0 {
> + label = "hps:green:led0";
> + gpios = <&portb 12 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led1 {
> + label = "hps:green:led1";
> + gpios = <&portb 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led2 {
> + label = "hps:green:led2";
> + gpios = <&portb 14 GPIO_ACTIVE_LOW>;
> + };
> +
> + hps_led3 {
> + label = "hps:green:led3";
> + gpios = <&portb 15 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&gmac1 {
> + status = "okay";
> + phy-mode = "rgmii";
> + phy = <&phy0>;
> +
> + mdio0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + phy0: ethernet-phy at 0 {
> + reg = <0>;
> + rxd0-skew-ps = <0>;
> + rxd1-skew-ps = <0>;
> + rxd2-skew-ps = <0>;
> + rxd3-skew-ps = <0>;
> + rxdv-skew-ps = <0>;
> + rxc-skew-ps = <3000>;
> + txen-skew-ps = <0>;
> + txc-skew-ps = <3000>;
> + };
This looks much better now, thanks!
--
Florian
^ permalink raw reply
* [PATCH] PCI: enable extended tags support for PCIe endpoints
From: Sinan Kaya @ 2016-09-25 2:10 UTC (permalink / raw)
To: linux-arm-kernel
Each PCIe device can issue up to 32 transactions at a time by default.
Each transaction is tracked by a tag number on the bus. 32 outstanding
transactions is not enough for some performance critical applications
especially when a lot of small sized frames are transmitted.
Extended tags support increases this number to 256. Devices not
supporting extended tags tie-off this field to 0. According to ECN, it
is safe to enable this feature for all PCIe endpoints.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/pci/probe.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 93f280d..2424f38 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1505,12 +1505,19 @@ static void program_hpp_type2(struct pci_dev *dev, struct hpp_type2 *hpp)
*/
}
+static int pci_configure_extended_tags(struct pci_dev *dev)
+{
+ return pcie_capability_set_word(dev, PCI_EXP_DEVCTL,
+ PCI_EXP_DEVCTL_EXT_TAG);
+}
+
static void pci_configure_device(struct pci_dev *dev)
{
struct hotplug_params hpp;
int ret;
pci_configure_mps(dev);
+ pci_configure_extended_tags(dev);
memset(&hpp, 0, sizeof(hpp));
ret = pci_get_hp_params(dev, &hpp);
--
1.9.1
^ permalink raw reply related
* [PATCH v2.1] arm64: kgdb: handle read-only text / modules
From: AKASHI Takahiro @ 2016-09-25 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923102340.GA2161@e104818-lin.cambridge.arm.com>
Hi Catalin,
On Fri, Sep 23, 2016 at 11:23:40AM +0100, Catalin Marinas wrote:
> On Fri, Sep 23, 2016 at 10:49:53AM +0100, Catalin Marinas wrote:
> > On Fri, Sep 23, 2016 at 04:42:08PM +0900, AKASHI Takahiro wrote:
> > > Handle read-only cases (CONFIG_DEBUG_RODATA/CONFIG_DEBUG_SET_MODULE_RONX)
> > > by using aarch64_insn_write() instead of probe_kernel_write().
> > > See how this works:
> > > commit 2f896d586610 ("arm64: use fixmap for text patching")
> > >
> > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > > Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will.deacon@arm.com>
> > > Cc: Jason Wessel <jason.wessel@windriver.com>
> > > Cc: <stable@vger.kernel.org> # 3.18-3.19: 2f896d5: arm64: use fixmap
> > > Cc: <stable@vger.kernel.org> # 3.18-3.19: f6242ca: arm64: Fix text
> > > Cc: <stable@vger.kernel.org> # 4.0-
> >
> > Queued for 4.8 with a slight change in the last Cc: tag above:
> >
> > Cc: <stable@vger.kernel.org> # 3.18.x-
>
> I tried to apply this patch to 3.18, 4.1, 4.4, 4.7. It fails on all of
> them with smaller or slightly larger conflicts.
Oh, too bad.
I guest we'd better revert the following patches as well:
c696b93 arm64/debug: Simplify BRK insn opcode declarations
c172d99 arm64/debug: More consistent naming for the BRK ESR template macro
but I will check anyway.
> So, I'll merge it in 4.8 without any "Cc: stable" tags, just a "Fixes:"
> one for the commit introducing CONFIG_DEBUG_SET_MODULE_RONX (3.18). Once
> the patch reaches mainline, could you please back-port and test it on
> the stable kernel versions and send separate patches to
> stable at vger.kernel.org?
Thanks,
-Takahiro AKASHI
> Thanks.
>
> --
> Catalin
^ permalink raw reply
* [PATCH v2] ARM: dts: socfpga: Add Macnica sodia board
From: Nobuhiro Iwamatsu @ 2016-09-24 23:59 UTC (permalink / raw)
To: linux-arm-kernel
Add support for board based on the Altera Cyclone V SoC.
This board has the following functions:
- 1 GiB of DRAM
- 1 Gigabit ethernet
- 1 SD card slot
- 1 USB gadget port
- QSPI NOR Flash
- I2C EEPROMs and I2C RTC
- DVI output
- Audio port
This commit supports without QSPI, DVI and Audio.
Signed-off-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
---
V2: move the PHY of setting to the Ethetnet PHY node level.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/socfpga_cyclone5_sodia.dts | 123 +++++++++++++++++++++++++++
2 files changed, 124 insertions(+)
create mode 100644 arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..7c5f0c3 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -696,6 +696,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) += \
socfpga_cyclone5_de0_sockit.dtb \
socfpga_cyclone5_sockit.dtb \
socfpga_cyclone5_socrates.dtb \
+ socfpga_cyclone5_sodia.dtb \
socfpga_cyclone5_vining_fpga.dtb \
socfpga_vt.dtb
dtb-$(CONFIG_ARCH_SPEAR13XX) += \
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
new file mode 100644
index 0000000..9aaf413
--- /dev/null
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sodia.dts
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2016 Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include "socfpga_cyclone5.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+/ {
+ model = "Altera SOCFPGA Cyclone V SoC Macnica Sodia board";
+ compatible = "altr,socfpga-cyclone5", "altr,socfpga";
+
+ chosen {
+ bootargs = "earlyprintk";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ name = "memory";
+ device_type = "memory";
+ reg = <0x0 0x40000000>;
+ };
+
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ regulator_3_3v: 3-3-v-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ leds: gpio-leds {
+ compatible = "gpio-leds";
+
+ hps_led0 {
+ label = "hps:green:led0";
+ gpios = <&portb 12 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led1 {
+ label = "hps:green:led1";
+ gpios = <&portb 13 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led2 {
+ label = "hps:green:led2";
+ gpios = <&portb 14 GPIO_ACTIVE_LOW>;
+ };
+
+ hps_led3 {
+ label = "hps:green:led3";
+ gpios = <&portb 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&gmac1 {
+ status = "okay";
+ phy-mode = "rgmii";
+ phy = <&phy0>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 0 {
+ reg = <0>;
+ rxd0-skew-ps = <0>;
+ rxd1-skew-ps = <0>;
+ rxd2-skew-ps = <0>;
+ rxd3-skew-ps = <0>;
+ rxdv-skew-ps = <0>;
+ rxc-skew-ps = <3000>;
+ txen-skew-ps = <0>;
+ txc-skew-ps = <3000>;
+ };
+ };
+};
+
+&gpio1 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom at 51 {
+ compatible = "atmel,24c32";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+
+ rtc at 68 {
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ };
+};
+
+&mmc0 {
+ cd-gpios = <&portb 18 0>;
+ vmmc-supply = <®ulator_3_3v>;
+ vqmmc-supply = <®ulator_3_3v>;
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH] ARM: dts: exynos: Add reboot reason support for Trats2
From: Wolfgang Wiedmeyer @ 2016-09-24 21:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922205522.GA15917@kozik-lap>
Krzysztof Kozlowski writes:
> On Thu, Sep 22, 2016 at 08:59:03PM +0200, Wolfgang Wiedmeyer wrote:
>>
>> Krzysztof Kozlowski writes:
>>
>> > On Thu, Sep 22, 2016 at 06:48:35PM +0200, Wolfgang Wiedmeyer wrote:
>> >> This allows to reboot the device into recovery mode and into the download
>> >> mode of the bootloader.
>> >
>> > Which bootloader? Probably UBoot... or Samsung stock one? Could you put
>> > that information here?
>>
>> I'm only working with the stock one. I was under the impression that the
>> stock bootloader cannot be replaced on a i9300 because there's a
>> signature check. Is UBoot loaded after the stock one on Trats2 or how
>> does this work? I didn't find information on that.
>
> +CC Marek,
>
> Trats2 is working with U-Boot. Just U-Boot. However I never converted S3
> into Trats2 on my own. I always used targets prepared to be "Trats2"
> type.
It would be awesome to be able to run U-Boot on i9300. Is there a way to
test this by not risking to brick the device, e.g. by booting from the
SD card? Then I could send an updated version of the patch that is
compatible with U-Boot :)
> Of course kernel is independent to bootloader but in that case you want
> to use a specific interface between kernel and specific bootloader
> type/version. In that case - this should be U-Boot, I think.
I absolutely understand that. Having the patch in mainline doesn't make
much sense if it's not compatible with U-Boot.
Best regards,
Wolfgang
>> >> Signed-off-by: Wolfgang Wiedmeyer <wolfgit@wiedmeyer.de>
>> >> ---
>> >> arch/arm/boot/dts/exynos4412-trats2.dts | 14 ++++++++++++++
>> >> arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
>> >> 2 files changed, 15 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> index 129e973..a38d1e3 100644
>> >> --- a/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> +++ b/arch/arm/boot/dts/exynos4412-trats2.dts
>> >> @@ -1294,3 +1294,17 @@
>> >> vtmu-supply = <&ldo10_reg>;
>> >> status = "okay";
>> >> };
>> >> +
>> >> +&pmu {
>> >> + compatible = "syscon", "simple-mfd";
>> >> +
>> >> + reboot-mode {
>> >> + compatible = "syscon-reboot-mode";
>> >> + offset = <0x80c>;
>> >> +
>> >> + mode-normal = <0x12345670>;
>> >> + mode-bootloader = <0x12345671>;
>> >> + mode-download = <0x12345671>;
>> >> + mode-recovery = <0x12345674>;
>> >
>> > Hmmm, how did you get these values? Are they already supported?
>>
>> I only have the vendor source drop as documentation. The magic mode
>> values [1] and the offset [2] can be found there.
>
> It would be useful to mention that in commit msg (just the source)...
> however as I wrote above, these values should be for U-Boot, not the
> stock one.
>
> Best regards,
> Krzysztof
>
>>
>> > It would be nice to document them:
>> > 1. In Documentation/arm/Samsung/Bootloader-interface.txt
>> > 2. In header. I hate such magic numbers... you could add new header next
>> > to existing rockchip one:
>> > include/dt-bindings/soc/samsung,boot-mode.h
>> > (and update maintainers entry :) )
>>
>> Thanks for the review! I will do the documentation and update the commit
>> message.
>>
>> Best regards,
>> Wolfgang
>>
>> [1] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/sec-reboot.c#n65
>>
>> [2] https://code.fossencdi.org/kernel_samsung_smdk4412.git/tree/arch/arm/mach-exynos/include/mach/regs-pmu.h#n79
>>
>>
>> --
>> Website: https://fossencdi.org
>> Jabber: wolfgang at wiedmeyer.de
>> OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
>> Key download: https://wiedmeyer.de/keys/ww.asc
--
Website: https://fossencdi.org
Jabber: wolfgang at wiedmeyer.de
OpenPGP: 0F30 D1A0 2F73 F70A 6FEE 048E 5816 A24C 1075 7FC4
Key download: https://wiedmeyer.de/keys/ww.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/58a07749/attachment.sig>
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-09-24 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <05a573de-e963-6590-6ed3-55af97067d7a@gmail.com>
On Saturday, September 24, 2016 4:14:15 PM CEST zhichang wrote:
>
> In V3, the outb is :
>
> void outb(u8 value, unsigned long addr)
> {
> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
> arm64_extio_ops->end < addr)
> writeb(value, PCI_IOBASE + addr);
> else
> if (arm64_extio_ops->pfout)
> arm64_extio_ops->pfout(arm64_extio_ops->devpara,
> addr + arm64_extio_ops->ptoffset, &value,
> sizeof(u8), 1);
> }
>
> here, arm64_extio_ops->ptoffset is the offset between the real legacy IO address
> and the logical IO address, similar to the offset of primary address and
> secondary address in PCI bridge.
Ok, though we can probably simplify this by making the assumption that
'ptoffset' is the negative of 'start', as the bus we register should
always start at port zero.
> But in V3, LPC driver call pci_address_to_pio to request the logical IO as PCI
> host bridge during its probing.
Right, so this still needs to be fixed.
Arnd
^ permalink raw reply
* [PATCH 1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Maxime Ripard @ 2016-09-24 20:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473411668.731.75.camel@schinagl.nl>
Hi Oliver,
Sorry for the slow answer.
On Fri, Sep 09, 2016 at 11:01:08AM +0200, Olliver Schinagl wrote:
> > > > > *chip, struct pwm_device *pwm)
> > > > > ? spin_lock(&sun4i_pwm->ctrl_lock);
> > > > > ? val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> > > > > ? val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> > > > > + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> > > > > + spin_unlock(&sun4i_pwm->ctrl_lock);
> > > > > +
> > > > > + /* Allow for the PWM hardware to finish its last
> > > > > toggle.
> > > > > The pulse
> > > > > + ?* may have just started and thus we should wait a
> > > > > full
> > > > > period.
> > > > > + ?*/
> > > > > + ndelay(pwm_get_period(pwm));
> > > >
> > > > Can't that use the ready bit as well?
> > > It depends whatever is cheaper. If we disable the pwm, we have to
> > > commit that request to hardware first. Then we have to read back
> > > the
> > > has ready and in the strange situation it is not, wait for it to
> > > become
> > > ready?
> >
> > If it works like you were suggesting, yes.
> >
> > >
> > > Also, that would mean we would loop in a spin lock, or keep
> > > setting/clearing an additional spinlock to read the ready bit.
> >
> > You're using a spin_lock, so it's not that bad, but I was just
> > suggesting replacing the ndelay.
>
> If you say the spin_lock + wait for the ready is just as expensive as
> the ndelay, or the ndelay is less preferred, then I gladly make the
> change;
For the spin_lock part, I was just comparing it to a
spin_lock_irqsave, which is pretty expensive since it masks all the
interrupts in the system, introducing latencies.
> but I think we need the ndelay for the else where we do not
> have the ready flag (A10 or A13 iirc?)
Hmmmm, good point. But that would also apply to your second patch
then, wouldn't it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/cb63cb8f/attachment.sig>
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-24 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB1PgaACukEj1jzUY-dQzbf50Em3h47KEsQu3rC3Jej=6Q@mail.gmail.com>
On Fri, Sep 23, 2016 at 11:43:55PM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On 23 September 2016 at 23:16, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
> >> Hi Maxime,
> >>
> >> On Thursday, 22 September 2016, Maxime Ripard <maxime.ripard@free-electrons.
> >> com> wrote:
> >>
> >> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> >> > > The panel should be enabled after the controller so that the panel
> >> > > prepare/enable delays are properly taken into account. Similarly, the
> >> > > panel should be disabled before the controller so that the panel
> >> > > unprepare/disable delays are properly taken into account.
> >> > >
> >> > > This is useful for avoiding visual glitches.
> >> >
> >> > This is not really taking any delays into account, especially since
> >> > drm_panel_enable and prepare are suppose to block until their
> >> > operation is complete.
> >>
> >>
> >> drm_panel_prepare turns on power to the LCD using enable-gpios property of
> >> the panel and then blocks for prepare delay. The prepare delay for panel
> >> can be set to how long it takes between the time the panel is powered to
> >> when it is ready to receive images. If backlight property is specified the
> >> backlight will be off while the panel is powered on.
> >>
> >> drm_panel_enable blocks for enable delay and then turns on the backlight.
> >> The enable delay can be set to how long it takes for panel to start making
> >> the image visible after receiving the first valid frame. For example if the
> >> panel starts off as white and the TFT takes some time to initialize to
> >> black before it shows the image being received.
> >>
> >> Refer to drivers/gpu/drm/panel-panel.simple.c for details.
> >
> > From drm_panel.h:
> >
> > """
> > * drm_panel_enable - enable a panel
> > * @panel: DRM panel
> > *
> > * Calling this function will cause the panel display drivers to be turned on
> > * and the backlight to be enabled. Content will be visible on screen after
> > * this call completes.
> > """
> >
> > """
> > * drm_panel_prepare - power on a panel
> > * @panel: DRM panel
> > *
> > * Calling this function will enable power and deassert any reset signals to
> > * the panel. After this has completed it is possible to communicate with any
> > * integrated circuitry via a command bus.
> > """
> >
> > Those comments clearly says that the caller should not have to deal
> > with the delays, even more so by just moving calls around and hoping
> > that the code running in between is adding enough delay for the panel
> > to behave properly.
> >
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_panel.h#n34
>
> In comment for struct drm_panel_funcs:
> /**
> * struct drm_panel_funcs - perform operations on a given panel
> * @disable: disable panel (turn off back light, etc.)
> * @unprepare: turn off panel
> * @prepare: turn on panel and perform set up
> * @enable: enable panel (turn on back light, etc.)
> * @get_modes: add modes to the connector that the panel is attached to and
> * return the number of modes added
> * @get_timings: copy display timings into the provided array and return
> * the number of display timings available
> *
> * The .prepare() function is typically called before the display controller
> * starts to transmit video data. Panel drivers can use this to turn the panel
> * on and wait for it to become ready. If additional configuration is required
> * (via a control bus such as I2C, SPI or DSI for example) this is a good time
> * to do that.
> *
> * After the display controller has started transmitting video data, it's safe
> * to call the .enable() function. This will typically enable the backlight to
> * make the image on screen visible. Some panels require a certain amount of
> * time or frames before the image is displayed. This function is responsible
> * for taking this into account before enabling the backlight to avoid visual
> * glitches.
> *
> * Before stopping video transmission from the display controller it can be
> * necessary to turn off the panel to avoid visual glitches. This is done in
> * the .disable() function. Analogously to .enable() this typically involves
> * turning off the backlight and waiting for some time to make sure no image
> * is visible on the panel. It is then safe for the display controller to
> * cease transmission of video data.
> *
> * To save power when no video data is transmitted, a driver can power down
> * the panel. This is the job of the .unprepare() function.
> */
It kind of make my point. When drm_panel_enable is called, the content
is visible, and there's no extra delay needed.
If what you want to fix is that the panel is enabled before the
controller, hence resulting in garbage on the screen while the
controller is setup, then your commit log is seriously misleading.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160924/15933e61/attachment.sig>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox