* [PATCH v3 11/21] ARM: pxa: support ICP DAS LP-8x4x FPGA irq
From: Sergei Ianovich @ 2014-01-15 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda_6P3s3LBwV5ve+=_JhxehephvpPT=pKPk3NzEKQLa9g@mail.gmail.com>
On Wed, 2014-01-15 at 08:39 +0100, Linus Walleij wrote:
> On Wed, Jan 8, 2014 at 8:01 PM, Sergei Ianovich <ynvich@gmail.com> wrote:
> Hm I don't know why I was deluded into thinking this had something to
> do with GPIO. I must have been soft in the head. Sorry about all those
> comments ...
It's not your fault for sure. My commit message wasn't clear enough and
needed clarifications. It is better now.
Thanks for constructive reviewing.
^ permalink raw reply
* [PATCH] ARM: S3C[24|64]xx: move includes back under <mach/> scope
From: Arnd Bergmann @ 2014-01-15 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda=p6GnpuNQizdQA1gGuOe8Lnsp+r8rQedWCRog2MRHww@mail.gmail.com>
On Wednesday 15 January 2014, Linus Walleij wrote:
> When I look at it, the issue also exist in e.g.
> drivers/gpio/gpio-samsung.c which can be compiled
> (like for allyesconfig) when PLAT_SAMSUNG is set.
>
> And it is also set to y for ARCH_EXYNOS... which
> doesn't have any custom GPIO header. So this would
> involve something like creating an empty
> <mach/gpio-samsung.h> for Exynos which doesn't
> seem like the right thing to do.
Ah, right. I looked at this before, but I misremembered about
PLAT_SAMSUNG and thought it was fine because ARCH_EXYNOS no
longer implied PLAT_SAMSUNG. That was wrong, instead ARCH_EXYNOS
still sets PLAT_SAMSUNG but not PLAT_S5P as it used to.
> So I'm sticking with the #ifdef patch for now as it
> seems to be the lesser evil :-/
Yes, agreed.
Arnd
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-15 13:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5MyWs3Z6MEvx9Rq6XaopcDppmjWaEUt036vBRf0Uy9aAg@mail.gmail.com>
On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
> >> Hi Boris,
> >>
> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
> >> >>
> >> >> Hello Nicolas, Jean-Christophe,
> >> >>
> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
> >> >> to know the state of the pendown gpio and also needs it as an
> >> >> interrupt source.
> >> >>
> >> >> The problem is that when a gpio is used as an interrupt, it's
> >> >> requested by the pinctrl driver during the xlate stage, marking it
> >> >> unavaliable for the other driver.
> >> >> It looks like the at91 pinctrl driver is the only one to use
> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
> >> >
> >> >
> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
> >> > related IRQ.
> >> > Because what is done here, is to solve the case where only the irq
> >> > is request, and in this specific case we need to request the pin as a
> >> > GPIO.
> >> >
> >>
> >> That's what I did first, and was about to submit the patch for the
> >> touchscreen driver.
> >> However it doesn't feel right. Being able to get the state of a gpio
> >> that is also an interrupt seems very useful to me, not only for a
> >> touchscreen controller.
> >>
> >> I understand why it's being done here. It's a matter of being sure
> >> that the GPIO is an input and that it'll not be configured otherwise
> >> latter.
> >> But:
> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
> >
> > because this the only to start to do it right
> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
> > use gpio_to_irq & co for irq.
> How can you get the value of the gpio that is also an interrupt source then ?
> Can you give a short example?
you just have to check the irq source
failing or raising
but on 9261 impossible the gpio does not have such detail
but anyway this is the invert you need to get the information from the IRQ no the way
arround
so the gpio driver may need to be updated to provide such information to the
touch driver
Best Regards,
J.
>
> >
> > I even send a proposition to do this work across the kernel t the CE-Linux for
> > funding
> >> 2) I believe that configuration of the direction can be done by
> >> describing the GPIO in the DT. (pinctrl-at91.c line 592).
> > No pinctrl is for pinmux ONLY not gpio direction & co
> >
> > Best Regards,
> > J.
> >
> >> 3) If all the GPIOs are described in the DT with a proper pinmux
> >> description, i believe the exclusion is also handled. It's probably
> >> not the case today though.
> >
> >>
> >> >
> >> > Best Regards,
> >> >
> >> > Boris
> >> >
> >> >>
> >> >> diff --git a/drivers/pinctrl/pinctrl-at91.c
> >> >> b/drivers/pinctrl/pinctrl-at91.c
> >> >> index a7549c4..cf91a35 100644
> >> >> --- a/drivers/pinctrl/pinctrl-at91.c
> >> >> +++ b/drivers/pinctrl/pinctrl-at91.c
> >> >> @@ -1463,14 +1463,6 @@ static int at91_gpio_irq_domain_xlate(struct
> >> >> irq_domain *d,
> >> >> *out_hwirq = intspec[0];
> >> >> *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> >> >>
> >> >> - ret = gpio_request(pin, ctrlr->full_name);
> >> >> - if (ret)
> >> >> - return ret;
> >> >> -
> >> >> - ret = gpio_direction_input(pin);
> >> >> - if (ret)
> >> >> - return ret;
> >> >> -
> >> >> return 0;
> >> >> }
> >> >>
> >> >> Jean-Jacques
> >> >
> >> >
> >>
> >> _______________________________________________
> >> 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] ARM: sunxi: change the AllWinner A1X to sunxi
From: Gerardo Di Iorio @ 2014-01-15 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3612364.BZBltgonI0@wuerfel>
hi,
2014/1/15 Arnd Bergmann <arnd@arndb.de>
>
> On Wednesday 15 January 2014 10:10:06 Maxime Ripard wrote:
> > On Thu, Jan 09, 2014 at 04:34:04PM +0100, Gerardo Di Iorio wrote:
> > > Change the AllWinner A1X SOCs to Allwinner Sunxi SOCs
> > >
> > > Signed-off-by: Gerardo Di Iorio <arete74@gmail.com>
> > > ---
> > > arch/arm/mach-sunxi/Kconfig | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
> > > index 547004c..adb2574 100644
> > > --- a/arch/arm/mach-sunxi/Kconfig
> > > +++ b/arch/arm/mach-sunxi/Kconfig
> > > @@ -1,5 +1,5 @@
> > > config ARCH_SUNXI
> > > - bool "Allwinner A1X SOCs" if ARCH_MULTI_V7
> > > + bool "Allwinner Sunxi SOCs" if ARCH_MULTI_V7
> >
> > I wonder if the sunxi (apart the weird letter case) is actually
> > needed. Maybe we can just put "Allwinner SoCs" (it would be great if
> > you could fix the SoCs case too).
>
> If you want to have exact naming, try to find something that excludes the
> old Sun3i (F20) and earlier chips (unless someone is already planning
> to work on them). Maybe also mention the "Boxchip" name, although that
> seems to be falling out of use these days.
>
if we use "Allwinner AX SoC" ?
> Arnd
>
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Tero Kristo @ 2014-01-15 13:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115035011.4167.96678@quantum>
On 01/15/2014 05:50 AM, Mike Turquette wrote:
> Quoting Mike Turquette (2014-01-14 19:16:32)
>> Quoting Felipe Balbi (2014-01-14 18:04:21)
>>> Hi,
>>>
>>> On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
>>>>> Felipe, care to run your randconfig magic for this?
>>>>
>>>> This branch builds just fine so far, I still have omap5 multiplaform and
>>>> uniplatform builds, but since that was working before i'm assuming it
>>>> won't break.
>>>
>>> No build failures in any of my 18 seeds (5 randconfigs of each), I'd
>>> attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
>>> send it.
>>>
>>> FWIW:
>>>
>>> Acked-by: Felipe Balbi <balbi@ti.com>
>>
>> Felipe,
>>
>> That's great to hear. Thanks for testing.
>>
>> Tero & Tony,
>>
>> These 40 patches apply very cleanly on top of clk-next with 2
>> exceptions:
>>
>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
>> on 3.13-rc1).
>>
>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
>> resolved correctly but would like verification.
>>
>> I'd prefer to simply merge these patches into clk-next, which is the
>> most straightforward route. Any ideas on how to handle the missing
>> AM35xx dtsi data? It can always go as a separate fix after this stuff
>> gets merged which, ironically, is how that file was created in the first
>> place.
>
> I've pushed my branch. Tero can you take a look and let me know if you
> see any problems?
>
> git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap
Hey Mike,
Can't see any issues there, also gave it a quick boot test with the
boards I have access to and seems to work fine.
-Tero
>
> Thanks!
> Mike
>
>>
>> Regards,
>> Mike
>>
>>>
>>> cheers
>>>
>>> --
>>> balbi
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-15 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115132035.GE9558@ns203013.ovh.net>
2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
>> >> Hi Boris,
>> >>
>> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
>> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>> >> >>
>> >> >> Hello Nicolas, Jean-Christophe,
>> >> >>
>> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
>> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
>> >> >> to know the state of the pendown gpio and also needs it as an
>> >> >> interrupt source.
>> >> >>
>> >> >> The problem is that when a gpio is used as an interrupt, it's
>> >> >> requested by the pinctrl driver during the xlate stage, marking it
>> >> >> unavaliable for the other driver.
>> >> >> It looks like the at91 pinctrl driver is the only one to use
>> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
>> >> >
>> >> >
>> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
>> >> > related IRQ.
>> >> > Because what is done here, is to solve the case where only the irq
>> >> > is request, and in this specific case we need to request the pin as a
>> >> > GPIO.
>> >> >
>> >>
>> >> That's what I did first, and was about to submit the patch for the
>> >> touchscreen driver.
>> >> However it doesn't feel right. Being able to get the state of a gpio
>> >> that is also an interrupt seems very useful to me, not only for a
>> >> touchscreen controller.
>> >>
>> >> I understand why it's being done here. It's a matter of being sure
>> >> that the GPIO is an input and that it'll not be configured otherwise
>> >> latter.
>> >> But:
>> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
>> >
>> > because this the only to start to do it right
>> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
>> > use gpio_to_irq & co for irq.
>> How can you get the value of the gpio that is also an interrupt source then ?
>> Can you give a short example?
>
> you just have to check the irq source
>
> failing or raising
>
> but on 9261 impossible the gpio does not have such detail
>
> but anyway this is the invert you need to get the information from the IRQ no the way
> arround
Should I modify the touchscreen driver to use irq_to_gpio() in this
case then ? or is this also not proper ?
>
> so the gpio driver may need to be updated to provide such information to the
> touch driver
>
> Best Regards,
> J.
>>
>> >
>> > I even send a proposition to do this work across the kernel t the CE-Linux for
>> > funding
>> >> 2) I believe that configuration of the direction can be done by
>> >> describing the GPIO in the DT. (pinctrl-at91.c line 592).
>> > No pinctrl is for pinmux ONLY not gpio direction & co
>> >
>> > Best Regards,
>> > J.
>> >
>> >> 3) If all the GPIOs are described in the DT with a proper pinmux
>> >> description, i believe the exclusion is also handled. It's probably
>> >> not the case today though.
>> >
>> >>
>> >> >
>> >> > Best Regards,
>> >> >
>> >> > Boris
>> >> >
>> >> >>
>> >> >> diff --git a/drivers/pinctrl/pinctrl-at91.c
>> >> >> b/drivers/pinctrl/pinctrl-at91.c
>> >> >> index a7549c4..cf91a35 100644
>> >> >> --- a/drivers/pinctrl/pinctrl-at91.c
>> >> >> +++ b/drivers/pinctrl/pinctrl-at91.c
>> >> >> @@ -1463,14 +1463,6 @@ static int at91_gpio_irq_domain_xlate(struct
>> >> >> irq_domain *d,
>> >> >> *out_hwirq = intspec[0];
>> >> >> *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
>> >> >>
>> >> >> - ret = gpio_request(pin, ctrlr->full_name);
>> >> >> - if (ret)
>> >> >> - return ret;
>> >> >> -
>> >> >> - ret = gpio_direction_input(pin);
>> >> >> - if (ret)
>> >> >> - return ret;
>> >> >> -
>> >> >> return 0;
>> >> >> }
>> >> >>
>> >> >> Jean-Jacques
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> linux-arm-kernel mailing list
>> >> linux-arm-kernel at lists.infradead.org
>> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Mark Rutland @ 2014-01-15 13:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115124041.GD9558@ns203013.ovh.net>
On Wed, Jan 15, 2014 at 12:40:41PM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 12:17 Wed 15 Jan , Mark Rutland wrote:
> > On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > The new interrupts-extended property, which reuses the phandle+arguments
> > > pattern used by GPIOs and other core bindings, still have some issue.
> > >
> > > If an SoC have already specifiy interrupt and a board want to add specific
> > > interrupt such as GPIO (which can be optionnal) be need to re-define
> > > interrupts-extended. So allow to have an optionnale interrupts-extended-2
> > > property.
> > >
> >
> > NAK.
> >
> > This is a hack that works around a dts organisation issue. This is _not_
> > a binding or parsing issue.
>
> So the DT is stupid. Yes w have board and SoC information
> so we do not want to duplicate them. Having a way to descript SoC vs board
> specific information need to be provided.
I agree that the current situation isn't fantastic. That doesn't make
the DT stupid. There are other solutions to this problem.
>
> >
> > Properties can be overridden - just describe all of the interrupts in
> > the final dts file.
> this is wrong, which mean you duplicate informaation and duplicate bug and
> fixes
It's certainly not nice, but it doesn't make it wrong.
The same problem can be found with any other list property that varies
per-board. Hacking the parsing of each property is not a solution.
Today the only way to implement what you want is to have the list in the
final file.
One way of working with that would be to have the common interrupts
described in a shared macro in the soc file:
#define SOC_COMMON_INTERRUPTS <&intc1 5 1>, <&intc2 1 0>
Then the soc file can have:
interrupts = SOC_COMMON_INTERRUPTS;
And the board can have:
interrupts = SOC_COMMON_INTERRUPTS, <&intc1 6 1>;
That gains functionality equivalent to your proposal, without
introducing new code or new edge cases in interrupt parsing. However, it
does make it unclear how many interrupts are described, and it won't
interact well with interrupt-names.
Another, more invasive option would be extend the dts syntax and teach
dtc to handle property appending. Then the soc dts could stay as it is,
and the board dts could have something like:
/append-property/ interrupts = <&intc1 6 1>;
/append-property/ interrupt-names = "board-specific-irq";
Both these options solve the issue at the source, are general to other
properties, and allow more than one level of hierarchy (the proposed
interrupts-extended-2 only allows one level).
Thanks,
Mark.
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Arnd Bergmann @ 2014-01-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Mccz47VMxDcrAC1NY30cY53gxEmp5MG4+n0PNn5RrsSw@mail.gmail.com>
On Wednesday 15 January 2014 14:44:24 Jean-Jacques Hiblot wrote:
> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> > On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> >> > because this the only to start to do it right
> >> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
> >> > use gpio_to_irq & co for irq.
> >> How can you get the value of the gpio that is also an interrupt source then ?
> >> Can you give a short example?
> >
> > you just have to check the irq source
> >
> > failing or raising
> >
> > but on 9261 impossible the gpio does not have such detail
> >
> > but anyway this is the invert you need to get the information from the IRQ no the way
> > arround
>
> Should I modify the touchscreen driver to use irq_to_gpio() in this
> case then ? or is this also not proper ?
irq_to_gpio no longer exists.
Arnd
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Anssi Hannula @ 2014-01-15 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D67099.1040904@ti.com>
15.01.2014 13:27, Jyri Sarha kirjoitti:
> On 12/31/2013 03:25 PM, Mark Brown wrote:
>> On Fri, Dec 20, 2013 at 12:39:38PM +0200, Jyri Sarha wrote:
>>> support. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE.
>>> The 8 least significant bits are ignored.
>>
>> Where does this constraint come from?
>>
>
> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> register statically to a value that works only with 4 byte samples.
> According to my tests it is possible to support 3 and 2 byte samples too
> by changing the CTS_N register value, but I am not sure if the
> configuration can be changed on the fly. My data sheet of the nxp chip
> is very vague about the register definitions, but I suppose the register
> configures some clock divider on the chip. HDMI supports only upto 24bit
> audio and the data sheet states that any extraneous least significant
> bits are ignored.
That sounds strange, CTS/N values only depend on audio sample rate and
TMDS/video clock, not on the audio format or the size of samples (HDMI
spec sec 7.2 - Audio Sample Clock Capture and Regeneration).
Sure there isn't anything more going on (like the used HDMI sink being
more tolerant to wrong CTS/N with 4-byte samples, or more likely
something else I can't immediately think of)?
BTW, radeon driver has some code that calculates static CTS/N values
since the hw autogeneration is not reliable there:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/radeon/r600_hdmi.c
Not that it directly helps now, but just for the record...
--
Anssi Hannula
^ permalink raw reply
* [RFC 0/2] Early patches to get rid of meminfo
From: Leif Lindholm @ 2014-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389765322-28582-1-git-send-email-lauraa@codeaurora.org>
Hi Laura,
On Tue, Jan 14, 2014 at 09:55:20PM -0800, Laura Abbott wrote:
> With the move away from bootmem and the convergence on memblock, it seems
> like meminfo should be deprecated as well to avoid duplication. This is
> a first pass attempt to just use memblock and not have meminfo integrated.
> There is still a major issue in terms of actually specifying mem at location
> on the command line but I wanted to send this out for some early feedback
> before putting any more effort into this. I've done basic boot testing on
> a simple DT target.
I can't see 1/2 and 2/2 - either in my inbox or in the archive.
Could you resend?
/
Leif
^ permalink raw reply
* [PATCH v3 2/2] serial: fsl_lpuart: add DMA support
From: Mark Rutland @ 2014-01-15 13:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15900408.Osb5heuoGi@wuerfel>
On Wed, Jan 15, 2014 at 11:17:07AM +0000, Arnd Bergmann wrote:
> On Wednesday 15 January 2014 11:05:37 Mark Rutland wrote:
> > On Wed, Jan 15, 2014 at 05:21:05AM +0000, Yuan Yao wrote:
> > > --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> > > +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
> > > @@ -4,11 +4,24 @@ Required properties:
> > > - compatible : Should be "fsl,<soc>-lpuart"
> > > - reg : Address and length of the register set for the device
> > > - interrupts : Should contain uart interrupt
> > > +- clocks : from common clock binding: handle to uart clock
> > > +- clock-names : from common clock binding: Shall be "ipg"
> >
> > Why are these now requried if they weren't previously? That breaks old
> > dts. I can't see any new code touching clocks. Was this an old but
> > undocumented requirement?
>
> It was previously required but not documented. I asked Yuan Yao to
> add the text to the binding along with the new "dmas" addition.
Ok.
>
> It would have been cleaner to do this as a separate patch, but at
> the very least it should be mentioned in the changelog.
Having it in the changelog would be nice.
Cheers,
Mark.
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-15 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Mccz47VMxDcrAC1NY30cY53gxEmp5MG4+n0PNn5RrsSw@mail.gmail.com>
On 14:44 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> > On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> >> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
> >> >> Hi Boris,
> >> >>
> >> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
> >> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
> >> >> >>
> >> >> >> Hello Nicolas, Jean-Christophe,
> >> >> >>
> >> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
> >> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
> >> >> >> to know the state of the pendown gpio and also needs it as an
> >> >> >> interrupt source.
> >> >> >>
> >> >> >> The problem is that when a gpio is used as an interrupt, it's
> >> >> >> requested by the pinctrl driver during the xlate stage, marking it
> >> >> >> unavaliable for the other driver.
> >> >> >> It looks like the at91 pinctrl driver is the only one to use
> >> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
> >> >> >
> >> >> >
> >> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
> >> >> > related IRQ.
> >> >> > Because what is done here, is to solve the case where only the irq
> >> >> > is request, and in this specific case we need to request the pin as a
> >> >> > GPIO.
> >> >> >
> >> >>
> >> >> That's what I did first, and was about to submit the patch for the
> >> >> touchscreen driver.
> >> >> However it doesn't feel right. Being able to get the state of a gpio
> >> >> that is also an interrupt seems very useful to me, not only for a
> >> >> touchscreen controller.
> >> >>
> >> >> I understand why it's being done here. It's a matter of being sure
> >> >> that the GPIO is an input and that it'll not be configured otherwise
> >> >> latter.
> >> >> But:
> >> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
> >> >
> >> > because this the only to start to do it right
> >> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
> >> > use gpio_to_irq & co for irq.
> >> How can you get the value of the gpio that is also an interrupt source then ?
> >> Can you give a short example?
> >
> > you just have to check the irq source
> >
> > failing or raising
> >
> > but on 9261 impossible the gpio does not have such detail
> >
> > but anyway this is the invert you need to get the information from the IRQ no the way
> > arround
>
> Should I modify the touchscreen driver to use irq_to_gpio() in this
> case then ? or is this also not proper ?
>
no as said by arnd irq_to_gpio does not exsit
that's why I said the irq need to provide you the information as it's a
raising or failing irq
Best Regards,
J.
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: zhangfei @ 2014-01-15 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001c01cf11ed$039b6270$0ad22750$%jun@samsung.com>
On 01/15/2014 08:26 PM, Seungwon Jeon wrote:
>>>> @@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
>>>> int present;
>>>> struct dw_mci_slot *slot = mmc_priv(mmc);
>>>> struct dw_mci_board *brd = slot->host->pdata;
>>>> - int gpio_cd = !mmc_gpio_get_cd(mmc);
>>>> + struct dw_mci *host = slot->host;
>>>> + int gpio_cd = mmc_gpio_get_cd(mmc);
>>>>
>>>> /* Use platform get_cd function, else try onboard card detect */
>>>> if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
>>>> @@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
>>>> else if (brd->get_cd)
>>>> present = !brd->get_cd(slot->id);
>>>> else if (!IS_ERR_VALUE(gpio_cd))
>>>> - present = !!gpio_cd;
>>>> + present = !gpio_cd;
>>> !!gpio_cd or gpio_cd is correct, isn't it?
>>>
>>
>> No, mmc_gpio_get_cd(mmc) has to revert.
> I'm missing something?
> If card is detected, mmc_gpio_get_cd() returns non-zero, right?
> I guess gpio_cd should be kept.
>
Hmm, looks you are right.
Though not see clearly mmc_gpio_get_cd declaratoin, other drivers
directly set get_cd as mmc_gpio_get_cd.
.get_cd = mmc_gpio_get_cd
However, in our board cd =0 when card is deteced while cd=1 when card is
removed.
In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
set, as well as new property "caps2-mmc-cd-active-low".
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -73,6 +73,8 @@ Optional properties:
+* caps2-mmc-cd-active-low: cd pin is low when card active
+
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
+ if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
+ pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
+
But it looks strange "cd-active-low" describing "CD_ACTIVE_HIGH" flag.
When card active, cd = 0, and ACTIVE_HIGH is required to make
mmc_gpio_get_cd return 1.
int mmc_gpio_get_cd(struct mmc_host *host)
{
return !gpio_get_value_cansleep(ctx->cd_gpio) ^
!!(host->caps2 & MMC_CAP2_CD_ACTIVE_HIGH);
}
Thanks
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-15 13:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6938A.9050806@linaro.org>
On Wednesday 15 January 2014 21:56:26 zhangfei wrote:
> However, in our board cd =0 when card is deteced while cd=1 when card is
> removed.
> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> set, as well as new property "caps2-mmc-cd-active-low".
>
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -73,6 +73,8 @@ Optional properties:
> +* caps2-mmc-cd-active-low: cd pin is low when card active
> +
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> +
The MMC_CAP2_CD_ACTIVE_HIGH flag should only be required for
legacy platforms. With DT parsing, you can normally specify
the polarity of the GPIO line in the GPIO specifier in DT.
Arnd
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-15 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115134653.GF25824@e106331-lin.cambridge.arm.com>
On 13:46 Wed 15 Jan , Mark Rutland wrote:
> On Wed, Jan 15, 2014 at 12:40:41PM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 12:17 Wed 15 Jan , Mark Rutland wrote:
> > > On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > > The new interrupts-extended property, which reuses the phandle+arguments
> > > > pattern used by GPIOs and other core bindings, still have some issue.
> > > >
> > > > If an SoC have already specifiy interrupt and a board want to add specific
> > > > interrupt such as GPIO (which can be optionnal) be need to re-define
> > > > interrupts-extended. So allow to have an optionnale interrupts-extended-2
> > > > property.
> > > >
> > >
> > > NAK.
> > >
> > > This is a hack that works around a dts organisation issue. This is _not_
> > > a binding or parsing issue.
> >
> > So the DT is stupid. Yes w have board and SoC information
> > so we do not want to duplicate them. Having a way to descript SoC vs board
> > specific information need to be provided.
>
> I agree that the current situation isn't fantastic. That doesn't make
> the DT stupid. There are other solutions to this problem.
>
> >
> > >
> > > Properties can be overridden - just describe all of the interrupts in
> > > the final dts file.
> > this is wrong, which mean you duplicate informaation and duplicate bug and
> > fixes
>
> It's certainly not nice, but it doesn't make it wrong.
>
> The same problem can be found with any other list property that varies
> per-board. Hacking the parsing of each property is not a solution.
agreed we have the same issue on pinctrl as example and it's become a
nightmare
>
> Today the only way to implement what you want is to have the list in the
> final file.
>
> One way of working with that would be to have the common interrupts
> described in a shared macro in the soc file:
>
> #define SOC_COMMON_INTERRUPTS <&intc1 5 1>, <&intc2 1 0>
>
> Then the soc file can have:
>
> interrupts = SOC_COMMON_INTERRUPTS;
>
> And the board can have:
>
> interrupts = SOC_COMMON_INTERRUPTS, <&intc1 6 1>;
hugly for me as a board could work on x SoC so the final dt could be compile
for more than 1 SoC if you one alias
>
> That gains functionality equivalent to your proposal, without
> introducing new code or new edge cases in interrupt parsing. However, it
> does make it unclear how many interrupts are described, and it won't
> interact well with interrupt-names.
>
> Another, more invasive option would be extend the dts syntax and teach
> dtc to handle property appending. Then the soc dts could stay as it is,
> and the board dts could have something like:
>
> /append-property/ interrupts = <&intc1 6 1>;
> /append-property/ interrupt-names = "board-specific-irq";
>
> Both these options solve the issue at the source, are general to other
> properties, and allow more than one level of hierarchy (the proposed
> interrupts-extended-2 only allows one level).
agreed here but this touch dtc
Best Regards,
J.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH 04/04] ARM: shmobile: r8a7790 CCI configuration
From: Sudeep Holla @ 2014-01-15 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115122622.9437.27236.sendpatchset@w520>
Hi,
On 15/01/14 12:26, Magnus Damm wrote:
> From: Gaku Inami <gaku.inami.xw@bp.renesas.com>
>
> Add the settings of CCI-400 for enabling ca15/ca7 snoop on r8a7790.
>
> Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com>
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
>
> arch/arm/mach-shmobile/smp-r8a7790.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> --- 0005/arch/arm/mach-shmobile/smp-r8a7790.c
> +++ work/arch/arm/mach-shmobile/smp-r8a7790.c 2014-01-15 15:40:56.000000000 +0900
> @@ -28,6 +28,11 @@
> #define CA15RESCNT 0x0040
> #define CA7RESCNT 0x0044
> #define MERAM 0xe8080000
> +#define CCI_BASE 0xf0090000
> +#define CCI_SLAVE3 0x4000
> +#define CCI_SLAVE4 0x5000
> +#define CCI_SNOOP 0x0000
> +#define CCI_STATUS 0x000c
>
> static struct rcar_sysc_ch r8a7790_ca15_scu = {
> .chan_offs = 0x180, /* PWRSR5 .. PWRER5 */
> @@ -71,6 +76,16 @@ static void __init r8a7790_smp_prepare_c
> r8a7790_pm_init();
> rcar_sysc_power_up(&r8a7790_ca15_scu);
> rcar_sysc_power_up(&r8a7790_ca7_scu);
> +
> + /* enable snoop and DVM */
> + p = ioremap_nocache(CCI_BASE, 0x8000);
> + writel_relaxed(readl_relaxed(p + CCI_SLAVE3 + CCI_SNOOP) | 0x3,
> + p + CCI_SLAVE3 + CCI_SNOOP); /* ca15 */
> + writel_relaxed(readl_relaxed(p + CCI_SLAVE4 + CCI_SNOOP) | 0x3,
> + p + CCI_SLAVE4 + CCI_SNOOP); /* ca7 */
> + while (__raw_readl(p + CCI_STATUS));
> + /* wait for pending bit low */
> + iounmap(p);
> }
I have mentioned this before, please use drivers/bus/arm-cci.c
That already does the job you need here and you need to use CCI DT bindings
for base address.
Regards,
Sudeep
^ permalink raw reply
* [PATCH 0/2] Introduce PTE_WRITE for arm64
From: Steve Capper @ 2014-01-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
This series adds support for a separate PTE_WRITE bit, allowing one to
distinguish between writable clean ptes and read only ptes. At the
moment we have the following bit encodings:
PTE_DIRTY PTE_RDONLY
!pte_dirty && !pte_write 0 1
!pte_dirty && pte_write 0 1
pte_dirty && !pte_write 1 1
pte_dirty && pte_write 1 0
One reason we need to add the distinction is to fix a problem with huge
pages, described here:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/215155.html
The patch in the link above attempts to address this issue by bypassing
set_pte_at in the huge page code, but it was decided that the lack of
distinction between writable clean ptes and read only ptes should be
addressed instead as it could likely lead to other issues that we've
not yet seen.
The first patch in the series expands out PTE_BIT_FUNC to make life
much easier for cscope and tags users. Whilst the second patch actually
introduces PTE_WRITE.
LPAE on ARM is also affected by this issue and will need a similar
patch.
Steve Capper (2):
arm64: mm: Remove PTE_BIT_FUNC macro
arm64: mm: Introduce PTE_WRITE
arch/arm64/include/asm/pgtable.h | 93 +++++++++++++++++++++++++++-------------
1 file changed, 63 insertions(+), 30 deletions(-)
--
1.8.1.4
^ permalink raw reply
* [PATCH 1/2] arm64: mm: Remove PTE_BIT_FUNC macro
From: Steve Capper @ 2014-01-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389794833-7505-1-git-send-email-steve.capper@arm.com>
Expand out the pte manipulation functions. This makes our life easier
when using things like tags and cscope.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/pgtable.h | 51 ++++++++++++++++++++++++++++++++--------
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7f2b60a..27c7839 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -146,16 +146,47 @@ extern struct page *empty_zero_page;
#define pte_valid_user(pte) \
((pte_val(pte) & (PTE_VALID | PTE_USER)) == (PTE_VALID | PTE_USER))
-#define PTE_BIT_FUNC(fn,op) \
-static inline pte_t pte_##fn(pte_t pte) { pte_val(pte) op; return pte; }
-
-PTE_BIT_FUNC(wrprotect, |= PTE_RDONLY);
-PTE_BIT_FUNC(mkwrite, &= ~PTE_RDONLY);
-PTE_BIT_FUNC(mkclean, &= ~PTE_DIRTY);
-PTE_BIT_FUNC(mkdirty, |= PTE_DIRTY);
-PTE_BIT_FUNC(mkold, &= ~PTE_AF);
-PTE_BIT_FUNC(mkyoung, |= PTE_AF);
-PTE_BIT_FUNC(mkspecial, |= PTE_SPECIAL);
+static inline pte_t pte_wrprotect(pte_t pte)
+{
+ pte_val(pte) |= PTE_RDONLY;
+ return pte;
+}
+
+static inline pte_t pte_mkwrite(pte_t pte)
+{
+ pte_val(pte) &= ~PTE_RDONLY;
+ return pte;
+}
+
+static inline pte_t pte_mkclean(pte_t pte)
+{
+ pte_val(pte) &= ~PTE_DIRTY;
+ return pte;
+}
+
+static inline pte_t pte_mkdirty(pte_t pte)
+{
+ pte_val(pte) |= PTE_DIRTY;
+ return pte;
+}
+
+static inline pte_t pte_mkold(pte_t pte)
+{
+ pte_val(pte) &= ~PTE_AF;
+ return pte;
+}
+
+static inline pte_t pte_mkyoung(pte_t pte)
+{
+ pte_val(pte) |= PTE_AF;
+ return pte;
+}
+
+static inline pte_t pte_mkspecial(pte_t pte)
+{
+ pte_val(pte) |= PTE_SPECIAL;
+ return pte;
+}
static inline void set_pte(pte_t *ptep, pte_t pte)
{
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/2] arm64: mm: Introduce PTE_WRITE
From: Steve Capper @ 2014-01-15 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389794833-7505-1-git-send-email-steve.capper@arm.com>
We have the following means for encoding writable or dirty ptes:
PTE_DIRTY PTE_RDONLY
!pte_dirty && !pte_write 0 1
!pte_dirty && pte_write 0 1
pte_dirty && !pte_write 1 1
pte_dirty && pte_write 1 0
So we can't distinguish between writable clean ptes and read only
ptes. This can cause problems with ptes being incorrectly flagged as
read only when they are writable but not dirty.
This patch introduces a new software bit PTE_WRITE which allows us to
correctly identify writable ptes. PTE_RDONLY is now only clear for
valid ptes where a page is both writable and dirty.
Signed-off-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/pgtable.h | 48 +++++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 27c7839..b524dcd 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -28,7 +28,7 @@
#define PTE_FILE (_AT(pteval_t, 1) << 2) /* only when !pte_present() */
#define PTE_DIRTY (_AT(pteval_t, 1) << 55)
#define PTE_SPECIAL (_AT(pteval_t, 1) << 56)
- /* bit 57 for PMD_SECT_SPLITTING */
+#define PTE_WRITE (_AT(pteval_t, 1) << 57)
#define PTE_PROT_NONE (_AT(pteval_t, 1) << 58) /* only when !PTE_VALID */
/*
@@ -67,15 +67,15 @@ extern pgprot_t pgprot_default;
#define _MOD_PROT(p, b) __pgprot_modify(p, 0, b)
-#define PAGE_NONE __pgprot_modify(pgprot_default, PTE_TYPE_MASK, PTE_PROT_NONE | PTE_RDONLY | PTE_PXN | PTE_UXN)
-#define PAGE_SHARED _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
-#define PAGE_SHARED_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN)
-#define PAGE_COPY _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_RDONLY)
-#define PAGE_COPY_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_RDONLY)
-#define PAGE_READONLY _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_RDONLY)
-#define PAGE_READONLY_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_RDONLY)
-#define PAGE_KERNEL _MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY)
-#define PAGE_KERNEL_EXEC _MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY)
+#define PAGE_NONE __pgprot_modify(pgprot_default, PTE_TYPE_MASK, PTE_PROT_NONE | PTE_PXN | PTE_UXN)
+#define PAGE_SHARED _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)
+#define PAGE_SHARED_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_WRITE)
+#define PAGE_COPY _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
+#define PAGE_COPY_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN)
+#define PAGE_READONLY _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
+#define PAGE_READONLY_EXEC _MOD_PROT(pgprot_default, PTE_USER | PTE_NG | PTE_PXN)
+#define PAGE_KERNEL _MOD_PROT(pgprot_default, PTE_PXN | PTE_UXN | PTE_DIRTY | PTE_WRITE)
+#define PAGE_KERNEL_EXEC _MOD_PROT(pgprot_default, PTE_UXN | PTE_DIRTY | PTE_WRITE)
#define PAGE_HYP _MOD_PROT(pgprot_default, PTE_HYP)
#define PAGE_HYP_DEVICE __pgprot(PROT_DEVICE_nGnRE | PTE_HYP)
@@ -83,13 +83,13 @@ extern pgprot_t pgprot_default;
#define PAGE_S2 __pgprot_modify(pgprot_default, PTE_S2_MEMATTR_MASK, PTE_S2_MEMATTR(MT_S2_NORMAL) | PTE_S2_RDONLY)
#define PAGE_S2_DEVICE __pgprot(PROT_DEFAULT | PTE_S2_MEMATTR(MT_S2_DEVICE_nGnRE) | PTE_S2_RDWR | PTE_UXN)
-#define __PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_TYPE_MASK) | PTE_PROT_NONE | PTE_RDONLY | PTE_PXN | PTE_UXN)
-#define __PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
-#define __PAGE_SHARED_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN)
-#define __PAGE_COPY __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_RDONLY)
-#define __PAGE_COPY_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_RDONLY)
-#define __PAGE_READONLY __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_RDONLY)
-#define __PAGE_READONLY_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_RDONLY)
+#define __PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_TYPE_MASK) | PTE_PROT_NONE | PTE_PXN | PTE_UXN)
+#define __PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)
+#define __PAGE_SHARED_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_WRITE)
+#define __PAGE_COPY __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
+#define __PAGE_COPY_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN)
+#define __PAGE_READONLY __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN)
+#define __PAGE_READONLY_EXEC __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN)
#endif /* __ASSEMBLY__ */
@@ -140,7 +140,7 @@ extern struct page *empty_zero_page;
#define pte_dirty(pte) (pte_val(pte) & PTE_DIRTY)
#define pte_young(pte) (pte_val(pte) & PTE_AF)
#define pte_special(pte) (pte_val(pte) & PTE_SPECIAL)
-#define pte_write(pte) (!(pte_val(pte) & PTE_RDONLY))
+#define pte_write(pte) (pte_val(pte) & PTE_WRITE)
#define pte_exec(pte) (!(pte_val(pte) & PTE_UXN))
#define pte_valid_user(pte) \
@@ -148,13 +148,13 @@ extern struct page *empty_zero_page;
static inline pte_t pte_wrprotect(pte_t pte)
{
- pte_val(pte) |= PTE_RDONLY;
+ pte_val(pte) &= ~PTE_WRITE;
return pte;
}
static inline pte_t pte_mkwrite(pte_t pte)
{
- pte_val(pte) &= ~PTE_RDONLY;
+ pte_val(pte) |= PTE_WRITE;
return pte;
}
@@ -201,8 +201,10 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr,
if (pte_valid_user(pte)) {
if (pte_exec(pte))
__sync_icache_dcache(pte, addr);
- if (!pte_dirty(pte))
- pte = pte_wrprotect(pte);
+ if (pte_dirty(pte) && pte_write(pte))
+ pte_val(pte) &= ~PTE_RDONLY;
+ else
+ pte_val(pte) |= PTE_RDONLY;
}
set_pte(ptep, pte);
@@ -376,7 +378,7 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long addr)
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
const pteval_t mask = PTE_USER | PTE_PXN | PTE_UXN | PTE_RDONLY |
- PTE_PROT_NONE | PTE_VALID;
+ PTE_PROT_NONE | PTE_VALID | PTE_WRITE;
pte_val(pte) = (pte_val(pte) & ~mask) | (pgprot_val(newprot) & mask);
return pte;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH 2/5] phy: add support for indexed lookup
From: Kishon Vijay Abraham I @ 2014-01-15 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114142310.GA21169@xps8300>
Hi Heikki,
On Tuesday 14 January 2014 07:53 PM, Heikki Krogerus wrote:
> Hi Kishon,
>
> And happy new year..
Happy new year :-)
>
> On Tue, Jan 07, 2014 at 07:10:36PM +0530, Kishon Vijay Abraham I wrote:
>>>>> /**
>>>>> - * phy_get() - lookup and obtain a reference to a phy.
>>>>> + * phy_get_index() - obtain a phy based on index
>>>>
>>>> NAK. It still takes a 'char' argument and the name is misleading.
>>>> Btw are you replacing phy_get() or adding a new API in addition to phy_get()?
>>>
>>> Additional API. The phy_get() would in practice act as a wrapper after
>>
>> In this patch it looks like you've replaced phy_get().
>>> this. It could actually be just a #define macro in the include file.
>>> The function naming I just copied straight from gpiolib.c. I did not
>>> have the imagination for anything fancier.
>>>
>>> I would like to be able to use some function like phy_get_index() and
>>> be able to deliver it both the name and the index. With DT you guys
>>> will always be able to use the name (and the string will always
>>> supersede the index if we do it like this), but with ACPI, and possibly
>>> the platform lookup tables, the index can be used...
>>
>> I think in that case, we should drop the 'string' from phy_get_index since we
>> have the other API to handle that? I don't know about ACPI, but is it not
>> possible to use strings with ACPI?
>
> No unfortunately. We just have what the ACPI tables provide. The PHYs
> would be "child" device entries under the controller and we can only
> get handle to them based on the index.
>
> I think I'll skip this patch from this set. Let's wait until we have
> an actual ACPI DSDT describing some PHYs.
yeah.. sure.
Cheers
Kishon
^ permalink raw reply
* [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
From: Kishon Vijay Abraham I @ 2014-01-15 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140114143849.GB21169@xps8300>
Hi,
On Tuesday 14 January 2014 08:08 PM, Heikki Krogerus wrote:
> On Tue, Jan 07, 2014 at 06:31:52PM +0530, Kishon Vijay Abraham I wrote:
>>> In any case, having two device names to deal with does not add any
>>> more risk. These associations should always be made in the place where
>>> the phy device is created so you will always know it's device name.
>>
>> huh.. we should also know the 'controller' device name while defining these
>> associations and in some cases the controller device and phy device are created
>> in entirely different places.
>
> If you don't want to use the controller device name to do the
> matching, we can use the con_id string as well. I believe the lookup
> method I use in this set just needs a small change.
The point I'm trying to make is that we won't 'always' know the device names in
advance.
Btw how are you planning to differentiate between multiple controllers of the
same type with con_id?
Maybe I'm missing the actual intention of this patch. Do you face problem if
the PHY's have to know about it's consumers in ACPI?
>
> Is that OK with you?
>
>
>>> Normally the platform code creates these associations in the same
>>> place it creates the platform devices, so you definitely know what the
>>> device names will be.
>>>
>>> In this case it's actually created in drivers/mfd/twl-core.c, so I do
>>> need to update this and move the lookup table there. We can still
>>> deliver the user name as platform data, though I believe it's always
>>> "musb". Maybe we could actually skip that and just hard code the name?
>>
>> I would rather leave the way it is modelled now.
>
> Do you mean, leave it in the platform code? Why? We would reduce the
> platform code by moving it to the mfd driver. Or did I misunderstood
> something?
In this case, the lookup table will be used only for non-dt boot so don't see
much use in moving to mfd driver.
I meant if the new method is not solving any problem then I would prefer the
way it is modelled now where the PHY's know about it's consumers.
Btw where does device gets created in ACPI boot?
Cheers
Kishon
^ permalink raw reply
* [PATCH v1 2/5] pinctrl: st: Add Interrupt support.
From: Linus Walleij @ 2014-01-15 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389711134-21049-1-git-send-email-srinivas.kandagatla@st.com>
On Tue, Jan 14, 2014 at 3:52 PM, <srinivas.kandagatla@st.com> wrote:
> ST Pincontroller GPIO bank can have one of the two possible types of
> interrupt-wirings.
Interesting :-)
> +Pin controller node:
> +Required properties:
> - compatible : should be "st,<SOC>-<pio-block>-pinctrl"
> like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
> -- gpio-controller : Indicates this device is a GPIO controller
> -- #gpio-cells : Should be one. The first cell is the pin number.
> +- st,syscfg : Should be a phandle of the syscfg node.
So why do you add this? This is totally unused by your driver.
> - st,retime-pin-mask : Should be mask to specify which pins can be retimed.
> If the property is not present, it is assumed that all the pins in the
> bank are capable of retiming. Retiming is mainly used to improve the
> IO timing margins of external synchronous interfaces.
> -- st,bank-name : Should be a name string for this bank as
> - specified in datasheet.
Why do you have this property? The driver is not using it.
And what is wrong with just using that name for the node?
> -- st,syscfg : Should be a phandle of the syscfg node.
> +- ranges : specifies the ranges for the pin controller memory.
And what are they used for? I've never seen this before.
> +Optional properties:
> +- interrupts : Interrupt number of the irqmux. If the interrupt is shared
> + with other gpio banks via irqmux.
> + a irqline and gpio banks.
> +- reg : irqmux memory resource. If irqmux is present.
> +- reg-names : irqmux resource should be named as "irqmux".
> +
> +GPIO controller node.
> +Required properties:
> +- gpio-controller : Indicates this device is a GPIO controller
> +- #gpio-cells : Should be one. The first cell is the pin number.
> +- st,bank-name : Should be a name string for this bank as specified in
> + datasheet.
Again, why?
> +Optional properties:
> +- interrupts : Interrupt number for this gpio bank. If there is a dedicated
> + interrupt wired up for this gpio bank.
> +
> +- interrupt-controller : Indicates this device is a interrupt controller. GPIO
> + bank can be an interrupt controller iff one of the interrupt type either via
> +irqmux or a dedicated interrupt per bank is specified.
> +
> +- #interrupt-cells: the value of this property should be 2.
> + - First Cell: represents the external gpio interrupt number local to the
> + external gpio interrupt space of the controller.
> + - Second Cell: flags to identify the type of the interrupt
> + - 1 = rising edge triggered
> + - 2 = falling edge triggered
> + - 3 = rising and falling edge triggered
> + - 4 = high level triggered
> + - 8 = low level triggered
Correct, but reference symbols from:
include/dt-bindings/interrupt-controller/irq.h
in example.
>
> Example:
> pin-controller-sbc {
Please put in an updated example making use of all the
new props.
(...)
> diff --git a/drivers/pinctrl/pinctrl-st.c b/drivers/pinctrl/pinctrl-st.c
> @@ -271,6 +276,8 @@ struct st_gpio_bank {
> struct pinctrl_gpio_range range;
> void __iomem *base;
> struct st_pio_control pc;
> + struct irq_domain *domain;
> + int gpio_irq;
Why are you putting this IRQ into the state container when it can be
a function local variable in probe()?
> struct st_pinctrl {
> @@ -284,6 +291,8 @@ struct st_pinctrl {
> int ngroups;
> struct regmap *regmap;
> const struct st_pctl_data *data;
> + void __iomem *irqmux_base;
> + int irqmux_irq;
Dito. I think.
> +static int st_gpio_to_irq(struct gpio_chip *chip, unsigned offset)
> +{
> + struct st_gpio_bank *bank = gpio_chip_to_bank(chip);
> + int virq;
Just name this variable "irq". It is no more virtual than any other
IRQ.
> +
> + if (bank->domain && (offset < chip->ngpio))
> + virq = irq_create_mapping(bank->domain, offset);
No, don't do the create_mapping() call in the .to_irq() function.
Call irq_create_mapping() for *all* valid hwirqs in probe() and use
irq_find_mapping() here.
> +static void st_gpio_irq_disable(struct irq_data *d)
> +{
> + struct st_gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> + writel(BIT(d->hwirq), bank->base + REG_PIO_CLR_PMASK);
> +}
> +
> +static void st_gpio_irq_enable(struct irq_data *d)
> +{
> + struct st_gpio_bank *bank = irq_data_get_irq_chip_data(d);
> +
> + writel(BIT(d->hwirq), bank->base + REG_PIO_SET_PMASK);
> +}
I *strongly* suspect that these two should be replaced with
_mask()/_unmask() rather than using disable/enable.
Because that seems to be what they are doing.
(...)
> +static void __gpio_irq_handler(struct st_gpio_bank *bank)
> +{
> + unsigned long port_in, port_mask, port_comp, port_active;
> + int n;
> +
> + port_in = readl(bank->base + REG_PIO_PIN);
> + port_comp = readl(bank->base + REG_PIO_PCOMP);
> + port_mask = readl(bank->base + REG_PIO_PMASK);
> +
> + port_active = (port_in ^ port_comp) & port_mask;
> +
> + for_each_set_bit(n, &port_active, BITS_PER_LONG) {
> + generic_handle_irq(irq_find_mapping(bank->domain, n));
So what happens if new IRQs appear in the register while you are
inside this loop?
Check this recent patch:
http://marc.info/?l=linux-arm-kernel&m=138979164119464&w=2
Especially this:
+ for (;;) {
+ mask = ioread8(host->base + CLRHILVINT) & 0xff;
+ mask |= (ioread8(host->base + SECOINT) & SECOINT_MASK) << 8;
+ mask |= (ioread8(host->base + PRIMINT) & PRIMINT_MASK) << 8;
+ mask &= host->irq_high_enabled | (host->irq_sys_enabled << 8);
+ if (mask == 0)
+ break;
+ for_each_set_bit(n, &mask, BITS_PER_LONG)
+ generic_handle_irq(irq_find_mapping(host->domain, n));
+ }
> +static struct irq_chip st_gpio_irqchip = {
> + .name = "GPIO",
> + .irq_disable = st_gpio_irq_disable,
> + .irq_mask = st_gpio_irq_disable,
> + .irq_unmask = st_gpio_irq_enable,
Just implement mask/unmask as indicated earlier.
> + .irq_set_type = st_gpio_irq_set_type,
> +};
You need to mark IRQ GPIO lines as used for IRQ.
Add startup() and shutdown() hooks similar to those I add
in this patch:
http://marc.info/?l=linux-gpio&m=138977709114785&w=2
> +static int st_gpio_irq_domain_xlate(struct irq_domain *d,
> + struct device_node *ctrlr, const u32 *intspec, unsigned int intsize,
> + irq_hw_number_t *out_hwirq, unsigned int *out_type)
> +{
> + struct st_gpio_bank *bank = d->host_data;
> + int ret;
> + int pin = bank->gpio_chip.base + intspec[0];
> +
> + if (WARN_ON(intsize < 2))
> + return -EINVAL;
> +
> + *out_hwirq = intspec[0];
> + *out_type = intspec[1] & IRQ_TYPE_SENSE_MASK;
> +
> + ret = gpio_request(pin, ctrlr->full_name);
> + if (ret)
> + return ret;
> +
> + ret = gpio_direction_input(pin);
> + if (ret)
> + return ret;
We recently concluded that you should *NOT* call
gpio_request() and gpio_direction_input() from xlate or similar.
Instead: set up the hardware directly in mask/unmask callbacks
so that the irqchip can trigger IRQs directly without any
interaction with the GPIO subsystem.
By implementing the startup/shutdown hooks as indicated
above you can still indicate to the GPIO subsystem what is
going on and it will enforce that e.g. the line is not set to
output.
> static int st_gpiolib_register_bank(struct st_pinctrl *info,
> @@ -1219,7 +1378,7 @@ static int st_gpiolib_register_bank(struct st_pinctrl *info,
> struct pinctrl_gpio_range *range = &bank->range;
> struct device *dev = info->dev;
> int bank_num = of_alias_get_id(np, "gpio");
> - struct resource res;
> + struct resource res, irq_res;
> int err;
>
> if (of_address_to_resource(np, 0, &res))
> @@ -1248,6 +1407,43 @@ static int st_gpiolib_register_bank(struct st_pinctrl *info,
> }
> dev_info(dev, "%s bank added.\n", range->name);
>
> + /**
> + * GPIO bank can have one of the two possible types of
> + * interrupt-wirings.
> + *
> + * First type is via irqmux, single interrupt is used by multiple
> + * gpio banks. This reduces number of overall interrupts numbers
> + * required. All these banks belong to a single pincontroller.
> + * _________
> + * | |----> [gpio-bank (n) ]
> + * | |----> [gpio-bank (n + 1)]
> + * [irqN]-- | irq-mux |----> [gpio-bank (n + 2)]
> + * | |----> [gpio-bank (... )]
> + * |_________|----> [gpio-bank (n + 7)]
> + *
> + * Second type has a dedicated interrupt per each gpio bank.
> + *
> + * [irqN]----> [gpio-bank (n)]
> + */
> +
> + if (!of_irq_to_resource(np, 0, &irq_res)) {
> + bank->gpio_irq = irq_res.start;
> + irq_set_chained_handler(bank->gpio_irq, st_gpio_irq_handler);
> + irq_set_handler_data(bank->gpio_irq, bank);
> + }
> +
> + if (info->irqmux_irq > 0 || bank->gpio_irq > 0) {
> + /* Setup IRQ domain */
> + bank->domain = irq_domain_add_linear(np,
> + ST_GPIO_PINS_PER_BANK,
> + &st_gpio_irq_ops, bank);
> + if (!bank->domain)
> + dev_err(dev, "Failed to add irq domain for [%s]\n",
> + np->full_name);
> + } else {
> + dev_info(dev, "No IRQ support for [%s] bank\n", np->full_name);
Why is the [bank name] inside [brackets]?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-15 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3154671.7LPLgq8X4K@wuerfel>
On Wednesday 15 January 2014 14:59:59 Arnd Bergmann wrote:
> On Wednesday 15 January 2014 21:56:26 zhangfei wrote:
> > However, in our board cd =0 when card is deteced while cd=1 when card is
> > removed.
> > In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> > set, as well as new property "caps2-mmc-cd-active-low".
> >
> > --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > @@ -73,6 +73,8 @@ Optional properties:
> > +* caps2-mmc-cd-active-low: cd pin is low when card active
> > +
> >
> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> > + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> > +
>
> The MMC_CAP2_CD_ACTIVE_HIGH flag should only be required for
> legacy platforms. With DT parsing, you can normally specify
> the polarity of the GPIO line in the GPIO specifier in DT.
I missed the fact that we already have a "cd-inverted" property
as specified in bindings/mmc/mmc.txt. If your GPIO controller
does not handle polarity, you can use that.
Arnd
^ permalink raw reply
* [PATCH v1 3/5] pinctrl: st: Add software edge trigger interrupt support.
From: Linus Walleij @ 2014-01-15 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389711141-21090-1-git-send-email-srinivas.kandagatla@st.com>
On Tue, Jan 14, 2014 at 3:52 PM, <srinivas.kandagatla@st.com> wrote:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> ST pin controller does not have hardware support for detecting edge
> triggered interrupts, It only has level triggering support.
> This patch attempts to fake up edge triggers from hw level trigger
> support in software. With this facility now the gpios can be easily used
> for keypads, otherwise it would be difficult for drivers like keypads to
> work with level trigger interrupts.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Clever! Mostly I like the patch as it is but:
> for_each_set_bit(n, &port_active, BITS_PER_LONG) {
> + /* check if we are detecting fake edges ... */
> + pin_edge_cfg = ST_IRQ_EDGE_CONF(bank_edge_mask, n);
> +
> + if (pin_edge_cfg) {
> + /* edge detection. */
> + val = st_gpio_get(&bank->gpio_chip, n);
> + if (val)
> + writel(BIT(n), bank->base + REG_PIO_SET_PCOMP);
> + else
> + writel(BIT(n), bank->base + REG_PIO_CLR_PCOMP);
> +
> + if (pin_edge_cfg != ST_IRQ_EDGE_BOTH &&
> + !((pin_edge_cfg & ST_IRQ_EDGE_FALLING) ^ val))
> + continue;
> + }
> +
Please insert comments here to explain what you are actually doing
because I sure as hell do not understand this code without comments
describing the trick used.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Seungwon Jeon @ 2014-01-15 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6938A.9050806@linaro.org>
On Wed, January 15, 2014, Zhangfei wrote:
> On 01/15/2014 08:26 PM, Seungwon Jeon wrote:
>
> >>>> @@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> >>>> int present;
> >>>> struct dw_mci_slot *slot = mmc_priv(mmc);
> >>>> struct dw_mci_board *brd = slot->host->pdata;
> >>>> - int gpio_cd = !mmc_gpio_get_cd(mmc);
> >>>> + struct dw_mci *host = slot->host;
> >>>> + int gpio_cd = mmc_gpio_get_cd(mmc);
> >>>>
> >>>> /* Use platform get_cd function, else try onboard card detect */
> >>>> if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> >>>> @@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> >>>> else if (brd->get_cd)
> >>>> present = !brd->get_cd(slot->id);
> >>>> else if (!IS_ERR_VALUE(gpio_cd))
> >>>> - present = !!gpio_cd;
> >>>> + present = !gpio_cd;
> >>> !!gpio_cd or gpio_cd is correct, isn't it?
> >>>
> >>
> >> No, mmc_gpio_get_cd(mmc) has to revert.
> > I'm missing something?
> > If card is detected, mmc_gpio_get_cd() returns non-zero, right?
> > I guess gpio_cd should be kept.
> >
>
> Hmm, looks you are right.
> Though not see clearly mmc_gpio_get_cd declaratoin, other drivers
> directly set get_cd as mmc_gpio_get_cd.
> .get_cd = mmc_gpio_get_cd
>
> However, in our board cd =0 when card is deteced while cd=1 when card is
> removed.
> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> set, as well as new property "caps2-mmc-cd-active-low".
Ok, you could do more.
mmc_gpio_get_cd() is expected to return non-zero if card is detection.
>
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -73,6 +73,8 @@ Optional properties:
> +* caps2-mmc-cd-active-low: cd pin is low when card active
> +
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> +
>
> But it looks strange "cd-active-low" describing "CD_ACTIVE_HIGH" flag.
> When card active, cd = 0, and ACTIVE_HIGH is required to make
> mmc_gpio_get_cd return 1.
I think your board seems not to use pull-up on GPIO line for card detection.
So, MMC_CAP2_CD_ACTIVE_HIGH would be needed.
Thanks,
Seungwon Jeon
> int mmc_gpio_get_cd(struct mmc_host *host)
> {
> return !gpio_get_value_cansleep(ctx->cd_gpio) ^
> !!(host->caps2 & MMC_CAP2_CD_ACTIVE_HIGH);
> }
>
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" 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
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