* [PATCH 2/2] i2c: sirf: add support for new SiRFmarco SMP SoC
From: Wolfram Sang @ 2013-01-24 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356489017-17737-2-git-send-email-Barry.Song@csr.com>
On Wed, Dec 26, 2012 at 10:30:17AM +0800, Barry Song wrote:
> From: Barry Song <Baohua.Song@csr.com>
>
> the driver is also compatible with SiRFmarco except SiRFprimaII,
> so simply add "sirf,marco-i2c" to OF match table.
>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
Why can't you use the existing compatible entry as a fallback like in:
compatible = "sirf,marco-i2c", "sirf,prima2-i2c";
?
> ---
> drivers/i2c/busses/i2c-sirf.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
> index 181d7c2..ed38b16 100644
> --- a/drivers/i2c/busses/i2c-sirf.c
> +++ b/drivers/i2c/busses/i2c-sirf.c
> @@ -439,6 +439,7 @@ static const struct dev_pm_ops i2c_sirfsoc_pm_ops = {
>
> static const struct of_device_id sirfsoc_i2c_of_match[] __devinitconst = {
> { .compatible = "sirf,prima2-i2c", },
> + { .compatible = "sirf,marco-i2c", },
> {},
> };
> MODULE_DEVICE_TABLE(of, sirfsoc_i2c_of_match);
> --
^ permalink raw reply
* [PATCH 2/2] i2c: sirf: add support for new SiRFmarco SMP SoC
From: Barry Song @ 2013-01-24 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124072736.GJ8364@nekote.pengutronix.de>
2013/1/24 Wolfram Sang <w.sang@pengutronix.de>:
> On Wed, Dec 26, 2012 at 10:30:17AM +0800, Barry Song wrote:
>> From: Barry Song <Baohua.Song@csr.com>
>>
>> the driver is also compatible with SiRFmarco except SiRFprimaII,
>> so simply add "sirf,marco-i2c" to OF match table.
>>
>> Signed-off-by: Barry Song <Baohua.Song@csr.com>
>
> Why can't you use the existing compatible entry as a fallback like in:
>
> compatible = "sirf,marco-i2c", "sirf,prima2-i2c";
> ?
ok. let's hold on this one.
i was hoping registers layout/work mode would have some changes in the
final marco design as marco chip was still a fpga.
i have been sure spi will have a new high speed mode, for i2c, no
message for the moment.
>
>> ---
>> drivers/i2c/busses/i2c-sirf.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-sirf.c b/drivers/i2c/busses/i2c-sirf.c
>> index 181d7c2..ed38b16 100644
>> --- a/drivers/i2c/busses/i2c-sirf.c
>> +++ b/drivers/i2c/busses/i2c-sirf.c
>> @@ -439,6 +439,7 @@ static const struct dev_pm_ops i2c_sirfsoc_pm_ops = {
>>
>> static const struct of_device_id sirfsoc_i2c_of_match[] __devinitconst = {
>> { .compatible = "sirf,prima2-i2c", },
>> + { .compatible = "sirf,marco-i2c", },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, sirfsoc_i2c_of_match);
>> --
-barry
^ permalink raw reply
* [PATCH] i2c: at91: add of_device_id entry for at91rm9200
From: ludovic.desroches @ 2013-01-24 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124072714.GH8364@nekote.pengutronix.de>
Hi,
On 01/24/2013 08:27 AM, Wolfram Sang wrote:
> On Tue, Dec 18, 2012 at 07:02:32AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 22:42 Wed 05 Dec , Joachim Eastwood wrote:
>>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>>> ---
>>> Hi,
>>>
>>> AT91RM9200 is gaining DT support now so let's add an id to the i2c driver.
>>>
>>> Tested on custom RM9200 board. Since the driver doesn't support pinctrl
>>> muxing yet I had to add pinctrl hogs for the i2c pins in my dts for it
>>> to work.
>>
>> IIRC the i2c IP have quite a lots of issue on rm9200 and until sam9g45
>>
>> it not recommended to use it instead use i2c-gpio
>
> Ludovic, you know the driver best. Does it make sense to add this?
I didn't add this when I did the rework because there was no DT tree
support for RM9200. The configuration for RM9200 IP is already in the
driver and used for non DT platform so I think it makes sense to add this.
But as Jean-Christophe said, it's recommended to use the i2c-gpio driver
since we know the first versions of the IP have several issues. However
if it fits user usage, it is not forbidden to use it.
Regards
Ludovic
>
>>
>> Best Regards,
>> J.
>>>
>>> regards
>>> Joachim Eastwood
>>>
>>> drivers/i2c/busses/i2c-at91.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
>>> index b4575ee..c504aa8 100644
>>> --- a/drivers/i2c/busses/i2c-at91.c
>>> +++ b/drivers/i2c/busses/i2c-at91.c
>>> @@ -584,6 +584,9 @@ static const struct platform_device_id at91_twi_devtypes[] = {
>>> #if defined(CONFIG_OF)
>>> static const struct of_device_id atmel_twi_dt_ids[] = {
>>> {
>>> + .compatible = "atmel,at91rm9200-i2c",
>>> + .data = &at91rm9200_config,
>>> + } , {
>>> .compatible = "atmel,at91sam9260-i2c",
>>> .data = &at91sam9260_config,
>>> } , {
>>> --
>>> 1.8.0
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH v2 1/1 net-next] net: fec: add napi support to improve proformance
From: Frank Li @ 2013-01-24 7:58 UTC (permalink / raw)
To: linux-arm-kernel
Add napi support
Before this patch
iperf -s -i 1
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 10.192.242.153 port 5001 connected with 10.192.242.138 port 50004
[ ID] Interval Transfer Bandwidth
[ 4] 0.0- 1.0 sec 41.2 MBytes 345 Mbits/sec
[ 4] 1.0- 2.0 sec 43.7 MBytes 367 Mbits/sec
[ 4] 2.0- 3.0 sec 42.8 MBytes 359 Mbits/sec
[ 4] 3.0- 4.0 sec 43.7 MBytes 367 Mbits/sec
[ 4] 4.0- 5.0 sec 42.7 MBytes 359 Mbits/sec
[ 4] 5.0- 6.0 sec 43.8 MBytes 367 Mbits/sec
[ 4] 6.0- 7.0 sec 43.0 MBytes 361 Mbits/sec
After this patch
[ 4] 2.0- 3.0 sec 51.6 MBytes 433 Mbits/sec
[ 4] 3.0- 4.0 sec 51.8 MBytes 435 Mbits/sec
[ 4] 4.0- 5.0 sec 52.2 MBytes 438 Mbits/sec
[ 4] 5.0- 6.0 sec 52.1 MBytes 437 Mbits/sec
[ 4] 6.0- 7.0 sec 52.1 MBytes 437 Mbits/sec
[ 4] 7.0- 8.0 sec 52.3 MBytes 439 Mbits/sec
Signed-off-by: Frank Li <Frank.Li@freescale.com>
Signed-off-by: Fugang Duan <B38611@freescale.com>
---
Change from v1 to v2
* Remove use_napi and napi_weight config. Support NAPI only.
* using napi_gro_receive replace netif_rx
drivers/net/ethernet/freescale/fec.c | 56 +++++++++++++++++++++++++++++-----
drivers/net/ethernet/freescale/fec.h | 2 +
2 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index f52ba33..39be2ab 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -67,6 +67,7 @@
#endif
#define DRIVER_NAME "fec"
+#define FEC_NAPI_WEIGHT 64
/* Pause frame feild and FIFO threshold */
#define FEC_ENET_FCE (1 << 5)
@@ -565,6 +566,20 @@ fec_timeout(struct net_device *ndev)
}
static void
+fec_enet_rx_int_is_enabled(struct net_device *ndev, bool enabled)
+{
+ struct fec_enet_private *fep = netdev_priv(ndev);
+ uint int_events;
+
+ int_events = readl(fep->hwp + FEC_IMASK);
+ if (enabled)
+ int_events |= FEC_ENET_RXF;
+ else
+ int_events &= ~FEC_ENET_RXF;
+ writel(int_events, fep->hwp + FEC_IMASK);
+}
+
+static void
fec_enet_tx(struct net_device *ndev)
{
struct fec_enet_private *fep;
@@ -656,8 +671,8 @@ fec_enet_tx(struct net_device *ndev)
* not been given to the system, we just set the empty indicator,
* effectively tossing the packet.
*/
-static void
-fec_enet_rx(struct net_device *ndev)
+static int
+fec_enet_rx(struct net_device *ndev, int budget)
{
struct fec_enet_private *fep = netdev_priv(ndev);
const struct platform_device_id *id_entry =
@@ -667,13 +682,12 @@ fec_enet_rx(struct net_device *ndev)
struct sk_buff *skb;
ushort pkt_len;
__u8 *data;
+ int pkt_received = 0;
#ifdef CONFIG_M532x
flush_cache_all();
#endif
- spin_lock(&fep->hw_lock);
-
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
*/
@@ -681,6 +695,10 @@ fec_enet_rx(struct net_device *ndev)
while (!((status = bdp->cbd_sc) & BD_ENET_RX_EMPTY)) {
+ if (pkt_received >= budget)
+ break;
+ pkt_received++;
+
/* Since we have allocated space to hold a complete frame,
* the last indicator should be set.
*/
@@ -762,7 +780,7 @@ fec_enet_rx(struct net_device *ndev)
}
if (!skb_defer_rx_timestamp(skb))
- netif_rx(skb);
+ napi_gro_receive(&fep->napi, skb);
}
bdp->cbd_bufaddr = dma_map_single(&fep->pdev->dev, data,
@@ -796,7 +814,7 @@ rx_processing_done:
}
fep->cur_rx = bdp;
- spin_unlock(&fep->hw_lock);
+ return pkt_received;
}
static irqreturn_t
@@ -805,6 +823,7 @@ fec_enet_interrupt(int irq, void *dev_id)
struct net_device *ndev = dev_id;
struct fec_enet_private *fep = netdev_priv(ndev);
uint int_events;
+ ulong flags;
irqreturn_t ret = IRQ_NONE;
do {
@@ -813,7 +832,14 @@ fec_enet_interrupt(int irq, void *dev_id)
if (int_events & FEC_ENET_RXF) {
ret = IRQ_HANDLED;
- fec_enet_rx(ndev);
+
+ spin_lock_irqsave(&fep->hw_lock, flags);
+ /* Disable the RX interrupt */
+ if (napi_schedule_prep(&fep->napi)) {
+ fec_enet_rx_int_is_enabled(ndev, false);
+ __napi_schedule(&fep->napi);
+ }
+ spin_unlock_irqrestore(&fep->hw_lock, flags);
}
/* Transmit OK, or non-fatal error. Update the buffer
@@ -834,7 +860,16 @@ fec_enet_interrupt(int irq, void *dev_id)
return ret;
}
-
+static int fec_enet_rx_napi(struct napi_struct *napi, int budget)
+{
+ struct net_device *ndev = napi->dev;
+ int pkgs = fec_enet_rx(ndev, budget);
+ if (pkgs < budget) {
+ napi_complete(napi);
+ fec_enet_rx_int_is_enabled(ndev, true);
+ }
+ return pkgs;
+}
/* ------------------------------------------------------------------------- */
static void fec_get_mac(struct net_device *ndev)
@@ -1392,6 +1427,8 @@ fec_enet_open(struct net_device *ndev)
struct fec_enet_private *fep = netdev_priv(ndev);
int ret;
+ napi_enable(&fep->napi);
+
/* I should reset the ring buffers here, but I don't yet know
* a simple way to do that.
*/
@@ -1604,6 +1641,9 @@ static int fec_enet_init(struct net_device *ndev)
ndev->netdev_ops = &fec_netdev_ops;
ndev->ethtool_ops = &fec_enet_ethtool_ops;
+ fec_enet_rx_int_is_enabled(ndev, false);
+ netif_napi_add(ndev, &fep->napi, fec_enet_rx_napi, FEC_NAPI_WEIGHT);
+
/* Initialize the receive buffer descriptors. */
bdp = fep->rx_bd_base;
for (i = 0; i < RX_RING_SIZE; i++) {
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 2ebedaf..01579b8 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -249,6 +249,8 @@ struct fec_enet_private {
int bufdesc_ex;
int pause_flag;
+ struct napi_struct napi;
+
struct ptp_clock *ptp_clock;
struct ptp_clock_info ptp_caps;
unsigned long last_overflow_check;
--
1.7.1
^ permalink raw reply related
* [PATCH v2 0/3] Add device tree support for NAND flash in am335x-evm
From: Philip Avinash @ 2013-01-24 8:02 UTC (permalink / raw)
To: linux-arm-kernel
This patch series adds device tree support for NAND flash in am335x-evm.
Also ELM node is populated in device tree and been used for BCH error
correction in NAND flash part. Also this patch series ensures RBL ecc
layout maintained in Linux kernel with BCH8 ecc scheme.
This patch series based on [1] and depends on [2].
1. http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=tree;h=refs/heads/for_3.9/dts;hb=refs/heads/for_3.9/dts
2.mtd: devices: elm: Removes <xx> literals in elm DT node
https://lkml.org/lkml/2013/1/24/30
Philip Avinash (1):
ARM: dts: AM33XX: Add NAND flash device tree data to am335x-evm
Philip, Avinash (2):
ARM: dts: AM33XX: Add ELM node
ARM: dts: AM33XX: Add GPMC node
arch/arm/boot/dts/am335x-evm.dts | 98 +++++++++++++++++++++++++++++++++++++-
arch/arm/boot/dts/am33xx.dtsi | 20 ++++++++
2 files changed, 117 insertions(+), 1 deletion(-)
--
1.7.9.5
^ permalink raw reply
* OHCI on Samsung S3C6410 SoC, how to get it work?
From: Juergen Beisert @ 2013-01-24 8:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi list,
I'm trying to get the OHCI unit work on my S3C6410 SoC based Mini6410 but
without luck yet.
The driver in my Linux-3.7.4 always reports:
[...]
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd: block sizes: ed 64 td 64
s3c2410-ohci s3c2410-ohci: s3c2410_start_hc:
s3c2410-ohci s3c2410-ohci: S3C24XX OHCI
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1
s3c2410-ohci s3c2410-ohci: irq 79, io mem 0x74300000
s3c2410-ohci s3c2410-ohci: created debug files
s3c2410-ohci s3c2410-ohci: fminterval delta -11999
s3c2410-ohci s3c2410-ohci: enabling initreset quirk
s3c2410-ohci s3c2410-ohci: init err (00000000 0000)
s3c2410-ohci s3c2410-ohci: can't start s3c24xx
s3c2410-ohci s3c2410-ohci: OHCI controller state
s3c2410-ohci s3c2410-ohci: OHCI 0.0, NO legacy support registers, rh state halted
s3c2410-ohci s3c2410-ohci: control 0x000 HCFS=reset CBSR=0
s3c2410-ohci s3c2410-ohci: cmdstatus 0x00000 SOC=0
s3c2410-ohci s3c2410-ohci: intrstatus 0x00000000
s3c2410-ohci s3c2410-ohci: intrenable 0x00000000
s3c2410-ohci s3c2410-ohci: hcca frame #0000
s3c2410-ohci s3c2410-ohci: roothub.a 00000000 POTPGT=0 NDP=0(0)
s3c2410-ohci s3c2410-ohci: roothub.b 00000000 PPCM=0000 DR=0000
s3c2410-ohci s3c2410-ohci: roothub.status 00000000
s3c2410-ohci s3c2410-ohci: startup error -75
s3c2410-ohci s3c2410-ohci: USB bus 1 deregistered
s3c2410-ohci s3c2410-ohci: s3c2410_stop_hc:
s3c2410-ohci: probe of s3c2410-ohci failed with error -75
[...]
>From the error messages I guess the unit does not receive a clock. But as far
I can follow the code, the driver enables the correct clocks. From the data
sheet I know the OHCI unit shares the clock with the OTG unit. Has someone a
working OHCI on an S3C6410 SoC based system and can give me some hints how to
get it work on my Mini6410?
Regards,
Juergen
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH 0/2] ARM: davinci: da850: add wdt DT node
From: Kumar, Anil @ 2013-01-24 8:38 UTC (permalink / raw)
To: linux-arm-kernel
Add wdt DT node and OF_DEV_AUXDATA for wdt driver in
da850 board dt file to use wdt clock.
This series applies on top of v3.8-rc4.
This is tested on da850 EVM.
Test Procedure:
$watchdog -F /dev/watchdog (Device should not reboot)
After wdt heartbeat timeout(DEFAULT_HEARTBEAT is 60 sec)
$ctr + c (Device should reboot after heartbeat timeout)
Kumar, Anil (2):
ARM: davinci: da850: add wdt DT node
ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 5 +++++
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
3 files changed, 15 insertions(+), 1 deletions(-)
--
1.7.4.1
^ permalink raw reply
* [PATCH 1/2] ARM: davinci: da850: add wdt DT node
From: Kumar, Anil @ 2013-01-24 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359016695-10362-1-git-send-email-anilkumar.v@ti.com>
Add da850 wdt DT node.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
---
:100644 100644 37dc5a3... 4666ce9... M arch/arm/boot/dts/da850-evm.dts
:100644 100644 640ab75... 08bf974... M arch/arm/boot/dts/da850.dtsi
arch/arm/boot/dts/da850-evm.dts | 3 +++
arch/arm/boot/dts/da850.dtsi | 5 +++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 37dc5a3..4666ce9 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -24,5 +24,8 @@
serial2: serial at 1d0d000 {
status = "okay";
};
+ wdt: wdt at 1c21000 {
+ status = "okay";
+ };
};
};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 640ab75..08bf974 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -56,5 +56,10 @@
interrupt-parent = <&intc>;
status = "disabled";
};
+ wdt: wdt at 1c21000 {
+ compatible = "ti,davinci-wdt";
+ reg = <0x21000 0xfff>;
+ status = "disabled";
+ };
};
};
--
1.7.4.1
^ permalink raw reply related
* [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry
From: Kumar, Anil @ 2013-01-24 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359016695-10362-1-git-send-email-anilkumar.v@ti.com>
Add OF_DEV_AUXDATA for wdt driver in da850 board dt
file to use wdt clock.
Signed-off-by: Kumar, Anil <anilkumar.v@ti.com>
---
:100644 100644 37c27af... 1b295d2... M arch/arm/mach-davinci/da8xx-dt.c
arch/arm/mach-davinci/da8xx-dt.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 37c27af..1b295d2 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -37,11 +37,17 @@ static void __init da8xx_init_irq(void)
of_irq_init(da8xx_irq_match);
}
+struct of_dev_auxdata da850_evm_auxdata_lookup[] __initdata = {
+ OF_DEV_AUXDATA("ti,davinci-wdt", 0x1c21000, "watchdog", NULL),
+ {}
+};
+
#ifdef CONFIG_ARCH_DAVINCI_DA850
static void __init da850_init_machine(void)
{
- of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table,
+ da850_evm_auxdata_lookup, NULL);
da8xx_uart_clk_enable();
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH] i2c: at91: add of_device_id entry for at91rm9200
From: Joachim Eastwood @ 2013-01-24 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5100E9A4.9020804@atmel.com>
On 24 January 2013 08:58, ludovic.desroches <ludovic.desroches@atmel.com> wrote:
> Hi,
>
>
> On 01/24/2013 08:27 AM, Wolfram Sang wrote:
>>
>> On Tue, Dec 18, 2012 at 07:02:32AM +0100, Jean-Christophe PLAGNIOL-VILLARD
>> wrote:
>>>
>>> On 22:42 Wed 05 Dec , Joachim Eastwood wrote:
>>>>
>>>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>>>> ---
>>>> Hi,
>>>>
>>>> AT91RM9200 is gaining DT support now so let's add an id to the i2c
>>>> driver.
>>>>
>>>> Tested on custom RM9200 board. Since the driver doesn't support pinctrl
>>>> muxing yet I had to add pinctrl hogs for the i2c pins in my dts for it
>>>> to work.
>>>
>>>
>>> IIRC the i2c IP have quite a lots of issue on rm9200 and until sam9g45
>>>
>>> it not recommended to use it instead use i2c-gpio
>>
>>
>> Ludovic, you know the driver best. Does it make sense to add this?
>
>
> I didn't add this when I did the rework because there was no DT tree support
> for RM9200. The configuration for RM9200 IP is already in the driver and
> used for non DT platform so I think it makes sense to add this.
>
> But as Jean-Christophe said, it's recommended to use the i2c-gpio driver
> since we know the first versions of the IP have several issues. However if
> it fits user usage, it is not forbidden to use it.
I assumed the new driver handles the HW quirks better than the old atmel-twi
driver(?). So the RM9200 i2c HW is at least usable with this driver.
I didn't encounter any problems during my short testing using a couple of
different i2c devices. As far as I can remember the old driver didn't even
handle the devices I tested with the new driver.
regards
Joachim Eastwood
^ permalink raw reply
* [PATCH 7/9] ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
From: Nicolas Ferre @ 2013-01-24 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123102057.GJ7360@game.jcrosoft.org>
On 01/23/2013 11:20 AM, Jean-Christophe PLAGNIOL-VILLARD :
> On 10:48 Wed 23 Jan , Nicolas Ferre wrote:
>> No need for this cmdline option as we are using DT.
>> Moreover this defconfig is targeted to multiple SoC/boards: this option
>> was nonsense.
> just keep the console the rest is a nonsense too
>
> as on 9g45 the initrd will be at 0x7xxxxxxx
Understood, but I prefer to keep a "root" option at least, so I keep it
like this.
> the console too but as the patch serie to support via DT is not yet mainline
> we can keep it
Ok for this.
>
> Best Regards,
> J.
>>
>> Reported-by: Josh Wu <josh.wu@atmel.com>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
>> arch/arm/configs/at91_dt_defconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/at91_dt_defconfig b/arch/arm/configs/at91_dt_defconfig
>> index b175577..a353ff6 100644
>> --- a/arch/arm/configs/at91_dt_defconfig
>> +++ b/arch/arm/configs/at91_dt_defconfig
>> @@ -31,7 +31,7 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
>> CONFIG_ZBOOT_ROM_BSS=0x0
>> CONFIG_ARM_APPENDED_DTB=y
>> CONFIG_ARM_ATAG_DTB_COMPAT=y
>> -CONFIG_CMDLINE="mem=128M console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
>> +CONFIG_CMDLINE="console=ttyS0,115200 initrd=0x21100000,25165824 root=/dev/ram0 rw"
>> CONFIG_KEXEC=y
>> CONFIG_AUTO_ZRELADDR=y
>> # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
>> --
>> 1.8.0
>>
>
>
--
Nicolas Ferre
^ permalink raw reply
* Sound/ARM/i.MX/SSI: fix SDMA starvation
From: Juergen Beisert @ 2013-01-24 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In cases when capturing is already running and someone enables also
playback, the SDMA unit of the i.MX SoC does not see an edge on its TX DMA
request line. This is due to the TX FIFOs are empty, and this request line is
active all the time, when the CCSR_SSI_SIER_TDMAE bit is set.
In this case also the TX FIFO underrun interrupt will flood the system forever.
To ensure the first edge happens after enabling the TX side of the SSI unit and
to trigger the SDMA unit successfully enable the CCSR_SSI_SIER_TDMAE on
demand only. To be sure, this patch does the same for the CCSR_SSI_SIER_RDMAE
(RX side) bit.
Signed-off-by: Juergen Beisert <jbe@pengutronix.de>
---
sound/soc/fsl/fsl_ssi.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
Index: linux.git/sound/soc/fsl/fsl_ssi.c
===================================================================
--- linux.git.orig/sound/soc/fsl/fsl_ssi.c
+++ linux.git/sound/soc/fsl/fsl_ssi.c
@@ -86,10 +86,9 @@ static inline void write_ssi_mask(u32 __
#endif
/* SIER bitflag of interrupts to enable */
-#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TDMAE | \
- CCSR_SSI_SIER_TIE | CCSR_SSI_SIER_TUE0_EN | \
- CCSR_SSI_SIER_TUE1_EN | CCSR_SSI_SIER_RFRC_EN | \
- CCSR_SSI_SIER_RDMAE | CCSR_SSI_SIER_RIE | \
+#define SIER_FLAGS (CCSR_SSI_SIER_TFRC_EN | CCSR_SSI_SIER_TIE | \
+ CCSR_SSI_SIER_TUE0_EN | CCSR_SSI_SIER_TUE1_EN | \
+ CCSR_SSI_SIER_RFRC_EN | CCSR_SSI_SIER_RIE | \
CCSR_SSI_SIER_ROE0_EN | CCSR_SSI_SIER_ROE1_EN)
/**
@@ -489,6 +488,9 @@ static int fsl_ssi_hw_params(struct snd_
*
* The DMA channel is in external master start and pause mode, which
* means the SSI completely controls the flow of data.
+ *
+ * To use the i.MX's SDMA unit it is important to create an edge on the
+ * corresponding request line. Otherwise the request will be ignored!
*/
static int fsl_ssi_trigger(struct snd_pcm_substream *substream, int cmd,
struct snd_soc_dai *dai)
@@ -500,20 +502,26 @@ static int fsl_ssi_trigger(struct snd_pc
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
write_ssi_mask(&ssi->scr, 0,
CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_TE);
- else
+ write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_TDMAE);
+ } else {
write_ssi_mask(&ssi->scr, 0,
CCSR_SSI_SCR_SSIEN | CCSR_SSI_SCR_RE);
+ write_ssi_mask(&ssi->sier, 0, CCSR_SSI_SIER_RDMAE);
+ }
break;
case SNDRV_PCM_TRIGGER_STOP:
case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK)
+ if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_TE, 0);
- else
+ write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_TDMAE, 0);
+ } else {
write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_RE, 0);
+ write_ssi_mask(&ssi->sier, CCSR_SSI_SIER_RDMAE, 0);
+ }
break;
default:
--
Pengutronix e.K. | Juergen Beisert |
Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v9 20/20] mdf: omap-usb-host: get rid of build warning
From: Roger Quadros @ 2013-01-24 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123233617.9205.88295@quantum>
On 01/24/2013 01:36 AM, Mike Turquette wrote:
> Quoting Roger Quadros (2013-01-23 02:38:12)
>> Fixes the below build warning when driver is built-in.
>>
>> drivers/mfd/omap-usb-host.c:750:12: warning:
>> ?usbhs_omap_remove? defined but not used [-Wunused-function]
>>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>> Reviewed-by: Felipe Balbi <balbi@ti.com>
>
> Hi Roger,
>
> I just noticed that $SUBJECT says "mdf" instead of "mfd" ;)
>
Thanks Mike. I've fixed it in the pull request and i'll mail a patch as well.
cheers,
-roger.
>
>> ---
>> drivers/mfd/omap-usb-host.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
>> index b21ca76..6b5edf6 100644
>> --- a/drivers/mfd/omap-usb-host.c
>> +++ b/drivers/mfd/omap-usb-host.c
>> @@ -791,7 +791,7 @@ static struct platform_driver usbhs_omap_driver = {
>> .owner = THIS_MODULE,
>> .pm = &usbhsomap_dev_pm_ops,
>> },
>> - .remove = __exit_p(usbhs_omap_remove),
>> + .remove = usbhs_omap_remove,
>> };
>>
>> MODULE_AUTHOR("Keshava Munegowda <keshava_mgowda@ti.com>");
>> --
>> 1.7.4.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v10 20/20] mfd: omap-usb-host: get rid of build warning
From: Roger Quadros @ 2013-01-24 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123233617.9205.88295@quantum>
Fixes the below build warning when driver is built-in.
drivers/mfd/omap-usb-host.c:750:12: warning:
?usbhs_omap_remove? defined but not used [-Wunused-function]
Signed-off-by: Roger Quadros <rogerq@ti.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
---
drivers/mfd/omap-usb-host.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index b21ca76..6b5edf6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -791,7 +791,7 @@ static struct platform_driver usbhs_omap_driver = {
.owner = THIS_MODULE,
.pm = &usbhsomap_dev_pm_ops,
},
- .remove = __exit_p(usbhs_omap_remove),
+ .remove = usbhs_omap_remove,
};
MODULE_AUTHOR("Keshava Munegowda <keshava_mgowda@ti.com>");
--
1.7.4.1
^ permalink raw reply related
* [V5 PATCH 07/26] usb: gadget: mv_udc: make mv_udc depends on ARCH_MMP or ARCH_PXA
From: Felipe Balbi @ 2013-01-24 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359009530-28182-8-git-send-email-chao.xie@marvell.com>
Hi,
On Thu, Jan 24, 2013 at 01:38:31AM -0500, Chao Xie wrote:
> Only ARCH_PXA and ARCH_MMP will use mv_udc.
>
> Signed-off-by: Chao Xie <chao.xie@marvell.com>
NAK, you should fix your transceiver dependency. I want these gadget
drivers to compile cleanly on all arches so we make proper use of
linux-next. I have applied up to previous patch in this series and I
won't go any further. The rest will be delayed for v3.10
sorry
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130124/e0efef21/attachment.sig>
^ permalink raw reply
* [PATCH] i2c: at91: add of_device_id entry for at91rm9200
From: ludovic.desroches @ 2013-01-24 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VxRrPOOQKragU=zSW-FPYdsmUEqY7k_fNHZVEM18zXvCg@mail.gmail.com>
On 01/24/2013 09:43 AM, Joachim Eastwood wrote:
> On 24 January 2013 08:58, ludovic.desroches <ludovic.desroches@atmel.com> wrote:
>> Hi,
>>
>>
>> On 01/24/2013 08:27 AM, Wolfram Sang wrote:
>>>
>>> On Tue, Dec 18, 2012 at 07:02:32AM +0100, Jean-Christophe PLAGNIOL-VILLARD
>>> wrote:
>>>>
>>>> On 22:42 Wed 05 Dec , Joachim Eastwood wrote:
>>>>>
>>>>> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
>>>>> ---
>>>>> Hi,
>>>>>
>>>>> AT91RM9200 is gaining DT support now so let's add an id to the i2c
>>>>> driver.
>>>>>
>>>>> Tested on custom RM9200 board. Since the driver doesn't support pinctrl
>>>>> muxing yet I had to add pinctrl hogs for the i2c pins in my dts for it
>>>>> to work.
>>>>
>>>>
>>>> IIRC the i2c IP have quite a lots of issue on rm9200 and until sam9g45
>>>>
>>>> it not recommended to use it instead use i2c-gpio
>>>
>>>
>>> Ludovic, you know the driver best. Does it make sense to add this?
>>
>>
>> I didn't add this when I did the rework because there was no DT tree support
>> for RM9200. The configuration for RM9200 IP is already in the driver and
>> used for non DT platform so I think it makes sense to add this.
>>
>> But as Jean-Christophe said, it's recommended to use the i2c-gpio driver
>> since we know the first versions of the IP have several issues. However if
>> it fits user usage, it is not forbidden to use it.
>
> I assumed the new driver handles the HW quirks better than the old atmel-twi
> driver(?). So the RM9200 i2c HW is at least usable with this driver.
>
No it doesn't handle HW quirks (clock stretching, stop command, etc.)
better for old IP versions than the old atmel-twi. Since we have no
workarounds for these quirks, it was recommended to use i2c-gpio.
> I didn't encounter any problems during my short testing using a couple of
> different i2c devices. As far as I can remember the old driver didn't even
> handle the devices I tested with the new driver.
I also did some tests on RM9200 with basic i2c devices and everything go
well so yes it is usable that's why I think this patch can be applied.
Regards
Ludovic
^ permalink raw reply
* [GIT PULL] at91: fixes for 3.8-rc5
From: Nicolas Ferre @ 2013-01-24 9:10 UTC (permalink / raw)
To: linux-arm-kernel
Arnd, Olof,
Here is the pull request related to the fixes series that I sent
earlier this week. Changes are obvious and are very constrained in
AT91-related material.
The following changes since commit 7d1f9aeff1ee4a20b1aeb377dd0f579fe9647619:
Linux 3.8-rc4 (2013-01-17 19:25:45 -0800)
are available in the git repository at:
git://github.com/at91linux/linux-at91.git tags/at91-fixes
for you to fetch changes up to 8461c2f6fdd3ef0b26f931d561435df8cae2a9a5:
ARM: at91/dts: correct comment in at91sam9x5.dtsi for mii (2013-01-23 10:40:51 +0100)
----------------------------------------------------------------
Here are fixes for AT91 that are mainly related to device tree.
One RM9200 setup option is the only C code change.
Some documentation changes can clarify the pinctrl use.
Then, some defconfig modifications are allowing the affected platforms
to boot.
----------------------------------------------------------------
Boris BREZILLON (1):
ARM: at91/dts: add macb mii pinctrl config for kizbox
Douglas Gilbert (1):
ARM: at91/dts: correct comment in at91sam9x5.dtsi for mii
Jean-Christophe PLAGNIOL-VILLARD (1):
ARM: at91: rm9200: remake the BGA as default version
Joachim Eastwood (1):
ARM: at91: fix gpios on i2c-gpio for RM9200 DT
Nicolas Ferre (2):
ARM: at91/at91_dt_defconfig: remove memory specification to cmdline
ARM: at91/at91_dt_defconfig: add at91sam9n12 SoC to DT defconfig
Richard Genoud (3):
ARM: at91/at91-pinctrl documentation: fix typo and add some details
ARM: at91/at91sam9x5 DTS: correct wrong PIO BANK values on u(s)arts
ARM: at91/at91sam9x5 DTS: add SCK USART pins
Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt | 5 +--
arch/arm/boot/dts/at91rm9200.dtsi | 4 +--
arch/arm/boot/dts/at91sam9x5.dtsi | 60 +++++++++++++++++++++++------------
arch/arm/boot/dts/kizbox.dts | 2 ++
arch/arm/configs/at91_dt_defconfig | 3 +-
arch/arm/mach-at91/setup.c | 2 ++
6 files changed, 51 insertions(+), 25 deletions(-)
Thanks, best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: DTS: exynos5250-arndale: Add initial board support file
From: Tushar Behera @ 2013-01-24 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK9yfHyKK4L_YH5fw=CrcjzeZgfhGKtDMpZQ3GVLnoVt3gkNiQ@mail.gmail.com>
On 01/24/2013 12:14 PM, Sachin Kamat wrote:
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 5ebb44f..60a9e52 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -44,6 +44,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
>> exynos4210-trats.dtb \
>> exynos4412-smdk4412.dtb \
>> exynos5250-smdk5250.dtb \
>> + exynos5250-arndale.dtb \
>
> I think this entry could be moved one step up for maintaining
> alphabetical order.
>
Ok.
>> exynos5250-snow.dtb \
>> exynos5440-ssdk5440.dtb
>> dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb \
>> diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts b/arch/arm/boot/dts/exynos5250-arndale.dts
>> new file mode 100644
>> index 0000000..7504cf3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/exynos5250-arndale.dts
>> @@ -0,0 +1,124 @@
>> +/*
>> + * Samsung's Exynos5250 based Arndale board device tree source
>> + *
>> + * Copyright (c) 2012 Samsung Electronics Co., Ltd.
>
> 2013?
>
Ok.
>> + * http://www.samsung.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> +*/
>> +
>> +/dts-v1/;
>> +/include/ "exynos5250.dtsi"
>> +
>> +/ {
>> + model = "Insignal Arndale evaluation board based on EXYNOS5250";
>> + compatible = "insignal,arndale", "samsung,exynos5250";
>> +
>> + memory {
>> + reg = <0x40000000 0x80000000>;
>> + };
>> +
>> + chosen {
>> + bootargs = "root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC2,115200 init=/linuxrc";
>
> This could be resticted only to console
> bootargs = "console=ttySAC2,115200";
>
>
Ok.
I will resubmit the patchset.
--
Tushar Behera
^ permalink raw reply
* [PATCH 3/6 v14] gpio: Add userland device interface to block GPIO
From: Alexander Stein @ 2013-01-24 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358856404-8975-4-git-send-email-stigge@antcom.de>
On Tuesday 22 January 2013 13:06:41, Roland Stigge wrote:
> This patch adds a character device interface to the block GPIO system.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
> ---
> Documentation/ABI/testing/dev-gpioblock | 34 ++++
> drivers/gpio/gpiolib.c | 225 +++++++++++++++++++++++++++++++-
> include/linux/gpio.h | 13 +
> 3 files changed, 271 insertions(+), 1 deletion(-)
>
> --- /dev/null
> +++ linux-2.6/Documentation/ABI/testing/dev-gpioblock
> @@ -0,0 +1,34 @@
> +What: /dev/<gpioblock>
> +Date: Nov 2012
> +KernelVersion: 3.7
> +Contact: Roland Stigge <stigge@antcom.de>
> +Description: The /dev/<gpioblock> character device node provides userspace
> + access to GPIO blocks, named exactly as the block, e.g.
> + /dev/block0.
> +
> + Reading:
> + When reading sizeof(unsigned long) bytes from the device, the
> + current state of the block, masked by the current mask (see
> + below) can be obtained as a word. When the device is opened
> + with O_NONBLOCK, read() always returns with data immediately,
> + otherwise it blocks until data is available, see IRQ handling
> + below.
> +
> + Writing:
> + By writing sizeof(unsigned long) bytes to the device, the
> + current state of the block can be set. This operation is
> + masked by the current mask (see below).
> +
> + IRQ handling:
> + When one or more IRQs in the block are IRQ capable, you can
^^^^
I think this should be GPIOs
> +static long gpio_block_fop_ioctl(struct file *f, unsigned int cmd,
> + unsigned long arg)
> +{
> + struct gpio_block *block = (struct gpio_block *)f->private_data;
> + unsigned long __user *x = (unsigned long __user *)arg;
> +
> + if (cmd == 0)
> + return get_user(block->cur_mask, x);
> +
> + return -EINVAL;
> +}
So there is no way from userspace to create/remove GPIO blocks? I know support in sysfs is problematic due to formatting, but an IOCTL for that would be nice.
Best regards,
Alexander
^ permalink raw reply
* [PATCH] ARM: DTS: exynos5250-arndale: Add initial board support file
From: Tushar Behera @ 2013-01-24 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGOxZ53VsXE_as6aNk85jdxVG2FAg-SqWc8svTHpgrcttE_q0w@mail.gmail.com>
On 01/24/2013 12:21 PM, Alim Akhtar wrote:
>> +
>> + i2c at 12CC0000 {
>> + status = "disabled";
>> + };
>> +
>> + i2c at 12CD0000 {
>> + status = "disabled";
>> + };
>> +
>> + i2c at 121D0000 {
>> + status = "disabled";
>> + };
>> +
>
> Why to disable these i2c devices here? Any particular reason?
> You can moves these to exynos5250.dtsi which is suppose to be common
> for all the exynos5250 platforms.
> Please see the exynos4.dtsi for reference.
>
Agreed. There was a discussion going on in [1] related to this. Since
there was no consensus on that, I preferred to go with the current
approach that is followed for other EXYNOS5250 based scripts.
If it is agreed by Kukjin to move to Exynos4 style, then I can submit
patches for that.
[1]
http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg15013.html
--
Tushar Behera
^ permalink raw reply
* [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Stefan Hajnoczi @ 2013-01-24 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALrVBktEQM5D-L+60RTzdRgo7jLZ671KxWMUFGnQwQ1bzgjO2A@mail.gmail.com>
On Thu, Jan 24, 2013 at 11:40:24AM +0530, Anup Patel wrote:
> IMHO, If we have something like Virtio-desktop specification then all
> possible guest OSes can have support for it and different hypervisor can
> emulate it without worrying about guest support.
At this point x86 virtualization is mature and working with a mix of
emulated x86 architecture pieces and virtio devices for
performance-critical or open-ended functionality that we want to be able
to extend.
ARM is getting KVM and virtio-mmio support. It will be in a similar
position soon.
Virtio guest drivers have not been implemented widely. The Linux and
Windows efforts are driven by the folks who were behind virtio from the
start, but Solaris, FreeBSD, and others didn't really jump on the virtio
bandwagon.
Given this landscape, what is the advantage of doing a virtio-desktop?
It will still need to fall back on ARM or x86 which is already being
virtualized and emulated.
Depending on how you see it we either have virtio-desktop already or,
if not, I think the experience with virtio adoption suggests other
hypervisors and guest OSes will not trip over themselves to implement
virtio-desktop.
What's the advantage over virtualizating an existing ARM or x86 platform
and using virtio devices where appropriate?
Stefan
^ permalink raw reply
* [alsa-devel] [PATCH V2 2/2] ASoC: Davinci: machine: Add device tree binding
From: Hebbar, Gururaja @ 2013-01-24 9:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123154804.GB4565@opensource.wolfsonmicro.com>
On Wed, Jan 23, 2013 at 21:18:12, Mark Brown wrote:
> On Wed, Jan 23, 2013 at 12:39:35PM +0000, Hebbar, Gururaja wrote:
> > On Fri, Jan 04, 2013 at 17:56:12, Mark Brown wrote:
>
> > > The CODEC driver biases should be changed over to be supplies, this
> > > makes the above much more natural - the routing there is a hack for
> > > older versions of ASoc. Otherwise this looks fine.
>
> > ON TLV320AIC3x Codec, MIC Bias power on/off share the same register bits
> > with Bias voltage output.
>
> So you need to use an event to write the actual enable bit.
Yes. Bias Enable/Disable is possible using SND_SOC_DAPM_SUPPLY. However the
actual Bias voltage should be user selectable.
>
> > SGTL5000 --> Single register for MIC BIAS enable & output impedance of MIC
> > Bias. The driver uses SND_SOC_DAPM_POST_PMU & SND_SOC_DAPM_PRE_PMD macro to
> > handle the MIC Bias enable & disable event.
>
> This is the way these things should be handled.
However, as mentioned before, TLV320AIC3x Codec there is no separate
enable/disable bit. It is mixed with Bias Voltage settings.
So it is either
a. Bias is disabled
b. Bias is enabled with some voltage. This voltage should be user
configurable.
So, by just using the SND_SOC_DAPM_POST_PMU & SND_SOC_DAPM_PRE_PMD I can mask
& handle one particular voltage.
Now I am not able understand how to make this user configurable using
SND_SOC_DAPM_xx macro.
I believe the below code change [1] should work in this situation. What is your opinion?
Thanks & Regards
Gururaja
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index 5708a97..2c17e46 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -268,6 +268,11 @@ static DECLARE_TLV_DB_SCALE(adc_tlv, 0, 50, 0);
*/
static DECLARE_TLV_DB_SCALE(output_stage_tlv, -5900, 50, 1);
+static const char *mic_bias_level_txt[] = { "off", "2V", "2.5V", "AVDD" };
+
+static const struct soc_enum mic_bias_level =
+SOC_ENUM_SINGLE(MICBIAS_CTRL, 6, 4, mic_bias_level_txt);
+
static const struct snd_kcontrol_new aic3x_snd_controls[] = {
/* Output */
SOC_DOUBLE_R_TLV("PCM Playback Volume",
@@ -391,6 +396,9 @@ static const struct snd_kcontrol_new aic3x_snd_controls[] = {
SOC_DOUBLE_R("PGA Capture Switch", LADC_VOL, RADC_VOL, 7, 0x01, 1),
SOC_ENUM("ADC HPF Cut-off", aic3x_enum[ADC_HPF_ENUM]),
+
+ /* Mic Bias Level */
+ SOC_ENUM("Mic Bias Level", mic_bias_level),
};
/*
@@ -596,12 +604,7 @@ static const struct snd_soc_dapm_widget aic3x_dapm_widgets[] = {
AIC3X_ASD_INTF_CTRLA, 0, 3, 3, 0),
/* Mic Bias */
- SND_SOC_DAPM_REG(snd_soc_dapm_micbias, "Mic Bias 2V",
- MICBIAS_CTRL, 6, 3, 1, 0),
- SND_SOC_DAPM_REG(snd_soc_dapm_micbias, "Mic Bias 2.5V",
- MICBIAS_CTRL, 6, 3, 2, 0),
- SND_SOC_DAPM_REG(snd_soc_dapm_micbias, "Mic Bias AVDD",
- MICBIAS_CTRL, 6, 3, 3, 0),
+ SND_SOC_DAPM_SUPPLY("Mic Bias", MICBIAS_CTRL, 6, 0, NULL, 0),
/* Output mixers */
SND_SOC_DAPM_MIXER("Left Line Mixer", SND_SOC_NOPM, 0, 0,
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 82d29a5..37b8e78 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -128,9 +128,9 @@ static const struct snd_soc_dapm_route audio_map[] = {
{"Line Out", NULL, "RLOUT"},
/* Mic connected to (MIC3L | MIC3R) */
- {"MIC3L", NULL, "Mic Bias 2V"},
- {"MIC3R", NULL, "Mic Bias 2V"},
- {"Mic Bias 2V", NULL, "Mic Jack"},
+ {"MIC3L", NULL, "Mic Bias"},
+ {"MIC3R", NULL, "Mic Bias"},
+ {"Mic Bias", NULL, "Mic Jack"},
/* Line In connected to (LINE1L | LINE2L), (LINE1R | LINE2R) */
{"LINE1L", NULL, "Line In"},
^ permalink raw reply related
* [PATCH 1/1] ARM: ux500: Disable Power Supply and Battery Management by default
From: Lee Jones @ 2013-01-24 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYydqJ+BVsh7P411zCod+83f2pVV5tPsKfoWPYUnOVpDQ@mail.gmail.com>
On Mon, 21 Jan 2013, Linus Walleij wrote:
> On Mon, Jan 14, 2013 at 3:57 PM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > The AB8500 Battery Management collection of drivers are more than a
> > little bit broken. There is lots of work still on-going in that area
> > and it's improving day by day; however, it's not ready to be enabled
> > by default just yet.
> >
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> Is this going for fixes (v3.8?)
Sorry, I thought I answer this, but clearly I didn't.
Can you take this into the -rcs please? It's preventing from a few of
the platforms from booting.
> For v3.9 I think you've submitted a whole lot of patches
> actually fixing it up?
>
> Anyway: Acked-by: Linus Walleij <linus.walleij@linaro.org>
> since you certainly know the status of this driver better than
> me.
>
> Yours,
> Linus Walleij
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Soc MC13783: Improve driver to handle LineIn
From: Gaëtan Carlier @ 2013-01-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
I would like to improve MC13783 driver to be able to control bypass of
LineIn (RXINR/L) and feed Analog LineIn stream into ouput Mixer via
ADDRXIN flag.
This first step one is for test purpose but I also need to select
RXINR/L as capture source (I saw in RM that CODEC must be enabled and
only RXINR flag must be selected as input) but nothing seems to be
captured this is why I need bypass working to test input level, and so on.
I try to create a Mixer based on other driver but it doesn't work.
I try to finc information about widget macro SND_SOC_DAPM_* but it is
hard to find something relevant.
* Which widgets can be link together ?
* Is there functional difference between VIRT and non-VIRT widget ?
I will post my code in some minutes after clean-up.
Thanks a lot.
Ga?tan Carlier.
^ permalink raw reply
* [PATCH] ARM: shmobile: ipmmu: Add basic PMB support
From: Damian Hobson-Garcia @ 2013-01-24 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1906988.fAZIpjYMPs@avalon>
Hi Laurent,
On 2013/01/23 9:04, Laurent Pinchart wrote:
> Hi Damian,
>
> On Tuesday 22 January 2013 11:31:51 Damian Hobson-Garcia wrote:
>> On 2013/01/21 22:12, Laurent Pinchart wrote:
>>> On Friday 18 January 2013 15:35:10 Damian Hobson-Garcia wrote:
>>>> The PMB can be used to remap 16, 64, 128 or 512 MiB pages from
>>>> the 0x80000000-0xffffffff address range to anywhere in the
>>>> 0x00000000-0x7fffffff range.
>>>
>>> Isn't it 0x80000000 - 0xbfffffff to 0x00000000 - 0xffffffff ?
>>
>> Yes, looking again at the spec, your values are the correct ones.
>>
>>>> It also has the ability to perform tiled-linear address translation,
>>>> which can be used to access a memory buffer as a series of n x m tiles,
>>>> useful for image encoding/decoding.
>>>> Currently only the userspace API via character device is supported.
>>>
>>> If I understand this correctly, you're allowing userspace to remap a
>>> virtual address block to a physical address block without performing any
>>> sanity check. Isn't that a major security issue ?
>>
>> No, not really. The PMB will only remap physical addresses, not virtual
>> addresses. Moreover, the remapped address is only accessible from the
>> IP blocks which are on the ICB bus, not the CPU. I will update the
>> comment to mention this. These IP blocks already have access to the
>> entire physical memory address space, so I don't think that adding the
>> the PMB into mix introduces any new security issues.
>
> The IP block will be programmed through a driver that will control where it
> writes to/reads from. Adding the PMB will remap those read/write operations
> without notifying the driver, opening the door to potential issues.
Actually this cannot happen. The driver must use the PMB driver to
request a mapping, and that mapping cannot be modified by user-space or
any other drivers.
Since the PMB only remaps address starting from 0x80000000 (which is
outside of the DRAM address space supported by the PMB enabled shmobile
devices), only drivers that intentionally use addresses within the PMB
range will have their data remapped.
By requesting a mapping by specifying the size and mapping destination
to the PMB driver, a driver will effectively lock a region of the PMB
address space for its own use. Since the specific region that is locked
is decided by the PMB driver, no other device can make changes to the
mappings in that region.
For example:
1. Driver A requests a PMB remap to address addr1 with a size of 16M
2. The PMB driver will allocate a region in the PMB address area to hold
the mapping (eg. 0x80000000 - 0x80000000 + 16M - 1)
3. Driver A accesses addr1 by specifying a DMA address of 0x80000000 to
the hardware
If another client (driver instance, user space, etc) tries to create
another mapping, the PMB driver allocates that request to an unused
memory region (perhaps 0x80000000 + 64M). If there are no available
regions left, the request will fail.
>
> What are the use cases for controlling the PMB from userspace ?
user-space drivers.
Thanks,
Damian
>
>> ...
>>
>>>> +
>>>> +#define PMB_DEVICE_NAME "pmb"
>>>> +
>>>> +#define PMB_NR 16
>>>> +/* the smallest size that can be reserverd in the pmb */
>>>> +#define PMB_GRANULARITY (16 << 20)
>>>> +#define PMB_START_ADDR 0x80000000
>>>> +#define PMB_SIZE 0x40000000
>>>> +#define NUM_BITS(x) ((x) / PMB_GRANULARITY)
>>>> +#define NR_BITMAPS ((NUM_BITS(PMB_SIZE) + BITS_PER_LONG - 1) \
>>>> + >> ilog2(BITS_PER_LONG))
>>>
>>> Does ilog2(BITS_PER_LONG) resolve to a compile-time constant ?
>>
>> Yes it does.
>>
>> Thanks for your other comments too. I'll look into making those changes.
>
--
Damian Hobson-Garcia
IGEL Co.,Ltd
http://www.igel.co.jp
^ 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